[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] Re: Context Issues
FYI
*************************************************************************************
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
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 01/16/2002
10:36 AM ---------------------------
"Paul R. Levine" <plevine@telcordia.com> on 01/16/2002 10:18:39 AM
To: "Fred Blommestein, van" <f.van.blommestein@berenschot.com>
cc: ebtwg@lists.ebtwg.org
Subject: Re: Context Issues
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC