The Semantic Definition of Service Operations

The core of the BIAN industry standard is the semantic definition of the service operations offered and consumed by Service Domains. BIAN’s service operation specifications are intended to be ‘implementation agnostic’. A practical implication of this being that the specification must include nothing that relates to any possible technical implementation including communication protocols and the likely message exchange choreography. A Service Domain exchange that is captured in a BIAN service operation as a semantic description of information provided and information returned may in practice result in a broad range of physical exchanges not limited to:

• A simple one way delivery of information possibly with acknowledged receipt
• A simple request for information with a timely complete response
• An interactive dialogue to progressively narrow in on the required information by developing increasingly detailed query criteria
• Any of the above types of information request that results in a delayed response at some point in the future
• Any of the above types of exchange that results in the allocation of some facility or resource
• Any of the above types of exchange that is accompanied by the physical movement of goods or other resources.

When using the BIAN semantic service operations to specify an interface or service interaction it is clearly necessary to determine the operational characteristics of the many exchanges. This definition will be site specific and so only some limited possible properties are associated with the semantic service operation specification in the BIAN model as described below.

A general guideline used within BIAN when defining a Service Operation is that to be complete, the semantic description should capture all of the main business concepts involved in an unambiguous way such that a basic technical design can be developed without further business input (other than to provide clarification of detail). However, the BIAN description is only intended to describe the mainstream features of a service operation: those that are anticipated to apply in most deployments. So for example additional business input would be needed to specify unique/differentiating, advanced or location specific needs.

It is assumed that the BIAN designs will be referenced by individuals already expert or at least highly familiar with the subject area. The intention of the BIAN specification is to establish the business purpose of the service operations and to clarify the capability partitioning represented by the Service Domains. It is not the intention of the BIAN standard to provide an exhaustive specification and explanation (as might be expected in an educational or reference definition)

In time BIAN may augment the main/common Service Domain and service operation definitions to also capture optional extensions/specializations that could be relevant based on qualifications such as geopolitical context, scale/performance requirements and/or, level of sophistication. At this time BIAN’s focus is on defining only the mainstream features.

Some specializations may also be needed to deal with different implementation situations and technical environments considerations including the integration of major packages, proprietary standards and technologies. These implementation level details may be also recorded using some appropriate mechanism and linked or mapped back to the BIAN standard for reference and reuse purposes. However these particular specifications would not be part of the BIAN standard which is intended to remain implementation agnostic.

The structure of a BIAN service operation specification is explained in more detail in the second document of the BIAN ‘How-to Guide - Defining Content.’ The specification includes four primary design considerations/concepts outlined here:

1. Allowed types of exchange – while avoiding any implementation level specifics, BIAN has defined four types of exchange that characterize the operational dependency between the involved Service Domains:

1. A two-way exchange – the calling Service Domain expects the response immediately so that it can continue with its work.
2. A request with an anticipated delay in the response – the calling Service Domain anticipates that the response will take some time and so will continue with other work and monitor for the expected response.
3. A hand-off notification – the calling Service Domain once passing on the necessary detail has no further operational interest in what the called Service Domain does (no response expected other than possible acknowledgement of receipt).
4. Provision of previously subscribed-to updates – the calling Service Domain has at some point subscribed to updates from the called service domain.

2. Standard service operation parameter types – BIAN currently defines four types of information that can make up the payload of the call and response of the information exchange:

1. Identifier – defines the reference criteria that can be used to identify the target control record instance(s).
2. Depiction – represents the information details that are captured for each control record instance.
3. Control – defines ‘parameters’ governing the requested action (including the specification of reporting/query details).
4. Analysis – references any tracked/derived values associated with one or some combination of control record instances (as would be maintained by the called Service Domain.

In addition to the input and output parameter descriptions the Service Operation lists the allowed pre and post states of the Service Domain.

3. Service operation standard action terms – Because all Service Domains have a common operational structure (they implement the full life cycle of some pattern of behaviour on an instance of some type of asset) it is possible to define a standard collection of action terms that characterise the different possible types of service operation offered by a Service Domain.

Diagram 16: Action terms, descriptions and examples

Different selections of these standard action terms sensibly apply to the different functional patterns. A default mapping is shown in the summary table below. Note that the precise working of any specific Service Domain may require changes to this default mapping. Some action terms may not apply, other may be required and in some cases more specialized services can be defined. This is explained in more detail in How-to Guide – Developing Content.

Diagram 17: Action terms mapped to Functional Patterns

4. Conceptual business vocabulary – all of the terms used will in time be cross-referenced to BIAN’s evolving semantic business vocabulary. This includes standard terms used in service operation names and the concepts described in the service content description. (BIAN’s Business Vocabulary capability is described in the second document of the ‘How-to Guide’ series – Developing Content).