Another set of comments

[Karsten Riemer <Karsten.Riemer@East.Sun.COM>]

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