Carsten Posingies

Hello there,

I'm currently trying to get my hands dirty with WCF. I pretty carefully studied all the various examples which come with the VS 2008 MSDN release. My (really just my ) problem is as follows: all examples I've seen so far strictly divide a WCF communication pair into a client and a service. Worse, there's no shared contracts neither data nor services/operations. After building and hosting a service, all the examples use svcutil.exe to generate the client stubs. This generated code implements the same contract as the service, but in a pretty different way which leads to funny code like the service calling the client's "sendXyzRequest" method.

For my tiny brain, a better approach would be a central point (assembly, whatever) which defines the data and service contracts and which both the client(s) and the services share by referencing this authority. Furthermore, even the implementations could be in one single place. For a request/response service you'd get a pretty straightforward sequence of method calls: client sends the request, service receives the request, service processes the request and creates an appropriate response, service sends the response, client receives the response. In a clean implementation, you'd completely hide any service.XYZ() calls within the client's code and vice versa.

BUT, in order to do this, there may be only ONE acmeClient.SendOrder() method, ONE acmeService.ReceiveOrder() method, ONE acmeService.SendOrderConfirmation() method, and ONE acmeClient.ReceiveOrderConfirmation() method, thus TWO classes which have to be the SAME TWO classes at the client and at the service, while the examples deal with four classes which only partly implement the contracts, but the "client's client side" and the "service's client side" implement the same contract's parts in different ways. At least to me this looks pretty ugly.

If anybody knows some examples which reflect my babble I'd be thankful for any hints.



Re: Windows Communication Foundation (Indigo) Beginner's question on WCF + MSMQ (party regarding the MSDN examples)

Alex_NZ

Well, WCF is designed to solely support SOA architecture, i.e. building _loosely_ coupled software solutions.. So you service is defined and used through published and discoverable interfaces. And all that generated proxy code you can see is actually here to help you consume them, it is not intentional part of WCF as one can say =))

If SOA is not working for you for some reason, there are other ideas and technology to build distributed systems, Remoting for example.

Regards,
Alex.




Re: Windows Communication Foundation (Indigo) Beginner's question on WCF + MSMQ (party regarding the MSDN examples)

David Kreutz - MSFT

As Alex points out in his post, WCF is designed to support Service in one location, Client in another and to have exactly this sort of loose coupling. Now if you as the application designed want to code up both the client AND the service and for development purposes share some code files between them, thats completely doable. You could create two seperate projects for example (Client and Service) and have a shared Interface.cs file between them. svcutil is essentially doing what you would do, it just does it in a more verbose way, its really the same approach.

I think you are missing something however, you implement methods such as "RecieveOrder" or "SendConfirmation" on your service, and then CALL those methods from your client. A better naming convention could be "PlaceOrder" and "ConfirmOrder". For example

//INTERFACE

[ServiceContract]

public interface IAcme

{

[OperationContract]

int PlaceOrder(Order input);

[OperationContract]

int ConfirmOrder(int orderNumber);

}

Your service would implement a PlaceOrder method that takes an Order object and returns an order number. Your ConfirmOrder method might take that order number and return a confirmation number. Or you could simplify it further, and return the confirmation number from the PlaceOrder method if it succeeded and use a Fault to show failure. There's lots of approaches. It just depends on the type of solution you need. WCF is fantastic for many distributed scenarios but its not for others and for some scenarios its not necessary at all. You'll have to look at what you need what WCF offers to determine whether its the right fit, or whether another technology (remoting, etc) is better.