This question is related to this one.
Given that WCF binding uses net.msmq:// URL, for instance net.msmq://server/private/nc_queue, how can one know what is the actual MSMQ address to which this URL is translated? Is there some kind of a trace that can be activated? Or an external tool that would help one capture the address?
Thanks.
EDIT1
OK, I owe a clarification. One can talk directly to MSMQ through the respective .NET API. In the case of MSMQ over its native port 1801, I would use this MSMQ address:
FormatName:Direct=OS:server\private$\nc_queue
When MSMQ is configured over HTTP, the address changes to something like this:
FormatName:Direct=http://server/msmq/nc_queue
But the WCF binding uses a standard URL to describe the address, like:
net.msmq://server/private/nc_queue
So, how can I know what is the actual MSMQ address (the one with the FormatName) to which the net.msmq:// is translated?
I don't really understand your question.... if you use the WCF netMsmqBinding, you're basically dropping off MSMQ messages into an MSMQ queue. So what you really have is a queue name that you're dealing with - not a URL.....
net.msmq://server/private/nc_queue
This translates into a MSMQ private queue called nc_queue on server - so what is it really that you're trying to do?? I'm not getting it..... care to clarify??
In the meantime, check out Tom Hollander's three-part blog post series on MSMQ, WCF and IIS:
MSMQ, WCF and IIS: Getting them to play nice (part 1 of 3)
MSMQ, WCF and IIS: Getting them to play nice (part 2 of 3)
MSMQ, WCF and IIS: Getting them to play nice (part 3 of 3)
Update: I think I'm beginning to understand your issues - if you're using the WCF netMsmqBinding, you're connecting to MSMQ directly - this is not "MSMQ-over-HTTP". If you want to set up and use MSMQ-over-HTTP from a WCF client, from what I understand, you'd be talking to a straight regular HTTP service, so you'd have to use basicHttpBinding (or wsHttpBinding) - not the specific netMsmqBinding.
Related
WCF has the following binding options:
http(s)
net.tcp
MSMQ
Couple of questions:
AFAIK, http(s) is actually a higher level protocol on top of TCP protocol, and net.tcp is in fact TCP protocol. So why do we have them both? Why not just have a single TCP protocol?
Could MSMQ be used across machine boundary?
If I want to have other binding options, what should I do?
Thanks.
The netTcpBinding is indeed a "lower level" protocol, and as such, it's also a tad faster than http. It works great in intranet/local network environment - inside your company.
But the netTcpBinding doesn't cross firewalls and routers very easily - you would have to start opening ports and that's something that has lots of security implications and thus is often hard to get done, especially in larger companies.
The http bindings of WCF works over port 80 - which is open on just about any firewall - so these bindings offer you more reach - your clients and folks from outside the company can talk to a service like this a lot more easily than to one that uses netTcpBinding.
The beauty of WCF is this: you can have a single service, but you can expose two endpoints - one using netTcpBinding (fast, binary encoding) for local clients - and a second 'basicHttpBinding` endpoint for clients calling from outside your LAN. There's nothing in the service implementation code that needs to know about this, nor do you have to program differently whether you're using nettcp or http. WCF handles all this for you.
MSMQ is a totally different beast - while netTcp and http bindings work in a "connected" fashion - you call the service and wait for an answer - the MSMQ binding is a queue-based system. In this case, you drop a request into a queue - and you're done right away. Some time later, the queue will be processed by some kind of a worker process or program, and something will be done. And you might be notified in some way (e-mail, response message on another queue or something) - but the a) calling the service, b) processing the message and c) getting a response are totally decoupled and can happen within seconds - or it could take days. And YES! of course MSMQ works over machine boundaries!
I am writing an application that has one Windows Service that needs to communicate with another Windows Service. The "target" service will accept a request from the "source" service and will perform a task. The "source" service will not wait for a response, so the request should return as soon as possible.
The plan was to have the "target" service host a WCF service which the "source" will communicate with. Once the request is received I need to communicate with the host Windows Service to tell it to do the work. I was thinking that the "target" WCF service would put a message on a MSMQ which the "target" Windows service will monitor. Once this is done the WCF service can return back to the caller.
Does this sound like a sensible approach for allowing a WCF service to tell a hosting Windows Service to perform a task?
Kind Regards
Michael
Allow me to disagree. Based simply on what you've described, using MSMQ to communicate between the "target" WCF service and the hosting Windows service seems extremely heavyweight to me. MSMQ allows different processes to communicate in a failsafe manner. In your case, the WCF service is hosted in the same process as the Windows service. Thus, while MSMQ as a commmunication mechanism between the two would work, it's not necessary.
Additionally, using the MSMQ binding between the "target" WCF service and the "source" WCF service makes sense if the two WCF services are not always running at the same time. For example, if the "target" WCF service is not always running, the MSMQ binding would allow the "source" WCF service to still send tasks. These tasks would be stored in the MSMQ to be retrieved when the "target" WCF service begins running. However, it sounds like both services will be running, so I can't see the need for the MSMQ binding.
For selecting WCF bindings, refer to this SO post.
C# - WCF - inter-process communication
Let me address one other thing. When your "target" WCF service receives a task request from the "source," simply communicating the task back to the Windows service is not going to do anything in and of itself. The Windows service is running, yes, but it does not have a thread of execution that you can leverage. The point is that in order to make task processing asynchronous, you'll need to start a thread to manage the task(s). I would suggest leveraging the ThreadPool to do this.
Hope this helps.
Yeah, that is a good approach. MSMQ is perfect for this task - the source service can send a request to the target by putting a message on the queue via WCF. MSMQ is good anytime you want to send a request to a service for asynchronous processing, especially if you don't need to get a response back. If you do need a response, you can setup the source as a WCF service as well, and the target can send a message back if needed. There are several different ways to accomplish this with the MSMQ binding.
#Matt
Thanks for your help.
After thinking about it a bit more and see how your approach would make things easier to setup and use. I need to have the "target" service send the outcome of the work back to the "source", so I will probably use nettcp and use a callback. The plan then is to setup a new thread, do the work and once its finished send a response back to the "source".
#Andy
Thanks for you help.
I took a look at msmq, but seeing as I would probably have to setup a new thread once I receive the message I might as well let the web service do the work.
In my application I need to push notifications of real time events from server to clients. The amount of data to pass is very small, mostly and Id. The number of clients listening simultaneously can be around 100 and I may have to publish one notification every 2 - 3 seconds. Both the server and client are built using .Net and WCF.
Given these requirements I have built a set of WCF services which will be run on a load balanced server cluster. The Instance context mode is Per Call and there is no need for sessions etc.
I am currently using BasicHttpBinding. Will TCP binding be better? Does it run on IIS 5 or 6? If not why?
What configuration for serialization can work best?
What are the things I need to do to make sure I get maximum performance?
Edit - Adding more information based on some of the responses -
I host a small WCF service in the client process using manual hosting. The server just calls this service on each client to push the data to all of them.
Firstly have you considered using messaging for what you are trying to achieve?
In answer to will TCP binding work better than BasicHttpBinding- almost certainly yes. If you want to use TCP, you can't use IIS- look into WAS with Windows Server 2008. If you're stuck with Windows Server 2003, then you'll have to host in a windows service instead.
You've made a good choice by choosing per call- this is the preferred instance management mode for creating scalable WCF services.
Edit:
Now you've update your question, I recommend you take a look at IDesign's Pub/Sub framework if you want to stick with WCF. I'd also look at Pub/Sub with MSMQ in WCF and also with "Vanilla" products such as Tibco RV.
If you need pushing data from service to clients you need sessions and you need duplex binding - NetTcpBinding or WSDualHttpBinding. It will not work with BasicHttpBinding because it allows only pulling data (client pools the service for changes). Push data means tha service sends data to clients when needed.
NetTcpBinding always crete session. It can't be hosted in IIS 6 or older. NetTcpBinding is allowed only in Windows Activation Service (WAS) which is extension of IIS 7.x. For older systems you need self hosting = windows service.
Edit:
Based on your description you need Publish-Subscribe message exchange pattern.
I have a WCF service with netMsmqBinding. My client can send messages to my queue, and when the service is running it retrieves messages from the queue as expected. If the service is not running, messages received are queued until the service starts.
My problem is that the service does not start when a message hits the queue. The service is hosted in IIS, and so it is not instantiated until IIS receives a request. If I browse to the service then it processes the messages in the queue, but obviously this is not my desired method of processing the queue!
I expect that I need to change the service implementation, or change the IIS setup, but I do not know where or what to change.
UPDATE
Does anyone actually use MSMQ over WCF? I had this working for a short time - I enabled the binding on a different website on the same server, bizarrely - but now it has somehow stopped working again.
The only problem I am having is with the Activation of the service when there is a message in the queue. At present the queue only processes when the service is instantiated, e.g. when I browse the the .svc file. I have the net.msmq protocol enabled on the application, and I have the net.msmq binding enabled on the site... is there anything else I need to do?
You explicitly need to configure IIS for non HTTP activation. I don't know all the details of the top of my head but basically you need to use appcmd to configure and enable the net.msmq binding activation.
Check this blogpost or this screencast should give you all the details.
This might save somebody the hours it took me:
http://msdn.microsoft.com/en-us/library/ms731053.aspx
I believe that my problems using MSMQ binding over WCF were mainly around IIS.
I had no end of problems using Windows XP / Server 2003 with IIS 6.
Using Windows 7 or Server 2008 with IIS 7.5 everything works well.
An even better suggestion is to run MSMQ as a managed service / Windows Service or a stand-alone application rather than under IIS.
I have develop a silverlight chat application. my question is (a) can netmsmqbinding support unlimited connections of wcf service. because first im use pollingduplex binding but it support only 10 connection on iis6 also on server edition.im allready set service throttling options but not effect on server iis. so that now i want to go for netmsmqbinding. please explain me msmqbinding limitations.can its better for chat application or not?
help me for take decision.
Thanks
As far as I know (but I don't know Silverlight all that well), it supports only the basicHttpBinding.
And even if Silverlight did support MSMQ - this is definitely not a good protocol to use when you're creating a chat application. The queue can buffer messages and deliver them later. That works well in many scenarios, but when I chat with someone, I want my message to show up right away - not "some time later".....
So if you really need to use MSMQ in some way, I think you'd have to have a BasicHttp-based front-end service that goes from your Silverlight client to the server, and then on the server actually route your message forward to a MSMQ queue.
Marc