BPEL: Състав на услугата за SOA

BPEL (език за изпълнение на бизнес процеси) се превърна в една от най-важните технологии на SOA (ориентирана към услугите архитектура) и позволява лесно и гъвкаво съставяне на услугите в бизнес процеси. BPEL е особено важен, тъй като той въвежда нова концепция в разработването на приложения - програмиране като цяло. Тази концепция ни позволява бързо да разработваме процеси, като определяме реда, в който ще бъдат извикани услугите. По този начин приложенията (и информационните системи) стават по-гъвкави и могат да се адаптират по-добре към промените в бизнес процесите.

Бизнес процесите обикновено имат динамичен характер. Компаниите трябва да подобряват и модифицират, да действат гъвкаво, да оптимизират и адаптират процесите, за да подобрят отзивчивостта на цялата компания. Всяка промяна и подобрение в бизнес процеса трябва да се отрази в приложения, които осигуряват подкрепа за тях. Въпреки че това изискване може да не звучи много трудно за изпълнение, ситуацията в реалния свят ни показва различна картина. Смяната и модификацията на приложения често е трудна работа, която изисква време. Следователно приложенията не могат да реагират незабавно на промени в бизнес процесите - по-скоро те изискват известно време за внедряване, тестване и внедряване на модификациите.

Постигането на информационните системи по-гъвкави и приспособими към промените и по-добре приведени в съответствие с бизнес процесите е основното обещание на SOA. В тази статия показвам защо BPEL е толкова важен и демонстрирам как да се разработи BPEL процес.

Подход, ориентиран към услугата

Подходът SOA за ефективна автоматизация на бизнес процесите изисква:

  • Стандартизиран начин за излагане и достъп до функционалността на приложенията като услуги
  • Инфраструктура на корпоративната шина за комуникация и управление на услуги, включително прихващане на съобщения, маршрутизация, трансформация и др.
  • Специализиран език за композиране на изложени функционалности на приложения в бизнес процеси

Първото изискване е изпълнено от най-новата разпределена архитектура - уеб услуги. Второто изискване е изпълнено от ESB (корпоративна сервизна шина), която осигурява поддръжка за централизирано, декларативно и добре координирано управление на услугите и техните комуникации. Третото изискване, състав на услугите в процеси, се изпълнява от BPEL, общоприетия специализиран език за дефиниране и изпълнение на бизнес процеси.

Бизнес процесът, както се вижда от BPEL, представлява съвкупност от координирани извиквания за услуги и свързани дейности, които дават резултат или в рамките на една организация, или в няколко. Например, бизнес процес за планиране на бизнес пътувания ще извика няколко услуги. В опростен сценарий бизнес процесът ще изисква да посочим името на служителя, дестинацията, датите и други подробности за пътуването. След това процесът ще извика уеб услуга, за да провери състоянието на служителя. Въз основа на статута на служител, той ще избере подходящия клас на пътуване. След това ще извика уеб услуги на няколко авиокомпании (като American Airlines, Delta Airlines и др.), За да провери цената на самолетните билети и да купи тази с най-ниска цена.

За клиентите процесът BPEL ще изложи своята функционалност по същия начин като всяка друга уеб услуга. От гледна точка на клиента тя ще изглежда точно като всяка друга уеб услуга. Това е важно и полезно, тъй като ни позволява да съставяме услугите в прости процеси, простите процеси в по-сложни процеси и т.н. Това също означава, че всеки BPEL процес ще бъде описан с описание на WSDL (език за описание на уеб услуги).

Основни понятия

BPEL е език, базиран на XML. Процесът BPEL се състои от стъпки. Всяка стъпка се нарича дейност. BPEL поддържа примитивни и структурни дейности. Примитивните дейности представляват основни конструкции и се използват за общи задачи, като изброените по-долу:

  • Извикване на уеб услуги, използване
  • Изчакваме заявката, използвайки
  • Манипулиране на променливи с данни, като се използва
  • Посочване на грешки и изключения, използване и т.н.

След това можем да комбинираме тези дейности в по-сложни алгоритми, които определят стъпките на бизнес процеса. За да комбинира примитивни дейности, BPEL поддържа няколко структурни дейности. Най-важните са:

  • Sequence ( ) за определяне на набор от дейности, които ще бъдат извикани в подредена последователност
  • Flow ( ) за определяне на набор от дейности, които ще бъдат извикани паралелно
  • Конструкция на случай-превключвател ( ) за изпълнение на клонове
  • While ( ) за дефиниране на цикли и т.н.

Както ще видим, BPEL не е толкова различен от програмните езици като Java. Но ще видим, че BPEL се различава от Java и поддържа характеристиките на бизнес процесите. BPEL също така предоставя манипулатори на грешки и компенсации, манипулатори на събития и набори за корелация. Той предоставя средства за изразяване на сложни паралелни потоци. Също така улеснява извикването на асинхронни операции и изчакването на обратно извикване.

BPEL процесите изискват среда за изпълнение - BPEL сървър, който ни дава добър контрол върху тяхното изпълнение. Обикновено BPEL сървърите осигуряват контрол върху екземплярите на процесите, които се изпълняват, и тези, които са завършили. Те поддържат продължителни процеси и могат да дехидратират състоянието на процеса, за да спестят ресурси. Някои сървъри осигуряват контрол върху дейностите на процеса и позволяват тяхното наблюдение. И накрая, използвайки BPEL сървър, всички наши процеси се разгръщат централно, което опростява поддръжката. Всичко това прави BPEL сървъра предпочитаната среда за стартиране и управление на процеси.

Изборът на правилния BPEL сървър обаче може да бъде доста труден, тъй като има няколко възможности за избор. Някои от най-популярните BPEL сървъри, базирани на Java EE (новото име на Sun за J2EE), включват Oracle BPEL Process Manager, IBM WebSphere Business Integration Server Foundation, BEA WebLogic Integration и AquaLogic. Налични са и поне четири BPEL сървъра с отворен код: ActiveBPEL Engine, FiveSight PXE, bexee и Apache Agila.

Примерен процес

Нека сега разгледаме примерния BPEL процес за бизнес пътувания, който описахме по-горе. Ще разработим асинхронен процес, който ще използва синхронно обаждане за проверка на състоянието на пътуването на служителя и две асинхронни обаждания за получаване на цените на самолетните билети. Фигурата по-долу показва цялостната структура на нашия процес. Вляво виждаме клиента, който извиква процеса. Процесът първо извиква уеб услугата за състоянието на пътуването на служителя. Тогава той извиква едновременно и асинхронно уеб услугите на двете авиокомпании. Това означава, че процесът ще трябва да приложи операцията за обратно извикване (и тип порт), чрез която авиокомпаниите ще върнат потвърждението на полетния билет. И накрая, процесът връща на клиента най-доброто предложение за самолетни билети. В този пример, за да запазим простотата, няма да приложим никакви обработки на грешки,което е от решаващо значение в реалните сценарии.

Нека сега напишем BPEL кода. Започваме с декларацията на процеса - основния елемент, където дефинираме името на процеса и пространствата от имена:

След това трябва да дефинираме партньорските връзки. Партньорските връзки определят различни страни, които взаимодействат с процеса BPEL. Това включва всички уеб услуги, които ще бъдат извикани, и клиента на процеса. Всяка партньорска връзка посочва до два атрибута: myRoleтова показва ролята на самия бизнес процес и partnerRoleтова показва ролята на партньора. В нашия пример дефинираме четири партньорски връзки:

За да съхраняваме съобщения и да ги преформатираме и трансформираме, имаме нужда от променливи. Обикновено използваме променлива за всяко съобщение, изпратено до уеб услугите и получено от тях. В нашия пример ще ни трябват няколко променливи. За всяка променлива трябва да посочим типа. Можем да използваме WSDL тип съобщение, прост тип XML Schema или елемент XML Schema. В нашия пример използваме WSDL типове съобщения за всички променливи:

Сега сме готови да напишем основното тяло на процеса. Съдържа само една дейност от най-високо ниво. Обикновено това е , което ни позволява да дефинираме няколко дейности, които ще се извършват последователно. В рамките на последователността първо указваме входното съобщение, което стартира бизнес процеса. Правим това с конструкцията, която чака съответстващото съобщение. В нашия случай това е TravelRequestсъобщението. В рамките на конструкцията не посочваме съобщението директно. По-скоро посочваме партньорската връзка, типа на порта, името на операцията и по желание променливата, която съдържа полученото съобщение за последващи операции. Свързваме приемането на съобщения с клиентския партньор и изчакваме TravelApprovalоперацията да бъде извикана за тип порт TravelApprovalPT. Съхраняваме полученото съобщение вTravelRequest променлива:

След това трябва да извикаме уеб услугата за състояние на пътуване на служител. Преди това трябва да подготвим данните за тази уеб услуга. Можем да изградим такова съобщение, като копираме частта от съобщението на служителя, изпратена от клиента. Сега можем да извикаме уеб услугата за състояние на пътуване на служител. Правим синхронно извикване, за което използваме активността. Използваме employeeTravelStatusпартньорската връзка и извикваме EmployeeTravelStatusоперацията за типа EmployeeTravelStatusPTпорт. Подготвили сме входното съобщение в EmployeeTravelStatusRequestпроменливата. Тъй като това е синхронно извикване, повикването изчаква отговора и го съхранява в EmployeeTravelStatusResponseпроменливата:

Следващата стъпка е да извикате и двете уеб услуги на авиокомпанията. Отново подготвяме първо необходимото входно съобщение (което е равно на двете уеб услуги). Ще правим едновременни асинхронни извиквания. За да изрази съвпадение, BPEL предоставя дейността. Извикването към всяка уеб услуга ще се състои от две стъпки:

  1. На активност се използва за асинхронно позоваването
  2. В дейността се използва да се изчака за обратно извикване

Използваме да групираме и двете дейности. Двете извиквания се различават само в името на партньорската връзка. Използваме AmericanAirlinesза едното и DeltaAirlinesза другото:

...