RE: Definitions and Requirements drafts

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

Tim

See just a few comments marked with @@

David

-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@tedis.com.au]
Sent: Sunday, January 30, 2000 11:40 PM
To: David Burdett
Cc: Ebxml Transport
Subject: Re: Definitions and Requirements drafts


unfortunately, Florida at  the other end of the world from me (literally),
so i
will be unable to attend.

still, i thank you for your comments and it has helped me clarify my
thoughts
(somewhat).

it is important that these ground rules are understood if we are to
rationalise
the ebXML approach with existing EDI applications.


David Burdett wrote:

> Tim
>
> See my comments below marked with ##
>
> David
>
> -----Original Message-----
> From: Tim McGrath [mailto:tmcgrath@tedis.com.au]
> Sent: Monday, January 24, 2000 8:34 PM
> To: Rik Drummond
> Cc: Ebxml Transport
> Subject: Definitions and Requirements drafts
>

>  The comparitive EDIFACT structure for a 'Document' would be something
like:
>
> 'Interchange' (a header a bit like a META tag) within which are:
> ...Functional Group (cf group of same 'Document' types)
> ......Message (cf  'Document')
> ......Message (cf  'Document')
> ......Message (cf  'Document')
> ...Functional Group (cf group of same 'Document' types)
> ......Message (cf  'Document')
> ......Message (cf  'Document')
>
> Is there value is having this additional 'group' structure - wouldn't  it
be
> useful for the definition and management of 'Services and Transactions'?
>
> ## Tim I'm not sure I completely get the point you're trying to make here.
I
> **think** that we have different understanding of the smantics of various
> things. For example I think you're suggesting that a Message is closely
> related to the physical transport used, e.g. HTTP, where as I tend to
think
> that a message is just a lump of data that needs to be transported between
> two points that is then wrapped in whatever data the chosen transport
> protocol needs. I suggest we try and clarify each other's understanding at
> the meeting in Orlando next week.##
>
>

yes i think you have clarified this.  i agree with you that the 'Message'
should
not be transport layer dependant.

In which case it is closely akin to an "Interchange".

This concept of an 'Interchange' grew from the idea that one data file would
equal one data transfer.  However this is not often the case. For example it
is
now common practice to use deliver multiple 'Interchanges' as seperate
attachments to one SMTP message.

>
> 1.2 A Document
>
>
> 1.2.2 Message
>
> Message <-> Interchange
>
> A Message is data that is sent from one Party to another. A Message
consists
> of information such as:
>
> 1) a Message Envelope that indicates who sent, who should receive and the
> reason for sending the
>
> message
>
> 2) Message Routing Information, that indicates how the message was
delivered
>
> 3) zero or more Digital Signatures to bind the data in the message, or
> elsewhere, together, and
>
> 4) zero or more Documents which is the business data that actually needs
to
> be sent
>
> All the data in a Message is contained within a Message Wrapper.
>
> Examples of a Message include:
>
> 1) a Purchase Order that is sent by a buyer to a supplier
>
> 2) an Invoice that is sent by the supplier back to the buyer
>
> 3) a request to make a payment of $50 sent to a Credit Card acquirer
>
> 4) the authorization received from a Credit Card acquirer as a result of
> making a payment
>
> 5) Status Data indicating the success or failure of a Service
>
> The 'Message' wrapper should only concern itself with transport layer
data.
>
> ## I'm not sure I agree with you. I think that in a business sense, it
will
> sometimes be important to have available information in a transport
protocol
> independent way that defines where the message came from and where it's
> going to. This would have a lot in common with stuff that you would also
see
> in a transport-protocol-dependent message wrapper. The key issue is that
you
> actually might want to digitally sign the "wrapper" information and if
you,
> at some point, have to change the wrapper because you are using a
different
> transport protocol, then you would break the original signature. So for
> example, if you started sending a message using one transport protocol,
you
> would have to use that same protocol all the way through the intermediate
> servers it passed through if you didn't want to break the signature. On
the
> other hand if you have a message wrapper that is transport protocol
> independent, then you can digitally sign it and transport over whatever
> transport protocol you want to.##
>

i agree. the difference between the 'transport-protocol-dependent message
wrapper' and the 'transport-protocol-independent ebXML message wrapper'
would be
that the latter has information content agreed (even if by default) to the
trading partners (parties) involved.

For example, Company/Service/Application/Standards identifiers, Digital
Signatures, control references, etc..

The 'transport-protocol-dependent message wrapper' would have things like
the
HTTP/SMTP Header information.

whilst there may be a relationship  between these two i suspect not many
values
actually do overlap.

For example, in the SMTP example above (deliver multiple 'Messages' as
seperate
attachments to one SMTP message) the SMTP header would not have much overlap
with the individual Message wrappers. This 'mailbag' concept is popular with
Application Servers and Value Added Networks, where thay act as clearing
houses
for Messages.

- and so, where does this leave the second item ( Message Routing
Information)?
What would be in there?

@@I think that there are two separate things here.

Firstly there is a "message" or what you call an interchange, that contains
one or more bits of data where **all the data is related** i.e. you have to
process all the data together otherwise the you will not get the business
result you want.

Secondly there is the idea of a "mailbag" or message batch which contains
multiple "messages" inside one outer wrapper that have been grouped together
for convenience as they all need to be sent to the same destination at the
same time.

Message Routing Information would hold data about how the message should be
(or was) physically delivered. For example in the real world you have a
choice between the local government run postal service and courier firms
such as FedEx. These organizations need to keep information about how the
message got from it's starting point to it's destination. This can sometimes
be important in case there are disputes over delivery. So really the Message
Routing Information is something that should really go on the "mailbag". It
needs to be separate from the message because, you might use different
messages for delivering documents and you really want to leave this up to
the delivery system to determine than specify it in the business part of the
message.

So if you're sending a single "message" then each message will need some
message routing information. However if all the messages are in a "mailbag"
then each individual message would need to inherit the message routing
information from the mailbag.

However one difference that I think the low costs associated with the
Internet will bring is a move towards sending single messages in near
real-time rather than mailbags full of messages as connection to the
internet will be continuous.

I agree though that we need to be able to support both individual and
batched delivery of messages.
@@


>
> Aren't these examples of Documents?  A 'Message' could carry several of
> these.
>
>
> ## On re-reading the above I think I can see where you're coming from. The
> point I was trying to make was that a Purchase Order is, for example, a
> document, it becomes a "message" only when it is being sent from one place
> to another.##
>

Ok  - then maybe it becomes 'part of a message'

>
> 1.2.7 Request Message
>
> A Request Message is a Message sent from one Party to a second Party with
> the intent that the second
>
> Party act upon the data in the Request Message by carrying out a Service.
>
> 1.2.8 Response Message
>
> A Response Message is a Message that is generated by the Party that
received
> a Request Message. It is
>
> produced as a result of carrying out the requested Service. It is the last
> Message in a Document
>
> Exchange unless the Message contains errors.
>
> Response Messages are sent back to the sender of the Request Message.
>
> Shouldn't Service Requests operate at the Document level?
>
> Therefore aren't these 'Request Document' and 'Response Document'?
>
> ## I think this reflects our difference in understanding in what is meant
by
> a Message compared with a document as described earlier.##
>

my conern is that i think/thought a Message could hold more than one
Document.
Can we allow a Message to carry a Purchase Order and a Request for Quote
together?

@@Yes. But only if they're in a "mailbag" as you need to know that, once
they've reached their destination and if they really are separate, they need
to be split up.@@
>
> I guess my general point is that I beleive a 'Message' and its wrapper
> should be objects dealing with the transport layer issues and that
> 'Documents' should carry the application information.
>
>
> ## I'd welcome an opportunity to clarify the definitions to reach a shared
> understanding. Perhaps we can do this during the meeting in Orlando. Will
> you be there?##
>

sorry, only if i walked :-)


--
regards
tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142