RE: Initial correlation of ebXML Transport requirements with CORBA services

[David Burdett <david.burdett@commerceone.com>]

Henry

Apologies in the delay in responding but I've been "snowed under" recently.
Anyway I now have some bandwidth to respond to the recent emails.

I disagree when you say ... "I'd rather favor the API model -- with the
protocol model you have to do an API eventually anyway or you have
portability problems" ...

I really don't think that one API will fit all the requirements that we
might have to support when transporting XML documents. For example suppose
you want to send someone a purchase order. What might happen when it is
received could be one of the following ...
1. It's processed by an integrated "on-line" e-commerce system that produces
an immediate reply
2. It's sent to an HTTP server that then passes it to a legacy ERP or
accounting system which processes it in batch overnight. It then generates a
response that is converted to an XML format using a style sheet before it is
sent by email.
3. It's printed immediately using an XML style sheet. Later someone uses
information on the printed sheet to go on-line to a hosted system to
generate the response.
4. It's forwarded to someone's wireless equipped PDA (because it's a very
important PO) and the response is telephoned in to someone who enters the
using a GUI as part of a local client-server application.

If you think how you want to handle the above then:
1. This will benefit from an API to immediately access the data and generate
a response
2. Will probably simply route the document to another sytstem based on it's
content without processing it
3. This will route it to a style sheet processor that renders particular
types of document and prints them
4. The PO is routed to wireless based server to forward the message

Now only the first one (the integrated system) will really benefit from
having an API since the response is generated in real time. The others don't
need them. They are all, though, realistic scenarios that describe how
businesses might want to process documents that they receive. BUT does the
sender care what they did internally. Will the sender care what API was used
to process their Purchase Order. I don't think so.

If you are a business and want to swap XML documents for e-commerce all you
are really concerned about is that if you send one document then you get
back the type of document you expect in the sequence you expect - what the
other organization had to do internally to generate the correct response is
irrelevant as long as the response is in the correct format and comes within
the timeframes you expect.

This doesn't meant that APIs are not **very** useful, it's just that I don't
think that they should be the "master" definition of how to do transport,
routing and packaging.

I would suggest that we can probably get the best of both worlds if:
1. We support a data/protocol based approach to the master definition and
then ...
2. Define an API that works with it so that those organizations that want to
use an API based approach can use one.

David


-----Original Message-----
From: Henry Lowe [mailto:hlowe@omg.org]
Sent: Wednesday, January 05, 2000 11:41 AM
To: ebXML-Transport@lists.oasis-open.org
Cc: henry@emerald.omg.org
Subject: RE: Initial correlation of ebXML Transport requirements with
CORBA services


Oops.  In sending this to Kay to pass on to Rik, I forgot to 
include the main transport list.  -- Henry
--------------------------------------------------
Hi Rik,

Just recovering from the holidays and am a bit behind.

To answer your question below, not really, unless I didn't 
understand some of the implications of the responses received 
up to this message from you.  Also, I have a question on your 
2-liner below.

In you statement "just allow them [objects] to be done in xml 
descriptions", do you mean do object invocations in XML syntax 
as is done in SOAP?  I would certainly agree with you that we 
should do objects, but if you want to do object invocations in 
XML syntax, you're going to have to respecify all the stuff that 
CORBA and other OO protocols already do in XML (probably not 
to hard but certainly not a small task).  Also, the messages 
would be rather bigger than those of CORBA or DCE (perhaps not 
a problem for those with bandwidth to spare, but for folk still
using a modem, that might be a problem).

While it won't (or shouldn't) affect the Requirements document, 
I don't think the data/protocol model which was suggested in 
reply to the orginal question, is the best way to go.  I'd rather 
favor the API model -- with the protocol model you have to do 
an API eventually anyway or you have portability problems (the 
IETF, which is really pretty protocol based, seems to be doing 
more and more APIs these days). 

I do agree with David, that we want to get the Requirements done 
first and go from there.  But I think we may want to get input 
from the other WGs on what sort of model they are expecting 
(as I heard in my brief visit with the Architecture WG in San 
Jose, do they want objects in the CORBA and COM sense so they 
can have componentized software?).

Slightly longish answer to a short question.

Best regards,
Henry
----------------------------------------------------------
At 02:55 PM 12/15/1999 -0600, Rik Drummond wrote:
>henry, did you get your question answered?  I think we should do
objects....
>just allow them to be done in xml descriptions.... your thoughts?
>
>-----Original Message-----
>From: Henry Lowe [mailto:hlowe@omg.org]
>Sent: Tuesday, December 14, 1999 9:35 AM
>To: Rik Drummond
>Cc: srh@us.ibm.com; Henry Lowe; ebXML-Transport@lists.oasis-open.org;
>andrew@emerald.omg.org; soley@emerald.omg.org
>Subject: RE: Initial correlation of ebXML Transport requirements with
>CORBA services
>
>
>Hi all,
>
>This raises an interesting question -- what model does XML
>require?  In San Jose, before I joined the Packaging & Transport
>group, I spent 10-15 minutes with the Architecture folk.  They
>were talking in terms of objects and components.  I just carried
>this over to the P&T discussion as a given, i.e., ebXML wants an
>OO transport.  I think this makes sense (all the usual arguments
>for OO and componenets), but Rik's question makes me pause and
>ask if this is a valid assumption.  Comments?
>
>Best regards,
>Henry
>-------------------------------------
>At 02:36 PM 12/13/1999 -0600, Rik Drummond wrote:
>>so can someone tell us what the functionality of these models.. so that we
>>can do our due diligence?
>>
>>-----Original Message-----
>>From: srh@us.ibm.com [mailto:srh@us.ibm.com]
>>Sent: Friday, December 10, 1999 12:25 PM
>>To: Henry Lowe
>>Cc: Rik Drummond; Henry Lowe; ebXML-Transport@lists.oasis-open.org;
>>henry@emerald.omg.org; andrew@emerald.omg.org; soley@emerald.omg.org
>>Subject: RE: Initial correlation of ebXML Transport requirements with
>>CORBA services
>>
>>
>>
>>
>>Henry,
>>Well put.
>>
>>Food 4 thought:
>>
>>I would add to your comments that in the end, commercial transactions for
>>eMarkets
>>over the internet via XML will require functionality that is similar to
>>almost all of the
>>already-thought-out CORBA Services, and Java Enterprise semantics; without
>>an ORB.
>>If you buy into this thought, the intellect of these problems has already
>>been spent,
>>and a logical approach to some of this may be to start with these current
>>programming models
>>and collaboration patterns mapped to an ORBless environment.
>>
>>Hmmmmm,
>>
>>Scott R. Hinkelman
>>IBM Austin
>>Architecture and Development, Industry XML/Java Standards
>>Office: 512-823-8097 TL793-8097
>>Home: 512-930-5675
>>Cell: 512-940-0519
>>srh@us.ibm.com
>>Fax: 512-838-1074
>>
>>
>>
>>Henry Lowe <hlowe@omg.org> on 12/10/99 11:40:38 AM
>>
>>To:   "Rik Drummond" <drummond@onramp.net>
>>cc:   "Henry Lowe" <hlowe@omg.org>, ebXML-Transport@lists.oasis-open.org,
>>      henry@emerald.omg.org, andrew@emerald.omg.org, soley@emerald.omg.org
>>Subject:  RE: Initial correlation of ebXML Transport requirements with
>>      CORBA services
>>
>>
>>
>>
>>Hi Rik,
>>
>>>Henry, could you give us some better background on corba and xml. will
you
>>>be converting corba to an xml based mechanism? Best regards, rik
>>
>>No, there are no plans to convert CCORBA to an XML based mechanism,
>>but there is already an active move to make it easier to use CORBA
>>to support XML -- you could do it with what's in CORBA products on
>>the market today treating XML as an octet string or character string.
>>However, the new work, the RFP is called XML/value, will do a better
>>job of it.
>>
>>This is a major reason I'm participating in the Transport & Packing
>>group -- XML needs a transport which provides security (encryption,
>>authentication, non-repudiation and all that good stuff) and also
>>a transport which provides the two phase commit semantics for
>>once-and-onnce-only (which will probably be VERY important to
>>e-commerce as I don't think banks will be too keen on transferring
>>millions of dollars/euros if there is a chance the transport is
>>going to lose or possible replicate the transfer ;-).  CORBA has it
>>now, our specs are open (indeed, we're submitting them to ISO
>>using their PAS process), and the specs are implemented in
>>commercially supported products which are on the market.
>>
>>Information on XML/value is on our web site at
>>http://www.omg.org/techprocess/meetings/schedule/XML_Value_RFP.html
>>As I said, it's new and the list of companies which have turned in
>>a Letter of Intent to submit is on this page (there is definite
>>interest).  We haven't had any submissions yet, but that's not too
>>surprising as the deadline hasn't passed.  For those interested in
>>more detail, there's a link to the RFP itself.
>>
>>On the OMG home page, there is also a pointer to some more info on
>>XML as it relates to OMG -- http://www.omg.org/xml/
>>
>>There are two other areas in which we currently use XML:
>>1. XMI which is an XML based means for texhanging UML models and
>>   other meta data, and
>>2. in our component model where descriptors of components are in
>>   XML.
>>However, this isn't the subject of your question.
>>
>>Hope this helps without being too long.  Glad to answer any further
>>questions.  Sorry about preaching two phase commit transaction
>>processing, but I'm a true believer.  It probably won't be the
>>last time I'll harangue the group on this :-)
>>
>>Best regards,
>>Henry
>>-------------------------------------
>>At 08:47 AM 12/10/1999 -0600, Rik Drummond wrote:
>>>Henry, could you give us some better background on corba and xml. will
you
>>>be converting corba to an xml based mechanism? Best regards, rik
>>>
>>>-----Original Message-----
>>>From: owner-ebxml-transport@lists.oasis-open.org
>>>[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of Henry
>>>Lowe
>>>Sent: Tuesday, November 30, 1999 12:50 PM
>>>To: ebXML-Transport@lists.oasis-open.org
>>>Cc: henry@emerald.omg.org
>>>Subject: Initial correlation of ebXML Transport requirements with CORBA
>>>services
>>>
>>>
>>>Hi,
>>>
>>>As a possible basis for discussion, attached is a first pass
>>>at correlating the ebXML transport requirements from San Jose
>>>with CORBA services.  There's still work to be done in that
>>>a) I'm not sure I understand all of the requirements, and
>>>b) I need some help from some of the OMG members to ensure
>>>   I get it right.
>>>
>>>But, it is a start and perhaps we can use it on the ConCall to
>>>clarify some of (a) and chat about some of (b).
>>>
>>>Has a time and number been fixed for the Call?  I have the
>>>feeling I've been missing some in-coming e-mail (of course,
>>>that's one of those things that's hard to pin down ;-)
>>>
>>>Best regards,
>>>Henry
>>>
>>
>>
>>
>>
>>
>
>