Most Read This Week
Wireless News Desk
JAIN/SLEE: EJB for Communications
Opening the telecommunications world for Java
By: Sven Haiges
Sep. 7, 2004 12:00 AM
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.
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
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
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...
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 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.
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.
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
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
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.
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.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads