none
Using DataContracts for an external WCF Service RRS feed

  • Question

  • Hi,

    I have a WCF Service which is consumed by a asp.net web application. Currently, I own both client and server side where as it might get extended by adding more service clients later.

    I used the following guideline to structure my WCF Service/Client- WCF the Manual Way… the Right Way  http://www.code-magazine.com/Article.aspx?quickid=0809101

    I use a manual ClientProxy class to expose webservice methods to the web application as many experts recommend  not to use Add Service Reference feature in VS.

    I need to consume complex data types (DataContracts) in my webapplication.  As far as I have the assembly for the datacontract in my solution, it will be no issue to have a reference to the data contract project. Basically, I added a reference to my web application which points to the data contract project in the same solution.

    I have few questions regarding this approach.

    1. How would somebody else consume my service without knowing the meta data (data/service contract) given that the person has to use a manual client proxy?

    2. Do I need to provide that person with data/service contract assemblies?

    Your responses are highly appreciated.

    Thanks

    Wednesday, January 9, 2013 2:54 PM

Answers

  • Anyone consuming your service needs to know what the contracts look like, it just depends on how you want to provide the definitions to them.

    You can either share the WSDL or a common assembly that holds the data and service contracts.

    You can share the WSDL by pointing someone to your running service so long as its configured to expose and allow its metadata to be pulled.  If its not (or you don't want to set that up), you can run the svcutil.exe over your assembly that contains your service and data contracts to generate WSDL.  If you are working with a non-.NET (i.e. java) client you will most likely need to share the WSDL with them.

    Or you can share an assembly that contains your data and service contracts if you are working with a .NET client.

    If you think about what the VS add service reference does, I believe it pulls the service WSDL, and then generates the WCF classes, data, and service contracts from it.  I don't typically take this approach myself, but it really depends on what you are trying to accomplish.

    Keep in mind there are some versioning concerns you will want to keep in mind before you start shipping things out to external clients.

    Hope this helps.

    Wednesday, January 9, 2013 7:51 PM

All replies

  • Anyone consuming your service needs to know what the contracts look like, it just depends on how you want to provide the definitions to them.

    You can either share the WSDL or a common assembly that holds the data and service contracts.

    You can share the WSDL by pointing someone to your running service so long as its configured to expose and allow its metadata to be pulled.  If its not (or you don't want to set that up), you can run the svcutil.exe over your assembly that contains your service and data contracts to generate WSDL.  If you are working with a non-.NET (i.e. java) client you will most likely need to share the WSDL with them.

    Or you can share an assembly that contains your data and service contracts if you are working with a .NET client.

    If you think about what the VS add service reference does, I believe it pulls the service WSDL, and then generates the WCF classes, data, and service contracts from it.  I don't typically take this approach myself, but it really depends on what you are trying to accomplish.

    Keep in mind there are some versioning concerns you will want to keep in mind before you start shipping things out to external clients.

    Hope this helps.

    Wednesday, January 9, 2013 7:51 PM
  • Thanks for the detail explanation and your standpoint would certainly help me to make a decision.

    Hasitha 

    Thursday, January 10, 2013 4:10 PM