Web|web Service Architecture Web Service: Description and registration, publishing Web Services
Content:
SOAP Message Sample
XML Schema Modeling
WSDL Service Description
UDDI Services Publishing
Summarize
Resources
Author Introduction
Related content:
Interactive interface, the core of Web service definition
Real-combat Web services
Web services based applications, solutions, and development platforms
What is a Web service?
Why do I need a Web service?
WSDL: Describing your Web services
Data Model for UDDI registration information
Chai Xiaolu (fennivel@uddi-china.org)
Chief System Architect
September 20, 2001
This article is the sixth of the series of architecture Web services, and the last one, based on the previous text, the whole process of publishing Web service interface is studied: XML schema modeling, WSDL Publishing and UDDI registration. Through this article, you can have a detailed understanding of the various XML and Web service of the series of specifications in the release of Web service around, the Web service technology will also have a deep understanding.
As I've described earlier, Web services are invoked through a SOAP message, described through WSDL, and publicly registered through UDDI. In the previous article, I've covered how to define a message for the SOAP API, so in this article, I'll just put save_category forward and see how this message can be modeled using a world-view XML schema on a specific implementation, If you use WSDL to specification and deliver the caller the Web service based on the message invocation, and how to publish the Web service along with its WSDL normalization description file to the UDDI registry. I hope you can explain through the example of this article, in this series of the last complete understanding of the work of Web services and related technical specifications of the role.
The resources cited in this article mainly include two categories, one is the Web Services Technical Resources Web site, contains a large number of Web services technical information, the other is the Web services "stack" series of technical specifications, they are a whole technical system, including UDDI, SOAP, WSDL, XML Schema, XML, and so on. At the end of this article, the links to these resources are given, and interested readers can find what they need through these resource links.
SOAP Message Sample
The following is an example of a save_category invocation, in which the soap HTTP Binding is used (the version of the SOAP specification used is 1.2), Suppose the target Web service is deployed in www.sagitta.com, and the portal location of the invoked Web service will be http://www.sagitta.com/catalog/.
In this message, a new category and a new product are 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"?>
<env:envelope xmlns:env= "Http://www.w3.org/2001/06/soap-envelope" >
<env:Body>
<save_category xmlns= "http://www.sagitta.com/schema/" >
<authInfo>5Az784kJceHCE982eB</authInfo>
<category categorykey= "cb4e17d1-6100-47f6-a532-cd9cbd30c073" parentcategorykey= " ab4e3de1-7865-f2c1-b49a-beccbd21c072 ">
<name>consumer electronics</name>
<description>product Category for Consumer electronics </description>
<category categorykey= "" parentcategorykey= "cb4e17d1-6100-47f6-a532-cd9cbd30c073" >
<name>sony Consumer electronics</name>
<description>sony ' s Product Category for Consumer electronics</description>
</category>
<product productkey= "" parentcategorykey= "cb4e17d1-6100-47f6-a532-cd9cbd30c073" >
<NAME>DSC-S75 Digital camera</name>
<description>sony ' s brand-new Professional Digital camera</description>
<compliantSpecBag>
<specification specificationkey= "key[usb1.1]"/>
</compliantSpecBag>
<featureBag>
<feature>......</feature>
<feature>......</feature>
</featureBag>
<parameterBag>
......
</parameterBag>
</product>
</category>
</save_category>
</env:Body>
</env:Envelope>
The return message for this call message may be:
http/1.1 OK
Content-type:text/xml; charset= "Utf-8"
content-length:nnnn
<?xml version= "1.0" encoding= "UTF-8"?>
<env:envelope xmlns:env= "Http://www.w3.org/2001/06/soap-envelope" >
<env:Body>
<categorylist xmlns= "http://www.sagitta.com/schema/" >
<category categorykey= "cb4e17d1-6100-47f6-a532-cd9cbd30c073" parentcategorykey= " ab4e3de1-7865-f2c1-b49a-beccbd21c072 ">
<category categorykey= "8933AA50-3AAF-11D5-80DC-002035229C64" parentcategorykey= " cb4e17d1-6100-47f6-a532-cd9cbd30c073 "/>
<product productkey= "89307600-3AAF-11D5-80DC-002035229C64" parentcategorykey= " cb4e17d1-6100-47f6-a532-cd9cbd30c073 "/>
</category>
</categoryList>
</env:Body>
</env:Envelope>
From this we can see that there is an xmlns modifier "http://www.sagitta.com/schema/" behind the two elements of Save_category and categorylist. This URI uniquely represents the namespace of the element and all its child elements. The schema definition of these elements can also be obtained through this URL.
The schema definition of an XML document described using the World Wide Web XML Schema defines the status of a support tool in the technical family of the entire website service. The Consortium XML Schema is a modeling tool for any type of XML document. In the Web service architecture, XML schemas are essential tools and underlying support, both in the presentation of SOAP messages and in the description of the WSDL interface.
I'll start with an XML schema, save_category this message (as well as a service portal) to explain how to model XML schemas for our XML messages, and how to use WSDL to Save_ Category The service Portal to describe the interface, and then publish the portal to the UDDI registry.
XML Schema Modeling
The file suffix of an XML schema is an. xsd file, and a definition in an XML schema is usually divided into two parts, a type definition and an element definition. Here we combine save_category specific XML Schema definitions to illustrate how to use XML schemas to implement schema definitions.
In the following XML Schema document, the type definition includes: compliantspecbag,featurebag,parameter,parameterbag,product and category six types, and the element is defined as Save_ Category this element.
Save_category XML Schema Description definition: (complete XML Schema document is: sagitta.xsd)
<?xml version= "1.0" encoding= "UTF-8"?>
<xs:schema xmlns:xs= "Http://www.w3.org/2001/XMLSchema" elementformdefault= "qualified" Unqualified ">
These are the file headers of the XML schema.
<xs:complextype name= "Compliantspecbag" >
<xs:sequence>
<xs:element name= "Specification" minoccurs= "0" maxoccurs= "unbounded" >
<xs:complexType>
<xs:simpleContent>
<xs:extension base= "Xs:string" >
<xs:attribute name= "Specificationkey" type= "xs:string" use= "required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
In this schema description, the Compliantspecbag element type is described, and any element that uses the Compliantspecbag type can contain an element that is specification, which can occur 0 times to infinity (Unrestricted, In fact, it is not possible to have infinite occurrences), and specification This element contains a property specificationkey, which is required and is of type string (xs:string). The Xs namespace is the namespace (namespace) of the XML Schema 2001 of the Consortium.
<xs:complextype name= "Featurebag" >
<xs:sequence>
<xs:element name= "feature" type= "xs:string" minoccurs= "0" maxoccurs= "unbounded"/>
</xs:sequence>
</xs:complexType>
Here, the Featurebag element type is described, and any document element that uses the Featurebag type can contain a feature, and the feature element can appear 0 to infinity (unrestricted, virtually impossible to appear infinitely). The type of the element's content is a string (xs:string).
<xs:complextype name= "parameter" >
<xs:sequence>
<xs:element name= "KeyName" type= "xs:string"/>
<xs:element name= "KeyValue" type= "xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complextype name= "Parameterbag" >
<xs:sequence>
<xs:element name= "parameter" type= "parameter" minoccurs= "0" maxoccurs= "unbounded"/>
</xs:sequence>
</xs:complexType>
This first describes the element type of parameter, and any document element that uses the parameter type can contain two keyname and keyvalue, all of which are child elements that must appear, and can occur only once. Their type is also a string (xs:string). The Parameterbag element type is then described, and any document element that uses the Parameterbag type can contain a parameter, and the type of the child element is a previously defined parameter (in an XML schema, The domain space of the type name and element name is orthogonal and does not need to consider any name duplication problem, and the number of parameter elements can occur from 0 to infinity.
<xs:complextype name= "Product" >
<xs:sequence>
<xs:element name= "name" type= "xs:string"/>
<xs:element name= "description" type= "xs:string"/>
<xs:element name= "Compliantspecbag" type= "Compliantspecbag"/>
<xs:element name= "Featurebag" type= "Featurebag"/>
<xs:element name= "Parameterbag" type= "Parameterbag"/>
</xs:sequence>
<xs:attribute name= "ProductKey" type= "xs:string" use= "required"/><xs:attribute name= "ParentCategoryKey" Type= "xs:string" use= "required"/>
</xs:complexType>
This describes the element type of product, and any document element that uses the product type can contain child elements such as name, description, Compliantspecbag, Featurebag, Parameterbag. The types of name and description elements are all xs:string. And the types of Compliantspecbag, Featurebag, parameterbag. It is also clear from the view of this broken XML schema definition that reference is made to these type definitions as defined above. Any document element that uses the product type also has two properties ProductKey and Parentcategorykey that must appear, which is the property value of the two string (xs:string) type, representing the key value of its own element and the key value of the parent category.
<xs:complextype name= "category" >
<xs:sequence>
<xs:element name= "name" type= "xs:string"/>
<xs:element name= "description" type= "xs:string"/>
<xs:element name= "category" Type= "category" minoccurs= "0" maxoccurs= "unbounded"/>
<xs:element name= "Product" type= "product" minoccurs= "0" maxoccurs= "unbounded"/>
</xs:sequence>
<xs:attribute name= "Categorykey" type= "xs:string" use= "required"/>
<xs:attribute name= "Parentcategorykey" type= "xs:string" use= "required"/>
</xs:complexType>
This is a description of the category element type, and any document element that uses the product type can contain child elements that are name, description, category, and product. The types of the name and description elements are simple type xs:string. And category is a recursive element that references its own type of element. The element type of product is the product type described above. Any document element that uses the product type also has two properties Categorykey and Parentcategorykey that must appear, which is the property value of the two string (xs:string) type, representing the key value of its own element and the key value of the parent category.
<xs:element name= "Save_category" >
<xs:complexType>
<xs:sequence>
<xs:element name= "AuthInfo" type= "Xs:base64binary"/>
<xs:element name= "category" Type= "category" minoccurs= "0" maxoccurs= "unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
This is the only element defined in this schema document, the element save_category is a composite type, and its elements can have authinfo and category. Where Authinfo is a base64 encoded string, category is a child element of type category that can occur 0 to an infinite number of times. It is not difficult to find that the basic mechanism of element definition and type definition is the same, in fact, we can completely split this definition into two paragraphs, a section for the type definition, a paragraph for the element definition, the following given this equivalent example, hope to help the understanding of the schema.
<xs:complextype name= "Save_category" >
<xs:sequence>
<xs:element name= "AuthInfo" type= "Xs:base64binary"/>
<xs:element name= "category" Type= "category" minoccurs= "0" maxoccurs= "unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name= "Save_category" type= "Save_category"/>
So why take the first approach, not the second one, because it's simple because the entire Web service-related message schema, such as category, product, Featurebag, Compliantspecbag, Parameterbag These elements can be reused, so it is more appropriate to define a type, and Save_category is a single message that cannot be reused by other elements, so it is directly defined as an element.
</xs:schema>
