B2b web Service Guidelines V2 rsvz enterprise Architecture
Download 0.95 Mb.
|
- Navigate this page:
- Explanation
- Example
VersionsGuidelineAn XML Schema or Web Service WSDL MUST be identified by a tuple (Name, [Provider,] Version) where Name and Provider are a string, and Version a number V 1. The Name MUST indicate the use of the Service or Schema and the Version augments when there are evolutionary changes. The Provider element only applies to services in which multiple providers play a role. A target namespace MUST be as follows: WSDL: http://www.rsvz-inasti.fgov.be/schemas/WS/name[/provider]/Vversion XML Schema: http://www.rsvz-inasti.fgov.be/schemas/WS/schema/name/Vversion where: name the service or schema name. version the version. provider (optional) an identifier representing the provider that offers the service. There MUST be one and only one XML Schema file per targetNamespace and vice versa. It MUST be named name_Vversion.xsd. A Web Service, named service, MUST be described using one or more of the following files: service_Vversion.wsdl – (optional) containing WSDL type, message and porttype elements Nisseservice_Vversion.wsdl – (optional) containing WSDL binding and service elements where NISSE is the service provider and interface definition specific to the operations provided by the service provider Sifservice_Vversion.wsdl – (optional) containing WSDL binding and service elements where a SIF is the service provider, and interface definition specific to the operations provided by the service provider where version MAY differ between the indivual WSDL files. If a service has only one service provider (NISSE or SIF), then service_Vversion.wsdl MUST also contain the WSDL binding and service elements. When there are multiple service providers, the targetnamespace of the WSDL for a given provider SHOULD contain an identifier representing that provider. The binding and service elements MUST NOT be prefixed with this identifier. In that case service_Vversion.wsdl SHOULD only contain the WSDL types, messages and port types that are shared between two or more providers. The following path structure MUST be followed:
ExplanationAll types and elements of one namespace are defined in exactly one XSD Schema file. It is possible to have multiple XSD Schema files that use the same target namespace, but this may lead to problems. For example, it is not easy to see if an element or type is redefined in some other schema file, which is obviously a problem. Such redefinition is easy to detect with tools if co-located in the same file. For WSDL’s it is a bit more complex. For one Service Definition there can be more than one WSDL file, but all with the same name, and with a target namespace that MAY only differ in the provider component and version. The individual WSDL files MAY differ in version to cope with changes that only affect a single service provider. The reason to split WSDL files this way is to make it much easier to import them in code generation tools or ESB products. For example, given a service Affiliation_V3, a SIF will import SifAffiliation_V3.wsdl and Affiliation_V3.wsdl as a Service Provider and NisseAffiliation_V3.wsdl and Affiliation_V3.wsdl as a Service Consumer. Note that the combination (name, [provider,] version) has the same identifying value as a targetnamespace, since a targetnamespace consists of some static text, the service name and the version. This is true for both XSD Schemas and WSDL files. Specifically for WSDL files, the targetnamespace MAY also include the identifier of the service provider. The path structure was introduced to ease readability: this way all files do not appear in the same directory. The other aspects of this guideline can be easier explained in the next guideline on Version Impact Analysis, so we defer that until then. ExampleThe figure below shows a configuration of two Services, consisting of WSDLs and XML Schemas. Each file has its own target namespace containing the version number. The arrows indicate that a schema is imported in another schema, or that a WSDL is imported into another WSDL. 
Some notes on the example configuration: Of Legal there are two versions used at the same time, V2 and V3. V2 is used by LegalInfo web service, V3 is used by Affiliation web service. The SIF provider WSDL of the Affiliation web service has evolved more quickly than the NISSE counterpart (V2 vs V1). The path structure of the WSDL and XML Schema files also follows a fixed pattern, as shown below. |-- Affiliation |-- Affiliation_V1.wsdl |-- NisseAffiliation_V1.wsdl |-- SifAffiliation_V2.wsdl |-- LegalInfo |-- LegalInfo_V2.wsdl |-- NisseLegalInfo_V2.wsdl |-- SifLegalInfo_V2.wsdl |-- schema |-- Affiliation |-- Affiliation_V1.xsd |-- Legal |-- Legal_V2.xsd |-- Legal_V3.xsd |-- Base |-- Base_V3.xsd |-- MetaInfo |-- MetaInfo_V5.xsd |