[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] RE: Context Issues
Marty,
I think that there may be room for some analog of CPP to CPA
with respect to reaching an agreement on how context constructs
"select" specializations for businesses engaging in some BPSS
specified collaborations. I am uncertain whether the current
CPPA scope is the place for this though...
Consider the remark below from Paul Levine:
" However, I believe the application of a finite list of
context categories to core components in the creation
of an Assembly Document outside the top-down UMM analysis and
resultant BPSS may result in the exchange of a deficient set of BIEs."
This seems to be a cautionary note on whether the problem
here is properly construed as a selection
among implementation alternatives to achieve
interoperable, secure, reliable,
etc. system configurations. Certainly the operational
environment is a more restricted view of things, and
on different levels of description, than the UMM, and we
don't want to have a role in fostering the exchange of
deficient sets of Business Information Entities!
That said, this does seem to be an area
where specializations of some kind are
occuring, and these specializations do seem
to be selections among a previously enumerated
list of options. There _might_ be some room for agreeements
on the specializations. So, I agree that we should be monitoring
what happens in the Context arena,
but urge that we wait for the gel to
firm up to a nice scuff resistant surface!
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, January 16, 2002 10:26 AM
To: Fred Blommestein, van
Cc: plevine@telcordia.com; ebtwg@lists.ebtwg.org
Subject: Re: Context Issues
At the present state of the art, the contents of the BPSS document, as
far
as I know, cannot be negotiated at CPA negotiation time. At present, the
CPA contains some attributes, such as security properties, that can be
used
to override default values that are given in the BPSS document. If the
BPSS team can handle negotiation of context in that wat, then something
will be possible.
Regards,\Marty
************************************************************************
*************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
************************************************************************
*************
"Fred Blommestein, van" <f.van.blommestein@berenschot.com> on 01/16/2002
11:21:06 AM
To: plevine@telcordia.com
cc: ebtwg@lists.ebtwg.org
Subject: Re: Context Issues
Hi Paul,
I understand the role of the BPSS. One of the questions is, is whether
the
BPSS can be adapted/negotiated when the CPA is formed, or whether it is
just a plain copy of the standard. Applying context to very generic
(process- and message-) specifications complicates the implementation
and
mapping process almost prohibitively. Specific processes per user
community
disallow communication between communities.
What we need imo is a mechanism that allows implementers to clearly
define
what the capabilities of their system (and organisation) is, while the
"handshake" with new trading partners should be able to find the "common
denominator" of the mutual capabilities. So it must be possible for a
company to state which processsteps/BIE's are essential for their
functioning, which are optional and which are conditional (conditions
based
on context or on events or information in the process itself).
Fred
<<< "Paul R. Levine" <plevine@telcordia.com> 1/16 4:33p >>>
Just a few points to add to Bob Haugen's. The BPSS's for various
business
process scenarios are fundamental to the capabilities of what CPPs can
execute, and thus to CPAs between pairs of trading partners that can
accommodate specific BPSSs. The BPSS is a run-time business process
specification, driving the collaborative business service interface
software as well as the business documents and business signals to be
exchanged in the choreography of the scenario. Thus the BPSS
incorporates
the Assembly Document. The BPSS embodies the information patterns and
business transaction patterns within the business collaboration patterns
that we are currently working on defining in the eBTWG BCP&MC project.
Following the UMM, the context is defined in all respects at the level
of
the Business Requirements View, considering all conditions and
constraints.
Our position in the eBTWG BP projects is that context can only be fully
defined by taking a top-down approach to business process analysis.
Context categories can certainly be used by the business process analyst
as
a check list in drawing out the business process and information
requirements from the business domain expert. However, I believe the
application of a finite list of context categories to core components in
the creation of an Assembly Document outside the top-down UMM analysis
and
resultant BPSS may result in the exchange of a deficient set of BIEs.
Regards,
Paul
"Fred Blommestein, van"
<f.van.blommestein@beren To:
ebtwg@lists.ebtwg.org
schot.com> cc: (bcc: Paul
R.
Levine/Telcordia)
Subject: Re:
Context Issues
01/15/02 06:31 PM
Martin, all,
Let me try to add something to the "context discussion".
So context, as far as I understood, is a mechanism to sub- and superset
named process-steps and named messages and message-components (BIE's).
This
is used because in some industries e.g. in the ordering process no order
confirmations need to be sent, or ASN's, while in other industries using
those documents is a must. Or some types of products need special
classification (like dangerous goods) and other don't. Context is
defined
by context drivers. Industry (per role in the process) and product
classification are among those drivers.
In the specification the CPP only refers to the standard
processes/messages
and states the context of the party whose profile is defined. The CPA
refers to an "Assembly document". I understand that that document is a
separate document, being the resolution of the standard
processsteps/messages, after application of the context rules. The
format
of the "Assembly document" is, as far as I know, not yet defined.
An organisation, preparing itself for ebXML based e-business should make
a
mapping between its internal workflow and its application system to the
standard processes/messages as defined in the registry. Those
processes/messages though are not defined until the trading partner (and
his context) is known. So the mapping can only be based on a foreseen
range
of contexts of possible trading partners (supposing that the set of
context
rules is stable). This not only complicates defining the mapping. If a
new
trading partner has a slightly different context than foreseen, the
context
rules must be applied again to check if the mapping can handle it. This
will probably be a manual process.
If however, the CPP would also refer to an "Assembly document" (either a
resolution of the standards and the context rules of the company, or a
manual adaptation of the standards based on the company's capabilities,
or
a combination of those), the confrontation of standards and
capabilities,
and the resulting mapping, can be done once: when the CPP is prepared.
In
the "CPP-assembly-document" per process step or BIE it should be
indicated
whether the organisation cannot, can or must handle such step or BIE.
The
CPP to CPA process can then be a straightforward parsing process that
compares the capabilities of the trading partners until the level of the
BIE (or even the codes used therein).
Such mechanism also gives organisations the freedom to deviate from the
rest of its industry. Suppose my company is in the telecom industry, but
the services I render are simple enough to code with an EAN/UPC number.
Then I do not need to demand from my customers that they have an
ordering
system that can specify complicated telecom-services. Or if I am a
third-tier automotive supplier and cannot handle ASN's, I can still do
business with individual customers that not really demand ASN's (while
it
would be common practice in the industry as a whole).
To further simplify the CPP-to-CPA process I would propose to name
adapted
process-steps and BIE's differently from the standard steps and BIE's
they
are specialisations of. Those parent standard steps/BIE's can be defined
as
the "types" of the specialised ones. If in two CPP's the (higher level)
names are equal, the parsing process can then skip to the next step or
BIE.
If the types match the parsing should go one level deeper. If the types
don't match the necessity to send or receive (cannot/can/must) should be
looked at.
This way we would use context as a mechanism to discuss (on a global
scale)
the applicability of processes and information entities to specific
industries, product groups, etc., but leave individual companies the
freedom how to organise their workflow and their information systems.
And
we would probably reach a higher level of interoperability, as we
investigate at the time of (automatic) collaboration negotiation the
specific capabilities to a detailed level, instead of assuming a context
definition that can only be an industry average.
Possibly I have a completely wrong view on the proposed solutions. In
that
case please educate me (I am not alone). Otherwise, these are my two
eurocents.
Fred van Blommestein
Berenschot / EP-NL / OpenXchange
<<< <martin.me.roberts@bt.com> 1/15 11:32a >>>
Folks,
I have published a brief paper to get discussions flowing on the
issue of what is in an assembly document and what rules can be applied.
I
believe strongly that this is a key weakness in the current architecture
and
document set.
I have titled the paper 'Context - a statement of the obvious'
because I feel that context should be obvious and not opaque as it is at
the
moment.
I would like to discuss this with interested parties prior to
Seattle. To do this I have set up a conference call, details are:
Reference: A 3982465
Date: 17 January 2002
Time: 18:00 (GMT) 13:00 (EST) 10:00 (PST)
Duration: 1 Hour 10 Mins
No of lines: 20
Chairperson: Martin Roberts
Telephone No from UK: 08706000825
Telephone No from abroad: +44 (0) 2088133300
Pin No: 332292#
Do join in the debate as I feel this will indeed close the loop in a
number
of peoples minds. <<Context.doc>>
Martin Roberts
xml designer,
BTexact Technologies
e-mail: martin.me.roberts@bt.com
tel: +44(0) 1473 609785 clickdial
<http://clickdial.bt.co.uk/clickdial?001609785.cld>
fax: +44(0) 1473 609834
pp 16 Floor 5, Orion Building, Adastral Park, Martlesham, Ipswich IP5
3RE,
UK
BTexact Technologies is a trademark of British Telecommunications
plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000
This electronic message contains information from British
Telecommunications plc which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this
information
is prohibited. If you have received this electronic message in error,
please
notify us by telephone or email (to the numbers or address above)
immediately.
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebtwg.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebtwg.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebtwg.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebtwg.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC