locked
Multiple DSS Nodes? RRS feed

  • Question

  •  

    So I have been making my first foray into the toolkit and have been real impressed, both with the capabilities provided but also with the impressive array of examples and documentation.

     

    The thing I am struggling with most is how to best implement multiple DSS nodes, and specifically to consume a service on a node hosted on another machine.  The example that seems closest, tutorial 7, seems to require the consuming service having a fair bit of coding specific to this situation.  Is that the only way to do it?  Are there any plans to make this multi-DSS node situation be a bit more transparent? 

     

    Also, is there any way to consume a service from a non-DSS service using the DSSP protocol?  I know it's possible with SOAP and there is a WCF-DSS example elsewhere, but I am looking for something that allows me to subscribe and receive notifications using DSS but without actually loading the environment (since I will want to do so from multiple applications that are user loaded and would prefer not to load the complete environment with each one).  A simple code example would really help me (C# or VB.Net).

    Tuesday, September 11, 2007 1:29 PM

Answers

  •  

    In terms of talking to other wellknown services on other nodes, then specifying partners and referring to them is the simplest way to go currently as far as I can tell. If you need to dynamically discover a service then it depends, you might need to talk to the service directory or some other equivalent service.

     

    In terms of consuming a service from a non-DSS node, then you'll have to bolt on your mechanism of choice onto your remote node, if you don't want the DSS runtime on your client. The transport/remoting/serialization is all tied into the DSS environment at a fairly low level.

     

    But for instance, I can imagine that (server-side) async WCF operations tie quite nicely in with the model. If you expose a singleton, you could hold directly the operations port of your well-known DSS service. If you expose a single-call you might use the static DssEnvironment class to look up your service each time.

     

    Nick.

    Wednesday, September 12, 2007 3:14 AM

All replies

  •  

    In terms of talking to other wellknown services on other nodes, then specifying partners and referring to them is the simplest way to go currently as far as I can tell. If you need to dynamically discover a service then it depends, you might need to talk to the service directory or some other equivalent service.

     

    In terms of consuming a service from a non-DSS node, then you'll have to bolt on your mechanism of choice onto your remote node, if you don't want the DSS runtime on your client. The transport/remoting/serialization is all tied into the DSS environment at a fairly low level.

     

    But for instance, I can imagine that (server-side) async WCF operations tie quite nicely in with the model. If you expose a singleton, you could hold directly the operations port of your well-known DSS service. If you expose a single-call you might use the static DssEnvironment class to look up your service each time.

     

    Nick.

    Wednesday, September 12, 2007 3:14 AM
  • Nick,

     

    Many thanks very helpful.  Partners does seem to be a good way to go where I can be sure the service is likely to exist... I am still trying to figure out how best to handle situation where I dont really know if service will be there (say I've just added a new robot, or in my case a zwave light switch... I'd like to pick this up through discovery). 

     

    Again, all ideas welcome, and once Im done I'll post my approach here.

     

    Guy

    Thursday, September 13, 2007 12:44 PM