Re: Cardinality of payload (Was description of Specification Metamode )

[Jim Clark <jdc-icot@lcc.net>]

Team,

Within the ebXML MetaModel there are 3 elements that provide for the transport
of information from one buisness process to a reciprical process. They are:
1) Business Action Message
2) Document Envelope
and
3) Business Document.

A Business Action Message(BAM) is the element which transports a Document
Envelope from one Business Service Interface to another. Eventhough there is a
one to one relationship between a BAM and a Document Envelope, it may require
more than one BAM to transport a DE from one destination (business process) to
another as is exhibited in the multi-role Business Service Interaction patterns.

As in any envelope which has routing instructions, (From address, To address,
carrier preference, receipt certificaition) a Buisness Envelope may carry one or
more Business Documents.

I hope this helps.

Jim




Cory Casanave wrote:

> Karsten,
> Thanks to a lively MM meeting I did not have a chance to raise an issue, one
> that also came up in Tokyo.  I am referring to the cardinality of the
> "payload" relation from "Message" to "Composite Information Entity".  In
> your model you have this as 1..* while I thought it was agreed that it was
> 1.  This question being does a message carry a single composite document or
> multiple composite documents.
>
> If the message carries multiple composite information entities I would make
> the case that it is just another composite.  The things you want to say
> about the "composite message", such as naming of sub-elements, cardinalities
> and security parameters are in every case the same things you want to say
> about the elements of a composite.  In addition, you want to deal with this
> composite message as a "type", you want to store it, log it, transform it,
> reuse it, bind to it...  This fits with the internet computing paradigm of
> document interchange and the power of this paradigm is that everything
> exchanged is a document.  If message is just another composite why do you
> need it?
>
> You do need a way to say that a document is exchanged as part of a
> commercial transaction - this is what the message should be for.
>
> If on the other hand we change to a message exchange paradigm it becomes the
> message type, not the document type that drives the system and this message
> type is not reusable, named or generally available for processing  like we
> would process a document type (I.E. storing and manipulating in a log).  So
> we have introduced another typing system and all the inherent overhead for
> supporting another typing system.  I can't think of any advantages of this
> new typing system that could not be handled with composite information
> entity.
>
> The alternative approach would be to have message inherit from composite
> information entity, suggesting that is a special kind of composite.  But,
> because of the relations to commercial transaction this would make it a
> single use type - something that should be avoided.
>
> All of this does not imply that the underlying technology may not want some
> kind of envelope, but I don't think we want to model that at the this level.
> In addition we want the technology to be able to send non-XML data that may
> be referenced by the document (I.E. pictures of people in the document), but
> this should also be part of the technology binding.
>
> So, this is a long winded way of saying that the cardinality of the payload
> relation should be "1" and composite messages should be modeled as a
> composite information entity.  I have no idea if this is an emotional issue
> with anyone or just an oversight.  If anyone has thoughts perhaps we should
> get them out so this can be resolved next week.
>
> Cory
>
> > -----Original Message-----
> > From: Karsten Riemer [SMTP:Karsten.Riemer@East.Sun.COM]
> > Sent: Monday, November 27, 2000 11:14 AM
> > To:   ebxml-bp@lists.ebxml.org
> > Cc:   cory-c@dataaccess.com
> > Subject:      description of Specification Metamodel
> >
> > Hi,
> > Tomorrow we will have our weekly metamodel meeting.
> >
> > The weekly BP/CC metamodel meeting is scheduled for 28 Nov. at 9 am PST,
> > 12 pm
> > EST.
> >
> > To access the call, dial 888-699-0348 domestically and +1 732-336-6000
> > internationally, with  a PIN of 4894#.
> >
> > Paul, could you please forward this to CC list since my e-mails to that
> > list
> > bounce.
> >
> > Last week I presented the specification metamodel to the metamodel
> > meeting,
> > but not everyone had the handout yet. For this week's meeting I have
> > included
> > the same handout in a more complete description of the metamodel,
> > attached.
> >
> > Last week the following issues were raised:
> > Need for subtype of role into agent and service.
> > Need for specification of timing/security on both halves of a commercial
> > transaction. Need for re-use of core process constructs.
> >
> > The last of these issues are addressed in the attached. The first two will
> > be
> > addressed after more discussion tomorrow. After tomorrow's meeting I will
> > create an issues list to keep track of all all of this is we move toward a
> > submission to QR end of December.
> >
> > Also discussed last week was the need for new names for the views of the
> > metamodel. In the attached document I am using the word "Analysis
> > Metamodel"
> > in place of the word "Methodology Metamodel", this seems a little better,
> > but
> > I am open to further suggestions.
> >
> > thanks,
> > -karsten << File: Word.Document.8 >>
begin:vcard 
n:Clark;James
tel;cell:936.524.4424
tel;work:936.264.3366
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:jdc-icot@lcc.net
fn:James Clark
end:vcard