none
Migrating to WCF from Remoting RRS feed

  • Question

  • Hi,

    I am trying to migrate to WCF from .Net Remoting.

    I have the following problem:

    I have a complex object that contains a big object tree and I need to access it remotely. Let's say my main class is A and it contains B as a member, and I declare A to be a WCF service and publish it.
    Now I need to do the following remote call:

    a.GetB().DoSomthing();


    But I Don't want B to be serialized. I want to be working on the remote instance.
    In Remoting I was able to make B an MBR object which was great.

    Is there an easy way to achieve the same kind of functionality in WCF accept going through all the cumbersome procedure of sending an EndpointAddress instance and construct a channel and all that?

    Thanks,

    Ori D.
    Thursday, April 12, 2007 10:37 AM

Answers

All replies

  • No, sorry, you will have to have to make B its own addressable endpoint as you suggest.
    Friday, April 13, 2007 9:26 AM
  • >>No, sorry, you will have to have to make B its own addressable endpoint as you suggest.

    So that means, that, for the real-world scenario that this post describes, WCF does not provide an adequate solution. Remoting, however, does.

    I am facing the same requirements as the ones this post describes, as are probably many others. The business logic contains a data tree object, where each objects consists of properties that point to sub-objects. Basic stuff. something like:

    public class A {
       public B B {get;set;}
       public X X {get;set;}
    }

    public class B {
      public List<C> C {get;set;}
    }

    and so on, so you can write things like:

    A.B.C[2].D = 42

    These trees are big, and they can easily reach a depth of 8 nested objects, and hold hundreds or thousands of objects. Making every B,C,D and thousands of others, each be its own addressable endpoint is unrealistic.

    Remoting does give a solution to this via MarshalByRef. Remoting is excellent technology, but the sad part is Microsoft is now unwilling to make even the most trivial fixes to fix a few critical bugs in Remoting, claiming that Remoting is superseded by WCF. This attitude is cleary evident in Connect discussions.

    These trees are very useful for example in data-binding. That is, Data bind a remote GUI to the business objects server. The GUI needs control and monitoring over each and every (nested) property in the tree.

    The current trend, to market the new and cool WCF,while letting Remoting rust away unmaintained, simply means that the .NET framework does not meet the needs of developers when it comes to remote access, such as described in this post.
    Saturday, September 15, 2007 7:43 PM
  • Even Serializing GetB wont help as it wont have a method its just data...

     

    The Dosomething normally would be a new operation - this is where the mismatch between SOA and remote Object architectures  become apparant.  You really have 2 choices

     

    GetSOmething becomes an action . The problem with this is you can get many RPC style actions. Please note though in many cases

     

    GetB()  , B would be a diifferent service from GetC() .

     

    WCF is not a remote object architecture... You really need to redesign . The best way is to forget the previous association between client and server , the shared dlls are now seperate and add a new message conversion layer.

     

    Though a lot more code , this will be quicker as you dont have to learn quirks in serialization and  give you chunkier less chatty messages.  The code is also very simple.

     

    Think of the WCF messages as SQl data ( even inheritance/contract interfaces are only supported through tricks)  and operations as the query - not objects.

     

    Regards,

     

    Ben

    Sunday, September 16, 2007 2:10 AM
  • Sorry missed the follow up  message.

     

    There is nothing wrong with remoting , i would still use it for some new projects  , its not going to go away for another 10 years and you have got critical bug fixes over the last few years  (.NET 2.0 had quite a few) . You just need to know why SOA was invented and what is does that remoting fails ( and fancy comms , security and Xml messsages have nothing to do with it) . IMHO too many people upgrade to WCF from remoting when they have the wrong architecture and converting to a different architecture is expensive.  The only issue with remoting is lack of security / new features  but this is a resource choice by MS who clearly want developers to take the SOA route .

     

    "
    These trees are big, and they can easily reach a depth of 8 nested objects, and hold hundreds or thousands of objects. Making every B,C,D and thousands of others, each be its own addressable endpoint is unrealistic."

     

     

    That is a remoting architecture choice .In SOA the tree would either be on the server with only the result of such a tree being exposed ( or on the client with server data used to populate it) .  In rare cases where both have access (a design flaw) the server wouild send the entire tree as one data message and the client would ocnvert it to a local tree,

     

    Just different ways of doing things. It is likley in 90% of scenarios the SOA soultion will be better however your existing design

     

    Note SOA does send data trees used for data binding ( though you would normally send 2-3 trees with a depth of 1-3 (Ocassionaly 4 or more ) ) not one massive tree.  Databinding does not support operations on these trees anyway eg your doSomething.  The client logic and the server logic are quite distinct and it is even common practice to remap the server data into a new client domain model this can be usefull as they have different points of reference eg UploadChanges on the client is Persistchanges on the server.

     

    The real difficulty is converting apps with no major redesign  ,I realise now that  this is maybe why MS adviced in 2004 not to develop new systems as remoting and they should use Basic web service ( or later WSE) and if not use enterprise services ( Dcom) , upgrading from these architectures is more trivial as they have not abstracted away the inter process communication later. 

     

    Regards,

     

    Ben

    Sunday, September 16, 2007 2:45 AM