Please any one clarify me WS Addressing in WCF does support the multiple ReplyTo or not?.
This would answer your question in depth # Microsoft
...
Multiple Endpoints and Unique Addresses
There are a few reasons why you might wish to expose multiple endpoints on a particular service. One reason is to expose the same contract using a few different bindings. For example, you may have some consumers that can only deal with WS-I Basic Profile 1.1-compliant services (one binding) and others that can handle the full suite of standards (another binding). Or you may have some internal enterprise consumers that demand binary TCP transmissions for performance reasons (yet another binding). The ability to expose the same contract using different bindings allows you to accommodate all of these consumers at the same time.
When exposing multiple endpoints with different bindings, each endpoint address must be unique. This is because each endpoint requires a different transport listener and channel stack. Consider the service configuration in Figure 4. In this example, all of the endpoints expose the same contract (ISimpleMath) but each one uses a different binding, so each address must be unique. If you modify an endpoint to use the same address as one of the other endpoints, Windows Communication Foundation will throw an exception while opening the ServiceHost.
...
I assume WCF is standards compliant. In this case at most one replyTo address can be given. See Section 3.1 of the WS-Addressing Core Specification for details.
Related
I am using On-Premise Service Bus 1.1 for communication between processes.
I need to perform request-response methods between end points and need to decide if I will use WCF or the bus (Service Bus Relay for WCF is not currently available for on premise).
WCF would be easiest to talk to via a generated client proxy, potential complexity with IIS host (or self host) and versioning of clients calling the service.
For Service Bus create two queues per remote service (i.e.
userService, userServiceResponse) and then use sessions. Flexible versioning with different commands. Management of these queues could become complex.
For my project everything is within the same subnet and if required WCF endpoints could talk directly to one another
To help me decide which technology to use, my questions are:
Where would WCF be used over request-response service bus?
Are there any libraries for Service Bus queues to implement
request-response messaging (or any robust code examples)?
If we have multiple publishers on a queue, how would we return a reply to a specific sender? Would we have multiple serviceReponse queues, or can a single return queue be used?
Service Bus messages can have a SessionID unique for that request where the service will receive the message, do something with it and reply with a message that has the same ID in the ReplyToSessionID. This allows the requesting party to receive based on the Session ID like this
MessageSession sessionReceiver = _queueClient.AcceptMessageSession(_mySessionID,TimeSpan.FromSeconds(5));
sessionReceiver.Peek();
I think the big question here is Sync vs Async whether you want the requesting party to sit back and wait for a response (WCF) or back later and check if the response is ready yet Service Bus but that is a business decision.
This link or this MSDN article might help you get started with Req/Rep for SB.
I don't think that deciding which technology should be used is a business decision. At first, it's a technical one.
I would not go with a product which is very operating system dependent, and worst, it's so premature. We can be creating coupling (OS x Bus) and stepping over a mined field.
But, this is only a personal opinion and might be biased as I'm not a Azure SB specialist.
I agree with #Tom, your decision is more related to sync/async model.
Some questions I usually answer before deciding on this subject:
Can we preview the rate of requests/minute and the amount of clients?
What is the nature of the service? Heavy processing logic or simple queries against a database?
I can list some others if you wish, but those two can easily help on the decision, forcing you to think broadly.
I got one interview question in WCF
What is the use of Having multiple contracts for different consumers for a web sevice?
Could any one know the answer for the above questions? Reg WCF question, i explained about DataContract, Service Contract, Message Contract.
Depends what they mean by different contracts.
If they mean different interfaces, then it could be a security benefit, restricting what you expose to each client.
If it is different endpoint configurations, you could use an efficient binary protocol for clients on the local net, and a compatible basic http binding for external clients. You could also have different authentication methods for each endpoint.
I am playing with WCF Routing. It works fine from the start ... but there is an issue I couldn't pass. In my playground I have routing service and 4 other WCF services implementing 2 different contracts. As I said it works fine ... but when accessing both contracts from client side, from single thread, I have to make 2 different connections. To access contracts ChannelFactory<> is used. I tried to get through WCF channel stack to get idea how to implement own binding/channel but failed to achieve the goal of single connection.
There is an option to generate interface as a sum of both interfaces, but this solution is supposed to work in the environment of many (30-40) independent contracts. What complicates and prevents me from applying this simple solution is the fact, that according to the "loose coupling" rule all those 30-40 independent contracts live independently.
Is there a way to construct channel stack in the way that allows us to route many contracts through single WCF Routing service and use single connection (connection pool/connection pool per thread) for accessing them from the client side. ?
Kind regards
Leszek
There is no "toolkit" way of doing this but you could combine the two contract on the client making sure that the actions are preserved and then route by action in the routing service to the correct downstream service
we had developed a webservice in vb.net,framework 2.0. We would need to rewrite this
websevice in WCF with framework 3.5. Please provide some guidance regarding this and also
there are many othersystems consuming our webservice url. Will this conversion have impact on the source system or does it involve any build activity for the source system to consume the url that will be developed with WCF method?
Please provide sample example to have better understanding on this. Thanks!
A few thoughts.
Case 1: Your webservice is having consumers and you want to rewrite only the service and not disturb the consumers.
In this case using a basicHttpBinding end point with regular wcf service implementation would do. You can find many references to build WCF service with basicHttpBinding. Most probably this would fit your need.
Follwoing links may be helpful to you.
http://msdn.microsoft.com/en-us/library/aa480190.aspx
http://msdn.microsoft.com/en-us/library/ms731361(v=VS.90).aspx
Case 2: If You want to rewrite the service, and it is acceptable to have changes in the consumers, then it is worthy to consider the following points.
Endpoint Choice
a. If your preference is to keep your service interoperable (i.e. you would like the service to serve different platforms), Soap based endpoints would help. basicHTTPBinding, wsHTTPBinding, etc.
b. If your consumers are in the windows platform, and you prefer better performance than SOAP based bindings, netTCPBinding based endpoints would help.
c. If your consumers are in the same machine, netNamedPipe can would be a choice.
Service Design
The service design offers you to go with a lot of combination of the following.
a. Choice of deciding the service instance's life cycle.
b. Choice of Concurrency.
c. Choice of Sessions, and enforcing the order in which the service has to be called (prefered by specific designers)
d. Choice of having or not having the transactions.
You shouldn't need to change anything. It should work the same.
Have you tried migrating it yet? If so, what were the problems? If not, just switch it to 3.5 and see what happens.
The Only need is to change the service endpoints in WCF service making as
http://localhost/YourProjectName/Servicename.svc ,
Without changing the Server Side coding , You
need to expose the Remote Interfaces making them as [Service Contract] and the Methods as [Data Contract] on the client Side
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