I took some time to read this book and I do not think I lost my so "precious" time. I would say that the book is not intended for Java beginners but more for people with a good technical background and especially with at least, some knowledge of the Java Enterprise world. Never the less, if you are not a specialist, just like I am not one, you could still read the book and you could learn a lot of new stuff.
Indeed, the book is taking you from the beginning and tries to lead you through different technologies like Java Messaging service (JMS), Enterprise Java Beans (EJB), WebServices (WS) and a few more. The author is clearly explaining how to use those different technologies within an Enterprise Service Bus (ESB) and how to implement it using the Java Business Integration (JBI) specification. The aim is to make you understand of how you could use any technology to achieve the Service Oriented Architecture.
A good point is that the theory is accompanied with a lot of examples based on Service Mix, which is an Apache JBI implementation. Those samples are insisting on EJB and WS, I would qualify them as realistic or real world samples. My opinion is that it could help a lot of people and companies not to rewrite their existing code but to rather reuse the code they already have and to make it working within a JBI container. You could find some explanations on how to make a real enterprise application using Service Mix and a huge assortment of useful packages like XStream or Axis. Also, on how to expose your EJBs as WSDL, which I find interesting. The samples provided in the book are accompanied with a lot of code and the whole build process. Thus even if you are not familiar with all those technologies you will be able to test and see the samples running.
All that is strengthen by the link to the Java Connector Architecture and to the point on how to exchange the information between all those different/heterogeneous systems.
While the book is correctly explaining the point of JBI, I would really appreciate to hear some words about the Service Component Architecture (SCA) and to see something about REST, but not only about WS. There are also a couple of references to VoIP and probably that a parallel could be shown with the SLEE (or JAIN SLEE) specification.
I also think there should be less explanation about WebServices and especially about the WS versioning, but some more words about XA transactions and services orchestration.
Finally, I really do recommend the book to those who are not familiar with ESBs or SOA and that want to learn something without investigating a lot on the web alone. Also, as I already mentioned to those who want to use a JBI container but have a lot of EJB and WS implementations around.
Showing posts with label jbi. Show all posts
Showing posts with label jbi. Show all posts
Wednesday, April 23, 2008
Sunday, September 2, 2007
JAIN SLEE or ESB + JBI + JCA ?
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.
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:
Posts (Atom)
Posts
