Advantages of having non interoperable services in WCF?

148 Views Asked by At

We are having some discussions about use of WCF and creation of services and client support.

Currently we support a silverlight client by providing silverlight versions of our service libraries client side, so that we can keep the strong typing of our service contract which is defined using interfaces.

This is ok, but having the service defined with interfaces makes it awkward for other clients as the WSDL has a lot of methods return ArrayOfAnyType and everything is just objects at the client end (which can be cast to the correct type, but as I said, its awkward).

We could rewrite our services to use explicit DTOs for the message transfer and recreate our business objects using similar client side libraries, which would make our service much more interoperable.

Doing this though would seem to block off some options for us, such as using EntityFramework and the self tracking entities it provides as these require the same libraries to be shared on client and server and are not interoperable (correct me if I've got this wrong)

It seems like there is a trade off between being interoperable and having access to more functionality out of the box, allowing for quicker development of solutions.

So my question is what advantages do we gain by deciding to be non interoperable and only supporting .net and silverlight client (if supporting silverlight clients can be considered non interoperable)? And what useful .net features do we block ourselves off from by deciding to be interoperable?

Are there standard techniques for allowing both types of solution to co exist, so you can support .net clients using the full range of features available to you, but still support other non .net clients well?

1

There are 1 best solutions below

0
On

You can use the Facade Pattern for this.

Move your current logic to the business layer, do not expose it via WCF.

Now create 2 WCF services one for each of the contracts you wish to support. This layer will map the business layer objects to the contract objects and call functionality in the business layer.

You then have a central place for all logic and custom services for each client.