The SOA Puzzle
Thursday, January 11th 2007 | Ismael Ghalimi
As mentioned before, SOA is BPM’s enabling infrastructure, and BPM is SOA’s killer application. But what is SOA really? And how does it relate to ESB (Enterprise Service Bus)? Ask these questions to ten SOA pundits, and you’ll get ten different answers. Well, I’m no SOA pundit, so don’t take my answer for gospel, but here is how Intalio is going about building its own SOA stack out of freely available Open Source pieces. If anything, it might give you some ideas for building yours down the road.
Enterprise Service Bus
The ESB will be the core component of your Service Oriented Architecture, so you want to get this one right. An ESB is a piece of middleware, and as such it’s notoriously difficult to characterize. Some see it as an intermediation interface, others as a full fledged platform. Some like it to be totally distributed, others prefer to manage it centrally with dedicated servers. What makes it even more maddening is that in some instances, there is no way to tell whether a given ESB is one or the other, for it can be both depending on how you look at it. So let’s try to simplify the problem: if you’re narrowing your search for the perfect ESB to commercially-supported Open Source offerings, you should ask yourself whether you want your ESB to be more Java centric than XML centric. If you do, I would go for one that is based on Sun’s Java Business Interface (JBI), and ServiceMix (supported by LogicBlaze) is as good as it gets. If you do not, I would take a look at Mule (supported by MuleSource). And if you cannot make up your mind, I would use both side by side. This is what we are doing at Intalio, and it seems to be the only way to satisfy the demands of all our customers.
Web Services Stack
If you want to make SOA part of your product, you will need to hook it up to your existing components. For example, you would like to invoke a Web service from a process through the ESB. For this, you will need some kind of Web services stack that will provide support for basic protocols such as SOAP, deal with its multiple versions (v1.1 and v1.2), handle attachments, supports WSDL’s multiple styles (RPC/encoded, RPC/literal, Document/encoded, Document/literal), etc. All this is very boring of course, so you certainly do not want to do it yourself. Instead, you might want to consider the excellent Apache Axis (supported by WSO2), and go on with your life. There are some alternatives of course, but this one has been picked by both JBoss and IBM WebSphere, and when these two competitors agree on something, you can be sure that it’s pretty good.
Web Services Application Server
Once you get your Web services stack and your ESB running, you can expose your existing components as Web services. That’s great. But what if you have to build new components? Well, you have two options there. Option number one: use a good old J2EE application server, and write some business logic packaged as beans or servlets, like we did for our BPEL4People task manager. For this purpose, we are using IBM WebSphere Application Server Community Edition (WAS CE), which is not much more than a commercially-supported version of Apache Geronimo. Option number two: use a dedicated Web services application server. This option should be of interest if you’re looking for a more lightweight solution, and one of the best implementations has been developed by WSO2, was previously known as WSO2 Tungsten, has been aptly renamed WSO2 Web Services Application Server, and is available under the Apache Software License.
Service Registry
Once you get all these neat little Web services, it would be a good idea to register them onto some kind of registry, so that they could be discovered by others for reuse purposes. On this front, you need something like CentraSite, a standards-based SOA registry and repository jointly developed by Fujitsu and Software AG. It provides advanced search capabilities leveraging UDDI 3.0 and metadata models, comes with a neat report generator, and provides two sets of user interfaces, one AJAX-based for Web browsers, and another implemented as a set of Eclipse plugins.
Administration Portal
Last but not least, you will need a way to manage all your services, for you will soon realize that you have a lot more of them that you thought. For this, just keep in mind that Web services are nothing more than tiny little pieces of IT, and there is no reason why you could not manage them the same way you manage any other pieces of your IT landscape, through some kind of system management portal that gives you tools for inventory, monitoring, charting, event correlation, root cause analysis, alerting, and control. Well, that’s good news really, because an Open Source system management portal has been released recently. It’s called Hyperic, and it’s sexy as this kind of thing can be. To make things even better, it has already been integrated with Mule, which does not hurt if you’re planning to use it as your ESB.
So here we are, all major components of our SOA are available through commercially-supported Open Source offerings, and we are working with our customers and partners to fit them all together into the underlying infrastructure that will make our BPMS rise and shine. If that sounds like fun, come join us and add your piece to the puzzle!
Entry filed under: BPM 2.0, SOA
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

















[…] An example of such a stack is the one currently developed by Intalio around our Business Process Management System (BPMS). Over time, we realized that our customers needed more than just a process design tool, a process execution engine, and a workflow framework. Some wanted integration with a modern Enterprise Content Management (ECM) system in order to support scenarios where BPM and ECM intersect, others wanted to get the functionality offered by a complete Enterprise Service Bus (ESB) as a way to build their own SOA puzzle. […]
[…] The SOA Puzzle […]
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment