none
How to pass a reference in WCF

    Question

  • I have a client and server setup in WCF. The method takes a reference type as a parameter. When the server makes updates on this parameter, the client does not see the changes.

     

    Here is the pseudo code for the call:

    Code Snippet

    //In client:

    MyCustomType obj = new MyCustomType();

    obj.PropertyA = 15;

    myServiceContractProxy.DoSomethingOnServer(ref obj);

     

    //On server

    void DoSomethingOnServer(ref MyCustomType obj)

    {

    obj.PropertyA = 100;

    }

     

    //Back on client after call

    MessageBox.Show(obj.PropertyA); //Still shows 15

     

    So what do I need to do to have this reference properly updated?

     

    Thanks for any information.

    Friday, September 7, 2007 11:49 PM

Answers

  • Ah, please ignore this post. My class that was being used as the DataContract had a base class that was not properly setup as a DataContract itself. In the example above, PropertyA was not marked as a DataMember.

     

    Saturday, September 8, 2007 12:01 AM

All replies

  • Ah, please ignore this post. My class that was being used as the DataContract had a base class that was not properly setup as a DataContract itself. In the example above, PropertyA was not marked as a DataMember.

     

    Saturday, September 8, 2007 12:01 AM
  • Id avoid ref and out paramaters if i were you , Soap doesnt understand it so you

     get am object[] returned in your proxies ( asmx) not sure about WCF  but you are not really representing what is on the wire/

     

     

    Regasrds,

     

    Ben

     

    Saturday, September 8, 2007 2:14 AM
  • Good point. It is sometimes a bit challenging to handle references in soap technologies, but it seems to be working okay in WCF. I have the data contract classes available to both the client and server and I'm creating my proxy class 'manually' to make sure my types are correct.

     

    It does bring up a larger point though: WCF accomodating both service oriented systems as well as enterprise distributed systems. I'm really hoping that WCF meets the needs of both. The general response to enterprise distributed systems asking about references is that we should avoid the tight coupling, but I think a lot of people don't realize that tight coupling in and of itself is not evil. If I'm developing a true SOA implementation then I'd want to avoid tight coupling, but if I'm developing a distributed enterprise solution then it may make perfect sense to have the distributed plumbing allow reference sharing in a more RPC style. The danger of tight coupling can still exist if your system is designed wrong but if I have an OO-based data contract, then there is no reason (in my mind) that there should be any restriction on reference passing in whatever form.

     

    From what I've seen so far with WCF, it seems to be okay, but I've seen threads on the forum of people complaining that their remoting solutions don't exactly port with regards to the reference sharing. I've also seen solutions that suggest it is still possible through configuration and extension, but I really hope that MS keeps both development camps in mind. I'm also not 100% clear on whether WCF is intended to completely replace remoting, but I do hope so because it would be a shame to not be able to take advantage of the WCF plumbing just because we're after a more RPC approach.

     

    I'm not trying to knock your comment, I appreciate the input. It just seemed like a good point to mention this.

     

    Thanks

    Saturday, September 8, 2007 3:08 AM
  •  

    "Good point. It is sometimes a bit challenging to handle references in soap technologies, but it seems to be working okay in WCF. I have the data contract classes available to both the client and server and I'm creating my proxy class 'manually' to make sure my types are correct.

     

    It does bring up a larger point though: WCF accomodating both service oriented systems as well as enterprise distributed systems. "

     

    SOAP aand SOA provids more benefit within an organisation than between an organisations. SOA systems are distributed enterprise systems. I would have said  both SOA and legacy remote object systems ;-)

     

    "I'm really hoping that WCF meets the needs of both. The general response to enterprise distributed systems asking about references is that we should avoid the tight coupling, but I think a lot of people don't realize that tight coupling in and of itself is not evil. If I'm developing a true SOA implementation then I'd want to avoid tight coupling, but if I'm developing a distributed enterprise solution then it may make perfect sense to have the distributed plumbing allow reference sharing in a more RPC style. The danger of tight coupling can still exist if your system is designed wrong but if I have an OO-based data contract, then there is no reason (in my mind) that there should be any restriction on reference passing in whatever form."

     

    It really depends on the size of the organisation - the big issue with the tight coupling was you needed to manage/rebuild clients from previous projects that used the server when the server was extended.This severly limited re-use.  For organisations where reuse and sharing are not important remote objects are a stronger solution.

     

     

    "From what I've seen so far with WCF, it seems to be okay, but I've seen threads on the forum of people complaining that their remoting solutions don't exactly port with regards to the reference sharing. I've also seen solutions that suggest it is still possible through configuration and extension, but I really hope that MS keeps both development camps in mind. I'm also not 100% clear on whether WCF is intended to completely replace remoting, but I do hope so because it would be a shame to not be able to take advantage of the WCF plumbing just because we're after a more RPC approach."

     

    Make no mistakes WCF was designed as an SOA tool .. If you follow SOA principals and keep simple chunky messages ( avoid inheriitance, interfaces , non SOAP types , generics etc ) you will get thinsg up and running MUCH quicker and your system will run better.

     

    "I'm not trying to knock your comment, I appreciate the input. It just seemed like a good point to mention this.".

     

    I have 3-4 conversations about legacy distributed OO code . I think its important to highlight to forum readers when and what to use. It should be noted if i was writing a distributed OO app and didnt need security id use Remoting which i used quite hapily in 2000. If reuse and sharing is important id leave the objects in the business layer and provide an SOA conversion layer ( in client and server) .

     

    The leap to SOA for OO developers is much harder.

     

    Regards,

     

    Ben

    Sunday, September 9, 2007 4:02 AM
  • I'm afraid there is some kind of misconception that distributed OO systems provide lesser solutions somehow. The difference between SOA and distributed OOP is a matter of the right architecture for the right solution. If I'm developing several standalone servers in a company's information system, then SOA makes perfect sense. If I'm developing shrinkwrapped distributed software that goes through a full release cycle (including every client/server in the entire system), then SOA does not make as much sense.

     

    "For organisations where reuse and sharing are not important remote objects are a stronger solution."

     

    I don't mean to be argumentative, but the fact that you think reuse and sharing are things you can't acheive in distributed OO solutions makes me think that you really aren't familiar with a true distrubted OOP solution.

     

    In fact, in reality, the only difference between SOA and distributed OOP (at least in the context we're talking about) is tight/vs loose coupling between client/server. Security, reuse, flexibility, cohesion, etc, all these facats are things you can achieve with both approaches.

     

    Actually, in terms of WCF, all the difference really means is that you use a class for your data contract instead of using a message and translating that back into some form of state on the other side of the wire. It's really the same thing as long as you've design the RPC system properly.

     

    Now, having said that, I do intended to design our external http-based services as true SOA clients because it is a much different solution: a) it is a system unto iteself, b) it needs interoperability with non-.Net clients, and c) we want to be able to upgrade it independently of any other system. So SOA makes sense here. For our distributed software, this doesn't make sense because if I change something on a server, I want to completely recompile, retest, re-everything any client that consumes it. It is a much different ballgame, not to mention we have .Net on the client and server, and the WCF services are just parts of a larger whole, that would never be independently upgraded.

     

    Anyway, I could go on. To summarize, I just think people don't realize that this is not a mutually exclusive concept. There is room for, and should always be room for, both approaches because they are very different solutions to very different problems.

     

    I hope my points came across clearly. Always interesting to debate this type of thing. Thanks for your input.

     

    Monday, September 10, 2007 8:57 PM
  • No problem with your points these debates are healthy ... if they dont get personal. I used to do a lot of remoting in .NET 1.0 days and had some painfull lessons. I was cautious on SOA at first but im now an advocate.

     

     "I'm afraid there is some kind of misconception that distributed OO systems provide lesser solutions somehow. The difference between SOA and distributed OOP is a matter of the right architecture for the right solution. If I'm developing several standalone servers in a company's information system, then SOA makes perfect sense. If I'm developing shrinkwrapped distributed software that goes through a full release cycle (including every client/server in the entire system), then SOA does not make as much sense."

     

    Even for shrink wrapped full release cycle an SOA product can do the job quite well. However the design philosphy for OO does not  easily map to SOA. 2 Tier VB apps talking to SQL are much more simlar to SOA services than distributed OO and there are plenty of these .

     

    When you release a client app as 3 tier instead of 2 there is normally a good reason to justify the much higher cost. The same goes with SOA.

     

    I fully admit an existing OO layered 1 tier or 2 tier app can be easily converted to Remoting ( though it may not be efficient) .Its not so easy to convert to SOA.

     

    On the other hand a typical 2 tier VB app can be converted to SOA by getting the SOA to server the data first.

     

    "For organisations where reuse and sharing are not important remote objects are a stronger solution.

     

    I don't mean to be argumentative, but the fact that you think reuse and sharing are things you can't acheive in distributed OO solutions makes me think that you really aren't familiar with a true distrubted OOP solution."

     

    I have worked for 3 organisations in the last 10 years who used OO and no one reused libraries between systems even thoguh everyone had a program to encourage this  (some teams used different languages like Small talk ,VB ,Java )  a few conferences have showed this .  For OO it was promised to share code however in practice this is a myth . How often have you see some OO order system in place and then when a stock system was written the code was reused and expanded whcih another team wrote,

     

    With remote objects this was promised but this was a disaster  the binary serialization model mean if the service was updated  all the old clients would crash as the version information was contained  in the serialization .  THis really meant different teams did not reuse remote object components.  ( ES achieved more success) .

     

    People learned accessing objects from  fascade and using DTO's provided a more robust models which dealt better with cross machine performance and could handle comms errors in a more organised way. The recent example in this list a.GetB().DoSomething() was  not good practice even in 2001.

     

     

    A few advanced remoting sites did take the serialization issues into account and made looser couplings , they used XML , Service interfaces  and XSD to generate your classes and you have poor performance so need chunky messages and you pretty much have SOA.

     

    The one exception here is companies that provided a single piece of software - here as its a single team there is no need for SOA and remoting offers a good solution.

     

     

    "In fact, in reality, the only difference between SOA and distributed OOP (at least in the context we're talking about) is tight/vs loose coupling between client/server. Security, reuse, flexibility, cohesion, etc, all these facats are things you can achieve with both approaches."

     

    Agreed , note the tight coupling made sharing difficult.

     

    "Actually, in terms of WCF, all the difference really means is that you use a class for your data contract instead of using a message and translating that back into some form of state on the other side of the wire. It's really the same thing as long as you've design the RPC system properly."

     

    Agreed.

     

    "Now, having said that, I do intended to design our external http-based services as true SOA clients because it is a much different solution: a) it is a system unto iteself, b) it needs interoperability with non-.Net clients, and c) we want to be able to upgrade it independently of any other system. So SOA makes sense here. For our distributed software, this doesn't make sense because if I change something on a server, I want to completely recompile, retest, re-everything any client that consumes it. It is a much different ballgame, not to mention we have .Net on the client and server, and the WCF services are just parts of a larger whole, that would never be independently upgraded."

     

    The real beauty of SOA services is if you add a new method for 1 client or add a parameter you do not need to test any other client its guranteed to be unaffected by the additional data. Addiionally you can version the contract and expose a new end point again less testing work.

     

     I use TDD test now with SOA services and i think its a great model .  I know how the services will perform , i still need to test my clients but these tend to be simple anyway .

     

    "Anyway, I could go on. To summarize, I just think people don't realize that this is not a mutually exclusive concept. There is room for, and should always be room for, both approaches because they are very different solutions to very different problems."

     

    They are not mutually exclusive but its worth noting SOA came as an evolution from remote objects and to deal with some specific  issues.  If you have a single development team and use good practices like interfaces ,DTO's you can achieve an equivalent  result.

     

    The real issue is OO designs having the same class visable on client and server with SOA this is not the case ( with the exception of frameworks) and bad practice. The client has its own DLL's and does not share them hence testing is easier ( if it doesnt change why test)  it also allows the client to have a different smaller domain than the service. This results in smaller simpler clients.

     

     

    "I hope my points came across clearly. Always interesting to debate this type of thing. Thanks for your input."

     

    Yep i still want to know how you see an SOA full test being different to a remoting one ?

     

    Regards,

     

    Ben

     

    Sunday, September 16, 2007 8:18 AM