Platform Indepent Model

Platform Indepent Model

Introduction

This Technical Specification defines a common set of data exchange specifications to support the vision of a seamless interoperable exchange of traffic and travel information across boundaries, including national, urban, interurban, road administrations, infrastructure providers and service providers. Standardisation in this context is a vital constituent to ensure interoperability, reduction of risk, reduction of the cost base, promotion of open marketplaces and many social, economic and community benefits to be gained from more informed travellers, network managers and transport operators.

Especially in Europe, delivering Transport Policy in line with the White Paper issued by the European Commission requires co-ordination of traffic management and development of seamless pan European services. With the aim to support sustainable mobility in Europe, the European Commission has been supporting the development of information exchange mainly between the actors of the road traffic management domain for a number of years.

This Technical Specification supports a methodology that is extensible.

To be able to successfully connect systems and start exchanging data, in an interoperable and easy way, there is a need to describe and agree on how the exchange should be done. This is set out in a data exchange specification. Data exchange in different scenarios can have different needs and requirements. Therefore, several data exchange specifications can be needed.

Data exchange specifications need to address two main issues. First, they must model the stakeholders and actors involved in data exchange – each potentially in different roles – as well as abstract exchange patterns for their interactions. Second, they must select a suitable implementation platform and clearly specify how the abstract scenarios and patterns are effectively implemented on this platform.

The following diagram shows such an abstract communication scenario from the perspective of a road operator who requires data exchange interfaces between the different components of its own operational systems – either between centre side components or between centre and field devices – but also to exchange information with other road operators or service providers.

../_images/abstractcommunicationscenario_exchange_pim.jpg

Abstract communication scenario

While the black links between centre side components and field devices may use a variety of communication protocols – mostly depending on the physical link conditions – the vast majority of other coloured links between centre - side components – internal to one organisation or external to others – is based on an IP network and mostly use the TCP transport layer protocol (UDP is also possible in a few cases).

Nevertheless – as the different colours indicate – they can very well have significantly different requirements. Internal links (blue) can reside in one domain of trust, hence do not require protocols compatible with security gateways. This can already be different for links to other road operators (red) and will certainly not hold for links to other types of organisations – like service providers – via the Internet (green).

While different security requirements offer the most striking and obvious example, there are more criteria that can lead to different preferences on different types of links, e.g. scalability, robustness, integration complexity, etc.

In broad terms, the colours blue – red – green form a hierarchy from more internal, closely-coupled, well-integrated systems towards external, loosely-coupled and non-integrated systems. The world of information and communication technology (ICT) offers a broad range of solutions for these different scenarios, offering different advantages and disadvantages. It is obvious that the one-size-fits-all principle will not provide the most efficient way of working here. Even on the highest level of abstraction and inside the ICT domain itself, we already find a well-known battle of paradigms between remote-procedure-call (RPC) type service specifications and RESTful architectures. The same clusters of options are found in the domain of ITS standards, where for example the European standard for the real-time information interface relating to public transport operations (SIRI – EN 15531 series [6]) introduces both concepts as complementary options: Publish-Subscribe and Request-Response.

The drafting of this Technical Specification was guided by the following principles:

  • Interoperability, such that different implementations can successfully engage in a data exchange process;
  • Support legacy implementations which are based on existing (exchange) specification, in order to maximize investments already made by stakeholders;
  • Address other user profiles, not only road operators, and thus make this Technical Specification available to a broader audience;
  • Reuse of existing (communications) standards, in order to reduce implementation complexity and take benefit of proven and already existent solutions for common ICT problems;
  • Clear separation between the payload content and the exchange model.

The informative Annex A details more the adopted methodology for defining this Exchange Platform Independent Model.

Scope

The scope of this Technical specification is to define and specify component facets supporting the exchange and shared use of data and information in the field of traffic and travel.

The component facets include the framework and context for exchanges, the data content, structure and relationships necessary and the communications specification, in such a way they are independent from any defined technical platform.

This Technical Specification establishes specifications for data exchange between any two instances of the following actors:

  • Traffic Information Centres (TIC),
  • Traffic Control Centres/Traffic Management Centres (TCC/TMC),
  • Service Providers (SP).

Use of this Technical Specification may be applicable for use by other actors like e.g. car park operators….

This Technical Specification includes the following types of information:

  • The use cases and associated requirements, and features relative to different exchange situations,
  • The different functional exchange profiles,
  • The abstract elements for protocols,
  • The data model for exchange (informational structures, relationships, roles, attributes and associated data types required).

In order to set up a new technical exchange framework, it is necessary to associate one functional exchange profile with a technical platform providing an interoperability domain where plug-and-play interoperability at technical level can be expected. The definition of such interoperability domains is not part of this Technical Specification but can be found in other standards or technical specifications like in ISO 14827-3. This Technical Specification is restricted to data exchange, definition of payload content models being beyond its scope.

Conformance

tbd

Terms and definitions

Term Definition Notes
business scenario 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 See also Use Case.
client entity that receives the information It is represented in the Information Delivery business scenario,
Functional Exchange Profile (FEP) selection of data exchange features for a particular Business Scenario  
HTTP Server software application that provides content to client applications by using the HTTP protocol  
interoperability domain pair of FEP and platform selected for implementing a data exchange subsystem Each PSM document defines an Interoperability Domain, which ensures that two implementations of this PSM are interoperable and can successfully exchange payload.
payload content model / content model bundle of information that is exchanged between two exchange systems containing an instance of the content model  
Platform Independent Model (PIM) document describing the abstract model of the standardised data exchange process in a platform independent way This definition is specific to this Technical Specification.
Platform Specific Model (PSM) document providing the implementation details of a FEP described in the PIM for a concrete platform This definition is specific to this Technical Specification.
profile-to-platform mapping act of defining an Interoperability Domain  
Pub / sub Publish-Subscribe pattern  
pull exchange situation where the exchange of information is originated by the client  
push exchange situation where the exchange of information is originated by the supplier  
Supplier entity that provides the information It is represented in the information delivery business scenario.
Use Case set of operational interactions between entities (called actors) and a system to ease understanding the main functions behind such interactions  

Symbols and abbreviated terms

ASN.1 Abstract Syntax Notation One
BUC Business use case
HTTP Hyper-Text Transfer Protocol
ICT Information and Communication Technology
IP Internet Protocol
ITS Intelligent Transport Systems
MDA Model Driven Architecture
REST Representational State Transfer
RPC Remote Procedure Call
SOAP Simple Object Access Protocol
TCP Transmission Control Protocol
UDDI Universal Description Discovery and Integration
UDP User Datagram Protocol
UML Universal Modelling Language
NOTE Specified in ISO/IEC 19505 series (2012)
W3C World wide web consortium
WSDL Web Service Definition Language
WSIL Web Services Inspection Language
WSS Web Services Security
XML eXtensible Markup Language

Exchange Modelling Framework

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.

image0

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.

image1

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:

image2

Figure 4 — General Data Delivery Business Scenario actors

Assuming the definitions in following Table:

Name Definition
Supplier System A system which gathers information (Road Information) which has to be conveyed to another system named Client System. Examples of Supplier Systems may be Traffic Control Centres or Traffic Information Centres or Service Providers Systems, gathering road data by any available source they have.
Client System A system which needs to update its internal information based on information which is available at another Systems named Supplier. Example of Client Systems are Traffic Control Centres or Traffic Information Centres or Service Providers Systems
Exchange Environment The set of components which enable information Exchange among Client System and Supplier Systems via DATEX protocol
Supplier The component of Exchange Environment which is devoted to provide Data to Client, retrieving them from Supplier System
Client The component of Exchange Environment which is devoted to collect Data from Supplier, delivering them to the Client System

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.

Note

A Functional Exchange Profile is a different concept from content profile. The description of the content profiles that may exist in an information delivery scenario is not in the scope of this TechnicalSpecification. Content profiles are handled in respect to whatinformation is exchanged.

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

Note

In the FEP+EP PIM description by Sequence Diagram any UML interactions that are not on the link between client and supplier are illustrative only - there is no obligation on a PSM to specify a mapping for those.

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.

image3

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

Simple Push

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)

Features Area Feature Simple Push available
Subscription Contract Contract N
  Catalogue N
Session Session life cycle N
  Link Monitoring Y
Information management Operating modes Periodic / On Occurrence based on triggering of Supplier condition
  Update methods Snapshot, Single Element Update, All Element Update
  Lifecycle management Y
Data delivery Data delivery Y
  Data request N
  Large datasets handling N
  Synchronisation Y, optional
Self-Description handshake N
Communication Security At PSM Level
  Compression At PSM Level
  Communication At PSM Level

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.

image11

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.

image12

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.

Interaction Message

direction

Supplier Client

designation description Exchanged information Optional
Payload Push Direct putData Push Delivery of Payload, which has to be delivered from Supplier to Client. Exchange information such as Client and Supplier identification and Exchange Status may be provided to easy controls Payload + Exchange Information (MessageContainer) N
Snapshot Payload Push Direct putSnapshotdata Push Delivery of current available Payload, i.e. Snapshot after a First Initialised Session in caso of first connection or after an explicit Snapshot realignment request from the Client. Exchange information such as Client and Supplier identification and Exchange Status may be provided to easy controls. Snapshot Payload + Exchange Information (MessageContainer) Y
Keep Alive Direct keepAlive Test Exchange Link and confirm Session Validity when no Payload Push update is needed, Exchange information such as Client and Supplier identification and Exchange Status may be provided to easy controls and supplier identification. Exchange Information N
Exchange Information Return Return Exchange Infomation Exchange information is returned from Client to supplier to provide Return status i.e. Success, Fail, Snapshot Synchronisation Request and to easy controls such as Supplier and Client Identification. Exchange Information N

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

image15

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

Snapshot Pull

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)

Features Area Feature Snapshot Pull available
Subscription Contract Contract N
  Catalogue N
Session Session life cycle N
  Link Monitoring N
Information management Operating modes Periodic or On Occurrence (i.e. Triggered by Client Condition)
  Update methods Snapshot
  Lifecycle management Y, based on snapshot: new and updated content delivered, outdated data not delivered.
Data delivery Data delivery Y
  Data request N
  Large datasets handling N
  Synchronisation Y
Self-Description handshake N
Communication Security To be defined at PSM Level
  Compression To be defined at PSM Level
  Communication To be defined at PSM Level

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.

image4

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

image5

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

Note

Depending on implementation (e.g. http /get of XML static files generated at Supplier side) the payload message may be generated by the Supplier based on condition on supplier side (e.g. event update or data gathered at supplier side). In those cases, extra information could be available to implement some optimization such as bandwidth saving not transferring the same data in case no update had been generated.

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.

image6

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

image7

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

Snapshot Push

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)

Features Area Feature Snapshot Push available
Subscription Contract Contract N
  Catalogue N
Session Session life cycle N
  Link Monitoring N
Information management Operating modes Periodic or On Occurrence (i.e. Triggered by Supplier Condition)
  Update methods Snapshot
  Lifecycle management Y, based on snapshot: new and updated content delivered, outdated data not delivered.
Data delivery Data delivery Y
  Data request N
  Large datasets handling N
  Synchronisation Y
Self-Description handshake N
Communication Security To be defined at PSM Level
  Compression To be defined at PSM Level
  Communication To be defined at PSM Level

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.

image8

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.

image9

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.

image10

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

Stateful Push

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)

Features Area Feature Stateful Push available
Subscription Contract Contract N
  Catalogue N
Session Session life cycle Y
  Link Monitoring Y
Information management Operating modes Periodic / On Occurrence based on triggering of Supplier condition
  Update methods Snapshot, Single Element Update, All Element Update
  Lifecycle management Y
Data delivery Data delivery Y
  Data request Snapshot realignment
  Large datasets handling N
  Synchronisation Y
Self-Description handshake N
Communication Security At PSM Level
  Compression At PSM Level
  Communication At PSM Level

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.

image16

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.

image17

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.

Interaction Message

direction

Supplier Client

designation description Exchanged information Optional
Open Session Direct openSession Supplier initialise a push delivery Session. Exchange Information N
Payload Push Direct putData

Push Delivery of Payload, which has not been yet delivered from Supplier to Client.

It SHALL contain in Exchange information the Session ID, previously obtained with OpenSession, referring which session it is pushing data.

Payload +

Exchange Information

(MessageContainer)

N
Snapshot Payload Push Direct putSnapshotdata Push Delivery of current available Payload, i.e. Snapshot after a First Initialised Session in caso of first connection or after an explicit Snapshot realignment request from the Client. It SHALL contain in Exchange information the Session ID, previously obtained with OpenSession, referring which session it is pushing data..

Snapshot Payload +

Exchange Information

(MessageContainer)

N
Keep Alive Direct keepAlive

Test Exchange Link and confirm Session Validity when no Payload Push update is needed.

It SHALL deliver the Session ID of a previously opened Session, wrapped in Exchange Information.

Exchange Information N
Close Session Direct closeSession Message to gracefully close a delivery Session, initiated by the Supplier Exchange Information N
Exchange Information Return Return Exchange Information Exchange information is returned from Client to supplier to provide Return status i.e. Success, Fail, Snapshot Synchronisation Request and to easy controls such as Supplier and Client Identification. Exchange Information N

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.

image18

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.

image19

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.

image20

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