Re: Submission of new TA specification DRAFT

["Paul R. Levine" <plevine@telcordia.com>]

Duane,

In my recent message I stated that there is a relationship between CCs and CBOs,
but it is not as Section 5.0-4 Core Components  Specification (CC) indicates.
In Mike Adcock's description, CCs are used to assemble higher level aggregate
CCs, not CBOs.  Mike related CCs to CBOs by saying, "individual CCs will in
general match the 'data list' part of CBOs."  CBOs contain CBOs recursively, and
CCs contain CCs recursively.  I still owe you a paragraph that show how the BPM
methodology uses CCs and 'smart' CCs to find or create new CBOs and business
objects.  An initial draft of the procedure follows.

1) Describe e-Business requirements, drawing from core processes
and core components that have been developed independent of any
existing or developing business processes.

2) Use the core component context types to extend/adjust
the core components in completing the attributes of the e-
Business requirements class diagram, showing business entity
classes, attributes and relationships together with class
definitions.

3) In the analysis workflow, transform the e-Business requirements
class diagram into a precise object-oriented class diagram, built
on common business entity classes (also known as CBOs).

4) The information bundles to be exchanged will be taken directly
from the attributes of the common business entity classes (same as
'smart CCs) and formed into XML constructs.  (At this point the
transformation from information bundles could be to any syntax, XML or
anything else. This is the real objective of the syntax neutral base we
are trying to achieve.)

Regards,

Paul




duane <duane@xmlglobal.com> on 09/14/2000 11:24:33 AM

To:   "Martin W Sachs/Watson/IBM" <mwsachs@us.ibm.com>
cc:   ebXML-StC <ebXML-StC@lists.ebxml.org>, ebXML-Architecture List
      <ebxml-architecture@lists.ebxml.org> (bcc: Paul R. Levine/Telcordia)
Subject:  Re: Submission of new TA specification DRAFT




MArty:

Thank you for the prompt reply and comments.  After reading these,  I
don;t think we would have any problem changing the section as per your
comments.  This would still meet our needs of specifying the functional
requirements for the TPP team.  If we change these items,  do you feel
that our spec would meet your needs and enable you to complete your
work?

We wish to get each of the teams to basically review the generic
sections plus the section that applies specifically to their domain
(scope).  I feel we could very easily reach this consensus.
Rik:  The Transport stuff is largely based on a working liaison between
our teams.  I believe it should meet with your approval however, can you
please revisit it briefly.

Lisa:  Please look at the COre Components, CBO's and there are also a
couple of implementation issues that touch on run time context and
design principles.  PLease let us know your comments ASAP (even though
this document hasn;t received official submission status from the QA
Team, I want to get the ball rolling.)

On a personal note - I am very excited about the latest specification.
I think we are well on our way to meeting our targets for Vancouver.  I
want to thank all those who have taken the time to aide the TA Team in
this presentation.  Everyone has been very instrumental in the
collaboration you see before you.

Duane Nickull