[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Binary XML
- From: Michael Brennan <Michael_Brennan@allegis.com>
- To: 'Stuart Naylor' <firstname.lastname@example.org>, email@example.com
- Date: Thu, 26 Jul 2001 13:36:18 -0700
The issues with COM and CORBA through firewalls has nothing to do with the
fact that they are binary protocols. It has to do with the way these
protocols use ports, and the fact that many firewall configurations only
permit traffic through particular ports (and sometimes filter traffic that
does not conform to a specific protocol, such as HTTP). In contrast, HTTP is
pretty ubiquitous and sticks to its designated port. Contrary to some myths,
HTTP can be used to carry any type of content -- binary or otherwise. HTTP
is really not particularly well suited for some of the purposes for which it
is being used, but it's there and it's easy to piggy-back other protocols on
top of it.
With that said, much of the talk of "binary XML" is misguided, IMO. There
is, unfortunately, widespread ignorance of what prevailing, established
protocols already provide for solving many of the problems that "binary XML"
is supposed to address. Some of the suggested use cases include:
1) A binary protocol can be more efficient to parse into in-memory data
objects. I think this is bogus. When sending over a WAN, network latency
will make this parsing overhead insignificant. On a high-performance LAN, a
situation that needs that extra efficiency may be better served by using
CORBA, COM, or a similar RPC mechanism. XML is not a panacea, and not every
problem needs an XML-based solution. The valid use cases for this are a
fraction of what some suggest, IMO.
2) Faster throughput over a WAN. There are already established ways of
dealing with this. The HTTP spec explicitly supports compression using
proven protocols (gzip, deflate). These same compression protocols could be
used over other transport protocols, as well. Inventing a "binary XML"
format purely for this reason is simply pointlessly reinventing the wheel.
3) Providing optimized random access to fragments from large documents. This
one is interesting, but is probably better served in the more general cases
by XML databases, which is an evolving area.
> -----Original Message-----
> From: Stuart Naylor [mailto:firstname.lastname@example.org]
> Sent: Thursday, July 26, 2001 11:23 AM
> To: email@example.com
> Subject: Binary XML
> Can someone explain to me the idea behind binary XML.
> My initial interest in XML was due to the pitfalls of using binary
> distributed objects such as COM / CORBA. The protocols worked fine but
> had major problems when presented with a firewall and
> security settings.
> I am just interested in how binary XML will circum-navigate all the
> security scares that the doom & gloom consultants attach to binary