org.uddi.api_v3

Class AccessPoint

java.lang.Object

org.uddi.api_v3.AccessPoint

All Implemented Interfaces:

Serializable

public class AccessPoint
extends Object
implements Serializable

B Appendix B: Using and Extending the useType Attribute

UDDI provides type information through the useType attribute on the following UDDI elements: accessPoint, overviewURL, discoveryURL, contact, address, email and phone. The useType attribute is intended to provide information on how to use or invoke the resource contained within the element. This Appendix establishes and explains common values and conventions for the useType attribute in the context of certain elements, as well as a model for establishing new common values and conventions.

B.1 accessPoint

Four common values for providing type information about the accessPoint are: "endPoint", "wsdlDeployment", "bindingTemplate", and "hostingRedirector.

B.1.1 Using the "endPoint" value

Typically, the network address of a Web service described by a bindingTemplate is found in the accessPoint element. This common behavior is denoted by using the string "endpoint" as the value of the accessPoint. Decorating an accessPoint with a useType="endPoint" signifies that a user or application can invoke a Web service at that address. A sample of such behavior is as follows:

<bindingTemplate bindingKey="uddi:example.org:catalog">
<description xml:lang="en">
Browse catalog Web service
</description>
<accessPoint useType="endPoint">
http://www.example.org/CatalogWebService
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:example.org:catalog_interface"/>
<tModelInstanceInfo tModelKey="uddi:uddi.org:transport:http"/>
</tModelInstanceDetails>
</bindingTemplate>

In the example above, a client would be able to parse the bindingTemplate and discover the end point of the Web service itself. However, the information about how to invoke that Web service would be modeled using tModels. All interface information about that service would be represented by the tModelInstanceInfo structures contained as children of the bindingTemplate.

The client knows the transport of the accessPoint either by checking to see if a protocol tModel has been associated with the bindingTemplate or inspecting the URI prefix. In the example above, the http transport was used, denoted by the tModelInstanceInfo.

UDDI RECOMMENDS that endpoints for phone, fax and modem communication follow the guidelines outlined in RFC 2806 URLs for Telephone Calls[51]. Following such a convention for a phone number accessPoint would result in the following bindingTemplate sample:

<bindingTemplate bindingKey="uddi:example.org:catalog">
<description xml:lang="en">
Browse catalog Web service
</description>
<accessPoint useType="endPoint">
tel:+1-512-555-1212
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:uddi.org:transport:telephone"/>
</tModelInstanceDetails>
</bindingTemplate>

B.1.2 Using the "wsdlDeployment" value

Instead of directly providing the network address in the accessPoint, it is occasionally useful or necessary to provide this information through indirect means. One common scenario for such a behavior is when the accessPoint is embedded within a WSDL file. In such a scenario, the UDDI accessPoint contains the address of the WSDL file, and the client then must retrieve the WSDL file and extract the end point address from the WSDL file itself.

In this case, decorating the UDDI accessPoint with a useType="wsdlDeployment" is appropriate. A sample of such behavior is as follows:

<bindingTemplate bindingKey="uddi:example.org:catalog">
<description xml:lang="en">
Browse catalog Web service
</description>
<accessPoint useType="wsdlDeployment">
http://www.example.org/CatalogWebService/catalog.wsdl
</accessPoint>

<categoryBag>
<keyedReference keyName="uddi-org:types:wsdl"
keyValue="wsdlDeployment"
tModelKey="uddi:uddi.org:categorization:types"/>
</categoryBag>
</bindingTemplate>

In the example above, a client would be able to parse the result of the bindingTemplate and determine the end point of the Web service within the WSDL file discovered in the accessPoint element. Note that the bindingTemplate has also been categorized with the "wsdlDeployment" value from the uddi.org:categorization:types scheme so that it can be discovered through a find_binding API call.

B.1.3 Using the "bindingTemplate" value

Another form of indirection uses UDDI itself to discover the location of the final end point. Categorizing a bindingTemplate with either "bindingTemplate" or "hostingRedirector" specifies that the accessPoint contains a bindingKey intended to be used in a get_bindingDetail API call to a UDDI registry Inquiry API Set. How the resultant bindingTemplate is interpreted depends on which one of the two methods described below is used. In the case of "bindingTemplate", a bindingKey refers to another binding within the same UDDI registry.

For example, suppose tempuri.com, the well known but fictitious maker of crispy batter coating for fried foods, contracts with the equally fictitious Web service hosting company ws-o-rama.com to host tempuri’s Web service that exposes its product catalog. Tempuri.com wishes to publish a bindingTemplate for this service in the UDDI Business Registry, but wishes to leave the details of the technical implementation and its description up to ws-o-rama.com who may wish to change them over time. To do this, tempuri.com and ws-o-rama.com use bindingTemplate indirection. In the UDDI Business Registry the bindingTemplate in tempuri’s businessEntity that describes this service appears as follows:

<bindingTemplate bindingKey="uddi:tempuri.com:catalog">
<description xml:lang="en">
Browse catalog Web service
</description>
<accessPoint useType="bindingTemplate">
uddi:ws-o-rama.com:tempuri:bt1
</accessPoint>
</bindingTemplate>

Here, the bindingTemplate describing tempuri’s catalog browsing Web service uses an accessPoint to refer to the bindingTemplate (also in the UDDI Business Registry) whose bindingKey is uddi:ws-o-rama.com:tempura:bt1. When a client does a get_bindingDetail asking for the bindingTemplate with that key, the following bindingTemplate is returned:

<bindingTemplate bindingKey="uddi:ws-o-rama.com:tempuri:bt1">
<description xml:lang="en">
Tempuri.com’s catalog browsing service hosted by ws-o-rama
</description>
<accessPoint useType="endPoint">
http://sf1.ws-o-rama.com/tempuri/catalog/
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:..."/>
</tModelInstanceDetails>
</bindingTemplate>

This bindingTemplate describes the actual Web service that is to be used.

B.1.4 Using the "hostingRedirector" value

It may be necessary to "hide" the network address of a Web service from unauthorized access. In this case, a useType="hostingRedirector" can be used to indicate that the client must follow a longer path of indirection to retrieve the accessPoint. In the bindingTemplate, the client will discover a bindingKey, which will lead to a bindingTemplate that contains the end point for a Web service which supports the UDDI get_bindingDetail Web Service. The client will then be able to re-issue the get_bindingDetail message with the original key, presumably with authentication, to this other Web service. Such an indirection mechanism allows a Web service to be discoverable but not accessible from a given node.

For example, tempuri.com uses ws-o-rama.com to host more than just its publicly visible catalog browsing service. In particular it has a number of services it does not wish to expose fully in the UDDI Business Registry. Instead, it wishes to keep their full definition in its private UDDI registry, which ws-o-rama.com also happens to host, and supply the end points to these Web services only to authorized inquirers.

In particular, tempuri has a Web service that its suppliers use to bill it for goods they deliver. In the UDDI Business Registry, tempuri publishes the following bindingTemplate, which contains a bindingKey.

<bindingTemplate bindingKey="uddi:tempuri.com:billing">
<description xml:lang="en">
Tempuri supplier billing Web service
</description>
<accessPoint useType="hostingRedirector">
uddi:ws-o-rama.com:tempuri:bt47
</accessPoint>
</bindingTemplate>

Here, the bindingTemplate describing tempuri’s supplier billing Web service uses an accessPoint to refer to the bindingTemplate (also in the UDDI Business Registry) whose bindingKey is uddi:ws-o-rama.com: tempuri:bt47. Note that the useType equals "hostingRedirector" which indicates that the bindingKey refers to a hostingRedirector service. When a client does a get_bindingDetail (on the UDDI Business Registry) asking for the bindingTemplate with that key, the following indirect bindingTemplate is returned:

<bindingTemplate bindingKey="uddi:ws-o-rama.com:tempura:bt47">
<description xml:lang="en">
Hosting Redirector Service for Tempuri.com
hosted by ws-o-rama.com
</description>
<accessPoint useType="endPoint">
http://sf1.ws-o-rama.com/tempuri/uddi/inquiry
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey="uddi:uddi.org:specification:hostingredirector"/>
</tModelInstanceDetails>
</bindingTemplate>

This bindingTemplate describes the hosting redirector Web service hosted for tempuri.com by ws-o-rama.com. By definition, it responds to the get_bindingDetail API call using SOAP over HTTP. The description in the bindingTemplate says it responds only to authorized requests. For authorized clients, invoking get_bindingDetail, passing the key of the original bindingTemplate (uddi:tempuri.com:billing) retrieves the following bindingTemplate:

<bindingTemplate bindingKey="uddi:tempuri.com:billing">
<description xml:lang="en">
Tempuri.com’s supplier billing browsing service
hosted by ws-o-rama.com
</description>
<accessPoint useType="endPoint">
http:sf1.ws-o-rama.com/tempuri/billing/
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="uddi:..."/>
</tModelInstanceDetails>
</bindingTemplate>

This bindingTemplate describes the actual Web service that is to be used.

Java class for accessPoint complex type.

The following schema fragment specifies the expected content contained within this class.

 <complexType name="accessPoint">
   <simpleContent>
     <extension base="<urn:uddi-org:api_v3>validationTypeString4096">
       <attribute name="useType" type="{urn:uddi-org:api_v3}useType" default="" />
     </extension>
   </simpleContent>
 </complexType>
 

See Also:

Serialized Form

Field Summary

Fields

Modifier and Type	Field and Description
protected String	useType
protected String	value

Constructor Summary

Constructors

Constructor and Description
AccessPoint()
AccessPoint(String value, String useType) A convenience constructor

Method Summary

Modifier and Type	Method and Description
String	getUseType() Gets the value of the useType property.
String	getValue() Gets the value of the value property.
void	setUseType(String value) Sets the value of the useType property.
void	setValue(String value) Sets the value of the value property.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Detail

value

protected String value

useType

protected String useType

Constructor Detail

AccessPoint

public AccessPoint()

AccessPoint

public AccessPoint(String value,
                   String useType)

A convenience constructor

Parameters:

value -

useType -

See Also:

for help on useType

Method Detail

getValue

public String getValue()

Gets the value of the value property.

Returns:

possible object is String

setValue

public void setValue(String value)

Sets the value of the value property.

Parameters:

value - allowed object is String

See Also:

for spec defined values

getUseType

public String getUseType()

Gets the value of the useType property.

Returns:

possible object is String

See Also:

for spec defined values

setUseType

public void setUseType(String value)

Sets the value of the useType property.

Parameters:

value - allowed object is String