SIRI uses a consistent set of general communication protocols to exchange information between client and
server. The same pattern of message exchange may be used to implement different specific functional
interfaces as sets of concrete message content types.
Two well-known specific patterns of client server interaction are used for data exchange in SIRI:
Request/Response and Publish/Subscribe.
¿ Request/Response allows for the ad hoc exchange of data on demand from the client.
¿ Publish/Subscribe allows for the repeated asynchronous push of notifications and data to distribute events
and Situations detected by a Real-time Service.
The use of the Publish/Subscribe pattern of interaction follows that described in the Publish-Subscribe
Notification for Web Services (WS-PubSub) specification, and as far as possible, SIRI uses the same
separation of concerns and common terminology for publish/subscribe concepts and interfaces as used in
WS-PubSub. WS-PubSub breaks down the server part of the Publish/Subscribe pattern into a number of
separate named roles and interfaces (for example, Subscriber, Publisher, Notification Producer, and
Notification Consumer): in an actual SIRI implementation, certain of these distinct interfaces may be combined
and provided by a single entity. Although SIRI is not currently implemented as a full WS-PubSub web service,
the use of a WS-PubSub architecture makes this straightforward to do in future.
For the delivery of data in responses (to both requests and subscriptions), SIRI supports two common
patterns of message exchange, as realised in existent national systems:
¿ A one step ¿Direct Delivery¿, as per the classic client-server paradigm, and normal WS-PubSub publish
subscribe usage; and;
¿ A two step ¿Fetched Delivery¿ which elaborates the delivery of messages into a sequence of successive
messages pairs to first notify the client, and then to send the data when the cli (...abbreviated)