Professional Documents
Culture Documents
Schema WSDL
Schema WSDL
Schema WSDL
• This
presentation identifies best practices in the use of
XML Schemas in a web services design
Learning objective
You will learn techniques to improve portability,
reusability, and interoperability in your web
services design
Agenda
• Steps:
– Separate complexType with name of PartListType
– Define an element of type PartListType with name PartList
QuoteRequest QuoteResponse
• Steps:
– Create a common type called, OwnerDetailsType
– CustomerDetails and SupplierDetails can reference this type
QuoteRequest QuoteResponse
• targetNamespace
– Specifies what namespace the types will be bound to
– Prefixes are used to reference these types in the message
Code example
<schema
targetNamespace=http://acme.com/supplier/RequestTypes
xmlns=http://www.w3.org/2001/XMLSchema
xmlns:supReq="http://acme.com/supplier/RequestTypes”>
…
<sequence>
<element name="CustomerDetails"
type="supReq:OwnerDetails"/>
<element name="PartList"
type="supReq:PartListType"/>
</sequence>
Versioning Web services
• Version control important in Web services design
– How do you maintain multiple version of the same service?
– How can clients control what version they are accessing?
–
to manage the version
Use namespaces to manage
versioning in XML schemas
client
? 1.2
1.3
Using namespaces to manage versioning
• Advantage of using namespaces:
– Each appears as a completely different namespace
– XML schema itself is enforcing the version control
<schema
targetNamespace=
"http://acme.com/supplier/requestTypes_v1" ...
<schema
targetNamespace=
"http://acme.com/supplier/versions/1.0/requestTypes"
Leveraging common types
• XML schemas don’t have to be defined in a single file
<schema targetNamespace=http://acme.com/supplier/types
xmlns:supReq=http://acme.com/supplier/types
xmlns:common="http://acme.com/supplier/quoteCommon”>
<import namespace=http://acme.com/supplier/QuoteCommon importing the
schemaLocation=”http://acme.com/supplier/commontypes.xsd”/> schema
<complexType name="QuoteRequestType">
<sequence>
<element type="common:DocumentInfoType” name=”DocumentInfo"/>
<element type="common:OwnerDetails” name=CustomerDetails"/>
<element type="common:PartListType" name=”PartList”/>
</sequence> referencing a
</complexType> common type
<element name="QuoteRequest“ type="supReq:QuoteRequestType">
</element>
</schema>
Agenda
<definitions
targetNameSpace=”http://acme.com/supplier/definitions”…>
<wsdl:import
namespace=”http://acme.com/supplier/types”
location=”http://acme.com/supplier/types.xsd”/>
And the correct way…
<definitions
targetNameSpace=”http://acme.com/supplier/definitions”…>
<types>
<xsd:schema
targetNamespace=”http://acme.com/supplier/types” …>
<xsd:import namespace=http://acme.com/supplier/types
schemaLocation=
”http://acme.com/supplier/types.xsd”/>
</xsd:schema>
</types>
Building modular WSDL
• Use import to separate WSDL into modular components:
<types>
<xsd:schema …>
<xsd:import …>
</xsd:schema>
</types>
<message name=”GetQuoteRequest”>
<part name=”QuoteRequest”
element=”types:QuoteRequest”/>
</message>
</definitions>
Referencing imported types
• Next important design question:
– How to properly reference schema types within the WSDL?
• In our example:
– Define a request for quote for a supplier
• QuoteRequest type in types.xsd file
– Import that file in the WSDL using xsd:import
– Reference the type within the <message><part> section
Managing namespaces with WSDL
Generally a good practice to specify a
different namespace for the imported schema types
• <import> requires that either the:
– Namespace of imported file is different
– Namespace of imported file is not specified (unqualified)
Altova XMLSPY
java.util.Date ??
xsd:datetime java.util.Calendar
java.util.Calendar
Mapping XML Schema structures
• Problems can occur in mapping certain XML Schema
constructs to a specific programming language:
– The <CHOICE> keyword is not supported in JAX-RPC
– No Java constructs to represent:
• Schema annotations
• Default values
• Optional attributes
• Key problem:
– Server-side bindings will not contain these constructs
– Constructs will also be lost in WSDL if platform dynamically
generates WSDL
• May need to force use of static WSDL file
Code example
Before:
<xs:element name="CustomerDetails">
<xs:annotation>
<xs:documentation>comments
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="CustId“
type="xs:integer“ After:
use="optional" default="9999"/>
<xs:element
</xs:complexType>
name="CustomerDetails">
</xs:element>
<xs:complexType>
<xs:attribute name="CustId”
type="xs:integer“>
</xs:complexType>
</xs:element>
Final thoughts around interoperability
• Make use of XML Schemas
– Clearly, there are pitfalls to avoid
– Much to be gained in reusability and portability
• Key objectives:
– Establish profiles showing how specifications work together
– Does not create standards, only guides their use
<schema targetNamespace=http://acme.com/supplier/quoteCommon
xmlns:qc=http://acme.com/supplier/quoteCommon
elementFormDefault="qualified“
attributeFormDefault="unqualified">