Внедрете персонализиран ESB с Java

Помислете за предприятие, в което имате разнородни приложения, евентуално доставени от различни екипи, които трябва да взаимодействат помежду си, но имат следните ограничения:

• Всяко приложение не е задължително изградено с помощта на една и съща технология и може да не говори с останалите, използвайки собствения си механизъм за извикване, например приложение J2EE и приложение .Net
• За предпочитане е всяко приложение да не трансформира заявките си във формата, разбираем за целевото приложение. Освен това предприятието има много приложения, които използват целевото приложение.
• Компонентите на услугата трябва да използват механизъм за извикване или заявка, който е естествен за тях. Например съществуващо приложение J2EE може да приема заявки само чрез Java Message Service (JMS).
• Предприятието се придвижва към архитектура, при която дадено приложение се отнася само до, едно, това, което знае и, второ, какво трябва да предаде като параметри, когато иска да получи услугите на друго приложение в рамките на предприятието.

Други ограничения може да изискват от вас да имате инфраструктура, която позволява на хетерогенните приложения да се интегрират безпроблемно, без да променят техния дизайн. Шина за корпоративно обслужване (ESB) е един от начините за реализиране на такава архитектура за интеграция на предприятието.

Въпреки че всяко предприятие вероятно ще създаде своя ESB по свой уникален начин, важно е да се има предвид гъвкавостта, когато се разглежда дефиницията на ESB. Няма фиксиран подход за изграждането му. Идеята е да има слой за свързване, който оптимизира взаимодействието между потребителите на услуги и доставчиците на услуги, който може да реагира на контекст, ориентиран към събития, съобщения или услуги.

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

Общи изисквания на ESB

Общите изисквания на ESB са и най-често използваните му функции:

1. Маршрутизация: ESB трябва да осигури ефективен и гъвкав механизъм за маршрутизиране.
2. Трансформация: Компонентът на услугата не трябва да знае формата на заявката на целевата услуга, който може да извика. Въз основа на заявителя и целта, ESB трябва да може да приложи подходящата трансформация към заявката, така че целта да я разбере.
3. Многопротоколен транспорт: Едно внедряване на ESB, което говори само за JMS или само за уеб услуги, не е от голяма стойност. Той трябва да бъде достатъчно разширяем, за да поддържа множество протоколи за съобщения в зависимост от нуждите на предприятието.
4. Сигурност: Ако е необходимо, ESB трябва да наложи удостоверяване и оторизация за достъп до различни компоненти на услугата.

Фигура 1 показва основните архитектурни компоненти на ESB. Той има три широки отделения:

1. Приемник: ESB разполага с различни интерфейси, позволяващи на клиентските приложения да изпращат съобщения до ESB. Например един сървлет може да получава HTTP заявките за ESB. В същото време може да имате MDB (управляван от съобщения боб), който слуша на дестинация JMS, където клиентските приложения могат да изпращат съобщения.
2. Ядро: Това е основната част от внедряването на ESB. Той се занимава с маршрутизация и трансформация и прилага сигурност. Обикновено той се състои от MDB, който получава входящите заявки и след това, въз основа на контекста на съобщението, прилага подходящата трансформация, маршрутизация и сигурност. Подробности за маршрутизация, транспорт, трансформация и информация за сигурността могат да бъдат посочени в XML документ (дискутиран скоро).
3. Диспечер: Всички манипулатори на изходящ транспорт попадат в тази част на ESB. Можете да включите произволен манипулатор на транспорт (имейл, факс, FTP и др.) В ESB.

Всички тези ESB части са слепени заедно от XML документ, който изброява всички маршрути, по които ESB работи. Различните транспортни манипулатори, трансформатори и политики за повторен опит и връзката им с различни маршрути са свързани чрез този XML документ.

ESBConfiguration.xml

Списъкът с XML ESBConfiguration.xml, който се появява по-долу, ни дава известна представа за работата на ESB. Основните елементи, които представляват интерес ESBConfiguration.xmlса следните:

1. Beans: Този елемент съдържа нула или повече Beanелементи.
2. Bean: Този елемент основно определя начина, по който създаваме и конфигурираме Beanклас. Той има следните атрибути:
   • name: Уникално име, което може да се използва за обозначаване на този боб.
   • className: Напълно квалифицирано име на класа боб.
   Всеки боб може да има нула или повече Propertyелементи като деца. Всеки Propertyелемент има атрибут, nameкойто го идентифицира, и дъщерен елемент от тип, Valueкойто съдържа стойността на свойството. Тези свойства всъщност са членове на класа в стил JavaBeans, които могат да конфигурират класа на bean.
3. RetryPolicies: Този елемент съдържа нула или повече RetryPolicyдеца.
4. RetryPolicy: Този елемент определя политиката за повторен опит за даден маршрут. Той има атрибут, nameкойто може да се използва за препращане към него. Той има два дъщерни елемента с име MaxRetriesи RetryInterval.
5. Route: Основният EsbConfigurationелемент може да съдържа нула или повече дъщерни елементи от този тип. Той по същество представлява маршрут за ESB. Той има следните атрибути:
   • name: Уникално име, което може да се използва за препращане към този маршрут.
   • retryPolicyRef: Препратка към политиката за повторен опит. Той трябва да съответства на атрибута на RetryPolicyелемента name.
   • transformerRef: Позоваване на боб, който представлява трансформатора. Той трябва да съответства на атрибута на Beanелемента name.
   Най Routeелемент може да има един или повече дъщерни елементи от тип TransportHandlerRef. Това дете основно сочи към боб, който представлява подходящ манипулатор на транспорта, който трябва да се използва за този маршрут, и името на публичния метод на този боб, който трябва да бъде извикан за изпращане на съобщението. По желание Routeелементът може да има едно DeadLetterDestinationдете, което сочи към друг маршрут, представляващ дестинация с мъртва буква.

Примерен XML документ EsbConfiguration.xml, се появява по-долу:

                              qcf-1   myCreditQueue     //www.tax.com/calc      file:///C:/temp/esb/transform/xsl/credit.xsl     file:///C:/temp/esb/transform/custom/configManager.properties      qcf-1   Redelivery.Queue     qcf-1   System.DL.Queue     qcf-1   System.Error.Queue     qcf-1   Redelivery.Request.Topic       10 100   10 500    

ESB поведение

В ESBConfiguration.xmlдокумента диктува поведението ни ESB е. На EsbRouterнатоварвания MDB този XML, от място в нейния ЕВРОВОК внедряване. Информацията, която съдържа, след това се организира в структура от данни, изобразена на Фигура 2 по-долу.

Най EsbRouterизползва тази информация (чрез EsbConfigManager), за да дешифрира подходящ маршрут, трансформацията, ако има такива, които да се прилагат, проверката на разрешение за сигурност и т.н. Най-важното е да се отбележи е начинът, по техниката на инжектиране, Зависимост, заедно с наследството, е била използвана за отделяне на различни функции (като многопротоколен транспорт на съобщения и трансформация на съобщения) на ESB, като по този начин тя може да бъде силно разширяема и адаптивна.

Както показва диаграмата на класа, два важни интерфейса са в дизайна на ESB: TransformHandlerи TransportHandler. Те ви позволяват да напишете конкретна реализация на трансформация и транспорт за пренасочени съобщения. След това тези класове на изпълнение могат да бъдат свързани с маршрутите чрез Beanелементи в EsbConfiguration. Например в примерния EsbConfiguration.xmlдокумент следната дефиниция на боб определя манипулатора на транспорта:

   myQCF   myCreditQueue   

След това този манипулатор на транспорт може да бъде посочен във Routeвъзел, като в него се вмъкне TransportHandlerдете по следния начин:

Забележка

Подходът, описан в тази статия, използва Java интерфейси за дефиниране на манипулаторите на транспорт и трансформация. По този начин всеки нов манипулатор ще трябва да внедри необходимия интерфейс, който може да изглежда натрапчив. Можете лесно да модифицирате EsbConfigManagerизползването на Dependency Injection за извикване на произволен метод от клас на изпълнение, като по този начин елиминирате необходимостта от внедряване на интерфейс. Но тъй като EsbRouterвинаги преминава javax.jms.Messageекземпляр, вашият клас за реализация на манипулатора трябва да използва типа javax.jms.Messageтака или иначе.