B2b web Service Guidelines V2 rsvz enterprise Architecture
Modifications and Version Impact Analysis
Download 0.95 Mb.
|
- Navigate this page:
- Explanation
- Releases
Modifications and Version Impact AnalysisGuidelineWhenever a structural change is applied to a WSDL or XML Schema, its version number MUST be augmented. When the version of a WSDL or XML Schema is augmented, then the following algorithm MUST be applied recursively to determine the version of an importing WSDL or XML Schema: if none of the changes are needed in an importing CI, then we have 2 options for the importing CI: the importing CI sticks to the older version the importing CI does not change version the importing CI imports the upgraded version the importing CI updates the namespace of the imported CI the importing CI increments its version if at least one change is needed in an importing CI, then the importing CI must import the upgraded version the importing CI updates the namespace of the imported CI the importing CI increments its version stop recursion if there is no importing CI anymore (i.e. when a WSDL CI has been treated) ExplanationTo determine if a configuration item undergoes a version upgrade or no change, it suffices to follow the import-relation between configuration items (see “ Figure 1 - Example Configuration” on page 54 for an example) and apply the above algorithm. The figure below also shows the import relationship on Configuration Elements, the identifying name, major and minor, and what concrete types of Configuration Elements exist. 
Note that Schema files can import other Schema files, and that WSDL files can import other WSDL files or Schema files. However, Schema Files cannot import WSDL files. To allow having multiple versions of the same Service in production in parallel the version must be included in the namespace and filename. In a sense a major change is exactly the same as a completely new Schema or Service Definition if you look at the consequences. ReleasesGuidelineA Release and Release Candidate MUST be named as follows:
A Release MAY contain multiple versions of the same Web Service Definition, i.e. the same Name but different Versions, for two reasons: Phasing out a service without disrupting production traffic. Support unfinished business of the past that does not comply and is incompatible with newer legislation. Avoid an upgrade of another Service that does not use a changed Schema. ExplanationA Release is a consistent set of schemas and web services that is put in production as a whole. An example of a release might be all the schemas and web services depicted in “ Figure 1 - Example Configuration” on page 54. As seen in this example a release, identified as say R2, consists of multiple specific versions of a schema or web service. Even more, the same schema may be included under multiple (major) versions, as is the case for Legal schema. It is important to realize that currently only the versions of the Service Definitions really matter, because Schema versions are implicitely defined through the imports of these Service Definitions, and Schema’s are never used on its own. So a Release determines essentially what Versions of which Services can be used between NISSE and SIFs. It is also important to note that this guideline does not say that all services of the current Release must be used or implemented (i.e. consumed or provided). It is virtually impossible that all 15 communicating partners would switch to another version of a Service at about the same time. Therefore a Release will keep the older Service version together with the newer Service version. NISSE will have both Service versions available at the Release date, but SIFs will continue to use the older version (“phasing out”) for a few more days or weeks and then switch to the newer version. More on this follows in the next guideline. Before a Release is put into production it has been the result of earlier tests, like System testing and Acceptance. In these preliminary phases we do not yet speak of Release, but of Baselines and Release Candidates. The following figure defines these terms. 
Figure 2 – Baseline, Release Candidates and Releases In this figure, a Baseline is a consistent set of schema and web service files, represented by CfgElement. CfgElements are files where the filename is a direct derivative of the name and version. A Baselines has a ‘revisionNr’, this is a label private to NISSE that completely identifies the Baseline9. Once a Baseline is considered ready for public availability, a special kind of Baseline is created, the “Release Candidate”. This is a package that will be distributed to all SIFs and NISSE so that everybody can start developing and testing the new or changed services. It is different from a Baseline in that it should be stable, should be linked to a list of Change Requests (see Change Control Board procedure), and that it has a Version and Sequence number. The Sequence is a sequence number – it is very unlikely that the first Release Candidate will be bug free and will become a Release; instead many Release Candidates with the same Version will be issueduntil all bugs are fixed. Once development and then acceptance testing have finished successfully, the latest Release Candidate used at that time becomes a Release. Note that a Release has exactly the same contents as the successful Release Candidate, and has the exact same version. In other words it can be viewed as just taking the Release Candidate package and attaching an additional Release ‘tag’. A Release has 3 phases: ready to be put into production (‘ready’), in production (‘current’), and retired from production (‘retired’). Releases are also special in that they are published on the web site of RSVZ-INASTI, and that they have to be stored ‘for eternity’. |