Question

[srh@us.ibm.com]

ebXMLers,
I will first appologize for perhaps asking some questions that
 may seem obvious to all you folks involved in BP/CC, as I am just
recently trying to get my head around the BP MM. I am also trying to
position our IBM tpaML with BP MM for where it can help, and have
some questions regarding the general thinking of the group concerning
BP MM and eventual runtime at the TRP level.

Clearly the TRP  will need configuration information in some form for
execution of a business process instance. Current thinking in TRP, and
myself, is that the configuration information could very well be in the
form of an Agreement (TPA). The BP MM indeed currently has this notion,
and would lead to the thinking that an Agreement would be 'generated'
from an instance of the BP.

Another viewpoint after some inital analysis (rough UML conversion of  the
IBM tpaML)
shoews that this does indeed seemspossible but perhaps redundant.
My fundamental question on the
groups thinking on this issue reloves around seperate generation of
an Agreement (currently in the BP MM) from a BP instance, vrs the BP
instance
itself (Step, etc) actually consituting the configuration information for a
specific BP instance.

Further thinking , it seems possible [disregarding the known issues with
loose DTD generation rules] to generate the Schema (or DTD) of
a specific BP (XMI path), and then realize an instance of such BP with a
valid XML document instance, which may itself be, or hold all of,
the configuration information for execution. This would allow
tighter combination of the notions in the BP MM with notions in the
tpaML, and not align to a model of TPA generation in a second step.

Thoughts?

Thanks,
Scott Hinkelman
Senior Software Engineer, SWG IBM Austin
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



Karsten Riemer <Karsten.Riemer@East.Sun.COM>@lists.oasis-open.org on
07/07/2000 04:20:23 PM

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

Sent by:  owner-ebxml-bp@lists.oasis-open.org


To:   ebXML-BP@lists.oasis-open.org
cc:
Subject:  Another set of comments



After my review of ebXML vs. EDOC, and following a discussion with Lisa
Shreve
of Core Components, here is another set of comments (I will use letters
starting at j since that's where I left off in this morning's e-mail -
Marcia,
please include these in official comments list)

j. Need to review the 'maps to' relationship between
BusinessServiceInterface
and BusinessTransaction. Some business services interfaces may not map to
specific business transactions.

k. This issue has been raised previously. There are too many levels in the
process definition, or rather one needs to use only a subset of them. Some
processes might only have a series of business messages, and no way to
neatly
order them into steps or transactions. Some processes might have distinct
InformationExchanges but no distinct transactions. Some messages exchanges
do
relate to  transactions but not on a many-to-1 basis. I don't know what the
solution is but we should talk about how to build a little more flexibility
into the hierarchy, or simplifying the hierarchy.

l. We have BusinessService as 'implementing one side of a business
process'.
But that is also what a partner role does. Could the two be combined
somehow.
Or if not, perhaps a service is not generic, but as implemented by a
partner.
In that case how does it differ from BusinesProcessInterface?

m. Could we find a new name for Duality? It is currently an association
class
which means that it describes the relationship between (in this case) two
Economic Events. I understand that it represents one economic event being
in
consideration of the other. Maybe that should be the name 'consideration',
or
'reciprocity', or 'evensteven?' Perhaps if we got some examples of how we
would actually name instances of Duality, we would be able to come up with
a
better class name.

n. Need to review our model for re-useability. We have the ability to link
a
bunch of pre-existing process pieces into a new process. We need to ensure
that we also have extensibility, i.e. re-use a process except with a few
additions. We also should be able to use templates and or patterns.
Finally,
I had a thought that perhaps we can use contexts to compose processes the
same
way that core components use contexts to compose messages.

o. Is a resource catalog truely stand-alone, or does it exist within the
context of a market?

p. Should we have the notion of sub-markets?

s. We should have the notion of 'optional' steps, transactions, information
exchanges. This would cut down on the number of specific processes defined.
If
my process is the same as your already defined process, except that I
consider
one step to be optional, and you don't, shouldn't we be able to share the
process definition anyway?

t. We should have the notion of 'repeating' steps, transactions,
information
exchanges. Rather than having individual instances of offer-counteroffer,
one
should be able to specify that the pattern repeats as many times as needed.

u. I need to be reminded of what PartyType is, and how and why it is
independent of markets.

v. This probably goes with 'k' above. We should move the
BusinessTransactionConstraint up to the StepDefinition level so you can use
it
to sequence any kind of step, not just transactions.

w. Don't have an answer, but could we review our naming convention for the
classes that end in 'type' or 'category'. Someone explained once how they
differ but I forgot.

x. To align with EDOC I recommend the following name changes:
   BusinessProcessInterface-->BusinessProcessPortal (interface has a more
narrow meaning in OMG)
   BusinessTransactionConstraint-->StepCondition (in EDOC we have pre- and
post StepConditions)

that's it for me (before I use up the whole alphabet)

-karsten


=======================================================================
= This is ebxml-bp, the general mailing list for the ebXML            =
= Business Process project team. The owner of this list is            =
= owner-ebxml-bp@oasis-open.org                                       =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-bp                                           =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-bp myname@company.com                        =
=======================================================================