Source: http://www.itblogs.ru/blogs/borkus/archive/2006/11/30/soa.aspx
Влад Боркус
Перечитав все комментарии, которые были сделаны в публикациях про SOA на ИТ Блогз, я обнаружил, что во всей нашей дискуссии был фундаментальный изъян. Начиная говорить про SOA, мы почти немедленно переходили на обсуждение веб-сервисов. В целом это не удивительно -- мы окружены вендорской пропагандой, из которой другой вывод сделать сложно. И все же веб-сервисы и SOA -- это не одно и то же.
И не только потому, что можно построить кучу веб-сервисов, и не внедрить у себя в итоге SOA. Этот тезис, безусловно, совершенно справедлив, но лишь чуть приближает к истине.
И не потому, что SOA -- не равно ESB, о чем тоже много говорилось.
А потому, что SOA -- это вообще не про веб-сервисы. Т.е. как бы совсем не про то.
Если говорить формально, то SOA -- это некоторая концепция реинжиниринга и развития корпоративного программного ландшафта. Упоминания этого термина можно встретить где-то в 1996 году у Гартнера. Тогда эти идеи в практической плоскости соотносились с компонентными технологиями.
С тех пор этот набор идей оброс неким опытом и набором где-то использованных приемов, которые в совокупности носят красивое название SOA Governance.
Появились XML и веб-сервисы, и оказалось, что эти идеи неплохо этой технологией дополняются.
Компоненты SOA
В основе SOA действительно лежит понятие сервиса, хотя не только его. Другими компонентами SOA являются фронт-энды приложений, репозиторий описаний сервисов, сервисная шина.
Ключевым для SOA являются наличие сервисов, ориентированных на деловые задачи. В SOA могут быть и масса других сервисов (трансформации, авторизации, и т.п.), но они вторичны.
Главное, что основные сервисы предоставляют каждый какой-то законченный деловой функционал. Крупный блок этого функционала. Скажем, сервис может предоставлять функции по работе с контрактом или с информацией о сотруднике.
В CORBA, EJB приложение строится из множества маленьких кирпичей. В SOA -- из малого количества больших.
В идеале бизнес-сервис должен предоставлять законченную функциональность по работе с сущностью, которой он взялся управлять. Например, в организации у нас есть только один
сервис по управлению контрактами. Иначе говоря, важное отличие сервиса от объекта CORBA -- это его изолированность от других сервисов.
Хотя в реальной жизни избежать даже корреляции сервисов не всегда удается, в идеале он должен быть совсем изолированным, и отвечать за все ресурсы, находящиеся под его управлением. Т.е., скажем, если у нас есть сервис, отвечающий за заказы, то изменить заказ в рамках SOA позволительно только одним способом -- через этот сервис. (Вспомним, что SOA -- это про организацию работ).
Чтобы добиться такой изолированности, борцы за SOA-веру предлагают проводить декомпозицию приложений. Или, когда это не возможно, строить так называемые «фасады» -- независимые сервисы, обращающиеся к одному или нескольким нижележащим системам. И работать потом через них.
Ключевым качеством сервиса является его описание. В описании сказано, что за интерфейс (функции) сервис имеет, приведен контракт (на каких условиях возможен доступ), и прочее -- кто его состряпал, какая версия, кто может менять сервис, когда этот сервис доступен, какая у него нагрузочная способность. Это описание совсем не обязательно должно быть на WSDL, например оно может быть на IDL или даже в MS Word. Главное, чтобы оно было.
Естественно, если описание -- в машино-распознаваемом формате, то использовать сервис потом намного удобнее.
Сами сервисы могут быть реализованы в рамках родной инсталляции SOA на разных технологических платформах -- WS, Java, .Net, CORBA. Более того, идея SOA как раз и состоит в том, чтобы обезопасить ИТ-инфраструктуру от смены поколений информационных технологий и стыковать плохо совместимые унаследованные технологии. Скажем, идеологи SOA открыто говорят, что SOAP когда-то отомрет, а ИТ надо будет и дальше жить. Требуется только, чтобы сервисы отвечали формальным требованиям SOA.
Работают с сервисами так называемые фронт-энды -- по большей части клиентские приложения разного сорта. Но могут работать и так называемые процессные сервисы, которые инкапсулируют оркестровку делового процесса. Можно также представить в этом контексте и другие сервисы - деловые правила.
Выше я также опустил так называемые технологические сервисы, к которым, например, относятся адаптеры. И сервисы, расширяющие функциональность нижележащей системы.
***
Все описания сервисов (описание интерфейса и контракт) обязаны храниться в репозитории.
Если это формальные описания, то система будет более конфигурируемая. Но, стоит заметить, что полноценные репозитории более сложны, а важны больше для B2B-среды, а не контролируемой корпоративной среды.
Но репозиторием может быть, и склад word-документов в файловой системе (это, конечно, экстремальный случай). В конце концов главный элемент в рамках SOA -- это корпоративный разработчик.
Здесь важны два момента. Описание всех интерфейсов должно быть унифицировано, и репозиторий должен быть центральным. Разработчик или динамически конфигурируемый клиент обращаются только к репозиторию, чтобы почерпнуть описания. Иначе -- SOA распадется.
Последний компонент SOA -- это шина сервисов. Это -- не обязательный компонент SOA. И уж, конечно, совсем не обязательно -- это ESB.
Главной задачей шины является технологическа стыковка систем на ее концах. Т.е. если с одной стороны у нас находится SOAP, а с другой -- CORBA, то шина должна обеспечить преобразование формата вызова от одной системы к другой. Например, коммутацию XML-полей на методы CORBA. Мы это можем сделать, так как у нас есть «нейтральное» описание сервиса.
В принципе, в рамках SOA может существовать несколько параллельных шин, скажем она -- асинхронная, а другая синхронная. Или идентичные шины в географички разных филиалах.
Проблемы
Как легко понять, у SOA много проблем. Транзакционной целостности очень сложно добиться, собрав систему из кубиков -- компенсационные шаги очень запутаны. Есть несколько теорий, как это надо делать, но все они имеют большие издержки. Хотя ясно, что задача не решается в общем случае в принципе.
Есть проблемы с тем, как строить безопасность в такой системе -- на каком уровне должна проводиться аутентификация, авторизация. Особенно все сложно в условиях, когда нельзя сделать общий identity сервис. Опять, есть у людей идеи, но выбор -- по обстоятельствам.
Есть проблемы, о которых упоминал Анатолий, -- как быть с бизнес-объектами. Хотя самый очевидный путь -- это стандартизовать их на уроне шины. Также бизнес-объекты по сути сами являются готовыми сервисами.
Есть в конце концов проблема организационная (все расползается) и с архитекторами (чтобы создать такую архитектуру нужны архитекторы экстра-класса, а их в мире на каждую фирму не наберешь).
Что касается успехов. Есть проекты, причем достаточно большие. Хотя их беглый анализ местами не внушает оптимизма -- в одних исходная задача была относительно простая, в других -- решение получилось кривое, и его переделывают.
****
PS. Написать этот текст меня подстрекал Анатолий, так что вся ответственность за последствия лежит на нем. Особенно если там отдельные вендор будут кидать в меня камнями :))
Но если статью на форуме сочтут приличной, то я ее попробую доработать и пристроить в какой-нибудь ИТ-журнал.
Published 30 ноября 2006 г. 5:21 by Vlad Borkus
Toliksaid:Ну, как минимум, не зря подстрекал - поскольку в общем-то все эти вещи вроде и понятные, но в кучу их собрать и систематизировать весьма полезно. Как минимум для появления общей терминологиии, что в 80% достаточно чтобы привести к консенсусу любую дискуссию ;-)
Щас Михаил скажет - что это можно маленько доработать - и в WiKi>
ноября 30, 2006 6:53
Elena Makurochkina said:
Спасибо за такой подробный пост!
Есть у Вас очень важный момент: "Описание всех интерфейсов должно быть унифицировано, и репозиторий должен быть центральным".
В общем этот абзац рушит понимание SOA именно как архитектуры. Фактически это говорит о том что архитектурный подход SOA ничем не отличается от стандартного – система должны быть ЕДИНОЙ. Т.е. это не подход к архитектуре, а подход к реализации.
За последнее время начитавшись и научавствовавшись в обсуждении SOA здесь, на ITBlogs, и, параллельно, влезши в тонкость Agile методологий разработки, стала я с большим подозрением смотреть на все гибкое, настраиваемое и универсальное: http://sundest.blogspot.com/2006/11/blog-post_30.html
ноября 30, 2006 7:47
Mikhail Elashkin said:
Коллеги, покажу как работать в Вики. Только с понедельника.
На этой неделе я заканчиваю один проект и перегружен ((
ноября 30, 2006 8:40
Tolik said:
Тут то и ловушка в центральном репозитории - потому что или я должен планировать его сам (и писать сам сервисы?) или, чтобы я мог в нем объединить в нем продукты разных вендоров - кто-то их должен стандартизировать (кто?)
ноября 30, 2006 8:47
Vlad Borkus said:
>Тут то и ловушка в центральном репозитории - потому что или я должен планировать его сам
Конечно -- планировать сам.
Вендор может и поможет немного, если создаст API в этой концепци. А может и наоборот, все запутает.
ноября 30, 2006 13:27
Vlad Borkus said:
Sundest,
>Фактически это говорит о том что архитектурный подход SOA ничем не отличается от стандартного – система должны быть ЕДИНОЙ.
Создание единой системы из кусочков -- цель любой интеграции.
Вы в целом описали идею-фикс у Гартнера. Назвыется общекорпоративный API.
Но в отношении SOA есть тонкость. Связи между кусками системы намного слабее, чем в приложенни класса R/3.
Более того, поскольку куски демаркированы API вот именно таким образом, то вы можете делать их на разных технологиях.
>В общем этот абзац рушит понимание SOA именно как архитектуры.
Архитектура -- еще менее четкий термин, чем SOA. Дискуссия, что же такое архиектура приложения идет лет 40.
ноября 30, 2006 13:35
Mikola said:
Очень толковый пост !
Спасибо
>Есть проекты, причем достаточно большие
"Имя сестра, имя !"
Особенно в России :-)
И еще, хотелось бы узнать наименее кривой, по Вашему мнению, проект.
Так сказать, лучший из худших.
ноября 30, 2006 17:30
Vlad Borkus said:
2 Mikola.
В России негусто. В сколько-нибудь полноценном виде не попадалось. Т.е интеграционные проекты на web-сервисах есть, в частности, скажем, на NetWeaver (см. ссылки в публикации Михаила Елашкина по последней конференции SAP), но вот насколько они исполнены в духе философии SOA -- не ясно. Мне показалось, что нет. Про нашумевший путь к SOA компании Аэрофтот могу тоже сказать, что действительно кое-что они в этом направлении два года делают, но судя по их презентациям, пока все очень и очень локально.
Примеры на Западе, по которым есть более-менее внятные описания:
- Deutsche Post AG (правда, исходно была низкая гетерогенность);
- Winterthur (швецкая страховая компания, но добиться полной изолированности сервисов, они, как я понял не смогли);
- Credit Suisse (большая SOA, в основном на базе CORBA, вроде бы довольно удачно развивают с середины 90-х)
- Halifax Bank Of Scotland (позиционирутеся как SOA, но по впечатлениям от описания --скорее интеграционный проект на базе web-сервисов. Делали в спешке. Не добились изоляции сервисов. Хотя исходно и не ставили такой задачи, отложив ее на второй этап. Возникли проблемы с переконфигурированием).
Упомнается еще часто проект в British American Tobacoo (использовали NetWeaver, SOA Software. Позиционируется как SOA). Но ощущения, что там есть внятная стратегия, у меня нет. Возможно, опять, внедрили пару продуктов. Описания очень туманные.
IBM на последнем своем бизнес-форуме давала примеры своих проектов, но подано было как чистая реклама. С ними надо разбираться. Что делали и как. Я пока не копался в их case'ах.
ноября 30, 2006 18:24
Tolik said:
Интересно, у нас значимая часть внутренней информационной системы (обмен данными с филиалами) - хоть сейчас в учебник по SOA (Web, XML, очереди сообщений, шина данных, только веб-сервисов нету, не понадобились они), но никакого SOA мы не делали, просто напрашивавшаяся логика развития. НО революции я там упорно не вижу, хотя решения, на мой взгляд и весьма красивые. ТОлько при чем тут SOA, обычные логичные решения.
ноября 30, 2006 20:12
Vlad Borkus said:
>ТОлько при чем тут SOA, обычные логичные >решения.
Логичные решения БОльшая редкость, потому теперь они выделены в специальный класс SOA. :))))) И являются объектом почитания :))))
Если серьезно, то значит ты просто на позиции CIO в этой компании достаточно долго, чтобы эту системную логику поддерживать.
В США не так. Средний срок жизни CIO на посту -- 11 месяцев, кажется. Я уж не говорю об увлечениях ИТ-модой. Плюс там компании существуют не 10 лет, а 40. Ну результат -- соответсвенно.
Внедрение SOA означает наведение этой самой логики, с выделением независимых сервисов.
Поэтому я и говорю, что к этому нужно относиться как к набору неких здравых идей.
ноября 30, 2006 21:51
Mikhail Elashkin said:
IBM называет Аэрофлот как case по SOA в России.
я собираюсь там посидеть и посмотреть что они сделали. но уже в 2007 году.
ноября 30, 2006 23:37
Vlad Borkus said:
>IBM называет Аэрофлот как case по SOA в России.
Миша, слабенько там вроде бы. Я же был на их презентации на бизнес-форуме. Два веб-сервиса, планы на 10 лет вперед. IBM я понимают понятно -- такая закупка софта. MQ, ProcessServer, MessageBroker и еще много всего. К тому же у них Lotus там. Вообще IBM shop.
Хотя, возможно, просто презентовать не могли по нормальному.
Но если планируется поход с реальным долгим обсуждением того, что они дейстсвительно сделали, то бери с собой.
декабря 1, 2006 0:07
Tolik said:
>Логичные решения БОльшая редкость, потому
>теперь они выделены в специальный класс
>SOA. :)))))
Может быть это вот и есть описание SOA ? ;-)
Несколько общо, но за эпиграф - сойдет на 100%
Главное, чтобы не за эпитафию
декабря 1, 2006 6:40
feygin said:
> Тут то и ловушка в центральном репозитории - потому что или я должен планировать его сам (и писать сам сервисы?) или, чтобы я мог в нем объединить в нем продукты разных вендоров - кто-то их должен стандартизировать (кто?)
О том, что информационная модель и API этого реестра должны быть стандартизованы вендорам было понятно довольно давно. Стандарт этот называется UDDI (см. http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.h…) и ваш покорный слуга к созданию его третьей версии имеет самое непосредственное отношение. Буду рад ответить на вопросы.
декабря 1, 2006 9:55
Tolik said:
UDDI - это хорошо
Но это немного не то. UDDI стандартизирует как найти сервер, как узнать чего у него есть ... Т.е. в общем-то это всё на уровне RPC
А для взаимодействия бизнес-модулей - нужны стандарты на бизнес-объекты, иначе сало будет радости другим бизнес-модулям от того, что в системе завелся HR-сервис. Чтобы его смогли использовать - должен быть стандартизован формат, скажем, объекта "сотрудник", способы запроса этих сотрудников из HR модуля, способы получения и фильтрации коллекций таких объектов ...
Создать такое можно - и тогда CRM От MS поймет и задействует HR от Oracle и всё будет здорово, но беда в том, что такой стандарт создаст почти непреодолимый барьер для входа в рынок революционных, не описаных в стандарте бизнес-модулей. Потому что на момент их выпуска их никто не узнает, а стандартизировать их не будут потому, что они не распространены
декабря 1, 2006 10:10
feygin said:
> Но это немного не то. UDDI стандартизирует как найти сервер, как узнать чего у него есть ...
Помимо этого на базе UDDI строятся реестры метаданных, хранящихся где-то снаружи. Как следствие, UDDI является механизмом их многократного использования, целью которого является заветная унификация интерфейсов.
Изменение этих интерфейсов в дальнейшем -- дело процессов, которые мы здесь называем "жизнью по SOA" (или более традиционно SOA governance). Собственно, основное назначение UDDI и состоит в design-time согласовании SOA, т.е. это центральный элемент этого самого governance (роль UDDI в runtime, на мой взгляд, несколько преувеличена, хотя в ряде случаев бывает весьма кстати). Замечу, что если интероперабельности между различными инфраструктурными элементами, поддерживающими governance, не требуется (или элементов таковых не имеется), то, как правильно отметил выше Влад, в качестве такого реестра/репозитория сойдет и файловая система или, скажем, Wiki-сайт какой-нибудь.
> Т.е. в общем-то это всё на уровне RPC
Не понял, что на уровне RPC? Как раз имевшие место неделю назад обсуждения на тему Web-сервисного RPC к SOA прямого отношения и не имеют. Я, к сожалению, не в состоянии достаточно плотно отслеживать происходящее здесь, поэтому не успел вовремя включиться в ту дискуссию.
декабря 1, 2006 10:31
Vlad Borkus said:
>А для взаимодействия бизнес-модулей - нужны стандарты на бизнес-объекты, иначе сало будет радости другим бизнес-модулям от того, что в системе завелся HR-сервис
Толя, надо вернуться к главной идее всего этого. Даниил, наверное, добавит, если что упущу.
А именно главное -- как мы выделяем сервисы. По сути-то главная идея SOA чем-то похожа на нормализацию базы данных, но только перенесена она в область интерфейсов и данных. Оговорюсь сразу, что аналогия не точная (см исходный текст).
Выделим некоторую смысловую и законченную область (скажем , «клиент») и демаркируем ее как сервис. Иначе говоря у нас во всей архитектуре формат бизнес-объекта только один.
Если ты "приложение" и хочешь с ним работать -- вот сервисное соглашение в реестре, пытайся ему удовлетворить. Не можешь -- вот тебе какие-то костыли в виде шины и сервисов трансформации. Не хочешь пользоваться костылями -- до свиданья. Таких привередливых -- не обслуживаем.
"Значит вам гнилого не надо, а другие его должны покупать? И вообще обед у нас" :)))
Теперь вот ситуация -- у тебя два packaged приложения, в каждом из которых свои представления о том, что такое «покупатель». Исключить это ты, по каким-то причинам, не можешь.
Но если ты строишь SOA, то твоя задача -- исключить любую возможность изменения данных в одном из них так, чтобы не изменились данные в другом. Т.е. ты должен разделить слои представления и логики/данных и построить фасад, через который работать с обоими приложениями. Бизнес-объект опять один, приватные форматы приложений учитываются только в фасаде. Фасад же отвечает за соответсвие двух баз -- путем одновременно их обновления.
Но если пользовательский интерфейс намертво вшит в оба приложения и по «плоским» уровням ты их порезать не можешь? Классического SOA на этом слое нет. Узкое место. Как решали в case’aх -- синхронизация состояния баз на уровне EAI, потому, как требуется работа с событиями. Или теперь это приплыло к терминам типа Event Driven Architecture.
Ну или еще вариант. Делаем опять-таки фасад для каждого приложения. Помещаем в него функцию опроса баз на предмет появления в них изменений, функуцию получения этих изменений, функцию апдейта. И пишем приватную логику синхронизации (оркестровки). Для публики же будет доступен только интерфейс по внесению изменений в общую базу и доступны данные из какой-то одной из них.
Вариант, конечно, плохой.
Я тут ситуацию немного упростил, потому как в одной посте все варианты рассматреть сложно.
декабря 1, 2006 15:01
Tolik said:
Полностью согласен с технически грамотрным описанием что я могу и что не могу сделать. Я, в общем-то об этом-же. Дальше дискуссия на уровне восприятия - стакан наполовину пуст или наполовину полон - т.е. описанная ситуация есть ли решение проблем конкретного предприятия или не особо. Я пока склоняюсь, что не особо.
декабря 1, 2006 17:08
Vlad Borkus said:
>Ют.е. описанная ситуация есть ли решение >проблем конкретного предприятия или не особо. >Я пока склоняюсь, что не особо.
У тебя много самописного ПО, если я правильно понял, т.е. эти идеи могут быть полезными.
Но кто лучше тебя знает ИТ твоего предприятия?
"Если доктор скажет в морг -- значит в морг" :)))
В целом, SOA - не SOA, главное, чтобы помогало.
Нужно вести здоровый образ жизни :)))
Отказ от мучного и сладкого, если хочешь похудеть :)))
Если серьезно,то сколько народу сумело этими мыслями воспользоваться?
Хотя нет, товаропроизводители очень даже воспользовались :))))
декабря 1, 2006 17:36
Vlad Borkus said:
>Есть у Вас очень важный момент: "Описание всех интерфейсов должно быть унифицировано, и репозиторий должен быть центральным"
Чего-то это задело, захотелось еще утонить. Репозиторий должен быть единым, и только в этом смысле центральным. Например, упоминавшийся UDDI v3 (если я правильно помню) позволяет
1) делать репозиторий распределенным с реплицированием. Т.е. вы можете в удаленном офиисе работать с копией, что удобно
2) предусмативает делегирование полномочий по управлению кусочками репозитория. (Что, правда, не всегда надо/хорошо в корпоративной среде)
декабря 2, 2006 3:54
feygin said:
> Даниил, наверное, добавит, если что упущу.
Добавлю, конечно, отчего же не добавить, раз уж такая ...party :)
http://feygin.elashkin.com/2006/12/soa_02.html
декабря 2, 2006 23:09
feygin said:
Называть UDDI репозиторием не очень правильно, потому что он все-таки не хранит никаких артефактов, а только регистрирует их. Логика была следующая: для интероперабельности инструментальных и middleware-, governance- и прочих средств достаточно стандартизованного доступа к реестру, а используя хранимые в нем ссылки необходимые артефакты можно получить из внешних репозиториев по не менее стандартному HTTP GET. Репозитории, являющими master-системами в связке с реестром, могут быть специфическими, например, какой-нибудь SAP может притащить свой репозиторий, а Oracle -- свой. Это нужно, например, для того, чтобы вендор мог генерировать артефакты динамически исходя из конфигурации своей систем. Могут быть и не контролируемые внешние артефакты. Общим связывающим элементом для всей SOA остается реестр. Я видел примеры, когда отдельный реестр был бы гораздо более эффективным решением, чем совмещенный реестр/репозиторий (как, например, ebXML Registry).
Eдинство реестра не означает его централизацию. Механизм иерархических разделов в UDDI V3 позволяет гибко делегировать управление и публикацию, оставляя сколько угодно регулирования (правил регистрации и обновления) уровню выше. Помимо этого есть механизмы распределения единого реестра по нескольким физически раздельным экземплярам, а также более экзотический механизм affiliation. Суть в том, что централизации в SOA (как административной, так и технологической) может быть ровно столько, сколько требуется в каждом конкретном случае, и модель UDDI-реестра поддерживает это требование.
декабря 3, 2006 0:28
Даниил Фейгин: мысли вслух said:
Предметное обсуждение SOA началось и по-русски. Сколько ни пишут журналы на эту тему, дискуссии никак
декабря 3, 2006 13:08
Vlad Borkus said:
>Предметное обсуждение SOA началось и по->русски. Сколько ни пишут журналы на эту тему, >дискуссии никак
То, как пишут наши журналы, не предполагает дискуссии. В них черезчур уж однобокая картина.
У Миши Елашкина была большая статься о проблемах современной прессы. На 90% могу подтвердить.
декабря 3, 2006 19:01
IMHO said:
Несколько недавних постов по поводу SOA на itblogs.ru сподвигли меня проглядеть доступные источники с
декабря 10, 2006 20:49
Just do IT said:
Так что же такое SOA . Сервисно-ориентированная архитектура. Вроде бы очень говорящее словосочетание.
декабря 11, 2006 14:01
Мысли по поводу интеграции, SOA и т.д said:
В последнее время ведется много дискуссий по поводу интеграции и особенно SOA (Service-Oriented Architecture)
декабря 17, 2006 12:09
Мысли по поводу интеграции, SOA и т.д said:
В последнее время ведется много дискуссий по поводу интеграции и особенно SOA (Service-Oriented Architecture)
декабря 17, 2006 12:11
Даниил Фейгин: мысли вслух said:
Предметное обсуждение SOA началось и по-русски. Сколько ни пишут журналы на эту тему, дискуссии никак
февраля 24, 2009 12:10
Влад Боркус
Перечитав все комментарии, которые были сделаны в публикациях про SOA на ИТ Блогз, я обнаружил, что во всей нашей дискуссии был фундаментальный изъян. Начиная говорить про SOA, мы почти немедленно переходили на обсуждение веб-сервисов. В целом это не удивительно -- мы окружены вендорской пропагандой, из которой другой вывод сделать сложно. И все же веб-сервисы и SOA -- это не одно и то же.
И не только потому, что можно построить кучу веб-сервисов, и не внедрить у себя в итоге SOA. Этот тезис, безусловно, совершенно справедлив, но лишь чуть приближает к истине.
И не потому, что SOA -- не равно ESB, о чем тоже много говорилось.
А потому, что SOA -- это вообще не про веб-сервисы. Т.е. как бы совсем не про то.
Если говорить формально, то SOA -- это некоторая концепция реинжиниринга и развития корпоративного программного ландшафта. Упоминания этого термина можно встретить где-то в 1996 году у Гартнера. Тогда эти идеи в практической плоскости соотносились с компонентными технологиями.
С тех пор этот набор идей оброс неким опытом и набором где-то использованных приемов, которые в совокупности носят красивое название SOA Governance.
Появились XML и веб-сервисы, и оказалось, что эти идеи неплохо этой технологией дополняются.
Компоненты SOA
В основе SOA действительно лежит понятие сервиса, хотя не только его. Другими компонентами SOA являются фронт-энды приложений, репозиторий описаний сервисов, сервисная шина.
Ключевым для SOA являются наличие сервисов, ориентированных на деловые задачи. В SOA могут быть и масса других сервисов (трансформации, авторизации, и т.п.), но они вторичны.
Главное, что основные сервисы предоставляют каждый какой-то законченный деловой функционал. Крупный блок этого функционала. Скажем, сервис может предоставлять функции по работе с контрактом или с информацией о сотруднике.
В CORBA, EJB приложение строится из множества маленьких кирпичей. В SOA -- из малого количества больших.
В идеале бизнес-сервис должен предоставлять законченную функциональность по работе с сущностью, которой он взялся управлять. Например, в организации у нас есть только один
сервис по управлению контрактами. Иначе говоря, важное отличие сервиса от объекта CORBA -- это его изолированность от других сервисов.
Хотя в реальной жизни избежать даже корреляции сервисов не всегда удается, в идеале он должен быть совсем изолированным, и отвечать за все ресурсы, находящиеся под его управлением. Т.е., скажем, если у нас есть сервис, отвечающий за заказы, то изменить заказ в рамках SOA позволительно только одним способом -- через этот сервис. (Вспомним, что SOA -- это про организацию работ).
Чтобы добиться такой изолированности, борцы за SOA-веру предлагают проводить декомпозицию приложений. Или, когда это не возможно, строить так называемые «фасады» -- независимые сервисы, обращающиеся к одному или нескольким нижележащим системам. И работать потом через них.
Ключевым качеством сервиса является его описание. В описании сказано, что за интерфейс (функции) сервис имеет, приведен контракт (на каких условиях возможен доступ), и прочее -- кто его состряпал, какая версия, кто может менять сервис, когда этот сервис доступен, какая у него нагрузочная способность. Это описание совсем не обязательно должно быть на WSDL, например оно может быть на IDL или даже в MS Word. Главное, чтобы оно было.
Естественно, если описание -- в машино-распознаваемом формате, то использовать сервис потом намного удобнее.
Сами сервисы могут быть реализованы в рамках родной инсталляции SOA на разных технологических платформах -- WS, Java, .Net, CORBA. Более того, идея SOA как раз и состоит в том, чтобы обезопасить ИТ-инфраструктуру от смены поколений информационных технологий и стыковать плохо совместимые унаследованные технологии. Скажем, идеологи SOA открыто говорят, что SOAP когда-то отомрет, а ИТ надо будет и дальше жить. Требуется только, чтобы сервисы отвечали формальным требованиям SOA.
Работают с сервисами так называемые фронт-энды -- по большей части клиентские приложения разного сорта. Но могут работать и так называемые процессные сервисы, которые инкапсулируют оркестровку делового процесса. Можно также представить в этом контексте и другие сервисы - деловые правила.
Выше я также опустил так называемые технологические сервисы, к которым, например, относятся адаптеры. И сервисы, расширяющие функциональность нижележащей системы.
***
Все описания сервисов (описание интерфейса и контракт) обязаны храниться в репозитории.
Если это формальные описания, то система будет более конфигурируемая. Но, стоит заметить, что полноценные репозитории более сложны, а важны больше для B2B-среды, а не контролируемой корпоративной среды.
Но репозиторием может быть, и склад word-документов в файловой системе (это, конечно, экстремальный случай). В конце концов главный элемент в рамках SOA -- это корпоративный разработчик.
Здесь важны два момента. Описание всех интерфейсов должно быть унифицировано, и репозиторий должен быть центральным. Разработчик или динамически конфигурируемый клиент обращаются только к репозиторию, чтобы почерпнуть описания. Иначе -- SOA распадется.
Последний компонент SOA -- это шина сервисов. Это -- не обязательный компонент SOA. И уж, конечно, совсем не обязательно -- это ESB.
Главной задачей шины является технологическа стыковка систем на ее концах. Т.е. если с одной стороны у нас находится SOAP, а с другой -- CORBA, то шина должна обеспечить преобразование формата вызова от одной системы к другой. Например, коммутацию XML-полей на методы CORBA. Мы это можем сделать, так как у нас есть «нейтральное» описание сервиса.
В принципе, в рамках SOA может существовать несколько параллельных шин, скажем она -- асинхронная, а другая синхронная. Или идентичные шины в географички разных филиалах.
Проблемы
Как легко понять, у SOA много проблем. Транзакционной целостности очень сложно добиться, собрав систему из кубиков -- компенсационные шаги очень запутаны. Есть несколько теорий, как это надо делать, но все они имеют большие издержки. Хотя ясно, что задача не решается в общем случае в принципе.
Есть проблемы с тем, как строить безопасность в такой системе -- на каком уровне должна проводиться аутентификация, авторизация. Особенно все сложно в условиях, когда нельзя сделать общий identity сервис. Опять, есть у людей идеи, но выбор -- по обстоятельствам.
Есть проблемы, о которых упоминал Анатолий, -- как быть с бизнес-объектами. Хотя самый очевидный путь -- это стандартизовать их на уроне шины. Также бизнес-объекты по сути сами являются готовыми сервисами.
Есть в конце концов проблема организационная (все расползается) и с архитекторами (чтобы создать такую архитектуру нужны архитекторы экстра-класса, а их в мире на каждую фирму не наберешь).
Что касается успехов. Есть проекты, причем достаточно большие. Хотя их беглый анализ местами не внушает оптимизма -- в одних исходная задача была относительно простая, в других -- решение получилось кривое, и его переделывают.
****
PS. Написать этот текст меня подстрекал Анатолий, так что вся ответственность за последствия лежит на нем. Особенно если там отдельные вендор будут кидать в меня камнями :))
Но если статью на форуме сочтут приличной, то я ее попробую доработать и пристроить в какой-нибудь ИТ-журнал.
Published 30 ноября 2006 г. 5:21 by Vlad Borkus
Comments
Toliksaid:Ну, как минимум, не зря подстрекал - поскольку в общем-то все эти вещи вроде и понятные, но в кучу их собрать и систематизировать весьма полезно. Как минимум для появления общей терминологиии, что в 80% достаточно чтобы привести к консенсусу любую дискуссию ;-)
Щас Михаил скажет - что это можно маленько доработать - и в WiKi>
ноября 30, 2006 6:53
Elena Makurochkina said:
Спасибо за такой подробный пост!
Есть у Вас очень важный момент: "Описание всех интерфейсов должно быть унифицировано, и репозиторий должен быть центральным".
В общем этот абзац рушит понимание SOA именно как архитектуры. Фактически это говорит о том что архитектурный подход SOA ничем не отличается от стандартного – система должны быть ЕДИНОЙ. Т.е. это не подход к архитектуре, а подход к реализации.
За последнее время начитавшись и научавствовавшись в обсуждении SOA здесь, на ITBlogs, и, параллельно, влезши в тонкость Agile методологий разработки, стала я с большим подозрением смотреть на все гибкое, настраиваемое и универсальное: http://sundest.blogspot.com/2006/11/blog-post_30.html
ноября 30, 2006 7:47
Mikhail Elashkin said:
Коллеги, покажу как работать в Вики. Только с понедельника.
На этой неделе я заканчиваю один проект и перегружен ((
ноября 30, 2006 8:40
Tolik said:
Тут то и ловушка в центральном репозитории - потому что или я должен планировать его сам (и писать сам сервисы?) или, чтобы я мог в нем объединить в нем продукты разных вендоров - кто-то их должен стандартизировать (кто?)
ноября 30, 2006 8:47
Vlad Borkus said:
>Тут то и ловушка в центральном репозитории - потому что или я должен планировать его сам
Конечно -- планировать сам.
Вендор может и поможет немного, если создаст API в этой концепци. А может и наоборот, все запутает.
ноября 30, 2006 13:27
Vlad Borkus said:
Sundest,
>Фактически это говорит о том что архитектурный подход SOA ничем не отличается от стандартного – система должны быть ЕДИНОЙ.
Создание единой системы из кусочков -- цель любой интеграции.
Вы в целом описали идею-фикс у Гартнера. Назвыется общекорпоративный API.
Но в отношении SOA есть тонкость. Связи между кусками системы намного слабее, чем в приложенни класса R/3.
Более того, поскольку куски демаркированы API вот именно таким образом, то вы можете делать их на разных технологиях.
>В общем этот абзац рушит понимание SOA именно как архитектуры.
Архитектура -- еще менее четкий термин, чем SOA. Дискуссия, что же такое архиектура приложения идет лет 40.
ноября 30, 2006 13:35
Mikola said:
Очень толковый пост !
Спасибо
>Есть проекты, причем достаточно большие
"Имя сестра, имя !"
Особенно в России :-)
И еще, хотелось бы узнать наименее кривой, по Вашему мнению, проект.
Так сказать, лучший из худших.
ноября 30, 2006 17:30
Vlad Borkus said:
2 Mikola.
В России негусто. В сколько-нибудь полноценном виде не попадалось. Т.е интеграционные проекты на web-сервисах есть, в частности, скажем, на NetWeaver (см. ссылки в публикации Михаила Елашкина по последней конференции SAP), но вот насколько они исполнены в духе философии SOA -- не ясно. Мне показалось, что нет. Про нашумевший путь к SOA компании Аэрофтот могу тоже сказать, что действительно кое-что они в этом направлении два года делают, но судя по их презентациям, пока все очень и очень локально.
Примеры на Западе, по которым есть более-менее внятные описания:
- Deutsche Post AG (правда, исходно была низкая гетерогенность);
- Winterthur (швецкая страховая компания, но добиться полной изолированности сервисов, они, как я понял не смогли);
- Credit Suisse (большая SOA, в основном на базе CORBA, вроде бы довольно удачно развивают с середины 90-х)
- Halifax Bank Of Scotland (позиционирутеся как SOA, но по впечатлениям от описания --скорее интеграционный проект на базе web-сервисов. Делали в спешке. Не добились изоляции сервисов. Хотя исходно и не ставили такой задачи, отложив ее на второй этап. Возникли проблемы с переконфигурированием).
Упомнается еще часто проект в British American Tobacoo (использовали NetWeaver, SOA Software. Позиционируется как SOA). Но ощущения, что там есть внятная стратегия, у меня нет. Возможно, опять, внедрили пару продуктов. Описания очень туманные.
IBM на последнем своем бизнес-форуме давала примеры своих проектов, но подано было как чистая реклама. С ними надо разбираться. Что делали и как. Я пока не копался в их case'ах.
ноября 30, 2006 18:24
Tolik said:
Интересно, у нас значимая часть внутренней информационной системы (обмен данными с филиалами) - хоть сейчас в учебник по SOA (Web, XML, очереди сообщений, шина данных, только веб-сервисов нету, не понадобились они), но никакого SOA мы не делали, просто напрашивавшаяся логика развития. НО революции я там упорно не вижу, хотя решения, на мой взгляд и весьма красивые. ТОлько при чем тут SOA, обычные логичные решения.
ноября 30, 2006 20:12
Vlad Borkus said:
>ТОлько при чем тут SOA, обычные логичные >решения.
Логичные решения БОльшая редкость, потому теперь они выделены в специальный класс SOA. :))))) И являются объектом почитания :))))
Если серьезно, то значит ты просто на позиции CIO в этой компании достаточно долго, чтобы эту системную логику поддерживать.
В США не так. Средний срок жизни CIO на посту -- 11 месяцев, кажется. Я уж не говорю об увлечениях ИТ-модой. Плюс там компании существуют не 10 лет, а 40. Ну результат -- соответсвенно.
Внедрение SOA означает наведение этой самой логики, с выделением независимых сервисов.
Поэтому я и говорю, что к этому нужно относиться как к набору неких здравых идей.
ноября 30, 2006 21:51
Mikhail Elashkin said:
IBM называет Аэрофлот как case по SOA в России.
я собираюсь там посидеть и посмотреть что они сделали. но уже в 2007 году.
ноября 30, 2006 23:37
Vlad Borkus said:
>IBM называет Аэрофлот как case по SOA в России.
Миша, слабенько там вроде бы. Я же был на их презентации на бизнес-форуме. Два веб-сервиса, планы на 10 лет вперед. IBM я понимают понятно -- такая закупка софта. MQ, ProcessServer, MessageBroker и еще много всего. К тому же у них Lotus там. Вообще IBM shop.
Хотя, возможно, просто презентовать не могли по нормальному.
Но если планируется поход с реальным долгим обсуждением того, что они дейстсвительно сделали, то бери с собой.
декабря 1, 2006 0:07
Tolik said:
>Логичные решения БОльшая редкость, потому
>теперь они выделены в специальный класс
>SOA. :)))))
Может быть это вот и есть описание SOA ? ;-)
Несколько общо, но за эпиграф - сойдет на 100%
Главное, чтобы не за эпитафию
декабря 1, 2006 6:40
feygin said:
> Тут то и ловушка в центральном репозитории - потому что или я должен планировать его сам (и писать сам сервисы?) или, чтобы я мог в нем объединить в нем продукты разных вендоров - кто-то их должен стандартизировать (кто?)
О том, что информационная модель и API этого реестра должны быть стандартизованы вендорам было понятно довольно давно. Стандарт этот называется UDDI (см. http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.h…) и ваш покорный слуга к созданию его третьей версии имеет самое непосредственное отношение. Буду рад ответить на вопросы.
декабря 1, 2006 9:55
Tolik said:
UDDI - это хорошо
Но это немного не то. UDDI стандартизирует как найти сервер, как узнать чего у него есть ... Т.е. в общем-то это всё на уровне RPC
А для взаимодействия бизнес-модулей - нужны стандарты на бизнес-объекты, иначе сало будет радости другим бизнес-модулям от того, что в системе завелся HR-сервис. Чтобы его смогли использовать - должен быть стандартизован формат, скажем, объекта "сотрудник", способы запроса этих сотрудников из HR модуля, способы получения и фильтрации коллекций таких объектов ...
Создать такое можно - и тогда CRM От MS поймет и задействует HR от Oracle и всё будет здорово, но беда в том, что такой стандарт создаст почти непреодолимый барьер для входа в рынок революционных, не описаных в стандарте бизнес-модулей. Потому что на момент их выпуска их никто не узнает, а стандартизировать их не будут потому, что они не распространены
декабря 1, 2006 10:10
feygin said:
> Но это немного не то. UDDI стандартизирует как найти сервер, как узнать чего у него есть ...
Помимо этого на базе UDDI строятся реестры метаданных, хранящихся где-то снаружи. Как следствие, UDDI является механизмом их многократного использования, целью которого является заветная унификация интерфейсов.
Изменение этих интерфейсов в дальнейшем -- дело процессов, которые мы здесь называем "жизнью по SOA" (или более традиционно SOA governance). Собственно, основное назначение UDDI и состоит в design-time согласовании SOA, т.е. это центральный элемент этого самого governance (роль UDDI в runtime, на мой взгляд, несколько преувеличена, хотя в ряде случаев бывает весьма кстати). Замечу, что если интероперабельности между различными инфраструктурными элементами, поддерживающими governance, не требуется (или элементов таковых не имеется), то, как правильно отметил выше Влад, в качестве такого реестра/репозитория сойдет и файловая система или, скажем, Wiki-сайт какой-нибудь.
> Т.е. в общем-то это всё на уровне RPC
Не понял, что на уровне RPC? Как раз имевшие место неделю назад обсуждения на тему Web-сервисного RPC к SOA прямого отношения и не имеют. Я, к сожалению, не в состоянии достаточно плотно отслеживать происходящее здесь, поэтому не успел вовремя включиться в ту дискуссию.
декабря 1, 2006 10:31
Vlad Borkus said:
>А для взаимодействия бизнес-модулей - нужны стандарты на бизнес-объекты, иначе сало будет радости другим бизнес-модулям от того, что в системе завелся HR-сервис
Толя, надо вернуться к главной идее всего этого. Даниил, наверное, добавит, если что упущу.
А именно главное -- как мы выделяем сервисы. По сути-то главная идея SOA чем-то похожа на нормализацию базы данных, но только перенесена она в область интерфейсов и данных. Оговорюсь сразу, что аналогия не точная (см исходный текст).
Выделим некоторую смысловую и законченную область (скажем , «клиент») и демаркируем ее как сервис. Иначе говоря у нас во всей архитектуре формат бизнес-объекта только один.
Если ты "приложение" и хочешь с ним работать -- вот сервисное соглашение в реестре, пытайся ему удовлетворить. Не можешь -- вот тебе какие-то костыли в виде шины и сервисов трансформации. Не хочешь пользоваться костылями -- до свиданья. Таких привередливых -- не обслуживаем.
"Значит вам гнилого не надо, а другие его должны покупать? И вообще обед у нас" :)))
Теперь вот ситуация -- у тебя два packaged приложения, в каждом из которых свои представления о том, что такое «покупатель». Исключить это ты, по каким-то причинам, не можешь.
Но если ты строишь SOA, то твоя задача -- исключить любую возможность изменения данных в одном из них так, чтобы не изменились данные в другом. Т.е. ты должен разделить слои представления и логики/данных и построить фасад, через который работать с обоими приложениями. Бизнес-объект опять один, приватные форматы приложений учитываются только в фасаде. Фасад же отвечает за соответсвие двух баз -- путем одновременно их обновления.
Но если пользовательский интерфейс намертво вшит в оба приложения и по «плоским» уровням ты их порезать не можешь? Классического SOA на этом слое нет. Узкое место. Как решали в case’aх -- синхронизация состояния баз на уровне EAI, потому, как требуется работа с событиями. Или теперь это приплыло к терминам типа Event Driven Architecture.
Ну или еще вариант. Делаем опять-таки фасад для каждого приложения. Помещаем в него функцию опроса баз на предмет появления в них изменений, функуцию получения этих изменений, функцию апдейта. И пишем приватную логику синхронизации (оркестровки). Для публики же будет доступен только интерфейс по внесению изменений в общую базу и доступны данные из какой-то одной из них.
Вариант, конечно, плохой.
Я тут ситуацию немного упростил, потому как в одной посте все варианты рассматреть сложно.
декабря 1, 2006 15:01
Tolik said:
Полностью согласен с технически грамотрным описанием что я могу и что не могу сделать. Я, в общем-то об этом-же. Дальше дискуссия на уровне восприятия - стакан наполовину пуст или наполовину полон - т.е. описанная ситуация есть ли решение проблем конкретного предприятия или не особо. Я пока склоняюсь, что не особо.
декабря 1, 2006 17:08
Vlad Borkus said:
>Ют.е. описанная ситуация есть ли решение >проблем конкретного предприятия или не особо. >Я пока склоняюсь, что не особо.
У тебя много самописного ПО, если я правильно понял, т.е. эти идеи могут быть полезными.
Но кто лучше тебя знает ИТ твоего предприятия?
"Если доктор скажет в морг -- значит в морг" :)))
В целом, SOA - не SOA, главное, чтобы помогало.
Нужно вести здоровый образ жизни :)))
Отказ от мучного и сладкого, если хочешь похудеть :)))
Если серьезно,то сколько народу сумело этими мыслями воспользоваться?
Хотя нет, товаропроизводители очень даже воспользовались :))))
декабря 1, 2006 17:36
Vlad Borkus said:
>Есть у Вас очень важный момент: "Описание всех интерфейсов должно быть унифицировано, и репозиторий должен быть центральным"
Чего-то это задело, захотелось еще утонить. Репозиторий должен быть единым, и только в этом смысле центральным. Например, упоминавшийся UDDI v3 (если я правильно помню) позволяет
1) делать репозиторий распределенным с реплицированием. Т.е. вы можете в удаленном офиисе работать с копией, что удобно
2) предусмативает делегирование полномочий по управлению кусочками репозитория. (Что, правда, не всегда надо/хорошо в корпоративной среде)
декабря 2, 2006 3:54
feygin said:
> Даниил, наверное, добавит, если что упущу.
Добавлю, конечно, отчего же не добавить, раз уж такая ...party :)
http://feygin.elashkin.com/2006/12/soa_02.html
декабря 2, 2006 23:09
feygin said:
Называть UDDI репозиторием не очень правильно, потому что он все-таки не хранит никаких артефактов, а только регистрирует их. Логика была следующая: для интероперабельности инструментальных и middleware-, governance- и прочих средств достаточно стандартизованного доступа к реестру, а используя хранимые в нем ссылки необходимые артефакты можно получить из внешних репозиториев по не менее стандартному HTTP GET. Репозитории, являющими master-системами в связке с реестром, могут быть специфическими, например, какой-нибудь SAP может притащить свой репозиторий, а Oracle -- свой. Это нужно, например, для того, чтобы вендор мог генерировать артефакты динамически исходя из конфигурации своей систем. Могут быть и не контролируемые внешние артефакты. Общим связывающим элементом для всей SOA остается реестр. Я видел примеры, когда отдельный реестр был бы гораздо более эффективным решением, чем совмещенный реестр/репозиторий (как, например, ebXML Registry).
Eдинство реестра не означает его централизацию. Механизм иерархических разделов в UDDI V3 позволяет гибко делегировать управление и публикацию, оставляя сколько угодно регулирования (правил регистрации и обновления) уровню выше. Помимо этого есть механизмы распределения единого реестра по нескольким физически раздельным экземплярам, а также более экзотический механизм affiliation. Суть в том, что централизации в SOA (как административной, так и технологической) может быть ровно столько, сколько требуется в каждом конкретном случае, и модель UDDI-реестра поддерживает это требование.
декабря 3, 2006 0:28
Даниил Фейгин: мысли вслух said:
Предметное обсуждение SOA началось и по-русски. Сколько ни пишут журналы на эту тему, дискуссии никак
декабря 3, 2006 13:08
Vlad Borkus said:
>Предметное обсуждение SOA началось и по->русски. Сколько ни пишут журналы на эту тему, >дискуссии никак
То, как пишут наши журналы, не предполагает дискуссии. В них черезчур уж однобокая картина.
У Миши Елашкина была большая статься о проблемах современной прессы. На 90% могу подтвердить.
декабря 3, 2006 19:01
IMHO said:
Несколько недавних постов по поводу SOA на itblogs.ru сподвигли меня проглядеть доступные источники с
декабря 10, 2006 20:49
Just do IT said:
Так что же такое SOA . Сервисно-ориентированная архитектура. Вроде бы очень говорящее словосочетание.
декабря 11, 2006 14:01
Мысли по поводу интеграции, SOA и т.д said:
В последнее время ведется много дискуссий по поводу интеграции и особенно SOA (Service-Oriented Architecture)
декабря 17, 2006 12:09
Мысли по поводу интеграции, SOA и т.д said:
В последнее время ведется много дискуссий по поводу интеграции и особенно SOA (Service-Oriented Architecture)
декабря 17, 2006 12:11
Даниил Фейгин: мысли вслух said:
Предметное обсуждение SOA началось и по-русски. Сколько ни пишут журналы на эту тему, дискуссии никак
февраля 24, 2009 12:10
Комментариев нет:
Отправить комментарий