Best practices for web services: Part 1, Back to the

basics
Formation of a semantic framework
Holt Adams
IT Architect
IBM jStart

01 October 2002

Dan Gisolfi (gisolfi@us.ibm.com)

Engagement Manager and Solution Architect
IBM jStart
James Snell (jasnell@us.ibm.com)
Architect and Strategist
IBM Software Group
Raghu Varadan (rvaradan@us.ibm.com)
Technology Architect
IBM Global Services
As the hype around web services ebbs and the technology enters the disillusionment phase of
the adoption life-cycle, business entities are now demanding best practices to aid them in their
technology adoption efforts. This article begins a series that will address the building blocks of
web services, applicable business scenarios, and best practice methods for embracing web
services by business and IT professionals. Our first task is to go back to basics to lay out a
vernacular that will provide clarity to our discussions.
The cloud of technologies being developed to deliver on the promise of web services has (in our
opinion) finally reached a point of maturity that allows us to start moving beyond the initial hype
and excitement into actual down-and-dirty implementation. In April 2002, Google announced that
it would enable developers to query more than 2 billion web documents directly from their own
applications using WSDL and SOAP technologies; if nothing else, this demonstrates that the idea
of using web services to deliver real-world applications has seriously begun to take root in the
minds of developers. Indeed, at many of our customer service engagements, we are witnessing a
trend: Customers, and not evangelists, are driving the rapid adoption of web service technologies,
within and beyond the enterprise.
Copyright IBM Corporation 2002
Best practices for web services: Part 1, Back to the basics

Trademarks
Page 1 of 9

developerWorks

ibm.com/developerWorks/

A key challenge for many developers and application architects who are seeking to apply these
technologies, however, is the fact that amidst all the hype, there is currently very little direction
available on how to best apply new technologies such as SOAP, WSDL, and UDDI within
real business scenarios. Recognizing this deficiency, a number of developers and architects
from across IBM's Global Services, jStart, and Emerging Technologies Groups have sought to
identify and document a collection of best practices for the real-world application of web service
technologies on a scenario-by-scenario basis.
The process is straightforward. The key to our method is that we will be looking at real business
scenarios -- not hypothetical scenarios conjured up to illustrate the way we think things should be,
but situations in which customers are actually applying these technologies within their businesses
to solve real problems. Within those scenarios, we ask some very key questions:

What is the business objective of the solution?

What general e-business pattern does the solution implement?
What is the logical architecture of the application?
How, where, and why were web service technologies used in the building of the application?
What specific benefit was realized from the use of web services in the application?
What was learned (positively and negatively) about the technologies and methodologies
used?

This article is the first in a series that will document and explore our findings; the series will be
most useful to solution architects and others who may be in positions to decide how -- or if -- web
service technologies and design methodologies should be adopted for a particular project. Our
roadmap for the series will be straightforward. We will first lay a foundation, explaining both the
language and the methods we used to identify and categorize the various best practices. This
process will include a vernacular, or set of common terms, that we'll define in this first article, plus
a second article focusing on the relationship of IBM's e-business patterns (see Resources) to our
best practices efforts. The third and subsequent installments will address each of the six questions
above for a collection of actual business scenarios. We will conclude with a summation article
consisting of our proposal for a set of best practices.

What is a web service?

It is probably fair to say that the initial hype surrounding web services has reached astronomical
proportions, so much so that the language used to describe what web services are, and how to
go about implementing them, is becoming entirely too overloaded and muddled. In fact, one of the
most difficult tasks the recently formed W3C Web Services Architecture Working Group has faced
so far has been to determine the answer to what seems like an easy question: What is the generic
definition of a web service? Given all the hype, one might think that such a definition wouldn't be
hard to come by. The challenge, however, is to overcome the abundance of definitions, most of
which are contradictory and only reveal a fragment of what web services can be or may become.
When distilling a collection of best practices, one of the most important first steps is to ensure
that the language used to describe the various core concepts is clear, concise, and accurate.
Unfortunately, you also have to work within the bounds of already existing and accepted
Best practices for web services: Part 1, Back to the basics

Page 2 of 9

ibm.com/developerWorks/

developerWorks

vernacular (regardless of how much confusion an existing name or term might cause). The
SOAP protocol itself, for instance, is the poster child for improperly named technologies in the
web services world: though the acronym stands for Simple Object Access Protocol, it describes
a messaging protocol specification that has little to do with objects and is far from simple to
implement.
The working definition of a web service that the W3C Web Services Architecture group managed
to agree on is as follows:
A web service is a software application identified by a URI, whose interfaces and
binding are capable of being defined, described, and discovered by XML artifacts,
and supports direct interactions with other software applications using XML-based
messages via Internet-based protocols.
For those who think that web services are limited to SOAP messages used to invoke the methods
of an application over an HTTP connection (as the traditional SOAP stock-quote service does), this
definition may be a bit surprising. However, it tells us a couple of interesting things pertinent to our
goal of a common vernacular:
Web services do not require SOAP.
Web services do not require HTTP.
However, a web service (as defined by the W3C) does require an XML-based description
mechanism of some kind (such as WSDL) that can be used to describe the service's form and
function. Remember, the backdrop framework for this industry-wide initiative around web service
technologies is a service-oriented architecture (SOA; for more information, see the Resources
section below). As such, a non-XML based description mechanism (like IDL) would make an SOA
implementation more complex and less open.
Note also that the W3C's definition, while mentioning service discovery, does not mention UDDI
or any other specific discovery mechanism. This fact will become important as we walk through
the various business scenarios and explore how and why certain service discovery mechanisms
are used. Specifically, while early literature on the web services architecture asserted that UDDI
had a core, essential role to play, real-life implementation of business solutions with web services
have demonstrated that UDDI's most significant role is actually quite specialized at this time; in
fact, many web services solution are built that do not use UDDI in any way. In the vast majority
of current business cases, it would be safe to say that these discovery mechanisms are not yet a
core component for integrating processes between business partners.

Defining our terms, narrowing our focus

The impact of the W3C's definition of a web service is profound in that the range of things that can
be called web services literally includes any software component that can be uniquely identified
and described using XML syntax. That range is potentially limitless and does absolutely nothing
to help us outline a set of best practices. The term web services itself poorly represents the entire
range of applications that may fit into the broad W3C definition, as many such applications may
never involve the Web or the technologies upon which the Web is built. Nevertheless, we must
Best practices for web services: Part 1, Back to the basics

Page 3 of 9

developerWorks

ibm.com/developerWorks/

somehow include the term web services in our vernacular, as it is already associated with the
domain of technologies relevant to our conversation.
What we discovered as we began to analyze customer scenarios is that we needed to come up
with new perspectives and a vernacular to differentiate the various subtypes of web services that
emerge through the use of the different available description, message, and transport protocols.
We started with the Venn diagram illustrated in Figure 1, which identifies a range of possible open
protocols that may or may not be used in service-oriented applications.

Figure 1. Service-oriented application protocols

From Figure 1, we derived the first two definitions in our new vernacular:
Web services are software components that are developed using specific technologies from
three primary technology categories:
An XML-based description format (for example, WSDL)
An application messaging protocol (for example, SOAP)
A collection or transport protocol (for example, HTTP)
In each of these categories, there are proprietary (vendor- or platform-specific) technologies
as well as open (vendor- or platform-independent) technologies available.
Service-oriented applications include applications that MAY make use of web service
technologies such as SOAP but MAY NOT include a WSDL or other XML-based description.
Such applications are considered Web-service-like but are not technically web services.
After considering the W3C's definition and the Venn diagram in Figure 1, we can say that any
piece of software that is described using some XML-based description mechanism qualifies as
a web service. It does not matter if such an applications makes use of any other web service
technologies. It's quite possible for an application that uses a programming language-dependent
messaging protocol (for example, JMS) and a proprietary transport protocol (for example,
MQSeries) to qualify as a fully compliant web service by simply providing a WSDL description of
the application's interface. Conversely, an application that sends SOAP messages over HTTP
but does not provide a WSDL description does not qualify as a web service, though it would be
considered Web-service-like and deemed a service-oriented application.
Best practices for web services: Part 1, Back to the basics

Page 4 of 9

ibm.com/developerWorks/

developerWorks

So, given our new definition for a web service, let us now focus on the circle in Figure 1 that
represents open XML-based descriptions. Furthermore, let's focus on the pain-points at which
web service technologies were originally targeted: integration and interoperability. These two
pain-points are pertinent to application development both internal and external to the enterprise.
Whether you need to integrate with a heritage COBOL application deep inside the back office
or with a distributed application on some external server over the Internet, you need to build
points of abstraction into your application to ensure ease of integration and interoperability. A de
facto standard description language in this domain is WSDL, which was created to provide an
abstraction layer around a service's interface and implementation.
Since WSDL is one possible open XML-based description language, there exists a category of
web services that choose to use WSDL as their description protocol. In Figure 2, we illustrate such
a subset of web services and derive three new additions to our vernacular.

Figure 2. Domain of web service protocols

Enterprise web services are web services that do provide a WSDL description but MAY
make use of proprietary application messaging or transport protocols. An example of such a
service would be one that sends SOAP messages over IBM MQSeries using JMS.
Internet web services are enterprise web services that MUST only use open application
messaging or transport protocols. An example of such a service would be one that sends OTA
XML messages over HTTP.
XML web services represent the very small subset of Internet web services that MUST
use the W3C's adopted XML-based messaging protocol over a narrow range of transport
protocols. Specifically, XML web services will only send SOAP messages, and only send
them over HTTP, SMTP, or raw TCP/IP connections.
These new definitions capture the concepts conveyed by many in the industry over the last few
years whilst providing a semantic framework to categorize the subsets of components that the
original (overloaded) term web services intended to capture but failed to articulate. For instance,
Microsoft's .Net strategy focuses on XML web services, while CommerceQuest's CICS Process
Integrator (CPI) focuses on enterprise web services. This new vernacular provides a framework for
understanding the intentions of both companies with respect to web service technologies.
Best practices for web services: Part 1, Back to the basics

Page 5 of 9

developerWorks

ibm.com/developerWorks/

Where do we go from here?

As we stated at the outset, the goal of this series is to explore a variety of real-world business
scenarios and distill from them a collection of best practices for the design and implementation
of web services in enterprise environments. Future articles in the series will each focus on a
single scenario and will use the language and classifications introduced in this first installment
to categorize our findings. The critical element in this process is the fact that this exercise is
dealing only with real-world scenarios that very much reflect the point of view of what can be done
today. We will not discuss theory or hypothetical what-ifs. We will analyze and evaluate each
scenario against common, proven design patterns, strategies, and best practices for enterprise
development. And we will be completely open about how the use of web service technologies in
any given situation helped -- or hindered -- the architecture.
Web services are not a silver bullet, but are a very appropriate alternative for many customer
situations. They play a distinct role in the enterprise. It is our intent to provide a set of best
practices that will help architects and developers integrate web service technologies into their ebusiness applications.

Best practices for web services: Part 1, Back to the basics

Page 6 of 9

ibm.com/developerWorks/

developerWorks

Resources

Read the second installment in the Best practices for web services series.
Check out all the Best practices for web services columns.
The W3C Web site contains links to many of the standards discussed here.
OASIS focuses on a number of XML-based standards and technologies.
Check out version 1.1 of the Web Service Description Language (WSDL) .
Take the developerWorks tutorial, Building web service applications with the Google API, by
Nicholas Chase (developerWorks, May 2002).
Read more about Google's web services offerings in "Google Tests Search Tools for
Developers," Stephanie Olsen (CNet, April 2002).
For more on Google's web services APIs, check out the project's home page.
To learn about service-oriented architecture, read "The Tao of E-Business Services," Steve
Burbeck (developerWorks, October 2000).
Find out more about IBM's patterns for e-business.

Best practices for web services: Part 1, Back to the basics

Page 7 of 9

developerWorks

ibm.com/developerWorks/

About the authors

Holt Adams
Holt Adams is currently a senior-level IT architect supporting IBM's jStart program,
working with customers and business partners to adopt emerging technologies such
as web services. After graduating from the University of Tennessee in 1982 with
an electrical engineering degree, he joined IBM in Research Triangle Park, N.C.
His experience includes hardware and software development of communication
and networking products, technical marketing of mobile and wireless solutions,
and architecture and integration of Internet-based solutions. For the past two years
he has been focused on promoting web services as IBM's strategic integration
technology, working with customers to initially develop proofs of concepts, but more
recently in developing solutions for production environments. Holt can be reached at
rhadams@us.ibm.com.

Dan Gisolfi
Dan Gisolfi is an engagement manager and solution architect for IBM's jStart
emerging technologies team. He keeps his hands dirty in both the business and
technical aspects of customer engagements. He gets to wear many hats, from
business development manger and evangelist to solution architect and contract
negotiator. Dan's current focus is to help IBM drive the adoption of web services
through real business solutions. You can contact Dan at gisolfi@us.ibm.com.

James Snell
James Snell is an architect and strategist for the emerging Internet technologies
team within IBM's software group, where he plays an active role in the evolving
architecture and implementation of Web service technologies. He is a coauthor of the
book Programming Web Services with SOAP, published by O'Reilly & Associates.
James can be reached at jasnell@us.ibm.com.

Raghu Varadan
Raghu Varadan is a technology architect with the IBM Global Services Architecture
Center of Excellence. He has over 14 years of experience in software consulting,
demonstrating the broad business application of technology, strategic technology
Best practices for web services: Part 1, Back to the basics

Page 8 of 9

ibm.com/developerWorks/

developerWorks

planning, and systems architecture. He has hands-on experience in developing largescale, complex, enterprise-wide architectures; he has also worked in object-oriented
and client-server applications development, and has been involved in both business
and technical aspects of the full life-cycle of software development. He has helped
various customers in adopting emerging technologies, delivered complex solutions to
meet various business needs of customers, and has also been involved in mentoring
customers and peers in the adoption and delivery of technologies in business. Raghu
can be reached at rvaradan@us.ibm.com.
Copyright IBM Corporation 2002
(www.ibm.com/legal/copytrade.shtml)
Trademarks
(www.ibm.com/developerworks/ibm/trademarks/)

Best practices for web services: Part 1, Back to the basics

Page 9 of 9