Dispelling Some Web Services Myths, Part 1

August 5, 2004 (Computerworld)

I'd like to briefly expose a few prevalent Web services notions that may be slowing the adoption of Web services and SOA. This will be a multipart series, so let's begin Part 1.

What is a Web services architecture (WSA)? What is a services-oriented architecture (SOA)? Are they the same thing?

There is confusion in the field about the meaning of these two terrms. I often hear both phrases used, sometimes interchangeably. What is the difference and why should it matter?

It certainly is possible to implement Web services in a non-SOA fashion, and this might be considered a Web services architecture. This is common for integration-focused Web services that are used to replace proprietary enterprise application integration (EAI) or homegrown integration approaches that are inflexible and expensive to maintain.

Similarly, a SOA can be implemented without deploying Web services, and in fact it has been done in the past with solutions such as Common Object Request Broker Architecture, Distributed Computing Environment, Component Object Model/Distributed Component Object Model, and even more recently with Java 2 Enterprise Edition middleware abstractions. These implementations were limited in that they were tightly bound to the computing platforms for which they were designed.

In general, an SOA is an architecture where application functionality is available as shared services discoverable on the network. Key elements of this SOA definition are "shared services" and "discovery." When a SOA is implemented using Web services , it's a more flexible and standards-based architecture than SOA without Web services. In fact, many industry proponents argue that Web services are an excellent architectural means to implement SOA based on Web Services Description Language (WSDL) as a superior Interface Definition Language (IDL) than previous approaches to SOA.

In a Web services-based SOA, available services are exposed using industry standard XML-based interfaces and communication mechanisms such that they will operate across all technology platforms. This is a superior architecture than SOA without Web services.

A Web services-based SOA is likely to employ all four core standards of Web services: XML, WSDL, Simple Object Access Protocol (SOAP) and Universal Description, Discovery and Integration (UDDI). In addition, the SOA implementation of WSDL to describe the available services will be such that the services will support dynamic binding and services reuse, where the WSDL in a WSA will probably employ static binding and may not be as easily incorporated into a future SOA without rework.

As mentioned above, Web services can be implemented in a non-SOA manner. Internal integration services are often implemented initially as point-to-point Web services with fixed binding and with no intent to expose them as shared, discoverable services in an SOA. This could probably be best described as a WSA.

This architectural model would employ three of the four core Web services standards -- XML, WSDL and SOAP -- while forgoing UDDI-based services discovery. The Web services strategy, goals and architectural design will probably be a more focused subset of those typically associated with an SOA. A WSA in this sense would be used in a nascent Web services approach where services discovery is not a requirement and where the preponderance of organizational benefits can be realized with point-to-point, integration-focused Web services. However, I urge clients to architect these initial services for a future SOA even though they may be point-to-point services. This will maximize potential reuse of the services.

In this sense, then, a WSA would be an SOA without services discovery (UDDI-based preferably) and without dynamic binding of services based on flexible WSDL construction. A WSA doesn't become a Web services-based SOA until two things are in place:

1. The WSDL for the Web services is constructed to support dynamic binding and services reuse


2. A UDDI registry (or an appropriate services discovery mechanism) is included in the architecture to support services discovery

Integration-focused entry points to Web services and SOA are very common despite some industry watchers suggesting an externally driven entry point. Both approaches are valid and depend on where the business benefits are greatest and the risk profile is minimized. However, when an organization begins with an integration-centric Web services approach, I encourage them to consider the SOA big picture when implementing their Web services such that the transition from a WSA to a Web services-based SOA is smoother.

There are clear differences between a WSA and a SOA based on Web services. In general, a WSA is a focused subset of a SOA. The strategy, business goals, architectural design and specific technologies used to build out a SOA are going to be different than those associated with a WSA.

If your organization elects to start with a WSA instead of a SOA, I suggest you consider the strategic benefits that attend a Web services-based SOA, and make sure that the targeted Web services, supporting platforms and technologies all can be accommodated into a larger SOA strategy. We've all heard the phrase "think globally, act locally." I suggest you "think SOA, act Web services." A Web services-based SOA is the big picture, and organizations should not lose sight of it.


Web services Standards Are Still Too Immature for Our Organization

Another issue is the confusion about standards, which ones are stable, which standards bodies to pay attention to and more. Let me be very clear: The four core standards of Web services are stable and mature, and are sufficient to solve 90% to 95% of the real Web services and SOA requirements that exist today.

XML is a W3C standard that has been widely deployed for Web-based applications for years. This is the foundation for all other Web services standards as they are all based on XML. SOAP, WSDL and UDDI were all endorsed by IBM and Microsoft Corp., and since then have been embraced by the entire vendor community as the definitive standards of Web services.

There are no excuses for not proceeding with Web services initiatives in an organization. That's not to say there isn't confusion. There is. However, the standards immaturity myth should be dispelled immediately.

The next article on "Dispelling Web Services Myths" will examine Web services security, varying goals of SOA vs. Web services, and whether Web services are appropriate for organizations that use EAI platforms. Stay tuned.