вопросы про SOA
1) В чем суть SOA? В большинстве статей написана какая-то маркетинговая чушь. Хотелось бы услышать четкий ответ.SOA и есть по сути маркетинговая чушь
Просто считается, что вместо того, чтобы писать переходник, скажем SAP - Oracle, можно из SAP вытянуть данные через WS, затем их через WS засунуть в Oracle.
3) На основании чего сейчас считается, что SOA позволит решить те проблемы, которые не могли ранее решить CORBA, DCOM и другие подобные технологии?
CORBA и DCOM к сожалению умерли.
Не морочь голову, WS - интеграционный стандарт, не имеющий никакого смысла в однородных системах.
Сам термин SOA довольно расплывчатый.
Единого понимания о том, что такое SOA, нет, поэтому точного формального определения ты не найдешь.
Принципиальное отличие от CORBA, DCOM и иже с ними очень простое: DCOM и CORBA - это технологии, а SOA - архитектура, или даже способ мышления, то есть SOA никак не завязана на способ реализации. Хотя придумывалось и то и другое для решения примерно одинаковых задач.
Если говорить с практической точки зрения, то важна не сама идея SOA - ориентация на сервисы, а скорее метод ее внедрения.
То есть SOA начинается не с определения, а с книжки, где описано, как именно нужно строить архитектуру SOA в IT-инфраструктуре отдельно взятой компании.
Соответственно различные производители интеграционных продуктов напишут в этих книжках разные вещи, поскольку у них разное видение предмета.
Из важных особенностей построения архитектуры SOA я бы выделил то, что она строится исходя из требований бизнеса, а не исходя из требований IT. То есть любой правильный процесс построения SOA архитектуры должен начинаться с выделения реальных бизнес-задач и оценки того, какие сервисы нужно реализовать для этих бизнес-задач, чтобы избежать дублирования функциональности.
Один из способов понять, что такое SOA - это понять, чем она не является.
Тут в помощь гугл - SOA anti-patterns.
Единого понимания о том, что такое SOA, нет, поэтому точного формального определения ты не найдешь.
Принципиальное отличие от CORBA, DCOM и иже с ними очень простое: DCOM и CORBA - это технологии, а SOA - архитектура, или даже способ мышления, то есть SOA никак не завязана на способ реализации. Хотя придумывалось и то и другое для решения примерно одинаковых задач.
Если говорить с практической точки зрения, то важна не сама идея SOA - ориентация на сервисы, а скорее метод ее внедрения.
То есть SOA начинается не с определения, а с книжки, где описано, как именно нужно строить архитектуру SOA в IT-инфраструктуре отдельно взятой компании.
Соответственно различные производители интеграционных продуктов напишут в этих книжках разные вещи, поскольку у них разное видение предмета.
Из важных особенностей построения архитектуры SOA я бы выделил то, что она строится исходя из требований бизнеса, а не исходя из требований IT. То есть любой правильный процесс построения SOA архитектуры должен начинаться с выделения реальных бизнес-задач и оценки того, какие сервисы нужно реализовать для этих бизнес-задач, чтобы избежать дублирования функциональности.
Один из способов понять, что такое SOA - это понять, чем она не является.
Тут в помощь гугл - SOA anti-patterns.
Просто считается, что вместо того, чтобы писать переходник, скажем SAP - Oracle, можно из SAP вытянуть данные через WS, затем их через WS засунуть в Oracle.Ты пишешь про EAI, а не про SOA.
Даже если система EAI построена на веб-сервисах, она все равно больше ориентирована на задачи IT, а не бизнеса.
Хотя SOA действительно сильно смахивает на маркетинговую чушь.
По крайней мере доказательств реального преимущества такой архитектуры я пока не видел.
Парочка success stories - еще не доказательство.
DCOM и CORBA - это технологии, а SOA - архитектура
тогда скорее DCOM и CORBA - это спецификации на архитектуру, а SOA - это методология.
Ты пишешь про EAI, а не про SOA.Не понимаю, почему ты разделяешь задачи IT и бизнеса.
Даже если система EAI построена на веб-сервисах, она все равно больше ориентирована на задачи IT, а не бизнеса.
Пример с Oracle + SAP это упрощенный вариант того, как сам представитель Oracle описывал SOA на своей конференции (OASIS).
Далее они привели пример: декомпозиция бизнес-процессов какой-то там конторы в терминах BPEL и веб-сервисов. Содержит около 300 сервисов
После этого мое мнение о SOA и Oracle в частности сильно изменилось к худшему
Тоже вариант.
Задачи IT и бизнеса я разделяю потому, что у IT и бизнеса разные цели.
Если сразу исходить из нужд и возможностей IT, то можно прийти не туда.
Если 300 сервисов - это все сервисы компании, то это немного.
Если сразу исходить из нужд и возможностей IT, то можно прийти не туда.
Если 300 сервисов - это все сервисы компании, то это немного.
Задачи IT и бизнеса я разделяю потому, что у IT и бизнеса разные цели.Да, разные, причем они не пересекаются Я вот совершенно не понимаю, какое отношение SOA имеет к бизнесу.
Если 300 сервисов - это все сервисы компании, то это немного.
Ага, только представленные в процедурном виде. Представляю, каково будет это сопровождать.
Я вот совершенно не понимаю, какое отношение SOA имеет к бизнесуSOA - это методология реорганизации бизнес-процессов компании так, чтобы получилась красивая сервис-ориентированная архитектура.
Предполагается, что именно такая архитектура даст компании [вставляем любые маркетинговые лозунги].
Фишка в том, что преобразование затрагивает не только IT-инфраструктуру (в отличие от EAI но и работу бизнес-подразделений. Именно поэтому SOA так трудно внедрить - она должна решать задачи бизнеса, но делать большую часть должны айтишники. В итоге препятствий при внедрении более чем достаточно.
SOA - это методология реорганизации бизнес-процессов компанииКороче, суть в том, что бизнес-процессы должны быть представлены как можно более независимым и слабо связанным образом? Так? Я просто за всеми этими маркетинговыми лозунгами не вижу самой методологии.
Я так понимаю, что для реализации SOA нужно сделать набор сервисов, как можно лучше покрывающих необходимости всех бизнес-процессов, при этом допустив минимум дублирования функциональности.
А сама идея SOA в том, что после этого построение любых производных бизнесс-процессов будет выглядеть как простой конструктор.
То есть после некоторой реорганизации IT можно будет например легко строить сквозные бизнес-процессы, или скажем навернуть портал для всех бэк-офисов и т.д.
Плюс построение новых бизнес-процессов будет гораздо проще при грамотном наборе сервисов. По идее, это должно развязывать руки бизнес-подразделениям, когда они придумывают что-то новое.
То есть лозунг SOA, как я его понимаю - "дайте свободу бизнесу".
Другое дело, что при попытке это сделать зачастую получается сферический конь в вакууме.
По крайней мере про ошибки при внедрении SOA пишут все кому не лень, а вот успешные внедрения попадаются гораздо реже.
Выглядит это примерно как у того доктора, который говорил - "Не беспокойтесь, предыдущие 100 таких операций я провалил, должно же наконец получиться".
А сама идея SOA в том, что после этого построение любых производных бизнесс-процессов будет выглядеть как простой конструктор.
То есть после некоторой реорганизации IT можно будет например легко строить сквозные бизнес-процессы, или скажем навернуть портал для всех бэк-офисов и т.д.
Плюс построение новых бизнес-процессов будет гораздо проще при грамотном наборе сервисов. По идее, это должно развязывать руки бизнес-подразделениям, когда они придумывают что-то новое.
То есть лозунг SOA, как я его понимаю - "дайте свободу бизнесу".
Другое дело, что при попытке это сделать зачастую получается сферический конь в вакууме.
По крайней мере про ошибки при внедрении SOA пишут все кому не лень, а вот успешные внедрения попадаются гораздо реже.
Выглядит это примерно как у того доктора, который говорил - "Не беспокойтесь, предыдущие 100 таких операций я провалил, должно же наконец получиться".
А сама идея SOA в том, что после этого построение любых производных бизнесс-процессов будет выглядеть как простой конструктор.Согласен.
То есть после некоторой реорганизации IT можно будет например легко строить сквозные бизнес-процессы, или скажем навернуть портал для всех бэк-офисов и т.д.
Плюс построение новых бизнес-процессов будет гораздо проще при грамотном наборе сервисов. По идее, это должно развязывать руки бизнес-подразделениям, когда они придумывают что-то новое.
Суть - в наборе сервисов, которые можно друг с другом соединять, или как говорят в СОА, оркестровать, чтобы получить реализацию всего бизнес-процесса. При это часто упор в литературе делается на то, что эти сервисы могут быть реализованы разными организациями/компаниями. Соответственно, ИТ-одтел ищет готовые сервисы, пишет еще немного своих собственных, все это интегрирует - и дело сделано.
По сути это очень напоминает то, что называется Component-Based Development, где тоже предлагалось собирать приложения из готовых комронентов, сдеаланных возможно третьими конторами (то, что называется COTS - Components-off-the-Shelf) и весь процесс выглядит как собирание конструктора.
В случае СОА - приложения распределенные, и компоненты становятся сервисами. Но суть та же.
А вообще, в обоих подходах главная проблема состоит в том, как создать такие вот слабосвязанные сервисы, которые можно было бы потом заново использовать. Тут и нужно мастерство. При это часто оказывается так, что достичь хорошей слабосвязанности не получается, потому что решаемая задача (реализуемая функциональность) не поддается такому вот разделению ответственностей между компонентами. В каждом конкретном случае много специфики в реализуемых функциональностах, и поэтому часто оказывается так, что разработанный компонент годится только для данного бизнесс-процесса, а для другого похожего бизнес-процесса нужно уже что-то менять... То есть суть в том, что создание специфических компонентов, которые бы можно было бы легко использовать повторно, - это скорее миф...
Вся эта история напоминает анекдот про сову и мышь.
Мышь приходит к сове и говорит:
- Сова, я такая маленькая, меня все обижают, а ты такая умная, ты все знаешь, помоги мне, что мне далать, как быть?
- Стань ежиком!
- Спасибо, Сова, я знала, что ты мне поможешь! Я так и сделаю.
Мышка хочет уже уйти, но тут останавливается в растерянности...:
- Сова, а... как это... А как мне стать ежиком ?
- Я даю только стратегические советы !
Вот СОА - это по большому счему стратегический совет - сделаейте слабосвязанные сервисы и радуйтесь жизни. А как сделать так, чтоб было слабосвязано, да побольше - тут, надо полагать, СОА советов не дает -)
А как сделать так, чтоб было слабосвязано, да побольше - тут, надо полагать, СОА советов не дает -)
тут должен начаться глубокий и жестокий бизнес-анал по изменению и оптимизации бизнес процессов.
тут должен начаться глубокий и жестокий бизнес-анал по изменению и оптимизации бизнес процессов.В том числе и это.
Может помочь, до некоторой степени.
В любом случае это поможет установить, что делать дальше.
Может, вообще отказаться от СОА. Потому что оптимизация бизнес-процесса - это еще с какой стороны посмотреть. Например, может оказаться, что для того, чтоб бизнес шел проще, бизнес-процесс дожнен быть смоделирован и реализован с помощью ИТ так, что в результате окажется, что слабосвязанные сервисы для этого не подходят.
То есть, в общем, оптимизация с точки зрения бизнеса может и не означать оптимизации с точки зрения реализации этого бизнеса. Мало ли, как там оно все устроено.
Вот СОА - это по большому счему стратегический советМда, на методологию как-то не похоже. Похоже на пускание слюны у трехлетних младенцев.
The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design:
- Service Encapsulation
- Service Loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
- Service contract - Services adhere to a communications agreement, as defined collectively by one or more service description documents
- Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world
- Service reusability - Logic is divided into services with the intention of promoting reuse
- Service composability - Collections of services can be coordinated and assembled to form composite services
- Service autonomy – Services have control over the logic they encapsulate
- Service optimization – All else equal, high-quality services are generally considered preferable to low-quality ones
- Service discoverability – Services are designed to be outwardly descriptive so that
Вот с Википедии про СОА кусок, основные архитектурные принципы.
Если так посмотреть, то эти же самые принципы проповедуются, скажем, в классическом ООП, только там все это относится к объектам - и Encapsulation, и Loose Coupling, и Contract, и Abstraction. Только наверно последних двух пунктов нету, но они не самые принципиальные.
Вообще, это общие принципы для разработки ПО, обеспечивающие определенные качества ПО.
Получается, что СОА просто следует этим советам и переносит их на бизнес-сервисы.
короче СОА надо знать только сейлзам, для реального девелопмента ничего нового
Большое спасибо всем ответившим!
Насколько я понял, SOA — это скорее набор идей, принципов, методологий, нежели какая-то конкретные программы, протоколы, и т. п.
Если так, то тогда такой вопрос для проверки. Допустим, я организовал бизнес-процессы в некоторой компании так, что имеется несколько сервисов, которые действительно независимы друг от друга и взаимодействуют через строго определенные интерфейсы. Но при этом, сами эти интерфейсы определены на IDL (а не на WSDL а в качестве протокола для взаимодействия сервисов используется CORBA (а не SOAP). Вопрос: является ли это SOA?
Насколько я понял, SOA — это скорее набор идей, принципов, методологий, нежели какая-то конкретные программы, протоколы, и т. п.
Если так, то тогда такой вопрос для проверки. Допустим, я организовал бизнес-процессы в некоторой компании так, что имеется несколько сервисов, которые действительно независимы друг от друга и взаимодействуют через строго определенные интерфейсы. Но при этом, сами эти интерфейсы определены на IDL (а не на WSDL а в качестве протокола для взаимодействия сервисов используется CORBA (а не SOAP). Вопрос: является ли это SOA?
Да, это будет SOA.
имеется несколько сервисов, которые действительно независимы друг от друга и взаимодействуют через строго определенные интерфейсы
ну, если они взаимодействуют, то стого говоря они уже не независимы -)
скорее слабосвязаны.
Вопрос: является ли это SOA?
будет.
но многих такое представление решения запутало бы -)
потому что сразу идет ассоциация с Web Servieces / SOAP / XML
которые действительно независимы
в качестве протокола для взаимодействия сервисов используется CORBA (а не SOAP)"независимы" и "используется corba" - эти понятия друг другу противоречат.
представь, вдруг надо кому-то реализовать простенький сервис и добавить к твоей системе - который берет данные слева кидает на право.
каким образом и на чем этот сервис придеться реализовывать, если в качестве "протокола" используется corba?
например, vb/delphi/perl/php можно будет под это заюзать?
плюс soap в том, что он развязывает руки на техническом уровне, т.к. текст (xml-ник) можно обработать/сгенерировать на любом инструменте.
плюс soap в том, что он развязывает руки на техническом уровне, т.к. текст (xml-ник) можно обработать/сгенерировать на любом инструменте.Большинство языков также позвляют генерировать бинарные пакеты, особенно если их формат переносим и стандартизован.
SOA – это религия, созданная для CIO и финансовых директоров, измученных безумными расходами на (пере)интеграцию приложений и (пере)реализацию бизнес-процессов, а также постоянным отставанием развития IT от требований бизнеса. А мы – апостолы и проповедники этой новой религии. (c) шеф
Большинство языков также позвляют генерировать бинарные пакеты, особенно если их формат переносим и стандартизован.и сколько будет стоит полноценная поддержка этого бинарного стандарта?
плюс xml в том, что его можно поддержать частично.
если в xml-е лишнее поле не прочитать/сгенерить/пропустить, то все будет адекватно работать.
если в бинарном пакете сделать тоже самое, то все рухнет со страшным грохотом.
Я с ним практически не знаком, но подозреваю, что он проще, чем SOAP. Потому что к SOAP дохрена различных наворотов, несколько вариантов представления (RPC/document и encoded/literal все реализации WS попарно несовместимы.
Аргумент не принимается. В бинарном пакете его можно заполнить нулями. Что быстрее свалит сервер - отсутствие поля в xml или нулевое значение в бинарном пакете - неочевидно.
XML позволяет добавлять новые поля с сохранением совместимости. Не факт что это нужно в таком низкоуровневом протоколе как SOAP.
плюс xml в том, что его можно поддержать частично.
если в xml-е лишнее поле не прочитать/сгенерить/пропустить, то все будет адекватно работать.
если в бинарном пакете сделать тоже самое, то все рухнет со страшным грохотом.
Аргумент не принимается. В бинарном пакете его можно заполнить нулями. Что быстрее свалит сервер - отсутствие поля в xml или нулевое значение в бинарном пакете - неочевидно.
XML позволяет добавлять новые поля с сохранением совместимости. Не факт что это нужно в таком низкоуровневом протоколе как SOAP.
> Аргумент не принимается. В бинарном пакете его можно заполнить нулями
для этого надо прочитать документ до последней корки, для того чтобы знать, что эти поля, вообще, есть.
вот скажи сходу сколько байт надо заполнять нулями хотя бы в заголовке bmp?
вопрос на засыпку - за сколько ты напишешь генерацию пустого mp3 файла (бинарный формат) и пустой html(текстовый формат)?
вместо mp3/html можешь взять другие форматы jpg/wordml/http/avi и т.д.
ps
ты кстати, вообще, много сам руками написал разных генераторов/парсеров? а также восстановил (reverse engineering) протоколов?
я много - больше сотни точно, и скажу точно - с текстовыми форматами времени уходят на два порядка меньше.
маленькие примеры:
1. для того, чтобы начать работать с бинарным форматом надо сразу же написать вьювер этого формата, текстовый формат и без спец. вьювера нормально читается
2. простой разбор текстового формата можно сделать через regex, для бинарных форматов - такого распространенного инструмента нет.
3. для генерации полноценного парсера текстового формата можно описать грамматику, и дальше сгенерить парсер, для описания бинарных форматов - есть только ASN, который почти никто не держит
и т.д.
для этого надо прочитать документ до последней корки, для того чтобы знать, что эти поля, вообще, есть.
вот скажи сходу сколько байт надо заполнять нулями хотя бы в заголовке bmp?
вопрос на засыпку - за сколько ты напишешь генерацию пустого mp3 файла (бинарный формат) и пустой html(текстовый формат)?
вместо mp3/html можешь взять другие форматы jpg/wordml/http/avi и т.д.
ps
ты кстати, вообще, много сам руками написал разных генераторов/парсеров? а также восстановил (reverse engineering) протоколов?
я много - больше сотни точно, и скажу точно - с текстовыми форматами времени уходят на два порядка меньше.
маленькие примеры:
1. для того, чтобы начать работать с бинарным форматом надо сразу же написать вьювер этого формата, текстовый формат и без спец. вьювера нормально читается
2. простой разбор текстового формата можно сделать через regex, для бинарных форматов - такого распространенного инструмента нет.
3. для генерации полноценного парсера текстового формата можно описать грамматику, и дальше сгенерить парсер, для описания бинарных форматов - есть только ASN, который почти никто не держит
и т.д.
несколько вариантов представления (RPC/document и encoded/literal все реализации WS попарно несовместимы.для небольших решений - это не критично, берется готовый запрос/ответ и заменяется пара полей и все работает, если формат текстовый, и все падает если формат бинарный.
для этого надо прочитать документ до последней корки, для того чтобы знать, что эти поля, вообще, есть.Нет, вменямые стандарты содержат список полей в одной или двух таблицах. Впрочем, неважно. Программисты, не читающие спецификации, а также форматы, позволяющие себя реализовывать без ее прочтения - источник половины проблем с совместимостью.
вопрос на засыпку - за сколько ты напишешь генерацию пустого mp3 файла (бинарный формат) и пустой html(текстовый формат)?А за сколько ты напишешь веб-браузер и mp3-декодер ? Сложность формата обычно перевешивает любые неудобства от бинарности.
К тому же, SOAP/CORBA достаточно реализовать для каждого языка не более одного раза. Нет, вру, для SOAP сложность пропорциональна количеству других его реализаций
для небольших решений - это не критично, берется готовый запрос/ответ и заменяется пара полей и все работает, если формат текстовый, и все падает если формат бинарный.
напомню с чего мы начинали:
"независимы" и "используется corba" - эти понятия друг другу противоречат.
В случае независимых компонент (написанных разными организациями/подразделениями) заменой пары полей ты не отделаешься.
> В случае независимых компонент (написанных разными организациями/подразделениями) заменой пары полей ты не отделаешься.
ты смешиваешь два вида задач
1. сделать вчера следующую важную херовину без который не может жить "бизнес" прямо сейчас
2. сделать мега-инструмент, который все умеет
если речь идет про автоматизацию бизнеса, то 99% задач - это первый пункт, и эти задачи надо делать быстро без многомесячного погружения в документацию.
и эти задачи отлично делаются через замену пару полей, в том числе и силами ИТ-отдела самой компании.
когда же делается мега-инструмент, то там действительно всплывают задачи полноты, совместимости с другими мега-инструментами и т.д., но написание таких мега-инструментов - это отдельная и редкая задача.
ps
Модельный пример.
Есть допустим фабрика мороженого с развернутой ERP-ишной мега-системой, и вдруг руководству этой фабрики приспичило загрузить в эту мега-систему прогноз температуры наружного воздуха, который должен браться с сайта гидромедцентра.
При использовании Corba,в какую сумму и время ты оцениваешь разработку решения для данного примера?
soap-сервис для данной задачи пишется максимум за пару дней на любом языке даже человеком незнакомым с soap.
ps
кстати поддержку версионности (одновременнее использование нескольких версий формата) ты как себе представляешь при использовании бинарного формата?
ты смешиваешь два вида задач
1. сделать вчера следующую важную херовину без который не может жить "бизнес" прямо сейчас
2. сделать мега-инструмент, который все умеет
если речь идет про автоматизацию бизнеса, то 99% задач - это первый пункт, и эти задачи надо делать быстро без многомесячного погружения в документацию.
и эти задачи отлично делаются через замену пару полей, в том числе и силами ИТ-отдела самой компании.
когда же делается мега-инструмент, то там действительно всплывают задачи полноты, совместимости с другими мега-инструментами и т.д., но написание таких мега-инструментов - это отдельная и редкая задача.
ps
Модельный пример.
Есть допустим фабрика мороженого с развернутой ERP-ишной мега-системой, и вдруг руководству этой фабрики приспичило загрузить в эту мега-систему прогноз температуры наружного воздуха, который должен браться с сайта гидромедцентра.
При использовании Corba,в какую сумму и время ты оцениваешь разработку решения для данного примера?
soap-сервис для данной задачи пишется максимум за пару дней на любом языке даже человеком незнакомым с soap.
ps
кстати поддержку версионности (одновременнее использование нескольких версий формата) ты как себе представляешь при использовании бинарного формата?
и все падает если формат бинарный.Насколько я знаю, в CORBA есть спецификация на компоненты, которая поддерживает версионность (правда с реализацией как всегда проблемы). В J2EE такое тоже есть. Так что выбор бинарный/текстовый - ничего не решает. В XML тоже можно внести несовместимые изменения, например, переименовав тэги.
Если посмотришь на ZeroC.com, у них версионность поддерживается.
Я слышал мнение, что XML более читаемый. Достаточно прочесть листинг любого WSDL-файла, чтобы в этом засомневаться.
Оставить комментарий
Landstreicher
Я не очень слежу за новомодными веяниями. Например, в последнее время часто слышал слова типа WS, SOA, но как-то не обращал на них внимание.Однако, похоже все-таки придется с этим столкнуться. Краткое знакомство с SOA привело к ряду вопросов.
1) В чем суть SOA? В большинстве статей написана какая-то маркетинговая чушь. Хотелось бы услышать четкий ответ.
2) Я так понял (возможно это не правильно что SOA позиционируется для решения тех задач, для которых раньше предлагались CORBA, DCOM, XML-RPC и еще множество других технологий. Все эти технологии так и не нашли такого широкого применения, как изначально предполагалось. Правильно ли, что SOA - это просто очередная реинкарнация того же самого. Или в ней есть что-то принципиально новое?
3) На основании чего сейчас считается, что SOA позволит решить те проблемы, которые не могли ранее решить CORBA, DCOM и другие подобные технологии?
4) Насколько мне известно, реализации WS от разных производителей не совместимы друг с другом. Есть ли какие-то перспективы по улучшению ситуации или это считается в порядке вещей?
Убедительная просьба не флудить.