You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by Thomas McKiernan <MC...@uk.ibm.com> on 2008/11/04 11:52:11 UTC
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
Re: MConnection MEP
Posted by Amila Suriarachchi <am...@gmail.com>.
On Tue, Nov 4, 2008 at 4:22 PM, Thomas McKiernan <MC...@uk.ibm.com>wrote:
> 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.
I think the MakeConnection should not be used in Addressible client case.
Since server can initiate messages to the client.
So it is useful only in non addressable case.
It should handle in the same way we handle sequenceTerminate (RM 1.0) and In
only message cases.
Where send message is in only but the server writes a message to back
channel. At the client it read this response with the same thread and call
AxisEngine.receive().
Please see org.apache.axis2.transport.http.HTTPSender.java handleResponse
method.
Even this gets a fault it is written to the response properties to
msgContext or operationContext. So isn't it possible to handle this at RM
level as in other cases?
thanks,
Amila.
>
>
> 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
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: MConnection MEP
Posted by Amila Suriarachchi <am...@gmail.com>.
On Tue, Nov 4, 2008 at 4:22 PM, Thomas McKiernan <MC...@uk.ibm.com>wrote:
> 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.
I think the MakeConnection should not be used in Addressible client case.
Since server can initiate messages to the client.
So it is useful only in non addressable case.
It should handle in the same way we handle sequenceTerminate (RM 1.0) and In
only message cases.
Where send message is in only but the server writes a message to back
channel. At the client it read this response with the same thread and call
AxisEngine.receive().
Please see org.apache.axis2.transport.http.HTTPSender.java handleResponse
method.
Even this gets a fault it is written to the response properties to
msgContext or operationContext. So isn't it possible to handle this at RM
level as in other cases?
thanks,
Amila.
>
>
> 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
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: MConnection MEP
Posted by Doug Davis <du...@us.ibm.com>.
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 <MC...@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 <du...@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 <MC...@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
Re: MConnection MEP
Posted by Doug Davis <du...@us.ibm.com>.
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 <MC...@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 <du...@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 <MC...@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
Re: MConnection MEP
Posted by Thomas McKiernan <MC...@uk.ibm.com>.
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 <du...@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 <MC...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: MConnection MEP
Posted by Thomas McKiernan <MC...@uk.ibm.com>.
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 <du...@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 <MC...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org