JEE
Introduction
Versions
- J2EE
- JEE (5)
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).
Overview
JEE basiert auf der Standard Edition (Java SE) and is a collection of specifications for server-based services and frameworks (Java Specificatin Request):
- 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 (JSR 154)
- Java Server Faces 1.2 (JSR 252)
- Java Server Pages
- Java Server Pages Standard Tag Library (JSR 52)
- Enterprise Application Technologies
- Enterprise Java Beans 3.0 (JSR 220)
- J2EE Connector Architecture 1.5 (JCA) (JSR 112)
- Common Annotations for the Java Platform (JSR 250)
- Java Message Service (JMS) (JSR 914)
- Java Persistence API (JSR 220)
- Java Transaction API (JTA) (JSR 907)
- Java Beans Activation Framework (JAF) 1.1 (JSR 925)
- Java Mail (JSR 919)
- Management and Security Technologies
- J2EE Application Deployment (JSR 88)
- J2EE Management (JSR 77)
- Java Authentication and Authorization Services (JAAS) (JSR 115)
- Java Naming and Directory Interface (JNDI)
Successfully tested JEE-server get from Sun the grade 'Jave EE compliant'.
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, 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
WAR-Files
A war file (web application archive) is just a jar file. The structure is:
- WEB-INF
- [web.xml for servlet container]
- [faces-config.xml for jsf]
- [other configuration files]
- [classes]
- [lib]
- META-INF
- [own directories]
- [own web files like html, jsp, css]
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.
Enterprise Application
EAR-Files
A ear file (enterprise application archive) is just a jar file. The structure is:
- META-INF
- application.xml
- [lib]
- [libs]
- beans jar file
- [war file]
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
- persistence.xml
- <bean classes>
Servlets
Java Server Pages (JSP)
Java Server Faces (JSF)
Java Message Service (JMS)
Java Persitence API (JPA)
Java Transaction API (JTA)
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
Enterprise Java Beans (EJB)
JCA
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