Platform Indepent Model¶

Introduction¶

Model driven approach is chosen to describe Exchange: this lead to describe exchange systems by means of abstract model which are named Platform Independent Model (PIM), modelling of exchange features is done by describing interaction among systems and subsystems which are described as Exchange Patterns, those interactions implements system capabilities as features which fulfils exchange requirements requested by specific Business Scenarios which are used to specify specific use of Exchange.

Since simple data exchange process is no longer sufficient for resolving all business needs, this Technical Specification encompasses more business functions as the stakeholders consolidate their systems and look at new ways to address the requests they encounter with the tools they already know and have in place.

Business scenarios and functional exchange profile¶

This Technical Specification is based on business scenarios, i.e. 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. Derived from requirements a business scenario has on information as well as technical parameters, Functional Exchange Profiles (FEPs) are identified to ensure interoperable services with the restriction of determining one FEP per business scenario for a specific technical platform. One FEP can support more than one business scenario.

Figure 2 — Business scenario and Functional exchange profile

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

• Information delivery

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

Requirements, Feature and Exchange Patterns¶

Requirements may vary depending on data exchange application i.e. Use Cases to be fulfilled, so there could be many reasons to consider or not any requirement based both on the gathering of data at Supplier System and the usage of Delivered data in the Client.

Requirements address the following items:

• Information provision,

• Communications,

• Security,

• Financial aspects.

Exchange is defined through Features which implement the Information Exchange and fulfils Data Exchange requirements.

Depending on many possible Exchange Platform considered for implementation, a subset of features and relative requirements is possible to be implemented. To fulfil a set of requirements many Platform are possible, but to be interoperable client and supplier shall implement the same platform with the same pattern. Allowing a wide variety of possible Exchange Pattern, the best suitable for an application may be chosen, according to requirements which fulfilment is granted by the selected Exchange Pattern.

Based on the requirements of a specific Business Scenario, a set of appropriate exchange features has to be combined into a Functional Exchange Profile (FEP).

The following schema represent the domains of PIM and PSM introducing Exchange Pattern EP and Functional Exchange Profile 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 the European DATEX II publications

The Data Delivery Business Scenario consider the actors as defined in the following figure:

Figure 4 — General Data Delivery Business Scenario actors

Assuming the definitions in following Table:

Road and Traffic Information is gathered at a System which is named “Supplier System” in case the information it stores is needed to betransferred to another system, named Client System, for any purpose.

The Data Delivery Business Scenario describes the Exchange pattern and Messages which are needed to be exchange among Supplier and ClientSystems 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 updates of Information status at the Supplier system has to bereplicated to the Client System via Information Delivery. The main scope of Information delivery is that Information on Client System is updated exactly in the same way as it is in the Supplier system without any difference on information values and semantics.

We can define “Exchange Message” the data structure in which the information is coded to transfer Information in the Exchange System fromthe 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 enables this scope and other secondary requirements which are possible based on available Features on considered Platforms and Patterns.

1. Supplier System Characterization

   • 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 mean of Messages

   • The Supplier of data exchange System shall produce and transmit the messages (D2Notification)

   • The Client of data exchange System should receive and process the messages

3. Client System Characterization

   • Could receive traffic and travel related data from the data exchange Environment

   • Could 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 actually 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 “Exchange Pattern” is to be introduced, as well as PIM and FEP. It can be defined as follows:

Exchange Pattern can be defined as: the basic Exchange Architecture Model which identifies Actors in the Exchange framework and Messaging Patterns as basic tools which are available to implement Information Delivery by Exchange features.

Messaging Patterns can be defined by means of UML Sequence Diagrams,Collaboration Diagrams and State Diagrams, in a way that Messages Triggering condition are well defined and any update of state is welldefined and identified based on the subsequent message exchange orconditions.

Examples of Exchange pattern are LCP (http/get), Pull, Push PubSub, etc

Once an Exchange Pattern and a Selection of Features (FEP) which can beimplemented on these Exchange patterns are set, a set of specificationat PIM level for Exchange Pattern/FEP is well defined.

A PIM for Exchange Pattern/FEP which enables all mandatory requirements is a valid platform for Information Delivery Business case.

Specific Exchange Pattern Specification PIM included in this specification

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

• Snapshot Pull

• Snapshot Push

• Simple Push

• Stateful Push

• PubSub FEP, Publish Subscribe Pattern [ based on OASIS WS Notification Specification (2006)]

Business scenario: Collaborative ITS Service¶

Overview

In CIS business scenario the exchange of information among centre is considered as a base to trigger processes and services on those data, so the data exchange layer is to be considered a mean as “ITS Services” enabler.

Information about CIS concept and its model description may be found in Annex G

Data Exchange enabling Service Request and Feedback Paradigm

The involved systems which in Data delivery had been considered as Supplier and Client can be seen in this paradigm respectively as Service Provider and Service Requester

Note that at Application level for implementing some Business Cases such as TMPlan Management, some Workflow modelling is normally requested. This could be simple workflow (Accept Request or Reject Request) or more complex: This workflow modelling at application level is out of scope of Exchange Specification, which provides only the essential tool to raise Service Request and Provide Feedback: Exchange of Payload to be processed and processing results:

• Collaborative mean 2 to many Systems interoperating

• 1 to n Data Exchange connection

  • Modelling Any Single CIS Usage Invoking with

    • 1 Service Requester

    • many Service Provider

  • Reducing complex combination of Single Usages from many requesters

    • out of scope, not needed to be described

    • question on possible lock of resources to be managed at Application or Human Operator level not described in the Exchange specification

• ITS Services definition, just to give a reference, service description is out of scope of specifications

• Specific Definition of ITS Service in the long description annex, note the reference EW DG

  • 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.

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 informative (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 Exchange Pattern/FEP Selection, but some common general information model may be considered, which could be specialised to manage specific Exchange pattern and PIM.

A General UML model for managing a minimum set of information forExchange is provided in this specification at Annex C

Data exchange features¶

Context Diagram

This technical Specification defines the features and rules that systemsshould implement in order to be able to communicate in the traffic andtravel data exchange world.

The context diagram of Figure 5 below identifies the entities and thefeatures that are specified in this Technical Specification and need tobe addressed by the technical implementations. The diagram presents thefeatures 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. The Technical specification 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 are defined the rules (protocol) 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 that are used by the data exchange applications, such as TCP/IP, Security, Web Services, etc. 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

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

1. Subscription contract – Supports all features related to the contract or agreement, such as:

   1. Contract and contract life cycle: a model and features that may be used to 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:

   Table 1 — Subscription contract: features and requirements

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

2. Session – The session feature group 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:

   Table 2 — Session: features and requirements

   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. Information management - Handles the features related to 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;

      1. Situation lifecycle management

      2. 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:

   Table 3 — Information management: features and requirements

   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 lifecycle management
   Support Information Processing	Information	Support for information management
   		Support for feedback on information management
   Distributed transaction	Information	Distributed transaction
   		Distributed atomic transaction

4. Data delivery – 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 the following Features:

   Table 4 — Data delivery: features and requirements

   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 closest to the physical layer. It is used by the application for the transport of messages.

   1. Communication – describe the protocols of communication that could be used;

   2. Security – describe how security features could be implemented;

   3. Compression – how data compression could 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:

   Table 5 — Communication: features and requirements

   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

Overview¶

The “Snapshot Pull” Exchange Pattern / FEP at PIM level is based on information retrieval by the Client from the Supplier which deliver a snapshot of information, i.e. all currently available information content, to the client, which can be implemented in several platform:some examples are XML retrieval of generated XML files by http/get, orSupplier exposing a SOAP WebService method (e.g. named “PULL”), fromwhich currently available data can be retrieved by the client.

This “Snapshot Pull” does not manage Session Lifecycle and Link Monitoring requirements, as well as synchronisation, this features and related requirements are not considered in this Pattern, synchronisation is note needed as implicit by snapshot delivering of currently availableinformation content.

To describe Snapshot Pull 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¶

We resume from Information Delivery Business Scenario description and definition 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 which enables messages generation and transfer among Supplier and Client.

Figure 6 — Snapshot Pull Exchange actors

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

Basic Exchange Pattern

The Supplier provides a mechanism to retrieve current data, also called “snapshot” of information, normally for a specific payload, i.e. current information content of Client System or Last retrieved information for Sampled data (see Annex F ).

Figure 7 — Snapshot Pull Exchange subsystems and interfaces interactionsand method

This mechanism is referred in this document as “pullData”.

The Client takes the initiative to retrieve the data based on its needs, normally when some condition defined at Client side are triggered or in a periodic way; specifically:

• Periodic Pull, based on fixed or variable time cycle, depending on application logic at Client System

• On Occurrence (Triggered Pull), on any condition stated by the Client or by the Client System

Relevant Exchange Information in Exchange Data Model

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 on the same Message and further information to allow to manage some extra features not required by the Snapshot Pull exchange. The usage of the Exchange Data Model wrapping is for harmonisation to other Exchange Pattern such as “Simple Pull” or “Stateful Push”.

A D2Container should be retrieved using Basic Exchange Data Model as reported in previous figure, alternatively a D2Payload may be retrieved without any further information.

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 created/updated for error management and processing saving.

Features Implementation Description¶

This sub-clause 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. Condition Triggered based on client) Pull 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 Supplier System to prepare for Delivery Messages, this can be done at timeout on a cycle basis or at specific condition triggering as “data updated” condition.

For lifecycle management information, snapshot 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.

Whenever a condition is raised the Supplier System may trigger this to the Supplier to manage creation of Pull Message.

Figure 8 — Snapshot Pull Sequence Diagram Information management at Supplier side

Information Management for Snapshot Pull 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)

Data Delivery¶

Data delivery

The sequence Diagram for Data Delivery is as follows

Figure 9 — Snapshot Pull Sequence Diagram for Data retrieval: implicit Data Delivery

Pull message generation processing is optional based on chosen Platform Technology

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

Not available

Communication

Communication Feature 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, etc.)

Optimisation issues

Bandwidth and Processing Savings

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

Pull message may be generated for all client reducing processing resources at Supplier side

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

Huge dataset handling

Not managed 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 platform: some examples are XML delivering of generated XML files by http / post, or Client exposing a SOAP WebService method (e.g.named “PUSH”) to which currently available data can be sent by the Supplier to the Client.

This “Snapshot Push” does not manage Session Lifecycle and Link Monitoring requirements, as well as synchronisation, this 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¶

We recall from Information Delivery Business Scenario description and definition that Data Exchange is needed to align the information kept bythe Supplier System into the Client System, for this purpose an ExchangeSystems is used which provides tools which enables messages generationand transfer between Supplier and Client.

Figure 10 — Snapshot Push Exchange actors

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

Basic Exchange Pattern

The Client provides a mechanism to receive data from action taken at Supplier site invoking specific resources / methods offered by Client. Supplier so logically “pushes” Messages to the Client. The Client shall acknowledge what received by a Return Information to the Supplier. This return message is available to bring some information back from Client to the Supplier.

Figure 11 — Snapshot Push Exchange subsystems and interfaces interactions and method

The Client provides a mechanism to the Supplier to push currently available data, also called “snapshot” of information, i.e. current information content at Supplier System or Last retrieved information for Sampled data (see Annex F ).

This mechanism is referred in this document as “putSnapshotData”.

The Supplier takes the initiative to deliver the data to the Client based on some rules, normally when some condition defined at Supplier side are triggered or in a periodic way; specifically:

• Periodic Push, based on fixed or variable time cycle, depending on application logic at Supplier System

• On Occurrence (Triggered Push), on any condition stated by the Supplier

Relevant Exchange Information in Exchange Data Model

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

Basic Exchange Data Model has been provided to allow the implementationto deliver more payload contents on the same Message and furtherinformation to allow to manage some extra features not required by the basic Snapshot Push Exchange. The usage of the Exchange Data Model wrapping is for harmonisation to other Exchange Pattern such as “SimplePull” or “Stateful Push”.

A D2Container should be retrieved using Basic Exchange Data Model as reported in previous figure, alternatively a D2Payload may be delivered.

A D2ExchangeInformation is returned to convey information about exchange operation and connection status.

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.

Features Implementation Description¶

This sub-clause 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 for Delivery Messages, this can be done at timeout on a cycle basis or at specific condition triggering as “data updated” condition.

For lifecycle management information, snapshot 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.

Whenever a condition is raised the Supplier System manage creation of Push Message and deliver it.

Figure 12 — 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)

Data Delivery

Data delivery

The sequence Diagram for Data Delivery is the same as previous figure

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 Section.

Synchronisation

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

Self-Description

Handshake

Not available

Communication

Communication Feature 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, etc.)

Optimisation issues

Bandwidth and Processing Savings

Payload timestamp information is available for Client side processing optimisation made at application level.

Pull message may be generated for all client reducing processing resources at Supplier side

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

Huge dataset handling

Not managed in this EP+FEP

Overview¶

Simple 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 “Simple Push” add 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 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¶

We recall from Information Delivery Business Scenario description and definition 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 which enables messages generation and transfer among Supplier and Client.

Figure 13 — Simple Push Exchange actors

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

Basic Exchange Pattern

The Client provides a mechanism to receive data from action taken at Supplier site invoking specific resources / methods offered by Client.

Supplier so logically “pushes” Messages to the Client. The Client shall acknowledge what received by a Return Information to the Supplier. This return message is available to bring some information back from Client to the Supplier, such as, Fail, Success, Snapshot Synchronisation Request. Return message information is logically described in this PIM, while implementation will be defined at PSM, level.

Figure 14 — Simple Push Exchange subsystems and interfaces interactions and method

The mechanisms available are referred in this document as “putData”,”keepAlive” and optional “putSnapshotData”.

Simple Push actually pushes available information or available updated information to the Clients, but do not keep track of what has been delivered to specific Clients. For specific use cases such as delivery of stateful information (e.g. situation payload information), a first snapshot may be useful and may be delivered to client based on information to be exchanged or explicit client request in return code. This feature is optional in this FEP+EP PIM. Based on previous optional requirement Exchanged data can either be current available data, also called “snapshot” of information, or, when a synchronisation is not needed such as for stateless information ( e.g.Road Data) , a set of information which had changed since the last Push may be exchanged to align the Information status on the Client System. Those messages may include single updated element or all updated elements depending on Update Method chosen.

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

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 to manage some extra features not required by the basic Snapshot Push Exchange.

For interoperability convenience the Exchange Data Model wrapping shall be managed in this Exchange Pattern.

A D2Container shall be pushed to Client using Basic Exchange Data Model as reported in previous figure.

A D2ExchangeInformation shall be returned from putData to convey information about exchange operation and connection status.

Exchange Information

Some not mandatory information should be managed in the Exchange Information to easy application development are fully described in Basic Exchange Data Model:

• Supplier Identification (String)

  • Requirement: Supplier identification.

• Client Identification (String)

  • Requirement: Client identification.

• Exchange Information (provided both by the Client and the Supplier) wraps Exchange and Exchange Status information “Success”, “Fail”, “Close Session Request”, “Snapshot Synchronisation Request”, SessionId

  • Requirement: Session Management, Link Monitoring

Payload Information

• 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.

Link Monitoring and Error Management¶

The Supplier initiate the communication and is made aware of Client Status based on Client Return response to the Supplier

The following diagram describes the Client status as monitored and managed by the Supplier.

Figure 15 – Supplier Side Simple Push State Diagram

Special management for initialisation and termination of Push Process to specific Client are to be considered at application development level in supplier and Client Systems.

The following diagram describes the Supplier status as monitored and managed by the Client.

Figure 16 — Simple Push State Diagram Client side

Special management in initialisation and termination of Push Process are to be considered at application level in Supplier and Client System.

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 Push Payload and Keep Alive. When data is available a Payload Push is exchanged which also inform client and supplier if session and systems status: Push received from Supplier on Client Side and return of Push on Payload push on Supplier side guarantees the network is available and the systems are up and running.

When no data is available to Supplier and a timeout is expired a KeepAlive Message is exchanged to check network and system availability.

In case Payload Push or KeepAlive fails or timed out the Supplier assumes the Client is Offline and keep trace of this status for any management purposes at Supplier System side (for delivery retry mechanism are to be described at PSM level defining a Logical Push mapping iterated for a maximum number of times).

Figure 17 - 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 Triggered based on supplier) Push based on Supplier side conditions.

Description of Operating Modes is done at general PIM Level, no extra details are needed in this Section 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 messages.

Description of Operating Modes is done at PIM Level, no extra details are needed in this Section for PIM/Exchange Pattern / FEP.

Lifecycle Management

Description of LifeCycle Management is done at PIM Level.

Lifecycle management to Exchange data among Client and Supplier is embed on Operating Mode and Update Method which had been chosen at Subscription contract.

Push delivery method allows to convey information from Supplier to Client as two different information.

Sampled data can 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 may be done for any operating mode as well with On Occurrence or Periodic Push.

Data Delivery

Data delivery

Based on Sequence Diagram described the Supplier after initialisation start sending Push information to Client: in case of stateful information delivery and based on subscription contract eventually agreed conditions e.g. it will manage 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’s not the first time the supplier send data to Client it can deliver normal Payload Push data, but the client for internal Client System needs may also require for snapshot push data by its return status.

After initialisation Data Ready condition at Supplier System Side trigger a Payload Push delivery.

A Periodic Push condition is also possible based on Contract agreement among Supplier and Client.

See Sequence Diagram at Link Monitoring Lifecycle for all Messaging details

Data request

Not implemented in this pattern

Large datasets handling

Not Described at PIM Level, may be defined at PSM level.

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 case a Simple Push is delivered based on Supplier site data available and conditions.

Self-Description

Handshake

Not available

Communication

Communication Feature 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, etc.)

Optimisation issues

Bandwidth and Processing Savings

Payload timestamp information is available for Client side processing optimisation made at application level.

Pull message may be generated for all client reducing processing resources at Supplier side

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

Huge dataset handling

Not managed 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¶

We recall from Information Delivery Business Scenario description and definition 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 which enables messages generation and transfer among Supplier and Client.

Figure 18 — Stateful Push Exchange actors

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

Basic Exchange Pattern

The Client provides a mechanism to receive data from action taken at Supplier site invoking specific resources / methods offered by Client.

Supplier so logically “pushes” Messages to the Client. The Client shall acknowledge what received by a Return Exchange Information to the Supplier. This Exchange Information return message is available to bring some information back from Client to the Supplier, such as SessionId, Fail, Success, Snapshot Synchronisation Request. Return message information is logically described in this PIM, while implementation will be defined at PSM, level.

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

The mechanisms available are referred in this document as openSession, “putData”, “keepAlive” and optional “putSnapshotData”, closeSession.

Exchanged data can either be current available data, also called “snapshot” of information, or, after a first transfer of currently valid data, i.e. a snapshot, a subset of information which had changed since the last Push may be exchanged to align the Information status on the Client System. Those messages may include single updated element or all updated elements depending on Update Method chosen.

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

• First Session Initialisation: one ===Snapshot alignment=== is needed to convey al currently available data at a first connection of Exchange.

• Session Initialisation : after a First Session had been created once needing a First Session Initialisation, for any time a Session had been closed or broken after some errors, it is necessary to align the Client by:

• a Delta Synchronisation, i.e. a simple payload Push delivering all updated content since last fulfilled Push

• a Snapshot Synchronisation with all the currently available content snapshot in case of snapshot alignment feature is requested by client.

• Snapshot Synchronisation request: one Snapshot alignment can also be acknowledged to the client for internal system need / maintenance / debug, it may be requested via any Return Messages on Exchange data.

• 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)

Relevant Exchange Information from Exchange Data Model

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 to manage some extra features not required by the basic Snapshot Push Exchange.

The Exchange Data Model wrapping shall be managed in this Exchange Pattern.

A D2Container shall be pushed to Client using Basic Exchange Data Model as reported in previous figure.

A D2ExchangeInformation shall be returned from putData to convey information about exchange operation and connection status.

Exchange Information

Extra information is needed to grant Exchange Features implementation besides return messages which are only logically described.

• Session ID to manage Session creation, updates, termination

Some not mandatory information should be managed in the Exchange Information to easy application development are fully described in Basic Exchange Data Model:

• Supplier Identification (String)

  • Requirement: Supplier identification.

• Client Identification (String)

  • Requirement: Client identification.

• Exchange Information (provided both by the Client and the Supplier) wraps Exchange and Exchange Status information “Success”, “Fail”, “Close Session Request”, “Snapshot Synchronisation Request”, SessionId

  • Requirement: Session Management, Link Monitoring

Payload Information

• 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 Stateful Push which are needed to manage Session, Synchronisation, Payload Exchange, Link Monitoring. These are formally contained in Pushed Messages to Client from Supplier or in Return Messages from Client to Supplier.

Session and Error Management¶

The Supplier initiate the communication and may be aware of Client Status based on Client Return response to the Supplier

The following diagram describes the Client status as monitored and managed by the Supplier.

Figure 20 - Stateful Push State Diagram Supplier side

Specific management for initialisation and termination of Push Process to specific Client are to be considered at application development level in supplier and Client Systems.

The following diagram describes the Supplier status as monitored and managed by the Client.

Figure 21 — Stateful Push State diagram Client side

Specific management in initialisation and termination of Push Process are to be considered at application level in Supplier and Client System.

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

After Session Status Management diagrams, the Sequence Diagram in the following figure illustrate the message exchanged and the expected return and behaviour.

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

NOTE. Fail on Open Session may include Client not Subscribed or not Authorised (failure reason in the exchange model). Check on this may be ensured at 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 Client Side.

When Session is ON the Supplier pushes available Payload data to the Client under 2 conditions:

• 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 Supplier and Client.

When no KeepAlive message or no Payload is received, after a KeepAlive timeout the client invalidate the session on its side and return Close Session to any attempt of Push from the Supplier.

If any Push or Keep Alive fails, the Supplier invalidate the session and start a new loop to Open Session.

Realignment Messages are managed when a Session is Opened, Snapshot Synchronisation request from the Client is returned in Open Session when needed. Further any Snapshot Synchronisation may be asked from Client in any Push Return as well, but this does not close a Session.

Any message and return in the Sequence Diagram will be mapped in PSM definition to real platform available implementation such as WebService Service request and return or any other available mechanism in a specific Platform.

Figure 22 — Stateful Push Sequence Diagram for Session Lifecycle and Data Delivery

Link Monitoring

Keep Alive based as described in previous Session Lifecycle

When data is available a Payload Push is exchanged which inform client and supplier if session and systems status: Push received from Supplier on Client Side and return of Push on Payload push on Supplier side guarantees the network is available and the systems are up and running.

When no data is available to Supplier and a timeout is expired a KeepAlive Message is exchanged to check network and system availability.

In case Payload Push or KeepAlive fail the session will be invalidated (retry mechanism are to be described at PSM level introducing a Logical Push mapping iterated for a maximum number of times)

Information Management

Operating Modes

Available operating mode for Supplier Push is Periodic or Condition Triggered Push (based on Supplier side conditions and interchange agreement on subscription)

Description of Operating Modes is done at general PIM Level, no extra details are needed in this Section for PIM/Exchange Pattern / FEP.

A Payload Push 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 messages.

Description of Operating Modes is done at PIM Level, no extra details are needed in this Section for PIM/Exchange Pattern / FEP.

Lifecycle Management

Description of LifeCycle Management is done at PIM Level.

Lifecycle management to Exchange data among Client and Supplier is embed on Operating Mode and Update Method which had been chosen at Subscription contract.

Push delivery method allows to convey information from Supplier to Client as two different information.

Sampled data can 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 may be done for any operating mode as well with On Occurrence or Periodic Push.

Data Delivery

Data delivery

Session Lifecycle ONLINE section allows to send data when available at 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 Session Lifecycle for Messaging details

Data request

Not implemented in this pattern

Large datasets handling

Not Described at PIM Level, may be defined at PSM level.

Synchronisation

Snapshot Synchronisation and Delta Synchronisation are available in Stateful Push

Snapshot Synchronisation is managed at First Session with a Client or under Client request.

Delta Synchronisation is managed when Session had been once created and closed by Network Error or any other condition, so that not delivered payload data are stored at Supplier side and delivered to Client as soon as Session is again established

Self-Description

Handshake

Not available

Communication

Communication Feature 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, etc.)

Optimisation issues

Bandwidth and Processing Savings

Payload timestamp information is available for Client side processing optimisation made at application level.

Pull message may be generated for all client reducing processing resources at Supplier side

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

Huge dataset handling

Not managed in this EP+FEP