Technical Note
Using WS-Addressing and UDDI
Document identifier:
uddi-spec-tc-tn-usingwsa-20051205.doc
Location:
Author:
Tony Rogers, CA
Editors:
[List your editors here]
Jason Garbis, Systinet (a Mercury Division)
Contributors:
[List your contributors here]
[Optionally list them in the Acknowledgments appendix instead]
Abstract:
WS-Addressing is a standard being developed under the auspices of W3C. It addresses a number of concerns relating to communication between web services and their clients. The primary data structure used in WS-Addressing is the End Point Reference (EPR), and one of the key features of the EPR is that it is client-specific – the EPR provided for one client to access a given web service may well be significantly different from the EPR provided for another client. This is notably different from UDDI, wherein the access point provided for a web service is the same for all enquirers. This might lead a casual read to conclude that WS-Addressing and UDDI are incompatible. This Technical Note explains how these apparent incompatible standards can be reconciled.
Status:
This document is updated periodically on no particular schedule. Committee members should send comments on this technical to the list. Others should comment at
For information on whether any intellectual property claims have been disclosed that may be essential to implementing this change request, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the UDDI Spec TC web page (
Table of Contents
1Introduction
1.1Problem statement
1.2Terminology
2Technical note Solution
2.1Definitions
2.2Technical note behavior
2.2.1Background for those not familiar with WS-Addressing and EPRs
2.2.2Finding the EPR minter for a Web Service
2.2.3Support for WS-Addressing
2.3Discussion
2.3.1tModels – three versus one keyed reference
2.3.2Connection via a keyed reference versus access point
2.3.3The web service points to its minter, not vice versa
2.4TModel definitions
2.4.1The WS-Addressing EPR Minter Reference TModel
2.4.2The WS-Addressing Marker TModels
2.5Example
2.5.1Heavyweight Minter
2.5.2Lightweight Minter
3References
3.1Normative
Appendix A. Acknowledgments
Appendix B. Revision History
Appendix C. Notices
1Introduction
WS-Addressing is a standard being developed under the auspices of the W3C. The WS-Addressing core document describes WS-Addressing as:
[jag] This section needs a more thorough introduction. I suggest including portions of the abstract here, and fleshing out the following
Web Services Addressing provides transport-neutral mechanisms to address Web services and messages. It defines properties…to facilitate end-to-end addressing of endpoints in messages. It enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.
The key data structure used by WS-Addressing is the End Point Reference (EPR). The EPR is described as supporting:
- Dynamic generation and customization of service endpoint descriptions.
- Referencing and description of specific service instances that are created as the result of stateful interactions.
- Flexible and dynamic exchange of endpoint information in tightly coupled environments where communicating parties share a set of common assumptions about specific policies or protocols that are used during the interaction.
One of the key points about the EPR is that it is dynamically generated, and different clients may well receive different EPRs for the same web service (the rationale for this is to support functionality such as “shopping carts”, where each potential customer has a shopping cart of their own).
UDDI is a registry which is designed to provide provides the same information to all enquiries, so each request for the access point for a web service will receive the same answer.
The key issue addressed in this technical note is that of how a UDDI Registry and WS-Addressing can not just coexist, but also benefit from each other. This note introduces an approach to reconciling WSA’s dynamic EPR with UDDI’s static access point.
How do we reconcile the dynamic EPR with the static access point?
1.1Problem statement
The WS-Addressing standard is silent on the subject of how a WS-A-aware client is to obtain the EPR it requires to initiate a conversation with a web service. [jag] need 1-2 sentences here explaining how typical WS-A implementations solve this problem. And, introduce that use of a UDDI Registry is best practices in an SOA.
This TN suggests that one means is for the client to start by locatingthe web service in a UDDI registry, but there is still a problem. The problem is one of obtaining an EPR. It would be both inappropriate and impractical to store EPRs in the UDDI registry, so an intermediate step is required.
1.2Terminology
The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC2119].
This Technical Note will use the terminology of UDDI and of WS-Addressing. The reader is referred to the UDDI Standard Version 3, and the WS-Addressing Recommendation Version 1, for the definitions of terms.
2Technical note Solution
2.1Definitions
EPR
An End Point Reference – an XML structure holding the information required to invoke a web service. Defined by the WS-Addressing standard.
Minter
A service piece of software which creates an EPR. It usually creates an EPR on demand for a specified web service for a particular client.Not defined in the WS-Addressing core document, but a common term when discussing the subject. The term comes from a “mint”, which is the place where coins are made, where the coins are “minted”. [jag] is it fair to say that minters themselves are typically exposed as web services? At the least we should say that we assume that this will be the case, as this is how we are modeling this in UDDI
2.2Technical note behavior
This Technical Note concerns itself with the gap between locating a desired web service (herein referred to as the “target web service”) in a UDDI registry and invoking that web service using an EPR. How the web service might be located in the UDDI registry is a matter of pure UDDI, and not in scope for this TN. How the web service might be invoked using the EPR is a question of WS-Addressing, and is again out of scope. Here we are simply talking about going from the UDDI binding template to an EPR.
2.2.1Background for those not familiar with WS-Addressing and EPRs
It is prudent to provide a little explanation for those unfamiliar with WS-Addressing.
The core of WS-Addressing is the End Point Reference, a data structure containing information relevant to one interaction between a client and a web service. Note that said interaction may be as little as a single call, or may be a complete conversation of many calls and responses. Most importantly, the parts of the content of an EPR can be specific to a particular interaction. It may contain information which distinguishes this interaction from others (such as a shopping cart id, if the interaction is a purchasing sequence).
As an aside, an EPR will usually hold:
- the address to which the message must be sent
- the action required
- an EPR indicating where the response (if any) should be sent
- an EPR indicating where the fault (if any) should be sent
- any additional information which must be included in the message (reference parameters)
Because each EPR can be specific to a particular interaction, it cannot be stored in a registry, nor made part of a WSDL file; an EPR must be obtained dynamically, with a fresh EPR obtained for each interaction. Something must create the EPR for an interaction. That something is called a minter. For the purposes of this TN we will assume that the minter is a web service (extending this TN to non-web-service minters is an exercise left up to the reader).Note that there may be a different EPR minter for every web service, or there may be minters which can create EPRs for many web services.
2.2.2Finding the EPR minter for a Web Service
The minter web service will almost certainly take parameters that are different from those of the target web service, so it must be described using WSDL of its own, and a different binding template.
The binding key of the minter web service binding template will be attached to the binding template of the target web service using a keyed reference in the target web service category bag. This keyed reference will use the uddi-org:wsaEprMinter tModel, the binding key as the value, and “WS-Addressing EPR Minter” as the name. A web service can only have one such keyed reference in the category bag of its binding template.
Note that the web service which is addressed by EPR points to its minter – this is discussed in detail below.
2.2.3Support for WS-Addressing
Web service bindings can be categorized [jag] we shouldn’t use the term “categorized” since we are not proposing a categorization based solution. How about “classified” ?
by the support they give to WS-Addressing. They may:
- Only be accessible using WS-Addressing
- Be accessible using WS-Addressing or not
- Not be accessible using WS-Addressing
[jag] We need to clean up some terminology in the doc – the proposal in the TN is to use the bT’s tModelInstanceDetails/tModelInstanceInfo to contain one of the three WSA tModels proposed. This needs to be spelled out explicitly – this is what defines the binding’s “technical fingerprint”. The doc uses the term “tModelBag” improperly – this structure is not part of the bindingTemplate – it’s only used as a parameter to the UDDI API’s. Phrases such as “a binding template’s tModel bag” will be confusing to the reader.
To allow UDDI clients to refine their search for a web service binding based on its support of WS-Addressing (or lack thereof) this Technical Note also defines three tModels that may be included in a binding template’s tModel bag to contribute to its technical fingerprint –a binding template may only include one of the three (including more than one is a contradiction). A fourth tModel is defined for inclusion in the EPR minter’s binding template tModel bag.
Note that any binding template which does not contain one of the three tModels described above is considered to be “unknown”; that is, we do not know anything about its support of WS-Addressing.
2.3Discussion
2.3.1tModels – three versus one keyed reference
[jag] I think there are 2 dimensions here that drive this
1, Is this a categorization of the bT, or is this part of it’s fingerprint?
2. What are the use cases that support one approach versus the other?
I think you could argue both sides for #1. But I think #2 is compelling enough to drive us to recommending using tModels in the fingerprint and not in a bT catBag – the argument for doing this via the find_service’s tModelBag argument is strong.
The choice between using three tModels (as advocated in this TN) and using one tModel in a keyed reference is not a straightforward one.
Using a single tModel has the attraction of simplicity. Given that bindings have category bags in UDDI V3, and that one can search the category bags of bindings even when searching for business entities or business services, the option of defining a tModel that represents the degree of support of WS-Addressing is appealing. A keyed reference with a tModel key of, say, uddi-org:wsaSupport, and possible values of “required”, “allowed”, and “unsupported”, would address the question readily.
However, the choice of three tModels, one for each of the possible levels of WS-Addressing support, has some compelling arguments. The fact that this approach is equally usable in UDDI Version 2 is not especially relevant (given the lack of a binding template category bag in Version 2, the rest of this TN cannot be implemented).
The “three tModel”approach makes it possible to specifythe desired level of WS-Addressing support in a search for a business service (or business entity) with particular categorizations – one includes the appropriate tModel key in the tModel bag as part of the find_service (or find_business) call, while reserving the category bag for the categorizations of the business service. Using a category bag on the binding templatewould precludesuch a search.
2.3.2Connection via a keyed reference versus access point
It might seem obvious to use the access point on the binding template as the place to store the connection to the minter’s binding template, but this has problems.
[jag[ the following few paragraphs need to be cleaned up – first, the accessPoint is not used to point to the WSDL – the portType’s tModel OverviewDoc/OverviewURL is used for this purpose.
Second, we need to make a stronger recommendation about how to alter the bindingTemplate’s accessPoint – which normally points to the service endpoint. This TN must recommend how to change the UDDI data to support WSA. The question is – what do we change the bT’s access point to? I suggest that we do in fact change this to contain the minter’s binding key, with a useType of either “bindingTemplate”, or a new “wsa-minter” value. (I am open to either – we should have the authors of the UDDI spec weigh in on this)
Most importantly, the useType of the access point has a limited set of standard values, none of which are appropriate to this use. It can be argued that “bindingTemplate” might be used, given that we are pointing off to another binding template, but this is a distortion of the intent of that value. We could solve the problem by adding a new useType value to cover this case, perhaps a value like “wsa-minter”, and define the semantics of this new value.
However, we are likely to want to associate WSDL with the binding template for the web service, and the standard means of doing so is to use the accessPoint URI to point to the WSDL, with a useType of wsdlDeployment.
So it seems appropriate to reserve the access point for this purpose, and to use a separate mechanism to locate the minter web service. Hence we have the recommendation of a keyed reference in the binding template’s category bag.
2.3.3The web service points to its minter, not vice versa
It might, at first, seem appropriate to have the minter web service’s binding template referencing the target web service, because that would allow a third party to provide a minting service to enable WS-A access to an existing web service. Although that might seem desirable, it has two severe problems.
[jag] I disagree with the argument that this is a security issue. The ability of someone to publish a bogus minter Service into UDDI is no worse that the ability of someone to publish a bogus “clone” of the real service, and point it to the malicious minter
I think the real issue is that of data integrity – it just makes sense that the owner of the service should be responsible for pointing to the official minter for that service.
First, there’s a security issue. If a third party were to provide a minter for a web service, they could take the opportunity to redirect the request to a different web service; this is because the only URL for the target web service that the caller will see is the one contained in the EPR as the wsa:to address. At the very least, the third party would have the opportunity to perform traffic analysis, and to see how often the web service is being called (every new interaction with the web service must be preceded by a request to the minter).
Second, a minter is only useful for a web service which can interpret WS-Addressing headers (most obviously wsa:replyTo and wsa:faultTo) – there is no way to add WS-A sugar to a non-WS-A web service.
Furthermore, we may have a minter web service which provides minting for multiple web services (it would take as a parameter an indication of the web service for which to mint an EPR). It is simpler (and easier to maintain) to have each web service which uses the minter point to it than to have the minter point to multiple web services. Any new web service can be published complete with a pointer to the minter, rather than publishing the web service, then updating the minter to point to it.
For these reasons, it is the web service that points to its minter, and not the other way around. The publisher of the web service binding template is the publisher who controls the minter to be used to access the web service.
2.4tModel TModel definitions
The following tModels are required to support the solution outlined in this Technical Note.
2.4.1The WS-Addressing EPR Minter ReferencetModel TModel
This tModel is used for keyed references that point to the minter of EPRs to access a particular web service.
2.4.1.1tModel definition
Name
uddi-org:wsaMinterReference
Description
tModel used to connect the binding template for a WS-Addressing-aware web service to the binding template for the EPR minter for that web service.
UDDI Key (V3)
uddi:uddi.org:wsa:minterreference
Derived V1, V2 format key:
TBD
Categorization
See below
Checked
No
2.4.1.1.1tModel Structure
<tModel tModelKey=”uddi:uddi.org:wsa:minterreference”>
<name>uddi-org:wsaMinterReference</name>