1.1 What are Web services?

Web services represent a new breed of Web-specific software component methodology. They are a new type of object-oriented (OO) programming la the Web. Web services are modular, self-contained, self-describing software components. These software components are available over the Web (i.e., they are published on the Web). They can be readily located and checked out, online and dynamically, using a new directory and corresponding search mechanism known as Universal Description, Discovery, and Integration (UDDI). They are also invoked and consumed (i.e., used) across the Web ”hence, the term Web services , reflecting the fact that these are software services for application developers that are totally Web-centric.

Web services are truly platform independent. This platform independence, furthermore, applies to both sides of a Web services configuration (i.e., the usage side as well as the provision side). Thus, applications that use Web services can run on any platform. Web services themselves , in turn , are also totally platform independent. There are also no restrictions as to what platforms they can be developed upon. Hence, there are no platform- related restrictions whatsoever as to which Web services can be used by which applications ”or as to how and where the Web services, or for that matter the applications, were developed. Therefore, it is possible to have a Web application running on a Windows 2000 server that relies on three Web services: one running on a UNIX server from Sun, a second on a Unisys mainframe, and the third on an IBM iSeries machine. The Web service running on the iSeries machine may have been developed on a PC using IBM s WebSphere Studio Application Developer, whereas that running on the Sun UNIX server could have been developed using BEA s WebLogic Workshop running on a RedHat Linux system. Figure 1.4 highlights this no caveats, platform-independent, any-to-any capability of Web services, whereas Figure 1.5 shows how it would be possible to have applications running on different platforms acting as Web service users and providers to each other, at the same side.

Figure 1.4: Web services are totally platform independent, with no caveats, and as such it is possible for an application running on a Windows 2000 server, for example, to rely on functionality obtained from Web services running on vastly different platforms.

Figure 1.5: Given the total platform independence of Web services, it is even possible for applications running on different platforms to act as Web service users and providers to each other, at the same time.

The platform independence of Web services is, however, not in any way associated with or dependent on Java, despite appearing to promulgate the same message popularized since the mid-1990s by the Sun-led Java camp. Since it is now one of the leading programming schemes of the Web era, Java inevitably does have a major role vis--vis Web services, particularly since the Web services initiatives of industry super-heavyweights such as IBM, H-P/Compaq, Oracle, BEA, and Sun are all highly Java-centric. Nonetheless, Web services, in addition to being platform independent, are also totally programming language agnostic . Thus, it would be eminently feasible for an application being written in Visual BASIC or C++ to readily use Web services functionality being provided by a legacy program written in COBOL, PL/I, or even BAL. Needless to say, Java presents no problems, either on the usage or on the supply side. Applications being developed in Java can use Web services being provided by software written in any language, including Java, while Web services emanating from software written in Java can be used by applications written in any language.

Just as with platform independence, the programming language neutrality of Web services has no boundaries. It is truly any-to-any when it comes to programming language interoperability. It also provides a bridge between the old and the new when it comes to software programming methodology. This is another key reason why so many enterprises , in addition to the computer vendor community, are so interested in Web services. Web services provide a structured and regulated means by which mission-critical software functionality developed decades ago, prior to the advent of the PC, let alone the Web, can be brushed off and profitably reused with brand-new Web-centric applications.

Web services provide a means for modernizing legacy applications, particularly those developed to run on mainframes and mini-computers (e.g., IBM AS/400s and HP 3000s). With Web services you can squeeze yet more ROI from these tried and trusted software workhorses, despite them having already earned their keep, many times over, a long time ago. This legacy reusability aspect of Web services is an area of particular interest to IBM and other host access vendors (e.g., Jacada, SEAGULL Software), not to mention the Fortune 1000 companies that together have invested trillions of dollars in their application software portfolios.

1.1.1 Linking to remote functionality

Web services, to cut to the chase, are a remote procedure invocation mechanism. The data interchange (i.e., the I/O) with the remotely invoked procedure is, however, always realized using XML documents ”hence, the platform and programming language independence. The software code that makes up a Web service is never embedded within an application that requires that functionality. Instead, the new application includes a programmatic call to the Web service using XML documents as the means to convey input parameters and receive the required output.

Web services are thus a remote procedure call (RPC) mechanism in the true sense of that phrase. This RPC mechanism operates via the exchange of XML-based documents. It can even be accurately categorized as an XML-centric messaging scheme. The use of the term RPC in this context, however, should not be confused or associated with the heavily used UNIX RPC scheme that popularized this acronym. Web services are not in any way tied to the UNIX RPC mechanism, though, to be fair, it should be noted that UNIX RPC is one of the many transport mechanisms that can be used to invoke and consume Web services. HTTP (i.e., the ubiquitous HyperText Transfer Protocol of the Web), though, is likely to be the most widely utilized of the transport options that are open to Web services. Some of the other transports that could also be used include native TCP (as in TCP/IP), the Simple Mail Transfer Protocol (SMTP) as used by Internet e-mail, message queuing schemes such as IBM s WebSphere MQ (ne MQSeries) and Microsoft s MSMQ, the File Transfer Protocol (FTP), and nascent Internet-oriented protocols such as Blocks Extensible Exchange Protocol (BEEP).

The remote procedure call mechanism of Web services is realized using a protocol known as SOAP ”which stands for Simple Object Access Protocol. SOAP is an XML-based messaging scheme that is platform and programming language agnostic. It is a simple, lightweight mechanism for exchanging structured and typed information peer to peer in decentralized and distributed environments la the Web. In the context of Web services, it is SOAP that flows across the various possible transport options such as HTTP, RPC, TCP, SMTP, message queuing, FTP, and BEEP. Thus, the data transfers that take place between applications and Web services occur in the form of XML documents exchanged via SOAP ”where SOAP in turn relies on a lower-level transport scheme such as HTTP or TCP for connectivity and networking across the Web.

Web services were originally meant to be programmatic, as opposed to visually interactive solutions. In other words, they were targeted for program-to-program consumption rather than for human-to-program interactions. In a sense Web services were going to provide new applications with ready access to a rich set of Web resident functionality comparable to what people had been enjoying on the Web since the mid-1990s (e.g., stock quotes, weather updates, traffic reports , news feeds, package tracking, currency conversions, insurance rates, and so forth). Web services would thus enable diverse software components to be integrated across the Web using open, standardized protocols (e.g., SOAP), which are decoupled and independent of any proprietary application programming interfaces (APIs). The goal of Web services is to facilitate simple, but pervasive, program-to-program programmatic interactions around the Web.

The initial (around 2000) program-to-program charter of Web services has, however, already started to evolve . In early 2002, IBM, a very influential and proactive force in the Web services arena, proposed a new standard, referred to as Web Services for Remote Portals (WSRP) via OASIS (i.e., Organization for the Advancement of Structured Information Standards). OASIS (http://www.oasis-open.org) is a not-for-profit, global consortium with more than 600 corporate and individual members in 100 countries around the world that drives the development, convergence, and adoption of e-business standards. WSRP advocates visual, user - facing Web services ”that is, Web services that come replete with their own presentation services, ideally in the form of a contemporary graphical user interface (GUI).

WSRP s rationale, as implied by its name , is to make Web services that much easier to integrate into portals. (A portal, where Yahoo!, Excite, and www.schawb.com are classic examples of the genre , is an intuitive, transactional, focal point of access to a diverse range of content, services, resources, and applications.) Many functions desirable for inclusion within portals (e.g., stock quote retriever, stock price ticker, weather report bug, search engine, and local traffic report window ) will in the future be available in the form of Web services.

What WSRP and a related specification known as Web Services for Interactive Applications (WSIA), which is now being amalgamated into WSRP, contend is that having a built-in GUI will simplify and expedite the deployment of such services within portals, rather than portal developers having to locate and rely on additional software to implement an appropriate user interface front end. To be fair, there are certain portal-specific, as opposed to Web services “specific, methodologies that can also be used with panache to tackle this user interface issue. Key among these are the so-called XSL portlets, which will automatically render XML-defined content (and remember that the output of a Web service is indeed an XML document) within specific portal window panes, where a portlet, as illustrated in Figure 1.6, is a piece of software that handles and controls a specific, autonomous window pane within an overall portal view (or window, or even page). The importance of Web services vis--vis portals will be discussed further in Sections 1.2 and 1.3.

Figure 1.6: Portlets, the individual window panes within an overall portal view.

1.1.2 Self-promoting, as in blowing your own trumpet

Even more so than the platform and programming language independence, it is their self-advertising and self-describing aspects that make Web services truly special, revolutionary, and pragmatic. A Web service, by definition, has to always maintain an accurate self-portrait. Its operational model, interfaces, I/O parameters, and binding requirements have to be clearly and cleanly described ”with these descriptions posted on the Web so that software developers can quickly determine what they can expect from a given Web service. Web services describe themselves using a new, XML-based dialect known as WSDL (i.e., Web Services Description Language).

Similar to how HTML describes the format of Web pages using tags, WSDL, typically pronounced whiz dull , provides a means for accurately describing contemporary Web-oriented communications protocols and messaging schemes. In the case of Web services, the messaging mechanism that will most often be described using WSDL is likely to be SOAP-based exchanges. The goal of WSDL is to ensure that automated processes (e.g., applications running on a PC) can automatically determine the exact networking capabilities of remote systems (e.g., mainframe or UNIX server) without human intervention or prior definitions. The WSDL-based definition of interfaces, parameters, and bindings ensures that a Web services client (i.e., a new application) can readily invoke a remote Web service programmatically, without regards to how or where the Web service is actually implemented.

While WSDL takes care of the self-describing part, the self-advertising aspect of Web services, along with the ability to locate these blowing their own trumpet Web services via a directory mechanism, is handled by UDDI. In much the same way that you could today use a search engine such as Google to find Italian olive oil producers or no-fee dating services, it is now possible, using UDDI, to search the Web for Web services that offer the exact software functionality required by an application (or portal) developer. By 2005, professional software developers tasked with delivering any new software functionality are likely to start by searching the Web, via UDDI, for pertinent Web services that may facilitate their tasks . It would be very akin to the current modus operandi of seasoned, never-pay-the-full-rate travelers or insurance buyers . These bargain hunters first scour the Web looking for deals before they ever think about talking to an actual travel or insurance agent. Similarly, application developers will also start looking for deals that will make their life that much easier ”with these deals, however, being in the form of Web services.

Starting soon, the first, automatic knee-jerk reaction of application developers when confronted with the need to reinvent the wheel (so to speak) in terms of some software functionality will be to check if appropriate reusable software is available in the form of a Web service. They would do this using UDDI and a UDDI registry. It could be done manually by a person or programmatically by an application. The UDDI registry will contain WSDL-based descriptions of Web services. There is, however, no overt relationship between UDDI and WSDL. They are independent standards that can be used independently of each other. Thus, it is indeed possible to have services listed in a UDDI registry that are not described using WSDL. Such services, bereft of the WSDL self-describing prerequisite, will, however, not fall into the category of Web services. They would instead be non-Web services “related software ventures or nonsoftware-related services (e.g., consulting). It is also possible to have WSDL descriptions of Web services that are maintained outside a UDDI registry.

A UDDI Business Registry (UBR) to propagate use of Web services is already operational. This registry is sometimes also referred to as the UDDI Global Registry, since it is the cornerstone of the UDDI imitative. The UBR is operated as a Web-based, distributed service, which is made up of multiple, autonomously maintained registry nodes. At the start of 2003, registry nodes making up the UBR were being maintained by IBM, Microsoft, the Japanese NTT Communications Corporation (http://www.ntt.com), and SAP, the German-based world leader in Enterprise Resource Planning (ERP) software.

The UBR provides a central and formal directory where companies and individuals can register their businesses and the services that they offer. It is an online, category-based Yellow Pages for Web services (that can also be used as a white-page directory in that it supports name-based searches for companies and individuals). People who are looking for a service can now turn to this UBR to locate the businesses and individuals that provide such services.

Figure 1.7 shows the Microsoft UDDI registry node in action doing a search for services having to do with the weather, while Figure 1.8 shows the same search conducted on the IBM node to illustrate that the UDDI registry nodes will differ in their implementational details, though based on the same underlying UDDI standard. When searching for a Web service to source via UDDI, one does not have to limit the search to specific platforms, formats, APIs, or programming languages. Web services, through the use of XML-based documents and protocols, transcend all of these issues, which up until now were still pertinent concerns when talking about using external software functionality.

Figure 1.7: Performing a search for weather services using Microsoft s UDDI registry, where the first 7 of the 20 services found are displayed on the left-hand results tab.

Figure 1.8: Another search for weather services, this time using IBM s UDDI Business registry, which serves to illustrate that the UDDI register nodes will differ in their implementation details.

Now that the roles that XML, SOAP, WSDL, and UDDI play in making Web services possible have been broached, Figure 1.9 extends the Web services model introduced in Figure 1.2 to show where these enabling technologies come into play. The bottom line here is that thanks to XML, WSDL, and UDDI, Web services have propelled object-oriented technology to the next logical plateau.

Figure 1.9: The generic Web services operational model introduced in Figure 1.2 is now extended to show where XML, SOAP, WSDL, and UDDI come into play.

1.1.3 The salient characteristics of Web services

At this juncture, with the general lay of the land when it comes to Web services mapped out, it is appropriate to look at the definition for Web services being proposed by the W3C as a part of the draft, November 14, 2002, Web Services Architecture specification. The authors of this specification, acutely aware of the confusion that has swirled around the issue of what actually constitutes a Web service, begin with this caveat: Although there are a number of varied and often seemingly inconsistent motivations for, and uses of, the term Web service , at its core the following definition captures what we believe to be the shared essence of the term.

With that out of the way, they set out to define a Web service in the following terms:

The W3C draft definition: A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML-based messages conveyed by Internet protocols.

The term URI in this definition refers to a Uniform Resource Identifier ”which is a short string that uniquely identifies resources on the Web, with Uniform Resource Locators (URLs) of the form www.some-name.com being the best-known examples of a URI. Software systems in this context can be thought of as a broad umbrella term, which sets out to cover most things software related, including applications and possibly even small operating systems. This W3C definition, though striving to be as broad and open-ended as possible, is still consistent and very much in line with the Web services model presented at the very beginning of this book. The pivotal issue here is that Web services are problem-solving applications (or software systems), as opposed to being just networking protocols (e.g., SOAP) or a utility messaging functionality provided by some middleware suite.

The key, immutable, and defining characteristics of Web services, on top of the fact that they are applications, can now be summarized as follows :

Modular
Self-contained
Self-describing
Self-advertising
Uniquely addressable
XML-centric
Standards based
Platform independent
Programming language agnostic
Amalgamative in mix-and-match mode

Of these, the Web services feature that is most often and consistently cited by the cognoscenti is that of modularity. That makes sense, since it captures the object or component nature of a Web service. It also alludes to the fact that the overall Web services “oriented application development paradigm revolves around the concept of integrating diverse software modules to realize the requisite end results. It is a Lego block model, with application developers being able to mix and match and then snap together the various modules with a minimum of effort ”confident that not only will it fit, but also that the whole will stick together with aplomb, without the need for glue.

The self-contained aspect of Web services builds on the idea of them being modular. It highlights that a given Web service has a clearly stated charter ”in the form of operational characteristics and promised results. This charter is what is specified using WSDL. Furthermore, a Web service is supposed to deliver the entire functionality it promises without recourse to other external dependencies. This does not preclude a Web service from being able to call other Web services within its code to deliver the overall functionality it promises. What it means is that all such external calls and dependencies have to be handled entirely within the original Web service. All external dependencies have to be totally transparent to a subscriber of that Web service. A Web service thus has to be a well-behaved, uniquely identifiable black box with predefined inputs and outputs and no unexpected variations in behavior.

Of the 10 quintessential Web services characteristics listed earlier, at least six, and possibly seven, can be explicitly attributed to four key enabling technologies ”namely, XML, SOAP, WSDL, and UDDI. The following chart takes the nine quintessential Web services characteristics and shows which of the four key enabling technologies are responsible, in the main, for that feature:

Web Service Characteristic	Made Possible By
Modular	”
Self-contained	”
Self-describing	WSDL
Self-advertising	UDDI
Uniquely addressable	Internet protocols (e.g., DNS)
XML-centric	XML
Standards based	XML, SOAP, WSDL, and UDDI
Platform independent	XML and SOAP
Programming language agnostic	XML and SOAP
Amalgamative in mix-and-match mode	XML, WSDL, and SOAP

Table 1.1 expands on this chart and shows all of the standards and specifications associated with Web services as of the spring of 2003. Note that the four key enabling technologies are now just the cornerstones in a rising pantheon of Web services “related methodologies. This list of methodologies will, of course, continue to expand and evolve for a long time to come. At present there is no formal body that promises to maintain an accurate and up-to-date list of these methodologies in an easy-to-reference, tabular basis ”particularly in light of some of the intercompany (e.g., IBM versus BEA) or interfaith (i.e., Java versus .NET) politics that swirl around during the preliminary phases when such specifications are being formulated. The de facto standards bodies (e.g., W3C, OASIS, and so forth), understandably, do not want to get embroiled in the early wrangling and wish to stay aloof and impartial until there is some consensus.

Table 1.1: Standards and Specifications Associated with Web Services as of Spring 2003
Standard or Specification	Category	Purpose	Maintained By	Original Vintage	Original Sponsors
Core Backbone Standards
XML	Description	Generalized data description scheme to facilitate data sharing	W3C	February 1998	Derived from SGML
SOAP	Messaging	Peer-to-peer exchange of messages using a remote procedure call mechanism	W3C	May 2000	IBM and Microsoft
WSDL	Description	XML derivative for describing Web-oriented communications protocols and messaging schemes	W3C	September 2000	IBM, Microsoft, and Ariba
UDDI	Advertising/Publishing	Web-based registry mechanism to publicize and locate services	OASIS	September 2000	IBM, Microsoft, and Ariba
Business Process Representation
Business Process Execution Language for Web Services (BPEL4WS)	Business Process	Notation for describing business process behavior and interactions within the context of Web services	”	First draft July 2002	IBM, BEA, and Microsoft
Description
Web Services Architecture	Description	Reference architecture that defines the key components and the relationships among them	W3C	First draft November 2002	Software AG, IBM, Iona, and BEA
Discovery
Web Services Inspection Language (WS-Inspection)	Discovery	XML-based scheme that complements UDDI and WSDL, which allows a WS requester to drill down into the services offered by a provider	”	First draft November 2001	IBM and Microsoft
Messaging
Reliable HTTP (HTTPR)	Messaging	Guarantees reliable delivery of HTTP packets (which could include SOAP messages) between a server and client	”	June 2001	IBM
Web Services Attachments	Messaging	Extension to SOAP to facilitate attachments (e. g., images) without explicit XML encoding	IETF ”draft RFC	First draft June 2002	IBM and Microsoft
Direct Internet Message Encapsulation (DIME)	Messaging	Lightweight binary message format for encapsulating multiple payloads ”and targeted to work with Web Services Attachments	IETF ”draft RFC	First draft June 2002	IBM and Microsoft
Security
XML Signature Syntax and Processing	Security	XML-based digital signatures	W3C	March 2001	Motorola, Citigroup, and W3C
XML Key Management Specification (XKMS)	Security	XML-oriented scheme to integrate Public Key Infrastructure (PKI) with the Internet	W3C	March 2001	VeriSign, Microsoft, and webMethods
Web Services Security (WS-Security)	Security	Enhancement to SOAP to provide message integrity, confidentiality, and authentication	”	April 2002	Microsoft, IBM, and VeriSign
WS-Security Addendum	Security	Clarifications to WS-Security, along with use of message timestamps, X.509 certificates, and password transmittal	”	August 2002	Microsoft, IBM, and VeriSign
WS-Security Profile for XML-Based Tokens	Security	Framework to permit XML-based security tokens (e. g., Security Assertion Markup Language [SAML] and Extensible Rights Markup Language [XrML]) to be used with WS-Security	”	August 2002	Microsoft, IBM, and VeriSign
Web Services Trust Language (WS-Trust)	Security	Builds on top of WS-Security messaging to cater to security token exchange and multidomain credential management	”	December 2002	IBM, Microsoft, VeriSign, and RSA
Web Services Policy Framework (WS-Policy)	Security/Policy	Framework to describe and communicate the policies of a WS, including service requirements, preferences, and capabilities	”	December 2002	IBM, Microsoft, BEA, and SAP
Web Services Policy Assertions Language (WS-PolicyAssertions)	Security/ Policy	Details general messaging-related assertions for use with WS-Policy, such as character encoding and preferred language	”	December 2002	IBM, Microsoft, BEA, and SAP
Web Services Policy Attachments (WS-PolicyAttachments)	Security/Policy	Specifies three attachment mechanisms for using policy expressions with existing WSs	”	December 2002	IBM, Microsoft, BEA, and SAP
Web Services Security Policy Language (WS-SecurityPolicy)	Security/ Policy	Model and syntax for describing and communicating security policy assertions within the context of WS-Policy	”	December 2002	IBM, Microsoft, VeriSign, and RSA
Web Services Secure Conversation Language (WS-SecureConversation)	Security/ Policy	Builds on top of the WS-Security and WS-Policy models to provide secure communications between services	”	December 2002	IBM, Microsoft, VeriSign, and RSA
Web Services Secure Conversation Language (WS-SecureConversation)	Security/ Policy	Builds on top of the WS-Security and WS-Policy models to provide secure communications between services	”	December 2002	IBM, Microsoft, VeriSign, and RSA
Transaction Processing
Web Services Coordination (WS-Coordination)	Transaction	Extensible protocols for coordinating the actions of distributed applications, especially in the context of completing a specific business process	”	August 2002	IBM, Microsoft, and BEA
Web Services Transaction (WS-Transaction)	Transaction	Works with WS-Coordination to monitor the success or failure of short- or long-duration transactions	”	August 2002	IBM, Microsoft, and BEA
User Interface
Web Services for Remote Portlets (WSRP) and Web Services for Interactive Applications (WSIA)	User interface	Standard set of user-facing interfaces for facilitating the plug-and-play integration of WSs with portals or interactive application	OASIS	January 2002	IBM, Epicentric, and WebCollage
Web Services Experience Language (WSXL)	User interface	Component model for interactive WSs to facilitate commercial distribution via multiple channels and synthesis of new services	”	Late 2001	IBM

For example, in early summer 2002, IBM, Microsoft, and a consortium made up of BEA, Sun, and SAP were each vociferously promoting its own specific scheme for business process orchestration, with IBM s Web Services Flow Language (WSFL) being the most cited in the media as the frontrunner for becoming the eventual standard. Nonetheless, in a few short weeks spanning July and August 2002, IBM and Microsoft decided, quite suddenly, to bury their hatchets vis--vis this issue, merge their competing schemes, and, moreover, collaborate, along with BEA, on creating the Business Process Execution Language for Web Services (BPEL4WS) ”now one of the de facto standards in the still nascent business process orchestration sphere. Similar fluid and unpredictable dynamics are also afoot in the crucial and fast-growing Web services security arena. Hence, the difficulty in attempting to present an objective snapshot of the various standards in play without in some cases appearing to be backing the wrong horses.

All this said, IBM, a major proponent of Web services, has been maintaining a very useful list of pertinent Web services specifications in the Web services section of its developerWorks portal ”which can be accessed by going to http://www.ibm.com and then selecting the developers link, which will typically appear in one of the navigation bars. If you need an up-to-date list of the Web services “related standards and specifications, this would be the best place to start, always assuming , of course, that IBM continues to maintain and post this list. In addition to this useful IBM list, it will also be worth consulting the Web Services Industry Portal at http://www. webservices .org, OASIS at http://www.oasis-open.org, the World Wide Web Consortium (W3C) at http://www.w3.org, and possibly even the new, vendor-oriented Web Services Interoperability Organization at http://www.ws-i.org to determine what these groups are portraying as the standards being adopted by the industry.

The ability to easily obtain incisive software functionality in the form of one or more Web services should positively influence all future decisions about new application development. It is important not to lose sight of this. Web services have the potential to dramatically compress schedules, enhance the functionality of applications, increase the competitive element of applications, and even reduce cost. This is not idle hyperbole. These are the things that Web services are really supposed to deliver.

1.1.4 Web services ”not

Web services would be easier for people to accept if they were called by a slightly more descriptive term. The current name is ambiguous, misleading, and misused, so much so that Web services in time may even surpass the infamous Physical Unit (PU) in IBM s very influential Systems Network Architecture (SNA) as being the most misunderstood term in the computer industry. An SNA PU, despite what the name connotes, was not a piece of hardware. Instead, it was a piece of software that controlled a hardware device. In much the same way, a Web service, as we now know with conviction , is not a service in the sense that most people think of computer, network, or Internet services. Services, in computer circles, mean many things to many people but invariably with a common underlying theme. The term is used, quite appropriately, to refer to any external entity that does work on your behalf , so people are used to print services, directory services, file services, security services, and so forth.

It has come to the point where, in the context of enterprise networking, there is an overall connotation that services are provided by middleware, such as Java 2 Enterprise Edition (J2EE), IBM s WebSphere Application Server, BEA WebLogic, IBM MQSeries, and Microsoft BizTalk Server. The problem is that Web services are not middleware in the conventional sense. They are problem-solving software components (e.g., specific segments of business logic) that deliver specific functionality (which would be described using WSDL) rather than utilities used to create or sustain software functionality. In other words, a Web service is the actual thing when it comes to application functionality rather than being supporting (or utility) functionality required to realize the application logic.

SOAP, WSDL, UDDI, and the nascent BPEL4WS are innovative and strategic technologies used to make Web services possible. Though they are indeed middleware services, they themselves are not Web services. They are enabling technologies for Web services, but there continues to be confusion about this distinction in the media, where it is yet possible to read three articles about Web services in trade journals where two are talking exclusively about the enabling technologies while the third is actually talking about Web services as modular applications. Also, it is not unusual to see headlines such as Intel to Support Web Services, where the services in question are the enabling technologies as opposed to the high-level, application-oriented services. However, by now it should be abundantly clear what is what when it comes to Web services and the enabling technologies needed to sustain them.