none
WCF serialization architecture question, not creating multiple instances of existing business objects

    Question

  • Hello,
    I've read a book on WCF and have 3 years of experience using web services in 1.1 & 2.0 .net frameworks. WCF makes perfect sense and I am eager to adopt it here, however there is one arhitectual question i am not clear on. In fact i cant find a clear answer for this anywhere.

    One of the pillars of SOA dictates that schema should be shared, and not the class, but this is hard to implement in an environment where WCF is used to communicate between web and middle tier of the same group. Meaning using WCF as transport mechanism between local tiers where the same business objects are widely used.

    If i have a common Trade object within my application framework, I use it everywhere, on all tiers with and without web services. So the problem here is, that if each webservice creates a proxy with its own version of Trade, there will now be multiple instances of Trade defined each in different namespace:

    MyCo.BusinessObjects.Trade
    MyCo.Services.TradeManagement.Trade
    MyCo.Services.TradeLookup.Trade
    etc...

    of course if a Trade is looked up using TradeLookup service, and than attempted to be passed into TradeManagement service it will cause a problem since they are different objects as far as the framework can tell.
    NOT TO MENTION if one property on Trade changes, all of those service proxies have to be regenerated now.

    so what i've been doing, is generating regular ws proxy, and than going in and removing all business objects from its definition, and adding a namespace where they are located so that all services would be usnig the MyCo.BusinessObjects.Trade.
    There is also a library from Think Tekture that will allow you to generate the proxy dynamically, and use whatever objects you choose with it omitting their serialization.

    To summarize i do not wish to maintain multiple instances of the same class. My question is, what are some ways to address this using WCF.
    Tuesday, April 10, 2007 3:55 PM

Answers

  • Hi,

     

    The simplest approach, I can think of, to achieve this objective, is to concentrate all the common objects in a common class library, that is shared among the various services, as well as the clients. This way you don't need to maintain multiple appearences of the same class. In order to make svcutil run without generating this common types while running against the services, when you generate the clients, use the /r option of that tool.

     

    Oren Fisher

    Microsoft, Connected Frameworks

    Thursday, April 26, 2007 6:10 PM

All replies

  • Hi,

     

    You will always need the type definition on both the client and service.  Because the serializers use xsi:type to define the name + namespace of the object, type mismatches should only occur with versioning issues.  We have some good documentation regarding Service Versioning at a number of different levels (e.g. DataContract versioning for your Trade object scenario):

    http://msdn2.microsoft.com/en-us/library/ms731060.aspx

     

    I hope this addresses some of your concerns. 

     

    -- Dave

     

     

    Wednesday, April 25, 2007 10:58 PM
  •  sonic wrote:
    Hello,
    To summarize i do not wish to maintain multiple instances of the same class. My question is, what are some ways to address this using WCF.

     

    it would be nice if svcutil had the /sharetypes options as wsdl.exe had, I guess you could try the /r option for some sharedtypes.dll assembly but I am not sure about the namespace here, will have to repro this.

    @llan

    Thursday, April 26, 2007 4:26 PM
  • Hi,

     

    The simplest approach, I can think of, to achieve this objective, is to concentrate all the common objects in a common class library, that is shared among the various services, as well as the clients. This way you don't need to maintain multiple appearences of the same class. In order to make svcutil run without generating this common types while running against the services, when you generate the clients, use the /r option of that tool.

     

    Oren Fisher

    Microsoft, Connected Frameworks

    Thursday, April 26, 2007 6:10 PM
  • This discussion brings me to a similar question: How do these services interact with other plataforms if there is a .net contract dependency?
    Thursday, April 26, 2007 6:12 PM
  • yep, that's it, thank you
    Thursday, May 24, 2007 4:18 AM
  • I'm facing this same problem.  But have DataContracts both shared by services and specific to a service.

     

    Say I create an assembly that defines the DataContracts I want to share amongst services, then reference it in my various services.  Am I then forced to put all of my DataContracts in this assembly?  For example, if I also have DataContracts that are specific to one service I can see from the service side how I just reference the shared assembly and also define service specific DataContracts.  But on the client side how do I generate proxies that use both the shared assembly and DataContracts from the specific service?

     

    If I run svcutil against the shared assembly I'll get all the shared DataContracts, but how do I then get just the specific DataContracts out of each service, without redefining the shared ones when I run svcutil against my service?

     

    Can anyone speak as to whether WCF 3.5 adds any support in this area?

     

    Monday, October 01, 2007 7:01 PM
  • Thanks Fisher..

     

    Whats your comment on "How do these services interact with other plataforms if there is a .net contract dependency?"

     

     

    Thursday, May 08, 2008 6:43 PM