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.
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:
The informative Annex A details more the adopted methodology for defining this Exchange Platform Independent Model.
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:
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:
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.
tbd
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 |
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 |
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.
This Technical Specification is based on business scenarios, i.e. high-level description of the interactions that can exist within a system being analysed or between the system and external entities (called actors) in terms of business functions. Derived from requirements a business scenario has on information as well as technical parameters, Functional Exchange Profiles (FEPs) are identified to ensure interoperable services with the restriction of determining one FEP per business scenario for a specific technical platform. One FEP can support more than one business scenario.
Figure 2 — Business scenario and Functional exchange profile
This version of the Technical Specification addresses the following business scenario:
Other business scenarios can be developed in future versions using the same methodology.
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:
Exchange is defined through Features which implement the Information Exchange and fulfils Data Exchange requirements.
Depending on many possible Exchange Platform considered for implementation, a subset of features and relative requirements is possible to be implemented. To fulfil a set of requirements many Platform are possible, but to be interoperable client and supplier shall implement the same platform with the same pattern. Allowing a wide variety of possible Exchange Pattern, the best suitable for an application may be chosen, according to requirements which fulfilment is granted by the selected Exchange Pattern.
Based on the requirements of a specific Business Scenario, a set of appropriate exchange features has to be combined into a Functional Exchange Profile (FEP).
The following schema represent the domains of PIM and PSM introducing Exchange Pattern EP and Functional Exchange Profile FEP.
Figure 3 — Business scenario and Functional exchange profile
One of the most common applications of a data exchange system is the exchange of traffic and travel information between two nodes. In such a scenario, one node acts as the supplier of the information while the other acts as the intended receiver of that information, i.e. the client.
EXAMPLE It is done by using the form of the European DATEX II publications
The Data Delivery Business Scenario consider the actors as defined in the following figure:
Figure 4 — General Data Delivery Business Scenario actors
Assuming the definitions in following Table:
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.
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.
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.
In the following chapters PIM for Exchange Pattern/FEP will be described for the following Platform
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.
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:
The normative Annex B provides a description of all requirements that can exist for specific Business Scenario including Collaborative Information Services
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
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 context diagram below (Figure 5) shows the topics broken up into boxes representing the exchange features and the relation with each layer.
Figure 5 - Context diagram
The features that support the requirements defined by use cases specified in this Technical Specification are detailed below:
Subscription contract – Supports all features related to the contract or agreement, such as:
Table 1 — Subscription contract: features and requirements
Features | Requirement Type | Requirement Name |
---|---|---|
Contract | Information | Subscription |
Client profiles | ||
Filter handling | ||
Catalogue | Information | Catalogue exchange |
Session – The session feature group supports all features related to the establishment of a logical session.
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 |
Information management - Handles the features related to management of the information, includes features such as:
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 |
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:
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 |
Communication – Handles all features related to the protocol closest to the physical layer. It is used by the application for the transport of messages.
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 |
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 |
We resume from Information Delivery Business Scenario description and definition that data exchange is needed to align the information kept by the Supplier System into the Client System, for this purpose an Exchange Systems is used which provides tools which enables messages generation and transfer among Supplier and Client.
Figure 6 — Snapshot Pull Exchange actors
The “Snapshot Pull” exchange pattern can be described by the following behaviours
The Supplier provides a mechanism to retrieve current data, also called “snapshot” of information, normally for a specific payload, i.e. current information content of Client System or Last retrieved information for Sampled data (see Annex F ).
Figure 7 — Snapshot Pull Exchange subsystems and interfaces interactionsand method
This mechanism is referred in this document as “pullData”.
The Client takes the initiative to retrieve the data based on its needs, normally when some condition defined at Client side are triggered or in a periodic way; specifically:
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.
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.
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:
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.
Managed offline, not automated.
No Session is managed for the current EP+FEP.
Link monitoring is not managed for the current EP+FEP.
Available operating mode for Client Pull is Periodic or On Occurrence (i.e. Condition Triggered based on client) Pull based on Client side conditions.
Available updated method is Snapshot, i.e. retrieval of only currently valid data.
Currently available information is included in the payload at Supplier System to prepare for Delivery Messages, this can be done at timeout on a cycle basis or at specific condition triggering as “data updated” condition.
For lifecycle management information, snapshot include all active information, outdated information is not delivered in content.
For sampled information the snapshot information contains last sampled data available at supplier site.
Whenever a condition is raised the Supplier System may trigger this to the Supplier to manage creation of Pull Message.
Figure 8 — Snapshot Pull Sequence Diagram Information management at Supplier side
Information Management for Snapshot Pull may be implemented as follows: when client gets snapshot of last updated/created items including all active items, it has to check for information which has been removed from payload to imply it had been invalidated (i.e. closed or cancelled)
The sequence Diagram for Data Delivery is as follows
Figure 9 — Snapshot Pull Sequence Diagram for Data retrieval: implicit Data Delivery
Pull message generation processing is optional based on chosen Platform Technology
Not implemented in this pattern
Not described in this pattern at PIM Level ( it may be implemented at PSM level see Optimisation Section).
Implicit synchronisation is available as only currently current available elements are retrieved by Snapshot Pull
Not available
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.)
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.
Not managed in this EP+FEP
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 |
We recall from Information Delivery Business Scenario description and definition that Data Exchange is needed to align the information kept bythe Supplier System into the Client System, for this purpose an ExchangeSystems is used which provides tools which enables messages generationand transfer between Supplier and Client.
Figure 10 — Snapshot Push Exchange actors
The “Snapshot Push” exchange pattern can be described by the following behaviours
The Client provides a mechanism to receive data from action taken at Supplier site invoking specific resources / methods offered by Client. Supplier so logically “pushes” Messages to the Client. The Client shall acknowledge what received by a Return Information to the Supplier. This return message is available to bring some information back from Client to the Supplier.
Figure 11 — Snapshot Push Exchange subsystems and interfaces interactions and method
The Client provides a mechanism to the Supplier to push currently available data, also called “snapshot” of information, i.e. current information content at Supplier System or Last retrieved information for Sampled data (see Annex F ).
This mechanism is referred in this document as “putSnapshotData”.
The Supplier takes the initiative to deliver the data to the Client based on some rules, normally when some condition defined at Supplier side are triggered or in a periodic way; specifically:
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.
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:
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.
Managed offline, not automated.
No Session is managed for the current EP+FEP.
Link monitoring is not managed for the current EP+FEP.
Available operating mode for Snapshot Push is Periodic or On Occurrence (i.e. Condition Triggered based on supplier) Push based on Supplier side conditions.
Available updated method is Snapshot, i.e. retrieval of only currently valid data.
Currently available information is included in the payload at Supplier System to prepare for Delivery Messages, this can be done at timeout on a cycle basis or at specific condition triggering as “data updated” condition.
For lifecycle management information, snapshot include all active information, outdated information is not delivered in content.
For sampled information the snapshot information contains last sampled data available at supplier site.
Whenever a condition is raised the Supplier System manage creation of Push Message and deliver it.
Figure 12 — Snapshot Push Sequence Diagram Information management at Supplier side
Information Management for Snapshot Push may be implemented as follows: when client gets snapshot of last updated/created items including all active items, it has to check for information which has been removed from payload to imply it had been invalidated (i.e. closed or cancelled)
The sequence Diagram for Data Delivery is the same as previous figure
Not implemented in this pattern
Not described in this pattern at PIM Level. May be implemented at PSM level see Optimisation Section.
Implicit synchronisation is available as only currently current available elements are retrieved by Snapshot Poll
Not available
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.)
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.
Not managed in this EP+FEP
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 |
We recall from Information Delivery Business Scenario description and definition that Data Exchange is needed to align the information kept by the Supplier System into the Client System, for this purpose an Exchange Systems is used which provides tools which enables messages generation and transfer among Supplier and Client.
Figure 13 — Simple Push Exchange actors
The “Simple Push” exchange pattern can be described by the following behaviours
The Client provides a mechanism to receive data from action taken at Supplier site invoking specific resources / methods offered by Client.
Supplier so logically “pushes” Messages to the Client. The Client shall acknowledge what received by a Return Information to the Supplier. This return message is available to bring some information back from Client to the Supplier, such as, Fail, Success, Snapshot Synchronisation Request. Return message information is logically described in this PIM, while implementation will be defined at PSM, level.
Figure 14 — Simple Push Exchange subsystems and interfaces interactions and method
The mechanisms available are referred in this document as “putData”,”keepAlive” and optional “putSnapshotData”.
Simple Push actually pushes available information or available updated information to the Clients, but do not keep track of what has been delivered to specific Clients. For specific use cases such as delivery of stateful information (e.g. situation payload information), a first snapshot may be useful and may be delivered to client based on information to be exchanged or explicit client request in return code. This feature is optional in this FEP+EP PIM. Based on previous optional requirement Exchanged data can either be current available data, also called “snapshot” of information, or, when a synchronisation is not needed such as for stateless information ( e.g.Road Data) , a set of information which had changed since the last Push may be exchanged to align the Information status on the Client System. Those messages may include single updated element or all updated elements depending on Update Method chosen.
The Supplier takes the initiative to push the data under the following conditions:
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.
Some not mandatory information should be managed in the Exchange Information to easy application development are fully described in Basic Exchange Data Model:
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 |
The Supplier initiate the communication and is made aware of Client Status based on Client Return response to the Supplier
The following diagram describes the Client status as monitored and managed by the Supplier.
Figure 15 – Supplier Side Simple Push State Diagram
Special management for initialisation and termination of Push Process to specific Client are to be considered at application development level in supplier and Client Systems.
The following diagram describes the Supplier status as monitored and managed by the Client.
Figure 16 — Simple Push State Diagram Client side
Special management in initialisation and termination of Push Process are to be considered at application level in Supplier and Client System.
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:
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.
Managed offline, not automated.
No Session is managed for the current EP+FEP.
Link monitoring is done by Push Payload and Keep Alive. When data is available a Payload Push is exchanged which also inform client and supplier if session and systems status: Push received from Supplier on Client Side and return of Push on Payload push on Supplier side guarantees the network is available and the systems are up and running.
When no data is available to Supplier and a timeout is expired a KeepAlive Message is exchanged to check network and system availability.
In case Payload Push or KeepAlive fails or timed out the Supplier assumes the Client is Offline and keep trace of this status for any management purposes at Supplier System side (for delivery retry mechanism are to be described at PSM level defining a Logical Push mapping iterated for a maximum number of times).
Figure 17 - Simple Push Sequence Diagram for Link Monitoring and Data Delivery
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
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.
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.
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
Not implemented in this pattern
Not Described at PIM Level, may be defined at PSM level.
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.
Not available
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.)
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.
Not managed in this EP+FEP
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 |
We recall from Information Delivery Business Scenario description and definition that Data Exchange is needed to align the information kept by the Supplier System into the Client System, for this purpose an Exchange Systems is used which provides tools which enables messages generation and transfer among Supplier and Client.
Figure 18 — Stateful Push Exchange actors
The “Stateful Push” exchange pattern can be described by the following behaviours
The Client provides a mechanism to receive data from action taken at Supplier site invoking specific resources / methods offered by Client.
Supplier so logically “pushes” Messages to the Client. The Client shall acknowledge what received by a Return Exchange Information to the Supplier. This Exchange Information return message is available to bring some information back from Client to the Supplier, such as SessionId, Fail, Success, Snapshot Synchronisation Request. Return message information is logically described in this PIM, while implementation will be defined at PSM, level.
Figure 19 — Stateful Push Exchange subsystems and interfaces interactions and method
The mechanisms available are referred in this document as openSession, “putData”, “keepAlive” and optional “putSnapshotData”, closeSession.
Exchanged data can either be current available data, also called “snapshot” of information, or, after a first transfer of currently valid data, i.e. a snapshot, a subset of information which had changed since the last Push may be exchanged to align the Information status on the Client System. Those messages may include single updated element or all updated elements depending on Update Method chosen.
The Supplier takes the initiative to push the data under the following conditions:
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.
Extra information is needed to grant Exchange Features implementation besides return messages which are only logically described.
Some not mandatory information should be managed in the Exchange Information to easy application development are fully described in Basic Exchange Data Model:
Payload Information
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 |
The Supplier initiate the communication and may be aware of Client Status based on Client Return response to the Supplier
The following diagram describes the Client status as monitored and managed by the Supplier.
Figure 20 - Stateful Push State Diagram Supplier side
Specific management for initialisation and termination of Push Process to specific Client are to be considered at application development level in supplier and Client Systems.
The following diagram describes the Supplier status as monitored and managed by the Client.
Figure 21 — Stateful Push State diagram Client side
Specific management in initialisation and termination of Push Process are to be considered at application level in Supplier and Client System.
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:
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.
Managed offline, not automated.
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:
In case no payload is available a Keep Alive message is used to check session status for Supplier and Client.
When no KeepAlive message or no Payload is received, after a KeepAlive timeout the client invalidate the session on its side and return Close Session to any attempt of Push from the Supplier.
If any Push or Keep Alive fails, the Supplier invalidate the session and start a new loop to Open Session.
Realignment Messages are managed when a Session is Opened, Snapshot Synchronisation request from the Client is returned in Open Session when needed. Further any Snapshot Synchronisation may be asked from Client in any Push Return as well, but this does not close a Session.
Any message and return in the Sequence Diagram will be mapped in PSM definition to real platform available implementation such as WebService Service request and return or any other available mechanism in a specific Platform.
Figure 22 — Stateful Push Sequence Diagram for Session Lifecycle and Data Delivery
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)
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
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.
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.
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
Not implemented in this pattern
Not Described at PIM Level, may be defined at PSM level.
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
Not available
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.)
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.
Not managed in this EP+FEP