J2EE Technologies
All J2EE application servers must provide containers to house J2EE components. The role of the container is to provide a component with the resources it needs to operate and a runtime within which to execute. While doing this it must also provide a degree of protection (security) to the application host.
Containers provide a number of services for a component. These services include:
Lifecycle management
Threading
Security
Transaction management
Communication with other components
J2EE containers must provide components with certain standard services. Yesterday, you were introduced to some of these services; today, you will explore them in a little more detail and see how they work in conjunction with J2EE components.
Hypertext Transfer Protocol (HTTP)
A WorldWide Web Consortium (W3C) specification defines HTTP 1.1 to support the exchange of data in a widely distributed network. Both JSPs, servlets and Web Services, allow clients to access a J2EE application through the use of HTTP.
HTTP over Secure Sockets Layer (HTTPS)
A Netscape specification defines the Secure Sockets Layer (SSL) 3.0, which is a protocol that manages the secure transfer of data over a network. HTTPS uses SSL as a sub-layer to HTTP to provide secure data transfer over the Internet.
Java Database Connectivity (JDBC)
JDBC is an API that allows you to access any tabular data source including relational databases, spreadsheets, and text files. The API allows you to connect to a database via a driver and then execute Structured Query Language (SQL) statements against that database.
Java Transaction API (JTA)
The JTA API allows you to work with transactions independently of a transaction manager. A transaction is an atomic group of operations (such as the ubiquitous banking application that debits one account and credits another). The transaction is considered complete when all operations are complete. If one operation fails, the other must roll back. A distributed system makes transaction management complex. In such a system, a transaction manager must coordinate transactions across the system.
Java Authentication and Authorization Service (JAAS)
JAAS is a supplement to the Java security framework. It provides both authorization and authentication services in a J2EE environment. (JAAS is similar to the Pluggable Authentication Module (PAM), which provides authentication in a Unix environment.) In common with the Java 2 security framework, JAAS provides access control based on code location and code signers. In addition, JAAS provides access control to a specific user or group of users.
Java API for XML Parsing (JAXP)
The JAXP API allows you to parse XML documents using the Document Object Model (DOM) or the Simple API for XML (SAX). XML is a text-based markup language that describes data. It provides a platform-independent and language-independent method for exchanging data between applications. JAXP also supports the Extensible Stylesheet Language Transformations (XSLT) language for dynamically transforming an XML document into another XML document, HTML, plain text, or some other format.
Java API for XML-based RPC (JAX-RPC)
The JAX-RPC specification defines client APIs for developing Simple Object Access Protocol (SOAP)-based portable Web Services. Developers use JAX-RPC to develop SOAP-based Web Service clients and endpoints. A Web Service endpoint is described using a Web Services Description Language (WSDL) document. JAX-RPC enables clients to invoke Web Services developed across heterogeneous platforms. Also, J2EE components can define Web Service endpoints that can be invoked by heterogeneous clients.
Java API for XML Registries (JAXR)
An XML registry is part of the infrastructure for building, deploying, and discovering Web services. There are several specifications for XML registries, including the ebXML Registry and Repository standard developed by OASIS and U.N./CEFACT (see www.ebxml.org) and the Universal Description, Discovery and Integration (UDDI) specification developed by a large consortium of vendors. JAXR provides an abstract interface to a variety of XML registries.
SOAP with Attachments API for Java (SAAJ)
The SAAJ API is used to manipulate messages conforming to the SOAP specification and SOAP with Attachments note. Originally part of JAXM (Java API for XML Messaging), SAAJ has been separated out to provide support for SOAP without mandating the use of JAXM.
Java Naming and Directory Interface (JNDI)
JNDI provides an API for working with naming and directory services. A naming service simply associates names with objects, for example, the Domain Name System (DNS) used by most Internet services to translate between domain names and IP addresses. A directory service also associates names with objects, but it also provides additional information through attributes using, for example, the Lightweight Directory Access Protocol (LDAP).
Although JNDI provides access to a wide array of naming and directory services, each service must provide a Service Provider. This is similar to JDBC and drivers, but in this instance, it is a naming or directory service and a Service Provider. For example, an LDAP directory must provide an LDAP Service Provider, which JNDI hides from you.
JavaBeans Activation Framework (JAF)
Typically, you use JAF in the context of JavaBeans (that's JavaBeans, not Enterprise JavaBeans!). However, a J2EE product must provide JAF for the JavaMail API to use MIME types. JAF allows you to send emails consisting of different MIME types and attachments.
JavaMail
The JavaMail API provides classes that allow you to work with email. Specifically, it allows you to send and receive emails by using a wide variety of protocols, including POP3, SMTP, and IMAP. Because the API uses JAF, you can create emails that conform to a large number of MIME types. For example, you can create HTML messages that contain embedded graphics or have attachments.
Java Message Service (JMS)
Messaging is the process of communication between applications or components; it does not include application to human communications, such as email. The JMS API allows you to create, send, and receive messages. Message-Driven Beans provide a means for consuming JMS messages within a J2EE environment. Typically Session and Entity beans are message producers but any Java program can produce JMS messages for delivery to an MDB.
Java Interface Definition Language (Java IDL)
Java IDL provides a way for you to access and deploy remote objects that comply with the Common Object Request Broker Architecture (CORBA) defined by the Object Management Group (OMG). IDL provides a language-independent means of defining object interfaces. The OMG provides mappings between various programming languages and IDL. A client written in any language that has an IDL binding can access objects you export using CORBA. For example, a Java client can consume objects written in other languages, such as C++, C, Smalltalk, COBOL, and Ada.
Remote Method Invocation over Internet Inter-Orb Protocol (RMI-IIOP)
RMI is a distributed object system that allows Java objects to interact with other Java objects running in a different virtual machine (usually on a remote host). In practice, you can access these remote objects almost as if they were local; you simply get a reference to the remote object and invoke its methods as if it were running in the same virtual machine.
The actual process of performing a remote method invocation utilizes client-side stubs and server-side skeletons. A client invokes a remote method by making a request on the stub, and this is forwarded to the server where the skeleton converts the request into an actual method call on the remote object. The stub marshals any arguments for the remote method into a serialized form for transfer over the network. The data is un-marshaled by the receiving skeleton, which, in turn, calls the actual service method. Any results from the method call are in turn marshaled up by the skeleton, sent to the stub to be un-marshaled and finally returned to the client.
RMI-IIOP is the transport mechanism used by stubs and skeletons for EJBs. You can also explicitly create RMI-IIOP clients and servers for your own applications by using the RMI compiler (rmic) to generate your RMI-IIOP stubs and skeletons.
You can also use RMI-IIOP as a mechanism for exposing your EJB components to CORBA clients without having to learn IDL. You can specify a flag to the RMI compiler which causes it to generate CORBA IDL on your behalf. After you have the CORBA IDL, this can be used together with an alternative language binding to create a client for the EJB that is written in another language.
Connector Architecture
The J2EE Connector Architecture allows your J2EE application to interact with Enterprise Information Systems (EIS), such as mainframe transaction processing systems, Enterprise Resource Planning (ERP) systems, and legacy non-Java applications. It does this by allowing EIS vendors to produce a resource adapter that product providers can plug into their application servers. The J2EE developer can then obtain connections to these EIS resources in a similar way to obtaining a JDBC connection.
The J2EE Connector Architecture defines a set of contracts that govern the relationship between the EIS and the application server. These contracts determine the interaction between server and EIS in terms of the management of connections, transactions, and security.