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

Formation of a semantic framework

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.


Holt Adams, IT Architect, IBM jStart

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

Dan Gisolfi (, Engagement Manager and Solution Architect, IBM jStart

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

James Snell, Architect and Strategist, IBM Software Group, Business Process Optimization

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

developerWorks Contributing author

Raghu Varadan, Technology Architect, IBM Global Services

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 planning, and systems architecture. He has hands-on experience in developing large-scale, 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

01 October 2002

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.

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 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 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
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.

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
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.

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 e-business applications.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks

Zone=SOA and web services
ArticleTitle=Best practices for web services: Part 1, Back to the basics