Vendors of application servers, enterprise software suites and EAI middleware each claim to offer the foundations for building an SOA. But there's a catch, as Loosely Coupled reader Brian Salzman writes in a comment posted to the site this week. I've copied the body of his comment here to keep it with my reply, along with any follow-up comments:
I've got a question for you, Phil.
I'm trying to better understand SOAs and I'm hoping you can help me out.
My understanding is, admittedly, grossly generalized, but please bear with me. The way I understand the segment is that there are three kinds of companies with realistic hopes of providing the enterprise with a SOA.
App. Server providers like IBM, BEA and Oracle
Enterprise software providers like SAP, and
Middleware providers like WebMethods, TIBCO and SeeBeyond
It seems to me that the app server providers are so married to their own platforms that they will never provide true cross-platform interoperability. And even if they could bring themselves to be platform-neutral, the marketplace would have trouble believing them.
The enterprise software providers, on the other hand, could give us a platform-neutral SOA, but they are themselves married to their own enterprise apps. This works fine if your company is an SAP shop, for example, but any company running SAP has also got a variety of other apps
in play. Will SAP's SOA play well with others? There is reason for concern.
The middleware providers, on the other hand, have made a living of being neutral in every respect. That's the theory and the market's perception at least. They do not hew to any single app server, nor do they cling to any particular enterprise suite. Middleware providers seem to me to be the logical choice to provide the SOA.
Great job on your site.
I think Brian is right in how he breaks down the vendors, except that I would add a fourth category of potential providers. But he is correct in identifying that the problem with each group is that they want to keep customers on their platforms. I feel this is as much true of the middleware vendors he cites as it is of the others they are probably worse in terms of wanting to tie people to their proprietary messaging platforms; at least if you use a J2EE vendor you are using a J2EE-based messaging infrastructure and could conceivably go to an open-source version or alternative vendor; although none of them are truly portable in that sense.
The fourth category I would add are vendors who support standards-based web services solutions. These do keep you reasonably free, except that they're all quite small, which means you have to mix-and-match several products to get a complete infrastructure; and also the standards are still being defined, so whichever vendors you pick, you'll still end up relying on some proprietary components and interoperability issues. However despite all of that I would recommend taking a look at vendors such as Systinet and Cape Clear in this category. I'm tempted to include Blue Titan in that list too, even though its products are quite closely tied to BEA's WebLogic platform for implementation. That shouldn't matter provided all its interfaces are standards-based; the beauty of an SOA is that every participating resource can be a 'black box' behind its standard interfaces, and it doesn't matter, provided it interoperates cleanly with other participants.
The short answer, then, to the question of which platform is the best foundation for your SOA is to reframe the question. Your SOA should be the platform, and the question becomes whether the applications, servers and middleware services that participate in the SOA do so in an interoperable, standards-based way. That can be very difficult to achieve if most of your resources are running on a single platform that has its own alternative, non-standards-based way of connecting them together, because:
All your developers will find it very tempting to continue doing it the native, non-standards-based way, which is probably more familiar and convenient for them; and
You'll have to go to special lengths to set up tests to check that services aren't 'cheating' by going native rather than connecting via the SOA; plus
You may well find there are compelling performance arguments for bypassing the SOA in certain application cases, especially early on and before XML acceleration and routing becomes more of a commodity item.
I hope that helps. Please feel free to respond with comments if that leaves any points unanswered, or raises new questions.
UPDATE [added 9:38 PM] I'm reliably informed that my perception about Blue Titan being tied to BEA's WebLogic platform is behind the times: "Network Director runs on all J2EE servlets (incl. WebLogic, WebSphere, Oracle AS, Jetty, JBoss)."
UPDATE [added August 7]: By coincidence, Ephraim Schwartz at InfoWorld has been musing along similar lines, but with a different conclusion: Are SOAs customer- or vendor-driven?. Meanwhile, some excellent food for thought has arrived here in comments from Todd Biske and Edwin Khodabakchian.