B2b web Service Guidelines V2 rsvz enterprise Architecture


Service Implementation Aspects & Versioning



Download 0.95 Mb.
Page11/14
Date02.05.2018
Size0.95 Mb.
#47313
1   ...   6   7   8   9   10   11   12   13   14

Service Implementation Aspects & Versioning

  1. Guideline


  1. All parties MUST conform to one-and-the same Release for a given period of time. This Release and time period is communicated by NISSE. This Release is called the ‘Current Release’.




  1. NISSE MUST support all versions of all services of the current Release, both as a service provider and service consumer.




  1. SIFs MUST inform NISSE of which Version of a Service they provide. This way NISSE knows what version to use as a service consumer.




  1. Versions MAY be marked “PhasingOut”, implying that:

    1. it MUST only be used for smooth installation of the new release

    2. it MUST NOT be used to start new flux instances, or being used in new flux instances10

    3. The new version MUST be used ASAP.



        1. Explanation


First we list the requirements that form the basis of these guidelines:

  1. With 15 communicating parties it is very difficult to install a release at the same time. All systems should be taken down at the same time, install the new release and go up more or less together. This is very difficult to organize. Moreover, if one party fails to install the new release, all should go back to the older Release.
     Therefore, putting a release in production should be possible in a larger time frame, e.g. a week, and all SIF’s can do this independently of each other and after NISSE has itself put the current Release into production.

  2. Sometimes a new Service version is only required by a limited number of SIF’s. The impact should be limited to these SIF’s only.
     Support for multiple versions of a Service within a Release.

  3. Versioning is a complex problem, which needs to be handled by all SIFs consuming resources.
     Shield SIFs as much as possible from these issues, and centralize work as much as possible with NISSE.

Let’s see how these requirements and the above guidelines work together, using the scenarios in the table below.
Release R1.0.0 is the current release of service ‘Sa’. It includes version ‘V1’ of the ‘Sa’ service.
All SIFs and NISSE use the R1 release, and as a result they all use the V1 version of Sa.
Not shown is that there is a ‘Ready’ release R2 which will go in production on December 6th. It has a new version V2 of service Sa.





December 6th. NISSE puts into production its new implementation for Sa V2, and keeps Sa V1 running.
The SIFs still use Sa V1 while communicating with NISSE, and NISSE also uses Sa V1 when communicating with the SIFs. Since Sa V1 is still valid the SIFs also conform to R1.
Meantime SIF 1 works on implementing Sa V2.





December 25th. This is a quiet day.
SIF 1 puts its service Sa V2 into production. It then informs NISSE that Sa V2 is ready. All new Sa operation invocations will use V2, regardless of whom – NISSE or SIF – initiates the operation.
If Sa is used in a Flux, new Flux instances, will use V2. Existing fluxes using Sa will continue to use V1 – the phasing out version.
SIF 2 is still using Sa V1.

The above depicted approach enables a number of important features:



  • A SIF can, within reasonable boundaries, determine the moment it enables a newer version of a Service.

  • Transitioning to a newer version of a Service can happen without service interruption.

  • It is up to NISSE to make sure that a SIF will only get message operation belonging to the service versions that the SIF supports. (Of course, these versions must be supported in the Current Release).

Regarding supporting an older version of a Service in a new Release the following table can serve as a guideline. Say that the Current Release contains version V1 of Service A, what can happen in the next release?




Contents of next Release

When to use

Service A, V1 ‘Phase Out’

Service A, V2
There is new legislation and V1 must phase out. Or V2 has more information and it is agreed that this one should be used instead.
Service A is used in existing fluxes, and these existing fluxes must still be completed using V1.

Service A, V1

Service A, V2
Only a limited number of SIFs need new functionality and the functionality offered by V1 is still valid. Both versions can be used, but a SIF MUST choose only one.

Service A, V1

Service A, V2
V1 must not be used anymore by any SIF or NISSE. Perhaps because of legal reasons, or serious flaws in the service design.

Of course, smooth transition is not possible, and therefore this possibility should be avoided.


      1. Life Cycle of Releases


The figure below summarizes the life cycle or releases.

The public website of NISSE contains the following items of all retired, current and ready Releases11:

  • WSDL’s

  • XML Schema’s

  • Interface Documentation

  • B2B Web Service Guidelines

Note that since not all services evolve at the same pace, multiple versions of the B2B Web Service Guildeines may apply to a given release.


As soon as a Release Candidate appears, it can be downloaded by a SIF’s development team. To test this Release Candidate a System-Test environment is available at NISSE with which the SIFs can test the new Release Candidate.
If no more bugs are found in the System-Test environment, then the latest Release Candidate is copied to the Acceptance Environment, where formal testing takes place.
If a bug is found during Acceptance Tests, a new Release Candidate is created which is first tested again in the System-Test environment and only after successful tests copied to Acceptance.
If a Release Candidate has no more bugs in Acceptance, it is promoted as a “ready” Release, awaiting production at the agreed date.
In Production there is only one active Release, the “Current Release”.
It is quite possible that there is a R3 “active” release, a R4 “ready” release, and a RC5_3 in Acceptance.
When a “ready” release is put into Production, the removed Release becomes “retired” and is marked as such in the public website.

      1. About Downloading Schema & WSDL Files





TODO Punt is dat we uit-productie genomen releases nog steeds moeten bijhouden op de website.

We moeten ook op één of andere manier kunnen aangeven wat de current release is.

Ook vraag ik me af – niet opgenomen in het voorstel – of we de service documentatie niet mee onder http://www.rsvz-inasti.fgov.be/schemas/WS/ moeten steken, b.v. in een subfolder “documentation”; release beheer wordt dan veel makkelijker.




        1. Guideline


  1. Communicating partners MUST use a local copy of the XML Schema and WSDL files.




  1. The “Current Release” will be available at two places

    1. http://www.rsvz-inasti.fgov.be/schemas/WS/Current

    2. http://www.rsvz-inasti.fgov.be/schemas/WS/RV where RV is the release label of the current release




  1. The “Retired Releases” will be available at http://www.rsvz-inasti.fgov.be/schemas/WS/RV where RV is the release label of the retired release

        1. Explanation


For optimal performance and robustness XML Schema and WSDL files must be kept locally.
Certain Web Services frameworks require access to the XML Schema and WSDL files to obtain meta-data that is not available in the generated proxy classes, and need to be explicitly configured to use local copies.
Unexpected or planned down-time of the RSVZ-INASTI website should not affect day-to-day B2B operations.

        1. Example


namespace="http://www.rsvz-inasti.fgov.be/schemas/WS/schema/LegalInfo/V1"



schemaLocation="./schema/LegalInfo.xsd">


The Current Release as of October 2008 is the following:

Note that there are no “Retired Releases” yet in the above screenshot. If it were, there would be a http://www.rsvz-inasti.fgov.be/schemas/WS/R1/Affiliation etc.
TODO RV voor current release


    1. Download 0.95 Mb.

      Share with your friends:
1   ...   6   7   8   9   10   11   12   13   14



The database is protected by copyright ©ininet.org 2024
send message
    Main page
united states
total number
vast majority
federal government
other side
next generation
supreme court
information contained
current state
executive director
national association
middle east
east coast
general assembly
private sector
same time
west coast
united kingdom
united nations
total amount
full range
highest level
soviet union
european union
national academy