ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i021 proposal (updated)
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: "Patil, Sanjay" <sanjay.patil@sap.com>
- Date: Thu, 16 Feb 2006 15:52:06 -0500
Given the amount of email traffic on
this issue over the course of the last week, I am not at all convinced
that we are close to resolving this.
Also, to be honest, I have not been
able to catch up completely on my email due to travel
and an inability to get email connectivity
for 1 1/2 days. I would actually prefer that we not spend
an entire call discussing/arguing something
that I do not yet believe has general consensus
agreement as to even the high-level
concepts of according message policy subject.
Also, given that the editor monkeys
are not to be trusted even with making grammatical changes,
I am also not comfortable in just making
hand-wavy voice changes to be addressed by the
editors, especially given that on other
issues where there was even less contention in the
discourse, there has been significant
pushback to get a formal, line-numbered set of changes
expressed in email for the TC to review
before-hand.
I don't understand why this issue would
be accorded special treatment, especially given the
fact that there remains (IMO) some significant
disagreement amongst the TC members.
Cheers,
Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
"Patil, Sanjay" <sanjay.patil@sap.com>
wrote on 02/16/2006 03:18:34 PM:
>
> The proposal has been out for review for about a week now (Paul posted
> it on Feb 9th). The issue itself has been open for about 8 months
now :)
>
> My proposed changes are something that I believe we can discuss on
the
> call without requiring a line-numbered proposal.
>
> I really suggest that we utilize today's call to discuss and resolve
> this issue. Marc, we can walk through the proposal again if
that may
> help you in understanding it better.
>
> -- Sanjay
>
> > -----Original Message-----
> > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > Sent: Thursday, Feb 16, 2006 11:52 AM
> > To: Patil, Sanjay; Paul Fremantle
> > Cc: wsrx
> > Subject: RE: [ws-rx] i021 proposal (updated)
> >
> > I'm sorry, I might be able to agree to this proposal but I need
more
> > time to review this, particularly as you seem to suggest yourself
that
> > there are changes you want to apply to this proposal. There
> > was a lot of
> > discussion on this issue this week and I expect there will be
more on
> > today's call.
> >
> > I simply can't digest that much information to make a call one
way or
> > the other yet. I think this is an important issue and would
> > prefer that
> > we take the proper amount of time to close it properly. If forced
I'm
> > afraid I would have to vote against adopting anything on this
today
> > rather than making the wrong call or accepting something that
is
> > incomplete.
> >
> > All of that said; I'm not opposed to what I'm seeing here. I
just need
> > more time to review it.
> >
> > Marc Goodner
> > Technical Diplomat
> > Microsoft Corporation
> > Tel: (425) 703-1903
> > Blog: http://spaces.msn.com/mrgoodner/
> >
> >
> > -----Original Message-----
> > From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
> > Sent: Wednesday, February 15, 2006 7:01 PM
> > To: Marc Goodner; Paul Fremantle
> > Cc: wsrx
> > Subject: RE: [ws-rx] i021 proposal (updated)
> >
> >
> > I am fine with Paul's suggested way of addressing my concerns.
I think
> > this proposal should be on the table as a candidate for resolving
i021
> > on tomorrow's call. I am taking the liberty (due to time zone
> > difference
> > with PaulF) to update the proposal as per his response just to
> > facilitate easier deliberation by the TC members ...
> >
> > I would also propose to -- a> define rules for handling the
case where
> > RM policy assertions are attached to multiple subjects in the
> > same WSDL,
> > and b> clarify (or even remove) the last paragraph related
to how EPR
> > contained RM assertions interact with WSDL attached RM assertions.
I
> > wouldn't ask for another round of proposal for resolving
> > these aspects,
> > and would rather let our able team of editors apply the necessary
> > changes (assuming the TC blesses the proposal and agrees on the
> > updates!) ...
> >
> > -- Sanjay
> >
> > --------------------------------------------------------------------
> > Based on CDII
> >
> > Delete 142-154 section 2.3 and replace with.
> >
> > 2.3 Assertion Attachment
> >
> > The RM assertion can have Service, Endpoint, Operation or Message
> > Endpoint Policy Subjects [WS-PolicyAttachment].
> >
> > WS-PolicyAttachment [WS-PolicyAttachment] defines both abstract
and
> > concrete attachment points in WSDL [WSDL1.1]. Because the RM
policy
> > assertion specifies a concrete behaviour, it MUST NOT be attached
to
> > abstract constructs:
> >
> > * wsdl:portType
> > * wsdl:portType/wsdl:operation
> > * wsdl:portType/wsdl:operation/wsdl:input
> > * wsdl:portType/wsdl:operation/wsdl:output
> > * wsdl:portType/wsdl:operation/wsdl:fault
> > * wsdl:message
> >
> > The RM policy assertion MAY be attached to the following constructs
> > * wsdl:service
> > * wsdl:port
> > * wsdl:binding.
> > * wsdl:binding/wsdl:operation
> > * wsdl:binding/wsdl:operation/wsdl:input
> > * wsdl:binding/wsdl:operation/wsdl:output
> > * wsdl:binding/wsdl:operation/wsdl:fault
> >
> > If the RM assertion is attached to the wsdl:service
> > construct, it MUST
> > be considered to apply to all the wsdl:port's referenced in
> > the binding.
> > If the RM assertion is attached to the wsdl:port construct,
> > it MUST be
> > considered to apply to all the wsdl:binding's referenced in the
port.
> > If the RM assertion is attached to the wsdl:binding
> > construct, it MUST
> > be considered to apply to all the wsdl:operation's referenced
in the
> > binding.
> > If the RM assertion is attached to the wsdl:operation
> > construct, it MUST
> >
> > be considered to apply to all the wsdl:input's, wsdl:output's
and
> > wsdl:fault's referenced in the operation.
> >
> > Attaching the RM assertion to a specific wsdl:input, wsdl:output,
or
> > wsdl:fault construct indicates that the RM protocol MUST be used
when
> > sending that message (or MAY if the assertion is marked optional).
> > Attaching the RM assertion to a specific wsdl:operation construct
> > indicates that the RM protocol MUST be used for all messages
(whether
> > input, output or fault) related to the operation(or MAY if
> > the assertion
> >
> > is marked optional).
> > Attaching the RM assertion to a specific wsdl:binding construct
> > indicates that the RM protocol MUST be used for all messages
(whether
> > input, output or fault) related to the binding (or MAY if the
> > assertion
> > is marked optional).
> > Attaching the RM assertion to a specific wsdl:port construct
> > indicates
> > that the RM protocol MUST be used for all messages (whether input,
> > output or fault) related to the port (or MAY if the assertion
> > is marked
> > optional).
> > Attaching the RM assertion to a specific wsdl:service construct
> > indicates that the RM protocol MUST be used for all messages
(whether
> > input, output or fault) related to the service (or MAY if the
> > assertion
> > is marked optional).
> >
> > WS-Addressing allows for policy assertions to be included within
an
> > EndpointReference. Per section 2.2 above, the presence of this
> > policy assertion in an EPR specifies the level of support for
> > WS-ReliableMessaging offered by that endpoint.
> > -------------------------------------------------------------------
> >
> > > -----Original Message-----
> > > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > > Sent: Wednesday, Feb 15, 2006 17:16 PM
> > > To: Paul Fremantle; Patil, Sanjay
> > > Cc: wsrx
> > > Subject: RE: [ws-rx] i021 proposal
> > >
> > > So where are we with this proposal now? Is the below text
in,
> > > out? Does
> > > it need to be revised in light of discussion to date? What
is the
> > > expectation for this issue on the call tomorrow? Discussion
> > to figure
> > > out the correct direction to refine this proposal seems
> > about right to
> > > me.
> > >
> > > Marc Goodner
> > > Technical Diplomat
> > > Microsoft Corporation
> > > Tel: (425) 703-1903
> > > Blog: http://spaces.msn.com/mrgoodner/
> > >
> > >
> > > -----Original Message-----
> > > From: Paul Fremantle [mailto:paul@wso2.com]
> > > Sent: Thursday, February 09, 2006 3:04 AM
> > > To: Patil, Sanjay
> > > Cc: wsrx
> > > Subject: Re: [ws-rx] i021 proposal
> > >
> > > Sanjay
> > >
> > > You are right. The proposal isn't yet fully clear on the
meaning of
> > > attaching WS-RM to a message or operation.
> > >
> > > How about if the following text was added, before the EPR
text.
> > >
> > > Attaching the RM assertion to a specific wsdl:input,
> > wsdl:output, or
> > > wsdl:fault construct indicates that the RM protocol MUST
be
> > used when
> > > sending that message (or MAY if the assertion is marked
optional).
> > > Attaching the RM assertion to a specific wsdl:operation
construct
> > > indicates that the RM protocol MUST be used for all
> > messages (whether
> > > input, output or fault) related to the operation(or MAY
if
> > > the assertion
> > >
> > > is marked optional).
> > > Attaching the RM assertion to a specific wsdl:binding construct
> > > indicates that the RM protocol MUST be used for all
> > messages (whether
> > > input, output or fault) related to the binding (or MAY if
the
> > > assertion
> > > is marked optional).
> > > Attaching the RM assertion to a specific wsdl:port construct
> > > indicates
> > > that the RM protocol MUST be used for all messages (whether
input,
> > > output or fault) related to the port (or MAY if the assertion
> > > is marked
> > > optional).
> > > Attaching the RM assertion to a specific wsdl:service construct
> > > indicates that the RM protocol MUST be used for all
> > messages (whether
> > > input, output or fault) related to the service (or MAY if
the
> > > assertion
> > > is marked optional).
> > >
> > > You are also right about the EPR. I would recommend making
the EPR
> > > policy override the WSDL policy, but once again I think
this
> > > is an issue
> > >
> > > with the overall WS-Policy Framework (i.e. a general Policy
> > > issue not a
> > > specific RX issue).
> > >
> > > Thanks for your comments,
> > >
> > > Paul
> > >
> > > Patil, Sanjay wrote:
> > > > Comments inline ...
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Paul Fremantle [mailto:paul@wso2.com]
> > > >> Sent: Thursday, Feb 09, 2006 1:43 AM
> > > >> To: wsrx
> > > >> Subject: [ws-rx] i021 proposal
> > > >>
> > > >> Proposal regarding issue 021. I'm not quite sure
this is
> > > >> right yet, so I
> > > >> would appreciate feedback from the Policy experts.
> > > >>
> > > >> Based on CDII
> > > >>
> > > >> Delete 142-154 section 2.3 and replace with.
> > > >>
> > > >> 2.3 Assertion Attachment
> > > >>
> > > >> The RM assertion can have Service, Endpoint, Operation
> > or Message
> > > >> Endpoint Policy Subjects [WS-PolicyAttachment].
> > > >>
> > > >> WS-PolicyAttachment [WS-PolicyAttachment] defines
both
> > > abstract and
> > > >> concrete attachment points in WSDL [WSDL1.1]. Because
the
> > > RM policy
> > > >> assertion specifies a concrete behaviour, it MUST
NOT be
> > > attached to
> > > >> abstract constructs:
> > > >>
> > > >> * wsdl:portType
> > > >> * wsdl:portType/wsdl:operation
> > > >> * wsdl:portType/wsdl:operation/wsdl:input
> > > >> * wsdl:portType/wsdl:operation/wsdl:output
> > > >> * wsdl:portType/wsdl:operation/wsdl:fault
> > > >> * wsdl:message
> > > >>
> > > >> The RM policy assertion MAY be attached to the
following
> > constructs
> > > >> * wsdl:service
> > > >> * wsdl:port
> > > >> * wsdl:binding.
> > > >> * wsdl:binding/wsdl:operation
> > > >> * wsdl:binding/wsdl:operation/wsdl:input
> > > >> * wsdl:binding/wsdl:operation/wsdl:output
> > > >> * wsdl:binding/wsdl:operation/wsdl:fault
> > > >>
> > > >> If the RM assertion is attached to the wsdl:service
> > > >> construct, it MUST
> > > >> be considered to apply to all the wsdl:port's referenced
in
> > > >> the binding.
> > > >> If the RM assertion is attached to the wsdl:port
construct,
> > > >> it MUST be
> > > >> considered to apply to all the wsdl:binding's referenced
> > > in the port.
> > > >> If the RM assertion is attached to the wsdl:binding
> > > >> construct, it MUST
> > > >> be considered to apply to all the wsdl:operation's
> > > referenced in the
> > > >> binding.
> > > >> If the RM assertion is attached to the wsdl:operation
> > > >> construct, it MUST
> > > >> be considered to apply to all the wsdl:input's,
> > wsdl:output's and
> > > >> wsdl:fault's referenced in the operation.
> > > >>
> > > > It seems like your proposal allows for attachment of
RM
> > assertion at
> > > the
> > > > message level. In that case, wouldn't you also want
to specify the
> > > > behavior when the RM assertion is directly attached
to the
> > > wsdl:input,
> > > > wsdl:output or wsdl:fault constructs? Or is that semantic
somehow
> > > > derived from the above? I think the main question of
the
> > > issue i021 is
> > > > whether and how does RM assertion apply to the outbound
> > (I hate this
> > > > term) messages of an endpoint, and I don't see a clear
> > > answer to that
> > > > question in this proposal.
> > > >
> > > > There should also be statements for handling the case
where RM
> > > > assertions are attached to multiple subjects within
the
> > same scope.
> > > >
> > > >
> > > >> WS-Addressing allows for policy assertions to be
> > included within an
> > > >> EndpointReference. Per section 2.2 above, the presence
of this
> > > >> policy assertion in an EPR specifies the level
of support for
> > > >> WS-ReliableMessaging offered by that endpoint.
> > > >>
> > > > Since the previous text regarding the WSDL attachment
of RM
> > > assertion
> > > > covers the behavior of outbound messages also, there
may
> > possibly be
> > > > conflicts when both the techniques of associating policies
(WSDL
> > > > attachment and EPR inclusion) are used.
> > > >
> > > > -- Sanjay
> > > >
> > > >
> > > >> Paul
> > > >>
> > > >> --
> > > >>
> > > >> Paul Fremantle
> > > >> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > >>
> > > >> http://bloglines.com/blog/paulfremantle
> > > >> paul@wso2.com
> > > >>
> > > >> "Oxygenating the Web Service Platform",
www.wso2.com
> > > >>
> > > >>
> > > >>
> > >
> > > --
> > >
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://bloglines.com/blog/paulfremantle
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
> > >
> >
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]