Distributeur Havi Logistics koos in 2006 voor een service-oriented architecture (soa). Voordeel was dat daarbij de Java-connectoren uit een eerder geïmplementeerde oplossing voor enterprise application integration (EAI) voor een groot deel konden worden herbruikt.
De Duitse distributeur Havi Logistics bevoorraadt in 32 Europese landen onder meer McDonald's-vestigingen, benzinepompwinkels, supermarktketens en cateraars. In 1990 begon het bedrijf met het automatiseren van de zakelijke processen met toeleveranciers en afnemers. Doordat standaardsoftware nog niet beschikbaar was, ging de eigen ict-afdeling van Havi zelf aan de slag. Het team ontwikkelde een eigen applicatie en integreerde deze met een aangekocht boekhoudsysteem.
In de loop der jaren groeide het aantal applicaties, totdat in 2006 25 verschillende systemen naast elkaar bestonden. Havi zocht naar een manier om al deze applicaties binnen één architectuur te integreren. Een oplossing voor enterprise application integration (EAI) op basis van Java bood tijdelijk soelaas.
Keuze voor SOA
Toen het aantal afzetpunten doorgroeide tot ongeveer vijfduizend, moest Havi naar een andere oplossing op zoek. 'We moesten dringend overstappen op een gedistribueerde structuur', zegt senior manager applicatiebeheer Stefan Lang van Havi Logistics IS GmbH. 'We wilden onze klanten de best mogelijke ondersteuning geven, maar konden niet de technologie dicteren die ze gebruiken.'
Om die reden koos Havi voor een service-oriented architecture (soa). De distributeur selecteerde de Sonic Enterprise Service Bus (ESB) van Progress Software. Volgens Havi ondersteunde deze de overgang vanaf de bestaande middleware het best. De EAI was al message- en service-georiënteerd.
Services
Naar schatting bijna 80 procent van de bestaande Java-connectoren naar klantapplicaties kan aangesproken worden als services. In die gevallen verandert niets vanuit het gezichtspunt van de klant.
Dat geldt echter niet voor de oorspronkelijke kernapplicatie, die nog uit 1990 stamt. Ook andere systemen ontbreekt het aan service-oriëntatie. 'In die gevallen moeten we zelf services programmeren', vertelt Lang. In een aantal gevallen is zelfs besloten om bestaande klantsystemen niet aan te sluiten op de soa, omdat dat 'niet kostenefficiënt is'.
Toch is Lang tevreden.'Een XML-service uitrollen is een kwestie van dagen, terwijl dat in het vroegere EAI-systeem weken duurde. Bovendien is het nu mogelijk om de software-ontwikkeling uit te besteden aan onderaannemers, dankzij de ESB-documentatie die interfaces beschrijft. 'Dat zijn allemaal dingen die niet konden met onze bestaande middleware.'
De integratie moet uiterlijk in 2015 afgerond zijn.
EAI kan gerealiseerd mbv SOA. Het is dus niet het een of het ander. Het artikel had wellicht kunnen heten “Distributeur stapt af van Java-connectors om SOA te realiseren”.
De terminologie-waanzin staat me nogal tegen. EAI is een naam voor een oplossing voor het integreren van verschillende applicaties, SOA voor een architectuur en een gedachtengoed. Binnen SOA noemt men de EAI meestal een ESB (Enterprise Service Bus). Maar dat is alleen maar een EAI die ook goed overweg kan met webservice-technologie. Er zijn zoveel klepels en klokken in de artikelen die over deze materie te vinden zijn en waar het in dit artikel over gaat is dat men een oud door een nieuwer systeem vervangt omdat men meer wil doen met webservices. tja, daarin zijn ze niet de enige.
en java-connectoren? ook al zoiets raars. Middels Java kun je webservices aanbieden, java message queues, maar gerust ook allerlei andere interfaces. Het is het EAI/ESB platform dat zorgt voor de ontkoppeling van de applicatiespecifieke connector/koppelvlak naar andere koppelvlakken van andere applicaties.
Als we willen dat de verwarring stopt, moeten we ook stoppen met verwarring zaaien…