Lists Home |
Date Index |
- From: "KenNorth" <KenNorth@email.msn.com>
- To: "Jonathan Borden" <firstname.lastname@example.org>, <email@example.com>
- Date: Mon, 7 Feb 2000 10:56:35 -0800
> We are back to the content vs. transport issue. XML is content.
> SMTP/HTTP are transports. It is usually no problem to stuff an XML
> into a message and send it along using whatever transport is desired. For
> reliable async messaging, there are proprietary messaging systems
> from IBM, MS etc. etc. Just as HTTP is layered on top of TCP/IP one can
> layer a transactional/reliability protocol on top of SMTP, but doing this
> not about XML per se, rather the domain of stuff like TIP, XA-Open etc.
I didn't get the impression the original poster (K.Kawaguchi) was confused
about the distinction between content and network transport. I'm missing
your point because the original inquiry was about software that:
- exposes a component interface
- supports message queues
- can deliver XML.
Is your point that we should only be discussing only document content, and
not software or system architectures used with XML applications?
In any case, there are classic messaging middleware products (pre-Java and
pre-XML). MQSeries is an example, and it established a de facto standard
wire protocol. There are newer (post-Java, post-XML) products that are wire
compatible with MQ, but they include features such as Java messaging and XML
================== Ken North =============================
See you at SIGS Java Developer Conference (London, March 13-15, 2000)