Integratie bus. De belangrijkste functies van de ESB. Voordelen van de DATAREON ESB Enterprise Service Bus

Moderne toepassingen werken zelden geïsoleerd; een applicatie kan niets zinvols doen zonder interactie met andere applicaties. Service-Oriented Architecture integreert en versnelt samenwerkingsapplicaties door de applicatie op te splitsen in stukjes die met elkaar gecombineerd kunnen worden. SOA (Service Consumers Call Service Providers) klinkt misschien eenvoudig, maar er doen zich twee belangrijke problemen voor:

1. Hoe kan een consument de aanbieder vinden van de dienst waarop hij een beroep wil doen?
2. Hoe kan een consument snel en betrouwbaar een dienst bellen op een traag en onbetrouwbaar netwerk?

Het blijkt dat er een directe oplossing is voor beide problemen - een aanpak genaamd Enterprise-service Bus (ESB - Enterprise Service Bus). De ESB maakt het voor zowel de consument als de aanbieder gemakkelijk om een ​​dienst in te roepen door alle complexe interacties daartussen te beheren. De ESB maakt het niet alleen gemakkelijker voor applicaties (of delen daarvan) om een ​​service aan te roepen, maar helpt hen ook gegevens door te geven en gebeurtenismeldingen te verspreiden. ESB-ontwerp implementeert veel erkende ontwerppatronen en standaardspecificaties.

Ik heb dit artikel geschreven om jullie ontwikkelaars te helpen begrijpen waarom ESB een nuttig en noodzakelijk onderdeel is van applicatie-integratie, inclusief SOA. Dit artikel behandelt geen definities of producten, maar richt zich op ESB-functies en -mogelijkheden die u niet zelf hoeft te implementeren. In dit artikel wordt uitgelegd wat de ESB voor u doet.

Beldiensten

Om u te helpen applicatie- en SOA-integratie te begrijpen, zal ik beginnen met te kijken hoe webservices werken. Webservices zijn de enige manier waarop u een serviceaanroep kunt implementeren. Dit is misschien niet eens de beste benadering, maar het is de meest gestandaardiseerde benadering die momenteel beschikbaar is, en webservices helpen bij het ontwerpen van het ontwerp, en dat is wat ik van plan ben te doen.

Eerst moet ik de terminologie uitleggen. Een webservice lijkt veel op een functie in procedureel programmeren: het heeft een naam, parameters en een resultaat. De naam is Uniform Resource-ID(URI - Uniform Resource Identifier), die aanbieder Het gebruikt de webservices om de webservice beschikbaar te maken als: eindpunt... De webserviceprovider gebruikt de endpoint-URI als adres om de webservice te zoeken en aan te roepen. V verzoek er is een specifieke actie en parameters die de consument doorgeeft aan de webservice wanneer het eindpunt wordt aangeroepen. Na het uitvoeren van de service verzendt het eindpunt antwoord geven terug naar de consument, die succes (of fout) meldt en het resultaat van de dienst bevat. Dat wil zeggen, de consument belt het eindpunt van de provider, verzendt een verzoek en ontvangt een reactie terug.

De huidige definitie van het implementeren van een webservice is WS-I Basic Profile 1.1, dat bestaat uit het "SOAP 1.1 over HTTP 1.1"-protocol dat wordt beschreven in Webtaal Services Description Language (WSDL) 1.1 (een link naar de specificatie zelf wordt gegeven in de "" sectie). In "SOAP over HTTP" roept de consument de service op met behulp van het SOAP-verzoek dat via HTTP is doorgegeven in het HTTP-verzoek. De consument blokkeert synchroon HTTP-socketactiviteit, wachtend op een HTTP-antwoord dat een SOAP-antwoord bevat. Een eindpunt-API wordt beschreven door zijn WSDL, een contract tussen een consument en een serviceprovider.

Nu je de terminologie begrijpt, gaan we eens kijken naar de opties voor hoe de consument werkt bij het aanroepen van een dienst: synchrone en asynchrone oproepen.

Vergelijking van synchrone en asynchrone oproepen

De consument kan de dienst synchroon of asynchroon aanroepen. Vanuit consumentenperspectief is het verschil:

• synchrone... De consument gebruikt één thread om de dienst op te roepen; de thread verzendt een verzoek, blokkeert voor de duur van de service en wacht op een reactie;
• asynchroon... De consument gebruikt twee threads om de dienst aan te roepen; de ene is voor het verzenden van een verzoek, de andere is voor het ontvangen van een reactie.

concepten asynchroon en synchroon vaak verward met concepten consequent en parallel... De laatste concepten verwijzen naar de volgorde waarin verschillende taken worden uitgevoerd, terwijl synchroon en asynchroon omgaan met de manier waarop een thread een enkele taak uitvoert, zoals het aanroepen van een enkele service. Op een goede manier Om het verschil tussen synchrone en asynchrone aanroep te begrijpen, moet u de implicaties van failover overwegen:

• synchrone... Als een consument crasht tijdens het blokkeren terwijl een service actief is, kan deze na een herstart niet opnieuw verbinding maken met die service, waardoor de respons verloren gaat. De consument moet het verzoek herhalen en hopen dat er geen noodgeval is;
• asynchroon... Als een consument een alarm heeft terwijl hij wacht op een reactie op een verzoek, kan de consument na een herstart blijven wachten op een reactie, dat wil zeggen dat de reactie niet verloren gaat.

Disaster recovery is niet het enige verschil tussen synchroon en asynchrone gesprekken maar als je probeert de stijl van de specifieke aanroep die wordt gebruikt te definiëren, kan het kijken naar crashherstel je daarbij helpen.

Nu je weet hoe je de communicatieoptie moet kiezen bij het aanroepen van de dienst, gaan we eens kijken naar de mogelijkheden om de consument te verbinden met de aanbieder. De consument kan kiezen de volgende opties: aansluitingen:

1. Synchrone directe oproep;
2. Synchroon bellen via een tussenpersoon (broker);
3. Asynchrone oproep via een tussenpersoon (broker).

Ik zal elke optie afzonderlijk bekijken.

Synchrone directe oproep

De aanroepmethode van de "SOAP over HTTP"-webservice is eenvoudig: net als bij een functieaanroep kent de consument het adres van het eindpunt en roept het rechtstreeks aan. Voor een succesvolle aanroep moet de webservice functioneren wanneer het eindpunt door de consument wordt aangeroepen en moet reageren voordat de consument een time-out krijgt. Als de webservice wordt geïmplementeerd op een nieuwe locatie (bijvoorbeeld een ander internetdomein), moet de consument op de hoogte worden gesteld van de nieuwe eindpunt-URI. Wanneer u meerdere serviceproviders van hetzelfde type implementeert, moet het eindpunt van elke provider een andere URI hebben. Om een ​​bepaalde serviceprovider te selecteren, moet de consument elke dergelijke URI kennen.

Denk bijvoorbeeld aan een eenvoudige webservice voor het opvragen van aandelenkoersen: een consument zendt een aandelensymbool door en krijgt zijn actuele waarde terug. Deze service kan worden geleverd door verschillende makelaars, elk met een andere URI. Het vinden van een webservice-URI is een kip-en-ei-probleem. Als de consument de locatie van het eindpunt kende, zou hij het adres van de dienst kunnen opvragen, maar wat is het adres dat de consument moet weten om het adres op te vragen.

Om dit probleem op te lossen, is er de specificatie Universal Description Discovery and Integration (UDDI), die een webservice beschrijft die een directory is (vergelijkbaar met een telefoonboek) voor het vinden van andere webservices. Het idee is om een ​​UDDI-service in te zetten op een bij de consument bekend adres; een consument kan UDDI gebruiken om andere webservices te vinden.

In een situatie van een aandelenkoersservice kent de consument het adres van de UDDI-service, die op zijn beurt de adressen van de aandelenkoersservices kent (zie figuur 1).

Figuur 2 laat zien hoe een consument een UDDI-service gebruikt om een ​​eindpunt te vinden en een van de aanbieders van aandelenkoersen te bellen. Het proces vindt plaats volgens het volgende algoritme:

1. De consument vraagt ​​UDDI om een ​​lijst van dienstverleners;
2. De consument selecteert een providereindpunt uit een lijst die is verkregen uit de UDDI;
3. De consument noemt dit endpoint.

Merk op dat het providerselectie-algoritme volledig afhankelijk is van de consument; in dit voorbeeld selecteert de consument gewoon de eerste in de lijst. In een echte situatie kan deze keuze moeilijker zijn.

Houd er ook rekening mee dat, aangezien het eindpunt van een service kan veranderen, een consument elke keer dat hij een service wil aanroepen, de UDDI opnieuw moet opvragen en moet analyseren of de providerinformatie is gewijzigd. De noodzaak om bij elke serviceaanroep een UDDI aan te vragen, brengt extra overhead met zich mee, vooral in een typische situatie waarin de providerinformatie niet verandert.

Synchrone oproep via proxy

Het nadeel van directe aanroep is dat de consument de URI van het provider-eindpunt moet kennen om de dienst aan te roepen. Het gebruikt UDDI als directory om deze URI te vinden. Als er meerdere providers zijn, bevat de UDDI meerdere URI's en moet de consument er een selecteren. Als de provider de eindpunt-URI wijzigt, moet deze zich opnieuw registreren bij de UDDI-server zodat de UDDI de nieuwe URI kan opslaan. De consument moet de UDDI opnieuw aanvragen om een ​​nieuwe URI te verkrijgen. Dit betekent in wezen dat elke keer dat een consument een service wil aanroepen, hij de UDDI moet opvragen voor de URI van de eindpunten en er een moet selecteren. Dit leidt tot een aanzienlijke inspanning van de consument bij de periodieke UDDI-query- en providerselectie-operaties. Deze benadering dwingt de consument ook om op de een of andere manier een aanbieder te kiezen, blijkbaar uit een gelijkwaardige lijst.

Een manier om het probleem te vereenvoudigen, is door een makelaar in te voeren die optreedt als tussenpersoon bij het aanroepen van een webservice. De consument belt niet meer rechtstreeks met de providerservice, maar met de proxyservice van de broker, die op zijn beurt de providerservice belt. De consument moet de URI van het proxyservice-eindpunt kennen en gebruikt daarom de UDDI om het adres op te zoeken, maar in dit geval retourneert de UDDI slechts één URI en hoeft de consument geen keuze te maken. De consument weet misschien niet eens dat het eindpunt een proxyservice is; het weet alleen dat het die URI kan gebruiken om een ​​webservice aan te roepen. De makelaar associeert de consument met de dienstverleners (zie figuur 3).

De proxyservice-URI moet stabiel zijn: nadat de consument de UDDI heeft gebruikt om de proxyservice-URI op te halen en de service de service voor het eerst aanroept, kan de consument die URI opnieuw gebruiken voor opeenvolgende aanroepen (tenminste totdat de proxy niet beschikbaar is). Ondertussen houdt de proxy de providers bij, hun URI's (die tussen oproepen kunnen veranderen), hun beschikbaarheid (of de laatste oproep is mislukt), hun laadtijd (hoe lang was de laatste oproep), enz. De proxydienst kan voor elk gesprek de keuze van de beste provider overnemen en die consument daarvan bevrijden. De consument belt simpelweg elke keer dezelfde proxydienst en stemt af met verschillende providers.

Figuur 4 toont een schematisch diagram van een consument die een makelaar gebruikt bij het bellen naar een dienst. Het werkalgoritme is als volgt:

1. De consument vraagt ​​de UDDI om een ​​lijst van dienstverleners. De URI die door de UDDI wordt geretourneerd, is in feite een proxyservice. UDDI retourneert slechts één URI, niet meerdere, aangezien de broker slechts één proxyservice heeft voor elke specifieke service;
2. De consument roept de dienst aan met behulp van de proxy-URI;
3. De proxyservice selecteert een serviceprovider uit een lijst met beschikbare providers;
4. De proxyservice roept het eindpunt van de geselecteerde provider aan.

Merk op dat de zorg voor de keuze van de aanbieder is verdwenen van de consument - deze keuze is geïmplementeerd in de proxy-service van de makelaar. Dit maakt het leven van de consument gemakkelijker. Het selectieproces in de proxyservice mag immers niet verschillen van het proces dat de consument gebruikt. Aangezien de UDDI-server en proxyservice echter zijn ingekapseld in de broker, functionaliteit zoals het cachen van UDDI-informatie en het ontvangen van meldingen van de UDDI-server voor de proxyservice wanneer de informatie in de cache verouderd is.

Merk ook op dat aangezien het proxy-adres stabiel is, de consument niet constant om UDDI hoeft te vragen telkens wanneer de service wordt aangeroepen. Dat wil zeggen, de consument hoeft maar één keer een UDDI aan te vragen, vervolgens het adres van de proxyservice in de cache op te slaan en te gebruiken bij herhaalde oproepen naar de service. Dit vermindert de overhead van het bellen van de service aanzienlijk.

Asynchrone oproep via proxy

Het nadeel van de synchrone benadering is dat de consument moet wachten tot de service is afgelopen - de thread moet worden geblokkeerd terwijl de service actief is. Als de dienst al lang draait, kan de consument niet meer wachten op een reactie. Wanneer een consument een verzoek doet (en als er geen functionerende dienstverleners zijn, of ze zijn overbelast), kan deze niet wachten. En, zoals hierboven vermeld, als de consument een noodgeval heeft terwijl hij het werk blokkeert, zal zelfs na opnieuw opstarten het antwoord verloren gaan en moet de oproep worden herhaald.

Een veelvoorkomende oplossing voor dit probleem is om de service asynchroon aan te roepen door de consument. Met deze aanpak gebruikt de consument één thread om een ​​verzoek te verzenden en een tweede om een ​​reactie te ontvangen. Dat wil zeggen dat de consument het werk niet mag blokkeren in afwachting van een reactie en op dat moment ander werk kan doen. Hierdoor is de consument veel minder gevoelig voor de levensduur van de aanbieder.

De makelaar waarmee de consument de webservice asynchroon kan aanroepen, wordt geïmplementeerd met behulp van het systeem berichten die berichtenwachtrijen gebruikt om een ​​verzoek te verzenden en een antwoord te ontvangen. Net als bij een synchrone proxyservice, fungeert een paar berichtenwachtrijen als een enkel adres dat een consument gebruikt om de service aan te roepen, ongeacht het aantal mogelijke providers dat luistert (zie afbeelding 5).

Deze benadering maakt gebruik van het Request-Reply-patroon om een ​​webservice aan te roepen. Transportfuncties kunnen nu berichtenwachtrijen uitvoeren in plaats van het HTTP-protocol dat is gespecificeerd in WS-I BP 1.1. Het SOAP-verzoek en -antwoord is hetzelfde als bij de WS-I BP, maar verpakt in berichtenberichten.

Figuur 6 laat zien hoe een consument asynchroon een dienst aanroept met behulp van een broker met behulp van het volgende algoritme:

1. De consument dient het SOAP-verzoek als bericht in bij de verzoekwachtrij. De consument sluit af en kan deze thread gebruiken om andere taken uit te voeren;
2. Elke aanbieder is een consument van de aanvraagwachtrij, waardoor ze concurrerende consumenten zijn. Het berichtensysteem bepaalt welke aanbieder een bericht kan ontvangen en zorgt ervoor dat slechts één aanbieder het bericht ontvangt. Hoe dit werkt, hangt af van de implementatie van het berichtensysteem;
3. De winnende provider ontvangt een bericht van de aanvraagwachtrij;
4. De provider voert de service uit;
5. De provider stuurt het SOAP-antwoord als bericht naar de antwoordwachtrij. Nu is de provider klaar met zijn werk en kan zijn thread gebruiken voor andere taken (bijvoorbeeld om te wachten op het volgende verzoek);
6. De luisterende consument ontvangt een bericht met daarin de SOAP-respons.

Merk op dat de providerselectiefunctie nu is geïmplementeerd in het berichtensysteem, wat het leven van de consument gemakkelijker maakt. Merk ook op dat als de consument een noodgeval ervaart na het verzenden van het verzoek (en zelfs als het antwoord op dat moment klaar is), het berichtensysteem het antwoord in de antwoordwachtrij zal opslaan totdat de consument weer online is.

Houd er ook rekening mee dat de consument UDDI niet gebruikt om de wachtrijen voor verzoeken en antwoorden te vinden. Bestaat momenteel niet standaard service om een ​​paar wachtrijadressen te retourneren, hoeft de consument deze adressen dus alleen maar te kennen. Ze zijn ofwel hard gecodeerd in het programma van de consument, of gelezen door het programma van config-bestand... Breid in de toekomst UDDI uit of specificeer een vergelijkbare service die een consument kan aanvragen om een ​​paar wachtrijen te definiëren om een ​​bepaalde service aan te roepen.

U kent nu de verbindingstype-opties voor het aanroepen van services. Laten we eens kijken naar aanvullende integratiemogelijkheden die ook nuttig kunnen zijn, en vervolgens hoe we een ESB kunnen ontwikkelen die ons deze mogelijkheden biedt.

Andere integratiemogelijkheden

De ESB biedt ook de mogelijkheid om verder te gaan dan het aanroepen van diensten en applicaties en delen van SOA te integreren met behulp van andere technologieën. Een service-aanroep is bijna altijd een bidirectionele operatie, dat wil zeggen dat het verzoek van de consument naar de aanbieder wordt verzonden en het antwoord in de tegenovergestelde richting wordt verzonden. Andere integratietechnologieën werken als eenrichtingsverkeer, wanneer de afzender informatie naar de geadresseerde verzendt en niet wacht op een reactie; de geadresseerde ontvangt de informatie gewoon zonder dat er een reactie nodig is.

Data overdracht

Soms hoeft een applicatie alleen gegevens door te geven aan een andere applicatie zonder de ontvangerprocedure te hoeven aanroepen, en zeker zonder te wachten op het resultaat. De afzender hoeft de ontvanger niet te vertellen wat hij met de gegevens moet doen; het maakt alleen de gegevens beschikbaar.

Een service-oproep kan worden gebruikt om gegevens over te dragen, wat gelijk staat aan het aanroepen van een setter-methode, maar de gegevensoverdracht is RPC. In werkelijkheid lijkt gegevensoverdracht meer op bestandsoverdracht: gegevens worden geëxporteerd door de afzender en geïmporteerd door de ontvanger zonder de ontvanger expliciet te vertellen wat hij met de gegevens moet doen. Het lijkt meer op een SOAP-bericht in documentstijl dan op een bericht in RPC-stijl.

Het gebruik van een ESB om gegevens over te dragen vergroot de mogelijkheid om een ​​ontvanger te vinden en gegevens betrouwbaar over te dragen. De afzender hoeft de ontvanger niet te vinden, hij hoeft alleen te weten hoe hij de ESB kan vinden en deze de ontvanger toe te vertrouwen. De ESB is ook verantwoordelijk voor de betrouwbare overdracht van gegevens. De afzender kan de gegevens eenvoudig doorsturen naar de ESB en erop vertrouwen dat deze worden overgedragen.

Voor meer informatie over technologie voor gegevensoverdracht, zie het sjabloon Documentbericht (zie het boek " ", de link waarnaar wordt gegeven in de sectie" ").

Gebeurtenismelding

Soms moet een wijziging in de ene applicatie worden gemeld aan andere applicaties. Als een consument bijvoorbeeld zijn adres wijzigt in één applicatie, worden de rest van de applicaties van zijn eigen basis gegevens moeten worden meegedeeld zodat zij hun administratie kunnen corrigeren.

Nogmaals, de ene applicatie kan een service in een andere applicatie aanroepen om hem van de wijziging op de hoogte te stellen, maar er zijn drie problemen met deze aanpak. De eerste twee problemen zijn hetzelfde als bij het overzetten van gegevens. Ten eerste is de service-oproep te specifiek om aan te geven wat de ontvanger met informatie moet doen, en ten tweede is het meestal bidirectioneel, waardoor de afzender moet wachten op een antwoord (zelfs in asynchrone modus), wat in feite het geval is niet willen doen...

Het derde en belangrijkste probleem bij het aanroepen van een dienst om een ​​gebeurtenis te melden, is dat een dienstaanroep inherent een één-op-één, consument-naar-leverancier-proces is, terwijl gebeurtenismelding inherent een één-op-veel-proces is. ", uitzending, is bedoeld voor alle geïnteresseerde ontvangers. Met behulp van een serviceoproep zou de afzender alle geïnteresseerde ontvangers moeten bijhouden en de service voor elk afzonderlijk moeten bellen. Zo een uitzending de meldingen kunnen het beste worden overgelaten aan de makelaar tussen de afzender en de ontvangers.

Het gebruik van de ESB voor gebeurtenismeldingen vergroot de mogelijkheid om een ​​lijst met geïnteresseerde ontvangers bij te houden en ervoor te zorgen dat de melding bij elk van hen wordt afgeleverd. Het stelt de ontvanger in staat om slechts één keer een melding te verzenden en er zeker van te zijn dat deze wordt afgeleverd bij alle geïnteresseerde ontvangers, wie ze ook zijn. Aangezien deze bewerking eenrichtingsverkeer is, kan de afzender ander werk doen tijdens het afleveren van meldingen, en meldingen kunnen parallel worden afgeleverd.

Meer informatie over communicatietechnologie is te vinden in de sjabloon voor gebeurtenisberichten (raadpleeg opnieuw het boek Enterprise Integration Patterns dat is gekoppeld in de sectie "".

Enterprise Service Bus-ontwikkeling

U kent nu het verschil tussen het rechtstreeks aanroepen van de webservice van een provider en het gebruiken van een makelaar om dit te doen. Je hebt ook geleerd hoe een makelaar een consument kan toestaan ​​een dienst synchroon of asynchroon aan te roepen.

Een makelaar wordt vaak een ESB genoemd. Dus hoe past ESB in het al? geaccepteerde projecten en sjablonen?

Zelfbeschrijving en vindbaarheid

Het verschil tussen webservices en andere integratiebenaderingen is dat de consument dynamisch kan communiceren met de serviceprovider. Dit wordt geleverd door de volgende twee hoofdfuncties:

• Zelfbeschrijving... De webservice beschrijft zichzelf op een machineleesbare manier. Twee of meer aanbieders van dezelfde dienst zijn direct herkenbaar, zelfs als ze totaal anders zijn geïmplementeerd, omdat hun beschrijvende interfaces dezelfde beschrijving volgen;
• detecteerbaarheid... Webserviceproviders kunnen worden georganiseerd in automatisch onderhouden mappen. De consument kan door zo'n directory bladeren om de aanbieder van de gewenste dienst te vinden.

Deze functionaliteit van webservices verschilt sterk van de bestaande integratiebenaderingen. Daarin werden de interfaces gedefinieerd tijdens het compileren en op het moment van consumentencommunicatie met providers. De berichtformaten werden niet beschrijvend uitgedrukt. Ze waren gebaseerd op een interne conventie en konden niet worden gedwongen om dit formaat te volgen, waardoor de ontvanger de door de afzender gecreëerde structuur niet kon verwerken.

Het zelfbeschrijvende vermogen van webservices maakte de integratie gemakkelijker door de te volgen interfaces aan te geven. Dynamic service discovery bevrijdde de consument van de afhankelijkheid van een specifieke provider met een specifiek adres, maar deze mogelijkheid zorgde ook voor zijn eigen problemen. Moet de consument eenmalig of altijd naar dienstverleners zoeken?

Het was moeilijk om de spanning op te lossen tussen het voor eens en altijd binden van een consument aan een provider tijdens het compileren en het potentieel zoeken naar een nieuwe provider elke keer dat deze tijdens runtime werd aangeroepen. De ESB stelde een derde, compromisoptie voor - om de consument in staat te stellen één keer dynamisch contact op te nemen met een proxyservice en toch meerdere providers en providers te kunnen gebruiken die in de toekomst via deze proxyservice kunnen verschijnen.

Op deze manier stelt de ESB niet alleen diensten beschikbaar voor consumenten om te bellen, maar biedt de consument ook de mogelijkheid om diensten programmatisch te vinden.

Servicegateway

De basis van een synchrone ESB is een zogenaamde servicegateway, die bemiddelt tussen serviceconsumenten en providers om de afhandeling van synchrone oproepen met behulp van een broker te vergemakkelijken. Het biedt toegang tot alle bekende services en proxyservices van elk van hen. De gateway biedt dus een "single window" voor de consument die een dienst wil bellen van elke provider die de gateway kent.

Als de services die de gateway coördineert webservices zijn, dan beschrijven ze zichzelf. Elke service declareert zijn interface met behulp van WSDL, dat uit de volgende vier delen bestaat:

1. Poorttypes- Een reeks bewerkingen die worden uitgevoerd door een webservice. Het poorttype kan stockBrokerServices zijn met poorten / bewerkingen zoals getQuote.
2. Berichten- Het formaat van verzoeken en antwoorden, zoals getQuoteRequest (die het aandelensymbool bevat) en getQuoteResponse (die de prijs bevat).
3. Types- De gegevenstypen die door de webservice worden gebruikt, zoals symbool en prijs (of alleen xs: string en xs: decimaal).
4. verbindingen- Het adres om de bewerking aan te roepen, bijvoorbeeld http://stockbroker.example.com/getQuote.

Dergelijke gateway-webservices (of meer specifiek hun proxyservices) zijn ook vindbaar. De gateway biedt deze mogelijkheid in de vorm van een UDDI-service, zoals eerder besproken. Om het service-aanroepadres te vinden, vraagt ​​de consument de gateway UDDI-service om een ​​lijst met providers voor de gewenste WSDL-bewerking en krijgt hij het gateway-proxy-serviceadres voor die bewerking terug.

Berichtenbus

Asynchrone ESB is gebaseerd op het bekende Message Bus-patroon dat wordt beschreven in het boek " Integratiepatronen voor ondernemingen", waarnaar wordt verwezen in" ". Een berichtenbus is een verzameling berichtkanalen (ook bekend als wachtrijen of onderwerpen), gewoonlijk geconfigureerd als kanaalparen voor verzoek en antwoord. Elk paar vertegenwoordigt een service die kan worden aangeroepen door een consument die de bus gebruikt. Deze consument verzendt een bericht naar de serviceverzoekwachtrij en luistert vervolgens (asynchroon) naar de antwoordwachtrij om het resultaat te krijgen, zodat hij weet welk resultaat overeenkomt met zijn specifieke verzoek omdat het resultaat de juiste correlatie-ID heeft.

De beller van de dienst weet niet echt wie de dienst verleent. Serviceproviders zijn ook aangesloten op de berichtenbus en luisteren naar verzoekberichten. Als er meerdere dienstverleners zijn, concurreren ze met elkaar als consumenten om specifiek verzoek:... Het berichtensysteem dat de berichtenbus implementeert, fungeert als een berichtverzender en distribueert verzoekberichten naar serviceproviders, waarbij deze distributie op de een of andere manier wordt geoptimaliseerd, afhankelijk van de belastingsbalans, netwerklatenties, enz. Wanneer de serviceprovider het verzoek ontvangt, voert deze de service uit en plaatst het resultaat in een bericht in de voorwaardelijke responswachtrij. Dat wil zeggen, de aanbieder en de consument weten nooit direct van elkaars locatie; ze kennen alleen de berichtenbus en het adres van de corresponderende kanalen en kunnen communiceren via gemeenschappelijke kanalen.

Deze berichtenbus is de essentie van de ESB en is niets nieuws. Applicatie-integrators gebruiken deze technologie al meer dan tien jaar met producten voor het in de wachtrij plaatsen van berichten, zoals WebSphere® MQ en TIBCO Enterprise Message Service. En in feite wordt vaak gezegd dat als u zakelijke berichtenproducten gebruikt, u een ESB hebt. IBM-klanten gebruiken deze mogelijkheden al geruime tijd met WebSphere Business Integration Message Broker en WebSphere MQ.

Dus, is de ESB gewoon een berichtenbus? Nee, Message Bus is absoluut de ruggengraat van een asynchrone ESB, maar een volledige ESB is meer dan dat. De ESB heeft mogelijkheden die een berichtenbus nooit had: de eerder genoemde zelfbeschrijvende en vindbare mogelijkheden.

Betere berichtenbus

Dus als de berichtenbus geen volledige ESB is, wat doet de ESB dan nog meer?

Het nadeel van traditionele berichtenbustechnologie is het gebrek aan zelfbeschrijvend vermogen. Vanuit het oogpunt van de consument zijn er vele kanalen om een ​​beroep te doen op vele diensten. Maar welke van deze kanalen is nodig voor de consument om de gewenste dienst in te roepen? Een consument kan niet zomaar een verzoek indienen bij een verzoekkanaal; het moet het juiste kanaal kennen om een ​​bepaalde dienst aan te roepen. Anders kan hij een vliegticket kopen in plaats van het boek dat hij wil. Bovendien moet de consument, zelfs nadat hij (op de een of andere manier) het juiste kanaal (en het kanaal om naar een reactie te luisteren) heeft bepaald, het gegevensformaat weten waarin het verzoek moet worden verzonden (en in welk gegevensformaat het antwoord kan worden verwacht).

Zoals eerder besproken, lost WSDL dit probleem voor synchrone webservices op en is momenteel ook de standaardvariant voor het beschrijven van asynchrone services. De WSDL die is gekoppeld aan een verzoekkanaal, moet beschrijven welke service dat kanaal biedt, evenals het formaat van het verzoekbericht dat de consument moet verstrekken. De WSDL moet waarschijnlijk ook het responskanaal specificeren waarop de consument moet luisteren om een ​​respons te ontvangen, en het formaat van het verwachte responsbericht. Op deze manier kan de aanroepende applicatie programmatisch een paar leidingen ontleden om een ​​dienst aan te roepen en te bepalen of ze de gewenste dienst leveren met gebruikmaking van de gewenste formaten voor verzoek- en antwoordberichten.

Zelfbeschrijvende servicepipes introduceren een ander probleem, het ontdekkingsprobleem, dat synchrone webservices oplossen met UDDI. Zoals eerder besproken, vraagt ​​de consument de UDDI-server naar het adres van de webserviceprovider, en de server retourneert de URL van die provider. De consument gebruikt deze URL om de dienst aan te roepen.

ESB-behoeften soortgelijke dienst directory's met een UDDI-achtige API, waarmee de consument het adres kan opvragen van de service die de gewenste WSDL-bewerking implementeert. De ESB retourneert het adres van het corresponderende verzoek- en antwoordkanaalpaar. Dat wil zeggen dat een ESB-client, net als een UDDI-client, niets anders hoeft te weten dan het volgende:

1. WSDL beschrijft de service die het wil aanroepen.
2. Het adres van de ESB-directoryservice (dat kan worden afgeleid van het ESB-rootadres).

Dit is voldoende om de serviceverzoek- en responskanalen te detecteren en een serviceoproep te starten. Bovendien is deze directoryservice gewoon een andere service van de ESB, als het ware de belangrijkste service voor het vinden van andere services.

Synchroon of asynchroon?

Dienstconsumenten worden geconfronteerd met een kunstmatige keuze tussen twee communicatiestijlen: synchroon of asynchroon. Om dit dilemma aan te pakken, zullen veel ESB's beide modi ondersteunen en in feite twee aanroepmodellen voor dezelfde service kunnen aanbieden. In dit geval kan de consument bij het opvragen van het adres van de dienst twee opties krijgen: een voor de synchrone modus, de tweede voor de asynchrone modus. De consument kan dan het belmodel kiezen dat het beste bij hem past. Ongeacht het model wordt dezelfde service uitgevoerd, hoewel het specifieke exemplaar van de serviceprovider kan verschillen.

Dat wil zeggen, de ESB is beter dan de traditionele berichtenbus omdat de ESB de service ook zelfbeschrijvend maakt en een directoryservice biedt om andere services te vinden. Dit is wat ESB-leveranciers van bouwproducten proberen te bieden.

Conclusie

Zoals u kunt zien, kan een service op een van de volgende manieren worden aangeroepen:

1. Direct en synchroon;
2. Synchroon via een makelaar;
3. Asynchroon via een makelaar.

Enterprise Service Bus is een broker die zowel synchrone als asynchrone service-aanroep ondersteunt. Het maakt ook de overdracht van gegevens en gebeurtenismeldingen tussen applicaties mogelijk. Het helpt consumenten bij het vinden van aanbieders en beheert de details van de interacties tussen hen.

Een synchrone ESB is een servicegateway die fungeert als centrale coördinator voor meerdere services. Een asynchrone ESB is een berichtenbus waarvan de services ook de zelfbeschrijvende en vindbare mogelijkheden van webservices ondersteunen. Er zijn nu standaarden en sjablonen voor het implementeren van een synchrone ESB en een berichtenbus om de asynchrone ESB te vereenvoudigen. Er zijn aanvullende normen nodig om het volledige potentieel van de ESB te realiseren.

Als u op dit moment een audit van de IT-infrastructuur uitvoert, ziet een typische diagnose er ongeveer zo uit:

1) De bestaande IT-infrastructuur bevat te veel onderlinge verbindingen (soms verborgen en slecht gedocumenteerd) tussen systemen en vereist daarom veel goedkeuringen en verbeteringen bij het maken van, zelfs minimale wijzigingen.

2) Er is niet één besturingsschakel die verantwoordelijk is voor het updaten en verstrekken van gegevens uit verschillende informatiesystemen.

3) Er is geen controle op uitwisselingsprocessen: er is geen uniforme omgeving voor gegevensuitwisseling tussen informatiesystemen.

4) Er is een "Technologische Dierentuin": een verscheidenheid aan informatiesystemen en gebruikte protocollen voor gegevensuitwisseling, veel connectoren (vaak op bestelling of onafhankelijk ontwikkeld), enz.

Complexe oplossing soortgelijke problemen- in de transitie naar het bouwen van een IT-infrastructuur op basis van het concept van Service Oriented Architecture (SOA), met als kernelement de Service Integration Bus. Een bus is software waarmee je kunt combineren groot aantal platforms en applicaties, en de interactie tussen hen organiseren op basis van services. Tegelijkertijd doen de technologieën waarop de systemen en hun diensten worden geïmplementeerd er niet toe, het kan JAVA, .NET of een ander platform zijn.

Een integratiebus biedt meestal de volgende functies:

Conversie van berichten, evenals hun verzending, algoritmische omleiding, wachtrijen en tracking;

Werken met berichten in de volgende modi: synchroon, asynchroon, point-to-point, publiceren-abonneren;

Ondersteuning voor XML- en SOAP-berichten;

Mogelijkheid om meerdere systemen aan te sluiten via kant-en-klare adapters en API voor het schrijven van nieuwe adapters;

Orkestratie (automatische plaatsing, coördinatie en aansturing) van diensten.

Conceptueel ziet de architectuur met behulp van de Integration Service Bus er als volgt uit:

Figuur 1 Architectuur met een integratiebus

Door de introductie van een integratiebus is de integratie van nieuwe systemen, zowel gekocht als zelf ontwikkeld, uiterst eenvoudig. Services zijn niet langer monolithische toepassingen, maar zijn opgesplitst in afzonderlijke services. Bijvoorbeeld: de samengestelde dienst "beschouw een aanvraag voor een lening" kan worden onderverdeeld in de volgende "enkele diensten":

• Voer klantgegevens in
• Controleer of er een record bestaat voor een bepaalde klant
• Een lijst met klantaccounts krijgen
• Krijg een lijst met services die door de klant worden gebruikt
• Krijg geaggregeerde gegevens over de geschiedenis van leningbetalingen
• Gegevens voor het rapport ophalen
• Accountsaldo ophalen
• Bereken kredietwaardigheid
• Genereer een rapport ter overweging door de manager
• Accountgegevens bijwerken
• Genereer een melding voor de klant

Houd er rekening mee dat sommige "enkele services" kunnen worden aangeroepen bij andere samengestelde bewerkingen, wat de integriteit van het systeem verhoogt, het onderhoud vergemakkelijkt en het risico vermindert.

Een portaal voor bankklanten combineert bijvoorbeeld rapportages over betaalrekeningen, hypotheekbetalingen en afschriften over kredietkaart op één pagina. Tegelijkertijd kunnen gegevens over rekeningen, gegevens over hypotheekbetalingen, gegevens op een creditcard uit verschillende systemen worden gehaald. Op basis van CRM-gegevens op dezelfde pagina kan potentieel interessante informatie worden weergegeven specifiek voor deze klant aanbod.

Door de implementatie van de integratiebus wordt transparantie van gegevensuitwisseling in het kader van bestaande en geïmplementeerde bedrijfsprocessen bereikt, is het mogelijk om de efficiëntie en productiviteit van medewerkers en afdelingen te verhogen, evenals om de kwaliteit van de klant te verbeteren tevredenheid, om de kosten voor het creëren en onderhouden van de IT-infrastructuur van de Bank te verlagen.

De volgende afbeelding laat zien hoe de interactie van de IT-systemen van de bank verandert na de introductie van de integratiebus.

Tekening2 Bank IT-architectuur voor en na busimplementatie

Er is tegenwoordig een breed scala aan keuzes op de markt voor integratiebussen. Zowel commerciële systemen als open source producten komen aan bod. broncode... Onder de fabrikanten van integratiebussen - leiders in implementatie in Rusland, kunnen IBM en Oracle worden onderscheiden; TIBCO kan worden gerekend tot de toonaangevende buitenlandse leveranciers.

Denk aan de implementatie van integratiebussen bij verschillende grote internationale banken.

Chinatrust Commerciële Bank ( Commerciële bank Chinatrast) gebruikt een integratiebus om haar producten en diensten te ondersteunen. Servicegerichte architectuur op basis van de integratiebus verenigt meer dan zeventig systemen op verschillende platforms, zoals: geautomatiseerd banksysteem, netwerkbankieren, hypotheeksysteem, loterijsysteem, workflowautomatiseringssysteem, interactief spraakmenu enzovoort. Diensten zoals data-aggregatie, rekeningoverzicht, inkomende en uitgaande overschrijvingen, overschrijvingen, notificaties (de functionaliteit van gebeurtenisgerichte communicatie is hierbij betrokken) en andere zijn in realtime beschikbaar gekomen. De kosten van het integreren van nieuwe systemen zijn gemiddeld met 30..40% gedaald.

De integratiebus van de bank ondersteunt momenteel 100.000 dagelijkse transacties in het bedrijfsleven en 50.000 in de retailsector. Het aantal internetbankieren steeg van 150.000 naar 1.200.000 per dag.

De Singapore-Maleisische bank OCBC heeft zichzelf onlangs het doel gesteld om de operationele efficiëntie met 25% te verhogen en de kosten van het ontwikkelen van nieuwe API's met 30% te verlagen over een periode van vijf jaar. De eerste SOA-gebaseerde dienst werd gelanceerd in 2006. Zes maanden later waren 116 afzonderlijke services operationeel, die elk inzetbaar zijn in samengestelde services. 50 enkelvoudige diensten maakten deel uit van meerdere samengestelde diensten. Ter ondersteuning van de integratieprocessen heeft de bank een Integration Competence Center in het leven geroepen. OCBC is van mening dat SOA de sleutel is tot het bereiken van de gestelde doelen.

In Japan is de concurrentie voor internetbankieren extreem hoog. Sumishin Net Bank, Ltd. een doel stellen om in een kortere tijd dan andere financiële instellingen een breed scala aan producten op de markt aan te bieden. Om dit doel te bereiken, moest de bank voldoen aan de strenge technische normen die aan de Japanse banksector worden opgelegd en tegelijkertijd een concurrentievoordeel ontwikkelen. Met behulp van tien softwareproducten, waaronder een integratiebus, is een servicegerichte architectuur ontwikkeld. In slechts 18 maanden na de lancering van een nieuwe lijn van diensten, werd ongeveer 600 miljard yen (ongeveer $ 6 miljard) geïnvesteerd in de bank, werden 400.000 rekeningen geopend. Er is een ongelooflijke flexibiliteit bereikt bij het toevoegen van nieuwe diensten. De kosten van hun ontwikkeling zijn aanzienlijk gedaald.

In Rusland worden integratiebussen gebruikt bij veel grote ondernemingen, waaronder telecomoperators, de banksector, maar ook in het complex van elektronische overheidssystemen in de Russische Federatie. Integratiebussen worden meestal geïmplementeerd door systeemintegrators. In het bijzonder heeft ons bedrijf AMT-GROUP, dat volgens cnews.ru is opgenomen in de Top 20 Russische bedrijven - aanbieders van IT-diensten voor banken, een succesvolle ervaring met het werken met integratiebussen en hun implementatie op verschillende activiteitsgebieden, waaronder de banksector. Onze specialisten hebben ruime ervaring in het creëren van servicegerichte architecturen op basis van integratiebussen, inclusief het auditen van bedrijfsprocessen en de daaropvolgende automatisering, het creëren van connectoren voor geïntegreerde systemen en het optimaliseren van de werkomgeving.

Het artikel maakt gebruik van materialen uit open bronnen:
http://www.tibco.com/multimedia/ss-ctcb_tcm8-15110.pdf
http://www.eawriter.com/images/case_studies/TIBCO_2.pdf
http://www-01.ibm.com/software/success/cssdb.nsf/CS/JSTS-7V4BWP?OpenDocument&Site=corp&cty=en_us

Schatting:

4 15

Enterprise Service Bus-functies

Moderne integratie van informatiesystemen is de implementatie van Service-Oriented Architectures (SOA) met behulp van webservicetechnologieën; er zijn veel uitstekende beschrijvingen van de voordelen en methoden om dit te doen (zie sectie). Onlangs werd de enterprise-servicebus beschouwd als een belangrijk onderdeel van de SOA-infrastructuur. Enterprise Service Bus(ESB) (zie paragraaf). Het is echter belangrijk om precies te weten wat een ESB is: een product, technologie, standaard of iets anders. Is het met name mogelijk om vandaag een ESB te bouwen, en zo ja, hoe precies?

In dit artikel wordt de ESB beschreven als een set infrastructuurfuncties die zijn geïmplementeerd met middlewaretechnologieën die SOA ondersteunen. De ESB ondersteunt interacties met behulp van diensten, berichten en evenementen in een heterogene omgeving, met het juiste serviceniveau en beheersbaarheid. In dit artikel hebben we een breed scala aan functies verzameld en geclassificeerd. Niet alle ESB-situaties vereisen echter dat u al deze functies gebruikt.

Het artikel definieert: minimale set functies die de meeste ESB-vereisten ondersteunen in overeenstemming met SOA-principes. Door de minimale functieset te definiëren, kunnen we begrijpen welke van de beschikbare technologieën kunnen worden gebruikt om een ​​ESB te implementeren die SOA ondersteunt. Als u begrijpt welke extra functies worden bepaald door de vereisten van een bepaalde situatie, kunt u in deze situatie de meest geschikte implementatietechnologie kiezen.

De volgende artikelen beschrijven een reeks ESB-scenario's met gemeenschappelijke SOA-uitgangspunten om een ​​ESB of SOA te implementeren. Op hun beurt helpen beslissingssjablonen u bij het selecteren van de juiste technologieën voor implementatie.

Naarmate de situaties waarin de ESB-oplossing wordt gebruikt evolueren, evolueert de door de ESB vereiste functionaliteit dienovereenkomstig. De functies en tools van producten die expliciet gebruik maken van de ESB zullen zich op een vergelijkbare manier ontwikkelen. Daarom zullen we in het laatste artikel in deze serie de SOA- en ESB-implementatieroadmap bekijken om een ​​eerste stapgids te bieden voor het gebruik van ESB-functies en -technologieën, en om de mogelijkheden voor geleidelijke implementatie te demonstreren.

Rol van ESB's in SOA Framework

Hoewel we niet in detail zullen ingaan op de definitie van SOA (zie paragraaf), is het toch nuttig om hier alle principes te verzamelen waar de meeste auteurs van SOA-definities het over eens zijn:

• Gebruik van expliciet implementatie-onafhankelijke interfaces om services te definiëren;
• Gebruik van communicatieprotocollen die de transparantie en interoperabiliteit van locaties verbeteren;
• Definieer services die herbruikbare bedrijfsfuncties omvatten.

Natuurlijk, verschillende technologieën zullen verschillende beperkingen hebben op de fysieke implementatie van de patronen die ze ondersteunen - sommige kunnen geschikt zijn voor zeer grootschalige distributie en ondersteuning voor integratie over grote geografische gebieden, terwijl andere meer geschikt kunnen zijn voor implementaties in gelokaliseerde clusters en ondersteuning bieden voor oplossingen met hoge beschikbaarheid en schaalbaarheid. Het in kaart brengen van de eisen voor de fysieke verdeling van de functies van de te gebruiken technologieën is een belangrijk aspect van ESB-ontwerp. Bovendien is het van cruciaal belang om het oorspronkelijk geïmplementeerde systeem incrementeel uit te breiden om te voldoen aan veranderende vereisten, om aanvullende systemen te integreren of om de geografische beschikbaarheid van de infrastructuur uit te breiden.

Figuur 2. Gecentraliseerd beheer van een gedistribueerde ESB-infrastructuur

Daarnaast dient de positie van de ESB ten opzichte van andere componenten van de SOA-infrastructuur, zoals de componenten Service Directory, Business Service Choreography en Business-to-Business (B2B) Gateway te worden geschetst. Aangezien de hierboven genoemde SOA-principes niet vereisen dat deze componenten aanwezig zijn, behandelen we ze als optionele componenten. Hieronder wordt een SOA-infrastructuur weergegeven die de relatie van deze componenten met de ESB laat zien.

Figuur 3: Rol van ESB's in SOA Framework

Om ESB-serviceverzoeken te routeren, is een speciale servicerouteringsmap... SOA kan echter ook een aparte zakelijke servicecatalogus die, in zijn eenvoudigste vorm, een tijdelijke (gebruikt in projectontwikkeling) map kan zijn die wordt gebruikt om herbruikbaar diensten door de ontwikkelaars van de organisatie. In de optiek van webservices wordt de rol van de bedrijfsservicedirectory en de servicerouteringsdirectory toegewezen aan de UDDI-directory, waardoor dynamische detectie en aanroep van services mogelijk wordt. Een dergelijke directory kan worden beschouwd als onderdeel van de ESB, maar totdat dergelijke oplossingen op grote schaal worden gebruikt, is het beter om de directory voor bedrijfsservices gescheiden te houden van de ESB.

De functie van de component Business Service Choreograaf is componeren Business processen van meerdere Bedrijfsdiensten; daarom roept dit onderdeel diensten aan via de ESB en biedt vervolgens bedrijfsprocessen aan klanten aan als andere diensten, ook via de ESB. De rol van het onderdeel Business Service Choreograaf, de workflowtechnologie, bij het coördineren van het werk van bedrijfsprocessen en services, identificeert dit onderdeel echter als niet-ESB-infrastructuurtechnologie.

Ten slotte is de functie van de B2B Gateway-component ervoor te zorgen dat de diensten van elk van twee of meer organisaties op een gecontroleerde en veilige manier beschikbaar zijn voor alle andere organisaties. Het is handig om te denken dat deze componenten verbonden zijn met de ESB, maar er geen deel van uitmaken. Hoewel er poorten zijn technologieën, het leveren van de functies die nodig zijn om zowel de B2B Gateway-componenten als de ESB zelf te implementeren afspraak de B2B Gateway-component scheidt het van de ESB. Dit onderdeel kan inderdaad aanvullende tools nodig hebben om zijn functies uit te voeren, zoals tools voor partnerrelatiebeheer die geen deel uitmaken van de ESB en niet noodzakelijkerwijs worden ondersteund door ESB-technologieën.

ESB-prestatiemodel

Vat en categoriseert enkele van de ESB-functies die in de beschikbare literatuur worden beschreven (zie sectie). Hoewel sommige van deze functies eenvoudig zijn, vormen andere, zoals autonomie en slimme functies, een belangrijke stap in de richting van een On Demand-omgeving. Het is belangrijk om te begrijpen dat voor de meeste bestaande ESB-gebruiksscenario's slechts enkele van deze functies uit sommige categorieën vereist zijn. O minimaal een reeks functies die nodig zijn om een ​​ESB te implementeren, we zullen het in de sectie hebben: Minimale ESB-functieset voor SOA.

Tabel 1. ESB-functies beschreven in gespecialiseerde literatuur

Veel van deze functies kunnen worden geïmplementeerd met behulp van geschikte technologieën of met behulp van open standaarden... Maar de technologieën die beweren te worden gebruikt in een ESB-implementatie kunnen sterk variëren in termen van prestaties, schaalbaarheid en beschikbaarheid, evenals welke ESB-functies en open standaarden ze ondersteunen. Om deze redenen, en omdat sommige van de relevante normen recentelijk zijn ontwikkeld of nog in ontwikkeling zijn, zijn vele van cruciaal belang: belangrijke beslissingen Bij ESB-implementaties moet momenteel een afweging worden gemaakt tussen het ondersteunen van volwassen, gevestigde technologieën en minder volwassen open standaarden.

In deze serie artikelen zal ik niet in detail treden op elk van deze categorieën functies. In plaats daarvan zullen we ons concentreren op die die relevant zijn voor de besluitvorming bij het kiezen van een benadering voor het implementeren of implementeren van een ESB. In de volgende sectie zullen we ons specifiek concentreren op de minimale functionaliteit die vereist is om SOA te ondersteunen door een ESB-implementatie.

Minimale ESB-functieset voor SOA

Als voor de meeste SOA-scenario's slechts een subset van de eerder genoemde functies relevant is, kunnen we de volgende vraag stellen: welke functies zijn opgenomen in minimum de set functies die nodig zijn om een ​​ESB te implementeren? Om deze vraag te beantwoorden, zullen we kijken naar de meest voorkomende elementen van de ESB-definitie die niet al te controversieel zijn:

• Een ESB is een logische architectuurcomponent die een integratie-infrastructuur biedt die consistent is met SOA-principes;
• SOA vereist het gebruik van implementatie-onafhankelijke interfaces, communicatieprotocollen die de implementatietransparantie en interoperabiliteit verbeteren, en servicedefinities die relatief klein zijn in detail en herbruikbare functionaliteit inkapselen;
• ESB kan worden geïmplementeerd als een gedistribueerde heterogene infrastructuur;
• De ESB biedt de tools om de service-infrastructuur te beheren en stelt u in staat te opereren in de gedistribueerde, heterogene omgeving van vandaag.

Het volgende is een minimale set ESB-functies die met deze principes in gedachten zijn geselecteerd.

Tabel 2. De minimale set ESB-functies

Houd er rekening mee dat de minimale functieset vereist geen gebruik van specifieke technologieën zoals EAI-middleware, webservices, J2EE of XML. Het is waarschijnlijk dat dergelijke technologieën zullen worden gebruikt als ze aan de vereisten voldoen, maar dit is niet vereist. Omgekeerd, de minimale set functies van bijna, zo niet volledig, wordt geleverd door het eenvoudige gebruik van SOAP / HTTP en WSDL.

• URL-adressering en de bestaande HTTP- en DNS-infrastructuur bieden een "bus"-infrastructuur voor serviceroutering en transparantie van plaatsingen;
• SOAP / HTTP ondersteunt het berichtenparadigma aanvraag antwoord;
• Het HTTP-transportprotocol is algemeen verkrijgbaar;
• SOAP en WSDL bieden een open, implementatie-agnostisch model voor interface-organisatie en serviceberichten.

Het gebruik van SOAP / HTTP en WSDL in zijn eenvoudigste vorm biedt echter eigenlijk alleen point-to-point-integratie en biedt niet de volgende belangrijke functionaliteit die vereist is voor een ESB:

• Afwezig administratie functie adressering en naamgeving van services beheren Servicenamen worden door elke adapter afzonderlijk beheerd, zodat de serviceroutering wordt gedeeld tussen de adressen die worden aangeroepen door de serviceclients, de HTTP-infrastructuur en de servicenamen die aan de adapters zijn toegewezen;
• Hoewel deze benadering afhankelijk is van implementatiedetails, draagt ​​deze niet bij aan het bieden van een vervanging voor de service-implementatie; serviceverzoekercode (mogelijk gegenereerd door ontwikkelingstools) zal vaak direct gekoppeld zijn aan een specifieke serviceproviderimplementatie via specifieke protocollen op specifieke adressen. Het vervangen van een service-implementatie door een andere implementatie vereist wijzigingen in de applicatiecode en herimplementatie.

Natuurlijk vereisen veel of zelfs de meeste scenario's extra functionaliteit die in de loop van de tijd gebruikelijker zal worden. Concreet zullen de volgende soorten vereisten waarschijnlijk leiden tot meer geavanceerde technologieën, nu of in de toekomst:

• Functies om de kwaliteit van de dienstverlening en het serviceniveau te waarborgen;
• SOA-concepten Meer hoog niveau- dienstchoreografie, catalogus, conversie, enz.;
• On Demand-vereisten voor de besturingsomgeving, zoals autonomie en beheerfuncties en infrastructuurintelligentie;
• Echt heterogene operaties over meerdere netwerken, meerdere protocollen en meerdere domeinen met verschillende eigendomsmodellen.

ESB-beveiligingsproblemen

Dit artikel is niet bedoeld om de beveiligingsvereisten zelf aan te pakken, maar ze kunnen een verschil maken bij het kiezen van een ESB-technologie. Als er bijvoorbeeld geen authenticatie en autorisatie van verzoeken aan de server nodig is, dan kan de keuze aan technologieën zeer uitgebreid zijn. Als een bepaald beveiligingsniveau vereist is, wat waarschijnlijker is, dan is het belangrijk om te beoordelen welke beveiligingsstijl acceptabel is. Bijvoorbeeld:

1. Zal het beveiligingsniveau van de communicatie-infrastructuur acceptabel zijn bij gebruik van wederzijdse authenticatie via het protocol van secure Beveiligde verbindingen Socket Layer EAI tussen EAI middleware-servers of HTTPS gebruiken?
2. Is point-to-point individuele beveiliging voldoende tussen deelnemende systemen of is een end-to-end beveiligingsmodel nodig? Is het bijvoorbeeld nodig om klantreferenties te distribueren via tussenliggende systemen zoals makelaars, end-to-end providers of service-implementaties?
3. Zou de beveiliging op de applicatielaag acceptabel zijn, kan de clientcode bijvoorbeeld basis HTTP-authenticatie uitvoeren met een gebruikers-ID en wachtwoord, of kan deze informatie als applicatiegegevens aan de service worden doorgegeven?
4. Moet de beveiligingsengine voldoen aan beveiligingsstandaarden zoals Kerberos of WS-Security?

Hoewel alle bovenstaande benaderingen van veiligheid, wordt aanbevolen om standaard-compatibele (bijv. WS-Security) beveiligingsfuncties te gebruiken, ondersteund door infrastructuur en middleware. Deze standaarden zijn echter relatief recent verschenen en ondersteunen ze softwareproducten bevindt zich nog in de ontwikkelingsfase, vooral in zaken die verband houden met het waarborgen van interoperabiliteit. Daarom zou een van de prioriteiten van de ESB-architectuur moeten zijn om de beveiligingsvereisten vroeg in de ontwikkelingsfase goed te keuren, zodat hiermee rekening kan worden gehouden bij het kiezen van een implementatietechnologie.

Conclusie

Dit artikel sprak het meest over algemene principes SOA en hun relatie met technologie voor webservices. Op basis van deze principes stelt de auteur dat de infrastructuurcomponent die de routeringsfunctie biedt, de interactie van services met elkaar moet garanderen, evenals ondersteuning voor het vervangen van de ene service-implementatie door een andere implementatie. Deze functies worden, naast vele andere, geïmplementeerd via de ESB.

De ESB biedt gedistribueerde infrastructuur en gecentraliseerde beheerfunctionaliteit waarvoor een servicerouteringsdirectory en optioneel een zakelijke servicedirectory vereist zijn. Business Service Choreograaf roept diensten aan van de ESB en stelt vervolgens processen als nieuwe diensten bloot via de ESB.

Onder de vele functies die door de ESB worden geboden, zijn er functies:

• Aansluitingen;
• Service-interacties;
• integratie;
• Zorgen voor de kwaliteit van de dienstverlening;
• Veiligheid;
• Zorgdragen voor het serviceniveau;
• Berichtverwerking;
• Servicemanagement en autonomie;
• Modellering;
• Intelligente infrastructuurfuncties.

In het volgende artikel in de serie kijken we naar veelvoorkomende scenario's, geschikte scenariobeslissingspatronen en bespreken we de meest voorkomende problemen in verband met die scenario's.

Dankbetuigingen

Dit artikel zou nauwelijks zijn gepubliceerd als de auteur zijn ideeën niet had besproken met de volgende mensen: Beth Hutchison, Rachel Reinitz, Olaf Zimmerman, Helen Wylie, Kyle Brown (Kyle Brown, Mark Colan, Jonathan Adams, Paul Fremantle, Keith Jones, Paul Verschueren, Daniel Sturman, Scott Cosby Cosby, Dave Clarke, Ben Mann, Louisa Gillies, Eric Herness, Bill Hassell, Guru Vasudeva, Kareem Yusuf), Ken Wilson, Mark Endrei, Norbert Bieberstein, Chris Nott, Alan Hopkins en Yaroslav Dunchych.

Applicatie-integratie is een vraag waarmee de IT-afdeling van elke organisatie met meer dan één van deze applicaties vroeg of laat wordt geconfronteerd. Hier is een verre van volledige lijst van taken die passen in het concept van "integratie":

• de noodzaak om algemene telefoonboeken bij te houden (bijvoorbeeld klanten- of werknemerslijsten);
• het starten van activiteiten in het ene informatiesysteem wanneer zich gebeurtenissen voordoen in een ander;
• een bedrijfsproces (een georganiseerde opeenvolging van acties die worden uitgevoerd door zowel mensen als informatiesystemen), die in verschillende applicaties plaatsvinden;
• informatie-interactie met zakenpartners (bijvoorbeeld automatische prijsaanvraag voor componenten van een leverancier);
• eenwording van informatie-uitwisselingen en bedrijfsprocessen in de vestigingen van het bedrijf.

Als dergelijke acties zelden worden uitgevoerd in de onderneming (bijvoorbeeld één keer per dag), kunnen deze acties op een ambachtelijke manier worden georganiseerd - bijvoorbeeld door handmatig gegevens van de ene applicatie naar de Excel-formaat en ze in een andere toepassing te laden of, in het algemeen, dubbele invoer van informatie in twee systemen tegelijk te gebruiken. Als de behoefte aan informatie-interactie tussen applicaties echter vele malen per dag ontstaat, rijst de vraag over het ineffectieve gebruik van human resources en dientengevolge ontstaat de noodzaak om deze procedure te automatiseren.

Point-to-Point integratie

De point-to-point integratietaak is relatief eenvoudig. Het is noodzakelijk om te begrijpen hoe elk van de twee op elkaar inwerkende systemen klaar is om gegevens te verzenden en te ontvangen, passende technische oplossingen te creëren voor toegang tot deze interfaces en ook een mechanisme te implementeren voor het converteren van gegevens van het bronsysteemformaat naar het ontvangersysteemformaat. In het beste geval bieden informatiesystemen een speciale programmeerinterface (API) voor integratie, en in het slechtste geval moet informatie rechtstreeks worden gelezen en geschreven naar de applicatiedatabase. Als resultaat verschijnt er een lokale integratieoplossing - een soort aparte softwaremodule zelf ontwikkeld met alle daaruit voortvloeiende eisen voor het onderhoud en het up-to-date houden ervan.

Point-to-point integratie

Dit komt niet neer op groot probleem zolang er maar weinig point-to-point-integraties zijn - een of twee. De praktijk leert echter dat het aantal point-to-point integraties de neiging heeft toe te nemen, en de kwaliteit van het beheer van deze integraties juist snel afneemt. Daar zijn veel redenen voor: het aantal integratiemodules neemt toe, de ontwikkelaars die deze of gene module hebben gemaakt verlaten de organisatie, de dataformaten in de geïntegreerde systemen veranderen, etc. Het trieste resultaat van de evolutionaire ontwikkeling van punt-naar-punt integraties is de meest complexe "vulling" van integratie-interacties tussen bedrijfsapplicaties, de houding waartegen de medewerkers van de IT-afdeling het gemakkelijkst in een paar woorden kunnen uitdrukken: "Terwijl het werkt , is het beter om het niet aan te raken." Deze situatie past echter noch de IT-afdeling zelf, noch de zakelijke klanten.

Integratie "vulling"

Enkele service bus

Na verschillende generaties verschillende benaderingen voor het integreren van applicaties te hebben doorlopen, is de wereldwijde software-industrie tot het concept van de Enterprise Service Bus (ESB) gekomen. Vanuit architectonisch oogpunt is ESB een softwareoplossing waarmee alle geïntegreerde applicaties op een uniforme manier via één enkel punt kunnen communiceren, waardoor ontwikkelaars en beheerders uniforme en gecentraliseerde tools krijgen voor het ontwikkelen, testen en bewaken van de stroom van alle integratie scenario's.

De belangrijkste onderdelen van een moderne servicebus zijn:

• Een message broker is een krachtige backbone voor realtime unified messaging tussen applicaties;
• adapters - technologische adapters en adapters voor bedrijfssystemen bieden interactie met applicaties in het formaat dat voor hen acceptabel is, waarbij informatie uit deze berichten wordt gepresenteerd in een uniform formaat dat door de broker wordt waargenomen - hoe meer verschillende adapters een bepaald integratieplatform biedt, hoe meer kansen. dat u voor de implementatie ervan in uw organisatie geen extra werk om adapters te maken die specifiek zijn voor uw systemen;
• ontwikkelomgeving voor integratiescripts - hoe gemakkelijker en sneller de ontwikkeling van integratiescripts, hoe minder investeringen in deze ontwikkeling en dus hoe sneller het rendement op de investering. Een moderne integratiebus biedt een ontwikkelaar visuele hulpmiddelen voor het construeren van integratiescenario's, die het in de meeste gevallen mogelijk maken om het zonder codering op laag niveau te doen;
• SOA-tools - naleving van de principes van servicegerichte architectuur is de onvoorwaardelijke standaard voor alle integratieoplossingen zoals "single service bus" (zoals de naam al aangeeft). Informatiesystemen worden hier beschouwd als aanbieders en afnemers van diensten, alle op de bus gepubliceerde diensten worden in één register geplaatst met de mogelijkheid hergebruiken en het beheren van beleid met betrekking tot diensten;
• verschillende controle- en beheertools (audits, logging, centrale monitoring, controle op de naleving van de service level agreement, enz.).

De voordelen van het gebruik van een enkele servicebus zijn onder meer:

• schaalbaarheid - de mogelijkheid om oplossingen van elke grootte en belasting te bouwen;
• flexibiliteit - het vermogen om integratiescenario's te implementeren en te wijzigen zonder noemenswaardige betrokkenheid van ontwikkelaars;
• beveiliging - ingebouwde authenticatie- en autorisatietools bieden controle over de toegang tot services op het niveau van de bus zelf, waardoor ontwikkelaars van integratiescenario's worden ontlast van de taak om deze mechanismen te implementeren;
• het gebruik van open standaarden - hiermee kunt u de betrokkenheid van dure specialisten bij eigen technologieën verminderen;
• centralisatie van controle- en beheertools - vermijdt "vervaging" van het verantwoordelijkheidspunt voor integratiescenario's, zorgt voor operationele monitoring en vroege waarschuwing bij storingen.

Een andere belangrijke vereiste voor de functionaliteit van de ESB-omgeving is de mogelijkheid om integratie met externe organisaties te implementeren - zakenpartners, leveranciers, zakelijke klanten, externe vestigingen. De eigenaardigheden van een dergelijke integratie zijn de onvoorspelbare kwaliteit van kanalen, gebrek aan garanties voor de levering van informatie en slechte gereedheid voor integratie als zodanig - in de regel biedt de partnerorganisatie een zeer beperkt scala aan formaten voor gegevensuitwisseling. In dit geval moet de integratiebus een middel bevatten om B2B-interactie te bouwen, wat het mogelijk maakt: uitwisseling van informatie volgens open, inclusief industriestandaarden, om gegarandeerde levering te garanderen, om tools te hebben voor het opzetten van informatie-uitwisseling in de context van een specifieke zakenpartner en, natuurlijk, om te werken in volledige overeenstemming met de principes van het integratieplatform zelf, het isoleren van de ontwikkelaar van integratiescenario's van technische details interactie met een partner.

Enterprise Service Bus

Beheer van bedrijfsprocessen

Een aanzienlijk deel van de integratiescenario's impliceert dat niet alleen applicaties die fungeren als informatiebron of ontvanger van informatie betrokken zijn bij informatie-uitwisseling, maar ook mensen - medewerkers van de organisatie die verschillende taken uitvoeren of beslissingen nemen. In dit geval kunnen we praten over verder gaan dan de reikwijdte van "pure" integratie en het verschijnen in de focus van onze aandacht van een nieuwe entiteit - bedrijfsprocessen en in de vereisten voor het integratieplatform - nieuwe functionaliteit voor het beheren van bedrijfsprocessen ( Bedrijfsprocesbeheer, BPM). Als er BPM-vereisten zijn, moet het integratieplatform de ontwikkelaar voorzien van:

• een visuele ontwerptool voor bedrijfsprocessen - het is optimaal dat deze tools kunnen worden gebruikt door mensen ver van IT, zoals bedrijfsanalisten of methodologen. Bovendien is de mogelijkheid om bedrijfsprocesmodellen over te dragen van gespecialiseerde tools modelleren in de ontwikkelomgeving. Dezelfde tool moet het mogelijk maken om de taakvormen voor de deelnemers aan de processen te ontwerpen, en bovendien ontwikkelaars zoveel mogelijk te beschermen tegen programmeren;
• omgeving voor de uitvoering van bedrijfsprocessen - een speciale engine die zorgt voor de verwerking van bedrijfsregels, de overdracht van taken tussen gebruikers en informatiesystemen in overeenstemming met de ontwikkelde modellen van bedrijfsprocessen, evenals de verwerking van uitzonderlijke situaties (bijvoorbeeld de uitvoerder overschreden de toegewezen tijd voor de taak);
• portaal van deelnemers aan bedrijfsprocessen - een gespecialiseerd portaal waarmee gebruikers processen kunnen starten, eraan kunnen deelnemen en de voortgang kunnen controleren lopende processen en het uitvoeren van administratieve handelingen in overeenstemming met de voor hen vastgestelde rechten;
• controle- en controletools. Het vermogen om snel en retrospectief de stroom van bedrijfsprocessen te analyseren is een belangrijk onderdeel van elk BPM-platform.

Op dit moment Veel softwareleveranciers hebben de neiging om de BPM-omgeving en de integratiebus te combineren tot één enkel middlewareplatform, waardoor de strikte scheiding die al jaren bestaat tussen BPM-systemen en applicatie-integratietools wordt opgeheven. Deze aanpak is zeer vooruitstrevend. Sommige leveranciers gaan zelfs nog verder en koppelen professionele tools voor het modelleren van bedrijfsprocessen aan het platform. Een pionier hierin is Software AG, dat een oplossing biedt die de befaamde ARIS Platform-modelleringstool en de webMethods-integratie / BPM-omgeving combineert.

Complex gebruik van het integratieplatform

Marktaanbiedingen

Op dit moment Er zijn drie groepen softwareaanbiedingen voor het bouwen van ESB's. Deze groepen variëren in zowel prijs als aangeboden functionaliteit.

De eerste groep bestaat uit voorstellen van bedrijven waarvan de producten toonaangevend zijn in het onderzoek van analytische bureaus in alle categorieën die in het artikel worden genoemd (ESB, SOA Governance, BPM, B2B). Deze groep omvat:

• IBM met de WebSphere-productlijn;
• Software AG met webMethods-integratieplatform;
• Oracle met een hele reeks voorstellen;
• Tibco met Business Integration-lijn.

In principe kunnen degenen die niet van compromissen houden, kiezen voor een van deze fabrikanten - alle beursgenoteerde bedrijven bieden volwaardige productlijnen (in het geval van Oracle is het echter niet altijd duidelijk om welk product het gaat, aangezien na aankoop van een aantal bedrijven biedt Oracle direct meerdere producten aan die niet altijd voldoende met elkaar zijn geïntegreerd). Tibco valt een beetje op, aangezien de omvang van dit bedrijf veel kleiner is dan de omvang van de andere leden van de vier, wat twijfel kan doen rijzen over de stabiliteit ervan. Software AG - nog niet erg bekend in Russische markt fabrikant, maar het webMethods-platform, dat vandaag het belangrijkste aanbod van dit bedrijf is, heeft een groot potentieel. Veel ondernemingen kennen en gebruiken IBM en zijn producten al, maar sommigen hebben klachten over de kosten van de implementatie en het onderhoud van het systeem.

De tweede groep voorstellen zijn bedrijven die zich vooral richten op "pure" ESB-functionaliteit en hier succes hebben geboekt. Deze groep omvat: Sun (Glassfish), Progress (Sonic) en Fujitsu.

Het aanbod van deze bedrijven is goed als u het bereik van uw platform niet wilt vergroten richting BPM en/of B2B. Anders loopt u het risico alleen te blijven met onvoldoende ontwikkelde functionaliteit en uw kosten voor de voltooiing ervan aanzienlijk te verhogen om aan uw behoeften te voldoen.

De derde groep is het talrijkst en omvat alle voorstellen die niet in de vorige twee groepen zijn opgenomen. Het is zinloos om alle voorstellen over het ESB-onderwerp in dit artikel op te sommen, je kunt zo'n lijst in elke zoekmachine krijgen. Als uw integratiebudget beperkt is en u zelf geneigd bent te experimenteren, kunt u met elk van hen uw geluk beproeven. De risico's hebben echter te maken met zowel onvoldoende ontwikkelde functionaliteit als: eventuele problemen met betrouwbaarheid, technische ondersteuning enen, neem je het op je.

Conclusie

Tot slot wil ik de lezers enkele eenvoudige tips geven voor het kiezen van een integratiebus:

• Overweeg een integratieoplossing te bouwen zonder te wachten op problemen met de interoperabiliteit van applicaties die u tegen de muur duwen. Hoe groter de verstopping, hoe moeilijker het is om deze te verhelpen;
• kies zorgvuldig een platform. Zoek een leverancier die je op alle vlakken tevreden stelt, want er is nu genoeg om uit te kiezen. Je moet geïnteresseerd zijn in zowel de technologische parameters van het platform als de methodologische aspecten van implementatie;
• nadenken over perspectief. Functionele vereisten, waarvan u zich nu bewust bent, kan in een jaar aanzienlijk veranderen, en als het platform ze niet bevredigt, moet u naar een ander "verhuizen". En één oversteek, zoals je weet, is gelijk aan twee branden.