Host a WCF service or ask consumers to host one?

I need to implement a bridge application in .NET which, on a high level,

• on the back side talks to an OCR system sending them images and getting back data from the images in readable format
• on the front side, applications would consume the bridge's service (WCF or otherwise) submitting images and expecting readable data as response.

The whole operation would be in asynchronous mode.

The applications that would be consuming services of the bridge can be .NET or Java based predominantly. (there could be a possibility of existing mainframe apps in future too)

My question is regarding the solution to send back the readable data back to the consuming application. As WCF callback are not interoperable with Java, I cannot use wsDualHttpBinding. Hence the 2 alternatives that I see currently are:

• a) Have another web service hosted on the bridge which the consuming application can poll.
• b) Have each consu开发者_StackOverflow中文版mer application host a webservice based on the standardized wsdl provided by the bridge in their own technology. Then the bridge would consume the application's webservice when their data is ready.

The issues I have with both options is:

• With a), polling is always resource intensive, but the consumer application need to only consume this webservice (generate their own proxy class).
• With b, for each application that need to be registered with the bridge, they need to create their own webservice. This doesn't seem to be so loosely coupled as SOA architecture recommends.

My question is, which one is more preferable to keep the system extensible and scalable? Is there any other way to implement this?

I would opt in this case for solution a) although it can mean polling... BUT solution b) has possibly a problem if there are security measures (network/firewall/proxy...) inbetween possibly leading to your service not being able to call their service... or they could implement the WSDL in some incompatible way...

Even if you implement solution b) IMHO you would have to provide solution a) as fallback...

Solution a) has the highest probability of working fine since the clients must already implement some webseervice calls to send the image data...

AND you can make solution a) server-side rather efficient because the operation (OCR) is comparatively "long-running" and the current state can be thus cached heavily in the webservice - perhaps updating state every 10s or so would be sufficient...

EDIT:

Another problem with solution b) is: what happens if their webservice is down for some moments when you try to call it ? You would have to implement some sort (persistent?) Queue etc. to make this reliable...

The way I would implement it is as followed using pub-sub:

Create two messages: GenerateOCRDataRequest - Contains ClientID, Image byte[] OCRProcessCompleted - Contains ClientID, ProcessedData byte[]

The client application will subscribe to the OCRProcessCompleted with their various clientID as a filter. They will also publish the GenerateOCRDataRequest and include their clientID so that when the response returns, they will only get their own requests.

The bridge application will subscribe to GenerateOCRDataRequest - When it receives it, it will process it then publish OCRProcessCompleted with the necessary data

In this scenario, I am assuming that both client and bridge will have a queue which message that are published will be placed and they will simply pop messages from the queue as needed.

If you want to implement the scenario about as described, you can use http://pservicebus.codeplex.com/ which provides api in both Java and .NET to do pub-sub. There are also examples on how to use it here: http://pservicebus.codeplex.com/wikipage?title=Samples%2fExamples&referringTitle=Home

Hope that helps