While the JAIN APIs still play only a minor role on Sun's Java Web site, the JAIN initiative is getting stronger. The JAIN technologies (Java APIs for Integrated Networks) have the potential to radically change the existing service architecture for communications service providers.

Following the link "Other Java Technologies/JAIN APIs" from Sun's Java Web site, you'll probably find your way to a completely unknown world: Java technologies for telecommunication products and services. This article introduces you to the basics of JAIN and then explores JAIN/SLEE in greater detail. By the way, SLEE means Service Logic Execution environment and is abbreviated to JAIN/SLEE or JSLEE.

Motivation
The service architectures of many telecommunications service providers have become a lot more complex over the past few years. This is because many providers merged, or new technologies like GPRS or W-CDMA were or will be introduced. These architectures can be described as highly vertically integrated and heterogeneous. They miss common interfaces, based on standards. Instead, most architectures are quite proprietary. This makes it hard to introduce new services because the complexity of the overall architecture is augmented with each new feature that is added to the communications network. Services like the Multimedia Messaging Service (MMS) were introduced last year and again new protocols and new network elements had to be integrated with the existing networks. Managing the communications network as a whole is getting harder and harder.

The JAIN initiative tries to break these vertical structures and replace them with horizontal ones. Proprietary interfaces between the network components are replaced with standards-based interfaces. The JAIN APIs are specified using the Java Community Process, which allows everybody to contribute to the specifications. These companies include IBM, Motorola, NTT, and Vodafone.

JAIN and Other Java Technologies
As JAIN is a new Java technology for most developers, it's interesting to explore how it relates to other existing Java technologies such as the Java 2 Micro Edition (J2ME), the Standard Edition (J2SE), or the Enterprise Edition (J2EE).

Java technologies can be divided into server-side and client-side technologies (see Figure 1). J2SE and J2ME target the client side. While J2ME targets mobile and resource-constrained devices, J2SE targets standard desktop systems.

On the server side, J2EE technologies target enterprise systems and JAIN technologies target communications systems. Based on the JAIN and J2EE specifications, communications services running in a SLEE may communicate directly with existing enterprise systems using RMI or any other protocol that the J2EE server exposes. In contrast, if an enterprise service needs to trigger some functionality exposed by a telecommunications service, it needs to communicate with a SLEE's resource adapter. The resource adapter then maps the requests into SLEE events and routes these events to the services.

Applications running on a mobile device need not necessarily use J2ME to access functionality provided by a server. For example, for MMS, the MMS User Agent on the client device is typically not implemented in Java.

Let's compare this to a desktop system. A client Web browser can also be implemented in any programming language. It will be compatible with the services offered on the server, as long as the protocols such as HTTP are supported.

Unlike J2SE, J2ME does not provide the functionality to connect directly to EJBs. This is because RMI is not supported on resource-constrained mobile devices. To exchange information with external systems, mobile devices supporting J2ME may use HTTP connections.

The JAIN APIs
There are currently 36 entries for JAIN technologies on the JCP Web site. This number is more than we can cover in this short article, but we will categorize those specifications in general and then focus on the JAIN/SLEE specification.

JAIN technology enables the integration of Internet and Intelligent Network (IN) protocols, which are referred to as Integrated Networks. JAIN APIs can be divided into Java application interfaces and Java application containers. Table 1 provides an overview of some related JAIN technologies.

The Java application interfaces for communications map the telecommunication protocols for the Java programming language. In contrast, the Java application containers for communications provide a standard execution environment for telecommunication services. These services typically use the Java application interfaces for communications via resource adapters.

Intelligent Networks are used in telecommunications systems. For example, call management for voice is done via the SS7 protocol. An intelligent network is also a service-independent network. The intelligence is not in the switch that connects to calling partners but in an external computer node, which may be distributed throughout the entire network. Because of this, Intelligent Networks allow a fast and efficient development of new services.

A protocol that's currently popular is SIP because it enables VoIP gateways; right now we can see that VoIP is beginning to change the telecommunications landscape radically. To talk "SIP," JAIN offers you the JAIN SIP 1.1 APIs as part of the Java APIs for Communications. SIP is an IETF protocol for IP-based communication. Using SIP, you can build your own SIP services like a SIP gateway, which is needed to create and manage the connections.

The Java Application Containers for Communications include only two specifications: SIP servlets and JAIN/SLEE. SIP servlets provide support for SIP based on the well-known Java servlets standard. The JAIN/SLEE technology is a container for telecommunications services and provides a common runtime environment for those services. The specification went final in March 2004 and can be downloaded from the JCP home page together with the reference implementation and the TCK.

Why We Need a New Technology...
Communications systems are typically event-driven, asynchronous systems. In contrast, enterprise systems typically use direct method invocations. An existing enterprise architecture is defined by the Enterprise JavaBeans specification. The SLEE specification specifies an asynchronous, event-driven communications architecture that targets communications systems specifically. Table 2 provides a high-level overview of the different requirements of enterprise and communications systems.

As shown in Table 2, there are substantial differences between communications and enterprise systems. The EJB specification meets the requirements of enterprise systems. The SLEE now meets the requirements of today's communication systems.

Although existing J2EE containers also support asynchronous event processing (JMS), these containers were not designed for it. A SLEE, on the other hand, was specifically designed for high-frequency telecommunications systems and is completely asynchronous. Thus, a SLEE fulfills the requirements of communications systems far better than any implementation on top of an EJB container.

Service Logic Execution Environment
The Service Logic Execution Environment (SLEE) API Specification defines an application framework for the development of portable telecommunication services. It was specified under the Java Community Process (JCP) as Java Specification Request (JSR) 22. The final approval ballot accepted the specification on February 17, 2004, and it went final. The specification is led by David Ferry from Open Cloud and Swee Lim from Sun Microsystems. In addition to the companies that the specification leads belong to, the expert group for this JSR includes companies like Siemens AG, IBM, Motorola, and NTT Corporation.

The SLEE reference implementation was built by Open Cloud, New Zealand. Open Cloud also created the reference implementation for JSLEE and sells an implementation of the SLEE that's not built on top of the EJB architecture (as the reference implementation is). Their product is called Open Cloud Rhino.

The four basic elements of the SLEE are resource adapters, events, activity contexts, and the runtime environment, which hosts the SBB Objects. Figure 2 shows the relationship between these elements.

The resource adapters are responsible for communicating with the external network protocols. They can send and receive events. Upon receipt of an event generated in the external network, they submit this event to the activity context as event objects. The SBB located within the SLEE runtime environment has interfaces to the activity contexts. The activity contexts are used to deliver these events to the SBBs. As resource adapters can communicate bidirectionally, they can also emit events to the native protocol stack. Such events could be fired by SBB objects running within the SLEE that responds to incoming requests.

The activity context is a logical entity within the SLEE that receives and routes the events to the SBB components. The routing is exactly performed by the event router, which is part of the SLEE. Events may be duplicated and routed to several SBB components.

Resource Adapters
Resource adapters communicate with external systems to the SLEE, e.g., network devices, protocol stacks, directories, or databases. According to the SLEE architecture, a resource adapter is a vendor-specific implementation of a resource adapter type. An instance of a resource adapter within the SLEE is called a resource adapter entity.

The resource adapter type declares all event types that may be fired and all activities that the adapter introduces. When a resource adapter passes an event to the SLEE, it must provide the event object, the event type, and an activity. The specification does not state how this information is passed to the SLEE. This API is up to the implementor of the specification. Because of this lack of clarity, a new JSR that should clearly define a Resource Adapter Framework was introduced in March 2004.

Events
Events objects carry information from one entity within the SLEE to another. Only SBB entities can both consume and produce events, while other entities such as resource adapters, the SLEE itself, and SLEE facilities can only produce events.

Each event is represented by an event object (subclass of java.lang.Object) and an event type. The event type determines how the SLEE will route the event, e.g., which SBB objects will receive the event to their event handling methods.

For each event that an SBB fires, the developer needs to specify an abstract fire event method. This method is implemented by the SLEE. SBB entities receive events from attached activity contexts. In case of an initial event, the SLEE first creates an SBB object and then routes the event to the SBB.

Activity Context and Co
The activity-related classes consist of the two logical entities, activity and activity context, and their Java object representations, activity objects and activity context interface object.

An activity represents a related stream of events. The Java representation of this logical entity is the activity object, which is created by either resource adapter entities or SLEE facilities. An example of an activity object is the JccCall Activity object. It's part of the Java Call Control APIs and represents a phone call.

An activity context represents the underlying activity within the SLEE and also holds shareable attributes that SBB entities want to share. The SBB objects can access the activity contexts through the activity context interface object.

An SBB can either use the generic activity context interface or extend this interface and define additional attributes that it wants to share with other objects.

The activity objects are typically generated by network events. The resource adapters listen to these events and create the appropriate activity objects. These objects are placed in the activity context of the SLEE. The SLEE is now responsible for the delivery of the generated events to the SBB objects. Vice versa, an SBB object can access the activity context interface to get access to the current activity object, e.g., a JccCall Activity Object. It can then fire events on this object, which will be delivered back to the resource adapters and to the underlying network.

To get access to an activity object, the SBB developer typically accesses the activity context interface, which is automatically available within every event handling method of the SBB abstract class.

Runtime Environment and SBB Abstract Class
According to the specification, the SLEE runtime environment must make some APIs available to the SBB components at runtime. Only a minimal runtime environment is specified, leaving it up to the implementor to provide additional functionality.

Currently, the SLEE must make only the following APIs available to instances of SBB components: Java 2 Platform, Standard Edition, v1.3 APIs; JNDI 1.2 Standard Extensions; JSXP 1.0; and JDBC 2.0 Standard Extension (support for row sets only). As in the Enterprise JavaBeans Specification, the SLEE must not allow components to access the local file system. Yet, an SBB may open a socket connection or queue a print job.

The SBB abstract class is part of the SBB component (which also includes the local interfaces and the SBB deployment descriptor) and contains the event-processing logic, which has to be added by the SBB developer. The SBB developer implements an SBB abstract class for every SBB component. The runtime environment is responsible for creating the pooled SBB instances from these abstract classes. This process can be compared to the creation of an EJB component. As with EJB, the runtime environment will be responsible for implementing certain abstract methods and for creating instances that process incoming events.

Each SBB abstract class implements the javax.slee.Sbb interface and must be defined public and abstract. The concrete methods contain the application logic of the component, while the abstract methods deal with firing events, container-managed persistence (CMP), child relationship management, profile CMP methods, and accessing the specific activity context. The abstract methods are implemented by the SLEE. It uses introspection and data from the deployment descriptors to create this specific code.

Conclusion
The JAIN initiative certainly opens the telecommunications world for the Java programming language. Presently, though, some APIs for telecommunications APIs are still missing (e.g., MM1 for multimedia messaging), which means that the developer has to implement these APIs. Further, the interfaces between these protocols and the SLEE (resource adaptors) is not yet specified in the current JSLEE specification, which makes it almost impossible for third-party resource adapter vendors to enter the market (and actually create one).

Yet the JAIN Days held recently in Munich at Sun Microsystems in Germany allow a positive conclusion. An active community is evolving, especially around SIP, and the mentioned problems with the Resource Adapter Framework were transformed into a new JSR that should fix this problem. International telecommunications companies such as Vodafone and NTT DoCoMo are watching carefully and some have already been successful with some JAIN/SLEE-based service implementations.

Resources

• Figure 1
• Figure 2
• Table 1
• Table 2