| Интеграция на приложения чрез Oracle SOA Suite |
| Сряда, 25 Април 2007 05:09 |
|
Разработчиците на приложения с опит знаят, че има няколко основни принципа за да завършат един проект успешно. Два от тях са да избягваме пренаписването на код, както и да се научим да използваме вече готов код където е възможно. На мениджърите на проекти често им се случва да чуват прословутата реплика от новобранеца в екипа : "Това по-лесно ще го напиша наново, отколкото да го оправя." Всеки мениджър с опит знае, как да постъпи в тази ситуация и как да пресече подобни желания още в зародиш, освен ако не иска половината време на екипа му да минава в извършването на една и съща работа отново и отново. За съжаление, подобна тенденция се наблюдава не само при разработката на нови приложения, но изобщо в сложните корпоративни архитектури, където се внедряват готови такива. Много често, вместо системите X,Y и Z да се интегрират, те просто се изхвърлят и се започва внедряването на нова система, която уж покрива функционалностите и на трите. Когато внедряването й приключи, се оказва че и тя трябва да се интегрира с оставащите системи в компанията и ситуацията отново е в начална фаза. Когато в поверената ни софтуерна инфраструктура започнат да се натрупват повече приложения и започнем да търсим подход за интеграция, трябва да подходим много внимателно. Колкото и да е интуитивно и лесно просто да свържем първите две системи, нуждаещи се от интеграция и да продължим с всяка следваща в последствие, трябва да избягваме тази практика. Така наречената интеграция "от точка до точка" може да звучи привлекателно, когато отговаряме за 3 системи, но съвсем няма да е така, когато броят на системите нарасне до 10. За да свържем n системи една с друга по този метод ще трябва да разработим n*(n-1)/2 връзки между тях. И ако за 3 системи броят на връзките да е приемлив (3*(3-1)/2 = 3), това съвсем няма да бъде така при 10 различни системи, където ще трябва да разработим и поддържаме 10*(10-1)/2 = 45 интеграционни механизма. Именно по тази причина софтуерните архитекти разработват различни методологии за интеграция, а тази която най-често цитират и чуваме да се споменава по различни конференции е SOA или Архитектура ориентирана към услугите (Service Oriented Architecture). Един от лидерите на пазара за платформи улесняващи интеграцията на приложенията чрез SOA и тяхното наблюдение и управление е Oracle. Не случайно представянето на най-новата версия на тяхната платформа Oracle SOA Suite 10g Release 3 бе обявено на Oracle Open World – най-голямото годишно събиране, организирано от компанията, което през октомври събра 41 000 участника. Преди обаче да се спрем на конкретното решение, нека кажем няколко думи за самата SOA методология. Какво е SOA Към момента в повечето компании различните отдели имат различни IT системи и приложения. Такъв тип информационни силози (приложения натрупали вертикално информацията, без интеграция по между си) правят създаването, управлението и промяната на бизнес процесите сложно. За справяне с този проблем бяха предложени различни решения като Message Oriented Middleware и Object Oriented Middleware. Иронията в случая е, че липсата на стандарти за транспортната среда, извикването и оркестрацията на процесите доведе до нова категория информационни силози – силози от middleware решения. Самата SOA не дефинира точен стандарт за комуникация между услугите. Достатъчно е просто да стъпим на някой от множеството такива. Принципно можем да използваме каквото сметнем за добре – RPC, DCOM, ORB и така нататък. Въпреки това, XML базираният стандарт за описване на уеб услуги - WSDL се налага все повече като стандарт в тази архитектура. Когато един клиент се свърже с дадена уеб услуга, той може да прочете нейният WSDL, за да разбере какви специфични функции предоставя тя, както и да получи описание на формата на данни, който услугата използва за комуникация. След това, клиентът може да използва отново XML базиран протокол (например SOAP), за да извика услугата, да й предаде параметри и да получи резултата от нейната работа. Като цяло концепцията не е нова. Още в миналото подобна инфраструктура се изгражда частично чрез използването на DCOM или CORBA. Предимствата, които SOA дава са увеличена продуктивност, преизползваемост на компонентите, автоматизация на бизнес процесите и намалени интеграционни разходи. Може би най-важното предимство, че така изградената архитектурата помага на информационните технологии да се приспособяват лесно и бързо към променящите се изисквания на бизнеса. SOA подходът ни позволява да “отключим” възможностите на различните системи, давайки ни възможност да създадем портфолио от услуги на бизнес ниво, които лесно се комбинират в цялостни бизнес процеси. SOA разчита на стандарти за дефиниция на интерфейси, дефиниция на процеси, обмен на съобщения, транспорт и т.н., за да позволи на всички услуги “да се разбират” и да се използват една друга. И така, какво ни трябва за да реализираме една пълнофункционална SOA архитектура в нашата организация? Преходът към SOA : От какво се нуждаем SOA дефинира използването на независими услуги и комбинирането им по такъв начин, че да отразява бизнес процесите в организацията. Основна част от концепцията е, че различните услуги комуникират по стандартен начин и могат да бъдат достъпвани без да е необходимо познаването на технологиите и платформите, които реализират самите услуги. Казано по-просто, ние сме клиенти на самата услуга, комуникираме чрез стандартен интерфейс с нея и не се интересуваме на какъв език е написана, върху каква платформа работи или къде физически се намира. Стъпвайки върху тази основа виждаме, че Service-oriented архитектурата е по същество колекция от услуги, които комуникират помежду си. Този тип комуникация може да бъде както прост обмен на данни, така и обща координация на по-сложни дейности. Нека видим от какво се нуждае една организация, за да реализира успешна Service-oriented архитектура.  Разработка на услугите Тъй като в основата на концепцията са услугите, то те са и първото място от което започваме. Трябва да си осигурим среда за разработка, чрез която лесно да разработваме стандартизирани уеб услуги. Тъй като самата SOA пропагандира стандарти, логичният избор е стъпването на стандартизираната и отворена J2EE платформа. Разбира се, от писането на код до превръщането му във уеб услуга трябва да извървим определения от стандартите път. По тази причина се нуждаем от инструмент, който максимално улеснява работата ни в това направление. Самото превръщане на Java кода в уеб услуга е свързано с някои допълнителни манипулации и създаването на контролна информация за контейнерът, в който ще работят нашите услуги. Колкото повече от тази работа може да ни спести средата за разработка, толкова по-добре. Един добър инструмент трябва да има вградени средства, които на базата на нашия код автоматично да генерират нужните файлове и контролни структури. Можем да се замислим и дали в някои случай няма да е по-лесно да използваме вече съществуващи бизнес логики, вместо да разработваме наличното отново. Ако средата предоставя адаптери за "обвиването" на вече наличен код и превръщането му в уеб услуги, това ще ни спести много. Сервизна шина Съгласно SOA методологията, отделните услуги работещи в нашата архитектура са "слабо свързани". Това означава, че те са максимално независими и най-често работят върху различни хардуерни платформи. Въпреки това, услугите трябва да комуникират една с друга. Трябва да внедрим някакъв тип преносна среда, за която можем да "закачаме" отделните услуги и приложения. Именно такава е целта и на сервизната шина. Един такъв компонент представлява комуникационна магистрала, която обслужва информационния обмен между различните системи. Въпреки, че сервизната шина обикновено се разглежда единствено като транспортен механизъм, тя може да има и по-интелигентно поведение. Добре ще бъде, ако тя поддържа интелигентно маршрутизиране на данните между различните участници в комуникационния процес, вместо да разпраща всичко към всички. Ако сервизната шина поддържа и дефиницията на някакви базови правила (например ако стойността на дадено поле в съобщението съдържа определена стойност, то съобщението се предава към система X, ако ли не – към система Y), то тя може да ни улесни още повече. Друго изискване, което е добре да имаме предвид е възможността системната шина да ни предоставя начин за наблюдение на вървящата по нея информация. Добре ще е да знаем скоростта на обмен на съобщения, времето за реакция на различните получатели на съобщения, цялостното време за протичане на един по-сложен процес и т.н., с цел лесно да идентифицираме тесни места в нашата транспортна инфраструктура и да внасяме нужните поправки навреме. Наличието на някакъв механизъм за сигурност, който да не позволява произволен достъп до системите закачени за шината също е желателен и може да ни спести много работа не само по време на внедряването на архитектурата, но и при ежедневното й поддържане в последствие. Управление на процесите След като нужните услуги са разработени и заедно със съществуващите приложения са закачени към шината, следващото за което трябва да се погрижим е да намерим система, която ще ни позволи лесно да представим и опишем нашите бизнес процеси чрез наличните услуги върху шината. Един успешен инструмент за управление и контрол на процесите (терминът "оркестрация на процесите" все повече се налага в този контекст) трябва да може безпроблемно да комуникира със сервизната шина. Той трябва да "вижда" всички услуги разположени върху нея и да може да ги извиква в определения от нас ред. Заедно с това, един такъв инструмент трябва да ни предостави възможност за вкарване на много по-сложна бизнес логика между извикването на отделните услуги. Ако една банка например има услуга за проверка на платежоспособност, кредитен рейтинг и текущ банков лихвен процент, използвайки оркестрация на процесите тя може да разработи собствен бизнес процес (например "оферта за кредит"), който не само интелигентно използва данните от тези услуги, но и конструира оферти чрез сложна бизнес логика изградена върху простите данни от услугите. За да е успешен нашия проект, трябва да поставим няколко предварителни изисквания. Първо, резултатът от описанието на бизнес процесите ни трябва да бъде в някакъв стандарт. Не е добре да разработим всичките си процеси в някакъв собственически формат, който ще ни "заключи" към конкретна платформа. Ако евентуално решим да я сменим за в бъдеще, ще сме изправени пред проблема за повторното създаване на вече направените услуги от нула. Големите доставчици на подобни решения като IBM, Microsoft и др. вече са разработили стандартен език за описание на бизнес процеси (BPEL). Трябва да сме сигурни, че инструмента който избираме го спазва. Второто за което е добре да внимаваме е дали инструментът който използваме е визуален и не изисква наличието на дълбоки познания по програмиране. Ако можем да описваме нашите процеси абстрактно, без да се интересуваме от техните инфраструктурни аспекти можем да сме сигурни, че няма да имаме проблеми с поддръжката за в бъдеще, а също така ще можем и директно да замесим бизнес потребителите в дизайна на процесите. Този подход е много по-успешен, отколкото опитите да ни обяснят какво точно искат, а ние да се мъчим да го програмираме със стандартни средства. Потребителски слой След като разработим някои от процесите си на базата на стандартизираните услуги, трябва да помислим за механизъм за тяхното използване. Ако тези процеси се извикват от други приложения и/или други процеси, то ще разчитаме на стандарти. Ако обаче очакваме с тях да взаимодействат крайни потребители, добре ще е да помислим за предоставянето на подходящ интерфейс към тези процеси. Също така, възможно е в самите процеси да има намесен човешки фактор (например при изискване за финално одобрение на сделка от страна на служител). Тогава пак трябва да помислим за технология, чрез която можем да внедрим човешки фактор в автоматизираните ни процеси. Тъй като в съвременните архитектури почти всички интерфейси се ориентират към уеб приложенията, наличието на портално решение, което да предоставя лесна интеграция с нашите процеси е задължително изискване. Наличието на добра портална система може да ни прати още по-напред. Ние можем да разрешим на наши крайни клиенти да си взаимодействат с наши бизнес процеси (например автоматично подаване на заявление за банков кредит, плащане на данък и др). Тъй като още в началото ние ориентирахме нашата архитектура към J2EE, добре ще е да се огледаме за портално решение работещо върху J2EE платформата и поддържащо нейните стандарти (например портлетната спецификация JSR-168). Наличието на готови компоненти за наблюдение и намеса в процесите също е огромен плюс. Например, ако порталното решение е добре интегрирано със слоят, който се грижи за управление на процесите, то може да има в себе си готови портлети за взаимодействие с процесите през интерфейса на портала. Защита на услугите Тъй като процесите в организацията ще разчитат на слабо-свързаните услуги, то най-вероятно ще имаме голям брой услуги достъпни във вътрешната ни мрежа. Добре е да помислим за защитата на тези услуги, тъй като надали бихме искали всеки един служител да може чрез стандартен интерфейс да извика дадена услуга и тя да му отговори с информация, без той да има право на достъп до тази информация. В защитата на услугите се използват различни техники, като най-популярни методи са използването на агенти при клиента и доставчика на услугата, които могат да идентифицират и оторизират потребителя или пък използването на прокси, което да изисква идентификация от страна на потребителя при опит за достъп до услуга. Същественото предимство в двата случая е, че сигурността е отделена от самите услуги. Ако в последствие създадем нова версия на услугите, няма да се наложи да вграждаме в тях политики на сигурност. Обратното също е вярно – ако сменим политиката на сигурност, няма да има нужда да внасяме поправки в услуги. По този начин се постига добро разделение на бизнес логиката от сигурността, а ясното разделяне на функционалните области е нещо, което винаги е полезно при големите проекти. Какво предлага Oracle Пакетът, който Oracle предлага за цялостното изграждане и поддръжка на SOA се нарича Oracle SOA Suite 10g.  Компоненти на Oracle SOA Suite 10g За фазата свързана с разработката на услугите, Oracle SOA включва Oracle JDeveloper 10g. JDeveloper 10g е базираната на стандарти интегрирана среда за разработка, която включва и J2EE фреймуърка Oracle ADF (Application Development Framework). Основната задача, поставена пред JDeveloper е той да бъде единен инструмент за дизайн в платформата на Oracle и целия J2EE спектър от технологии. Затова той поддържа J2EE, XML, Oracle Portal, BPEL, Oracle Wireless и редица други продукти и технологии. Самият процес на разработка също може да бъде изпълнен в няколко аспекта. Наред със стандартното писане на код, могат да се използват и наличните инструменти за декларативна разработка, UML моделиране, дизайн на бази данни и други. JDeveloper позволява разполагане на приложения не само върху Oracle, но също така и върху BEA WebLogic, IBM WebSphere, JBoss и др. Казано по друг начин - той се адаптира към средата, в която го използваме. Ролята на сервизна шина в SOA Suite 10g е поверена на Oracle Enterprise Service Bus (ESB). Отново ориентиран към стандартите, този инфраструктурен компонент е основният интегратор между слабо свързаните услуги. ESB е бърз, сигурен и с висока надеждност. Той се явява основният транспортен механизъм в комуникацията на SOA. ESB притежава многопротоколна шина за съобщения с централизирано управление и наблюдение. В шината всички услуги се виждат като стандартни уеб услуги чрез WSDL. В ESB съществуват адаптери за управление на потока от съобщения, трансформация и маршрутизиращи правила за правилно пренасочване и обслужване на данните както в рамките на компанията, така и извън нея. Тъй като самата интеграция на наличните системи в компанията включва технологии и приложения на трети страни, Oracle предоставя над 300 готови адаптера за свързване с подобни системи, които могат да се използват от страна на ESB. Те осигуряват връзка както и към системи използващи стандартни протоколи (FTP, JMS, HTTP), както и към затворени системи, които комуникират по специфичен начин (SAP, PeopleSoft, J.D. Edwards). По този начин се спестява писането на специализиран код, както и времето за пускане на услуги в шина се съкращава драстично. Oracle BPEL Process Manager (BMP) е двигателят, който позволява моделирането, автоматизацията и наблюдението на бизнес процеси. За разлика от по-разпространените технологии, които автоматизират процеси чрез генериране на изпълним код, BPM включва вграден BPEL (Business Process Execution Language) двигател, който се грижи за изпълнението на процесите. Този подход, освен че подобрява преизползваемостта, позволява да наблюдаваме изпълнението и състоянието на процеса във всяка негова стъпка. Процесите в Oracle BPEL Process Manager се описват чрез BPEL стандарта, което автоматично позволява те да се пренасят и изпълняват върху други BPEL двигатели. Освен, че изключва възможността за "заключване" на потребителя върху една платформа, както би се случило ако се използва собствен метод за описание на процеса, поддръжката на редица останали стандарти като XML, XSLT, XPATH, JMS, JCA и разбира се уеб услугите като цяло, гарантират пълната преносимост на всеки един процес или негова част. Друга интересна възможност, която е включена в пакета е единната система за сигурност, управление и наблюдение, която може да се приложи върху всички услуги и процеси. Той се нарича Web Services Manager и реализира контрол на достъпа както чрез агенти, така и работейки в режим на интелигентно прокси. Политиките на сигурност и управление могат да се променят без това да влияе на услугите и процесите, в които те участват. В допълнение активността на бизнес процесите може да бъде наблюдавана в реално време, чрез Business Activity Monitoring(BAM).  BAM предоставя данни за изпълнението на процесите в организацията в реално време По отношение на презентационния слой, можем да използваме Oracle Portal 10g, който е тясно интегриран със SOA Suite. В комбинация, двете решения могат както да представят данни за поведението на цялата инфраструктура (от гледна точка на сигурността и производителността), така и Oracle Portal да служи за входна точка на потребителите, които могат да задействат различни процеси направо в портала и да следят тяхното изпълнение, чрез готовите портални интеграционни компоненти за SOA Suite. За финал е добре да обърнем внимание, че Oracle SOA Suite 10g е достъпен в две редакции. Първата включва в себе си и Oracle Application Server 10g, който играе ролята на основна платформа, върху която работят отделните компоненти на SOA Suite. Другата редакция се нарича Oracle SOA Suite for Non-Oracle Middleware и предоставя компонентите в пакет, проектиран да работи върху други приложени сървъри, например IBM WebSphere, JBoss и др. Какво казва бизнесът Водещите анализатори предсказват значителни инвестиции от страна на компаниите в технологии свързани със SOA. Пазарът на свързаните със SOA IT услуги е величина по-голяма от пазара на IT инструменти и технологии взети задно. Според IDC до края на 2008 г. за уеб услуги SOA-ориентирани бизнес приложения ще бъдат изхарчени 11 милиарда долара. Research & Markets предричат 17 милиарда до края на 2011 г., а според Gartner цялостния пазар на IT услугите и приложенията свързани със SOA ще достигне 153 милиарда долара до края на 2008 г., като 80% от всички новоразработени IT проекти ще бъдат базирани на SOA. |
Коментари