[
Lists Home |
Date Index |
Thread Index
]
At 09:43 AM 2004-08-31, Chiusano Joseph wrote:
> or a dynamic retrieval of
those choices from a
> UDDI repository (basically a standards-based way) would be a good
idea.
Yes, one can use UDDI to dynamically retrieve a WSDL document of
course.
So if this means retreiving a WSDL document that contains multiple
soap:address values, then that is on target.
If all you need at runtime from a WSDL file is the soap:address, you can
put the URL in the UDDI bindingTemplate/accessPoint, and not bother with
the WSDL.
A bindingTemplate allows only one accessPoint, so for load balancing you
would want multiple bindingTemplates.
There are options about how these bindingTemplates are organized in a
UDDI registry.
- The bindingTemplates could be all within the same
businessService (same businessEntity),
- in different businessService entries (same
businessEntity), or
- spread across different businessEntities (e.g.,
UBR).
This last option is an interesting case, and probably not amenable to a
single WSDL with multiple soap:address.
The UDDI Business Registry (UBR) has multiple "operators" (IBM,
Microsoft, SAP) that provide the UDDI SOAP interface to the same
(virtual) data. A query to one should return the same results as
the same query to the others (more or less, depending on latency for
replication among the operators). We can look at UBR's SOAP
interfaces as an example that may be representative of any web
service. Each operator has its own businessEntity [1][2][3].
Each provides the SOAP Inquiry interface, which has a tModel [4] for the
generic WSDL document (without soap:address). This tModel's
tModelKey appears in the "fingerprint" [5].
If you search UBR for businesses whose "fingerprint" includes
[4], (and you drill down on the resulting set of businesses to the
associated bindingTemplate), you will find all bindings that implement
the UDDI SOAP inquiry interface. I found 5 such businessEntities in
the UBR: 3 for UBR itself[1][2][3], one for Systinet [6], and one that
looks bogus. Now you can't tell that some of these refer to UBR,
and others do not, but that is another issue.
So, given that the UDDI inquiry returns multiple results, the client
would need to decide somehow which one to use. You may be able to
refine the query so that UDDI would return a single binding, or perhaps a
smaller set that you know are all equal in terms of the underlying data
(e.g., the 3 UBR entries [1][2][3]). At design time you want to
think about what UDDI fingerprint should be used for runtime inquiry
(late binding), and design appropriate selection processing into the
consumer/client.
If your query was able to narrow down the results to the three UBR
entries, then the consumer can try one, and if unsuccessful, can try
another (i.e., failover).
The UBR operators have no way of load balancing across the three
operators. Any one operator may do load balancing transparently
(e.g., DNS returning a different IP address, or other load balancing
approaches).
Whether your consumer is designed to look for multiple soap:address
entries in a WSDL, or looks in UDDI as described above, are design time
issues. I refer to this as "Binding Patterns". One
binding pattern would be to look for multiple soap:addresses in a single
WSDL. Another binding pattern might involve UDDI. Other
binding patterns can be used, such as, looking for an inspection.wsil, or
other techniques. This is analogous to the various ways that an
application can be provided with bootstrap info; e.g., look in the
Windows Registry, environment variable, command line parameter, Java
.properties file, or hard-coded default. A web service consumer
application may implement several binding patterns, with a certain
precedence (e.g., command line parameter overrides UDDI
lookup).
I recommend that a URI be used to identify each binding pattern.
Perhaps a tModel in UBR can be published for each binding pattern.
UBR would assign a tModelKey, and a URL can be constructed using it
(e.g., [4]). The overviewURL in the tModel would point to a
document that describes the binding pattern. To facilitate
searching for "registered" binding patterns, the tModel used to
register the pattern would include a categoryBag with an appropriate
taxonomy [7], for example,
<categoryBag>
<keyedReference
tModelKey=" UUID:1691F1E0-9926-11D8-A122-000629DC0A53"
keyName="" keyValue="bindingPattern" />
</categoryBag>
[1]
http://uddi.ibm.com/ubr/uddiget?businessKey=1B51FFEA-9101-43D0-BAB9-4C5791E102B1
[2]
http://uddi.microsoft.com/discovery?businessKey=6c068bd0-21f8-40f0-9742-94e60e68d690
[3]
http://uddi.sap.com/UDDI/discovery/businessEntity/02fb553a-5be9-47b7-a0d8-dc94a1709703
[4]
http://uddi.ibm.com/ubr/uddiget?tModelKey=UUID:AC104DCC-D623-452F-88A7-F8ACD94D9B2B
[5]
http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.htm#_ftn9
(footnote [9])
[6] http://uddi.sap.com/UDDI/discovery/businessEntity/1b593cb2-cbaf-1023-866c-0050da428585
[7] http://uddi.sap.com/UDDI/discovery/tModel/UUID:1691F1E0-9926-11D8-A122-000629DC0A53
Paul
|
