[ebxml-dev] FRC B2B System - Victorian Gas Industry

[BELFORD Neil <Neil.Belford@vencorp.vic.gov.au>]

Due to interest expressed in our ebXML deployment I have here detailed a quick overview of our situation.

There has been a great deal off work in the area of retail contestability in utilities in Australia, mostly under state based legislative frameworks, at the behest of the federal government. The state of Victoria, for reasons of recent political history is the most advanced down this path, and of the utilities, Gas is well ahead of Electricity in terms of effective B2B implementation, possibly because the Gas industry was able to learn from the mistakes of Elelctricity.

The reasons for the success of the B2B system here in the Gas industry are threefold.

Firstly is the very thoroughly developed, socialised, and agreed use of the 'aseXML' data description language, and the success the various participants have had in understanding and integrating the use of this language/schema with infrastructure in their existing application layer.

Secondly the adoption of ebXML ebMS1.0 for the messaging infrastucture. Participants were able to deploy disparate COTS systems, all needing some further development, but nonetheless leveraging the extensive efforts of the ebXML development with great success.

Thirdly the system Architecture and Specifications which intergrated and formalised the relationship between the application layer and the messaging layer, and, rigidly defined the actual usage of ebMS1.0 in unequivocal terms, defining the parameters for presenting a gateway to this system in a manner that allows for a definitive certification process. 

This system uses only the lowest tier of the ebXML 'stack', and was I to begin the architecture process again, the system would be substantially different I am sure. The use of ebXML would be more deeply integrated into the business process rather than being more or less 'clipped on' as it is here.

One outstanding problem in our system is the differing throughput capabilities and requirements of participant gateways. This is causing some headaches in operation, a gateway that is swamped with traffic and thus failing, causes substantial traffic backlogs in all other systems and perversely has the effect of increasing the load on that gateway - not unlike the problems experienced when a network link begins to thrash because of high usage. Exactly what can be done about this, as a general solution, is not immediately obvious. This is the kind of real world problem that deploying B2B systems, or 'promiscuous computing', will throw up.


Neil Belford

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





******************************************************************
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.
******************************************************************