RE: [ebxml-dev] from making fun about the complexity of Web Services Sta

["David RR Webber \(XML\)" <david@drrw.info>]

Does anyone know about the pilots that Oracle are running with Medicare?

 

This is a monster system that pays 30% of US healthcare costs = $450 BILLION annually.

 

Right now its all running on EDI and mainframes.

 

The recommend to Congress is due next year for the new technology architecture.

 

Since Oracle has support for ebMS v1 and ebMS v2 in their product - its a natural fit

to do what Norway has already done for their NIA and prescription drugs - and

use ebMS architecture.

 

Also the new ebBP BPSS v2.0.4 can do an excellent job of documenting the business

processes.

 

I suspect that Oracle are right now trying to do all this with a hack together band-aid

of BPEL and WS* and EDI to XML transformers...

 

We should at least have the ebXML + CPA + Registry and open source as an option

in the solution stack...

 

Anyone know any more about what is happening over in Baltimore and the three

pilots Oracle are running?

 

DW

"The way to be is to do" - Confucius (551-472 B.C.)

-------- Original Message --------
Subject: [ebxml-dev] from making fun about the complexity of Web
Services Standards (SOAP/WSDL) to more ebXML education
From: Sacha Schlegel <sacha@schlegel.li>
Date: Mon, November 20, 2006 4:54 am
To: ebxml-dev <ebxml-dev@lists.ebxml.org>

Dear ebXML community

Reading the blog that makes fun of SOAP/WSDL at
http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/ caused me to write to the ebXML community.

The longer the more I see the real value of the ebXML architecture for
B2B setups. The ebXML architecture with collaborative business
processes, business documents (such as UBL via Core Components),
registry, collaboration agreements and messaging looks very very solid
and simple enough. At this place I would like to thank all the people
who have been working on ebXML version 1.0 and later.

Another thought I had the other day (coming back from the 1st UBL
conference) was the following:

For some time I was thinking that when I chose ebXML business process to
describe the collaborations and then inside the organisations I do have
the private business processes ... one of my questions was how can we
connect the dots between these two types of business processes. Well I
think a very simple solution for the SME's is: we dont have to :) (at
least not on the SME's side). It seems a lot of people want to reach the
SME's (includes the small local companies) and those people do not have
"private business processes and workflows executed electronically in
multiple loosely coupled software systems." (at least not in the year
2006) ... these people may have an finance or accounting system,
wordprocessing, spreadsheets, email and thats it. And the only interface
such an finance/accounting system may provide is "import of an invoice",
"import of a purchase order" etc. These smaller style applications have
all the internal private business processes and for them the sufficient
interfaces are import business documents and probably export business
documents.

So for me it seems that ebXML Business Process is a very good choice for
governments who want to reach the SME's. Clearly defined public
collaborative business processes (and references to business documents)
is all that SME's need right now today. CPA negotiation is then the
right thing in theory how to get the agreements (selection of technical
details like certificates, transport protocol, ports etc) between two
parties ... but we need a more practical implementation of this part ...
but once we have the CPA's we truly and simply import the CPA in the
ebXML messaging system at both ends and both are ready to execute B2B.
Maybe this ebXML business process, CPA and messaging system is
integrated into such an financial or accounting system.

Coming back from the 1st UBL conference I think one thing we, the ebXML
community, have done badly is to help our peer colleges in UBL to show
them that ebXML is a sound solution for UBL based infrastructures. So
one of our goals now must be to help UBL end users and UBL customers to
implement their infrastructure to exchange their beloved UBL documents.

And while I am at it ... thanks to the interoperability focused people
that we have 4+ plus years of interoperable ebXML messaging solutions
(and that includes combinations of reliable, secure and asynchronous
messaging setups).

Kind regards

Sacha