Programování

Implementujte přizpůsobitelný ESB s Javou

Zvažte podnik, ve kterém máte heterogenní aplikace, případně dodávané různými týmy, které potřebují vzájemně komunikovat, ale mají následující omezení:

  • Každá aplikace nemusí být nutně vytvořena pomocí stejné technologie a nemusí komunikovat s ostatními pomocí svého nativního vyvolávacího mechanismu, např. Aplikace J2EE a aplikace .Net.
  • Výhodně by každá aplikace neměla transformovat své požadavky do formátu srozumitelného cílové aplikaci. Navíc má podnik mnoho aplikací, které používají cílovou aplikaci.
  • Součásti služby by měly používat mechanismus vyvolání nebo požadavku, který je pro ně přirozený. Například stávající aplikace J2EE může přijímat požadavky pouze prostřednictvím služby Java Message Service (JMS).
  • Podnik směřuje k architektuře, kde se aplikace týká pouze jedné, toho, co ví, a dvou, čeho by měla předávat jako parametry, když chce v rámci podniku získat služby jiné aplikace.

Další omezení mohou vyžadovat, abyste měli infrastrukturu, která umožňuje heterogenním aplikacím bezproblémovou integraci beze změny jejich designu. Enterprise service bus (ESB) je jedním ze způsobů realizace takové architektury podnikové integrace.

Ačkoli každý podnik pravděpodobně vytvoří svůj ESB svým vlastním jedinečným způsobem, je důležité mít na paměti flexibilitu při zvažování definice ESB. Neexistuje žádný pevný přístup k jeho vybudování. Cílem je mít vrstvu připojení, která optimalizuje interakce mezi spotřebiteli služeb a poskytovateli služeb, takovou, která může reagovat na kontexty orientované na události, zprávy nebo služby.

Tento článek pojednává o přístupu k vytváření rozšiřitelného ESB založeného na prostředí Java, který podporuje nejběžnější funkční požadavky ESB.

Společné požadavky na ESB

Společnými požadavky ESB jsou také jeho nejčastěji používané funkce:

  1. Směrování: ESB by měl poskytovat účinný a flexibilní směrovací mechanismus.
  2. Proměna: Komponenta služby by neměla potřebovat znát formát požadavku cílové služby, který by mohla vyvolat. Na základě žadatele a cíle by měl být ESB schopen použít příslušnou transformaci na požadavek, aby mu cíl porozuměl.
  3. Víceprotokolový transport: Implementace ESB, která mluví pouze s JMS nebo pouze s webovými službami, nemá velkou hodnotu. Mělo by být dostatečně rozšiřitelné, aby podporovalo více protokolů zpráv v závislosti na potřebách podniku.
  4. Bezpečnostní: V případě potřeby by ESB měla vynutit autentizaci a autorizaci pro přístup k různým komponentům služby.

Obrázek 1 ukazuje hlavní architektonické komponenty ESB. Má tři široké přihrádky:

  1. Přijímač: ESB zpřístupňuje různá rozhraní umožňující klientským aplikacím odesílat zprávy na ESB. Například servlet může přijímat požadavky HTTP na ESB. Současně můžete mít MDB (fazole řízená zprávami) naslouchající v cíli JMS, kde mohou klientské aplikace odesílat zprávy.
  2. Jádro: Toto je hlavní část implementace ESB. Zpracovává směrování a transformaci a aplikuje zabezpečení. Obvykle se skládá z MDB, který přijímá příchozí požadavky a poté na základě kontextu zprávy použije příslušnou transformaci, směrování a zabezpečení. Podrobnosti o směrování, přepravě, transformaci a bezpečnostních informacích lze zadat v dokumentu XML (krátce diskutováno).
  3. Odesílatel: Všechny odchozí manipulátory dopravy spadají pod tuto část ESB. Do ESB můžete připojit libovolný obslužný program přenosu (e-mail, fax, FTP atd.).

Všechny tyto části ESB jsou slepeny dohromady dokumentem XML, který uvádí všechny trasy, na kterých ESB působí. Různé obslužné rutiny přenosu, transformátory a zásady opakování a jejich připojení k různým trasám jsou všechny propojeny prostřednictvím tohoto dokumentu XML.

ESBConfiguration.xml

Výpis XML—ESBConfiguration.xml, která se objeví níže - poskytuje určitou představu o fungování ESB. Hlavní prvky zájmu v ESBConfiguration.xml jsou následující:

  1. Fazole: Tento prvek obsahuje nulu nebo více Fazole elementy.
  2. Fazole: Tento prvek v podstatě definuje způsob, jakým vytváříme a konfigurujeme a Fazole třída. Má následující atributy:
    • název: Jedinečný název, kterým lze odkazovat na tento fazole.
    • jméno třídy: Plně kvalifikovaný název třídy fazole.
    Každá fazole může mít nulu nebo více Vlastnictví prvky jako děti. Každý Vlastnictví prvek má atribut název který ji identifikuje a podřízený prvek typu Hodnota který drží hodnotu vlastnosti. Tyto vlastnosti jsou ve skutečnosti členy třídy třídy JavaBeans, kteří mohou konfigurovat třídu fazole.
  3. Opakovat zásady: Tento prvek obsahuje nulu nebo více Opakovat politiku děti.
  4. Opakovat politiku: Tento prvek definuje zásadu opakování pro danou trasu. Má atribut název kterým lze odkazovat. Má dva podřízené prvky pojmenované MaxRetries a RetryInterval.
  5. Trasa: The EsbConfiguration kořenový prvek může obsahovat nulu nebo více podřízených prvků tohoto typu. V zásadě představuje cestu pro ESB. Má následující atributy:
    • název: Jedinečný název, kterým lze odkazovat na tuto trasu.
    • retryPolicyRef: Odkaz na zásady opakování. Mělo by to odpovídat Opakovat politiku elementy název atribut.
    • transformátorRef: Odkaz na fazole, která představuje transformátor. Mělo by to odpovídat Fazole elementy název atribut.
    The Trasa prvek může mít jeden nebo více podřízených prvků typu TransportHandlerRef. Toto dítě v zásadě ukazuje na objekt bean, který představuje vhodný obslužný program přenosu, který by měl být použit pro tuto trasu, a název veřejné metody tohoto objektu bean, který by měl být vyvolán k odeslání zprávy. Volitelně Trasa prvek může mít jeden DeadLetterDestination dítě, které ukazuje na jinou trasu představující cíl mrtvého dopisu.

Ukázkový dokument XML, EsbConfiguration.xml, se objeví níže:

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

Chování ESB

The ESBConfiguration.xml dokument určuje chování našeho ESB. The EsbRouter MDB načte tento XML z umístění uvedeného v jeho deskriptoru nasazení. Informace, které obsahuje, jsou poté uspořádány do datové struktury zobrazené na obrázku 2 níže.

The EsbRouter používá tyto informace (prostřednictvím EsbConfigManager) k dešifrování příslušné cesty, transformace, která má být použita, kontroly autorizace zabezpečení atd. Důležitý bod, který je třeba poznamenat, je způsob, jakým byla technika Dependency Injection spolu s dědičností použita k oddělení různých funkcí (například jako přenos více protokolů a transformace zpráv) ESB, což umožňuje jeho vysokou rozšiřitelnost a přizpůsobitelnost.

Jak ukazuje diagram tříd, v designu ESB jsou dvě důležitá rozhraní: TransformHandler a Transportní manipulátor. Umožňují vám napsat konkrétní transformaci a implementaci transportu pro směrované zprávy. Tyto implementační třídy lze poté propojit s trasami prostřednictvím Fazole prvky v EsbConfiguration. Například ve vzorku EsbConfiguration.xml dokument, následující definice fazole určuje obslužný program přenosu:

   myQCF myCreditQueue 

Na tuto obslužnou rutinu přepravy pak lze odkazovat v a Trasa uzel vložením a Transportní manipulátor dítě k tomu takto:

Poznámka
Přístup popsaný v tomto článku používá rozhraní Java pro definování obslužných rutin transportu a transformace. Každý nový obslužný program by tedy musel implementovat požadované rozhraní, což by se mohlo zdát rušivé. Můžete snadno upravit EsbConfigManager použít Dependency Injection pro volání libovolné metody implementační třídy, čímž eliminuje potřebu implementovat rozhraní. Ale protože EsbRouter vždy projde a javax.jms.Message instance, vaše třída implementace obslužné rutiny musí používat typ javax.jms.Message tak jako tak.
$config[zx-auto] not found$config[zx-overlay] not found