There is a lot of noise about the Service Oriented Architecture (SOA) and much less about how to coordinate those services or how to assemble them in a logical structure. A business has no gain if SOA is implemented and that those different services are not linked to each other or orchestrated.
The Service Orchestration concept is something that exists for a long time but it seems to me that it is not applied within a lot of organizations. One thing is to have a Service Oriented Architecture implemented for you business and the other is to really reuse and orchestrate automatically your business around those services.
Service orchestration is a concept mainly used in ESBs but I do not think it should only be used and implemented there. Business Process Management (BPM) is a technology that could orchestrate the services without any problems and some ESBs are using BPM to provide the service orchestration.
A service should be seen as a step in a business process and there you go, you are free to model your services as a unique business process that suites your needs. A business process mainly needs two kind of steps, which could be manual or automatic. A manual step is where an action is needed by someone from your company or a third party.
As I am working in document management for a longer period now, I am trying to explain to my clients that they could reuse their existing services in a newly created business process where document management is also completely integrated with the whole solution. Specifically, Alfresco has a BPM solution based on the jBPM implementation and thus document management is already integrated with BPM. The only thing to do is to integrate your existing service within your business process and benefit from it as an added value to your business.
This kind of integration does not need an ESB and I am not saying that this kind of solution is equivalent to a an ESB implementation. ESBs allows you to do much more than just service orchestration but this is just to explain that SOA is not really an added value to your business if you do not have a business process management around the services.
Showing posts with label esb. Show all posts
Showing posts with label esb. Show all posts
Monday, May 19, 2008
Friday, January 11, 2008
REST and integration ... ?
Since REST has been adopted for a long time now it seems that applications integrations are the next step. Usually I thought that integrating different applications should be done via an ESB I am sure now that it is not true.
In my opinion any decent application should have different interfaces exposed to the world. One may consider WebServices and some others REST or any other technology or interface. To keep the focus on integration I will not discuss what is better even if I think that one should use the right tool for the right job.
Once an application has a REST interface it is very easy to access that information directly from the browser for example, even if you can use it on the server side too. The information provided might be in different format such as XML or JSON. JSON is very suitable for browsers and XML is better handled by the server side.
To get the data from the application and to make the user experience much better, people are using AJAX today, and that is for sure a must have. There are a lot of Javascript frameworks out there, opensource and commercials ones, that offers AJAX functionalities and also nice widgets or UI components. It is up to everyone to chose the framework that suites the best your needs.
At the end the integration is very easy to be done. It is true that security is a weak point in such an integration but that can be solved too.
To enable REST in your application it is good to consider the integration of a server side scripting language and of a templating framework. The templates should allow you to output different formats such as XML or JSON.
In my opinion any decent application should have different interfaces exposed to the world. One may consider WebServices and some others REST or any other technology or interface. To keep the focus on integration I will not discuss what is better even if I think that one should use the right tool for the right job.
Once an application has a REST interface it is very easy to access that information directly from the browser for example, even if you can use it on the server side too. The information provided might be in different format such as XML or JSON. JSON is very suitable for browsers and XML is better handled by the server side.
To get the data from the application and to make the user experience much better, people are using AJAX today, and that is for sure a must have. There are a lot of Javascript frameworks out there, opensource and commercials ones, that offers AJAX functionalities and also nice widgets or UI components. It is up to everyone to chose the framework that suites the best your needs.
At the end the integration is very easy to be done. It is true that security is a weak point in such an integration but that can be solved too.
To enable REST in your application it is good to consider the integration of a server side scripting language and of a templating framework. The templates should allow you to output different formats such as XML or JSON.
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
