WCF to WCF Communication

Question

I have an architecture, where there are the following constituents:

1. External Applicaton (EA) - Third party who makes a request to WCF Service
2. WCF Service (WS) - All the business logic
3. Pub-Sub Service (PSS) - Handles publishes and subscriptions
4. Internal Application (IA) - Subscribes or unsubscribes to Pub-Sub (with CallBacks)

The external application (EA) references the WCF service (WS) and makes a call to a specific method, to which all Internal Applications (IA) should be notified through the Pub-Sub Service (PSS).

The problem I have is in deciding whether it is feasible or best practice to get one WCF Service (WS) to communicate with another WCF Service (Pub-Sub Service). I've read that this is not a good idea given that requests are processed in a synchronous manner and this could cause inconsistencies in service delivery.

My specific question based on that is - can someone share pro's and con's of allowing two WCF services to talk to one another; or is this a non-issue?

Thanks

Answer 1

I am totally agree with Steven. You should consider using message queue here. And the resources are below:

http://msdn.microsoft.com/en-us/library/ms751499.aspx

http://msdn.microsoft.com/en-us/library/ms731089.aspx

http://www.codeproject.com/Articles/34168/WCF-Queued-Messaging

Hope those will suffice. Thanks.

Answer 2

I agree with the other answers, however since a message oriented approach is not feasible with your available resources, I'll put it this way.

As long as your WCF services are acting as a client (your 'WS') and a server (your 'PSS'), it will share the pitfalls of any client-server application. However, this assumes a couple of things:

a) Your 'WS' implements One-Way operations, or "fire and forget", towards your 'EA'. See here for reference: What You Need To Know About One-Way Calls, Callbacks, And Events . Otherwise, the 'EAs' will have to wait until your internal call to 'PSS' completes.

b) Your 'WS' channel is configured and has well and enough resources to handle the load, because One-Way operations aren't really asynchronous; if the channel can't handle the load the calls will queue up and block the client until resources are freed and execution can continue.

c) No constraints as to guaranteed, transactional or ordered delivery or any other messaging-like behavior is required.

But, a said before this sort of scenario really calls for a message based architecture. You have several points of failure and troubleshooting this chain of dependencies will be no fun.