Working towards the next version of the SWIM Supporting Material

Page tree

Working towards the next version of the SWIM Supporting Material

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »


(plus) 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:

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

Error rendering macro 'viewpdf'

com.atlassian.confluence.macro.MacroExecutionException: com.atlassian.confluence.macro.MacroExecutionException: The viewfile macro is unable to locate the attachment "contextual_narrative.pdf" on this page

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:

  • Discover a SWIM Service; 
  • Consider using a SWIM Service;
    • from business points of view (=assess fitness for business purpose);
    • from operational points of view (=assess fitness for operational purpose);
    • from technical points of view (=assess technical feasibility);
  • Implement a consuming client (technical by nature).

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.

  • discover

A.2.1

In support of business decision-making, experts need to:

  • discover and compare services that would meet the business or operational objectives;
  • discover and compare services in relation to technical considerations; and
  • explore service description information to become aware of what the service delivers (e.g. through a SWIM registry);

To enable the above steps, service providers need to:

  • provide business information about the service to document service usage conditions; and
  • provide information about the service to document what the service delivers;
  • consider using

A.2.2

Assess fitness for business purpose

In support of operational decision-making, business experts need to:

  • evaluate the service in relation to the business objective.

To enable the above steps, service providers need to:

  • provide business information about the service.

Assess fitness for operational purpose

In support of operational decision-making, operational experts need to:

  • understand what the service delivers in relation to the operational context;
  • understand how the service works without being overloaded by technology details; and
  • evaluate the service in relation to the operational goals.

To enable the above steps, service providers need to:

  • provide operational information about the service to document the intended operational usage;
  • provide information about the service to document what the service delivers in relation to the operational context; and
  • provide information about how the service works without technology details.

Assess technical feasibility

In support of technical considerations and decision-making, technical experts need to:

  • evaluate the service in relation to technical feasibility; and
  • understand how the service interfaces must be implemented in technical systems in order to use the service.

To enable the above steps, service providers need to:

  • provide technical information about the service interfaces.
  • implement consuming client

A.2.3

In support of technical considerations and decision-making, technical experts need to:

  • understand how the service works at the technical level;
  • understand how to access the service; and
  • use machine-readable artefacts in support of prototyping and development.

To enable the above steps, service providers need to:

  • provide information which explains how the service works at the technical level;
  • provide information about how to access the service; and
  • provide machine-readable artefacts allowing the service consumer to use the service.
  • No labels