Er bestaat nog steeds veel verwarring over wat nu het verschil is tussen de termen eai (enterprise application integration) en soa (service oriented architecture). Voor sommigen is soa niets meer dan eai in een vernieuwde verpakking.
De cynici definiëren soa als eai met een dun laagje soap (simple object access protocol). Ze gebruiken soa op dezelfde wijze als eai, zien vergelijkbare voordelen, en beschouwen het als een marketingstunt om eai weer nieuw leven in te blazen.
Toch bestaan er wel degelijk grote verschillen. Wat de discussie wel altijd lastig maakt, is wat er precies met eai bedoeld wordt. De term eai kunnen we op twee manieren uitleggen. Ten eerste kan eai gezien worden als een vorm van integratie waarbij applicaties op de applicatielogicalaag geïntegreerd worden. Tegenhangers van eai zijn dan eii (enterprise information integration) en epi (enterprise presentation integration). Bij eii wordt er op de gegevenslaag gekoppeld. In feite zouden we datawarehousing als een vorm van eii kunnen beschouwen. Creëren we koppelingen via de user interface, dan spreken we over epi. Veel portalen zijn op basis van epi ontwikkeld. Ook als we oude mainframe applicaties met hun character-based, terminal-achtige interfaces benaderen (soms screen scraping genoemd), praten we over epi.
Eai is in deze discussie een term die verwijst naar de wijze waarop systemen geïntegreerd worden en niet zozeer naar de technologie, de standaarden of de producten die hierbij gebruikt worden. Het is een integratiestijl. Als we de term eai op deze manier interpreteren, dan is soa een vorm van eai, omdat we ook bij soa altijd hopen dat we de bestaande systemen op de applicatielogicalaag kunnen integreren.
De term eai heeft echter ook een andere verklaring: het is eveneens een productcategorie. Leveranciers als SeeBeyond (nu eigendom van Sun), Tibco, Vitria en Webmethods waren de grote spelers in deze markt. In feite hebben ze deze markt groot gemaakt en een gezicht gegeven. eai-producten hebben uiteraard de mogelijkheden om op de applicatielogicalaag te integreren en ondersteunen dus eai als integratiestijl. En hierdoor ontstaat meestal de verwarring.
Het doel van de klassieke eai-producten was interoperabiliteit: de mogelijkheid om gegevens en commando’s eenvoudig van de ene naar de andere applicatie te sturen. Hierbij blijven de applicaties zelf wel bestaan. Ze krijgen alleen meer mogelijkheden en functioneren meer als onderdeel van een groter geheel. En hier schuilt een groot verschil met soa. Soa heeft ook de doelstelling om applicaties met elkaar te laten communiceren, maar dit is niet het einddoel. Het einddoel is dat de klassieke applicatie verdwijnt en dat al de applicatielogica in de services terechtkomt. Uiteindelijk moet een soa bestaan uit een netwerk van services die alle taken van de bestaande applicaties hebben overgenomen. Hierdoor ontstaat er veel meer flexibiliteit en kunnen we sneller en makkelijker inspelen op veranderingen in de markt.
Soa is dus niet alleen eai. Het begint vaak met eai, maar naarmate een soa langer bestaat, zullen de applicaties langzaamaan uitgehold worden. Zoals gezegd, er zal steeds meer functionaliteit in de services terechtkomen. Dan hebben we het dus niet meer alleen over interoperabiliteit. En dat is het grote verschil tussen het doel van eai-producten enerzijds en dat van soa-producten anderzijds. Het doel op lange termijn is dus verschillend.
Dus soa is niet eai met een laagje soap. Een soa wordt uiteindelijk een platform waarop alle it-functionaliteit rust. Tenminste, dat is het doel en de droom. Of iedereen dit zal verwezenlijken, moet nog blijken. Want dit is wel een ambitieuze doelstelling. Als een organisatie een soa-product toch inzet alsof het een eai-product is, dan kunnen we ons sterk afvragen wat de toegevoegde waarde is. Misschien is soa dan alleen maar eai met behulp van soap. Ik denk niet dat we dan iets opgeschoten zijn.
Rick F. van der Lans
