Daniel ShollerOur SOA surveys show that the vast majority of services in production today (over 80%) are WS-* services. This means that they have a WSDL descriptor, and at least in theory they can be invoked via SOAP over HTTP. In reality, many of them use commercial middleware or ESB message transports. However, nearly every discussion of SOA today includes a conversation about how much one can rely on the WS standards, and their evolution. Organizations of all types are trying to figure out if the vision of web services that was espoused a few years ago has any relevance to their future plans.
There are several reasons why this comes about. One of the most prevalent ones is that there is a growing understanding that SOA is not a uniform thing. There are different styles of SOA, and the differences between those styles are part of what creates this uncertainty. The prevailing style, which unfortunately does not have a recognized name, (although we refer to it in our research as "RPC" style SOA) is closely associated with the use of WS-*. An alternative style (Web Oriented Architecture coined by my colleague, Nick Gall) which uses the architectures associated with the web, and with the architectural style called REST as the basis for the design of services. This style is often perceived to be Anti-WS, since the WS-* protocols do not lend themselves easily to the creation of WOA or RESTian interfaces. The notion that there is an alternative, and one that does not depend on web services standards, and in fact may be antithetical to the use of those standards means that the position of those standards as the core of SOA understanding has been disrupted. WOA style services represent a small (about 15%) but rapidly growing segment of the services that are being built today.
In addition we are at a point where people are really doing SOA. In North America and Europe, the use of SOA is extremely strong (See our recent survey research). We also see from those same sources that most services are being implemented for A2A within the organization (although the use of B2B services is growing. The data for this is available in my upcoming research on justification… stay tuned). Many of these services are being built with the help of an ESB or other middleware technology forms, and while WS* may be used in those implementations, it is often hidden in the tooling that organizations use.
There is no doubt that WS-* based services will have a place in the service portfolio for a long time to come, but we are reaching the point where WS* does not mean SOA. This is both good and bad. The good is that it means that practitioners must now focus on the design, which is the part of SOA that really makes the difference. The bad news is that it means that the technology choices are not nearly as simple as they might have first appeared, and we will be struggling with choosing the right technologies for the design patterns we choose for a long time to come. In many cases, we will find the WS-* standards and the technology that implements them to be useful, but we are likely to find any number of cases where it is not. As we continue to evolve the styles of SOA, we will have more variation in the manner in which services are implemented, at least until the industry as a whole comes to a common understanding of the best practices and uses for the various styles of SOA.
2 responses so far ↓
1 John Pescatore October 22, 2008 at 4:08 pm
Does anyone know anymore what the integer value of * is? At least 3 digits, no? Maybe 4.
2 Dan Sholler October 22, 2008 at 4:22 pm
Well, if you just count approved OASIS standards, the number is 12, but that is part of the problem. As the nature of SOA and the practices change, the potential areas of standardization (and the approaches) have shifted. Part of the uncertainly that many people have about the Web Services standards is that it is unclear what the end result will be.