× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



XML is no better than any other communications type?  You have got to be 
kidding me.  Compare XML against your favourite binary protocol (ASN.1 
perhaps?) on the criteria of standardisation, cross platform tool support, 
interoperability testing and industry usage.   Nothing is going to beat 
XML.   In fact the most popular binary protocols are being reformulated in 
XML (e.g., DSML for LDAP, XML-RPC and SOAP for RPC).

XML messages are usually larger than those expressed in a binary protocol, 
given.  But how many integration projects fail on the basis that the 
intergration protocol had less than 100% runtime performance?  Very few -- 
the key challenge is interoperability, not out and out pedal-to-the-metal 
every-byte-counts performance.

And to be pedantic -- at the network level it doesn't matter if you're 
transferring 8 bytes or 708, either way they're both getting shipped in a 
single 1500 byte ethernet packet.




"Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> 
Sent by: java400-l-bounces@xxxxxxxxxxxx
09/12/2004 13:42
Please respond to
Java Programming on and around the iSeries / AS400 
<java400-l@xxxxxxxxxxxx>


To
"'Java Programming on and around the iSeries / AS400'" 
<java400-l@xxxxxxxxxxxx>
cc

Subject
RE: The OS/400-Java "impedence bump"






Yeah, there is a compelling reason.

First off, XML is no better than any other communications type.  In
fact, it requires a lot of negotiation and implied agreement just to get
it working.  You have to agree on the tags and content of those tags
just to get things started.  For a good discussion of some of XML's
shortcomings, you might want to read my recent article:

http://www.mcpressonline.com/mc?1@xxxxxxxxxxxxxxxxxxxx@.6b1994a0

Second, XML is very fat, especially if you use SOAP.  A typical SOAP
message has 700 bytes of overhead.  When I'm only sending an account
number, that's a lot of useless overhead clogging the network.  There's
a reason why modem manufacturers take the time to determine the fastest
speed available.

No, if we had a simple standard header that allowed two computers to
identify their fastest common communication mode, we'd be able to reduce
a lot of the clutter.

Joe


> From: Niall.Smart@xxxxxxxxxxxxxxx
> 
> That sounds like a lot of development overhead and complexity, instead
of
> getting machines to negotiate on an agreeable data format, just get
> everything to talk XML.   Unless of course there is a compelling
reason
> not to!

--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) 
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.




The information contained in this e-mail is confidential and
may be privileged. It  is intended only for the addressee(s)
stated above. If you are not an addressee, any use,
dissemination, distribution, publication, or copying
of the information contained in this e-mail
is strictly prohibited.

Friends First Life Assurance Company Ltd is regulated
by the Irish Financial Services Regulatory Authority. 

If you have received this e-mail in error, please immediately
notify us by telephone at 353-1-6610600 or e-mail
Helpdesk@xxxxxxxxxxxxxxx and delete the e-mail
from your system.

Thank you for your co-operation.
Friends First  Group, Cherrywood Business Park , Loughlinstown
Dublin 18.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.