DE TOEKOMST VAN ENTERPRISE APPLICATION INTEGRATION

DE TOEKOMST VAN ENTERPRISE APPLICATION INTEGRATION INTEROPERABILITEIT VAN J2EE EN .NET WEB SERVICES

DELFT, AUGUSTUS 2002 9203624 9281354

Mark Dumay Remco Groeneweg

Technische Universiteit Delft Faculteit Informatie Technologie en Systemen Afdeling Technische Informatica

2

Voorwoord Dit rapport behoort bij het vak OO Talen & Technieken, welke onderdeel uitmaakt van de doctoraalfase van de opleiding Technische Informatica. Doel van het vak is om de kennis en vaardigheden van studenten op OO-gebied te verdiepen en te verbreden. In dit rapport wordt ingegaan op het fenomeen web services. Hierbij wordt specifiek gekeken naar twee platformen die dit claimen te ondersteunen, te weten Microsoft .NET en Java 2 Enterprise Edition. Daarnaast wordt onderzocht of de web service de bestaande en toekomstige integratieproblematiek van applicaties vereenvoudigt. Mark Dumay en Remco Groeneweg. Delft, augustus 2002.

De illustratie op de voorkant van dit rapport is eigendom van SoftwareAG en afkomstig van de volgende URL: http://www.softwareag.com/corporat/products/webservices/default.htm#

3

4

Gehanteerde afkortingen API ASP CBD CLR CLS COM CORBA DCOM DNA EAI EIS EJB GAC HTTP IAI IDE IDL IIS IL IS IIOP J2EE JAX-RPC JAXM JAXR JMS LAN MOM RMI RPC SOAP TCP UDDI UML WSDL WSDP XML XSD

Application Programming Interface Active Server Pages Component-Based Development Common Language Runtime Common Language Specification Component Object Model Common Object Request Broker Architecture Distributed Component Object Model Distributed Network Architecture Enterprise Application Integration Enterprise Information System Enterprise JavaBeans Global Assembly Cache Hypertext Transfer Protocol Inter-enterprise Application Integration Integrated Development Environment Interface Definition Language Internet Information Server Intermediate Language Information System Internet Inter-Orb Protocol Java 2 Enterprise Edition Java API for XML-based RPC Java APIs for XML Messaging Java API for XML Registries Java Message Service Local Area Network Message-oriented middleware Remote Method Invocation Remote Procedure Call Simple Object Access Protocol Transfer Control Protocol Universal Description, Discovery, and Integration Unified Modeling Language Web Services Description Language Java Web Services Developer Pack Extensible Markup Language XML Schema Definition Language

5

6

Inhoudsopgave VOORWOORD

3

GEHANTEERDE AFKORTINGEN

5

1

INLEIDING

9

2

CASE BESCHRIJVING

11

3

INTER-ENTERPRISE APPLICATION INTEGRATION

13

3.1 3.2 3.3 3.4 3.5 4

DE TECHNIEK ACHTER WEB SERVICES 4.1 4.2 4.3

5

WEB SERVICE PROTOCOL HET J2EE PLATFORM HET .NET PLATFORM

19

25 25 25 27 33

INLEIDING ONTWERP IMPLEMENTATIE INSTALLATIE

DE .NET APPLICATIE DHB-ERP.NET 6.1 6.2 6.3 6.4

13 13 14 15 16 19 20 21

DE J2EE APPLICATIE HOTCOFFEE 5.1 5.2 5.3 5.4

6

INLEIDING DEFINITIE VAN EEN BEDRIJFSINFORMATIESYSTEEM SYSTEEMINTEGRATIE OP BEDRIJFSNIVEAU MIDDLEWARE ALS SYSTEEMINTEGRATIETECHNOLOGIE DE WEB SERVICE ALS MIDDLEWARE-EVOLUTIE

35 35 35 37 40

INLEIDING ONTWERP IMPLEMENTATIE INSTALLATIE

7

ERVARINGEN BIJ J2EE EN .NET INTEGRATIE

43

8

CONCLUSIE

45

LIJST VAN FIGUREN

47

REFERENTIES

49

7

8

1

Inleiding

Applicatie-integratie van bedrijfsinformatiesystemen (Engels: Enterprise Information Systems [EIS]) is momenteel een erg actueel thema in het vak van de IT. Met de ontwikkeling van vele afzonderlijke applicaties is er sprake van een heterogene informatievoorziening in veel bedrijven. De behoefte om die applicaties met elkaar samen te laten werken, dan wel opnieuw te implementeren, wordt dan ook steeds groter. Applicaties die al enkele jaren operationeel zijn, en veelal geïmplementeerd zijn middels inmiddels verouderde technieken, worden ook wel aangeduid met de term legacy applicatie. Opnieuw ontwikkelen van deze applicaties is veelal echter geen reële optie, voornamelijk vanwege de gepaard gaande kosten en gevergde tijdsbesteding. Nieuwe platformen, zoals J2EE en .NET, doen de belofte dat deze platformen de integratie met bestaande applicaties vergemakkelijken. Maar daarnaast gaan ze nog een stap verder: ze maken het ook eenvoudiger om applicaties van verschillende bedrijven aan elkaar te koppelen, zogenaamde bedrijfsketenintegratie. In dit rapport wordt dit aangeduid als Inter-enterprise Application Integration (IAI). Centraal concept hierbij is de webservice. Technisch gezien wordt er geen onderscheid gemaakt naar applicaties binnen een bedrijf of daar buiten. Het is de verwachting dat veel nieuwe EIS op een van beide platformen (J2EE of .NET) zullen worden ontwikkeld. Het is echter de vraag of het probleem van applicatie-integratie hiermee in de toekomst geheel verdwenen is. Dit rapport geeft hierop een antwoord door in beide platformen een webservice te implementeren en deze vervolgens met elkaar samen te laten samenwerken. Het onderzoek in dit rapport is gebaseerd op een zelf opgestelde casusbeschrijving, die een in onze ogen reëel vraagstuk op het vlak van bedrijfsketenintegratie beschrijft. Dit wordt uitgewerkt door allereerst het begrip IAI af te bakenen, waar met name de relatie tussen informatiesystemen en (bedrijfs)applicaties aan bod komt. Vervolgens worden web services vanuit een technische invalshoek bekeken. Op grond van de casus worden vervolgens twee applicaties uitgewerkt, waarvan één op basis van J2EE en de ander op basis van .NET. Vervolgens komen de ervaringen bij de koppeling van deze twee applicaties aan bod. Tot slot worden de algemene indrukken en ervaringen verwerkt in de conclusie van dit onderzoek.

9

10

2 Case beschrijving Koffiebranderij ‘De Heete Boon’ (DHB), welke is gevestigd in Haarlem te Nederland, is al sinds 1794 specialist in het prepareren en branden van koffiebonen. Voornaamste afzetmarkt van de geproduceerde koffie is de Benelux en Duitsland. DHB, welke diverse koffiemerken in handen heeft, zit momenteel op een marktaandeel van 24% en is hiermee de op één na grootste speler. De grote concurrent ‘StarCoffee’, een van oorsprong Amerikaans bedrijf, wist door een agressieve groeistrategie in 5 jaar tijd een marktaandeel van 31% te bemachtigen. DHB wil met StarCoffee gaan concurreren op prijs, waarbij ze wel garant wil staan voor een constante hoge kwaliteit. Daarnaast heeft de marketing&sales afdeling het plan opgevat de diversiteit van het productaanbod te vergroten. Hierbij wordt onder andere gedacht aan ‘Hete Boon Mocca Royal’ en ‘Hete Boon Excellent’. Voor beide producten zijn speciale koffiebonen benodigd, die niet door de huidige toeleveranciers kunnen worden verzorgd. De directie van DHB wil om de nieuwe strategie te kunnen verwezenlijken een verregaande ketenintegratie realiseren. Hierbij moeten de toeleveranciers en DHB intensief met elkaar kunnen communiceren over productaanbod, prijs en leveringsdatum. In de toekomst wordt er gedacht aan het realiseren van Just-in-Time productie, zodat er een minimale voorraad kan worden aangehouden. IT wordt gezien als het belangrijkste technologische middel dat kan worden ingezet. Om het project in goede banen te leiden, wordt allereerst een pilot opgezet, waarbij DHB en één toeleverancier betrokken zijn. Vanwege de goede verstandhouding tussen Karel Boon en een directielid van Microsoft Nederland, bezit DHB een serverpark op basis van Windows 2000. Bovendien is er recentelijk een licentie van Visual Studio.NET verkregen. De toeleverancier in Guatemala moet het echter met een oude Pentium doen, die ook nog eens regelmatig niet te gebruiken is vanwege stroomuitval. Hierop draait een Linux distributie van RedHat, met een gratis reference implementatie van Sun J2EE. De applicaties DHB-ERP.NET en HotCoffee zijn onafhankelijk van elkaar ontworpen en geïmplementeerd. De systeemintegratie is dan ook iets wat op basis van de bestaande applicaties dient te worden gerealiseerd. Wel kan hier gebruik worden gemaakt van de bestaande ontwerpen en broncode. Na de pilot wil de directie van DHB graag een rapport verkrijgen, met daarin een theoretische achtergrond van systeemintegratie. Daarnaast moet het rapport kunnen dienen als basis voor de technici die een eventueel systeem gaan realiseren. Dit betekent eveneens dat er een goede beschrijving moet komen van de eventuele tekortkomingen van de voorgestelde techniek. De pilot moet dan ook vooral worden gezien als een proofof-concept.

11

12

3 Inter-enterprise application integration Dit hoofdstuk geeft een uitleg van het begrip inter-enterprise application integration en de daarbij behorende definities. Achtereenvolgens worden de begrippen bedrijfsinformatiesysteem, applicatie-integratie, middleware en web service besproken.

3.1 Inleiding Inter-enterprise application integration (IAI) is het onderzoeksgebeid dat zich bezighoudt met de koppeling van bedrijfsapplicaties van verschillende bedrijven. Vanuit een informaticaperspectief wordt gekeken hoe bedrijfsketenintegratie kan worden gerealiseerd of geoptimaliseerd. De nadruk ligt hierbij op procesintegratie. Dit betekent dat het niet zo zeer gaat om de applicaties daadwerkelijk met elkaar te integreren, maar dat de applicaties met elkaar moeten kunnen samenwerken om samen een proces tussen twee of meerdere bedrijven te realiseren. IAI kan worden gezien als de volgende stap in de bedrijfsautomatisering, waarbij werkzaamheden door personen om de processen van verschillende bedrijven aan te laten sluiten worden gerealiseerd door een automatiseringsoplossing. Technisch gezien is het zogenaamde middleware die bedrijfsinformatiesystemen van verschillende organisaties met elkaar integreert. Om nu de begrippen bedrijfsketenintegratie en IAI een betere invulling te kunnen geven, is het zinvol eerst deze onderliggende concepten te definiëren.

3.2 Definitie van een bedrijfsinformatiesysteem Van het begrip bedrijfsinformatiesysteem, in het Engels aangeduid met enterprise information system (EIS), bestaan vele definities. Het onderscheid met het onderliggende begrip information system (IS) is ook niet geheel evident. Vanuit een managementperspectief is er veelal sprake van een koppeling met een of meerdere bedrijfsprocessen. Een dergelijk systeem maakt gebruik van informatietechnologie om informatie te benaderen en/of te manipuleren1. Het systeem kan niet los worden gezien van de omgeving, die typisch bestaat uit mensen, voorschriften en werkwijzen. Een meer technische benadering betrekt nadrukkelijk telecommunicatie- of computerapparatuur bij het systeem2. Om tot een scherper onderscheid te komen tussen een IS en een EIS, wordt de laatste een hoger abstractieniveau toebedacht. Een EIS is de totale verzameling van informatiesystemen die tezamen de informatie-infrastructuur vormen van een bedrijf3. Een IS vormt in deze context de ondersteuning van een afgebakend bedrijfsproces. 1

Zie [01], p. 61. Zie [04], URL: http://www.its.bldrdoc.gov/projects/devglossary/_information_system.html 3 Zie [01], URL: http://java.about.com/library/glossary/bldef-eis.htm 2

13

Hierbij is een applicatie een daadwerkelijk gerealiseerd softwaresysteem. Vanwege de definitie bestaat een IS uit één of meerdere applicaties, waarbij het IS de onderlinge coherentie van deze applicaties waarborgt. In figuur 3-1 wordt de samenhang tussen de begrippen EIS, IS en applicatie grafisch weergegeven. Elke ovaal geeft invulling aan een verzameling op een bepaald niveau.

EIS Applicatie

Applicatie

Applicatie Applicatie

IS

IS

figuur 3-1 De samenhang tussen EIS, IS en applicatie

De samenhang tussen IAI en bedrijfsinformatiesystemen wordt in figuur 3-2 geïllustreerd. De gestippelde lijn geeft een grens tussen twee bedrijven aan. Interenterprise integratie heeft nu als doel om de twee bestaande EIS met elkaar te laten communiceren. EIS

EIS IAI

IS

IS

IS

IS

figuur 3-2 Weergave van inter-enterprise application integration

3.3 Systeemintegratie op bedrijfsniveau Zoals vermeld in paragraaf 3.2 bestaat een IS uit één of meerdere applicaties. Doordat veel van deze aanwezige applicaties los van elkaar zijn geïmplementeerd en/of ingericht, is er vaak sprake van een heterogeen geheel. De samenhang verkrijgen en vergroten tussen deze applicaties is een doelstelling van applicatie-integratie. De algemene benaming voor applicatie-integratie op bedrijfsniveau is Enterprise Application Integration (EAI). EAI bestaat uit methoden en technieken om de computer applicaties in een organisatie te moderniseren, te consolideren en te coördineren4. Deze erg ruime definitie maakt geen onderscheid tussen de begrippen EIS, IS en/of applicatie. Veelal wordt een applicatie synoniem gesteld aan een informatiesysteem. Om verwarring te voorkomen maken we hier onderscheid tussen een bedrijfsapplicatie en een applicatie. 4

Zie [09], URL: http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci213523,00.html

14

Een bedrijfsapplicatie is een reëel softwaresysteem, die kan bestaan uit één of meerdere applicaties. Het verschil met een IS is dat een bedrijfsapplicatie geen inbegrip heeft van methoden en processturing. Wel bevat een IS in onze definitie altijd één bedrijfsapplicatie. Herdefinitie van EAI zegt dan dat deze bestaat uit methoden en technieken om bestaande bedrijfsapplicaties in een organisatie te herinrichten, dusdanig dat er een optimale samenhang in de informatievoorziening van een organisatie wordt verkregen. Aangezien EAI volgens bovenstaande definitie nadrukkelijk spreekt over bedrijfsapplicaties, en niet over IS, heeft EAI in onze ogen voornamelijk een technische insteek. Procesorganisatie op organisatorische grondslag is een aspect dat bij de integratie van bedrijfsprocessen en informatiesystemen zeker niet over het hoofd mag worden gezien, maar is niet primair de taak van EAI. Deze zou wel als de technische aanvulling en/of invulling hierop kunnen worden gezien.

3.4 Middleware als systeemintegratietechnologie De gebruikte technologie in het vakgebied van EAI wordt in het algemeen aangeduid als middleware. Het kan gezien worden als de bemiddelaar tussen twee of meerdere systemen, zodat er een min of meer geïntegreerd systeem ontstaat. Grofweg zijn er twee verschillende groepen middleware te onderscheiden: • Distributed object middleware; • Message-oriented middleware (MOM). Distributed object middleware maakt het mogelijk dat objecten op verschillende fysieke machines met elkaar kunnen communiceren. Traditioneel werd hierbij ingezet op local area networks (LAN). Doel van de platformen die dit realiseren is het zo transparant mogelijk aanbieden van deze faciliteit aan de systeemontwerpers. Een veelgehanteerde term voor aanroepen over systeemgrenzen heen is de remote procedure call (RPC). Dit gebeurt op basis van synchrone communicatie, wat wil zeggen dat er gewacht wordt op resultaat voordat het huidige proces verder wordt doorlopen. Voorbeelden van distributed object middleware zijn DCOM en CORBA. DCOM, wat staat voor Distributed Component Object Model, is de techniek die Microsoft ontwikkeld heeft voor met name Windows netwerken. Officieel wordt het tegenwoordig onderhouden door het ActiveX consortium en er zijn ook diverse implementaties op andere platformen5. De tegenhanger van DCOM is de Common Object Request Broker Architecture (CORBA), welke is ontwikkeld door de Object Management Group (OMG); een samenwerkingsverband van ruim 500 IT-bedrijven6.

5

Zie [06], URL: http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/ prodtechnol/winntas/plan/dcomtowp.asp?frame=true 6 Zie [09], URL: http://searchdatabase.techtarget.com/sDefinition/0,,sid13_gci213865,00.html

15

Message-oriented middleware maakt het mogelijk dat applicaties berichten met elkaar uitwisselen. In tegenstelling tot een RPC) zoals die in veel ontwikkelplatformen voorhanden is, heeft MOM als uitgangspunt asynchrone communicatie. Dat wil zeggen dat een bericht in een wachtrij wordt geplaatst, en het antwoord op een vrij willekeurig tijdstip kan terugkomen. Populaire implementaties van MOM-producten zijn MQ Series van IBM en Software AG’s EntireX7.

3.5 De web service als middleware-evolutie In paragraaf 3.4 is het begrip middleware uiteengezet en werd het uitgelegd als de technologie die applicatieintegratie mogelijk maakt. Om een duidelijker onderverdeling te verkrijgen, splitsen we dit uit naar de volgende drie niveaus van integratie: • Applicatieniveau; • Bedrijfsapplicatieniveau; • Interbedrijfsapplicatieniveau. Met de toenemende schaalgrootte van veel organisaties worden er ook andere eisen gesteld aan systeemintegratie. Voorheen lag de nadruk op het koppelen van bestaande applicaties tot een bedrijfsapplicatie (zie paragraaf 3.3). Typisch gezien maakten deze deel uit van hetzelfde LAN en veelal werden allereerst applicaties die met dezelfde softwaretechnologie waren gerealiseerd met elkaar geïntegreerd. In een dergelijke situatie kan een technologie als COM of CORBA-implementatie goede diensten bewijzen. Op bedrijfsapplicatieniveau, ofwel het integreren van bestaande bedrijfsapplicaties tot een EIS, neemt ook de orde van de heterogeniteit van systeemplatformen toe. Veelal is het ondoenlijk COM of CORBA te gebruiken in dit geval, simpelweg omdat de standaarden voor gegevensuitwisseling niet toereikend zijn. Op interbedrijfsapplicatieniveau spelen dezelfde problemen als op bedrijfsapplicatieniveau, alleen is een extra complicerende factor de beveiliging van de systemen. Deze systemen maken over het algemeen geen deel uit van afgeschermd netwerk, maar zijn hiervoor afhankelijk van bijvoorbeeld het internet. In het kort zijn er twee problemen die met de bestaande middleware naar voren komen: • Er ontbreken goede gegevensstandaarden; • Communicatie maakt integraal deel uit van de systeemarchitectuur. Veel van de gebruikte protocollen werken met binaire standaarden voor gegevensoverdracht, die echter vaak moeilijk te vertalen is naar andere platformen. Een voorbeeld hiervan is de byte-volgorde, die per operating system kan afwijken. Daarnaast is systeemintegratie over het algemeen niet iets wat simpel achteraf kan worden toegevoegd. Dit bekent niet alleen dat de broncode van de bestaande systemen moet worden aangepast, maar dat in veel gevallen de gebruikte architectuur moet worden herzien. 7

Zie [09], URL: http://searchsecurity.techtarget.com/tip/1,289483,sid14_gci557159,00.html

16

De web service is een relatief nieuwe manier in de strijd voor systeemintegratie. Het biedt onder andere een standaard voor gegevensoverdracht, die is gebaseerd op Extensible Markup Language (XML). De web service kan gezien worden als een schil die om de bestaande informatievoorziening van een bedrijf heen wordt gelegd. Met name op het gebied van bedrijfsapplicatie- en interbedrijfsapplicatieintegratie biedt dit goede perspectieven.

17

18

4 De techniek achter web services Dit hoofdstuk geeft inzicht in de technische aspecten van web services. Allereerst worden de onderliggende platformonafhankelijke standaarden weergegeven. Vervolgens worden voor achtereenvolgens het J2EE en het .NET platform de belangrijkste communicatiemechanismen besproken. Tevens wordt uitgelegd hoe een web service in het desbetreffende platform kan worden gerealiseerd.

4.1 Web service protocol In paragraaf 3.5 is de term web service geïntroduceerd. Het biedt de mogelijkheid om processen tussen meerdere bedrijven op elkaar af te stemmen. Communicatie gebeurt op basis van gestandaardiseerd berichtenverkeer. 4.1.1 SOAP De achterliggende technologie voor het berichtenverkeer is het SOAP protocol. SOAP staat voor Simple Object Access Protocol en is onder andere en schemadefinitie op basis van Extensible Markup Language (XML). Dit betekent niet alleen dat er een afspraak is over de syntax, maar ook dat alle gegevens voldoen aan een ISO-standaard. SOAP garandeert dus dat de gegevens op elk platform op de juiste manier kunnen worden geïnterpreteerd. SOAP berichten kunnen vanwege hun eenvoudige opmaak en structuur moeiteloos worden verwerkt door de standaard internetprotocollen. Zo is een dergelijk bericht via HTTP over poort 80 te verzenden, zonder dat deze wordt gehinderd door bijvoorbeeld een firewall8. 4.1.2 WSDL Naast de standaard voor berichtenverkeer bieden web services ook een universele manier om faciliteiten te definiëren. Zoals opgemerkt in paragraaf 3.5 kunnen de web services tezamen worden gezien als een schil om het EIS heen, die bepaalde functionaliteit toegankelijk maakt. Deze interface wordt gespecificeerd middels de web services description language (WSDL). Net als SOAP is WSDL gedefinieerd in een XML schema (XSD). 4.1.3 UDDI Naast SOAP en WSDL is de derde standaard van belang voor web services Universal Description, Discovery, and Integration (UDDI). Het is een mechanisme die het mogelijk maakt web services publiekelijk bekend te maken9. Via de website www.uddi.org is het mogelijk diensten te zoeken en aan te melden bij de aangesloten partners. Doordat veel bedrijven niet gewillig zijn om hun diensten open te stellen voor willekeurige gebruikers, is het ook mogelijk UDDI op bedrijfsniveau in te zetten. Op 8 9

Zie [09], URL: http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci214295,00.html Zie [09], URL: http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci508228,00.html

19

deze manier kunnen bijvoorbeeld de bestaande applicaties op een universele manier op het intranet worden aangeboden.

4.2 Het J2EE platform Deze paragraaf geeft een algemene indruk van J2EE, gevolgd door een bespreking van de belangrijkste interne communicatiemechanismen. Tot slot wordt ingegaan op de ondersteuning voor web services, en dan met name in vergelijk met de specificaties van paragraaf 4.1. 4.2.1 Inleiding J2EE, wat staat voor Java 2 Enterprise Edition, is een verzameling van APIs die het aanmaken van gedistribueerde applicaties vereenvoudigen. In de eerste plaats is J2EE geen product maar een standaard, die door Sun is opgesteld. Het programmeermodel maakt gebruik van een onderliggend platform, wat door diverse leveranciers wordt geleverd. Het staat leveranciers ook toe om een Integrated Development Environment (IDE) te verkopen, die kan werken als (grafische) schil om het platform heen. Wel biedt Sun een zogenaamde reference implementatie, die gratis kan worden gebruikt. De taal van het J2EE platform is, zoals de naam al suggereert, Java. Het principe van Java, ‘write once, run everywhere’, blijft gehandhaafd. Eigenlijk verandert er voor de traditionele gebruiker van Java ook niet veel, behalve dat er een uitgebreidere bibliotheek beschikbaar is, om bijvoorbeeld de integratie met bestaande systemen te vergemakkelijken. Het componentmodel wordt in J2EE gerealiseerd door de zogenaamde Enterprise JavaBeans (EJB). 4.2.2 Platformgeoriënteerde communicatiemechanismen J2EE maakt standaard gebruik van Remote Method Invocation – Internet Inter-Orb Protocol (RMI-IIOP) als communicatiemechanisme. RMI-IIOP is in feite een CORBA implementatie in Java. Het protocol is ontwikkeld in samenwerking met IBM en combineert volgens [07] de Java RMI technologie met de beste features van CORBA. De bouwstenen van J2EE, de Enterprise JavaBeans, gebruiken het protocol om elkaar aan te roepen. Verder is het protocol geschikt om met de meeste bestaande EIS die gebruikmaken van het eerdergenoemde gedistribueerde objectmodel te communiceren. RMI-IIOP is uitgebracht in mei 2000 en is het antwoord op de toenemende vraag naar Java applicaties die met de wijdverbreide CORBA gebaseerde informatiesystemen konden samenwerken. De Java Message Service (JMS) API biedt functionaliteit om Java applicaties te laten samenwerken met allerlei MOM-producten. Het moet het mogelijk maken om legacysystemen, Enterprise Resource Planning (ERP) -systemen en allerlei andere applicaties met elkaar te integreren. De APIs zijn volgens Sun in nauwe samenwerking met de industrie ontworpen en zouden net zoals de Java Database Connectivity (JDBC) APIs op een uniforme manier moeten werken. De interface is gedefinieerd door Sun, de

20

implementatie voor een bepaald middleware product doet de leverancier van het betreffende product. 4.2.3 Ondersteuning voor web services Sun heeft voor de implementatie van web services een verzameling van verschillende APIs, onder de noemer Java Web Services Developer Pack (WSDP). Belangrijkste onderdeel hierin is de Java APIs for XML Messaging (JAXM). Het zorgt ervoor dat applicaties berichten kunnen zenden en ontvangen, op basis van SOAP 1.1. JAXM is meer bedoeld voor asynchrone communicatie terwijl een andere API, de Java API for XML-based RPC (JAX-RPC) een RPC-mechanisme op basis van SOAP implementeert. De laatste versie Java APIs for XML Processing (JAXP) biedt ondersteuning voor WSDL, maar op het moment van schrijven is de documentatie hiervan nog niet compleet. JAXM heeft geen functionaliteit voor het aanmaken van berichten op basis van een WSDL beschrijving. Het aanroepen van een remote webservice met een Java programma is wel mogelijk, vooralsnog moet dan wel handmatig de WSDL beschrijving worden vertaald naar programmacode. Webservices worden in Java geïmplementeerd in servlets, deze zijn in een J2EE applicaties vaak ook te vinden in de web-container samen met JSPs. Het voordeel van deze benadering is dat de functionaliteit van de J2EE applicatie in dezelfde container beschikbaar wordt gesteld als webpagina en webservice. Het publiekelijk bekend maken van web services, onder andere op basis van UDDI, wordt in J2EE ondersteund door Java API for XML Registries (JAXR).

4.3 Het .NET platform Deze paragraaf geeft inzicht in het .NET platform. Twee aspecten, te weten communicatiemechanismen voor het .NET platform en web services, krijgen hierna extra aandacht. 4.3.1 Inleiding Het Microsoft .NET framework is een verzameling van systeembibliotheken, die gezamenlijk een enigszins abstracte toegang tot het onderliggende besturingssysteem bieden. Het framework bevat tevens een code-executieplatform, de Common Language Runtime geheten (CLR). Met deze CLR kan geïnterpreteerde code worden uitgevoerd. De CLR draait op de machine in een zogenaamde host. Deze host is ook degene die een applicatie uitvoert. Er zijn meerdere hosts, waarvan tenminste één werkt met Internet Information Server (IIS)10. Zodoende is het ook mogelijk via een HTTP-request een .NET dienst aan te spreken. Deze code voor CLR wordt aangeduid met de term Intermediate Language (IL). Het framework bevat meerdere compilers, die bijvoorbeeld C#, Managed C++ en Visual 10

Covalent Enterprise Ready Server maakt het mogelijk .NET te integreren met de web server Apache.

21

Basic.NET code kunnen omzetten naar IL. Eigenlijk is de term compiler hier onjuist, omdat er strikt genomen alleen een interpretatie plaatsvindt. Elke willekeurige programmeertaal kan worden ondersteund door het framework, zolang deze maar voldoet aan de Common Language Specification (CLS). 4.3.2 Platformgeoriënteerde communicatiemechanismen Centraal begrip in .NET is de assembly. Een assembly is vergelijkbaar met een component, en heeft inbegrip van applicatiecode, versie-informatie en toegangscontrole. In de Global Assembly Cache (GAC) worden deze assemblies bekend gemaakt op het locale systeem. Doordat het .NET framework een Common Type System heeft, zijn gegevens tussen verschillende assemblies zonder meer overdraagbaar. Om resources en toegang tot applicaties te kunnen reguleren, kent .NET het application domain. Zolang assemblies uit hetzelfde domein elkaar aanroepen, zijn deze methods calls lokaal. Bij aanroepen tussen verschillende domeinen, die ook op verschillende machines kunnen verblijven, wordt gebruik gemaakt van .NET Remoting. Hierbij wordt het remote object middels een proxy of een kopie lokaal benaderd. Het aangeroepen object definieert dit door de klasse MarshalByRefObject te implementeren. Dit betekent hoe dan ook dat de metagegevens van het aangeroepen object bekend moeten zijn op het lokale systeem, van waar de aanroep afkomstig is. De communicatie tussen de domeinen gebeurt middels een channel, die naar eigen keuze via bijvoorbeeld TCP of HTTP kan verlopen, in zowel ASCII als binaire vorm. De laatste vorm van communicatie dwingt dan wel af dat beide partijen om kunnen gaan met deze binaire standaard, iets wat typisch niet geldt voor multiplatform oplossingen. Als laatste is het in .NET ook mogelijk om met COM componenten te communiceren, bekend als COM Interop. Het grootste verschil is dat .NET in managed code draait, en COM in unmanaged code. Dit betekent dat met name het geheugengebied in .NET wordt beheerd door het .NET framework, en bij COM door het onderliggende operating system. Er zijn klassen die het mogelijk maken gegevens tussen beide geheugentypen op een relatief veilige manier te transporteren. 4.3.3 Ondersteuning voor web services De web service is een integraal onderdeel van het .NET framework. Met name ASP.NET biedt een snelle en gemakkelijke manier om een service te definiëren, aangezien deze standaard het WSDL schema kan aanmaken en SOAP over HTTP via GET en POST kan afhandelen. Het is ook mogelijk dit handmatig te doen via .NET remoting (besproken in paragraaf 4.3.2). ASP.NET maakt een .ASMX bestand aan, dat werkt met IIS (mits het .NET framework is toegevoegd). Door in de code (typisch is dit code-behind, waarbij presentatie en code in de internetpagina van elkaar gescheiden zijn) een afgeleide klasse van ‘System.Web.Services.WebService’ te maken en een meta-tag ‘[WebMethod]’ toe te voegen aan de methodes toe te voegen, is de web service een feit.

22

Het zoeken en registeren bij een publieke repository zoals UDDI, is geen standaard onderdeel van .NET. Wel bieden vele UDDI websites een web service aan, waarmee middels SOAP kan worden gecommuniceerd. Deze kan binnen de applicatie met behulp van een proxy eenvoudig worden aangesproken.

23

24

5 De J2EE applicatie HotCoffee Dit hoofdstuk geeft een globale indruk van de applicatie HotCoffee, die met behulp van J2EE is gerealiseerd. Allereerst wordt er een algemene inleiding gegeven, gevolgd door het ontwerp en de implementatie van de applicatie. Tot worden de stappen doorgenomen die zich typisch bij een installatie voordoen.

5.1 Inleiding Onlangs is er door de Verenigde Naties een emancipatieprogramma gestart, dat als doel heeft de lokale koffieboeren uit Guatemala minder afhankelijk te maken van tussenhandelaren. Via een gesponsord programma zijn Linux servers ter beschikking gesteld waarop de koffieboeren via internet rechtstreeks hun koffie kunnen aanbieden. De afnemers zijn vooral koffiebranders uit Europa en de Verenigde Staten. De applicatie die dit mogelijk maakt is ‘HotCoffee’. Deze is gebaseerd op een reference implementatie van J2EE en is geïmplementeerd als web service. Het is de bedoeling dat dit mechanisme wordt gedemonstreerd, door met een toonaangevende Europese koffieproducent een pilot op te zetten.

5.2 Ontwerp 5.2.1 Use cases Zoals vermeld in de casus (zie hoofdstuk 2) wil DHB met de toeleveranciers kunnen communiceren over productaanbod, prijs en leveringsdatum. De belangrijkste functionaliteit is dat DHB voortaan rechtstreeks bij de koffieboer kan bestellen. In de toekomst wordt er verder nog gedacht aan het realiseren van functionaliteit ter ondersteuning van Just-in-Time productie, zodat er een minimale voorraad kan worden aangehouden. De beheersfunctionaliteit voor de koffieboeren wordt hier verder buiten beschouwing gelaten.

figuur 5-1 Use case diagram van HotCoffee

25

In figuur 5-1 wordt het UML use case diagram van de HotCoffee applicatie weergegeven. Deze geeft de volgende functionele eisen aan het systeem weer: • Bestellen – DHB moet in staat zijn afhankelijk van het aanbod een bestelling te kunnen doen voor een levering koffiebonen; • OpvragenProductAanbod – DHB moet het productaanbod kunnen opvragen; • OpvragenPrijs – DHB moet de actuele prijzen van alle producten kunnen opvragen. Deze prijzen zijn aan constante verandering onderhevig en afhankelijk van de prijs van koffiebonen op de wereldmarkt; • OpvragenLeveringsDatum – DHB moet weten wanneer een product geleverd kan worden. Deze use cases worden hier niet verder gedefinieerd, aangezien deze alleen ter illustratie dienen. 5.2.2 Klassendiagram Het klassendiagram dat naar aanleiding van de functionele eisen is gemaakt, staat weergegeven in figuur 5-2. Het is gescheiden is twee delen, te weten de ‘Web Container’ en de ‘EJB Container’.

figuur 5-2 Klassendiagram HotCoffee

Het klasseontwerp is op basis van de use cases en typische J2EE design patterns [08] gemaakt. Met betrekking tot de bouwstenen in een J2EE applicatie maken we onderscheid tussen de volgende Beans: 26

• •

•

Session Beans worden meestal gebruikt als beheersobjecten. Ze kunnen taken verrichten voor de clients; Entity Beans representeren persistente bedrijfsobjecten zoals Order en Klant. Deze objecten worden opgeslagen in een database waarbij elke entity bean een onderliggende tabel heeft in de database en elke instantie van de entity bean correspondeert met een rij in deze tabel; Message-driven Beans zijn stukjes code die dienen als een JMS listener. Deze beans zijn in staat asynchrone berichtjes af te handelen, dit om te kunnen communiceren met MOM. Deze worden niet gebruikt in de applicatie.

Het is de bedoeling dat de applicatie de use cases ook als webservice beschikbaar stelt. Ze moeten dus aanroepbaar zijn met SOAP berichten. Met behulp van JAXM kunnen we deze webservices boven op onze beans construeren. Binnen de webcontainer definiëren we hiervoor een aantal klassen die in staat zijn SOAP berichten te ontvangen. LineItem is een hulpklasse met dezelfde attributen als Product, echter waaraan een veld quantity is toegevoegd. De klasse wordt beheerd door de Entity Beans Product en Order en heeft zijn eigen tabel in de database.

5.3 Implementatie Deze paragraaf bespreekt de implementatie van de applicatie HotCoffee. Allereerst komen de componenten aan bod, gevolgd door de code voor de web service. 5.3.1 Componenten Zoals in het klassendiagram in paragraaf 5.2.2 te zien is, bestaat de applicatie uit meerdere componenten, die door het web service gedeelte toegankelijk worden gemaakt. Elk component, ofwel Enterprise JavaBean (EJB) bestaat uit drie afzonderlijke delen: • De Remote interface – een interface klasse die de methoden van de bean definieert; • De Home interface – een interface klasse die de methoden definieert om de bean aan te maken, op te zoeken of te verwijderen; • De Enterprise Bean klasse – deze klasse bevat de implementatie van de methoden die gedefinieerd staan in de remote interface en home interface. Alle enterprise beans die remote toegankelijk zijn moeten een remote interface en een home interface gedefinieerd hebben. Omdat een enterprise bean in een EJB container wordt uitgevoerd kan een client (bijvoorbeeld een servlet of JSP) de bean niet rechtstreeks instantieren, de container beheert immers het aanmaken en afsluiten van de beans. De home interface definieert dus wat de client wel en niet mag. Ter illustratie hiervan zijn voor de entity bean Order enkele codevoorbeelden opgenomen. Allereerst is in figuur 5-3 de Remote interface weergegeven. Deze interface definieert een viertal methoden, die overeenkomen met het klassendiagram. In die zin kan de interface dan ook als contract worden gezien tussen de bean en de gebruikers hiervan.

27

import javax.ejb.EJBObject; import java.rmi.RemoteException; import java.util.*; public interface Order extends EJBObject { public ArrayList getLineItems() throws RemoteException; public String getCustomerId() throws RemoteException; public double getTotalPrice() throws RemoteException; public String getStatus() throws RemoteException; } figuur 5-3 Java Remote interface Order

De Home interface van de EJB Order is te zien in figuur 5-4. De methoden create, findByPrimaryKey en findByProductId zijn allen administratieve functies om de bean te kunnen beheren. import java.util.*; import java.rmi.RemoteException; import javax.ejb.*; public interface OrderHome extends EJBHome { public Order create(String orderId, String customerId, String status, double totalPrice, ArrayList lineItems) throws RemoteException, CreateException; public Order findByPrimaryKey(String orderId) throws FinderException, RemoteException; public Collection findByProductId(String productId) throws FinderException, RemoteException; } figuur 5-4 Java Home interface OrderHome

De daadwerkelijke implementatie van de bean staat in de klasse OrderBean, gedefinieerd in figuur 5-5. Zoals aangeduid in het klassendiagram is deze bean een zogenaamde entity bean, waardoor deze klasse communiceert met een database. Er is hier geen gebruik gemaakt van managed persistence, zodat de SQL code om de bean in de database op te slaan in de code van de bean zelf staat. Aangezien de code van de klasse vrij lang is, wordt alleen de methode ejbCreate weergegeven. De create methode van de home interface correspondeert met de ejbCreate methode in de bean klasse. Aangezien EJBs RMI(-IIOP) gebruiken om remote methods aan te roepen is een remote interface noodzakelijk. De methode insertOrder bevat vervolgens de SQL code om de gegevens in de juiste tabel in de database op te slaan.

28

public class OrderBean implements EntityBean { public String ejbCreate(String orderId, String customerId, String status, double totalPrice, ArrayList lineItems) throws CreateException { try { insertOrder(orderId, customerId, status, totalPrice); for (int i = 0; i < lineItems.size(); i++) { LineItem item = (LineItem)lineItems.get(i); insertItem(item); } } catch (Exception ex) { throw new EJBException("ejbCreate: " + ex.getMessage()); } this.orderId = orderId; this.customerId = customerId; this.status = status; this.totalPrice = totalPrice; this.lineItems = lineItems; return orderId; } } figuur 5-5 Java Enterprise Bean OrderBean

5.3.2 Web service Het web service gedeelte van de applicatie wordt geïmplementeerd als messaging provider container. Hiervoor maken we gebruik van JAXM (zie paragraaf 4.2.3), welke bestaat uit twee packages: • javax.xml.soap – Deze package bevat de basisfunctionaliteit om SOAP berichtjes aan te maken en te vullen; • javax.xml.messaging – Deze package bevat de API om gebruik te maken van een messaging provider. We zullen in onze applicatie geen gebruik maken van messaging providers en derhalve hier verder niet op ingaan. Aangezien SOAP niets anders is dan XML over HTTP kunnen we de webservice binnen onze applicatie eenvoudig implementeren met behulp van een Java servlet. In tegenstelling tot de gebruikelijke servlets genereert deze nu XML in plaats van HTML als uitvoer. De code voor de OrderServlet staat weergegeven in figuur 5-6. Het try-block van de methodes onMessage en doPost wordt verderop uitgewerkt. 29

public class OrderServlet extends HttpServlet { static MessageFactory fac = null; static { try { fac = MessageFactory.newInstance(); } catch (Exception ex) { ex.printStackTrace(); } }; MessageFactory msgFactory; public void init(ServletConfig servletConfig) throws ServletException { super.init(servletConfig); try { // Initialize it to the default. msgFactory = MessageFactory.newInstance(); } catch (SOAPException ex) { throw new ServletException("Unable to create message" + "factory" + ex.getMessage()); } } public void doPost( HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { try { ... } catch (Exception ex) { throw new ServletException( "JAXM POST failed " + ex.getMessage()); } } public SOAPMessage onMessage(SOAPMessage message) { SOAPMessage confirmation = null; try { ... } catch (Exception ex) { ex.printStackTrace(); } return confirmation; } } figuur 5-6 Java Servlet class OrderServlet

30

De code voor het verwerken van SOAP berichten staat in de methode doPost, te zien in figuur 5-7. De klasse MessageFactory biedt functionaliteit om de inputstream om te zetten naar een SOAP bericht. Met SOAPMessage kan de inhoud van het SOAP bericht worden geëxtraheerd. De OrderServlet geeft na ontvangst antwoord door een een SOAPMessage object reply te declareren en te vullen met behulp van de methode onMessage. // Get all the headers from the HTTP request MimeHeaders headers = getHeaders(req); // Get the body of the HTTP request. InputStream is = req.getInputStream(); // Now internalize the contents of the HTTP request and // create a SOAPMessage SOAPMessage msg = msgFactory.createMessage(headers, is); SOAPMessage reply = null; reply = onMessage(msg); if (reply != null) { // Need to call saveChanges because we're going to // use the MimeHeaders to set HTTP response // information. These MimeHeaders are generated as // part of the save. if (reply.saveRequired()) { reply.saveChanges(); } resp.setStatus(HttpServletResponse.SC_OK); putHeaders(reply.getMimeHeaders(), resp); // Write out the message on the response stream. OutputStream os = resp.getOutputStream(); reply.writeTo(os); os.flush(); } else resp.setStatus(HttpServletResponse.SC_NO_CONTENT);

figuur 5-7 Java code voor de methode doPost

Als reply niet leeg is wordt de status van resp op OK gezet en worden de headers en inhoud van reply geschreven naar resp. Als reply leeg is, wordt de status van resp veranderd om aan te geven dat er geen inhoud is. De methode onMessage vult het SOAP bericht dat als ontvangstbevestiging wordt gestuurd. De code hiervoor is weergegeven in figuur 5-8.

31

//retrieve the orderID elementfrom the message received SOAPBody sentSB = message.getSOAPPart().getEnvelope().getBody(); Iterator sentIt = sentSB.getChildElements(); SOAPBodyElement sentSBE = (SOAPBodyElement)sentIt.next(); Iterator sentIt2 = sentSBE.getChildElements(); SOAPElement sentSE = (SOAPElement)sentIt2.next(); //get the text for orderID to put in confirmation String sentID = sentSE.getValue(); //create the confirmation message confirmation = fac.createMessage(); SOAPPart sp = confirmation.getSOAPPart(); SOAPEnvelope env = sp.getEnvelope(); SOAPBody sb = env.getBody(); Name newBodyName = env.createName("confirmation", "Confirm", "http://www.hotcoffee.com"); SOAPBodyElement confirm = sb.addBodyElement(newBodyName); //create the orderID element for confirmation Name newOrderIDName = env.createName("orderId"); SOAPElement newOrderNo = confirm.addChildElement(newOrderIDName); newOrderNo.addTextNode(sentID); //create ship-date element Name shipDateName = env.createName("ship-date"); SOAPElement shipDate = confirm.addChildElement(shipDateName); //create the shipping date Date today = new Date(); long msPerDay = 1000 * 60 * 60 * 24; long msTarget = today.getTime(); long msSum = msTarget + (msPerDay * 2); Date result = new Date(); result.setTime(msSum); String sd = result.toString(); shipDate.addTextNode(sd); confirmation.saveChanges(); figuur 5-8 Java code voor de methode onMessage

5.3.3 Beschrijving van de web service Aangezien HotCoffee een publieke service beschikbaar stelt is het van belang dat er een goede beschrijving van de webservice komt. Zoals genoemd in paragraaf 4.2.3 is de WSDL ondersteuning op het Java platform nog niet optimaal geregeld. Er zijn momenteel nog geen tools beschikbaar op het Java platform om een webservice te definiëren en daaruit code en een WSDL beschrijving te genereren. Dit heeft als gevolg dat deze handmatig moet worden opgesteld. In figuur 5-9 is de WSDL beschrijving van de web service Order gedeeltelijk weergegeven. De methode getDeliveryPeriod is voor een connectie op basis van 32

HTTP POST gespecificeerd. Zoals te zien valt, is de methode gesplist in twee gedeelten: de eerste geeft de inkomende parameters (hier leeg) aan, de tweede het resultaat. <definitions xmlns:http=http://schemas.xmlsoap.org/wsdl/http/ targetNamespace="http://hotcoffee.com/" > <s:schema elementFormDefault="qualified" targetNamespace="http://hotcoffee.com/"> <s:element name="getDeliveryPeriod"> <s:element name="getDeliveryPeriodResponse"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="getDeliveryPeriodResult" type="s:int" /> <message name="getDeliveryPeriodHttpPostIn" /> <message name="getDeliveryPeriodHttpPostOut"> <portType name="OrderHttpPost"> <service name="Order"> figuur 5-9 WSDL definitie van de web service Order

5.4 Installatie Op de website http://java.sun.com/j2ee stelt Sun een reference implementatie van J2EE beschikbaar. Deze is niet geoptimaliseerd voor snelheid, maar biedt wel de volledige J2EE functionaliteit. Tevens wordt een simpel database management system meegeleverd, ‘Cloudscape’, welke naadloos is te integreren met een J2EE applicatie. De complete package bestaat uit: • J2EE server – het serverprogramma; • Deploytool – een gecombineerde grafische/command-line utility om beans te deployen en te beheren; • Java webserver – een webserver voor het testen van JSP-pagina’s en servlets. Voor de EJB geïnstalleerd kan worden, moeten de betreffende .class bestanden eerst ingepakt worden, wat door de deploytool gedaan kan worden. Deze doet het volgende: • Het aanmaken van een deployment descriptor; • Het inpakken van de deployment descriptor en .class bestanden in een JAR bestand. Als dit gelukt is, kan het eveneens met de deploytool worden geïnstalleerd op een J2EE server. In figuur 5-10 is een illustratie van deze tool te zien.

33

figuur 5-10 Screenshot van het grafische gedeelte van de J2EE deploytool

34

6 De .NET applicatie DHB-ERP.NET In dit hoofdstuk wordt de applicatie DHB-ERP.NET besproken. Deze applicatie is ontwikkeld op basis van het Microsoft .NET platform. Eerst is er een inleiding, waarna het uiteindelijke ontwerp aan bod komt. Hierna worden de implementatie en installatiehandelingen doorgenomen.

6.1 Inleiding DHB heeft sinds kort een bedrijfsbrede applicatie draaien: ‘DHB-ERP.NET’. Dit pakket is speciaal voor DHB ontwikkeld en ondersteunt de hele bedrijfsvoering, waaronder voorraadbeheer, inkoop en facturering. Het pakket is gebaseerd op het .NET platform. Vooral het subsysteem ‘inkoop’ is aan veel discussie onderhevig geweest. De directie van DHB wil om de nieuwe strategie te kunnen verwezenlijken een verregaande ketenintegratie realiseren. Het grote probleem hierbij is dat het subsysteem inkoop met allerlei diverse andere systemen van toeleveranciers (die vaak ook de koffieboeren uitbuiten) moet kunnen communiceren. Geïnspireerd door het emancipatieprogramma van de Verenigde Naties heeft DHB één koffieboer geselecteerd voor een pilot met web services.

6.2 Ontwerp 6.2.1 Use cases Het nieuwe subsysteem inkoop zal de ketenintegratie realiseren door met behulp van een web service contact te onderhouden met de leveranciers. In figuur 6-1 is het use diagram van dit subsysteem te zien.

figuur 6-1 Use case diagram van DHB-ERP.NET

35

De use cases duiden de volgende functionaliteit van het systeem aan (deze worden niet nader gespecificeerd): • ToevoegenLeverancier – De inkoper moet een nieuwe leverancier kunnen toevoegen. Hiervoor moeten de gegevens van de leverancier bekend zijn alsmede het formaat van de SOAP berichten die DHB in staat stelt met de leverancier te communiceren; • OpvragenLeverancierOverzicht – Van elke leverancier moet op elk gewenst moment alle gegevens oproepbaar zijn; • ZoekenBesteLeverancier – Gegeven een aantal parameters (leveringstermijn, koffiesoort, hoeveelheid, kwaliteit) moet het systeem de goedkoopste leverancier weten te vinden; • OpvragenOrderOverzicht – Van alle orders moet een bevestiging zijn ontvangen, deze moeten oproepbaar zijn via een OrderOverzicht. 6.2.2 Klassendiagram Het ontwerpen van gedistribueerde applicaties geschiedt in het .NET platform over het algemeen volgens het 3-lagen principe. Dit houdt in dat er een logisch onderscheid is gemaakt naar data, applicatielogica en presentatie. Het is argumenteerbaar de web services te zien als een vierde laag; de servicelaag. Om snel een applicatie te kunnen ontwerpen zijn er in Visual Studio.NET een aantal enterprise templates aanwezig, die zijn verdeeld in de volgende vier groepen: • User Services – WinUI, WebUI en WebServices; • Business Services – BusinessFacade en BusinessRules; • Data Access and Persistence – DataAccess; • Other – SystemFrameworks. Het klassendiagram in figuur 6-2 is op basis van deze templates gemaakt. Hierbij is de gegevenskoppeling verder buiten beschouwing gelaten. Het is gescheiden in twee gedeeltes, waarbij het Business Service gedeelte bestaat uit facade- en rules-klassen. De facade-klassen geven ondersteuning aan de mogelijke scenario’s die invulling geven aan een use case. De Supplier en Rules klassen communiceren middels een WSDL-interface met verscheidene toeleveranciers. Tevens wordt met de web service StockService de mogelijkheid gegeven aan deze toeleveranciers om inzicht te krijgen in de huidige voorraad van een bepaalde koffiesoort bij DHB.

36

figuur 6-2 Klassendiagram DHB-ERP.NET ‘Inkoop’

6.3 Implementatie De implementatie van de applicatie DHB-ERP.NET wordt besproken aan de hand van twee onderdelen. Allereerst komen de componenten aan bod. Vervolgens wordt de realisatie van het web service gedeelte besproken. 6.3.1 Componenten Component-based development (CBD) is met het .NET platform enigszins veranderd. In het oude platform, door Microsoft aangeduid als Distributed Network Architecture (DNA) werd met behulp van DCOM/COM+ een applicatiearchitectuur gerealiseerd. In .NET is COM beschikbaar via zogenaamde interop services, maar maakt het geen intrinsiek onderdeel uit van het platform. Het lijkt aannemelijk dat de concepten uit COM, zoals bijvoorbeeld transaction management en message queueing, in de toekomst wel integraal onderdeel gaan uitmaken van het .NET framework. COM wordt dan echter alleen nog ondersteund voor koppelingen met legacy applicaties. Zoals vermeld in paragraaf 6.2.2 heeft .NET notie van de drie-lagen architectuur. Er zijn diverse templates aanwezig die dit concept realiseren. Een belangrijke notie is dat CBD in .NET intrinsiek onderdeel uitmaakt van het platform. Zoals genoemd in paragraaf 4.3.2 is de assembly synoniem voor het begrip component. Niet alleen vormt het een eenheid voor toegangscontrole, maar tevens heeft het inbegrip van versiebeheer. Dit betekent dat

37

er op één machine meerdere versies van dezelfde assembly kunnen bestaan, zonder dat de afhankelijke applicaties hierdoor worden gehinderd. De realisatie van de gedefinieerde klassen in het klassendiagram (paragraaf 6.2.2) behelst dan ook niet meer dan het definiëren van deze klassen in een projectbestand. Door ze al dan niet deel uit te laten maken van de dezelfde assembly, is aan te sturen hoe de binaire componenten er uit zien. Er kan zodoende worden gekozen, uit het oogpunt van bijvoorbeeld performance, om een applicatie te splitsen in meerdere assemblies, die op verschillende servers draaien. 6.3.2 Web service De implementatie van de web service StockService gebeurt op basis van ASP.NET (zie paragraaf 4.3.3). In figuur 6-3 is de code weergegeven voor deze klasse. Het grootste deel van de gewenste functionaliteit is al aanwezig door de overerving van de WebService klasse. Zo is bijvoorbeeld standaard zowel HTTP GET als HTTP POST geïmplementeerd. De gedefinieerde methode GetCurrent is door specificatie van de tag ‘WebMethod’ aangemerkt als een geëxporteerde methode. using using using using using using using

System; System.Collections; System.ComponentModel; System.Data; System.Diagnostics; System.Web; System.Web.Services;

namespace DHB_ERP_Inkoop { public class StockService : System.Web.Services.WebService { private StockController m_objStockController; public StockService() { InitializeComponent(); m_objStockController = new StockController(); } [WebMethod] public int GetCurrent(string type) { return m_objStockController.GetCurrent(type); } } } figuur 6-3 C# class StockService

De WSDL definitie van deze web service is opvraagbaar door de volgende URL op te geven: http://servername/StockService.asmx?WSDL. De methode GetCurrent is, vanwege het geïmplementeerde HTTP GET mechanisme, aan te roepen met: http://servername/StockService.asmx/GetCurrent?type=stocktype 38

Als resultaat van deze aanroep wordt een XML bericht teruggestuurd, met daarin de waarde. In figuur 6-4 staat een voorbeeld met de waarde ‘100’. 100 figuur 6-4 SOAP bericht van de methode GetCurrent("stocktype")

Zoals aangegeven in paragraaf 6.2.2 communiceren de Supplier en Order klassen met behulp van een WSDL schema met een web service. Dit gebeurt in onze implementatie op basis van een proxy-mechanisme. De code hiervoor kan worden gegenereerd met een tool. De volgende aanroep maakt de C# file WSOrder aan, die op basis van HTTP POST communiceert met de web service: wsdl.exe /l:CS /protocol:HttpPost /o:WSOrder.cs "{URL:WSDL}"

Door nu het schema uit figuur 5-9 op te geven (URL:WSDL) wordt de code verkregen die in figuur 6-5 staat. De getDeliveryPeriod methode is hierbij de gewenste definitie. Tevens zijn er events opgenomen, die afgaan bij het aanroepen en afronden van deze methoden.

39

using using using using using using

System; System.ComponentModel; System.Diagnostics; System.Web.Services.Protocols; System.Web.Services; System.Xml.Serialization;

[System.Diagnostics.DebuggerStepThroughAttribute()] [System.ComponentModel.DesignerCategoryAttribute("code")] public class Order : System.Web.Services.Protocols.HttpPostClientProtocol { public Order() { this.Url = "http://hotcoffee.com/OrderServlet "; } [System.Web.Services.Protocols.HttpMethodAttribute(typeof( System.Web.Services.Protocols.XmlReturnReader), typeof(System.Web.Services.Protocols.HtmlFormParameterWriter))] [return: System.Xml.Serialization.XmlRootAttribute("int", Namespace="http://hotcoffee.com/", IsNullable=false)] public int getDeliveryPeriod() { return ((int)(this.Invoke("getDeliveryPeriod", (this.Url + "/getDeliveryPeriod"), new object[0]))); } public System.IAsyncResult BegingetDeliveryPeriod( System.AsyncCallback callback, object asyncState) { return this.BeginInvoke("getDeliveryPeriod", (this.Url + "/getDeliveryPeriod"), new object[0], callback, asyncState); } public int EndgetDeliveryPeriod(System.IAsyncResult asyncResult) { return ((int)(this.EndInvoke(asyncResult))); } } figuur 6-5 C# code WSOrder.cs

6.4 Installatie Met de introductie Windows XP is standaard een versie van de Microsoft Installer aanwezig op nieuwe machines. Met dit programma kunnen applicaties op een eenduidige manier worden geïnstalleerd, en is het mogelijk deze later zonder al teveel problemen weer te deïnstalleren. Software die wil voldoen aan het nieuwe logo-programma van

40

Microsoft (om aan te kunnen tonen aan klanten dat het product compatible is met Windows), moet verplicht gebruik maken van deze installer. In Visual Studio .NET zijn een aantal templates aanwezig die de installatie van applicaties vergemakkelijken. Deze templates exporteren bestanden, die kunnen worden herkend door de Microsoft Installer. De template voor de applicatie van DHB is een web setup. Door deze toe te voegen aan de solution (verzameling van assemblies die de gehele applicatie vertegenwoordigen) en vervolgens te compileren, worden de bestanden verkregen. In figuur 6-6 staat een screenshot van deze template, waarin de benodigde projectbestanden (primary output) worden opgegeven.

figuur 6-6 Screenshot van de web setup template

41

42

7 Ervaringen bij J2EE en .NET integratie Als we de advertenties van Microsoft moeten geloven is IAI met behulp van webservices een peulenschil. De softwarereus uit Redmond geeft je het idee dat de IS van bedrijven in een handomdraai met elkaar te koppelen zijn. Dit beeld behoeft uiteraard nuancering. In deze paragraaf zullen we onze ervaringen uiteenzetten. Allereerst zullen we ingaan op webservices in het algemeen, daarna zullen we applicatieontwikkeling op de platformen afzonderlijk behandelen. In deze twee paragrafen beschrijven we kort onze ervaringen bij het ontwikkelen en installeren van de testapplicaties

7.1 Webservices Het is in principe mogelijk om een .NET applicatie en een J2EE applicatie met behulp van webservices aan elkaar te koppelen. Webservices zijn momenteel nog geen standaard onderdeel van J2EE, de volgende versie, specificatie EJB 2.1 voorziet hier wel in. De ondersteuning voor webservices in Java is nog niet af. Door de afwezigheid van een goede WSDL ondersteuning is het ‘snel’ aanroepen van een Java webservice nog niet mogelijk. Het blijkt eenvoudig om een webservice aan te roepen. Aangezien SOAP in feite XML over HTTP is, gaan aanroepen moeiteloos door de bestaande internet infrastructuur en firewalls heen. Tests over het TU ASDL netwerk bevestigen dit. In het algemeen zijn de voordelen van webservices als volgt samen te vatten: • Conceptuele eenvoud – het principe van webservices is eenvoudig te begrijpen; • Integratie in bestaande infrastructuur – het principe van webservices sluit naadloos aan op de meestvoorkomende netwerk- en applicatieinfrastructuren van bedrijven. De belofte van snelle naadloze integratie tussen informatiesystemen van verschillende bedrijven lijkt ons wat te ver gaan. De advertentiecampagnes gaan voorbij aan het feit dat de informatiehuishouding van bedrijven in de praktijk erg kan verschillen. Zo zijn webservices misschien een aardige technische oplossing voor het integratieprobleem, de conceptuele vertaling tussen entiteiten in de verschillende informatiesystemen is doorgaans niet zonder haken en ogen. Hier zit dan ook gelijk de zwakte van onze proefopstelling, het simuleren met behulp van twee testapplicaties geeft onvoldoende inzicht in de praktijk. Het grootste nadeel van de technologie is vooralsnog zijn onvolwassenheid. Alleen de modernste platformen bieden vooralsnog ondersteuning voor webservices. De technologie moet dan ook vooral gezien worden als lijm voor de toekomst.

7.2 J2EE J2EE is bedoeld voor grote complexe bedrijfsapplicaties. Het zou de ontwikkeltijd van dit soort toepassingen aanzienlijk moeten verkorten omdat de bedenkers van J2EE de functionaliteit die voor de meeste bedrijfstoepassingen benodigd is 43

(transactiemechanismen, security, webinterfaces, etc.) hebben geabstraheerd en automatisch laten inbouwen in de applicatie. Dit verandert niets aan het feit dat de materie complex is. Het programmeren en installeren van een J2EE applicatie vereist veel specifieke vakkennis. We hebben in ons onderzoek gemerkt dat het nadrukkelijk niet het geval is dat J2EE deze noodzaak wegneemt. Door de vele stappen in het ontwikkelproces van een J2EE applicatie is een goede ontwikkeltool onontbeerlijk. Het handmatig compileren is al redelijk veel werk door het grote aantal regels dat in het classpath dient te staan. Verder is het testen nagenoeg ondoenlijk zonder een IDE, er zijn teveel stappen van code tot uitvoeren om dit snel te kunnen doen. Een voorbeeld van een ontwikkelomgeving voor J2EE applicaties is Sun’s eigen ONE studio 4, IBM Websphere studio, etc. Het toevoegen van webservices aan een J2EE applicatie is niet moeilijk. Het java platform kent al jaren de server-side webprogramma’s, servlets. De interface is dus snel gedefinieerd, we moeten alleen zelf de code schrijven die zorgt dat de SOAP berichten verwerkt worden door de betreffende bean. Zoals reeds eerder opgemerkt is webservices in Java nog volop in ontwikkeling.

7.3 .NET Voor installatie van het .NET platform is gebruik gemaakt van Visual Studio.NET. Deze bevat naast het .NET framework ook een Integrated Development Environment (IDE) om het programmeren te versnellen. Tevens bevat het een uitgebreide bibliotheek met gebruikersinformatie. De installatie verliep zonder al teveel moeite, enkel de koppeling met IIS verliep niet goed. Dit kwam doordat IIS op het moment van installatie nog niet beschikbaar was op het systeem. Later toevoegen van de functies ging niet zonder problemen. De koppeling werd uiteindelijk handmatig aangemaakt door gebruikmaking van de tool ‘aspnet_regiis.exe’. Aangezien webservices een integraal onderdeel zijn van .NET is het toevoegen van webservices aan een applicatie eenvoudig.

44

8 Conclusie Met webservices is het vakgebied van systeemintegratie weer een stapje hoger gekomen. Voorheen was het de uitdaging om de verschillende systemen binnen een bedrijf aan elkaar te koppelen, nu moeten we constateren dat er een ontwikkeling gaande is waarbij de systemen van verschillende bedrijven aan elkaar gekoppeld worden. Webservices voegen in dit kader iets wezenlijks toe aan bestaande middlewareproducten. Het concept is eenvoudig te begrijpen en past technisch bijna naadloos in de meestvoorkomende netwerk- en applicatieinfrastructuren. Verder biedt het een oplossing voor aantal traditionele integratieproblemen, zoals het ontbreken van goede communicatiestandaarden. Webservices maken de twee grootste platformen van dit moment, J2EE en .NET, koppelbaar. Aan de hand van een casus hebben we de plaats van webservices in informatiesystemen afgebakend. Vervolgens hebben we delen van de voorbeeldapplicatie getracht te implementeren. Het implementeren van een complete testapplicatie, een proof-of-concept, bleek te tijdrovend. In dit verslag is aan de hand van codevoorbeelden aangetoond dat het concept zou moeten werken. Aan de Javazijde zitten nog enige beperkingen, webservices zijn nog volop in ontwikkeling, echter we verwachten dat webservice ondersteuning op dit platform binnenkort ook volledig is. Webservices als de lijm van ketenintegratie? We moeten hierbij een aantal kritische kanttekeningen plaatsen. De informatiehuishouding van bedrijven kan nogal verschillen waardoor een conceptuele vertaling lastig is. Dit is moeilijk in een testapplicatie te vatten, hiervoor zouden testen moeten worden gedaan met operationele informatiesystemen. Ten tweede is de technologie nog erg onvolwassen, getuige de nog onvolledige ondersteuning op het Java platform. We kunnen concluderen dat webservices een goede aanvulling zijn op bestaande middlewareproducten, zonder deze overbodig te maken. De ontwikkeling is nog volop gaande, met z’n allen op weg naar een geïntegreerde toekomst?

45

46

Lijst van figuren figuur 3-1 De samenhang tussen EIS, IS en applicatie.................................................... 14 figuur 3-2 Weergave van inter-enterprise application integration.................................. 14 figuur 5-1 Use case diagram van HotCoffee ................................................................... 25 figuur 5-2 Klassendiagram HotCoffee............................................................................. 26 figuur 5-3 Java Remote interface Order .......................................................................... 28 figuur 5-4 Java Home interface OrderHome................................................................... 28 figuur 5-5 Java Enterprise Bean OrderBean................................................................... 29 figuur 5-6 Java Servlet class OrderServlet...................................................................... 30 figuur 5-7 Java code voor de methode doPost................................................................. 31 figuur 5-8 Java code voor de methode onMessage.......................................................... 32 figuur 5-9 WSDL definitie van de web service Order...................................................... 33 figuur 5-10 Screenshot van het grafische gedeelte van de J2EE deploytool................... 34 figuur 6-1 Use case diagram van DHB-ERP.NET........................................................... 35 figuur 6-2 Klassendiagram DHB-ERP.NET ‘Inkoop’ ..................................................... 37 figuur 6-3 C# class StockService ..................................................................................... 38 figuur 6-4 SOAP bericht van de methode GetCurrent("stocktype")................................ 39 figuur 6-5 C# code WSOrder.cs....................................................................................... 40 figuur 6-6 Screenshot van de web setup template............................................................ 41

47

48

Referenties [01]

ABOUT, INC., “Focus on Java”, [On line] Zie: http://java.about.com/

[02]

ALTER, S., “Information Systems. A management perspective”, 2nd Edition, The Benjamin/Cummings Publishing Company, Inc., 1996.

[03]

FOWLER, M., “Enterprise Application Architecture”, draft april 2002, [On line] Zie: http://www.martinfowler.com/isa/index.html

[04]

FTSC, “Development Site for proposed Revisions to American National Standard T1.523-2001”, [On line] Zie: http://www.its.bldrdoc.gov/projects/devglossary/

[05]

JURIC, M.B., “EAI and Web Services”, EAI Journal, juli 2002, p31 – 35.

[06]

MICROSOFT, “Microsoft Technet”, [On line] Zie: http://www.microsoft.com/technet/default.asp

[07]

SUN MICROSYSTEMS, “Java RMI over IIOP”, [On line] Zie: http://java.sun.com/products/rmi-iiop/

[08]

SUN MICROSYSTEMS, “The J2EE Tutorial - A beginner's guide to developing enterprise applications.”, [On line] Zie: http://java.sun.com/j2ee/tutorial/1_3fcs/index.html

[09]

TECHTARGET, INC., “TechTarget”, [On line] Zie: http://www.techtarget.com/

[10]

UDDI.ORG, “Using WSDL in a UDDI Registry, Version 1.07”, mei 2002.

[11]

WILLE, W., “Presenting C#”, SAMS Publishing, 2000.

49