Can we write a resource adapter based on sip such that a Sip Servlet application can be mechanically converted into a Slee SBB? Francesco and I were thinking about this and it appears possible. Thoughts?
indeed this sounds very interesting. I had already some intersting discussions with SIP Servlet vendors. One of them actually claimed they love the JSLEE framework and management facilities ...
One thing I ask myself is .. One strong element in SIP Servlet spec is the possibility to chain invocations. That's obviously possible in JSLEE as well (through direct invocation). However, in Servlets it's just a matter of configuration ... How shall this issue be addressed?
A separate entity coordinating / orchestrating the incoming events?
Ah, this is only important if more than one SIP Servlet is listening to incoming SIP messages (which may be not too important at this stage of discussion).
Are your referring to a feature similar to HTTP Filters? There are a lot of good examples for the HTTP case.
What are the use cases for SIP?
I refer to the SIP Servlet specification (see section 2.1 and following) that explains how initial SIP messages and subsequent SIP messages in the scope of an application should be treated. There, they talk about "rules" for message routing and how this should be applied to incoming messages. The base topic is application composition (which is another interesting topic for JAIN SLEE as well).
> Are your referring to a feature similar to HTTP
> Filters? There are a lot of good examples for the
> HTTP case.
> What are the use cases for SIP?
OK. What would be some of the practical use cases where this kind of feature would be useful and how do you see its design?
the most interesting use case is the SCIM (Service Capability Interaction Manager) defined in the 3GPP specification TS.23218 (download at http://www.3gpp.org/ftp/Specs/html-info/23218.htm, free registration required) on page 10. The SCIM is ...
[i]"in addition a specialized type of SIP Application Server, the service capability interaction manager (SCIM) which performs the role of interaction management between other application servers."[/i]
(BTW If you do not download the spec ... that's the only interesting sentence about the SCIM).
In SIP Servlet, there is a glimpse of a beginning regarding the SCIM in the standards. That's also one reason, why so many people believe that IMS and SIP Servlets belong together (not me!).
The design is an interesting question. Easiest to build - but also not very nice architecture approach - is to have a SBB which delegates requests to other SBBs. This obviously breaks the whole configuration and programming model of the SLEE - but may be feasible.
A better way to do extends the standard by having a flexible and configurable event router.
Another way may be to execute every service (a collection of SBBs) in a virtual SLEE, collect the results in the real instance and then give a consolidated answer (depending on the results calculated in the virtual instances) towards the RA / network.
However, even if this doesn't make too much sense for you, it could be an interesting effort to show that SIP Servlet can be executed inside SLEE programming model.
That was an idea Phelim mentioned as well. How would the pseudo code look like? Do we have an open source SIP servlet container to work with?
have a look on this one:
I dont think one needs a full SIP Servlet implementation to do this. For example one can translate a servlet program to use the JAIN-SIP RA and CMP fields. Incidentally, the sip servlet RI is functional -- one does not need an open source implementation to experiment with this idea.
Thanks for the pointer ( though I was aware of it ). Need to follow up there too.
mapping sip servlet to sbb is not a hard work.We can save data(including state) in cmp instead of session .And invoke interface is almost same.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.