I was going through this article http://weblogs.asp.net/spano/archive/2007/10/02/choosing-the-right-wcf-binding.aspx to choose Binding options.
where i got an unusual doubt of what is mean by
offline or disconnected interaction, choose the NetMsmqBinding
Does that mean the even if service is not running still client using the service ?
Can you share some real time example ?
The 2 bindings are radically different.
NetTcpBinding can be thought of as an MS proprietary format (usually binary) similar in concept to RPC (e.g. can be used to replace .NET Remoting). It is synchronous, i.e. both client and server must be online at the same time, and the client receives a response (almost) immediately.
MSMQ is a Message Oriented Middleware solution by Microsoft, which revolves around asynchronous queues - e.g. if the destination server is offline when the client sends a message, the message will be queued on the client until the server comes back online. Each queue is one way only, although bidirectional communication can be achieved via a second queue back from server to client. Sending WCF MSMQ messages requires that the MSMQ Service be installed on the client. Messages on the queue can have a delivery 'timeout' else will be placed on an applicable dead letter queue.
Real world examples:
I would use NetTcpBinding with binary serialization for high performance, synchronous communication needs between a Microsoft WCF client and server, e.g. uploading files, media etc where Xml would not be useful (otherwise, I would use wsHttpBinding for synchronous Xml / SOAP messaging)
I would use MSMQBinding with DTC enabled to ensure reliable messaging between 2 or more systems (e.g. financial), with at least one of the endpoints being in .Net, and a 'compatable' server (not necessarily WCF, e.g. BizTalk, or other EAI hubs or ESB buses which have adapters for MSMQ, e.g. Bridges exist between MSMQ and MQSeries). Messages would typically be in an Xml format.
TL;DR
Does that mean the even if service is not running still client using the service
Yes. If MSMQ is running locally, the client will get an immediate return successful response (indicating that the message has been queued). This does not however mean that the message has been successfully received by the server.
Related
I use WCF to execute some code on a server (takes a long time). The request to execute that code is send from several client machines within the local network (TCP).
Since the code takes a while to execute and there are a bunch of clients, I need to somehow queue the requests.
I thought about using MSMQ as queueing mechanism. As far as I understood, MSMQ has to be installed on the client machines as well, not just the server.
Is it possible to not have to install MSMQ on all clients? Are there any alternatives to MSMQ, or simpler ways to have a queue in between the clients and the WCF-service?
Is it possible to not have to install MSMQ on all clients?
No. You must have msmq installed on all machines which want to participate in the sending and receiving of messages.
Are there any alternatives to MSMQ
Yes, many.
or simpler ways to have a queue in between the clients and the
WCF-service?
WCF uses msmq for queued transport on-premise. However, it is possible to use WCF with Azure Service Bus if you want to run in Azure. Link
I came across a situation in my work environment. where i have wcf service which receives messages from client and store in db. Now my problem is suppose server was down for 10 mins these 10 mins messages should be stored in client at some place and client should check for availability of server for every 1 min.Is there any procedure that i could follow or any help would be appreciated .Thank you
binding :netTCPBinding
MSMQ does exactly what your first sentence says - when you send an MSMQ message, if it can't get the remote queue then it stays with the client and the built-in MSMQ service retries in the background. That way your message, once sent, is "safe." It's going to reach its destination if at all possible. (If you have a massive message volume and messages need to be stored for a long time then storage capacity can be an issue, but that's very, very unlikely.)
Configure WCF to send/receive MSMQ messages
I'd only do this if it's necessary. It involves modifying both the service and the client, and the documentation isn't too friendly.
Here's the documentation for MsmqBinding. Steps 3 and 4 for configuring the WCF service are blank. That's not helpful! When I selected the .NET 4.0 documentation those details are filled in.
I looked at several tutorials, and if I was going to look at this I'd start with this one. I find that a lot of tutorials muddy concepts by explaining too many things at once and including unnecessary information about other parts of the writers' projects.
The client queues its messages locally
If you don't to make lots of modifications to your service to support MsmqBinding. You could just implement the queuing locally. If the WCF service is down, the client puts the message in a local MSMQ queue and then at intervals reads the messages back from that queue and tries sending to the WCF service again. (If the WCF service is still down, put the message back in the queue.)
I'd just send messages straight to the queue and have another process dequeue and send to WCF. That way the client itself just "fires and forgets" if that's okay.
That way you don't have to deal with the hassle of modifying your service, but you still get the benefit. If your message can't go to the WCF service then it goes someplace "safe" where it can even survive the client app terminating or the computer restarting.
Sending and receiving messages in a local queue is much easier to configure. Your client can check to see if the queues exist and create them if needed. This is much easier to work with and the code samples are much more complete and on-point.
I have messages that I want to send from multiple WPF client applications to a service that can be processed some time after being sent.
Because of expected intermittent connectivity issues between client and server and necessary down time for the service, I'm inclined to create a WCF service with a queued endpoint. This has worked well for me in the past when the client machines were actually other servers and few in number.
I'm concerned about doing this with many client machines primarily because I think it will be difficult to monitor so many outgoing queues to confirm that no traffic is being trapped on the client machines.
Has anyone tried doing this before?
If so, would you recommend it? Why or why not?
Even if you haven't done it, can you think of other pitfalls beside the operational issue of monitoring all those outbound queues?
Your question may be better worded as:
Should a system be rolled out with many nodes all using MSMQ?
If so this is the essence of messaging and is what such systems are designed for irrespective of whether they are JMS, Apache MQ, Websphere, SonicMQ, or MSMQ.
Also, "traffic is being trapped on the client machines" - how do you define trapped? Remember, the application may be quite happy for the message to be sitting locally for days before being forwarded to the remote host. Messaging systems have timeouts generally for both reaching the destination and for the destination to process it.
I think you will be fine.
HTTP transfer has been available since MSMQ 3.0, however I'm afraid MassTransit doesn't offer the feature to use HTTP protocol as transport protocol between queues.
There's a very similar question about this here, which has not been completely answered.
Does anyone know if it's possible for a client to subscribe to a bus and send/receive messages through HTTP? Here's the architecture I'm willing to implement:
I'll have 2 computers in the local network
Computer A runs a server application and MassTransit.RuntimeServices
Computer B runs a client application which sends messages to A
I want the communication between them to be done via http.
I tried to change the address in UseSubscriptionService to http instead of msmq, but it doesn't work. If I set computer's A MSMQ service to Hardened Mode, the client application running on computer B get's a timeout while trying to subscribe to mt_subscriptions.
Bus.Initialize(sbc =>
{
sbc.UseMsmq();
sbc.VerifyMsmqConfiguration();
sbc.UseMulticastSubscriptionClient();
sbc.ReceiveFrom("msmq://localhost/test_queue_client");
sbc.UseSubscriptionService("msmq://m3-dev1/mt_subscriptions"); // maybe I could use http instead of msmq, but it doesn't work
});
Any clues on that??
No, MassTransit does not support HTTP for MSMQ. You could, in theory, add your own transport that supports that. RabbitMQ is a way better transport than MSMQ in every way except if you need to enroll in distributed transactions. And RabbitMQ only requires a single port open between the boxes.
Our approach for distributed integration is to have a custom web service contract with proper security. This defines an input port. The input port actually publishes messages to mass transit buses.
On the other side, the same contract is used to deliver messages to subscribers.
By having a custom contract and http/https transport we are independent on actual message bus in the middle. And this pays of, we were using another bus for like 2 years and 2 years ago we migrated to mass transit based bus without ANY changes to clients (publishers/subscribers).
I'm about to write a "server" application that is responsible to talk with external hardware. The application shall handle requests from clients. The clients send a message to the server, and if the server is busy with doing stuff with the hardware the new messages shall be stored in a queue that will be processed later.
The client shall also be able to cancel a request (if it is in the server's queue.). When the server application is finished with the hardware it shall be able to send the result back to the client that requested the job.
The server and client applications may or may not be on the same PC. All development is done in .NET (C#) 2005.
What is the best way to solve this communication problem?
MSMQ? SOAP? WCF? Remoting? Other?
Assuming you can use .NET 3.0 or greater then you probably want to WCF as the communications channel - the interface is consistent but it will allow you to use an appropriate transport mechanism depending on where the client and server are in relation to each other - so you can choose to use SOAP or MSMQ or a binary format or others as appropriate (and can roll your own if needed). It also covers the need for two way communication.
Queuing the messages at the server should probably be regarded as a separate problem - especially given the need to remove queued messages.
If clients and server processes are on the same machine, I think named pipes will give you the fastest raw byte transfer rate.
If the processes are across different machines, you'd need to use sockets-based approach.
Remoting is reportedly very slow. Based on the target OSes that you're planning to deploy the solution on, you could have options like WCF et al. However, the overhead of these protocols is something you may want to look at while deciding.
Remoting
If all development is done in .NET 2005, Remoting is the best way to go.
MSMQ would make some sense, though there are then security and deployment considerations. You could look at a service bus (such s NServiceBus or MassTransit) and there's also SQL Server Service Broker that could help (and can also be used by a service bus as the transport).
WCF would be another thing to look at, however that's really the across-network transport, so you'd probably still want the WCF calls to put a message on the server queue.
I don't recommend remoting, because it's hard to maintain a separation of concerns, and before you know it you're developing a really chatty interface without realising it. Remote calls are expensive in relative terms, so you should be trying to keep the messages fairly coarse-grained. WCF would be my recommendation. Not least because you can set it up to use a HTTP transport and avoid a lot of deployment and security headache.
The .NET Framework provides several ways to communicate with objects in different application domains, each designed with a particular level of expertise and flexibility in mind. For example, the growth of the Internet has made XML Web services an attractive method of communication, because XML Web services are built on the common infrastructure of the HTTP protocol and SOAP formatting, which uses XML. These are public standards, and can be used immediately with current Web infrastructures without worrying about additional proxy or firewall issues.
Not all applications should be built using some form of XML Web service, however, if only because of the performance issues related to using SOAP serialization over an HTTP connection.
Choosing Communication Options in .NET helps you decide which form of interobject communication you want for your application.