(This article is the reduction version of BindingTemplate and Web service calls in the developerWorks column. You need to browse the original text, please visit http://www.ibm.com/developerworks/cn/)
Call mode based on bindingTemplate
When we need to prepare an application: This application needs to use a remote web service that has been registered by other commercial entities in the UDDI registration center, then you need to find the invoke specification information required to call the designated service from the registration center. And use when programmed. This type of service call for cross-commercial entities will be traditionally be regarded as a task in the development phase. Despite this development model, it does not change due to the appearance of UDDI registration information, but at least, if the special call mode supported by UDDI registration is used, a very significant and important issue can be solved.
The data in the BindingTemplate information set from the UDDI Registration Center represents a call specification instance of a specified remote web service. The program should cache this information and use this call specification to access this web service through the address registered by the Web service. Tools that use previously popular remote procedures Calling technologies have been able to automate such a job, whether by cache their call location or by writing a fixed code, it can be done. However, when the remote service has been migrated without notify the caller, it will cause problems that cannot automatically update access code or access addresses. Such migrations can be made by various reasons, including server upgrades, disaster recovery, and change in service portals or corporate names.
When the information obtained from the UDDI registry is cached, the correct approach is to query the UDDI registry that is currently gaining the data and obtains the updated BindingTemplate information corresponding to it. The correct call is to use GET_BINDINGDETAILS and passed into the original BindingKey key value. If the returned data is different from the cache, new call information should be used to re-try the service call. If this heavy trial operation succeeds, the new information should replace the original cached information into the current cache.
In the use of Web services, use such call modes, using UDDI Operating Inlet Site (Operator Site) can automatically complete service recovery with mass partners without aggravating communication with coordination overhead. For example, if a business activates a disaster recovery site to replace a collapsed original service providing site, most of the partners will have failed when they want to access the already crash service providing site. By updating the address of the new provider to UDDI information, those who use calling modes will automatically obtain new service call information and restore system connections without administrator intervention.
The detailed programming of this process is as follows:
1. Service providers register the web service S in the UDDI registry using Save_xx;
2. The caller uses the FIND_XX query the UDDI registry to obtain the summary information of the required service S;
3. The caller uses GET_XX again to query the UDDI registry to obtain the details of the required service S;
4. The caller cache service S's bindingTemplate information, through service binding, implement the call to the service S;
5. Service S has problems in some reason and cannot continue to provide services;
6. The service provider redescent service S in the new location, and updated the technical description of the UDDI registry for Web service S;
7. The caller uses the bindingTemplate information of the cached service S again to call, the call failed; (the deployment position of the service S has changed)
8. The caller uses the cache's BindingTemplate's BindingKey key value query the UDDI registry to obtain the updated BindingTemplate information after the service S. 9. The new BindingTemplate information of the caller cache service S is re-implemented by the service binding to re-implement calls to the service S.
Service redirection
In many cases, the API defined in the GET_BINDINGDETAIL message is direct. When a business or application knows the service that needs to be called, the service-related BindingTemplate information can be cached for use. If the cache information does fail while really need to be called (such as the AccessPoint information of the cached BindingTemplate structure is used to call a remote partner provided by a remote partner), the app can be obtained by bindingKey in the cached information. A new copy of a bindingTemplate message. This cache operation avoids extra access to the registry.
Need special circumstances for HostingRedirector
The special needs that cannot be directly supported by AccessPoint information in bindingTemplate is:
§ Web services provide hostage by third parties: a business can choose to release a service, which is logically belonging to the company, but in fact, the service is running on remote or third-party hosts. (Such as an enterprise application of ASP mode). The application service provider and network trading market operator is a typical representative of this situation. In this case, it is actually the value of the running timeline of the binding information BindingTemplate actually controls the binding information bindingTemplate as a third-party application service provider and network trading market operator.
§ Access control of the binding position specified by the user: In other cases,, for example, the redirection associated with the call context is based on the caller's user ID (such as a user who has some permissions is redirected into one management entry, Other users are redirected into a normal entry), or even a daily route, at this time, the way to more dynamically contact the actual contact information of the remote service is very essential, compared to the cache AccessPoint data to support call. It is more necessary.
For these reasons, the BindingTemplate structure includes another data element, called HostingRedirector. The presence of the HostingRedirector element indicates that the caller must use an additional step to get AccessPoint information (ie, call addresses) if you need to call the Web service indicated by the specified BindingTemplate. When parsing an HostingRedirector reference, two steps are required.