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?