The application composition and routing mechanism developed in SIP Servlet 1.1 is vastly different from the model in SIP Servlet 1.0. The new mechanism introduces a new logical entity called an Application Router (AR). Instead of dispatching SIP requests to servlet applications as a result of complex XML files, the container uses the new AR. A common API is provided so the container can interact appropriately with the AR.

Figure 2 provides a simplified example of how the new application composition mechanism operates in SIP Servlets 1.1. The container gets a SIP request (1) as in the previous example. The SIP request is then passed to the SIP servlet container (2) for further processing. The container uses the common Application Router API to request which SIP Servlet application should get the request (3). In Figure 2, "App 1" is returned and the request is then serviced. It should be noted that the XML mappings for requests are no longer used as the primary selection mechanism. Instead, a default SIP servlet in the application is always triggered. Once App 1 has finished with the request the process is repeated (4-8) until no more applications want to make use of the SIP request. At this point the request can be routed externally (9).

The AR is an interesting concept that lets implementations be flexible in how they select and compose services (e.g., a push-to-talk service could consist of several SIP servlet applications, say conferencing, presence, and floor control). The decision as to exactly what is returned by the AR to the SIP servlet container could be very simple or based on profile information from a Home Subscriber Server (HSS) or some other data store. As long as the AR exposes the standardized API interface to the container, it's free to do what it wants when making decisions. With the new standards definition, service providers will most likely be able to tailor an AR to act in an appropriate manner based on any number of required variables. This approach provides an extremely powerful alternative to the static XML mappings provided in SIP Servlet 1.0.

It's fact that a B2BUA is the most popular form of SIP servlet application, and yet it's not all that easy to construct. It was obvious that application developers needed a helping hand to produce such functionality easily. A new B2BUA helper class has been introduced in SIP Servlets 1.1 specifically for this purpose.

A B2BUA consists of multiple protocol sessions that have to be linked to mimic a single-network entity. The B2BUA helper class provides convenient methods that enable implicit linking to take place that reduces complexity and eases the flow between linked protocol sessions in a B2BUA application. The B2BUA helper class also provides previously unavailable functionality, including the ability to send multiple SIP provisional response codes when acting as a User Agent Server (UAS). This was an important feature that suffered from limitations in SIP Servlets 1.0 that has now been addressed.

This article has highlighted the weakness of the encode-URI mechanism and the ability to specifically associate new protocol sessions with an existing application session. SIP Servlets 1.1 introduces a new "Session Targeting" feature that lets an application specify a protocol session association with an existing application session. Session Targeting is achieved by including a specialized Java annotation in applications that checks the protocol session associated with a new SIP request and makes a decision on whether to associate or create a new application session. When applied to conferencing, for example, a user dialing into a conference instance can now be part of an existing application session if required.

One of the primary benefits of the new Session Targeting over the previous Encode-URI mechanism is that it has no impact on the application composition chain. Requests containing an encoded URI are immediately directed to the correct application instance, while session-targeted requests traverse the composition path normally until they reach the appropriate application (as denoted using the Java annotation). The ability to traverse the full composition path and not skip vital steps provides a powerful protocol session association mechanism.

Convergence was a key theme introduced in SIP Servlets 1.0 and continues to be important in 1.1. As discussed, a converged HTTP and SIP container doesn't holistically fulfil the requirements of SOA/J2EE-based telecom solutions. The term "convergence" is redefined in SIP Servlets 1.1 to accommodate both a converged HTTP/SIP container and include convergence from a J2EE perspective. For example, an enterprise archive (EAR) that contains both SIP and HTTP servlets that communicate using EJB is now considered a "converged" application. This provides a true holistic definition of convergence.

A number of subtle changes were required to accommodate such a redefinition. First, the primary interface used to create and carry out SIP functions (SipFactory) is now made available via a specific Java annotation (@SipFactory) as well as from the Servlet Context (as defined in SIP Servlet 1.0). The annotation providing SIP functionality can then be used anywhere in a converged application (convergence as previously defined in this paper).

It's also important to note that a converged application can access an existing instance of an application. Each application session is uniquely identified by a key. SIP Servlets 1.1 lets a converged application access an application session using the getAppplicationSession method available via the SipSessionUtil interface. The method call lets a converged application retrieve the session using the unique application session identifier and is returned the appropriate access to a unique Application Session instance. It functions like 'SipFactory' access, so this utility is made available to the converged components of a converged application and can be injected via a specific Java annotation (@SipSessionsUtil).

Clearly, annotations and the resource injection available in Java 5 are needed by the SIP Servlet 1.1 specification. For this reason Java 5 is the mandatory supported platform.

Backwards compatibility has also been a major consideration in designing the next generation of SIP servlet containers. While every effort has been made to maintain legacy applications, there are certain areas that have been clarified in both the API and container behavior. The bottom line is that a well-behaved SIP Servlet 1.0 application can be successfully deployed in a SIP Servlet 1.1-compliant container. In all other cases some small code modifications might be required.

While this discussion isn't a definitive guide to the changes incorporated in JSR 289, it does highlight some of the primary modifications. These changes help to form a more complete picture of the technological direction of SIP servlet containers.

Conclusion
SIP servlet technology was originally created to provide an appropriate platform for rapidly creating telecommunications services and improving the application development infrastructure. It's true to say that the first generation of SIP servlets achieved its objective by establishing a sound technology platform that has seen wide adoption and a high level of implementation from both container and application developers. It's also clear that, as the technology and deployments evolved, those first-generation servlets needed to be revised to take advantage of new innovations and the insights gained by working with SIP Servlets 1.0.

SIP Servlets 1.1 will mark a new departure in telecommunications technology. The ability to provide true convergence in an application and to compose service-level constructs will provide a powerful tool that will aid Java developers and carriers for years to come. In conjunction with other new features such as B2BUA help, an API cleanup, and SIP access from a converged application, SIP servlet technology will now offer the versatility to move SIP application development to the next level.

References
• www.jcp.org/en/jsr/detail?id=116
• www.jcp.org/en/jsr/detail?id=289