Re: AW: [ebxml-dev] ebXML and limited resources - on an ebXML Grid

[David Lyon <djlyon@froggy.com.au>]

Hi Daniel,

Have you looked at Distributive ebxml Grid technology ? as this has many of 
the elements that you are talking about.

Many companies are working on Distributive Grid technology, even some of the 
larger companies now. 

The ebXML Grids use a different communications paradigm than http or smtp. 
Based on the idea to keep tcp/ip connections open. When messages are ready, 
they are sent down the open connection in realtime. In of course, ebxml/UBL 
format.

Unlike computational Grids, an ebXML Grid is about permanantly opened TCP/IP 
connections to allow businesses to be "always on" with their trading 
partners. There is significant commercial value in having the latest 
information and of course, in proprietory systems, this technology has been 
around for over a decade.

We've been doing testing on a Grid and they certainly have no performance 
problems when they are up and running. But they are complicated like any 
eCommerce solution and the Grid that we run is largely experimental at the 
moment.

Some strict ebxml advocates say that passing ebXML/UBL messages over an ebXML 
Grid is not ebXML. At the same time, they say that ebXML is transport neutral 
so obviously there is a split of opinions or some misconceptions about what 
the ebXML specifications mean when they say that ebXML is transport neutral.

I also believe that there may be some ebXML Grid meetings in Germany next 
year so it will be interesting to see when these happen.

Best Regards

David Lyon

On Wednesday 13 November 2002 10:05 am, Daniel Kilper wrote:
> Hello Neil,
>
> Thank you for your substantial comments to my question. We are looking at
> high speed network performance. The intention of our approach is to use
> ebXML for signalling in a new kind of telecommunication markets (see:
> www.whyless.org). Therefore it is necessary to measure the overhead
> generated by a signalling communication framework like ebXML. I know that
> there are other standards available but it would be fine as you wrote to
> have the strengths of ebXML as a common data description language. That's
> why I try to determine the cost (overhead=ebXML) in comparison to the
> returns (payload of telecommunication network) of a network. This is
> strongly related to efficiency of a communication framework.
>
> Have you got an idea if there is something available to efficiency of
> ebXML?
>
> Thanks,
>
> Daniel
>
> ___________________________________________________________________________
>_ ____________
>
> 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."
> ___________________________________________________________________________
>_ ____________
>
> -----Ursprüngliche Nachricht-----
> Von: BELFORD Neil [mailto:Neil.Belford@vencorp.vic.gov.au]
> Gesendet: Mittwoch, 13. November 2002 06:16
> An: Ebxml-Dev (E-mail)
> Betreff: 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>
>
>
> ----------------------------------------------------------------
> 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>