Manage Learn to apply best practices and optimize your operations.

A standard SOA paradox

Adam Michelson explores the key SOA standards and helps to identify which are likely to be adopted.

What would service-oriented architecture be without standards? Not much. But is it any better off with the large...

number of SOA standards that exist? Java and the Java EE are feeling the backlash of a specification that is too complex with too many standards, as simpler scripting languages are making ground. SOA will suffer the same backlash if the number of SOA standards and specifications continues to grow in number and complexity. We already see the emergence of very simple REST Web services as IT professionals look for clarity through the morass of SOA standards. Simplicity is the pathway to adoption.

It is not easy to stem the tide of the creation of SOA standards. Many times the creation and support for standards is political, with certain standards backed by software vendors that have their own agenda. The standards that survive give their creators leverage, so the result is no shortage of standards being created and trying to be the fittest. Given the proliferation of SOA standards, there is an opportunity to take a step back and provide some perspective on all the SOA standards that exist. That is the purpose of this series of articles.

We will explore the key SOA standards and try to identify which are likely to be adopted. Unfortunately this is not an easy task. Identifying only the most popular standards is not a popular thing to do as there will be a few that may feel snubbed for not being included. But there are so many SOA standards that exist and they are changing constantly, so discussing them all is practically impossible. The different versions of all the standards compound the complexity. This article still lists almost 70 individual standards, way too many for the average IT worker to be expected to keep abreast of.

This series of articles tries to lend some perspective on the existing SOA standards. It tries to pick some winners or at least some standards to take note of. It will compare like-standards and try to separate the key differences between them. This first article in the series lays out the key SOA standards and standards organizations that back them. Future articles in this series will take a deeper dive into some of the most intriguing standards. We will examine categories of standards and try to understand their similarities and differences. Ultimately the goal is to provide some perspective on all the standards that exist and which may be most relevant for you and your organization.

Some of the standards discussed here are technically not standards at all. They are a collection of specifications, APIs, protocols or just SOA concepts. To adequately compare SOA standards, they must be contrasted against not just other standards, but similar technical concepts as well. So I ask you to blur the distinction between standards, specifications, APIs and protocols for a few minutes so we can have a productive conversation on the topic.

Major Standards Organizations

To create so many standards there must be many standards organizations out there. Keeping track of these organizations can be confusing unto itself. So before we look at the standards, let's first review some of the major standards organizations that exist. Like the standards reviewed in this article, these are just some of the primary standards bodies. There are more in existence, but we kept it to just some of the major ones for simplicity. Not all of these standards organization participate in SOA standards, but they all do participate in technology standards. The people who participate in these organizations are credited for some of the great technology acronyms of our time! So let's get to know them a bit better.

The diagram below shows some of the major standards organizations. Again, I am using the term 'standard' loosely to include relevant specifications, APIs and the like. Peter Roden from OASIS helped me put the original picture together and I skewed it a bit to make it relevant for a discussion on SOA standards.

Some of the primary standards organizations

The most active organization of late that participate in SOA standards include:

  • W3C - World Wide Web Consortium
  • OASIS – Organization for the Advancement of Structured Information Standards
  • WS-I – Web services Interoperability Organization
  • JCP – Java Community Process
  • OSOA – Open SOA Collaboration

As way of introduction, here is a short description of each of these organizations. Many of these descriptions are derived from the organization's own websites:

W3C: The World Wide Web Consortium (W3C) develops interoperable technologies through defining specifications and guidelines, as well as creating software and tools to lead the Web to its full potential. In order for the Web to reach its full potential, the most fundamental Web technologies must be compatible with one another and allow any hardware and software used to access the Web to work together. W3C refers to this goal as "Web interoperability." By publishing open, non-proprietary, standards for Web languages and protocols, W3C seeks to avoid market fragmentation and thus Web fragmentation. The W3C was founded by Tim Berners-Lee in 1994.

OASIS: OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that drives the development, convergence and adoption of e-business standards. The consortium produces more Web services standards than any other organization along with standards for security, e-business and standardization efforts in the public sector and for application-specific markets. OASIS was first formed as SGML Open in 1993 and changed its name to OASIS in 1998.

WS-I: The Web Services Interoperability Organization (WS-I) is an open industry organization chartered to promote Web services interoperability across platforms, operating systems and programming languages. The consensus is that there are too many Web services standards (WS-*) in existence today and the WS-I is trying to help with this issue. There are two standards the WS-I have in the works, Basic Profile (BP) that includes the Attachments Profile, and Basic Security Profile (BSP).

JCP: Since its introduction in 1998 as the open, participative process to develop and revise the Java™ technology specifications, reference implementations and test suites, the Java Community Process program has fostered the evolution of the Java platform in cooperation with the international Java developer community.

OSOA: The Open SOA Collaboration represents an informal group of industry leaders that share a common interest: defining a language-neutral programming model that meets the needs of enterprise developers who are developing software that exploits service-oriented architecture characteristics and benefits. The collaboration is not a standards body - it is a set of vendors who wish to innovate rapidly in the development of this programming model and to deliver specifications to the community for implementation. When mature, the intent is to hand these specifications over to a suitable standards body (such as OASIS or W3C) for future shepherding. The industry partners are currently working on two main projects, Service Component Architecture (SCA) and Service Data Objects (SDO).

The SOA standards fall into some basic categories that we will use as a way to define and compare common standards:

  • Attachments – Standards for including extended data sets in messages.
  • Discovery – Standards to describe and locate services.
  • Events – Standards for using an event model to call services rather than just using request-response.
  • Integration - Standards to help heterogeneous systems work together.
  • Management - Standards to control, monitor and generally govern services.
  • Modeling – Standards to design SOA architecture and components. These also include standards to assure a model is designed correctly.
  • Orchestration Standards – Standards that define business workflow or conditions that define how services should work together.
  • Protocol - Standards that define messaging systems or infrastructure frameworks.
  • Transactionality – Standards to make services support state, data transactions and reliability. Often this extends into security to offer secure, reliable messages.
  • Security - Standards that make SOA messages secure or services authorize and authenticate.

Several standards categories exist to cope with inherit shortcomings within modern SOA infrastructure, or in particular, Web services. For example, Web services are not very good at attaching data to messages, event-based instantiation, managing transactions or security. These are fairly common capabilities in previous messaging protocols such as JMS, CORBA or IIOP, but do not exist natively in Web services. So there are many standards that try to help bring Web services up-to-par with its messaging predecessors. Other groups of standards are more strategic, such as the orchestration and management standards that add new capabilities to middleware. Orchestration tries to map business process onto messaging while many of the management standards are in response to the governance mandates that have come about in the current business climate. And finally some of the standards are even more abstract and try to create common modeling techniques for SOA architecture. These categories are my own interpretation of the standards described here and are used simply to help understand and deal with all the services that exist.

The following table lists many of the popular and influential SOA standards in existence. In future articles we will dive deeper into some of the specific standards, and try to understand what separates them, and take an educated guess at which will be adopted. But just to lay the groundwork, a fairly exhaustive list of SOA standards is presented here:

In the articles following this introduction, we will dig a bit deeper into some of the categories of standards described here. We will look to compare and contrast competing standards and look for which ones complement each other. We will also try to look into the crystal ball and predict some winners and losers among the standards, tying to figure out which will be adopted and which will not.

SOA relies upon standards and since we can't live without them, we must learn how to live with them.

About the author

Adam Michelson has more than a decade of technology implementation experience. Adam is currently the director of service-oriented and enterprise architecture for Optaros Inc., an international consulting and systems integration firm that provides enterprises with best-fit solutions to IT business challenges, maximizing the benefits of open source software.


This was last published in February 2007

Dig Deeper on Business process modeling and design

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close