Subject: Re: There already is a separate Meta model!
Cory, 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. Regards, Marth ************************************************************************************* 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>, jamesc@edifecs.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. This 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 drive the execution engine. What we are in danger of, by our continued thrashing, 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 firm mapping down to such an execution model - lets not loose this advantage with 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 another. 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 have 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 Regards, Cory Casanave
Powered by
eList eXpress LLC