Working towards the next version of the SWIM Supporting Material
Working towards the next version of the SWIM Supporting Material
F2F: add more narrative here - e.g. organisation B plays the role of service provider. Much of the detail is available in the PDF narrative. Angelos: link to the definition of service consumer (other domains now call it service user). Miguel: make clear the link between our definitions and the ICAO SWIM Controlled Vocabulary. Walter: our definitions are those used in the specs. David: need help in understanding the direction of the arrows/verbs on them - text would help. Sam: link to the other specs - INFO and TI. Walter: may also bring in some materials being used to describe service life-cycle. Miguel: entry point that is integrated and users then go to where they need to go. Walter: could have a SWIM space on confluence.
Context of the specification
The context of the specifciation is the System Wide Information Management (SWIM) where 2 organisations exchange information using SWIM Services.
One organisation, Organisation B, which plays the role of service provider, makes a SWIM Service available for use by other organisations, such as Organisation A, which plays the role of service consumer.
Role of the specification
The role of the specification is summarised with the following diagram.
Description of the elements and the relationships appearing in the diagram:
- Organisation B is service provider of a running Service.
- The Service enables Information Exchange with service consumers, such as Organisation A.
- Organisation B, the service provider, produces a Service Description.
- The Service Description describes the running Service
- The Service Description follows the EUROCONTROL Specification for SWIM Service Description
- Organisation A, the service consumer, uses the Service Description.
- The Service Description enables Organisation A, the service consumer, to make good use of the Service.
Summary:
- A Service Description following the SWIM Service Description specification enables service consumers (Organisation A) to make good use of a Service made available by a service provider (Organisation B).
The following section provides an illustrated narrative about the role of the specification.
Narrative
Nominal service description usage scenario involving a service provider and a service consumer
Annex A - Purpose and use of service descriptions
The specification "ANNEX A – Service descriptions" introduces the purpose and use of service descriptions.
The text of the Annex is organised in such a way that there is a one-to-one mapping between the paragraphs of the text and elements in the narrative.
Below is a full of the Annex A mapped to the elements of the narrative.
element | reference | text |
---|---|---|
service description | A.1 §1-2 | A service description provides information about an implemented service. Providers and consumers of information services use a service description to exchange information about the capabilities of a specific implemented service. A well-formulated service description, built according to the present specifications, enables the unambiguous interpretation of the underlying information exchanges and service design, both inside and outside the European ATM Network context. |
service consumer | A.1 §3 | From the viewpoint of a service consumer, a service description is essential to obtain information about available services (e.g. in the context of iSWIM implementation). For each service, the consumer can find in the service description the information needed in order to use, or consider using, a service made available. This covers for example aspects such as the behaviour of the service, the information it provides, and any constraint attached to its use. Based on the information provided, a well-formulated service description enables a consumer to compare and assess services in terms of usefulness (e.g. fitness for purpose), usage (e.g. feasibility to implement) and quality. |
service provider | A.1 §4 | From the viewpoint of a service provider, a shared service description enables a service to be discoverable within the SWIM environment. Typically, an organisation publishes the service description information through a common registry. This provides an organisation with a means to expose the services it offers. Additionally, a well-defined and standardised way of describing a service might improve efficiency when exploring and comparing new services. |
use service description | A.2 | Depending on the context of the service consumer (e.g. business, operational or technical) the actual use of the service description may be different. Typically, the following usage contexts exist:
To meet the different expectations of service description information, the usage contexts listed above require different types of information about a service. They constitute the drivers for the requirements on the service description provided in this specification. The uses further described below are informative and are provided in order to highlight the main differences that could occur in terms of the information need of each type of expert using service description information. In reality, the differences explained may be distributed to the expert roles in different ways, depending on each organisation’s internal mode of operations. |
| A.2.1 | In support of business decision-making, experts need to:
To enable the above steps, service providers need to:
|
| A.2.2 | Assess fitness for business purpose In support of operational decision-making, business experts need to:
To enable the above steps, service providers need to:
Assess fitness for operational purpose In support of operational decision-making, operational experts need to:
To enable the above steps, service providers need to:
Assess technical feasibility In support of technical considerations and decision-making, technical experts need to:
To enable the above steps, service providers need to:
|
| A.2.3 | In support of technical considerations and decision-making, technical experts need to:
To enable the above steps, service providers need to:
|