Здравствуйте, vpedak, Вы писали:
V>то, что SOA это архитектурный подход — это понятно, только кроме веб сервисов на данный момент никто не сможет обеспечить этот подход (про корбу только давайте сначала не начинать ) когда требуется независимость от языка разработки.
кроме веб-сервисов ещё есть асинхронный мессаджинг. соответственно, если конкретный производитель message service предоставляет API на нескольких языках, то возникает какая-то независимость от языка разработки (в пределах поддерживаемых), но добавляется зависимость от производителя.
усреднённые подходы тоже годятся. например, в случае java JMS как стандартный способ может использоваться для взаимодействия всех компонентов, написанных на Java. для всех остальных же пишутся или конфигурируются (если платформа позволяет) web services, адаптирующие посылку-приём сообщений
я при этом говорю лишь про техническую реализуемость, и старательно избегаю рассуждений о том, насколько это хорошо в целом.
V>Я в этом проблемы не вижу (то кто и как все это толкует). Технически то возможно обеспечить работу с разных платфорт на веб сервисах, так что все-таки есть альтернатива корбе. Я именно об этом.
корба-то помощнее будет, собственно о чём и речь — чистая корба сама по себе сложна, но аппсервер, сделанный по стандарту должен её поддерживать в том или ином виде в качестве транспорта ejb (с предоставлением соотв. обязательных сервисов). соответственно, имея в арсенале ejb(slsb)/corba/jms/web/web services, можно добиться многого, если не всего. и для большинства случаев это будет более оправдано в экономическом смысле, чем писание доморощенных протоколов, равно как и прикручивание standalone-реализаций web services.
Здравствуйте, C0s, Вы писали:
C0s>корба-то помощнее будет, собственно о чём и речь — чистая корба сама по себе сложна, но аппсервер, сделанный по стандарту должен её поддерживать в том или ином виде в качестве транспорта ejb (с предоставлением соотв. обязательных сервисов). соответственно, имея в арсенале ejb(slsb)/corba/jms/web/web services, можно добиться многого, если не всего. и для большинства случаев это будет более оправдано в экономическом смысле, чем писание доморощенных протоколов, равно как и прикручивание standalone-реализаций web services.
Здравствуйте, vpedak, Вы писали:
V>Здравствуйте, C0s, Вы писали:
C0s>>для меня SOA — это архитектурный подход, SOAP — лишь его созвучие, а стандарты из мира WebServices напяливаются на аббревиатуру SOA только маркетологами
V>то, что SOA это архитектурный подход — это понятно, только кроме веб сервисов на данный момент никто не сможет обеспечить этот подход (про корбу только давайте сначала не начинать ) когда требуется независимость от языка разработки.
Вы под веб-сервисами имеете в виду этот кошмар в виде SOAP/WSDL/UDDI? Да ну. Между прочим, веб сервисы работали за 10 лет до SOAP и прекрасно без него обходились.
Типичный пример веб-сервиса — процессинг платежей по кредиткам. Отродясь он работал в виде HTTP POST, и имел все преимущества протокола, независящего от языка, проходящего скрозь прокси и все остальные бла-бла-бла.
При этом реально написать клиента к этому сервису до сих пор проще, чем заиспользовать мега-SOAP.
Есть еще масса веб-сервисных протоколов, которые на практике оказываются более удобными.
При этом возникает странный парадокс: от SOAP мы ожидаем всего, что дает нам стандарт. В частности, облегченное освоение этого протокола, простоту отладки, и прочее удешевление разработки клиентов и сервисов.
Но как ни странно, на "маленьких" протоколах SOAP не помогает, т.к. почти любая альтернатива будет не слишком сложнее в освоении.
Что еще более странно, на больших протоколах SOAP начинает мешать. Я уже писал про проблемы с поддержкой разных версий протокола и прочей ерундой.
Так что я совершенно согласен с SOA, но к SOAP никакой теплоты не испытываю.
V>Я в этом проблемы не вижу (то кто и как все это толкует). Технически то возможно обеспечить работу с разных платфорт на веб сервисах, так что все-таки есть альтернатива корбе. Я именно об этом.
Ну, я бы всё же разделил протокол и архитектуру. Альтернативных соапу протоколов — вагон и маленькая тележка, только они меньше раскручены. Технически он из себя ничего особенного не представляет.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Вы под веб-сервисами имеете в виду этот кошмар в виде SOAP/WSDL/UDDI? Да ну. Между прочим, веб сервисы работали за 10 лет до SOAP и прекрасно без него обходились. S>Типичный пример веб-сервиса — процессинг платежей по кредиткам. Отродясь он работал в виде HTTP POST, и имел все преимущества протокола, независящего от языка, проходящего скрозь прокси и все остальные бла-бла-бла. S>При этом реально написать клиента к этому сервису до сих пор проще, чем заиспользовать мега-SOAP.
Дело не в SOAP, а в том что есть WSDL который описывает интерфейс веб сервиса (чего совсем нет в вашем подходе дергания сервера по HTTP) и есть еще UDDI, который находит нужные сервисы. Без этого SOA жить не будет.
Здравствуйте, vpedak, Вы писали:
V>Дело не в SOAP, а в том что есть WSDL который описывает интерфейс веб сервиса (чего совсем нет в вашем подходе дергания сервера по HTTP) и есть еще UDDI, который находит нужные сервисы. Без этого SOA жить не будет.
SOA прекрасно жила и будет жить без WSDL и UDDI. Эти протоколы используются только на этапе разработки, а в рантайме бегают исключительно HTTP реквесты. Которые в случае SOAP подчиняются достаточно идиотским и плохо переносимым правилам.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>SOA прекрасно жила и будет жить без WSDL и UDDI. Эти протоколы используются только на этапе разработки, а в рантайме бегают исключительно HTTP реквесты. Которые в случае SOAP подчиняются достаточно идиотским и плохо переносимым правилам.
Не совсем так, сам сервис в рантайме находится через UUDI сначала прежде чем уже его по SOAP вызовут. И как я уже писал у SOAP и WSDL есть одно преимущество перед простыми HTTP запросами что они описывают интерфейс вызова сервиса. Одно это сводит на нет преимущества простого HTTP запроса (если они и были вообще).
Здравствуйте, vpedak, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
S>>SOA прекрасно жила и будет жить без WSDL и UDDI. Эти протоколы используются только на этапе разработки, а в рантайме бегают исключительно HTTP реквесты. Которые в случае SOAP подчиняются достаточно идиотским и плохо переносимым правилам.
V>Не совсем так, сам сервис в рантайме находится через UUDI сначала прежде чем уже его по SOAP вызовут.
1. Это используется в жизни?
2. Вы уверены, что это является неотъемлемой частью идеологии SOA?
V> И как я уже писал у SOAP и WSDL есть одно преимущество перед простыми HTTP запросами что они описывают интерфейс вызова сервиса.
Они описывают его из рук вон плохо. В том смысле, что предназначены для генераторов клиентских stub'ов, что якобы облегчает написание клиентского кода.
В реальности, однако, WSDL не заменяет документации по сервису. А более простые протоколы не требуют такого чудовищного стабного кода. V>Одно это сводит на нет преимущества простого HTTP запроса (если они и были вообще).
Увы, они есть. Практика показывает — написать клиента к "простому" HTTP протоколу в разы проще, чем к веб-сервису. Особенно это касается языков, для которых не предусмотрены готовые решения от MS. На досуге потренируйтесь в реализации SOAP клиента на PHP/Perl/C++.
V>А какие кстати правила которые плохо переносятся?
Я сейчас навскидку не назову, но народ постоянно встревает с попытками заимпортировать WSDL от С#-ного сервиса в, к примеру, Delphi.
Кроме того, из-за проблем с версионированием SOAP сервисов у народа возникает искушение перейти к непрозрачно сериализуемым структурам, типа дотнетного датасета. Это забарывает излишнюю типизированность SOAP, но убивает на корню кроссплатформенность. V>Вячеслав Педак
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Я сейчас навскидку не назову, но народ постоянно встревает с попытками заимпортировать WSDL от С#-ного сервиса в, к примеру, Delphi. S>Кроме того, из-за проблем с версионированием SOAP сервисов у народа возникает искушение перейти к непрозрачно сериализуемым структурам, типа дотнетного датасета. Это забарывает излишнюю типизированность SOAP, но убивает на корню кроссплатформенность.
А потом технология, язык и/или платформа X объявляется умирающей и/или неправильной, потому как на поддерживает частную фичу от Y.
Y объявляется следующей серебрянной пулей, используя которую можно лежать под пальмой и ничего не делать.
До следующего раза, когда обнаружится новая фенечка в виде Z.
PS Все намеки и совпадения надуманны.
PS 2 Искали несколько месяцев назад программиста на COBOL. Сами в г.Москва.
Ближайший "москвич" нашелся в Бельгии, приехать за 6000 евро/месяц отказался.
V>>Не совсем так, сам сервис в рантайме находится через UUDI сначала прежде чем уже его по SOAP вызовут. S>1. Это используется в жизни?
да
S>2. Вы уверены, что это является неотъемлемой частью идеологии SOA?
да
Меркури недавно купила Sysinet (произволителя этих самых реестров для SOA) за $105 миллионов, а потом HP купил и ее за $4.5 миллиарда
Вот такие вот цифирки для раздумья
V>> И как я уже писал у SOAP и WSDL есть одно преимущество перед простыми HTTP запросами что они описывают интерфейс вызова сервиса. S>Они описывают его из рук вон плохо. В том смысле, что предназначены для генераторов клиентских stub'ов, что якобы облегчает написание клиентского кода.
А можно тогда привести пример хорошего оисания ремотного интерфейса если этот плох? А то по мне, дак он имеет все что надо и протокол описывает и типы и вызовы. Что еще то надо?
S>В реальности, однако, WSDL не заменяет документации по сервису. А более простые протоколы не требуют такого чудовищного стабного кода.
Вы прочтите спеку по SOAP — он простой как "грабли", у него в названии даже — simple. И опять же если есть лучше протоколы — поделитесь...
Я не вредничаю, я правда хочу понять, может я пропустил чего.
S>Увы, они есть. Практика показывает — написать клиента к "простому" HTTP протоколу в разы проще, чем к веб-сервису. Особенно это касается языков, для которых не предусмотрены готовые решения от MS. На досуге потренируйтесь в реализации SOAP клиента на PHP/Perl/C++.
Не хочу, на java и C# это делается очень просто. Все остальные языки для меня лично не сильно интересны. Я работаю в конкретной области бизнес приложений, где они наиболее востребованы.
V>>А какие кстати правила которые плохо переносятся? S>Я сейчас навскидку не назову, но народ постоянно встревает с попытками заимпортировать WSDL от С#-ного сервиса в, к примеру, Delphi. S>Кроме того, из-за проблем с версионированием SOAP сервисов у народа возникает искушение перейти к непрозрачно сериализуемым структурам, типа дотнетного датасета. Это забарывает излишнюю типизированность SOAP, но убивает на корню кроссплатформенность.
Я не совсем понял что такое проблемы с версионированием SOAP сервисов, насколько я помню SOAP вообще редко меняется.
А про то, что народ непрозрачно сериализует — дак ножиком можно и хлеб резать и людей убивать — думать оно всегда полезно. Технология не всегда может влиять на неправильное ее использование.
Здравствуйте, vpedak, Вы писали: S>>1. Это используется в жизни? V>да
круто. S>>2. Вы уверены, что это является неотъемлемой частью идеологии SOA? V>да
А можно ссылочку, где про это почитать? А то я, судя по всему, слишком расслабленно трактую термин SOA. V>Меркури недавно купила Sysinet (произволителя этих самых реестров для SOA) за $105 миллионов, а потом HP купил и ее за $4.5 миллиарда V>Вот такие вот цифирки для раздумья
Я слишком туп, чтоб думать над голыми цифирками. Вот ничем не хуже цифирка.
Поясни, чем именно занимается эта Sysinet. А то я по немецки не слишком бегло читаю.
V>А можно тогда привести пример хорошего оисания ремотного интерфейса если этот плох?
Да сколько угодно. Вот например, один из протоколов Authorize.Net.
Обрати внимание на невыразимую в WSDL информацию: как настроить, что передавать.
Написать клиента к Authorize.net очень легко, несмотря на отсуствие генератора стабов. V>А то по мне, дак он имеет все что надо и протокол описывает и типы и вызовы. Что еще то надо?
Надо описывать семантику вызовов. А про это WSDL тебе ничего не скажет.
V>Вы прочтите спеку по SOAP — он простой как "грабли", у него в названии даже — simple. http://www.w3.org/TR/soap12-part1/ — 55 страниц, не считая ссылок на внешние документы. Я дал пример, где протокол описан вместе с конкретным API, и то он занимает меньше места. V>И опять же если есть лучше протоколы — поделитесь...
Лучшие — есть.
Стандартных — нету.
Значительно лучшим протоколом является XML-RPC.
Лучшим протоколом является REST.
Лучшим протоколом является JsHttpRequest — его клиентом может выступать даже браузер. V>Я не вредничаю, я правда хочу понять, может я пропустил чего.
S>>Увы, они есть. Практика показывает — написать клиента к "простому" HTTP протоколу в разы проще, чем к веб-сервису. Особенно это касается языков, для которых не предусмотрены готовые решения от MS. На досуге потренируйтесь в реализации SOAP клиента на PHP/Perl/C++. V>Не хочу, на java и C# это делается очень просто. Все остальные языки для меня лично не сильно интересны.
Если вас интересует только два языка в плане написания клиентов к вашему сервису, то вместо отдачи WSDL и надежды на то, что у разработчика клиента под рукой окажется нужный генератор, проще сделать 2 (две) клиентские библиотеки на этих языках. SOAP создавался с претензией на кроссплатформенность; если ее выкинуть, то становится неясно, зачем вообще всё это понапружено. V>Я работаю в конкретной области бизнес приложений, где они наиболее востребованы.
Я понимаю — потому мне и интересно общаться. Мы работаем в совсем другой области, и интересно сравнить опыт применения.
V>Я не совсем понял что такое проблемы с версионированием SOAP сервисов, насколько я помню SOAP вообще редко меняется.
Я не про сам SOAP, я про API на основе SOAP. То, что написано в WSDL, не вырубишь топором. Фундаментальная проблема — в жуткой затипизированности SOAP.
API обычно существует не сам по себе; он предоставляет доступ к некоторой модели предметной области. Эта модель всё время меняется. И API должен, с одной стороны, давать доступ к этим новым явлениям, а с другой стороны — обеспечивать обратную совместимость. Банальный Name/Value POST (как в примере от Authorize.net), к примеру, совершенно к этому нечувствителен. Сервер, увидев, что какие-то из новых параметров не переданы, поймет, что клиент вызывает старую версию протокола, и вернет соответствующие данные. В XML-RPC клиент точно указывает, какая часть структуры ему интересна, и сервер никогда не вернет ему лишнего. И только в SOAP у нас зашита определенная структура возвращаемых данных, и добавление в нее поля с практической точки зрения оборачивается созданием нового ендпоинта.
V>А про то, что народ непрозрачно сериализует — дак ножиком можно и хлеб резать и людей убивать — думать оно всегда полезно. Технология не всегда может влиять на неправильное ее использование.
Еще как может. Если единственный способ обеспечить две версии API в одном ендпоинте сводится к отказу от типизации — все так и будут делать.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vpedak, Вы писали:
V>>>Не совсем так, сам сервис в рантайме находится через UUDI сначала прежде чем уже его по SOAP вызовут. S>>1. Это используется в жизни? V>да
Честно говоря, ни разу еще не видел, чтобы оно нормально использовалось. Как и баззворды типа ESB (Enterprise Service Bus).
V>А можно тогда привести пример хорошего оисания ремотного интерфейса если этот плох? А то по мне, дак он имеет все что надо и протокол описывает и типы и вызовы. Что еще то надо?
Честно говоря, мне больше всего IDL из CORBA нравился. Если бы оттуда просто выкинули некоторые части и добавили некоторые дополнительные фичи (типа улучшеного версирования) — было бы вообще замечательно.
S>>В реальности, однако, WSDL не заменяет документации по сервису. А более простые протоколы не требуют такого чудовищного стабного кода. V>Вы прочтите спеку по SOAP — он простой как "грабли", у него в названии даже — simple. И опять же если есть лучше протоколы — поделитесь...
SOAP сейчас официально не значит ничего (а до этого расшифровывался еще как Service Oriented Architecture Protocol) И он уж точно не Simple, и не Object Access.
Я лично использую SOAP как последнее средство для интеграции или когда он диктуется внешними условиями. Вообще, по ощущения SOAP сейчас повторяет путь CORBA — та же куча стандартов, которые целиком никто пока не реализует, та же тяжеловесность и та же "enterprise"-овость.
Здравствуйте, Sinclair, Вы писали:
S>Лучшие — есть. S>Стандартных — нету.
Вот в этом-то и большой плюс WDSL. Как не крути, а это стандарт, который поддерживают все кому не лень и по многу раз.
S> И только в SOAP у нас зашита определенная структура возвращаемых данных, и добавление в нее поля с практической точки зрения оборачивается созданием нового ендпоинта.
У меня пока стойкое ощущение, что это правильно.
S>Еще как может. Если единственный способ обеспечить две версии API в одном ендпоинте сводится к отказу от типизации — все так и будут делать.
А в чем смысл иметь две версии протокола на одном эндпоинте?
Здравствуйте, IB, Вы писали: S>>Лучшие — есть. S>>Стандартных — нету. IB>Вот в этом-то и большой плюс WDSL. Как не крути, а это стандарт, который поддерживают все кому не лень и по многу раз.
Угу. Только вот этих "всех" мало, и все поддерживают его по-разному.
IB>А в чем смысл иметь две версии протокола на одном эндпоинте?
В том, что тебе не нужно тащить столько ендпоинтов, сколько у тебя было версий протокола. Из шарпа это еще и не вполне тривиально сделать — для корректной сериализации нужно тащить с собой N комплектов классов передаваемых данных.
Трудно написать клиента, поддерживающего разные версии сервера — он должен стучаться в кучу потенциальных ендпоинтов, вместо того, чтобы один раз подключиться и договориться. При апгрейде сервера клиенту нужно перенастроить подключение руками.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>Честно говоря, ни разу еще не видел, чтобы оно нормально использовалось. Как и баззворды типа ESB (Enterprise Service Bus).
С этиим согласен, что это все очередная разводка на деньги для маркетологов Но слишком уж много денег в это вложено, так что может и доведут до нормального состояния
C>Честно говоря, мне больше всего IDL из CORBA нравился. Если бы оттуда просто выкинули некоторые части и добавили некоторые дополнительные фичи (типа улучшеного версирования) — было бы вообще замечательно.
Я тоже за, только ИМНО Corba — умерла уже (выше все это обсуждали)
C>SOAP сейчас официально не значит ничего (а до этого расшифровывался еще как Service Oriented Architecture Protocol) И он уж точно не Simple, и не Object Access.
WSDL содержит информацию и о том куда передавать и как.
V>>Вы прочтите спеку по SOAP — он простой как "грабли", у него в названии даже — simple. S> http://www.w3.org/TR/soap12-part1/ — 55 страниц, не считая ссылок на внешние документы. Я дал пример, где протокол описан вместе с конкретным API, и то он занимает меньше места.
Нельзя сравнивать general purpose коммуникационный протокол, который позволяет описывать и передавать любые данные и специфичный протокол.
Проблема то в том, что если везде пихать специфичные протоколы, то потом поддерживать это все будет очень тяжело
V>>И опять же если есть лучше протоколы — поделитесь... S>Лучшие — есть. S>Стандартных — нету.
Ну вот это видимо и самая большая проблема.
V>>Не хочу, на java и C# это делается очень просто. Все остальные языки для меня лично не сильно интересны. S>Если вас интересует только два языка в плане написания клиентов к вашему сервису, то вместо отдачи WSDL и надежды на то, что у разработчика клиента под рукой окажется нужный генератор, проще сделать 2 (две) клиентские библиотеки на этих языках.
Мы так и сделали
S>SOAP создавался с претензией на кроссплатформенность; если ее выкинуть, то становится неясно, зачем вообще всё это понапружено.
Но маркетинг требует поддержки web services как стандартного межплатформенного API
V>>Я не совсем понял что такое проблемы с версионированием SOAP сервисов, насколько я помню SOAP вообще редко меняется. S>Я не про сам SOAP, я про API на основе SOAP. То, что написано в WSDL, не вырубишь топором. Фундаментальная проблема — в жуткой затипизированности SOAP. S>API обычно существует не сам по себе; он предоставляет доступ к некоторой модели предметной области. Эта модель всё время меняется. И API должен, с одной стороны, давать доступ к этим новым явлениям, а с другой стороны — обеспечивать обратную совместимость. Банальный Name/Value POST (как в примере от Authorize.net), к примеру, совершенно к этому нечувствителен. Сервер, увидев, что какие-то из новых параметров не переданы, поймет, что клиент вызывает старую версию протокола, и вернет соответствующие данные. В XML-RPC клиент точно указывает, какая часть структуры ему интересна, и сервер никогда не вернет ему лишнего. И только в SOAP у нас зашита определенная структура возвращаемых данных, и добавление в нее поля с практической точки зрения оборачивается созданием нового ендпоинта.
Но это же тоже несложно решить архитектурно. Кто мешает на том же SOPA передавать name value значения. ИМНО от типизированности больше пользы чем вреда. Зато гадость лишнюю не засунут в данные.
Да и создание нового end point это тоже не плохой вариант, то что будет 2 end pointa поддерживающие разные версии — это же хорошо даже.
Note, however, that a system does not necessarily need to use any or all of these standards to be "service-oriented." For example, some service oriented systems have been implemented using Corba, Jini and REST.
V>Здесь все подробно описано — https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-130-27^1461_4000_100__
Ок, понятно.
S>>Обрати внимание на невыразимую в WSDL информацию: как настроить, что передавать. V>WSDL содержит информацию и о том куда передавать и как.
Нет. В WSDL нигде, к примеру, не будет сказано в каком порядке вызывать методы, или что они делают.
V>Нельзя сравнивать general purpose коммуникационный протокол, который позволяет описывать и передавать любые данные и специфичный протокол.
Конечно можно. Мы говорим о том, что вменяемый протокол описывается гораздо короче. V>Проблема то в том, что если везде пихать специфичные протоколы, то потом поддерживать это все будет очень тяжело
На практике, я думаю, потребителей Authorize.net на пару порядков больше, чем у веб сервисов. И с поддержкой у них не слишком плохо.
V>Ну вот это видимо и самая большая проблема.
Ага.
V>Мы так и сделали
Тогда какая вам разница — есть WSDL или его нету?
S>>SOAP создавался с претензией на кроссплатформенность; если ее выкинуть, то становится неясно, зачем вообще всё это понапружено. V>Но маркетинг требует поддержки web services как стандартного межплатформенного API
Вот! И мы наступили в те же грабли. Маркетинг, голимый маркетинг.
V>Но это же тоже несложно решить архитектурно. Кто мешает на том же SOPA передавать name value значения.
)
Это прямо по анекдоту про попытку заинтересовать бизнесом.
Ну и надо было столько трахаться, WSDL, импорт, стабы, неймспейсы, кастом хидеры, эмуляция транзакций — и всё ради чего? Чтобы name/value передавать? Чудовищно!
V>ИМНО от типизированности больше пользы чем вреда. Зато гадость лишнюю не засунут в данные.
ХаХа. V>Да и создание нового end point это тоже не плохой вариант, то что будет 2 end pointa поддерживающие разные версии — это же хорошо даже.
Эта иллюзия продолжается у всех по-разному. У меня она начала проходить к третьей версии нашего протокола, а выход четвертой ее окончательно похоронил.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vpedak, Вы писали:
C>>Честно говоря, ни разу еще не видел, чтобы оно нормально использовалось. Как и баззворды типа ESB (Enterprise Service Bus). V>С этиим согласен, что это все очередная разводка на деньги для маркетологов Но слишком уж много денег в это вложено, так что может и доведут до нормального состояния
Сам-то в это веришь? Текущий SOAP вообще один-в-один повторяет CORBA.
C>>Честно говоря, мне больше всего IDL из CORBA нравился. Если бы оттуда просто выкинули некоторые части и добавили некоторые дополнительные фичи (типа улучшеного версирования) — было бы вообще замечательно. V>Я тоже за, только ИМНО Corba — умерла уже (выше все это обсуждали)
В CORBA было слишком много неправильных решений, так что умерла она вполне заслужено.
Кстати, мне сейчас больше всего нравятся тупые легковесные протоколы типа Hessian (используем его для связи программы на С++ на встроеном устройстве и сервера на Java) или XML-RPC (используем для клиентского API).
C>>SOAP сейчас официально не значит ничего (а до этого расшифровывался еще как Service Oriented Architecture Protocol) И он уж точно не Simple, и не Object Access. V>Был он simple — http://en.wikipedia.org/wiki/SOAP
Так я же написал "сейчас"
Note, however, that a system does not necessarily need to use any or all of these standards to be "service-oriented." For example, some service oriented systems have been implemented using Corba, Jini and REST.
Дак кто против то? Я говорил только о том, что на мой взгляд сейчас SOA наиболее реально реализовать именно на веб сервисах, так как они более всего распространены, стандартизованы и все.
S>Нет. В WSDL нигде, к примеру, не будет сказано в каком порядке вызывать методы, или что они делают.
Да, но для этого можно использовать BPEL который очень хорошо на эти веб сервисы ложится
S>Тогда какая вам разница — есть WSDL или его нету?
Ну мы же не о нашем конкретном случае говорим, а вообще... Что нам ждать в будующем
S>Вот! И мы наступили в те же грабли. Маркетинг, голимый маркетинг.
Это да, только славо богу маркетинг не может диктовать всего, поэтому мы все равно будем поддерживать наше custom решение и веб сервисы пойдут в добавку к этому
S>Ну и надо было столько трахаться, WSDL, импорт, стабы, неймспейсы, кастом хидеры, эмуляция транзакций — и всё ради чего? Чтобы name/value передавать? Чудовищно!
Я же не говорю что так надо делать обызательно, но так ничто не межает сделать технически. Выбор — это всегда хорошо.
S>Эта иллюзия продолжается у всех по-разному. У меня она начала проходить к третьей версии нашего протокола, а выход четвертой ее окончательно похоронил.
Ну если для вас добавление нового ендпойнта так болезненно, то я то тут при чем? Сделайте один ендпойнт, а все старые поставьте заглушки которые будут просто конвертировать старые вызовы к новому формату и все.