RE: updated metamodel issues list

["Hayes, Brian" <Brian.Hayes@Commerceone.com>]

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