Introduction¶

The model driven approach is chosen to describe exchange: this leads to describe exchange systems by means of abstract models which are named platform independent model (PIM), in which modelling of exchange features is done by describing interaction among systems and subsystems as exchange patterns (EP). These interactions implement system capabilities as features which fulfil exchange requirements requested by specific business scenarios which are used to describe specific uses of exchange.

Business scenarios and functional exchange profile¶

This document is based on business scenarios, i.e. a high-level description of the interactions that can exist within a system being analysed or between the system and external entities (called actors) in terms of business functions. Business scenarios are derived from application requirements on useful business information needed and on technical capabilities enabled by available technologies. FEPs are identified to ensure interoperable services with the restriction of determining one FEP per business scenario for a specific exchange pattern, which are abstract model of available technical platforms.

One business scenario can be supported by more then one FEP which can be enabled by several EP (Figure 2).

Figure 2 — Business scenario and Functional exchange profile

This version of the Technical Specification addresses the following business scenario:

• Information delivery
• Collaborative ITS services.

Other business scenarios can be developed in future versions using the same methodology.

Requirements, Feature and Exchange Patterns¶

Requirements can vary depending on data exchange applications, i.e. use cases to be fulfilled, so there are many reasons to consider or not any requirement based both on the gathering of data at supplier system and the usage of the delivered data in the client.

Requirements address the following items:

• Information provision,
• Communications,
• Security,
• Financial aspects.

Exchange is defined through enabling features which fulfils data exchange requirements.

Many possible technical exchange platform are possible, each of which can enable subset of requirements in different ways. To be interoperable a client and a supplier shall implement the same platform with the same pattern. Allowing a wide variety of possible exchange patterns, the best suitable for an use case application is chosen, in order to fulfils the needed set of requirements.

Based on the requirements of a specific business scenario selected for application use cases implementation, a set of appropriate exchange features shall be combined into a FEP.

The following schema in Figure 3 represent the domains of PIM and PSM introducing exchange pattern (EP) and FEP.

Figure 3 — Business scenario and Functional exchange profile

Business scenario: Information delivery¶

Overview

One of the most common applications of a data exchange system is the exchange of traffic and travel information between two nodes. In such a scenario, one node acts as the supplier of the information while the other acts as the intended receiver of that information, i.e. the client.

EXAMPLE: It is done by using the form of publications, e.g. in the European DATEX II.

The data delivery business scenario considers the actors as defined in Figure 4:

Figure 4 — General Data Delivery Business Scenario actors

The following Table provides the basic definitions for exchange:

Road and traffic information is gathered in a system which is named “Supplier System”. In case this information is needed by another system, named “Client System”, for any purpose, it has to be transferred among the two systems by the exchange environment.

The data delivery business scenario describes the exchange pattern and messages which are needed to be exchanged among supplier and client systems besides the underneath technology and exchange pattern. The purpose for which information is exchanged is not considered in this use case description.

As explained in the information delivery background in Annex F , any update of information status at the supplier system shall be replicated to the client system via information delivery. The main objective of information delivery is that information on the client system is updated exactly in the same way as it is in the supplier system without any difference in information values and semantics.

“Exchange message” is defined as the data structure in which the information is coded to transfer information in the exchange system from the supplier to the client.

Assuming Sc = Client status, Ss = Supplier status, exchange is a mean to have Sc equivalent to Ss,

Formally:

Ss >> Information >> Supplier >> Exchange Message >> Client >> Information >> Sc

i.e. Client System Status is updated in equivalent mode as Supplier System Status by means of Data Delivery Exchange Messages through Supplier and Client.

Information delivery business scenario scope is implemented by selected exchange features which enable this scope and other secondary requirements which are based on available features on considered platforms and patterns.

1. Supplier system characterisation
   • Shall provide data as input to the data exchange environment
   • Is mandatory for the information data delivery process
2. Data exchange environment
   • Shall be an environment supporting the exchange of information and data by means of messages
   • The supplier, of data exchange system, shall produce and transmit the messages (Notification)
   • The client, of data exchange system, should receive and process the messages
3. Client system characterisation
   • Shall receive traffic and travel related data from the data exchange environment
   • Can be either another system for further processing or a simple client for the content visualization, the purpose of information exchange is not considered to be relevant in information delivery business scenario
   • Is mandatory for the information data delivery process

Requirements

The normative Annex B provides a description of all requirements that can exist for specific Business Scenario including Information Delivery whether they are used in a particular functional exchangeprofile or not. All requirements are organised into groups based ontheir characteristics.

Data Delivery Exchange Pattern

For data delivery the concept of ”EP” is introduced, as well as PIM and FEP. These are defined as in Terms and definitions in the introduction.

Examples of exchange pattern are the GET method of HTTP, Pull, Push, PubSub, etc.

Once an exchange pattern and a selection of features (FEP) which can be implemented on this exchange pattern are set, a set of specification at PIM level for EP+FEP is well defined.

A PIM for EP+FEP that enables all mandatory requirements is a valid platform for the corresponding business case (information delivery or collaborative ITS services).

Specific Exchange Pattern Specification PIM included in this PIM part

In the following chapters PIM for Exchange Pattern/FEP will be described for the following platform:

• Snapshot Pull
• Snapshot Push
• Simple Push
• Stateful Push

The normative Annex E details the features of the main FEPs considered in this document for the corresponding exchange pattern.

Business scenario: Collaborative ITS Service¶

Overview

A service is any processing of data which enable a value to the data themselves.

In ITS fieald “ITS Services” can be considered as the processing of information to address specific requirement such as to manage traffic, deliver information.

“Collaborative ITS services” (CIS) are “ITS Services” which can be enabled by combing different “ITS Services” which are provided by several stakeholders which may have different roles (e.g. Traffic Management Centers, Traffic Information Centres, Service Providers).

CIS exchange specification explore user requirements and define common techniques to address them to implement collaborative “ITS services” by different centres. They are based on exchanging information to be processed by the different nodes and receiving the processing outcomes (feedback), giving a simple mechanism, upon which it could be possible to build more sophisticated workflows, enabling to coordinate operations distributed among many centres.

In CIS business scenario the exchange of information among centres is considered as a base mechanism to trigger specific processing and to provide services on this data, so the data exchange layer is to be considered as an “ITS services” enabler.

“ITS Services” description is out of the scope of this document: a detailed description of possible usage of CIS detailed in informative Annex G .

Example of “ITS Service” in the different “ITS domain” are:

• TIS: Traffic Information Services
  • Information Delivery
  • Allowed Channels
• TMS: Traffic Management Systems
  • Hard Shoulder Running
  • Dynamic Speed
  • Dynamic Lane Management
  • etc.
• F&L: Freight&Logistic
  • Secure Truck Parking
  • etc.

Data exchange enabling service request and feedback paradigm

The involved systems, which in data delivery had been considered as supplier and client, can be considered in this paradigm respectively as service requester and service provider.

At application level, for implementing a business case, such as management of TMP, workflow management is usually requested; this could be a simple workflow (one shot request and acceptancs or rejection) or a more complex one: complex workflow modelling at application level is out of the scope of this document. This document provides the essential tools as building blocks to implement such simple workflow to a raise service request and provide feedback as exchange of payload to be processed and processing results.

CIS enabling mechanism:

• Service request delivery from service requester to the involved service providers.
• Service feedback delivery from service provider to the relative service requester.

CIS main characteristics are as follows:

• collaborative: 2 to many systems interact to achieve a common objective by processing data and exchange processing results;
• CIS modelling consider using a set of “1 to n” exchange connections considering any single CIS triggering request as 1 service requester and 1 to many service providers so that any complex interaction can be considered a combination of single usages from multiple requesters;
• possible lock of resources at service provider sides which are to be managed at application or human operator level are not described in the document.

Requirements

The normative Annex B provides a description of all requirements that can exist for specific business scenario including Collaborative Information Services

Exchange Data Model¶

To implement some exchange features, such as session management or link monitoring, or security features, extra information is to be added to the informational (payload) content. This extra information, named exchange information, enables messages to convey information and data which are related to client and supplier status, identity, authorisation, etc.

Exchange information could be different among EP+FEP selection, but some common general information models are considered, which can be specialised to manage specific exchange pattern and PIM.

A general UML model for managing a minimum set of information for exchange is provided in Annex C

Data exchange features¶

Context Diagram

This document defines the features and rules that systems shall implement in order to be able to communicate in the traffic and travel data exchange world.

The context diagram below in Figure 5 shows the entities and the features specified in this document and which need to be addressed by the technical implementations. The diagram presents the features in different layers for communication, message rules and application:

• The “Application layer” is used for defining how using and implementing different business and application needs. This document describes the features to deal with how and when the information is published and made available, how subscriptions are managed, how to handle services and transactions. This layer defines the semantics of the communication.
• The “Messages Rules layer” defines the features and the rules used for the transport of the messages. This is the layer where the rules (protocol) are defined that enable different systems (suppliers and clients) to communicate and understand each other, i.e. for sending and receiving messages. This layer defines the syntax of the communication.
• The “Communication layer” deals with the support for communication between systems, and defines the protocols and services used by the data exchange applications, e.g. TCP/IP, security, web services. The communication layer deals with rules at the lowest level, i.e. the physical exchange. This layer provides solutions to the defined requirements and features although it is up to upper applications to define what protocols to use and how to use them. This layer defines the physical support for the communication.

The context diagram below (Figure 5) shows the topics broken up into boxes representing the exchange features and the relation with each layer.

Figure 5 - Context diagram

Features

The features that support the requirements defined by use cases specified in this document are detailed below:

1. The “Subscription contract”, detailed in the table below, supports all features related to the contract or agreement, such as:

   1. Contract and contract life cycle: a model and features that can be used for the support of the information of a subscription contract
   2. Catalogue: a model for handling catalogues;

   The subscription contract is optional and may include the following features:

   Features	Requirement Type	Requirement Name
   Contract	Information	Subscription
   		Client profiles
   		Filter handling
   Catalogue	Information	Catalogue exchange

2. The “Session” feature group, detailed in the table below, supports all features related to the establishment of a logical session.

   1. Session life cycle – features for managing the life cycle of a logical session (create, manage and terminate);
   2. Link Monitoring – features for link monitoring and control;

   The session feature group is optional and includes the following Features:

   Features	Requirement Type	Requirement Name
   Session life cycle	Communication	Error handling
   		Timeout management
   		Session
   Link Monitoring	Communication	Error handling
   		Timeout management
   		Full reliability
   		Link monitoring and control

3. The “Information management” handles the features related to the management of the information, includes features such as:

   1. “Operating modes”: features to specify what portion of the information shall be exchanged
   2. “Update methods”: features that let a data exchange system specify when the information should be exchanged
   3. “Lifecycle management”: features for handling the life cycle management of exchanged payload information for payload for which life cycle is applicable; a. Situation lifecycle management b. Filter handling
   4. “Support information processing”: feature for handling directives to process exchanged data and send feedback on processing outcomes.
   5. Distributed transaction: features for handling a transaction on several systems consistently, i.e. an operation is capable to keep data consistency among several systems based on operator undertaken actions. The information management group includes the following features:

   The “information management” group includes the features listed in the following table.

   Features	Requirement Type	Requirement Name
   Operating modes	Information	Reference datasets for different versions
   Update methods	Information	Full audit trail data delivery (all state changes)
   Lifecycle management	Information	Support for life cycle management
   Support Information Processing	Information	Support for information management
   		Support for feedback on information management
   Distributed transaction	Information	Distributed transaction
   		Distributed atomic transaction

4. The “data delivery” feature group supports all features to exchange data between the supplier and client. In the publish-subscribe pattern this feature group will support all related interfaces between the producer and the consumer; it supports features such as:

   1. Data delivery: features to delivery information by the supplier to the client on a push mode (direct delivery and fetched delivery);
   2. Data request: features to exchange information requested by the client;
   3. Large datasets: support the exchange messages with large volumes;
   4. Synchronisation: how to ensure data synchronisation between the systems that are communicating.

   The “data delivery” group includes features and requirements listed in the next table.

   Features	Requirement Type	Requirement Name
   Data delivery	Information	Extensibility
   	Communication	Delivery/response
   		Message sequence
   		Snapshot data delivery (last known state)
   		Exchange quality measures (ex. response timestamp)
   		On occurrence update
   		Periodic update
   	Security	Client identification
   		Supplier identification
   	Information	Incremental data delivery
   Data request	Information	Extensibility
   	Communication	Request/response
   		Message sequence
   		Snapshot data delivery (last known state)
   		Exchange quality measures (ex. response timestamp)
   		On occurrence update
   		Periodic update
   	Security	Client identification
   		Supplier identification
   Large datasets handling	Information	Data delivered as soon as possible
   		Delayed delivery
   		Multi-part data delivery
   Synchronisation	Information	Synchronisation
   	Communication	With state supplier
   		Failed data recovery

5. Communication – Handles all features related to the protocol (close to the physical layer). It is used by the application for the message transport.

   1. Communication – describe the protocols of communication that can be used;
   2. Security – describe how security features can be implemented;
   3. Compression – how data compression can be used while transmitting data.
   4. Bidirectional communication – enable client to send back data to supplier as feedback on data exchanged and processing status of data based on supplier processing directive in Collaborative ITS Services The communication function is responsible for implementing the following Features:

   The communication function is responsible for implementing the following features:

   Features	Requirement Type	Requirement Name
   Security	Security	Security (data)
   		Integrity
   		Confidentiality
   		State the intended recipient
   		Client authentication
   		Supplier authentication
   		Client authorization
   		Non-repudiation
   Compression	Communication	Compression
   Communication	Communication	Timely responses
   Bidirectional communication	Communication	Bidirectional communication

Exchange Pattern modelling using UML¶

Exchange patterns which enables features for selected FEP can be described by use of some UML diagrams which describe which actors are involved in the exchange, and the specific interactions among them which enable the features themselves.

Exchange system description assumes external systems like TCC and TMC are external to exchange and exchange agents are the actors which may implement the exchange role of client, supplier, service requester or service provider as defined in the business case.

The Figure 6 describes the main exchange involved actors as well as other interacting actor external to exchange.

Figure 6 — Exchange actors

Systems (e.g. TCC or TMC system) may act both as client or supplier and for exchange purposes, systems need to interact with the exchange agent, of the same client or supplier type, which realise a system interface enabling the exchange features.

Based on multiple option for a system to be a client or supplier for Data Delivery, or a Service Requester or Service Provider for Collaborative ITS Services business scenario, the relative system and interfaces can specialise. Figure 7 and Figure 9 shows the exchange agent and interfaces specialisation respectively for data delivery

Figure 7 — Data Delivery Exchange actors definitions

Figure 8 — Communication: Features and requirements

Figure 9 — CIS Exchange agents definition

Figure 10 — CIS Exchange systems, agents and interfaces

This system, exchange agents and interfaces classes will be used in any of the FEP+EP specification descriptions in the following clauses to describe the provided interfaces and interactions. Each of exchange interface realisation will be implemented as a specific specialisation for its FEP+EP, e.g. Snapshot Push will have its specific “snapshot push” supplier interface”, i.e. the “Snapshot Push Client Interface”, which will be described as a specialisation of the exchange snapshot push client interface. The modelling for a snapshot push client system and its Exchange agent and interface is shown in Figure 11.

Figure 11 — Sample of “Snapshot Push” client system and its Exchange agent and interface

The relevant Communication Diagrams will be introduced in the FEP+EP descriptions in the following clauses. In the description of the interactions among exchange systems and subsystems UML Sequence Diagrams will be used. Interactions among actors and their interfaces are described using the actor themselves, the realised specialised interfaces are not mentioned for schema understanding convenience. Figure 12 is an example of provided Sequence Diagram.

Figure 12 — CIS Exchange actors

State Diagrams can be used as well to specify specific status of exchange operation which will lead to specific interfaces behaviours such as return messages definition and specific interaction provided (e.g. synchronisation, synchronisation request). State Diagram are not needed for understanding in simple cases such as stateless FEP+EP so they will not be described in some FEP+EP descriptions.

Overview¶

The “Snapshot Pull” EP+FEP at PIM level is based on information retrieval by a client from a supplier which delivers a snapshot of information, i.e. all currently available information content, to the client. It can be implemented in several platforms: some examples are XML retrieval of generated XML files by http/get, or supplier exposing a SOAP Web Service method (e.g. named “PULL”), from which currently available data is retrieved by the client.

This “Snapshot Pull” does not manage session life cycle and link monitoring requirements, as well as synchronisation. This feature and related requirements are not considered in this pattern, synchronisation is not needed as implicit when delivering snapshots of currently available information content.

To describe the Snapshot Pull EP+FEP at PIM level all features are described in a general abstract format, independently from the specific technology platform this model will be implemented with (e.g. http/get XML, WebService).

Exchange Pattern Messages Definition¶

Overall presentation

The information delivery business scenario description and definition states that data exchange is needed to align the information kept by the supplier system into the client system. For this purpose an exchange systems is used which provides tools enabling messages generation and their transfer between supplier and client.

Figure 13 — Snapshot Pull Exchange actors

The “Snapshot Pull” exchange pattern is described in the following subclauses.

Basic Exchange Pattern

In a snapshot pull contex the supplier exchange system provides a mechanism to retrieve currently available and valid data (i.e. a snapshot of information) from action taken at client side, which will invoke this specific mechanism offered by the supplier.

In the context of the “Snapshot Pull” FEP +EP framework, to enable interoperability among client and supplier, all rules defined in this clause apply.

A snapshot pull supplier exchange system shall realise a snapshot pull supplier interface wich provides a ” ” method which implements the snapshot pull mechanism.

A snapshot pull client exchange system shall realise a snapshot pull client interface which invokes the “pullSnapshotData” Method provided by the snapshot pull supplier interface to retrieve snapshot data.

Figure 14 shows the communication diagram for Snapshot Pull FEP + EP.

In this FEP+EP framework the client “pulls” messages from the supplier.

The client shall deliver in the pull request no information to the supplier

The Supplier shall retun the client pull request by delivering a “MessageContainer” information which includes ExchangeInformation.

Figure 14 — Snapshot Pull exchange subsystems, interface interactions and methods

The client takes the initiative to retrieve the data based on application level requirements which determine the needed exchange OPERATING mode (e.g. on occurrence, condition triggered or periodic).

Relevant Exchange Information in Exchange Data Model

No exchange information is needed in this pattern to implement data delivery features. Nevertheless “Basic Exchange Data Model” has been provided to allow the implementation to deliver more than one payload content on the same message and further information to allow managing extra features not required by the Snapshot Pull exchange.

A “MessageContainer” instance should be retrieved using the basic exchange data model as reported in Figure 14, alternatively a payload may be retrieved without any further information.

Information related to Exchange that should be managed to make application development easier are fully described in basic exchange data model.

Exchange Context information related are:

• Supplier related Information
  • Requirement: Supplier identification.

Dynamic Information information related are:

• Exchange DynamicInformation (provided both by the client and the supplier) wraps information such as exchangeStatus (“online”, “offline”, “undefined”, etc.)
• Message Generation timestamp information
  • Requirement: reliable Information.

Exchange Messages

• Payload Message
  • Payload messages should be delivered wrapped into a container (see Basic Exchange Data Model Annex C ) with Exchange data.
  • Payload Messages contain Payload Update Timestamp which may be used to understand when payload has been created/updated for error management and processing saving.

State Diagrams¶

State diagram are not needed and not developed for stateless FEP+EP as Snapshot Pull.

Features Implementation Description¶

Overview

This subclause provides a description and the corresponding specification for each feature identified in the context diagram, according to the Snapshot Pull exchange architecture. The following features are specified:

• Subscription contract;
• Subscription (also known as session);
• Information Management;
• Data delivery;
• Communication/Protocol.

Subscription Contract

Contract

Managed offline, not automated. It assumes information for controls to be implemented in Client to assess the identity of supplier and authenticate the Supplier request in messages exchange.

Catalogue

Managed offline, not automated.

Session

Session Life Cycle

No Session is managed for the current EP+FEP.

Link Monitoring

Link monitoring is not managed for the current EP+FEP.

Information Management

Operating Modes

Available operating mode for client Pull is Periodic, or On Occurrence (i.e. a condition triggered based on client). Pull-exchange based on client-side conditions.

Update Methods

Available updated method is Snapshot, i.e. retrieval of only currently valid data.

Lifecycle Management

Currently available information is included in the payload at a supplier system to prepare message delivery. It can be done at time-out on a cycle basis or at specific triggering condition as “data updated” condition.

For life cycle management information, a snapshot includes all active information, outdated information is not delivered in content.

For sampled information the snapshot information contains last sampled data available at supplier site.

Whenever a condition is raised the supplier system triggers it to the supplier to manage the creation of a payload pull delivery message (see Figure 15).

Figure 15 — Snapshot Pull Payload delivery creation: information management at supplier side

Information management for Snapshot Pull at client side is implemented as follows: when a client gets a snapshot of the last updated/created items it includes all valide active information: information which had been delivered and which is not available in the last delivered payload shall not be considere after last devlivery, i.e. it had been invalidated either as closed or cancelled information.

Data Delivery

Data delivery

The sequence Diagram for Data Delivery is as follows

Figure 16 — Snapshot Pull sequence diagram for data retrieval: implicit data delivery

When a pullSnapshotData request is triggered from the client to the interface method on supplier SnapshotPull interface, the corresponding snapshot payload(s) available shall be delivered as return message by the supplier enclosed in a MessageContainer.

..note:: Depending on implementation (e.g. http /get of XML static files generated at supplier side) the payload message is generated by the supplier based on conditions which are only managed by the supplier (e.g. event update or data gathered at the supplier side). In these cases, extra information can be available to implement some optimisation such as bandwidth saving by not transferring the same data in case no update had been generated. This aspects will be describe when applicable for PSM mapping.

..note:: ExchangeInformation delivered in the return message by the supplier may contain any information which can be used to inform the client about client request processing which may be implemented in an optional pullRequest check. A processing for delivery based on client may be implemented by the supplier based on ExchangeInformation and offline subscription agreements. Any processing description for payload delivery based on client which can be implemented on supplier side based on any subscription agreement among client and supplier, are out of scope of this FEP+EP specification.

Data request

Not implemented in this pattern

Large datasets handling

Not described in this pattern at PIM Level ( it may be implemented at PSM level see Optimisation Section).

Synchronisation

Implicit synchronisation is available as only currently current available elements are retrieved by Snapshot Pull

Self-Description

Handshake is not available

Communication

Communication features are implemented at PSM level, they are relevant for the specific platform chosen on which the exchange pattern will be implemented (e.g. http/XML, Web Services SOAP, REST, etc.).

General Optimisation Issues

Some exchange pattern features of any context diagrams features groups (e.g. information management, data delivery etc.) allow the implementation of general optimisation such as processing saving and bandwith.

Payload timestamp information is available for client-side processing optimisation made at the application level.

Pull message may be generated for all clients reducing processing resources at the supplier-side.

No extra optimisation issues are considered in this EP+FEP.

Overview¶

The “Snapshot Push” exchange pattern / FEP at PIM level is based on pushing information by the supplier to the client delivering a snapshot of information, i.e. all currently available information content, to the client. This exchange pattern can be implemented in several platforms: some examples are XML delivering of generated XML files by http/post, or a client exposing a SOAP web service method (e.g. named “PUSH”) when currently available data can be sent by the supplier to the client.

This “Snapshot Push” does not manage session life cycle and link monitoring requirements, as well as synchronisation, these features and related requirements are not considered in this pattern. Synchronisation is not needed as implicit by snapshot delivering of currently available information content.

To describe Snapshot Push exchange pattern/FEP at PIM level all features are described in a general abstract format, independently from the specific technology platform in which this model will be implemented (e.g. http/get XML, WebService).

Exchange Pattern Messages Definition¶

Overall presentation

The information delivery business scenario description and definition imply that data exchange is needed to align the information kept by the supplier system into the client system; for this purpose, an exchange system is used which provides tools enabling message generation and their transfer between supplier and client (see Figure 17).

Figure 17 — Snapshot Push Exchange actors

The “Snapshot Push” exchange pattern can be described by the following behaviours

Basic Exchange Pattern

In a snapshot push context the client provides a mechanism to receive data from action taken at a supplier site invoking specific resources / methods offered by the client.

The snapshot push client provides a mechanism to the snapshot push supplier to push currently available data, also called “snapshot” of information, i.e. current information at supplier system or last retrieved information for sampled data (see Annex F ).

In the context of the “Snapshot Push” FEP +EP framework, to enable interoperability among client and supplier, all rules defined in this clause apply.

A snapshot push Client exchange system SHALL realise a snapshot push client interface wich provides a putSnapshotData method.

A snapshot push supplier exchange system SHALL realise a snapshot push Supplier interface which invokes the putSnapshotData Method provided by the snapshot push Client interface to deliver snapshot data.

Figure 18 shows the communication diagram for Snapshot Push FEP + EP.

In this FEP+EP framework the supplier “pushes” messages to the client.

The client shall acknowledge the received message by a return information to the supplier. This return information shall be coded as ExchangeInformation.

The supplier takes the initiative to deliver the data based on application level requirements which determine the needed exchange operating mode (e.g. on occurrence or periodic).

Figure 18 — Snapshot Push Exchange subsystems, interfaces interactions and methods

Relevant Exchange Information in Exchange Data Model

No extra exchange No extra exchange information is needed in this pattern to implement any described features.

Basic exchange data model has been provided to allow the implementation to deliver more payload contents in the same message and further information to allow managing some extra features not required by the basic “Snapshot Push” exchange. The usage of the exchange data model wrapping is for harmonisation with other exchange patterns such as “Simple Push” or “Stateful Push”.

A container should be retrieved using basic exchange data model as reported in the previous figure, alternatively a payload may be delivered.

An ExchangeInformation is returned to convey information about exchange operation and connection status.

Exchange Context information related are:

• Supplier related Information
  • Requirement: Supplier identification.
• Client related Information
  • Requirement: Client identification.

Dynamic Information information related are:

• Exchange DynamicInformation (provided both by the client and the supplier) wraps information such as exchangeStatus (“Success”, “Fail”, “Close Session Request”, “Snapshot Synchronisation Request”)
• Message Generation timestamp information
  • Requirement: timely, reliable Information, session management.

Exchange Messages

• Payload Message
  • Simple payload messages may be exchanged within this FEP+EP.
  • Payload messages should be delivered wrapped into a container (see Basic Exchange Data Model Annex C ) with exchange data.
  • Payload Messages contain payload update timestamp which may be used to understand when payload has been updated for error management and processing saving.

State Diagrams¶

State diagram are not needed and not developed for stateless FEP+EP as Snapshot Push.

Features Implementation Description¶

This subclause provides a description and the corresponding specification for each feature identified in the context diagram, according to the Snapshot Pull exchange architecture. The following features are specified:

• Subscription contract
• Subscription (also known as session)
• Information Management
• Data delivery
• Communication/Protocol

Subscription Contract

Contract

Managed offline, not automated. It assumes information for controls to be implemented in client to assess the identity of supplier and authenticate the supplier request in messages exchange.

Catalogue

Managed offline, not automated.

Session

Session Life Cycle

No Session is managed for the current EP+FEP.

Link Monitoring

Link monitoring is not managed for the current EP+FEP.

Information Management

Operating Modes

Available operating mode for Snapshot Push is Periodic or On Occurrence (i.e. Condition Triggered based on supplier) Push based on supplier-side conditions.

Update Methods

Available updated method is Snapshot, i.e. retrieval of only currently valid data.

Lifecycle Management

Currently available information is included in the payload at supplier system to prepare message delivery; this can be done at time-out on a cycle basis or at specific triggering condition as “data updated” condition.

For life cycle management information, snapshots include all active information, outdated information is not delivered in content.

For sampled information the snapshot information contains last sampled data available at supplier site.

Information management for Snapshot Push is implemented as follows: when client gets snapshot of last updated/created items including all active items, it has to check for information which has been removed from payload to deduce it had been invalidated (i.e. closed or cancelled).

Data Delivery

Data delivery

For all clients which have an active subscription, whenever a payload delivery condition is triggered, the supplier system shall manage the creation of a payload push message in a MessageContainer and shall deliver it by its SnapshotPush supplier interface to the corresponding snapshoPush method available via the SnapshotPush client interfaced.

Figure 19 illustrates the sequence diagrams which describes the interaction amont exchange supplier and its clients.

Figure 19 — Snapshot Push Sequence Diagram Information management at supplier side

Information Management for Snapshot Push may be implemented as follows: when client gets snapshot of last updated/created items including all active items, it has to check for information which has been removed from payload to imply it had been invalidated (i.e. closed or cancelled)

The client may verify the message delivered by the supplier and shall return an ExchangeInformation message to the supplier with information back to the supplier about the delivered message, i.e. return status and exchange status defined in basic exchange data model, which may be processed by the supplier to implemente optional exchange checks.

Data request

Not implemented in this pattern

Large datasets handling

Not described in this pattern at PIM Level. May be implemented at PSM level (see optimisation subclause).

Synchronisation

Implicit synchronisation is available as only currently current available elements are retrieved by Snapshot Push.

Self-Description

Handshake is not available

Communication

Communication features are implemented at PSM level, they are relevant for the specific platform chosen on which the exchange pattern will be implemented (e.g. http/XML, Web Services SOAP, REST, etc.).

General optimisation issues

Some exchange pattern features of any context diagrams features groups (e.g. information management, data delivery etc.) allow the implementation of general optimisation such as processing saving and bandwith.

Payload timestamp information is available for client-side processing optimisation made at the application level.

Push message may be generated for all clients reducing processing resources at the supplier-side.

No extra optimisation issues are considered in this EP+FEP.

Overview¶

The “Simple Push” exchange pattern / FEP at PIM level is based on information messages sent or pushed by the supplier to a client. It can be implemented in several platforms: some examples are push of generated XML content by http/post, or client providing a SOAP WebService method “push” by which data can be provided by the supplier to the client.

This “Simple Push” adds extra features to the basic Snapshot Push exchange pattern to manage link monitoring, as well as synchronisation/realignment in case of communication lacks or system maintenance. This mechanism will be detailed at PIM level in the following subclauses.

To describe the exchange pattern/FEP at PIM level all features are described in a general abstract format, independently from the specific technology platform in which this model will be implemented. (e.g. http/get XML, WebService).

Exchange Pattern Messages Definition¶

Overall Presentation

Information delivery business scenario description and definition state that data exchange is needed to align the information kept by the supplier system into the client system; for this purpose, an exchange system is used which provides tools enabling messages generation and their transfer between a supplier and a client (Figure 20).

Figure 20 — Simple Push Exchange actors

The “Simple Push” exchange pattern can be described by the following subclauses

Basic Exchange Pattern

In a simple push context, the client provides a mechanism to receive data from action taken at a supplier site, invoking specific resources / methods offered by the client.

Therefore, the supplier logically “pushes” messages to the client. The client shall acknowledge what is received by a return exchange information to the supplier. This exchange information return message is available to bring information back from the client to the supplier, such as SessionId, failure, success, snapshot synchronisation request. Return message information is logically described in this PIM, while implementation will be defined at PSM level.

The simple push client provides two mechanism to the simple push supplier to push data:

• a “push” method is intended to push “available data” which had not yet been delivered to the client, based on some supplier side logic and status,
• a “snapshot push” is intended to push “all currently available data”, also called “snapshot” of information, i.e. current information at supplier system or last retrieved information for sampled data (see Annex F ). this snapshot push method is used for synchronisation purposes among client and supplier.

Besides these push data delivery methods the simple push client also provides a “keep alive” method to implement link monitoring capabilities among client and supplier, the keep alive method is used from the supplier to advise the client when no information updates are to be delivered, so the supplier delivers a “keep alive” message to check and enable the client to check that echange systems and network connection are available, despite the supplier doesn’t need to exchange payload content. “Keep Alive messaged are delivered by the supplier to the client, according a time interval which is defined among them.

In the context of this “Simple Push” FEP +EP framework, to enable interoperability among client and supplier, all rules defined in this clause apply.

Any simple push client exchange system SHALL realise a simple push client interface wich provides a putSnapshotData, a putData and a keepalive method.

Any simple push supplier exchange system SHALL realise a simple push supplier interface which can invoke the putSnapshotData, putData, keepAlive methods provided by the simple push Client interface to deliver data or snapshot data and information to implement link monitoring.

Figure 21 shows the communication diagram for simple push FEP + EP.

In this FEP+EP framework the supplier “pushes” messages to the client.

The client shall acknowledge the received message by a return information to the supplier. This return information shall be coded as ExchangeInformation.

Figure 21 — Simple Push exchange subsystems, interface interactions and methods

The supplier takes the initiative to push the data under the following conditions:

• On Occurrence Push: as soon as an information is updated at the Supplier Systems, this condition triggers the Supplier to send push data to align to the Client to update the Client System as soon as possible after this update.
• Periodic Push: at predefined time interval the Suppliers start an exchange based on Client and Supplier agreement (subscription contract)
• a Snapshot Synchronisation with all the currently available content snapshot in case a snapshot alignment feature is needed or requested by client.
• Response to a Snapshot Synchronisation request: one Snapshot alignment can also be acknowledged to the client for internal system need / maintenance / debug, it may be requested by the Client via any Return Messages, i.e. wrapped in returned Exchange Information.

Relevant Exchange Information from Exchange Data Model

Overview

Basic exchange data model has been provided to allow the implementation to deliver more payload contents on the same message and further information to allow managing extra features not required by the Simple Push exchange.

For interoperability convenience the exchange data model wrapping shall be managed in this exchange.

A payload shall be pushed to a client using basic exchange data model as reported in the previous figure.

An ExchangeInformation shall be returned from putData to convey information about exchange operation and connection status.

Exchange Information

Information related to Exchange that should be managed to make application development easier are fully described in basic exchange data model.

Exchange Context information related are:

• Supplier related Information
  • Requirement: Supplier identification.
• Client related information
  • Requirement: Client identification.

Dynamic Information information related are:

• Exchange DynamicInformation (provided both by the client and the supplier) wraps information such as exchangeStatus (“Success”, “Fail”, “Close Session Request”, “Snapshot Synchronisation Request”), and SessionID
  • Requirement: Session management, Link monitoring.
• Message Generation timestamp information
  • Requirement: timely, reliable information, session management

List of exchanged Messages

Different Messages or Supplier / Client interactions (invoked method) are to be exchanged in Simple Push which are needed to manage Synchronisation, Payload Exchange, Link Monitoring. These are formally contained in Pushed Messages to Client from Supplier or in Return Messages from Client to Supplier.

State diagrams¶

The supplier initiates the communication and is made aware of the client status based on the client return response to the supplier.

The following diagram (Figure 22) describes the client status as monitored and managed by the supplier.

Figure 22 – Supplier Side Simple Push State Diagram

The following diagram (Figure 23) describes the supplier status as monitored and managed by the client.

Figure 23 — Client-side Simple Push State Diagram

Special management in initialisation and termination of Push process is to consider at the application level in supplier and client systems.

Features Implementation Description¶

This subclause provides a description and the corresponding specification for each feature identified in the context diagram, according to the Publish-Subscribe data exchange architecture. The following features are specified:

• Subscription contract;
• Subscription (also known as session);
• Information Management;
• Data delivery;
• Communication/Protocol.

Subscription Contract

Contract

Managed offline, not automated. It assumes information for controls to be implemented in Client to assess the identity of supplier and authenticate the supplier request in messages exchange.

Catalogue

Managed offline, not automated.

Session

Session Life Cycle

No Session is managed for the current EP+FEP.

Link Monitoring

Link monitoring is done by Payload Push and KeepAlive. When data is available a payload Push is exchanged which also informs client and supplier about the session and systems status: Push received from supplier on client side and return of push on payload push on supplier side guarantee the network is available and the systems are up and running.

When no data is available at supplier and a time-out has expired a KeepAlive message is exchanged to check network and system availability.

In case payload push or KeepAlive fails or times out, the supplier assumes the client is offline and keeps trace of its status for any management purposes at the supplier system side (for delivery retry mechanism is to be described at PSM level defining a logical push mapping iterated for a maximum number of times) (Figure 24).

Figure 24 - Simple Push sequence diagram for link monitoring and data delivery

Information Management

Operating Modes

Available operating mode for Simple Push is “Periodic”, or “On Occurrence” (i.e. condition is triggered based on supplier) push based on supplier-side conditions.

Description of operating modes is done at a general PIM level; no extra details are needed in this subclause for PIM/Exchange Pattern / FEP.

A Payload Push condition is triggered based on the agreed operating mode defined at subscription among client and supplier.

Update Methods

Available updated methods are: Snapshot, Single Element Update, All element update.

All updates available are conveyed in a payload publication push message.

Description of update methods is done at PIM level; no extra details are needed in this subclause for PIM/exchange pattern / FEP.

Lifecycle Management

Description of life cycle management is done at PIM level.

Life cycle management to exchange data between client and supplier is embedded with the operating mode and update method chosen at subscription contract.

Push delivery method allows conveying information from supplier to client as two different pieces of information.

Sampled data may be conveyed as Periodic or On Occurrence push of a snapshot payload containing all current active data or last collected data.

A Single/All Element updated push can be done for any operating mode as well with On Occurrence or Periodic Push.

Data Delivery

Data delivery

Based on sequence diagram described in Figure 24, the supplier after initialisation starts sending push information to a client: in case of stateful information delivery and based on the possibly agreed conditions of the subscription contract, e.g. it manages a snapshot push whenever it has no historical information about client status, deriving it is the first connection ever and a Snapshot Push is needed to align the client system when it is not the first time the supplier sends to the client normal payload push data, but the client for internal system needs can also require for snapshot push data by its return status.

After initialisation ready data condition at the supplier system side triggers a payload push delivery.

A periodic push condition is also possible based on contract agreement between supplier and client.

See sequence diagram at link monitoring life cycle for all messaging details.

Data request

Not fully implemented in this pattern.

A snapshot synchronisation request can be managed in the client return data, by the return status described in the “Basix Exchange Data Model” by returnStatus set as snapshotSynchronisationRequest.

This feature implementation is not mandatory in this FEP, agreement to manage among client and supplier are needed to enable full interoperability.

Large datasets handling

Not fully implemented in this pattern.

A multi-part data delivery can be optionally implemented by supplier by setting in the delivered message within exchange “Dynamic Information” setting the completedPayload as false, as described in Basic Exchante Data Model, it will inform the client one or more subsequent message will be delivered to complete the payload information, until the attribute completedPayload will be set as true.

This feature implementation is not mandatory in this FEP, agreement to manage among client and supplier are needed to enable full interoperability.

Synchronisation

Snapshot synchronisation and delta synchronisation are available in Simple Push.

Snapshot synchronisation is optionally managed at first connection with a client or under client request. In all other cases a Simple Push is delivered based on supplier site data available and conditions.

Self-Description

Handshake is not available

Communication

Communication features are implemented at PSM level, they are relevant to the specific Platform chosen on which the Exchange pattern will be implemented (e.g. http/XML, Web Services SOAP, REST).

General optimisation issues

Some exchange pattern features of any context diagrams features groups (e.g. information management, data delivery etc.) allow the implementation of general optimisation such as processing saving and bandwith.

Payload timestamp information is available for client-side processing optimisation made at the application level.

Snapshot Push messages may be generated for all clients reducing processing resources at the supplier-side.

No extra optimisation issues are considered in this EP+FEP.

Overview¶

Stateful Push Exchange Pattern / FEP at PIM level is based on information messages sent or pushed by the Supplier to the Client as may be implemented in several platform: some examples are push of generated XML content by http/post, or Client providing a SOAP WebService method “push” by which data can be provided by the Supplier to the Client.

This “Stateful Push” add extra features to the basic Snapshot Push exchange pattern to manage Session Lifecycle and Link Monitoring, as well as synchronisation/realignment in case of communication lacks or system maintenance. This mechanism will be fully explained at PIM level in the following sections.

To describe the Exchange Pattern/FEP at PIM Level all features are described in a general abstract format, independently from the specific technology platform in which this model will be implemented. (e.g. http/get XML, WebService)

Exchange Pattern Messages Definition¶

Overall presentation

Information delivery business scenario description and definition state that data exchange is needed to align the information kept by the supplier system into the client system; for this purpose, an exchange system is used which provides tools enabling messages generation and their transfer between a supplier and a client (Figure 25).

Figure 25 — Stateful Push Exchange actors

The “Stateful Push” exchange pattern is described in the following subclauses.

Basic Exchange Pattern

In a stateful push context, the client provides a mechanism to receive data from an action taken at the supplier site invoking specific resources / methods offered by the client.

Therefore, the supplier logically “pushes” messages to the client. The client shall acknowledge what is received by a return exchange information to the supplier. This exchange information return message is available to bring information back from the client to the supplier, such as SessionId, failure, success, snapshot synchronisation request. Return message information is logically described in this PIM, while implementation will be defined at PSM level.

As in “Simple Push”, the “Stateful Push” client provides two mechanism to the “Stateful Push” supplier to push data:

• a “push” method is intended to push “available data” which had not yet been delivered to the client, based on some supplier side logic and status,
• a “snapshot push” is intended to push “all currently available data”, also called “snapshot” of information, i.e. current information at supplier system or last retrieved information for sampled data (see Annex F ). This “snapshot push” method is used for synchronisation purposes among client and supplier.

Besides “push” data delivery methods the simple push client also provides a “keep alive” method to implement link monitoring capabilities among client and supplier, the keep alive method is used from the supplier to advise the client when no information updates are to be delivered, so the supplier delivers a “keep alive” message to check and enable the client to check that exchange systems and network connection are available, despite the supplier doesn’t need to exchange payload content. “Keep Alive” messages are delivered by the supplier to the client, according a time interval which is defined among them.

“Stateful Push” session management methods are available to implement session management features; such methods, namely openSession and closeSession usage which are used to define dynamic exchange information context to enable session management exchange features.

In the context of this “Stateful Push” FEP+EP framework, to enable interoperability among client and supplier, all rules defined in this clause apply.

Any stateful push client exchange system SHALL realise a stateful push client interface wich provides a putSnapshotData, a putData, an openSession, a closeSession mehod and a keepalive method.

Any stateful push supplier exchange system SHALL realise a stateful push supplier interface which can invoke the putSnapshotData, putData, openSession, closeSession and keepAlive methods provided by the stateful push Client interface to deliver data or snapshot data and information to implement link monitoring and session management.

Figure 26 shows the communication diagram for simple push FEP + EP.

In this FEP+EP framework the supplier “pushes” messages to the client.

The client shall acknowledge the received message by a return information to the supplier. This return information shall be coded as ExchangeInformation.

Figure 26 — Stateful Push Exchange subsystems and interfaces interactions and method

The supplier takes the initiative to push the data, or the snapshot data, under the following conditions:

• On occurrence push: as soon as an information is updated at the supplier systems, this condition triggers the exchange supplier to manage an alignment to the exchange client to update the client system as soon as possible after this update.
• Periodic push: at predefined time interval the supplier starts an exchange based on client and supplier agreement (subscription contract).
• A snapshot synchronisation with the whole currently available content snapshot at exchange initialitation, e.g. the first time data are exchanged among supplier and client.
  • First session initialisation: a global snapshot alignment is needed to convey all currently valid data at the first connection of exchange.
  • Session initialisation: after a session had been created the client shall be aligned with an incremental delta synchronisation when a partial update feature is enabled, delivering all updated content since last exchange, or with a global synchronisation with all the current active content in case the snapshot alignment feature is enabled (this may also depend on specific payload depending on the agreement between client and supplier or contract).
• Response to a snapshot synchronisation request: one snapshot alignment may also be transmitted to the client for internal system needs/maintenance/debug, it can be requested by the client via any return messages, i.e. as a specific return value in returned exchange information.

Relevant exchange information from exchange data model

Basic exchange data model has been provided to allow an implementation that delivers more payload contents in the same message and further information to allows managing extra features which are not required by the basic Snapshot Push exchange.

In order to ensure interoperability, the exchange data model wrapping shall be used in this exchange pattern.

A container shall be pushed to client using basic exchange data model as stated in the previous figure.

An ExchangeInformation object shall be returned from putData to convey information about exchange operation and connection status.

Exchange information

Information related to Exchange that should be managed to make application development easier are fully described in basic exchange data model.

Exchange Context information related are:

• Supplier related information
  • Requirement: Supplier identification.
• Client related information
  • Requirement: Client identification.
• Exchange DynamicInformation (provided both by the client and the supplier) wraps information such as exchangeStatus (“Success”, “Fail”, “Close Session Request”, “Snapshot Synchronisation Request”), and SessionID
  • Requirement: Session management, link monitoring
• Message Generation timestamp information
  • Requirement: Timely, reliable information, session management.

Payload Information

• Generation Timestamp Information
  • Requirement: Timely, reliable information, session management.

List of exchanged Messages

Different messages or supplier/client interactions are exchanged in the Stateful Push which are needed to manage session, synchronisation, payload exchange, link monitoring. These are formally contained in messages pushed to a client by a supplier or in messages returned from client to supplier.

State Diagrams¶

The supplier initiates the communication and can be aware of the client status based on the client return response to the supplier.

The following diagram (Figure 27) describes the client status as monitored and managed by the supplier.

Figure 27 — Supplier-side Stateful Push state diagram

The following diagram (Figure 28) describes the supplier status as monitored and managed by the client.

Figure 28 — Client-side Stateful Push state diagram

Specific management in the initialisation and termination of a push process should be considered at the application level in the supplier and client systems.

Features Implementation Description¶

Overview

This subclause provides a description and the corresponding specification for each feature identified in the context diagram, according to the Publish-Subscribe data exchange architecture. The following features are specified:

• Subscription contract;
• Subscription (also known as session);
• Information Management;
• Data delivery;
• Communication/protocol.

The corresponding classes, attributes and relationships described in the class diagrams included in the next subclauses are described in C.4.

Subscription Contract

Contract

Managed offline, not automated. It assumes information for controlling to be implemented in a client to assess the identity of supplier and authenticate the supplier request in messages exchange.

Catalogue

Managed offline, not automated.

Session

Session Life Cycle

After the session status management diagrams, the following sequence diagram illustrates the exchanged message and the expected return and behaviour.

When a session needs to be initiated, an “Open Session” is tried in loop until it succeeds.

A failure when opening a session includes cases of a client who has not subscribed or is not authorised. Checking this can be ensured at the PSM level (e.g. this could include VPN setting or IP firewall or signatures handling), logical information may be included in exchange data to be managed in subscription check at the client side.

When a session is “ON” the supplier pushes available payload data to the client in case one of the 2 conditions is fulfilled:

• payload available for On Occurrence Operating Mode or
• payload delivery timeout for Periodic Push Operating Mode.

In case no payload is available a” Keep Alive” message is used to check session status for the supplier and the client.

When no “Keep Alive” message or no payload is received, after a “Keep Alive” time-out the client invalidates the session on its side and returns a “Close Session” message to prevent any attempt of push from the supplier.

If any push or keep alive fails the supplier invalidates the session and starts a new loop to open session.

Realignment messages are managed when a session is opened, a global synchronisation request from the client is returned in opening session when needed. Further any global synchronisation may be asked by a client in any push return as well but this does not close the session.

Any message and return in the sequence diagram (Figure 29) will be mapped in PSM definition to real platform available implementation such as a web service “Service request and return” or any other available mechanism in a specific platform.

Figure 29 — Stateful Push sequence diagram for session life cycle and data delivery

Link Monitoring

“Keep Alive” is based as described in the previous session life cycle.

When data is available a payload push is exchanged which informs the client and the supplier about the session and systems status: The push is received from the supplier on the client side and the return of Push on payload push on the supplier side guarantees the network is available and the systems are up and running.

When no data is available and a time-out has expired a “Keep Alive” message is exchanged to check the network and system availability.

In case a payload push or a “Keep Alive” fails the session shall be invalidated (the retry mechanism is to describe at the PSM level introducing a logical push mapping iterated for a maximum number of attempts).

Information Management

Operating Modes

The available operating modes for supplier Push are either periodic, or condition-triggered (based on the supplier-side conditions and the interchange agreement at the subscription).

The general description of the operating modes is done at the PIM level, no extra details are needed in this subclause for PIM/exchange pattern / FEP.

A payload Push is triggered based on the agreed operating mode defined at the subscription between the client and the supplier.

Update Methods

Available updated methods are: Snapshot, Single element update, All elements update.

All updates available are conveyed in a payload publication push message.

The general description of the update methods is done at the PIM level, no extra details are needed in this subclause for PIM/exchange pattern / FEP.

Lifecycle Management

The description of life cycle management is done at the PIM level.

The life cycle management for exchanging data among a client and a supplier is embedded in the operating mode and the update method which have been chosen in the subscription contract.

The push delivery method allows conveying information from a supplier to a client as two different sets of information.

Sampled data can be conveyed (pushed) as “Periodic” or “On occurrence” of a global payload containing all currently active data or last collected data.

A “Single element” or “All elements” update push can be done for any operating mode, i.e. with “On occurrence” or “Periodic” push.

Data Delivery

Data delivery

Session life cycle online section allows sending data when available at the supplier system by triggering a data ready condition.

A periodic push condition is also possible based on contract agreement among supplier and client.

See sequence diagram at the session life cycle for messaging details

Data request

Not fully implemented in this pattern.

A snapshot synchronisation request can be managed in the client return data, by the return status described in the “Basix Exchange Data Model” by returnStatus set as snapshotSynchronisationRequest.

This feature implementation is not mandatory in this FEP, agreement to manage among client and supplier are needed to enable full interoperability.

Large datasets handling

Not fully implemented in this pattern.

A multi-part data delivery can be optionally implemented by supplier by setting in the delivered message within exchange “Dynamic Information” setting the completedPayload as false, as described in Basic Exchante Data Model, it will inform the client one or more subsequent message will be delivered to complete the payload information, until the attribute completedPayload will be set as true.

This feature implementation is not mandatory in this FEP, agreement to manage among client and supplier are needed to enable full interoperability.

Synchronisation

Global synchronisation and delta synchronisation are available in Stateful Push.

The global synchronisation is managed at the first session with a client or under a client request.

The delta synchronisation is managed once a session had been created and closed due to a network error or any other condition, so that not-delivered payload data is stored at the supplier side and delivered to the client as soon as a session is established again.

Self-Description

Handshake is not available

Communication

The communication features are implemented at the PSM level; they are relevant to a specific platform chosen on which the exchange pattern will be implemented (e.g. http/XML, Web services with SOAP, REST, etc.).

Optimisation issues

Some exchange pattern features of any context diagrams features groups (e.g. information management, data delivery etc.) allow the implementation of general optimisation such as processing saving and bandwith.

Payload timestamp information is available for client-side processing optimisation made at the application level.

Snapshot Push messages may be generated for all clients reducing processing resources at the supplier-side.

No extra optimisation issues are considered in this EP+FEP

Overview¶

Simple CIS FEP+EP PIM is based on description of interactions which enable service request and feedback exchange among a service requester and one to many service providers as illustrated in informative Annex H .

It can be implemented in several technological platforms with specific interactions methods, e.g. SOAP WebService methods.

The simple CIS FEP+EP frameworks enables a common communication interface to embed ITS service request and feedback in a way that two or more TMC, TIC or SP systems can perform in a common interoperable way.

Simple CIS FEP +EP framework is not designed to implement Data Delivery business scenario but it may be based on payload content which is assumed to be exchanged by Data Delivery which can be enabled by Data Delivery FEP+EP. Only Specific features enabling CIS are described and introduced for Simple CIS. Feature which are not related to this FEP+EP are martked as “Not applicable” in the table below.

To describe the EP+FEP at PIM level all features are described in a general abstract format, independently from the specific technology platform in which this model will be implemented. (e.g. http/get XML, WebService).

Exchange pattern and messages definition¶

Overall presentation

“Simple CIS” FEP+EP enable 1 service requester node to implement CIS service sequest interaction for 1 to several service providers.

The interaction is described as the CIS service requester addressing all involved CIS service providers through their Simple CIS Exchange interfaces which provides methods to deliver service requests from a requester to a multiplicity of service providers (Figure 30).

Figure 30 — “Simple CIS” exchange actors

The “Simple CIS” exchange pattern is described in the following subclauses.

Basic exchange pattern

In a “Simple CIS” context, the service provider provides a mechanism to receive a service request from action taken at a service requester site. This will result in the service requester invoking specific methods/resource offered by the service provider. On the reverse side a mechanism is also needed to enable the service provider to feed back the result of processing or action triggered by the service request, so the service requester itself provides a mechanism to receive a service feedback from the involved service providers when their actions or processes results are available.

Figure 31 shows the communication diagram for “Simple CIS” FEP + EP.

In this FEP+EP framework the service requester deliver a service request trigger to the service provider and the service provider delivers service feedback information to the service requester.

Therefore the “Service Requester” logically “pushes” “CIS Service Requests” messages, embedded in a “MessageContainer”, to the “Service Provider” which shall acknowledge the reception of such messages by a return message, embedded in an “ExchangeInformation”. This exchange information return message is available to bring information back from the “Service Provider” to the “Service Requester”, such as failure, success. Return message information is logically described in this PIM, while implementation will be defined at PSM level.

At the same time, the involved “Service Providers” logically push “CIS Service Feedback” messages, embed in a “Message Container” to the “Service Requester” which symmetrically shall acknowledge the reception of suche messages by a return message, embedded in an “ExchangeInformation”. This exchange information return message is available to bring some information back to the “Service Provider” which management is not relevant to this FEP+EP and is not described in this document.

The management of any further workflow based on any processing or action errors is in this workflow framework pattern based on CIS “Service Feedback” is only in charge of the “Service Requester” System and is defined at application level based on the specific application requirements needed to enable the specific collaborative ITS services.

In the context of this “Simple Push” FEP +EP framework, to enable interoperability among CIS service requester and CIS service providers, all rules defined in this clause apply.

Any simple CIS service provider exchange system SHALL realise a simple CIS service provider interface which provides a putCISServiceRequest method.

Any simple push service requester exchange system SHALL realise a simple CIS service requester interface which can invoke the putCISServiceRequest method provided by the simple cis service provider interface to deliver cis service request to trigger action/process by the service provider systems.

Any simple CIS service requester exchange system SHALL realise a simple CIS service requester interface which provides a putCISServiceFeedback method.

Any simple CIS service provider exchange system SHALL realise a simple CIS service provider interface which can invoke the putServiceRequest method provided by the simple CIS service requester interface to deliver CIS service feedback to the service requester systems.

Figure 31 shows the communication diagram for simple push FEP + EP.

In this FEP+EP framework the service requester “pushes” service requests messages to the service provider and the service provider “pushes” service feedback messages to the service requester.

Both service provider and service requester shall acknowledge the received service request or service feedback messages by a return information to the corresponding counterpart, i.e. respectively to the service requester and to the service provider. This return information shall be coded as ExchangeInformation.

Figure 31 — Simple CIS exchange subsystems, interface interactions and methods

Relevant exchange information from exchange data model

Overview

Basic exchange data model has been provided to allow the implementation to enable CIS features to support information processing and enable distributed transactions features.

CIS Information embed all information needed to request for specific processing and to enable workflow management to support transaction negotiation processes by service request and service feedback messages.

Exchange information enables to deliver the Exchange context of involved service requester and service providers to enable orchestration of ITS services supply and exchange dynamic information which enables general exchange status information to monitor transactions negotiation or service processing in general.

Exchange information

Some non-mandatory information which should be managed in the exchange information for easy application development are fully described in basic exchange data model:

• Service Provider Identification

  • Requirement: Supplier identification. (String)

• Client Identification

  • Requirement: Client identification. (String)

• Exchange Information (provided both by the client and the supplier) wraps exchange and exchange status information “Success”, “Fail”, “Close Session Request”, “SessionId”

• Generation timestamp information

  • Requirement: timely, reliable Information

CIS information

• Service Request

  It provides the reference to element to be processed and the requested action, also addressing the service for which the action is triggered:

• Predefined service

  • Requirements: Support for information processing, Distributed transaction

• Requested Action

  • Requirements: Support for information processing, distributed transaction, distributed atomic transaction

• Service Feedback

  • Requirements: Support for feedback on information processing, distributed transaction,

• Service request status

  • Requirements: Support information processing, Support for feedback on information processing, distributed transaction

Exchanged messages

Different messages or supplier / client interactions (invoked method) are exchanged in Simple Push which are needed to manage synchronisation, payload exchange, link monitoring. These are formally contained in pushed messages to a client from a supplier or in return messages from client to supplier.

State Diagrams¶

State diagram are not needed and not developed for stateless FEP+EP as Simple CIS.

Features implementation description¶

Overview

This subclause provides a description and the corresponding specification for each feature identified in the context diagram, according to the Simple Push data exchange architecture. The following features are specified:

• Subscription contract;
• Subscription (also known as session);
• Information management;
• Data delivery;
• Communication/protocol.

Subscription contract

Contract

Managed offline, not automated. It assumes information for controls to be implemented in client to assess the identity of supplier and authenticate the supplier request in messages exchange.

Catalogue

Managed offline, not automated.

Session

Session life cycle

No session is managed for the current EP+FEP.

Link monitoring

Not managed in this EP+FEP.

Information management

Overview of information management features

CIS features implementation is based on Service Request and Service Feedback implementation.

As explained in Annex H, besides Exchange actors involvement”Collaborative ITS Services” workflow management to support information process and transactions features involves application level management. These application level checking and triggers, which are needed to implement control and triggers to start exchange features, are considered existing and are not described in this document, which only assumes these processing and triggering functions are needed and implemented at “Service Requester System” and “Service Provider System” and are only indicated in the sequence diagrams as placeholders to support understanding of exchange workflows.

Figure 32 describes the interaction to implement a service request from the “Service Requester System” to one up to many “Service Provider Systems” by the “Simple CIS” exchange.

After the application level “Service Requester” system has triggered the “Service Request” exchange management, at first outcome it will receive the information that Service Request have been delivered to involved “Service Provider” systems, or some errors happened or had been recognised by the “Service Provider” systems in the service request itself. Returned “Exchange Information” is the first outcome of the Service Request delivery to the Service Provider and Service Provider System.

For CIS it is also assumed that at “Service Requester System” some application level management of service requests which had been delivered is needed and feedback and error/timeout management is done as application level implementation. The outcomes of such management will lead some application logic to decide the next workflow and exchange action needed but are not described in this specification.

Figure 32 — Simple CIS sequence diagram for Service Request

As stated above only interaction among “Exchange Interfaces” i.e. Service Requester and Service Provider are considered normative for the specific FEP+EP in this document. Other interaction are assumed but are dependent on application logic and requirements which are external to the exchange system which are not in the scope of this document. General aspect for CIS and some application level workflow requirements are described at Annex H .

Figure 33 describes the interaction to implement a service feedback from the “Service Provider System” to the “Service Requester System” by the “Simple CIS” exchange.

After the application level “Service Provider” system has delivered the feedback to the “Service Requester” exchange management, at first outcome it will receive the information that service feedback have been delivered to the “Service Requester” system or some errors happened or had been recognised by the “Service Requester” systems in the service feedback itself. Returned Exchange Information is the first outcome of the “Service Feedback” delivery to the Service Requester and Service Requester System.

For CIS it is also assumed that at “Service Requester System” some application level management of service feedbacks which had been delivered is needed and feedback and error/timeout management is done as application level implementation. The outcomes of such management will lead some application logic to decide the next workflow and exchange action needed but are not described in this specification.

Figure 33 — Simple CIS sequence diagram for Service Feedback

Support information processing

While the workflow to enable the support to information processing is defined in sub-clause 6.4.4.1 of this document, the information needed to enable such information process are described in the Basic Exchange Data Model at Annex C , specifically at CIS Information description.

Predefined services are possible as well as not predefined services, which are enabled by specific attributes in the CIS Information classes.

Distributed transaction

While the workflow to enable the support to distribute not atomic transactions processing is defined in sub-clause 6.4.4.1 of this document, the information needed to enable such information process are described in the Basic Exchange Data Model at Annex C , specifically at “CIS Information” description.

Predefined services are possible as well as not predefined services, which are enabled by specific attributes in the “CIS Information” classes.

Data delivery

Not managed in this EP+FEP.

In Simple CIS FEP+EP PIM it is assumed that data delivery requirements to deliver data to be processed are enabled by a parallel Data Delivery exchange and referenced in CIS Information to specify the relative processing action, despite payload data can be also delivered in a Service Request or Service Feedback when needed by specific application level management, it can be assumed delivered in a previous exchange. The responsibility of data availability to support actions and processing requests are assumed to be in charge of the “Service Requester System” itself.

Self-Description

Handshake not available.

Communication

Communication features are implemented at PSM level, they are relevant to the specific Platform chosen on which the Exchange pattern will be implemented (e.g. http/XML, Web Services SOAP, REST).

Overview¶

“Stateful CIS” is an extension of the “Simple CIS”, described and specified for the “Simple CIS” FEP+EP PIM (i.e. clause 6 in this document), with session management and link monitoring features which are enabled by the same mechanisms which are defined for the “Stateful Push” FEP + EP PIM (i.e. section 5 in this document). The overall implementation of “Stateful CIS” will be a combination of features described for both “Simple CIS” service request and service feedback mechanism, with session management and link monitoring features implemented as per “Stateful Push”.

Only specific “Stateful Push” definition will be described in the current section, all definition and specification which are the same for “Stateful Push” or “Simple CIS” FEP+EP PIM will be addressed to the specific sections in this document.

NOTE All definition applies which are related to “Simple CIS” and “Stateful Push”FEP + EP PIM, but supplier role and name is to be associated to the requester system and client role and name is to be associated to the provider systems.

“Stateful CIS” FEP+EP PIM is based on description of interactions which enable service request and feedback exchange among a service requester and one to many service providers as illustrated in informative Annex H .

It can be implemented in several technological platforms with specific interactions methods, e.g. SOAP WebService methods.

The “Stateful CIS” FEP+EP frameworks enables a common communication interface to embed ITS service request and feedback in a way that two or more TMC, TIC or SP systems can perform in a common interoperable way.

“Stateful CIS” FEP +EP framework is not designed to implement Data Delivery business scenario but it may be based on payload content which is assumed to be exchanged by Data Delivery which can be enabled by Data Delivery FEP+EP. Only Specific features enabling CIS are described and introduced for Simple CIS. Feature which are not related to this FEP+EP are martked as “Not applicable” in Table 9.

To describe the “Stateful CIS” EP+FEP at PIM level all features are described in a general abstract format, independently from the specific technology platform in which this model will be implemented. (e.g. http/get XML, WebService).

Table 15 Selection of features for Simple Push

Exchange pattern and messages definition¶

Overall presentation

As Simple CIS “Stateful CIS” FEP+EP enable one service requester node to implement CIS service sequest interaction for one up to several service providers. At the same time Session Management and Link Monitoring features allows “Stateful CIS” Service Requester and Service Provider Systems to be aware of network communication features among them to enable reliable and timely exchange and take initiative to trigger any required actions besides CIS actions themselves in case a session or link are broken by system or network failures.

The interaction is described as the CIS service requester addressing all involved CIS service providers through their Stateful CIS Exchange interfaces which provides methods to deliver service requests from a requester to a multiplicity of service providers (Figure 34).

Figure 34 — “Stateful CIS” exchange actors

The “Simple CIS” exchange pattern is described in the following subclauses.

Basic exchange pattern

In a “Stateful CIS” context, the service provider provides a mechanism to receive a service request from action taken at a service requester site. This will result in the service requester invoking specific methods /resource offered by the service provider. On the reverse side a mechanism is also needed to enable the service provider to feed back the result of processing or action triggered by the service request, so the service requester itself provides a mechanism to receive a service feedback from the involved service providers when their actions or processes results are available.

Besides “Simple CIS” service request and service feedback methods the stateful cis client also provides a “keep alive” method to implement link monitoring capabilities among service requester and service providers, the keepAlive method is used from the service requester to advise the client when no service request are to be delivered, so the service requester delivers a “keep alive” message to check and enable the service providers to verify that exchange systems and network connection are available, despite the service requester doesn’t need to exchange payload content. “Keep Alive” messages are delivered by the service requester to the service providers, according a time interval which is defined among them.

“Stateful CIS” session management methods are available to implement session management features in the same way they are described and available for “Stateful Push” FEP+EP PIM; such methods, namely openSession and closeSession usage which are used to define dynamic exchange information context to enable session management exchange features.

Figure 35 shows the communication diagram for “Stateful CIS” FEP + EP.

In this FEP+EP framework the service requester delivers a service request trigger to the service provider and the service provider delivers service feedback information to the service requester.

Therefore, the “Stateful CIS Service Requester” logically “pushes” “CIS Service Requests” messages, embedded in a “MessageContainer”, to the “Stateful CIS Service Provider” which shall acknowledge the reception of such messages by a return message, embedded in an “ExchangeInformation”. This exchange information return message is available to bring information back from the “Service Provider” to the “Service Requester”, such as failure, success. Return message information is logically described in this PIM, while implementation will be defined at PSM level.

At the same time, the involved ” Stateful CIS Service Providers” logically push “CIS Service Feedback” messages, embed in a “Message Container” to the ” Stateful CIS Service Requester” which symmetrically shall acknowledge the reception of suche messages by a return message, embedded in an “ExchangeInformation”. This exchange information return message is available to bring some information back to the “Service Provider” which management is not relevant to this FEP+EP and is not described in this document.

The management of any further workflow based on any processing or action errors is in this workflow framework pattern based on CIS “Service Feedback” is only in charge of the “Service Requester” System and is defined at application level based on the specific application requirements needed to enable the specific collaborative ITS services.

In the context of this “Stateful Push” FEP +EP framework, to enable interoperability among CIS service requester and CIS service providers, all rules defined in this clause apply.

Any simple CIS service provider exchange system SHALL realise a stateful CIS service provider interface which provides a putCISServiceRequest method, and an openSession, closeSession and keepalive methods.

Any simple push service requester exchange system SHALL realise a simple cis service requester interface which can invoke the putCISServiceRequest, openSession, closeSession, keepAlive methods provided by the simple cis service provider interface to deliver cis service request to trigger action/process by the service provider systems.

Any simple CIS service requester exchange system SHALL realise a simple CIS service requester interface which provides a putCISServiceFeedback method.

Any simple CIS service provider exchange system SHALL realise a simple CIS service provider interface which can invoke the putServiceRequest method provided by the simple CIS service requester interface to deliver CIS service feedback to the service requester systems.

Figure 35 shows the communication diagram for simple push FEP + EP.

In this FEP+EP framework the service requester “pushes” service requests messages to the service provider and the service provider “pushes” service feedback messages to the service requester.

Both service provider and service requester shall acknowledge the received service request or service feedback messages by a return information to the corresponding counterpart, i.e. respectively to the service requester and to the service provider. This return information shall be coded as ExchangeInformation.

NOTE This return message is available to bring some exchange information back from the receiver system which may be used for any further exchange features implementations or application level checks or processing and/or workflow management decision in CIS implementation which are out of scope of this document.

Figure 35 — Stateful CIS exchange subsystems, interface interactions and methods

Relevant exchange information from exchange data model

Overview

Basic exchange data model has been provided to allow the implementation to enable CIS features to support information processing and enable distributed transactions features.

CIS Information embed all information needed to request for specific processing and to enable workflow management to support transaction negotiation processes by service request and service feedback messages.

Exchange information enables to deliver the Exchange context of involved service requester and service providers to enable orchestration of ITS services supply and exchange dynamic information which enables general exchange status information to monitor transactions negotiation or service processing in general.

Exchange information

Some non-mandatory information which should be managed in the exchange information for easy application development are fully described in basic exchange data model:

• Service Provider Identification

  • Requirement: Supplier identification. (String)

• Client Identification

  • Requirement: Client identification. (String)

• Exchange Information (provided both by the client and the supplier) wraps exchange and exchange status information “Success”, “Fail”, “Close Session Request”, “SessionId”

• Generation timestamp information

  • Requirement: timely, reliable Information

CIS information

• Service Request

  It provides the reference to element to be processed and the requested action, also addressing the service for which the action is triggered:

• Predefined service

  • Requirements: Support for information processing, Distributed transaction

• Requested Action

  • Requirements: Support for information processing, Distributed transaction, Distributed atomic transaction

Service Feedback

• Requirements: Support for feedback on information processing, Distributed transaction,

Service request status

• Requirements: Support information processing, Support for feedback on information processing, Distributed transaction

Exchanged messages

Different messages or supplier / client interactions (invoked method) are exchanged in Simple Push which are needed to manage synchronisation, payload exchange, link monitoring. These are formally contained in pushed messages to a client from a supplier or in return messages from client to supplier.

State Diagrams¶

The service requester initiates the communication and by open session and keep alive messages can be aware of the service provider status based on return messages or possible communication errors.

The following diagram (Figure 36) describes the internal service requester status and the corresponding service provider status as monitored and managed by the service requester.

Figure 36 — CIS requester-side Stateful CIS state diagram

The following diagram (Figure 37) describes the internal service provider status and the service requester status as monitored and managed by the service provider.

Figure 37 — CIS Provider-side Stateful CIS state diagram

Specific management in the initialisation and termination of a push process should be considered at the application level in the supplier and client systems.

Features implementation description¶

Overview

This subclause provides a description and the corresponding specification for each feature identified in the context diagram, according to the Simple Push data exchange architecture. The following features are specified:

• Subscription contract;
• Subscription (also known as session);
• Information management;
• Data delivery;
• Communication/protocol.

Subscription contract

Contract

Managed offline, not automated. It assumes information for controls to be implemented in client to assess the identity of supplier and authenticate the supplier request in messages exchange.

Catalogue

Managed offline, not automated.

Session

Session life cycle

After the session state management diagrams, at exchange initialisation a session needs to be initiated, an “Open Session” is tried in loop until it succeeds.

A failure when opening a session includes cases of a client who has not subscribed or is not authorised. Checking this can be ensured at the PSM level (e.g. this could include VPN setting or IP firewall or signatures handling), logical information may be included in exchange data to be managed in subscription check at the service provider side.

When a session is “ON” the service requester may send service request to involved service providers when all conditions to start a CIS service are triggered.

In case no CIS Service requester triggering condition occurs a” Keep Alive” message is used to check session status for the supplier and the client.

When no “Keep Alive” message or no payload is received, after a “Keep Alive” time-out the service provider invalidates the session on its side and returns a “Close Session” message at firse received message of any type.

If any service request or keep alive fails the service requester invalidates the session and starts a new loop to open session.

Any message and return in the sequence diagram (Figure 37) will be mapped in PSM definition to real platform available implementation such as a web service “Service request and return” or any other available mechanism in a specific platform.

Link monitoring

After “Keep Alive” mechanism introduced in the previous session life cycle, service requests and keep alive messages are exchanged which give evidence to the service requester and service providers about the session and systems status.

When no service request or feedback are exchanged and a time-out has expired a “Keep Alive” message is exchanged to check the network and system availability.

In case service request or service feedback or “Keep Alive” fail, the session shall be invalidated.

Information management

Overview of information management features

Besides the Service Request and Service Feedback handshaking which is fully described in the equivalent “Stateful CIS” clause, Stateful CIS implements them in the framework of a stateful session, which implementation make aware the application side Service Requester about the availability and session status of all service providers which are involved in the Collaborative ITS Service implementation. This enable the decision process to trigger and manage CIS to involve information about involved CIS Service Provider status and availability.

All application level rules about decisions to trigger services and involved providers orchestration functionalities of CIS are out of scope of the exchange specification and are not described in this documents.

Support information processing

This clause description and specification for “Stateful CIS” are the same as the equivalent “Simple CIS” clause.

Distributed transaction

This clause description and specification for “Stateful CIS” are the same as the equivalent “Simple CIS” clause.

Data delivery

Not managed in this EP+FEP.

In Stateful CIS FEP+EP PIM it is assumed that data delivery requirements to deliver data to be processed are enabled by a parallel Data Delivery exchange and referenced in CIS Information to specify the relative processing action, despite payload data can be also delivered in a Service Request or Service Feedback when needed by specific application level management, it can be assumed delivered in a previous exchange. The responsibility of data availability to support actions and processing requests are assumed to be in charge of the “Service Requester System” itself.

Self-Description

Handshake not available.

Communication

Communication features are implemented at PSM level, they are relevant to the specific Platform chosen on which the Exchange pattern will be implemented (e.g. http/XML, Web Services SOAP, REST).