I have an existing WCF service that I now need to have consume an external WCF callback (aka duplex) service. The duplex service is by its nature asynchronous and yet I need to keep my original WCF service synchronous. Is there a well known pattern to do this? What are the most important pitfalls I need to watch out for?
My current intention is to invoke the duplex service and then wait for a ManualResetEvent to be raised. When the callback is called by the duplex, it would reset the event and make the waiting operation resume and complete its work.
Yes, I'd go this way too. Pay attention to how you control these events' lifetime. Seems like you'll need to pass some id to the duplex service so that, when callback arrives, this id could be resolved into the original ManualResetEvent.
Related
I am writing n duplex WCF application, just want to make sure that the client call must halt till callback method is complete.
Suggestions would be appreciated!
just want to make sure that the client call must halt till callback
method is complete.
To my understanding, in that case, you don't need to employ Duplex Communication system. An singular Request - Reply communication system should suffice; which is by the way, is default communication mechanism.
Is anyone able to help me correctly call a Wcf service from within an NServiceBus Saga\Handler?
Presently I am making a synchronous call from within a Handler.
However, IIRC, in a while ago on the NServiceBus documentation pages it recommended using a Saga but provided no further details.
My understanding is that a Saga is preferred as it can be persisted while the Wcf call is being processed and then resumed to receive the response.
(The only other thought is that a Saga is preferred as they are generally longer running than Handlers).
What I need help with is the most appropriate way to resume the Saga instance on the reply from the Wcf service.
Thanks
Mark
You actually wouldn't want the saga to call any external resource directly.
Instead, the saga would send a message to a handler and that handler would synchronously call WCF and then send a message back with the response.
If the call to WCF times out, the handler would do its automatic retry logic, or potentially the message might end up in an error queue.
The saga would then be able to deal with the logic of what to do if a response is not received within a certain period of time.
I want to implement a WCF service that responds immediately to the caller, but queues up an asynchronous job to be handled later. What is the best way to go about doing this? I've read the MSDN article on how to implement an asynchronous service operation, but that solution seems to still require the task to finish before responding to the caller.
There are many ways to accomplish this depending what you want to do and what technologies you are using (e.g. Unless you are using silverlight, you may not need to have your app call the service asynchronously) The most straight forward way to achieve your goal would be to have your service method start up a thread to perform the bulk of the processing and return immediately.
Another would be to create some kind of request (e.g. Create an entry in a datastore of some kind) and return. Another process (e.g. A windows service, etc.) could then pick up the request and perform the processing.
Any WCF service can be made asynchronous -
One of the nice things about WCF is you can write a service synchronously. When you add a ServiceReference in the client, you have the option of generating asynchronous methods.
This will automatically make the service call asynchronous. The service will return when it's done, but the client will get two methods - BeginXXX and EndXXX, as well as XXXAsync + an XXXCompleted event, either of which allows for completely asynchronous operation.
I have a self hosted WCF 4.0 service with an HTTPS endpoint. I have method that writes some trace info after the message comes in. However, some messages are 400k in size, so there is a long wait conceivably between when WCF has it and my console app has it. How can I get a hook or interception layer in there so I can at least know when a message is first coming in?
I think there is a WCF Performance Counter related to this, so there must be some way to know...
Thanks for all ideas!
This is not the same as Detect WCF client open channel operation , this is about knowing when the HTTP traffic first comes in. Maybe its not that I need to monitor things on my WCF service, maybe I need to monitor some other WCF layer that is intercepting HTTP. Can anyone say?
What about making a custom MessageEncoder that simply wraps the default implementation, but overrides ReadMessage() and logs some information before calling the wrapped implementation (which creates a Message instance)? At this stage the full message isn't even fully streamed over the wire, hence it's a very early point of the processing pipeline. Obviously, however, you don't know anything about the message yet. But if you want to get a timestamp, that might be a convenient place to get it.
One option is implement the IDispatchMessageInspector interface for your service with your message size checking code in the AfterReceiveRequest method override. Your code should look something like the code in this blog post.
I have a service that uses callback operations to call back its client. Is there a away to notify the client when Service goes down? An exception is raised when client goes down during callback, but with service goes down the subscription is lost but client is not notified.
Does WCF support some heartbeat operation to check the state of the service?
Thanks
No, there's no such thing as a "check if this service call will succeed" method.
You need to call the service and be prepared to handle any exceptions that occur during the service call.
There's really no reliable or useful way to check for service availability. All that a heartbeat could check for is that you can call your service method right now - but a fraction of a second later, that connection might be gone (cable has been unplugged or severed, server has crashed - the possibilities of things going wrong are endless......), too. It cannot check if all the necessary background services and databases etc. are available.
So in reality, such a heartbeat check is quite pointless. Just call the service, hope for the best, and be prepared for the worst! Wrap your service calls in good exception handling, and get on with it.