OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Fault-tolerance in web services

[ 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,

keyName="" keyValue="bindingPattern" />

[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



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS