Two wcf servers vs a wcf server with callback

I have got two applications that need to communicate via WCF: Called A and B. A suppose to push values to B for storage/update B suppose to push a list of values stored in it to A

the senior programmer in my team wants to open a WCF server at A and another WCF server at B.

I claim that one sh开发者_如何转开发ould be the server and the other should be the client and use server call back In order to avoid splitting the interface into two, avoid circular dependency, and duplication of code settings. he doesn't understand it. can anyone help me explain him why his solution is bad code?

---

It depends on your criteria. Let's assume a client/server model where A is the client and B is the server. You state that B should "push" data to A.

If you truly need push then you should make B into a duplex server. This does put some strain on your bandwith, so if you have a bandwith restriction, this might not be the right choice.

If you can incur some delay at A than you might want to opt for a polling mechanism of your own (maybe based on timing, or some other logic).

If both are not an option, you can try and swap roles. So then make B the client and A the server. It's les intuitive, but it might fit your scenario. If you can incur a delay on storing data, make B poll A for changes in the data and save at an interval.

If there can be no delay in both and bandwith is limited, you do end up with two WCF services. Altough it may look silly at first glance, keep in mind they are services and not servers. It does make things a bit more complex, so I would keep it as a last resort.

---

A service should encapsulate a set of functionality that other applications can consume. All it does is wait for and respond to requests from other components, it doesn't initiate actions by itself.

If Application B is storing data, then it can of course be provided to Application A as a service. It provides the "service" of storing data without application A having to worry about how or where, and returns successfully stored data. This is exactly the kind of thing that WCF Services are meant to handle.

I am assuming that application A is the one initiating the requests (unless you have an unmentioned 3rd application, one of them must be the initiator). If Application A is initiating actions (for example, it has a UI, or is triggered to do some batch processing etc.) then it should not be modeled as a "service".

I hope that helps :)