Comments on BP Architecture Document

[Scott Hinkelman/Austin/IBM <srh@us.ibm.com>]

Klaus, BPers,
->This is recent post to the trp list from myself with terminology that we
should consider:
-------------
MSers, (<-correct, right!)
Further, on terminology to minimize confusion,
I would suggest we drop the terms TPA and Partner.

It is yet unclear why we need a distinction between Party and Partner, so
unless we decide we need both, lets stick with just Party.

It is now evident that we will have (logically, at least) a
PA (PartyAgreement) and a PP (PartyProfile).
The PP specifies what a Party *CAN* do, while
a PA specifies what a Party *WILL* do.
-----------

So, I believe we will be on a path toward a PP spec and a PA spec
from the tp workgroup. This week may very well flatten this.

-> The drawing under "Position Within ...." should show both
the PP and the PA (not TPA and TPP) being capable to be registered
in the RegRep. The MS spec contains the ability to point to
a PA by id. (Actually, I believe that itself needs changed from
TPAid to PAid).

-> Under "Relationship to Core ...."
>The entities within an enterprise are called business entities, and their
data structure can be represented by business objects.

I would suggest dropping this line altogether, and avoiding the whole BO
discussion since it is out of scope for ebXML anyway, and you don't
know if the intra-enterprise technology is OO. If we do decide to
leave it in, then I would suggest a more discussion beyond "their structure
can
be rep.. by busi.. objects" and tie in words about object *behavior* needed
to
support intra-enterprise functionality.

>The communication with parties outside the enterprise takes place through
an exchange of business messages.

At this level, do you not mean "business documents" ?

>Both business objects and business messages are composed from core
components, re-useable low level data structures.

Again I would skip the BO aspect, switch to 'business documents' for this
level of the Architecture,
and stick to describing Core Components as Core Business Data Structures
with no behavior (which they are. By the way,
I think we should remain CC to CBDS because "components" is one of most
overloaded terms in I/T )

>A trading partner profile describes only one side, i.e. one role. Thus,
the business semantics of a trading partner profile can be derived from a
business process >definition. When combined with TRP semantics you get a
trading partner profile.

The PP will be able to describe more than one role. It will be able to
describe
or indicate capability for a Party to play multiple Roles within multiple
processes.

Concerning the UML->XML mappings:
I agree that modeling a process outside of the UML-based methodology is
important.
We should show alternate modeling input for the XML layer.

This surfaces questions on the content of the XML layer concerning
terminology (BOM, etc)
and how much it reflects the BP MM's built-in methodology. This is an
important
issue that will reflect the feasibility for tool vendors to construct
products/tools specifically targeted for B2B process definition, rather
than
solely having to use a general-purpose modeling approach like UML;
say perhaps, for developing nations.

Thanks,
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
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> on 10/09/2000 10:00:47 PM

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

To:   Klaus-Dieter Naujok <knaujok@pacbell.net>
cc:   ebxml-bp@lists.ebxml.org
Subject:  BP Architecture Document



Klaus,
For your TA architecture session,
here is a pass at a BP chapter for the TA architecture.
It follows the outline I sent earlier.
Let's discuss in tomorrow's phone call.

I am copying BP list so they can react if I have misrepresented anything.

-karsten