Re: Conf. Call follow-up

[dick@8760.com]

Gord,

I actually think we're in violent agreement, perhaps it's semantics. I'll use a
scenario to emphasize the point.

Imagine you're a large electric company with hundreds of trading partners which
you exchange several different types of transactions (invoices, purchase orders,
payments). Suppose you have to send a group of payments and purchase orders to a
trading partner, it sure would be efficient if you could "batch" these
transactions into a single payload and deliver the "batch" as one package. You
build a payload containing all  the transactions for a trading partner into a
"batch" and place it into an ebXML wrapper complete with headers and send to the
trading partner. If the trading partner has constructed an efficient system, the
payload (batch) would be instantaneously processed  using the internal systems
responsible for processing payments and purchase orders. Depending on the
"processing mode" (synchronous, asynchronous), an "application level" response
is sent indicating success or failure of the transactions contained in the
"batch". For this case I'll assume synchronous processing (RPC like), the entire
process including data exchange/process/acknowledgement occurs in seconds
(depending on size of payload) over a single socket.

The term batch in the above scenario refers to the packaging of objects as
opposed to "batch mode processing", which is where I believe the confusion lies.
Believe me, I'm not advocating batch mode processing.

Do we agree?

Dick Brooks
http://www.8760.com/

----- Original Message -----
From: Jenkins Gordon <gjenkins@singnet.com.sg>
To: Dick Brooks <dick@8760.com>; David Burdett <david.burdett@commerceone.com>;
ebXML Transport (E-mail) <ebXML-Transport@lists.oasis-open.org>
Sent: Wednesday, March 08, 2000 10:40 PM
Subject: Re: Conf. Call follow-up


> I guess I was not clear enough - not talking about
> snip
>  "synchronous, asynchronous, acknowledged,
>  unacknowledged, signed, unsigned, encrypted, unencrypted, etc. etc."
>
> Point was - the old economy, the EDI way , the VAN way - was packet or
> batch.
>
> The new way is online or instantaneous
>
> Lets give the implementers - of which I am one - something they can use.
>
> Gordon Jenkins
> Standard Chartered Bank C&IB
> Senior Product Manager: Electronic Commerce
> 51 Bras Basah
> SINGAPORE 189554
>
> Email : gjenkins@singnet.com.sg
>
> Tel :65-331 5095
> ----- Original Message -----
> From: Dick Brooks <dick@8760.com>
> To: Jenkins Gordon <gjenkins@singnet.com.sg>; David Burdett
> <david.burdett@commerceone.com>; ebXML Transport (E-mail)
> <ebXML-Transport@lists.oasis-open.org>
> Sent: Thursday, March 09, 2000 8:41 AM
> Subject: RE: Conf. Call follow-up
>
>
> > Gord,
> >
> > I believe the ebXML MR&T solution  should be flexible enough to support
> > batch, interactive, simplex, synchronous, asynchronous, acknowledged,
> > unacknowledged, signed, unsigned, encrypted, unencrypted, etc. etc.
> >
> > Let the implementers decide what's best for them.
> >
> > Dick Brooks
> > http://www.8760.com/
> >
> >
> > -----Original Message-----
> > From: Jenkins Gordon [mailto:gjenkins@singnet.com.sg]
> > Sent: Wednesday, March 08, 2000 5:14 PM
> > To: Dick Brooks; David Burdett; ebXML Transport (E-mail)
> > Subject: Re: Conf. Call follow-up
> >
> >
> > With respect, is not  the Model we must be thinking about for the future
> > NOT be " batch "or "packet" thinking -
> > business on the internet will demand "on line"
> > -meaning instantaneous.
> > Gord
> > Gordon Jenkins
> > Standard Chartered Bank C&IB
> > Senior Product Manager: Electronic Commerce
> > 51 Bras Basah
> > SINGAPORE 189554
> >
> > Email : gjenkins@singnet.com.sg
> >
> > Tel :65-331 5095
> > ----- Original Message -----
> > From: Dick Brooks <dick@8760.com>
> > To: David Burdett <david.burdett@commerceone.com>; ebXML Transport
> (E-mail)
> > <ebXML-Transport@lists.oasis-open.org>
> > Sent: Thursday, March 09, 2000 5:53 AM
> > Subject: RE: Conf. Call follow-up
> >
> >
> > > John,
> > >
> > > I think the model your're thinking of is the current VAN model where
> > > multiple "transactions" are contained in a single interchange. I believe
> > the
> > > ebXML solution must be flexible enough to let parties "batch"
> transactions
> > > into a single payload or operate in a "Request/Response" mode. In the
> case
> > > of a batch transaction the payload could contain the same EDI file (X12,
> > > EDIFACT) that would be sent to a VAN.
> > >
> > > Dick Brooks
> > > http://www.8760.com
> > >
> > > -----Original Message-----
> > > From: owner-ebxml-transport@lists.oasis-open.org
> > > [mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of David
> > > Burdett
> > > Sent: Monday, March 06, 2000 11:01 AM
> > > To: ebXML Transport (E-mail)
> > > Subject: RE: Conf. Call follow-up
> > >
> > >
> > > John
> > >
> > > I agree but ...
> > > 1. What do people think of the probability that current EDI enabled
> > > companies when transitioning to ebXML, will run their web servers so
> that
> > > they can only accept data during a single narrow window. One of the
> major
> > > benefits of going to the web is to shorten the "supply chain cycle", if
> > they
> > > don't "open the window" they will not get this benefit.
> > > 2. Why can't the web server that is accepting the messages simply batch
> up
> > > the messages it receives so that they are made available to existing
> > systems
> > > in the time window it wants?
> > >
> > > Item 1 tells me most companies won't want to do it. Item 2 tells me if
> > they
> > > want to do it they can easily add the functionality themselves. So, I
> > think
> > > we should have a **rule** that a transport wrapper can only have one
> MIME
> > > message. Doing otherwise just adds to the complexity.
> > >
> > > Thoughts?
> > >
> > > David
> > > PS. I've taken John's email address off the list as I'm sure he's fed
> up,
> > > like me of getting multiple copies of the same message.
> > >
> > >
> > > -----Original Message-----
> > > From: john_ibbotson@uk.ibm.com [mailto:john_ibbotson@uk.ibm.com]
> > > Sent: Monday, March 06, 2000 8:51 AM
> > > To: David Burdett
> > > Cc: ebXML Transport (E-mail)
> > > Subject: RE: Conf. Call follow-up
> > >
> > >
> > >
> > >
> > >
> > > David,
> > > The situation I was anticipating was the EDI batching one where a number
> > of
> > > separate messages are assembled are sent in a single envelope. This is
> > > widely used in the EDI community where one partner only accepts messages
> > > during a particular time window.
> > > John
> > >
> > > MQSeries Technical Strategy & Planning,
> > > IBM UK Ltd, Hursley Park,
> > > Winchester, SO21 2JN
> > >
> > > Tel: +44 (0)1962 815188
> > > Fax: +44 (0)1962 816898
> > > Notes Id: John Ibbotson/UK/IBM
> > > email: john_ibbotson@uk.ibm.com
> > >
> > >
> > > David Burdett <david.burdett@commerceone.com> on 03/06/2000 04:35:12 PM
> > >
> > > Please respond to David Burdett <david.burdett@commerceone.com>
> > >
> > > To:   John Ibbotson/UK/IBM@IBMGB, David Burdett
> > >       <david.burdett@commerceone.com>
> > > cc:   "ebXML Transport (E-mail)" <ebXML-Transport@lists.oasis-open.org>
> > > Subject:  RE: Conf. Call follow-up
> > >
> > >
> > >
> > >
> > > John says ...
> > >
> > > >>>I assume we would be able to support multiple MIME envelopes within a
> > > single transport wrapper?<<<
> > >
> > > We can, but I'm not sure we should include this requirement in our work.
> > > The
> > > only reason I can think of doing it is if we want to send multiple
> > > un-related messages at the same time, and I don't see sufficient benefit
> > in
> > > doing this compared with the extra complexity involved. I'm willing to
> be
> > > convinced though.
> > >
> > > >>>Is further nesting necessary or simply being over complex ?<<<
> > >
> > > As far as our work is concerned, I don't think we should "design in" any
> > > extra nesting. However if someone want's to put a complete MIME message
> > (no
> > > matter what it contains) as part of another MIME message in order to
> meet
> > a
> > > specific design requirement, then MIME supports this and they are
> entitled
> > > to do so.
> > >
> > > To my mind, these two requirements both fall the wrong side of the KISS
> > > principle.
> > >
> > > Regards
> > >
> > > David
> > > PS John didn't send the original to the ebxml list, but I'm assuming he
> > > intended to !
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: john_ibbotson@uk.ibm.com [mailto:john_ibbotson@uk.ibm.com]
> > > Sent: Monday, March 06, 2000 1:25 AM
> > > To: David Burdett
> > > Subject: RE: Conf. Call follow-up
> > >
> > >
> > >
> > >
> > >
> > > I like David's view of the message structure since it matches my own. I
> > > assume we would be able to support multiple MIME envelopes within a
> single
> > > transport wrapper ?
> > > Is further nesting necessary or simply being over complex ?
> > > John
> > >
> > > MQSeries Technical Strategy & Planning,
> > > IBM UK Ltd, Hursley Park,
> > > Winchester, SO21 2JN
> > >
> > > Tel: +44 (0)1962 815188
> > > Fax: +44 (0)1962 816898
> > > Notes Id: John Ibbotson/UK/IBM
> > > email: john_ibbotson@uk.ibm.com
> > >
> > >
> > > David Burdett <david.burdett@commerceone.com> on 03/05/2000 12:09:37 AM
> > >
> > > Please respond to David Burdett <david.burdett@commerceone.com>
> > >
> > > To:   "'ian.c.jones@bt.com'" <ian.c.jones@bt.com>,
> > >       ebXML-Transport@lists.oasis-open.org
> > > cc:    (bcc: John Ibbotson/UK/IBM)
> > > Subject:  RE: Conf. Call follow-up
> > >
> > >
> > >
> > >
> > > Ian said ...
> > >
> > > >>>  I also support the idea that we define the header, routing,
> manifest
> > > structure then define how we put this in MIME for both SMTP and HTTP (as
> > > Dick pointed out there are 2 variants), AND a XML wrapped version.  This
> I
> > > believe this is what David was proposing in the XML Messaging
> requirements
> > > paper. i.e. We are transport protocol independent and provide "mappings"
> > to
> > > them if needed.<<<
> > >
> > > This is, I think, not *quite* what I meant. What I envisaged was the
> > > following type of structure:
> > >
> > > Transport Wrapper (e.g. SMTP or HTTP)
> > > |  MIME Envelope Start (or Outer XML Envelope)
> > > |  MIME Envelope Parameters ...
> > > |  MIME (or XML) separator ...
> > > |  |  <MessageHeader>
> > > |  |    ...
> > > |  |  </MessageHeader>
> > > |  MIME (or XML) separator ...
> > > |  |  <MessageRoutingInfo>
> > > |  |    ...
> > > |  |  </MessageRoutingInfo>
> > > |  MIME (or XML) separator ...
> > > |  |  <FirstDoc>
> > > |  |    ...
> > > |  |  </FirstDoc>
> > > |  MIME (or XML) separator ...
> > > |  |  <SecondDoc>
> > > |  |    ...
> > > |  |  </SecondDoc>
> > > |  MIME (or XML) separator ...
> > > |  | etc ...
> > > |  MIME Envelope (end)
> > > Transport Wrapper End
> > >
> > > The point I'm trying to make is that I have always thought of the
> Message
> > > Header as being an XML document containing the types of information we
> > have
> > > been identifying. I did not anticipate the information being held as
> > > name-value pairs in the MIME Envelope Parameters. The main reason for
> this
> > > is if you want to sign the information it contains. You can only sign
> > > information in the parameters (I think) if you sign the complete
> message.
> > > On
> > > the other hand if you sign only the message parts, then you have a
> better
> > > chance of being able to break up the MIME message, throw away the MIME
> > bits
> > > and keep the rest safely stored away on disk. I always tend to think of
> > the
> > > MIME enevelope as just that, an envelope, which can be thrown away once
> > you
> > > opened it.
> > >
> > > Regards
> > >
> > > David
> > >
> > >
> > >
> >
>