Expose 3rd party interface (over WCF) to Silverlight

Question

Hi.

I searched a lot, apologies if I missed something obvious. And thanks for reading the looong text below.

I have a 3rd party (read: No way to access/change the source) application here. It consists of a server (Windows service) and an API, that talks to the server via remoting. For several reasons I'd like to expose this API over WCF (see subject: One reason is a WCF client).

The problem is, the API is

1. unchangeable (follows 3rd party rule)
2. using no WCF itself (it is serializable/MarshalByRef where necessary for Remoting)
3. using lots of interfaces and internal implementation classes

Following 1 I cannot use the (quite intrusive) WCF attributes myself.

Following 2 the API itself can be used "over the wire" (they support remoting via TCP and HTTP), but remoting is not good enough for me.

Following 3 I have mostly interfaces (which WCF won't handle well, cannot (de-)serialize). The implementation classes could be sent over, but - I cannot access them.

The general usage for this API is based on a single interface (and its members/properties), so the typical usage is like

var entryPoint = new ApiClientEntryPoint();
entryPoint.SomeMethodCall();
entryPoint.PropertyExposingAnInterface.SomeOtherMethodCall();

and so on.

What I'd really like to do is generate (with as little effort/code as possible) a proxy (not in the typical WCF sense) that I expose via WCF and that serializes this hierarchy mapping every call/property on the client to the real thing on the server.

The closest I've come so far is stumbling upon this project, but I wonder if there are more/other tools available that take a medium to large part of this work off my shoulder.

If there are any general other advices, better approaches to wrap something preexisting and unchangable into WCF, please share.

Answer 1

My advice is to use a facade pattern. Create a new WCF service that is specific to your usage and wrap the 3rd party service. Clients would talk to your service and you would talk to the 3rd party. But clients would not talk to the 3rd party directly.

This would work in most but not all scenarios. I'm not sure of your particular scenario so YMMV.

BTW you can look at WCF RIA Services which is good for exposing services to Silverlight where you can avoid doing a lot of the hand coding of service stuff. But again depending on your particular scenario it might not be the best way to go.

Edit:
It's now clear that the API is too big and/or the usage patterns of the clients are too varied in order to effectively use a facade. The only other thing I can suggest is to look at using a code generation tool. Use reflection (assuming it is a .NET API?) to pull apart the API and then codegen new services using the details you gathered. You could look at the T4 templates built into Visual Studio or you could look at a more "robust" tool such as CodeSmith. But I'm guessing this would be some painful code to write. I'm not aware of an automated solution for this.

Is the API well documented? If so, is the documentation in a parseable format such as XML or well-structured HTML? In that case you might be able to codegen from the documentation as opposed to reflecting through the code. This might be quicker depending on the particulars.

Answer 2

Okay, hair brained scheme #1 on my side:

1. Use Visual Studio Refactor menu to "extract interface" on 'ApiClientEntryPoint'.
2. Create a new WCF service which implements the above Interface and get VS to generate the method stubs for you.
3. 'For PropertyExposingAnInterface.SomeOtherMethodCall' You will have to flatten the interfaces as there is no concept of a "nested" service operation.

Your only other option will be to use T4 code gen ,which will probably take longer than the above idea.