Web Services Architecture

An orchestration description reflects a simple choreography of Web service invocations between two business partners to complete a multi-step business interaction. For example an agreement definition defines roles such as buyer and seller within a purchasing protocol. The agreement definition outlines the requirements that each role must fulfill. For example, the seller must have web services that receive request for quote (RFQ) messages, purchase order (PO) messages and payment messages. The buyer role must have Web services that receive quotes (RFQ response messages), invoice messages and account summary messages. This simple choreography of web services into business roles is critical for establishing multi-step service-oriented interactions between business parties. A given service requestor or service provider might be able to play the buyer or seller role in a number of different business process flow standards. By explicitly modeling business agreements and each node’s ability to play roles in the business agreement, the requestor can choose which business agreement to engage in with various provider business partners.

4.3.2.2 Orchestration

4.3.2.3 Service Level Agreements

4.3.2.4 Business Level Agreements

While the bottom three layers of the stack identify technologies for compliance and interoperability, the service publication and service discovery can be implemented with a range of solutions.

4.4 Discovery Agencies "Stack"

Any action that makes a WSDL document available to a requestor, at any stage of the service requestor’s lifecycle, qualifies as service publication.

Since a web service cannot be discovered if it has not been published, service discovery depends upon service publication. The variety of discovery mechanisms parallels the set of publication mechanisms. Any mechanism that allows the service requestor to gain access to the service description and make it available to the application at runtime qualifies as service discovery. The simplest, most static example of discovery is static discovery wherein the service requestor retrieves a WSDL document from a local file. This is usually the WSDL document obtained through a direct publish or the results of a previous find operation. Alternatively, the service may be discovered at design time or run time using a local WSDL registry, or a public or private registry such as UDDI. The variety of service discovery mechanisms is discussed in more detail in the section titled Service Discovery.

4.4.1 Service Publication

4.4.1.1 Producing Service Descriptions

The service description may be generated, hand coded, or pieced together based on existing service interface definitions etc. Developers may hand code the entire service description, including the UDDI entry. Tools exist to generate parts of the WSDL and potentially parts of the UDDI entry from metadata artifacts from the programming model and the deployment of the web service executable. Parts of the service description may already exist (for example the web service may be based on an industry standard service interface definition) such that very little needs to be further generated.

Editorial note
CBF: needs to be made less UDDI-centric

4.4.1.2 Publishing Service Descriptions

A service description can be published using a variety of mechanisms. These various mechanisms provide different capabilities depending on how dynamic the application using the service is intended to be. The service description may be published to multiple service registries using several different mechanisms. The simplest case is a direct publish. A direct publish means the service provider sends the service description directly to the service requestor. This can be accomplished using an e-mail attachment, an FTP site, or even a CDROM distribution. Direct publish can occur after two business partners have agreed on terms of doing e-business over the Web, or after fees have been paid by the service requestor for access to the service. In this case the service requestor may maintain a local copy of the service description. Slightly more dynamic publication uses WSIL. WSIL defines a simple HTTP GET mechanism to retrieve Web services descriptions from a given URL. An enhanced service description repository would provide a local cache of service descriptions, but with additional search capabilities.

Another means of publishing service descriptions available to Web services is through a UDDI registry. There are several types of UDDI registries that may be used depending on the scope of the domain of Web services published to it. When publishing a Web service description to a UDDI registry, complete business context and well thought out taxonomies are essential if the service is to be found by its potential service consumers.

Internal Enterprise Application UDDI registry: Web services for use within a company for internal enterprise applications integration should be published to a UDDI registry of this kind. The scope of this UDDI registry may be single application, departmental, or corporate. These UDDI registries sit behind the firewall and allow the service publishers more control over their service registry and its accessibility, availability, and publication requirements.
Portal UDDI registry: Web services published by a company for external partners to find and use may use a portal UDDI registry. A portal UDDI registry runs in the service provider’s environment outside the firewall or in a DMZ between firewalls. This kind of private UDDI registry contains only those service descriptions that a company wishes to provide to service requestors from external partners. This allows companies to retain control of their service descriptions, access to the UDDI registry and quality of service for the UDDI registries. Moreover, by using the Role based visibility inherent in portals, and emerging in newer drafts of the UDDI specs themselves, the enterprise may limit visibility of service descriptions to the partners authorized to see their existence.
Partner Catalog UDDI registry: Web services to be used by a particular company can be published to a Partner Catalog (rolodex like) UDDI registry. A Partner Catalog UDDI registry sits behind the firewall. This kind of private UDDI registry contains only approved, tested, and valid web service descriptions from legitimate business partners. The business context and metadata for these web services can be targeted to the specific requestor.
e-Marketplace UDDI registry: For web services that the service provider intends to compete for requestors' business with other web services, the service description should be published to an e-Marketplace UDDI registry or the UDDI Business Registry. E-Marketplace UDDI registries are hosted by an industry standards organization or consortium and contain service descriptions from businesses in a particular industry. These services may be required to support specific standards, searchable meta data, interfaces, or data types E-Marketplace UDDI registries will generally provide some filtering of illegitimate entries as well as some guaranteed qualities of service.
UDDI Business Registry: Web services may also wish to publish to the UDDI Business Registry in some other public registry in order that they may be discovered by new potential business partners or service users.

This figure shows the continuum from the most static, easiest technologies for publish and discovery to the most dynamic, more complex technologies. Users or implementers of web services may not follow this progression in strict sequence.

Editorial note
CBF: is there a missing graphic here?

4.4.2 Service Discovery

4.4.2.1 Acquiring Service Descriptions

As with publishing Web service descriptions, acquiring Web service descriptions will vary depending on how the service description is published and how dynamic the Web service application is meant to be. Service requestors will find Web services during two different phases of an application lifecycle – design time and run time. At design time, service requestors will search for web service descriptions by the type of interface they support. At run time service requestors will search for a web service based on how they communicate or qualities of service advertised.

With the direct publish approach, the service requestor will cache the service description at design time for use at runtime. The service description may be statically represented in the program logic, stored in a file, or in a simple, local service description repository.

Service requestors can retrieve a service description at design time or runtime from a Web page (URL), a service description repository, a simple service registry or a UDDI registry. The look-up mechanism will need to support a query mechanism that provides find by type of interface (based on a WSDL template), the binding information (i.e. protocols), properties (such as QOS parameters), the types of intermediaries required, the taxonomy of the service, business information, etc.

The various types of UDDI registries have implications on the number of runtime binding web services can choose from, policy for choosing one among many, or the amount of pre screening that must be done by the requestor before invoking the service. Service selection can be based on binding support, historical performance, quality of service classification, proximity, or load balancing. E-Marketplace UDDI registries will have more runtime services to choose from. Some pre screening must be done to verify that the web service provider is a worthy partner and is not nefarious or inept. Choosing a service may be done based on price promises, cost, presence on approved partners list, as well as binding support, historical performance, quality of service classifications, and proximity. If service requestors query the UDDI Business Registry for web service providers, they will have to exercise the most caution and diligence when prescreening potential service providers. An efficient and accurate filter will have to be in place to return only suitable descriptions and potential business partners.

4.4.2.2 Consuming Service Descriptions

Once a service description is acquired, the service requestor will need to process it in order to invoke the service. The service requestor uses the service description to generate SOAP requests or programming language specific proxies to the web service. This generation can be done at design time or at runtime to format an invocation to the web service. Various tools can be used at design time or runtime to generate programming language bindings from WSDL documents. These bindings present an API to the application program and encapsulate the details of the XML messaging from the application.

4.4.2.3 Inspection

Inspection technologies such as WSIL provide a de-centralized service discovery method. It may be used to discover Web services at the service provider's point-of-offering. The WSIL specification defines a document format that contains a list of WSDL URLs and other related WSIL URLs within a domain. WSIL can also reference UDDI entries/repositories and RDF documents as well. It can actually contain references to anything. The WSIL specification defines a convention for naming and placing the files so that they are easier to locate (similar to index.html and robots.txt files). Inspection technologies, unlike registries, is not suited for many/most of the dynamic discovery/bind scenarios, simply because there is no searching capability.

They may or may not be local to the system. WSIL documents can be used to enable a variety of discovery agent patterns:

Local service discovery for ‘local’ web service applications (micro SOAs that don’t leave the box… all else is the same except it limits where it looks for services).
Application integration.
Discovery agents populated by crawlers looking for WSIL documents.
Management topologies of available services (but its not a discovery source).

Editorial note
CBF: this section needs more, we can get some help the WSIL folks

4.5 Overarching Concerns

4.5.1 Security Concern

Editorial note
CBF: To be further developed...

High-level application interactions may require trust between partners, confidence in the data exchanged, or confidentiality. (The Web services architecture provides support for traditional security artifacts. @@@)

The Web services architecture defines a certain number of roles (@@@ see roles section) and data exchanges (messages, description documents, etc).

First, an agent acting in a defined role and therefore taking part into a Web service interaction may authenticate itself to the other agents it is interacting with.

Second, any interaction may need to be authorized. Authorization can be done in a variety of ways: using a username/password combination, using tokens, etc.

Third, the data exchanged, in the form of a message or any other document (e.g. service description), may have its authorship identified and its integrity guaranteed. Integrity guarantees can be enabled at different layers.

Finally, any of the data used may need to be kept confidential and be accessible only to interested parties. This can be done at the transport layer level, as well as at the message level.

Candidate technologies:

Editorial note
(@@@ need list to be made more open: non-repudiation, etc.)

Web Services Security Core Specification [23] : message level integrity and confidentiality
XKMS[20] : obtaining security information (values, certificates, management or trust data) from a Web service
XML Signature[21] : document signing
XML Encryption[22] : document encryption

4.5.2 Quality of Service Concern

Editorial note
CBF: To be developed...

As Web services become pervasive and critical to business operations, the task of managing Web services and the Web services architecture will be imperative to the success of such operations. Management in this case is defined as a set of capabilities for; discovering the existence, availability, health, and usage, as well the control and configuration of resources, where resources are defined as Web services, agents of the Web services architecture, and roles undertaken in the architecture.

4.5.3 Management Concern

4.5.3.1 Managed Resources

Managed Resources includes the agents of the Web service architecture (Service, Service Environment, Client, Client Environment, Service Description) and roles defined in a Web service architecture (Discovery Agency, Requestor, Providor).

4.5.3.2 Management

Management includes the systems that use information and control mechanisms exposed by the resources to be managed. For example, Management systems may use and correlate information to determine and display topologies, status, events. Mangement systems may also use this information to monitor and compare with policies for automated control or configuration.

4.5.3.3 Manageability

Manageability includes the information and control semantics that managed resources expose to management systems. Manageability information includes identification, configuration, metrics, operations, and events for the resource. It also includes the means by which manageability is exposed to management applications and mechanisms for control and configuration.

4.5.3.4 Manager Role

As a result of these definitions it is useful to introduce the role of the Manager which uses the manageability information provided by the manageable resources. Since, the manager needs to be able to manage all of the agents of the Web services architecture, it needs to be able to ‘discover’ manageable resources and access management information of the resource, as well as utilise the control and configuration mechanisms exposed. The Web service Architecture will define the basic set of management information, and control mechanisms supported by each resource identified in the architecture The definition of the ‘Manager’ role, beyond the information model offered to it and how it interacts with the existing roles of the Web services architecture, is outside the scope of this architecture document, which will neither define how the Manager is implemented or how an implementaion is to use the manageability information.

The management concern is satisfied by defining the architecture necessary to make a Web service architecture implementation and a Web service implementation manageable. This architecture must define the minimum, basic information, metrics, configuration, operations, events, and behaviors that a Web services agent must implement in order to be called a ‘manageable Web services agent’. Not all agents must be manageable. Not all Web services architecture implementations must be manageable. Support of this manageable Web services architecture by implementations of the Web services architeture is higly recommended, but not required.

To summarize, the Web Services Architecture does not specify how management concept should to be implemented and does not prescribe any specific management systems. It defines:

Extensible Management Information Schema that directly correlates with the WS Architecture roles
Base set of Management Operations/Events (Manageability) that WS Architecture roles need to provide
Access to Management Information/Operations/Events (Manageability)
Discovery of Access to Management Information

Essentially, it defines an extensible information set and information flow that enable various interested parties to realize management of implementations of Web Services and Web Services Architectures.

4.5.3.5 Manageable agents

In order for the Web service architecture to be manageable, each of the agents of the architeture must be manageable.

Service environment concept is critical to managing Web services. For the agents of a web service application, supporting a management environment can add significant complexity to an application. The service environment should simplify this for services by automatically providing metrics, audit logs, start/stop processing, event notification, and other management functions as part of a services execution environment. Since not all information can be gleaned by the infrastructure through observing the behavior of the agents it hosts, a web service implementation may need to provide basic health and monitoring information to its hosting environment or directly to the manager.

At this time the agents to be managed are:

Service Environment
Web Service
Discovery Agency

Additional managable agents may emerge as the architecture definition progresses, including Client Environment, Client, Intermediary, Gateway, Hosted Service, and Service Proxy.

4.5.3.6 Manageability Information

The following management information categories must be defined for each manageable agent:

Identification – read only data that uniquely identifies the agent. This data may include information that is not required for unique identification
Configuration – read only and read/writeable data that represents the configuration of the data agent
Metrics – a value that captures a state at a point in time. Generally these values are numeric, but may be strings as well. A service should allow customization so that metrics can be returned that reflect values accumulated since the service status became ‘Up’, within a sliding window relative to ‘now’ or current time, and within a time interval. A service must declare in its management portType which of these metric interval types are supported.
Operations – methods that control the agent. Operations are distinct from configuration changes in that configuration changes are generally persistent over interations/instances of the agent. Operations includes lifecycle control.
Events – one way messages from the agent that indicate a problem, a lifecycle state change, or a state change.

4.5.3.7 Access to Manageability Information

In addition to defining the information to be exposed by a manageable agent, this architecture must define a standard means to access this information. Access must be defined for the management information from the Web Service Execution Environment, Web Service, Discovery Agency, and Web Service client.

4.5.3.8 Manageability Discovery

Finally, it must be possible for the manageability information and access to that information to be discovered. Hence we need to define the discovery of managable agents as well as the management information.

4.5.3.9 Realization in Web Services Architecture

Since the Web services architecture defines how to define information, operations, and notifications through WSDL portTypes, access through bindings, and locateability through ports, it is consistent to use the Web services architecture to describe as well as provide access to and discoverability of the manageable agents of the Web services architecture itself.

A Web service can define its manageability information in a portType and service that is available to the manager or environment. A manageability service WSDL document can be defined that a web service implements to provide access to a web service’s management information by management systems. This interface would include the ability to get configuration and metric data, update configurations, and receive events from manageable web service that the manageability service represents. Other agents of the Web services architecture can provide their own manageability portTypes and ports as well.

The management interface, or service port, of a Web Service, Execution Environment, or Discovery Agency is identified by a URI. This URI will be bound directly to a port type described by WSDL. The WSDL document may contain multiple bindings, including a SOAP over HTTP and an HTTP binding, which allows direct HTTP Get of manageability data items via a URL. The manageability WSDL should be published or advertised to a discovery agency. This provides for the following variation of the Web services oriented architecture triangle:

Editorial note
This probably should be added to Usage Scenarios doc

In this scenario we take the Web services architectural triangle, we can decorate it with the artifacts and roles for management activities. In this example we add the following artifacts

A service environment that the service runs in. The service environment is part of the service provider
A management portType for the execution environment which it advertises (grey oval).
Management portTypes for the Discovery Agencies which they advertise (yellow oval).
A management portType for the service which the service provider advertises (green oval)
A business portType and for the service which the service provider advertises
A discovery agency for management portTypes. The management portType is advertised with a different discovery agency than the busines portType. This is for illustration purposes only and certainly the both portTypes could be available from the same discovery agency.
A business service requester (i.e. stockquote requester) which has access to the business operations.
A separate management service requester which has access to the management operations. Certainly, these requesters could be one and the same.

In this scenario, a manageable service is advertised by the service provider in a management discovery agency. The management service requester discovers the existence and interface of a manageable Web service. It then interacts with the management portType to access the management data of the service.

This same scenario works for management requesters who want to interact with the management PortTypes of the discovery agencies and execution environment. The management service requester can discover the managability portType for the discovery agencies, service environment, and service and interace with any of these agent just like the example of their interaction with a service.

This scenario is not meant to be exclusive of all other ways to advertise and pass manageability information to managers.

4.6 The Complete Web Services "Stack"

Extended Web services architecture graphic

The figure above illustrates the complete stack of functions contained in the extended Web services architecture. The extended functionality includes additional technologies in the following areas: discovery agencies, description, and wire. The extended architecture also includes overarching concerns such as security, management, and qualites of service that apply to all agents in the Web services architecture.

Editorial note
CBF: what about privacy? where should this be reflected in the stack?

Editorial note
EN: As with the basic architecture, a next step after completing the description of the diagrams will be to fill in the diagrams with reference technologies and specifications.

5 Web Service Architecture

[EN: This seems like a good place to insert the "stakeholders perspective" information Frank developed, meaning once we get through the qualities and the Web services stack, then we can go through the stakeholders' perspective and validate that the requirements are met.]

Stakeholders' viewpoints

In this section we examine how the architecture meets the Web services requirements. We present this as a series of stakeholders' viewpoints; the objective being that, for example, security represents a major stakeholder's viewpoint of the architecture itself.

Editorial note
When developing a particular stakeholder's viewpoint, one should make sure that the concepts discussed are properly documented in the architecture.

Scalability and extensibility

According to the Web services Architecture requirements, it is a major goal of the architecture that any implementations are inherently scalable and extensible.

This goal is broken down into five critical success factors: modularity, extensibility, simplicity, migration from EDI and peer to peer.

Modularity

The critical success factor AC002 focuses on the modularity of the architecture; with appropriate granularity. This is reduced to an overall conceptual integrity with appropriate decomposition and easy comprehension.

Our architecture is laid out using the simple style of concepts and relationships. This modeling technique is simple, and yet allows us to expose the critical properties of Web services. A major design goal of the architecture has been the appropriate separation of concerns. In general, this is achieved by rigorous minimalism associated with each concept: only associating those properties of a concept that are truly necessary to meet the requirements.

The overall themes in this architecture can be summarized as:

Web services are used and presented by agents interacting on behalf of real-world actors.
Message structures, service interfaces, conversations are first of all explicitly identified and potentially described using using a variety of description languages. This has the effect of documenting the various aspects involved in two or more interacting Web services.
Minimal assumptions about required components. For example, although Web services may be documented, it is not required. Similarly, although descriptions may be published, that is also not required.

Extensibility

Peer to peer interaction

To support Web services interacting in a peer to peer style, the architecture must support peer to peer message exchange patterns, must permit Web services to have persistent identity, must permit descriptions of the capabilities of peers and must support flexibility in the discovery of peers by each other.

In the message exchange pattern concept we allow for Web services to communicate with each other using a very general concept of message exchange. Furthermore, we allow for the fact that a message exchange pattern can itself be identified -- this permits interacting Web service agents to explicitly reference a particular message pattern in their interactions.

A Web service wishing to use a peer-to-peer style interaction may use, for example, a publish-subscribe form of message exchange pattern. This kind of message exchange is just one of the possible message exchange patterns possible when the pattern is explicitly identifiable.

In the agent concept we note that agents have identifiers. The primary role of an agent identifier is to permit long running interactions spanning multiple messages. Much like correlation, an agent's identifier can be used to link messages together. For example, in a publish and subscribe scenario, a publishing Web service may include references to the Web service that requested the subscription, separately from and additionaly to, the actual recipient of the service.

The agent concept also clarifies that a given agent may adopt the role of a service provider and/or a service requestor. I.e., these are roles of an agent, not necessarily intrinsic to the agent itself. Such flexibility is a key part of the peer to peer mode of interaction between Web services.

In the service concept we state that services have a semantics that may be identified in a service description and that may be expressed in a service description language. This identification of the semantics of a service, and for more advanced agents the description of the service contract itself, permits agents implementing Web services to determine the capabilities of other peer agents. This is turn, is a critical success factor in the architecture supporting peer-to-peer interaction of Web services.

Finally, the fact that services have descriptions means that these descriptions may be published in discovery agencies and also retrieved from such agencies. In effect, the availability of explicit descriptions enables Web services and agents to discover each other automatically as well as having these hard-coded.

Long running transactions

In CSF AC017 are identified two requirements that support applications in a similar manner to traditional EDI systems: reliable messaging and support for long-running stateful choreographed interactions. This architecture supports transactions by allowing messages to be part of message exchanges and extended choreographies. It also permits support for message reliability.

Conversations

Conversations are supported in this architecture at two levels: the single use of a Web service and the combination of Web services.

A message exchange pattern is defined to be the set of messages that makes a single use of a service. Typical examples of message exchange pattern are request-response, publish-subscribe and event notification.

The details of the message exchange pattern may be documented in a service description — expressed in a service description language such as WSDL.

In addition, the architecture supports the correlation of messages by permitting messages to have identifiers.

Web services may be combined into larger scale conversations by means of choreographies. A choreography is the documentation of the combination of Web services, leaving out the details of the actual messages involved in each service invokation and focusing on the dependencies between the Web services.

Of particular importance, both to individual message exchange patterns and combined services, is the handling of exceptions.

Message reliability

The Web services architecture consists of:

A single specification of the way in which artifacts of the system are identified: the Uniform Resource Identifier (URI) [1] (see section 5.1 Identifiers.).
A non-exclusive set of data formats designed for interchange between agents in the system (see section 5.2 Formats.).
A small and non-exclusive set of protocols for interchanging information between agents (see section 5.3 Protocols.).
A small and non-exclusive set of ... (see section 6 Processing Model).
Issue (procmod):
Is Process Model a foundational architectural aspect?
Resolution:
None recorded.

Each of these is discussed in detail in the following sections.

5.1 Identifiers

The Web services architecture builds directly upon the Web Architecture [7]. As such, the Web services architecture directly leverages the definition of, and architectural constraints placed on, identifiers from the Architecture Principles of the Web [7].

Issue (qnames):

What about QNames as identifiers as used by WSDL? TAG Finding.

Resolution:

None recorded.

Issue (uuids):

What about UUIDs as identifiers as used by UDDI? Don't believe that there is a formally registered URI scheme for UUIDs.

URIs MUST be used to identify all conceptual elements of the system (see Web Services Architecture Requirements: AR009.3).

5.2 Formats

As with identifiers (see section 5.1 Identifiers), the Web services architecture builds upon the definition of, and architectural constraints placed on, formats from Architecture Principles of the Web [7].

...

5.2.1 XML Infoset

Specifications for data formats used in the context of Web services SHOULD be based on XML Infoset [2]. XML Infoset is not a data format per se, but a formal set of information items and their associated properties that comprise an abstract description of an XML document [3]. The XML Infoset specification provides for a consistent and rigorous set of definitions for use in other specifications that need to refer to the information in a well-formed XML document.

Serialization of the XML Infoset definitions of information MAY be expressed using XML1.0 [3]. However, this is not a requirement. The flexibility in choice of serialization format(s) allows for broader interoperability between agents in the system.

Editorial note

CBF: cite examples of possible alternate serializations such as compressed or binary XML.

5.2.2 XML Schema

Specification of message formats, structures and datatypes SHOULD be based on the W3C XML Schema: Structures [4] and XML Schema: Datatypes [5] specifications.

Issue (otherschema):

What about other schema languages such as RELAX NG, Schematron, DTD?

5.2.3 SOAP

One of the key specifications used in the context of Web services is SOAP [8]. The format of a SOAP message is formally defined in the SOAP1.2 Part 1: Messaging Framework specification. However, SOAP is much more than simply a message format.

Editorial note
refer to (and develop!) other sections describing extensibility, binding framework, and process model.

5.2.3.1 SOAP Extensibility

SOAP provides a simple messaging framework whose core functionality is concerned with providing extensibility. Extensions to the base messaging framework defined by SOAP are modeled and specified as abstract features. Example features include "reliability", "security", "correlation", and "routing". The Web services architecture describes a number of these features (see section 3.2.1 Features), their inter-relationships with one another, and their purpose within the overall architecture.

A SOAP feature MUST clearly and completely specify the content and semantics of the properties used to implement the desired behavior, including any modifications to the SOAP Processing Model (see section 5.2.3.3 Process Model).

All SOAP Features MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 5.2.4 WSDL).

Expression of a SOAP Feature is accomplished through one of the two mechanisms provided for by SOAP:

the SOAP Binding Framework, or
as a SOAP Module

One special type of SOAP Feature is the Message Exchange Pattern (MEP). A MEP is a template that establishes a pattern for the exchange of messages between SOAP nodes. Examples of MEPs include: request/response, oneway, peer-to-peer conversation, etc. A MEP MAY be supported by one or more underlying protocol binding instances either directly, or indirectly with support from software that implements the required processing to support the SOAP Feature as expressed as a SOAP Module.

All MEPs MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 5.2.4 WSDL).

Issue (wsdlmep):

WSDL identifies MEPs using QNames, not URIs.

5.2.3.1.1 SOAP Module

A SOAP Module is a formally specified expression of a SOAP Feature as one or more SOAP header blocks. Refer to the SOAP specification for the detailed requirements of a SOAP Module. A SOAP Module is typically used to express a feature that is not provided for either directly or indirectly through mechanisms of the bound transport, or transfer, protocol. They are also used for the expression of end-to-end SOAP Features that might span multiple, disparate transport, or transfer, protocols as the message is conveyed from original sender to ultimate receiver.

5.2.3.2 SOAP Protocol Binding Framework

SOAP provides for the exchange of messages between software agents known as SOAP nodes using a variety of underlying transport, or transfer, protocols. The formal set of rules for exchanging a SOAP message via an underlying protocol is called a binding. The SOAP Protocol Binding Framework provides general rules for the specification of bindings to an underlying protocol. The framework also describes the formal relationship between bindings and the SOAP nodes that implement those bindings.

All SOAP Protocol Bindings MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 5.2.4 WSDL).

Issue (soapbinduri):

SOAP1.2 does not REQUIRE that a binding specification be identified with a URI.