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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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


Subject: RE: [ws-rx] i021: a proposal



"Yalcinalp, Umit" <umit.yalcinalp@sap.com> wrote on 01/16/2006 04:12:45 PM:

> Two things:

>  
> -- A question about the EPR/metadata section that you are
> suggesting.  I am trying to understand how strong a requirement you
> are suggesting we make there.

>  
> In WS-A, we have discussed the fact that EPRs may be stale. This is
> also true for EPRs that may contain metadata that indicates that the
> endpoint should have WS-RM engaged or EPRs that may not have this
> data. It may be possible to use other means, for example WS-MEX, to
> determine the capabilities of the endpoint.  Therefore, "requiring"
> the metadata section may not be feasible right away, although we can
> recommend it.


I'm envisioning this being used in cases where people choose to
_not_ expose WSDL, where doing a WS-MEX Get isn't an option, or in
cases where people know the EPR will not go stale.  The choice is
up to the generator of the EPR.  The RM spec just offers up a list of
possible solutions and let's the app make the choice.  If the
wsa:Metadata section can not be used for things like this then I would
question why its even there at all.

> -- Are you suggesting to remove the extensibility of the assertion
> itself? Removing extensibility contradicts the general extensibility
> principles we have adopted in the industry for WS standards in
> general. We should not limit the vendor's capabilities in this area
> and not force them to use some other mechanism in their private environment.

>  
> I will oppose such a direction.

Given the previous discussions it just seemed easier to kill 'em. :-)
If things like AckInterval and MaxMessageNumber can't be thought of
as static enough to include in WSDL/Policy and we move them to the
CreateSequenceResponse, then I have a feeling most everything would
probably be moved there as well.  And CSR is extensible so people can
place those 'other parameters' in there.  Honestly, I don't really
have a huge preference either way because I never saw a problem with
Sequences spanning multiple endpoints and each endpoint exposing different
RM Policy - but after seeing all of the angst it cause some people
it just seemed easier to remove them.
(I keep having flashbacks to our endless DA discussions  :-)

thanks,
-Doug


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