RE: [ebxml-dev] ebXML and limited resources

["Munter, Joel D" <joel.d.munter@intel.com>]

Hi Daniel,

There is lots of XML Acceleration Technology now available.  You might want
to factor some of this into your architecture designs.

This is from http://www.nwfusion.com/news/tech/2002/0610tech.html
	"Traditional network accelerators speed network applications by 
	moving content closer to users, as in the case of local or global 
	caching, or by off-loading cryptographic functions from servers, 
	as with Secure Sockets Layer accelerators. 

	However, the growing use of dynamic XML in applications is giving 
	network administrators something new to worry about. XML is a
verbose 
	format that creates performance problems. This has spurred the 
	emergence of a new type of network device: the XML accelerator.

You might want to review:

http://radio.weblogs.com/0105910/2002/06/23.html

http://www.innovapp.com/intel_XML_accel.cfm  cool Intel-based H/W

http://www.gotocol.com/innet.html

Joel

-----Original Message-----
From: BELFORD Neil [mailto:Neil.Belford@vencorp.vic.gov.au]
Sent: Tuesday, November 12, 2002 10:16 PM
To: Ebxml-Dev (E-mail)
Subject: FW: [ebxml-dev] ebXML and limited resources


Hello Daniel,

We have just gone live with an industry wide B2B implementation using the
ebXML messaging infrastructure, carrying an aseXML document as the payload.
aseXML is the Australian energy industries data description language.

I'm not sure what you mean by network resources, if you want high speed
network performance, clearly - dont use any form of web services, ebXML or
otherwise, don't use anything that uses HTTP as the transport layer. If you
are in an all Java environment use RMI (in conjunction with RMIProxy
http://www.rmiproxy.com/ if you have to cross firewalls - otherwise it will
fall back to HTTP anyway and defeat the purpose of the technology). If you
dont have the option of deploying on RMI then you need CORBA and middleware.
The difficulties of CORBA (and DCOM for that matter) is kind of the problem
that cumbersome web services are there to fix. So - if ubiquity demands you
sit on HTTP (or SMTP for that matter) using an intermediate data description
language (presumably some flavour of XML) - expect overheads in the gateways
and on the network.

ebXML is an excellent solution to many of the problems posed by inter
enterprise collaboration, certainly here in the Gas industry it has been a
startling success in the form in which we have used it ( ebMS v1.0 with
signing and reliable messaging). However while it offers excellent
abstraction from the disparate platforms that are deployed by the various
participants, it is by no means 'lightweight' in the gateways. The overheads
in HTTPS, digital signing, reliable messaging, and so on, are substantial,
particularly if you need to scale up to large traffic volumes. Our system
(which has a hub and spoke architecture) has been live for about 3 weeks and
is currently doing about 100,000 messages through the hub on a busy day. 

Given all the constraints we faced, I don't think any technology other than
ebXML could have delivered a viable messaging solution to this industry; in
conjunction with aseXML which has here demonstrated the great strength of
XML in providing a common data description language.



Neil Belford

Architect, 
FRC B2B System
VENCorp 
http://www.vencorp.com.au
 


-----Original Message-----
From: Daniel Kilper [mailto:daniel.kilper@mailbox.tu-dresden.de]
Sent: Wednesday, November 13, 2002 12:55 AM
To: ebxml-dev@lists.ebxml.org
Subject: [ebxml-dev] ebXML and limited resources


Dear all,

We are currently dealing with XML based transaction standards used in
environments with limited network resources. Is there an investigation
available dealing with efficiency of ebXML under time or limited network
resource constraints?

Thanks in advance for comments,

Daniel Kilper

____________________________________________________________________________
____________

EU-Project "whyless.com"
Department of Business Management and Economics
Dresden University of Technology
01062 Dresden, Germany

phone : +49 351 463 39201
fax   : +49 351 463 36883
e-mail: daniel.kilper@mailbox.tu-dresden.de

"This communication is intended solely for the addressee and is
confidential and not for third party unauthorized distribution."
____________________________________________________________________________
____________


----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>


******************************************************************
This e-mail is confidential and for the sole use of the intended 
recipient(s).  If you are not the intended recipient, you are not 
authorised to disclose, use, distribute or in any other way make 
use of the information contained in it, and such activities are
prohibited.  If you have received this e-mail in error, please 
notify the sender by reply e-mail, delete the document and destroy 
all copies of the original message.
******************************************************************

----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>