Simple Message Queue Protocol (SMQP) is a publish/subscribe specification that is currently being reviewed by the IETF since September of 2001. Several revisions of the protocol have also been submitted based on people's comments, and recommendations. This article is to further introduce readers/developers to the protocol and encourage additional input to the specification.
Post a Comment
How is this better or worst than XMLRPC or SOAP, or some other system such as that?
Yet another communications protocol?
I have a similar question for John:
How does SMQP compare to MUSCLE? ( http://www.lcscanada.com/muscle/ )
(We hosted a detailed article regarding MUSCLE a few months back btw: http://www.osnews.com/story.php?news_id=1523 )
How is this better or worst than XMLRPC or SOAP, or some other system such as that?
Yet another communications protocol?
After read this article and I have the same question as your.
TAGS and KEYWORDS aren't really enough; ideally you want to be able to send at least name/value pairs that can be handled in a topic-specific way. I suppose if the topic is Stocks then "IBM" or "MSFT" are fine keywords, but if the topic were computers/x86/desktop/ I might want to have "motherboard:asus" or "floppydrive:no".
I have SOAP for a long time. But the problem with SOAP, XMLRPC is that they are RPC type technologies. And RPC technologies have been problematic from day one! Examples, RPC, DCE-RPC, DCOM, CORBA, etc.
What has worked though are things like MSMQ, MQ Series and other messaging type technologies. Of course messaging technologies are harder to implement in business application terms. But they are more stable, robust, easier to administer, etc...
Interesting I was wondering when this type of technology will come along....
>And RPC technologies have been problematic from day one!
And those problems are ? (except for the bloat overhead of xml in Soap ) ?
SunRPC is imho very nice.
RPC, and especially SOAP is not exactly a real message queue. Yes, it is implemented to have features such as a message queue, and certain B2B systems can be set up with a BUNCH of code to manage guaranteed delivery, asynchronous and synchronous queues, etc, but I can't realistically connect to a SOAP service the way it currently is understood and BLOCK on reception of a message. And a little opinion from me, XML downright sucks like a bag of ass (I've been working with SGML since the latter 80s so don't tell me I don't know what I'm talking about).
In SOAP, how could I ``block on produce?''
JMS is fantastic because I can use it to talk and load balance and send messages using any vendor. Now on Unix, I have to HOPE that someone implemented SysV IPC and hope that the implementation is not broken (there are instances with SysV IPC where one (or an SA) must obtain root access to clear the queues: not good). MSMQ has it's oddities as well. Other than JMS, there is no CLEAR standard for accessing MQ handlers. Having it as an RFC, people can now wrap SysV IPC, MSMQ, IBM MQ Series, et all and I shouldn't care who implements the queue.
For those who don't work with MQ applications, they are fabulous. You can implement semaphores, critical section coding, load balancing, object pooling, batch & priority processing, anync and sync handling. The most successful piece of software I ever wrote used an MQ as the sole `kernel' as a message passer between business object producers and consumers: a very different way to look at an application, but more powerful than people realize.
--
3lixyqueue
YAIS (yet another internet standard). I have started to understand why people go to windows. One standard. A shitty one perhaps, but still. One standard from one company. Trying to keep up with all the standards is a pain in the ass.
Maybee I'm just kranky this morning....
Developing systems based on MOM takes a different mindset than using RPC. Many of the features you expect from an enterprise system such as guaranteed once delivery, 100% uptime, and high scalability are "free" using a product like MQSeries. However, until JMS came along, there wasn't a high-quality yet inexpensive implementation for most developers to run against.
However, most of the affordable JMS implementations can't hold a candle to MQ (Orion comes to mind). Here's hoping that SMQP spurs some innovation in the inexpensive, commercial sector.
A message passing protocl, with a lack of flexibility in some spots where it would be nice to be flexible, and a lack of rigidity where it'd be nice to know what to expect.<p>
This looks like a bad reimplementation of XMLRPC/SOAP/et al. Like everyone else, I just can't see how this brings any benefits, since it doesn't seem to actually define any queueing behavior that would add onto existing message passing human readable protocols.<p>
If the author wanted to do something useful they'd write an MQ architecture for *nix that was open source and freely available and that was message passing protocol independent.
Greetings:
Thank you for the comments so far.
SQMP is a message queue protocol that allows not only point-to-point transmission of messages, but topic and content based. It is to be more than a simple IM protocol. SMQP has greater authentication, guaranteed delivery (transactional), multi-part encryption and compression.
SMQP is a MQ protocol much like proprietary MSMQ and MQSeries (WebSphere MQ), but open. It has many of the same features found in MSMQ and MQSeries.
JMS is a java interface specification for messaging services, not an implementation. JMS could be implemented using SMQP.
SMQP is a non-blocking protocol; send and continue much like email. RPC systems are a call and block until remote procedure is complete. SMQP would be a request, async notification (though you can sometimes fake an async RPC request).
As someone mentioned earlier, SOAP is not a MQ. SOAP/.Net is still struggeling with how to manage a real MQ system for web services that is not just a point-to-point request (SMTP). Additionally, SMQP is one protocol, not a combination of syntax like HTTP, XML, WSDL, and UDDI.
Thank you for noticing that. It has been coing back and forth to have just named tags or a meta desciption of n/v pairs. However, the largest con against meta fields is that the other nodes would need to know the context of the named fields. For example,
SYMBOL=IBM
Then subscribers would have to know these names exists. The TAG approach allows it to be more free form much like a query at a search engine or an HTML meta header definition. The specification allows for begin, contain, end, and approximate string matching.
As the protocol get more widely used, meta fields can be looked at again as long as the context of the names could be universally understood.
I have started to understand why people go to windows. One standard. A shitty one perhaps, but still. One standard from one company.
The official standard
http://www.iana.org/assignments/port-numbers
Thank God, we're using one standard from many companies and universities instead of MS standards.
Greetings.
I guess I need to know what you mean by 'queing behavior'.
In terms of topics which is basically a message queue with a hierarchial context, it has the following controls:
* User access control (read/write)
* Delivery control to subscribers (all, one, or none)
* Priority control
* Auto receipt request (by server not subscriber)
* Message reply, recall, and replace
* Timeout control when subscribers are not present
* Sequencing control (messaging ordering)
* Message maintenance (delete, move, count, list, etc.)
* Subscription windows (since and/or until date/time)
* Subscription suspend and resume w/o unsubscribing
* Topic property change notification
* More...
If you have other needs to govern queues/topics that is not mentioned here or in the specification, I would like to discuss them more with you. As the posting mentioned, we are looking for additional features that are needed by developers trying to implement a MQ system and to improved the depth the SMQP specification.
I'll read everything Monday, but does this spec allow or consider bounded queues?
--
3lixyqueue
John, you seem to know the topic pretty well. You're involved in IETF activities?
And FYI, you might catch some bad waves by regular trolls pretty soon, I hope you're aware of it.
Revision 11 will have properties on a topic that can place limits (boundaries). The currently planned topic limits include:
Number of subscribers
Number of messages at a given instance
Maximum individual message size
Maximum size of all current messages
A return code of 414 is returned when a resource has been exceeded. Additionallu, a server implementation can throw a 414 error code if other resources have been exceeded that are outside the protocol.
I am the author of the SMQP that has been in work for a couple of years. I've been working with the IETF as a specification author but not as a member of the task force. SMQP is an Internet-Draft. It is up to the IETF to place it on the standards track. This takes time. I've been getting excellent feedback from people over the last two years to make SMQP an enterprise level solution.
I'am aware that some will not receive this positively. I hope that they can become knowledgeable in MQ solutions and/or have used MQ solutions to understand the importance of having an open specification to manage this.
John wrote:
As someone mentioned earlier, SOAP is not a MQ. SOAP/.Net is still struggeling with how to manage a real MQ system for web services that is not just a point-to-point request (SMTP). Additionally, SMQP is one protocol, not a combination of syntax like HTTP, XML, WSDL, and UDDI.
Having read the spec (cool!), I would have to differ here on a few points. First, SOAP (at least recent versions) is really just a message formatting standard. Any message transport that is specified is just given as an example. SOAP does not include WSDL or UDDI - those are seperate specifications built on SOAP. For that matter, SOAP isn't necessarily a "web service" thing either.
SMQP is a transport protocol, more comparable to HTTP or SMTP than SOAP. Like those protocols, it doesn't specify the format of the messages it carries.
Given all that, I don't see why SOAP and SMQP should be seen as competing at all. Actually, I think that they would work together rather well, using SMQP as a transport for SOAP messages. In many ways this is similar to what the Jabber group are doing with their protocol.
What I'd like to see is a comparison between SMQP and Jabber. They seem to be tackling the same problem domain in quite similar ways, if you ignore syntax differences.
Agreed with Brians Hawley's comments. SMQP can easily be used with SOAP. Jabber is moving in that direction, but we did not want to be so XML based. We wanted the commands to be tight and light-weight. XML is a very verbose syntax which is both good and bad.
Jabber is more competing with APEX that is using the BEEP specification (RFC 3080). But both APEX and Jabber have yet to deal with some of the issues SMQP had to deal with earlier in its development. SMQP dealt with security, authentication, and encryption early in its development for one.
It can be confusing with many seamingly competing protocols. In the end, its not the protocol that is the best that 'wins', its the protocol that is adopted and used the most.
Given the simplicity of the syntax, it shouldn't be difficult to implement SMQP client code. Are there any patents that would prevent me from doing so? How about server code?
