[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