I'm currently developing a 3G Video Portal for a carrier's user community, the solution is based on JSLEE and I'm using Spring WebFlow to create the user navigation flows. I like the activity queueing concept of JSLEE and the implementation of the Video Portal has been straightforward. Sometimes I have the feeling that there are too much abstraction inside JSLEE and the standard could undertake a good deal of simplification. But when I look at the "competing" standard inside the JCP I have to admit that is no mature yet even in the upcoming release (JSR-289). The main issue I have with Sip Servlets is the programming model that is still too similar to the Http Servlets programming model, this has been a major selling point for the spec among Telcos but it's also one of the weaker point from the technical point of view.
The main difference between SipServlets and HttpServlet is in the underlying protocol. SIP is much more complex than http can be used in P2P mode by different actors User Agent Client, User Agent Server, Proxy, B2BUA. The greater difference is that http is an application protocol and you can built your own Web Application just using http while SIP is mostly a session protocol and you always need one more protocol (at least a protocol to talk to the media server) to build a compelling application.
This is why I wonder if the programming model of Sip Servlets, still too similar to the Http protocol, is appropriate and really ease development of applications like my 3G Video Portal. Sip Servlets should move towards a multi-protocol approach taking full advantage by queueing and lock-free concurrency introduced in Java5.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment