General Information

XML Web services are the fundamental building blocks in the move to distributed computing on the Internet. Open standards and the focus on communication and collaboration among people and applications have created an environment where XML Web services are becoming the platform for application integration. Applications are constructed using multiple XML Web services from various sources that work together regardless of where they reside or how they were implemented.

There are probably as many definitions of XML Web Service as there are companies building them, but almost all definitions have these things in common:

• XML Web Services expose useful functionality to Web users through a standard Web protocol. In most cases, the protocol used is SOAP.
• XML Web services provide a way to describe their interfaces in enough detail to allow a user to build a client application to talk to them. This description is usually provided in an XML document called a Web Services Description Language (WSDL) document.
• XML Web services are registered so that potential users can find them easily. This is done with Universal Discovery Description and Integration (UDDI).

Top
2). Why should I care about Web Services?

One of the primary advantages of the XML Web services architecture is that it allows programs written in different languages on different platforms to communicate with each other in a standards-based way. Those of you who have been around the industry a while are now saying, "Wait a minute! Didn't I hear those same promises from CORBA and before that DCE? How is this any different?"

The first difference is that SOAP is significantly less complex than earlier approaches, so the barrier to entry for a standards-compliant SOAP implementation is significantly lower. The other significant advantage that XML Web services have over previous efforts is that they work with standard Web protocols-XML, HTTP and TCP/IP. A significant number of companies already have a Web infrastructure, and people with knowledge and experience in maintaining it, so again, the cost of entry for XML Web services is significantly less than previous technologies.

Top
3). What can I do with XML Web services?

The first XML Web services tended to be information sources that you could easily incorporate into applications-stock quotes, weather forecasts, sports scores etc. It's easy to imagine a whole class of applications that could be built to analyze and aggregate the information you care about and present it to you in a variety of ways; for example, you might have a Microsoft® Excel spreadsheet that summarizes your whole financial picture-stocks, 401K, bank accounts, loans, etc. If this information is available through XML Web services, Excel can update it continuously. Some of this information will be free and some might require a subscription to the service. Most of this information is available now on the Web, but XML Web services will make programmatic access to it easier and more reliable.

Exposing existing applications as XML Web services will allow users to build new, more powerful applications that use XML Web services as building blocks. For example, a user might develop a purchasing application to automatically obtain price information from a variety of vendors, allow the user to select a vendor, submit the order and then track the shipment until it is received. The vendor application, in addition to exposing its services on the Web, might in turn use XML Web services to check the customer's credit, charge the customer's account and set up the shipment with a shipping company.

In the future, some of the most interesting XML Web services will support applications that use the Web to do things that can't be done today. For example, one of the services that the Microsoft .NET My Services project will support is a calendar service. If your dentist and mechanic exposed their calendars through this XML Web service, you could schedule appointments with them on line or they could schedule appointments for cleaning and routine maintenance directly in your calendar if you like. With a little imagination, you can envision hundreds of applications that can be built once you have the ability to program the Web.

Top
4). What's the difference between an XML Web service and a Web site?

Unlike Web sites, which are pictures of data designed to be viewed in a browser by a person, an XML Web service is designed to be accessed directly by another service or software application. XML Web services are reusable pieces of software that interact programmatically over the network through industry recognized standards (XML and SOAP). XML Web services can be combined with each other and other applications to build intelligent interactive .NET experiences.

Top
5). What is SOAP?

Soap is the communications protocol for XML Web services. When SOAP is described as a communications protocol, most people think of DCOM or CORBA and start asking things like, "How does SOAP do object activation?" or "What naming service does SOAP use?" While a SOAP implementation will probably include these things, the SOAP standard doesn't specify them. SOAP is a specification that defines the XML format for messages-and that's about it for the required parts of the spec. If you have a well-formed XML fragment enclosed in a couple of SOAP elements, you have a SOAP message.

A major source of confusion when getting started with SOAP is the difference between the SOAP specification and the many implementations of the SOAP specification. Most people who use SOAP don't write SOAP messages directly but use a SOAP toolkit to create and parse the SOAP messages. These toolkits generally translate function calls from some kind of language to a SOAP message. For example, the Microsoft SOAP Toolkit 2.0 translates COM function calls to SOAP and the Apache Toolkit translates JAVA function calls to SOAP. The types of function calls and the data types of the parameters supported vary with each SOAP implementation so a function that works with one toolkit may not work with another. This isn't a limitation of SOAP but rather of the particular implementation you are using.

By far the most compelling feature of SOAP is that it has been implemented on many different hardware and software platforms. This means that SOAP can be used to link disparate systems within and without your organization. Many attempts have been made in the past to come up with a common communications protocol that could be used for systems integration, but none of them have had the widespread adoption that SOAP has. Why is this? Because SOAP is much smaller and simpler to implement than many of the previous protocols. DCE and CORBA for example took years to implement, so only a few implementations were ever released. SOAP, however, can use existing XML Parsers and HTTP libraries to do most of the hard work, so a SOAP implementation can be completed in a matter of months. This is why there are more than 70 SOAP implementations available. SOAP obviously doesn't do everything that DCE or CORBA do, but the lack of complexity in exchange for features is what makes SOAP so readily available.

Top
6). How secure are Web Services?

The good news is Web Services today are as secure as existing Internet transmissions. However, the bad news is Web Services today are as secure as existing Internet transmissions.

Early in its development, SOAP was seen as an HTTP-based protocol so the assumption was made that HTTP security would be adequate for SOAP. After all, there are thousands of Web applications running today using HTTP security so surely this is adequate for SOAP. For this reason, the current SOAP standard assumes security is a transport issue and is silent on security issues.

When SOAP expanded to become a more general-purpose protocol running on top of a number of transports, security became a bigger issue. For example, HTTP provides several ways to authenticate which user is making a SOAP call, but how does that identity get propagated when the message is routed from HTTP to an SMTP transport? SOAP was designed as a building-block protocol, so fortunately, there are already specifications in the works to build on SOAP to provide additional security features for Web services (e.g. WS-Security).

Top
7). What is WSDL?

WSDL (often pronounced whiz-dull) stands for Web Services Description Language. Generally, we can say that a WSDL file is an XML document that describes a set of SOAP messages and how the messages are exchanged. In other words, WSDL is to SOAP what IDL is to CORBA or COM. Since WSDL is XML, it is readable and editable but in most cases, it is generated and consumed by software.

To see the value of WSDL, imagine you want to start calling a SOAP method provided by one of your business partners. You could ask him for some sample SOAP messages and write your application to produce and consume messages that look like the samples, but this can be error-prone. For example, you might see a customer ID of 2837 and assume it's an integer when in fact it's a string. WSDL specifies what a request message must contain and what the response message will look like in unambiguous notation.

The notation that a WSDL file uses to describe message formats is based on the XML Schema standard which means it is both programming-language neutral and standards-based which makes it suitable for describing XML Web services interfaces that are accessible from a wide variety of platforms and programming languages. In addition to describing message contents, WSDL defines where the service is available and what communications protocol is used to talk to the service. This means that the WSDL file defines everything required to write a program to work with an XML Web service. There are several tools available to read a WSDL file and generate the code required to communicate with an XML Web service. Some of the most capable of these tools are in Microsoft Visual Studio® .NET.

Many current SOAP toolkits include tools to generate WSDL files from existing program interfaces, but there are few tools for writing WSDL directly, and tool support for WSDL isn't as complete as it should be. It shouldn't be long before tools to author WSDL files, and then generate proxies and stubs much like COM IDL tools, will be part of most SOAP implementations. At that point, WSDL will become the preferred way to author SOAP interfaces for XML Web services.

Top
8). What is UDDI?

Universal Discovery Description and Integration (UDDI) is the yellow pages of Web services. As with traditional yellow pages, you can search for a company that offers the services you need, read about the service offered and contact someone for more information. You can, of course, offer a Web service without registering it in UDDI, just as you can open a business in your basement and rely on word-of-mouth advertising but if you want to reach a significant market, you need UDDI so your customers can find you.

A UDDI directory entry is an XML file that describes a business and the services it offers. There are three parts to an entry in the UDDI directory. The "white pages" describe the company offering the service: name, address, contacts, etc. The "yellow pages" include industrial categories based on standard taxonomies such as the North American Industry Classification System and the Standard Industrial Classification. The "green pages" describe the interface to the service in enough detail for someone to write an application to use the Web service. The way services are defined is through a UDDI document called a Type Model or tModel. In many cases, the tModel contains a WSDL file that describes a SOAP interface to an XML Web service, but the tModel is flexible enough to describe almost any kind of service.

The UDDI directory also includes several ways to search for the services you need to build your applications. For example, you can search for providers of a service in a specified geographic location or for business of a specified type. The UDDI directory will then supply information, contacts, links, and technical data to allow you to evaluate which services meet your requirements.

Top
9). What is still left to be done with regards to Web Services?

SOAP (how to talk to XML Web services), WSDL (how to describe XML Web Services), and UDDI (how to find XML Web Services) constitute a set of baseline specifications that provide the foundation for application integration and aggregation. From these baseline specifications, companies are building real solutions and getting real value from them.

While much work has been done to make XML Web services a reality, more is needed. Today, people are having success with XML Web services, but there are still things that are left as an exercise for the developer (e.g. security, operational management, transactions, reliable messaging). Pending and future specifications (e.g. WS-Security, WS-Inspection, WS-Routing, WS-Referral) will help complete these outstanding requirements, as well as, enhance the Web Service architecture.

Over the next 12-36 months, Web Services will become critically important for organizations. Some of the first benefits an organization will realize will be reduced development and support costs (primarily through business logic reuse) and integration of their internal systems. Except for a few oddities, most medium-to-large organizations have struggled to integrate their various platforms and applications. Web Services will allow these disparate platforms/applications to interact seamlessly. Most enterprise software vendors (e.g. Microsoft, IBM, PeopleSoft, Oracle, SAP, etc.) either currently expose their application processes with Web Services or will in the next release/patch of their software. Plus, by wrapping an organization's current in-house developed business processes with Web Services, redundant and "legacy" logic can be either be eliminated or centralized.

Over time, Web Services will be used by organizations to gain strategic advantage either by exposing business processes to external parties to forge new relationships, and/or opening new markets by offering unique and previously unavailable services.

Top
2). What impact will Web Services have on an IT staff?

Profound. Web Services will not only change the way applications are defined and architected, Web Services will change the roles and responsibilities of each IT stakeholder. Since Web Service-based applications are loosely coupled solutions that will rely on both internal and external processes, all IT stakeholders (e.g. developers, database administration, infrastructure, QA, testing, user community, IT management, external partners, etc.) are active players in the design, development, and deployment of these applications. Cooperation and synergy between these stakeholders will by crucial for an organization's Web Service offerings to be successful. Besides the technical challenges facing these roles, best practices will have to be agreed upon and implemented so corporate and global standards are followed.

Top
3). Will the idea of an "application" be a thing of the past?

To a certain extent - yes. Enlightened applications will be a coupling of components/services to string together business processes. As business needs change, an organization will just re-couple the appropriate components and services to accommodate the change.

Top
4). Will Web Services increase or reduce the amount of software developed today?

In the short term, more software will be developed as processes are rewritten/wrapped into Web Services. In the long term, less software will be developed do to reuse and consolidation.

Top
5). How will people get paid for Web Services?

A variety of payment and usage models currently exist for Web Services (with more to come). However the two most promising models are:

• Subscription. People will lease the services they need. This model is good when usage is fairly static, and/or, consistent budgeting is needed.
• Transactional. People will pay for what they use. As needs increase or decrease so does operating/processing costs. We think that is the model most people will embrace.

First, an organization needs to become comfortable with XML. This goes beyond a developer focus. An organization's infrastructure, database, and business communities needs to become comfortable working with this medium.

Second, an organization needs to get educated in how to build these new solutions. Some organizations will learn by trial-and-error (e.g. undirected pilots, spot application upgrades, one-off solutions, etc.). We do not recommend this approach. The current fragmentation in IT organizations has come about because of this mentality. We recommend organizations take a centralized, enterprise-based view of implementing Web Services. Education in Web Service best practices and technical disciplines should be focused creating reuse and consistency within an organization. (A good first step is partaking in DSI's Visual Studio .NET Bootcamp)

Third, an organization must become ready to identify and cope with change. The organizations that understand and embrace the Web Services model will be able to react quickly these changes. Eventually, these organizations will proactively gain strategic advantages from Web Services.

Given that Web Services are located, defined, and accessed via XML (UDDI, WSDL, and SOAP) any processes that need to have heterogeneous (e.g. cross-platform) or firewall-restricted access (e.g. external, departmental, centralized process) are prime candidates to be implemented via Web Services. Web Services will allow unlike platforms/application to speak to one another consistently and provide secure and encrypted transport over widely accepted Internet protocols (e.g. HTTP, SMTP, etc.).

Existing application that use binary interfaces (e.g. COM, CORBA, and Java) need not be rewritten as Web Services. Often Web Service wrappers can be placed around existing business logic to facilitate Web Service communications. However, since the Web Service protocols are text-based, infrastructure-based performance enhancements may be needed to match the native speed of components that use like binary interfaces.

Top
2). What is WS-Security specification?

WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies.

WS-Security also provides a general-purpose mechanism for associating security tokens with messages. No specific type of security token is required by WS-Security. It is designed to be extensible (e.g. support multiple security token formats). For example, a client might provide proof of identity and proof that they have a particular business certification.

Additionally, WS-Security describes how to encode binary security tokens. Specifically, the specification describes how to encode X.509 certificates and Kerberos tickets as well as how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the credentials that are included with a message.

Top
3). What is WS-Inspection specification?

The WS-Inspection specification provides an XML format for assisting in the inspection of a site for available services and a collection of rules for how inspection-related information should be made available for consumption. A WS-Inspection document provides a means for aggregating references to pre-existing service description documents which have been authored in any number of formats. These inspection documents are then made available at the point-of-offering of the service as well as through references which may be placed within a content medium such as HTML.

Top
4). What is WS-Routing specification?

Web Services Routing Protocol (WS-Routing) is a SOAP-based, stateless protocol for exchanging one-way SOAP messages from an initial sender to the ultimate receiver, potentially via a set of intermediaries. In addition, WS-Routing provides an optional reverse message path enabling two-way message exchange patterns like request/response, peer-to-peer conversations, and the return of message acknowledgements and faults. WS-Routing is expressed as a SOAP header entry within a SOAP envelope making it relatively independent of the underlying protocol. This specification defines the use of WS-Routing in combination with TCP, UDP, and HTTP but other underlying protocols are possible.

Top
5). What is WS-Referral specification?

Web Services Referral Protocol (WS-Referral) is a SOAP-based, stateless protocol for inserting, deleting, and querying routing entries in a SOAP router. A SOAP router is a SOAP node that exposes SOAP message relaying as a Web service, either as a standalone service or in combination with other services. An example of a SOAP router is a SOAP node supporting the Web Services Routing Protocol (WS-Routing). In addition to mechanisms for inserting, deleting, and querying routing entries, WS-Referral defines an XML-based structure called a WS-Referral statement for describing a routing entry along with a set of conditions under which the statement is satisfied.