XML vs. CORBA (was RE: Alternatives to browsers)

[Brandt Dainow]

I like W3C's statement on their summary doc - "XML may not be the answer to
everything, but it's always worth considering."

Brandt Dainow
bd at internet-etc.com
Internet Etc Ltd
http://www.internet-etc.com

>-----Original Message-----
>From: owner-xml-dev at ic.ac.uk [mailto:owner-xml-dev at ic.ac.uk]On
>Behalf Of
>Simon St.Laurent
>Sent: Tuesday, January 18, 2000 6:54 PM
>To: xml-dev at ic.ac.uk
>Subject: XML vs. CORBA (was RE: Alternatives to browsers)
>
>
>At 03:56 PM 1/18/00 +0000, Miles Sabin wrote:
>>I'm having trouble seeing why XML over HTTP is preferable to
>>eg. CORBA or Java RMI (maybe tunneled through HTTP if there's
>>a need to traverse firewalls) for application specific comms.
>>How is application specific markup better than an application
>>specific binary wire protocol?
>
>As others have said here already, XML isn't preferable in a lot of
>case-by-case situations.  On the other hand, defining data formats for
>interchange makes it much easier for different developers to choose
>different transport mechanisms at will, without being trapped
>in a single
>large and complex environment.
>
>At 06:37 PM 1/18/00 +0000, Miles Sabin wrote:
>>If you've got CORBA/RMI/DCOM clients and servers on both ends
>>why would you want to take a detour via XML over HTTP (other
>>than for firewall traversal). The generated XML would be about
>>as illuminating (and as helpful for interoperation) as running
>>a binary executable through a disassembler.
>
>If you already have that infrastructure on both ends, I doubt
>there's much
>value in changing it over to XML/HTTP.  On the other hand, if you don't
>have that infrastructure on both ends, or are faced with
>supporting it in a
>diverse set of environments, I would strongly urge you take a
>look at XML.
>
>Even if you're talking about straight object-to-object
>communication, tools
>like JXML's Quick let you handle that communication in ways
>that are much
>more interesting than disassembled binary material.  Sun's latest moves
>toward using XML for Java object persistence in 1.3 may provide similar
>food for thought.
>
>For me, the key aspect that XML provides - and other solutions
>don't - is
>that XML can be made to work in nearly any vaguely modern computing
>environment, with a relatively small overhead.  There may be
>more work to
>do as far as connecting the XML information to your applications, but
>you'll be able to do it when and how you feel appropriate,
>without needing
>much infrastructure.
>
>Simon St.Laurent
>XML Elements of Style / XML: A Primer, 2nd Ed.
>Building XML Applications
>Inside XML DTDs: Scientific and Technical
>Cookies / Sharing Bandwidth
>http://www.simonstl.com
>
>xml-dev: A list for W3C XML Developers. To post,
mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN
981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer
to OASIS.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.