Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News SOA Vision, Implementation and Tooling

SOA Vision, Implementation and Tooling

As with any technology trend, the phenomenon of Service Oriented Architecture in the Enterprise evolves in three seperate threads--the state of the grand vision, the state of implementation and the state of tooling.

As with many historical innovations, the grand vision for SOA moved quickly into the future. This was because the grand vision borrows heavily from technology trends in the past including CORBA, EAI, transaction processing, DCOM and a host of earlier incarnations of distributed computing environments. Some of the vision keepers for SOA have had histories with these earlier systems, such as Eric Newcomer (CORBA), David Linthicum (EAI), Mark Little (Transactions), Steve Jones (Java),  Don Box (DCOM). In some cases, there are folks from the pure XML world like Canadians Tim Bray and Duane Nickull. These are just a few of the inspiring vision keepers blogging on SOA today; this group shows the diversity of backgrounds and perspectives informing the SOA vision.

The state of implementation lags the vision, as always. Many projects are now moving past pilot and into implementation. A Yankee group survey finds that 84 percent of companies are already in the midst of a service-oriented architecture project or will undertake one within the next year. Companies are just beginning to show ROI and ROA on SOA. These leading indicators are guiding the way for new projects.

Several organizations have published Maturity models including CDBI and Bearing Point. Maturity models help segment the adoption and clarify the stage of development of SOA in an organization. The Bearing Point SOA Maturity model suggests that SOA implementation matures across the following five stages:

  • Level 1: This is the initial learning and initial project phase of SOA adoption. Projects here are typically done to simultaneously meet a specific need to implement functionality while trying out specific technologies and an approach to SOA. "
  • Level 2: At this level, standards are set as to the technical governance of SOA implementation, typically under leadership of the architecture organization.
  • Level 3: A partnership forms between technology and business organizations in order to assure that the use of SOA provides clear business responsiveness.
  • Level 4: Level 4 focuses on measuring and presenting these processes at the business level so as to provide continuous feedback on the performance and business impact of the processes implemented at Level 3.
  • Level 5: The SOA information systems become the "enterprise nervous system" and takes action automatically according to events occurring at the business level according to rules optimizing business goals.
Unfortunately, surveys have not yet been conducted which clearly determine the stage of adoption in most enterprises. Infoworld conducted some survey research (link is to a powerpoint slide deck) which helps establish general trends, but the staging was not based on any formal maturity model.

SOA in particular benefits from such maturity models because of the length and scope of deployment. Many SOA projects span multiple years and phases. They are also useful because practical advice is so strongly dependent on the maturity of the implementation. What makes sense for one SOA implementation might be overkill (or insufficient) for another. Many experts agree that the mainstream Enterprise is already moving towards SOA. Alex Rosen, SOA Practice Manager for MomentumSI recently stated:  "We've passed the point of deciding if SOA will be adopted, for most organizations the question deals with when the adoption will occur."

The state of SOA tooling is perhaps the most significant to the eventual success of SOA. Tools (broadly defined, not just development environments) represent the maturation of platforms, methodologies and requirements into reproducable and consistent systems. One of the weakest areas in SOA tooling is support for architects. Architectural tools include those that can help structure and communicate the overall plan for a service architecture. Steve Jones from Cap Gemini suggests that Wikis and Visio are the state of the art for architecture. Sandy Carter from IBM, speaking at the recent SOA Executive Forum in New York said that the number one business process modeling tool on the market was PowerPoint.

As we move from architectural tools down into implementation tools, the landscape improves a great deal. Large vendors are all proposing infrastructure stacks to address SOA, including IBM SOA Foundation, BEA Aqualogic, Oracle Fusion, and SAP Netweaver to name a few. These large vendors are attempting to pull together comprehensive software stacks to address SOA. However, some of these efforts are still far from completion for example, analyst Joshua Greenbaum, principal of Enterprise Applications Consulting and Shawn Willett of Current Analysis have both commented on this gap. Because of this a plethora of smaller vendors are providing tools in the areas of testing, governance, management, adaptors, registries, scripting, user interface, and a host of other fine-grained capabilities.

On the emerging Open Source Web Services platform a number of efforts including the Apache AXIS2 centric WSO2 Tungsten application server and the XFire SOAP Framework are advancing the state of the art.  Xfire provides JBI support and  is integrated with Spring, Pico, Plexus and Loom. Spring integration is highlighed in this tutorial by Marc Logemann. A number of other efforts are underway to provide intermediation including ServiceMix, Mule, Synapse and Celtix.

Whether driven by back-end, messaging or even web front ends, the state of SOA tooling lags behind both the state of implementation as well as the grand vision for SOA. In this emerging state, online communities, word of mouth and public debate play a vital role in helping navigate the most useful technologies for hands-on implementers.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • tools for SOA architects

    by Gerald Loeffler,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Regarding your perception that there is a shortage of architecture-level tools for SOA:

    I've just come off an extensive SOA project and i must say that i didn't have the impression that we were inhibited by a lack of tools to communicate the SOA. UML component and class diagrams work as fine for capturing the static structure of (and interface to) an SOA as they do for other technologies. In addition, if a webservices-specific view is needed, then Eclipse WTP generates a decent visualisation of WSDL definitions. UML stereotypes (e.g. <<SOAP12>>) can be used to identify the protocol bindings exposed by a service.

    The area were these tools fall short, though, is in formally expressing the security constraints and QOS characteristics of the different webservices - textual annotations have to be used for that. That wasn't a significant impediment in our project but might be in others.

    Could you be more specific in what kind of architecture-level tools with what specific features you would see as needed to capture the characteristics of a SOA?


  • Re: tools for SOA architects

    by miko matsumura,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Could you be more specific in what kind of architecture-level tools with what specific features you would see as needed to capture the characteristics of a SOA?

    Hi Gerald,

    I really appreciate your comment! I think for the people who are willing to express themselves in UML, there are a lot of available tools--though some of the business side folks can find UML a bit obtuse at times.

    Steve Jones comments on this here:

    Steve is coauthor of a business/service decomposition notation which I feel might be a good target for tooling at the architectural level.

    I think you are right about tools for expressing policy and quality issues. This might be because the standards arent quite complete in these areas.


Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p