Re: updated metamodel issues list

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

Karsten,

I wholly concur with Brian.
When you refer to the adding flexibility, what we have done is remove it. The
initial and terminal states has always been part of a Commerical Transaction. By
removing them, we no longer have a mechanism to specify the Terms and Conditions
of a Commercial Transation within the context of a Commercial transaction itself.
By removing these states, we no longer are able to reflect the full semantics of a
CT. We are in effect changing it.

Hope this helps,
Jim

Karsten Riemer wrote:

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