Немного о "многозвенках"
Думал, что тема преимущества использования многозвенных систем против классического "клиент-сервер" исчерпана уже давно. Однако, нет. Копья ломаются до сих пор... (см., например, RSDN). Поэтому решил выложить один старый непубликовавшийся (в силу незаконченности) материал, который, тем не менее, похоже не потерял своей актуальности:В этом материале вы не найдете обсуждения архитектуры Web-служб. Не только потому что материал не был закончен, но потому, что (мое личное глубокое убеждение) Web Services в большей степени касаются вопроса интеграции приложений (через публикацию well-defined интерфейсов во "внешний мир"), чем основы внутрикорпоративной прикладной инфраструктуры. Распределенные транзакции, безопасность, службы именования, асинхронный обмен информацией.... - если обсуждать эти вопросы в контексте интероперабельности (то есть прозрачности взаимодействия разнородных систем), стандартного (на уровне именно стандартов, а не соглашений между отдельными компаниями) их решения, увы, нет. SOAP (в подавляющем большинстве случаев по HTTP...), WSDL (не дай-то вам использовать неинтероперабельные структуры и схемы), UDDI (ау, ты где?) - вот что стандартизировано в более-менее приемлемом виде (даже пришлось создавать отдельную организацию - WS-I, несмотря на работу W3C. Кстати, неплохой материал: "Web Services: Standards Breed Like Crazy..."). Бизнес-логика на Web-сервере (по моему в это уже играли - CGI и т.п.)? Производительность на уровне самой шины? Вы все еще работаете по HTTP? :-) ...
Комментарии: 8:
Сергей, складывается впечателение, что ты абсолютный противник вебсервисов в принципе. Но это же не так. Т.е. наверняка есть место вебсервисам в жизни не только для межсистемного обмена. Пример такой системы можно привести такой: территориально распределенная организация с выделенными каналами связи посредственного качества, по которым нормально ходит только http. Использовать вебинтерфейс либо трудно, либо нецелесообразно. остается вебсервис в качестве "транспорта". Особенно если сделать такую реализацию логики, при которой нужен один единственный себсервис с одним единственным методом.
Евгений,
Спасибо за комментарий.
Я противник бездумного применения Web-сервисов как панацеи (особенно, для внутрикорпоративной инфраструктуры), но не Web-служб как одного из способов интеграции.
1. Часто кроме "прикладного канала" передачи данных (SOAP) необходима инфраструктура распределенных транзакций, асинхронного обмена, безопасности и т.п. Можно представить себе биллинговую систему мобильного оператора или АБС, использующие в качестве основного протокола SOAP? Здесь, наверное, WS не очень применимы.
2. "Навешивать" бизнес-логику на уровне классов самой Web-службы (я имею в виду те классы, например, сидящие в Axis или ASP, которые крутятся на узле Web-сервера, публикующего wsdl) - катастрофа.
Если Web-служба играет роль только точки входа для интеграции - это нормально. Иметь SOAP-доступ в дополнение к IIOP - замечательно - если и wsdl достаточно корректен (в нем нет неинтероперабельных схем) - замечательно. Подменять же прикладную инфраструктуру предприятия SOAP'ом - imho, беда.
Наверное, можно провести аналогию с Apache или IIS. Приложения могут крутиться непосредственно на них. С другой стороны, Apapche и IIS могут являться точкой входа в систему, и за ними может быть серьезный back-end, инфраструктура безопасности (в том числе с точки зрения DMZ и т.п.), серверы бизнес-логики, серверы БД и т.п. Если применение Web-служб рассматривать по второму сценарию - т.е. только как entry point - это будет более адекватно.
С уважением,
Сергей
По-моему, достаточно вменяемая статья InfoWorld "Web services chugging along" http://www.infoworld.com/article/05/07/22/HNwsprogress_1.html .
Она заканчивается цитатой аналитика ZapThink, смысл которой состоит в том, что проблема WebServices состоит в понимании того для чего они и как их использовать. Я бы добавил ещё один важный вопрос - где именно их стоит использовать, а где нет.
-Сергей
Добрый день, Евгений!
Хотелось бы тоже отметить, что говоря о взаимодействии филиальной сети с головной организацией, даже при условии плохих каналов связи, web-services не являются единственным возможным решением. На самом деле все сильно зависит от организации бизнес-процессов (БП) и того как взамодействуют филиалы с головной конторой и архитектуры корпративной системы, поддерживающей эти БП . Например, в одном случае филиалы отправляют только итоговые отчеты о своей работе, в другом случае ведется общая НСИ (справочники), и т.д. В каждом случае могут быть использованы разные способы взаимодействия в рамках информационной систмы. Но скажем если стоит задача репликации баз данных (НСИ) -- то скорее всего web-services не лучшее решение. Web-services хорошы в рамках концепции SOA, в частности когда БП проходит "сквозь" различные подразделения организации (в т.ч. территориально-распределенные) или вообще самостоятельные организации, которые на условиях аутсорсинга, выполняют некие сервисы в неком большом БП организации. Т.е. должны присутствовать явные бизнес-компоненты, с четкими бизнес-сервисами, которые можно "обложить" web-services.
При "более тесном" взимодействии систем в филиалах и головной конторе, можно подумать и об использовании концепции ESB (сервис <> web-service) и использования систем очередедей сообщений, которые могут использовать в т.ч. и почтовые протоколы.
Сорри, это был мой комментарий ..
Юрий,
Ну я же не утверждал, что в случае плохих каналов связи вебсервисы единственно верный путь. Я же не в Микрософте работаю :). Я говорил, о том, что вебсервисы МОГУТ применятся в этом случае. И как сказал Сергей, в случае если за сервисом стоит правильный бэкэнд, то это неплохое решение.
Евгений.
Кстати, есть великолепный ресурс по компонентной разработке и SOA/ESB - CBDI Forum "Independent insight for Service Oriented Practice" (когда то он назывался Component-Based Development and Integration Forum):
http://www.cbdiforum.com
Кстати, в дополнение к комментарию Юрия:
Если посмотреть на новейшие стандарты описания бизнес-процессов, например, BPMN (www.bmpi.org) - он транслируется в BPEL (Business Process Execution language), который в определенной степени и выстроен, чтобы хорошо ложиться в концепцию и технологии SOA/ESB.
Отправить комментарий
Подпишитесь на каналы Комментарии к сообщению [Atom]
<< Главная страница