| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
Communication technologies provide mechanisms for communication between clients and servers and between collaborating objects hosted by different servers. The J2EE specification requires support for the following types of communication technologies:
The following sections give an overview of J2EE platform communication technologies. How these communication technologies are used by clients is discussed in Chapter 3.
Internet protocols define the standards by which the different pieces of the J2EE platform communicate with each other and with remote entities. The J2EE platform supports the following Internet protocols:
- TCP/IP--Transport Control Protocol over Internet Protocol. These two protocols provide for the reliable delivery of streams of data from one host to another. Internet Protocol (IP), the basic protocol of the Internet, enables the unreliable delivery of individual packets from one host to another. IP makes no guarantees about whether or not the packet will be delivered, how long it will take, or if multiple packets will arrive in the order they were sent. The Transport Control Protocol (TCP) adds the notions of connection and reliability.
- HTTP 1.0--Hypertext Transfer Protocol. The Internet protocol used to fetch hypertext objects from remote hosts. HTTP messages consist of requests from client to server and responses from server to client.
- SSL 3.0--Secure Socket Layer. A security protocol that provides privacy over the Internet. The protocol allows client-server applications to communicate in a way that cannot be eavesdropped or tampered with. Servers are always authenticated and clients are optionally authenticated.
Remote Method Invocation (RMI) is a set of APIs that allow developers to build distributed applications in the Java programming language. RMI uses Java language interfaces to define remote objects and a combination of Java serialization technology and the Java Remote Method Protocol (JRMP) to turn local method invocations into remote method invocations. The J2EE platform supports the JRMP protocol, the transport mechanism for communication between objects in the Java language in different address spaces.
Object Management Group (OMG) protocols allow objects hosted by the J2EE platform to access remote objects developed using the OMG's Common Object Request Broker Architecture (CORBA) technologies and vice versa. CORBA objects are defined using the Interface Definition Language (IDL). An Application Component Provider defines the interface of a remote object in IDL and then uses an IDL compiler to generate client and server stubs that connect object implementations to an Object Request Broker (ORB), a library that enables CORBA objects to locate and communicate with one another. ORBs communicate with each other using the Internet Inter-ORB Protocol (IIOP). The OMG technologies required by the J2EE platform are: Java IDL and RMI-IIOP.
2.5.3.1 Java IDL
Java IDL allows Java clients to invoke operations on CORBA objects that have been defined using IDL and implemented in any language with a CORBA mapping. Java IDL is part of the J2SE platform. It consists of a CORBA API and ORB. An Application Component Provider uses the idlj IDL compiler to generate a Java client stub for a CORBA object defined in IDL. The Java client is linked with the stub and uses the CORBA API to access the CORBA object.
2.5.3.2 RMI-IIOP
RMI-IIOP is an implementation of the RMI API over IIOP. RMI-IIOP allows Application Component Providers to write remote interfaces in the Java programming language. The remote interface can be converted to IDL and implemented in any other language that is supported by an OMG mapping and an ORB for that language. Clients and servers can be written in any language using IDL derived from the RMI interfaces. When remote interfaces are defined as Java RMI interfaces, RMI over IIOP provides interoperability with CORBA objects implemented in any language. RMI-IIOP contains:
| - | Client and server stubs that work with any ORB. |
| - | An IDL file compatible with the RMI interface. To create a C++ server object, an Application Component Provider would use an IDL compiler to produce the server stub and skeleton for the server object. |
Application clients must use RMI-IIOP to communicate with enterprise beans.
Messaging technologies provide a way to asynchronously send and receive messages. The Java Message Service provides an interface for handling asynchronous requests, reports, or events that are consumed by enterprise applications. JMS messages are used to coordinate these applications. The JavaMail API provides an interface for sending and receiving messages intended for users. Although either API can be used for asynchronous notification, JMS is preferred when speed and reliability are a primary requirement.
2.5.4.1 Java Message Service
The Java Message Service (JMS) is an API for using enterprise messaging systems such as IBM MQ Series and TIBCO Rendezvous. JMS messages contain well-defined information that describe specific business actions. Through the exchange of these messages, applications track the progress of the enterprise. The JMS supports both point-to-point and publish-subscribe styles of messaging.
In point-to-point messaging, a client sends a message to the message queue of another client. Often a client will have all its messages delivered to a single queue. Most queues are created administratively and are treated as static resources by their clients.
In publish-subscribe messaging, clients publish messages to, and subscribe to messages from, well-known nodes in a content-based hierarchy called topics. A topic can be thought of as a message broker that gathers and distributes messages addressed to it. By relying on the topic as an intermediary, message publishers are independent of subscribers and vice versa. The topic automatically adapts as both publishers and subscribers come and go. Publishers and subscribers are active when the objects that represent them exist. JMS also supports the optional durability of subscribers that "remember" the existence of the subscribers while they are inactive.
The JMS API definitions must be included in a J2EE product, but a product is not required to include an implementation of the JMS ConnectionFactory and Destination objects. These are the objects used by an application to access a JMS service provider. A future version of the J2EE platform will require that a J2EE product provide support for both JMS point-to-point and publish-subscribe messaging, and thus must make those facilities available using the ConnectionFactory and Destination APIs.
2.5.4.2 JavaMail
The JavaMailTM API provides a set of abstract classes and interfaces that comprise an electronic mail system. The abstract classes and interfaces support many different implementations of message stores, formats, and transports. Many simple applications will only need to interact with the messaging system through these base classes and interfaces.
The abstract classes in JavaMail can be subclassed to provide new protocols and add functionality when necessary. In addition, JavaMail includes concrete subclasses that implement widely used Internet mail protocols and conform to specifications RFC822 and RFC2045. They are ready to be used in application development. Developers can subclass JavaMail classes to provide the implementations of particular messaging systems, such as IMAP4, POP3, and SMTP.
The JavaBeans Activation Framework (JAF) integrates support for MIME data types into the Java platform. JavaBeans components can be specified for operating on MIME data, such as viewing or editing the data. The JAF also provides a mechanism to map filename extensions to MIME types.
The JAF is used by JavaMail to handle the data included in email messages; typical applications will not need to use the JAF directly, although applications making sophisticated use of email may need it.
Data formats define the types of data that can be exchanged between components. The J2EE platform requires support for the following data formats:
- HTML 3.2: The markup language used to define hypertext documents accessible over the Internet. HTML enables the embedding of images, sounds, video streams, form fields, references to other HTML documents and basic text formatting. HTML documents have a globally unique location and can link to one another.
- Image files: The J2EE platform supports two formats for image files: GIF (Graphics Interchange Format), a protocol for the online transmission and interchange of raster graphic data, and JPEG (Joint Photographic Experts Group), a standard for compressing gray-scale or color still images.
- JAR file: A platform-independent file format that permits many files to be aggregated into one file.
- Class file: The format of a compiled Java file as specified in the Java Virtual Machine specification. Each class file contains one Java language type--either a class or an interface--and consists of a stream of 8-bit bytes.
- XML: A text-based markup language that allows you to define the markup needed to identify the data and text in XML documents. XML will be supported in a future version of the J2EE specification. As with HTML, you identify data using tags. But unlike HTML, XML tags describe the data, rather than the format for displaying it. In the same way that you define the field names for a data structure, you are free to use any XML tags that make sense for a given application. When multiple applications use the same XML data, they have to agree on the tag names they intend to use.