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] i061 proposal / directions



Umit,

I hear you when you say I am preaching to the choir. However, I think it is important to
make it clear that the proposal in the WS-A is actually counter-productive, and in fact
is in and of itself a violation of the WS-I SSBP.

"support" of WS-I BP etc does not necessarily mean *to the exclusion of other functionality*
when it comes to a runtime or tooling product.

Many SOAP implementations still support SOAP encoding, despite the fact that the BP does not
allow its use. Developers have a choice (usually) as to whether the services they
develop/deploy will be WS-I BP conformant or not. They make that decision based
upon their interoperability requirements.The WS-I BP applies not to runtimes and tooling but
to deployed instances of a Web service. Nearly every Web services product/stack of which
I am aware supports both WS-I BP conformant and non-conformant behaviours and
gives the developer a means by which they can choose between the two options.

Once you toss WS-Addressing and WS-RM into the mix, strict WS-I BP conformance
is stretched to the limits anyway. First off, you'll get warnings about the use of non-sanctioned
extensions (addressing MAPs and RM header blocks). Secondly, as soon as you
use a non-anonymous wsa:ReplyTo, you are violating BP. Throwing in WSDL extensions
not specified in the BP is in violation of the BP, so the "solution" you suggest is itself
violating the BP!

Basic Profile was designed to improve interoperability of "basic" Web services. Some
compromises were made that unfortunately are inconsistent with more advanced
features. IMO, SOAP stacks that implement the more advanced functionality should
not be constrained by the BP *when those advanced features are employed*. This is not
inconsistent with the BP IMO because the services exploiting the more advanced
features are not "basic" Web services, and there is nothing preventing the same
runtime/tooling from performing in a manner consistent with the BP when developers
choose to do so.

I understand where you are coming from, but frankly, I maintain my position that
all this proposal will do is to weaken, not strengthen, interoperability because it
allows for too much optionality.

IMO, the WS-RM spec should in fact mandate that a conformant RMD MUST be capable
of flowing SeqAcks to a wsrm:AcksTo specifying the anonymous URI. I feel strongly that
it is that important to too many customers who need RM functionality and have firewall
policies in place that require it.

I suppose I could be convinced that the MUST above could be softened to a SHOULD,
but I would like to first see some compelling use cases as to examples when there is
good reason not to do so (and "we didn't modify our SOAP stack to enable it  is NOT a valid
answer:-)

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


"Yalcinalp, Umit" <umit.yalcinalp@sap.com> wrote on 01/19/2006 09:49:14 AM:

> Chris,

>  
> Please do not disregard that you are preaching to the choir here ;-)
>  
> The markup is only for those vendors who can not support the
> backflow. I was not suggesting that WS-RM should change its
> behaviour, but allow those who want to only support WS-I BP
> Compliant behaviour to support WS-RM. This is an interim solution
> that will allow vendors to move forward. Please DO note that I
> offered this as "a solution" not "the solution" for the tc.

>  
> I am glad that we are finally discussing the issue openly, thanks to
> Sanjay's suggestion.  

>  
> Cheers!
>  
> --umit
>  
>
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Wednesday, Jan 18, 2006 7:14 AM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i061 proposal / directions

>
> Umit,
>
> Please see my comments below.
>
> 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
>
> "Yalcinalp, Umit" <umit.yalcinalp@sap.com> wrote on 01/17/2006 07:36:32 PM:
>
> > Chris,
> >  
> > You think that we should not be constrained by WS-I BP conformance,
> > but WS-A discussion has been just the opposite. I note that there
> > has been a lot of discussion not to support the behaviour that has
> > been advocated by some of the vendors due to the incompatibility
> > introduced with WS-I BP 1.x. Especially in situations with request-
> > response with an non-anonymous reply endpoint and an anonymous
> > AcksTo, this specific use case is reduced to two one-way SOAP
> > exchanges. There has not been yet an agreement whether the HTTP
> > response may carry a SOAP Envelope and thus allow the
> > acknowledgement to appear. This is due to the fact that this
> > specific case ends up being modeled with two one-way "undefined"
> > SOAP one-way MEPs and thus depends on the assumptions on how the
> > one-way MEP is defined. I am quite sure that you have been following
> > the discussion in WS-A ;-)
>
> Nope, I haven't been following the discussions in WS-A. I have been
> following the discussions in XMLP and my point all along has been that
> the whole notion of an explicit or implicit relationship between
> the SOAP MEP and the WSDL (or higher-level) MEP is something to be
> avoided at all costs *especially* when one adds WS-Addressing into the
> mix.
>
> >  
> > IMO, if the specification assumes behaviour which contradicts other
> > specifications, it is preferable to state it explicitly. Better yet,
> > a special markup in the WSDL/Policy that indicates when the
> > assumption MAY NOT be supported:
>
> <Rolls eyes/>
>
> >  
> > My anology for this is the wsaw:UsingAddressing [1]
> > markup/assertion. It indicates that an endpoint engaged in WS-A
> > supports both anonymous and non-anonymous URIs as addresses of
> > response endpoints. The engagement of WS-RM may also assume a
> > similar semantic and use a similar approach.
> >  
> > We currently have wsaw:Anonymous element in WS-Addressing that
> > indicates whether anonymous URI as addresses of response EPRs are
> > allowed to fine tune the semantics of wsaw:UsingAddressing marker.
> > This element may have three different values,
> > "optional"/"required"/"prohibited".
>
> I've seen this much at least in the WS-A discussions and frankly, I find
> it suboptimal from an interoperability standpoint because it
> provides for too much optionality. IMO, stuff should "just work".
> It should not have to be configured differently depending upon
> what the other endpoint has or has not implemented. It only
> adds unnecessary complication.
>
> We are hearing from customers that an *important* use case for them
> is to be able to send a WSDL oneway message and receive the RM ack
> on the HTTP response. They either do not wish to, or cannot, expose
> a separate endpoint for receiving the RM acks.
>
> Providing a WSDL annotation such as you have described above
> might help in terms of informing the sending side what configurations
> are supported, but it doesn't help at all solve the problem when
> the HTTP response flow is the ONLY viable vehicle for the RM
> ack.
>
> >  
> > One option for us may be to indicate endpoints which could not
> > support anonymous URIs (AcksTo) with a "prohibited" value in
> > conjunction with the WS-RM policy assertion to indicate that
> > Anonymous Acks can not be sent on a backchannel. This will allow
>
> See above. Blech. This doesn't help customers to solve their
> problems. It only unnecessarily complicates matters.
>
> > those with WS-I BP semantics not to allow Acks to flow in the
> > backchannel as they may not be able to support it. This is a
> > possible option.  It will also force a non-anonymous AcksTo destination.
>
> See above. Not an option if the purpose is to solve customer problems.
> The WS-I BP is what it is, but that does not make it right. When
> the BPWG was deliberating this matter, I argued fiercely that it was
> a decision that the WG would later regret. Yet again, I get to say
> "I told you so" :-)
>
> If you ask me, all of this discussion of adding some psuedo-policy
> gunk is a cop-out that doesn't benefit the customer, it only benefits
> the vendor by allowing them to do as little as possible and still
> claim support for a standard while at the same time, diminishing
> the value of the standard as regards interoperability.
>
> >  
> > Note that the burden is on the vendor to make this additional
> > declaration when backflows are not supported, not the other way
> > around. This option also serves as "the caveat" as it formally
> > provides a definition as to when the backchannel can not be used.
>
> See above. This places no "burden" on the vendor. It's a cop-out. It
> places the
> "burden" on the *customer* who has to deal with unnecessary complication
> and who has to kludge up a sub-optimal work-around configuration when
> dealing with an endpoint that doesn't support sending a SOAP message
> on an available channel (the HTTP response flow) just because the WS-I
> BPWG made a foolish decision.
>
> I added the quote from The Matrix for a reason. We should make our own
> reality. We have a valid, and IMO compelling, use case that we seem
> to be throwing out with the WS-I BP bath-water.
>
> WS-I BP is what it is because its primary purpose was to facilitate
> interoperability of BASIC Web services that lacked an addressing
> component such as WS-Addressing. It has served its purpose well in
> that regard. However, as we seek to move beyond "Basic" Web services,
> I do not believe for a moment that we should be constrained to abide
> by the guidance of the WS-I BP.
>
> >  
> > I am not sure whether Gil was also going to suggest this possibility
> > for (1) in his proposal as we discussed the uses of this markup
> > during one of the WS-A concalls.
> >  
> > Since we are discussing options, I thought this should be put onto
> the table.
> >  
> > --umit
> >  
> > [1] http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-
> > wsdl.html?content-type=text/html;%20charset=utf-8
> >  
> > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > Sent: Tuesday, Jan 17, 2006 3:43 PM
> > To: Gilbert Pilz
> > Cc: ws-rx@lists.oasis-open.org
> > Subject: RE: [ws-rx] i061 proposal / directions
>
> >
> > I would point out that the SOAP1.2 specification actually REQUIRES
> > that there be a SOAP
> > envelope in both the request AND response flows of the SOAP/HTTP
> > binding for the
> > Request Response MEP. There is no formally defined oneway MEP
> > defined for SOAP1.2
> > and the XMLP WG is actually pursuing a strategy of amending the
> > Request Response
> > MEP such that the response SOAP envelope is optional, rather than
> > define a new MEP for
> > oneway.
> >
> > I would also point out that in all cases of interop of the WS-
> > Reliable Messaging spec, prior to
> > submission to this TC, implementations were interoperably exchanging
> > oneway messages
> > with acks on the HTTP response flow. I am unaware of any
> > implementations that were unable
> > to do this.
> >
> > I understand that many current SOAP stacks that offer WS-I BP
> > conformance do not
> > send a SOAP envelope in the response to a WSDL input only operation,
> > however, I don't think
> > that we should necessarily be constrained by that.
> >
> > Additionally, regardless of whether the RM spec says that an AcksTo
> > that carries the anon
> > URI means that SeqAcks flow on the HTTP response flow does not
> > require that an implementation
> > actually support that mode of operation. An RMD should be free (IMO)
> > to decline a
> > CS with an AcksTo of the anonymous URI if in fact it cannot support
> > sending SeqAcks on the
> > response to a oneway WSDL operation. As for the RMS, it would not
> > send a CS with an AcksTo
> > specifying the anonymous URI if it was unprepared to handle SOAP
> > envelopes sent in the
> > HTTP response to a WSDL oneway (unless it was a very confused
> > implementation:-)
> >
> > I think it is fine if the spec might include a caveat that indicated
> > that use of the anonymous URI
> > in AcksTo might not be supported in all implementations, but
> > personally, I would think that
> > the spec is fine as it stands.
> >
> > There is no spoon, Neo.
> >
> > Finally, it is not in the scope of the TC to specify a polling
> > mechanism. If someone is in need
> > of one of these, Doug has published one here:
> >
> >         http://www.w3.org/Submission/ws-polling/
> >
> > 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
> >
> > "Gilbert Pilz" <Gilbert.Pilz@bea.com> wrote on 01/17/2006 06:15:56 PM:
> >
> > > My main objection to the current proposal is that it requires the
> > > existence of a back-channel along the entire message path between the
> > > RMS and the RMD. I think most of us are aware of the sturm und drang
> > > around this issue (BP 1.1 says you don't have a back-channel [1], WS-A
> > > is currently entertaining a definition of "one way over SOAP 1.1" that
> > > precludes a back-channel [2], the WS-Addressing [3] and WS-Description
> > > [4] WG's have each asked the XMLP WG to define a one-way SOAP MEP and
> > > corresponding HTTP binding that may include a back-channel, etc.)
> > >
> > > Considering that the various specifications in this area are still in
> > > flux, I don't think we can presume any uniformity of implementations (in
> > > regards to one-way messages using SOAP 1.1) any time soon. That being
> > > the case I think it's a very bad idea for WS-RM to specify behavior that
> > > presupposes the existence of a back-channel in the case of one-way SOAP
> > > 1.1/HTTP.
> > >
> > > Its important to stress that I'm raising this argument as a *practical*
> > > matter. I'm not making any arguments about how one-way SOAP 1.1/HTTP
> > > *should* behave (nor do I think it is the function of the WS-RM TC to
> > > consider such arguments). I'm simply noting that, as of today, you can't
> > > make assumptions about how the underlying SOAP/HTTP stack will behave
> > > with regards to one-way messages and back-channels.
> > >
> > > I think that we should do the following instead:
> > >
> > > 1.) Note the circumstances under which the use of the anonymous URI for
> > > AcksTo may result in the inability of the RMS to receive
> > > acknowledgments.
> > >
> > > 2.) Specify a mechanism (synchronous polling via an empty SOAP body and
> > > an AckRequested header?) that allows the RMS to get the acknowledgements
> > > in cases where (1) pertains.
> > >
> > > I'll be sending out a more formal proposal for this tomorrow.
> > >
> > > - g
> > >
> > > [1]
> > > http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#One-Way_Op
> > > erations
> > >
> > > [2]
> > > http://lists.w3.org/Archives/Public/public-ws-addressing/2005Dec/att-008
> > > 0/ws-addr-wsdlProposedRevision1.62.html#wsdl11oneway
> > >
> > > [3]
> > > http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0003.ht
> > > ml
> > >
> > > [4] http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0060.html
> > >
> > > > -----Original Message-----
> > > > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > > > Sent: Monday, January 16, 2006 9:47 PM
> > > > To: Yalcinalp, Umit; Patil, Sanjay; Doug Davis
> > > > Cc: ws-rx@lists.oasis-open.org
> > > > Subject: [ws-rx] i061 proposal / directions
> > > >
> > > > Retitled to indicate topic better.
> > > >
> > > > The proposal is in the issue list already. Not sure if there
> > > > has been any updates to this one or not, I don't recall any.
> > > >
> > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > s.xml#i061
> > > >
> > > >
> > > > Marc Goodner
> > > > Technical Diplomat
> > > > Microsoft Corporation
> > > > Tel: (425) 703-1903
> > > > Blog: http://spaces.msn.com/members/mrgoodner/
> > > >
> > > > -----Original Message-----
> > > > From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
> > > > Sent: Monday, January 16, 2006 5:24 PM
> > > > To: Patil, Sanjay; Marc Goodner; Doug Davis
> > > > Cc: ws-rx@lists.oasis-open.org
> > > > Subject: RE: [ws-rx] Proposed list of issues for discussion
> > > > on the 1/19 conf-call
> > > >
> > > >  
> > > >
> > > > > -----Original Message-----
> > > > > From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
> > > > > Sent: Monday, Jan 16, 2006 4:58 PM
> > > > > To: Marc Goodner; Doug Davis; ws-rx@lists.oasis-open.org
> > > > > Subject: RE: [ws-rx] Proposed list of issues for discussion on the
> > > > > 1/19 conf-call
> > > > >
> > > > >
> > > > > Hi Marc,
> > > > >
> > > > > I don't remember having seen a clear and specific proposal on this
> > > > > issue yet. If I may have missed it, could you please point
> > > > me to the
> > > > > same.
> > > > >
> > > > > The current proposal in the issue text is more of a
> > > > discussion of the
> > > > > matter and alludes to different alternatives. For example, the
> > > > > proposal as it stands suggests two ways of deciding when to use a
> > > > > backchannel (in the case where the AcksTo EPR has anon
> > > > value) - a> EPR
> > > > > comparison, and
> > > > > b> correlation with sequence identifier.
> > > > >
> > > > > The proposal also assumes a particular disposition of the WS-I BP
> > > > > compliance issue about using a SOAP response on the backchannel for
> > > > > one-way messages. I am not sure if the entire TC has agreed to this.
> > > >
> > > > +1.
> > > >
> > > > Based on my experience/discussions in WS-A, it is not clear
> > > > to me whether there is yet a universal agreement to allowing
> > > > anonymous Acks on the backchannel since it will require a
> > > > SOAP envelope on the HTTP response just to be able to include
> > > > protocol headers.
> > > >
> > > > If the idea is to agree on this behaviour in this tc and push
> > > > the requirement elsewhere, that is an approach. Whatever we
> > > > do, however, we need to make sure that the protocol
> > > > requirements are "allowed" to be expressed since the stack
> > > > /the specs need to compose together. Even if we may decide to
> > > > break/extend the rules here, if it is prevented by the
> > > > baseline specs it will not be desirable. Hence, we can not
> > > > avoid taking WS-A/XMLP into account eventually.
> > > >
> > > > >
> > > > > I feel that the group needs to further discuss this issue on the
> > > > > mailing list first.
> > > >
> > > > >I am quite willing to approach the WS-A WG chair with a  formal
> > > > >requirement coming from the WS-RX TC once we discuss and  formulate
> > > > >succinctly our needs.
> > > > >
> > > > > Thanks,
> > > > > Sanjay
> > > >
> > > > --umit
> > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > > > > > Sent: Monday, Jan 16, 2006 16:18 PM
> > > > > > To: Patil, Sanjay; Doug Davis; ws-rx@lists.oasis-open.org
> > > > > > Subject: RE: [ws-rx] Proposed list of issues for
> > > > discussion on the
> > > > > > 1/19 conf-call
> > > > > >
> > > > > > When are we going to take on i061? Doug had a specific
> > > > proposal for
> > > > > > that one some time ago that did not depend on waiting on
> > > > another TC
> > > > > > or WG. My understanding is that Addressing was waiting on
> > > > XP. That
> > > > > > seems indirect enough that we shouldn't hold our breath,
> > > > should we
> > > > > > move on?
> > > > > >
> > > > > > Marc Goodner
> > > > > > Technical Diplomat
> > > > > > Microsoft Corporation
> > > > > > Tel: (425) 703-1903
> > > > > > Blog: http://spaces.msn.com/members/mrgoodner/
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
> > > > > > Sent: Monday, January 16, 2006 3:19 PM
> > > > > > To: Doug Davis; ws-rx@lists.oasis-open.org
> > > > > > Subject: RE: [ws-rx] Proposed list of issues for
> > > > discussion on the
> > > > > > 1/19 conf-call
> > > > > >
> > > > > >  
> > > > > > You are right. i085 (proposed-01 on 1/12 conf-call) was
> > > > resolved on
> > > > > > the last call itself.
> > > > > >  
> > > > > > Here is the updated proposed list of issues (i085
> > > > replaced by i082):
> > > > > >
> > > > > > a> i082 Level of "response message" unclear, for SequenceResponse
> > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > > s.xml#i082
> > > > > >
> > > > > > b> i086 Alternative approach for MaxMessage
> > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > > s.xml#i086
> > > > > >
> > > > > > c> i087 Acknowledgement Interval in CreateSequenceResponse
> > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > > s.xml#i087
> > > > > >
> > > > > > d> i075 Case of multiple RM Policies and DAs within an RMD scope
> > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > > s.xml#i075
> > > > > >
> > > > > > e> i083 Tom Rutt Fault Messages for Terminated Sequence
> > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > > s.xml#i083
> > > > > >  
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > >
> > > > > >    From: Doug Davis [mailto:dug@us.ibm.com]
> > > > > >    Sent: Monday, Jan 16, 2006 12:39 PM
> > > > > >    To: ws-rx@lists.oasis-open.org
> > > > > >    Subject: Re: [ws-rx] Proposed list of issues for
> > > > discussion on the
> > > > > > 1/19 conf-call
> > > > > >    
> > > > > >    
> > > > > >
> > > > > >    I might be remembering incorrectly but I thought we adopted the
> > > > > > proposal for i085 already (and I think the notes refelect that as
> > > > > > well).
> > > > > >
> > > > > >    -Doug
> > > > > >    
> > > > > >    
> > > > > >    
> > > > > >    
> > > > > >    "Patil, Sanjay" <sanjay.patil@sap.com>
> > > > > >
> > > > > >    01/16/2006 03:32 PM
> > > > > >
> > > > > >      
> > > > > >       To
> > > > > >       <ws-rx@lists.oasis-open.org>
> > > > > >       cc
> > > > > >      
> > > > > >       Subject
> > > > > >       [ws-rx] Proposed list of issues for discussion on the
> > > > > > 1/19 conf-call
> > > > > >
> > > > > >      
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >    The first three issues below are essentially the ones that we
> > > > > > accepted on the last call (1/12). The issues list is
> > > > currently being
> > > > > > updated and therefore the URLs for these three issues may become
> > > > > > active some time later today!
> > > > > >
> > > > > >    Thanks,
> > > > > >    Sanjay
> > > > > >
> > > > > >    A> i085 CloseSequence element is inconsistent
> > > > > >    
> > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > > s.xml#i085
> > > > > > <http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > > > es.xml#i08
> > > > > > 5>  
> > > > > >
> > > > > >    B> i086 Alternative approach for MaxMessage
> > > > > >    
> > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > > s.xml#i086
> > > > > > <http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > > > es.xml#i08
> > > > > > 6>  
> > > > > >
> > > > > >    C> i087 Acknowledgement Interval in CreateSequenceResponse
> > > > > >    
> > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > > s.xml#i087
> > > > > > <http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > > > es.xml#i08
> > > > > > 7>  
> > > > > >
> > > > > >    D> i075 Case of multiple RM Policies and DAs within an RMD scope
> > > > > >
> > > > > >    
> > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > > s.xml#i075
> > > > > > <http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > > > es.xml#i07
> > > > > > 5>  
> > > > > >
> > > > > >    E> i083 Tom Rutt        Fault Messages for Terminated Sequence
> > > > > >    
> > > > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > > > s.xml#i083
> > > > > > <http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > > > es.xml#i08
> > > > > > 3>  
> > > > > >
> > > > > >
> > > > >
> > > >


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