Re: service binding - tech comment v0.2 CPP/CPA

[christopher ferris <chris.ferris@east.sun.com>]

Well, I think I understand the interpretation, but that isn't
what I had in mind;-)

Consider the RosettaNet PIP xxx that REQUIRES the acknowledgment
to be sent via SMTP yet ther request comes by way of
some other protocol. (I only recall this anecdotally,
so the actual PIP number escapes me). This might be expressed as:

<Role name="buyer" ...>
	<ServiceBinding collaborationId="N100" channelId="HTTP01">
		<Override message="Acknowledgment" channelId="SMTP01"/>
	</ServiceBinding>
</Role>

Thus, a Party wishing to play the "seller" role would be REQUIRED
to support an SMTP send capability for the Acknowledgment
message.

It isn't as if there is a choice in use of the HTTP01 or SMTP01
delivery channel. The "default" nature of the delivery channel
in the ServiceBinding is to avoid having to explicitly list ALL
of the messages that are associated with a business process
with a delivery channel in a ServiceBinding.

Again, maybe the choice of "Override" for the element name
is resulting in the confusion. Maybe "Message" or "Action"
is more appropriate, but then the confusion would be
that each message (or action) would be listed even
though the idea was to have a delivery channel apply 
(as a default) to te whole business process unless otherwise
overridden by an Override child element...

Cheers,

Chris


"Moberg, Dale" wrote:
> 
> I agree with Marty that this is clearer
> and has a number of enhancements! Thanks Chris.
> 
> I interpreted the default and override to
> each be acceptable capabilities that
> could be matched, even though they might be
> differently ranked. So Marty's question
> about whether an override could be
> used in a proposed CPA did not occur
> to me. Nevertheless, it seems worth
> clarifying how the preference system
> works. I guess that if you had capabilities
> that you did not really want to encourage
> being used, you would not advertize them
> at all in the CPP. (I don't say anything
> about Fortran or Cobol in my resume...)
> 
> Dale Moberg
> 
> > -----Original Message-----
> > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > Sent: Tuesday, January 23, 2001 10:48 AM
> > To: christopher ferris
> > Cc: ebxml-tp@lists.ebxml.org
> > Subject: Re: service binding - tech comment v0.2 CPP/CPA
> >
> >
> >
> > Chris,
> >
> > This service binding proposal looks great.  However I do have
> > some comments
> > and questions.
> >
> > Regarding preference among alternative service bindings:
> >
> >    It should state that preference among alternatives is a negotiation
> >    matter.  (This mostly relates to matching send properties
> > to receive
> >    properties that we still have to add but we should add the
> > point about
> >    the negotiation matter now.)
> >
> >    We probably need to say what happens if a delivery channel
> > with override
> >    specified is not compatible with the other partner. One
> > possibility is
> >    that this is an incompatibility that must be negotiated.
> >
> >    In order for Override to be meaningful, the delivery channels with
> >    Override specified have to appear in the CPA if they are
> > compatible with
> >    both parties.  Therefore in fact, preference also
> > determines selection
> >    of delivery channel when the collaboration protocol is
> > being performed.
> >
> >    It needs to state (if true) that where more than one
> > delivery channel is
> >    allowed the highest preference (the default) delivery
> > channel will be
> >    used unless an override is specified for a particular message. (I
> >    suggest avoiding the question of what selects the delivery
> > channel.)
> >
> >      One could extend this to permit dynamic selection of
> > delivery channel
> >      in order of preference (again avoiding what does the
> > selection).  This
> >      would be a non-normative note.
> >
> > This proposal appears to limit each role to one certificate for all
> > delivery-channel security functions on all delivery channels.  Is this
> > sufficient?  tpaML  allows a different certificate for each security
> > function used in either transport or doc exchange (transport
> > encryption,
> > transport authentication, nonrepudiation, digital envelope) in each
> > delivery channel. However, when I look at the transport and
> > doc exchange
> > security functions I do see a certificate reference in each.  So the
> > question is, what is the function of the certificate
> > reference in <Role> vs
> > the certificate references in the individual security definitions?
> >
> > Default delivery channel:  Somewhere the text needs to state that the
> > default delivery channel is the one specified by the
> > highest-preference
> > service binding for this role and collaboration protocol. I think this
> > statement belongs in the text for channelID attribute.
> >
> > Override element:  It should state what is done Override is
> > specified in
> > the only service binding specified for this role and collaboration
> > protocol.  "Ignore" is a possibility but this could be
> > considered an error
> > that should be corrected.  The error could be detected by a CPP-aware
> > authoring tool and by a CPA composition tool.
> >
> > Message attribute:  I suggest stating that the value of the message
> > attribute is defined in the collaboration protocol element
> > identified by
> > the collaborationId attribute.
> >
> > "Alternate" should be "alternative" since there can be more than two.
> >
> > 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
> > **************************************************************
> > ***********************
> >
> >
> >
> > christopher ferris <chris.ferris@east.sun.com> on 01/22/2001
> > 01:14:14 PM
> >
> > To:   "ebxml-tp@lists.ebxml.org" <ebxml-tp@lists.ebxml.org>
> > cc:
> > Subject:  service binding - tech comment v0.2 CPP/CPA
> >
> >
> >
> > All,
> >
> > One of the issues that has been discussed both on and
> > off list is the purpose and function of the ServiceBinding
> > element.
> >
> > There has been some confusion and also some concern that
> > the current draft of the CPP will make it difficult
> > at best for automated CPP+CPP->CPA mapping.
> >
> > One of the concerns was that in the current design, it is difficult
> > to determine if all of the messages for a given collaboration
> > protocol are actually "bound" to a DeliveryChannel.
> >
> > Another concern raised is how to map alternate delivery channels
> > to a given collaboration protocol, etc.
> >
> > I would therefore like to propose the attached revision to the
> > Role element that I think will make things a little clearer
> > than they are in v0.2 as well as to provide a little better
> > closure on ensuring that all messages are "bound" to
> > a delivery channel.
> >
> > This proposal also involves removing the ServiceBinding child
> > element from the DeliveryChannel, as this function is now covered
> > with the attached proposed change to the Role and ServiceBinding
> > elements.
> >
> > Comments are encouraged.
> >
> > Cheers,
> >
> > Chris
> >
> >
> >
> >
> >
> >
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard