I was looking what SLEE (Service Logic Execution Environment) or in the java world JAIN SLEE could offer in a telephony world. I am working on an open source telephony application called Svarog (http://sourceforge.net/projects/svarog/) based on Asterisk PBX (http://www.asterisk.org/) and I wanted to see how I could improve it in a next step.
Well, there is the SLEE specification and a java open source implementation sponsored by RedHat and JBoss called Mobicents (http://www.mobicents.org-a.googlepages.com/index.html). I am not an expert in telephony nor in SLEE specification, but what I understood is that this is something to do with EDA (Event Driven Architecture). We also have a reference implementation of SLEE, which is done by OpenCloud (http://www.opencloud.com/ ). And SLEE is often considered to be in telephony what EJB is in JEE.
SLEE is also "service" oriented where it has its own SBB (Service Building Blocks) which are resource adaptors. It does not seem to be specified for the telephony world only and it should be possible to inlcude any kind of services into the SLEE environment. It is specific because it offers a scalable, robust, reliable and transacted environment for "real time" applications. Probably that is why it is tight to the telephony world.
If this is not wrong, what I said till there, I see no reason why this kind of environment could not be setup using some open source projects such as ESB (Enterprise Service Bus), JMS (Java Messaging Service), rule engines and workflow engines. What I do think is that SLEE is maybe more complicated than setting up all those different projects. There is JBI (Java Business Integration) which already has several implementations in the open source community and IBM has its own standard SCA (Service Component Architecture) which seems to be adapted as well and which should not be an opponent to the JBI specification. I think that the Springframework could offer a base for writing something "ala" SLEE and to get a good support for Java Transactions and other services needed to write a scalable, robust, reliable and transacted environment. I mentioned JMS but I know it is not event based, but could be used and I think is used in some EDA. I forget to say that there is also JCA (JEE Connector Architecture) which is here in purpose to be used for resource adapters.
Well, the point is that it seems Mobicents cannot be used without the JBoss Application Server, and I think SLEE specifies that the implementation should not be tight to JEE.
We do not have specifications for ESB but we do have for JBI, which are also used in ESB such as Mule or ServiceMix. Both of them offers integrations with workflow and rule engines and are based on events ... so, how is SLEE different in it? In my opinion, SLEE could be a standard way to do ESB.
To conclude, an ESB coupled with JCA with a good support for transactions is really a god environment for a real time event based driven architecture, could be the thing that is needed for a telecom service platform.
Subscribe to:
Post Comments (Atom)
Posts
6 comments:
Daniel, good post.
Burr Sutter who manages the JBoss SOA product pointed me to it.
I will agree that JSLEE can be represented as an extension to Java EE.
JSLEE can also be seen as a high-performance real-time task oriented ESB. This point of view is shared by Mark Little, who manages the JBoss ESB project.
Mobicents is not directly dependent on Java EE, but it does leverage a lot of lower level JBoss building blocks. Most significantly its microkernel architecture and lower level services such as naming, clustering, management, transactions.
Extending JCA in a direction supporting real-time session protocols such as SIP, RTP, XMPP and others required by telco applications will be a worthwhile effort.
EJBs can also come close to SBBs if there was a way for stateful EJBs to attach themselves to multiple related activities (SIP Dialog, RTP session, HTTP Sessoin). Another requirement would be the ability for EJBs to communicate among each other asynchronously via lightweight transaction aware events.
It would be great to see Java EE 6 enabling profiles for vertical markets such as telco. That would allow JSLEE 2.0 to enhance a flexible POJO based platform rather than specifying similar APIs for a different carrier-grade platform.
Ivelin Ivanov
Hello Ivelin,
thank you for sharing your thoughts with me.
First of all, I am really glad that people from JBoss found and read my blog.
Do you plan to remove the dependencies on JBoss from Mobicents ? I ask this because I planned to use mobicents and at the end I wanted to see how good would be that idea on using different components like ESB, JCA, JBI ... because SLEE is too heavy in my opinion.
I agree totally with your comment about the EJB improvements and for sure this can be done in a non standard way but it would be great to have it standardized. Actually, I think adding some AOP functionalities would help to do that in a first step. What about adding some kind of interceptors to SLEE if there are none?
I also need to bind it to an HttpSession to use the "comet" ajax for example. So I have a hack with DWR but that's not nice. Well, the problem with HttpSessions is that it is not specified how a container should manage the sessions, so the sessions are not managed in the same way on each app/web server.
And yes, using POJOs would help a lot, I think. That is one of the points I did not want to go with SLEE immediately. Spring, Transactions, Mule, AOP at least interceptors ... give me a more flexible system right now.
Regarding the profiles I think that something like that failed in JME. And I am not sure of how this will really work in JEE.
Regards,
Daniel
Hey Daniel,
I was just searching for JAIN SLEE related links in the web and found your blog entry.
It's really interesting to read. Your analysis is comparable to those I hear when talking to people. I'm with BEA and we offer a JEE/SIP Servlet application server being a firm believer that this combination brings at least as much value to the telecommunication industry as alternative approaches like JAIN SLEE would bring.
The architecture scenario positioned as an alternative to the JAIN SLEE environment - but being composed from enterprise technologies - reads like being state of the art. Through the enterprise building blocks it is very easy to integrate such an architecture into existing IT and enterprise architectures - leveraging standards. Your approach reads more like the enterprise environment extends its reach towards the network - whereas JAIN SLEE assumes the other way around.
All the best, Michael.
I think that the JAIN SLEE is suffering with the same thing that EJB v2.1: the complexity. I`ve tested many examples in the web, none of them works...
Sandra, I can only agree. But I am sure the JBoss team is doing a good job and soon we will have something adopted and usable by a larger crowd. I like the JSLEE approach and especially the SBBs and real time processing but however I do think today that all of that could fit nicely in a space based architecture either (JavaSpaces, I also wrote some posts about that).
you may want to look at vtd-xml, the latest and most advanced xml processing api that is a must have for high perfomrance ESB
vtd-xml
Post a Comment