CODEWITHSUNDEEP
c#wcfsoap
Axel GeNuS
Axel GeNuS

Reputation: 610

Share data contracts among different namespaces

I'm facing some problems with WCF and namespaces. The situation is this: my webservice (let's call it "WS-A") should act as a proxy to another (more complex) webservice ("WS-B"). WS-A exposes simpler interfaces for an application we developed so it simply "hides" some business logic we don't want to end in our application. We got the WSDL and XSD schemas for WS-B and imported them in C# with svcutil. Obviousely it carried over the namespace of WS-B (http://ws.source.com). For WS-A we're using some other namespace (http://ws.example.com). Some data structures have to be shared among the two webservices but I haven't been able to reuse the same data contracts. AFAIK WCF requires data and service contracts' namespaces to be "static" and cannot be decided at runtime. Is there a way to do that with WCF or I should change my strategy?

EDIT: Here is an example trying to clarify what I need.

                                  Namespace A     V      Namespace B
                               +--------------+   |   +--------------+
                               |              |   |   |              |
           Application >-------+ Webservice A +-------+ Webservice B |
                               |              |   |   |              |
                               +--------------+   |   +--------------+

The application calls the operation "GiveMeData" of WS-A which uses namespace A as described in its WSDL. The response contains a reference to the class "Data" which is actually a data structure obtained from WS-B which uses namespace B.

[DataContract(Namespace="http://namespaceB")]
public class Data {
...    
}

So the response would bind Data to the wrong namespace.

Upvotes: 1

Views: 779

Answers (1)

Greg
Greg

Reputation: 946

So you want to reduce the amount of duplicate code in your system as well as possibly skip some object deep-copy operations that seem pretty pointless?

The comments on the question indicate this is a bad idea, and I concur. When either you or the backend web service need to change the contract, even just a little, you won't be able to, or will end up with two data contact classes anyway.

Instead, you should keep two POCO class definitions, even if they are the same structurally, and manage the clone/copy process with something like http://automapper.org . That way, you take advantage of some conversion caching in the mapper, and keep your code clean.

If you insist on using the same POCO on both ends of the proxy service, you probably want to code with the backend POCO only. But then you would need to manipulate the message in the WCF pipeline after serializing responses (before it goes to the wire), and before deserializing requests (before it gets turned into POCOs. The former is a bit of a hack. You can think of it like redacting info from the response using regex replacement on the namespaces. As you control the serialized stream for responses, this is not too difficult. But you don't control what gets sent to your proxy service, so the regex to manipulate the requests will be proportionately more complicated, and very error prone. Take a look at this example of a WCF custom message encoder: https://social.msdn.microsoft.com/Forums/en-US/0da33309-ec07-47d6-8ddb-15290a80977f/wcf-hook-in-after-serialization?forum=wcf .

The author of that answer has a few other blog posts on the subject with different approaches. Bottom line, the code to accomplish your desire gets really weird, really fast.

Upvotes: 2

Related Questions