This is an abstract of a demo that RTI plans to have available at the RTI Connext Users Group meeting, to be held in London next month (http://www.rti.com/connextcon).
The Oasis Reference Architecture for Service Oriented Architecture defines the concepts surrounding service ‘reachability’, including the use of Federated Service Registries (what services are known about) and Service Repositories (what you need to know, to access a service). Once your Consumer knows what Services are available, and also how to attach to a given Service Interface, you’re now rocking that SOA. So how does that apply to a real-time SOA, using DDS?
If you sort of squint at it, the DDS anonymous DCPS Discovery protocol is a part of the Service Registry. For the Service Repository, Discovery also can supply you with the Types, but only supports the pub-sub integration pattern. There isn’t any automated, or standards-driven, protocol for doing this using DDS.
To get a full, Federated Registry-Repository (cf Figure 38, page 63 of the reference document linked above), you can implement a Service Discovery process. Using a well-known topic and type, you can search for suitable Service Interfaces (based on Search or Keywords, etc), determine what integration pattern a Service uses, find the Topics that are needed for it, and merge that information with the normal DCPS Discovery discovered information. The end result is to build, ad-hoc, the necessary infrastructure to accesses that Service’s Interface — without requiring a maintained Repository.
For the London Connext Conference, RTI has a Raspberry Pi with an attached Pressure/Altimeter/Temperature sensor that publishes using pub/sub. A service starts up and subscribes to the PAT data, which it then offers (as a Service Interface) via Request/Reply and “Last Value Cache” QoS. The Service publishes a provision instance, loaded from an XML file, on a well known topic (“Service Provision”). The instance includes particulars of the Service Interface: This service uses Simple Request Reply, This is the Request Topic, the Reply Topic, with respective topic Type names, these are my human defined keywords.
A service consumer can now query the “Service Provision” topic using a content filter on the keywords, to find an arbitrary Temperature Service, identify that it is Simple Request/Reply, create the necessary Request writers and Reply readers (using the Types from normal Discovery process), make a request and process the reply. The only foreknowledge the Consumer has, is that there may be a Temperature sensor on the network that uses a specific set of keywords.