JEE

From Wiki RB4

Ü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)

JNDI

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

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. Die blaufumgebung ist der EJB Container, der folgende Dienste zur Verfügung stellt:

  • Security Handling
  • Concurrency Handling
  • Transaction Handling
  • load balancing and distribution

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

EJB 1.0

  • 1998

EJB 2.1

Disadvantages
  • complex, not lightweight
    • content and numbers of deployment descriptors
    • some methods have to be implemented, although they were not in an interface and couldn't be checked at compile time
    • neccessity to implement artifacts
  • functional range for persistence was not enough to model established O/R mappings
    • container-managed persistance for an entity with a multi-table-mapping

EJB 3.0

  • 05/2006

Version 3.0 vereinfacht die Implementierung. Getrieben wurde dies durch konkurrierende lightweight frameworks wie Spring oder Hibernate, durch neue Java 5 Erweiterungen oder neue Design-Prinzipien wie Aspect Oriented Programming (AOP). EJB 3.0 is based on:

  • annotations (eleminates the xml deployment descriptors in 80%, but it can still be there. Descriptor overwrites annotations)
  • container managed POJOs with arbitrary inheritance structures
  • dependency injection (EJB isn't lookup up anymore, but specified by annotation and the container manages the rest, also cault inversion of control (IOC))
  • configuration by exceptions (only the special case has be described)
  • improvement of testability (no container for test necessary)
  • improvement of database queries (JPA instead of native SQL)
  • cross-cutting concern (Auslagerung von zentralen Funktionalitäten in interceptors z.B. zum Logging oder zentraler fachlicher Funktionalitäten)
  • shorter development cycles (because less errors, which are detected after build and deploy)

Architektur

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. An EJB 3.0 session bean is a POJO managed by the EJB container, which are annotated with @stateless or @stateful. Additionally the the business methods have to be specified in a Plain Old Java Interface (POJI). By design, the EJB specification disallows the same Business interface to be marked as @Local as well as @Remote (this restriction has been added in a revision to the PFD). The reason for this is that remote interfaces have different semantics to local interfaces, and it is usually inappropriate for the same method to be exposed as a remote interface as well as local interface. The problems are two-fold:

  1. Remote interfaces must typically be designed to be coarse-grained.
  2. Remote interfaces do not support the pass-by-reference semantics of parameter passing as in local interfaces.

Having separate Remote and Local interfaces forces designers to think about how the interfaces will be used and ensure that the design is optimised for the use case. It also reduces the chances of errors caused by incorrect semantics, such as clients relying upon ability to pass parameters by reference. Local Interfaces can only be uses in the same application (ear-file), not on the same server.

Stateless Session Beans

In a stateless session bean (SLSB), the client-side stub object can route your method call to any bean instance that happens to be available in the container-managed object pool. Hence, you should not have any field variables to store the bean state in the bean class. To define a session bean, you first need to define the local and remote service interface containing all its business methods. The session bean interface is just plain old Java interface without any annotation e.g. 

public interface Calculator {
  public double calculate (int start, int end, double growthrate, double saving);
}
public interface RemoteCalculator {
  public double calculate (int start, int end, double growthrate, double saving);
  public String getServerInfo ();
}

and the implementation class: 

@Stateless
@Local ({Calculator.class})                                    // specification of the local interface
@LocalBinding (jndiBinding="EJB3Trail/LocalCalculator")
@Remote ({RemoteCalculator.class})                             // specification of the remote interface
@RemoteBinding (jndiBinding="EJB3Trail/RemoteCalculator")
public class StatelessCalculator 
  implements Calculator, RemoteCalculator {
  public double calculate (int start, int end, double growthrate, double saving) {
    double tmp = Math.pow(1. + growthrate / 12., 12. * (end - start) + 1);
    return saving * 12. * (tmp - 1) / growthrate;
  }
}


Stateful Session Beans

If the client invokes method calls against the same bean stub, the calls are always tunneled to the same bean instance in the container. So, all field variables in the bean instance retain their values as long as the client application retains the bean stub (or reference for a local client). In a web application, the servlet (or JSP page) caches the bean stub as an attribute in the HttpSession object. It is very important to note that the stateful session bean class must implement the Serializable interface so that the container can serialize them and store them to preserve the state information when the bean instances are not in use.

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.

Patterns

Service Locator

  • for accessing beans instead of the lookup, create sequence

Business Delegate

Resources

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