Comparison of SOA Suites

June 17th, 2007

Several SOA vendors are trying to put together comprehensive suites of SOA products that in theory should be capable of addressing all aspects of SOA, including governance, integration, business process management and others.

Formation of SOA suites is having a tremendous impacts on how SOA products are selected as many organizations are being tempted to settle for "one stop shop" approach as opposed to doing proper product evaluation within each SOA product category. (Interesting discussion about SOA suites is available at ZDNet).

So what is a SOA suite and how offerings from different vendors support different aspects of SOA? The table below attempts to answer this question.

One thing to keep in mind is that SOA products within the same category can differ substantially in terms of their feature sets. Definitions of ESB, registry and other SOA product categories are not standardized and so vendors are free to categorize their products as they wish. Detailed analysis and evaluation is still a requirement when selecting SOA products.

IBM, BEA and Oracle are emerging as leaders in terms of completeness of their SOA suites. Microsoft's products are not as comprehensive, nevertheless Microsoft's marketshare makes it a signifcant player - Micorsoft's shops tend to be very loyal to the vendor even if Microsoft's SOA story is not as compelling.

Other vendors, including Software AG/webMethods and HP have interesting offerings too, however, they still have some gaps in their capabilities and so they are not covered here (perhaps I'll add more vendors in the future).


  IBM BEA Oracle Microsoft
Web Services Container (applicaiton server) WebSphere Application Serer WebLogic Application Server Oracle Application Server .NET/Windows
ESB WebSphere ESB

Message Broker
AquaLogic Service Bus Enterprise Service Bus (part of Oracle SOA suite) BizTalk Server (some ESB capabilities)
Registry/Repository WebSphere Registry and Repository AquaLogic Service Registry (re-braned Systinet product)

AqualLogic Enterprise Repository (FlashLine aquisition)
Oracle Service Registry (re-braned Systinet product?)  
Business Process Management WebSphere Process Server (also includes ESB) AquaLogic BPM Suite (Fuego acquisition) BPEL Process Manager BizTalk Server
Business Activity Monitoring WebSphere Business Monitor AquaLogic BPM Suite Business Activity Monitoring BizTalk Server
SOA Security Tivoli Access Manager

Tivoli Federated Identity Manager

WebSphere DataPower SOA Appliances
AquaLogic Enterprise Security Oracle Web Services Manager (formerly Oblix COREsv) Windows?
SOA Management Tivoli Composite Application Manager for SOA (part of Tivoli suite) BEA AquaLogic SOA Management Oracle Web Services Manager  

6 comments to “Comparison of SOA Suites”:

  1. As an fyi, AMR Research just conducted a comprehensive, real-world analysis of all of the SOA/BPM product suties, including IBM, Oracle, SAP, BEA and Tibco. webMethods Fabric earned the top overall score -

    http://www.amrresearch.com/Content/View.asp?pmillid=20372

    Posted by John Conley
  2. […] 製品比較: http://myarch.com/comparison-of-soa-suites […]

    Posted by Tomonari.Net » SOAについてのリサーチ
  3. http://www.amrresearch.com/Content/View.asp?pmillid=20372

    Posted by Camilo Aguilar
  4. This document is only for AMR clients :(

    Posted by Camilo Aguilar
  5. Hi,
    There is an AMR Research document #20372 available at www.softwareag.com/corporate/images/soa_and_bpm_for_enterprise_applications_a_dose_of_reality_tcm16-35176.pdf.
    Is that it?
    Regards, Erik

    Posted by Erik Ykema
  6. […] Bobby Wolf posted a great article about a wide-spread problem plaguing many SOA implementations: over-engineering of SOA infrastructure, meaning that people rollout products that are not particularly required to implement their business services. He specifically talks about ESBs, but I would say that “you ain’t gonna need it” principle should be applied to any component of a SOA stack. For example, why implement a super-expensive BPM suite (or a BPEL engine) when an organization is simply trying to build some data services? Or why pay for a registry if there are only a handful of services in place? […]

    Posted by MyArch » Blog Archive » You Ain’t Gonna Need ESB

Post a comment