Здравствуйте, Nikolay_Ch, Вы писали:
N_C>А как оба варианта организуются технически? Есть где почитать подробнее?
Прямо конкретную литературу я, наверное, не назову...
Если же описать на пальцах, то получится примерно так.
Сhoreography
Каких-то специальных решений я не видел, и, подозреваю, их нет. По большому счету, всё делается путем вызова одних сервисов их других, причем это может быть вызов в режиме Request-Replay, а может быть через передачу сообщения.
В первом случае получается этакое дерево вызовов, где каждый "вышележащий" сервис ждет завершения всех своих дочерних сервисов.
Во втором, как уже писали коллеги, каждый сервис использует входящий endpoint в виде очереди сообщений, которую и разгребает потихоньку, при этом формируя сообщения для других.
Собственно, техническая часть — это протоколы самих сервисов, в первую очередь SOAP (т.к. он поддерживает как режим Request-Replay, так и передачу в очередях сообщений), фреймворки для создания Web Services, а также очереди сообщений.
На самом деле была даже попытка создать некий стандарт для описания хореографий
Web Services Choreography Description Language (WS-CDL), который, как я понимаю, так и не дошел до релиза и в народ не пошел тоже.
Orchestration
Вот здесь всё куда интереснее.
Дело в том, что идея очень здорово пересеклась с популярными в 2005-2010 годах концепциями процессного управления (Business process management, BPM) и сервисного подхода в организации (Service-oriented architecture, SOA).
Эти концепции попытались перенести и в IT. Т.е. идея, по сути была в том, что:
У нас есть ряд систем, каждая из которых решает свою задачу (разной степени широты или узости).
Вместо того, чтобы делать тысячи интеграций каждой пары систем или пытаться заменить все системы одним большим монстром, мы делаем из каждой системы сервис с фиксированным интерфейсом (не обязательно это Web Service или очередь сообщений — может и обмен файликами или пересылка данных через таблицу БД).
В центре же у нас стоит специальный сервер, задача которого организация процессов, которые соединяют множество систем. Например, процесс приема нового сотрудника инициируется из системы работы с кандидатами, проходит через кадровый учет, бухгалтерию и отдел безопасности, а если человек пришел с госслужбы, то должна сработать отдельная ветка, где пойдет задача, например HR-ам, уведомить госорганы, что человек у нас начал работу.
В результате образовался целый класс систем для работы с BP.
Там есть достаточно большая терминологическая путаница, но можно с большой долей вероятности утверждать, что BPMS (Business Process Management Systems) и ESB (Enterprise Service Bus) — суть одно и то же.
Такая система обычно включает в себя:
Инструменты для описания бизнес-процессов. Это как правило графическая рисовалка на базе одной из распространенных нотаций
Инструментария разработчика (редко когда всё можно было чисто мышкой нарисовать)
Движка исполнения процесса (чаще всего его называют BPM Engine или Workflow Engine)
Коннекторов к разным системам и/или протоколом, от универсальных (типа email, web service, database, flat file, ...) до специализированных типа коннектора к 1C и SAP.
Инструментов мониторинга и анализа (чтобы понимать, где узкие места)
Иногда еще отдельно называют UI для конечных пользователей (типа система назначенных заданий), но чаще это делает через что-то стороннее — например задания выдаются письмами.
Конкретные системы, которые можно назвать: IBM WebSphere ESB, TIBCO, Vitria, Oracle Enterprise Service Bus, Microsoft BizTalk, OpenESB, ... В большинстве своем они достаточно монструозны и дороги.
Что касается средств описания и разработки...
Тут тоже полно всего (у многих систем долгое время была своя нотация, у некоторых она так и осталась своя ...) но из всего это я бы выделил 2 стандарта:
Первый это язык описания процессов в виде диаграмм.
Он включает в себя и сами диаграммы и формат для их хранения и передачи. Диаграммы выглядят примерно так:
| BPMN диагармма |
| |
| |
Второй — это XML язык, который в декларативной форме описывает выполнение процесса. Он, например, позволяет:
Описывать поток управления (последовательно, ветвления, циклы)
Описывать вызовы веб-сервисов
Описывать некие преобразования информации, которые происходят внутри (там можно и переменные объявить, и действия над ними сделать и потом результат отдать сервису и получить ответ)
Т.е. вообще это чистой воды язык для оркестровки.
| Выглядит примерно так |
| <?xml version="1.0" encoding="utf-8"?>
<!-- Asynchrnous BPEL process -->
<process name="BusinessTravelProcess"
targetNamespace="http://packtpub.com/bpel/travel/"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:trv="http://packtpub.com/bpel/travel/"
xmlns:emp="http://packtpub.com/service/employee/"
xmlns:aln="http://packtpub.com/service/airline/" >
<partnerLinks>
<partnerLink name="client"
partnerLinkType="trv:travelLT"
myRole="travelService"
partnerRole="travelServiceCustomer"/>
<partnerLink name="employeeTravelStatus"
partnerLinkType="emp:employeeLT"
partnerRole="employeeTravelStatusService"/>
<partnerLink name="AmericanAirlines"
partnerLinkType="aln:flightLT"
myRole="airlineCustomer"
partnerRole="airlineService"/>
<partnerLink name="DeltaAirlines"
partnerLinkType="aln:flightLT"
myRole="airlineCustomer"
partnerRole="airlineService"/>
</partnerLinks>
<variables>
<!-- input for this process -->
<variable name="TravelRequest" messageType="trv:TravelRequestMessage"/>
<!-- input for the Employee Travel Status web service -->
<variable name="EmployeeTravelStatusRequest" messageType="emp:EmployeeTravelStatusRequestMessage"/>
<!-- output from the Employee Travel Status web service -->
<variable name="EmployeeTravelStatusResponse" messageType="emp:EmployeeTravelStatusResponseMessage"/>
<!-- input for American and Delta web services -->
<variable name="FlightDetails" messageType="aln:FlightTicketRequestMessage"/>
<!-- output from American Airlines -->
<variable name="FlightResponseAA" messageType="aln:TravelResponseMessage"/>
<!-- output from Delta Airlines -->
<variable name="FlightResponseDA" messageType="aln:TravelResponseMessage"/>
<!-- output from BPEL process -->
<variable name="TravelResponse" messageType="aln:TravelResponseMessage"/>
</variables>
<sequence>
<!-- Receive the initial request for business travel from client -->
<receive partnerLink="client"
portType="trv:TravelApprovalPT"
operation="TravelApproval"
variable="TravelRequest"
createInstance="yes" />
<!-- Prepare the input for the Employee Travel Status Web Service -->
<assign>
<copy>
<from variable="TravelRequest" part="employee"/>
<to variable="EmployeeTravelStatusRequest" part="employee"/>
</copy>
</assign>
<!-- Synchronously invoke the Employee Travel Status Web Service -->
<invoke partnerLink="employeeTravelStatus"
portType="emp:EmployeeTravelStatusPT"
operation="EmployeeTravelStatus"
inputVariable="EmployeeTravelStatusRequest"
outputVariable="EmployeeTravelStatusResponse" />
<!-- Prepare the input for AA and DA -->
<assign>
<copy>
<from variable="TravelRequest" part="flightData"/>
<to variable="FlightDetails" part="flightData"/>
</copy>
<copy>
<from variable="EmployeeTravelStatusResponse" part="travelClass"/>
<to variable="FlightDetails" part="travelClass"/>
</copy>
</assign>
<!-- Make a concurrent invocation to AA in DA -->
<flow>
<sequence>
<!-- Async invoke of the AA web service and wait for the callback -->
<invoke partnerLink="AmericanAirlines"
portType="aln:FlightAvailabilityPT"
operation="FlightAvailability"
inputVariable="FlightDetails" />
<receive partnerLink="AmericanAirlines"
portType="aln:FlightCallbackPT"
operation="FlightTicketCallback"
variable="FlightResponseAA" />
</sequence>
<sequence>
<!-- Async invoke of the DA web service and wait for the callback -->
<invoke partnerLink="DeltaAirlines"
portType="aln:FlightAvailabilityPT"
operation="FlightAvailability"
inputVariable="FlightDetails" />
<receive partnerLink="DeltaAirlines"
portType="aln:FlightCallbackPT"
operation="FlightTicketCallback"
variable="FlightResponseDA" />
</sequence>
</flow>
<!-- Select the best offer and construct the TravelResponse -->
<switch>
<case condition="bpws:getVariableData('FlightResponseAA','confirmationData','/confirmationData/aln:Price')
<= bpws:getVariableData('FlightResponseDA','confirmationData','/confirmationData/aln:Price')">
<!-- Select American Airlines -->
<assign>
<copy>
<from variable="FlightResponseAA" />
<to variable="TravelResponse" />
</copy>
</assign>
</case>
<otherwise>
<!-- Select Delta Airlines -->
<assign>
<copy>
<from variable="FlightResponseDA" />
<to variable="TravelResponse" />
</copy>
</assign>
</otherwise>
</switch>
<!-- Make a callback to the client -->
<invoke partnerLink="client"
portType="trv:ClientCallbackPT"
operation="ClientCallback"
inputVariable="TravelResponse" />
</sequence>
</process>
|
| |
Что на сегодня
Мое глубоко личное мнение: в том виде как описано выше, системы BPMS не прижились. ESB я в основном встречал в банках. Ну и более-менее их подходы сейчас есть в российских системах документооборота. Правда там в основном они используются чисто как Workflow движок, который используется для процессов внутри системы, а оркестровка внешних — чисто в дополнение.
Однако, полностью от идеи оркестровки вендоры отказаться не могут и время от времени появляются более легковесные решения типа
Azure Logic Apps или
Microsoft Flow
Также большой вопрос по чисто программистским инструментам. В том же .Net выход Windows Workflow Foundation практически напрочь уничтожил конкурентов, но сам WF... ну не то чтобы приказал долго жить, но практически встал в развитии.