JEE
Ü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:
- Web Services Technologies
- Implementing Enterprise Web Services (JSR 109)
- Java API for XML-Based Web Services (JAX-WS) 2.0 (JSR 224)
- Java API for XML-Based RPC (JAX-RPC) 1.1 (JSR 101)
- Java Architecture for XML Binding (JAXB) 2.0 (JSR 222)
- SOAP with Attachments API for Java (SAAJ) (JSR 67)
- Streaming API for XML (JSR 173)
- Web Service Metadata for the Java Platform (JSR 181)
- Web Application Technologies
- Java Servlet 2.5 (JSR 154)
- JavaServer Faces 1.2 (JSR 252)
- JavaServer Pages 2.1 (JSR 245)
- JavaServer Pages Standard Tag Library (JSR 52)
- Enterprise Application Technologies
- Enterprise JavaBeans 3.0 (JSR 220)
- J2EE Connector Architecture 1.5 (JSR 112)
- Common Annotations for the Java Platform (JSR 250)
- Java Message Service API (JSR 914)
- Java Persistence API (JSR 220)
- Java Transaction API (JTA) (JSR 907)
- JavaBeans Activation Framework (JAF) 1.1 (JSR 925)
- JavaMail (JSR 919)
- Management and Security Technologies
- J2EE Application Deployment (JSR 88)
- J2EE Management (JSR 77)
- Java Authorization Contract for Containers (JSR 115)
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.
Directory Structure
| <SERVER_ROOT>/<WEBAPP>/ | JSPs, HTMLs |
| <SERVER_ROOT>/<WEBAPP>/WEB-INF/ | deployment descriptor s. 2.2 |
| <SERVER_ROOT>/<WEBAPP>/WEB-INF/CLASSES/ | servlet and utility classes |
| <SERVER_ROOT>/<WEBAPP>/LIB/ | Jar-Archives the application depends on. If there are duplicate classes in the classes directory they will be used. |
Deployment Descriptor
Eine Web-Applikation wird im File web.xml beschrieben (s. description). Das root Element ist <web-app>.
Servlet
Ein Servlet wird duch <servlet> 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 |
Listener
<listener> braces the listener classes. <listener-class> contains the name of the class that responds to a Web Application event.
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.
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. 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.
Servlets
Java Server Pages (JSP)
Java Server Faces (JSF)
JavaBeans
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 <P> of type T if it has accessor methods
public <P> get<P>() // if T is boolean public boolean is&;ltP>() public void set<P>()
Eine Bean sollte keine public member haben. Die genaue Spezifikation can be found 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.
Bean Klasse
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
public class MyBeanPK implements java.io.Serializable Nur entity beans benötigen diese Klasse. Ein großer Teil der Informationen darüber wie Beans zur Laufzeit verwaltet werden, stehen in dem sogenannten Deployment-Deskriptor. 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. Es gibt zwei Arten von EJBs: session beans und entity beans.
Session Beans
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.
Entity Beans
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.
Deployment Descriptor
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.
Sources
- EJB Tutorial http://docs.jboss.org/ejb3/app-server/tutorial/index.html
- Comparison between EJB 3.0 and EJB 2.1 implementation http://www.jroller.com/raghukodali/entry/does_ejb_3_0_really