| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
| Table of Contents |
|---|
| Excerpt |
|---|
This |
- Promote a better understanding of service definitions
- Agree the expected content of a service definition
- Decide how to publish the expected content e.g. as a set of requirements.
Introduction
Service definitions (and other service related artefacts) are defined in the SWIM reference glossary.
It is important to disambiguate the terms as they share some commonalities in purpose and scope. It is possible to represent the commonalities and differences as follows:
in order to use a service
consider using a service
initial evaluation of the information service characteristics
Note: Service overviews "promote service discovery" according to the definition. However, this ability is not confined to service overviews. The SWIM Registry promotes service discovery.
Purpose and usage
The purpose of a service definition is to harmonize service implementations.
A service definition is produced by a community of interest. It contains a set of service metadata that defines a type of service.
| Info |
|---|
For example, a service definition may define an AMAN service. |
However, the service definition does not provide every piece of metadata about resulting service instances. For example, some service definitions will be technology agnostic and say nothing about the technologies to be used when implementing the service. The metadata is collected throughout the Service Orientation process. Much of it is collected by the end of the design step but it is possible to add more during the implementation step (typically technical aspects).
A service definition may be registered in the SWIM Registry. This will allow it to be discovered by service providers.
A service definition is used by service providers. The service instance they implement is a running service that conforms to the service definition. A service provider will produce a service description that completes the service metadata, expanding on that that was available in the service definition. The service description refers to the service definition ("standard") that was used as the basis for the service instance (see SWIM-SERV-010 Service standard reference).
Creation
Bottom-up, top-down, middle-out
The service orientation process is written with a classical top-down approach (e.g. starting from the list of identified services at https://www.eatmportal.eu/working/rnd/service-overview). However, it acknowledges that much of the activities can occur based on existing services that are in need of alignment. A service definition can therefore be the result of a community coming together to align a service that its members have already implemented. It is, of course, also possible to start the service orientation process somewhere in the middle and develop the justification for the services at the same time as implementing it.
The requirements on service definition have to take this into account.
Legacy to new
A service definition can be used as a part of the service lifecycle process to support the transition from a legacy (description) to new systems. The legacy can be "abstracted" into a definition that ensure the same operational needs are carried into the new system.
Content of a service definition
Service Definitions - minimum contentpage manages activities related to service definitions. |
| Info |
|---|
The relationships between service overviews, service definitions and service descriptions is discussed on the Artefacts to describe services page. |
| Table of Contents |
|---|
Specification
Current version
The current published version of the specification is available at SWIM Service Definition Specification v1.0. This is supported by SWIM Service Definition Handbook v1.0.
Future version
The table below records the changes that have been requested.
Request name | Description | Notes |
|---|---|---|
Simple example |
| |