JEE: Difference between revisions

From Wiki RB4
No edit summary
 
(141 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==Übesicht==
 
Die aktuelle Version der J2EE-Spezifikation ist die Version 5.0. Der neue Name für die Spezifikation lautet Java Platform, Enterprise Edition, kurz Java EE (manchmal mit Extension 5). JEE basiert auf der Standard Edition (Java SE) und definiert folgende Technologien:
==Introduction==
===Versions===
*J2EE
*JEE 5
*JEE 6
Die aktuelle Version der J2EE-Spezifikation ist die Version 6.0. Der neue Name für die Spezifikation lautet Java Platform, Enterprise Edition, kurz Java EE.  
 
===Overview===
JEE basiert auf der Standard Edition (Java SE) and is a collection of specifications for server-based services and frameworks. The Java EE platform uses a simplified programming model. XML deployment descriptors are optional. Instead, a developer can simply enter the information as an annotation directly into a Java source file, and the Java EE server will configure the component at deployment and runtime. These '''annotations''' are generally used to embed in a program data that would otherwise be furnished in a deployment descriptor. With annotations, you put the specification information in your code next to the program element affected.
 
In the Java EE platform, '''dependency injection''' can be applied to all resources that a component needs, effectively hiding the creation and lookup of resources from application code. Dependency injection can be used in EJB containers, web containers, and application clients. Dependency injection allows the Java EE container to automatically insert references to other required components or resources, using annotations.
 
Expert groups, composed of interested parties, have created Java Specification Requests (JSRs) to define the various Java EE technologies:


*'''Web Services Technologies'''
*'''Web Services Technologies'''
Line 11: Line 23:
**Web Service Metadata for the Java Platform (JSR 181)
**Web Service Metadata for the Java Platform (JSR 181)
*'''Web Application Technologies'''
*'''Web Application Technologies'''
**Java Servlet 2.5 (JSR 154)
**Java Servlet (JSR 154)
**JavaServer Faces 1.2 (JSR 252)
**[[JEE#Java_Server_Faces_.28JSF.29|Java Server Faces 1.2 (JSR 252)]]
**JavaServer Pages 2.1 (JSR 245)
**[[JEE#Java_Server_Pages_.28JSP.29|Java Server Pages]]
**JavaServer Pages Standard Tag Library (JSR 52)
**Java Server Pages Standard Tag Library (JSR 52)
*'''Enterprise Application Technologies'''
*'''Enterprise Application Technologies'''
**Enterprise JavaBeans 3.0 (JSR 220)
**[[JEE#Enterprise_Java_Beans_.28EJB.29|Enterprise Java Beans 3.0 (JSR 220)]]
**J2EE Connector Architecture 1.5 (JSR 112)
**[[JEE#JCA|J2EE Connector Architecture 1.5 (JCA) (JSR 112)]]
**Common Annotations for the Java Platform (JSR 250)
**Common Annotations for the Java Platform (JSR 250)
**Java Message Service API (JSR 914)
**[[JEE#Java_Message_Service_.28JMS.29|Java Message Service (JMS) (JSR 914)]]
**Java Persistence API (JSR 220)
**Java Persistence API (JSR 220)
**Java Transaction API (JTA) (JSR 907)
**Java Transaction API (JTA) (JSR 907)
**JavaBeans Activation Framework (JAF) 1.1 (JSR 925)
**Java Beans Activation Framework (JAF) 1.1 (JSR 925)
**JavaMail (JSR 919)
**Java Mail (JSR 919)
**[[#Context_and_Dependency_Injection|Contexts and Dependency Injection (CDI) (JSR 299)]]
*'''Management and Security Technologies'''
*'''Management and Security Technologies'''
**J2EE Application Deployment (JSR 88)
**J2EE Application Deployment (JSR 88)
**J2EE Management (JSR 77)
**J2EE Management (JSR 77)
**Java Authorization Contract for Containers (JSR 115)
**Java Authentication and Authorization Services (JAAS) (JSR 115)
**[[JEE#JNDI|Java Naming and Directory Interface (JNDI)]]


Successfully tested JEE-server get from Sun the grade 'Jave EE compliant'.


==Web-Applications==
==Web-Applications==
A '''web application''' is a collection of servlets, jsps, html-pages, classes and other resources installed under a specific subset of the server's URL namespace such as /catalog and possibly installed via a .war file. In the case of a web application marked "distributed" in its deployment descriptor, there will be one context instance for each virtual machine.  
A '''web application''' is a collection of servlets, jsps, html-pages, classes and other resources installed under a specific subset of the server's URL namespace such as /catalog and possibly installed via a .war file. In the case of a web application marked "distributed" in its deployment descriptor, there will be one context instance for each virtual machine.  


===Directory Structure===
===Deployment Descriptor===
{| border=1 cellpadding=2 cellspacing=0
Eine Web-Applikation wird im File '''web.xml''' beschrieben. Since JEE6 it is optional. Das root Element ist '''<web-app>'''. When the web server receives a request, it determines which servlet class to call using web.xml, which resides in the war/WEB-INF/ directory in the WAR. WEB-INF/ and web.xml are part of the servlet specification. The entries are:
|-
 
====<filter>,<filter-mapping>====
Servlet-Filter bieten eine Möglichkeit, auf die Werte des Requests und der Response um eine Anfrage an eine Web-Ressource herum zuzugreifen. Dabei können mehrere Filter je nach Konfiguration eine Filterkette bilden, die der Request durchläuft. Dabei wird mittels Mapping-Regeln bestimmt, welche Filter für welche Requests zuständig sind und ggf. eine Kette bilden.


|<SERVER_ROOT>/<WEBAPP>/
Jeder Filter muss das Interface javax.servlet.Filter implementieren.
|JSPs, HTMLs
|-


|<SERVER_ROOT>/<WEBAPP>/WEB-INF/
<!-- first define a named filter -->
|deployment descriptor s. 2.2
<filter>
|-
  <filter-name><Name></filter-name>
  <filter-class><Full classname></filter-class>
  <init-param>
      <param-name><Parametername></param-name>
      <param-value><Parametervalue</param-value>
  </init-param>
</filter>
<!-- now map this filter to a URL-pattern -->
<filter-mapping>
  <filter-name><Name s. above></filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>


|<SERVER_ROOT>/<WEBAPP>/WEB-INF/CLASSES/
|servlet and utility classes
|-


|<SERVER_ROOT>/<WEBAPP>/LIB/
====<listener>====
|Jar-Archives the application depends on. If there are duplicate classes in the classes directory they will be used.
'''<listener>''' braces the listener classes. '''<listener-class>''' contains the name of the class that responds to a Web Application event, e.g. to listen for application create/destroy events, to listen for session create/destroy events, to listen for changes to session attributes. The named classes have to implement specific interfaces:
|}
* ServletContextListener
===Deployment Descriptor===
* HttpSessionListener
Eine Web-Applikation wird im File web.xml beschrieben (s. [http://e-docs.bea.com/wls/docs61/webapp/web_xml.html description]). Das root Element ist '''<web-app>'''.  
* HttpSessionAttributeListener


====Servlet====
====<servlet>====
Ein Servlet wird duch '''<servlet>''' mit den folgenden Elementen beschrieben:
Ein Servlet wird mit den folgenden Elementen beschrieben:
{| border=1 cellpadding=2 cellspacing=0
{| border=1 cellpadding=2 cellspacing=0
|-
|-
Line 79: Line 103:
|}
|}


====Listener====
====<welcome-file-list>====
'''<listener-class>''' contains the name of the class that responds to a Web Application event.
Contains a list of files to be used if no file is specified in the URL.


===War-Files===
===WAR-Files===
A war file (web application archive) is just a jar file. Jar up your WEB-INF directory and any other resources (html files, jsp files, etc) into myweb.war, and drop it into your tomcat webapps directory.
A war file (web application archive) is just a jar file. The structure is:
*'''\WEB-INF'''
**['''[[JEE#Deployment_Descriptor|web.xml]]''' for servlet container]
**['''faces-config.xml''' for [[JavaJEEJSF|JSF]]]
**['''[[Seam#Components_configuration|components.xml]]''' for [[Seam]]]
**['''[[Seam#Pageflow_configuration|pages.xml]]''' for [[Seam]]]
**[<WarFileName>'''-ds.xml''' for JPA datasource configuration]
**[other configuration files]
**['''[[Axis#Create_a_web_service_for_an_existing_POJO_and_web_application|Axis Web Services Directories]]'''] for Axis Web Service Implementations]
**['''\classes''']
***[servlet and utilities classes]
***['''\META-INF''']
****['''[[JavaJEEJPA#persistence.xml|persistence.xml]]''']
**['''\lib''']
*'''\META-INF'''
*[own directories]
*[own web files like html, jsp, css]


===Applet Code within a Web-Application===
===Applet Code within a Web-Application===
An applet is executed on the client side (browser), not on the server side (servlet container). You need to place the applet class files in a location accessible from the browser, which means you have to treat them like normal files (like HTML or GIF files that you want the browser to load). Thus they need to go in the webapp directory tree, but '''not''' in the WEB-INF subdirectory.  
An applet is executed on the client side (browser), not on the server side (servlet container). You need to place the applet class files in a location accessible from the browser, which means you have to treat them like normal files (like HTML or GIF files that you want the browser to load). Thus they need to go in the webapp directory tree, but '''not''' in the WEB-INF subdirectory.  
It is best to think of the set of applet class files as entirely different from the set of servlet class files. They will be loaded by different Virtual Machines, and may even have different versions of classes. It is a simple matter to configure your build environment (Ant or make) to create copies of common class files in the two different classpath directories.  
It is best to think of the set of applet class files as entirely different from the set of servlet class files. They will be loaded by different Virtual Machines, and may even have different versions of classes. It is a simple matter to configure your build environment (Ant or make) to create copies of common class files in the two different classpath directories.


==Enterprise Application==


===EAR-Files===
A ear file (enterprise application archive) is just a jar file. The structure is:
*'''\META-INF'''
**'''application.xml'''
**'''jboss-app.xml'''
*['''\lib''']
**[libs]
*[[JEE#beans_jar_file|beans jar file]]
*<nowiki>[</nowiki>[[JEE#WAR-Files|WAR file]]<nowiki>]</nowiki>
Any .jars put in a ''lib'' directory at the top-level of the .ear will be visible to all modules within the .ear. Note that this only applies to Java EE 5 implementations. In J2EE 1.4 and earlier, you'll need to add a Class-Path entry to the ejb-jar's MANIFEST.MF file to refer to the name of the library .jar in the .ear.
====beans jar file====
* '''\META-INF'''
** '''ejb-jar.xml'''
** '''[[JavaJEEJPA#persistence.xml|persistence.xml]]'''
* <bean classes>


==[[Servlets|Servlets]]==
==[[Servlets|Servlets]]==
Line 97: Line 155:
==[[JavaJEEJSF|Java Server Faces (JSF)]]==
==[[JavaJEEJSF|Java Server Faces (JSF)]]==


==JavaBeans==
==[[JavaJEEJMS|Java Message Service (JMS)]]==
The JavaBeans API provides a framework for defining reusable, embeddable, modular software components.
 
* Öffentlicher Standardkonstruktor (Default constructor)
* Serialisierbarkeit (Serializable)
* Öffentliche Zugriffmethoden (Public Getters/Setters)
 
 
===Conventions===
A bean defines a '''property''' &lt;P> of type T if it has accessor methods
public &lt;P>  get&lt;P>() // if T is boolean public boolean  is&;ltP>()
public void    set&lt;P>()
Eine Bean sollte keine public member haben. Die genaue Spezifikation can be found [http://java.sun.com/products/javabeans/docs/spec.html here].
 
==Enterprise Java Beans (EJB)==
EJB sind das Komponentenmodell von Java für Enterprise Anwendungen. Dabei werden viele Anforderungen von Geschäftssystemen wie z.B. Sicherheit, Zuteilung von Resourcen, Persistenz, Nebenläufigkeit und Transaktionsintegrität berücksichtigt. Serverseitige Komponenten können als unabhängige Stückchen ausführbare Software eingesetzt werden. Wenn neue Produkte entwickelt werden und sich betriebliche Vorgänge verändern, können Komponenten neu zusammengefügt, verändert und erweitert werden, so dass das Geschäftssystem diese Veränderung wiederspiegelt.
Die ursprünglichen JavaBeans (java.beans.*) sind ebenfalls ein Komponentenmodell, aber kein serverseitiges wie EJB. Sie haben aber nichts miteinander zutun. Außer das es beides Komponentenmodelle sind und sie den gleichen Namen haben, dienen die beiden APIs unterschiedlichen Zwecken. EJB erweitern das ursprüngliche Modell nicht und verwenden es auch nicht. Die ursprünglichen Beans sind dafür gedacht in einem Prozeß eingesetzt zu werden z.B. für GUI-Elemente.
 
===Versionen und Inhalte===
Im Dezember 1997 gab Sun Microsystems den ersten Entwurf der Spezifikation zu EJB frei.
 
===EJB 3.0===
Version 3.0 sollte die Implementierung vereinfachen. Der zweite Teil beschäftigt sich mit der Persistenz und wird '''Java Persistence API (JPA)''' genannt und im package javax.persitence definiert. [[Hibernate]] implementiert JPA, ist somit eine JPA Engine.
 
===Architektur===
Um eine Enterprise Bean zu implementieren muß man zwei Interfaces und ein oder zwei Klassen definieren.
 
====Remote Interface====
public interface <MyRemoteInterface> extends javax.ejb.EJBObject
{
<MethodSignature> throws RemoteException;...}
Dieses Interface defniert die eigentliche Funktionalität bzw. die business methods der Bean. Alle Methoden müssen eine RemoteException auslösen, was erforderlich ist, wenn eine Methode über RMI aufgerufen wird. EJBs verlangen dies auch bei CORBA-IIOP, oder JRMP (Java Remote Methode Protocol).
 
 
====Home Interface====
public interface <MyHomeInterface> extends javax.ejb.EJBHome
The home interface defines the methods that allow a client to create, find, or remove an enterprise bean.


==[[JavaJEEJPA|Java Persistence API (JPA)]]==


====Bean Klasse====
==[[JavaJEEJTA|Java Transaction API (JTA)]]==
public class <MyBeanClass> implements [javax.ejb.EntityBean | javax.ejb.SessionBean]
Diese Klasse implementiert die Methoden des Remote Interface. In der Regel implementiert sie nicht das Interface, sondern besitzt Methoden mit der passenden Signatur.


====Primärschlüssel====
==JNDI==
public class MyBeanPK implements java.io.Serializable
The Java Naming and Directory Interface (JNDI) is part of the Java platform, providing applications based on Java technology with a unified interface to multiple naming and directory services. JNDI works in concert with other technologies in the Java Platform, Enterprise Edition (Java EE) to organize and locate components in a distributed computing environment.
Nur entity beans benötigen diese Klasse.
JNDI erlaubt die Unterstützung praktisch aller Arten von Namens- und Verzeichnisdiensten, insbesondere von:
Ein großer Teil der Informationen darüber wie Beans zur Laufzeit verwaltet werden, stehen in dem sogenannten Deployment-Deskriptor.  
*[[LDAP|LDAP]]
Ein Client agiert nie direkt mit der Bean-Klasse, sondern verwendet immer nur die Home- und Remote Interfaces einer Bean und interagiert damit automatisch mit den Stubs.
*DNS
Es gibt zwei Arten von EJBs: session beans und entity beans.
*NIS
*CORBA Namensdienst
*Dateisystem


==[[JavaJEEEJB|Enterprise Java Beans (EJB)]]==


====Session Beans====
==JCA==
Session beans are typically used to model business processes or tasks. A session bean might model a set of e-mailing services or credit card validation service. Es gibt zwei Formen von session beans: stateful und stateless. Erstere können wie der Name schon sagt State-Informationen tragen, sind aber bzgl. der Performance bedenklich. Letztere bieten eine bessere Performance u.a. weil sie geshared werden können, aber in diesem Fall muss die State-Informationen irgendwo anders liegen, z.B. in der HTTP-Session von Servlets bzw. in JSP beans.
The J2EE Connector architecture provides a Java technology solution to the problem of connectivity between the many application servers and today's enterprise information systems (EIS). The J2EE Connector architecture defines a standard architecture for connecting the J2EE platform to heterogeneous EIS systems. Examples of EIS systems include ERP, mainframe transaction processing, database systems, and legacy applications not written in the Java programming language. The J2EE Connector architecture enables an EIS vendor to provide a standard resource adapter for its EIS. The resource adapter plugs into an application server, providing connectivity between the EIS, the application server, and the enterprise application. An EIS vendor needs to provide just one standard resource adapter which has the capability to plug in to any application server that supports the J2EE Connector architecture. Multiple resource adapters (that is, one resource adapter per type of EIS) are pluggable into an application server. To achieve a standard system-level pluggability between application servers and EISs, the J2EE Connector architecture defines a standard set of system-level contracts between an application server and EIS. The resource adapter implements the EIS-side of these system-level contracts. An application server and an EIS collaborate to keep all system-level mechanisms, such as transactions, security, and connection management, transparent from the application components.


The J2EE Connector architecture (Version 1.0) defines the following set of system-level contracts:
* connection management
* transaction management
* security contract


====Entity Beans====
The J2EE Connector architecture (Version 1.5) defines the following set of system-level contracts:
Entity beans more often model business objects in a domain. An entity bean might represent a bank account, a customer, etc.. Im Unterschied zu normalen java classes bieten entity beans den Vorteil, das das transaction handling, synchronisierung mit der DB und der Lifecycle standardisiert ist. Allerdings sind sie wiederum sehr teuer.
* transaction inflow contract
* message inflow contract
* lifecycle management
* work management


==Context and Dependency Injection==


====Deployment Descriptor====
==Resources==
Before the jar archive with all the classes is created there must be a directory called META-INF to store the deployment descriptor (always called ejb-jar.xml) and -- optionally -- another XML file to tell the server about application specific server infomormation. With JBoss, this file must be called jboss.xml.
* [http://docs.oracle.com/javaee/6/tutorial/doc/docinfo.html Standard Java 6 Tutorial]

Latest revision as of 21:42, 3 March 2017

Introduction[edit]

Versions[edit]

  • J2EE
  • JEE 5
  • JEE 6

Die aktuelle Version der J2EE-Spezifikation ist die Version 6.0. Der neue Name für die Spezifikation lautet Java Platform, Enterprise Edition, kurz Java EE.

Overview[edit]

JEE basiert auf der Standard Edition (Java SE) and is a collection of specifications for server-based services and frameworks. The Java EE platform uses a simplified programming model. XML deployment descriptors are optional. Instead, a developer can simply enter the information as an annotation directly into a Java source file, and the Java EE server will configure the component at deployment and runtime. These annotations are generally used to embed in a program data that would otherwise be furnished in a deployment descriptor. With annotations, you put the specification information in your code next to the program element affected.

In the Java EE platform, dependency injection can be applied to all resources that a component needs, effectively hiding the creation and lookup of resources from application code. Dependency injection can be used in EJB containers, web containers, and application clients. Dependency injection allows the Java EE container to automatically insert references to other required components or resources, using annotations.

Expert groups, composed of interested parties, have created Java Specification Requests (JSRs) to define the various Java EE technologies:

Successfully tested JEE-server get from Sun the grade 'Jave EE compliant'.

Web-Applications[edit]

A web application is a collection of servlets, jsps, html-pages, classes and other resources installed under a specific subset of the server's URL namespace such as /catalog and possibly installed via a .war file. In the case of a web application marked "distributed" in its deployment descriptor, there will be one context instance for each virtual machine.

Deployment Descriptor[edit]

Eine Web-Applikation wird im File web.xml beschrieben. Since JEE6 it is optional. Das root Element ist <web-app>. When the web server receives a request, it determines which servlet class to call using web.xml, which resides in the war/WEB-INF/ directory in the WAR. WEB-INF/ and web.xml are part of the servlet specification. The entries are:

<filter>,<filter-mapping>[edit]

Servlet-Filter bieten eine Möglichkeit, auf die Werte des Requests und der Response um eine Anfrage an eine Web-Ressource herum zuzugreifen. Dabei können mehrere Filter je nach Konfiguration eine Filterkette bilden, die der Request durchläuft. Dabei wird mittels Mapping-Regeln bestimmt, welche Filter für welche Requests zuständig sind und ggf. eine Kette bilden.

Jeder Filter muss das Interface javax.servlet.Filter implementieren. 

<filter>
  <filter-name><Name></filter-name>
  <filter-class><Full classname></filter-class>
  <init-param>
     <param-name><Parametername></param-name>
     <param-value><Parametervalue</param-value>
  </init-param>
</filter>

<filter-mapping>
  <filter-name><Name s. above></filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>


<listener>[edit]

<listener> braces the listener classes. <listener-class> contains the name of the class that responds to a Web Application event, e.g. to listen for application create/destroy events, to listen for session create/destroy events, to listen for changes to session attributes. The named classes have to implement specific interfaces:

  • ServletContextListener
  • HttpSessionListener
  • HttpSessionAttributeListener

<servlet>[edit]

Ein Servlet wird mit den folgenden Elementen beschrieben:

<servlet-name> required
<servlet-class> required (or use <jsp-file>) [<Packages>].<Class>

Zur Abbildung auf eine URL dient das <servlet-mapping> mit den folgenden Elementen:

<servlet-name> required
<url-pattern> required /xyz/abc => nur <WebAppURL>/xyz/abc\\\\/xyz/* => alle <WebAppURL>/*\\\\*.abc => alle <WebAppURL>/*/*.abc

<welcome-file-list>[edit]

Contains a list of files to be used if no file is specified in the URL.

WAR-Files[edit]

A war file (web application archive) is just a jar file. The structure is:

Applet Code within a Web-Application[edit]

An applet is executed on the client side (browser), not on the server side (servlet container). You need to place the applet class files in a location accessible from the browser, which means you have to treat them like normal files (like HTML or GIF files that you want the browser to load). Thus they need to go in the webapp directory tree, but not in the WEB-INF subdirectory. It is best to think of the set of applet class files as entirely different from the set of servlet class files. They will be loaded by different Virtual Machines, and may even have different versions of classes. It is a simple matter to configure your build environment (Ant or make) to create copies of common class files in the two different classpath directories.

Enterprise Application[edit]

EAR-Files[edit]

A ear file (enterprise application archive) is just a jar file. The structure is:

Any .jars put in a lib directory at the top-level of the .ear will be visible to all modules within the .ear. Note that this only applies to Java EE 5 implementations. In J2EE 1.4 and earlier, you'll need to add a Class-Path entry to the ejb-jar's MANIFEST.MF file to refer to the name of the library .jar in the .ear.

beans jar file[edit]

Servlets[edit]

Java Server Pages (JSP)[edit]

Java Server Faces (JSF)[edit]

Java Message Service (JMS)[edit]

Java Persistence API (JPA)[edit]

Java Transaction API (JTA)[edit]

JNDI[edit]

The Java Naming and Directory Interface (JNDI) is part of the Java platform, providing applications based on Java technology with a unified interface to multiple naming and directory services. JNDI works in concert with other technologies in the Java Platform, Enterprise Edition (Java EE) to organize and locate components in a distributed computing environment. JNDI erlaubt die Unterstützung praktisch aller Arten von Namens- und Verzeichnisdiensten, insbesondere von:

  • LDAP
  • DNS
  • NIS
  • CORBA Namensdienst
  • Dateisystem

Enterprise Java Beans (EJB)[edit]

JCA[edit]

The J2EE Connector architecture provides a Java technology solution to the problem of connectivity between the many application servers and today's enterprise information systems (EIS). The J2EE Connector architecture defines a standard architecture for connecting the J2EE platform to heterogeneous EIS systems. Examples of EIS systems include ERP, mainframe transaction processing, database systems, and legacy applications not written in the Java programming language. The J2EE Connector architecture enables an EIS vendor to provide a standard resource adapter for its EIS. The resource adapter plugs into an application server, providing connectivity between the EIS, the application server, and the enterprise application. An EIS vendor needs to provide just one standard resource adapter which has the capability to plug in to any application server that supports the J2EE Connector architecture. Multiple resource adapters (that is, one resource adapter per type of EIS) are pluggable into an application server. To achieve a standard system-level pluggability between application servers and EISs, the J2EE Connector architecture defines a standard set of system-level contracts between an application server and EIS. The resource adapter implements the EIS-side of these system-level contracts. An application server and an EIS collaborate to keep all system-level mechanisms, such as transactions, security, and connection management, transparent from the application components.

The J2EE Connector architecture (Version 1.0) defines the following set of system-level contracts:

  • connection management
  • transaction management
  • security contract

The J2EE Connector architecture (Version 1.5) defines the following set of system-level contracts:

  • transaction inflow contract
  • message inflow contract
  • lifecycle management
  • work management

Context and Dependency Injection[edit]

Resources[edit]

Retrieved from "http://uweheuer.spdns.de/mediawiki_new/index.php?title=JEE&oldid=6356"