SOA Vision, Implementation and Tooling

| by Miko Matsumura on Jun 02, 2006. Estimated reading time: 4 minutes |
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.

Tell us what you think

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

Email me replies to any of my messages in this thread

tools for SOA architects by Gerald Loeffler

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

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.


Re: tools for SOA architects by John Harby

I'd hope that SOA can remain independent of specific tooling wherever possible. Some may want to take an agile approach with minimal UML and with the incremental potential of building out services this is certainly reasonable. Others may want to use a model-driven approach and use extensive tooling to generate code. It would be nice to support both types.

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

Email me replies to any of my messages in this thread

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

Email me replies to any of my messages in this thread

3 Discuss