| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
| Excerpt |
|---|
This page handles FAQ answers that are a work in progress. |
| Table of Contents |
|---|
Current FAQ
Updates
How do I define the list of topics for use in AMQP 1.0?
| Info |
|---|
| AMQP 1.0 technically has no subscription function (unlike 0.9). Subscription is handled by a broker. |
The role of topics is discussed in the TIYP supporting material. See, e.g., the "Subject-based Filtering" section in https://reference.swim.aero/technical-infrastructure/guidance-for-pub-sub-push-implementation.html that discusses topic enumerations and topic trees. The getTopics operation allows a service consumer to request the list of topics that are available to use in the subscription.
The topics themselves are URIs and should be based on the data that is exchanged. The need for semantic interoperability applies to the topic names. Therefore, it a best practice to use terms coming from a common semantic reference such as the a stardardised information exchange model, the AIRM and/or the list of service categories.
An example, using terms from the AIRM and the format used in the TIYP supporting material:
- /meteorology/precipitation
- /meteorology/precipitation/LFPG
| Info |
|---|
Domains may agree their own topic trees. For example, work on topic trees is occurring within the MET community. See https://wmo-teams.atlassian.net/wiki/spaces/WIS2/pages/167313674/WIS+2.0+Demonstration+Projects+Workshop. |
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).The functional scope also affects the granularity of the service. It is based on the operational needs of the service consumer. The service should be meaningful in the sense that it solves a whole problem for users and it is important to understand what that problem is e.g. is it to see all of the meteorological weather products or simply METARs.
| Info |
|---|
| See the Service Orientation Process knowledge article - in particular, the Identify and Design steps are useful in understanding users and their needs. |
| Info |
|---|
| The Interoperability Architecture, in particular, the organisational view is most relevant here. |
In Europe, some services that implement information exchanges are regulated, in the sense that they are listed in the EU Regulation - Common Project 1 and in the SESAR Deployment Programme. These may act as a guide in deciding the granularity of a new service. On the other hand, the list may act as input to a wider service orientation activity.
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: https://www.domain.com/url?variable=value&variable=value). 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 describe a service that uses GraphQL?
GraphQL is allowed using HTTP as the transport layer (i.e. using WS-Light binding in SWIM-SERV-018 TI Profile and bindings).
GraphQL is an example of message-oriented service design (as opposed to operation-oriented or resource-oriented service design). For message-oriented services, the essential part is describing the data schema. GraphQL services do this in its own schema language “GraphQL Schema Language”.
-TBD-