[
Lists Home |
Date Index |
Thread Index
]
COTS only applies when the market has entered commodity mode. XML
messaging has a ways to go before it is a commodity. The current SOAP
vs REST debate demonstrates that. If it were a commodity, there would
be no space for such debate. Buying COTS XML acceleration today is akin
to buying SGML COTS software 5-10 years ago... it exists, but it targets
vertical markets. When it moves out of the vertical markets into the
mass markets, then it will be commodity. There are excellent options
available, but don't expect any of them to be around in any recognizable
form in 5 years.
-derek
> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com]
> Sent: Thursday, June 02, 2005 8:02 AM
> To: Derek Denny-Brown; Chiusano Joseph; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Why XML for Messaging?
>
> One answer, Derek: COTS.
>
> We have to do it that way. As I replied to Dare, we
> prefer these be based on standards and that probably
> means FastInfoset because there aren't good alternatives
> that will be available in the timeframe alloted or
> possibly ever given positions taken publicly by MS, IBM,
> the W3C, etc. So it's off to ISO.
>
> XML will be replaced. Technological churn is ceaseless.
> You and I are both too close to the current winner to
> know what that will be, but we are also old enough to
> have seen fish become mammals when the seas boiled. At
> that point, it will be another 'good-enough' solution
> quite probably, and it will likely be a solution that
> we are rejecting today because we don't need it yet.
>
> Actually, we do use CSV for many things. Some customers
> prefer it. XML is there for those that don't. Where
> we have to use binaries, we can do exactly as you suggest
> and have. We want a standard for exactly the same reason
> as we use XML: the customer demands it and we don't want
> to lose business explaining YAGNI to them. In a business
> deal, the real technology debate is the last debate and it
> is had after the contract is signed.
>
> My suggestion to you, Joe, is to benchmark web service
> performance. Consultants inside 395 need to come to
> grips with these issues. Good enough isn't always.
> No slur intended, at all. The closer any system
> comes to real time, the more it matters.
>
> len
>
> (also my own opinion and not that of my employer)
>
> From: Derek Denny-Brown [mailto:derekdb@microsoft.com]
>
> So create a format tuned for your scenario, and stick XML APIs on both
> ends to support plugging into existing XML machinery. This begets the
> whole binary-xml question. The issue is not one of making a faster
> format; that is easy. The issue is making a format that is enough
> faster in enough different scenarios, to make it better than
> individually tuned formats. CSV may be optimal for you, so use it.
As
> has been brought up, there are cases where CSV doesn't work (embedded
> commas, newlines, nested structure, etc). As Dare commented, XML
isn't
> about being the best at anything. It is about being the good-enough
for
> the widest variety.
>
> > Still, what will replace XML? What will it look like?
> > Is it hiding in the tall grass or is it laying on
> > the shelf at Sun? It's a fun question.
>
> I don't think there is anything out there today that will 'replace'
XML.
> To replace XML it would have to provide enough benefit in enough
> scenarios to justify moving existing systems. For most users, none of
> the current proposals for something XML-Like (be it simplified XML or
> binary-xml), are really necessary. XML's reach is already being
> extended by using custom alternate formats in tightly coupled systems.
> That trend is likely to continue, but for the near term, it is likely
to
> exist as an optimization path. XML-text will still be the primary
> model. That model isn't likely to change until enough XML is rolled
> out, that XML developers start to really become fed up with XML's
> limitations due to it's origins as a 'document' format. Why can't a
> user escape arbitrary characters both in content, but also in names?
As
> XML becomes increasingly used to communicate between systems, which do
> not share its origins in text markup, these will become increasingly
> problematic issues.
>
> Just like XML is a SGML, generalized for the WWW markup, someday we
will
> see a new text format supplant XML that is generalized for _data_
> exchange... or whatever need is found that XML does not quite fit.
>
> -derek
>
> Disclaimer: the above is my personal view and is independent of my
> employer
|
