I have a little problem and don't know where to start.
I need to make a subscribtion service and if returns unique address on which consumer will send soaps after subscription. It works like so : you send a SOAP on address http://foo.org/Subscribe and in response you get address http://foo.org/SubscriptionManager/1, the next consumer will get http://foo.org/SubscriptionManager/2 etc.
How can i emplement that via WCF? I guesed that WCF have something like ASP.Net Routing, where i could route links like http://foo.org/SubscriptionManager/ and access 2 as a parameter, but i haven't found something like that.
I look forward to any help.
The question I have is why do you want to route users to different endpoints?
The whole idea of returning a service URI for the consumer to call is not good design in my opinion.
You are forcing your consumers to do more work - they must make an extra call and interrogate the response just to find out which endpoint they have to call.
If your requirement is to spread load between two services you should offer a single load-balanced endpoint which will then send requests to the other endpoints.
Alternatively, if your requirement is to route certain users to one or other of the subscription services based on some rules then you can have a look at WCF-Routing.
Related
I have this service that posts JSON messagest to a given url, the requests cannot be modified and because of that I cannot add all the headers I need to post to a queue in Azure.
I have been researching on this but seems like the only way to make a post other from the authorization headers is allowing a range of IPs to post to the Q; something that I cannot do either because the sender can change IPs and I could loose data, not good.
What I'm trying to find out is if Microsoft has a way (or some different service from queues) that I can use to prevent data loss in case my app is down (this is where the queue comes in), or if there's some way I can allow this external provider to post to my queue without all the security or with a minimum of it.
Thanks in advance.
I work on a system where we have the same website across multiple countries. Each of these websites has it's own services. Everything works well, but I've always found myself having to send messages rather than publishing as the messages otherwise other services where I know before hand it's completely irrelevant. It sounds pointless to me publishing to many services and then filtering it's relevance.
Is there a practice I should be dealing with when wanting to publish messages to a certain subset of services, how have others dealt with this problem?
By default endpoints subscribe to all messages. If you want only certain endpoints to subscribe to specific sets, then you need to configure your endpoint to DoNotAutoSubscribe(). You then must explicitly subscribe to each message type the endpoint will be interested in using Bus.Subscribe().
Could you describe your logic of determining relevance for particular endpoint systems ? the purpose of publishing and subscribing is that there are events in a system that other endpoints can subscribe to.
you should not know something about your subscribers. so how do you determine relevance ?
if these messages are not relevant for a specific endpoint why do you want to subscribe to these messages ?
If it truly is an event message then you need to publish the message. If you need to publish to a subset you could have a separate subscription store that the endpoint in question would use.
Typically it should be up to the subscriber to determine whether the received event is relevant but if you do have the information up-front then could go with the separate subscription store.
In my FOSS ESB project (http://shuttle.codeplex.com/) a ISubscriptionManager implementation has to be provided to the ESB to determine the subscriber uris to send published messages to. Although it may be overkill one could provide a custom implementation that contains some logic to perform the filtering; otherwise the separate subscription store.
Is that possible (using behavior and IClientMessageInspector.BeforeSendRequest) to change the comunication channel before send a message ?
I need to change this, because i have a backup/primary strategy for my proxy.
Based on your comment, it sounds like you want to be able to switch service endpoints in mid-call if the primary service is offline. I don't think there's any way to do that - at least not elegantly.
Once a communication channel is established, it's pretty much set until it is closed (or aborted). There's no way to switch it from one endpoint to a different (backup) endpoint - you couldn't even do it by creating a new channel because the proxy would still be using the primary endpoint.
Based on my understanding of WCF, about the closest you could come would be for the client to detect that the primary service was not responding (most likely through a timeout), and then it could switch to a proxy configured for the secondary/backup service.
Now, you might be able to, within IClientMessageInspector.BeforeSendRequest do some checking to see if the service is responsive, and if it does not response try to generate a new proxy with the backup service endpoint and send the message there...BUT I don't know if that would work, and even if it did it strikes me as a bit of a kludge.
Simplest solution is that the client simply switches to the alternate service endpoint if the primary endpoint is down, IMO.
Old thread, but for future reference.
I think WCF Routing (.NET4) is what you are looking for, namespace "System.ServiceModel.Routing.RoutingService". Search for "High Availability" on this page, Practical Messaging Scenarios with WCF 4, for an example.
From 1: "The back up list indicates to the Routing Service that if the primary endpoint, OneWayService1 is not available (i.e., it fails to respond), the Routing Service should try each subsequent endpoint beginning with OneWayService2 and ending with OneWayService4 until a service responds."
The scenario is a follow:
I have multiple clients in which they can register themselves on a workflow server, using WCF requests, to receive some kind of notifications. The information of the notifications will be received from an external system using another receive activity. The workflow then should get the notification information and callback all registered clients using send activity and callback correlations (the clients are exposing callback interfaces implemented in there and the end-point addresses passed initially with the registration requests). "Log-running workflow service" approach is used with a persistent storage.
Now, I'm looking for some way to correlate the incoming information of the notifications received from the external system with the persisted workflow instances created previously when the registration requests, so that all clients will be notified using end-points that already passed with the registration requests. Is WF 4.0 capable of resuming and executing multiple workflow instances when the information of the notification received without storing end-points somehow manually and go though them? If yes, how can I do that?
Also, if my approach of doing so is not correct, then please advice me about the best practice of doing such system using WCF services.
Your help is highly appreciated.
When you use request correlation with workflow services the correlation key must always match a single workflow instance, you can't have multiple workflow instances react to a single message. So you either need to multicast the message using all the different correlation keys or resume you workflow instances in some other way. That other way could be to store the request somewhere, like a SQL table, and have the workflows periodically check that location if they need to notify the client.
I'm contemplating a project where I'll be required to make use of what is variously called the "asynchronous" mode, or the "duplex" mode, or the "callback" mode of SOAP webservice. In this mode, the caller of the service provides in the SOAP header a "reply-to" address, and the service, instead of returning the output of the call in the HTTP response, creates a separate HTTP connection to this "reply-to" address and posts the response message to it. This is normally achieved in WCF using a CompositeDuplexBinding, like so:
<binding name="async_http_text">
<compositeDuplex clientBaseAddress="http://192.168.10.123:1234/async" />
<oneWay />
<textMessageEncoding messageVersion="Soap12WSAddressing10" />
<httpTransport useDefaultWebProxy="false" />
</binding>
This results in not one, but two HTTP connections per call: one from the client to the service, and then one from the service back to the client. From the point of view of the service implementation, nothing changes, you have a method that implements the interface method, and you take in the request and return the response. Fantastic, this is what I need, almost.
In my situation, the request and response can be separated by anything from minutes to days. I need a way to decouple the request and the response, and "store" the state (message, response URI, whatever) until I have enough information to respond at a later time (or even never, under certain circumstances).
I'm not terribly excited about having my methods essentially "paused" for up to days at a time, along with the required silly timeout values (if they're even accepted as valid), but I don't know how to go about putting a system like this together.
In order to be completely clear, I'm implementing a set of standards provided by a standards body, so I do not have flexibility to change SOAP message semantics or alter protocol implementations. This sort of interaction is exactly what was intended when the ReplyTo header was implemented in WS-Addressing.
How would you do it? Perhaps Workflow Foundation enables this sort of thing?
In such case don't use HTTP duplex communication as defined in WCF. It will simply not work because it is dependent on some other prerequisities - session, service instance living on the server, etc. It all adds a lot of problems with timeouts.
What you need is bi-directional communication based on fact that service exposes one way service and client exposes one way service as well (services can be two-way to support some kind of delivery notification). You will pass client's address in the first request as well as some correlation Id to differ multiple requests passed from the same client. You will call client service when the request is completed. Yes, you will have to manage all the stuff by yourselves.
If you are in intranet environment and your clients will be Windows based you can even think about changing your transport protocol to MSMQ because it has built-in support for all these requirements.
Edit:
I checked your updated question and you would call your communication pattern as Soap Messaging. I have never did it with WCF but it should be possible. You need to expose service on both sides of the communication - you can build your service to exactly follow needed contracts. When your service receives call you can use OperationContext.Current.IncommingMessageHeaders to access WS-Addressing information. You can store this information and use them later if you need them. The problem is that these information will not contain what you need. You have to fill them first on the client. This is generally possible by using OperationContextScope and filling OperationContext.Current.OutgoingMessageHeaders. What I'm affraid is that WCF can be "to clever" and override your changes to outgoing WS-Addressing information. I will probably try it myself during weekend.
It turns out the Windows Workflow Foundation (v4) does indeed facilitate this sort of message exchange.
Because WF allows you to decouple the request and response, and do basically whatever you want in the middle, including persist the workflow, idle it, and go outside and cut the grass, you get this capability "for free". Information can be found at these URLs:
Durable Duplex (MSDN)
Workflow 4 Services and duplex communications