ebxml-tp message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: Re: There already is a separate Meta model!


I a not sure what you mean by "the TP is already using another Meta model".
If you are referring to the business protocol section of the IBM tpaML
proposal, you are correct although I am not sure that Meta model is the
correct term since what is in each TPA is specific to the business process
being performed although it is hand-crafted.

The internal IBM proof of concept (BPF) has already demonstrated that the
execution engine can perform valuable services for the application layer,
namely performing those functions that are generic to all business
processes such as managing the orchestration and checking for orchestration
errors, assisting with business-level timeouts, and others.

It would be a serious mistake if the ebXML TP specification were unable to
exploit the execution engine in service of the business process.



Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com

Cory Casanave <cory-c@dataaccess.com> on 11/21/2000 02:23:50 PM

To:   Karsten Riemer - Sun IR Development <Karsten.Riemer@east.sun.com>,
cc:   linkage@interaccess.com, ebxml-bp@lists.ebxml.org,
      ebxml-cc@lists.ebxml.org, cory-c@dataaccess.com, alonjon@mega.com
Subject:  There already is a separate Meta model!

I have been watching all the dialog about the need for a specification Meta
model and it's degree of alignment with the collaboration model.  It seems
we are missing an important point - the TP is already using another Meta
model, one not derived or aligned with the collaboration model at all.
model is used to drive the execution engine of the TP layer.

I have strong doubts that the collaboration model will ever be used to
the execution engine.  What we are in danger of, by our continued
is that there will be NO relation between the execution model and business
modeling.  It will be a BIG WIN for EbXml to be able to show business
modeling (which is how I think of the collaboration + REA model) with a
mapping down to such an execution model - lets not loose this advantage
religious wars.

Unless we get our act together the current (TPA) execution model will go
forward as part of the first EbXml release and will be very hard to unroot.
We will be forced to adapt the business semantics to meet the capabilities
of the implementation rather than the other way around.

So, the assertion is that we WILL HAVE an intermediate model, one way or

That it would be far better to cooperate to make this integrate with
business modeling and the execution model.

Discussions of "it is or is not the same model" are useless.

You have at-most a month, after that the technology implementation will
gone to far.

Karstens model is the only base line to proceed from.  If there are missing
semantics, work it out.

If we succeed we will be able to keep a traceable path from business
modeling to execution & compatibility with RosettaNet, CGI,
TMForum, UN/EDFACT, ect

Cory Casanave

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC