locked
Pass by Reference or Pass by Value RRS feed

  • Question

  • If I have a DSS service that publishes a notification in response to a consumer's request, and the notification response contains the service state object --> Is this state object passed by reference or by value?  I'm assuming it would almost have to be passed by value due to all the voodoo black magic of the DSSP (read:  SOAP based messages).  But I just wanted some confirmation/correction of my perceived understanding.

     

    Here's why I'm asking....

     

    My consumer service (on physical box A) is requesting an object that has a type property representing a winform.  When this consumer service receives it's repsonse back from the publishing service (on physical box B and where the object is instantiated), it will eventually want to display the winform.  When the consumer service invokes the .Show() method of the type property representing a winform, will the winform actually be displayed on box A or box B?

     

    I'm guessing (and hoping) that if the repsonse message is passed by value, then the winform will be displayed on box A.

     

    Any enlightening remarks are greatly appreciated.

    Thursday, September 4, 2008 7:08 PM
    Moderator

Answers

  • There is still some "magic" with WinForms. In particular, they use a Single Threaded Apartment (STA) model and so we have to do some fancy programming in RDS to handle them. They have what is called "thread affinity" which means that you can only update a Form from the same thread that initially created it. This is yet another reason why you cannot pass a running Form across to another computer.

     

    I don't think that the maintenance is a big issue. You will have to distribute updated application code if you change a Form anyway. (Otherwise how will it know what to do with new/changed fields?) With RDS you simply have to copy over the DLLs to a working system and you can run the new application. We even provide a tool for creating the installation packages called DssDeploy.

     

    Yes, CCR & DSS are being used for non-robotics applications. Unfortunately most of them are "trade secret" and the organizations concerned don't want to give out many details.

     

    There is nothing wrong with writing applications that communicate only using "events". In MRDS we call them notifications, but it is basically the same thing. In particular, we use the REST (Representational State Transfer) model. This is how web services work, although the DSS protocol makes some extensions such as asynchronous notifications.

     

    You can think of the CCR and in particular DSS as client-server on steroids because an application can actually be distributed across multiple nodes, i.e. it is more peer-to-peer whereas in client-server there is a "master" and some "slaves". It can handle a very high volume of messages (the limitation on throughput is usually the processing time in the application) and it forces you to think about the information you want to maintain (state) and the information and operations that are required to update that data (messages).

     

    We realize that MRDS presents a new programming paradigm for many people, but a new approach is necessary if you want to take advantage of parallelism.

     

    Trevor

     

    Tuesday, September 9, 2008 4:13 PM

All replies

  • Hi Dennis,

     

    The state will effectively be passed by value. If you think about it, in general the service requesting the state could be on another computer. So what it gets is really a copy of the state.

     

    As for passing a WinForm, you can't do that. On a single computer you can pass the address (handle) of a WinForm around amongst different routines, but as soon as you try to pass it to another computer it becomes meaningless because of the way that WinForms works. So getting back to the previous question, you can't send a WinForm as part of the state. Perhaps you can just pass the data on the form instead?

     

    Trevor
    Monday, September 8, 2008 8:58 PM
  • Trevor,

     

    Thank you for your reply!  My post had been sitting there for a while and I was starting to think MSDN had been hit by an asteroid or perhaps a stray black hole from the large hadron collider... but I digress....

     

    OK, that makes sense about the state being passed by value.  Phewwww!

     

    I was afraid the winform magic wasn't real and that only a handle could be passed.  Is this somewhat related to an old VB6 realm fact that winforms are "special" objects?  I know when .NET came out, they touted that Forms are finally real class objects, blah, blah, blah, but there still seems to be something not quite straight (read:  legacy) about them.

     

    Regardless, your suggestion to pass the form data is a good one.  I think that may be my only option.

     

    I was hoping to be able to instantiate and populate the form on a central server, and then pass the pretty painted form back to the client.  This approach would have the benefit of allowing the .NET assembly that contains the winform objects to reside on the central server, and thus some improved maintainability/flexibility could be achieved.  Oh well.

     

    Say, as long as I got you on a thread - can I ask you another question?  Great!  OK, I am currently architecting a C# solution for a client and I'm wanting desparately to incorporate CCR & DSS.  At this stage, it really has nothing to do with robotics.  However, I've read that some firms have applied CCR & DSS to say, financial applications.  This may work perfectly for my solution.  Whooops, I'm losing focus because that's not what my question is really about.

     

    Here is my question:  Am I crazy to want to have all the objects in my application communicate only through events?  This may be overkill and definitely a lot more work, but I don't feel that the UI should drive the objects; rather the objects should dictate their own UI.  This is not the standard beginner VB "Hello World" approach, but I'm trying to achieve a loosely coupled architecture that MRDS encourages, but apply it in a traditional n-tier client server arena.  I'm guessing your gut reaction would be to ask:  "why not use the MRDS message-oriented approach"?  Simply put: my customer would freak out --> they only understand and only want to understand C# client-server stuff.  Regardless, the more I architect the solution in which objects only communicate asynchronously via events, the more it starts to look like CCR with task queues, generics, coordination primitives, etc...

     

    Any ideas/suggestions?

     

    Thank you,

     

     

    Tuesday, September 9, 2008 4:19 AM
    Moderator
  • There is still some "magic" with WinForms. In particular, they use a Single Threaded Apartment (STA) model and so we have to do some fancy programming in RDS to handle them. They have what is called "thread affinity" which means that you can only update a Form from the same thread that initially created it. This is yet another reason why you cannot pass a running Form across to another computer.

     

    I don't think that the maintenance is a big issue. You will have to distribute updated application code if you change a Form anyway. (Otherwise how will it know what to do with new/changed fields?) With RDS you simply have to copy over the DLLs to a working system and you can run the new application. We even provide a tool for creating the installation packages called DssDeploy.

     

    Yes, CCR & DSS are being used for non-robotics applications. Unfortunately most of them are "trade secret" and the organizations concerned don't want to give out many details.

     

    There is nothing wrong with writing applications that communicate only using "events". In MRDS we call them notifications, but it is basically the same thing. In particular, we use the REST (Representational State Transfer) model. This is how web services work, although the DSS protocol makes some extensions such as asynchronous notifications.

     

    You can think of the CCR and in particular DSS as client-server on steroids because an application can actually be distributed across multiple nodes, i.e. it is more peer-to-peer whereas in client-server there is a "master" and some "slaves". It can handle a very high volume of messages (the limitation on throughput is usually the processing time in the application) and it forces you to think about the information you want to maintain (state) and the information and operations that are required to update that data (messages).

     

    We realize that MRDS presents a new programming paradigm for many people, but a new approach is necessary if you want to take advantage of parallelism.

     

    Trevor

     

    Tuesday, September 9, 2008 4:13 PM