Geschäftskomponenten mit EJBs

Transkript

1 Geschäftskomponenten mit EJBs FWP Aktuelle Technologien zur Entwicklung verteilter Java-Anwendungen Theis Michael - Senior Developer UniCredit Global Information Services S.C.p.A Sommersemester 2012

2 2

3

4 Enterprise Java Beans - Überblick Standard-Komponentenmodell für server-seitige Java-Komponenten Ziel: Schnelle Entwicklung von verteilten, transaktionalen, sicheren und portablen Anwendungen Verteilbarkeit über Remote Interfaces / RMI Deklarative und programmatische Transaktionalität (CMT - BMT) Deklarative und programmatische Security Deklarative und programmatische Persistenz (CMP - BMP) Portabilität/Herstellerunabhängigkeit innerhalb der Java EE-Plattform 4

5 Session Beans Stateless Session Beans Halten keinen Zustand über Methodenaufrufe hinweg Keine Bindung eines Beans an einen bestimmten Client Container bestimmt die Lebensdauer des Session Beans Mehrere Instanzen in einem Instanzenpool Stateful Session Beans Halten Zustand über Methodenaufrufe hinweg Session Bean ist an bestimmten Client gebunden Client bestimmt die Lebensdauer des Session Beans Singleton Session Bean Sonderfall von Stateless Session Beans mit einer Instanz pro Applikation 5

6 Entities und Message Driven Beans Entities (Java Persistence Architecture) Halten Zustand über Methodenaufrufe und Client-Sessions hinweg Objekt-orientierte Sicht auf (relationale) Daten Eigene Abfragesprache JPQL bzw. SQL Message Driven Beans (seit EJB 2.0) Asynchrone Verarbeitung von Nachrichten aus einer JMS-Queue 6

7 Stateless Session Beans Annotationen markieren Klassen als Session Beans und definieren deren macht aus beliebiger Klasse ein Stateless Session macht aus einem implementierten Business-Interface ein Remote- ein definiert die Transaktionalität der gesamten Klasse oder bestimmen die erforderlichen Zugriffsrechte für den Aufruf lässt sich der Lebenszyklus der EJB verfolgen Dependency ermöglicht die deklarative Verknüpfung von Session Beans und den von ihnen benötigten Ressourcen 7

8 Stateless Session Beans Interfaces Remote Interface Methodenaufrufe erfolgen entfernt (d.h. von anderen Applikationen) Alle Parameter müssen serialisierbar sein und werden als Kopie übergeben Aufrufer und Session Bean können überall laufen Local Interface Methodenaufrufe erfolgen lokal (d.h. innerhalb der gleichen Anwendung) Alle Parameter werden als Referenz übergeben (sofern es sich um Referenztypen handelt) Aufrufer und Session Bean müssen sich innerhalb der gleichen Anwendung befinden No-interface view Session-Bean-Klasse ohne Interface Rechner Applikationsserver Applikation Client Applikation Applikationsserver Applikation Applikationsserver Appliation EJB EJB EJB EJB 8

9 Registrierung und Lookup Session Beans werden beim Deployment registriert Registrierung erfolgt im JNDI-Baum eines Application bestimmt den Namen unter dem das Session Bean registriert wird und wieder gefunden werden kann Manueller Look-up eines entfernten Session Beans ist der harte Teil CourseManagementService service = null; // reference to a remote SLSB InitialContext jndicontext = null; try { // (1) create a JNDI context jndicontext = new InitialContext(); // (2) lookup remote stub Object remotestub = jndicontext.lookup(jndi_name); // (3) narrow remote stub to expected remote interface service = (CourseManagementService) PortableRemoteObject.narrow(remoteStub, CourseManagementService.class); } finally { if (jndicontext!= null) { jndicontext.close(); } } 9

10 Skeleton Entfernte Aufrufe über RMI RMI (Remote Method Invocation) definiert die Art und Weise wie EJBs entfernt aufgerufen werden können Alle Remote Interfaces der aufgerufenen Applikation müssen in das EJB Client Modul gepackt werden Aufrufende Applikation muss dieses EJB Client Modul als Hilfsmodul hinzufügen Application 1 Application 2 (1) RMI Request Message IIOP or EJB 1 vendor-specifc protocol EJB 2 Stub (2) RMI Response Message 10

11 Dependency Injection Abhängigkeiten zu anderen Resourcen müssen nicht mehr von den EJBs selber aufgelöst werden Mit EJB 3.0 muss nur noch ein Feld vom erwarteten Typ definiert werden und diese Feld mit einer entsprechende Annotation versehen werden Der EJB Container löst die Anhängigkeiten auf und inijiziert die benötigten Referenzen in die markierten Felder Beipiel: wird die Referenz zu einem anderen EJB public class UserRegistrationServiceImpl implements UserRegistrationService private UserRepository userrepository; public void registeruser(user newuser) { public class UserRespositoryImpl implements UserRepository {... 11

12 Interzeptoren Interzeptoren bringen AOP in die EJB-Welt Fangen Methodenaufrufe ab bevor sie das Ziel-EJB erreichen Ermöglichen das deklarative Hinzufügen von Querschnittsfunktionalität Mit wird ein Interzeptor an ein TraceInterceptor.class }) public class CourseManagementServiceImpl implements CourseManagementService {... Die Interzeptor-Klasse muss eine Invocation-Handler-Methode implementieren public class TraceInterceptor public Object handleinvocation(invocationcontext invocation) throws Exception { // alle Aktionen vorm Weiterleiten an das Ziel-EJB invocation.proceed; // Weiterleiten an das Ziel-EJB // alle Aktionen nach der Rückkehr vom Ziel-EJB } 12

13 Deklarative Transaktionalität Transaktionales Verhalten eines EJBs bestimmt durch die Annotation TransactionAttributeType MANDATORY REQUIRED (*) REQUIRES_NEW SUPPORTS NOT_SUPPORTED NEVER Beschreibung Erfordert eine aktive Transaktion beim Aufruf Erfordert eine aktive Transaktion beim Aufruf; startet eine neue Transaktion falls notwendig Legt beim Aufruf immer eine Transaktion an; erzwingt die Verwendung einer lokalen Transaktion Es ist egal, ob eine aktive Transaktion vorliegt oder nicht Unterstützt keine Transaktionen; aktive Transaktionen werden vorübergehend unterbrochen Es darf keine aktive Transaktion vorliegen 13

14 Deklarative Security Zugriffsschutz beim Aufruf von EJBs wird über Annotations @DenyAll Beschreibung Definiert Rollen, gegen die beim Aufruf geprüft werden kann Definiert eine Liste von Rollen, die ein angemeldeter Benutzer haben muss, um Methoden eines EJBs aufzurufen Weist den Aufruf von Methoden eines EJBs für alle angemeldeten Benutzer ab 14

15 Neue EJB-Features mit EJB 3.1 Keine expliziten Remote oder Local Interfaces mehr erforderlich (no-interface view) Singleton session beans ( ) Session-Bean-Methods können asynchron aufgerufen werden ( ) Vereinfachte Verpackung EJBs können in Web-Applikations-Module verpackt werden EJB Lite Abgespeckter EJB-Container als Teil des Web-Profils von JavaEE 6 15

16

17 Typen von Geschäftskomponenten Business Component Facade Service Domain Object Leben in der Geschäftslogikschicht Facade Bietet grob-granulare Geschäftslogik über Schnittstellen an Verbirgt die Komplexität der Geschäftslogik vor dem Aufrufer Benutzt Services zur Abwicklung der eigenen Funktionalität Service Bietet fein-granulare, wiederverwendbare Geschäftslogik über Schnittstellen an Benutzt Resource Access Components für den Zugriff auf externe Resourcen Domain Object Repräsentiert das für Aufrufer sichtbare Domänenmodell Meist simple Datenträger (Data Transfer Object = DTO) 17

18 Service-Fassaden Eine Service-Fassade stellt ein grob-granulares Interface für spezifische Geschäftslogik zur Verfügung, wobei deren Komplexität dem Aufrufer nicht bekannt gemacht wird Sie implementieren diese Geschäftslogik selbst Oder sie nutzen andere Services um diese zu implementieren Oder sie leiten den Aufruf an andere Backend-Systeme weiter Service-Fassaden werden als Stateless Session Beans implementiert Service-Fassaden können auch als Webservices veröffentlicht werden Facade: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. [GOF1995] 18

19 Boundary Wächter am Tor zur Geschäftslogik Entfernte Aufrufe Propagation der Transaktion Service Fassaden Interface Lokale Aufrufe Lokale Kommunikation Geschäftskomponente Service-Fassaden-Interfaces agieren als Torwächter Stellen sicher, dass Geschäftslogik immer konsistent ausgeführt wird Stellen sicher, dass nur Benutzer mit den erforderlichen Zugriffsrechten Zugang haben Alle Methoden eines Service-Fassaden-Interfaces Sollten eine aktive Transaktion voraussetzen oder besser eine neue erzeugen Sollten für entfernte Aufrufe designt werden auch wenn man sie nur lokal nutzt Sollten immer einen authentisierten Benutzer verlangen 19

20 Services Services implementieren fein-granulare Geschäftslogik die nur innerhalb der Geschäftslogik-Schicht sichtbar ist die leicht zu komplexeren Abläufen von Geschäftslogik orchestriert werden kann Services sind zustandslose POJOs oder Stateless Session Beans Services arbeiten auf einem applikations-spezifischen Domänenmodell Die Verwendung von Service ist nicht zwingend erforderlich: In einfachen Applikationen kann sich die Geschäftslogik auch ausschließlich in Service- Fassaden befinden, sofern sie dort nicht dupliziert wird! 20

21 Domänen-Objekte Domänen-Objekte repräsentieren das Domänen-Modell gegenüber der Benutzerschnittstelle der Anwendung gegenüber entfernten Aufrufern der Anwendung In SOA-nahen Architekturen simple Daten-Transfer-Objekte Eingabeparameter in Methoden der Service-Fassaden-Interfaces Rückgabewerte aus Methoden der Service-Fassaden-Interfaces Reine Datenkontainer (fast) ohne Logik (nur einfache Validierungsregeln und Zugriffskontrolle auf Feldebene) Lassen sich typischerweise in drei Arten unterteilen (EVANS): Entitäten: persistente Geschäftsdaten mit einer spezifische Identität Value Objects: transiente Geschäftsdaten, nicht ein eine Identität gebunden Aggregate: Cluster aus Entitäten und Value Objekten umgeben von einer transaktionale Grenze 21

22 Design von Geschäftskomponenten Service-Fassaden und Domänen-Objekte bilden gemeinsam die öffentliche Programmierschnittstelle der Geschäftslogikschicht es lohnt sich daher, ein wenig über deren Design nachzudenken! Einige Kriterien für gute Geschäftskomponenten Keine äußerlichen Abhängigkeiten zum Domänenmodell aus anderen Anwendungen Kompatibilität gegenüber älteren Versionen muss eingehalten werden Leicht verständlich und einfach zu benutzen durch vollständige Dokumentation, sprechende Namen, klare Verträge und eindeutige Informationen im Fehlerfall 22

23

24 Quellen Eric Jendrock et. al. The Java EE 6 Tutorial l/doc/ Oracle February 2012 Bill Burke & Richard Monson-Heafel Enterprise JavaBeans 3.0, 5th Edition O'Reilly Media, Inc. May 2006 ISBN Adam Bien Real World Java EE Patterns: Rethinking Best Practices press.adam-bien.com June 2009 ISBN Eric Evans Domain Driven Design: Tackling Complexity in the Heart of Software Addison Wesley 2004 ISBN

25

26 Vielen Dank! Michael Theis Senior Developer UniCredit Business Integrated Solutions S.C.p.A. phone mobile web 26