RE: Composibility problems with refps

Dims,

I never said I subscribed to Omri's take on the correlation of EPR 
components with URI components.

That said, my comments below.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

"Srinivas, Davanum M" <Davanum.Srinivas@ca.com> wrote on 11/22/2004 
05:07:25 PM:

> Chris,
> 
> Can we stick to Question everything (Why do we need to subject ref's and
> prop's to SOAP Processing Model?) instead of it's already in there
> everything will crumble if you take it out ("colossal mistake" and "red
> herring")

Actually, I think that the charter is pretty clear that the WG is to 
refine the
input spec, not start from scratch.

> 
> What are the advantages of subjecting ref props's and param's to SOAP
> Processing Model? And what exactly do we lose by going the opposite way.

As written, rep props/params are inserted into SOAP messages addressed to 
the
endpoint referenced as SOAP headers. Hence, they are subject to the SOAP 
processing
model whether they contain soap:mustUnderstand or soap:actor/role 
attributes or not.

Now, the fact that the ref props/params become SOAP header blocks is 
important and
quite useful. For instance, an endpoint that knows it resides behind a 
gateway/firewall
could design and publish an EPR that took this fact into consideration by 
including
ref props/params that would aide in the gateway's routing of the messages 
received.
For instance, the gateway could be an HTTP endpoint, targetted by the 
wsa:Address
and one of the ref props/params could be an MQSeries queue name that the 
ultimate
recipient will be using to dequeue messages addressed to it.

That use case seems quite reasonable to me. The EPR would probably look 
something
like this:

<wsa:EndpointReference>
  <wsa:Address>http://my.gateway.ibm.com/queuea</wsa:Address>
  <wsa:ReferenceProperties>
    <mq:QueueId soap:actor="http://www.ibm.com/gateway/" 
soap:mustUnderstand="true">queuea</mq:QueueId>
  </wsa:ReferenceProperties>
</wsa:EndpointReference>

Now, if I somehow misdirected to the wrong gateway service, the one that 
knows about
MQSeries, then the sender would never get a SOAP MustUnderstand fault 
indicating that
in fact the message could not be processed if the ref prop were wrapped in 
some generic
wsa:Warpper element.

> Since I am feeling a bit lost....Let's take an example, Omri talks about
> Ref Props's as part of the identity of the service
> (http://www.gazitt.com/OhmBlog/). Are u suggesting that an intermediary
> should know all about the services that is behind it? And on the other

see above... yes

> hand let's take a Ref Param ["ability to send "parameters" (or attach
> "cookies") to the EPR, without changing the service identity"]. Are u
> saying that an intermediary should know all possible values of every
> parameter that is likely to be sent to a service?

No, but I am saying that by wrapping the ref props/params in some generic
wsa:Wrapper element that you lose the ability to leverage the SOAP 
processing
model and IMO, that would be a mistake.

> 
> Thanks,
> dims
> 
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Christopher B
> Ferris
> Sent: Monday, November 22, 2004 4:10 PM
> To: Anish Karmarkar
> Cc: Jonathan Marsh; public-ws-addressing@w3.org;
> public-ws-addressing-request@w3.org; tom@coastin.com
> Subject: Re: Composibility problems with refps
> 
> 
> Anish/Tom,
> 
> But then this means that the refps that under the current design become
> SOAP headers, and subject to the SOAP processing model, would no longer
> be subject to the SOAP processing model. I think that this would be a
> collossal mistake.
> 
> Frankly, I think that the idea of reference properties/params
> interfering with other WS-* use of headers is a red herring. Of course,
> it is always possible to do something that would break any protocol. At
> most, I could see adding a note in the spec that recommended caution
> when including any protocol elements as reference property/parameters as
> their subsequent inclusion as SOAP header blocks in messages addressed
> to the endpoint *might*, I repeat, *might* conflict with constraints as
> to cardinality of such header blocks in a message, etc.
> 
> I would strongly discourage any thoughts of a wrapper element for
> reference property/parameters.
> 
> Cheers,
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295
> 
> 
> 
> Anish Karmarkar <Anish.Karmarkar@oracle.com> Sent by:
> public-ws-addressing-request@w3.org
> 11/22/2004 02:03 PM
> 
> To
> tom@coastin.com
> cc
> Jonathan Marsh <jmarsh@microsoft.com>, public-ws-addressing@w3.org
> Subject
> Re: Composibility problems with refps
> 
> 
> 
> 
> 
> 
> 
> I agree that would indeed solve the problem -- either refp specific
> header(s) or the use of [to] property.
> 
> -Anish
> --
> 
> Tom Rutt wrote:
> 
> > 
> > As Glen has suggested before, encapsulating the ref parms and ref 
> > props in a ws-addressing specific header element would allow arbitrary
> 
> > qnames for the ref props and ref parms, without confusion.
> > 
> > Tom Rutt
> > 
> > Anish Karmarkar wrote:
> > 
> >>
> >> Yes.
> >> Or in the context of SOAP, composability with any specification that 
> >> uses SOAP header(s) as a mechanism to convey information.
> >>
> >> -Anish
> >> --
> >>
> >> Jonathan Marsh wrote:
> >>
> >>> Specifically, you're worried about the case where the reference 
> >>> properties and reference parameters are in a namespace used by the 
> >>> reliability, security, etc. mechanisms, right?
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: public-ws-addressing-request@w3.org [mailto:public-ws- 
> >>>> addressing-request@w3.org] On Behalf Of Anish Karmarkar
> >>>> Sent: Monday, November 15, 2004 11:10 AM
> >>>> To: public-ws-addressing@w3.org
> >>>> Subject: Composibility problems with refps
> >>>>
> >>>>
> >>>> All,
> >>>>
> >>>> During last week's concall discussion of issue i008 I took an 
> >>>> action to explain the composibility problem with refps in an email.
> 
> >>>> This email fulfills that action.
> >>>>
> >>>> WS-Addressing [1] Submission includes [reference properties] and 
> >>>> [reference parameters] in the info models for EPR. These refps are 
> >>>> opaque to the consumer. In the SOAP binding of EPR, the refps are 
> >>>> bound as individual SOAP header blocks. I.e., a consumer of a EPR 
> >>>> using
> SOAP
> >>>> is required to copy the refps as individual SOAP header blocks
> without
> >>>> understanding what the blocks mean or do.
> >>>>
> >>>> Typically SOAP header blocks are part of a SOAP module and express 
> >>>> certain functionality. For example, WSS, WS-Reliability, 
> >>>> WS-ReliableMessaging, WS-C, WS-T WS-Context etc, specify header
> blocks
> >>>> that have a particular meaning that is conveyed from the sender to
> the
> >>>> receiver. Specifications in the realm of Web services are designed 
> >>>> to be composible with other specs. For example, WS-Context can be 
> >>>> composed with WS-Reliability and WSS.
> >>>>
> >>>> A consuming application that dereferences an EPR that contains 
> >>>> refps may have some policies in place wrt to reliability, security,
> 
> >>>> coordination, transaction, privacy etc. Given that refps may 
> >>>> contains any XML and these refps are bound as SOAP header blocks, 
> >>>> refps can potentially interfere with composibility of WS-Addressing
> 
> >>>> with other WS-* specs that the consumer may be using. The opacity 
> >>>> of the refps prevents the consumer from making any inferences about
> 
> >>>> the refps in an EPR.
> >>>>
> >>>> This issue is slightly different from the security of EPRs -- which
> >>>> *may* potentially be resolved by requiring the minter of the EPR to
> 
> >>>> sign the EPR.
> >>>>
> >>>> HTH to clarify the issue.
> >>>>
> >>>> -Anish
> >>>> --
> >>>>
> >>>>
> >>>>
> >>>> [1] http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
> >>>>
> >>>
> >>>
> >>>
> >>
> > 
> 
> 
> 
> 
> 
>

Received on Tuesday, 23 November 2004 00:27:03 UTC