), voorheen Axelot Datareon ESB genaamd, is bedoeld voor het bouwen van een gedistribueerd informatielandschap van een onderneming. Het softwareproduct zorgt voor de interactie van alle geïntegreerde applicaties in één centrum, combineert bestaande informatiebronnen en zorgt voor gecentraliseerde gegevensuitwisseling tussen verschillende informatiesystemen.

De Datareon ESB-bedrijfsdataservicebus is een middel om de stabiliteit en volledigheid van de informatie-uitwisseling te garanderen, de algehele prestaties van het informatiesysteem te verbeteren en de arbeidskosten voor de administratie ervan te verlagen.

Het Datareon ESB-softwareproduct is officieel opgenomen in het uniforme register van Russische programma's voor elektronische computers en databases, dat kan worden gekocht door staats- en gemeentelijke instellingen.

Functionaliteit

• Ondersteunt verschillende standaarden en integratiescenario's
• Beheer uw integratielandschap centraal met het Eclipse-ecosysteem
• Datatransformatie (meerstaps algoritmen voor datatransformatie met controle over verschillende omstandigheden)
• Gegevens van elke grootte overbrengen (verticaal en horizontaal schalen)
• Eenvoudige integratie met producten op het 1C:Enterprise 8-platform
• Zorgen voor veilige gegevensoverdracht
• Diagnose en bewaking van de toestand van het gehele datatransmissienetwerk

Problemen die moeten worden opgelost

• Gegevensoverdracht tussen verschillende informatiesystemen (met routing of point-to-point)
• Vorming van een enkele informatieruimte in heterogene omgevingen
• Opbouw van een gedistribueerd systeem op basis van het gebeurtenismodel in de volgende opties:
  • het bouwen van applicaties met end-to-end bedrijfsprocessen op basis van een gebeurtenismodel;
  • creatie van een systeem met synchronisatie van bedrijfsapplicaties in verschillende informatiesystemen
• Het verkrijgen van een schaalbare managementarchitectuur op ondernemings-/holdingniveau
• Implementatie van een gegevensuitwisselingssysteem op transportniveau en op bedrijfslogicaniveau
• Het delegeren van de taak om informatiestromen op te bouwen naar analytische afdelingen
• Verminderde algehele complexiteit van het integratieontwerp en verminderde kanaaldoorvoervereisten
• Verhoogde algehele stabiliteit van de datatransportlaag
• Het verlagen van transactiekosten bij het uitwisselen van gegevens tussen verschillende afdelingen

2017

Axelot Datareon ESB 2.1.0.0

De AXELOT Datareon ESB-oplossing werd opgenomen in de lijst van Gold Application Development-competenties - een feit dat de hoge kwaliteit van het product en de compatibiliteit ervan met Microsoft-producten bevestigt.

AXELOT Datareon ESB biedt een aantal belangrijke voordelen voor bedrijven:

• Mogelijkheid tot integratie;
• Betrouwbaarheid en herbruikbaarheid van middelen;
• Het verkrijgen van een schaalbare managementarchitectuur op ondernemings-/holdingniveau;
• Het delegeren van de taak om informatiestromen op te bouwen naar analytische afdelingen;
• Het verminderen van de algehele complexiteit van het integratieschema en het verminderen van de vereisten voor kanaaldoorvoer;
• Het vergroten van de algehele stabiliteit van de laag voor transportgegevensoverdracht;
• Het verlagen van transactiekosten bij het uitwisselen van gegevens tussen verschillende afdelingen;
• Het verlagen van de totale kosten voor het onderhouden en onderhouden van het informatiesysteem.

Belangrijkste kenmerken van het systeem:

• Een groot aantal connectoren voor diverse systemen: 1C:Enterprise 8, SOAP services, REST services, MS SQL, IBM DB2, Oracle DB, PostgreSQL, SharePoint, OData, TCP, Siemens TeamCenter en anderen;
• Plug-inmechanisme voor zelfontwikkeling van connectoren;
• Ondersteuning voor verschillende programmeertalen en technologieën bij het ontwikkelen van interactiescenario's: 1C:Enterprise 8, JavaScript, T-SQL;
• Het opzetten vanio's met behulp van visuele mappingmechanismen en aangepaste XSLT-transformaties;
• Werken met verschillende dataformaten (XML, JSON, XLS, DBF, CSV, Base64 en andere);
• Statische en dynamische routering van informatiepakketten;
• Hoge interactiesnelheid en fouttolerantie: verminderde vereisten voor netwerkbandbreedte, taakverdeling, isolatie van informatiedomeinen, mogelijkheid om de status van integratieknooppunten te bewaken;
• Ondersteuning voor het evenementenmodel, synchrone en asynchrone oproepen, gegarandeerde levering;
• Het wijzigen van integratiescenario’s van abonneesystemen (ontladen/laden, transformatie- en routeringsmechanismen) in een ‘hot’-modus zonder de noodzaak om ze te stoppen (inclusief configuraties op het 1C:Enterprise 8-platform);
• Diagnostiek en monitoring van alle integratieprocessen, de mogelijkheid om informatiepakketten te debuggen en te traceren.

Bijzondere aandacht wordt besteed aan de integratie van applicaties op het 1C:Enterprise 8-platform. De levering omvat een speciaal subsysteem dat in elke standaardconfiguratie op het 1C:Enterprise 8-platform kan worden ingebouwd en dat alle noodzakelijke mechanismen biedt voor een snelle en gemakkelijke installatie en beheer van de integratie. De interactie van "AXELOT: ESB Service Data Bus" met de configuratie op het 1C:Enterprise 8-platform wordt uitgevoerd via SOAP- en REST-services.

Servercomponenten "AXELOT: ESB Service Data Bus" zijn ontwikkeld in C++. Het beheer en de configuratie van "AXELOT: ESB Service Data Bus" wordt uitgevoerd in de Eclipse-ontwikkelomgeving en kan worden uitgevoerd in combinatie met de ontwikkeling van systemen op het 1C:Enterprise 8-platform in 1C:Enterprise Development Tools. "AXELOT: ESB Service Data Bus" is multi-platform en ondersteunt MS Windows- en Linux-besturingssystemen.

AXELOT Datareon ESB is een volledig Russische ontwikkeling en wordt momenteel opgenomen in het uniforme register van Russische programma's voor elektronische computers en databases, die door staats- en gemeentelijke instellingen kunnen worden gekocht om bepaalde problemen op te lossen.

Moderne toepassingen opereren zelden geïsoleerd; een applicatie kan niets zinvols doen zonder interactie met andere applicaties. Servicegerichte architectuur integreert samenwerkingsapplicaties en versnelt deze door de applicatie op te delen in delen die met elkaar gecombineerd kunnen worden. Het SOA-model (serviceconsumenten bellen serviceproviders) lijkt misschien eenvoudig, maar brengt twee belangrijke problemen met zich mee:

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

Het blijkt dat er voor beide problemen een eenvoudige oplossing bestaat: een aanpak die Enterprise Service Bus (ESB) wordt genoemd. Een ESB maakt het voor zowel de consument als de aanbieder gemakkelijk om een ​​beroep te doen op een dienst, waarbij alle complexe interacties daartussen worden beheerd. ESB maakt het niet alleen gemakkelijk voor applicaties (of delen van applicaties) om een ​​dienst aan te roepen, maar helpt hen ook data te communiceren en gebeurtenismeldingen te verspreiden. ESB-ontwerp implementeert veel erkende ontwerppatronen en standaardspecificaties.

Ik heb dit artikel geschreven om jou, de ontwikkelaar, te helpen begrijpen waarom ESB een nuttig en noodzakelijk onderdeel is van applicatie-integratie, inclusief SOA. Dit artikel gaat niet over definities of producten, maar richt zich eerder op kenmerken en mogelijkheden van de ESB die u niet zelf hoeft te implementeren. In dit artikel leggen we uit wat ESB voor u doet.

Diensten bellen

Om u te helpen applicatie-integratie en SOA te begrijpen, zal ik eerst kijken naar hoe webservices werken. Webservices zijn de enige manier waarop u een serviceaanvraag kunt implementeren. Dit is misschien niet eens de beste manier, maar het is de meest gestandaardiseerde aanpak die momenteel beschikbaar is, en webservices helpen het ontwerp te begeleiden, 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 Uniforme bronidentificatie(URI - Uniform Resource Identifier) ​​​​welke aanbieder Webservices worden gebruikt om een ​​webservice beschikbaar te maken als eindpunt. De webserviceprovider gebruikt de eindpunt-URI als adres om de webservice te lokaliseren en aan te roepen. IN verzoek Er is een specifieke actie en parameters die de consument doorgeeft aan de webservice wanneer hij het eindpunt aanroept. Nadat de service is voltooid, verzendt het eindpunt antwoord terug naar de consument, die succes (of fout) meldt en het resultaat van de dienst bevat. Dat wil zeggen dat de consument het eindpunt van de provider belt, een verzoek verzendt en een antwoord terugkrijgt.

De huidige definitie van hoe een webservice moet worden geïmplementeerd is WS-I Basic Profile 1.1, dat bestaat uit het "SOAP 1.1 over HTTP 1.1"-protocol dat wordt beschreven in Web Services Description Language (WSDL) 1.1 (een link naar de specificatie zelf vindt u in het gedeelte " "). Bij SOAP via HTTP roept de consument een service aan met behulp van een SOAP-verzoek dat via HTTP wordt verzonden in een HTTP-verzoek. De consument blokkeert synchroon op de HTTP-socket en wacht op een HTTP-antwoord met een SOAP-antwoord. De API van een eindpunt wordt beschreven door de WSDL, een contract tussen de consument en de serviceprovider.

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

Vergelijking van synchrone en asynchrone oproepen

De consument kan de dienst zowel synchroon als asynchroon aanroepen. Vanuit het oogpunt van de consument zijn de verschillen als volgt:

• Synchronisch. De consument gebruikt één thread om de service aan te roepen; de thread verzendt een verzoek, blokkeert terwijl de service actief is en wacht op een reactie;
• Asynchroon. De consument gebruikt twee threads om de service aan te roepen; één is voor het verzenden van een verzoek, de tweede is voor het ontvangen van een antwoord.

Concepten asynchroon En synchroon vaak verward met concepten consistent En parallel. Deze laatste concepten verwijzen naar de volgorde waarin verschillende taken worden uitgevoerd synchroon En asynchroon omgaan met de manier waarop een thread een enkele taak uitvoert, zoals het aanroepen van een enkele service. Een goede manier om het verschil tussen een synchrone en een asynchrone oproep te begrijpen, is door na te denken over de gevolgen van crashherstel:

• Synchronisch. Als een consument een crash ervaart terwijl hij wordt geblokkeerd terwijl een service actief is, kan hij na een herstart geen verbinding meer maken met die service, waardoor de reactie verloren gaat. De consument moet het verzoek herhalen en hopen dat er geen sprake is van een noodsituatie;
• Asynchroon. Als een consument tijdens het wachten op een reactie op een verzoek een noodsituatie ervaart, kan de consument na een herstart blijven wachten op een reactie, waardoor de reactie niet verloren gaat.

Herstel van fouten is niet het enige verschil tussen synchrone en asynchrone oproepen, maar als u probeert de stijl van de specifieke oproep die wordt gebruikt te bepalen, kan het kijken naar crashherstel hierbij helpen.

Nu u weet hoe u een interactieoptie kiest wanneer u een dienst belt, gaan we eens kijken naar de mogelijkheden om een ​​consument met een aanbieder te verbinden. De consument kan kiezen uit de volgende aansluitmogelijkheden:

1. Synchrone directe oproep;
2. Synchrone oproep via een tussenpersoon (makelaar);
3. Asynchrone oproep via een tussenpersoon (makelaar).

Ik zal elke optie afzonderlijk bekijken

Synchrone directe oproep

De SOAP via HTTP-aanroepmethode voor de webservice is direct: net als bij een functieaanroep kent de consument het adres van het eindpunt en roept dit rechtstreeks aan. Voor een succesvol gesprek moet de webservice functioneren wanneer de consument het eindpunt belt en moet reageren voordat de consument een time-out krijgt. Als de webservice op een nieuwe locatie wordt geïmplementeerd (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 ​​specifieke dienstverlener te kunnen selecteren, moet de consument elke URI kennen.

Neem bijvoorbeeld een eenvoudige webservice voor aandelenkoersen: de consument geeft een aandelensymbool door en ontvangt de huidige waarde ervan terug. Een dergelijke dienst kan worden geleverd door verschillende makelaarsbedrijven, die elk hun eigen URI hebben. 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 dat adres is, moet de consument weten voordat hij het adres kan opvragen.

Om dit probleem op te lossen, is er een UDDI-specificatie (Universal Description Discovery and Integration) 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 adres dat goed bekend is bij de consument; de consument kan UDDI gebruiken om andere webdiensten te vinden.

In de situatie van de 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 het eindpunt van dienstverleners op het gebied van aandelenkoersen te vinden en een van hen te bellen. Het proces volgt het volgende algoritme:

1. De consument vraagt ​​bij UDDI een lijst met dienstverleners op;
2. De consument selecteert een providereindpunt uit een lijst verkregen van UDDI;
3. De consument noemt dit eindpunt.

Ik merk op dat het algoritme voor het kiezen van een aanbieder volledig afhankelijk is van de consument; in dit voorbeeld selecteert de consument eenvoudigweg de eerste in de lijst. In een echte situatie kan deze keuze moeilijker zijn.

Ik merk ook op dat, aangezien het eindpunt van een dienst kan veranderen, een consument elke keer dat hij een dienst wil bellen, hij de UDDI opnieuw moet opvragen en moet controleren of de providerinformatie is veranderd. Als u bij elke serviceoproep een UDDI-verzoek moet indienen, brengt dit extra overhead met zich mee, vooral in de normale situatie waarin de providerinformatie niet verandert.

Synchrone oproep via een tussenpersoon

Het nadeel van een directe oproep is dat de consument de URI van het eindpunt van de provider moet kennen om de dienst te kunnen bellen. Het gebruikt UDDI als map om deze URI op te zoeken. Als er meerdere providers zijn, bevat de UDDI meerdere URI's en moet de consument er één selecteren. Als de provider de eindpunt-URI wijzigt, moet hij zich opnieuw registreren bij de UDDI-server zodat UDDI de nieuwe URI kan opslaan. De consument moet UDDI opnieuw aanvragen om een ​​nieuwe URI te verkrijgen. In wezen betekent dit dat elke keer dat een consument een dienst wil aanroepen, hij de UDDI moet opvragen voor de URI's van de eindpunten en er één moet selecteren. Dit resulteert in aanzienlijke inspanningen voor de consument tijdens de periodieke handelingen van het opvragen van UDDI en het selecteren van een provider. Deze aanpak dwingt de consument ook om op een of andere manier een aanbieder te selecteren, vermoedelijk uit een gelijkwaardige lijst.

Eén manier om het probleem te vereenvoudigen is het introduceren van een makelaar die als tussenpersoon fungeert bij het aanroepen van een webservice. De consument belt niet meer rechtstreeks naar de dienst van de aanbieder, maar belt naar de proxydienst van de makelaar, die op zijn beurt de dienst van de aanbieder belt. De consument moet de URI van het eindpunt van de proxyservice kennen en gebruikt daarom UDDI om het adres op te zoeken, maar in dit geval retourneert UDDI slechts één URI en hoeft de consument geen keuze te maken. De consument is zich er misschien niet eens van bewust dat het eindpunt een proxyservice is; het weet alleen dat het deze URI kan gebruiken om een ​​webservice aan te roepen. De makelaar verbindt de consument met dienstverleners (zie figuur 3).

De proxyservice-URI moet stabiel zijn: nadat een consument UDDI heeft gebruikt om de proxyservice-URI te verkrijgen bij de eerste aanroep van de service, kan de consument die URI hergebruiken voor opeenvolgende oproepen (tenminste totdat de proxyservice niet meer actief is). Ondertussen houdt de proxyservice de providers bij, hun URI's (die tussen oproepen kunnen veranderen), hun beschikbaarheid (of de laatste oproep is mislukt), hun belasting (hoe lang de laatste oproep heeft geduurd), enz. De proxydienst kan de verantwoordelijkheid overnemen om voor elk gesprek de beste aanbieder te selecteren, waardoor de consument van deze last wordt ontlast. De consument belt simpelweg elke keer dezelfde proxydienst en deze coördineert met verschillende providers.

Figuur 4 laat zien hoe een consument een makelaar gebruikt bij het inroepen van een dienst. Het bedieningsalgoritme is als volgt:

1. De consument vraagt ​​UDDI om een ​​lijst met dienstverleners. De door UDDI geretourneerde URI is feitelijk een proxyservice. UDDI retourneert slechts één URI, niet meerdere, omdat de makelaar slechts één proxyservice heeft voor een bepaalde service;
2. De consument belt de service 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.

Houd er rekening mee dat de zorg voor het kiezen van een aanbieder bij de consument is weggenomen - deze keuze is geïmplementeerd in de proxyservice van de makelaar. Dit maakt het leven van de consument makkelijker. Het selectieproces bij de proxydienst mag immers niet afwijken van het proces dat de consument hanteert. Omdat de UDDI-server en de proxyservice echter zijn ingekapseld in de broker, kan bepaalde functionaliteit eenvoudig worden geïmplementeerd, zoals het in de cache opslaan van UDDI-informatie en het ontvangen van meldingen van de UDDI-server aan de proxyservice dat de in de cache opgeslagen informatie niet langer actueel is.

Houd er ook rekening mee dat, aangezien het proxyadres stabiel is, de consument niet bij elke serviceoproep voortdurend naar UDDI hoeft te vragen. Dat wil zeggen dat de consument slechts één keer UDDI hoeft aan te vragen, vervolgens het proxyserviceadres in de cache hoeft op te slaan en dit te gebruiken bij herhaalde oproepen naar de service. Dit vermindert de overhead bij het aanroepen van de dienst aanzienlijk.

Asynchrone oproep via een proxy

Het nadeel van de synchrone aanpak is dat de consument moet wachten tot de service is voltooid: de thread moet worden geblokkeerd terwijl de service actief is. Als de dienst 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 overbelast zijn), kan deze niet wachten. En zoals hierboven vermeld: als een consument tijdens een werkuitsluiting een noodgeval ervaart, zelfs na een herstart, gaat het antwoord verloren en moet het gesprek opnieuw worden geprobeerd.

Een veel voorkomende oplossing voor dit probleem is dat de consument de service asynchroon aanroept. Bij deze aanpak gebruikt de consument één thread om het verzoek te verzenden en een tweede om het antwoord te ontvangen. Dat wil zeggen dat de consument tijdens het wachten op antwoord geen werk hoeft te blokkeren en in de tussentijd ander werk kan doen. De consument is daardoor veel minder gevoelig voor de levensduur van de aanbieder.

De broker, waarmee een consument asynchroon een webservice kan aanroepen, wordt geïmplementeerd met behulp van een berichtensysteem dat berichtenwachtrijen gebruikt om een ​​verzoek te verzenden en een antwoord te ontvangen. Net als bij een synchrone proxyservice fungeren een paar berichtenwachtrijen als één adres dat door de consument wordt gebruikt om de service aan te roepen, ongeacht het aantal mogelijke providers dat luistert (zie figuur 5).

Deze aanpak maakt gebruik van het Request-Reply-patroon om een ​​webservice aan te roepen. In plaats van het HTTP-protocol dat is gespecificeerd in WS-I BP 1.1, kunnen transportfuncties nu berichtenwachtrijen uitvoeren. Het SOAP-verzoek en -antwoord zijn hetzelfde als bij de WS-I BP, maar ze zijn ingesloten in berichtensysteemberichten.

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

1. De consument geeft het SOAP-verzoek als bericht door aan de aanvraagwachtrij. De consument is klaar met zijn werk en kan de draad 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 het bericht kan ontvangen en zorgt ervoor dat slechts één aanbieder het bericht ontvangt. Hoe dit daadwerkelijk werkt, hangt af van de implementatie van het berichtensysteem;
3. De winnende aanbieder ontvangt een bericht van de aanvraagwachtrij;
4. De aanbieder voert de dienst uit;
5. De provider verzendt het SOAP-antwoord als bericht naar de antwoordwachtrij. De provider is nu klaar met zijn werk en kan zijn thread voor andere taken gebruiken (bijvoorbeeld wachten op het volgende verzoek);
6. De luisterende consumententhread ontvangt een bericht met een SOAP-antwoord.

Houd er rekening mee dat de functie voor providerselectie nu in het berichtensysteem is geïmplementeerd, waardoor het leven voor de consument gemakkelijker wordt. Houd er ook rekening mee dat als de consument een noodsituatie ervaart na het verzenden van het verzoek (en zelfs als het antwoord in de tussentijd gereed is), het berichtensysteem het antwoord in de antwoordwachtrij zal opslaan totdat de consument weer operationeel is.

Ik wil ook opmerken dat de consument UDDI niet gebruikt om naar wachtrijen voor verzoeken en antwoorden te zoeken. Er bestaat momenteel geen standaardservice voor het retourneren van een paar wachtrijadressen, dus de consument hoeft alleen maar de adressen te kennen. Ze zijn ofwel hardgecodeerd in het consumentenprogramma of worden erdoor gelezen vanuit een configuratiebestand. In de toekomst moeten we UDDI uitbreiden of een vergelijkbare service specificeren waar een consument om kan vragen om een ​​paar wachtrijen te definiëren om een ​​specifieke service aan te roepen.

Nu kent u de opties voor verbindingstypen voor beldiensten. Laten we eens kijken naar aanvullende integratiemogelijkheden die ook nuttig kunnen zijn, en vervolgens hoe we een ESB kunnen ontwerpen die ons deze mogelijkheden biedt.

Andere integratiemogelijkheden

ESB biedt ook de mogelijkheid om verder te gaan dan alleen serviceaanvragen en applicaties en delen van SOA te integreren met behulp van andere technologieën. Een serviceoproep is bijna altijd een bidirectionele handeling, wat betekent dat het verzoek van de consument naar de aanbieder wordt gestuurd en het antwoord in de andere richting. Andere integratietechnologieën werken als unidirectionele operaties, waarbij de afzender informatie naar de ontvanger verzendt en niet op een antwoord wacht; de ontvanger ontvangt eenvoudigweg de informatie zonder dat er een reactie nodig is.

Gegevensoverdracht

Soms hoeft een applicatie alleen maar gegevens door te geven aan een andere applicatie, zonder dat de ontvangersprocedure hoeft te worden aangeroepen en zeker zonder op het resultaat te wachten. De afzender hoeft de ontvanger niet te vertellen wat hij met de gegevens moet doen; het maakt die gegevens eenvoudigweg beschikbaar.

Voor de overdracht van gegevens kan een serviceaanroep worden gebruikt, wat overeenkomt met het aanroepen van een settermethode, maar de gegevensoverdracht wordt uitgevoerd volgens het RPC-principe. 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. Dit lijkt meer op een SOAP-bericht in documentstijl dan op een bericht in RPC-stijl.

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

Aanvullende informatie over de technologie voor gegevensoverdracht vindt u in het documentberichtsjabloon (voor meer informatie hierover, zie het boek " ", waarvan de link wordt gegeven in de sectie " ").

Gebeurtenismelding

Soms moet een wijziging in de ene applicatie doorgegeven worden aan andere applicaties. Als een consument bijvoorbeeld in één applicatie zijn adres wijzigt, moeten andere applicaties met hun eigen databases hiervan op de hoogte worden gesteld, zodat zij hun gegevens kunnen corrigeren.

Nogmaals, de ene applicatie kan een service in een andere applicatie aanroepen om deze op de hoogte te stellen van de wijziging, maar er kleven drie problemen aan deze aanpak. De eerste twee problemen zijn dezelfde als bij gegevensoverdracht. Ten eerste is de serviceoproep te specifiek in termen van het vertellen aan de ontvanger wat hij met de informatie moet doen, en ten tweede heeft hij de neiging bidirectioneel te zijn, waardoor de afzender wordt gedwongen te wachten op een antwoord (zelfs asynchroon), wat hij eigenlijk niet wil. te doen.

Het derde en belangrijkste probleem bij het aanroepen van een dienst voor het melden van gebeurtenissen is dat het aanroepen van een dienst in wezen een één-op-één proces is, van consument naar provider, terwijl het melden van gebeurtenissen in wezen een één-op-veel-proces is , is bedoeld voor alle geïnteresseerde ontvangers. Met behulp van een serviceoproep zou de afzender alle geïnteresseerde ontvangers moeten volgen en voor elk van hen afzonderlijk de service moeten bellen. Het uitzenden van dergelijke kennisgevingen kan het beste worden overgelaten aan een makelaar die zich tussen de afzender en de ontvangers bevindt.

Het gebruik van een ESB voor het melden van gebeurtenissen 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. Hierdoor kan de ontvanger slechts één keer een melding verzenden en erop vertrouwen dat deze bij alle geïnteresseerde ontvangers wordt afgeleverd, ongeacht wie ze zijn. Omdat deze bewerking unidirectioneel is, kan de afzender ander werk doen terwijl meldingen worden afgeleverd, en kunnen meldingen parallel worden afgeleverd.

Aanvullende informatie over de technologie voor gegevensoverdracht kunt u vinden in de gebeurtenisberichtsjabloon (raadpleeg nogmaals het boek "Enterprise Integration Patterns", waarnaar u kunt verwijzen in de sectie " ").

Ontwikkeling van Enterprise Service Bus

Nu kent u het verschil tussen rechtstreeks bellen naar de webservice van een provider en hiervoor een makelaar gebruiken. Je hebt ook geleerd hoe een makelaar een consument een dienst synchroon of asynchroon kan laten aanroepen.

ESB wordt vaak een makelaar genoemd. Dus hoe past ESB in gevestigde ontwerpen en patronen?

Zelfbeschrijving en vindbaarheid

Wat webservices anders maakt dan andere integratiebenaderingen is dat een consument dynamisch kan communiceren met een serviceprovider. Dit wordt bereikt door de volgende twee hoofdfunctionaliteiten:

• Zelfbeschrijving. Een webservice beschrijft zichzelf op een machineleesbare manier. Twee of meer aanbieders van dezelfde dienst worden onmiddellijk herkenbaar, zelfs als ze totaal verschillend worden geïmplementeerd, omdat hun beschrijvende interfaces overeenkomen met dezelfde beschrijving;
• Detecteerbaarheid. Webserviceproviders kunnen worden georganiseerd in automatisch bijgehouden directory's. De consument kan in zo'n directory bladeren om de aanbieder van de gewenste dienst te vinden.

Deze functionaliteit voor webservices verschilt sterk van de bestaande integratiebenaderingen. Daarin werden interfaces gedefinieerd tijdens het compileren en tijdens de communicatie tussen de consument en de providers. Berichtformaten werden niet beschrijvend uitgedrukt. Ze waren gebaseerd op interne overeenstemming en konden niet worden gedwongen dit formaat te volgen, waardoor de ontvanger de door de afzender gecreëerde structuur niet meer kon verwerken.

De mogelijkheid om webservices zelf te beschrijven, vereenvoudigde de integratie door interfaces aan te geven die moesten worden gevolgd. Dynamische service-ontdekking zorgde ervoor dat de consument niet langer afhankelijk was van een specifieke aanbieder voor een specifiek adres, maar deze mogelijkheid zorgde ook voor zijn eigen problemen. Moet de consument eenmalig of continu zoeken naar dienstverleners?

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 mogelijk zoeken naar een nieuwe provider bij elk gesprek tijdens runtime. De ESB stelde een derde compromisoptie voor: een consument in staat stellen één keer dynamisch contact op te nemen met een proxydienst en toch via die proxydienst gebruik te kunnen maken van meerdere aanbieders en toekomstige aanbieders.

De ESB maakt dus niet alleen diensten beschikbaar voor consumenten om te bellen, maar biedt consumenten ook de mogelijkheid om diensten programmatisch te vinden.

Service-gateway

De basis van een synchrone ESB is de zogenaamde servicegateway, die fungeert als tussenpersoon tussen serviceconsumenten en providers en de verwerking van synchrone oproepen met behulp van een makelaar mogelijk maakt. Het biedt toegang tot alle bekende services en proxyservices voor elk van hen. Op deze manier biedt de gateway een "single window" voor een consument die elke dienst wil bellen van elke aanbieder die bij de gateway bekend is.

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

1. Poorttypen– Een reeks bewerkingen die worden uitgevoerd door een webservice. Het poorttype zou stockBrokerServices kunnen zijn met poorten/bewerkingen zoals getQuote .
2. Berichten– Verzoek- en antwoordformaat, zoals getQuoteRequest (dat het aandelensymbool bevat) en getQuoteResponse (dat de prijs bevat).
3. Soorten– Gegevenstypen die door de webservice worden gebruikt, zoals symbool en prijs (of eenvoudigweg xs:string en xs:decimaal).
4. Verbindingen– 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 als een UDDI-service, zoals eerder besproken. Om het serviceoproepadres te vinden, vraagt ​​de consument de UDDI-service van de gateway om een ​​lijst met providers voor de gewenste WSDL-bewerking en ontvangt het gateway-proxyserviceadres voor die bewerking terug.

Berichtenbus

De asynchrone ESB is gebaseerd op het bekende Message Bus-patroon beschreven in het boek " Sjablonen voor bedrijfsintegratie", waarnaar wordt verwezen in de sectie " ". Een berichtenbus is een verzameling berichtkanalen (ook wel wachtrijen of onderwerpen genoemd), doorgaans geconfigureerd als kanaalparen voor verzoek-antwoord. Elk paar vertegenwoordigt een dienst die door een consument kan worden aangeroepen met behulp van de bus Deze consument geeft een bericht door aan de aanvraagwachtrij van de service en luistert vervolgens (asynchroon) naar de antwoordwachtrij om het resultaat te verkrijgen. Hij weet welk resultaat overeenkomt met zijn specifieke verzoek, omdat het resultaat de juiste correlatie-ID heeft.

De consument die de dienst belt, weet eigenlijk niet wie de dienst levert. Serviceproviders zijn ook aangesloten op de berichtenbus en luisteren ernaar voor verzoekberichten. Als er meerdere dienstverleners zijn, concurreren deze als consumenten met elkaar om een ​​bepaald verzoek te ontvangen. Het berichtensysteem dat de berichtenbus implementeert, fungeert als berichtenbeheerder en distribueert verzoekberichten naar serviceproviders, waardoor deze distributie op de een of andere manier wordt geoptimaliseerd, afhankelijk van de belastingsbalans, netwerkvertragingen, enz. Zodra een serviceprovider een verzoek ontvangt, voert deze de service uit en plaatst het resultaat in een bericht in een voorwaardelijke antwoordwachtrij. Dat wil zeggen dat aanbieder en consument nooit direct elkaars locatie kennen; ze kennen alleen de berichtenbus en het adres van de overeenkomstige kanalen en kunnen via gemeenschappelijke kanalen communiceren.

Deze berichtenbus is de essentie van een ESB, en hier is niets nieuws. Applicatie-integrators maken al meer dan tien jaar gebruik van deze technologie, waarbij ze gebruik maken van message queuing-producten zoals WebSphere® MQ en TIBCO Enterprise Message Service. En er wordt zelfs vaak gezegd dat als u zakelijke berichtenproducten gebruikt, u een ESB heeft. IBM-klanten profiteren al een tijdje van deze mogelijkheden met WebSphere Business Integration Message Broker en WebSphere MQ.

Is de ESB dus slechts een berichtenbus? Nee, de berichtenbus is absoluut de kern van een asynchrone ESB, maar een volledige ESB omvat meer. De ESB heeft mogelijkheden die de berichtenbus nooit had: de eerder genoemde mogelijkheden voor zelfbeschrijving en vindbaarheid.

Beste berichtenbus

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

Een nadeel van traditionele berichtenbustechnologie is het gebrek aan zelfbeschrijvingsvermogen. Vanuit het perspectief van de consument zijn er meerdere kanalen om meerdere diensten aan te vragen. Maar welke van deze kanalen is nodig voordat een consument de gewenste dienst kan bellen? De consument kan niet zomaar een verzoek indienen bij welk verzoekkanaal dan ook; het moet het juiste kanaal kennen om een ​​bepaalde dienst te bellen. Anders koopt hij mogelijk een vliegticket in plaats van het gewenste boek. Bovendien moet de consument, zelfs nadat hij (op de een of andere manier) het juiste kanaal heeft bepaald (en het kanaal om naar een antwoord te luisteren), weten in welk dataformaat het verzoek moet worden verzonden (en in welk dataformaat hij het antwoord kan verwachten).

Zoals eerder besproken wordt dit probleem voor synchrone webservices opgelost door WSDL, dat nu een variant is van de standaard om ook asynchrone services te beschrijven. De WSDL die aan een verzoekkanaal is gekoppeld, moet beschrijven welke dienst het kanaal biedt, evenals het formaat van het verzoekbericht dat de consument moet verstrekken. De WSDL zou waarschijnlijk ook het antwoordkanaal moeten specificeren waarnaar de consument moet luisteren om het antwoord te ontvangen, en het formaat van het verwachte antwoordbericht. Op deze manier kan de oproepende applicatie programmatisch een paar service-aanroepkanalen analyseren en bepalen of deze de gewenste service bieden met behulp van de gewenste aanvraag- en antwoordberichtformaten.

Zelfbeschrijvende servicekanalen introduceren een ander probleem, namelijk 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. Via deze URL kan de consument de dienst aanroepen.

De ESB heeft een vergelijkbare directoryservice nodig met een UDDI-achtige API die de consument kan gebruiken om het adres op te vragen van de service die de gewenste WSDL-bewerking implementeert. De ESB retourneert het adres van het overeenkomstige paar verzoek- en antwoordkanalen. Dat wil zeggen dat een ESB-client, vergelijkbaar met een UDDI-client, niets anders mag weten dan het volgende:

1. WSDL die de service beschrijft die moet worden aangeroepen.
2. Het ESB-directoryserviceadres (dat kan zijn afgeleid van het ESB-hoofdadres).

Dit is voldoende om de aanvraag- en antwoordkanalen van de service te ontdekken en de service te bellen. Bovendien is deze directorydienst gewoon een andere dienst van de ESB, alsof het de voornaamste dienst is voor het vinden van andere diensten.

Synchronisch of asynchroon?

Klanten van diensten worden geconfronteerd met een kunstmatige keuze tussen twee interactiestijlen: synchroon of asynchroon. Om dit dilemma op te lossen zullen veel ESB's beide modi ondersteunen en in feite twee belmodellen voor dezelfde dienst aanbieden. In dit geval kan de consument bij het aanvragen van het serviceadres twee opties ontvangen: één voor de synchrone modus, de tweede voor de asynchrone modus. De consument kan vervolgens het belmodel kiezen dat het beste bij hem of haar past. Ongeacht het model wordt dezelfde service uitgevoerd, hoewel de specifieke instantie van de serviceprovider kan verschillen.

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

Conclusie

Zoals u heeft gezien, kan de dienst op een van de volgende manieren worden opgeroepen:

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

Enterprise Service Bus is een broker die het aanroepen van services in synchrone en asynchrone modi ondersteunt. Het maakt ook de overdracht van gegevens en gebeurtenismeldingen tussen applicaties mogelijk. Het helpt consumenten aanbieders te vinden en beheert de details van de interacties tussen hen.

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

Als u op dit punt 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 aanpassingen bij het doorvoeren van eventuele, zelfs minimale wijzigingen.

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

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

4) Er is een “Technologische Dierentuin”: er wordt een verscheidenheid aan informatiesystemen en protocollen voor gegevensuitwisseling gebruikt, veel connectoren (vaak op bestelling of onafhankelijk ontwikkeld), enz.

De oplossing voor een reeks van dergelijke problemen ligt in de transitie naar het bouwen van een IT-infrastructuur gebaseerd op het concept van Service Oriented Architecture (SOA), waarvan het belangrijkste element de Integration Service Bus is. Een bus is software waarmee je een groot aantal platforms en applicaties kunt combineren en de interactie daartussen kunt 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 doorgaans de volgende functies:

Berichttransformatie en berichtoverdracht, algoritmische omleiding, wachtrijen en tracking;

Werken met berichten in modi: synchroon, asynchroon, punt-tot-punt, publiceren-abonneren;

Ondersteuning voor XML- en SOAP-berichten;

Mogelijkheid om meerdere systemen te verbinden via kant-en-klare adapters en API's voor het schrijven van nieuwe adapters;

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

Conceptueel ziet de architectuur die de Integration Service Bus gebruikt er als volgt uit:

Figuur 1 Architectuur met behulp van een integratiebus

Bij de introductie van een integratiebus wordt de integratie van nieuwe systemen – zowel aangekocht als zelfstandig ontwikkeld – enorm vereenvoudigd. Diensten zijn niet langer monolithische toepassingen, maar worden opgesplitst in afzonderlijke diensten. Bijvoorbeeld: de samengestelde dienst ‘een leningaanvraag in overweging nemen’ kan worden onderverdeeld in de volgende ‘eenheidsdiensten’:

• Voer klantgegevens in
• Controleer of er een record bestaat voor een bepaalde klant
• Ontvang een lijst met klantaccounts
• Ontvang een lijst met services die door de klant worden gebruikt
• Ontvang geaggregeerde gegevens over de betalingsgeschiedenis van leningen
• Gegevens voor het rapport ophalen
• Accountsaldo ophalen
• Bereken de kredietwaardigheid
• Genereer een rapport ter beoordeling door de manager
• Update accountgegevens
• Genereer een melding voor een klant

Merk op dat sommige “unit services” kunnen worden gebruikt in andere componentbewerkingen, wat de integriteit van het systeem vergroot, het gemakkelijker te onderhouden maakt en de risico’s vermindert.

Het klantportaal van een bank combineert bijvoorbeeld betaalrekeningrapporten, hypotheekbetalingsrapporten en creditcardafschriften op één pagina. Tegelijkertijd kunnen rekeninggegevens, hypotheekbetalingsgegevens en creditcardgegevens uit verschillende systemen worden gehaald. Op basis van CRM-gegevens kan op dezelfde pagina een aanbod worden getoond dat specifiek voor een bepaalde klant potentieel interessant is.

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

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

Tekening2 IT-architectuur van de bank voor en na de implementatie van de bus

Momenteel is de keuze op de markt voor integratiebussen vrij groot. Zowel commerciële systemen als open source producten komen aan bod. Onder de fabrikanten van integratiebussen die toonaangevend zijn op het gebied van implementatie in Rusland, kunnen we IBM en Oracle benadrukken; TIBCO kan tot de toonaangevende buitenlandse leveranciers worden gerekend.

Laten we eens kijken naar de implementatie van integratiebussen bij verschillende grote internationale banken.

Chinatrust Commercial Bank maakt gebruik van een integratiebus om haar producten en diensten te ondersteunen. De servicegerichte architectuur gebaseerd op de integratiebus integreert meer dan zeventig systemen op meerdere platforms, zoals: geautomatiseerd banksysteem, netwerkbankieren, hypotheeksysteem, loterijsysteem, workflowautomatiseringssysteem, interactief spraakmenu, enz. In realtime zijn diensten zoals gegevensaggregatie, accountoverzicht, inkomende en uitgaande overdrachten, overdrachten, meldingen (op gebeurtenissen gebaseerde communicatiefunctionaliteit ingeschakeld) en andere beschikbaar gekomen. De kosten voor het integreren van nieuwe systemen zijn met gemiddeld 30 tot 40% gedaald.

Momenteel ondersteunt de integratiebus van de bank 100.000 dagelijkse transacties in het bedrijfsleven en 50.000 in de detailhandel. Het aantal online banktransacties steeg van 150.000 naar 1.200.000 per dag.

De Singaporees-Maleisische bank OCBC heeft onlangs een vijfjarig doel gesteld om de operationele efficiëntie met 25% te verhogen en de kosten voor het ontwikkelen van nieuwe software-interfaces met 30% te verlagen. De eerste SOA-gebaseerde dienst werd in 2006 gelanceerd. Na zes maanden waren er 116 eenheidsdiensten actief, die elk bruikbaar waren in samengestelde diensten. 50 individuele diensten maakten deel uit van verschillende componenten. Ter ondersteuning van integratieprocessen heeft de bank een Integration Competence Center opgericht. OCBC is van mening dat SOA een sleutelrol speelt bij het bereiken van de gestelde doelen.

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

In Rusland worden integratiebussen gebruikt in veel grote ondernemingen, waaronder telecomoperatoren, de banksector, maar ook in het complex van elektronische overheidssystemen van de Russische Federatie. De implementatie van integratiebussen wordt doorgaans uitgevoerd door systeemintegrators. In het bijzonder heeft ons bedrijf AMT-GROUP, dat volgens cnews.ru is opgenomen in de Top 20 Russische bedrijven die IT-diensten aan banken leveren, succesvolle ervaring met het werken met integratiebussen en de implementatie ervan in verschillende werkterreinen, waaronder de banksector . Onze specialisten hebben ruime ervaring met 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

Tarief:

4 15

Integratie databus is bedoeld voor het bouwen van samengestelde toepassingen die gebruik maken van verschillende standaarden en interactietechnologieën die volgens verschillende principes zijn gebouwd. Bijzondere aandacht wordt besteed aan de integratie van applicaties op het 1C:Enterprise-platform.

Ondersteunt verschillende standaarden en integratiescenario's met behulp van de integratiedatabus

Vaak krijg je bij het bouwen van samengestelde applicaties te maken met een situatie waarin verschillende soorten applicaties zijn ontworpen voor verschillende standaarden en integratieschema's. Het is ook niet ongebruikelijk dat er een situatie ontstaat waarin het veranderen van de integratiemechanismen van bestaande applicaties onmogelijk of arbeidsintensief is om een ​​aantal redenen: gebrek aan een ontwikkelaar, gebrek aan broncode, enz. Met de integratiebus kunt u dergelijke toepassingen combineren tot één geheel, het verbergen van verschillen in integratie op het niveau van mechanismen en instellingen van typische connectoren, wat de interactie van applicaties leidt tot één enkel gecontroleerd integratieschema.

De volgende typen connectoren bestaan ​​in DATAREON ESB:

• SOAP-servicesconnector, inclusief 1C:Enterprise 8-webservices
• Connector voor REST-services, inclusief webservices "1C:Enterprise 8"
• MS SQL-connector
• IBM DB2-connector
• Oracle-connector
• PostgreSQL-connector
• SharePoint-connector
• OData 1C-connector
• TCP-connector
• Siemens Team Center-connector
• SAP-connector en anderen.

Alle connectoren hebben de mogelijkheid om de verbinding met het bronsysteem parametrisch te configureren en ermee te communiceren.

De lijst met beschikbare connectoren wordt voortdurend uitgebreid; een volledige lijst moet worden gecontroleerd met DATAREON.

DATAREON ESB bevat een mechanisme waarmee u onafhankelijk verschillende connectoren in Java- of .Net-platformtalen kunt ontwikkelen. Op deze manier kan elk maatwerkscenario voor koppeling met bronsystemen worden geïmplementeerd.

Integratie van informatiesystemen met behulp van een enterprise service bus (ESB)

Een van de beste praktijken voor het integreren van complexe informatiesystemen is de constructie van logische datamarts, evenals de creatie van gecentraliseerde infrastructuren voor gegevensuitwisseling met behulp van MDM-systemen en enterprise service-bussen (ESB, Enterprise Service Bus). Onze oplossingen, waaronder het ArchiGraph.MDM-systeem, zijn geschikt voor gebruik als onderdeel van het speciale besturingssysteem Astra Linux Special Edition, evenals Alt Linux.

Waarom is een integratiebus nodig?

Elk bedrijf dat meer dan twee softwareproducten gebruikt die met overlappende sets informatie werken, kent de kosten als er niet tussen deze producten wordt gecommuniceerd. Niet-gesynchroniseerde klantenlijsten of productlijnen en andere informatie tussen ERP, CRM en andere bedrijfsapplicaties veroorzaken voortdurend verlies van tijd, middelen en bedrijfsreputatie. De enige juiste oplossing voor dit probleem is de implementatie van een enterprise service bus (ESB), in combinatie met een master data management (MDM) systeem.

Oplossingen gebaseerd op het regelmatig uploaden en transformeren van informatie (ETL) en service-georiënteerde architectuur (SOA) bieden slechts een tijdelijke oplossing voor dergelijke problemen, hebben veel nadelen en beperken het groeipotentieel van de IT-infrastructuur.

Implementatie van de integratiebus

Bij het implementeren van een integratiebus ontstaat de taak om de informatiestructuur over dezelfde objecten in verschillende informatiesystemen in kaart te brengen (vergelijken). Dit probleem moet worden opgelost door een algemeen informatiemodel te creëren dat neutraal is ten opzichte van elke toepassing. Een dergelijk model kan het meest effectief worden geïmplementeerd met behulp van semantische technologieën. Voor het behalen van optimale implementatieresultaten is het nodig dat het model wordt ontwikkeld door een professionele data-architect.

Een belangrijk onderdeel van het implementatieproject is de implementatie van connectoren (software-interfaces) voor alle applicaties die betrokken zijn bij data-uitwisseling. Onze specialisten hebben ervaring met het ontwikkelen en aansluiten van connectoren voor een breed scala aan software op diverse platforms.

Samen met partners voeren wij integratieprojecten uit op basis van oplossingen IBM WebSphere MQ, Integration Service Bus, WSO2 Message Broker, Apache Synapse en de Business Semantics bus.

Vaak wordt een project om een ​​integratiebus te implementeren uitgevoerd als onderdeel van de algehele herinrichting van de informatiearchitectuur van een onderneming.

2005

Bedrijfsservicebus - een “budget”-benadering voor het oplossen van integratieproblemen

Bereid: gebaseerd op materialen van buitenlandse locaties
Vertaling: Intersoft Lab

We bleven de lezer kennis laten maken met verschillende benaderingen van integratie en besloten ons te concentreren op een relatief nieuwe en zeer aantrekkelijke technologie: de Enterprise Service Bus (ESB).

Wat is een enterprise service bus en hoe verhoudt deze zich tot enterprise applicatie-integratie (EAI), besproken in eerdere nummers van het DWH, OLAP en XML Experts Club Magazine? Volgens gevestigde traditie geven wij eerst het woord aan deskundigen op dit gebied.

Gartner-analisten definiëren ESB als een nieuw type middleware dat de functionaliteit van andere bestaande soorten middleware combineert. De Enterprise Service Bus ondersteunt webservices door het implementeren van SOAP (Simple Object Access Protocol) en het gebruik van WSDL (Web Services Description Language) en UDDI (Universal Description, Discovery and Integration) specificaties. Veel zakelijke servicebussen ondersteunen ook andere communicatiestijlen, waaronder gegarandeerde bezorging en publiceren en abonneren. De diensten die door deze bussen worden geleverd, bieden een ‘toegevoegde waarde’ die lichtgewicht messaging-middleware niet biedt: berichtvalidatie, transformatie, op inhoud gebaseerde routering, beveiliging, servicedetectie voor servicegerichte architectuur, taakverdeling en registratie. Sommige diensten zijn in de busbasis ingebouwd, andere worden in plug-in modules uitgevoerd. Bovendien ondersteunen bussen XML en andere berichtformaten.

Wat is er zo aantrekkelijk aan de zakelijke servicebus? Allereerst de relatieve goedkoopheid. ESB-producten worden doorgaans gepositioneerd als betaalbare, of, zoals ze zeggen, ‘budget’-oplossingen.

Tegenwoordig is er inderdaad een toenemende vraag naar integratietechnologieën. Terwijl EAI-implementaties vroeger om strategische doelen gingen en daarom op de lange termijn vruchten afwierpen, zijn de uitdagingen waarmee bedrijven nu worden geconfronteerd tactisch en vereisen ze een nieuwe aanpak. “Modern Business Realities” heeft de aandacht gevestigd op gebieden waar EAI-aanbieders traditioneel zwak zijn geweest: transformatie, op ontwikkelaars gerichte softwareverwerking (zoals Java) en integratie met externe technologieën. Al deze “bereidde vruchtbare grond” voor de opkomst van een nieuwe productcategorie: ESB.

Sprekend over de verdiensten van de enterprise service bus, is het de moeite waard om de woorden van vice-president en lid van de onderzoeksafdeling van Gartner Roy Schulte te citeren: “Conventionele middleware kan niet langer nieuwe applicaties ondersteunen die gebruik maken van servicegeoriënteerde (Service Oriented Architecture, afgekort . SOA) en gebeurtenisgestuurde architectuur (EDA), webservices en bedrijfsprocesbeheer. Dit is de belangrijkste reden waarom architecten en informatiesysteembeheerders hun bedrijfsinformatie-infrastructuren moeten versterken met ESB’s.”

Toonaangevende Gartner-analist benadrukt ESB-leveranciersgroepen. Tot de eerste groep rekent hij ESB-producten, die gepositioneerd zijn als ‘goedkope’ integratieoplossingen die optimaal geschikt zijn voor de ondersteuning van composiettoepassingen en SOA. De tweede groep bestaat uit producten die bedoeld zijn voor de markt voor webservices, en tot slot bestaat de laatste uit softwaretools die EDA-ondersteuning bieden. Roya Schulte schat dat de ESB-markt de komende jaren krapper zal worden, gedreven door de toenemende vraag naar webdiensten en multi-protocol- en gebeurtenisgestuurde oplossingen.

Interessant is dat ESB in een aantal bedrijven niet als een productcategorie wordt behandeld, maar als een architectuur. IBM beschouwt de enterprise service bus bijvoorbeeld als een ‘architectonisch patroon’.

Er kan dus worden gesteld dat er nog steeds geen duidelijke definitie bestaat van wat ESB is. Eigenlijk draait de discussie om twee vragen:

1. Is ESB een architectuur (en die niet eens gestandaardiseerd hoeft te worden), een ‘eenrichtingsbenadering’ of een onafhankelijk product?

   Hoewel het voor sommige leveranciers, die momenteel geen kant-en-klare oplossing hebben, nuttig kan zijn om over Enterprise Service Bus als architectuur te praten, is de huidige omgeving zodanig dat klanten eisen dat hun productaanbod ESB-functionaliteit omvat. Daarom mogen we de komende twee jaar een toename verwachten van het aantal leveranciers dat ESB-mogelijkheden aanbiedt.

2. Wat is de plaats en toekomst van ESB-producten, namelijk: is Enterprise Service Bus een geavanceerder berichtenwachtrijsysteem dat eenvoudige XML-transformatie biedt, evenals routering en berichtenuitwisseling, of zal het gebruik van applicatie-adapters, automatisering en bedrijfsprocesmodellering ESB mogelijk maken? om EAI met succes te vervangen.

Op dit moment zijn er geen definitieve antwoorden op deze vragen.

Het is echter de moeite waard om te benadrukken dat, hoewel er onduidelijkheid bestaat over de Enterprise Service Bus, het duidelijk is dat, omdat ESB gebaseerd is op open standaarden, de aanschaf- en implementatiekosten aanzienlijk kunnen worden verlaagd.

Merk op dat het woord ‘service’ in de term ‘corporate service bus’ centraal staat. Analisten van Forrester Research beschouwen ESB dan ook als “een laag middleware die kan worden gebruikt om toegang te krijgen tot een reeks kern (herbruikbare) zakelijke diensten.” Met SOA kan een groot deel van de functionaliteit worden aangeboden als een ‘service’ op een bedrijfsservicebus die XML-invoer en -uitvoer van die services doorstuurt, transformeert en valideert.

ESB en XML

Het zou oneerlijk zijn als we de bijzondere rol van XML niet zouden benadrukken – XML is de basis voor integratie. Als je accepteert dat XML meer een 'alfabet' is dan alleen maar een taal, wordt het duidelijk dat de volledige implementatie van integratie het orkestreren van bedrijfsprocessen, het beheren van XML-transformatie en het valideren en doorsturen van XML-berichten door de hele organisatie vereist. Al deze functionaliteit vormt de basis van de Enterprise Service Bus.

XML kan een uitgebreide weergave van een dataset bieden. De populariteit van deze taal kan worden verklaard door de hoge flexibiliteit en uitbreidbaarheid ervan. Met de XML-syntaxis kunt u gespecialiseerde XML-schema's moderniseren en ontwikkelen om verschillende gegevens te verwerken.

Tegelijkertijd zorgt de snelle groei van de hoeveelheid gegevens die moet worden overgedragen voor ernstige problemen voor het functioneren van de bedrijfsinformatiestructuur. De eerste integratieprojecten die gebruik maakten van de mogelijkheden van XML waren dus het ‘levende’ bewijs van de belofte van deze taal, maar nu zijn er bepaalde problemen met de toename van het aantal, de omvang en de complexiteit van XML-documenten. De belangrijkste redenen voor de bestaande problemen (gebrek aan schaalbaarheid) worden hieronder opgesomd:

• Het hele document parseren: Normaal gesproken moet u hele documenten parseren, zelfs als u er maar een deel van hoeft te extraheren voor routering en filtering. Als de documenten groot worden, loopt de wachttijd op.
• Opnieuw scannen. Documenten worden vaak opnieuw geparseerd. In elke fase van het bedrijfsproces kunnen dezelfde documenten dus meerdere keren worden gescand. Omdat deze praktijk extreem veel hulpbronnen vergt, verslechtert de prestatie en doorvoer.
• Ontwerp met enkele draad. In dit geval kan de volgende verwerkingsstap pas worden gestart als de huidige is voltooid; Hierdoor neemt de wachttijd toe omdat het hele proces afhankelijk is van de langzaamste stap.

Om het probleem van onvoldoende schaalbaarheid op te lossen, wordt aanbevolen een verwerkingsarchitectuur te gebruiken die de volgende kenmerken ondersteunt:

• Documentstreaming - zorgt ervoor dat XML-documenten worden verwerkt zodra elk element arriveert, d.w.z. een lage wachttijd is gegarandeerd. Met deze aanpak kunnen grote berichten net zo productief worden verwerkt als kleine.
• Selectieve verwerking, waarbij zeer aanzienlijke prestatieverbeteringen worden bereikt door alleen relevante fragmenten te verwerken in plaats van het gehele XML-document.
• Multi-threaded verwerking, waarbij de processor de uitlijning van opeenvolgende stappen langs een kanaal, de parallelle uitvoering van individuele stappen en de taakverdeling van identieke stappen beheert bij het verwerken van meerdere XML-fragmenten.
• De enige scan waarbij, in plaats van meerdere herhaalde lezingen van de structuur van hetzelfde document vanaf het allereerste begin, alle benodigde fragmenten in één overdracht worden geëxtraheerd.

Bovenstaande functies kunnen worden geïmplementeerd met behulp van de Enterprise Service Bus - zonder speciale codering of configuratie.

Wat is het verschil tussen een enterprise service bus (ESB) en message brokers (bijvoorbeeld RabbitMQ)?

Als gevolg hiervan kan het probleem van onbevredigende prestaties worden opgelost.

Conclusie

Afgaande op publicaties in buitenlandse internetpublicaties en beoordelingen van analisten van toonaangevende onderzoeksbureaus is de corporate service bus niet langer slechts een nieuwe technologie met groot potentieel. Gartner voorspelt zelfs dat in 2005 de meeste grote bedrijven ESB's zullen gebruiken. IDC is van mening dat de zakelijke servicebus de informatietechnologie moet ‘revolutioneren’ en flexibele en schaalbare gedistribueerde gegevensverwerking mogelijk moet maken.

Ondersteuning voor open standaarden (en vooral XML) maakt een goedkope maar effectieve oplossing mogelijk en garandeert een snel rendement op de investering, d.w.z. een hoge ROI. Zoals Steve Craggs, vice-president van het Consortium for Integration, opmerkt: “ESB is de basis voor integratie en biedt een flexibele en aanpasbare omgeving waarmee integratieprojecten vruchtbaar, succesvol en systematisch kunnen worden geïmplementeerd.”

En toch bestaat er nog steeds onzekerheid over de dubbelzinnigheid van de term ‘corporate service bus’. Tegenwoordig verwijst ESB naar elke technologie die nodig is om SOA te implementeren. Dit is precies het standpunt van ZapThink, een bedrijf gespecialiseerd in de ontwikkeling en toepassing van servicegerichte architectuur. In dit verband waarschuwen ZapThink-analisten dat tenzij er in 2005 een echte en concrete definitie van de enterprise service bus wordt ontwikkeld, de term ESB "voor altijd uit het SOA-lexicon zal verdwijnen." Wat SOA zelf betreft, dit zal in het volgende artikel worden besproken.

Publicaties

1. Beth Gold-Bernstein, is een ESB cruciaal voor uw toekomst?
2. Nigel Thomas en Warren Buckley, ‘De opkomst van de ESB.’
3. Materialen gepubliceerd op de website van het Integration Consortium.

Wat zijn ESB en SOA¶

Een uitstekende beschrijving van het systeem-van-systemen-denken
Nick Coghlan, kernpython-ontwikkelaar

Ook verkrijgbaar in Catala, Duits, Engels, Frans, Italiaans, Nederland, Portugees, Turkçe En 中文 .

Het acroniem ESB en de bijbehorende SOA kunnen voor verwarring zorgen. ESB staat voor Enterprise Service Bus. SOA - Servicegerichte architectuur.

Deze namen zeggen niet veel, dus hieronder vindt u meer volledige informatie in eenvoudige taal, zonder onnodig bedrijfstaal.

De hele waarheid¶

Laten we ons eens voorstellen wat er gebeurt als u inlogt op de front-endapplicatie van uw bank:

1. Uw naam wordt weergegeven
2. Uw rekeningsaldo wordt weergegeven
3. Toont uw creditcards en betaalkaarten
4. Mogelijk bestaat er een lijst met uw beleggingsfondsen
5. U ontvangt ook een lijst met vooraf afgewikkelde leningen waarin u mogelijk geïnteresseerd bent

Met een hoge mate van waarschijnlijkheid kunnen we zeggen dat al deze stukjes informatie tot verschillende systemen en applicaties behoren, die elk gegevens leveren via een soort interface (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV of een andere interface). ):

1. van CRM met Linux en Oracle
2. van een COBOL-systeem dat draait op een z/OS-mainframe
3. ze zeggen dat deze informatie afkomstig is van een mainframesysteem, maar deze jongens houden hun lippen te stijf op elkaar om iets anders te zeggen dan dat ze CSV verkiezen boven al het andere
4. van een mix van PHP en Ruby die op Windows draait
5. van PostgreSQL, Python en Java draaiend op Linux en Solaris

De vraag is: hoe kun je een frontend-applicatie laten praten met systemen 1-5? Nou ja, absoluut niet.

Dit is een fundamentele basis om ervoor te zorgen dat dergelijke omgevingen over meerdere systemen heen kunnen schalen. Je dwingt ze niet om rechtstreeks met elkaar te communiceren.

In het onderstaande diagram wordt elke oproep naar een dienst die door een ander systeem wordt geleverd, weergegeven door een lijn van verschillende dikte en stijl:

Merk op dat we niet eens een proces op hoog niveau lieten zien (App1 roept App2 aan en App3 of App5, afhankelijk van of de vorige reactie van App6 succesvol was, zodat App4 later de gegevens kan gebruiken die door App2 zijn gegenereerd, maar alleen als App1 verbiedt dit niet, enz.).

Merk ook op dat we het niet over servers hebben: elk van de systemen kan op 10 fysieke servers draaien, dus minstens 60 fysieke componenten zullen informatie met elkaar uitwisselen.

Er worden echter enkele problemen duidelijk.

Hoe interfaces scheiden? Hoe het lossen plannen? Hoe coördineert u updates of geplande downtime wanneer elke applicatie wordt beheerd door verschillende ontwikkelteams, leveranciers of afdelingen, en de helft van de oorspronkelijke ontwikkelaars het bedrijf al heeft verlaten?

Als u denkt dat u 6 applicaties kunt beheren, wat dacht u van 30?

Kun jij 400 aan? En sinds 2000? Elke applicatie kan zijn eigen unieke ecosysteem zijn, waarvoor tientallen servers of andere apparaten nodig zijn om te kunnen draaien. Het bestaat dus uit 20.000 bewegende delen, verspreid over continenten en over technische en culturele grenzen. En al deze onderdelen willen voortdurend en non-stop berichten uitwisselen, zonder enige downtime. (We zullen u het diagram besparen.)

Er is een mooie naam voor deze situatie: chaos.

Hoe kunt u de situatie verbeteren?¶

De eerste stap is toegeven dat de situatie uit de hand is gelopen. Hierdoor kun je zonder al te veel schuldgevoel naar een oplossing zoeken. Oké, het is gebeurd, je wist niet hoe je het beter kon doen, maar er is een kans dat dit allemaal kan worden opgelost.

Dit kan organisatorische veranderingen in de benadering van IT met zich meebrengen, maar een andere stap is om te onthouden dat systemen en applicaties zijn ontworpen voor meer dan alleen het delen van gegevens. Ze zijn gemaakt om bedrijfsprocessen te ondersteunen, ongeacht het bedrijf zelf, of het nu om bankieren, audio-opnamen, radarapparatuur of wat dan ook gaat.

Zodra u deze twee punten duidelijk heeft gedefinieerd, kunt u beginnen met het ontwerpen of herontwerpen van uw systemen rond services.

Een service is iets interessants, herbruikbaars en atomairs dat door één systeem wordt blootgesteld aan andere applicaties die er gebruik van willen maken, maar de service wordt nooit rechtstreeks op een één-op-één-manier blootgesteld. Dit is de kortste en meest betekenisvolle beschrijving die mogelijk is.

Als een bepaalde systeemfunctionaliteit aan deze drie vereisten voldoet:

• I interessant (interessant)
• R bruikbaar (herbruikbaar)
• A tomisch (atomisch)

dan is de kans groot dat het systeem als dienst aan andere systemen kan en moet worden blootgesteld, maar nooit direct verbonden.

Laten we de IRA-aanpak bespreken met een paar voorbeelden.

Variabel	Opmerkingen
Omgeving	CRM-systeem van elektriciteitsbedrijf
Functionaliteit	Het retourneren van een lijst met klanten die in het derde kwartaal van 2012 actief waren op het selfserviceportaal
Dit is interessant?	Ja, best interessant. Hiermee kunnen allerlei nuttige rapporten en statistieken worden gegenereerd.
Het is mogelijk	Nee, niet echt. Ondanks het feit dat je hierdoor kunt creëren
vele malen	constructies op hoog niveau, zoals statistieken voor het hele jaar,
gebruik?	Het is duidelijk dat we dit in 2018 niet nodig zullen hebben.
Is het atomair?	Hoogstwaarschijnlijk wel. Als er voor andere kwartalen al soortgelijke diensten bestaan, dan is het mogelijk om het hele jaar te bekijken.
Hoe kan ik dit omzetten in een IRA?	Forceer het ontvangen van willekeurige begin- en einddatums van de periode, in plaats van alleen het kwartaal op te geven. Forceer het ontvangen van willekeurige aanvragen, niet alleen de portal. Bied de mogelijkheid om de toepassing op te geven om informatie te ontvangen als invoerparameter.

Variabel	Opmerkingen
Omgeving	e-commercesite
Functionaliteit	Retourneer elk stukje informatie dat ooit is verzameld voor de opgegeven gebruiker
Dit is interessant?	Over het algemeen wel. Als je toegang hebt tot het geheel, kun je altijd kiezen wat je nodig hebt.
Het is mogelijk	Vreemd genoeg niet echt. Het zullen er maar een paar zijn
vele malen	eventuele toepassingen die van belang zullen zijn
gebruik?	gebruik absoluut elk stukje informatie.
Is het atomair?	Absoluut niet. Dit monster van functionaliteit is gedoemd om logischerwijs uit tientallen kleinere onderdelen te bestaan.
Hoe kan ik dit omzetten in een IRA?	Verdeel in verschillende kleinere delen. Denk na over wat de koper beschrijft: ze hebben adressen, telefoonnummers, favoriete producten, voorkeursmethoden om contact met hen op te nemen, enzovoort. Van elk van deze punten moet een onafhankelijke dienst worden gemaakt. Gebruik ESB om samengestelde services te maken van atomaire services.

Variabel	Opmerkingen
Omgeving	Elk CRM-systeem, waar dan ook
Functionaliteit	De kolom CUST_AR_ZN in de tabel C_NAZ_AJ bijwerken nadat iemand een account heeft aangemaakt
Dit is interessant?	Absoluut niet interessant. Dit is een interne functie van het CRM-systeem. Niemand met een gezond verstand zou met dergelijke functionaliteit op laag niveau willen omgaan.
Het is mogelijk	Ja, waarschijnlijk. Een account kan worden aangemaakt via
vele malen	meerdere kanalen zodat het meerdere keren als iets lijkt
gebruik?	gebruikt.
Is het atomair?	Het lijkt zo. Dit is een eenvoudige update van één kolom in een tabel.
Hoe te maken van
deze IRA?	Probeer er niet eens een dienst van te maken. Het is niet interessant. Niemand wil nadenken over specifieke kolommen en tabellen in één systeem. Dit is een complex onderdeel van een CRM-systeem en ook al is het herbruikbaar en atomair, het is niet de moeite waard om er een dienst van te maken. Het is de verantwoordelijkheid van jou en CRM om erover na te denken. Dwing anderen niet om dit ook te dragen

Variabel	Opmerkingen
Omgeving	Mobiele operator
Functionaliteit	Een prepaidkaart opwaarderen in de facturering
Dit is interessant?	Extreem. Iedereen wil er gebruik van maken, via sms-berichten, IVR, IM, portals, cadeaubonnen, enz.
Het is mogelijk	Ja. Het kan op veel hoog niveau deelnemen
vele malen	processen.
gebruik?
Is het atomair?	Ja, vanuit het oogpunt van de beltoepassing kan de kaart al dan niet worden opgewaardeerd. Het feit dat facturering dit via een reeks stappen implementeert, is niet belangrijk. Vanuit zakelijk oogpunt is dit atomair; het is een ondeelbare dienst die wordt geleverd door facturering.
Hoe te maken van	Het is al een IRA.
deze IRA?

Als u in de afgelopen 50 jaar aan programmeren heeft gedaan, zal het u duidelijk zijn dat het leveren van een dienst vergelijkbaar is met het leveren van een API in het ene stuk code aan het andere. Het enige verschil is dat je niet met submodules van één systeem te maken hebt, maar op het niveau van de gehele omgeving van individuele systemen werkt.

Beschikbaarheid van services in ESB en SOA¶

Nu u weet dat systemen niet rechtstreeks communiceren en u begrijpt wat een dienst is, kunt u de ESB effectief gaan gebruiken.

Het is nu de taak van de ESB om geïntegreerde systeemdiensten aan te bieden en te gebruiken. In de meeste gevallen hoeft er dus slechts één toegangsmethode en één interface te worden gedefinieerd tussen elk systeem en de ESB.

Dus als u, zoals in het bovenstaande diagram, 8 systemen heeft, dan heeft u 16 interfaces (één in elke richting) voor creatie, onderhoud, beheer en provisioning.

Zonder de ESB zou je 56 interfaces moeten creëren en beheren (ervan uitgaande dat elk systeem met elkaar praat).

Geen extra 40 interfaces betekent minder tijdverspilling en meer geldbesparing. Dit is een reden waarom uw vrijdagen minder stressvol zullen zijn.

Dit feit alleen al zou u moeten aanmoedigen om de implementatie van een ESB te overwegen.

Als een van de systemen wordt herschreven, overgedragen aan een andere eigenaar, verdeeld over afdelingen of leveranciers, dan is het de taak van de ESB-jongens om de nodige wijzigingen aan te brengen. Geen van de andere systemen zal dit zelfs maar merken, omdat hun interface met de ESB onaangetast blijft.

Zodra u regelmatig IRA-diensten gaat gebruiken, kunt u gaan nadenken over samengestelde diensten.

Herinner je je de hierboven genoemde ‘geef-me-wat-je-kan-over-deze-klant’-service?

Het was geen goed idee om er een te maken, maar soms kom je clienttoepassingen tegen die informatie moeten verzamelen. De ESB-jongens zullen hiervoor verantwoordelijk zijn, wiens taak het zal zijn om de beste atomaire services te selecteren om een ​​samengestelde service te bouwen voor dit specifieke clientsysteem dat deze specifieke set samengestelde gegevens vereist.

Na verloop van tijd zal de hele organisatie gaan begrijpen dat het niet langer om databasetabellen, bestanden, pakketten, functies, routines of records gaat. Nu hebben we het over een architectuur waarin interessante, herbruikbare en atomaire diensten van ESB-applicaties centraal staan.

Mensen zullen niet langer denken dat applicaties en systemen berichten naar elkaar sturen. Zij zullen de ESB zien als een universele toegangspoort tot interessante diensten waar hun eigen systemen gebruik van kunnen maken. En ze zullen niet eens controleren wie wat levert; hun systemen houden zich alleen bezig met de ESB.

Het zal tijd, geduld en gecoördineerde inspanning vergen, maar het is volledig haalbaar.

Maar pas op...¶

De beste manier om het hele SOA-concept te beëindigen is door een ESB in te zetten en te verwachten dat de problemen zichzelf oplossen. Hoewel het een geweldig idee is, zal het simpelweg inzetten van een ESB helaas niet voldoende zijn.

In het beste geval zal het proberen iets onder het tapijt te verbergen, zoals in het onderstaande diagram, tot niets leiden:

Jullie IT-mensen zullen het systeem haten en hoewel managers ESB aanvankelijk als nieuwe oplossing zullen tolereren, zal het later een lachertje worden. 'Wat, is dit de nieuwe zilveren kogel? Haha.”

Dergelijke gevolgen zijn onvermijdelijk als de ESB geen deel uitmaakt van een groter ontwikkelingsplan.

Het blijkt dus dat ESB alleen voor banken en dergelijke is?¶

Helemaal niet. Dit is een goede oplossing in elke situatie waarin het gecoördineerde werk van verschillende gegevensbronnen en verschillende toegangsmethoden vereist is om een ​​interessant resultaat te bereiken.

De taak om de laatste meetwaarden van een temperatuursensor te verzamelen en deze via verschillende kanalen te publiceren, zoals e-mailwaarschuwingen en iPhone-applicaties, is bijvoorbeeld zeer geschikt voor een integratieplatform.

Het periodiek controleren en monitoren van de werking van alle instances van een kritische applicatie en, als ze niet allemaal werken, is het ook prima om een ​​geconfigureerd script uit te voeren en een sms-bericht naar beheerders te sturen.

Alles wat integratie in een duidelijke, goed gedefinieerde omgeving vereist, past waarschijnlijk goed bij een ESB-service. Maar zoals altijd komt de beslissing of iets echt geschikt is voor integratie voort uit ervaring.

zakelijke servicebus

Natuurlijk kan het Zato-team helpen.

Maar ik heb gehoord dat SOA XML, SOAP en webservices is¶

Ja, dat willen sommige mensen je graag laten geloven.

Als de mensen of leveranciers met wie je hebt samengewerkt een BASE64-gecodeerd CSV-bestand hebben verzonden in een SAML2-beveiligd SOAP-bericht, dan is het begrijpelijk waar je die indruk hebt gekregen.

XML, SOAP en webservices hebben hun eigen gebruiksscenario's, maar zoals alles kunnen ze verkeerd worden gebruikt.

SOA gaat over een heldere en beheersbare architectuur. Het feit dat een dienst al dan niet gebruik maakt van SOAP is praktisch irrelevant. SOA als architecturale benadering zal nog steeds geldig zijn, zelfs als er helemaal geen SOAP-service wordt gebruikt.

Als een architect een mooi gebouw ontwerpt, kan hij de kleur van het interieur niet teveel beïnvloeden.

Dus nee, SOA is geen XML, SOAP en webservices. Ze kunnen worden gebruikt, maar vormen slechts een onderdeel en niet de basis.

Verdwaalde collega’s kun je naar dit artikel verwijzen, zodat zij kunnen achterhalen wat SOA is.

Verder¶

Dit hoofdstuk behandelt alleen de basisprincipes, maar moet toch een duidelijk inzicht bieden in hoe een ESB en SOA eruit moeten zien en wat er nodig is om succes te behalen.

Andere onderwerpen die hier niet aan bod komen, zijn onder meer (maar zijn niet beperkt tot):

• Hoe u managementsteun krijgt voor de invoering van een ESB
• Hoe SOA-architecten en analyseteams samen te stellen
• Vertegenwoordiging van het Canonical Data Model (CDM) in de organisatie
• Key Performance Indicators (KPI's) - Nu u over een gemeenschappelijke en uniforme methode beschikt voor het leveren van services tussen systemen, moet u beginnen met het observeren en analyseren van wat er feitelijk aan u wordt geleverd
• Business Process Management (BPM) - hoe en wanneer u een BPM-platform kiest voor servicemanagement (het antwoord is niet te vroeg, leer eerst hoe u prettige en nuttige services kunt bouwen)
• Wat te doen met systemen zonder API? Mocht de ESB bijvoorbeeld directe toegang hebben tot hun databases (het antwoord is dat dit varieert, er is geen gouden regel)

Dus wat is Zato?¶

Zato is een ESB- en applicatieserver geschreven met Python en kan worden gebruikt om middleware- en backend-systemen te bouwen. Het is open source-software met commerciële en gemeenschapsondersteuning. En Python is een programmeertaal die bekend staat om zijn eenvoud en efficiëntie.

Door Python en Zato te gebruiken, kunt u uw productiviteit verhogen en minder tijd verspillen.

Zato is geschreven pragmatici voor pragmatici. Dit is niet het zoveelste door een leverancier haastig gebouwde systeem in de nasleep van de ESB/SOA-hype.

In feite is Zato gebouwd op basis van praktische ervaring met het “bestrijding van branden” veroorzaakt door dergelijke systemen. In feite besteedden de auteurs van Zato zoveel tijd aan het bestrijden van dergelijke omgevingen dat ze vrijwel ongevoelig werden voor eventuele branden.

Dit is de smederij waaruit Zato ter wereld kwam en als zodanig kan het prestaties en gebruiksgemak bieden die niet in andere vergelijkbare oplossingen te vinden zijn.

Tot ziens Hier!

(Enterprise Service Bus) is ontworpen om een ​​gedistribueerd informatielandschap van een onderneming op te bouwen. Het softwareproduct zorgt voor de interactie van alle geïntegreerde applicaties in één centrum, combineert bestaande informatiebronnen en zorgt voor gecentraliseerde gegevensuitwisseling tussen verschillende informatiesystemen.

Enterprise Data Service Bus DATAREON ESB is een effectief middel om de stabiliteit en volledigheid van de informatie-uitwisseling te garanderen, de algehele prestaties van het informatiesysteem te verbeteren en de arbeidskosten voor het beheer ervan te verlagen.

Enterprise-servicebus

Softwareproduct DATAREON ESB officieel opgenomen in het uniforme register van Russische programma's voor elektronische computers en databases, dat kan worden gekocht door staats- en gemeentelijke instellingen (https://reestr.minsvyaz.ru/).

Om 2-3 informatiesystemen in kleine bedrijven te integreren, biedt DATAREON een softwareproduct aan dat is gemaakt op basis van DATAREON ESB - DATAREON MQ.

DATAREON ESB-functionaliteit

Taken opgelost met behulp van de bedrijfsdataservicebus

• Gegevensoverdracht tussen verschillende informatiesystemen (met routing of point-to-point)
• Vorming van een uniforme informatieruimte in heterogene omgevingen
• Een gedistribueerd systeem bouwen op basis van een gebeurtenismodel bij de volgende opties:
  • het bouwen van applicaties met end-to-end bedrijfsprocessen op basis van een gebeurtenismodel;
  • creatie van een systeem met synchronisatie van bedrijfsapplicaties in verschillende informatiesystemen
• Ontvangst schaalbare besturingsarchitectuur ondernemings-/holdingniveau
• Inzet systemen voor gegevensuitwisseling op transportniveau en op bedrijfslogicaniveau
• Het delegeren van de taak om informatiestromen op te bouwen analytische afdelingen
• Het verminderen van de algehele complexiteit van het integratieontwerp en het verminderen van de kanaalcapaciteitsvereisten
• Verhoogde algehele stabiliteit gegevensoverdracht op de transportlaag
• Lagere transactiekosten bij het uitwisselen van gegevens tussen verschillende afdelingen
• Lagere totale kosten voor onderhoud en ondersteuning van het informatiesysteem.

Voordelen van de DATAREON ESB Enterprise Data Service Bus

• Snelle integratie
• Hoge betrouwbaarheid
• Mogelijkheid om hulpbronnen te hergebruiken