[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Two Comments on Negotiation Draft (high level)
Some thoughts within. 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 ************************************************************************************* Dale Moberg <dmoberg@cyclonecommerce.com> on 08/28/2001 01:07:04 PM To: Martin W Sachs/Watson/IBM@IBMUS cc: "CPPA (E-mail)" <ebxml-cppa@lists.oasis-open.org> Subject: Two Comments on Negotiation Draft (high level) Goals section: 1. If we have the goal of extending our work to web services, then I think under section 1.1 High-Level requirements, we should also include a bullet on automated composition from a CPA template. The reason for this is that in web services, we do not have the pure peer-to-peer collaboration scenario that the CPP composition process is to treat. A publicized web service is really just saying: "This is what I do and this is how you can access this service." At most there might be some flexibility in user identity, possibly some security related credential matters, and maybe some customized resource allocations-- and all these items seem to be handled easily by the template value substitution process rather than the matching of capabilities. It is possible that eventually web services might have multiple endpoints, variable packaging and security options, and at that level of complexity, the CPP to CPA formation process would be needed. At any rate, and possibly independently of whether web services are to be in scope, we should add CPA template substitution in the high-level requirements process. MWS: I agree with all of this but I am not clear on what automated composition means in this 1-sided case. Let's say that a service provider advertises a CPA template. What does the service consumer's input to the composition process look like? Is it a CPP, another CPA template, or is the service consumer really just filling in the blanks in the service provider's CPA template with an editing tool? High-Level Requirements I think the bootstrap issues for Negotiation need to be taken very seriously and that we reach agreement on just how lightweight the negotiation process can be. For example, while I think we should have repository access of CPPs allowed, I do not think it should be required. If so, should we require that there always be CPP access via a UDDI registered CPP provider service? In other words, it might be pretty easy to GET a CPP via a URL endpoint found in a UDDI registry or obtained over the phone. I think that what should be mandatory for negotiation are only the lightest commitment configurations and functions. (like HTTP GET of a CPP from a URL either gotten out of band or from a registry). Likewise, the negotiation process should be as light as we can get by with-- possibly just POST the candidate CPA to a URL (obtained from a registry or out of band). This is a fairly extreme minimalism in terms of what functionality is required get CPPs (CPA templates, see above) and to propose a CPA. Where this gets tricky is in response to a proposed CPA that has been posted. Synch response is the least commitment in that an agreed upon return URL does not need to be known. So, in summary, I would like us to consider at the requirement stage just how minimalistic we can make the software capability prerequisites for engaging in CPA negotiation. I think we should aspire to a minimalistic prerequisite set, and note that as a requirement. Maybe this is just a KISS endorsement! MWS: I agree that we should strive for a minimalist design at least for the first version. I will distill something from these points when I update the draft. MWS: The most minimalist approach is to decide that the discovery process is out of scope. Then the process begins with two CPPs (or a CPA template from one party and some TBD input from the other party) whose origins are not specified. Probably this is too minimalist. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC