Примерно таким заголовком анонсировали интернет издания мартовское исследование Forrester SOA Adoption 2010: Still Important, Still Strong Оказывается 71% опрошенных компаний уже используют SOA или собираются это сделать в течении 2011 года. То же самое говорит почти половина средних и малых компаний. Организации довольны результатами, получаемыми от сервис-ориентированной архитектуры и не собираются от неё отказываться. Безусловно, определенная часть опрошенных просто не понимает о чем говорит, но единодушие в ответах респондентов показывает, что «пациент скорее жив, чем мертв».
Не менее интересное исследование появилось в конце апреля The Forrester Wave™: Enterprise Service Bus, Q2 2011. Рынок ESB продолжает неплохо расти. Кроме вполне привычных для ESB задач, таких как маршрутизация сообщений и преобразование данных 35% компаний используют ESB непосредственно для разработки сервисов, а 14% для прикладной разработки на BPEL (28% используют BPEL для оркестровки). Кстати, с языком исполнения бизнес-процессов WS_BPEL ситуация тоже интересная. 2-3 года назад только ленивый не говорил о том, что SOA и BPM – браться на век. Затем из лагеря BPM стали отчетливо слышаться голоса, что BPEL not for people. В ответ могу попрекнуть разработчиков BPMS в монолитности архитектуры их флагманских продуктов. Далеко не все BPMSы, те который для людей, а не так называемый IC-BPMS, отвечают принципам сервис-ориентированной архитектуры, потому как сервисов они не предоставляют. В итоге, у больших вендоров в линейке присутствуют как минимум по два продукта: один для быстрого рисования процессов и пользовательских интерфейсов к ним, а другой для интеграции в корпоративную информационную систему, т.е. интероперабельный.
Но вернемся к SOA. Такое впечатление, что поставщики и заказчики ИТ решений объявили временное перемирие. Поставщики по прежнему пытаются продать монолитные приложения(не далее чем вчера к нам притащили очередное творение для кота Тома, с красивыми пользовательскими интерфейсами и полным отсутствием интерфейсов программных). Заказчики вежливо делают вид, что новыми технологиями интересуются, но продолжают резать ИТ-бюджеты. Тем временем ИТ-отделы компаний продолжают создавать сервисы «на коленке», как это и делалось последние несколько лет. Мне кажется ситуация сдвинется с мертвой точки только при условии появления стандартов на сервисы в предметных областях, таких как финансы, управление цепочками поставок, складской учет, управление персоналом, управление ИТ и т.д. Один из немногочисленных примеров таких стандартов Content Management Interoperability Services принятый в мае прошлого года. Стандарт пусть и неоднозначный, зато все ECM вендоры реализовали его моментально. Теперь вы можете работать из своего приложения с документами, не сильно задумываясь о том, на чем сделано ваше корпоративное хранилище контента на IBM, EMC, или опенсорсном Alfresco. А представьте, насколько бы упростилась жизнь любой организации при наличии стандартизированного интерфейса к системе управления персоналом. Любое приложение смогло бы вытащить информацию о статусе сотрудника: не уехал ли он случайно в отпуск или командировку или кто его непосредственный руководитель, в каком филиале человек трудиться, в каких проектах участвует и т.д. Или другой пример – корпоративные справочники: поставщики, заказчики, договора, филиалы, адреса, услуги(продукты), бизнес-процессы в конечном счете. Все это есть в корпоративной информационной системе и всего этого нет. Потому что извлечь КИС такую информацию могут не все и не всю и только по заявке на ИТ-услугу и только посредством специализированного программного обеспечения, которое устанавливается на виндоуз, но не работает, например, на iPad. В ИТ ситуация не лучше. Я всегда считал, что CMDB – это база данных, т.е. программа реализующая стандарт SQL 92. Как бы не так! «Промышленные» CMDB лишены программных интерфейсов, позволяющих создавать/изменять/читать конфигурационные единицы(CI). Тонкий цинизм в отношении ИТ-отделов компаний-заказчиков, не правда ли?! И это при том, что евангелисты ITIL всегда не прочь были порассуждать о сервис-ориентированой архитектуре.
Возможно, я в чем-то сгущаю краски. Однако многочисленные WS-* стандарты не принесли гармонию в корпоративные ИТ-ландшафты. Если что-то и помогает выпрямлять архитектуру корпоративных информационных систем, так это конкретные сервисы.
Максим, у меня снова глупый вопрос )
А что такое Сервис?
И можно мне сказать что такое SOA? Желательно на конкретных примерах.
У меня сейчас в голове под этими словами скрываются примерно такие образы:
1. Сервис: модное слово обозначающее Услугу или Службу. В разных контекстах под словом Сервис понимают разные вещи. «Студенты» ITSM думают что Сервис это Услуга. Веб-программисты думают что Сервис это их Веб-сайт или функция Веб-сайта которая скажем музыку играет. В контексте SOA под сервисом я так понял понимается некое веб-приложение, в которое можно передать параметры, а оно вернет результат в формате XML или каком то другом, из какой то БД.
2. Если п.1 в части SOA верен, тогда система SOA это по сути приложение которое позволяет создавать эти «сервисы», залазить в разные БД через разные интерфейсы и возвращать какие то результаты запросов.
Например вышеупомянутый запрос о не доступности сотрудника. Или у студии Арт. Лебедева есть «сервис» генерации правильной типографики для сайтов. Сайт отправляет туда словосочетание с тире и кавычками. Возвращается правильные кавычки и тире. В соответствии с хитрыми правилами рус.яза )
Соответственно SOA это когда приложения между собой общаются на языке «сервисов», вместо старых спосообов синхронизаций таблиц и т д
Я правильно понял? 🙂
Я не стану посылать сюда: Reference Model for Service Oriented Architecture как это сделало бы большинство уважаемых аналитиков 🙂
Свое понимание SOA и сервисов я описывал в Программный интерфейс к бизнесу и Одна из ошибок при переходе от инхауса к аутсорсингу