Working towards the next version of the SWIM Supporting Material
Frequently Asked Questions about the implementation of the SWIM Service Description specification. Including direct link to the supporting material when applicable.
|Table of Contents|
How does a service description relate to a service level agreement?
The conformance checking for our service was by self-assessment. Is this correct? Is there a role for governance? What about supervisory authorities?
The conformance to the specifications is done by self-assessment. National supervisory authorities may be involved. EUROCONTROL is not involved.
How do I show compliance with Common Project 1 (CP1)?
The SESAR Deployment Programme (SDP) talks about the need for “concrete requirements that the service needs to fulfill to comply with”. The SWIM requirements are then detailed in a dedicated section (p130). This section is a good start for a compliance checklist but remember that the national supervisory authorities may have different requirements. It states:
How do I record the use of GRIB2 in my service?
This best practice covers how to detail the use of e.g. GRIB2 in the service description.
SWIM-SERV-260 Service interface protocols and data format
The selection of protocol and data format for this requirement must be consistent with the interface service binding selected in SWIM-SERV-250 SWIM TI Profile and interface bindings.
The selection is found in the TIYP Specification (see diagrams below).
SWIM-SERV-290 Information definition - minimum
The requirement expects the content of the service payload to be defined. It is here that the content of the GRIB2 file e.g. turbulence should be defined. However, GRIB2 is a standard owned and defined for the MET domain, not the Aviation MET domain. Therefore it is out of scope of the AIRM.
How do I define the list of topics for use in AMQP 1.0?
The need for harmonisation/guidance on topic trees is not unique to AMQP 1.0.
How do I decide on the granularity of a service?
It is difficult to provide an exact answer to this question because there are many factors that affect the granularity of the service.
Service granularity is related to the design principle of service composability which defines services in such a way that they can be used in a service composition. A service composition is an aggregation of services where many smaller (i.e. fine grained) services (the composition members) are combined together in a larger (coarse grained) service. Typically a composition member provides functionality to the other services in the service composition. An example to think of as service composition is a service that mashes up data from various domains to create integrated picture (e.g. combining aeronautical information with flight data).
Each of my service consumers has a dedicated endpoint. Is this described as one service with multiple endpoints or as different services?
This situation allows each service consumer to have the information customised to their needs. However, as the operational need and functionality of the service remains consistent, it is a best practice to deal with this as a single service.
The Service Metadata Schema for service descriptions makes the definition of at least an endpoint mandatory. Therefore, it is not possible to simply ignore the endpoint field. However, the schema does allow users to define multiple endpoints and you can also use parameterized URLs (to illustrate: ). The use of parameterized URLs is very common and can be a sensible solution to the problem described while fitting inside the current schema restrictions. The description of the endpoint can then be used to say that the parameters will be assigned to the consumer when a formal arrangement (such as a service level agreement) is agreed.
How do I document the HTTP error codes in my service description?
My service relies on the standard HTTP error codes. Is there a need to document them in the service description?
The Examples/Notes section of requirement SWIM-SERV-220 Service behaviour explains that error messages and error handling in general can be included in a model view (as part of SWIM-SERV-330 Model view). They are modelled as part of the detailed service behaviour.
However, it is possible to add an entry in the service behaviour section of a service description. For example:
Other error messages are documented in SWIM-SERV-280 Service messages.