Links

  • 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java

Archives

Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by jcn at 10:45 on Wednesday 30 June    Add 'Expanding EJB technology 2.1 to reach to heterogenous systems' site to delicious  Add 'Expanding EJB technology 2.1 to reach to heterogenous systems' site to technorati  Add 'Expanding EJB technology 2.1 to reach to heterogenous systems' site to digg  Add 'Expanding EJB technology 2.1 to reach to heterogenous systems' site to dzone

De sessie begint met een stukje geschiedenis van de EJB-technologie en hoe zij met de buitenwereld konden communiceren. EJB 1.0 kon alleen client request / response aan. De opvolger, versie 2.0 kon daarnaast ook overweg met JMS, RMI-IIOP en bevatte interoperable security. In deze versie werkte de Message Driven Beans (MDB) samen met de Java Messaging Service (JMS), met standaardisatie op het vlak van het protocol, de interoperable naamgeving en beveiligde samenwerking. Versie 2.1 voegt daar ook nog de Java Connector Architecture (JCA) en Web Services (WS) aan toe. Vanaf versie 2.1 was het mogelijk dat een MDB aanvragen kon ontvangen van de JCA en daarnaast stateless session beans (SLSB) als web service end point gedefinieerd konden worden. Maar hoe kun je heterogene systemen vandaag de dag samen laten werken?

Vandaag de dag kunnen heterogene systemen perfect met elkaar praten door het gebruik van web services. EJB 2.1 bevat hiervoor al perfecte methoden. EJB 2.1 is volledig gebaseerd op de web services standaarden, dus daarvoor hoeven geen specifieke code aanpassingen uitgevoerd te worden. JAX-RPC wordt gebruikt als een brug tussen de Java code aan de ene kant en de web service aan de andere kant. Via een JAX-RPC mapping file wordt hiermee de o.o.-wereld aan de web services wereld gekoppeld, dus de Java programma aan de JAX-RPC runtime client.

Wanneer je een EJB gebruik wilt laten maken van een web service, doe je een JNDI-lookup van de web service. Vervolgens maak je van deze web service een service object en open je een port op de web service middels dit service object. Vervolgens kun je op dit service object je method requests uitvoeren. Wanneer je een EJB als web service beschikbaar wilt stellen, hoef je dit alleen maar aan te geven in de deployment descriptor van de EJB (gebruik hiervoor <service-endpoint>myEJB.myService</service-endpoint>) en een mapping aan te brengen in webservices.xml. Kijkend naar de toekomst wordt gestreeft om ook de aanpassingen in de deployment descriptors te vervangen door annotaties.

De JCA is eigenlijk niets anders dan JDBC richting een EIS, waarbij vendor-specifieke systemen elk hun eigen resource adapter (RA) hebben. In JCA 1.0 was er ondersteuning voor connection management, transaction management en security management en was alleen uitgaande communicatie mogelijk (dus richting de EIS). In JCA 1.5 hebben ze daar nog workflow management, message inflow en transaction inflow aan toegevoegd en wordt bi-directionele communicatie ondersteunt. Inflow betekent hier dan ook dat een transactie wordt gestart in de EIS en doorloopt in de Java applicatie.

Door gebruik te maken van web services kun je dus nu verschillende systemen en platforms (bijv. .NET en Java) met elkaar laten praten, middels JCA kun je verschillende typen applicaties met elkaar laten praten en toch gebruik maken van doorlopende transacties (iets wat nu nog redelijk lastig is met web services).


© 2020 Java Competence Network. All Rights Reserved.