B2b web Service Guidelines V2 rsvz enterprise Architecture
Download 0.95 Mb.
|
- Navigate this page:
- References
- Other documents
IntroductionRSVZ-INASTI strives for standardising automated message exchange, especially towards Social Insurance Funds (SIF), using standard Web Services. Also KSZ, KBO (primary network) and FedICT evolve towards and support these standards. This document describes all guidelines on the design and use of Web Services between RSVZ-INASTI and the Social Insurance Funds. Chapter 3 gives context information on the guidelines. Specifically the role of XML Schema and WSDL – Web Service Description Language – is explained. Chapter 4 describes the terminology used in this document. In chapter 5 the guidelines are listed one by one, including explanation and an example. Finally chapter 6 describes the procedure for the initial certificate request, and the renewal of certificates. ReferencesFedICT GuidelinesFedICT RSVZ Service Interface Guidelines.pdf xFront GuidelinesElement Versus Type Global Versus Local Elements Hide Versus Expose Schema Versioning Zero, One, Or Many Namespaces
Other documentsDocument Literal Wrapped: http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/ ContextWeb Services is a standardized exchange of XML messages between two parties, for example between RSVZ-INASTI and a SIF. This standard has two parts, one being the XML message structure1 and the other being the transport protocol such as HTTP, SMTP etc. A Web Service thus imposes rules on the message itself and how it is transported. The rules on a specific Web Service are described in a separate WSDL file, which is also an XML file describing the message structure and transfer protocol. A WSDL file has two functions: A “contract” between RSVZ-INASTI and the SIF’s on what functionality must be available on each side, and how it can be invoked using an XML message exchange. Consequently, if a SIF provides software based on this contract it is guaranteed to use the functionalities described in the contract. A WSDL can (and should) be used by today’s standard tools for code generation. All code to create or interpret the XML messages and code to set up the communication can be generated this way. This greatly improves development productivity and maximally avoids errors. Today when one speaks of ‘standard Web Services’ the use of this WSDL and code generation is typically implied. The figure below shows a typical scenario, starting by a new or changed web service ‘contract’ up to putting the new or changed web service into production. 
A WSDL file is published on a RSVZ-INASTI web site and is downloaded by a SIF and imported in a standard software tool (Visual Studio .NET, Java Eclipse…). Functional personnel can see what functionality is available, and technical personnel can see how to use and integrate this functionality in their application programs. The software tool generates all code that transforms XML web service messages to program data and vice versa, including code to set up a connection with RSVZ-INASTI. Specifically, for each Web Service functionality (‘operation’) a corresponding programming language operation (or method) is generated. Then, for each data exchanged in the form of an XML message for that web service functionality, a corresponding programming language data structure is defined, and used as input or output parameter of the generated code operation. A technical person then integrates the generated code with the SIF’s own application code. Two possibilities: If RSVZ-INASTI offers (and implements) the functionality (service) then the SIF just has to generate so-called ‘stub-code’ used for calling the RSVZ-INASTI server implementing the functionality. For example, for asking RSVZ-INASTI to register a new self-employed worker. If the SIF has to implement the service it has to generate a so-called ‘server-skeleton’ and install it on its own server, so it can be called by RSVZ-INAST. For example, RSVZ-INASTI informing the SIF that registration has succeeded. The generated code, together with the SIF’s application code, is installed on the SIF’s server infrastructure. The SIF and RSVZ-INAST exchange web services conforming to the WSDL standard. Without WSDL or SOAP web services, as is the case for the current electronic exchanges (phases 1a, 1b and 2a), codegeneration is possible from the schemas, but with some important restrictions: Schema is intended to describe possible documents; it is not centered on functionality or operations as WSDL is. In WSDL functionality comes first, with Schema alone you need to add additional written documentation on what to do with the transferred documents. Code can be generated from Schema files, but the code to set up a communication over HTTP, JMS or other protocols, must be written by hand, as well as dispatching to the proper functional implementation. With WSDL all of the code is generated. Web Services still are in constant evolution, in which new or improved features are added. Since all major vendors provide these added features through their development tools and infrastructure software it is very easy to adapt these new features once needed and mature. For example, extensions such as ‘reliable transport’, security, transactions, load-balancing, processes etc. are already available, or are in the process of being standardized. Existing WSDL’s and Web Services can be extended with these features almost transparently to the application code; often it is just a matter of configuration. As noted before, WSDL documents describe possible SOAP (or web service) message exchanges, just like XML Schema describes possible XML documents. In a way it is fair to say that WSDL builds further upon XML Schema, adding notions as operations, operation parameters, interfaces grouping operations, and URL’s where these interface operations can be invoked. 
So when a Fund imports and uses a WSDL, it also has to import the related Schemas. In our approach we try to re-use maximally the existing XML Schema’s. In the end XML Schema will describe 80% of the message exchanges, leaving 20% for the WSDL’s. |