OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Two Comments on Negotiation Draft (high level)


Some comments below.



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

"Collier, Timothy R" <timothy.r.collier@intel.com> on 08/29/2001 02:13:14

To:   "'Dale Moberg'" <dmoberg@cyclonecommerce.com>, Martin W
cc:   "CPPA (E-mail)" <ebxml-cppa@lists.oasis-open.org>
Subject:  RE: Two Comments on Negotiation Draft (high level)

Along the lines of extreme minimalism, what is the minimum we think should
be allowed for a CPA?  One line of thought might be present when one
dictates terms, then maybe their CPP is a "take it or leave it, only one
choice for each" CPA.

MWS:  Above is the CPA Template case.  The Service Provider's CPA template
dictates almost everything.  In the extreme case, the service consumer can
only supply his endpoint address. This is equivalent to the WSDL model
except that the WSDL model does not include an agreement document of
any sort.

Or is it possible that the CPA could be reduced to a

MWS:  If by "reduced to a WSDL", you mean only port types and the very
minimalist transport bindings that it now has, I don't think so.
I expect to see WSDL getting richer as endpoint properties are considered.
I would not want to see CPP-CPA backpedal on functionality.  Use of the CPA
template preserves the functionality while limiting choices.

Should the negotiation account for no negotiation?

MWS:  I would think "no negotiation" could be a logical low end of the
function defined in the negotiation process definition.  Alternatively,
the "no negotiation" case could be accomplished by allowing a party to
advertise that it does or doesn't perform our negotiation process.


-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Tuesday, August 28, 2001 10:07 AM
To: Martin W Sachs
Cc: CPPA (E-mail)
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.

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
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!

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