David and Dale,
My understanding is that AMQP was very much positioned as
an internal (intra-enterprise) messaging bus protocol competing with
existing proprietary protocols. I do not think it was intended as an
inter-enterprise protocol.
So I see ebMS as being complementary to AMQP for
inter-enterprise message exchange just as ebMS is complimentary to JMS and
other proprietary messaging protocols.
Some
of my colleagues in Cisco have been quite active in the development of the
AMQP. I can ask them to engage in the discussion if there's
interest.
Best
Regards,
John
Dale,
Good synopsis.
That would certainly jive with SWIFT message needs - where their existing
XML is overspecified - whereas the original SWIFT messages are highly compact
but underspecified! And of course banks love to have hardware messaging
layers that only they have. And when they talk about open standard - that
means between banks!
which makes an ebXML CPA look trivial! Trawling through that though I
see I could if pressed write some XSLT to output that control file
format from a CPA... since most of the semantic and logic content would
appear to be consistent with typical control parameters, or easily defaulted
to obvious values.
I'm not sure about sweet spot for ebMS though - as certainly the UK NHS are
sending very high message volumes per minute of common XML messages... so it
probably is an example of the banks intentionally wanting to be different
(again) and the cost is not an issue for them.
Thanks, DW
Original Message --------
Subject: [ebxml-msg] RE:
[ebcore] AMQP and ebXML messaging?
From: "Moberg Dale"
<dmoberg@axway.com>
Date: Tue, August 12, 2008 2:07 pm
To: "David
RR Webber (XML)"
<david@drrw.info>,
<ebxml-msg@lists.oasis-open.org>
Cc:
<ebcore@lists.oasis-open.org>
I have encountered
AMQP proponents and evangelists (!) several times over the last few years, and
have heard a presentation on it from an original
contributer.
Actually it seemed to
me that AMQP was more concerned with supplementing ordinary internet protocols
with message queues, as the acronym suggests.
For example, fixed
length message headers were typically used partly out of concern with overflow
attacks.
Binary
representations were sometimes used instead of XML to avoid XML parser
attacks. Etc.
So I would guess you
could layer a SOAP infoset on top of AMQP if you wanted to. I really think
that AMQP is maybe an alternative to FTP, SMTP and HTTP for business data
exchange and is not very high up on the collaboration protocol
layering.
If it is payload
neutral, we can layer ebMS 3.0 payloads over it. I see no real reason to think
AMQP is not neutral in this respect. If we wanted to we could work out the
Transport details for AMQP and layer over it. Do you see any interest in that?
My impression is that they were going for high performance on high volumes of
short messages, which is not the normal sweet spot for the ebXML OASIS
layers.
Dale
Moberg
In researching
TWIST I tripped over the related work on AMQP
The
banking industry of course has a long history of inventing messaging that only
they use.
However
they claim interoperability with SOAP in this case - but when you look at
their business objectives - it looks like they are re-inventing the ebMS
wheel.
So the
question I have is - has anyone else looked at this AMQP stuff - and is it
compatible with ebMS - particularly V3.0?
Obviously if implementers can send ebMS exchanges
across AMQP infrastructure seamlessly then this is less
problematic.