(translated from Sun's JavaEE 5 Tutorial)

Mô Hình Ứng Dụng Java Enterprise Edition

Java EE được thiết kế để hỗ trợ các ứng dụng cài đặt các dịch vụ doanh nghiệp cho khách hàng nhân viên, nhà cung cấp, các đối tác có nhu cầu hoặc quan hệ với doanh nghiệp. Các ứng dụng tiềm ẩn sự phức tạp và truy xuất dữ liệu từ nhiều nguồn và phân phối các ứng dụng đến nhiều loại người dùng.

Distributed Multitiered Applications

Nền tảng Java EE sử dụng mô hình ứng dụng nhiều lớp (tiers) cho các ứng dụng doanh nghiệp. Logic ứng dụng được chia thành các components theo chức năng và nhiều application components tạo nên Java EE application được cài đặt trên nhiều máy khác nhau phụ thuộc vào tier nào trong môi trường Java EE mà application components được cài.

• Client-tier components chạy trên máy client.

• Web-tier components chạy trên Java EE server.

• Business-tier components chạy trên Java EE server.

• Enterprise information system (EIS)-tier software chạy trên EIS server.

Mặc dù 1 ứng dụng Java EE có thể gồm 3 hay 4 tiers như hình trên, ứng dụng Java EE thường được xem là ứng dụng 3 lớp vì chứng được phân phối ở 3 nơi: máy khách, máy Java EE server, và database hay các máy tài nguyên khác ở hậu trường. Ứng dụng 3 lớp chạy theo cách này là mở rộng chuẩn mô hình 2 lớp client-server bằng việc đặt máy chủ ứng dụng đa luồng ở giữa ứng dụng khách và đầu lưu trữ.

Bảo mật
Java EE security cho phép các ràng buộc được xác định tại thời điểm deploy.
Nền tảng Java EE cung cấp các quy tắc truy xuất bằng khai báo chuẩn được xác định bởi developer và thực thi khi deploy trên server. Java EE cung cấp cơ chế login chuẩn. cùng 1 ứng dụng sẽ chạy trên những môi trường bảo mật khác nhau mà khong phải thay đổi code.

Java EE Components
Ứng dụng Java EE được tạo từ các components. 1 Java EE component là 1 đơn vị software cần được lắp ráp lại để thành 1 ứng dụng Java EE với những lớp và files có liên quan và communicate với các components khác

• Application clients and applets are components chạy trên client.

• Java Servlet, JavaServer Faces, and JavaServer Pages™ (JSP™) technology components are web components chạy trên server.

• Enterprise JavaBeans™ (EJB™) components (enterprise beans) are business components chạy trên server.
  

Web Clients

1 web client gồm 2 phần

(1) dynamic web pages chứa nhiều loại ngôn ngữ đánh dấu (HTML, XML, and so on), được sinh ra bởi các web components chạy trên web tier,

(2) 1 web browser, có nhiệm vụ hiển thị các trang nhận được từ server

1 web client đôi khi được gọi là thin client. Thin clients thường không truy vấn databases, thực thi các business rules phức tạp, hay kết nối đến các ứng dụng hợp pháp khác. Khi dùng thin client, các tác vụ phức tạp nặng nề được chuyển cho enterprise beans (EJB) chạy trên Java EE server, nơi mà cung cấp các chức năng về bảo mật tốc độ, dịch vụ và sự ổn định của kỹ thuật về phía server.

Applets

1 web page nhận từ web tier có thể chứa 1 embedded applet. 1 applet là 1 ứng dụng khách nhỏ (small client application ) được viết bằng Java được chạy trên máy ảo Java được cài đặt trên web browser. Tuy nhiên, các hệ thống khách sẽ cần các Java Plugin và các security policy file để applet chạy được trên web browser

Web components là những API được ưa chuộng cho việc tạo các web client program vì không cần các plug ins hay security files được cài đặt trên hệ thống client

Application Clients

1 application client chạy trên máy client và cung cấp 1 phương tiện để các users để xử lý các task đòi hỏi giao diện GUI phức tạp mà markup language không làm được. Các API thường dùng là Swing hay Abstract Window Toolkit (AWT) API, nhưng 1 giao diện dòng lệnh vẫn có thể được sử dụng.

Application clients truy xuất trực tiếp các enterprise beans (EJBs) chạy ở business tier. Tuy nhiên, nếu cần, 1 application client có thể mở 1 HTTP connection để thiết lập kết nối với 1 servlet chạy ở web tier. Application clients viết bằng các các ngôn ngữ không phải Java có thể tương tác với Java EE 5 servers, cho phép Java EE 5 platform tương tác với các hệ thống hợp pháp khác, các clients, không phải Java language.

The JavaBeans™ Component Architecture

Server and client tiers có thể dùng các components dựa trên nền tảng JavaBeans component architecture (JavaBeans components) để quản lý dòng dữ liệu (data flow) giữa ứng dụng client hay applet và các components chạy trên Java EE server hay giữa server components và database. JavaBeans components không được xem là Java EE components theo Specification của Java EE.

JavaBeans components có các thuộc tính và có hàm get và set methods để truy xuất thuộc tính.

Java EE Server Communications

Figure dưới đây trình bày các elements tạo nên client tier. The client giao tiếp với business tier chạy trên Java EE server hoặc trực tiếp hay , như trong trường hợp client chạy trên browser, bằng các trang JSP hay servlets chạy trên web tier.

Càng nhiều chức năng đặt trên server, càng dễ phân phối, triển khai và quản lý ứng dụng; tuy nhiên, càng giữ nhiều chức năng trên client càng làm người dùng thấy tiện lợi.

Web Components

Java EE web components hoặc là servlets hoặc các pages được tạo bằng JSP technology (JSP pages) và/hoặc JavaServer Faces technology. Servlets là các lớp Java xử lý động các request và xây dụng các response. JSP pages là document dạng text mà chạy như là các servlet nhưng cho phép tạo các dữ liệu tĩnh 1 cách tự nhiên. JavaServer Faces technology xây dựng trên nền servlets and JSP technology cung cấp user interface component framework cho web applications.

Các trang HTML tĩnh và applets được đóng gói cùng với web components trong quá trình lắp ráp ứng dụng nhưng không được coi là web components theo chuẩn Java EE specification. Các lớp ứng dụng phía Server-side cũng được đóng gói cùng với web components và, giống như các trang HTML , không được xem là web components.

Như hình sau, web tier, giống như client tier, có thể bao gồm JavaBeans component để quản lý dữ liệu người dùng nhập vào và gởi dữ liệu đó cho enterprise beans (EJB) chạy trên business tier xử lý.

Business Components

Business code, là logic xử lý hay đáp ứng các yêu cầu cho 1 loại nghiệp vụ nào đó cho 1 loại hình doanh nghiệp nào đó như là banking, retail, or finance, được xử lý bởi các enterprise beans (EJB) chạy trên business tier.

Hình sau hướng dẫn cách enterprise bean nhận data từ client programs, xử lý nó (nếu cần), và gởi nó cho Enterprise Information System tier để lưu trữ. 1 enterprise bean (EJB) cũng nhận data từ database, xử lý nó (nếu cần), và gởi nó về client programs.

Enterprise Information System Tier

Enterprise Information System tier xử lý EIS software và bao gồm cả enterprise infrastructure systems như là enterprise resource planning (ERP), mainframe transaction processing, database systems, and other legacy information systems. Ví d, Java EE application components có thể cần truy xuất đến enterprise information systems for database connectivity.

Java EE Containers

Container Services

Containers là interface giữa 1 component và low-level platform-specific functionality hỗ trợ component. Trước khi 1 web, enterprise bean, hay application client component có thể dùng được, nó phải được lắp ráp thàn các Java EE module và deploy vào các container của nó.

Tiến trình lắp ráp liên quan đến các thiết lập container cụ thể cho mỗi component trong ứng dụng JavaEE và cho toàn bộ ứng dụng JavaEE. Cấu hình Container dùng điều chỉnh cách chức năng mà JavaEE server hỗ trợ, bao gồm các dịch vụ như là security, transaction management, Java Naming and Directory Interface™ (JNDI) lookups, and kết nối từ xa

• Mô hình bảo mật Java EE cho phép bạn cấu hình 1 web component hay enterprise bean (EJB) để các tài nguyên hệ thống chỉ được truy xuất bởi các users có thẩm quyền.

• Mô hình transaction của Java EE cho phép bạn xác định mối liên hệ giữa các methods làm nên chỉ 1 transaction để tất cả các methods trong 1 transaction được xem như là 1 đơn vị.

• Dịch vụ tìm kiếm JNDI cung cấp 1 interface thống nhất theo tên (naming) và dịch vụ directory trong doanh nghiệp để các application components có thể truy xuất các dịch vụ đó.

• Mô hình kết nối Java EE quản lý truyền thông ở mức độ thấp (low-level) giữa clients và enterprise beans (EJB). Sau khi 1 enterprise bean được tạo ra, 1 client gọi các methods của nó như thể nó tồn tại trên cùng 1 máy ảo.

Các loại Container

Tiến trình cài đặt các components của ứng dụng Java EE trong Java EE containers được mô tả ở hình dưới.

• Java EE server: nơi chạy các sản phẩm Java EE. 1 Java EE server cung cấp EJB và web containers.

• Enterprise JavaBeans (EJB) container: quản lý việc chạy các enterprise beans cho ứng dụng Java EE applications. Enterprise beans và container của nó chạy trên Java EE server.

• Web container: quản lý việc chạy các trang JSP và servlet components cho ứng dụng Java EE. Web components và container của nó chạy trên Java EE server.

• Application client container: quản lý việc chạy các application client components. Application clients và container của nó chạy trên client.

• Applet container: quản lý việc chạy các applets. Bao gồm 1 web browser và Java Plug-in chạy trên client cùng với nhau.

Web Services Support

Web services là các ứng dụng doanh nghiệp dựa trên nền web sử dụng công nghệ chuẩn và mở trên nền XML và giao thức transport để trao đổi dữ liệu với việc gọi các client. Nền tảng Java EE cung cấp các XML APIs và các công cụ bạn cần để thiết kế, phát triển, kiểm tra, và triển khaiweb services 1 cách nhanh chóng và các clients có đầy đủ khả năng tương tác với các ứng dụng web services khác và với các clients chạy trên nền Java hay không phải Java.

Để viết web services và các clients bằng Java EE XML API, tất cả việc cần làm là truyền dữ liệu cho các methods và xử lý kết quả trả về; hoặc đối với cá web services hướng đến tài liệu(document-oriented), bạn gởi tài liệu (document) chứa dữ liệu service đi và về. Không cần lập trình cấp thấp ở đây vì XMP API implementations làm công việc dịch dữ liệu ứng dụng đi và về từ 1 luồng dữ liệu dạng XML đã được gởi theo chuẩnXML-based transport protocols

Việc dịch dữ liệu sang luồng theo dạng XML chuẩn hóa để làm các web services và các clients được viết bằng Java EE XML APIs hoàn toàn có thể tương tác được với nhau. Điều này không cần thiết nghĩa là dữ liệu được truyền bao gồm XML tags vì dữ liệu được truyền chính nó có thể là plain text, XML data, hay bất kỳ loại dữ liệu nhị phân nào như audio, video, maps, programs files, computer-aided design (CAD) documents ...

XML

XML là dạng chuẩn dựa trên nền văn bản (text-based) có tính mở rộng, độc lập hệ điều hành, độc lập ngôn ngữ ứng dụng để mô tả dữ liệu. Khi dữ liệu XML trao đổi giữa các bên, các bên có toàn quyền tạo các tags riêng cho mình để mô tả dữ liệu, thiết kế các schemas để xác dịnh tag nào có thể được dùng trong 1 loại XML document nào, và sử dụng XML stylesheets để quản lý việc hiển thị và xử lý dữ liệu.

Giao thức truyền tải SOAP (SOAP Transport Protocol)

Các yêu cầu của Client và hồi âm của web service được trao đổi dưới 1 dạng thông điệp kiểu Simple Object Access Protocol (SOAP) trên phương tiện HTTP, nhằm đảm bảo việc tương tác giữa client và web services. Client và web services có thể chạy trên các nền ngôn ngữ khác nhau và ở nhiều nơi trên Internet. HTTP là chuẩn yêu cầu - hồi âm (request-response) quen thuộc cho việc gởi các thông điệp trên Internet, và SOAP là 1 giao thức dựa trên nền XML tuân thủ mô hình yêu cầu - hồi âm của HTTP.

Phần SOAP cho việc truyền tải thông điệp xử lý như sau:

• Định nghĩa phong bì theo nền XML để mô tả cái gì trong thông điệp và cách xử lý thông điệp.

• Bao gồm các quy tắc mã hóa trên nền XML để diễn tả lọai dữ liệu mà ứng dụng sử dụng trong thông điệp.

• Định nghĩa các quy tắc trên nền XML cho việc diễn tả yêu cầu (request) cho các dịch vụ từ xa (remote service) và hồi âm kết quả.
  

WSDL Standard Format

Ngôn Ngữ Mô Tả Các Dịch Vụ Web (The Web Services Description Language (WSDL)) là 1 định dạng XML đã chuẩn hóa cho việc mô tả các dịch vụ trên mạng. Mô tả bao gồm tên của dịch vụ, địa chỉ của dịch vụ, và cách để liên hệ với dịch vụ. Các mô tả dịch vụ WSDL có thể lưu trữ ở hồ sơ UDDI (UDDI registries) hay phát hành rộng rãi trên web hay cả 2. Sun Java System Application Server Platform Edition 8 cung cấp 1 công cụ cho việc sinh tự động đặc tả WSDL các dịch vụ Web có sử dụng các hàm gọi từ xa (remote procedure calls) để truyền thông với clients.

Các định dạng chuẩn UDDI và ebXML

Các chuẩn trên nền XML khác như là Universal Description, Discovery and Integration (UDDI) và ebXML, khiến các doanh nghiệp dễ dàng phát hàng thông tin lên Internet và các sản phẩm của họ và các dịch vụ web, nơi mà thông tin có thể sẵn sàng truy cập toàn cầu bởi các clients muốn kinh doanh

Java EE Application Assembly and Deployment 1 ứng dụng Java EE được đóng gói thành 1 hay nhiều đơn vị chuẩn cho việc triển khai đến bất kỳ hệ thống tương thích nền Java EE. Mỗi đơn vị chứa: 1 component chức năng hay các components (enterprise bean, JSP page, servlet, applet, etc.) 1 file đặc tả yêu cầu triển khai. Khi 1 đơn vị Java EE đã được tạo, nó sẵn sàng được triển khai (deploy). Việc triển khai liên quan đến dùng 1 công cụ do nhà cung cấp JavaEE cung cấp để xác định các thông tin đặc trưng riêng. như là danh sách các người dùng nội bộ có thể truy xuất nó và tên của database cục bộ. Một khi đã triển khai trên 1 hệ thống, ứng dụng sẵn sàng chạy.

Đóng Gói Ứng Dụng

A Java EE application is delivered in an Enterprise Archive (EAR) file, a standard Java Archive (JAR) file with an .ear extension. Using EAR files and modules makes it possible to assemble a number of different Java EE applications using some of the same components. No extra coding is needed; it is only a matter of assembling (or packaging) various Java EE modules into Java EE EAR files.

An EAR file (see Figure 16) contains Java EE modules and deployment descriptors. A deployment descriptor is an XML document with an .xml extension that describes the deployment settings of an application, a module, or a component. Because deployment descriptor information is declarative, it can be changed without the need to modify the source code. At runtime, the Java EE server reads the deployment descriptor and acts upon the application, module, or component accordingly.

There are two types of deployment descriptors: Java EE and runtime. A Java EE deployment descriptor is defined by a Java EE specification and can be used to configure deployment settings on any Java EE-compliant implementation. A runtime deployment descriptor is used to configure Java EE implementation-specific parameters. For example, the Sun Java System Application Server Platform Edition 9 runtime deployment descriptor contains information such as the context root of a web application, the mapping of portable names of an application's resources to the server's resources, and Application Server implementation-specific parameters, such as caching directives. The Application Server runtime deployment descriptors are named sun-moduleType.xml and are located in the same directory as the Java EE deployment descriptor.

A Java EE module consists of one or more Java EE components for the same container type and one component deployment descriptor of that type. An enterprise bean module deployment descriptor, for example, declares transaction attributes and security authorizations for an enterprise bean. A Java EE module without an application deployment descriptor can be deployed as a stand-alone module. The four types of Java EE modules are as follows:

• EJB modules, which contain class files for enterprise beans and an EJB deployment descriptor. EJB modules are packaged as JAR files with a .jar extension.

• Web modules, which contain servlet class files, JSP files, supporting class files, GIF and HTML files, and a web application deployment descriptor. Web modules are packaged as JAR files with a .war (Web ARchive) extension.

• Application client modules, which contain class files and an application client deployment descriptor. Application client modules are packaged as JAR files with a .jar extension.

• Resource adapter modules, which contain all Java interfaces, classes, native libraries, and other documentation, along with the resource adapter deployment descriptor. Together, these implement the Connector architecture (see J2EE Connector Architecture, page 23) for a particular EIS. Resource adapter modules are packaged as JAR files with an .rar (resource adapter archive) extension.

Development Roles

Reusable modules make it possible to divide the application development and deployment process into distinct roles so that different people or companies can perform different parts of the process.

Java EE Product Provider

The Java EE product provider is the company that designs and makes available for purchase the Java EE platform APIs, and other features defined in the Java EE specification. Product providers are typically application server vendors who implement the Java EE platform according to the Java EE 5 Platform specification.

Tool Provider

The tool provider is the company or person who creates development, assembly, and packaging tools used by component providers, assemblers, and deployers.

Application Component Provider

The application component provider is the company or person who creates web components, enterprise beans, applets, or application clients for use in Java EE applications.

Enterprise Bean Developer

An enterprise bean developer performs the following tasks to deliver an EJB JAR file that contains the enterprise bean(s):

• Writes and compiles the source code

• Specifies the deployment descriptor

• Packages the .class files and deployment descriptor into the EJB JAR file

Web Component Developer

A web component developer performs the following tasks to deliver a WAR file containing the web component(s):

• Writes and compiles servlet source code

• Writes JSP, JavaServer Faces, and HTML files

• Specifies the deployment descriptor

• Packages the .class, .jsp, and .html files and deployment descriptor into the WAR file

Application Client Developer

An application client developer performs the following tasks to deliver a JAR file containing the application client:

• Writes and compiles the source code

• Specifies the deployment descriptor for the client

• Packages the .class files and deployment descriptor into the JAR file

Application Assembler

The application assembler is the company or person who receives application modules from component providers and assembles them into a Java EE application EAR file. The assembler or deployer can edit the deployment descriptor directly or can use tools that correctly add XML tags according to interactive selections. A software developer performs the following tasks to deliver an EAR file containing the Java EE application:

• Assembles EJB JAR and WAR files created in the previous phases into a Java EE application (EAR) file

• Specifies the deployment descriptor for the Java EE application

• Verifies that the contents of the EAR file are well formed and comply with the Java EE specification

Application Deployer and Administrator

The application deployer and administrator is the company or person who configures and deploys the Java EE application, administers the computing and networking infrastructure where Java EE applications run, and oversees the runtime environment. Duties include such things as setting transaction controls and security attributes and specifying connections to databases.

During configuration, the deployer follows instructions supplied by the application component provider to resolve external dependencies, specify security settings, and assign transaction attributes. During installation, the deployer moves the application components to the server and generates the container-specific classes and interfaces.

A deployer or system administrator performs the following tasks to install and configure a Java EE application:

• Adds the Java EE application (EAR) file created in the preceding phase to the Java EE server

• Configures the Java EE application for the operational environment by modifying the deployment descriptor of the Java EE application

• Verifies that the contents of the EAR file are well formed and comply with the Java EE specification

• Deploys (installs) the Java EE application EAR file into the Java EE server

Java EE 5 APIs

Figure 17 illustrates the availability of the Java EE 5 platform APIs in each Java EE container type. The following sections give a brief summary of the technologies required by the Java EE platform, and the APIs used in Java EE applications.

Enterprise JavaBeans Technology

An Enterprise JavaBeans™ (EJB™) component, or enterprise bean, is a body of code having fields and methods to implement modules of business logic. You can think of an enterprise bean as a building block that can be used alone or with other enterprise beans to execute business logic on the Java EE server.

There are two kinds of enterprise beans: session beans and message-driven beans. A session bean represents a transient conversation with a client. When the client finishes executing, the session bean and its data are gone. A message-driven bean combines features of a session bean and a message listener, allowing a business component to receive messages asynchronously. Commonly, these are Java Message Service (JMS) messages.

In Java EE 5, entity beans have been replaced by Java™ persistence API entities. An entity represents persistent data stored in one row of a database table. If the client terminates, or if the server shuts down, the persistence manager ensures that the entity data is saved.

Java Servlet Technology

Java servlet technology lets you define HTTP-specific servlet classes. A servlet class extends the capabilities of servers that host applications that are accessed by way of a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by web servers.

JavaServer Pages Technology

JavaServer Pages™ (JSP™) technology lets you put snippets of servlet code directly into a text-based document. A JSP page is a text-based document that contains two types of text: static data (which can be expressed in any text-based format such as HTML, WML, and XML) and JSP elements, which determine how the page constructs dynamic content.

JavaServer Pages Standard Tag Library

The JavaServer Pages Standard Tag Library (JSTL) encapsulates core functionality common to many JSP applications. Instead of mixing tags from numerous vendors in your JSP applications, you employ a single, standard set of tags. This standardization allows you to deploy your applications on any JSP container that supports JSTL and makes it more likely that the implementation of the tags is optimized.

JSTL has iterator and conditional tags for handling flow control, tags for manipulating XML documents, internationalization tags, tags for accessing databases using SQL, and commonly used functions.

JavaServer Faces

JavaServer Faces technology is a user interface framework for building web applications. The main components of JavaServer Faces technology are as follows:

• A GUI component framework.

• A flexible model for rendering components in different kinds of HTML or different markup languages and technologies. A Renderer object generates the markup to render the component and converts the data stored in a model object to types that can be represented in a view.

• A standard RenderKit for generating HTML/4.01 markup.

The following features support the GUI components:

• Input validation

• Event handling

• Data conversion between model objects and components

• Managed model object creation

• Page navigation configuration

All this functionality is available using standard Java APIs and XML-based configuration files.

Java Message Service API

The Java Message Service (JMS) API is a messaging standard that allows Java EE application components to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous.

Java Transaction API

The Java Transaction API (JTA) provides a standard interface for demarcating transactions. The Java EE architecture provides a default auto commit to handle transaction commits and rollbacks. An auto commit means that any other applications that are viewing data will see the updated data after each database read or write operation. However, if your application performs two separate database access operations that depend on each other, you will want to use the JTA API to demarcate where the entire transaction, including both operations, begins, rolls back, and commits.

JavaMail API

Java EE applications use the JavaMail™ API to send email notifications. The JavaMail API has two parts: an application-level interface used by the application components to send mail, and a service provider interface. The Java EE platform includes JavaMail with a service provider that allows application components to send Internet mail.

JavaBeans Activation Framework

The JavaBeans Activation Framework (JAF) is included because JavaMail uses it. JAF provides standard services to determine the type of an arbitrary piece of data, encapsulate access to it, discover the operations available on it, and create the appropriate JavaBeans component to perform those operations.

Java API for XML Processing

The Java API for XML Processing (JAXP), part of the Java SE platform, supports the processing of XML documents using Document Object Model (DOM), Simple API for XML (SAX), and Extensible Stylesheet Language Transformations (XSLT). JAXP enables applications to parse and transform XML documents independent of a particular XML processing implementation.

JAXP also provides namespace support, which lets you work with schemas that might otherwise have naming conflicts. Designed to be flexible, JAXP lets you use any XML-compliant parser or XSL processor from within your application and supports the W3C schema. You can find information on the W3C schema at this URL: http://www.w3.org/XML/Schema.

Java API for XML Web Services (JAX-WS)

The JAX-WS specification provides support for web services that use the JAXB API for binding XML data to Java objects. The JAX-WS specification defines client APIs for accessing web services as well as techniques for implementing web service endpoints. The Web Services for J2EE specification describes the deployment of JAX-WS-based services and clients. The EJB and servlet specifications also describe aspects of such deployment. It must be possible to deploy JAX-WS-based applications using any of these deployment models.

The JAX-WS specification describes the support for message handlers that can process message requests and responses. In general, these message handlers execute in the same container and with the same privileges and execution context as the JAX-WS client or endpoint component with which they are associated. These message handlers have access to the same JNDI java:comp/env namespace as their associated component. Custom serializers and deserializers, if supported, are treated in the same way as message handlers.

Java Architecture for XML Binding (JAXB)

The Java Architecture for XML Binding (JAXB) provides a convenient way to bind an XML schema to a representation in Java language programs. JAXB can be used independently or in combination with JAX-WS, where it provides a standard data binding for web service messages. All Java EE application client containers, web containers, and EJB containers support the JAXB API.

SOAP with Attachments API for Java

The SOAP with Attachments API for Java (SAAJ) is a low-level API on which JAX-WS and JAXR depend. SAAJ enables the production and consumption of messages that conform to the SOAP 1.1 specification and SOAP with Attachments note. Most developers do not use the SAAJ API, instead using the higher-level JAX-WS API.

Java API for XML Registries

The Java API for XML Registries (JAXR) lets you access business and general-purpose registries over the web. JAXR supports the ebXML Registry and Repository standards and the emerging UDDI specifications. By using JAXR, developers can learn a single API and gain access to both of these important registry technologies.

Additionally, businesses can submit material to be shared and search for material that others have submitted. Standards groups have developed schemas for particular kinds of XML documents; two businesses might, for example, agree to use the schema for their industry's standard purchase order form. Because the schema is stored in a standard business registry, both parties can use JAXR to access it.

J2EE Connector Architecture

The J2EE Connector architecture is used by tools vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged in to any Java EE product. A resource adapter is a software component that allows Java EE application components to access and interact with the underlying resource manager of the EIS. Because a resource adapter is specific to its resource manager, typically there is a different resource adapter for each type of database or enterprise information system.

The J2EE Connector architecture also provides a performance-oriented, secure, scalable, and message-based transactional integration of Java EE-based web services with existing EISs that can be either synchronous or asynchronous. Existing applications and EISs integrated through the J2EE Connector architecture into the Java EE platform can be exposed as XML-based web services by using JAX-WS and Java EE component models. Thus JAX-WS and the J2EE Connector architecture are complementary technologies for enterprise application integration (EAI) and end-to-end business integration.

Java Database Connectivity API

The Java™ Database Connectivity (JDBC) API lets you invoke SQL commands from Java programming language methods. You use the JDBC API in an enterprise bean when you have a session bean access the database. You can also use the JDBC API from a servlet or a JSP page to access the database directly without going through an enterprise bean.

The JDBC API has two parts: an application-level interface used by the application components to access a database, and a service provider interface to attach a JDBC driver to the Java EE platform.

Java Persistence API

The Java™ Persistence API is a Java standards-based solution for persistence. Persistence uses an object-relational mapping approach to bridge the gap between an object oriented model and a relational database. Java Persistence consists of three areas:

• The Java Persistence API

• The query language

• Object/relational mapping metadata

Java Naming and Directory Interface

The Java Naming and Directory Interface™ (JNDI) provides naming and directory functionality, enabling applications to access multiple naming and directory services, including existing naming and directory services such as LDAP, NDS, DNS, and NIS. It provides applications with methods for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes. Using JNDI, a Java EE application can store and retrieve any type of named Java object, allowing Java EE applications to coexist with many legacy applications and systems.

Java EE naming services provide application clients, enterprise beans, and web components with access to a JNDI naming environment. A naming environment allows a component to be customized without the need to access or change the component's source code. A container implements the component's environment and provides it to the component as a JNDI naming context.

A Java EE component can locate its environment naming context using JNDI interfaces. A component can create a javax.naming.InitialContext object and looks up the environment naming context in InitialContext under the name java:comp/env. A component's naming environment is stored directly in the environment naming context or in any of its direct or indirect subcontexts.

A Java EE component can access named system-provided and user-defined objects. The names of system-provided objects, such as JTA UserTransaction objects, are stored in the environment naming context, java:comp/env. The Java EE platform allows a component to name user-defined objects, such as enterprise beans, environment entries, JDBC DataSource objects, and message connections. An object should be named within a subcontext of the naming environment according to the type of the object. For example, enterprise beans are named within the subcontext java:comp/env/ejb, and JDBC DataSource references in the subcontext java:comp/env/jdbc.

Java Authentication and Authorization Service

The Java Authentication and Authorization Service (JAAS) provides a way for a Java EE application to authenticate and authorize a specific user or group of users to run it.

JAAS is a Java programming language version of the standard Pluggable Authentication Module (PAM) framework, which extends the Java Platform security architecture to support user-based authorization.

Simplified Systems Integration

The Java EE platform is a platform-independent, full systems integration solution that creates an open marketplace in which every vendor can sell to every customer. Such a marketplace encourages vendors to compete, not by trying to lock customers into their technologies but instead by trying to outdo each other in providing products and services that benefit customers, such as better performance, better tools, or better customer support.

The Java EE 5 APIs enable systems and applications integration through the following:

• Unified application model across tiers with enterprise beans

• Simplified request-and-response mechanism with JSP pages and servlets

• Reliable security model with JAAS

• XML-based data interchange integration with JAXP, SAAJ, and JAX-WS

• Simplified interoperability with the J2EE Connector architecture

• Easy database connectivity with the JDBC API

• Enterprise application integration with message-driven beans and JMS, JTA, and JNDI