How to architect a Web service-wsdl service description

web| Architecture

Finally, I end this section by giving a schema diagram that corresponds to the schema definition of the save_category element described in this section.

Figure 1. SOAP API schema diagram



WSDL Service Description

After the SOAP API message completes schema modeling, on the one hand the data model can be used by SOAP interface, which can be used to save incoming parameters and generate outgoing parameters when specific calls occur. At the same time, using this data model, we can generate the corresponding WSDL description, so that the interface document of the Web service is published to the user, the interface document has the ability to be automatically processed by the program.

The following is a detailed definition of the WSDL document: (The complete WSDL document is: SAGITTA.WSDL)


<?xml version= "1.0"?>
<definitions name= "CatalogService"
Targetnamespace= "HTTP://WWW.SAGITTA.COM/WSDL/SAVECATEGORY.WSDL"
Xmlns:tns= "HTTP://WWW.SAGITTA.COM/WSDL/SAVECATEGORY.WSDL"
Xmlns:myxs= "http://www.sagitta.com/schema/"
xmlns:soap= "Http://www.w3.org/2001/06/soap-envelope"
xmlns= "http://schemas.xmlsoap.org/wsdl/" >

<import namespace= "http://www.sagitta.com/schema/" location= "http://www.sagitta.com/schema/save_category.xsd" />




This is the file header of the WSDL file, where the import element indicates that in this WSDL file, the types system is specifically described by the http://www.sagitta.com/schema/save_category.xsd file, where it is simply imported.


<message name= "Save_category" >
<part name= "Body" element= "myxs:save_category"/>
</message>

<message name= "CategoryList" >
<part name= "Body" element= "myxs:categorylist"/>
</message>




Two messages are defined here: the save_category message, which has completely created the structure definition of the root element in the previous schema modeling. Where Myxs is the namespace (namespace) used here, the specific definition of the namespace appears on the file header. The categorylist will correspond to the return message of the save_category message, not shown in schema modeling, where I'll just list an element name, and I'm sure you'll know how to define it after reading the first half of this article and the previous article in this series.


<porttype name= "Save_category_porttype" >
<operation name= "Save_category_operation" >
<input message= "Tns:save_category"/>
<output message= "Tns:categorylist"/>
</operation>
</portType>




This section defines the type of invocation pattern for the service access point, indicating that the entry type is a request/response pattern, the request message is save_category, and the response message is categorylist.


<binding name= "save_category_soapbinding" type= "Save_category_porttype" >
<soap:binding style= "Document" transport= "Http://www.w3.org/2001/06/soap-envelope/http" >
<operation name= "Save_category_operation" >
<soap:operation soapaction= "http://www.sagitta.com/catalog/" >
<input>
<soap:body use= "literal" namespace= "http://www.sagitta.com/schema/"
encodingstyle= "Http://www.w3.org/2001/06/soap-encoding"/>
</input>
<output>
<soap:body use= "literal" namespace= "http://www.sagitta.com/schema/"
encodingstyle= "Http://www.w3.org/2001/06/soap-encoding"/>
</output>
</soap:operation>
</operation>
</soap:binding>
</binding>




This section describes the abstract definition of the service access point with the soap HTTP binding, describing how access is deployed through the access entry point type described previously in the soap/http. It specifies that the soapaction that should be used when specific soap calls are "http://www.sagitta.com/catalog/", and that the encoding style of the request/Response message should be in the code style defined by the SOAP specification "http:// Www.w3.org/2001/06/soap-encoding ".


<service name= "CatalogService" >
<documentation>online Web Service for catalog</documentation>
<port name= "Save_category_port" binding= "tns:save_category_soapbinding" >
<soap:address location= "http://www.sagitta.com/catalog/"/>
</port>
</service>

</definitions>




This section is the definition of a specific Web service, in this Web service called CatalogService, which provides a service access portal (there is a lot more, but here for the reason of the demo, only one is introduced), the access address is "http:// www.sagitta.com/catalog/", the message mode used is defined by the preceding binding.

UDDI Services Publishing

In the previous section, we have described the catalog service as a structured description of the Web services by using the WSDL tool. To enable more potential users to discover this Web service, and to enhance the interoperability of this Web service and the ability to maintain connectivity during disaster recovery, we need to use the UDDI SDK to register this Web service with the UDDI registry.

Suppose we have previously registered a businessentity, called Www.sagitta.com, an online service provider, the BusinessEntity key value is " 434554f4-6e17-1342-ea41-36e642531da1 ", then we are going to register a businessservice under this businessentity to describe the previous catalog Service. The assumption that we also need to set up is that we have registered a service Type (TModel), which describes the invocation specification of a Web service that we need to publish, specifically the WSDL document I defined earlier, in UDDI, where the description link is registered.

Businessservice a registered SOAP message, which uses Microsoft's test.uddi.microsoft.com site, authinfo can be filled in for test udditest.


<?xml version= "1.0" encoding= "UTF-8"?>
<envelope xmlns= "http://schemas.xmlsoap.org/soap/envelope/" >
<Body>
<save_service generic= "1.0" xmlns= "Urn:uddi-org:api" >
<authInfo>udditest</authInfo>
<businessservice businesskey= "434554f4-6e17-1342-ea41-36e642531da1" servicekey= "" >
<name>categoryService</name>
<description xml:lang= "en" >online Web Service for catalog</description>
<bindingTemplates>
<bindingtemplate bindingkey= "servicekey=" ">
<description xml:lang= "en" >categoryservice ' s bindingtemplate3</description>
<accesspoint urltype= "http" >http://www.sagitta.com/catalog/</accessPoint>
<tModelInstanceDetails>
<tmodelinstanceinfo tmodelkey= "UUID:E31A569A-AEFF-4468-BA4D-2BF22FE4ACEF" >
<description xml:lang= "en" >sagitta Web Service Type description</description>
<instanceDetails>
<description xml:lang= "en" >sagitta Web Service Type description</description>
<overviewDoc>
<description xml:lang= "en" >sagitta Web Service overview</description>
<overviewURL>http://www.sagitta.com/wsdl/savecategory.wsdl</overviewURL>
</overviewDoc>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
</businessService>
</save_service>
</Body>
</Envelope>




Through the above API calls, we have registered this service in the UDDI registry, where the Bindingtemplate Accesspoint is the portal of the service, and Overviewurl in Overviewdoc is the access location for the WSDL document.

A potential user can find the Web service by querying the UDDI registry, find a description of the service through the URL saved in Overviewurl, and then access the service through the access address specified by Accesspoint.

When an emergency service crash occurs, the Web service may be migrated to another host, and the IP address, or even the URL to be accessed, can vary greatly, when the original integrated connection will no longer work. However, because of the existence of UDDI registration, we can solve this problem by automated procedures, so that similar service disaster recovery process is very rapid.

The specific process is generally:

When the restored service starts, it automatically updates the data on the UDDI registry and modifies the access gate to the new URL location;
The connected client system, when found unable to access the final service, will periodically query the UDDI registry to see if there is any difference between the new bindingtemplate data and the local cache, and if so, to download it locally, re-establish the service bindings, and complete the migration of the service connections.
Summarize

By the end of this article, how to architect the Web service series will come to a complete conceptual overview of Web services throughout the series, from why Web services start to what is Web services, Web services development tools. Then, a concrete example is introduced to introduce the construction mode of Web service and the application of "stack" technology of various web services. I hope this series has a comprehensive help to understand and accept the next generation of application packaging mode Web services.

Resources

Web Service Technology/Comment website
Uddi-china.org, a UDDI-oriented Web services technology Web site.
webservices.org, Web Services Integrated class technology Web site.
IBM Developerworks/web Service Zone, IBM's WEB Services technology Resource Center
MSDN Online Web Services Developer Resources, Web Service Developer Resource Web site for Microsoft
Itpapers/web service, Itpapers's WEB Services review article
Interop Stack Series technical standard specification for addressing business-to-business e-business application interactions and integrations
UDDI Executive White Paper, uddi-china.org, uddi.org
UDDI Technology white Paper, uddi-china.org, uddi.org
UDDI Programmer API Specification, uddi-china.org, uddi.org
UDDI data structure Reference, uddi-china.org, uddi.org
Web Service Description Language (WSDL) 1.0, IBM, SEP 2000
Soap:simple Object Access PROTOCOL Specification 1.1, IBM, Microsoft, DevelopMentor, 2000
XML Schema Part 0:primer, the Consortium, 2 May 2001
Extensible Markup Language (XML) 1.0 (Second Edition), the Consortium, 6 OCT 2000
Author Introduction

Chai Xiaolu: Shanghai Easy e-commerce Technology Co., Ltd. (dealeasy) chief System Architect, XML technical advisor. Member of Uddi-china.org Blue Blaze Studio. UDDI Advisor group member, Wsui Working group member. He received a master's degree in computer Science from Fudan University in 2000, and has been in the International Computer Science Conference (ICSC), Asia-Pacific XML Technology Symposium (XML asia/pacific ' 99), China XML Technology Symposium (Beijing), and computer scientific periodicals. Many papers have been published in major domestic conferences and periodicals. specialize in xml-based system integration and data exchange technology research, at the same time, database, object-oriented technology and CSCW technology is better.