Programming model vs Connectivity or SIP Servlet vs JSLEE

Confession: I like the SIP Servlet way of doing things!

I will try to list some of the reasons and my arguments supporting my choice. Let's see if I succeed ...



First of all: Programming model.
OK, I admit that I like the SIP Servlet programming model a lot. It's specified in JSR-116 and JSR-289 which is due to release in Nov 2007 which means it took less than 2 years to complete. Not that fast, but still quite OK. Why do I like it? My background as a J2EE developer and architect is of course quite influential. I like the HTTP Servlet programming model. It's easy to understand and implement and the same applies to SIP Servlets. The threshold is low for beginners, especially if they are used to HTTP Servlet programming. When you write simple applications, they are really easy to develop and maintain, an important aspect in modern software development. When the applications grow they will of course be more complicated. For really advanced applications, the model can get in the way since there are a lot of events happening and you need to remember in which order they occur. It would not be too bad with an even higher abstraction layer above SIP Servlets. How that should look like is another question ...


When I get into these kind of problems I usually move my application into Spring and use the SIP Servlet as an adapter. I honestly don't think it's so much the SIP Servlet model as my own ability writing clear understandable code. Spring gives me the inherent support and is guiding me in creating code that is beautiful in the same way as it helps J2EE getting better.





Support for the SIP Servlet programming model has been growing lately and now all the major vendors have support for SIP in their application servers or it is in their road maps. This includes IBM, Oracle, Sun, Ericsson, Ubiquity and others.



Secondly: Convergence with existing JEE environment
In the spec it is defined how a SIP Servlet should work in conjunction with HTTP Servlets and EJBs. This allows for a converged standards based container. It basically just adds another container to the plethora of containers available today in a J2EE server. Since the spec is so similar to the existing servlets it is very easy to integrate it with existing enterprise Java applications or any WebService for that matter.



Thirdly: Separation of connectivity from programming model
Connectivity is an important part of any telecom application. SIP Servlets and especially the container hosting the SIP Servlet, in this case BEA WLSS, has a number of standard ways to connect to various sources. These methods of connecting to resources are not dependent on the programming model as such and they are independent of the programming model. The main advantage is that it enables the developer to select the best programming model for the needs at hand, the best connectivity standard for the task and thus leads to an open and flexible non-vendor lock-in solution.


For example I can create a SIP Servlet that sends an email for every SIP Message received. I create my SIP Servlet and then uses Java Mail to create and send the mail. This is a standard implemented by WebLogic Server.


Another example is that while setting up a call I can check the caller against a black-list exposed as a web service. Once the initial Invite is received a call-out to the web service is done. Since I have the WSDL a client stub is created in BEA Workshop (or any other modern IDE) with a few clicks.

Final example is the opposite, exposing SIP presence information through a web service. A web page wants to display the current presence information for a specific user. A SIP Servlet is created and then exposed as a web service. The Web page invokes the web service and the SIP Servlet gets the presence information and returns it to the Web page for display. With BEA WLSS this is done with a few clicks and the SIP Servlet is exposed as a web service.



Fourthly: Standards based
SIP Servlets are standardized in JSR-116, JSR-289 and then there is a Media Server API being standardized in JSR-309. All other connectivity methods are also standardized in JCP or elsewhere. JSLEE have JSR-240 and standardization of the resource adapter interface is not yet done.



Fifthly: Inter and Intra Container Service Orchestration
This is actually not an argument for SIP Servlets in general, more for BEA WLSS since we are partnering with Convergin. Through Convergin Accolade WCS in combination with BEA WLSS a customer gets a complete migration path from today's service execution to tomorrow's All-IP based services. Services can be developed today using tomorrow's technology and be exposed to legacy, pre-IMS and IMS networks. The same applies for existing legacy services that can be exposed through legacy adaptor capabilities of Convergin Accolade WCS. In conjunction with the exposure of services to different networks, we are also able to do advanced Service Capability Interaction Management, SCIM, where blending SIP with IN/SS7 and SOA services into a complete complex service adds yet an advantage. This is not part of the SIP Servlet spec, but is possible through using the SIP protocol in combination with proprietary solutions in the case of SCIM. IM-SSF is standardized through 3GPP.



Sixthly: All-IP and IMS
If you are an operator and have an All-IP and/or IMS strategy it feels quite natural to select an execution environment based on the programming model, maturity of container, existing installed base etc. Then the SIP Servlet spec fits very well into an All-IP strategy since it features all best-in breed attributes and with a clear path towards IP-based services. With a combination of BEA WLSS and Convergin SCIM we can offer a very fast, low latency, fast-time-to-market through efficient programming models and tools, a complete SOA vision and a broad range of partners. For more info on the BEA and Convergin cooperation please read this press-release: http://www.convergin.com/show_flashpr.php?docindex=pressdocs/pr18_20061207.swf



Well, enough said on this topic. Now you know why I like the SIP Servlet standard and my current understanding. Obviously I may have misunderstood things or missed important aspects of other technologies. Please don't hesitate to comment on that :-) As you also may have noticed I haven't talked directly about JAIN SLEE in this post. The main reason being that I don't want to talk about something I don't know as well as I know SIp Servlets. However, the arguments for why I like SIP Servlets should be understood in the context of JAIN SLEE and my arguments in this post are thought of being indicative for why SIP Servlets have advantages in these areas.