axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Davis <...@us.ibm.com>
Subject Re: MConnection MEP
Date Tue, 04 Nov 2008 12:18:30 GMT
sounds like this may require some basic changes to axis2 itself - this 
could be a good time to move MC out from under the RM code and allow 
non-RM users access to it.  We're already testing this in WS-I's RSP 
testing (yes with MSFT) so having axis2 support it too would be a good 
thing, IMO.

thanks
-Doug
______________________________________________________
STSM  |  Web Services Architect  |  IBM Software Group
(919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com



Thomas McKiernan <MCKIERNA@uk.ibm.com> 
11/04/2008 06:23 AM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
sandesha-dev@ws.apache.org, axis-dev@ws.apache.org
Subject
Re: MConnection MEP






Hi Doug,
Sorry I was being a bit confusing there. The replyTo isn't really an 
issue. What I really meant, but did not express at all well, is that we 
need "replyTo" data to be present in the application msg flow so that the 
response can be tied up with the MConnection msg.
So this means that to use makeConnection with RM I believe that we also 
need WS-A, but the replyTo does not specifically have to be set in the MC 
msg itself, just in application msgs.

As I say I'm ok with tagging the MC msg as a special oneWay msg. It is 
also worth pointing out that MConnection msgs can cause faults (missing 
selection criteria) and these also need to be returned. 
The main point I was making is that axis2 code seems to forbid faults 
coming back on the back channel of 1-way messages so simply making the 
MConnection msg a 1-way breaks our ability to send these faults.

Many thanks,
Thomas

----------------------------------
Thomas McKiernan

WebSphere Messaging Development,
IBM United Kingdom Limited

Internal Phone: 248241 
External Phone: +44 (0)1962 818241
Mobile: +44 (0)789 1737497
Email: MCKIERNA@uk.ibm.com

Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21 
2JN


Caminante, no hay camino 
Se hace camino al andar.
("Walker, there is no path; the path is made by walking.")  Antonio 
Machado



From:
Doug Davis <dug@us.ibm.com>
To:
Thomas McKiernan/UK/IBM@IBMGB
Date:
04/11/2008 11:09
Subject:
Re: MConnection MEP




Tom, 
 are you suggesting that the MC msg contains a replyTo ?  While it _may_, 
it is not required to do so.  And in fact, if it is there it should be 
ignored by the MC Receiver in the non-faulting cases.  For example, if it 
contains a wsa:Address value of http://www.ibm.com then MC will still work 

just as expected. 

IMO, MC should be a true one-way msg but the MC Receiver should tag the 
connection as a special MC one. Then right before it sends back a 202 
(because there should be no msg to return) it detects that its special and 

checks the MC Queue to see if there's a msg that should be sent back 
instead of the 202. 

thanks
-Doug
______________________________________________________
STSM  |  Web Services Architect  |  IBM Software Group
(919) 254-6905  |  IBM T/L 444-6905  |  dug@us.ibm.com 


Thomas McKiernan <MCKIERNA@uk.ibm.com> 
11/04/2008 05:52 AM 


To
sandesha-dev@ws.apache.org, axis-dev@ws.apache.org 
cc

Subject
MConnection MEP








Hi all,

Some recent investigation has revealed that Sandesha2 treats a 
MakeConnection msg as a 2-way msg.
However, according to the MC spec this is not entirely correct:

"The MakeConnection element is sent in the body of a one-way message that 
establishes a contextualized back-channel..."

The time that this becomes an issue is when WS-A is involved. Obviously we 


need a replyTo for MC connection to be any use to us. However, by defining 


MConnection as a 2-way we find that WS-A will complain if there is no 
msgID present in the msg. 
This is causing interop issues, since there is really no requirement on 
there being a msgID in this case.

So our options are to define the msg as 1-way or to perform some sort of 
"ignore the WSA msgID restriction in this specific case" fix.

I'm happy with either. One issue with making the MConnection msg 1way is 
that this breaks the sandesha unit tests: we stop sending spec defined 
faults back (e.g. "missing selection criteria" etc) due to code in axis2 
org.apache.axis2.receivers.AbstractMessageReceiver which swallows the 
fault in the case of a one way MEP.
Can this be changed?

Any thoughts on this issue would be gratefully appreciated. 

Many thanks,
Thomas

----------------------------------
Thomas McKiernan

WebSphere Messaging Development,
IBM United Kingdom Limited

Internal Phone: 248241 
External Phone: +44 (0)1962 818241
Mobile: +44 (0)789 1737497
Email: MCKIERNA@uk.ibm.com

Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21 
2JN


Caminante, no hay camino 
Se hace camino al andar.
("Walker, there is no path; the path is made by walking.")  Antonio 
Machado





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU







---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org









Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








Mime
View raw message