Dear all, sorry for another email, hopefully not too lenghty... in order to avoid confusion I refer to services as in the sense of service-oriented architectures (and not in sense of a ROS service). To make that more concrete, let me include the API of the SmartSoft communication patterns as you see it from inside a component as a component builder. The first example is a "query". The client side exposes synchronous as well as asynchronous access methods and you do not have to care about multithreaded access, mixture of concurrent synchronous and asynchronous access etc.. The server side just forwards each incoming request to any processing by the handler upcall and you provide the return answer via the "answer" method. The next example is a publish / subscribe pattern. A client subscribes to get newest updates and either check for them, wait for the next one etc. The server side just pushes in updates via the "put" method. In general, we have a few more patterns in order to make live for robotics people as easy as possible but basically, you need a request / response and a publish / subscribe pattern. We provide: communication: - send just oneway - query request / response - push newest update all subscribed clients as soon as new data is available at the server - push timed provide periodic updates to subscribed clients coordination: - event inform as soon as a server side predicate became true - wiring allow for dynamic rewiring of components during runtime - state manage the life-cycle of a component (activate, deactivate, shutdown, error, ...) - parameter parameterize a component from outside at run-time - monitoring diagnostic port Inside these patterns, you run a protocol that is not visible to the robotics component builder. It is based on messages and these form the stable interface to the underlying middleware. You "just" have to map that protocol onto whatever middleware you are interested in. Just a snapshot of parts of the internal protocol: Now what would be interesting? - discuss such communication patterns for robotics - define them (their semantics) independently of the underlying middleware - although there is already work available here: - how to present QoS at the API of the patterns? - how to map QoS onto middleware if it provides QoS support? - ... Am 18.02.2014 09:42, schrieb Ingo Lütkebohle: > On Tue, Feb 18, 2014 at 2:12 AM, Brian Gerkey > > wrote: > > On Mon, Feb 17, 2014 at 9:06 AM, Wrede, Sebastian > > wrote: > > * How will services / RPC be implemented with DDS? Is there > already an > > accepted standard protocol for doing RPC over DDS? > > My understanding is: (i) the current DDS spec doesn't include what we > call services; (ii) there's an extension for services that is > currently under consideration and may make its way into a future > revision of the spec; and (iii) some current implementations have > vendor-specific extensions for services. > > > I know that many people feel otherwise, but in my personal opinion, > services are a bad idea anyway, and what we really want is something > more like (though not necessarily exactly the same) what actionlib > offers. That is, something which *explicitly* acknowledges that there > are always packets/messages underneath, that there is asynchronicity, > and that there may be impossibility to act *in the protocol*. > > Just saying ;-) > > cheers > > -- > Ingo Lütkebohle, Dr.-Ing. > Machine Learning and Robotics Lab, IPVS, Universität Stuttgart > http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle > +49-711-685-88350 > > PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B -- Prof. Dr. Christian Schlegel Prodekan, Studiendekan Master IS Fakultät Informatik Hochschule Ulm Tel.: 0731 / 50-28242 http://www.hs-ulm.de/schlegel http://www.servicerobotik-ulm.de/ http://www.youtube.com/user/roboticsathsulm http://www.zafh-servicerobotik.de/ http://smart-robotics.sourceforge.net/ http://www.joser.org/