Об ИТ из Канады

Блог Михаила Флёнова - программист, блогер, автор нескольких скандальных книг какими-то глазами...
SOA - сервис ориентированное программирование - Статья : блог Михаила Флёнова

SOA - сервис ориентированное программирование

Некоторые считают, что Россия в области ИТ движется очень быстро, и мы скоро всех догоним и перегоним. Так ли это? Я думаю, что нет. Например, в корпоративных приложениях мы застряли в архитектуре клиент-сервер. Лично я очень мало видел многоуровневых решений российской разработки, а сервис ориентированная архитектура вообще диковина. Многие просто до конца не понимают, что это такое, где использовать, и какие мы получаем преимущества.

Некоторые считают, что сервисы используются только в WEB приложениях и только на Java или .NET, а в других приложениях абсолютно не нужны. Это серьезное заблуждение. Да, в языке программирования Java уже есть множество классов, которые упрощают разработку, но это не значит, что эта технология не может быть написана на другом языке. Подойдет абсолютно любой язык программирования, умеющий работать с TCP/IP протоколом.

Да, протокол общения с сервисом использует в качестве базы HTTP запросы, но это не значит, что использование сервисов ограничено только WEB браузером. В браузере уже реализованы все необходимые функции для работы с HTTP и XML, но кто мешает реализовать то же самое в вашем корпоративном приложении и получить преимущества SOA? Хотя, последние тенденции показывают, что ИТ сдвигается в сторону WEB, а тут преимущества SOA проявляются в полной степени.

Что такое сервисы

Что такое архитектура SOA (service oriented architecture, сервис ориентированная архитектура)? Уже из названия понятно, что основа – это сервисы. Сервис можно воспринимать как программу, которая умеет выполнять какое-то действие по внешнему запросу и при необходимости может возвращать результат.

В некоторых источниках можно встретить, что сервис – это что-то более крупное, чем CORBA, а в других говорят, что сервис маленький, но их множество может объединяться в стек. Из-за многообразий формулировок и начинается путаница и появляется неопределенность. Я придерживаюсь мнения, что сервис может быть любого размера и не имеет значения - больше он или меньше CORBA объекта. Главное, чтобы это был законченный объект, который будет выполнять необходимые действия и прятать от потребителя услуг внутреннюю работу. Я не даром употребил слово «объект», потому что аналогия с этой технологией действительно прослеживается.

Сервис можно воспринимать как функцию, которая может находиться удаленном компьютере (а может и локально), и при этом выполняет какие-то действия, а входные параметры и результат передается по сети. Внешнее приложение (корпоративная программа, WEB браузер или даже небольшая программа на карманном компьютере) используют этот сервис для получения или управления данными.

Чтобы внешние программы могли взаимодействовать с сервисом, существует стандартный протокол SOAP (Simple Object Access Protocol, простой протокол доступа к объектам), который основан на HTTP запросах. В основе протокол отправляет серверу запросы (например, POST) по HTTP, внутри которых находиться SOAP запрос в виде XML схемы. Результат работы сервис возвращает также по HTTP протоколу, в который завернут SOAP ответ в виде XML схемы.

Для доступа к SOA можно использовать не только SOAP, но и уже упомянутую CORBA или собственную разработку. Идеология от этого не измениться. Но на наш взгляд, SOAP является лучшим решением, поэтому в данной статье будем рассматривать SOA и SOAP в связке.

Пример для SOA

Чтобы увидеть всю мощь рассматриваемой архитектуры, давайте сразу рассмотрим небольшой пример. Наибольшую эффективность и наглядность можно обеспечить именно в WEB, наверно поэтому здесь сервисы получили наибольшее распространение и почти везде выражения SOA и WEB сервисы объединены в одно целое.

Допустим, что вы разрабатываете WEB магазин продажи книг. Можно просто составить каталог книг и никак не отслеживать наличие товара на складах и возможность поставок, но такое положение дел не устроит посетителей вашего магазина. Будет очень некрасиво, если посетитель закажет и оплатит книгу, которая не издавалась уже 5 лет. Вы попадете в нехорошее положение из-за того, что не сможете выполнить заказ, а посетитель уйдет в следующий раз в другой интернет-магазин.

Чтобы отслеживать возможность поставки товара, вы можете сделать запрос к WEB-сервису оптовой компании, где закупаются книги. Он может вернуть вам количество книг на оптовом складе, дату ближайшей поставки и срок поставки, если книги нет на складе. Используя эту информацию, вы можете сообщить посетителю более-менее реальные данные, когда он сможет получить свою книгу, если ее нет в магазине.

С другой стороны, WEB сервис оптового магазина, для обработки запроса клиента проверяет остатки собственной базы данных товара и запрашивает WEB сервис издателя книги, чтобы тот сообщил:

  • - а есть ли книга у издательства;
  • - если нет, когда будет переиздание;
  • - когда издательство может осуществить поставку оптовику, и с какого склада (чаще всего не столичные издательства имеют локальный склад плюс по одному в Москве и в Санкт-Петербурге);

Обращение интернет магазина к сервису оптовой компании и далее к сервису издательства, называется b2b (business to business). Такое общение, позволяет магазину предоставлять посетителю максимально полную и приближенную к действительности информацию, а магазину и оптовой компании оптимизировать хранение товара на складе. Например, если WEB-сервис издательства сообщает, что какая-то книга может быть поставлена в течение 10 дней, а по статистическим данным оптовая компания видит, что на складе товара осталось максимум на 9 дней, то отделу снабжение может быть предложено сформировать заявку на допоставку товара. Это избавит вас от перебоя в поставках при минимальных затратах на хранение.

А если сервисы будут отображать не только состояние склада, но и изменения цены? Ведь цена книг может меняться (инфляцию никто еще не отменял) и если магазин не отреагирует, то может начать торговать в убыток. Если цена будет контролироваться через WEB сервисы, при повышении цены издательства или стоимости поставки, интернет магазин благодаря WEB сервисам может мгновенно отреагировать. Можно пойти дальше – магазин может автоматически устанавливать свою розничную цену как:

цена оптовой компании + цена поставки + N% прибыли

и в этом случае магазин никогда не будет торговать в убыток.

Конкурентные преимущества

На данный момент для организаций WEB – лучший способ предоставить своим клиентам подобные рассмотренному выше сервисы в реальном времени. Рассылка дисков почтой и баз данных по E-mail устарела, а программная обработка содержимого WEB страниц, где компании показывают состояние своих товаров - возможна, но очень сложная в реализации и чувствительна к любым изменениям в структуре HTML документов.

Как много в России компаний предоставляет своим клиентам что-то подобное? Оставим вопрос открытым. Большинство интернет магазинов отображают возможные сроки поставки, добавляя к текущей дате заранее определенное число. Чтобы убедиться в этом, достаточно сравнить срок поставки на несколько отсутствующих товаров и 90% случаев, они будут одинаковы.

В связи с этим, появление у какой-либо компании полноценных сервисов, используемых не только внутри компании, но и предоставляемых для нужд клиентов и партнеров, будет является серьезным конкурентным преимуществом, позволяющим оптимизировать состояние складов и затрат на хранение товара.

Независимость от языка

Технология SOA предоставляет нам великолепную (возможно даже лучшую) независимость от всего, а самое главное - от языка программирования и от ОС. Языки программирования развиваются очень динамично. Еще десять лет назад балом правил С++ и его позиции казались непоколебимы, но два года назад пальму первенства отобрал Java. Да, в нашей стране это не так заметно, но я всегда говорю – посмотрите предложение о работе в США и Канаде и вы увидите, что мы серьезно отстали. Наибольший спрос на Java и SOA.

Еще пару лет назад всем казалось, что Java отобрал пальму первенства всерьез и надолго, но новинка от MS в виде технологии .NET пусть и медленно, но набирает обороты и каждый год откусывает небольшой кусок пирога от J2EE.

В этот момент программисты начинают задумываться – что победит, и какой язык использовать? Все мы можем только догадываться, и кто-то может угадать, но сказать точно мы не беремся. Используя сервисы, вам абсолютно все равно, какой язык победит. Один сервис может быть написан на Java, другой на C#, а третий на С++ и все они будут прекрасно дружить и совместно работать на благо компании.

Мне уже несколько раз приходилось участвовать в авантюрах, когда на предприятии приходиться переписывать тонну кода только из-за того, что старая программа написана на языке, который больше не развивается и не может обеспечить потребности компании. Например, сейчас я занимаюсь переписыванием кода с Power Builder на Delphi. Это грозит кардинальными изменениями, потому что переписывать приходиться сразу все. Если бы корпоративная программа использовала бы SOA архитектуру, то переход можно было бы делать постепенно.

А можно поступить еще лучше – перенести на другой язык только те сервисы, которые действительно нуждаются в этом и где старый язык не может реализовать необходимые потребности. Те сервисы, которые и так работают хорошо, можно оставить без изменений. Главное – отказаться от монолитных решений, которые неудобны и неповоротливы.

Протокол SOAP, который используется для обмена информацией, базируется на двух открытых стандартах XML и HTTP. HTTP и XML независимы от платформы, а значит сервисы могут работать на любых платформах, лишь бы там была поддержка TCP/IP. А так как этот протокол реализован практически во всех современных устройствах и ОС, то границ для рассматриваемой нами архитектуры практически нет. Ваше Windows приложение может без проблем обращаться к сервису, работающему на Linux и наоборот, а с помощью браузера к сервису можно обратиться даже с мобильного телефона.

Большинство новых технологий обязательно старается учитывать то, что код должен использоваться максимально эффективно. Если возникает необходимость в новом месте решить уже реализованную ранее задачу, то код не должен переписываться заново. Сервисы решают эту проблему великолепно, и даже там, где программы реализованы различными производителями.

Архитектура SOA позволяет вам создать один сервис, который будет являться поставщиком данных не только для WEB приложения, но и для различных модулей корпоративного программного обеспечения. Очень часто, различные модули должны работать с одними и теми же данными, просто отображать могут их по-разному. Например, остатки по складу могут быть нужны отделу снабжения, кладовщику, аналитику, маркетологу и т.д. Реализовывать в каждом из модулей функции отображения нужных данных слишком невыгодно и расточительно. Достаточно написать один сервис, который будет возвращать XML схему с остатками запрошенного товара, а клиентской программе остается только отобразить содержимое схемы в удобной пользователю форме. Благо XML с его расширениями XSL, DTD предоставляет широкие возможности по форматированию.

Допустим, что вы стремитесь идти в ногу со временем и используете все современные программные пакеты для управления затратами, клиентами поставщиками и т.д. На рынке сейчас можно увидеть множество различных систем ERP, CRM и др. продуктов от разных производителей. Но как их заставить работать вместе? Необходим какой-то механизм, который позволит модулям и программным пакетам обмениваться информацией, чтобы не приходилось информацию об одном и том же поставщике вводить в две разные базы данных.

В качестве стандарта при обмене информацией становиться XML, потому что он простой, удобный, мощный и независим от платформы. А так как SOA возвращает данные в виде XML, то вполне логично было бы сделать так, чтобы различные модули и программы могли сами запрашивать нужную информацию у сервисов.

Возможно, что в нашей стране предприятия не используют сервисы только из-за специфики бизнеса "по-русски", а может просто потому, что руководству никто не показал преимущества, которые предоставляет SOA. Если вы до сих пор не увидели все достоинства этой архитектуры, тогда мы идем к вам.

За дополнительной информацией я бы рекомендовал обратиться к сайту www.ibm.ru, где собрано множество статей по рассмотренной архитектуре. Особенно, стоит обратить внимание на следующие ссылки:

  • http://www.ibm.com/developerworks/ru/webservices/
  • http://www.ibm.com/developerworks/webservices/newto/websvc.html
  • http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
  • http://www.ibm.com/developerworks/ru/library/ws-whyesb/

Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание

О блоге

Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю

Внимание!

А ты уже читал мою последнюю книгу о больших сайтах и приложениях? Узнай, что это такое здесь

Обратная связь

Без проблем вступаю в неразборчивые разговоры по e-mail. Стараюсь отвечать на письма всех читателей вне зависимости от страны проживания, вероисповидания на русском или английском языке.

Пишите мне