1) MSMQ
2) Public Queues
3) Queue Management, Initial MQ installation and setup
4) Both, but mostly binary because XML is too verbose for our MSMQ messages
5) Interesting

We're looking at wrapping a Web Service around MSMQ for our next version. Today all inter-service communication is done via MSMQ, but to provide remote client access to our services, we're looking at providing a Web Service endpoint that queues up messages for the services.

1) MSMQ
2) Private Queues
3) Queue Management & Creating new queues dynamically
4) Both (Kind of...)
5) Interesting (might be Great, depends on how "manage" is defined)

We're using a mix of VB6 and VB.Net with our queues (VB6 posting, VB.Net consuming).

Everything is supposed to be in place to use Public Q's, but since our current prod apps were built for, tested with and run on Private Q's we're going to wait until the next major rev of our suite before we move to them.

One of the things I really would like is a service to help manage the queue's (both at a queue level and a queue content level)... Queue counts, queue message content (for non-binary queue messages), queue config, etc, etc

There must be a better way than the Computer Management MMC snap-in?

A web service to mange this would be great...

(1) MSMQ and Hand-rolled : seperate apps
(2) Private Queues
(3) A & C (B is a problem but these problems are related to overall queue management in certain situations)
(4) Primarily XML
(5) Great!

I blogged a case for rolling my own implementation here: http://dotnetjunkies.com/WebLog/sdhebert/archive/2004/06/11/16267.aspx

When building a "shrink-wrapped" application, creating a managable queing functionality using MSMQ is what I would term effectively impossible. First, consider the case when all points must be capable of communicating with one another. The number of queues needed is an n^2 equation (there are ways to simplify, but you see the nature of the problem in that equation). When you consider that you do not have control over the domain/activedir services in a shrink-wrap situation, the problem becomes far more daunting. Rolling my own with webservices was the only approach.

I'd love to see a discovery service of these types of queues and monitoring services as well.

1) The Message Queuing app I use is:
A. MSMQ
B. MQSeries -- Only if I have to exchange data with an IBM mainframe

2) I use the following features of my queuing solution:

A. Public Queues - can't use because these machines are not part of an AD

B. Private Queues

3) I have been frustrated in the past with any of the following:

A. Queue Management -- yes...crappy tools to manage queues

B. Creating new queues dynamically -- a pain if your are using private queues on diff. machines


4) I routinely use the following serialization formatters:

A. Binary

5) The idea of a WebService that I could use from within my application to easily create, manage and implement message queuing from a .NET application i find:

B. Interesting
__________

Kirk,

In response to #4 you say:

"Both, but mostly binary because XML is too verbose for our MSMQ messages"

Have you considered formatting the message you post to your queue as a sort of instruction or a pointer to the actual content you would otherwise post? This way you can post the messages to the queue and generally not be concerned with the size since you would be posting a batch of instructions for some other application to process.

Just a thought.

The only problem with this is if you have multiple clients accessing the same queue. They'd need the full message, right?

1) The Message Queuing app I use is:
A. MSMQ
D. Other commercial product: Oracle Advanced Queuing.

2) I use the following features of my queuing solution:
A. Public Queues
B. Private Queues
C. Transactions

3) I have been frustrated in the past with any of the following:
A. Queue Management

4) I routinely use the following serialization formatters:
C. Both

5) The idea of a WebService that I could use from within my application to easily create, manage and implement message queuing from a .NET application i find:
B. Interesting

WSMQ Project started

A little late to the party, but:
1: MSMQ
2: Private Queues almost exclusively. Have used the others when needed.
3: I used to be frustrated by those, but have built up a library of BASIC code (VBScript, VB 6, and VB.NET) for automating them.
4: All of the above. Learning to do your own formatters in .NET is very important.
5: Why a web service?

John,

I was interested in creating a service-based queue as an alternative to MSMQ.. I was interested in a Web Service because I wanted communication over open standards transports.

You may be interested in a project here I've set up. There's already a working prototype of this:

http://workspaces.gotdotnet.com/wsmq