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