RE: updated metamodel issues list

[Martin W Sachs <mwsachs@us.ibm.com>]

Karsten,

I agree that we need to keep it simple and get something out that works.
However, I am a bit puzzled by your statement that "that they will start by
concentrating on just one business transaction. "  Today, OBI has at least
two business transactions (PO Request and Unsolicited PO).  I believe that
cXML and some RosettaNet PIPs also have more than one each.

Regards,
Marty



*************************************************************************************

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
*************************************************************************************



Karsten Riemer <Karsten.Riemer@East.Sun.COM> on 12/21/2000 10:13:21 AM

Please respond to Karsten Riemer <Karsten.Riemer@East.Sun.COM>

To:   "Hayes, Brian" <Brian.Hayes@Commerceone.com>
cc:   "ebXML-BP (E-mail)" <ebxml-bp@lists.ebxml.org>
Subject:  RE: updated metamodel issues list



Brian,
I am not sure if I understand you syntax correctly, but I think that we are
in
full agreement on that the world is going to embrace the collaboratio model
in
 stages, and that they will start by concentrating on just one business
transaction. I also agree that it would be useful to say something about
under
which circumstances such a business transaction is able to start.

But you don't need the states and transitions explicitly associated with
the
requestingActivity in order to do that. Just have a start state associated
with the transaction. A transaction ALWAYS starts with a
requestingActivity,
and therefore the start state of the transaction IS the start state for the
requestingActivity>

What I don't want to see is additional flexibility in how to transition
from
and to the requesting activity, because then the whole carefully built
semantics of the business transaction (a.k.a. Commercial Transaction) is
undermined. Don't do it. The Commercial Transaction semantics is the
absolute
cornerstone of this whole architecture. Changing it opens up a lot of new
discussions we cannot afford to have right now.

-karsten

     After having a bit of time to review the decision to remove the
>Transition related elements of the RequestingBusnessActivity (under
>BusinessTransaction), I think they need to be put back into the
>Specification model.  My belief in this is further strengthened since the
>target audience for the Specification model is a Business Process Analyst.
>
>     The upper part of the model concerns itself with business
>collaborations.  If the analyst is using a UML tool like Rose, I expect to
>see this part of the model (or most of it) represented by an UML activity
>diagram.
>   In the example of procurement management covering things like order
>creation, order change, and order cancel, the activity diagram and thus
the
>Specification model instance might describes things like (i may not be
using
>the correct naming conventions):
>+ StartState-->[OrderCreation:BusinessTransactionActivity]
>+
>[OrderCreation:BusinessTransactionActivity]-[Order.Accepted:Guard]
->[Synchro
>nization]
>+
>[Synchronization]->[OrderChange:BusinesTransactionActivity]
->[Synchronizatio
>n]
>+
>[Synchronization]->[OrderCancel:BusinesTransactionActivity]
->[Synchronizatio
>n]
>+ [Synchronization]-[Order.Canceled:Guard]->Success
>etc.
>
>     The lower part of the mode concerns itself with business
transactions.
>If using UML diagrams, I expecct to see this part of the model represented
>by an UML activity diagram.  Business transactions can be [re]used by
>different BusinessTransactionActivity(s).  The business transactions are
not
>explicitly concerned with their transition relationships to other business
>transactions for a number of reasons including a) this already covered in
>the upper part of the model (the business collaboratio (business
transaction
>activity) activity diagram) b) in general, it will be difficult to predict
>what other business transactions a business transaction might be
associated
>with in a greater business collaboration.
>     Continuing with the above example, I expect the business transaction
>activity diagram for the order creation business transaction
>([CreateOrder:BusinessTransaction]) to describe/define things like:
>+ StartState
>-[TRANSACTION=CREATE:Gaurd]->[CreatePurchaseOrder:BusinessTransaction]
>+
>[CreatePurchaseOrder:RequestingBusienssActivity]+[Buyer:AuthorizingRole]
->[P
>rocessPurchaseOrder:RespondingBusinessActivity]+[Supplier:AuthorizingRole]
>+ [CreatePurchaseOrder:RequestingBusienssActivity]-[FAILED:Gaurd]->Failure
>
>     My guess is that e-business solutions will likely implement the
ability
>to drive business service instances using an XML or other representation
of
>the lower part of the model (business transaction) before implenting
>software that is driven off of the XML representation of the upper part of
>the model (business collaborations).  And while it can be stated that
>companies are developing tools and software frameworks for both
>implementations, people will be more comfortable with first implementing
the
>business transaction XML instance.  It's the natural transition from only
>having the ability to implementing documents schemas/definitions (EDI).
>Furthermore, the business transaction level represents the
>basic/component-level business process.  IMHO, it is more important to
ebXML
>and the rest of the world that we have the ability to represent business
>processes over understanding how to represent a collaboration of business
>processes.
>
>Respectfully,
>Brian Hayes
>
>> -----Original Message-----
>> From: Cory Casanave [mailto:cory-c@dataaccess.com]
>> Sent: Wednesday, December 20, 2000 10:15 AM
>> To: Karsten Riemer; ebxml-bp@lists.ebxml.org;
>> ebxml-core@lists.ebxml.org
>> Subject: RE: updated metamodel issues list
>>
>>
>> Updated model after Meta model meeting.  Version is now 0.81
>> 1.     12/20/00 Meta Model Meeting
>> 2.     Changed "Activity" to "Business Activity"
>> 3.     Changed "State" to "Business State"
>>  <<ebXmlSpec081.zip>>
>>
>> > -----Original Message-----
>> > From:     Karsten Riemer [SMTP:Karsten.Riemer@East.Sun.COM]
>> > Sent:     Tuesday, December 19, 2000 6:07 PM
>> > To:  ebxml-bp@lists.ebxml.org; ebxml-core@lists.ebxml.org
>> > Subject:  updated metamodel issues list
>> >
>> > In the metamodel meeting today we resolved lots of issues.
>> > Attached is the new issues list.
>> > We are on target, although a very tight target, for
>> submitting to QR all
>> > of
>> > the infrastructure release deliverables from the metamodel
>> team by 12/22
>> > (except that we likely will defer the production rules to closer to
>> > 1/14/2001)
>> >
>> > Attendees today: Jim Clark, Cory Casanave, Jamie Clark,
>> Bill McCarthy,
>> > Paul
>> > Levine, Karsten Riemer
>> >
>> >
>> > We will have daily meetings 12 noon the rest of this week,
>> hope to have
>> > virtual champagne in the Friday meeting.
>> >
>> > Tomorrows agenda:
>> >
>> > 1.  Resolve differences in modeling collaboration nesting
>> (recursion)
>> > 2.  Resolve differences in modeling transitions
>> > 3.  Resolve differences in modeling binding documents to
>> success/failure
>> > 4.  Finalize placement of timing/security parameters
>> >
>> > 5. Go over results from London context meeting, decide how
>> much of that to
>> > incorporate in infrastructure metamodel/schema.
>> >
>> > -karsten << File: WinZip >>
>>