Bulk Operation
|
One-Way Operations that have the additional aspect of sending large datasets, as a sequence of chunks, where each transfer of a chunk corresponds to one operation execution.
See also “Taxonomy of Operations” at page 30.
|
Business Errors
System Errors
|
A Business Error is an error interpreted by the user (human or machine). The user may have the ablity to resolve this, e.g. by changing input data.
A System Error is interpreted by system operators and/or developers, and they take action to resolve it. A user is typically also informed in a general way, saying that ‘a general system error occurred – please contact your system administrator at phone...”.
|
Document Literal Wrapped
DLW
|
Convention on web services.
See http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/.
|
Flux
Message Flux
|
A Message Flux is a set of messages that is used together, in the sense that they are related to the same function.
Where each message is identified individually by a unique number (in ApplHeader.MessageID) a message may also belong to a flux instance. In the latter case each message of the flux has an additional unique id identifying that flux.
|
One-Way Operation
|
A caller sends a message to a callee, and does not wait for an answer.
See also “Taxonomy of Operations” at page 30.
|
Pseudo One-Way Operation
|
See Pseudo One-Way over HTTP - Idempotent Operations on page 31.
|
Request-Response Operation
|
The caller waits until it receives a response – it does not do anything else meanwhile. This is very similar to a function call in most programming languages.
See also “Taxonomy of Operations” at page 30.
|
Service Consumer
|
Software making use of a service, by sending a message to it and possibly waiting for an answer.
Possible aliases:
‘caller’, i.e. ‘caller of a service’.
‘client’ as the client-side of a client-server relationship.
‘sender’ or ‘initiator’, as they send a message and/or initiate sending a request message and wait for the reply.
|
Service Provider
|
Software providing and implementing a service.
Possible aliases:
‘callee’, the opposite of ‘caller’.
‘server’ as the server-side of a client-server relationship.
‘receiver’ as they listen for incoming messages, doing some business functionality (and optionally send back another message)
|
SOAP
|
Base protocol of web services. SOAP defines the structure of the XML messages and how they are exchanged.
See http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/.
|
Web Service
|
Interaction and data exchange between two parties, based on SOAP and optionally other protocols such as WSDL, WS-Security and the like.
Often narrowed down to SOAP over http.
See also http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#webservice.
|
WSDL
WSDL file
|
WSDL = Web Service Description Language
XML file that describes actual Web Service operations and message exchanges, as well as the protocols used and the actual address of the service or ‘endpoint’.
See http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/
|
Guidelines
Note: the terms “MUST”, “MUST NOT”, “SHOULD”, “SHOULD NOT”, “MAY”, “REQUIRED”, “OPTIONAL” - when they appear in all-capitals - must be understood as in http://www.faqs.org/rfcs/rfc2119.html.
General Standards Guideline
Following standards MUST be used:
XML 1.0 - http://www.w3.org/TR/2000/REC-xml-20001006
UTF-8 encoding
Namespaces in XML 1.0 - http://www.w3.org/TR/2006/REC-xml-names-20060816/
XML Schema 1.0 - http://www.w3.org/2001/XMLSchema
SOAP 1.1 - http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
WSDL 1.1 - http://www.w3.org/TR/wsdl
In addition to this, conformance with WS-I Basic Profile is the overall goal for the B2B guidelines and the implementation.
Explanation
These are the standards and conventions that are mature today, and supported by all common commercial tools today.
UTF-8 is ‘backward compatible’ with ASCII, using one byte for western character sets. Therefore it is most suited for our applications.
WS-I help us to achieve maximum platform interoperability, which is interoperability between BEA, IBM, Oracle, Sun, open source and Microsoft implementations.
Example
Schema Namespaces
Here we describe guidelines specific to the schemas, this is the .XSD files as well as the schema definition part in the .WSDL files.
Always use a Target Namespace in schemas Guideline
All schemas MUST define a targetnamespace.
This namespace must start with http://www.rsvz-inasti.fgov.be/schemas/WS for WSDL schemas,
and with http://www.rsvz-inasti.fgov.be/schemas/WS/schema for ordinary schemas (XSD files).
Explanation
Namespaces define a scope for the name of elements, types and attributes, so that two elements can have the same name as long as they belong to different namespaces. This is so because the real name of an element, type or attribute is the name of the element, type or attribute prefixed with the namespace name.
By having http://www.rsvz-inasti.fgov.be/schemas/WS as the first part of the namespace name we ensure that our namespace names will be unique worldwide.
Example
targetNamespace="http://www.rsvz-inasti.fgov.be/schemas/WS/schema/LegalInfo/V1"
elementFormDefault & attributeFormDefault Guideline
When defining a schema you MUST specify the following in the element:
elementFormDefault=”qualified”
attributeFormDefault=”unqualified”.
Explanation
elementFormDefault=”qualified” ensures that local (or anonymous) element definitions must be namespace-prefixed in instance documents. This improves human readability, as well as performance of xml parsers.
An schema fragment:
If we specified elementFormDefault=”unqualified” an instance document would look like this:
Darin
Darby
Applying our guideline the same instance document is as follows:
<ex:Husband>Darin
<ex:Wife>Darby
Readability is even more important when multiple namespaces are involved, as will be the case for reasons of version management.
In the case of attributes the opposite approach is taken, since intuitively attributes belong to their element and thus implicitly have the same namespace. A prefix is thus unnecessary.
Example
targetNamespace="http://www.rsvz-inasti.fgov.be/schemas/WS/schema/LegalInfo/V1"
elementFormDefault="qualified" attributeFormDefault="unqualified"
xmlns="http://www.rsvz-inasti.fgov.be/schemas/WS/schema/LegalInfo/V1">
Default namespace and qualifiers Guideline
If a default namespace is used in a schema definition, then it MUST be that of the target namespace.
Explanation
This guideline is for human readability. Element or type definitions (via name attribute) have no prefixes – they are defined in the namespace mentioned as target namespace. If these elements or types are referred to elsewhere in the same schema definition (via type or ref attribute) then it makes sense not to use a prefix either. To achieve this, the default namespace must be the same as the target namespace.
Example
targetNamespace="http://www.rsvz-inasti.fgov.be/schemas/WS/Affiliation/V1"
elementFormDefault="qualified" attributeFormDefault="unqualified"
xmlns="http://www.rsvz-inasti.fgov.be/schemas/WS/Affiliation/V1">
...
...
Prefixes Guideline
You SHOULD use these prefixes for the listed namespaces:
xs W3C Schema namespace
soap SOAP namespace
wsdl WSDL namespace
tns target namespace
Explanation
Standardising prefixes improves human readability, and developer productivity.
Reuse & Encapsulation: Local vs. Global Elements, Elements vs. Types Guideline
Local elements SHOULD be preferred over global elements.
For reuse, types SHOULD be preferred over global elements.
Explanation
Re-use via types is more flexible than re-use via global elements. One advantage of types is that you can have multiple elements re-using the same type but with a different name. Extension of types is also an advantage.
Some techniques are not possible with types, only with global elements. Still, you can define a type, have a global element of this type, and have all possibilities. Further, some of these techniques are forbidden elsewhere in this document, e.g. substitution groups.
Encapsulation is about hiding complexity. Someone who takes a look at a schema for the first time only considers the global elements at first: they are the ones that can be used to start some XML documents. Local elements are only considered next, in the scope of a global element. If many global elements exist then lots of elements must be studied; if only a few, a minimum, exist it is much easier to see which ones to use.
The separation global/local can be seen as a sort of drill-down: first select the interesting one, and then drill down to its internals.
Example
Below we first have a type definition, RelationshipStruct. This is then used to define a local element Relationship in AcceptAffiliationType. Finally, a global element AcceptAffiliation is created of that latter type.
<xs:complexType name="RelationshipStruct">
<xs:sequence>
<xs:element name="Century" type="CenturyType" minOccurs="0">
…
xs:complexType>
Then RelationshipStruct is re-used to define an element named Relationship, in yet another type
<xs:complexType name="AcceptAffiliationStruct">
<xs:complexContent>...
<xs:element name="Relationship" type="tns:RelationshipStruct" minOccurs="0" />
xs:complexContent>
xs:complexType>
<xs:element name="AcceptAffiliation" type="tns:AcceptAffiliationStruct" />
Another example on the schema extension mechanism:
<xs:complexType name="AbstractResultStruct" abstract="true" />
<xs:complexType name="NoMatchStruct">
<xs:complexContent>
<xs:extension base="AbstractResultStruct">
<xs:sequence>
<xs:element name="Code">
...
<xs:complexType name="MatchesStruct">
base="AbstractResultStruct">
...
The element Result is then defined with type AbstractResultType:
name="Result" type="AbstractResultStruct"/>
An XML instance must use the xsi:type attribute to signal the actual type:
<p:Result xsi:type="p:NoMatchStruct"
xmlns:p="http://www.rsvz-inasti.fgov.be/schemas/WS/schema/LegalInfo/V4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
250250
Schema element & type name conventions Guideline
Names SHOULD follow UpperCamelCase convention.
Names of simple types SHOULD end with suffix “Type”.
Names of complex types SHOULD end with suffix “Struct”.
Explanation
UpperCamelCase means that identifiers start with a capital, and each following noun also starts with a capital – other letters are lower case.
Abbreviations can be all uppercase. The noun following the abbreviation then should again start with an upper case letter.
The suffixes make it immediately clear what kind of construct is used: is it an element, complex type or simple type.
Be aware that in XML Schema an element definition ‘Attestation’ can co-exist with a type definition equally named ‘Attestation’. Internally, schema makes a kind of sub-namespace division between elements and types. This may lead to hard to find validation error.
Example
Substitution groups Guideline
Substitution groups MUST NOT be used.
Explanation
Substitution group elements must be defined as global elements. This is inconsistent with the guideline on re-use and encapsulation.
Code generators have difficulties processing substitution group elements.
A better alternative to substitution groups is “schema restriction”, as explained in http://www.w3.org/TR/xmlschema-0/#UseDerivInInstDocs.
Use of Guideline
The technique SHOULD NOT be used.
Explanation
Using this technique may have far-stretching consequences in schema documents that import other schemas containing this construct. These side-effects are difficult to detect and predict.
Guideline
For documentation or comments the annotation and documentation elements MUST be used.
XML comments () MUST NOT be used for documentation purposes.
Explanation
When using parsers or other XML tools, e.g. XSLT, Xquery, an XML comment is often lost.
With annotation and documentation elements it is possible to generate user documentation.
Example
Do not use:
Instead, use:
Datatype voor geboortedatum
Format date de naissance
Enumerations Guideline
XSD enumerations MUST only be used for value-sets that are relatively stable and limited in size.
XSD enumerations of type xs:string MUST be composed of letters, numbers or an underscore.
XSD enumerations of type xs:string MUST NOT start with a number.
XSD enumerations of type xs:string MUST NOT only differ in case.
XSD enumerations of type xs:string SHOULD be preferred over other types.
Explanation
Using enumerations has the advantage that only prescribed values can be used, since the possible values are validated against a set prescribed in the schema.
The downside is: any addition or removal of a value requires a minor or major upgrade of the defining schema. This implies that all parties involved must integrate the new schema. Therefore one must be sure that the set of values in the enumeration will not change, at least for the normal life of a schema version.
Some examples:
NACE codes must not be enumerations. The messages that somewhere use a NACE code will change less frequently than the set of NACE codes, overall.
Error codes must never be part of enumerations. A backend-system might add an error code at any time, rather independently. It is better to describe these errorcodes in a separate human-readable document.
Male/Female is a good candidate for an enumeration. Adding a third option, like ‘Unspecified’, would mean that there are a lot of other accompanying business changes, so the schema change would be necessary anyway and would be part of a much bigger rework of different systems and databases.
Other legally prescribed values are also a good candidate for an enumeration, as far as they do not change too much and that they are closely related to the business processes involved.
Enumations of type xs:string are preferred since they are better suited to be transformed into language constructs.
Web Service frameworks that generate code for these enumerations, are limited by the language and development platform that they are targeting.
Not all frameworks support generating enums for types other than xs:string, mostly because identifiers are required to start with a letter.
Example
Good example:
Java code:
public enum GenderType {
MALE("male"),
FEMALE("female");
}
public class Person {
protected String name;
protected GenderType gender;
public String getName() {
return name;
}
public void SetName(String value) {
this.name = value;
}
public GenderType getGender() {
return gender;
}
public void SetGender(GenderType value) {
this.gender = value;
}
}
C# code:
public enum GenderType : int {
male = 0,
female = 1
}
public partial class Person {
private string NameField;
private GenderType GenderField;
public string Name {
get { return this.NameField; }
set { this.NameField = value; }
}
public GenderType Gender {
get { return this.GenderField; }
set { this.GenderField = value; }
}
}
Code and Description Guideline
A code element SHOULD NOT be accompagnied by a textual description of the code when the value-set is stable or common knowledge.
For codes that are not accompanied by a textual description, the XSD or the interface documentation SHOULD include a textual description of each item in the value-set or a reference to it.
Explanation
A textual description of a code is only useful for presentation purposes, and would affect the size of all exchanged messages – even if the description would hardly ever change.
Localization of messages, and presenting codes in a human-readable form SHOULD be a feature of consuming applications, and is usually implemented using resource bundles or code tables.
Below is an example of a NisseProfession element, which describes the profession of a person.
Good example:
Bad example:
URI References Guideline
The case of a URI MUST exactly match the actual location and filename of a referenced document.
To refer to other documents in the same tree, you MUST use relative path references.
The slash "/" character MUST be used to separate hierarchical components.
Explanation
If the case of a URI does not match the actual location and filename of a referenced file, then that file cannot be found when the scheme is case-sensitive.
URI references that refer to the same document but differ in case are not considered equivalent. In the context of WSDL/XSD imports and includes, this can cause definitions from the same document to be imported more than once.
Relative addressing of URI allows document trees to be partially independent of their location and access scheme. For instance, it is possible for a single set of documents to be simultaneously accessible and traversable via multiple schemes if the documents refer to each other using relative URI. Such document trees can be moved, as a whole, without changing any of the relative references.
According to RFC 2396, URI references that do make use of the slash "/" character for separating hierarchical components are considered opaque by the generic URI parser. Although some URI parsers do support other separator characters for hierarchical components, using them disables interoperability.
Good example:
<xs:import namespace="http://www.rsvz-inasti.fgov.be/schemas/WS/schema/VierdeWeg/V1"
schemaLocation="schema/VierdeWeg/VierdeWeg_V1.xsd" />
Bad example:
<xs:import namespace="http://www.rsvz-inasti.fgov.be/schemas/WS/schema/VierdeWeg/V1"
schemaLocation="schema\VierdeWeg/VierdeWeg_V1.xsd" />
WSDL Style and Use Guideline
A WSDL document MUST use the document/literal wrapped style, meaning:
Each part definition MUST reference a global element declaration defined, imported, or included in the types section of the WSDL document.
In the binding definition, the soap:binding MUST specify (this is the default value), and the soap:body definitions MUST specify use="literal".
Input and output messages (if present) MUST contain exactly one part.
The element definitions are "wrapper" elements; the input and output parameters are defined as element structures within these wrapper elements.
A wrapper element MUST be defined as a complex type that is a sequence of elements (with no attributes).
The name of the input wrapper element MUST be the same as the operation name.
The Web Services stack in Windows Communication Foundation (WCF) imposes the following additional requirements:
Message part for input or output parameters MUST always be named "parameters".
For headers, the message part MUST have “header” as name.
For faults, the message part MUST be named “detail”.
The name of the response wrapper element MUST be the same as the operation name with suffix “Response”.
The elements representing input or output parameters which are mapped to “object types” must be nillable.
The JAX-WS 2.0 specification (JSR-000224) adds the following criteria:
The wrapper elements MUST NOT contain other structures such as wildcards (element or attribute), xsd:choice, substitution groups (element references are not permitted) or attributes; furthermore, they MUST NOT be nillable.
Wrapper child elements with the same local name MUST also have the same type.
The JAX-WS 2.0 specification and WCF specify difference criteria with regards to the nillability of parameters. Therefore, the only valid approach here is to compare the results on both.
Microsoft recommends using the XmlSerializer (instead of the DataContractSerializer) when dealing with contract-first design. This can be accomplished by passing the following options to svcutil.exe:
Option
|
Description
|
/useSerializerForFaults
|
This option specifies whether the serializer specified in the 'serializer' switch is used for fault contract types.
DataContractSerializer is used for faults if this switch is not specified.
|
/serializer:XmlSerializer
|
Generate data types that use the XmlSerializer for serialization and deserialization.
|
More information is available here.
Explanation
WSDL distinguishes two different binding styles for SOAP:
Indicates that the SOAP body simply contains an XML document. The sender and receiver must agree on the format of the document ahead of time.
Specifies that the SOAP body contains an element with the name of the Web method being invoked. This element in turn contains an entry for each parameter and the return value of this method.
The strength of the “document” style (compared to RPC) is that the soap:body is completely defined by XML Schema, allowing the message to be validated before invoking an operation on the service producer.
The “Use” attribute specifies the encoding rules of the SOAP message. This concerns how types are represented in XML. The two offered choices are:
Each message part references an abstract type using the type attribute.
If the use is Literal, each part references a concrete schema definition using either the element or type attribute; in other words, data is serialized according to a given schema. In practice, this schema is usually expressed using W3C XML Schema.
Neither document/encoded nor RPC/encoded are WS-I compliant, so that leaves us with the document/literal binding model.
Apart from the mentioned styles and uses, there’s another very commonly used style called document/literal wrapped. Its advantage over the document/literal (non-wrapped) style is that the operation name is in the SOAP message, so the receiver can dispatch the message easiliy.
Although there’s no formal specification that defines the style, document/literal wrapped has become the de facto standard for defining interoperable Web Services.
Unique Identifiers Guideline
When a given element is intended as a unique identifier:
The application that creates the identifier MUST ensure the value is unique within its application.
A unique identifier MUST be combined with the identity of the originator to obtain an identifier that is unique across all partners.
Explanation
While mechanisms exist to generate a Universally Unique Identifier, these implementations may not be available on all hardware or development platforms.
Depending on the actual implementation, the identifier may also reveal private information such as the identity of the computer that created the UUID.
Combining the unique identifier with the identity of the organization that created it, results in a more controlled approach while still guaranteeing uniqueness across all parties involved.
For example:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
xmlns:v3="http://www.rsvz-inasti.fgov.be/.../V3">
xmlns:meta="http://www.rsvz-inasti.fgov.be/.../V4">
2008-09-29T03:49:45
003
SOCIAS
000
200
004
73081328744
soap:Body>
soap:Envelope>
In this example, the MessageID is intended as the identification of the message exchange. A receiving application combines the value of the MessageID element (i.e. 004) with the identity of the sender to obtain an identifier that is unique across all partners.
Share with your friends: |