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


Doug,
 
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.
 
-- 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.
 
--umit
 


From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Friday, Jan 13, 2006 4:51 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] i021: a proposal


Proposal for i021:

- reduce the RM policy assertion to mean that RM is supported
  <wsrmp:RMAssertion [wsp:Optional="true|false"]?/>
  No Optional attribute implies RM is supported but optional.
- this assertion applies _just_ to incoming messages
- when optional its up to the RMS to decide whether or not RM is used
- when not optional then RM is required for all messages to this endpoint
- define a new RMRequired Fault to return when an endpoint gets a message
  that wasn't RM-enabled but requires it to be.
- Define this new fault in the RM spec.
- Add text to the wsrm spec saying that when a message is sent to
  an EPR that contains the <wsrmp:RMAssertion> element in the
  <wsa:Metadata> section then the sender of the message should use
  this information to know whether or not RM is supported/required.

When sending replies it may not be possible for the wsa:ReplyTo endpoint
to always expose WSDL to let the RMD know whether or not it is RM-enabled.
To satisfy this the RMS can include the <wsrmp:RMAssertion> element in
the wsa:ReplyTo EPR's <wsa:Metadata> element.

As to the current parameters (e.g. MaxMessage#), those are removed and
will either be placed in the CreateSeqResponse (based on Paul's issues)
or dropped entirely from the spec.  This assertion is not extensible.

thanks,
-Doug


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