The Platform Independent Model (PIM) part 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 model 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 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 select a suitable implementation platform and clearly specify how the abstract scenarios and patterns are effectively implemented on this platform. The diagram in Figure 1 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.
Figure 1 - 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.
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.
As well, the ITS station architecture is not in contradiction with this document but is complementary of what is defined in this document. According to the principles and the taxonomy defined in ISO 21217, this document defines a conceptual notion of:
This document specifies the process of defining the exchange characteristics by use case-driven feature selection of relevant parameters for the relevant OSI layers as defined in ISO 21217. Two exchange schemas are considered: Information delivery and Functional service negotiation between central ITS stations.
The informative Annex A details more the adopted methodology for defining this Exchange Platform Independent Model.
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 |
Collaborative ITS Services | collaborative ITS services are ITS Services which can be enabled by combing different “ITS Services” which are provided by combined effort of two or up to several stakeholders which may have different roles. | It is represented in the Information Delivery business scenario |
Exchange Pattern (EP) | the basic exchange architecture template, described by UML communication diagrams, which identifies the actors in the exchange framework and the available interactions among them, which enable data exchange functionalities as a set of exchange features | |
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 | UML definition of the data structures that can be used to describe travel and traffic information to be exchanged in an exchange system | |
payload publication / payload | 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 part. |
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 part. |
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 | |
simple push | push-based exchange pattern where that does not require state to be maintained | |
snapshot | set of data providing all of the last known state as opposed to providing partial changes | This definition is specific to this part. |
snapshot pull | pull-based exchange pattern where only the last snapshot version is exchanged | This definition is specific to this part. |
snapshot push | push-based exchange pattern where only the last snapshot version is exchanged | This definition is specific to this part. |
stateful push | push-based exchange pattern where data describing a communication session is maintained across successive communication within that session | This definition is specific to this part. |
Supplier | entity that provides the information | It is represented in the information delivery business scenario. |
Use Case (UC) | 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 |
TCC | Traffic Control Center |
TMC | Traffic Management Center |
TIC | Traffic Information Center |
TCP | Transmission Control Protocol |
TMP | Traffic Management Plan |
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 |
The model driven approach is chosen to describe exchange: this leads to describe exchange systems by means of abstract models which are named platform independent model (PIM), in which modelling of exchange features is done by describing interaction among systems and subsystems as exchange patterns (EP). These interactions implement system capabilities as features which fulfil exchange requirements requested by specific business scenarios which are used to describe specific uses of exchange.
This document is based on business scenarios, i.e. a high-level description of the interactions that can exist within a system being analysed or between the system and external entities (called actors) in terms of business functions. Business scenarios are derived from application requirements on useful business information needed and on technical capabilities enabled by available technologies. FEPs are identified to ensure interoperable services with the restriction of determining one FEP per business scenario for a specific exchange pattern, which are abstract model of available technical platforms.
One business scenario can be supported by more then one FEP which can be enabled by several EP (Figure 2).
Figure 2 — Business scenario and Functional exchange profile
This version of the Technical Specification addresses the following business scenario:
Other business scenarios can be developed in future versions using the same methodology.
Requirements can vary depending on data exchange applications, i.e. use cases to be fulfilled, so there are many reasons to consider or not any requirement based both on the gathering of data at supplier system and the usage of the delivered data in the client.
Requirements address the following items:
Exchange is defined through enabling features which fulfils data exchange requirements.
Many possible technical exchange platform are possible, each of which can enable subset of requirements in different ways. To be interoperable a client and a supplier shall implement the same platform with the same pattern. Allowing a wide variety of possible exchange patterns, the best suitable for an use case application is chosen, in order to fulfils the needed set of requirements.
Based on the requirements of a specific business scenario selected for application use cases implementation, a set of appropriate exchange features shall be combined into a FEP.
The following schema in Figure 3 represent the domains of PIM and PSM introducing exchange pattern (EP) and FEP.
Figure 3 — Business scenario and Functional exchange profile
One of the most common applications of a data exchange system is the exchange of traffic and travel information between two nodes. In such a scenario, one node acts as the supplier of the information while the other acts as the intended receiver of that information, i.e. the client.
EXAMPLE: It is done by using the form of publications, e.g. in the European DATEX II.
The data delivery business scenario considers the actors as defined in Figure 4:
Figure 4 — General Data Delivery Business Scenario actors
The following Table provides the basic definitions for exchange:
Name | Definition |
---|---|
Supplier System | A system which gathers information (road information) which needs to be conveyed to another system named client system. Examples of supplier systems are traffic control centres or traffic information centres or service provider systems, gathering road data from any available source they have. |
Client System | A system which needs to update its internal information based on information which is available from another system named supplier. Examples of client systems are traffic control centres or traffic information centres or service provider systems. |
Exchange Environment | The set of components which enables information exchange among client systems and supplier systems via a data exchange protocol. |
Supplier | The component of exchange environment which is devoted to providing data to client, retrieving them from supplier system. |
Client | The component of exchange environment which is devoted to collecting data from supplier, delivering them to the client system. |
Road and traffic information is gathered in a system which is named “Supplier System”. In case this information is needed by another system, named “Client System”, for any purpose, it has to be transferred among the two systems by the exchange environment.
The data delivery business scenario describes the exchange pattern and messages which are needed to be exchanged among supplier and client systems besides the underneath technology and exchange pattern. The purpose for which information is exchanged is not considered in this use case description.
As explained in the information delivery background in Annex F , any update of information status at the supplier system shall be replicated to the client system via information delivery. The main objective of information delivery is that information on the client system is updated exactly in the same way as it is in the supplier system without any difference in information values and semantics.
“Exchange message” is defined as the data structure in which the information is coded to transfer information in the exchange system from the supplier to the client.
Assuming Sc = Client status, Ss = Supplier status, exchange is a mean to have Sc equivalent to Ss,
Formally:
Ss >> Information >> Supplier >> Exchange Message >> Client >> Information >> Sc
i.e. Client System Status is updated in equivalent mode as Supplier System Status by means of Data Delivery Exchange Messages through Supplier and Client.
Information delivery business scenario scope is implemented by selected exchange features which enable this scope and other secondary requirements which are based on available features on considered platforms and patterns.
The normative Annex B provides a description of all requirements that can exist for specific Business Scenario including Information Delivery whether they are used in a particular functional exchangeprofile or not. All requirements are organised into groups based ontheir characteristics.
Note
A FEP is a different concept from content profile. The description of the content profiles that can exist in an information delivery scenario is not in the scope of this document. Content profiles are handled in respect to which information is exchanged.
For data delivery the concept of ”EP” is introduced, as well as PIM and FEP. These are defined as in Terms and definitions in the introduction.
Examples of exchange pattern are the GET method of HTTP, Pull, Push, PubSub, etc.
Once an exchange pattern and a selection of features (FEP) which can be implemented on this exchange pattern are set, a set of specification at PIM level for EP+FEP is well defined.
A PIM for EP+FEP that enables all mandatory requirements is a valid platform for the corresponding business case (information delivery or collaborative ITS services).
In the following chapters PIM for Exchange Pattern/FEP will be described for the following platform:
The normative Annex E details the features of the main FEPs considered in this document for the corresponding exchange pattern.
A service is any processing of data which enable a value to the data themselves.
In ITS fieald “ITS Services” can be considered as the processing of information to address specific requirement such as to manage traffic, deliver information.
“Collaborative ITS services” (CIS) are “ITS Services” which can be enabled by combing different “ITS Services” which are provided by several stakeholders which may have different roles (e.g. Traffic Management Centers, Traffic Information Centres, Service Providers).
CIS exchange specification explore user requirements and define common techniques to address them to implement collaborative “ITS services” by different centres. They are based on exchanging information to be processed by the different nodes and receiving the processing outcomes (feedback), giving a simple mechanism, upon which it could be possible to build more sophisticated workflows, enabling to coordinate operations distributed among many centres.
In CIS business scenario the exchange of information among centres is considered as a base mechanism to trigger specific processing and to provide services on this data, so the data exchange layer is to be considered as an “ITS services” enabler.
“ITS Services” description is out of the scope of this document: a detailed description of possible usage of CIS detailed in informative Annex G .
Example of “ITS Service” in the different “ITS domain” are:
The involved systems, which in data delivery had been considered as supplier and client, can be considered in this paradigm respectively as service requester and service provider.
At application level, for implementing a business case, such as management of TMP, workflow management is usually requested; this could be a simple workflow (one shot request and acceptancs or rejection) or a more complex one: complex workflow modelling at application level is out of the scope of this document. This document provides the essential tools as building blocks to implement such simple workflow to a raise service request and provide feedback as exchange of payload to be processed and processing results.
CIS enabling mechanism:
CIS main characteristics are as follows:
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 informational (payload) content. This extra information, named exchange information, enables messages to convey information and data which are related to client and supplier status, identity, authorisation, etc.
Exchange information could be different among EP+FEP selection, but some common general information models are considered, which can be specialised to manage specific exchange pattern and PIM.
A general UML model for managing a minimum set of information for exchange is provided in Annex C
This document defines the features and rules that systems shall implement in order to be able to communicate in the traffic and travel data exchange world.
The context diagram below in Figure 5 shows the entities and the features specified in this document and which need to be addressed by the technical implementations. The diagram presents the features in different layers for communication, message rules and application:
The 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 document are detailed below:
The “Subscription contract”, detailed in the table below, supports all features related to the contract or agreement, such as:
The subscription contract is optional and may include the following features:
Features | Requirement Type | Requirement Name |
---|---|---|
Contract | Information | Subscription |
Client profiles | ||
Filter handling | ||
Catalogue | Information | Catalogue exchange |
The “Session” feature group, detailed in the table below, supports all features related to the establishment of a logical session.
The session feature group is optional and includes the following Features:
Features | Requirement Type | Requirement Name |
---|---|---|
Session life cycle | Communication | Error handling |
Timeout management | ||
Session | ||
Link Monitoring | Communication | Error handling |
Timeout management | ||
Full reliability | ||
Link monitoring and control |
The “Information management” handles the features related to the management of the information, includes features such as:
The “information management” group includes the features listed in the following table.
Features | Requirement Type | Requirement Name |
---|---|---|
Operating modes | Information | Reference datasets for different versions |
Update methods | Information | Full audit trail data delivery (all state changes) |
Lifecycle management | Information | Support for life cycle management |
Support Information Processing | Information | Support for information management |
Support for feedback on information management | ||
Distributed transaction | Information | Distributed transaction |
Distributed atomic transaction |
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:
The “data delivery” group includes features and requirements listed in the next table.
Features | Requirement Type | Requirement Name |
---|---|---|
Data delivery | Information | Extensibility |
Communication | Delivery/response | |
Message sequence | ||
Snapshot data delivery (last known state) | ||
Exchange quality measures (ex. response timestamp) | ||
On occurrence update | ||
Periodic update | ||
Security | Client identification | |
Supplier identification | ||
Information | Incremental data delivery | |
Data request | Information | Extensibility |
Communication | Request/response | |
Message sequence | ||
Snapshot data delivery (last known state) | ||
Exchange quality measures (ex. response timestamp) | ||
On occurrence update | ||
Periodic update | ||
Security | Client identification | |
Supplier identification | ||
Large datasets handling | Information | Data delivered as soon as possible |
Delayed delivery | ||
Multi-part data delivery | ||
Synchronisation | Information | Synchronisation |
Communication | With state supplier | |
Failed data recovery |
Communication – Handles all features related to the protocol (close to the physical layer). It is used by the application for the message transport.
The communication function is responsible for implementing the following features:
Features | Requirement Type | Requirement Name |
---|---|---|
Security | Security | Security (data) |
Integrity | ||
Confidentiality | ||
State the intended recipient | ||
Client authentication | ||
Supplier authentication | ||
Client authorization | ||
Non-repudiation | ||
Compression | Communication | Compression |
Communication | Communication | Timely responses |
Bidirectional communication | Communication | Bidirectional communication |
Exchange patterns which enables features for selected FEP can be described by use of some UML diagrams which describe which actors are involved in the exchange, and the specific interactions among them which enable the features themselves.
Exchange system description assumes external systems like TCC and TMC are external to exchange and exchange agents are the actors which may implement the exchange role of client, supplier, service requester or service provider as defined in the business case.
The Figure 6 describes the main exchange involved actors as well as other interacting actor external to exchange.
Figure 6 — Exchange actors
Systems (e.g. TCC or TMC system) may act both as client or supplier and for exchange purposes, systems need to interact with the exchange agent, of the same client or supplier type, which realise a system interface enabling the exchange features.
Based on multiple option for a system to be a client or supplier for Data Delivery, or a Service Requester or Service Provider for Collaborative ITS Services business scenario, the relative system and interfaces can specialise. Figure 7 and Figure 9 shows the exchange agent and interfaces specialisation respectively for data delivery
Figure 7 — Data Delivery Exchange actors definitions
Figure 8 — Communication: Features and requirements
Figure 9 — CIS Exchange agents definition
Figure 10 — CIS Exchange systems, agents and interfaces
This system, exchange agents and interfaces classes will be used in any of the FEP+EP specification descriptions in the following clauses to describe the provided interfaces and interactions. Each of exchange interface realisation will be implemented as a specific specialisation for its FEP+EP, e.g. Snapshot Push will have its specific “snapshot push” supplier interface”, i.e. the “Snapshot Push Client Interface”, which will be described as a specialisation of the exchange snapshot push client interface. The modelling for a snapshot push client system and its Exchange agent and interface is shown in Figure 11.
Figure 11 — Sample of “Snapshot Push” client system and its Exchange agent and interface
The relevant Communication Diagrams will be introduced in the FEP+EP descriptions in the following clauses. In the description of the interactions among exchange systems and subsystems UML Sequence Diagrams will be used. Interactions among actors and their interfaces are described using the actor themselves, the realised specialised interfaces are not mentioned for schema understanding convenience. Figure 12 is an example of provided Sequence Diagram.
Figure 12 — CIS Exchange actors
State Diagrams can be used as well to specify specific status of exchange operation which will lead to specific interfaces behaviours such as return messages definition and specific interaction provided (e.g. synchronisation, synchronisation request). State Diagram are not needed for understanding in simple cases such as stateless FEP+EP so they will not be described in some FEP+EP descriptions.
The “Snapshot Pull” EP+FEP at PIM level is based on information retrieval by a client from a supplier which delivers a snapshot of information, i.e. all currently available information content, to the client. It can be implemented in several platforms: some examples are XML retrieval of generated XML files by http/get, or supplier exposing a SOAP Web Service method (e.g. named “PULL”), from which currently available data is retrieved by the client.
This “Snapshot Pull” does not manage session life cycle and link monitoring requirements, as well as synchronisation. This feature and related requirements are not considered in this pattern, synchronisation is not needed as implicit when delivering snapshots of currently available information content.
To describe the Snapshot Pull EP+FEP at PIM level all features are described in a general abstract format, independently from the specific technology platform this model will be implemented with (e.g. http/get XML, WebService).
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 |
The information delivery business scenario description and definition states that data exchange is needed to align the information kept by the supplier system into the client system. For this purpose an exchange systems is used which provides tools enabling messages generation and their transfer between supplier and client.
Figure 13 — Snapshot Pull Exchange actors
The “Snapshot Pull” exchange pattern is described in the following subclauses.
In a snapshot pull contex the supplier exchange system provides a mechanism to retrieve currently available and valid data (i.e. a snapshot of information) from action taken at client side, which will invoke this specific mechanism offered by the supplier.
In the context of the “Snapshot Pull” FEP +EP framework, to enable interoperability among client and supplier, all rules defined in this clause apply.
A snapshot pull supplier exchange system shall realise a snapshot pull supplier interface wich provides a ” ” method which implements the snapshot pull mechanism.
A snapshot pull client exchange system shall realise a snapshot pull client interface which invokes the “pullSnapshotData” Method provided by the snapshot pull supplier interface to retrieve snapshot data.
Figure 14 shows the communication diagram for Snapshot Pull FEP + EP.
In this FEP+EP framework the client “pulls” messages from the supplier.
The client shall deliver in the pull request no information to the supplier
The Supplier shall retun the client pull request by delivering a “MessageContainer” information which includes ExchangeInformation.
Note
This return message is available to bring some information from the client to the supplier, e.g. exchange information, which may be used for any further exchange features implementations or application level checks or processing which are out of scope of this FEP+EP specification.
Figure 14 — Snapshot Pull exchange subsystems, interface interactions and methods
The client takes the initiative to retrieve the data based on application level requirements which determine the needed exchange OPERATING mode (e.g. on occurrence, condition triggered or periodic).
No exchange information is needed in this pattern to implement data delivery features. Nevertheless “Basic Exchange Data Model” has been provided to allow the implementation to deliver more than one payload content on the same message and further information to allow managing extra features not required by the Snapshot Pull exchange.
A “MessageContainer” instance should be retrieved using the basic exchange data model as reported in Figure 14, alternatively a payload may be retrieved without any further information.
Information related to Exchange that should be managed to make application development easier are fully described in basic exchange data model.
Exchange Context information related are:
Dynamic Information information related are:
State diagram are not needed and not developed for stateless FEP+EP as Snapshot Pull.
This subclause provides a description and the corresponding specification for each feature identified in the context diagram, according to the Snapshot Pull exchange architecture. The following features are specified:
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. a condition triggered based on client). Pull-exchange 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 a supplier system to prepare message delivery. It can be done at time-out on a cycle basis or at specific triggering condition as “data updated” condition.
For life cycle management information, a snapshot includes all active information, outdated information is not delivered in content.
For sampled information the snapshot information contains last sampled data available at supplier site.
Whenever a condition is raised the supplier system triggers it to the supplier to manage the creation of a payload pull delivery message (see Figure 15).
Figure 15 — Snapshot Pull Payload delivery creation: information management at supplier side
Information management for Snapshot Pull at client side is implemented as follows: when a client gets a snapshot of the last updated/created items it includes all valide active information: information which had been delivered and which is not available in the last delivered payload shall not be considere after last devlivery, i.e. it had been invalidated either as closed or cancelled information.
The sequence Diagram for Data Delivery is as follows
Figure 16 — Snapshot Pull sequence diagram for data retrieval: implicit data delivery
When a pullSnapshotData request is triggered from the client to the interface method on supplier SnapshotPull interface, the corresponding snapshot payload(s) available shall be delivered as return message by the supplier enclosed in a MessageContainer.
..note:: Depending on implementation (e.g. http /get of XML static files generated at supplier side) the payload message is generated by the supplier based on conditions which are only managed by the supplier (e.g. event update or data gathered at the supplier side). In these cases, extra information can be available to implement some optimisation such as bandwidth saving by not transferring the same data in case no update had been generated. This aspects will be describe when applicable for PSM mapping.
..note:: ExchangeInformation delivered in the return message by the supplier may contain any information which can be used to inform the client about client request processing which may be implemented in an optional pullRequest check. A processing for delivery based on client may be implemented by the supplier based on ExchangeInformation and offline subscription agreements. Any processing description for payload delivery based on client which can be implemented on supplier side based on any subscription agreement among client and supplier, are out of scope of this FEP+EP specification.
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
Handshake is not available
Communication features are implemented at PSM level, they are relevant for the specific platform chosen on which the exchange pattern will be implemented (e.g. http/XML, Web Services SOAP, REST, etc.).
Some exchange pattern features of any context diagrams features groups (e.g. information management, data delivery etc.) allow the implementation of general optimisation such as processing saving and bandwith.
Payload timestamp information is available for client-side processing optimisation made at the application level.
Pull message may be generated for all clients reducing processing resources at the supplier-side.
No extra optimisation issues are considered in this EP+FEP.
The “Snapshot Push” exchange pattern / FEP at PIM level is based on pushing information by the supplier to the client delivering a snapshot of information, i.e. all currently available information content, to the client. This exchange pattern can be implemented in several platforms: some examples are XML delivering of generated XML files by http/post, or a client exposing a SOAP web service method (e.g. named “PUSH”) when currently available data can be sent by the supplier to the client.
This “Snapshot Push” does not manage session life cycle and link monitoring requirements, as well as synchronisation, these features and related requirements are not considered in this pattern. Synchronisation is not needed as implicit by snapshot delivering of currently available information content.
To describe Snapshot Push exchange pattern/FEP at PIM level all features are described in a general abstract format, independently from the specific technology platform in which this model will be implemented (e.g. http/get XML, WebService).
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 |
The information delivery business scenario description and definition imply that data exchange is needed to align the information kept by the supplier system into the client system; for this purpose, an exchange system is used which provides tools enabling message generation and their transfer between supplier and client (see Figure 17).
Figure 17 — Snapshot Push Exchange actors
The “Snapshot Push” exchange pattern can be described by the following behaviours
In a snapshot push context the client provides a mechanism to receive data from action taken at a supplier site invoking specific resources / methods offered by the client.
The snapshot push client provides a mechanism to the snapshot push supplier to push currently available data, also called “snapshot” of information, i.e. current information at supplier system or last retrieved information for sampled data (see Annex F ).
In the context of the “Snapshot Push” FEP +EP framework, to enable interoperability among client and supplier, all rules defined in this clause apply.
A snapshot push Client exchange system SHALL realise a snapshot push client interface wich provides a putSnapshotData method.
A snapshot push supplier exchange system SHALL realise a snapshot push Supplier interface which invokes the putSnapshotData Method provided by the snapshot push Client interface to deliver snapshot data.
Figure 18 shows the communication diagram for Snapshot Push FEP + EP.
In this FEP+EP framework the supplier “pushes” messages to the client.
The client shall acknowledge the received message by a return information to the supplier. This return information shall be coded as ExchangeInformation.
Note
This return message is available to bring some exchange information from the client to the supplier which may be used for any further exchange features implementations or application level checks or processing which are out of scope of this document.
The supplier takes the initiative to deliver the data based on application level requirements which determine the needed exchange operating mode (e.g. on occurrence or periodic).
Figure 18 — Snapshot Push Exchange subsystems, interfaces interactions and methods
No extra exchange No extra exchange information is needed in this pattern to implement any described features.
Basic exchange data model has been provided to allow the implementation to deliver more payload contents in the same message and further information to allow managing some extra features not required by the basic “Snapshot Push” exchange. The usage of the exchange data model wrapping is for harmonisation with other exchange patterns such as “Simple Push” or “Stateful Push”.
A container should be retrieved using basic exchange data model as reported in the previous figure, alternatively a payload may be delivered.
An ExchangeInformation is returned to convey information about exchange operation and connection status.
Exchange Context information related are:
Dynamic Information information related are:
State diagram are not needed and not developed for stateless FEP+EP as Snapshot Push.
This subclause provides a description and the corresponding specification for each feature identified in the context diagram, according to the Snapshot Pull exchange architecture. The following features are specified:
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 message delivery; this can be done at time-out on a cycle basis or at specific triggering condition as “data updated” condition.
For life cycle management information, snapshots include all active information, outdated information is not delivered in content.
For sampled information the snapshot information contains last sampled data available at supplier site.
Information management for Snapshot Push is implemented as follows: when client gets snapshot of last updated/created items including all active items, it has to check for information which has been removed from payload to deduce it had been invalidated (i.e. closed or cancelled).
For all clients which have an active subscription, whenever a payload delivery condition is triggered, the supplier system shall manage the creation of a payload push message in a MessageContainer and shall deliver it by its SnapshotPush supplier interface to the corresponding snapshoPush method available via the SnapshotPush client interfaced.
Figure 19 illustrates the sequence diagrams which describes the interaction amont exchange supplier and its clients.
Figure 19 — Snapshot Push Sequence Diagram Information management at supplier side
Information Management for Snapshot Push may be implemented as follows: when client gets snapshot of last updated/created items including all active items, it has to check for information which has been removed from payload to imply it had been invalidated (i.e. closed or cancelled)
Note
Snapshot Push message generation may create different payload based on the client to which messages are to be delivered based on subscription information. Optional payload delivery processing based on ExchangeInformation and client subscriptions information are out of scope of this FEP+EP specification and are not described.
The client may verify the message delivered by the supplier and shall return an ExchangeInformation message to the supplier with information back to the supplier about the delivered message, i.e. return status and exchange status defined in basic exchange data model, which may be processed by the supplier to implemente optional exchange checks.
Note
ExchangeInformation provided by the supplier and client may optionally be checked to implement optional features enabled by Supplier and defined by Supplier and Client in the optional Subscription process which is out of scope of this FEP+EP specification.
Note
ExchangeInformation delivered in the return message by the snapshot push client may contain any information which can be used to inform the snapshot push supplier about any client request processing, which may be implemented in an optional check. Optional processing to deliver payload information based on agreements among client and supplier may be implemented by the supplier based on offline subscription agreements. These processing description and specification are out of scope of this FEP+EP specification.
Not implemented in this pattern
Not described in this pattern at PIM Level. May be implemented at PSM level (see optimisation subclause).
Implicit synchronisation is available as only currently current available elements are retrieved by Snapshot Push.
Handshake is not available
Communication features are implemented at PSM level, they are relevant for the specific platform chosen on which the exchange pattern will be implemented (e.g. http/XML, Web Services SOAP, REST, etc.).
Some exchange pattern features of any context diagrams features groups (e.g. information management, data delivery etc.) allow the implementation of general optimisation such as processing saving and bandwith.
Payload timestamp information is available for client-side processing optimisation made at the application level.
Push message may be generated for all clients reducing processing resources at the supplier-side.
No extra optimisation issues are considered in this EP+FEP.
The “Simple Push” exchange pattern / FEP at PIM level is based on information messages sent or pushed by the supplier to a client. It can be implemented in several platforms: some examples are push of generated XML content by http/post, or client providing a SOAP WebService method “push” by which data can be provided by the supplier to the client.
This “Simple Push” adds extra features to the basic Snapshot Push exchange pattern to manage link monitoring, as well as synchronisation/realignment in case of communication lacks or system maintenance. This mechanism will be detailed at PIM level in the following subclauses.
To describe the exchange pattern/FEP at PIM level all features are described in a general abstract format, independently from the specific technology platform in which this model will be implemented. (e.g. http/get XML, WebService).
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 |
Information delivery business scenario description and definition state that data exchange is needed to align the information kept by the supplier system into the client system; for this purpose, an exchange system is used which provides tools enabling messages generation and their transfer between a supplier and a client (Figure 20).
Figure 20 — Simple Push Exchange actors
The “Simple Push” exchange pattern can be described by the following subclauses
In a simple push context, the client provides a mechanism to receive data from action taken at a supplier site, invoking specific resources / methods offered by the client.
Therefore, the supplier logically “pushes” messages to the client. The client shall acknowledge what is received by a return exchange information to the supplier. This exchange information return message is available to bring information back from the client to the supplier, such as SessionId, failure, success, snapshot synchronisation request. Return message information is logically described in this PIM, while implementation will be defined at PSM level.
The simple push client provides two mechanism to the simple push supplier to push data:
Besides these push data delivery methods the simple push client also provides a “keep alive” method to implement link monitoring capabilities among client and supplier, the keep alive method is used from the supplier to advise the client when no information updates are to be delivered, so the supplier delivers a “keep alive” message to check and enable the client to check that echange systems and network connection are available, despite the supplier doesn’t need to exchange payload content. “Keep Alive messaged are delivered by the supplier to the client, according a time interval which is defined among them.
In the context of this “Simple Push” FEP +EP framework, to enable interoperability among client and supplier, all rules defined in this clause apply.
Any simple push client exchange system SHALL realise a simple push client interface wich provides a putSnapshotData, a putData and a keepalive method.
Any simple push supplier exchange system SHALL realise a simple push supplier interface which can invoke the putSnapshotData, putData, keepAlive methods provided by the simple push Client interface to deliver data or snapshot data and information to implement link monitoring.
Figure 21 shows the communication diagram for simple push FEP + EP.
In this FEP+EP framework the supplier “pushes” messages to the client.
The client shall acknowledge the received message by a return information to the supplier. This return information shall be coded as ExchangeInformation.
Note
This return message is available to bring some exchange information from the client to the supplier which may be used for any further exchange features implementations or application level checks or processing which are out of scope of this document.
Figure 21 — Simple Push exchange subsystems, interface interactions and methods
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 managing extra features not required by the Simple Push exchange.
For interoperability convenience the exchange data model wrapping shall be managed in this exchange.
A payload shall be pushed to a client using basic exchange data model as reported in the previous figure.
An ExchangeInformation shall be returned from putData to convey information about exchange operation and connection status.
Information related to Exchange that should be managed to make application development easier are fully described in basic exchange data model.
Exchange Context information related are:
Dynamic Information information related are:
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 case 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 initiates the communication and is made aware of the client status based on the client return response to the supplier.
The following diagram (Figure 22) describes the client status as monitored and managed by the supplier.
Figure 22 – Supplier Side Simple Push State Diagram
The following diagram (Figure 23) describes the supplier status as monitored and managed by the client.
Figure 23 — Client-side Simple Push State Diagram
Special management in initialisation and termination of Push process is to consider at the application level in supplier and client systems.
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 Payload Push and KeepAlive. When data is available a payload Push is exchanged which also informs client and supplier about the session and systems status: Push received from supplier on client side and return of push on payload push on supplier side guarantee the network is available and the systems are up and running.
When no data is available at supplier and a time-out has expired a KeepAlive message is exchanged to check network and system availability.
In case payload push or KeepAlive fails or times out, the supplier assumes the client is offline and keeps trace of its status for any management purposes at the supplier system side (for delivery retry mechanism is to be described at PSM level defining a logical push mapping iterated for a maximum number of times) (Figure 24).
Figure 24 - Simple Push sequence diagram for link monitoring and data delivery
Available operating mode for Simple Push is “Periodic”, or “On Occurrence” (i.e. condition is triggered based on supplier) push based on supplier-side conditions.
Description of operating modes is done at a general PIM level; no extra details are needed in this subclause for PIM/Exchange Pattern / FEP.
A Payload Push condition is triggered based on the agreed operating mode defined at subscription among client and supplier.
Available updated methods are: Snapshot, Single Element Update, All element update.
All updates available are conveyed in a payload publication push message.
Description of update methods is done at PIM level; no extra details are needed in this subclause for PIM/exchange pattern / FEP.
Description of life cycle management is done at PIM level.
Life cycle management to exchange data between client and supplier is embedded with the operating mode and update method chosen at subscription contract.
Push delivery method allows conveying information from supplier to client as two different pieces of information.
Sampled data may be conveyed as Periodic or On Occurrence push of a snapshot payload containing all current active data or last collected data.
A Single/All Element updated push can be done for any operating mode as well with On Occurrence or Periodic Push.
Based on sequence diagram described in Figure 24, the supplier after initialisation starts sending push information to a client: in case of stateful information delivery and based on the possibly agreed conditions of the subscription contract, e.g. it manages a snapshot push whenever it has no historical information about client status, deriving it is the first connection ever and a Snapshot Push is needed to align the client system when it is not the first time the supplier sends to the client normal payload push data, but the client for internal system needs can also require for snapshot push data by its return status.
After initialisation ready data condition at the supplier system side triggers a payload push delivery.
A periodic push condition is also possible based on contract agreement between supplier and client.
See sequence diagram at link monitoring life cycle for all messaging details.
Not fully implemented in this pattern.
A snapshot synchronisation request can be managed in the client return data, by the return status described in the “Basix Exchange Data Model” by returnStatus set as snapshotSynchronisationRequest.
This feature implementation is not mandatory in this FEP, agreement to manage among client and supplier are needed to enable full interoperability.
Not fully implemented in this pattern.
A multi-part data delivery can be optionally implemented by supplier by setting in the delivered message within exchange “Dynamic Information” setting the completedPayload as false, as described in Basic Exchante Data Model, it will inform the client one or more subsequent message will be delivered to complete the payload information, until the attribute completedPayload will be set as true.
This feature implementation is not mandatory in this FEP, agreement to manage among client and supplier are needed to enable full interoperability.
Snapshot synchronisation and delta synchronisation are available in Simple Push.
Snapshot synchronisation is optionally managed at first connection with a client or under client request. In all other cases a Simple Push is delivered based on supplier site data available and conditions.
Handshake is not available
Communication features are implemented at PSM level, they are relevant to the specific Platform chosen on which the Exchange pattern will be implemented (e.g. http/XML, Web Services SOAP, REST).
Some exchange pattern features of any context diagrams features groups (e.g. information management, data delivery etc.) allow the implementation of general optimisation such as processing saving and bandwith.
Payload timestamp information is available for client-side processing optimisation made at the application level.
Snapshot Push messages may be generated for all clients reducing processing resources at the supplier-side.
No extra optimisation issues are considered in this EP+FEP.
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 |
Information delivery business scenario description and definition state that data exchange is needed to align the information kept by the supplier system into the client system; for this purpose, an exchange system is used which provides tools enabling messages generation and their transfer between a supplier and a client (Figure 25).
Figure 25 — Stateful Push Exchange actors
The “Stateful Push” exchange pattern is described in the following subclauses.
In a stateful push context, the client provides a mechanism to receive data from an action taken at the supplier site invoking specific resources / methods offered by the client.
Therefore, the supplier logically “pushes” messages to the client. The client shall acknowledge what is received by a return exchange information to the supplier. This exchange information return message is available to bring information back from the client to the supplier, such as SessionId, failure, success, snapshot synchronisation request. Return message information is logically described in this PIM, while implementation will be defined at PSM level.
As in “Simple Push”, the “Stateful Push” client provides two mechanism to the “Stateful Push” supplier to push data:
Besides “push” data delivery methods the simple push client also provides a “keep alive” method to implement link monitoring capabilities among client and supplier, the keep alive method is used from the supplier to advise the client when no information updates are to be delivered, so the supplier delivers a “keep alive” message to check and enable the client to check that exchange systems and network connection are available, despite the supplier doesn’t need to exchange payload content. “Keep Alive” messages are delivered by the supplier to the client, according a time interval which is defined among them.
“Stateful Push” session management methods are available to implement session management features; such methods, namely openSession and closeSession usage which are used to define dynamic exchange information context to enable session management exchange features.
In the context of this “Stateful Push” FEP+EP framework, to enable interoperability among client and supplier, all rules defined in this clause apply.
Any stateful push client exchange system SHALL realise a stateful push client interface wich provides a putSnapshotData, a putData, an openSession, a closeSession mehod and a keepalive method.
Any stateful push supplier exchange system SHALL realise a stateful push supplier interface which can invoke the putSnapshotData, putData, openSession, closeSession and keepAlive methods provided by the stateful push Client interface to deliver data or snapshot data and information to implement link monitoring and session management.
Figure 26 shows the communication diagram for simple push FEP + EP.
In this FEP+EP framework the supplier “pushes” messages to the client.
The client shall acknowledge the received message by a return information to the supplier. This return information shall be coded as ExchangeInformation.
Note
This return message is available to bring some exchange information from the client to the supplier which may be used for any further exchange features implementations or application level checks or processing which are out of scope of this document.
Figure 26 — Stateful Push Exchange subsystems and interfaces interactions and method
The supplier takes the initiative to push the data, or the snapshot data, under the following conditions:
Basic exchange data model has been provided to allow an implementation that delivers more payload contents in the same message and further information to allows managing extra features which are not required by the basic Snapshot Push exchange.
In order to ensure interoperability, the exchange data model wrapping shall be used in this exchange pattern.
A container shall be pushed to client using basic exchange data model as stated in the previous figure.
An ExchangeInformation object shall be returned from putData to convey information about exchange operation and connection status.
Information related to Exchange that should be managed to make application development easier are fully described in basic exchange data model.
Exchange Context information related are:
Different messages or supplier/client interactions are exchanged in the Stateful Push which are needed to manage session, synchronisation, payload exchange, link monitoring. These are formally contained in messages pushed to a client by a supplier or in messages returned from client to supplier.
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 initiates the communication and can be aware of the client status based on the client return response to the supplier.
The following diagram (Figure 27) describes the client status as monitored and managed by the supplier.
Figure 27 — Supplier-side Stateful Push state diagram
The following diagram (Figure 28) describes the supplier status as monitored and managed by the client.
Figure 28 — Client-side Stateful Push state diagram
Specific management in the initialisation and termination of a push process should be considered at the application level in the supplier and client systems.
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:
The corresponding classes, attributes and relationships described in the class diagrams included in the next subclauses are described in C.4.
Managed offline, not automated. It assumes information for controlling to be implemented in a client to assess the identity of supplier and authenticate the supplier request in messages exchange.
Managed offline, not automated.
After the session status management diagrams, the following sequence diagram illustrates the exchanged message and the expected return and behaviour.
When a session needs to be initiated, an “Open Session” is tried in loop until it succeeds.
A failure when opening a session includes cases of a client who has not subscribed or is not authorised. Checking this can be ensured at the PSM level (e.g. this could include VPN setting or IP firewall or signatures handling), logical information may be included in exchange data to be managed in subscription check at the client side.
When a session is “ON” the supplier pushes available payload data to the client in case one of the 2 conditions is fulfilled:
In case no payload is available a” Keep Alive” message is used to check session status for the supplier and the client.
When no “Keep Alive” message or no payload is received, after a “Keep Alive” time-out the client invalidates the session on its side and returns a “Close Session” message to prevent any attempt of push from the supplier.
If any push or keep alive fails the supplier invalidates the session and starts a new loop to open session.
Realignment messages are managed when a session is opened, a global synchronisation request from the client is returned in opening session when needed. Further any global synchronisation may be asked by a client in any push return as well but this does not close the session.
Any message and return in the sequence diagram (Figure 29) will be mapped in PSM definition to real platform available implementation such as a web service “Service request and return” or any other available mechanism in a specific platform.
Figure 29 — Stateful Push sequence diagram for session life cycle and data delivery
“Keep Alive” is based as described in the previous session life cycle.
When data is available a payload push is exchanged which informs the client and the supplier about the session and systems status: The push is received from the supplier on the client side and the return of Push on payload push on the supplier side guarantees the network is available and the systems are up and running.
When no data is available and a time-out has expired a “Keep Alive” message is exchanged to check the network and system availability.
In case a payload push or a “Keep Alive” fails the session shall be invalidated (the retry mechanism is to describe at the PSM level introducing a logical push mapping iterated for a maximum number of attempts).
The available operating modes for supplier Push are either periodic, or condition-triggered (based on the supplier-side conditions and the interchange agreement at the subscription).
The general description of the operating modes is done at the PIM level, no extra details are needed in this subclause for PIM/exchange pattern / FEP.
A payload Push is triggered based on the agreed operating mode defined at the subscription between the client and the supplier.
Available updated methods are: Snapshot, Single element update, All elements update.
All updates available are conveyed in a payload publication push message.
The general description of the update methods is done at the PIM level, no extra details are needed in this subclause for PIM/exchange pattern / FEP.
The description of life cycle management is done at the PIM level.
The life cycle management for exchanging data among a client and a supplier is embedded in the operating mode and the update method which have been chosen in the subscription contract.
The push delivery method allows conveying information from a supplier to a client as two different sets of information.
Sampled data can be conveyed (pushed) as “Periodic” or “On occurrence” of a global payload containing all currently active data or last collected data.
A “Single element” or “All elements” update push can be done for any operating mode, i.e. with “On occurrence” or “Periodic” push.
Session life cycle online section allows sending data when available at the supplier system by triggering a data ready condition.
A periodic push condition is also possible based on contract agreement among supplier and client.
See sequence diagram at the session life cycle for messaging details
Not fully implemented in this pattern.
A snapshot synchronisation request can be managed in the client return data, by the return status described in the “Basix Exchange Data Model” by returnStatus set as snapshotSynchronisationRequest.
This feature implementation is not mandatory in this FEP, agreement to manage among client and supplier are needed to enable full interoperability.
Not fully implemented in this pattern.
A multi-part data delivery can be optionally implemented by supplier by setting in the delivered message within exchange “Dynamic Information” setting the completedPayload as false, as described in Basic Exchante Data Model, it will inform the client one or more subsequent message will be delivered to complete the payload information, until the attribute completedPayload will be set as true.
This feature implementation is not mandatory in this FEP, agreement to manage among client and supplier are needed to enable full interoperability.
Global synchronisation and delta synchronisation are available in Stateful Push.
The global synchronisation is managed at the first session with a client or under a client request.
The delta synchronisation is managed once a session had been created and closed due to a network error or any other condition, so that not-delivered payload data is stored at the supplier side and delivered to the client as soon as a session is established again.
Handshake is not available
The communication features are implemented at the PSM level; they are relevant to a specific platform chosen on which the exchange pattern will be implemented (e.g. http/XML, Web services with SOAP, REST, etc.).
Some exchange pattern features of any context diagrams features groups (e.g. information management, data delivery etc.) allow the implementation of general optimisation such as processing saving and bandwith.
Payload timestamp information is available for client-side processing optimisation made at the application level.
Snapshot Push messages may be generated for all clients reducing processing resources at the supplier-side.
No extra optimisation issues are considered in this EP+FEP
Simple CIS FEP+EP PIM is based on description of interactions which enable service request and feedback exchange among a service requester and one to many service providers as illustrated in informative Annex H .
It can be implemented in several technological platforms with specific interactions methods, e.g. SOAP WebService methods.
The simple CIS FEP+EP frameworks enables a common communication interface to embed ITS service request and feedback in a way that two or more TMC, TIC or SP systems can perform in a common interoperable way.
Simple CIS FEP +EP framework is not designed to implement Data Delivery business scenario but it may be based on payload content which is assumed to be exchanged by Data Delivery which can be enabled by Data Delivery FEP+EP. Only Specific features enabling CIS are described and introduced for Simple CIS. Feature which are not related to this FEP+EP are martked as “Not applicable” in the table below.
To describe the EP+FEP at PIM level all features are described in a general abstract format, independently from the specific technology platform in which this model will be implemented. (e.g. http/get XML, WebService).
Features Area | Feature | Simple Push available |
---|---|---|
Subscription contract | Contract | N |
Catalogue | N | |
Session | Session life cycle | N |
Link monitoring | N | |
Information management | Operating modes | Not applicable |
Update methods | Not applicable | |
Life cycle management | Not applicable | |
Support information processing | Y | |
Distributed transaction | Y, not atomic transactions | |
Data delivery | Data delivery | Not applicable |
Data request | Not applicable | |
Large datasets handling | Not applicable | |
Synchronisation | Not applicable | |
Self-Description | Handshake | N |
Communication | Security | At PSM level |
Compression | At PSM level | |
Communication | At PSM level |
“Simple CIS” FEP+EP enable 1 service requester node to implement CIS service sequest interaction for 1 to several service providers.
The interaction is described as the CIS service requester addressing all involved CIS service providers through their Simple CIS Exchange interfaces which provides methods to deliver service requests from a requester to a multiplicity of service providers (Figure 30).
Figure 30 — “Simple CIS” exchange actors
The “Simple CIS” exchange pattern is described in the following subclauses.
In a “Simple CIS” context, the service provider provides a mechanism to receive a service request from action taken at a service requester site. This will result in the service requester invoking specific methods/resource offered by the service provider. On the reverse side a mechanism is also needed to enable the service provider to feed back the result of processing or action triggered by the service request, so the service requester itself provides a mechanism to receive a service feedback from the involved service providers when their actions or processes results are available.
Figure 31 shows the communication diagram for “Simple CIS” FEP + EP.
In this FEP+EP framework the service requester deliver a service request trigger to the service provider and the service provider delivers service feedback information to the service requester.
Therefore the “Service Requester” logically “pushes” “CIS Service Requests” messages, embedded in a “MessageContainer”, to the “Service Provider” which shall acknowledge the reception of such messages by a return message, embedded in an “ExchangeInformation”. This exchange information return message is available to bring information back from the “Service Provider” to the “Service Requester”, such as failure, success. Return message information is logically described in this PIM, while implementation will be defined at PSM level.
At the same time, the involved “Service Providers” logically push “CIS Service Feedback” messages, embed in a “Message Container” to the “Service Requester” which symmetrically shall acknowledge the reception of suche messages by a return message, embedded in an “ExchangeInformation”. This exchange information return message is available to bring some information back to the “Service Provider” which management is not relevant to this FEP+EP and is not described in this document.
The management of any further workflow based on any processing or action errors is in this workflow framework pattern based on CIS “Service Feedback” is only in charge of the “Service Requester” System and is defined at application level based on the specific application requirements needed to enable the specific collaborative ITS services.
In the context of this “Simple Push” FEP +EP framework, to enable interoperability among CIS service requester and CIS service providers, all rules defined in this clause apply.
Any simple CIS service provider exchange system SHALL realise a simple CIS service provider interface which provides a putCISServiceRequest method.
Any simple push service requester exchange system SHALL realise a simple CIS service requester interface which can invoke the putCISServiceRequest method provided by the simple cis service provider interface to deliver cis service request to trigger action/process by the service provider systems.
Any simple CIS service requester exchange system SHALL realise a simple CIS service requester interface which provides a putCISServiceFeedback method.
Any simple CIS service provider exchange system SHALL realise a simple CIS service provider interface which can invoke the putServiceRequest method provided by the simple CIS service requester interface to deliver CIS service feedback to the service requester systems.
Figure 31 shows the communication diagram for simple push FEP + EP.
In this FEP+EP framework the service requester “pushes” service requests messages to the service provider and the service provider “pushes” service feedback messages to the service requester.
Both service provider and service requester shall acknowledge the received service request or service feedback messages by a return information to the corresponding counterpart, i.e. respectively to the service requester and to the service provider. This return information shall be coded as ExchangeInformation.
Note
This return message is available to bring some exchange information back from the receiver system which may be used for any further exchange features implementations or application level checks or processing and/or workflow management decision in CIS implementation which are out of scope of this document.
Figure 31 — Simple CIS exchange subsystems, interface interactions and methods
Basic exchange data model has been provided to allow the implementation to enable CIS features to support information processing and enable distributed transactions features.
CIS Information embed all information needed to request for specific processing and to enable workflow management to support transaction negotiation processes by service request and service feedback messages.
Exchange information enables to deliver the Exchange context of involved service requester and service providers to enable orchestration of ITS services supply and exchange dynamic information which enables general exchange status information to monitor transactions negotiation or service processing in general.
Some non-mandatory information which should be managed in the exchange information for easy application development are fully described in basic exchange data model:
Different messages or supplier / client interactions (invoked method) are exchanged in Simple Push which are needed to manage synchronisation, payload exchange, link monitoring. These are formally contained in pushed messages to a client from a supplier or in return messages from client to supplier.
Interaction message | Direction requester provider | Designation | Description | Exchanged information | Optional |
Service Request | Direct | putCISServiceRequest | Push delivery of a service request, which has to be delivered from service requester to the service provider. CIS Information is delivered in the specific container to address the instruction to process information and/or implement the requested service. Exchange information such as requester and service provider identification and exchange status are provided to easy controls. |
Message Container including: Payload (optional when not delivered in former Data Delivery Exchange) + CIS Information (Mandatory service request information) + Exchange Information with relevant information to enable exchange features |
N |
Service Feedback | Return | putCISServicefeedback | Push delivery of a CIS Service Feedback. CIS service feedback Information is delivered in the specific container to address the status and result of processing and/or and/or implementation of the requested service. Exchange information such as client and supplier identification and exchange status may be provided to easy exchange related controls. |
Message Container including: Payload (optional when not delivered in Data Delivery Exchange) + CIS Information (Mandatory service feedback information) + Exchange information with relevant information to enable exchange features |
N |
Exchange Information Return | Return (Direct on Service Feedback) | D2Exchange Information | Exchange information is returned from client to supplier to provide return status i.e. Success, Fail and exchange context information to easy controls such as supplier and client identification. | Exchange Information | N |
State diagram are not needed and not developed for stateless FEP+EP as Simple CIS.
This subclause provides a description and the corresponding specification for each feature identified in the context diagram, according to the Simple Push data exchange architecture. The following features are specified:
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.
Not managed in this EP+FEP.
CIS features implementation is based on Service Request and Service Feedback implementation.
As explained in Annex H, besides Exchange actors involvement”Collaborative ITS Services” workflow management to support information process and transactions features involves application level management. These application level checking and triggers, which are needed to implement control and triggers to start exchange features, are considered existing and are not described in this document, which only assumes these processing and triggering functions are needed and implemented at “Service Requester System” and “Service Provider System” and are only indicated in the sequence diagrams as placeholders to support understanding of exchange workflows.
Note
Application level triggers and checkings are depending on specific payload domain which is managed in the exchange and can be specified only based on the payload content itself which is out of scope of this document. Examples of specific domain information are referred in the Basic Exchange Data Model CIS Information (ref. Annex C ) as predefined services such as: VMS message processing, information broadcast delivery or traffic management plans activation and implementation.
Figure 32 describes the interaction to implement a service request from the “Service Requester System” to one up to many “Service Provider Systems” by the “Simple CIS” exchange.
After the application level “Service Requester” system has triggered the “Service Request” exchange management, at first outcome it will receive the information that Service Request have been delivered to involved “Service Provider” systems, or some errors happened or had been recognised by the “Service Provider” systems in the service request itself. Returned “Exchange Information” is the first outcome of the Service Request delivery to the Service Provider and Service Provider System.
For CIS it is also assumed that at “Service Requester System” some application level management of service requests which had been delivered is needed and feedback and error/timeout management is done as application level implementation. The outcomes of such management will lead some application logic to decide the next workflow and exchange action needed but are not described in this specification.
Figure 32 — Simple CIS sequence diagram for Service Request
As stated above only interaction among “Exchange Interfaces” i.e. Service Requester and Service Provider are considered normative for the specific FEP+EP in this document. Other interaction are assumed but are dependent on application logic and requirements which are external to the exchange system which are not in the scope of this document. General aspect for CIS and some application level workflow requirements are described at Annex H .
Figure 33 describes the interaction to implement a service feedback from the “Service Provider System” to the “Service Requester System” by the “Simple CIS” exchange.
After the application level “Service Provider” system has delivered the feedback to the “Service Requester” exchange management, at first outcome it will receive the information that service feedback have been delivered to the “Service Requester” system or some errors happened or had been recognised by the “Service Requester” systems in the service feedback itself. Returned Exchange Information is the first outcome of the “Service Feedback” delivery to the Service Requester and Service Requester System.
For CIS it is also assumed that at “Service Requester System” some application level management of service feedbacks which had been delivered is needed and feedback and error/timeout management is done as application level implementation. The outcomes of such management will lead some application logic to decide the next workflow and exchange action needed but are not described in this specification.
Figure 33 — Simple CIS sequence diagram for Service Feedback
While the workflow to enable the support to information processing is defined in sub-clause 6.4.4.1 of this document, the information needed to enable such information process are described in the Basic Exchange Data Model at Annex C , specifically at CIS Information description.
Predefined services are possible as well as not predefined services, which are enabled by specific attributes in the CIS Information classes.
While the workflow to enable the support to distribute not atomic transactions processing is defined in sub-clause 6.4.4.1 of this document, the information needed to enable such information process are described in the Basic Exchange Data Model at Annex C , specifically at “CIS Information” description.
Predefined services are possible as well as not predefined services, which are enabled by specific attributes in the “CIS Information” classes.
Not managed in this EP+FEP.
In Simple CIS FEP+EP PIM it is assumed that data delivery requirements to deliver data to be processed are enabled by a parallel Data Delivery exchange and referenced in CIS Information to specify the relative processing action, despite payload data can be also delivered in a Service Request or Service Feedback when needed by specific application level management, it can be assumed delivered in a previous exchange. The responsibility of data availability to support actions and processing requests are assumed to be in charge of the “Service Requester System” itself.
Handshake not available.
Communication features are implemented at PSM level, they are relevant to the specific Platform chosen on which the Exchange pattern will be implemented (e.g. http/XML, Web Services SOAP, REST).
“Stateful CIS” is an extension of the “Simple CIS”, described and specified for the “Simple CIS” FEP+EP PIM (i.e. clause 6 in this document), with session management and link monitoring features which are enabled by the same mechanisms which are defined for the “Stateful Push” FEP + EP PIM (i.e. section 5 in this document). The overall implementation of “Stateful CIS” will be a combination of features described for both “Simple CIS” service request and service feedback mechanism, with session management and link monitoring features implemented as per “Stateful Push”.
Only specific “Stateful Push” definition will be described in the current section, all definition and specification which are the same for “Stateful Push” or “Simple CIS” FEP+EP PIM will be addressed to the specific sections in this document.
NOTE All definition applies which are related to “Simple CIS” and “Stateful Push”FEP + EP PIM, but supplier role and name is to be associated to the requester system and client role and name is to be associated to the provider systems.
“Stateful CIS” FEP+EP PIM is based on description of interactions which enable service request and feedback exchange among a service requester and one to many service providers as illustrated in informative Annex H .
It can be implemented in several technological platforms with specific interactions methods, e.g. SOAP WebService methods.
The “Stateful CIS” FEP+EP frameworks enables a common communication interface to embed ITS service request and feedback in a way that two or more TMC, TIC or SP systems can perform in a common interoperable way.
“Stateful CIS” FEP +EP framework is not designed to implement Data Delivery business scenario but it may be based on payload content which is assumed to be exchanged by Data Delivery which can be enabled by Data Delivery FEP+EP. Only Specific features enabling CIS are described and introduced for Simple CIS. Feature which are not related to this FEP+EP are martked as “Not applicable” in Table 9.
To describe the “Stateful CIS” EP+FEP at PIM level all features are described in a general abstract format, independently from the specific technology platform in which this model will be implemented. (e.g. http/get XML, WebService).
Features Area | Feature | Simple Push available |
---|---|---|
Subscription contract | Contract | N |
Catalogue | N | |
Session | Session life cycle | Y |
Link monitoring | Y | |
Information management | Operating modes | Not applicable |
Update methods | Not applicable | |
Life cycle management | Not applicable | |
Support information processing | Y | |
Distributed transaction | Y, not atomic transactions | |
Data delivery | Data delivery | Not applicable |
Data request | Not applicable | |
Large datasets handling | Not applicable | |
Synchronisation | Not applicable | |
Self-Description | Handshake | N |
Communication | Security | At PSM level |
Compression | At PSM level | |
Communication | At PSM level |
Table 15 Selection of features for Simple Push
As Simple CIS “Stateful CIS” FEP+EP enable one service requester node to implement CIS service sequest interaction for one up to several service providers. At the same time Session Management and Link Monitoring features allows “Stateful CIS” Service Requester and Service Provider Systems to be aware of network communication features among them to enable reliable and timely exchange and take initiative to trigger any required actions besides CIS actions themselves in case a session or link are broken by system or network failures.
The interaction is described as the CIS service requester addressing all involved CIS service providers through their Stateful CIS Exchange interfaces which provides methods to deliver service requests from a requester to a multiplicity of service providers (Figure 34).
Figure 34 — “Stateful CIS” exchange actors
The “Simple CIS” exchange pattern is described in the following subclauses.
In a “Stateful CIS” context, the service provider provides a mechanism to receive a service request from action taken at a service requester site. This will result in the service requester invoking specific methods /resource offered by the service provider. On the reverse side a mechanism is also needed to enable the service provider to feed back the result of processing or action triggered by the service request, so the service requester itself provides a mechanism to receive a service feedback from the involved service providers when their actions or processes results are available.
Besides “Simple CIS” service request and service feedback methods the stateful cis client also provides a “keep alive” method to implement link monitoring capabilities among service requester and service providers, the keepAlive method is used from the service requester to advise the client when no service request are to be delivered, so the service requester delivers a “keep alive” message to check and enable the service providers to verify that exchange systems and network connection are available, despite the service requester doesn’t need to exchange payload content. “Keep Alive” messages are delivered by the service requester to the service providers, according a time interval which is defined among them.
“Stateful CIS” session management methods are available to implement session management features in the same way they are described and available for “Stateful Push” FEP+EP PIM; such methods, namely openSession and closeSession usage which are used to define dynamic exchange information context to enable session management exchange features.
Figure 35 shows the communication diagram for “Stateful CIS” FEP + EP.
In this FEP+EP framework the service requester delivers a service request trigger to the service provider and the service provider delivers service feedback information to the service requester.
Therefore, the “Stateful CIS Service Requester” logically “pushes” “CIS Service Requests” messages, embedded in a “MessageContainer”, to the “Stateful CIS Service Provider” which shall acknowledge the reception of such messages by a return message, embedded in an “ExchangeInformation”. This exchange information return message is available to bring information back from the “Service Provider” to the “Service Requester”, such as failure, success. Return message information is logically described in this PIM, while implementation will be defined at PSM level.
At the same time, the involved ” Stateful CIS Service Providers” logically push “CIS Service Feedback” messages, embed in a “Message Container” to the ” Stateful CIS Service Requester” which symmetrically shall acknowledge the reception of suche messages by a return message, embedded in an “ExchangeInformation”. This exchange information return message is available to bring some information back to the “Service Provider” which management is not relevant to this FEP+EP and is not described in this document.
The management of any further workflow based on any processing or action errors is in this workflow framework pattern based on CIS “Service Feedback” is only in charge of the “Service Requester” System and is defined at application level based on the specific application requirements needed to enable the specific collaborative ITS services.
In the context of this “Stateful Push” FEP +EP framework, to enable interoperability among CIS service requester and CIS service providers, all rules defined in this clause apply.
Any simple CIS service provider exchange system SHALL realise a stateful CIS service provider interface which provides a putCISServiceRequest method, and an openSession, closeSession and keepalive methods.
Any simple push service requester exchange system SHALL realise a simple cis service requester interface which can invoke the putCISServiceRequest, openSession, closeSession, keepAlive methods provided by the simple cis service provider interface to deliver cis service request to trigger action/process by the service provider systems.
Any simple CIS service requester exchange system SHALL realise a simple CIS service requester interface which provides a putCISServiceFeedback method.
Any simple CIS service provider exchange system SHALL realise a simple CIS service provider interface which can invoke the putServiceRequest method provided by the simple CIS service requester interface to deliver CIS service feedback to the service requester systems.
Figure 35 shows the communication diagram for simple push FEP + EP.
In this FEP+EP framework the service requester “pushes” service requests messages to the service provider and the service provider “pushes” service feedback messages to the service requester.
Both service provider and service requester shall acknowledge the received service request or service feedback messages by a return information to the corresponding counterpart, i.e. respectively to the service requester and to the service provider. This return information shall be coded as ExchangeInformation.
NOTE This return message is available to bring some exchange information back from the receiver system which may be used for any further exchange features implementations or application level checks or processing and/or workflow management decision in CIS implementation which are out of scope of this document.
Figure 35 — Stateful CIS exchange subsystems, interface interactions and methods
Basic exchange data model has been provided to allow the implementation to enable CIS features to support information processing and enable distributed transactions features.
CIS Information embed all information needed to request for specific processing and to enable workflow management to support transaction negotiation processes by service request and service feedback messages.
Exchange information enables to deliver the Exchange context of involved service requester and service providers to enable orchestration of ITS services supply and exchange dynamic information which enables general exchange status information to monitor transactions negotiation or service processing in general.
Some non-mandatory information which should be managed in the exchange information for easy application development are fully described in basic exchange data model:
Different messages or supplier / client interactions (invoked method) are exchanged in Simple Push which are needed to manage synchronisation, payload exchange, link monitoring. These are formally contained in pushed messages to a client from a supplier or in return messages from client to supplier.
Interaction message | Direction requester provider | Designation | Description | Exchanged information | Optional |
Open Session | Direct | openSession | Service requester initialise a stateful cis session with the involved service provider. | Exchange Information | N |
Service Request | Direct | putCISServiceRequest | Push delivery of a service request, which has to be delivered from service requester to the service provider. CIS Information is delivered in the specific container to address the instruction to process information and/or implement the requested service. Exchange information such as requester and service provider identification and exchange status are provided to easy controls. |
Message Container including: Payload (optional when not delivered in former Data Delivery Exchange) + CIS Information (Mandatory service request information) + Exchange Information with relevant information to enable exchange features |
N |
Service Feedback | Return | putCISServicefeedback | Push delivery of a CIS Service Feedback. CIS service feedback Information is delivered in the specific container to address the status and result of processing and/or and/or implementation of the requested service. Exchange information such as client and supplier identification and exchange status may be provided to easy exchange related controls. |
Message Container including: Payload (optional when not delivered in Data Delivery Exchange) + CIS Information (Mandatory service feedback information) + Exchange information with relevant information to enable exchange features |
N |
Keep Alive | Direct | keepAlive | Test exchange link and confirm session validity when no service request or feedback is exchanged. 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 stateful cis session, initiated by the service requester. | Exchange Information | N |
Exchange Information Return | Return (Direct on Service Feedback) | D2Exchange Information | Exchange information is returned from client to supplier to provide return status i.e. Success, Fail and exchange context information to easy controls such as supplier and client identification. | Exchange Information | N |
The service requester initiates the communication and by open session and keep alive messages can be aware of the service provider status based on return messages or possible communication errors.
The following diagram (Figure 36) describes the internal service requester status and the corresponding service provider status as monitored and managed by the service requester.
Figure 36 — CIS requester-side Stateful CIS state diagram
The following diagram (Figure 37) describes the internal service provider status and the service requester status as monitored and managed by the service provider.
Figure 37 — CIS Provider-side Stateful CIS state diagram
Specific management in the initialisation and termination of a push process should be considered at the application level in the supplier and client systems.
This subclause provides a description and the corresponding specification for each feature identified in the context diagram, according to the Simple Push data exchange architecture. The following features are specified:
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 the session state management diagrams, at exchange initialisation a session needs to be initiated, an “Open Session” is tried in loop until it succeeds.
A failure when opening a session includes cases of a client who has not subscribed or is not authorised. Checking this can be ensured at the PSM level (e.g. this could include VPN setting or IP firewall or signatures handling), logical information may be included in exchange data to be managed in subscription check at the service provider side.
When a session is “ON” the service requester may send service request to involved service providers when all conditions to start a CIS service are triggered.
In case no CIS Service requester triggering condition occurs a” Keep Alive” message is used to check session status for the supplier and the client.
When no “Keep Alive” message or no payload is received, after a “Keep Alive” time-out the service provider invalidates the session on its side and returns a “Close Session” message at firse received message of any type.
If any service request or keep alive fails the service requester invalidates the session and starts a new loop to open session.
Any message and return in the sequence diagram (Figure 37) will be mapped in PSM definition to real platform available implementation such as a web service “Service request and return” or any other available mechanism in a specific platform.
After “Keep Alive” mechanism introduced in the previous session life cycle, service requests and keep alive messages are exchanged which give evidence to the service requester and service providers about the session and systems status.
When no service request or feedback are exchanged and a time-out has expired a “Keep Alive” message is exchanged to check the network and system availability.
In case service request or service feedback or “Keep Alive” fail, the session shall be invalidated.
Besides the Service Request and Service Feedback handshaking which is fully described in the equivalent “Stateful CIS” clause, Stateful CIS implements them in the framework of a stateful session, which implementation make aware the application side Service Requester about the availability and session status of all service providers which are involved in the Collaborative ITS Service implementation. This enable the decision process to trigger and manage CIS to involve information about involved CIS Service Provider status and availability.
All application level rules about decisions to trigger services and involved providers orchestration functionalities of CIS are out of scope of the exchange specification and are not described in this documents.
This clause description and specification for “Stateful CIS” are the same as the equivalent “Simple CIS” clause.
This clause description and specification for “Stateful CIS” are the same as the equivalent “Simple CIS” clause.
Not managed in this EP+FEP.
In Stateful CIS FEP+EP PIM it is assumed that data delivery requirements to deliver data to be processed are enabled by a parallel Data Delivery exchange and referenced in CIS Information to specify the relative processing action, despite payload data can be also delivered in a Service Request or Service Feedback when needed by specific application level management, it can be assumed delivered in a previous exchange. The responsibility of data availability to support actions and processing requests are assumed to be in charge of the “Service Requester System” itself.
Handshake not available.
Communication features are implemented at PSM level, they are relevant to the specific Platform chosen on which the Exchange pattern will be implemented (e.g. http/XML, Web Services SOAP, REST).
This clause is reserved for future new models/patterns supporting new business scenarios, such as “Collaboration ITS Services”.
The definition of the business scenario is mandatory prior to the PIM description because a PIM implementation is “connected” to a business scenario.
CIS can be implemented using bidirectional data delivery approach for service request and feedback exchanges as possible PIM for a non-pre-emptive CIS implementation as described in Annex H .