B2b web Service Guidelines V2 rsvz enterprise Architecture



Download 0.95 Mb.
Page3/14
Date02.05.2018
Size0.95 Mb.
#47313
1   2   3   4   5   6   7   8   9   ...   14

Glossary




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/




  1. 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.
    1. General

      1. Standards

        1. Guideline


Following standards MUST be used:

  1. XML 1.0 - http://www.w3.org/TR/2000/REC-xml-20001006

  2. UTF-8 encoding

  3. Namespaces in XML 1.0 - http://www.w3.org/TR/2006/REC-xml-names-20060816/

  4. XML Schema 1.0 - http://www.w3.org/2001/XMLSchema

  5. SOAP 1.1 - http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

  6. 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.


        1. 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.
        1. Example





    1. 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.
      1. Always use a Target Namespace in schemas

        1. 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).
        1. 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.
        1. Example




targetNamespace="http://www.rsvz-inasti.fgov.be/schemas/WS/schema/LegalInfo/V1"
      1. elementFormDefault & attributeFormDefault

        1. Guideline


When defining a schema you MUST specify the following in the element:

  • elementFormDefault=”qualified”

  • attributeFormDefault=”unqualified”.
        1. 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.
        1. 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">


      1. Default namespace and qualifiers

        1. Guideline


If a default namespace is used in a schema definition, then it MUST be that of the target namespace.
        1. 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.
        1. 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">

...


...



      1. Prefixes

        1. Guideline


You SHOULD use these prefixes for the listed namespaces:


  • xs W3C Schema namespace

  • soap SOAP namespace

  • wsdl WSDL namespace

  • tns target namespace



        1. Explanation


Standardising prefixes improves human readability, and developer productivity.
      1. Reuse & Encapsulation: Local vs. Global Elements, Elements vs. Types

        1. Guideline


Local elements SHOULD be preferred over global elements.
For reuse, types SHOULD be preferred over global elements.
        1. 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.


        1. 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



      1. Schema element & type name conventions

        1. Guideline

Names SHOULD follow UpperCamelCase convention.


Names of simple types SHOULD end with suffix “Type”.
Names of complex types SHOULD end with suffix “Struct”.

        1. 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.

        1. Example









      1. Substitution groups

        1. Guideline


Substitution groups MUST NOT be used.
        1. 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.
      1. Use of

        1. Guideline


The technique SHOULD NOT be used.
        1. 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.
      1. Documentation & Comments

        1. Guideline


For documentation or comments the annotation and documentation elements MUST be used.
XML comments () MUST NOT be used for documentation purposes.
        1. 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.
        1. Example


Do not use:

Instead, use:




Datatype voor geboortedatum

Format date de naissance


      1. Enumerations

        1. Guideline


  1. XSD enumerations MUST only be used for value-sets that are relatively stable and limited in size.

  2. XSD enumerations of type xs:string MUST be composed of letters, numbers or an underscore.

  3. XSD enumerations of type xs:string MUST NOT start with a number.

  4. XSD enumerations of type xs:string MUST NOT only differ in case.

  5. XSD enumerations of type xs:string SHOULD be preferred over other types.



        1. 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.
        1. 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; }



}

}

      1. Code and Description

        1. Guideline


  1. A code element SHOULD NOT be accompagnied by a textual description of the code when the value-set is stable or common knowledge.

  2. 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.



        1. 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:




























      1. URI References

        1. Guideline


  1. The case of a URI MUST exactly match the actual location and filename of a referenced document.

  2. To refer to other documents in the same tree, you MUST use relative path references.

  3. The slash "/" character MUST be used to separate hierarchical components.



        1. 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" />

      1. WSDL Style and Use

        1. Guideline


A WSDL document MUST use the document/literal wrapped style, meaning:


  1. Each part definition MUST reference a global element declaration defined, imported, or included in the types section of the WSDL document.

  2. In the binding definition, the soap:binding MUST specify (this is the default value), and the soap:body definitions MUST specify use="literal".

  3. Input and output messages (if present) MUST contain exactly one part.

  4. The element definitions are "wrapper" elements; the input and output parameters are defined as element structures within these wrapper elements.

  5. A wrapper element MUST be defined as a complex type that is a sequence of elements (with no attributes).

  6. 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:




  1. Message part for input or output parameters MUST always be named "parameters".

  2. For headers, the message part MUST have “header” as name.

  3. For faults, the message part MUST be named “detail”.

  4. The name of the response wrapper element MUST be the same as the operation name with suffix “Response”.

  5. 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:




  1. 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.

  2. 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.


        1. Explanation


WSDL distinguishes two different binding styles for SOAP:


  • Document style

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.




  • RPC style

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:


  • Encoding

Each message part references an abstract type using the type attribute.




  • Literal

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.

      1. Unique Identifiers

        1. Guideline


When a given element is intended as a unique identifier:


  1. The application that creates the identifier MUST ensure the value is unique within its application.

  2. A unique identifier MUST be combined with the identity of the originator to obtain an identifier that is unique across all partners.
        1. 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.



    1. Download 0.95 Mb.

      Share with your friends:
1   2   3   4   5   6   7   8   9   ...   14




The database is protected by copyright ©ininet.org 2024
send message

    Main page