Architecture Web Service: Description and Registration, Publishing Web Services
content:
SOAP Message Example XML Schema Modeling WSDL Service Description UDDI Service Release Summary Reference Author
related information:
Interactive interface, Web service definition core actual Web service-based application, solution and development platform What is a web service? Why do I need a web service? WSDL: Describe your Web service UDDI registration information data model
Chainivel@uddi-china.org, Chief System Architect, September 20, 2001 (this article was originally published by IBM DeveloperWorks China website, its URL is http://www.ibm.com/developerWorks/cn/)
This article is the sixth article of architecture web services, and the last article, the text is based on the application instance of the previous article, and the entire process of the release web service interface is investigated: XML Schema modeling, WSDL release And UDDI registration. Through this article, everyone can understand the approach of each XML and Web Service's series of series of XML and Web Service in the WEB Service's release, and there will be a in-depth understanding of Web Service technology.
In the forebel, I have already introduced that the web service is called by the SOAP message, and the interface is described by WSDL, as well as public registration through UDDI. In the previous article, I have already introduced the message definition of the SOAP API. So in this article, I will submit save_category to see how this message is performed using W3C XML Schema. Modeling, if you use WSDL to specify and deliver the calling of the message-called Web service, and how to put this web service along with its WSDL specification description file to the UDDI registry. I hope that everyone can explain the instance of this article, in this series, the final understanding of the working principle and related technical specifications of the Web service. The resources cited herein mainly include two categories, one is the technical resource website of web services, including the technical information of a large number of web services, and the other is the "Stack" technical specification of the web service, they are a whole technical system. Including UDDI, SOAP, WSDL, XML Schema, XML, etc. The links of these resources are given in this article, and interested readers can find the desired content through these resource links. SOAP Message Example The following is an example of a Save_category, in the example, using SOAP HTTP Binding (version of the SOAP specification for use is 1.2), assume that the target web service is deployed at www.sagitta.com, while the entry of the called web service The location will be http://www.sagitta.com/catalog/. In this message, a new Category and a new product will be added to an existing category.
Post / Catalog HTTP / 1.1
Content-type: text / xml; charSet = "UTF-8"
Content-Length: nnnn
SOAPACTION: "http://www.sagitta.com/catalog/"
Host: www.sagitta.com
XML Version = "1.0" encoding = "UTF-8"?>
category>
compliantspecbag>
featurebag>
......
parameterbag>
product>
category>
save_category>
eNV: body>
eNV: envelope>
The return message of the call message may be:
HTTP / 1.1 200 ok
Content-type: text / xml; charSet = "UTF-8"
Content-Length: nnnn
XML Version = "1.0" encoding = "UTF-8"?>
category>
categorylist>
eNV: body>
eNV: envelope>
From this we can see two elements of Save_category and CategoryList "http://www.sagitta.com/schema/" http://www.sagitta.com/schema/ ". This URI uniquely represents the element of the element and its child elements. At the same time, the SCHEMA definition of these elements can be obtained through this URL. The mode defined in the Technical Series of the XML document using W3C XML Schema is in a support tool. W3C XML Schema is a modeling tool for any type of XML document. In the Web Services, the XML Schema is indispensable for important tools and underlying supports whether the SOAP message is indicated or in the interface description of WSDL. Below I will start from XML Schema, which describes how to use XML Schema modeling for our XML messages, how to use WSDL to interface with WSDL, and then use WSDL to interface the SAVE_CATEGORY. Published to the UDDI registry. XML Schema Modeling XML Schema's file suffix is a .xsd file, definition in an XML Schema is usually divided into two parts, type (TYPE) definitions and elements definitions. Below we combine Save_category specific XML Schema definition to explain how to use XML Schema to implement mode definitions. In the XML Schema document below, the type definition includes: CompliantSpecbag, FeatureBag, Parameter, Parameterbag, Product, and Category six types, and the element is defined as a Save_category element. Save_category's XML Schema Description Definition: (Complete XML Schema Document is: Sagitta.xSD)
XML Version = "1.0" encoding = "UTF-8"?>
The above is the file header of XML Schema.
xs: extension>
xs: simplecontent>
xs: complexType>
xs: element>
xs: sequence>
xs: complexType>
In this schema description, the element type of CompliantSpecbag is described. Any element that can be included using a CompliantSpecbag type element is specification. This element can have 0 to endless (unlimited, in fact impossible to have infinite times), Spectation This element contains an attribute specificationKey, which is required, and the type is a string (XS: String). XS This namespace is the namespace of W3C XML Schema 2001 (Namespace).
xs: sequence>
xs: complexType>
Here, describing the element type of Featurebag, any sub-element that uses the Featurebag type, which can contain Feature, and the Feature element can appear 0 times to infinity (unlimited, in fact impossible to occur infinite times). The type of content of this element is a string (XS: String).
xs: sequence>
xs: complexType>
xs: sequence>
xs: complexType>
Here, the element type of Parameter is first described. Any child elements that use Parameter types can include two keyName and KeyValue, which are both child elements that must appear while only once. Their type is also a string (XS: String). Then describe the parameterbag element type, any document element using the parameterbag type, the child element that can be included is parameter, and the type of this child element is the previously defined parameter (in XML Schema, the type name and element name, the type name and element name is orthogonal) No need to consider any name repetition questions), the number of parameter elements can be from 0 to endless times.
xs: sequence>
xs: complexType>
Here, the product of the product is described here, and any sub-elements that can be included using the Product Types are Name, Description, CompliantSpecbag, Featurebag, Parameterbag. The type of Name and Description elements is XS: String. CompliantSpecbag, Featurebag, Parameterbag's type You can clearly discover these type definitions that reference the previously defined by viewing this break XML Schema definition. Any document element using the Product Type There are two attributes of the properties that appear ProductKey and ParentCateGoryKey, which is the attribute value of the two string (Xs: String) type, which represents the key value of its own element and the key value of the parent Category.
xs: sequence>
xs: complexType>
This is a description of the Category element type, any sub-elements that can be included using the product type document element is Name, Description, Category, and Product. The type of Name and Description elements is simple type XS: String. Category is a recursive element that references its own element type. The element type of Products is the previously described Product type. Any document element using the Product Type There are two attributes that you must appear CategoryKeyKey, which is the attribute value of the two string (XS: String) types, indicating the key value of your own element and the key value of the parent Category.
xs: sequence>
xs: complexType>
xs: element>
This is the only element definition in this Schema document, and the element Save_category is a composite type, and its elements can have Authhinfo and Category. Austhinfo is a base64 encoded string, and Category is a child element that can appear 0 to unlimited type Category. We are not difficult to find the basic mechanism of elemental definitions and type definitions. I hope to help understand the understanding of Schema.
xs: complexType>
Then use the first method, without using the second method, the reason is also very simple, because the entire web service related message SCHEMA, such as Category, Product, Featurebag, CompliantSpecbag, Parameterbag these elements may be reused Therefore, it is defined to be a class relatively appropriate, while save_category is a single message, it is impossible to be multiplexed by other elements, so it is directly defined as an element.
xs: schema>
Finally, I give the schema illustration of the schema definition of the SAVE_CATEGORY element described in this section to end the section. Figure 1. SOAP API Schema Diagram WSDL Service Description After completing the SCHEMA modeling for the SOAP API message, this data model can be used by SOAP Interface. This data model can be used in addition to incoming parameters when specific calls occur. Generate the outgoing parameters. At the same time, using this data model, we can generate the corresponding WSDL description to publish this web service interface document to the user, which is the ability to automatically process the program. The following is a detailed definition of the WSDL document: (Complete WSDL document is: Sagitta.wsdl)
XML Version = "1.0"?>
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/"> This is the file header of the WSDL file, where the import element is indicated in this WSDL file, and the Types system is specifically described by http://www.sagitta.com/schema/save_category.xsd file, which is just imported here. message> message> Here, two messages are defined: Save_category messages, the structure definition of the root element has been created in the previous Schema modeling. Where MyXS is named here, and the specific definition of the namespace appears on the file header. CategoryList will correspond to the return message of the Save_category message, there is no performance in Schema modeling, here I also list one element name, I believe that everyone will read the first half of this article and the previous article of this series, will Clearly how to define. Operation> porttype> This part defines the type of call mode of the service access point, indicating that the entry type is the request / response mode, the request message is Save_category, and the response message is categoryList. EncodingStyle = "http://www.w3.org/2001/06/soap-encoding" /> input> EncodingStyle = "http://www.w3.org/2001/06/soap-encoding" /> OUTPUT> soap: Operation> Operation> soap: binding> binding> This part describes the abstraction definition of the service access point with the SOAP HTTP, describes how to access the access entry deployed by the SOAP / HTTP to access the entry point type of the previously described. The SOAPACTION that should be used in the specific SOAP call is "http://www.sagitta.com/catalog/", and the encoding style of the request / response message should use the SOAP specification default defined encoding style "http: //www.w3.org/2001/06/soap-encoding ". port> service> definitions> This part is the definition of a specific web service. In this web service called CatalogService, it provides a service access entry (there is still a lot, but here is here because of the reason, only one), the access address is " http://www.sagitta.com/catalog/ ", the message mode used is defined by the previous binding. UDDI Service is released in the previous section, we have been structured by using the Catalog Service this Web service by using the WSDL tool. In order to enable more potential users to find this web service, we also need to use UDDI SDK to register this web service to the UDDI registry using UDDI SDK in order to strengthen the interoperability of this web service and disaster recovery. Suppose we have already registered a businessentity, called www.sagitta.com, an online service provider, this businessentity key value is "434554f4-6e17-1342-ea41-36e642531da1", then we have to register a businessservice under this BusinessSentity Used to describe the previous Catalog Service. At the same time, the assumption that we need to be established is to register a service type (TMODEL), which describes the call specification of our web services that we need to publish. The specific content is the WSDL document I defined in front, in UDDI, register It is a description link. The SOAP message registered by BusinessService is as follows, where Microsoft's Test.uddi.microsoft.com site, so AUTHINFO can be filled in the test UDDitest. XML Version = "1.0" encoding = "UTF-8"?> overviewdoc> instancedetails> TMODELINSTANCEINFO> TMODELINSTANCEDETAILS> bindingTemplate> BindingTemplates> businessservice> sa_service> Body> Envelope> Through the above API call, we have already registered this service into the UDDI registry, where bindingTemplate's AccessPoint is the entry of the service, while OverViewURL in OverViewDoc is the access location of the WSDL document. Potential users can find this web service by querying the UDDI Registry, find the description of the service through the URL saved in OverViewURL, and then access this service through the access address specified by AccessPoint. When an emergency service crashes, the web service may be migrated to another host, IP address, even accessed URLs may have changed, and the original integrated connection will no longer work. However, due to the presence of UDDI registration, we can solve this problem by automated program means, making similar services to service disaster recovery very quickly. The specific process is generally: When the recovered service is started, automatically update the data on the UDDI registry, modify the access portal to the new URL position; when the client system is found, when it is discovered that the final service is found, it will Regularly query the UDDI registry to see if the new BindingTemplate data and the local cache are different. If there is, download it to the local, re-establish the service binding, complete the migration of the service connection. Summarizing this article, how to architecture web service will tell a paragraph, in the entire series, from why there is a web service start, what is a web service, a development tool for web services, a concept for web services A comprehensive introduction. Then describe the construction mode of the web service and the specific applications of the various web service "stack" technology in a specific example. I hope this series has a comprehensive help to understand and accept the next generation of application packaging mode web services. Reference Web Service Technology / Commentary UDDI-CHINA.ORG, with UDDI-based Web service technology website. WebServices.org, comprehensive technology website for Web services. IBM DeveloperWorks / Web Service Zone, IBM Web Services Technology Resource Center MSDN Online Web Services Developer Resources, Microsoft Web Services Developer Resources Website ITPAPERS / Web Service, ITPAPERS Web Services Comments Ability to resolve B2B e-commerce application interaction and integration Interop Stack Series Technology Standard Specification UDDI performs 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, 25 Sep 2000 SOAP: Simple Object Access Protocol Specification 1.1, IBM, Microsoft, DevelopMentor, 2000 XML Schema Part 0: Primer, W3C, 2 May 2001 Extensible Markup Language (XML) 1.0 (Second Edition), W3C, 6 OCT 2000 Architecture Web Services Series