Business Web Services Scorecard

Author:
David Burdett. Email: david@davidburdett.com, Web: http://www.davidburdett.com

Latest version:
http://www.davidburdett.com/papers/scorecard/BusinessWebServicesScorecard.htm

This version:
http://www.davidburdett.com/papers/scorecard/20030801/BusinessWebServicesScorecard.htm

Copyright 2003, David Burdett

Abstract

There is huge amount of hype around Web Services and its standards such as SOAP, WSDL and UDDI. Although they are currently being used successfully, they have well known limitations that prevent them being used more widely by business.

This paper helps by providing a "scorecard" of Web Services standards from a business perspective. It describes a comprehensive framework that:

• Explains the different areas of Web Services that need standardization before businesses can realize the maximum benefit that Web Services technology will bring
• Describes the benefits that standardization of each area could eventually bring
• Identifies and assesses the major Web Services standards that have been developed in each area, and
• Offers likely developments in Web Services Standards in the future.

As a result of reading this paper, the reader should:

• Better understand the benefits that Web Services can bring to a business' use of Information Technology
• Understand the limitations of existing Web Services solutions caused by lack of standardization
• Be able to better identify those solutions that enable a business to realize the benefits of Web Services now, whilst minimizing the costs associated with the changes arising as web services standards evolve.

This August 2003 version of the paper also provides an overview of what's changed since the last publication of this paper in May 2003. See the what's changed section.

Table of Contents

Abstract

Management Summary
    How the Business Web Services Scorecard helps
    Web Services Standards Framework
    The Current State of Business Web Services Standards
    What should businesses do now?
    What the rest of this paper contains
    How to provide feedback

What's Changed

Web Services Basics
    A Real World Service
    An Equivalent Web Service
    Real World vs. Web Services
    So what are SOAP, WSDL and UDDI?

Web Services Standards Framework
    Underlying Technology
    The Framework
    How Complex Web Services Work
    What Features Should Complex Web Services Support
    The Current State of Complex Web Services
    The Future of Complex Web Services

Definition Languages
    What Definition Languages are needed
    The Current State of Definition Languages
    The Future of Definition Languages

Semantic Definitions
    What Semantic Definitions are needed
    The Current State of Semantic Definitions
    The Future of Semantic Definitions

Profiles, Policies and Agreements
    What Profile, Policy and Agreement Standards are needed
    The Current State of Profile, Policy and Agreement Standards
    The Future of Profile, Policy and Agreement Standards

Web Services Management
    What Web Services Management Standards are needed
    Current State of Web Services Management Standards
    The Future of Web Services Management Standards

Registries
    What Registry Standards are needed
    Current State of Registry Standards
    The Future or Registry Standards

Program APIs
    What Program API Standards are needed
    Current State of Program API Standards
    The Future of Program API Standards

Getting Standards Adopted

What the Scores Mean

Glossary

Management Summary

Standards are about interoperability and lowering costs and, as a result, increasing adoption and use. The classic example is the standard railway gauge of 4 feet, 8 � inches or 1.435 meters that is based on the width of an Imperial Roman war chariot . As a result of this standardization trains built anywhere in the world could run anywhere in the world leading to the explosive growth of railways in the 19th century.

Standardization is just as important today. Once standards are either created or "just evolve", widespread adoption and use follows, for example Microsoft and IBM with the PC or the web browser with the Internet. More recently a similar "explosion" of use is promised through the use of Web Services technology and its use by businesses to lower the cost of integration and speed the flow of information within the business and with business partners. But as before, this will not happen until there is the necessary standardization.

But there is a huge amount of hype around Web Services and its standards such as SOAP, WSDL and UDDI Although they can be used successfully now within a business, they have limitations that mean that care must be taken before applying them more generally. To navigate through this maze, a Business must understand both the current state of standardization and what is likely to happen in the future in order to make better strategic and tactical decisions on what to do.

How the Business Web Services Scorecard helps

This paper helps by providing a "scorecard" of Business Web Services Standards. It is a guide that:

• Provides a framework that explains the different areas of Web Services that need standardization before businesses can realize the maximum benefit that Web Services technology will bring
• Describes the benefits that standardization in each area could eventually bring
• Identifies and assesses the major standards that have been developed in each area, and
• Offers likely developments in Web Services Standards in the future.

The results are summarized in a "scorecard" that provides a score for each standards area in terms of scope: have all the necessary standards been identified; maturity: to what extent are the standards fully developed and ready for use now; and adoption: are the current standards likely to be widely adopted. See the section on what the scores mean for more information on how each area is scored.

Web Services Standards Framework

The Web Services Standards Framework is a convenient way of grouping together the different standards that are needed. The diagram below provides an overview. More explanation is provided in a later section

The Current State of Business Web Services Standards

Complete development of the standards required for Web Services will probably take a total of about ten years to reach full maturity. In many ways this is a similar time scale to the time taken for the development of the HTTP and HTML standards - the basic standards on which the web as we know it today is built.

So how mature are Web Services standards at the moment?

The answer is probably about half complete as the diagram below illustrates.

Each of the areas in the diagram is described in detail in later chapters together with an explanation of what the scores mean Highlights are provided below.

Complex Web Services

Although SOAP provides the basic method used by Web Services for exchanging messages and is close to full maturity, additional standards, grouped under the name Complex Web Services, are needed to provide secure, reliable exchange of messages

ebXML Messaging meets most of this need and is mature with several implementations available. However its focus of meeting the needs of Business-to-Business integration (B2Bi) means that it is more complex than is necessary for use in non-business situations.

Partly because of this, alternative solutions to much of the functionality inside ebXML Messaging is being developed elsewhere, for example WS Security and WS Reliable Messaging that provide alternative but incompatible technology. There are also several competing yet near identical specifications from different vendors that have been developed, for example for reliable messaging Several of these specifications that come from major vendors such as IBM, Microsoft and BEA have intellectual property (IP) restrictions associated with them that prevent them from being used by others.

Development of "standards" by some of the major players who then restrict the standards to their own use, even temporarily, could potentially have major implications on the development of Web Services in the future see getting standards adopted for more details.

Conclusion: Although the scope of Complex Web Services is well understood, their current state of development is confused with several competing standards under development with restrictions on intellectual property rights that could have major consequences on the development of standards in the future.

Conclusion: Development of proprietary standards that are published yet have restrictions on their use is a cause for concern and could limit the development of open freely distributable solutions.

Definition Languages and Semantic Definitions

XML as a Definition Language to define the structure of business documents is very mature. However XML is like an alphabet, it allows words to be constructed that can then be strung together to make sentences that have meaning. XML though does not, on its own, have any meaning at all.

To fix this,semantic definitions are required to define both the business documents (the equivalent of the language) and also what the information in the documents means (the equivalent of a dictionary). Since XML is mature, many vertical industry groups have developed XML definitions of their business documents with a view to defining the standard for their industry.

The problem is that many businesses, particularly smaller businesses, cannot afford to implement the many different versions of an XML Order document, for example, that have resulted. It also means that the hopes of the vertical industry groups will likely be dashed. In many ways this is very similar to the experience with EDI that also did not realize widespread adoption in the lower levels of the supply chain due to it high cost.

Fortunately this problem is well recognized and work is underway in groups such as the UBL (Universal Business Language) activity in OASIS to develop generic definitions of the common business documents that can be used by anybody in any industry. Several vertical Industry groups are interested in UBL as it provides a sound base that they can use to develop their definitions.

Choreographies are definitions of the sequence in which businesses exchange documents. Agreeing these sequences is as important to interoperability as defining the structure of the messages themselves. For example if a buyer sends a supplier an order, the supplier needs to know how to respond. Should they: a) return an order response indicating the extent to which they can meet the order; b) just ship the goods and send an invoice or c) do something different. There will be problems if the buyer is expecting an order response but gets an Invoice instead.

Some work on defining choreography definitions was started by ebXML with the BPSS specification. However, as with ebXML Messaging, it has a focus that makes it harder to use outside of this context.

Work started in early 2003 within the WS-Choreography working group in the W3C to develop a more generally applicable choreography specification based on the Web Services Choreography Interface (WSCI) specification that had been developed by Sun, SAP, BEA and Intalio. Notable absentees from the WS-Choreography initiative were IBM and Microsoft. The reason why soon became clear when IBM, Microsoft, BEA and others in April 2003 set up another working group in OASIS to develop a language to define business processes based on the Business Process Execution Language for Web Services (BPEL4WS or BPEL) specification which is a rival to WSCI

However since publication of the first version of this paper The apparent competition, for a language to define business processes, between BPEL specification and the WSCI specification has passed as the WS Choreography working group in the W3C that was taking WSCI as its input is focusing on the development of a choreography definition language rather than a business process execution language

So far defining choreography instances, for example how to place an order, has been confined to individual vertical industry groups, such as RosettaNet, that have used written specifications and diagrams to describe the choreographies to be used within their business. Next to no work has been done to define generally accepted choreography definitions that can be used by anyone.

Conclusion: Good progress has been made on developing both the definition languages and semantic definitions for XML business documents although there is still much work to do on developing semantic definitions.

Conclusion: The work to develop a choreography definition language within the W3C has usefully separated its focus from the work going on in OASIS around BPEL4WS to develop a business process execution language, removing the anticipated rivalry between the two.

Conclusion: It is likely that within the next year, generally agreed definitions for the popular XML business documents required for use in a supply chain, such as definitions for an Order, will have been developed as part of the UBL initiative.

Conclusion: Choreography definitions, such as how to place an order, are much further behind and it will probably be several years before they reach a similar state of maturity.

Profiles, Policies and Agreements

In practice standards are always used in combination. For example before Web Services can be used to integrate businesses together or integrate the systems within a business, agreement must be reached on:

• Business Documents The format and structure of the business documents that will be exchanged
• Complex Web Services How those business documents are packaged up into messages that are sent reliably and securely between the systems and business involved, and
• Choreographies The sequence in which the messages are exchanged.

Even if standardization is reached on how Complex Web Services are used to deliver messages securely and reliably, the variations imposed by the differing needs of vertical industries and geographic regions mean that there will always be multiple different formats of business documents and the choreographies used to exchange them.

This could result in a large number of permutations of how standards are used together.

Profiles can help solve this problem by defining a specific combination or profile of how standards are used together therefore reducing the choices available and making interoperable solutions much easier to build and test.

However, very little work has been done on developing standard profiles or developing a definition language that allows them to be defined.

Even when profiles have been developed, there are still decisions that need to be made in an individual implementation for example deciding which digital certificates should be used to digitally sign a message Fixing this problem requires an implementation to define the policies that it will use when using Web Services.

As with the specifications for reliable messaging, Microsoft, IBM and others have developed some specifications (WS Policy) that allow implementation policies to be defined, however the specifications are proprietary and do not permit unrestricted use by others. Neither has there been any suggestion that they will be submitted to a standards group in the near future.

A business may have policies on how it will deploy Web Services. However, policies can be modified as a result of individual agreements made between a business and its partners. Although some work has been done within the ebXML initiative to develop agreements, they are not generally applicable to the use of web services in other environments.

Creating agreements almost always also requires a negotiation to create them. A negotiation protocol can save time by automating the process. However very little work has been done on this topic.

Conclusion: Standardization of choreography definitions together with standards for semantic definitions and Complex Web Services are the three most fundamental areas that need standardization. This means that in the short term use of Web Services will be restricted primarily to integrating applications together within the business, or outside the business on the basis of individual agreements

Conclusion: Lack of standardization around how to define and use profiles, policies and agreements means that developing interoperable solutions that are easy to build and test will be harder to achieve as manual effort will often be required.

Web Services Management

One of the foundations of Web Services is the idea that there is no need to know the technology used to implement the service or where the service is running. If you then go to the next step of composing new services or applications out of existing services then you need distributed management of the components or other services that were used to build the service so that the composed service can be managed as a whole.

Managing these Web Services needs to includes:

• Change Management , Managing changes, for example supporting new versions of a Web Service
• Operational Management , for example standards to enable the starting, stopping, status monitoring and fault reporting of Web Services and the servers they run on
• Service Level Management , to make sure that the Web Service and the servers it runs on perform in the way expected
• Auditing and Problem Resolution, so that, when problems do occur, they can be investigated more easily.

A lot of work has been done on distributed management generally, and with the start of the Web Services Distributed Management Technical Committee in April 2003 within OASIS good progress has been made especially in the areas of change management and operational management However it will probably be a few years before standards in this area become mature.

Conclusion: The problems with distributed management of services are well understood and good start has been made with the Web Services Distributed Management Technical Committee.

Registries

Before businesses can interoperate, they must share information that describes how they have agreed to work together. This can include: Business Document definitions, Choreography definitions, Profiles, Policies, Agreements and much more. Registries help by providing a store of the definitions of the information that needs to be shared.

Access to the definitions in the registry is required at:

• Design time, to help make sure that solutions are designed and built correctly, and
• Run time, to help ensure that Web Services operate correctly.

To make this work registry standards are needed to support discovery of information, retrieval of information and also the negotiation of agreements based on the information recorded in a registry

Standards are also needed to make it easy to publish the information in a registry as well as manage the exchange, replication and change management of the information in registries so that the information can be easily shared.

Currently there are two main standards initiatives that provide support for registries: UDDI (Universal Description, Discovery and Integration) and ebXML Registry Although UDDI is comprehensive in its support of discovery, retrieval, publishing and management of the information in a registry, it does not provide support for negotiation and it is also restricted in the different types of information it can store.

The ebXML Registry, by comparison is less comprehensive in terms of discovery, publishing and replication, but is more flexible in terms of the different types of information it can store. There has also been some convergence between the ebXML Registry work and UDDI within OASIS

Conclusion: Both UDDI and the ebXML Registry will not be complete until some of the missing standards described earlier are more mature. For example before a registry can be used for negotiation of agreements on how businesses would interoperate, you need to define how to use profiles, policies and agreements first.

Conclusion: Both UDDI and ebXML Registry were specifications that were developed quite early in the development of Web Services. This means that they have their own approaches to providing such things as security and reliability that will need to be replaced by more standard approaches resulting from work on Complex Web Services

Program APIs

Applications that want to use Web Services must create messages that conform to the appropriate Web Services standards. Typically Web Services Middleware is used to do this that provides convenient APIs that the application programmer can use. Program API standards help by providing application portability that makes it easier to move applications from one vendor platform to another.

APIs are very closely tied to the programming language and system/technology on which they run. For Web Services this means there are two main environments to consider: Microsoft's .NET and Sun's Java 2 Enterprise Edition (J2EE).

If Microsoft's .NET solution is chosen, then it effectively means that the Microsoft APIs must be used. As these APIs are likely to be only usable with Microsoft solutions, they are unlikely to become part of a separate standardization process and therefore are not considered in any detail in this paper that focuses on J2EE and its development as part of the Java Community Process (JCP).

Next, APIs are dependent, to a degree, on the development of related standards. For example, the development of an API to support reliable messaging is dependent on the development of a specification of how to do reliable messaging between two web services.

Conclusion: For Java, Sun's Java Community Process (JCP), provides an effective forum for the development of program APIs They have also developed several APIs that support Web Services. These are gradually being included into new revisions of the J2EE specification However, the dependency of API specifications on the development of Web Services standards means that it will be some years before the APIs will be mature.

What should businesses do now?

The previous sections provide an overview of the current state of development of the Web Services and related standards required to realize the implementation of low cost interoperable solutions for business.

Although the standards are not yet complete and will not be for some time, the business benefit and lower costs that occur when businesses use Web Services technology to integrate their systems are well established, particularly if the limitations of existing standards, in terms of the lack of secure reliable delivery of messages, are taken into account.

However, with the state of the world economy in 2003 and after the bursting of the "dotcom" bubble, it is very hard for any business to make an investment in new technology unless there is a quantifiable Return on Investment (ROI).

Web Services help businesses realize a better ROI by offering a lower cost of implementation when integrating systems together or building composite applications However additional costs will almost certainly be incurred with early implementations in order to update them later to make use of new Web Services standards as they mature.

This means that businesses should look for an approach to Web Services development and deployment that minimizes the total cost of ownership by providing an effective environment for implementing Web Services now whilst at the same time lowering the cost of evolving to new Web Services standards as they mature.

What are the key features to look for in a solution?

Firstly, the solution should recognize that the development of Web Services standards is not yet mature and include architectural features that allow new web services standards to be easily plugged in whilst seamlessly providing support for older versions of standards.

Secondly, the solution should record information about the standards used in an implementation in rules stored in a registry rather than hard coded rules in software as changing rules in a registry's database is always easier, faster and more reliable than changing code.

Thirdly, the solution should use the data in the registry to allow abstract APIs to be used that do not vary much if at all as standards evolve. As a result, it should be possible to implement new standards by only reconfiguring the information within the registry rather than reprogramming applications.

Fourthly, the solution should be able to record the rules in a central registry yet execute them in a distributed way so that the consistency that results from a single central definition is combined with performance, robustness and scalability that arise from a distributed redundant implementation.

What the rest of this paper contains

The rest of this white paper covers:

• What's changed. A summary of what has changed in the Business Web Services Scorecard paper and, more generally, using Web Services for Business, since this paper was first published in May 2003. Skip this section if you have not read this paper before.
• Web Services Basics Read this first if you are not already familiar with web services
• The Web Services Standards Framework This provides a description of each area of Web Services Technology that needs standardization. It is followed by sections that describe each area in detail:
• Complex Web Services These are a set of standards that provide functions such as securing messages and making sure that messages are delivered reliably
• Definition Languages These standards specify how to describe things, such as how to describe a business, how to describe a service, or how to describe a business document that is sent to a service
• Semantic Definitions These standards use the Definition Languages to define what actual things mean
• Profiles, Policies and Agreements These are standards that describe how other standards are used together or in a particular context
• Web Services Management These are a set of standards that make it easier to manage and control an environment that is built using Web Services
• Registries A Registry is a store of information that can contain definitions of things.
• Program APIs These are standards that provide standard program application interfaces (APIs) that programmers can use when developing applications.
• An overview of Getting Standards Adopted that describes the main factors that can affect whether or not a standard is widely used
• A description of What the Scores Mean, which describes how the scores on the scorecard were calculated
• Glossary This describes the terminology used in this paper and provides references and resources where more information can be discovered about the standards initiatives described.

How to provide feedback

This paper aims to be a fair, accurate and complete summary of where standards are needed to make Web Services work effectively for business. However it is possible some relevant standards have been omitted or you might think the opinions expressed on the current or future state of standards development are inaccurate. If you think this then please email the author on david@davidburdett.com so that your ideas can be included in future versions of this document.

If you want to be notified when new versions of this paper are available (approximately every 3 months), please register by sending an email with "subscribe" in the title to david@davidburdett.com

What's Changed

This section describes what's changed in using Web Services for Business since this paper was first published in May 2003.

So what has changed in using Web Services for Business since May 2003?

The short answer is not that much although there have been a few developments in a number of areas including:

• Complex Web Services
• Definition Languages
• Profiles, Policies and Agreements,
• Web Services management, and
• Registries

The changes in each of these areas are described below.

Complex Web Services

In Complex Web Services, new specifications (WS Context) have been published to handlecorrelating messages and maintaining contex about long running business transactions These specifications will be submitted to a standards group on a royalty free basis. The specifications also support a way of doing two-phase commit

SOAP 1.2 has also become a full recommendation. This means that the specification is in its final form. It is likely SOAP1.2 will very gradually replace the current version, SOAP1.1, in implementations although both will coexist for the foreseeable future.

Also development of the DIME specification has ceased. DIME was a specification that handled attachments, that was developed by Microsoft. Instead, the Proposed Infoset Addendum to SOAP Messages with Attachments or PASWA for short, was published by Microsoft, IBM and others which was used as the basis for a draft specification called the SOAP Message Transmission Optimization Mechanism (SMTOM) published by the group in the W3C developing the SOAP specifications. Both of these specifications propose the idea of defining, in a SOAP message as a single XML document, all the different parts that need to be carried in a message including attachments For more information see the section on Message Packaging

On Message Security, the WS Federation specification has been published This leaves just the WS Authorization specification to be published in the set of security-related specifications identified by IBM, Microsoft and others. However there is no news about either the intellectual property rights associated with these specifications or them being submitted to a standards organization for ongoing development.

Definition Languages

For Definition Languages, the Web Services Description Language version 1.2 is continuing to be developed However it now appears that it will not be backwards compatible with version 1.1 although it is a more flexible specification.

The apparent competition, for a language to define business processes, between the Business Process Execution Language for Web Services (BPEL4WS) specification and the Web Services Choreography Interface (WSCI) specification has passed as the WS Choreography working group in the W3C that was taking WSCI as its input is focusing on the development of a choreography definition language rather than a business process execution language

Semantic Definitions

Although progress has been maintained on existing initiatives, there have been no major new developments in Semantic Definitions

Profiles, Policies and Agreements

The main development in Profiles, Policies and Agreements is the publication for public review of version 1.0 of the Web Services Interoperability Organization's (WS-I) Basic Profile This means that the profile is very close to its final form.

Work is also going on version 1.1 of the WS-I Basic Profile specification. The main change in this version is support for attachments

The WS-I has also set up a group to provide a profile on how to use WS Security

The WS-I activity, since it has the participation of all the major vendors and if focusing on interoperability, is likely to result in profiles for the use of existing standards that will be widely implemented.

A section has also been added on discovery standards and security. This clarifies some of the difficulties associated with using key management to facilitate trusting the information sent by business partners when using web services over the Internet.

Web Services Management

Since the last version of this specification, the Web Services Distributed Management (WSDM) technical committee within OASIS, has reached full speed and there are several new developments.

Firstly, a set of requirements has been produced for change management and submitted to the WSDM technical committee. This means that work should start on a standard for managing changes to Web Services.

Specifications have also been submitted to the WSDM technical committee in the area of operational management

Registries

For Registries, very little of substance has changed since the last version of this paper was published. The main change has been the publication of the final version of UDDI version20

Program APIs

There have been no major developments in Program APIs although work continues on existing initiatives.

Glossary

There are also several additional or changed entries in the Glossary for: DIME, Key Management , Proposed Infoset Addendum to SOAP Messages with Attachments (PASWA), SOAP Message Transmission Optimization Mechanism (SMTOM), Taxonomy, TCP/IP, Web Services Management Framework, Web Services Transaction Management, WS Context, WS Events, WS Management, WSMF Foundation, and XKMS

If you have any questions or comments, please contact the author

Web Services Basics

A Real World Service

Web services are built around the idea of "services" that is very similar to the real world. For example consider the following situation where a small business owner is requesting a quote for the printing of business cards from a printer ...

The letter sent to the printer says ... "Please quote me for 5 boxes of 500 business cards in two colors as per this sample" ...

The letter sent in reply said ... "Each box of 500 will cost $35.67 plus sales tax, inclusive of delivery and it takes two days to dispatch once an order is placed" ...

This simple exchange represents a request (for a quotation), by the business owner for a service (printing of business cards) from the printing company. Before carrying this out the business owner needs to know:

• What to do What should be put in the request for quote so that the printing company can provide a full answer in their response
• Where to send it What address should be put on the envelope
• How to send it Should it be sent by regular post, a courier or perhaps using a fax?

The request for quote that the business sends is also made up of several different parts:

• The Envelope This is the "container" in which the documents, e.g. the request for quote, is placed
• The Document This is the content of the envelope, i.e. the actual piece of paper on which the request for quote is written
• The Letter This is the assembly of the Envelope and its document into something that is actually sent. How this is done will depend on how the letter is to be delivered. For example, national postal services such as the USPS, and companies such as FedEx and UPS each have different requirements for what the letter should look like
• An Address This identifies where the letter or package should be delivered. Often this requires looking up the address in an address book or a directory like Yellow Pages
• The Postal System This is the people, organization and equipment that actually deliver the letter or package. It can be an internal mail system, a national postal service such as the USPS in the United States, or a private carrier such as FedEx or UPS.

An Equivalent Web Service

Web Services, especially when used in a business context, work in a very similar way to the example above - but electronically. For example you need to know:

• What to do How do you create an electronic equivalent of a Request for Quote or the Quotation and place it in an envelope ready for sending
• Where to send it Where to send the electronic
message In this example it would probably be a web site operated by the printing business
• How to send it What technology to use to deliver the electronic Request for Quote to its destination - this is where the Internet comes in.

Web Services also provide exact equivalents to the lower level parts:

• The Electronic Envelope This is the electronic container into which electronic documents are placed. For Web Services this is a SOAP envelope
• The Electronic Document This is the electronic equivalent of a paper business document or instruction. It is typically defined using XML
• The Electronic Message This is the equivalent of the letter or package. It consists of an electronic document placed in an electronic envelope, for example an XML Request for Quote placed inside a SOAP envelope
• The Electronic Address This specifies where the message should be sent. It is often an Internet address (called a URL)
• The Software Delivery System This is software running at sender and recipient of the message that use the Internet for delivering the message. It takes the place of the Postal System to accept messages and deliver them to their final destination.

Real World vs. Web Services

So what are the fundamental differences between real world services and web services?

The biggest difference is the human factor.

Real world services involve humans at each end. This means that you can rely on the human who receives a message to interpret it and understand it even if they have never seen a request quite in that form before. If there is a problem, then they can just pick up the phone, talk to someone who sent the original and the problem is usually fixed!

Web services, on the other hand, involve one computer talking directly to another - but computers are dumb. Both computers at the sender and receiver need to know, in advance, and in detail, exactly what should go in each message, how to send it and where to send it. The computers also need to know what to do when things goes wrong. Without everything predefined and agreed in advance, web services won't work as expected and to fix the problem people will need to get involved.

Web Services Standards such as SOAP, WSDL, UDDI and others help solve this problem by defining standard ways in which computers work together so that they can interoperate.

So what are SOAP, WSDL and UDDI?

SOAP, WSDL and UDDI are the three Web Services Standards that are the foundation on which all the other specifications are built. So what are they and what do they do?

Simple Object Access Protocol (SOAP)

The Simple Object Access Protocol or SOAP is, at a very simple level, the equivalent of a blank envelope (i.e. without an address), delivered using a simple mail service. This means that:

• It provides a way in which you can put an electronic business document inside the SOAP envelope to create an electronic message
• It describes a way of delivering the electronic message to its destination using Internet technology.

The SOAP envelope consists of two parts:

• A SOAP Header which can contain additional information such as an electronic address, and
• A SOAP Body which contains the business document

What SOAP does not define though is:

• Addressing standards SOAP does not specify what an electronic address should look like
• Message Security SOAP does not specify how to secure a message to make sure it has not been tampered with
• Message Authenticity SOAP does not specify how to identify who sent a message
• Reliable Delivery SOAP does describe how to make very sure that the message gets delivered. This is equivalent to the services provided by companies such as FedEx and UPS that guarantee delivery, provide receipts and generally make sure that the message is delivered to the correct place.

Web Services Description Language (WSDL)

Web Services Description Language or WSDL, is just what it states, it's a description of a Web Service. This means that it describes:

• What the service does It describes the electronic requests that a service can accept and the electronic responses it can produce
• Where to send messages It provides addresses (called ports) which are the location to which messages should be sent
• How to send messages The address also indicates the methods to be used to deliver a request or a response, for example by email, or to a web site.

WSDL definitions of a Web Service can be used to help automate the creation of the software needed to send and receive messages - significantly reducing the software development effort and cost required.

What WSDL does not provide is:

• Semantics WSDL does not define what each request or response means, or what is formally called its "semantics". Without this understanding the software or application that generates a message won't know for sure what to put in a message and the application that receives the message won't know what to do with it!
• Long Running Transactions WSDL only allows you to define the way you interact with a Web Service as a simple request and a response. Real business is more complex. For example after placing an order, you might want to change it several times or cancel it. WSDL does not allow you to define these complexities
• Combining Services WSDL also does not tell you how you can combine multiple services with their individual requests and responses into a larger and more complex composed service or composite application This is very necessary as business is usually quite complex and often requires multiple interactions between partners and between the applications and systems within a business in order to do something really useful.

Universal Discovery Description and Implementation (UDDI)

Universal Description, Discovery and Implementation or UDDI is a way of defining a directory of businesses and the services they offer. The services can either be "real world" services or web services. Once created, the directory can be used for discovering services that exist and, for web services, their WSDL definition can be downloaded and used.

Some UDDI directories are "public" in that anyone can review the contents of the directory to find services they might want to use. Other directories can be private, for example to define the services that are used just within one enterprise.

Public UDDI directories have a number of problems:

• Inaccurate Data Anyone can put the data into the public UDDI registries that currently exist at the moment, for free - primarily because the current UDDI registry operators have no source of revenue to employ staff to check the accuracy and completeness of the data. This means that there are many gaps and inconsistencies, and the data is often out of date
• Authenticity As there are no controls over the data placed in UDDI directories it means that it is hard to know what data is authentic. This makes it quite easy for someone to pretend to be somebody else and put up incorrect data
• Agreements Real business is based on agreements between the parties involved so that all the parties involved know that messages received are authentic and that messages sent will be processed. UDDI does not help in the creation or recording of these agreements or any of the additional data, such as semantics, that are really needed in order to make Web Services work for business.

Private UDDI directories on the other hand can work well. If a Registry of WSDL definitions that software developers can use is set up, then the directory is completely within the control of the organization that sets it up therefore security and accuracy are less of a concern.

Web Services Standards Framework

This section provides an overview of the Web Services Standards Framework. The framework provides a structure that allows the many different web services standards required for interoperability to be put into a context.

The framework includes the basic standards of SOAP, WSDL and UDDI but identifies many more that are required before Web Services can really be used for business.

Note that this framework groups standards together into sections where each section describes standards that serve a similar purpose. It should not be confused with an architecture that identifies the different components that are needed to build a software solution.

Underlying Technology

At the lowest levels, there is the underlying technology on which all Web Services run. They are not part of the Web Services standards but are needed in order to make web services work. They include:

• The Operating System, such as Microsoft Windows, Linux, Sun's Solaris, IBM's AIX, etc
• Transport Protocols which are the standards, supported by the operating system that are used to transport messages over the Internet, such as SMTP for email and HTTP for connecting to web sites
• Application Server software that is designed to run applications. Included in this are: Microsoft's .NET server, IBM's WebSphere, Sun's iPlanet, BEA's WebLogic as well as open-source solutions such as Jboss and Tomcat.

Application server software sits between the operating system and the applications providing a uniform interface or API for application programs to use. One of the key components of an Application Server is support for the programming language that programmers use. For everyone but Microsoft, the main language they support is Sun's Java For Microsoft .NET their programming language support is based around the Common Language Infrastructure (CLI) that supports just about any language but Java.

Running on top of the Application Server, is the Web Services Middleware software that supports Web Services. This, in turn must support the various Web Services Standards in order to make them work which brings us to the main purpose of this framework.

The Framework

This section provides brief explanations of each of the parts of the framework. Later sections provide more detail.

The basis for all Web Services is the Simple Object Application Protocol, SOAP standard. This is the basic envelope in which all messages are sent to and from a Web Service. However SOAP has limitations as described earlier.

Complex Web Services

To remove the limitations of SOAP, additional functionality is required that is collectively described as Complex Web Services that enable SOAP messages to be sent securely and reliably.

Definition Languages

The next layer is the Definition Languages layer. The standards in this layer describe how to define things. Examples of things that need defining include: Business Documents, the Web Services themselves and the people and organizations that deploy and use them - plus many more! Without a clear way of defining information that needs to be shared, then interoperability will not easily occur.

Semantic Definitions

The Semantic Definition layer uses the Definition Languages layer to do two things:

• Define actual things, for example define the precise structure and content of an XML Order document
• Provide semantics that explain what the things being defined mean For example a shipment date could mean a requested, required, planned or actual shipment date depending on the context in which it is used.

Profiles, Policies and Agreements

The Profiles, Policies and Agreement layer contains standards for describing how standards are used together or in a particular context For example:

• Several different versions of an order business document are required to meet, for example, the needs of different vertical industries or localities, e.g. countries
• Several different transport protocols could be used to transport a message, e.g. HTTP and SMTP
• Several different Complex Web Services standards could be used, for example do you send a message reliably, securely or both.

A profile defines either:

• The subset of standards that should be used together, or
• How an existing standard should be used differently depending on the context, e.g. the vertical industry, location or business process

This makes building and testing an implementation easier as a solution does not have to implement all the different possible combination of options. In particular, it reduces the amount of testing required to make sure that solutions can interoperate.

Profiles, though usually still allow some choice. This means, that when a Web Service is used some decisions still need to be made to determine what exactly to do. A policy solves this problem by constraining how a profile is used in a specific implementation.

Even if an implementation has a preferred policy for how they plan to use web services it might clash with the policies adopted by their business partners. In this case, there is a need for agreement standards that specify how two (or more) businesses will amend their use of profiles and policies when interacting with one another. And if there can be agreements then you also need negotiation protocol standards to reach that agreement.

Web Services Management

Web Services also need management, they need to be: designed, developed, tested, deployed, used and eventually retired. Once they are actually being used, they need to be started, stopped, monitored, restarted, etc.

As Web Services can run on many different technologies, Web Services Management standards are needed that allow them to be managed, monitored and controlled no matter where they are run. This is particularly important when several Web Services operated by different organizations are grouped together to build a composite application

Registries

When web services are being developed and used, they need to have access to definitions of things, such as business document definitions and web service descriptions as well as access to definitions of the businesses and organizations that are actually using them. This information is typically stored in a registry Registry standards are needed, because the information they contain often needs to be shared.

Program APIs

Application Program Interfaces (APIs) are the way in which applications which do the useful work interact with infrastructure such as Web Services Middleware, for example to create an XML Order business document and send it in a SOAP envelope Standards are needed so that applications developed using one technology environment can be deployed on another.

Complex Web Services

Complex Web Services are a layer of technology that builds on top of SOAP to provide additional useful functions such as securing messages and making sure that messages are delivered reliably. A simple analogy would be to the services provided by companies such as FedEx or UPS to deliver securely and reliably, letters and packages.

How Complex Web Services Work

Most of the features in Complex Web Services rely on two main ideas:

• SOAP Header Information Carrying additional information in the SOAP Header for a SOAP Message that can be used by the recipient of a message to implement a feature, and
• A Protocol. This describes the behavior of the sender and receiver of the message indicating what they should do with the information in the SOAP Header

For example a very simple protocol could include in the SOAP Header, data requesting that the recipient of the message return an acknowledgement to indicate that the message was received. This would provide a simple form of reliable messaging

For example if a buyer was sending a purchase order to a seller they could send a request for an acknowledgement in the SOAP Message that contained the order that looked like this:

However this only works if the both the sender and the receiver of the message understand the SOAP Header and what to do with it when they receive it. Standardization of headers and the protocols that go with them will really help.

What Features Should Complex Web Services Support

The introduction to Complex Web Services provided an example of one simple header that could be used to request the recipient of a message to send back another message as an acknowledgement. There are many other features that benefit from standardization. They are grouped under the following six headings:

• Message Metadata Additional data that describes a SOAP Message and how it should be processed
• Message Packaging How to include one or more documents inside a SOAP Message
• Message Addressing How to specify the destination for a SOAP Message
• Message Delivery How to deliver a SOAP Message reliably
• Message Security How to secure the information in a SOAP Message

Message Metadata

Message Metadata is additional information about a message that can be used when processing it. The following different types of information, stored in SOAP Headers, are useful:

• Message Identifiers Message Identifiers are headers that provide a unique identifier for a message that can later be referenced, for example to retrieve a message after it has been saved
• Message Correlation These are SOAP Headers that indicate that a message is a response to an earlier message They work by including the earlier message's Message Identifier Message correlation can be used, for example, to tie together a message and its reply as in the acknowledgement message example described earlier
• Conversation Identifiers A conversation is a set of related messages that meet a useful business purpose. For example if a Conversation Identifier is added to a message sent to a supplier that contains an order, then, if a change order is sent some time later with the same Conversation Identifier, then the message can be passed to the correct application for processing without the Web Services Middleware having to open up the message
• Choreography Identifiers Strictly, a choreography identifies the sequence and conditions in which messages are sent and received when carrying out a business transaction For example there are many different ways in which a business can pay for goods: payment with order, payment on invoice, payment based on goods received. Each of these involves a different sequence of messages between the buyer and seller. Choreography Identifiers are used to identify exactly which sequence is being used.
• Agreement Identifiers The sender and receiver of a message may have agreed specific rules that they will follow when conducting a business transaction An Agreement Identifier can be used to identify which set of rules or agreement to follow. For example the parties in a business transaction may have agreed that some messages will be digitally signed for security whereas others will not. Agreements are also discussed later

Message Packaging

Message Packaging describes how to assemble all of the components of a message into the form that is sent "over the wire". Several areas will benefit from standardization:

• Message Envelope The Message Envelope is the one area that is really well standardized in the form of the SOAP Message that has been described earlier
• Transport Bindings Transport bindings are needed because the Internet has different transport protocols that are used to send messages, each of which has its own rules. This is similar to the way in which you can put an ordinary envelope with a letter inside a FedEx or UPS envelope before handing it to the courier for delivery - each envelope and the rules for its delivery are different. Examples of transport protocols include SMTP when sending a message by email and HTTP when sending it to a web server
• Attachments A SOAP envelope on its own can only handle a single document inside its SOAP Body Sometimes you want to send more than one. In this case you need to have rules on how to add the additional documents as attachments so that they can be sent together
• Message Manifests These SOAP Headers are like a table of contents for a message They are very useful if you are sending multiple documents in one message as they can be used to locate a document more quickly as well as make sure that all the documents that were sent were received.

Message Addressing

Addresses on messages serve a similar purpose to addresses on letters. For example they can be used to:

• Check that the message has been delivered to the correct recipient
• Work out how to route a message to its correct destination
• Identify alternative methods of delivery, if the original planned method did not work or was not available.

Message Addresses are usually contained in the SOAP Headers of a SOAP Message Useful address information includes:

• Logical Addresses A Logical Address is the direct equivalent of the name on an ordinary letter. It specifies who should receive the message rather than exactly where the message should be delivered
• Physical Addresses A Physical Address is the opposite of a Logical Address as it specifies exactly where the message should be sent rather than who should receive it
• Return Addresses A Return Address is the equivalent of a return address on a letter and identifies where the message came from and therefore, where details of any problems with the message should be sent. Return Addresses can be either a Logical Address or a Physical Address
• Address Routing An address route specifies the precise route that a message should follow in order to get from its origin to its destination. In many ways it is similar to the approach followed by postal services to determine the route that a letter will follow so that it can be delivered to the correct destination.

Message Delivery

Message Delivery includes the features that make sure a message was delivered and is processed properly. Useful features include:

• Delivery Receipts The essence of a Delivery Receipt is the recipient of a message sending back another message (the delivery receipt) to indicate that the message was received. If this is combined with Authentication, then it can be used to provide non repudiation
• Reliable Messaging Reliable messaging tries to make sure that a message is delivered by resending it until an acknowledgment or delivery receipt is received from the destination. At the destination, the recipient checks for duplicate messages to make sure that the message is not processed twice
• Message Sequencing Message Sequencing makes sure that messages are delivered in the sequence they were sent typically by including a sequence number in the message and taking corrective action to request the resending of messages if any are missing.
• Message Expiry The Internet can sometimes be unreliable. This means that messages can arrive long after they were sent. Message Expiry allows the sender of a message to say "don't process this message if you receive it after this time"
• Two Phase Commit A Two Phase Commit is a process by which two processes running at separate locations can synchronize what they do so that, at both ends, everything works or nothing works. It is based on the ideas of two-phase commit used when synchronizing data on distributed databases.

Message Security

Message Security is concerned with privacy and authentication and making sure that messages do not get altered when they are sent. It includes:

• Transport Security Although not strictly part of Web Services, Transport Security uses technology such as Secure Sockets Layer (SSL) to make sure that the contents of the message cannot be seen when it is being sent. It is the equivalent of securing the truck used to transport an ordinary letter. Once the truck arrives you can identify who secured the truck and be certain that no one saw the messages while they were being delivered. But, once the truck has been opened, the message is no longer secure.
• Digital Signatures Digital Signatures can be used make sure that a message has not been altered. it is like someone signing an open letter or a check as proof that it is genuine and has not been altered. The benefit of a digital signature is that it lasts so that the accuracy of the message is known even after the message has been transported and the content of the message unpacked. However digital signatures do not ensure message privacy as anyone can see what the message contains.
• Encrypted Messages Transport Security provides message privacy while the message is being sent. Message Encryption goes further and encrypts the message itself in much the same way that "spies" code their messages. The message can only be decoded if you have the correct "key".
• Authentication Authentication is the process of identifying who or what created or sent a message It is similar to looking at the credentials of someone who delivers a package or checking the signature on a letter to make sure it is genuine. On a SOAP Message, digital signatures are used be used to identify who sent a message
• Authorization Authorization goes one step further than authentication and checks a digital signature to determine who the sender was and then the authority of the sender to make the request that receiving the message implies For example a driving license can be used to identify someone (authentication), but it also indicates that the owner is "authorized" to drive. With a driving license, you trust the authority that issued the driving license checked that the holder is who they say they are. Similarly with a SOAP Message, authorization involves checking the digital signature on a message to determine if the recipient should act on it.

The Current State of Complex Web Services

For Complex Web Services, the outcome is mixed.

ebXML

On the plus side there are standards such as ebXML Messaging that provide a comprehensive set of standards for reliable secure transport of messages between businesses for which several proven interoperable implementations already exist.

On the down side, ebXML is not widely supported particularly by vendors such as IBM and Microsoft.

ebXML Messaging addresses most of the features described in this section except for: Choreography Identifiers, Physical Addresses, Return Addresses, Address Routing, and Two Phase Commit

ebXML Messaging is very focused on meeting the needs of Business-to-Business integration (B2Bi). As a result it is more complex than is necessary for use in non-business lightweight Web Service implementations, such as to connect securely and reliably between a personal computer and a cell phone. For these environments, the support provided in ebXML Messaging for defining the businesses involved in an interaction, the agreements to use and the ability to transport multiple documents in attachments is not needed, although they are essential for B2Bi

Alternative Approaches

Partly because of ebXML's B2Bi focus, alternative solutions for much of the functionality inside ebXML Messaging is being developed elsewhere, for example the WS Security and WS Reliable Messaging technical committees within OASIS

This means that the current state of Complex Web Services standards is very confused. Put simply, apart from Message Security, there are many overlapping specifications that provide alternative but incompatible ways of providing identical functionality. There are also a number of other specifications that have been published that come from major vendors, that have not yet been submitted to any standards organization yet contain intellectual property restrictions that prevent them being used by others.

Many of these overlapping specifications are described in the sections that immediately follow.

Message Metadata

Specifications for Message Identifiers and Message Correlation have been included as part of the WS Reliability specification which is the main input to the OASIS WS Reliable Messaging Technical Committee.

Message Identifiers and Message Correlation are also included as part of the WS MessageData specification published by BEA as well as the WS Addressing specification developed by IBM, Microsoft and BEA. Both of these specifications have intellectual property restrictions on their use and have not been submitted to a standards group.

More recently, Sun, Oracle, Iona, Arjuna, and Fujitsu have published the WS-Context specification. Which provides ways of doing Message Correlation that includes identifying the Web Services that are exchanging a set of related messages The authors state an intention to submit the specification to a standards organization on a royalty free basis.

Conversation Identifiers and Choreography Identifiers are currently not part of any activity although they might be identified as part of the WS-Choreography activity within the W3C

Similarly, Agreement Identifiers are not part of any current standardization activity.

Message Packaging

SOAP is the base Message Packaging standard used for all Web Services. The current versions are SOAP 1.1 and SOAP 1.2

SOAP version 1.2 became a full recommendation in June 2003. It is likely that vendors will now gradually start releasing solutions that support SOAP 1.2. It is likely that SOAP 1.2 will eventually displace SOAP 1.1.

Transport Bindings have focused on defining how SOAP can work with the transport protocols HTTP or MIME Bindings to other transports such as SMTP have also been defined.

For Attachments, the current main "standard" is SOAP with Attachments Although this has not followed any standardization process, it is a de facto standard that has realized widespread adoption.

The Direct Internet Message Encapsulation (DIME) specification that has been developed by Microsoft and IBM, offers similar functionality to SOAP with Attachments and has been submitted to the IETF as an Internet Draft However since this paper was last published in May 2003, there have been several developments in the way that attachments are handled.

Firstly, DIME is no longer being developed within the IETF and the original submission to the IETF has been allowed to lapse.

Secondly, an alternative approach to handling attachments has been developed by AT&T, BEA, Canon, Microsoft, SAP and Tibco called the Proposed Infoset Addendum to SOAP Messages with Attachments or PASWA This specification provides an approach for integrating XML and non-XML documents inside SOAP that is compatible with Soap With Attachments

Also, since PASWA's publication in late April 2003, the specification has been used within the W3C to develop the SOAP Message Transmission Optimization Mechanism (SMTOM) specification that provides a similar mechanism for handling multiple message parts within a single XML document.

At the same time the Web Services Interoperability Organization (WS-I) has been developing version 1.1 of its SOAP Basic Profile, which includes the handling of attachments

The net of all this is that the SOAP Basic Profile version 1.1 developed by the WS-I will, by the end of the 2003, probably be included in vendor solutions for handling attachments inside SOAP messages. At the same time the SMTOM specification is likely to be further developed, and will probably be finalized during 2004.

None of these approaches to handling attachments removes the benefit of having a Message Manifest or table of contents that allows an application to immediately understand what is in a message without having to process the whole message

The only work on Message Manifests is the WS SOAP Manifest specification developed by Commerce One. Although, this has not been standardized yet, it is available on a royalty free basis for use without restriction.

Message Addressing

The WS Reliability specification includes SOAP Headers that identify the logical address and physical address for the message The WS Addressing specification also provides SOAP Headers that identify logical addresses and physical addresses

A Return Address is included within the WS Addressing specification and is also included within the WS Callback specification.

Address Routing is provided by the WS Routing specification from Microsoft. This specification defines how to route a message through one or more intermediary SOAP processors. This specification has also not been submitted to any standardization activity.

Message Delivery

Delivery Receipts are included as part of the WS Reliability specification in the form of an acknowledgement message that is returned to the sender of the message Delivery Receipts are also provided by mthe WS Reliable Messaging and WS Acknowledgement specifications, neither of which has been submitted to a standards group.

The WS Reliability and the WS Reliable Messaging specifications each provide support for reliable messaging and message sequencing

Message expiry is supported by the WS Reliability specification.

Two Phase Commit is supported by the Business Transaction Protocol activity within OASIS and the similar WS Transaction specification developed by IBM Microsoft and BEA. The latter has not been submitted to any standards organization.

Two Phase Commit is also one of the ideas supported by the Web Services Transaction Management (WS-TXM) specification developed by Arjuna, Fujitsu, IONA, Oracle and Sun. However this specification can also be used to handle the compensatory actions that a business must take when a business transaction it is participating in fails.

Message Security

Secure Sockets Layer (SSL) is the well-established technology for providing transport security over HTTP The XML Signature specification developed within the W3C and its related specification on Canonical XML are the definitive standard for generating digital signatures using XML There are also standards for encrypting XML (XML Encryption) that have been developed in the W3C All these standards are mature and stable.

However XML Signature and XML Encryption do not define how they should be used with Web Services. This problem is being addressed by the WS Security activity within OASIS that has developed a specification that describes:

• How SOAP messages should be digitally signed and/or encrypted, and
• How their authenticity is determined by attaching security tokens to a message

The Liberty Alliance is an initiative that is specifying how to determine the identity of businesses and individuals that can be used to determine the Authentication of SOAP messages

IBM, Microsoft and others have developed additional message security related specifications that address: establishing trust relationships (WS Trust), establishing a secure context for exchanging SOAP messages (WS Secure Conversation), brokering trust between organizations (WS Federation), and management of authorization data and policies (WS Authorization).

With the publication of WS Federation in July 2003 only the WS Authorization specification remains to be published.

None of these specifications have been submitted to a standards group.

The Future of Complex Web Services

So how is this likely play out?

Over the next few years ebXML Messaging could become popular for B2B integration (B2Bi) or Enterprise Application Integration (EAI) where messages are being sent over the insecure Internet. The reasons for this are:

• It is working now - there are several ebXML Messaging solutions that exist, although IBM and Microsoft do not actively endorse and rarely mention ebXML
• Several vertical industry associations (e.g. AIAG and UCC) as well as governments (including the UK and Australia) are endorsing its use
• Competing specifications for secure reliable messaging are immature.

At the same time basic SOAP will be used within the enterprise since:

• It is fit for purpose - if you are not worried about the secure reliable delivery of messages
• It is working now - there are effective solutions available from many major vendors
• There are toolkits and development environments available that make it easier to develop and implement than solutions that use ebXML

On the other hand the non-ebXML specifications that address Complex Web Services are many and overlap with each other. Several also contain intellectual property restrictions that could prevent their standardization.

Eventually though, specifications such as WS Security, WS Reliability and others will mature and result in a "battle" with ebXML Messaging for the B2Bi space. However it is not clear who will win. So what are the factors that could influence the outcome?

If ebXML Messaging realizes significant adoption for example if big business and particularly governments mandate the use of ebXML Messaging, then it will be hard for it to be completely displaced - if a solution is not broken, why fix it?

If significant adoption does occur, then IBM and Microsoft will probably more actively endorse and support ebXML Messaging once their customers start demanding it.

Bottom line? There will probably be a stalemate where both ebXML Messaging and other specifications coexist for some time especially as the non-ebXML Messaging solutions are in a confused state. This is quite unfortunate from a standards perspective, as it will add to implementation complexity.

Definition Languages

Definition Languages specify how to describe things, such as how to describe a business, how to describe a service, or how to describe a business document that is sent to a service

Why definition languages are needed

There are two reasons why standard Definition Languages are needed:

• Shared Information The information that is used by Web Services often needs to be shared because it needs to be agreed. For example, before a supplier can accept an electronic order from a buyer, the buyer and supplier need to agree the structure of the order and the details of what the order will contain.
• Reusable Technology If standard definition languages are used to create definitions then a single set of technology can be used to process them. For example if all business documents are defined using XML, then you only need XML technology to generate or process any of them.

Definition Language Profiles

Sometimes definition languages are multi-purpose for example XML can be used to define both business documents (e.g. UBL), as well as mathematical expressions (e.g. MathML). This can result in definition languages that offer more choice than is needed on how to implement particular features.

When this happens a definition language profile can be useful to constrain what the definition language does. For example XML Schema is a very powerful language for defining XML documents. However the needs of XML business documents are much simpler, so a profile on how to use XML to define business documents is useful as it makes it easier to create reusable technology.

What Definition Languages are needed

As said earlier, definition languages are needed whenever information about things needs to be shared and agreed. So what information needs to be shared?

In general there are three main types of information that needs to be shared:

• Organization related This includes languages to define businesses, roles, users and categories
• Process related This includes languages to define business processes, choreographies and services
• Data related This includes languages to define business documents, messages and transformations (maps)

Organization Related Language Definitions

Organization related definition languages that benefit from standardization include:

• Business/Organization definitions These are languages that define standard information about a business or organization that can be used for search and discovery. It can include definitions of the structures for names, addresses, locations and contact information.
• Role definitions When businesses interact they usually take on a particular role For example the roles of buyer and seller when purchasing something. Clear definitions of the roles that business play, what the role means and how that role is identified is useful. A business can take multiple roles at the same time but usually in any individual business transaction they only take one.
• User definitions Often the origin and destination for messages are individual people. Standard methods of defining users allow information about them to be shared between systems that need to know them. Information that needs to be kept about Users includes: names, addresses, email addresses and contact information as well as the roles, responsibilities and privileges a user may have to access computer systems or carry out business processes
• Categorizations In business, you often need to be able to search for information, for example a business, a user, etc. Many different types of categorization are useful, for example by geography or by type of services provided (for businesses). To be really useful, categorizations need to be based on standard taxonomies Although categorization is most often used to identify businesses and the services they provide, it can also be used elsewhere, for example to identify a business document definition that is used in a particular vertical industry.

Process Related Language Definitions

Process related definitions languages that benefit from standardization include:

• Service definitions A service executes a process within a business and does useful work by processing input and generating output. For example, a Sales Order Management Service could accept orders and provide an order response in return. In providing the response the service could do several activities or sub-processes such as checking stock levels, prices, credit checks etc.
• Business Process definitions Most processes in a business involve the execution of several sub-processes involving multiple systems both within, and often, outside the business. A business process definition defines the sequence and conditions in which the processes within a business are executed. A business process can, but need not, be used to define the sequence of actions used to implement a service For example it could define that the processing of an order involves, credit authorization, stock availability checks, delivery scheduling, etc.
• Choreography definitions A business usually has a lot of control over how its internal business processes work. In fact "better" internal business processes, are often used as a means of providing competitive differentiation. However this control disappears as soon as a process interacts with other processes outside the business. In this case, each business has to agree with the other businesses how they will cooperate. For example if a buyer sends a supplier an order, the supplier needs to know how to respond. Should they: a) return an order response indicating the extent to which they can meet the order, b) just ship the goods and send an invoice or c) do something different. Choreography definitions solve this problem by defining the precise sequence and conditions in which messages are exchanged between cooperating businesses or processes.

Data Related Language Definitions

Data related definition languages that benefit from standardization include:

• Document definitions These describe how to define the structure of business documents, for example an order, invoice, etc. Both the sender and receiver of a business document must understand its structure and the meaning or semantics of what it contains.
• Message definitions Electronic business documents are always sent inside an electronic envelope, e.g. a SOAP envelope, for transportation. Sometimes multiple documents need to be sent at the same time using attachments Message definition languages describe how to define the structure of a message. They include use of: the SOAP envelope, SOAP Headers or extensions for Complex Web Services and how they are bound into a transport protocol
• Transformation (map) definitions Until Document Definitions and Message Definitions are standardized, there will be a need for rules to describe how to transform a document or message constructed according to one definition into the format of another. A transformation (map) definition language defines how to describe a transformation.

The Current State of Definition Languages

The definition language that is the foundation for all other Web Services specifications is XML in both its original format, XML 1.0, and as XML Schema It is used either directly, for example to define a business document such as an order, or indirectly, for example to define the structure of a definition language such as the Web Services Description Language, WSDL

Organization Related Language Definitions

There are probably as many ways of defining a business/organization as there are XML business document standards since most vertical industry groups that are developing business document definitions also define structures to record information about a business such as: names, addresses, locations etc. Few of these are completely compatible (but see the next section on Semantic Definitions). Similarly there is no agreement on how to define roles, users or categorizations which will make automated searching harder to do.

Perhaps the closest to a standard for business definitions and how to categorize them is UDDI However, UDDI is not being relied upon widely as it is not currently very suited for this purpose due to concerns over security and data quality described earlier

UDDI has also been the main forum for developing ways of categorizing information although, as stated earlier it has not been widely adopted.

Work has also not been done to define standard ways of defining roles, although not much more is needed than a name, an identifier and an good description.

Process Related Language Definitions

Web Services Description Language (WSDL) version 1.1 is mature in the way that it defines web services in terms of the input and output messages, and the destinations (called ports) to which messages are sent. It has also received widespread support as a format for generating software stubs to simplify and speed the creation of software that can invoke a Web Service.

Version 1.2 of the WSDL specification is also being developed and is making good progress although there are many differences with version 1.1 that means it is unlikely to be backwards compatible with WSDL 1.1.

However more work is needed on both these specifications so that they can record some of the policies and profiles that a service supports. This is likely to require co-operation between the work being done within the WSDL working group within the W3C and the specifications such as WS Policy that has been published by BEA, IBM, Microsoft and SAP.

There are several business process definition languages including Business Process Execution Language for Web Services (BPEL4WS) developed by BEA, IBM and Microsoft, and Web Services Choreography Language (WSCI) developed by BEA, Intalio, SAP and Sun. These two languages are very similar with BPEL4WS being announced about one month after WSCI in the summer of 2002.

There are also other choreography definition languages that have been developed such as the Business Process Schema Specification (BPSS) developed as part of the ebXML initiative. BPSS though is focused primarily on B2Bi and is less applicable to other contexts e.g. EAI As with ebXML Messaging, BPSS is also tied closely to the other ebXML specifications and is not easily used with the other Web Services specifications.

WSCI was also stated as the main input to the WS Choreography activity that started within the W3C in early 2003. Notable absentees from the WS-Choreography initiative were IBM and Microsoft although Microsoft turned up for the first meeting of WS-Choreography only to promptly leave.

The reason why Microsoft left soon became clear when IBM, Microsoft, BEA and others in April 2003 set up another working group in OASIS to develop the BPEL specification they had earlier developed.

Although it would appear that there are two competing business process definition standards activities in the W3C and OASIS as well as two competing Business Process specifications. At the time of writing (late July 2003), several meetings of both the BPEL and WSCI groups have been held, and it would now seem that the WS Choreography group seems to be focusing more on the development of a choreography definition language and the BPEL group on a Business Process definition language This means that the two specifications should be much more complementary.

For more explanation on why there are competing standards initiatives see the section on Getting Standards Adopted

Data Related Definition Languages

Data related Definition Languages are the most mature of all the definition languages, probably because XML, the foundation for all definition languages, is ideal for defining them directly. XML Schema adds further power by defining what can validly be placed in each field in a document as well as allowing for extensibility so that you can define how one document or element within it is based on another. These definitions can then be used at run-time to validate an instance of an XML document.

The WSDL specification allows the messages used by a service to be defined. However, sometimes, you can have the same message used by different services for different purposes so there will be benefit if there is a way of defining a message separately that WSDL can then reuse. Currently there is no separate definition language for messages

The only existing "standard" for transformations is Extensible Stylesheet Transformations (XSLT). This standard is very powerful and flexible and was originally designed for formatting XML documents into something that could be viewed by a person, e.g. an HTML document on a web browser. However this power makes it less than ideal for use in business document transformations, as most current XSLT implementations store the complete XML document in memory. This results in relatively low upper limits on the size of documents that can be processed. This is a significant limitation given that business documents can sometimes be large - at least several Mb.

The Future of Definition Languages

So what happens next?

The use of XML as the basis of all definition languages is assured, especially since XML Schema provides a solid, though somewhat complex, foundation.

Development of the rest of the standard definition languages is unclear since the work is being done in several different forums without any formal over-arching structure that unites them all together and provides a context of how one relates to another.

The one activity that might be able to bring all these different threads together is the Web Services Architecture (WS Architecture) at the W3C although this is far from completing its work and is trying to meet the needs of the web as a large information resource as well as a means for conducting business.

Completion of all the necessary definition languages is therefore probably several years away.

Semantic Definitions

Semantics define the meaning of things. For example what does a Customer Id in an order mean. Is it, for example, the identifier the seller uses to identify the customer or is it the one used by the customer to identify itself? Unless there are precise definitions of what fields such as these mean, then there can be misunderstandings and successful interoperability will be hard to achieve.

Similarly if a message is sent to a service, then the sender needs to know what sending that message will mean. Sending an invoice to a business could mean, for example: "please pay the amount specified in the invoice for services and products provided" but it could just as easily mean "please calculate the tax and customs duties due on this invoice, then return the invoice so that it can then be sent to the customer"

Why semantic definitions are needed

To solve these types of problems semantic definitions are required for two main reasons:

• Shared Understanding Without a precise shared definition of what things mean then there will be confusion. This applies to integrating information within the business where existing systems have different structures for data and definitions of what things mean. It also applies even more outside the business where often no single business is in control and the need for a shared understanding of what things mean is even more important.
• Reduced Information Loss Shared understanding can be achieved by each company creating its own definitions of what things mean, but if you take the next step and agree on standard semantic definitions, then interoperability becomes much easier to realize, as there should be less need for transformations of data when exchanging information.

Standard Semantics vs. Standard Representations

The next useful step is to agree on standard representations of the semantic definitions While not strictly necessary, adoption of a standard representation would mean that transformations from one format to another are completely avoided. For example the ISO currency codes for the US dollar, the UK pound and the Euro can be represented by the codes "USD", "GBP" and "EUR". But they can also be represented by the numeric codes: "840", "826" and "978". These code lists are directly equivalent so there is no loss of information. However if one business uses the alpha codes and the other numeric codes, then transformations will still required when exchanging information.

Standard Representations don't apply just to codes. They can also apply at multiple different levels including the tags used for fields in XML documents and standard structures for the documents themselves.

The Role of Context

Semantic definitions can also vary depending on the context in which the piece of information is being used. For example a date is always a date and identifies a particular day in a year. However the meaning of a date can vary depending on where the item is being used. For example a "shipment date" is the date on which a shipment is made and a "sell by" date is the date by which a product should be sold.

Even this can be further qualified depending on the purpose for which the data is being used. For example in a planning document a shipment date could be a date that identifies when the buyer is requesting the goods be shipped. Later, in an Advanced Shipment Notice, it would be the date set by the supplier that identifies when the supplier plans to deliver the goods, then, later still in a Delivery Note, it would be the actual date the goods were shipped.

What Semantic Definitions are needed

Potentially any of the things that can be defined by a definition language could benefit from having standard semantic definitions So semantic definitions fall into the same areas of:

• Organization related These include standard semantics for roles and categories
• Process related These include standard semantics for services, business processes and choreographies
• Data related This includes standard semantics for messages and business documents

Organization Related Semantic Definitions

Organization related semantic definitions that benefit from standardization include:

• Role Definitions The definitions of what is meant by such roles as Buyer, Seller, Payee, Payer, might be quite intuitive, but once you start referencing slightly more obscure definitions such as Payment Authority, Requisitioner, etc, then a clear and agreed definition of each role is very useful.
• Categorizations Categorizations are mainly used for searching and identification. For example, find all the providers of logistics services within 50 miles of Paris, France. Most of the existing search registries require human involvement, but standardization of the way in which the information is categorized would allow for easier automated searching.

Process Related Semantic Definitions

Process related semantic definitions that benefit from standardization include:

• Service Definitions All services have an interface that describes how you interact with them. In a business context, these services are often a "window" into the business that allows business documents inside messages to be sent and generated. Standardized service definitions help as they reduce the cost and effort required to interact with a service since structures and patterns of interaction developed for one situation can be reused.
• Business Process Definitions Business processes are internal to an enterprise. In fact different internal business processes are often used by a business to provide a competitive differentiator through either lower costs or better customer service. Standard or template process definitions help as they can be used as examples of "good business practice" in terms of how a business of that type should work. Formal definitions of business processes also make it easier for a business to define the business process once and then replicate that process over many locations.
• Choreography Definitions Internal business processes are constrained by the interactions they have with other businesses. For example, many parts of the auto industry make payments based on goods received rather than invoices. If a business has to support many different ways of doing business then it makes it harder to automate, as the internal business process needs to change. Standardized Choreography Definitions help, as they limit the number of different variations a business will need to support in their solutions.

Data Related Semantic Definitions

Data Related semantic definitions that benefit from standardization include:

• Document Definitions As with choreography definitions, if each business, or even each industry develops its own business document definitions, then each implementation will need to use a transformation map so that they can convert internal formats into the format used by each industry. This will increase the cost of implementation and therefore reduce the rate of adoption.
• Message Definitions Standard definitions for messages, i.e. the envelope and the documents it contains, also help as they lower the cost of implementation. If standard envelopes and messages existed in the real world, then it would be the equivalent of giving a package to FedEx who then, half-way through the shipment, hands-off the package to UPS to complete the delivery.
• Transformation (map) Definitions Current implementations have many different business document and message formats. Standardized Transformations between any pair of documents helps as they make sure that the transformation is always done the same way by different implementations.

The Current State of Semantic Definitions

EDI was the first major attempt at creating semantic definitions for use in business. It also achieved success with larger businesses in vertical industries where large companies could persuade the smaller companies within their industry to follow their approach. However EDI was never widely adopted by smaller businesses, as many could not afford the technology required especially as they often had to support multiple different standards for the multiple vertical industries in which they took part

So where are we today?

Organization Related Semantic Definitions

Little effort has been made to define roles, although several definition languages such as the Collaboration Protocol Agreement (CPA) and Business Process Specification Schema (BPSS) within ebXML have identified the need to define them.

UDDI has developed standard taxonomies for identifying businesses and services based on codes such as UNSPSC and NAICS as well as proprietary codes developed by Dun and Bradstreet and Thomas Register. However, as stated earlier, there are data quality issues over the public UDDI registries that mean that these taxonomies are not widely used in connection with Web Services.

Process Related Semantic Definitions

There are no widely developed standard definitions for services or business processes

Choreography definitions tend to be limited to specific vertical industry initiatives such as RosettaNet However the lack of a standard choreography definition language means that even if standard choreography definitions existed, they are not directly usable in an automated way to validate that a business is following the choreography correctly. The ebXML initiative has developed a business process catalog that identifies a set of standard process definitions although this is not widely implemented.

Data Related Semantic Definitions

With the advent of XML, more work has been done on standard business document definitions than any other area. Much of this work has been done within vertical industry groups such as RosettaNet (high-tech), PIDX (petroleum), ACORD (insurance) and many others although there are some cross-industry initiatives such as OAGI Most of these definitions, even though they all use XML as the definition language, have different structures and often, different semantics This means, for example that a RosettaNet Order will not map to a PIDX order without some loss of data.

Unless this changes, it will mean that smaller businesses that often work in multiple different industries, will have to use transformations to support all the business documents that their customers ask them to use. As support for a large number of transformations is both time consuming and expensive to implement, it is likely to mean that adoption of XML and web services for business will be slowed.

Probably the initiative that promises to address this problem most directly is the Universal Business Language (UBL) initiative that is developing a set of simple business documents that should be universally applicable.

Although a lot of work has been done on defining standard envelope structures such as SOAP, little work has been done on how standard business document formats and envelopes structures are combined to create messages Several vertical industry groups such as RosettaNet have identified message formats that include both the document and envelope definitions, however they do not use SOAP Other vertical industry groups such as UCC Net have specified use of ebXML Messaging together with their own vertical industry business document formats. The idea of specifying how to use different standards in combination is discussed later in the section on Profiles, Policies and Agreements

No publicly available transformation maps for business documents are available. Generally they tend to be built into proprietary mapping software.

The Future of Semantic Definitions

So what happens next? To realize interoperability at an economic cost, two main types of semantic definitions must be standardized:

• Business Documents, because this is the data that gets exchanged, and
• Choreographies as agreement is needed on the sequence in which data is exchanged.

All the other standard semantic definitions, although they offer efficiency benefits, are not the barrier to widespread adoption that these two areas represent.

Good progress is being made on the definition of standard business documents as the UBL initiative has the support of many vertical industries and governments and is likely in the near future, to be adopted by one of the major international standards groups such as UN/CEFACT or ISO

Work on standard choreographies is the natural next step although no work has yet started and, once started, it will probably be several years before it is complete.

Profiles, Policies and Agreements

Profiles, Policies and Agreement are standards for describing how other standards are used together or in a particular context For example:

• Several different versions of an order document are required to meet, for example, the needs of different vertical industries
• Several different
transport protocols could be used to transport a message, e.g. HTTP or SMTP

Why Profiles, Policies and Agreements are needed

Even when individual standards have been finalized, the number of different ways in which standards could be combined will still be huge. In practice, this will mean that businesses, particularly smaller businesses, are unlikely to be able to economically support all the different variations they will be asked to. As a result, widespread interoperation of web services to support business and eCommerce is less likely to occur.

What Profile, Policy and Agreement Standards are needed

Profile and Policy Standards - Using standards in context

To reduce the number of combinations that are required, further sets of standards are needed:

• 
  
Profile Definitions These can further divided into
• Context Profile definitions These define how a standard is used in a particular context, for example how to adapt a generic invoice to use it in the chemical industry in the US
• Combination Profile definitions These define how standards are used in combination For example the particular combination of business documents, choreographies, services and Complex Web Services standards used in the US chemical industry
• Policy Definitions These define how a standard or profile are used within a specific implementation. Policy definitions are needed because profiles can only go so far. Profiles cannot provide implementation specific information such as which digital certificate to use when digitally signing a message or where messages of a particular type should be sent. However this information can be recorded in a policy definition.

Profile Definitions

Profile Definitions are particularly useful in two main cases: a) when an industry wants to reach agreement on how the members of their industry will interoperate, or b) to handle the different business document formats and choreographies that apply in different geographies.

Areas where context profiles need to be defined include:

• Document definitions The content of a business document varies depending on location, industry, the business process being used etc. For example, VAT is required on Invoices in Europe and Sales Tax in the US, and flight segment information is often required on line items in an Invoice for the travel industry, but probably nowhere else
• Choreography definitions The way businesses interoperate also varies by location and industry. For example, unlike many other industries, large parts of the auto industry do not use invoices to request payments for the parts manufactured by third parties that are used to build cars. Instead, payments are made based on goods delivered and accepted at the factory gate. On the other hand, when buying office products, an auto manufacturer is as likely as any other business to just send a purchase order and pay when the invoice arrives and has been checked.
• Complex Web Services The way the standards that make up Complex Web Services are used can also be usefully agreed, depending on why they are being used. For example messages used by eCommerce, will often need to be digitally signed and sent using a reliable messaging protocol. On the other hand, messages sent from a cell phone to a PDA do not.

Profile definitions are most useful when deciding what standards to support in an implementation. For example, if a vertical industry agrees on a particular combination of business documents, choreographies and Complex Web Services to use, then a business that participates in that industry will then know which standards they need to support in order to participate fully.

However, no business operates entirely within its industry. For example all businesses need to buy office products and other every-day materials. This means that there will be significant benefit if there are a few widely adopted generic profiles that are supported by many software installations so that any business can "do business" using web services with any other.

Policy Definitions

Whereas Profile Definitions provide guidance on what standards to implement, they can still leave some choices to an individual implementation. They also cannot always provide all the information needed before a standard can be used. To fill this gap, more information is needed that needs to be recorded in a policy definition that describes, for example:

• Message Security Before a message can be digitally signed, you need to know which digital certificate to use.
• Message Delivery Some profiles may leave the use of Reliable Messaging or other delivery mechanisms as an implementation choice, in which case a policy decision needs to be made and recorded by an implementation that describes to actually do.

Negotiation and Agreements - agreeing what to do

Even if an implementation has preferred policies for how they plan to use web services for business, it might clash with the policies adopted by their business partners. In this case, yet more standards are needed:

• Agreement definitions Agreements specify how two (or more) businesses have agreed to amend their use of profiles and policies when interacting with one another.
• Discovery standards These are standards that allow you to discover and distribute information about policies, profiles as well as other information about how a business uses web services.
• Negotiation standards These are negotiation protocol standards that permit automated negotiation of agreements once profile and policy information has been discovered.

Standard ways of defining agreements are useful because, once an agreement is reached, the agreement can be recorded and shared between the businesses involved to help ensure that interoperation is achieved.

A standard negotiation protocol is useful as it can automate the setting up of the connections that are required once two businesses have made the decision to interact. This will increase speed and accuracy with which the connection is made. However, it is unlikely to completely remove the need for human involvement in the decision to do business in the first place.

Discovery standards involve accessing registries that store the information. Registries are covered in more detail in a later section

Discovery standards and security

Although discovery and profile/policy distribution standards can be useful in speeding the setting up of how businesses connect, there is a problem in that the distribution needs to be controlled and kept private as often a business will want to authenticate who is requesting the policy information before providing it. This authentication will often use messages that are digitally signed and encrypted so that a recipient of the message can validate who sent it and be sure that the request cannot be seen by others unless authorized. This in turn means that the recipient of a message must have access to the digital certificate that the sender of the message used to sign the message and the sender of the message must have access to the digital certificate that the recipient of the message wants them to use to encrypt the message.

There's a catch 22 here as these digital certificates are themselves policy information belonging to the sender and receiver of the message. This information also needs to be distributed. To solve this problem key management standards are needed to facilitate the distribution of the digital certificates

Practical Implementation of Profiles

There are two basic ways in which a profile can be created:

• By Restriction - this means that you identify a subset of the standard that is used in a particular context, or
• By Extension - which means that you extend the standard by adding in extra information to use in a particular context.

If only restriction is being used, then it assumes that everything that you need in the standard is already present and therefore developing a subset will be sufficient. For example if an Invoice definition existed which contained all the fields that would ever be needed by all industries in all locations in the world then you could, in theory, identify the subset.

Clearly this is impractical. Therefore the better approach is to identify the subset that most businesses in most industries need and then extend it where necessary as the need is identified. If the initial small subset is also actually useful and works, in many circumstances, then you have a base standard for interoperability that all businesses can use for many transactions no matter what the context.

The areas where this type of minimalist standardization is most useful includes: Business Documents, Choreographies and the use of Complex Web Services as, without, standardization in all of these three areas, basic interoperation between different businesses is not possible.

Describing Profiles

Given the variability that necessarily exists in how standards are used in a particular context or combination, there will still be multiple profiles that a business will need to understand and support. To help solve this problem two further standards are useful:

• A Profile Definition Language which identifies how individual standards have been constrained/extended in a particular context as well as how standards are used in combination, and
• A Profile Identification Standard This simple standard would identify the profile that was being followed in an individual message

The benefit of this approach is that if the definition of a profile is available when a message is received, it can be analyzed to automatically determine if the message conforms to the profile and so can be processed. Further, if each of the individual components of a profile are supported by the recipient, the recipient may still be able to successfully process the message even if profile had never been seen before.

Combining profiles together

The diagram below illustrates the way in which different types of profiles could be combined together.

The top half of this diagram provides an example of how different combinations of base web services standards and Complex Web Services standards could be combined to define a profile for use in Business-to-Business integration (B2Bi).

The bottom half of the diagram shows how Business Document, Choreography and Service Definitions could be adapted for use in a specific business context and then combined with the B2B profile to provide a complete definition of how to do B2B within an industry.

The Current State of Profile, Policy and Agreement Standards

Very little work has been done on the development of profile and policy standards. A little more work has been done on agreement standards.

Profile definitions

One of the main activities that is developing a profile definition is the Web Services Interoperability Organization (WS-I) initiative. This initiative is developing a Basic Profile of how 11, 11 and 20 should be used together with the specific objective of improving interoperability.

Version 1.0 of the Basic Profile was published for public review in July 2003. This means it is likely to be finalized in the fall of 2003. In parallel with this version 1.1 of the Basic Profile is being developed. The main addition to this is the support for attachments that the version 1.0 profile did not support.

The WS-I group has also set up an activity to develop a WS-I Basic Profile Security WG. The focus of this group is to define a profile of how the WS Security specifications should be used.

The specifications produced by the WS-I organization are likely to be widely implemented, since the WS-I has the participation of all the major vendors and also includes interoperability testing.

However it should be noted that new versions of SOAP, WSDL and UDDI are all quite close to finalization. This means that the WS-I Basic Profile will need to be updated once they are complete.

Another initiative that is working on enabling profile definitions for business documents is the Universal Business Language (UBL) initiative within OASIS This has developed a business document standard that consists of a set of minimalist, but useful, definitions of business documents for eCommerce, together with a process by which those business document definitions can be extended depending on the context in which they are being used. The business documents have been constructed out of small individual components that help ensure, for example, that the definition of common structures such as name, address, line item, etc, is the same in all the documents. They have also identified the need to develop a methodology that allows these minimalist definitions to be extended to meet the needs of different industries and locations around the world.

Policy definitions

Some policy definition work has been carried out as part of the ebXML initiative that has developed a Collaboration Protocol Profile (CPP) that defines the various IT parameters that describe how a business carries out eCommerce when using the ebXML set of protocols. This means it is closer to a policy than a profile as the information it contains varies depending on the implementation.

More work has been done on policy definition languages for example with the set of specifications titled WS Policy, WS PolicyAssertions, and WS PolicyAttachments that allow assertions to be made about how a service should be used. Together they provide a generic way for describing the "capabilities, requirements, and general characteristics" of a Web Service as a set of assertions that can then be bound to a WSDL definition.

The initial focus of WS Policy is to define the policies for securing web services. This information could then be used at design-time and run-time to ensure that a Web Service was being used properly. However the WS Policy specifications are not yet part of any standards activity and there are currently intellectual property restrictions on their use. Also their developers, IBM, Microsoft, BEA and SAP have made no suggestions of moving them into a standards group even though the specifications are being updated.

Profile Definition Languages

There is no known work being done to develop a Profile Definition Language although the need to compose specifications into profiles has been identified by both the Web Services Interoperability Organization (WS-I) and the WS Architecture group within the W3C

Agreement definitions

The main activity that is working on how to define agreements for eCommerce is the Collaboration Protocol Agreement (CPA) work being done as part of the ebXML initiative. This defines how two businesses (or what ebXML calls parties) will interoperate when using the ebXML protocols. However this specification, like ebXML Messaging, only works with other ebXML specifications and does not work with any of the more recent Web Services specifications.

Negotiation Standards

The need for automated negotiation has been identified in a number of initiatives:

• ebXML has identified the requirements for the automated generation of a Collaboration Protocol Agreement from two Collaboration Protocol Profiles
• The need for negotiating the security policies to be used has also been identified as part of the WS Security activity at OASIS

There are also other several non-web service related negotiation protocols, for example the Information Content and Exchange protocol (ICE) for negotiating how to subscribe to syndicated information feeds on the web.

Generally there is currently no single effort that is focusing on how to define the policies related to web services and how to negotiate they way would be used.

The Future of Profile, Policy and Agreement Standards

Although some work has been done in developing profile, policy and agreement standards, there is much left to do. When this work does start it needs to be separated into a number of different tracks:

• Complex Web Services Work needs to be done to develop profiles on how Complex Web Services should be used in a particular context. For example, the need to send a message securely and reliably is universal and independent of a vertical industry. Therefore developing one profile for use by all industries will be very beneficial. This type of work is most likely to occur as an extension of the existing work on profiles within the WS-I
• Business Documentand Choreography definitions Developing common, minimalist but universally applicable standards for business document and choreography definitions that can be used by most businesses, in most industries, in most countries should facilitate interoperability between any businesses almost anywhere. Vertical industries can then extend these definitions to meet their specific needs whilst still maintaining interoperability. The minimalist definitions are best ratified if not developed by an international standards body such as UN/CEFACT or ISO Vertical industry associations, such as RosettaNet, PIDX, UCC and others can then take those minimalist definitions and extend or adapt them to meet the needs of their industry and geographic variations can be developed by individual countries, probably in working groups within UN/CEFACT
• Policy definitions Developing a standard way of defining policies that can then be universally applied is needed as it then opens the way for the development of standard ways of expressing agreements and negotiating them using a negotiation protocol It is to be hoped that the currentWS Policy set of specifications developed by BEA, IBM, Microsoft and SAP are submitted to a standards group soon for this purpose.
• Agreement definitions and Negotiation Protocol Standards Finally standard ways of recording agreements and negotiating them will also provide benefit. This work should ideally occur as part of the same activity that is standardizing policy definitions so that the close relationship between profiles, policies, agreements and their negotiation is properly maintained. There are no current activities that plan to do this.

Web Services Management

One of the foundations of Web Services is the idea that you do not need to know the technology used by a service or what server is being used to run the service For example it should not matter whether a service is running on a .NET or a J2EE server. Neither should it matter whether the service is running on a server attached to the local LAN or operating remotely over the Internet.

Why Web Service Management Standards are needed

If you then go to the next step of composing new services or applications out of existing services, then in order to completely and fully manage the composed service you also need distributed management of the components or other services that were used to build the new service Some of the services that you might need to manage can be beyond the control of an individual implementer as they are being run by a different business for example using an external credit checking bureau's service when processing an order to check the credit worthiness of a customer. This means that discovering status and other information about a service that is being run by a third party will become essential. This means that standards are needed on how to discover management related information about a service if interoperability is to be realized.

What Web Services Management Standards are needed

Complete management of solutions built using Web Services should cover the design, development, testing, deployment, use, evolution and retirement of all the different components used to create that solution.

The design, developing and testing of a service will often be entirely within the control of one business and therefore there is less need for standardization of how this is done. But when a service is deployed, used, evolved or, eventually, retired, other organizations may use the service that need to know and understand the operation of and changes to the service This leads to the need for several standards covering:

• Change Management This includes standards to notify other interested parties of new, changed or retired services
• Operational Management This includes standards to start, stop, monitor and report faults associated with the operation of services
• Service Level Management This includes standards to set target service levels for a service then later monitor actual performance against those targets
• Auditing and Problem Management This includes standards to enable the investigation, after the event, of what a particular service instance did when it was run, for example by examining logs as well as other information about the operation of the service

Change Management

When new services are created, or existing services changed, or retired, then users of those services need to be notified. To do this several individual standards are needed:

• Publish and Subscribe standards These are standards that allow subscription by one organization that uses a service to a notification service that provides information on new services or changes to a service
• Notification Standards These are standards that allow one service to notify another service that a change has occurred or will occur, for example a new version of the service has been created or the service will be shut down temporarily.

Once notification of a change has been received, the recipient can determine what action to take. Sometimes this might be automatic, for example, that the URL of a service has changed. In other circumstances human intervention could be required.

In all cases, it will often be a good idea to combine Change Management standards with the use of the secure, reliable messaging of Complex Web Services to assure the authenticity of the change and reliable delivery of notifications.

Operational Management

A Web Service implementation could be composed of services that are running on different technologies for example some on a .NET server and some on a J2EE server. Also some of the services might be running locally on a LAN whereas others might be running remotely on the Internet. However, from an operational management perspective, information about the current state of the operation of all of the services is needed so that, when problems occur, corrective action can be taken. This is particularly true when services are being used to create a composite application

If the management software that is used is tied to a particular technology, then operational challenges occur when failures arise, as manual intervention will often be needed to fully understand what the impact will be over the whole system. Alternatively, if control of services is centralized then the problem will be easier to manage, as the "big picture" will be available in one place. To realize central control, standards are needed in the areas of:

• Server Management This includes managing the servers on which web services are running and includes: server status (e.g. is the server running or not), starting and stopping a server, server availability (are there any planned down times), as well as getting and setting server configuration data
• Web Service Management This covers the management of individual web services running on a server. It includes: Web Service status (e.g. is the Web Service running or not), starting and stopping a Web Service, Web Service availability, and getting and setting Web Service configuration data

In practice, it will be up to the implementer of a Web Service to decide the extent to which third parties are provided access to operational management information about the Web Services they run. For example an operator of a server may not allow access to any server management facilities, but could allow others to manage the Web Service they operate on the server.

As with change management, use of the secure and reliable features of Complex Web Services will often be advisable in order to ensure the authenticity and accuracy of the information used in the operational management of web services and the servers on which they run.

Service Level Management

The focus of service level management is ensuring that services and the business processes they support are performed in a timely way that meets the business objectives of their implementers and users.

Exception based service level management is needed to help provide early warning of problems before they become so significant that the deterioration of the quality of service becomes noticeable. To provide service level management support, four topics need to be addressed:

• Service Level Setting This includes specifying what needs to be monitored, then setting the target service levels in terms of availability, response times and hardware utilization levels, etc which if exceeded or not met, indicate that a problem has, or is about to, occur.
• Service Level Response This involves specifying what the response or action should be once a service level has been exceeded or not met.
• Gathering Service Level Data This involves capturing the raw data from which the actual service levels achieved can be derived
• Service Level Monitoring This includes analyzing the data captured about service levels, comparing the actual service levels with targets then taking the appropriate action if service levels are not being met.

To support service level management over distributed systems, standards are needed for capturing of the raw data used to determine actual service levels The basic information required is the same for all web services no matter what technology is being used for implementation and includes:

• Server Utilization Information Utilization levels of the main hardware components, processor, disks, memory, network, etc of the servers on which the Web Services are running
• Web Service Information This includes information about response times of individual web services and their hardware resource usage.
• Server and Web Service Availability Information This includes information about the availability of individual web services and the servers on which they run

Auditing and Problem Management

Service Level Management's focus is on preventive management of potential problems to minimize their impact. In spite of this, problems will still sometimes occur which need to be investigated and fixed. Access to relevant information about the problem will improve the accuracy and speed of the diagnosis. As before access to information in a way that is independent of the technology on which the Web Service runs is needed.

To do this requires standards in the following areas:

• Event Logging These are standard ways of recording events, for example the events associated with the Operational Management and Service Level Management of web services described in the previous two sections.
• Message Logging This is the recording in logs of the messages that are sent between web services.
• Log search and analysis The amount of data kept in logs can be voluminous. This means that recording log information centrally can be impractical. To simplify this problem standards for carrying out distributed search and analysis of message and event logs will help.
• Message Tracking Once a specific problem has been identified, then detailed tracking and analysis of the messages that flowed between web services and the execution of the web services themselves can provide detailed information on what happened that can be used for problem diagnosis.

Current State of Web Services Management Standards

Change Management

Most vendors who offer Web Services Middleware provide some type of change management solution, however they only work for solutions that are built on that platform.

Since the last version of this paper was published, Actional, AmberPoint, Confluent, IBM, Merant and Talking Blocks have submitted a Change Management Requirements document to the Web Services Distributed Management Technical Committee within OASIS suggesting that a sub-committee be set up to address Change Management.

Operational Management

The Web Services Distributed Management Technical Committee is planning to liaise with the Distributed Management Task Force (DMTF) which has been working on the distributed management of particularly hardware devices for many years with success. This has included the development of protocols that allow for discovery, management and monitoring of those remote devices that are designed to work over the Internet.

Also since the last version of this paper was published one set of specifications and one set of requirements have been published and submitted to the Web Services Distributed Management TC that address Operational Management.

Hewlett Packard has published the specification. It consist of three specifications covering: WSMF Foundation which defines the base framework for management of services on the web using Web services; WS Events which defines a Web services based event notification mechanism by which one service can notify another service of some event; and WSMF-Web Services Management defines a model for the management of Web services.

IBM, CA and Talking Blocks have submitted a requirements document called WS Manageability.

Since both of these documents have been submitted to the same standards group there is a good chance that they can converge.

Service Level Management

Although the charter is not clear, it is probable that Service Level Management will be included as part of Web Services Distributed Management Technical Committee.

Auditing and Problem Management

The need for auditing and problem management has been identified as part of the ebXML Messaging Activity as well as within the Web Services Architecture activity within the W3C At the time of writing, though, there are no known specific standards activities in this area.

The Future of Web Services Management Standards

With the progress made in the Web Services Distributed Management Technical Committee, work is now starting on Change Management. This leaves the major gaps in standards in the area of Auditing and Problem Management

As Auditing and Problem Management are generic problems, they are most likely to be set up as activities probably within an OASIS Technical Committee.

Registries

Information used by Web Services often needs to be shared because it needs to be agreed. For example, before a supplier can accept an electronic order from a buyer, the buyer and supplier need to agree the structure of the order and the details of what the order will contain.

Registries help by providing a place to store the information that needs to be shared that can then be accessed by others that have the need as well as the authority to do so. This information that may need to be shared includes:

• 
  
Business Process definitions, that describe the sequence in which processes (or sub-processes) are executed
• Choreography and Role definitions, to verify that messages are sent in the correct sequence to the correct destination
• Service Interface definitions, to ensure that web service software operated by one business knows how to interact with a service run by another
• Business Document and Message definitions, to make sure that the structure and content of the messages sent between services is correct
• Profile Definitions, to make sure that all of the above are used correctly in combination for the context in which they are being used
• Policy and Agreement definitions, to make sure that the implementations behave according to implementation policies and agreements made with others.

This shared information is needed:

• At design time, to ensure that solutions are built that match the definitions correctly
• At run time, to ensure that web services are following the definitions correctly.

At run time, further information is also needed that describes the organizations and technology involved. For example:

• Businesses and Organizations - a description of a business, how to identify them, the services they provide, their structure and, sometimes, the people who work within them
• Servers - the actual technology that is used to implement web services including their addresses on the web (URLs) and the services, business processes, choreographies, etc that they support
• Web Services - the actual web services that run on the servers that support the operation and running of businesses and organizations.

Why Registry Standards are needed

All the information described above needs to be standardized because it needs to be shared and if it needs to be shared then a mechanism for sharing the information is needed. Although manual-sharing methods can be used they are time consuming and potentially inaccurate. Storing the information in a Registry and providing standard methods for searching and retrieving the information is a more efficient, lower-cost and accurate option.

What Registry Standards are needed

Essentially, three main types of registry standard are needed;

• Discovery Standards that allow information in a registry to be searched using search parameters
• Information Retrieval Standards so that, once the appropriate information has been identified, it can be retrieved
• Negotiation and Agreement Standards Often the result of a search can result in multiple choices. Therefore a negotiation protocol that negotiates which of the choices to use is required as well as a way of recording the agreements that result.

Standards are also needed in several other areas:

• Publication Standards are needed so that information can be published to a registry easily in a standard way
• Registry Replication and Federation Standards are needed since a single repository for any piece of information is both a potential single point of failure and unlikely to scale to the very high volumes that will occur as Web Services become more widely deployed

Each of these areas is described below.

Discovery Standards

Discovery standards allow registries to be searched. Parameters on which a search can be made include:

• Category and keyword searches For example searching for a business near a particular location that operates in a specific industry identified by a category keyword
• Standards and Protocols Supported For example searching for services that support specific versions of protocols and standards, for example a specific choreography or business document format
• Text searches For example searching free-form text descriptions of businesses, services, etc
• OwnerOperator searches/ For example searching for services that are provided by or operated by a particular business or organization.

Different types of registries can also be searched, for example:

• Local registries For example searching for data in a local or cached registry
• Partner registries For example searching registries operated by business partners
• Directories For example searching directories or registries operated by companies such as Dun and Bradstreet and Thomas' Register specifically for the purpose of locating new business partners
• Standards groups For example searching for business document and choreography definitions that have been created by a standards groups

Standardization of categorizations, keywords and search protocols are needed to enable search automation.

Information Retrieval Standards

Once information that needs to be retrieved has been identified, then it needs to be retrieved. There are two main approaches to this:

• URL Based Retrieval Retrieval of information using a URL where a request is made to a server which then responds with the results is the simplest but suffers from two main problems:
• Security The information may not be digitally signed Requests may not be digitally signed therefore the recipient may not know whether the request is authorized Similarly, the data that is returned may not be digitally signed therefore the authenticity and accuracy of the information may not be known with certainty
• Scalability If the information is only available at one location on the web, then the server that holds the information could be overwhelmed with the number of searches that are made on it for resources that are popular
• Web Service Based Retrieval This alternative treats the registry as a Web Service where the data in the registry is retrieved by making requests to the Web Service. This approach can also use the security and reliability features of Complex Web Services to help ensure the accuracy, authenticity and reliability of retrieval of the information.

Standards are needed for Web Service Based Retrieval so that the same technology can be used to query any registry

Negotiation and Agreement Standards

Often a business will support multiple different choreographies or multiple different business document formats. In this case a decision must be made on which of the available choices to use.

One approach to this problem is to negotiate out-of-band agreements that define all the minute details of how two or more services will interact in order to realize interoperability before any interaction takes place.

Although this problem can be solved using pre-negotiated agreements, a more automated approach is to use a negotiation protocol that compares the standards, profiles and policies that are supported by each of the services involved then identify the subset that is common to both. The result can then be recorded in an agreement

Since agreements need to be shared, their format also needs standardization. Similarly, a negotiation protocol needs to be standardized that works with registries so that the automated negotiation can occur.

For additional information see the section on Negotiation and Agreements

Publication Standards

The information contained in registries also needs to be maintained. This means that standards are needed for:

• Information publishing This covers standards that include:
• Allowing an owner to manage the "life cycle" of data in a registry including: creating, testing, adding, changing, deprecating and deleting the data they own
• Changing the owner of the information, for example if a different person or business becomes responsible for the data
• Change Management This includes the ability for the owner to notify others of changes to the information in the registry - this topic is covered in more detail in the Change Management section of this paper

Standards are needed for Information Publishing and Change Management to allow an information owner to use the same technology for publishing to any registry

Registry Replication and Federation Standards

The amount of data that will need to be stored in a registry can be significant. There will also be multiple registries with multiple owners as those owners will often want to control the data they own. This means that sharing of information between multiple registries is the only practical way in which registries will be able to work.

There are two basic models for the distribution and replication of data stored in a registry These are:

• Replicated Registries Where the information in one registry is automatically copied to another.
• Federated Registries Where multiple registries can appear as if they are one.

A Replicated Registry has the benefit that multiple copies of the information are available. This means that they are highly available and scalable. On the other hand, multiple copies of data means that there are opportunities for inconsistencies between the multiple copies. Replication also means that the size of individual registries is larger as they contain duplicate data.

A Federated Registry solves this problem by allowing multiple registries to appear as if they are one large registry This works by one registry automatically searching additional registries when necessary. This avoids the problems of replication and minimizes the size of a registry by avoiding duplication, but at the expense of requiring more extensive and often longer searches to retrieve information.

In practice a combination of a Replicated Registry and a Federated Registry is needed.

Current State of Registry Standards

Currently there are two main standards initiatives that provide support for registries:

• UDDI (Universal Description, Discovery and Integration) which started as a separate consortium which then migrated to OASIS, and
• ebXML Registry which started as a separate joint initiative between OASIS and UN/CEFACT and then migrated to OASIS only.

Both these standards partially meet the requirements for registries

UDDI (Universal Description, Discovery and Integration)

UDDI's strength is the description, identification and classification of businesses and the services they provide with specific support for web services definitions in the form of WSDL definitions. However UDDI does not provide a mechanism for storing and searching for all the other information needed to drive web services including: business document and message definitions, business process definitions, choreography and role definitions, profile definitions and policy and agreement definitions.

Within the scope of the types of information it can record, UDDI provides good approaches for Discovery Standards, Information Retrieval Standards, Publication Standards and Replication and Federation Standards

Since the last version of this paper was published 20 of the UDDI specifications have been finalized. In the meantime, development of version 3.0 continues.

With version 3.0 of UDDI, support is also provided for securing the information stored in the registry so that the authenticity and accuracy of the information can be assured and Change Management through the use of publish-subscribe mechanism to notify others of changes.

UDDI does not provide support for Negotiation and Agreement standards or Federated Registry standards

Electronic Business XML (ebXML) Registry

The ebXML Registry on the other hand allows any type of information such as business document and message definitions to be stored as well as the business and Web Service information that UDDI allows. The ebXML Registry specification also supports the use of ebXML Messaging This means that access and maintenance of data in the registry can be secure and reliable. The ebXML Registry also provides support for agreement standards through the ebXML Collaboration Protocol Agreement standards that can be stored in the registry There is also some initial work being done on negotiating an agreement by comparing ebXML Collaboration Protocol Profiles

However, when compared with UDDI, ebXML Registry's approach to discovery of information is less flexible and less powerful than the approach used by UDDI The ebXML Registry also does not support replication.

The Future or Registry Standards

So what does this mean for the future?

Firstly, both the ebXML Registry and UDDI suffer, to a degree, as they are dependent on work going on in other standards areas as they are dependent on those standards activities identifying the information that needs to be stored in a registry

The other disadvantage they have, is that they have adopted their own individual approaches to solving problems, for example securing the data stored in registries, since they wanted to solve the security problem before more generally applicable standards such as WS Security were complete.

The security problems associated with public registries described earlier also means that use of registries has been, and will probably remain in the foreseeable future, limited to private implementations, where the information is regarded as a local resource available only to the business that maintains it.

Even though, both UDDI and the ebXML Registry are now part of OASIS, there does not seem to be any major initiative to align them very closely.

Program APIs

Applications that want to use Web Services must create messages that conform to the appropriate Web Services standards.

Typically Web Services Middleware is used to do this that provides convenient APIs that the application programmer can use. This allows programmers to create applications that conform to the standard with more consistency for much less effort.

Why Program API Standards are needed

Program API standards are also needed to provide application portability and therefore allow preservation of investment by allowing applications to more easily move from one Web Services Middleware software platform to another. If programmers use a proprietary API for accessing Web Services Middleware, then they cannot so easily move their solution to any other platform without additional work and cost.

What Program API Standards are needed

Generally Program API Standards are needed at all the "touch-points" that an application can have with Web Services Middleware This includes APIs for:

• Document Management
• Message Management
• Registry Management
• Organization Management
• Service and Process Management
• Profile, Policy and Agreement Management , and
• Web Services Management

These are described in more detail below.

Document Management

Document Management includes APIs that allow both XML and non-XML documents to be created, accessed, verified and transformed by an application.

These APIs are at the core of web services as they are the basic way by which an application can manipulate the data it receives and sends using Web Services.

Message Management

Message Management includes APIs to support Complex Web Services including:

• Message Packaging Creating, accessing and manipulating the different parts of a message
• Message Delivery Sending and receiving messages
• Message Addressing and Routing Specifying the logical and physical addresses to which messages are sent and the route a message should take to reach its destination
• Reliable Messaging How you ensure a message is delivered with a high degree of certainty
• Message Security Digitally signing and encrypting messages Ensuring message authenticity and that the request implied by sending a message is authorized

Message Management APIs are also core to web services since applications must be able to send and receive messages using the web services standards in order to use web services.

Registry Management

Registry Management includes APIs for maintaining and accessing information in a registry including:

• Discovery Searching for information
• Information Retrieval Retrieval of information remotely
• Negotiation and Agreement Negotiating agreements on how web services will interact
• Publication Publishing and managing information in a registry
• Replication and Federation Replicating information between registries and simultaneous searching of multiple registries

Most organizations will want to keep separate shared registries of the services, business documents, etc. that they use at design-time to build applications as it helps ensure that the data accessed is consistent and up-to-date as it is only held in one place.

The APIs that are needed at design time include: Discovery, Information Retrieval, Negotiation and Agreement, and Publication

At run-time, access by applications to a registry is primarily confined to Information Retrieval for example to resolve references to: business document definitions, business process definitions, choreography definitions and profile, policy and agreement information. There is therefore significant benefit in having standardized APIs for this purpose.

Finally Replication and Federation APIs are primarily internal to the management of registries themselves so there is less benefit in their standardization.

Organization Management

Organization Management includes APIs for:

• Business/Organization Management Managing and retrieving information about businesses, organizations and partners stored in a registry
• User Management Managing and retrieving data about users of web services and the roles, responsibilities and privileges they have stored in a directory or registry

Many applications will be need to access and maintain information about business partners and users. Therefore standardizing APIs for this purpose is useful.

Service and Process Management

Service and Process Management includes APIs for:

• Service definitions Managing and retrieving the information about service definitions
• Business Process definitions Managing, retrieving and executing business process definitions
• Choreography definitions Managing and retrieving choreography definitions and validating that a choreography is being followed correctly

Applications need access to all these different types of information at run-time. See the discussion above on Registry Management

Profile, Policy and Agreement Management

Profile, policy and agreement management includes APIs for:

• Profiles, Policies and Agreements Managing and retrieving profiles, policies and agreements to control how the Web Services Middleware behaves
• Negotiation Protocol Conducting a negotiation when required to agree what behavior an application should follow then recording the result as an agreement

As for Service and Process Management, applications need to use all these different types of information at run-time. See the discussion above on Registry Management

Web Services Management

Web Service Management includes APIs for:

• Change Management Sending and receiving notification of changes
• Operational Management Starting, stopping, etc, servers and web services
• Service Level Management Setting and monitoring service levels, server and Web Service utilization and availability
• Auditing and Problem Management Recording and searching logs and message tracking

Apart from APIs that allow applications to log events and record statistics about their performance, most of these functions will be developed inside proprietary systems/software management solutions. Therefore, as long as they follow a published SOAP/XML protocol, they should be able to interoperate, so there is less need for APIs in this area to be standardized.

Current State of Program API Standards

APIs are very closely tied to the programming language and system/technology environment on which they run. For Web Services, there are two main environments to consider:

• Microsoft's .NET Server that provides a complete design time and run-time environment for building web services, and
• Java 2 Enterprise Edition Servers based on the J2EE specifications developed as part of the Java Community Process (JCP)by Sun and others.

NET, J2EE and Standard APIs

Although there are some benefits in developing an abstract API that can then be mapped to specific language and technology environments, it is highly unlikely that this will happen in the foreseeable future for .NET and J2EE This means that, when developing programs that use web services you have to choose either.NET or J2EE as a design-time and run-time environment.

If Microsoft's .NET solution is chosen, then it effectively means that implementations are constrained to using the Microsoft APIs As these APIs are likely to be only usable with Microsoft solutions, they are unlikely to become part of a separate standardization process.

J2EE is different as there are J2EE solutions available from multiple vendors. This means that standardization of Web Services APIs to work in the J2EE environment is beneficial as it offers greater portability of applications between J2EE platforms.

Composite Applications

However, one of the basic premises behind Web Services is the ability to compose new applications and services out of existing web services no matter what the technology used to develop the original programs. This means that you can create a new service out of existing services where some services run on .NET, some run on J2EE and some run remotely over the Internet on a server using an unknown technology.

However only a single technology environment can be used to create the composed application and the rules that describe its behavior.

APIs are dependent on Standards Development

The next limiting factor on API development is that many APIs for Web Services are dependent, to a large degree, on the development of Web Services protocols and standards those APIs are designed to support.

As the Web Services protocols are not yet complete, the APIs to support them aren't complete either.

This also means, for example, that the Microsoft APIs only tend to support the protocols that Microsoft supports. So if you want to use a Web Service standard that Microsoft does not support then you will probably have to rely on a third party solution. This is less likely to be a problem for J2EE since there are more developers, more choices and a more open standards process in JCP that means that, once a standard is agreed, there are more likely to be solutions available for it.

The following sections provide a guide to the APIs that are currently available. Note that only APIs for Java are described since, as described earlier, the Microsoft .NET APIs are unlikely to be standardized.

Document Management

There are two basic types of APIs that are used to manipulate XML documents:

• Generic APIs, specifically DOM and SAX, and
• Document specific APIs that use Java Beans

DOM is a standard that allows direct manipulation of an XML document in computer memory by treating the XML document as a tree structure. This means that all parts of the document can be accessed directly and quickly, however the size of the document that can be handled is limited by the amount of memory available. This can be a significant performance restriction when processing XML documents used for business as they are often large.

SAX is a standard that allows serial processing of an XML document. This means that theoretically, there is no limit to the size of the document that can be processed as a SAX compliant processor starts at the beginning of an XML document and then gradually works its way through to the end. On the other hand, if you need to retrieve data from earlier in a document then the document must be re-read which increases the time required to process it.

Neither the DOM nor the SAX approach to document manipulation verifies that the structure of the XML document conforms to its XML Schema This imposes significant additional responsibilities on the application program and the application programmer to make sure that the XML generated or received is correct.

An alternative approach that solves the verification problems of DOM and SAX is to use Java Beans In this approach an XML Schema is processed and used to generate software that can be used as a normal API to generate or process the document. This also has the advantage that a lot of the validation can be done at design time rather than run time.

For Java, the JAXP specification defines an API that supports both DOM and SAX, and the JAXB specification has been developed for Java Beans However JAXB only supports a subset of the features in XML Schema

Message Management

The JAXM specification provides an API for packaging and transporting SOAP messages This supports simple SOAP messages, for example messages without any attachments and also the sending and receiving of messages that conform to the ebXML Messaging specification.

In addition there are specifications being developed as part of the Java Community Process to create APIs that support the digital signing and encryption of messages (and also business documents) using the W3C XML Signature and XML Encryption specifications.

Registry Management

The JAXR specification defines a Java API for accessing and manipulating the information in a registry It provides support for both ebXML Registry version 1.0 and UDDI version 2.0.

Organization Management

The JAXR specification describes how to access business and user information held in a UDDI registry

Service and Process Management

The JWSDL specification supports the creation and manipulation of WSDL definitions of web services that conform to version 1.1 of WSDL It also facilitates the creation of software stubs that contain APIs that make it easier for an application to interact with a Web Service.

Profile and Policy Management

As little work has been done on profile and policy standards there are no APIs yet available for this area.

Web Service Management

The JMX specification provides APIs that support the operational management and service level management of applications running in the Java environment. They are not specifically tied to monitoring Web Services.

The Future of Program API Standards

The recurring theme on API standards is that they will change as the Web Services specifications and protocols on which they rely, evolve.

Examples where changes are likely include:

• Message Management JAXM will probably need to be updated or extended as the base web services specifications such as SOAP are developed. Further changes will be required as specifications such as WS Security and WS Reliability mature.
• Registry Management Since current registry management API specifications, define their own methods of accessing a registry, they will need to change to support equivalent Complex Web Services APIs for security and reliability as standards in these areas evolve
• Organization Management, and Profile, Policy and Agreement Managementspecification APIs will also need to change as the standards in the area mature.
• Web Service ManagementAPIs also need to be expanded so that Web Services can be more directly managed and controlled.

API Profiles

The final area where more work on APIs is needed is to create profiles that describe how APIs are used on different types of devices, for example, small devices such as PDAs will probably require a smaller set of APIs than for a J2EE application server

Getting Standards Adopted

SOAP, WSDL and UDDI are recognized as being the foundation standards on which many other Web Services standards are built. The dominant position of these standards was no accident. It occurred because of the combined marketing effort of major vendors, especially IBM and Microsoft.

The importance of support by "major players" for a standard should not be underestimated, as it is a critical factor that a business should use in assessing the future success of the various standards initiatives.

Fundamentally there are three sets of players who together "set the standard":

• Standards Groups, such as the IETF, OASIS and the W3C,
• Major vendors: such as IBM, Microsoft, Sun, Oracle and others, and
• Major users: big companies and governments that use the standard.

The Role of Standards groups

Standards groups provide a forum in which standards specifications can be developed. They also have rules and procedures that allow a specification to be "approved" as a standard which means that the specification will be stable and one on which solutions can be developed with a fair degree of confidence. Any specification that is developed outside of one of the major standards groups has difficulty in being accepted as a standard unless it is a standards group such as RosettaNet that is focusing on the needs of a specific vertical industry or it is a standards group developed by a consortia of major vendors.

On the other hand, the simple creation and approval of a specification in a standards group is no guarantee that the standard will be widely adopted - there are hundreds of standards that fall into this category. For a standard to succeed, two extra things are needed:

• It must solve a real problem If the standard does not solve a real problem, then it means that there will be little demand for the products or solutions that support the standard
• Solutions must be developed that support them If the standard solves a real problem, and vendors can see how they can sell product or obtain influence over their market, then they are more likely to develop solutions that support the standard. On the other hand, some workable standards sometimes are ignored because they do not suit the marketing objectives of some vendors.

The Role of Major Vendors

Sometimes a group of software vendors write an initial draft of a specification that addresses a problem area and then submits the specification to one of the standards groups to be further developed and standardized. This has benefits in that the initial specification can be developed faster and so the approved standard is finalized earlier.

It also provides several advantages to the vendors who developed it:

• Marketing There are marketing and time-to-market benefits as the developers of the original specification can start building solutions earlier since they have access to advance copies of the specification. This is especially true if their major competition is excluded from the activity.
• Influence The developers of the specification are well positioned to take senior positions such as chair or editor, in the standards activity. This provides an opportunity for them to exert further influence over the standard as it is developed.

It also almost guarantees that there will be solutions developed that support the standard.

The Role of Major Users

The last category with an influence is the major users. Businesses also want the marketing and influence advantages that being involved in standards can provide, as they can be first to market with implementations that use the standards.

In addition, because of the major influence large users have within their industry, they can provide a real incentive for the adoption of a particular standard by "requiring" that smaller businesses within their industry use the standard. This approach has often been followed by big business such as the major auto manufacturers and also by Governments.

Vendors vs. Users

This leads to a tension between vendors and users in that:

• Major vendors want to exert influence over the direction of future standards developments because of the advantages it gives to their companies
• Major users want the reverse, i.e. they don't want any individual vendor to realize significant benefit as it reduces competition and therefore tends to increase the prices of solutions. It also means that all the users in their industry operate on a more level playing field.

This tends to make major users support the standards initiatives that have started in an open forum and are not sponsored by any particular vendor. The classic example of this is the user support for business standards initiatives such as ebXML and the standards activities which evolved from it which are much more user/business driven than the other Web Services Architecture driven solution which is more driven by the vendors.

Neither approach is actually perfect.

Vendors have a depth of technology understanding that is rarely found in businesses. Conversely, users have a depth of understanding of business needs and requirements that vendor staff rarely have.

Really, a joint partnership between users and software vendors is really needed.

What the Scores Mean

Each standards area reviewed by this paper is given a numerical score in terms of: scope - i.e. have all the necessary standards been identified; maturity - i.e. to what extent are the standards fully developed and ready for use now; and adoption, - i.e. are the standards currently or likely to be widely adopted. The percentage scores and what they mean are explained in more detail below:

• Scope:
• Fully scoped (100%) means that the need for standardization is well recognized by groups and organizations that could develop those standards
• Partially scoped (50%) means that the need for the standard has been identified to a degree but that there is not yet widespread agreement on what the scope should be
• Not scoped (0%)means that the need is not yet fully identified if at all
• Maturity:
• Mature (100%) means that a fully developed specification has been developed with interoperable implementations from multiple vendors
• Complete (66%) means that specifications have been developed that are either complete or close to completion but solutions are not yet widely available
• In development (33%) means that specifications are being developed within a standards organization but that they are not yet close to completion
• Immature (0%) means that there are no specifications, or there are some specifications but they are proprietary or are in the very early stages of development
• Adoption:
• Full (100%) means that the standard is, or will be, widely adopted and supported by many vendors and users
• Partial (50%) means that some groups have adopted the specification but others have not or are choosing not to
• None (0%) means that there is little or no adoption of the specification

Finally, remember that the numerical scores are designed primarily as a means of providing an overall "feel" for the state of each standards area.

Glossary

This Glossary explains many of the terms, standards and ideas in Web services. Some of the terms apply to other areas too. However only the Web service explanation is given here

The explanations also identify many links to further information on the web. All the links were live at the time the Glossary was developed (August 2003). If you discover any that are broken, please let the author know so that they can be updated in a future version.

Name	Explanation
NET	The .NET Framework is Microsoft's architecture for building applications on the Windows operating system including Web Services. It consists of a set of developer tools, servers and client software. See http://msdn.microsoft.com/netframework/default.asp See also J2EE and ApplicationServer
ACORD	ACORD is an insurance industry association in the US that is developing XML standard documents s for electronic data sharing. See http://www.acord.org/
Address Route	An Address Route describes the set of web addresses through which a Web Service message (i.e. a SOAP Message) is sent from when it is first created until it is reaches its final destinations.
Address Routing	See Address Route
Agreement	An Agreement describes how two, sometimes more, businesses have agreed to carry out business with each other electronically. They are typically created by comparing one business' use of profiles and policies with the other business' use and selecting and agreeing a subset of technology that both support. They are identified with an Agreement Identifier See also Collaboration Protocol Agreement
Agreement Identifier	An Agreement Identifier is a unique identifier that identifies an agreement Agreement Identifiers are often carried in the SOAP Headers of a SOAPMessage so that the agreement that applies to the processing of a message can be determined by the recipient of the message
AIAG	The Automotive Industry Action Group (AIAG) is a US based not-for-profit association of companies involved in the automotive industry. They develop several eCommerce and B2Bi standards for use in their industry. See http://www.aiag.org/
ANSI	American National Standards Institute. One of the De Jure standard setting organizations. See http://www.ansi.org/
API Profile	An API Profile defines the subset of existing application program interfaces used for a specific purpose. For example it could be the profile used when connecting a PC to a portable device such as a PDA
API	An Application Program Interface (API) defines how a programmer writes a program to interface to some other program or operating system. For Web Services, standardized APIs are needed to define how an application communicates with Web Services Middleware See Program APIs for more detail.
Application Program Interface	See API
Application Server	An Application Server is software that can be used to run a set of programs that provide business logic. It is distinct from front-end software, such as a web browser that displays information to a user, and a back end transaction or database server that provides the information manipulated by the programs running on the application server. See also .NET and J2EE
Architecture	Architectures define an overall structure. In the context of information systems, they define the various components of software and/or hardware from which the information system is built together with the interfaces between those components and descriptions of what each component does.
Attachment	Attachments are additional documents sent at the same and in the same message as a main business document Attachments can be both XML and non-XML. To include an attachment, methods such as MIME, DIME or SOAP with Attachments have to be used to combine all the parts together into one message
Authentication	Authentication is the process by which a recipient of a message, such as a SOAP Message, can determine the identity of the sender of the message with certainty. This often involves the sender of a message digitally signing the message using a digital certificate and the recipient of the message checking the digital signature for accuracy when the message is received.
Authorization	Authorization is the process of checking that a request implied by the receipt of a message, e.g. a SOAP Message is one that the sender of the message is allowed to make and therefore the request should be acted on by the service that receives it.
B2Bi	B2Bi or Business-to-Business Integration is the process of integrating the information systems of different businesses together. Often used in the context of integrating a buyers information systems with those of their suppliers. See also EAI
Basic Profile	The WS-I Basic Profile is one of the activities of WS-I It is a specification that provides precise rules on how the basic Web Services specifications of SOAP 1.1, WSDL 1.1 and UDDI 2.0 should be used together in order to maximize interoperability
BPEL, BPEL4WS	The Business Process Execution Language for Web Services (BPEL4WS) is a specification developed by IBM, BEA, Microsoft, Siebel and SAP. It is a definition language for business processes It is being developed in the Web Services Business Process Execution Language Technical Committee in OASIS. See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
BPSS	The Business Process Specification Schema (BPSS) is a specification that defines how two or more businesses exchange information in order to integrate their systems together (see B2Bi). The BPSS specification can be used to define a choreography
Business Process	A business process is the sequence and conditions in which the processes within a business are executed to meet some useful purpose, for example handling a purchase order. Most business processes involve the execution of several sub-processes involving multiple systems both within, and often, outside the business. A business process can often be used to define the sequence of actions used to implement a service Business Processes can be defined using business process execution languages such as BPEL4WS
Business Process Execution Language for Web Services	See BPEL4WS
Business Process Execution Language	A Business Process Execution Language is a definition language used to define a business process Examples of Business Process Languages include:BPEL4WS, and WSCI
Business Process Specification Schema	See BPSS
Business Document	A Business Document is a name for the documents such as orders, invoices, shipment notices or any other document that is exchanged between businesses in order to carry out business
Business to Business Integration	See B2Bi
Business Transaction	A Business Transaction is an instance of two or more businesses carrying out business. For example a buyer placing an order with a seller.
Business Transaction Protocol	The Business Transaction Protocol of BTP is a protocol that allows the synchronization of data between remote servers using an XML based protocol using the ideas of two-phase commit. BTP is a Technical Committee within OASIS see http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=business-transaction
Callback Address	See return address
Canonical XML	Canonical XML is a standard developed within the W3C that defines a way of generating a physical representation of an XML document so that it is in a standard or canonical form. If two different documents, once generated in their canonical form are identical, then they are logically equivalent even if there were some differences in the original. Before XML documents are digitally signed or a digital signature is checked, they are always transformed into the canonical form. See http://www.w3.org/TR/xml-c14n
Categorization	Categorization is mainly used for searching for definitions of such things such as businesses, services, choreographies, business document definitions etc. Categorization can be keyword based, for example the keyword "order" should identify business documents, business processes and choreographies that involve handling of an order. They can also be non-keyword based, for example find all the providers of logistics services within 50 miles of Paris, France.
Change Management	Change Management is the activity of managing changes to web services. It involves sending notifications of changes in a Web Service to the users of the Web Service so that those users can adapt their systems as required. See the section on Change Management for more detail.
Choreography	A choreography definition specifies the sequence and conditions in which messages are exchanged between two or more cooperating services to execute some useful purpose, for example between two businesses to place an order. Messages that take part in a choreography are identified with a Choreography Identifier and are defined using a Choreography Definition Language
Choreography Definition Language	A Choreography Definition Language is a definition language that can be used to define a choreography Typically it is defined using XML
Choreography Identifier	A Choreography Identifies is a unique identifier that identifies the sequence and conditions in which messages are exchanged. Choreography Identifiers are often carried in the SOAP Headers of a SOAPMessage so that the choreography that applies to the processing of a message is known
CLI	See Common Language Infrastructure
Collaboration Protocol Agreement	The Collaboration Protocol Agreement (CPA) is one of the specifications within ebXML Its purpose is to define how two businesses will interact when taking part in B2B (see B2Bi). Separate agreements are required for each process being integrated. CPAs can be created from the intersection of two Collaboration Protocol Profiles (CPPs). See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-cppa
Collaboration Protocol Profile	A Collaboration Protocol Profile (CPP) is one of the specifications within ebXML It defines the technical capabilities of a business to do B2Bi The intersection of two Collaboration Protocols Profiles can be used to create Collaboration Protocol Agreement (CPA). See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-cppa
Common Language Infrastructure	The Common Language Infrastructure is a standard in which applications written in multiple high-level programming languages may be executed in different system environments without the need to rewrite the application to take into consideration the unique characteristics of those environments. The specification was originally developed by Microsoft and is used primarily in Microsoft products. It has been submitted and ratified by ECMA See http://www.ecma-international.org/publications/standards/ECMA-335.HTM
Complex Web Services	Complex Web Services are a set of techniques and technologies that allow a Web Service that uses a set of SOAP extensions and protocols to exchange messages between servers securely and reliably.
Composed Service	See Composite Application
Composite Application	A Composite Application is an application that is created by combining together several other existing applications together to create new functionality. The applications often run on different technologies so Web Services standards are an ideal way to enable the communication. If the Composite Application implements a service then that service is known as a Composed Service
Context	The circumstances or conditions in which something is used, for example how the content and structure of a business document varies depending on the country and industry (the context) in which the business document is created.
Conversation	A conversation is a set of related messages For example the set of messages used by a buyer to place an order, the seller to provide a response, and the buyer to make multiple changes through sending change orders. Conversation instances are identified with a Conversation Identifier
Conversation Identifier	A Conversation Identifier is a unique identifier for an instance of a choreography For example, the exchange of messages required to complete the placement of an order could have a choreography identifier associated with them. Choreography identifiers are transported in SOAP Headers of a SOAP Message so that the conversation being executed can be identified.
CPA	See Collaboration Protocol Agreement
CPP	See Collaboration Protocol Profile
De Facto Standard	A De Facto standard is a standard that has achieved widespread use without being submitted to any formal standardization procedure through a standards organization. Examples include the PC and the Microsoft Windows Operating system. See also De Jure standard
Definition Language	A Definition Language is a language, often defined using XML, that can be used to describe the precise characteristics and structure of objects that are of interest to web services. For example definition languages can be created to describe such things as services, business documents, business processes, choreographies, messages, roles, policies, agreements, profiles, business partners, users, systems, web services, standards and more.
Definition Language Profile	A Definition Language Profile is the subset of a definition language that is designed for some particular purpose. For example, XML Schema is a powerful language that contains more features than necessary to define a business document Therefore profiles of XML Schema have been created that define a useful subset of XML Schema that is targeted on the definition of business documents
De Jure Standard	A De Jure standard is one that has been sanctioned and approved by a formal standards setting authority. Strictly speaking for computer standards this must be one of: ANSI (American National Standards Institute), ITU (International Telecommunication Union), IEEE (Institute of Electrical and Electronic Engineers), ISO (International Standards Organization), or VESA (Video Electronics Standards Association). In practice for Web Services, OASIS and the W3C are the main standards setting authorities.
Delivery Receipt	A Delivery Receipt is a message, usually a SOAP Message that is returned by a recipient of an earlier message to indicate to the sender of the earlier message that the message was received.
Digital Signature	A Digital Signature is a way of signing an electronic document in a similar way to a pen can be used by a person to sign a paper document. This means that a digital signature can be used to determine the authenticity of a business document or message Digital signatures can also be used to ensure that any alterations to a business document can always be detected. See also XML Signature Digital signatures are created and checked using a Digital Certificate
Digital Certificate	A Digital Certificate is a set of codes that are used to create and verify a digital signature and/or encrypt a message or XML document. Digital Certificates can be thought of as "keys" that can be used to lock or unlock a document. See also key management
DIME	Direct Internet Message Encapsulation (DIME) was a specification for combining multiple documents into a single SOAP Message It was originally developed by IBM and Microsoft and was submitted to the IETF as an Internet Draft The DIME specification however has not been progressed and the Internet Draft published at the IETF has been allowed to lapse see http://www.ietf.org/internet-drafts/draft-nielsen-dime-03.txt The original specification is available at http://msdn.microsoft.com/library/en-us/dnglobspec/html/draft-nielsen-dime-02.txt See also SOAP with Attachments
Direct Internet Message Encapsulation	See DIME
Discovery	Discovery is the process of discovering information about a Web Service so that the information can be used to build solutions that use that web service. UDDI and the ebXML Registry are the main standards that are used to support discovery.
Distributed Management Task Force	The Distributed Management Task Force is an industry organization that is developing interoperable standards for managing distributed software and hardware. See http://www.dmtf.org/
DMTF	See Distributed Management Task Force
Document	In a web services context, a document is the data that is placed in the content or payload of a SOAP Message A document can be placed either in the SOAP Body or in an attachment Documents are often business documents
Document Definitions	A Document Definition, is a definition of a document in a definition language Document definitions are usually written using XML or XML Schema
Document Object Model	See DOM
DOM	The Document Object Model (DOM) is an interface that allows programs to dynamically access and update the content of documents, especially XML documents. See http://www.w3.org/DOM/
DotNET	DotNET is an alternative spelling for .NET
EAI	Enterprise Application Integration (EAI) is a set of technologies used to integrate the systems and solutions within a business. Web Services technologies are often used for the exchange of messages between the systems involved. See also B2Bi
ebXML	ebXML was a joint 18 month initiative between OASIS and UN/CEFACT that started in November 1999. Its objective was to enable eCommerce globally through the development of a set of standards. When it finished, on going development of the technical ebXML specifications moved to in OASIS and the business-focused specifications moved to UN/CEFACT See http://www.ebxml.org/
ebXML Messaging	ebXML Messaging is one of the standards within ebXML Its purpose is to provide a set of standards to support Complex Web Services See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-msg
ebXML Registry	ebXML Registry is one of the standards within ebXML Its purpose is to define a standard way of manipulating information with Registries See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep See also UDDI
EDI	Electronic Data Interchange (EDI) is a set of standards that describe the business documents and choreographies required to carry out eCommerce. There are two main flavors of EDI: ANSI X12, see http://www.x12.org/, who have developed EDI standards for the USA, and , UN/CEFACT, see http://www.unece.org/cefact/, who have developed the international version of EDI. EDI technologies are gradually being replaced by technologies based on Web Services and XML
Electronic Data Interchange	See EDI
Encryption	Encryption is a method by which data can scrambled so that it cannot be understood by anyone unless they have the key to unscramble it. XML or other data can be encrypted using the XML Encryption standard.
Enterprise Application Integration	See EAI
Event Logging	An Event Log records information about things that happen in Web Services Middleware, for example, messages sent and retrieved, problems and errors found, business processes started or stopped. They can be analyzed after the event to help identify the cause of problems and monitor the performance and behavior of the Web Services Middleware and the Web Services that run on them.
Federated Registry	A Federated Registry one that allows multiple registries to appear as if they are one large registry This works by one registry automatically searching additional registries when necessary. See also Replicated Registry
HTML	HyperText Markup Language (HTML) is the definition language used to display web pages on a web browser. See http://www.w3.org/TR/html4/
HTTP	HyperText Transport Protocol. The transport protocol originally designed for sending web pages over the internet. It is also the main protocol used for transporting SOAP messages HTTP is built on top of TCP/IP See http://www.w3.org/Protocols/
ICE	The Information and Content Exchange Protocol is a protocol that describes how to subscribe to syndicated news feeds. See http://www.w3.org/TR/NOTE-ice
IEEE	Institute of Electrical and Electronic Engineers (IEEE) is one of the De Jure standards setting organizations. See http://www.ieee.org/
IETF	The Internet Engineering Task Forces is the standards setting authority for Internet protocols such as TCP/IP More recently the standards related to web services have usually been developed within either OASIS or the W3C In the IETF, initial versions of standards are published as Internet Drafts which, once approved, become Request For Comments or RFCs See http://www.ietf.org
Implementation Policy	An implementation policy describes the rules that a particular implementation of web services will use when generating or processing a SOAP Message, for example how to digitally sign a message or the protocol to use send a message reliably.
Information Content and Exchange	See ICE
Intellectual Property	Intellectual property is associated with unique and novel ideas over which a business claims rights. Patents and copyrights are used to establish those rights. Once a business has established those rights, they can then require other businesses to get a license from them before using those ideas. Granting of a license can often involve the payment of fees.Patents and copyright have been established around many of the software ideas associated with Web Services.
Internet Engineering Task Force	See IETF
Internet Draft	An Internet Draft is the description given to initial, unapproved versions of standards published in the IETF
IP	See intellectual property
ISO	The International Organization for Standardization (ISO) is one of the De Jure standards setting organizations. See http://www.iso.ch/
ITU	The International Telecommunication Union (ITU) is one of the De Jure standards setting organizations. See http://www.itu.int/
J2EE	Java 2 Enterprise Edition is a framework, architecture and a set of associated APIs for a software platform built on top of Java for large scale computing. Originally developed by Sun Microsystems, J2EE compliant solutions are available from several vendors. See http://java.sun.com/J2EE/ See also application server and .NET
Java	Java is an object oriented programming language for developing applications. See http://java.sun.com/
Java Beans	Java Beans is an approach where an XML Schema for a document is processed to generate software known as a Java Bean. The Java Bean can be used to either read or set the data in an instance of the XML document using normal Java APIs. This means that programmers can read and create XML documents without needing to know any of the intricacies of handling XML.
Java Community Process	The Java Community Process is an open organization of Java developers and licensees who develop and revise Java technology specifications, reference implementations, and technology compatibility kits. Originally created by Sun Microsystems. See http://www.jcp.org/en/home/index
JAXB	The Java Architecture for XML Binding (JAXB) provides an API and tools that automate the mapping between XML and Java. Developed under the Java Community Process http://java.sun.com/xml/jaxb/
JAXM	The Java API for XML Messaging (JAXM) provides an API that enables applications to send and receive document oriented XML messages using SOAP with Attachments Developed under the Java Community Process See http://java.sun.com/xml/jaxm/
JAXP	The Java API for XML Processing (JAXP) provides an API that supports the processing of XML documents using DOM, SAX and XSLT Developed under the Java Community Process http://java.sun.com/xml/jaxp/
JAXR	The Java API for XML Registries (JAXR) is an API that provides for accessing different types of XML Registries Developed under the Java Community Process See http://java.sun.com/xml/jaxr/
JCP	See Java Community Process
JMX	The Java Management Extensions (JMX) is an open technology for management and monitoring systems and software running in a Java environment. See http://java.sun.com/products/JavaManagement/
JWSDL	The Java API for WSDL is an API that provides a way of representing and manipulating WSDL documents in Java Developed under the Java Community Process See http://www.jcp.org/en/jsr/detail?id=110
Key Management	Key Management is the management of the processes required for creating, updating, distributing and deprecating the keys or digital certificates required to generate digital signatures or to encrypt documents. The XML Key Management Working Group in the W3C is addressing the distribution part of Key Management with the XKMS specification. See http://www.w3.org/2001/XKMS/
Liberty Alliance	The Liberty Alliance is standards group that is developing a set of specifications for federated identity services. It allows users to link identity information between accounts without centrally storing personal information. See http://www.projectliberty.org/
Logical Address	A logical address is an identifier or an address for a Web Service that identifies who is running the service and what it does rather than where it is located on the Web. For example urn:www-dnb-com/dunsno/123456789012345/salesorder could identify the sales order service operated by the company with the DUNS no 123456789012345. Logical addresses usually need to be mapped to a physical address before a SOAP Message can be sent. Logical addresses usually remain the same even when the physical address has changed.
Message	A Message consists of an envelope and its contents. For Web Services it is a SOAP Envelope with a business document contained in the SOAP Body Messages are created by one service and then sent to another service that processes them. A Message can also contain additional documents as an attachment
Message Correlation	Message Correlation is the idea of relating one message that is sent with its reply. Typically, the first message contains a Message Identifier in a SOAP Header that is then included in the SOAP Header of any reply
Message Encryption	Message Encryption is the process of scrambling a message so that its contents are not decipherable by anyone who does not have access to the digital certificate required to unscramble the message See also encryption
Message Envelope	A Message Envelope is a way of electronically grouping together the different message parts within a message For Web Services, a Message Envelope is always a SOAP Envelope
Message Expiry	Message Expiry is information typically stored in the SOAP Header of a message that indicates to the recipient of the message the time after which the message should no longer be processed
Message Identifier	A Message Identifier is a unique identifier for a message that allows the message to be referenced and retrieved. They are often Globally Unique Identifiers or GUIDs which means that no two identifiers are ever the same. Message Identifiers are stored in the SOAP Header of a message See also Message Correlation
Message Manifest	A Message Manifest is a table of contents that identifies and locates each of the message parts in a SOAP message
Message Part	A Message Part contains a discrete separate part of a message Message Parts can be located in the SOAP Body or in an attachment
Message Privacy	Message Privacy is the idea of protecting the contents of a message from viewing by people or software that are not authorized to see it. Encryption techniques are usually used to do this. See also Message Encryption and SSL
Message Routing	Message Routing is the process of specifying the servers through which a message passes when it is sent from the original creator of the message to its final destination.
Message Security	Message Security involves one or more of: making sure that a message has not been tampered through the use of a digital signature, is kept private using Message Privacy, is authentic and authorized See also Message Privacy and Message Encryption
Message Sequencing	Message Sequencing is the idea of making sure that messages are processed in the same sequence at the destination as the sequence in which they were sent even if some of the messages were delayed so that some messages arrive after messages that were sent later
MIME	Multipurpose Internet Mail Extensions (MIME) is the widely used standard, originally and still used for email (SMTP) that is used to group together multiple documents into one message See also DIME and SOAP with Attachments
Multipurpose Internet Mail Extensions	See MIME
NAICS	NAICS is the North American Industry Classification System. It is a way by which a business can classify the types of services that they provide. It is used by UDDI See http://www.census.gov/epcd/www/naics.html
Negotiation Protocol	A Negotiation Protocol is an automated protocol that determines how two (or more) services will interoperate by agreeing the Web Services protocols and standards they are each going to use. A Negotiation Protocol should take profiles and policies as input and generate an agreement as the output.
Non Repudiation	Non Repudiation is the ability, after the event of being able to prove that something occurred. For example, by digitally signing a business document or message using a digital certificate, you can later examine the business document or message and determine who created it.
OAGI	The Open Applications Group (OAGI) is a non-profit consortium focusing on best practices and processes based on XML content for B2Bi and EAI See http://www.openapplications.org/
OASIS	Organization for the Advancement of Structured Information Standards. A not-for-profit, global consortium that drives the development, convergence and adoption of e-business standards. Together with the W3C, it is the home for the development of many of the standards used by Web Services. See http://www.oasis-open.org/
Operational Management	Operational Management is the activity of managing the operation or running of a set of Web Services and the servers on which they run. See the section on Operational Management for more detail
PASWA	See Proposed Infoset Addendum to SOAP Messages with Attachments
Physical Address	A Physical Address is the location of a service on the Web. It is typically defined as a URL See also Logical Address
PIDX	The Petroleum Industry Data exchange (PIDX) is a committee of the American Petroleum Institute. It's objective is to "achieve petroleum industry and enterprise-wide integration of business processes through seamless electronic business communication". It has developed several XML business document standards.
Policies	Policies describe the rules that are used to determine what an implementation using Web Services does in a specific set of circumstances. For example it could contains rules on whether or not a SOAP Message should be digitally signed and if so, which digital certificate to use.
Policy Definition	A Policy Definition is a description of a policy typically in some machine or computer readable form.
Port	A port is a location or interface on the web to which SOAP messages can be sent. See also WSDL
Proposed Infoset Addendum to SOAP Messages with Attachments	The Proposed Infoset Addendum to SOAP Messages with Attachments or PASWA is a specification developed by AT&T, BEA, Canon, Microsoft, SAP and Tibco. It provides an approach for "integrating XML with pre-existing [non XML] data formats". It is backwards compatible with Soap With Attachments (version 1.0). See http://www.gotdotnet.com/team/mgudgin/paswa/paswa.html
Privacy	Privacy is the process of making sure that only those that are allowed can see a message or its contents. The techniques used involve encryption See also XML Encryption and SSL
Profile	A Profile describes how standards are used in combination or in a particular context. For example: how the base web services standards of SOAP, WSDL and UDDI are used together; how they are used with other standards to make them secure and reliable; or, how they are used with specific business documents in a vertical industry. Defining profiles makes interoperability easier to realize since it limits choice. See also Profile Definitions and Basic Profile
Profile Context	A Profile context describes the set of conditions in which a specific profile is designed to be used
Protocol	In a web services context, a protocol describes how to implement some specific functionality in terms of the behavior of the sender and receiver of a message as well as the format and content of the message itself. For example a reliable messaging protocol would describe how to send a message from a sender to a receiver with a high probability that the message would be successfully delivered
RAND	Reasonable and Non Discriminatory terms are licensing terms applied to the use of intellectual property for example in a Web Services specification, that are both "reasonable", i.e. no one should find them too onerous and "non discriminatory", i.e. the same terms apply to everyone. Note that the license terms may involve the payment of license fees. See also Royalty Free
Reasonable and Non-Discriminatory Terms	See RAND
Registry	A Registry stores rules and other information that can be used when: a) designing web services and applications; and b) when those services or applications are running. Information that they store can include definitions of: services, business documents, choreographies, messages, roles, policies, agreements, profiles, business partners, users, systems, web services, standards and more. Registries can be queried to search and retrieve the information they contain. See also Registry Federation and Registry Replication
Registry Federation	A registry that is Federated is a set of registries that behave as if they are one. This means that a query on one of the registries in the set will be resent to other registries in the federation when necessary in order to complete the query. Registry Federation is an alternative to Registry Replication
Registry Replication	Registry Replication is the process of periodically or, on demand, copying information from one registry to another so that there is usually a registry available that can be used to satisfy any query. Registry replication is an alternative to Registry Federation See also UDDI
Reliable Messaging	Reliable Messaging is a protocol that allows a message to be delivered to its destination with a high probability that the message will be delivered. Reliable messaging works by requesting an acknowledgement message be sent in return to a message that was sent. If no acknowledgement is received after a period of time, the original message is resent until the acknowledgement arrives or the original sender gives up. Reliable Messaging is major component of Complex Web Services
Replicated Registry	A Replicated Registry is a registry where the information in the registry is automatically copied to other registries See also Federated Registry
Request for Comment	See RFC
Return Address	A Return Address is information stored in a SOAP Header that indicates to the recipient of the message where a reply to the message should be sent. It is also sometimes know as a callback address.
Return On Investment	A Return on Investment or ROI, is the process of measuring the benefit realized from making an investment. Both the benefit and investment can be measured in several different ways including money, time and quality. A positive ROI is often a prerequisite for many purchasing decisions.
RFC	A Request For Comment (RFC) is the final, approved form of standards specifications published by the IETF See also Internet Draft
ROI	See Return on Investment
Role	Roles are involved in business processes and describe the types of behavior that a business can take in that process. Examples of roles include buyer, seller, payer, financial institution, etc.
RosettaNet	RosettaNet is an organization that focuses on defining messaging, business document and choreography standards for the High tech Industry. See http://www.rosettanet.org/
Royalty Free	Royalty Free terms are licensing terms applied to the use of intellectual property for example for a Web Services specification. They key point in Royalty Free terms is that no license fees are involved. Note that Royalty Free does not preclude the use of other licensing terms. See also RAND
SAX	The Simple API for XML (SAX) is a common interface implemented by many XML Parsers for processing XML documents. The SAX interface starts at the beginning of an XML document and then serially processes all the XML elements until the end is reached. See http://www.saxproject.org/
Secure Sockets Layer	See SSL
Security Roadmap (IBM and Microsoft)	A roadmap for "Security in a Web Services World: A Proposed Architecture and Roadmap" See http://www-106.ibm.com/developerworks/webservices/library/ws-secmap/
Security Token	A Security Token is additional information attached to a message that increases the security of a message through encryption or the use of a digital signature
Semantics	Semantics are the explanation of the meaning of things. For example the explanation of the meaning of a shipping date on an order. Semantics are key to realizing interoperability since, unless meanings are shared, data held in, for example, business documents will be miss-understood and therefore processed incorrectly.
Semantic Definitions	Semantic Definitions are documents that describe semantics
Service	A Service is a process operated by a business that accepts requests and generates an appropriate response. For example a quotation service could accept a request for a quotation and respond with a quote. A Web Service is a service that accepts requests and generates responses using Web Service standards such as SOAP.
Service Level	A Service Level is a measure of the performance of a service They can be both technical, for example provide a response to a SOAP query within 1 second, as well as business focused, for example fewer than 0.1% errors by a data entry function. Note that all services levels must be measurable. See also Service Level Agreement and Service Level Management
Service Level Agreement	A Service Level Agreement is an agreement where one party agrees that they will perform a service for another party within an agreed set of service levels Service Level Agreements can also specify the action to be taken if target service levels are not met.
Service Level Management	Service Level Management is the process first setting service levels then recording them in a Service Level Agreement (SLA) and finally, once in place, the service levels are monitored and, if any problems occur, appropriate action take to solve the problem.
SLA	See Service Level Agreement
SMTOM	See SOAP Message Transmission Optimization Mechanism
SMTP	Simple Mail Transport Protocol (SMTP) is a widely used protocol for sending e-mail messages All e-mail systems that use the Internet use SMTP for sending messages between one email server and another. SMTP is built on top of TCP/IP See http://www.ietf.org/rfc/rfc1123.txt
SOAP Body	The SOAP Body is the second part of the SOAP Envelope It contains the payload of the message typically in the form of a business document
SOAP Envelope	The SOAP Envelope is the outermost part of a SOAP Message It contains a SOAP Header and a SOAP Body
SOAP Header	The SOAP Header is the first part of the SOAP envelope and contains additional information about the message such as Address Routing, Choreography Identifiers, Conversation Identifiers, Digital Signatures, Message Correlation, Message Expiry, Message Identifiers and Message Manifests
SOAP Message	A SOAP Message is a SOAP Envelope wrapped in a transport protocol such as HTTP or SMTP
SOAP Message Transmission Optimization Mechanism	The SOAP Message Transmission Optimization Mechanism (SMTOM) provides "a concrete implementation of it for optimizing the transmission and/or wire format of SOAP messages". This provides a mechanism for transporting multiple different parts of a message while still allowing the message to appear as XML to the application that is processing it. It is based on the ideas of PASWA See http://www.w3.org/TR/soap12-mtom/
SOAP with Attachments	SOAP with Attachments is a specification that describes how to carry a SOAP Envelope with attachments using MIME See http://www.w3.org/TR/SOAP-attachments
SOAP	The Simple Object Access Protocol (SOAP) is a protocol that describes how two servers can interact with each other by exchanging information in SOAP messages A SOAP Message consists of SOAP Envelope with a SOAP Header and a SOAP Body The original version of SOAP is version 1.1, this being replaced by version 1.2
SOAP 1.1	The original version of SOAP See http://www.w3.org/TR/SOAP/
SOAP 1.2	The replacement for SOAP version 1.1 SOAP Version 1.2 is being developed in the W3C see http://www.w3.org/TR/soap12-part1/
Software Stub	A Software Stub is automatically generated software, often generated from WSDL that allows ordinary APIs to be used to process SOAP Messages without the programmer needing to understand the detail of how SOAP works.
SSL	Secure Sockets Layer (SSL) is a protocol for sending or transmitting private messages via the Internet. It works by encrypting any data that is sent over a connection. By convention, URLs that start with "https:" instead of "http:" are using SSL. See also XML Encryption
Standard Representation	A Standard Representation is generally agreed and accepted way of defining how something appears. For example there can be a standard way of describing the structure of an XML order business document
Taxonomy	Taxonomy is the orderly classification of a set of related things where those things are given a code that identifies their position within the taxonomy. Those codes can then be used to identify and locate similar or related things. Examples of taxonomies are NAICS and UNSPSC
TCP/IP	The Transmission Control Protocol/Internet Protocol (TCP/IP) is a communications protocol developed by the US Department of Defense to enable the networking of disparate systems. It is the standard protocol of the Internet.
Transformation Definitions	A Transformation Definition, sometimes called a Transformation Map is a description of how to covert a document or message from one format to another, for example how to convert an XML Order document into its EDI equivalent.
Transformation Map	See Transformation Definition
Transport Binding	A Transporting binding describes how the messages of a protocol such as SOAP, are carried within a Transport Protocol
Transport Protocol	A Transport Protocol is a protocol that specifies at a low level how data is transferred between servers. SMTP and HTTP are the most popular transport protocols.
Transport Security	Transport Security is a method of encrypting a message as it is sent between servers. See SSL
Two Phase Commit	Two Phase Commit is a process by which two processes running at separate locations can synchronize what they do so that, at both ends, everything works or nothing works. It is based on the ideas of two-phase commit used with distributed databases to make sure that multiple copies of a database are always identical
UBL	The Universal Business Language (UBL) initiative is a Technical Committee within OASIS that is developing standard representations for business documents used in B2Bi See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl
UCC	The Universal Code Council (UCC) is non-profit organization promoting multi-industry standards for product identification and related electronic communication. See http://www.uc-council.org/
UDDI	Universal Description, Discovery and Implementation (UDDI) is a standard for storing, searching and managing information in registries It is a technical committee within OASIS. See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uddi-spec
UDDI 2.0	UDDI 2.0 is the version of UDDI that is used to create the Basic Profile within WS-I
UN/CEFACT	The United Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT) is the department of the United Nations historically responsible for defining and maintaining the international version of EDI More recently it has sponsored several standards activities related to the definition of business documents and business processes including ebXML See http://www.unece.org/cefact/
Universal Business Language	See UBL
Universal Code Council	See UCC
Universal Discovery Description and Integration	See UDDI
Universal Resource Locator	See URL
UNSPSC	The United Nations Standard Products and Services Code (UNSPSC) is a classification convention that is used to numerically identify products and services. See http://www.unspsc.org/
URL	A Universal Resource Location (URL) is standard used to specify an address of a resource on the web. The resources include: web pages, which usually start with the text "http:" and people, for example email addresses.
VESA	Video Electronics Standards Association (VESA) is one of the De Jure standards setting organizations. See http://www.vesa.org/
W3C	The World Wide Web Consortium (W3C) is the original standards setting authority that developed many of the original standards for the web such as HTML and HTTP Together with the OASIS, it is the home for the development of many of the standards used by Web Services. See http://www.w3.org
Web Server	A Web Server is a computer running software that can generate web pages for display in a browser. A Web Server uses the HTTP and HTML standards.
Web Services Choreography Interface	See WSCI
Web Services Description Language	See WSDL
Web Services Distributed Management	A technical committee within OASIS that is developing standards to support the remote management and monitoring of Web Services. See: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm
Web Services Interoperability Organization	See WS-I
Web Services Management	Web Services Management is the process of managing a set of web services no matter what technology the web service is running on. It includes change management, operational management, service level management as well as auditing of web service performance and problem resolution. See Web Services Management for more details.
Web Services Management Framework	A set of specifications that address the operational management aspects of Web Services Management. The specifications are published by: Hewlett Packard with support from: Ascential Software, BEA Systems, Informatica, IONA, Oracle, Sun Microsystems, TIBCO Software, and webMethods. See http://devresource.hp.com/drc/specifications/wsmf/WSMF-Overview.jsp The other specifications in the set are: WS Events; WSMF Foundation and WS Management
Web Services Middleware	Web Services Middleware is software that supports Web Services standards, protocols and principles providing a convenient set of APIs that an application programmer can use to develop Web Services.
Web Services Transaction Management	The Web Services Transaction Management (WS-TXM) specification developed by Arjuna, Fujitsu, IONA, Oracle and Sun provides a mechanism for handling the problems that can occur when multiple different business transactions need to cooperate and one of them fails causing the other business transactions to take some compensatory action. See http://www.arjuna.com/library/specs/ws_caf_1-0/WS-TXM.pdf
World Wide Web Consortium	See W3C
WS Acknowledgement	WS Acknowledgement is a specification published by BEA that "allows a sender of a message to request that an acknowledgement is sent in a response". See http://dev2dev.bea.com/technologies/webservices/WS-Acknowledgement-0_9.jsp
WS Addressing	WS Addressing is a specification published by IBM, BEA and Microsoft that "provides transport-neutral mechanisms to address Web services and messages". See http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-addressing.asp
WS Architecture	WS Architecture is an activity within the W3C that is "identifying the technologies necessary for Web services to be used, described, discovered and how Web services interact with each other". See http://www.w3.org/2002/ws/arch/
WS Authorization	WS Authorization is a specification that IBM and Microsoft plan to develop that will "describe how to manage authorization data and authorization policies". See IBM and Microsoft's Security Roadmap
WS Callback	WS Callback is a specification published by BEA in February 2003 that is "used to dynamically specify where to send asynchronous responses to a SOAP request". See http://dev2dev.bea.com/technologies/webservices/WS-CallBack-0_9.jsp
WS Choreography	WS Choreography is an activity with the W3C Its purpose is to "create the definition of a choreography language(s) for describing a choreography, as well as the rules for composition of, and interaction among, such choreographed Web services". See http://www.w3.org/2002/ws/chor/
WS Context	The WS-Context specification published by Sun, Oracle, Iona, Arjuna, and Fujitsu provides a mechanism for sharing context information between a set of web services that are taking part in some common process. See http://www.arjuna.com/library/specs/ws_caf_1-0/WS-CTX.pdf
WS Coordination	The WS Coordination is a specification developed by IBM, Microsoft and BEA. It "describes an extensible framework for providing protocols that coordinate the actions of distributed applications". See http://www-106.ibm.com/developerworks/library/ws-coor/
WS Distributed Management	The Web Services Distributed Management technical committee is an activity within OASIS that is defining "web services management, including using web services architecture and technology to manage distributed resources. The TC will also develop the model of a web service as a manageable resource". See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm
WS Events	The Web Services Events specification published by Hewlett Packard provides a set of XML documents that and associated processing rules that can be used for advertising, subscribing, producing and consuming Web Services. It is part of the Web Services Management Framework See http://devresource.hp.com/drc/specifications/wsmf/WS-Events.pdf
WS Federation	WS Federation is a specification developed by IBM, Microsoft, Verisign, BEA and RSA that "describes how to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities". See ftp://www6.software.ibm.com/software/developer/library/ws-fed.pdf
WS-I	The Web Services Interoperability Organization is an "open, industry organization chartered to promote Web services interoperability across platforms, operating systems, and programming languages". See http://www.ws-i.org/
WS Management	The Web Services Management Specification published by Hewlett Packard describes how the other specifications in the Web Services Management Framework can be used to manage web services. See http://devresource.hp.com/drc/specifications/wsmf/WSMF-WSM.pdf
WS MessageData	WS Message Data is specification published by BEA. It provides metadata definitions for Message Identity See http://dev2dev.bea.com/technologies/webservices/WS-MessageData-0_9.jsp
WSMF Foundation	The Web Services Management Foundation specification published by HP uses Web Services to provide management interfaces to manageable resources. It is part of the Web Services Management Framework See http://devresource.hp.com/drc/specifications/wsmf/WSMF-Foundation.pdf
WS Policy	WS Policy is a specification developed by IBM, Microsoft, BEA and SAP that provides "a general-purpose model and corresponding syntax to describe and communicate the policies of a Web service". See http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-policy.asp
WS PolicyAssertions	The Web Services Policy Assertions Language is a specification published by IBM, Microsoft and SAP. The specification "defines general messaging-related assertions for use with WS-Policy". See http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-policyassertions.asp
WS PolicyAttachments	The Web Services Policy Attachment is a specification published by IBM, Microsoft, BEA and SAP. It " specifies three specific attachment mechanisms for using policy expressions with existing XML Web service technologies". See http://www-106.ibm.com/developerworks/library/ws-polatt/
WS Reliability	WS Reliability is a specification published by Sonic, Sun, NEC, Fujitsu, Oracle and Hitachi that defines a protocol "for exchanging SOAP messages with guaranteed delivery, no duplicate s, and guaranteed message ordering"". See http://sunonedev.sun.com/platform/technologies/ws-reliability.v1.0.pdf
WS ReliableMessaging	The WS Reliable Messaging Protocol is a specification published by BEA, Microsoft, Tibco and IBM. It "describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures". See http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-reliablemessaging.asp
WS Routing	WS Routing is a specification published by Microsoft that "defines mechanisms for routing SOAP messages". See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/wsroutspecindex.asp
WS SOAP Manifest	The WS SOAP Manifest is a specification published by Commerce One. It defines ""a table of contents for a SOAP message that describes, locates and records, in a transport-binding independent way, additional meta-information about the various Message Parts within a SOAP message". See http://www.commerceone.com/developers/docs/ws-soapmanifestv1_0.pdf
WS SecureConversation	The WS Secure Conversation Language is a specification developed by IBM, Microsoft, Verisign and RSA Security that "defines extensions that build on WS Security to provide secure communication. Specifically, it defines mechanisms for establishing and sharing security contexts, and deriving session keys from security contexts". See http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-secureconversation.asp
WS Security	The WS Security specification developed by IBM, Microsoft and RSA describes "enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication". See http://www-106.ibm.com/developerworks/webservices/library/ws-secure/
WS Transaction	The WS Transaction is a specification developed by IBM, BEA and Microsoft was published. It "describes coordination types that are used with the extensible coordination framework described in the WS-Coordination specification". See http://www-106.ibm.com/developerworks/library/ws-transpec/
WS Trust	The WS Trust Language is a specification developed by IBM, Microsoft, Verisign and RSA Security that "defines extensions that build on WS Security to request and issue security tokens and to manage trust relationships". See http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-trust.asp
WSCI	Web Services Choreography Interface is a specification published by Intalio, Sun, SAP and BEA in August 2002. It is "an XML-based interface description language that describes the flow of messages exchanged by a Web Service participating in choreographed interactions with other services". It is one of the inputs into the WS Choreography activitiy. See http://www.w3.org/TR/wsci/
WSDL	The Web Services Description Language (WSDL) is a specification developed by IBM and Microsoft that defines "an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information". Version 1.2 of WSDL is being developed in the W3C See http://www.w3.org/2002/ws/desc/
WSDL 1.1	The first version of the WSDL Specification. See http://www.w3.org/TR/wsdl
WSDM	See Web Services Distributed Management technical committee.
xCBL	The XML Common Business Library (xCBL) is "a set of XML building blocks and a document framework that allows the creation of robust, reusable, XML documents to facilitate global trading". See http://www.xcbl.org/
XKMS	See key management
XML	The Extensible Mark up Language (XML) is a "simple, very flexible text format derived from SGML" developed within the W3C It is the foundational definition language for all Web Services. See http://www.w3.org/XML/
XML Common Business Library	See xCBL
XML Encryption	XML Encryption is an activity within the W3C that has developed a specification for "a process for encrypting data and representing the result in XML". See http://www.w3.org/TR/xmlenc-core/
XML Parser	An XML Parser is software that processes an XML document and makes the XML content available to an application through an API Most parsers support the DOM and SAX APIs
	XML Schema is the definition language developed in the W3C that is universally used to define the structure of XML documents. See http://www.w3.org/XML/Schema
XML Signature	XML Signature is the activity within the W3C that specified a way of digitally signing a document using XML See http://www.w3.org/Signature/
XSLT	XSLT is the activity within the W3C that specified a way of transforming XML into other formats such as HTML. See http://www.w3.org/TR/xslt

About the Author

David Burdett is Director of Standards Strategy, Web Services for Commerce One. He is responsible for directing Commerce One's use of Web Services standards in its products and solutions. Recently he has played leading roles in Web Services and eCommerce standards including: Web Services Architecture, ebXML, UBL and the Internet Open Trading Protocol - the first XML based eCommerce protocol that pre-dated all other XML eCommerce initiatives.

He is also an experienced consultant with over 20 years experience in managing and motivating teams in IT strategy, development, architecture and organization in industries including: finance, insurance, distribution, security regulation, utilities, oil, entertainment, accountancy, legal and healthcare.

He has also authored several articles and books on Web Services and XML technology.

David is a British citizen who holds a Masters Degree in Computer Science. He currently lives in the Bay Area.

David can be contacted on david@davidburdett.com His weblog is at http://www.davidburdett.com