BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Advanced Message Queue Protocol to Commoditize Messaging

by Floyd Marinescu on Jun 20, 2006 |
The Advanced Message Queuing Protocol (AMQP) specification 0.8 has been announced today by the newly formed AMQP working group which consists of JP Morgan Chase, RedHat, Twist, Iona, Cisco, and others. AMQP is an open specification for queue-based messaging that is technology agnostic, designed for performance and completely interoperable; it defines a protocol and model for queue-based messaging. The AMQP protocol aims commoditize the messaging middleware industry and provide true interoperability across technology stacks in any language or operating system. JMS APIs over AMQ could easily interoperate with .NET clients or any other language or platform that can communicate via AMQP.  

The AMQP wire-level format is split into two layers; a functional layer and a transport layer. The functional layer defines commands available to support transactional store and forward, publish/subscribe and batch file transfer messaging styles. The transport layer covers wire communication, "channel multiplexing, framing, content encoding, heart-beating, data representation, and error handling." The transport and functional layers are also pluggeable, allowing the protocol to evolve easily over time.  AMQP is like the messaging middleware equivalent to HTTP, and far better suited for asynchronous interoperable messaging than HTTP.  As a protocol, AMQP doesn't attempt to specify any technology specific API,  but any such API (such as JMS in Java) can send messages over AMQP. JMS will be to an AMQP server what JavaMail is to an SMTP Sever. 

John O'Hara, VP, Distinguished Engineer and Senior Architect at JPMorgan Chase, is the father of of AMQP. John worked on the idea for almost a year before finally selling the concept internally. AMQ now has the support of the Investment Bank and an implementation is now running in production there. O'Hara told InfoQ that JPMC already is already using AMQ in production a global trading system consisting of 800 users across 5 companies and data centers. "We have implementations from multiple companies running Java, C++, C#, running across Windows, Linux, and Solaris." 

On the need for AMQP, O'Hara explained that  "whenever trading partners get together to exchange business transactions, they know what information model they want to use (as standardized by specs like FPML), but they haven't got a transport to send it across... having a standard transport that provides a high quality of service and semantics required for business transaction messaging, even across the internet, can close that gap.  AMQ does not supply a toolkit for data transformation, it supplies a reliable eventing, business transaction and file transfer protocol that can be used between  or within organizations."  While AMQP is an interoperability spec, it can also help in integration concerns "we equally expect it to be tunnelled across the internet between business partners."

InfoQ also spoke to John Davies, a member of the AMQ working group, and now CTO of C24.

"Banks spend a lot of money just to send messages inside their own bank." Davies said, "AMQ should help to commoditise the messaging industry much like web servers have been commoditized by Apache". Messaging has not been commoditized yet. Over 90% of messaging according to Davies is IBM and Tibco RV, a small percentage is owned by Sonic and the rest is shared by 30 or so other vendors, mostly JMS vendors.

Just as today no one can try to sell a web server, in the future,  AMQ aims to commoditize the middleware industry.  The AMQP spec allows anyone to freely make open source, commercial or even hardware implementations of the protocol, which will contribute to its proliferation.   RedHat is currently working on an implementation that will be built into the operating system, making AMQ as free and available as SendMail, and accessible from any technology API such as JMS. 

Today AMQP is being published by a working group including JPMC, RedHat, TWIST, Iona, Cisco, and others. IBM, Sonic and Tibco have been aware of it for some time and have been watching the work which has been done in secret.  At the moment no one has published implementations but JMS, C/C++ versions are in the works.   John Davies is CTO of C24 who is also working on SWIFT, FpML, TWIST, TRAX2 and other financial services messaging over AMQ transports, with implementations coming soon. The AMQP specification is said to reach version 1.0 within 18 months. The working group is allowing more time for feedback and testing before submitting to a standards body at 1.0.  AMQP has been assigned port 5672 for both TCP and UDP, the UDP port being for a future multi-cast implementation.

Looking to the future, Davies thinks that AMQP will take over the messaging market soon: "JMS was released in 98 from memory, it was pretty much de facto in the Java world by 03 so I'd expect AMQ to be behind the lion share of the market by 2011."

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Glad to see this is finally out in the open by James Strachan

For a while there I wasn't sure if this was ever gonna make it out of JPMChase - so great news guys!

Due to the uncertainty behind AMQP we ended up building two alternatives at Apache to AMQP which are working nicely. I'm sure one day we'll add AMQP support to Apache ActiveMQ too then in addition to REST, Ajax and WS-Notification users can choose the wire protocol that suits their requirements the best.

James
LogicBlaze
Fuse: Open Source SOA

Re: Glad to see this is finally out in the open by John Davies

James,
Having multiple standards is not such a good idea and rather defeats the point. I would rather see ActiveMQ implement AMQ than have a whole choice of standards to choose from. Go on, you can do it, I expect to see something tomorrow morning after we've drunk Barcelona dry.

-John- (in Barcelona for TSSJS-E)

Re: Glad to see this is finally out in the open by Dan Diephouse

I am no messaging expert, but somehow I doubt that AMQP will be the end all be all of messaging protocols. One of the cool things about ActiveMQ is you can use which ever one may suit your needs. This helps keep standards honest and gives a chance for innovation.

Dan Diephouse
Envoi Solutions

Requirement on implementations to be OSS and royalty-free by Demed L'Her

The article says that "Implementations of AMQP will also be required to be open and royalty free". I checked the specs and didn't find any obvious (note: I am not fluent in Legalese) language to that effect (line 14 to 25 maybe? but these are among the most convoluted sentences I've ever read).

Could someone comment on this?
Any home (www) identified for that project?

Glad to see the tech part is easier to read ;-)

Re: Glad to see this is finally out in the open by Brian McCallister

John,

Stomp actually has gained a fair amount of traction, and I am willing to be sees wider usage than AMQP for a lot of things just because of its extreme simplicity. AMQP has the potential to be more performant, but until we have a chance to really dig into it, who knows.

I;m excited ot have both, to be honest.

-Brian

Re: Glad to see this is finally out in the open by Brian McCallister

Wow, I need more coffee before I (attempt to) type.

-Brian

Re: Glad to see this is finally out in the open by Brian McCallister

Wow, I need more coffee before I (attempt to) type.

-Brian

Re: Requirement on implementations to be OSS and royalty-free by Robert Greig

It is not the case that implementations have to be open source or royalty free.

The specification itself is free to use - no licencing is required. You can download it and start implementing it.

--Robert (JP Morgan Chase)

Re: Glad to see this is finally out in the open by John O'Hara

I wholeheartly support John's view here.

There needs to be confidence in each implementation of a common standard. Like implementations of TCP/IP, you try to avoid variety in the interpretation of the standard so interop works well. Developers can take pride in their implementations, but don't actually change TCP, which is not perfect but does the job.

A choice of transports for a middleware product just dilutes testing efforts and leaves everyone wondering "which is right", which lowers the end users' confidence.

Confidence in the stability, longevity and reliability of middleware is very important for users -- right up there with Databases and Operating Systems. That's why all three of these need to adhere to standards religiously.

Re: Requirement on implementations to be OSS and royalty-free by John O'Hara

The specification itself is open and royalty free.

Anyone is free to make free or commercial (or even hardware) implementations of AMQP. That's the point.

There will be a protocol community site, but that's still being put together. Please be patient; it should appear on www.amqprotocol.org one day.

Recently there was an article somewhere about banks consuming open products and not giving back. Well JPM has given back to the community - no strings attached (but do read the license). AMQP is the result of many man-years of effort driven by real requirements and involving several companies. Enjoy.

Why did we do it? When a firm has thousands of systems to integrate it just makes sense.

Look out for open project and commercial product announcements from other sources in the near future...

AMQP compared to Stomp... by John O'Hara

Stomp is a nice conversational command language to front a middleware server.
But I can't write a program in Stomp protocol and *know* that it will work the same when pointed at a different middleware server.

Why? Stomp doesn't specify all the semantics of the middleware; there are a million little questions to answer; how does prefetch work, how is flow control handled, how are async events in the middle of a transaction presented, when something goes wrong what happens to the connection and what state is it left in, if I sent a message and the server acks it did it get to the server or another client, was it guaranteed to be safe stored or was that 'optimised' away, how does message re-delivery work, when a message is allocated across a cluster what are the ordering guarantees, how does a firewall recognise this protocol, if I write an MT program can I still use network traffic shaping, if the protocol resistant to buffer overflow exploits ... this list goes on and on.

AMQP documents the semantics you can depend on (or tries to, we must have missed something). If we have missed something, we have a bug in the protocol - please tell us and we'll correct it.

AMQP was almost a text protocol at one stage; but we wanted to make life easier for hardware acceleration.

Re: Glad to see this is finally out in the open by Michael Neale

Standards often end up benefiting all involved (as long as they cover enough functionality) - so I don't know why anyone would object to this effort. Sounds good.

Re: AMQP compared to Stomp... by Brian McCallister

John,

Yep, I agree, and adding a JMS behavioral spec is something I have actively resisted -- Stomp is designed as a very simple edge protocol. The behavior inside the messaging system is up to the messaging system.

I am looking forward to having some down time to do an AMQP implementation and see how it feels. I really am looking forward to it a lot, and if it turns out to be on about the same order of complexity to implement I'll do a backflip in excitement.

Question about it though, AMQP was developed behind closed doors, once released, what is the specification development model, and who will own it? The copyright seems to be jointly assigned to all the folks who worked on it, in the spec doc.

-Brian

Re: AMQP compared to Stomp... by Brian McCallister

Pass one through the spec -- I like it a lot at first glance!

Re: Glad to see this is finally out in the open by James Strachan

James,
Having multiple standards is not such a good idea and rather defeats the point.


It depends on the purpose of the protocol. I see no reason not to have multiple protocols if they serve different purposes and hit different sweet spots.

e.g. REST/Ajax/Comet is designed to work great on the internet with web infrastructure and browsers etc.

WS-Notification/WS-Eventing/WS-EventingNotification are for the SOAP stacks and folks who really like pointy brackets ;).

OpenWire is a protocol designed with performance, flexibility and features in mind in the ActiveMQ project rather than interoperability between any client and server from different vendors.

Stomp's current sweet spot is its easy to implement in an hour or two in any language and gets you talking; allowing a telnet session to be a Stomp client.

AMQP clearly has a sweet spot as being a good interoperability protocol across messaging vendors (kinda like WS-Notification without those pesky angle brackets! :)

So I'm keen to see AMQP succeed and welcome it. However I don't see all of the above protocols disappearing any time soon; though we could well have some rationalisation.


I would rather see ActiveMQ implement AMQ than have a whole choice of standards to choose from.


I'm sure ActiveMQ will implement AMQP one of these days; though ActiveMQ will always offer folks choices too - right tool for the job and all that. There doesn't have to be one protocol to rule them all.

Go on, you can do it, I expect to see something tomorrow morning after we've drunk Barcelona dry.

-John- (in Barcelona for TSSJS-E)


LOL. Looking forward to it! :)

James (boarding a plane for Barcelona real soon....)
LogicBlaze
Fuse: Open Source SOA

Re: Requirement on implementations to be OSS and royalty-free by Andreas Mueller

As a JMS vendor (SwiftMQ) I really appreciate this effort. A wire protocol for interop is what we need. However, what I'm missing is a standard for destination names. They highly differ between the different messaging vendors and sometimes have semantics attached (like hierachical topic names etc). How will you handle that?

There will be a protocol community site, but that's still being put together. Please be patient; it should appear on www.amqprotocol.org one day.


How will you handle AMQP compliancy certification? Will you provide a TCK? Who will do the certification? The vendor itself or will there be an instance doing it? In the latter case: will it be free?

Re: Requirement on implementations to be OSS and royalty-free by Robert Greig


However, what I'm missing is a standard for destination names. They highly differ between the different messaging vendors and sometimes have semantics attached (like hierachical topic names etc). How will you handle that?


What we have done is introduce the concept of an exchange, which could have been called a "router". In a nutshell an exchange implements an algorithm for routing a message within the broker. We have defined some standard exchanges in the protocol specification (for point to point, pub sub, header based routing and so on) - that list is not exhaustive and we imagine others will come up useful ones.

By doing this we don't rely on a naming convention.

Ping me privately if you have questions or want a more thorough explanation - also look at the section on exchanges in the protocol specification.

-- Robert (JP Morgan Chase)

Re: Requirement on implementations to be OSS and royalty-free by Robert Greig


OpenWire is a protocol designed with performance, flexibility and features in mind in the ActiveMQ project rather than interoperability between any client and server from different vendors.


AMQP is a protocol designed with performance, flexibility and features in mind and interoperability between any client and server from different vendors.

It is not intended that people will have to make a choice between performance and interoperability.

-- Robert (JP Morgan Chase)

Interop test/cert by Kit Davies

This is really good news but I would like to see some kind of independent interoperability testing group set up to *prove* compatibility. Something like what the Drummond Group does for ASx.

Then I can check a matrix and see that, eg, Product X is known to work with Product Y. Standards adherence is not enough. It is too woolly and open to interpretation.

Kit

Testing Compliance, and Destination Naming by John O'Hara

Testing compliance is one of the tough areas that the WG is discussing. The whole project is very aware of things that make these efforts fail (the article about the problems with CORBA over on slashdot is very relevant, and what we're trying to avoid). In the end, interop is the ultimate test. You either work with the other implementations that exist, or you don't. Those other implementations which interoperate are controlled by different entities, so that seems like a fair and pragmatic starting point.

AMQP wants to be a reliable, stable, neutral, long term protocol. These are the characteristics users want - but not necessarily the developers working on the middleware.

On Destination Names: it became obvious during the 3 major revision of the protocol and the implementations by the group that the concept of "destination", while convenient is fundamentally broken.

Draw parallels to FedEx; to send a message you get a box (message) apply a stamp (QoS), add an address (routing information), doodle on the box (header based routing) and *give it to FedEx* (or another service - your AMQP implementation). You don't send it to the destination, per se.

Once we had this "ah ha" moment, the whole thing became a lot more elegant and efficient. Its also how IP works and how email works (ish). Read the spec, its interesting.

I do agree that having a nice naming convention for routing information (like peoples home addresses, or email addresses) would be great. Feel free to propose one, but make sure you've implemented it at least once and put it in production first ;-)

AMQP is primarily a Client to Broker protocol by John O'Hara

To correct James Strachan's point; AMQP is a client-to-broker protocol (but it has also been successfully used for cluster interconnect and WAN bridging). It's also very efficient (not insanely efficient :-)

I should be able to take a PERL AMQP client from my Linux supplier and point it at an AMQP compliant server on Java from my favourite middleware vendor and it should work. Perhaps in the future I can buy a hardware device that implements the AMQP and up-size to that just by changing the connection parameters. Hopefully we can get to full plug and play. History has shown that the industry benefits from that kind of convergence.

Perhaps I might the first person to coin the term "Middleware Enabled Network (MEN)" (like SAN, or MAN), or "Network Messenger".

It should be noted, that according to Gartner, all the small middleware vendors combined have less market share than the largest supplier.

A well implemented standard levels the playing field for smaller suppliers, grows the market and increases the confidence of your potential customers. It also enables everyone to move up the stack and do more interesting things.

Re: AMQP compared to Stomp... by John O'Hara

AMQP is jointly owned by everyone who contributes to it. If you make a big enough contribution to AMQP that you are invited to sign the copyright and patent licensing contract for AMQP, you get your name on the Copyright statement. The Working Group is careful to manage the IP in AMQP to keep it open.

AMQP, once finalised, will go to a standards organisation, which will be licensed to maintain it and evolve it from then on.

There will be a web portal for open development coming in a couple of weeks at www.amqprotocol.org (and www.amqp.org)

Re: Testing Compliance, and Destination Naming by Andreas Mueller

Testing compliance is one of the tough areas that the WG is discussing. The whole project is very aware of things that make these efforts fail (the article about the problems with CORBA over on slashdot is very relevant, and what we're trying to avoid). In the end, interop is the ultimate test. You either work with the other implementations that exist, or you don't. Those other implementations which interoperate are controlled by different entities, so that seems like a fair and pragmatic starting point.


I consider a TCK as one of the most important parts of your protocol. If we have to test interop in-depth with all other impls this would be hard work. Just consider that these are all competitors and everybody thinks he has the proper impl. So at the end it would be the survival of the strongest (money-wise). If you ever had the luck to integrade a JCA 1.5 resource adapter into the different app servers, you know what I mean. JCA 1.5 has a spec but no JCA 1.5 TCK...

But anyway, I'm looking forward to the launch of your web site.

Re: AMQP is primarily a Client to Broker protocol by Andreas Mueller

It should be noted, that according to Gartner, all the small middleware vendors combined have less market share than the largest supplier.


Right. And even the JMS standard did not change that dramatically. Before JMS came up, MQ had ~75% market share. I think they are still around 70%. A standard middleware protocol will not change it either.

Re: AMQP is primarily a Client to Broker protocol by John Davies


Andreas:
Right. And even the JMS standard did not change that dramatically. Before JMS came up, MQ had ~75% market share. I think they are still around 70%. A standard middleware protocol will not change it either.


I disagree, firstly JMS is Java only and and therefore had no influence on the Microsoft and mainframe implementations, secondly it is just an API so if anything JMS made it easier to use MQ. Someone using the JMS API doesn't need to know what the implementation is, we do this a lot in the banking world. The code is the same for MQ, SwiftMQ, Sonic, ActiveMQ or any of the other 30 or so implementations. Banks use MQ because it works on everything, you can send a message from a .NET machine running VB to a Linux box running Java to a mainframe. Several other JMSs do a lot of this but you're just moving off one commercial product to another, if you move off MQ you're still locked into the implementation once you commit.

AMQ will change this, if SwiftMQ, Sonic, ActiveMQ and others implement the AMQ Protocol we will be free to use any and all implementations, they will interoperate. This is identical to the way IIOP allowed IBM's Java to talk to Sun's Java. It wasn't that long ago, before J2EE app servers predicated IIOP that you couldn't get a simple Java client (written with Sun's JDK) wouldn't talk to WebSphere. People using WebSphere were locked into using IBM's JVM and if you had a bug in it (and there were quite a few) you were screwed. By forcing app servers (as of J2EE V1.3) to use IIOP it meant that all app servers can talk to all clients, as long as they used IIOP.

AMQ will do much the same, I can see the 70% being seriously reduced over the coming years, unless of course IBM do something inventive, knowing what they're like though it's unlikely.

If vendors like SwiftMQ and Sonic start to implement AMQ they will be able to maintain and possibly grow their market share simply based on the value they add to the stack, monitoring tools, queue browsers etc. etc. The time to do this is now, the quicker you do it the larger the market place.

-John-

Floyd - erratum on licensing statement by Demed L'Her

Floyd,

This was confirmed by various folks in the comments. The statement on licensing requirements in the article ("Implementations of AMQP will also be required to be open and royalty free") is not quite correct. Thanks.

Re: Requirement on implementations to be OSS and royalty-free by Demed L'Her

Thanks for the confirmation. Makes more sense and in-line with my understanding of the license. Just suggested Floyd to correct the article.

Re: Requirement on implementations to be OSS and royalty-free by Floyd Marinescu

Thanks for the confirmation. Makes more sense and in-line with my understanding of the license. Just suggested Floyd to correct the article.


Sorry about that, I believe there was discussion about having a compliancy test that might reuquire certified versions to be open source, but that is not final yet. I'll update the article.

Re: Floyd - erratum on licensing statement by Floyd Marinescu

Floyd, This was confirmed by various folks in the comments. The statement on licensing requirements in the article ("Implementations of AMQP will also be required to be open and royalty free") is not quite correct. Thanks.

Updated, thanks.

MQ Interoperability by Geoffrey Wiseman

Finally. :)

Re: AMQP is primarily a Client to Broker protocol by James Strachan

I should be able to take a PERL AMQP client from my Linux supplier and point it at an AMQP compliant server on Java from my favourite middleware vendor and it should work.


FWIW today you can use the Stomp client for C, C++, C#, Java, perl, python, php, ruby or even pike and talk to any Stomp server and it does work fine right now.

So there's nothing intrinsically new about having cross language clients talking to the broker within one organisation.

Though IMHO the real value of AMQP will come when MQSeries, Tibco and a bunch of JMS providers natively support it - allowing different business units or companies to communicate via the protocol to avoid trying to make cross-organisational decisions on what messaging middleware to use. i.e. it would be a much more efficient option than using WS-Eventing/WS-Notification to cross organisational boundaries.

James
LogicBlaze
Fuse: Open Source SOA

Re: AMQP is primarily a Client to Broker protocol by Pieter Hintjens

Stomp does, indeed, let different languages work together. For what it's worth, Stomp implements more or less the first version of AMQP, which we designed in early 2005, and rewrote twice more after that. The goal at that stage was to cover the needs of JMS, in a clear wire-level protocol.

But it soon became clear to us that this did not deliver interoperability. JMS has some real flaws, the most severe being its obsession with "destination" even though the semantics of queues and topics are quite different - queues are a message store, and topics are a distribution mechanism.

We threw away the concept of destination and dug deeper into the question, "what does it mean to do messaging?" and came up with a semantic model that seperates the entities that do distribution, and the entities that do storage. The result is the model of AMQP exchanges and queues.

This is the real innovation in AMQP, in my opinion. Wire level protocols are a dime a dozen, and APIs are no big deal. SWIG makes it easy to export an API to lots of languages. All this is fun, especially for vendors, because it captures lots of users and applications.

The goal of AMQP is the opposite - to free the users. And to do this, we needed to define a rule book for interoperability. The AMQP model does this. We've tested it - two teams, building their own brokers and clients, and plugging them together, and we know it works. We know exactly how long it takes a good developer to implement AMQP and we know exactly how to measure whether the results play by the book, or do not.

You'll find that the protocol specifications are extremely lucid in this regard. They define what is needed for interoperability but nothing more. There are some areas that need closure, obviously. And it's possible to make proprietary extensions to the protocol in many places. This is not a bad thing.

The cost of the clarity that AMQP delivers is that it's non-trivial. You can't just telnet to an AMQP broker and try it. It's unlikely that existing brokers can just implement the protocol because AMQP goes deep into the functionality of the broker, it rips open that black box and it says, "we want this piece, here, and that piece there", and the pieces it specifies are sophisticated, complete, nearly a full recipe for a messaging broker.

The upside is that we know this approach works. So the risk of implementing AMQP is almost zero.

Re: AMQP is primarily a Client to Broker protocol by Hiram Chirino


We threw away the concept of destination and dug deeper into the question, "what does it mean to do messaging?" and came up with a semantic model that separates the entities that do distribution, and the entities that do storage. The result is the model of AMQP exchanges and queues.

This is the real innovation in AMQP, in my opinion.


I agree 100%. Like I stated in my blog post about AMQP, I think the binding semantics described in AMQP are a great idea. I think it would be great if an abstract API like JMS would include some of these concepts in it's next revision.

I also think that those semantic ideas can be used by other protocols too. STOMP could easily add support for this. Like you said, wire protocols are a dime a dozen, as long as they can convey the data, the wire protocol has done it's job.

The thing that is harder to do is changing an existing legacy brokers to support the new semantics of allowing client configured bindings. This fact could make it difficult for legacy messaging brokers like IBM MQ and Tibco to support this new protocol.


Wire level protocols are a dime a dozen, and APIs are no big deal. SWIG makes it easy to export an API to lots of languages. All this is fun, especially for vendors, because it captures lots of users and applications.


Well, there are APIs and then there are vendor neutral APIs like JMS. Some are no big deal, the others are a little more important.


The goal of AMQP is the opposite - to free the users. And to do this, we needed to define a rule book for interoperability. The AMQP model does this. We've tested it - two teams, building their own brokers and clients, and plugging them together, and we know it works. We know exactly how long it takes a good developer to implement AMQP and we know exactly how to measure whether the results play by the book, or do not.

You'll find that the protocol specifications are extremely lucid in this regard. They define what is needed for interoperability but nothing more. There are some areas that need closure, obviously. And it's possible to make proprietary extensions to the protocol in many places. This is not a bad thing.


It would be interesting to know how you define 'interoperability'. Would it cover the case of having a JMS client that talks AMQP from vendor A talking to vendor B?


The cost of the clarity that AMQP delivers is that it's non-trivial. You can't just telnet to an AMQP broker and try it. It's unlikely that existing brokers can just implement the protocol because AMQP goes deep into the functionality of the broker, it rips open that black box and it says, "we want this piece, here, and that piece there", and the pieces it specifies are sophisticated, complete, nearly a full recipe for a messaging broker.


I think these are all negatives against this protocol if you want it to become THE interop protocol of different vendors.

--
Regards,
Hiram
LogicBlaze

Re: Interop test/cert by Andy Doddington

If the standard is inadequate to ensure interoperability then it should be tightened up - that is its purpose. Test suites are really only a compromise (albeit a pragmatic one) and should not be used in place of a good standard

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

34 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT