[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-cppa-negot] Action item: specifying negotiation process as a wsdl.
I agree that if your correspondants are concerned about the negotiation business process itself, all your points are correct. My point was that the negotiation business process is not generally viewed as an end in itself. Its purpose as normally understood as leading to an agreement (CPA) between two parties on the infrastructure characteristics that will support message exchanges in an electronic commerce activity. Regards, Marty At 05:17 PM 5/6/2004, Monica J. Martin wrote: >Martin Sachs wrote: > >>The NDD is substantive to the process of negotiating a CPA. > >mm1: Then it is substantive to the business process of negotiating the >CPPA not necessarily the BPSS instance that is included as part of the >CPPA negotiation. >Therefore, it is substantive and could impact the negotiation business >process. > >>The BPSS instance associated with negotiating a CPA describes only the >>choreography etc. of negotiating a CPA. Neither the NDD nor the >>negotiation BPSS instance is a part of any "monetary" business process. > >mm1: The monetary aspect was not the intent of my message Marty. The >intent is that the attachment, document, appendix (logical documents) if >substantive can affect the process. Monetary aspects are not the basis. I >understand you point about eCommerce. But the negotiation of the CPA is in >and of itself a supporting technology that is in somewhat related to the TPA. > >>Once the CPA has been agreed to, the NDD and negotiation BPSS are not >>factors in what is done with the CPA or the BPSS instance associated with >>the CPA. > >mm1: But they do affect the negotiation process itself. Therefore they are >substantive, i.e. they must be parsable and interrogated right? > >> >> >>Regards, >>Marty >> >>At 03:24 PM 5/6/2004, you wrote: >> >>>Dale Moberg wrote: >>> >>>>Hi >>>> >>>>At the f2f people asked me how much work it would be to convert the wire >>>>formats of negotiation to wsdl. >>>> >>>>In terms of BPSS instance work, it would probably best be deferred until >>>>BPSS has support for wsdl defined processes. Currently an >>>>"OperationActivity" element is proposed and under discussion. >>> >>>mm1: Given the current proposal, what, if any, questions or gaps do you >>>see with the OperationActivity. >>> >>>>In terms of CPPA work, the 2.x CPPA (with extensions for WSDL and other >>>>things) could be used to specify the services. >>> >>>mm1: How do we resolve the difference between signals and messages, and >>>the differences in processing (legal commitment and economic aspects >>>implicit here)? We have not yet resolved the definition of a service in >>>the context of ebBP for the BSI, which may serve as a composed service >>>interface. Thoughts? >>> >>>>In terms of Negotiation schema work (NDD plus NegotiationMessage), a >>>>quick solution is sketched in the schema attached to this message. [See >>>>also the wsdl:type with the same info.] >>>mm1: We have received some feedback from the international legal >>>community (for eCommerce today) that the NDD may or may not be >>>considered an attachment. The key is if the NDD (supplemented to the >>>NegotiationMessage) is substantive to the business process. At this >>>time, it depends on the parties overall agreement at a minimum. We >>>should discuss this as if the NDD is considered non-substantive if (1) >>>May not impact the business and (2) It can only be interrorgated by >>>type and metadata (not on the instance but the metadata type). We should >>>discuss this further as this has a potential impact on ebBP and >>>CPPA/CPPA negotiation. >>> >>>>In terms of WSDL work, a quick solution is sketched in the wsdl attached >>>>to this message. >>>> >>>>So, overall there is not too much work that would be needed to fully >>>>support a WS described wire format. >>>> >>>>Nevertheless, we could defer the CPPA and BPSS work, roll-up the payload >>>>into a single SOAP:body, and include the wsdl in a short amount of time >>>>IMO. >>>mm1: Deferring some of the CPPA and BPSS questions (such as negotiation) >>>may be advised. However, addressing the basic implications of the >>>payload roll-up and any impacts to the business process should be >>>discussed now. I would prefer we address BPSS v2.0 as soon as practical, >>>if only incrementally. Thanks. >>> >>>>The wsdl has a lot of namespaces that you will certainly need to change >>>>schemaLocations for. >>>>If you are at that level of investigation and run into trouble, send me >>>>a message and I can send the exact files (for CPPA, NDD, and >>>>NegotiationMsg that I used in this illustration). >>>> >>>>There is about half of an afternoon's work in the above examples. So >>>>they are by no means finished. Some incomplete areas: >>>>1. Should we define faults for any operations in the service? >>> >>>mm1: How does this relate to business exceptions? >>> >>>>2. Should request-response patterns be defined for some operations? >>>>Which ones? [All the current operations are "one-way" MEPs.] >>> >>>mm1: Does that require we map to the business transaction patterns in >>>ebBP? How does this affect CPPA assumptions? >>> >>>>3. Should we try to break out messages into distinct specializations of >>>>an underlying type? [I just used one schema for the SOAP:body uniformly >>>>in this discussion approach.] >>>mm1: Given my questions above, we maybe should talk about this as an option. >>> >>>>Dale Moberg >>>> >>>> >>>> >>>>------------------------------------------------------------------------ >>>> >>>>To unsubscribe from this mailing list (and be removed from the roster >>>>of the OASIS TC), go to >>>>http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/leave_workgroup.php. >>>> >>> >>> >>> >>>To unsubscribe from this mailing list (and be removed from the roster of >>>the OASIS TC), go to >>>http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/leave_workgroup.php. >>> >> >> >>************************************* >>Martin Sachs >>standards architect >>Cyclone Commerce >>msachs@cyclonecommerce.com > ************************************* Martin Sachs standards architect Cyclone Commerce msachs@cyclonecommerce.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]