VL4

Verteilte Komponentensysteme
Überblick :
• Komponenten
• Modelle für verteilte Komponentensysteme
• Java 2 Enterprise Edition
– Überblick über die J2EE
– Enterprise JavaBeans
•
CORBAcomponents
Verteilte Anwendungen (04/05)
T.S. (JD)
1
Komponenten – Definition
(zum nicht Auswendiglernen)
“A software component is a unit of composition with contractually specified
interfaces and explicit context dependencies only. A software component can
be deployed and is subject to composition by third parties.“
Szyperski: „Component Software“
Also: eine Software-Komponente ist:
–
–
–
–
–
Eine gekapselte Code-Einheit welche
wohldefinierte Schnittstellen implementiert
genau beschriebene Abhängigkeiten besitzt
aus einer oder mehreren Klassen besteht
eigenständig installierbar und lauffähig (in Laufzeitumgebung) ist.
Verteilte Anwendungen (04/05)
T.S. (JD)
2
Warum Komponenten?
•
Immer umfassendere Anwendungen
•
Integration mit immer mehr unterschiedlichen Systemen
•
Rücksichtnahme auf immer mehr Problembereiche notwendig (Internet,
Sicherheit, unterschiedliche Datenquellen)
 Komplexität der Anwendungen nimmt zu
Wünsche:
• Konzentration der Entwickler auf Geschäftslogik
• Wiederverwendbarkeit geschaffener Programmstrukturen (nicht nur Klassen)
• Verteilung von Programmteilen
Verteilte Anwendungen (04/05)
T.S. (JD)
3
Warum Komponentensysteme?
•
Kommunikationsmechanismus (SOAP, RMI) allein ist nicht genug Unterstützung
 Basisfunktionen als Dienste bereitstellen, die Entwickler bei der Umsetzung der
Geschäftslogik nutzen können
Etwa:
• Persistenz
• Verteilung
• Sicherheitsmechanismen
• Lifecycle
• Discovery
• Konfiguration
Verteilte Anwendungen (04/05)
T.S. (JD)
4
Komponenten – Einordnung
•
Vorteile:
–
–
–
–
•
Leichter wiederzuverwenden
Leichter zu verteilen
Leichter zu „verteilen“/ über (Unternehmens-)Grenzen hinweg zu nutzen
Bei Nutzung von AppServer: leichter zu erstellen
Nachteile:
– Mehr Overhead
•
Klassifizierung
– Deployable: COM-Komponenten, CORBAcomponents, EJB
– GUI/ UI: Servlets, Applets, X-Komponenten, vcl (visual component library)
– Sonderform undeployable: Java Beans
Verteilte Anwendungen (04/05)
T.S. (JD)
5
Java 2 Enterprise Edition
•
Spezifikation eines Middleware-Application-Frameworks
(analog zu CORBA/SOAP: J2EE ist kein Produkt)
•
Zusammenfassung einzelner Java-Technologien für den Unternehmensbereich
(inkl. Applikationsmodell, Referenzimplementation, Kompatibilitätstestwerkzeug,
Entwicklungswerkzeuge, Blue-Prints)
•
häufig als N-Tier-Modell bezeichnet, genau genommen aber 3-Tier
•
Zur Zeit aktuell: J2EE 1.4 (seit 11/03)
(praktisch alle Produkte implementieren J2EE 1.3; WebSphere, JEUS, sun J2EE 1.4 )
Verteilte Anwendungen (04/05)
T.S. (JD)
6
Die J2EE-Architektur
Plus:
- SOAP
Verteilte Anwendungen (04/05)
T.S. (JD)
7
J2EE: Technologiekomponenten – 1
•
Java 2 Platform Standard Edition
– Kern der Java-Plattform mit den Standard-APIs
•
Enterprise JavaBeans (EJB)
– Komponentenstandard
– definiert Schnittstellen und Architektur auf Seiten des Server
– integriert weitere APIs
•
Remote Method Invocation (RMI)
– API für verteilte Kommunikation zwischen Objekten
– CORBA-Integration über RMI-IIOP
•
CORBA (Java IDL)
– durch CORBA definierte Sprachinteroperabilität
– Integration in existierende Systeme
•
Naming and Directory Interface (JNDI)
– API für den Zugriff auf Directory Services zum Auffinden von
Komponenten und Ressourcen
Verteilte Anwendungen (04/05)
T.S. (JD)
8
J2EE: Technologiekomponenten – 2
•
Java Database Connectivity (JDBC)
– API für den Zugriff auf relationale Datenbanken
•
Java Message Service (JMS)
– asynchrone Aufrufe (publish/subscribe oder Point-to-Point)
– transaktionsorientierte Nachrichten
•
Transaction API
– High-level API für das Transaktionsmanagement (JTA)
– Java Transaction Service als Low-level API für Transaktionen (JTS)
•
Java Mail
– API für E-Mail-Operationen auf verschiedenen Plattformen und mit
verschiedenen Protokollen
•
Java Beans Activation Framework (JAF)
– für Java Mail
Verteilte Anwendungen (04/05)
T.S. (JD)
9
J2EE: Technologiekomponenten – 3
•
Servlets und Java Server Pages (JSP)
–
–
–
•
XML-Processing (JAXP)
–
–
•
Handhabung von XML-Dokumenten
DOM, SAX, XSLT
XML-based RPC // SOAP with Attachments
–
–
–
•
Request/Response-orientierte Kommunikation
Erweiterung eines Web-Server
Scripting-Eigenschaften
SAAJ > JAX-RPC
Vollständige Webservices-Umsetzung
incl. WSDL, SSL, TLS
Connectors
–
Zugriff auf existierende Back-End-Informationssysteme
Verteilte Anwendungen (04/05)
T.S. (JD)
10
J2EE Applikationsmodell
Zusammenspiel der Technologien
Verteilte Anwendungen (04/05)
T.S. (JD)
11
Enterprise JavaBeans ™ - die Spezifikation
Enterprise JavaBeans Specification
Version 2.1, Final Release vom 24. November 2003
© 1999- by Sun Microsystems Inc.
901 San Antonio Road, Palo Alto, CA 94303.U.S.A
 Komponentenarchitektur für verteilte objektorientierte (Geschäfts-)
Anwendungen in JavaTM
 Transparenz der Low-Level-APIs bei der Applikationsentwicklung
 Philosophie: Write Once, Run AnywhereTM
 Spezifikation für Entwicklungs- und Laufzeitunterstützung
Verteilte Anwendungen (04/05)
T.S. (JD)
12
EJB
•
•
•
•
EJB sind serverseitige Softwarekomponenten
Residieren in Applikations-Servern/ Containern
1:1-Umsetzung des Unternehmensdatenmodells und Services
Kommunizieren analog zu RMI über Stubs und Skeletons (übernimmt
Container).
Zwischen Skeleton und Implementierung existiert eine weitere Instanz, das
EJBObject, welches alle Requests bezüglich EJB-Services (paralleler
Anfragen, Sicherheitsmaßnahmen, Transaktionen etc.) untersucht und diese
berücksichtigt.
Verteilte Anwendungen (04/05)
T.S. (JD)
13
EJB: Rollen im Entwicklungsprozeß
1) Enterprise Bean Provider
-
Entwickler von Enterprise Beans für die jeweilige Anwendungsdomäne
2) Application Assembler
-
Entwickler von Applikationen unter Verwendung der vorhandenen Enterprise Beans
3) Deployer
-
Anpassung/Installation von Applikationen an/in die jeweilige Umgebung, wie zum
Beispiel in Abhängigkeit vom verwendeten EJB-Container
4) Administrator
-
Konfiguration und Administration der Infrastruktur, wie zum Beispiel Netzwerk, EJB
Server und Container
5) EJB Container Provider
-
Laufzeitumgebung für EJB; Container mit Standard API für Enterprise Beans auf der
Basis des EJB Server
6) EJB Server Provider
–
Anbieter von Low-Level-Systemdiensten, wie zum Beispiel Transaktionen
Verteilte Anwendungen (04/05)
T.S. (JD)
14
EJB – Entwurfsprozess
Erstellung
Der Entwickler erstellt:
• Remote Interface
–
–
•
Home Interface
–
–
•
Wie bei RMI:
Definition der öffentlichen Methoden der Enterprise Bean
Callback-Methoden für den Container
arbeitet als Factory für EJB Objects
Bean Implementation
Implementierung der Klasse(n)
 Alle Methoden des Remote Interfaces, des Home Interfaces und interne Geschäftslogik
–
•
Deployment Deskriptor
–
–
•
spezifiziert die Anforderungen des Enterprise Bean an die Middleware
informiert den Container über die Anforderungen des Bean bezüglich Verwaltung,
Lebenszyklus, Transaktionen, Persistenz und Sicherheit
(bei bestimmten Beans eine PrimaryKey-Klasse)
Verteilte Anwendungen (04/05)
T.S. (JD)
15
EJB – Entwurfsprozess
Generierung
Zusätzlich umfasst ein EJB:
• Home Object
– Container-generierte Implementierung des Home Interface
•
EJB Object
– Container-generierte Implementierung des Remote Interface
– enthält das Netzwerkwissen und interagiert mit dem Client
– delegiert die Methodenaufrufe zu den Bean Instances
•
Bean‘s Properties
– Attribute für die Anpassung des Bean zur Laufzeit
 Ejb-jar-file
– Zusammenfassung des kompletten Enterprise Bean
Verteilte Anwendungen (04/05)
T.S. (JD)
16
Web Component
Enterprise Bean
Client DD
Java App.
EJB DD
EJB Class
Remote Intf.
Home Intf.
Web Comp. DD
JSP File
Servlet Class
Gif File
HTML File
.jar File
.jar File
.war File
J2EE Client
Assembly
Phase
J2EE Appl.
J2EE Appl. DD
.ear File
Deployment
Stub Classes
.jar File
J2EE Server
Verteilte Anwendungen (04/05)
T.S. (JD)
17
EJB – Drei unterschiedliche Bohnen
Die Enterprise JavaBeans - Spezifikation umfasst (seit Version 2.0) drei
unterschiedliche EJB-Typen mit wohldefinierten Aufgaben:
EJB
Session Bean
Entity Bean
Verteilte Anwendungen (04/05)
Message Driven Beans
T.S. (JD)
18
Session Beans
•
•
•
•
•
•
•
Repräsentieren die Unternehmens-Logik (Abläufe)
greifen auf gemeinsam benutzte Daten zurück
für je einen Client
kurze Lebensdauer
gehen verloren, wenn der EJB Container terminiert
können transaktionsorientiert sein
zustandsorientiert/zustandslos
Zwei Versionen: stateful und stateless session beans
Verteilte Anwendungen (04/05)
T.S. (JD)
19
Stateful Session Beans
•
Stateful Session Beans können einen Zustand annehmen
 Haben einen Conversational State in Verbindung mit dem Client
•
•
für dialogorientierte Kommunikation mit mehreren Anfragen
stehen einem Client nach jeder Anfrage weiterhin zur Verfügung
•
•
Activation  ejbActivate() (Benachrichtigung)  swap in
Passivation  ejbPassivate()  swap out (Objekt Serialisierung)
•
z.B.: Onlineshopping-Cart, der sich den Inhalt merkt
Verteilte Anwendungen (04/05)
T.S. (JD)
20
Stateless Session Beans
•
•
•
•
Stateless Session Beans sind zustandslos (stateless = ohne Zustand)
bearbeiten genau eine Anfrage und werden wieder freigegeben
sinnvoll bei atomaren oder eine Transaktion umfassenden Anfragen
z.B.: AccountManagerBean mit Methode createAccount()
•
Entscheidung stateful vs. stateless
 Zustandsrelevante, Client-spezifische Daten müssen nicht mit jedem Aufruf
übertragen werden.
 Passivation/Activation (stateful) kann zu Flaschenhälsen bei der Ein/Ausgabe
führen und Pooling erscheint komplizierter.
Verteilte Anwendungen (04/05)
T.S. (JD)
21
Zustandsübergangsdiagramm: Session Bean
Does Not
Exist
Stateful Session Bean
setSessionContext()
ejbCreate()
ejbRemove()
Does Not
Exist
Ready
create()
setSessionContext()
ejbCreate()
remove()
ejbRemove()
Stateless Session Bean
ejbPassivate()
Ready
Passive
ejbActivate()
Verteilte Anwendungen (04/05)
T.S. (JD)
22
Entity Bean
•
•
•
Repräsentiert persistente Daten einer Anwendung (View auf Geschäftsobjekte)
längere Lebensdauer
bleibt erhalten, wenn der EJB Container terminiert
(mehrere Entity Bean-Instanzen können die selben Daten repräsentieren!)
•
Evtl. Angabe einer Klasse als Primärschlüssel, in der Equivalenz etc. geklärt
sein müssen
Container/Bean-managed Persistenz  Persistence Service
•
Verteilte Anwendungen (04/05)
T.S. (JD)
23
Zustandsübergangsdiagramm: Entity Bean
Does Not
Exist
unsetEntityContext()
setEntityContext()
Pooled
remove()
ejbRemove()
ejbPassivate()
ejbActivate()
create()
ejbCreate()
ejbPostCreate()
Ready
Verteilte Anwendungen (04/05)
T.S. (JD)
24
Message Driven Beans
•
•
•
•
•
•
•
Zustandslose nicht-persistente EJB
ermöglichen lose, asynchrone Kommunikation über Nachrichten (JMS)
nur Bearbeitung der Nachrichten, keine Unternehmenslogik
MDB ist als „message recipient“ oder „message consumer“ in message queue
registriert
Container ruft Callback-Methode onMessage() bei Auftreten einer
Nachricht auf
MDB sind anonym (Clients können nicht auf sie zugreifen)
kein Remote- noch Home Interface (Aktivierung nur durch Container)
Verteilte Anwendungen (04/05)
T.S. (JD)
25
Ablauf zur Laufzeit
EJB Container/Server
Home
Interface
(1) New
EJB Object
Home Object
(3) EJB Object
Reference
Client Code
(4) Method
Call
(7) Return
to Client
(2) Create
EJB
Object
(5) Acquire,
Delegate
Enterprise
Beans
EJB Object
Remote
Interface
Verteilte Anwendungen (04/05)
Database
(6) Method
returns
T.S. (JD)
26
Schritte zum Erstellen eines Stateless Session Bean
1) Schreiben des Remote Interface
– extends javax.ejb.EJBObject
– Business-Methoden
2) Schreiben des Home Interface
– extends javax.ejb.EJBHome
– create()
3) Implementieren des Bean
– implements javax.ejb.SessionBean
– Must (copy and paste): ejbCreate(), ejbRemove(), ejbActivate
(), ejbPassivate(), setSessionContext(),
– Business-Methoden
Verteilte Anwendungen (04/05)
T.S. (JD)
27
Schreiben des Remote Interface
import javax.ejb.EJBObject;
import java.rmi.RemoteException;
/**
* This is the HelloBean remote interface.
*
* This interface is what clients operate on when
* they interact with EJB objects. The container
* vendor will implement this interface; the
* implemented object is the EJB object, which
* delegates invocations to the actual bean.
*/
public interface Hello extends EJBObject {
public String sayHelloTo(String to)
throws RemoteException;
}
Verteilte Anwendungen (04/05)
T.S. (JD)
28
Schreiben des Home Interface
import
import
import
import
java.io.Serializable;
java.rmi.RemoteException;
javax.ejb.CreateException;
javax.ejb.EJBHome;
/**
* This is the home interface for HelloBean. This interface
* is implemented by the EJB Server's glue-code tools - the
* implemented object is called the Home Object, and serves
* as a factory for EJB Objects.
* One create() method is in this Home Interface, which
* corresponds to the ejbCreate() method in HelloBean.
*/
public interface HelloHome extends EJBHome {
Hello create() throws RemoteException, CreateException;
}
Verteilte Anwendungen (04/05)
T.S. (JD)
29
Implementieren des Bean
import java.rmi.RemoteException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
/**
* Demonstration stateless session bean.
*/
public class HelloEJB implements SessionBean {
// per copy and paste:
public
public
public
public
public
void
void
void
void
void
ejbCreate() {}
ejbRemove() {}
ejbActivate() {}
ejbPassivate() {}
setSessionContext(SessionContext ctx) {}
// implementiere entfernte Methoden:
public String sayHelloTo(String to) {
return("Hello " + to + "!");
}
}
Verteilte Anwendungen (04/05)
T.S. (JD)
30
Schritte zum Installieren eines Stateless Session Bean
1) Deployment Descriptor
durch Tool (Deploytool) erzeugte XML-Datei
Parameter: Bean home name, Enterprise Bean class name, Home interface
class name, Remote interface class name, Stateless
⑤ Environment Properties
durch Tool (Deploytool)
Anpassung des Bean an verschiedene Umgebungen
( Transaktionen, Security, DB etc.)
3) Erstellen des Ejb-jar File
durch Tool (Deploytool)
4) Deployment
durch Tool (Deploytool) und Container/Server Verifikation des Ejb-jar File,
Generierung von EJBObject und HomeObject, Generierung RMI-Stubs und
Skeletons
5) Implementieren und Aufrufen des Client
Verteilte Anwendungen (04/05)
T.S. (JD)
31
Deploytool des J2SDKEE
Verteilte Anwendungen (04/05)
T.S. (JD)
32
Clients für Enterprise JavaBeans
•
andere Enterprise JavaBeans
– ein typisches Beispiel: Session Bean als Client eines Entity Bean
•
Servlets
– indirekter Zugriff auf Enterprise JavaBeans vom Web-Browser aus via
HTTP, Web-Server mit Servlet-konformer API
•
JavaServer Pages / Faces Components
– indirekter Zugrif auf Enterprise JavaBeans vom Web-Browser via HTTP,
Web-Server mit JSP Scripting Engine und eventuell JavaBeans Component
•
•
Web-Service-Clients
Stand-Alone Java Application
– siehe Beispiel auf der folgenden Folie
•
J2EE Application Clients
– mit Zugriff auf J2EE-Services, wie zum Beispiel Security Authentication
und JNDI
Verteilte Anwendungen (04/05)
T.S. (JD)
33
Stand-Alone Java Application als EJB Client
•
Beispiel: Client für das HelloBean
import ...;
public class HelloClient {
public static void main(String[] args) {
try {
Context initial = new InitialContext();
Object objref = initial.lookup("MyHello");
HelloHome home =
(HelloHome)PortableRemoteObject.narrow(
objref, HelloHome.class);
Hello helloRef = home.create();
System.out.println(helloRef.sayHelloTo("Chef"));
helloRef.remove();
} catch (Exception ex) {
System.err.println("Caught an exception!");
ex.printStackTrace();
}
}
}
Verteilte Anwendungen (04/05)
T.S. (JD)
34
EJB 2.0: lokale Interfaces, EQL
(Enterprise JavaBeans Query Language)
•
lokale Interfaces für enge Kopplung von Komponenten
– Einführung zur Erhöhung der Effizienz bei lokal installierten EJB (marshalling und
unmarshalling wird vermieden...)
– allerdings Gefahr bei nicht durchdachter Nutzung (Call-by-Reference, kein
Marshalling!)
•
EJB Query Language (EJB QL) als einheitliche Anfragesprache
– um Pfadausdrücke erweitertes SQL92
– Suchoperationen ejbFind...() für Objekte und ejbSelect...()
für Werte vom Bean Provider im Deployment Descriptor formuliert
Verteilte Anwendungen (04/05)
T.S. (JD)
35
EJB Services – Persistence Service
•
Container-mananaged Persistence statt Bean-managed Persistence
– schnellere Implementierung/ niedrigere Fehlerwahrscheinlichkeit
• „Herkömmlich 75 % der Entwicklungszeit für DB-Programmierung“
– Reduktion von Code
• Generieren und Deklarieren von Zugriffslogik mit Container-Werkzeugen
• Keinerlei eigene DB-Programmierung
– eventuelle Einschränkungen durch den Container
• keine Unterstützung von komplexen Objekten oder Beziehungen!
– portable Datenbankschicht
• Persistenz stark verbessert
• Komplexität abhängig von den Möglichkeiten des Container
 Rapid Development mit Container-managed Persistence
Verteilte Anwendungen (04/05)
T.S. (JD)
36
EJB Services –
Transaktion Service, Naming Service
•
•
•
Container bieten Transaktion-Service für jede Methode
Aufteilung der Transaktionen wieder in Bean- /Container-managed T.
Containermanaged Transaktions bei Installation durch Deployment D.
•
•
•
•
Naming Service durch Java Naming and Directory Interface (JNDI)
Container registrieren ihre Home Objekte in lokalem Repository
Die JNDI-API bietet Dienste zum Nachschlagen, Ein- und Austragen
Zugriff über den Namen (über Beschreibung möglich)
Verteilte Anwendungen (04/05)
T.S. (JD)
37
EJB Services – Security Service
•
Authentication (zum Beispiel durch Benutzername/Paßwort)
– von der Applikation und vom EJB Container abhängig
•
Authorization (Rechte, zum Beispiel für den Zugriff auf Funktionen)
– Security Roles
• Sammlung von Client Identities (Server-spezifisch)
– declarative, durch den Container überprüft
• Im Deployment Descriptor abstrakt beschrieben
– programmatic, Überprüfung im Bean Code
• boolean isCallerInRole(Identity role)
• Principal getCallerPrincipal()
Verteilte Anwendungen (04/05)
T.S. (JD)
38
Connectors
J2EE Connectors Specification Version 1.0
– Version 1.5 Proposed Final Draft 2
•
•
Interoperabilität mit Systemen, die nicht J2EE-, CORBA-, SOAP-konform sind
Überblick:
ContainerComponent
Contract
Application
Server
Application Component
Client API
System
Contract
Ressource Adapter
Verteilte Anwendungen (04/05)
EIS
specific
Interface
T.S. (JD)
Enterprise
Information
System
39
EJB – Zusammenfassung
•
•
•
•
EJB ist Service-orientierte Infrastruktur.
EJB 2.0 beseitigt Schwächen des Persistenz-Dienstes und führt MDB/EQL ein
EJB 2.1: Einführung der Webservices (EJB als WS deployable)
Für Folgeversionen ist unter anderem Vererbung auf Komponenten-Ebene
geplant.
 Resümee:
Soll verhältnismäßig schnell eine sichere, portierbare, skalierbare und robuste,
komponentenbasierte Applikation erstellt werden, so ist es sinnvoll auf die J2EETechnologie zurückzugreifen.
Der Schwerpunkt liegt dabei auf der Implementierung des Unternehmensmodells
und der Unternehmenslogik, wohingegen systemnahe Dienste transparent genutzt
werden können.
Verteilte Anwendungen (04/05)
T.S. (JD)
40
CORBA Component Model (CCM)
•
•
•
•
Modell für serverseitige Komponenten mittels derer CORBA-Applikationen
erstellt werden können.
Ähnelt den EJB sehr stark
Spezifikation eines Containers enthalten
Abweichend von EJB ist das CCM entsprechend der CORBA-Philosophie
sprachunabhängig (Aber: EJB laufen in CORBA-Containern!)
Verteilte Anwendungen (04/05)
T.S. (JD)
41
Neue Konzepte im CCM
•
•
•
Komponenten in CORBA
Aggregierte, sowie interne Interfaces
Component Implementation Definition Language (IDL  CIDL)
 Management- und Service-Interfaces
•
Erweiterung der Beschreibungsmöglichkeiten  neue Begriffe...
Verteilte Anwendungen (04/05)
T.S. (JD)
42
CCM – die neuen Begriffe...
•
•
•
Facets: erweitert beschriebene Interfaces (provides, supports)
Receptacles: interne Verknüpfungspunkte für enge Kopplung
Events erlauben eine lose Kopplung von Komponenten nach dem ObserverEntwurfsmuster
– Event sources sind Komponenten, welche Ereignisse publizieren. Einzige Quelle!
– Event sinks sind Komponente, welche bestimmte Ereignisse abonnieren, indem sie
als deren Abonnent deklariert werden.
( Während Ereignisse aus einer einzigen Quelle stammen, werden sie von allen aktiven
Senken empfangen. )
•
Attributes werden um die Möglichkeit, Exceptions zu generieren erweitert.
Wird eine Operation ausgeführt, die auf ein Attribut zugreift oder es ändert, so
kann ein Exception geworfen werden.
Verteilte Anwendungen (04/05)
T.S. (JD)
43
Die CORBAcomponent
Verteilte Anwendungen (04/05)
T.S. (JD)
44
Unterschiedliche CC
Session
Service Components
•
•
•
•
Steht exklusiv einem Client zur Verfügung
Bei Verbindung wird die Komponente erstellt und anschließend wieder freigegeben
Lebenszyklus ist beschränkt auf eine funktionale Anfrage
Beispiel: Konto anlegen, Überprüfung einer Systemaktivität
(aka stateless session beans)
Session Components
•
•
•
•
Ähnlich einer Service Component
Unterschied: mit Zuständen versehen
Im Container werden die Zustände nicht persistiert
Beispiel: Shopping Cart, Aufstellen eine Geschäfts-Bilanz
(aka stateful session beans)
Verteilte Anwendungen (04/05)
T.S. (JD)
45
Unterschiedliche CC
persistente
Process Components
• Zustände werden persistiert und dauerhaft festgehalten
• Zugriff und Nutzung durch mehrere Clients möglich
• Beispiel: Geschäftsprozesse („Urlaubsantrag“, „Fahrtkostenantrag“)
Entity Components
• Entity Components verfügen über einen eindeutigen Primary Key
• eindeutige Identifikation der Komponente möglich
• Späteres „Wiederaufwinden“ durch PK
• Beispiel: Geschäftsobjekte, „Bankkonto“ oder „Kunde“
(aka entity beans)
Sehr gute Einführung:
http://www.omg.org/cgi-bin/doc?ccm/2002-04-01
Verteilte Anwendungen (04/05)
T.S. (JD)
46