|
Hi Doug,
I went through the code and for me, these changes
makes the life of RM and Security implementers much simple. Wish we had this
before.:)
One thing I noticed is the order of WSA, WSRM and
Security.
According to the code first we check WSA and then
perform the Security. Can we fix this order? I mean can there be situation where
the entire message is encrypted even the addressing headers?
However if this order fits to all the interop
requirement I think this should be the way how it should be and it will not add
any ambiguity to the user so that they need not worry about the order of these
QoSs.
I wish I can give it a try to fit Sandesha code to
this, but it will take some time with my time limits, but I am willing to give
it a hand if some one can takeover the task.
Thanks,
Jaliya
----- Original Message -----
Sent: Tuesday, February 14, 2006 8:30
AM
Subject: Re: Please revert this - and a
proposal
Hi Jaliya,
The code is under: https://svn.apache.org/repos/asf/webservices/axis/trunk/proposals/dug
If you look in AxisClient.java and
AxisServer.java you'll see the spots where "rmImpl" is called,
these are the plug points. There are
three interfaces that an implementation needs to support:
void addRMHeaders(msgContext)
boolean
sendMessage(msgContext)
boolean processRMHeaders(msgContext)
I'm hoping to add documentation today to these methods but let me say a
few things now:
addRMHeaders - is
called for each outgoing message right before the transport chain is
called. This method is called to add
any piggy-backed Acks - note that this can
happen regardless of whether RM is used to send this particular
message. This method
should not
be used for anything other than Acks - the normal RM headers (seq) are
added
someplace else. Note, this
is also called in AxisServer for outgoing (response) messages.
sendMessage - this is the main entry
point into the RM code for sending messages. It is
expected to do whatever it takes to create a sequence
and send a message. In the most
trivial case it should send the CreateSeq, get the CreateSeqResponse,
add the Seq header
to the outgoing
message and then call AxisClient.invokeTransport() to actually send it.
Basically,
RM is now in total
control over when the transport is run - which makes sense since it may
need
to retry. The return value
from sendMessage() is a boolean indicating whether or not the RM code
actually took control - 'true' means 'yes' so
the AxisClient code should not attempt to run the
transport itself.
processRMHeaders - this is the server side equivalent of sendMessage().
Its job is to
accept the
incoming message, and if RM was used, it should then take control over when
the
rest of the engine is invoked -
this is because due to persisting of messages or InOrder
processing it may need to wait quite a while before the
service is actually run. Note that even
when the incoming message was not sent using RM (ie, no Seq header) it
may still contain
Acks so those will
need to be looked for and processed no matter what. The return value
of
this method is a boolean that
indicated whether or not the normal engine flow should be used
to process the message. 'true' means
that processRMHeaders detected it was an RM message
so it took control (and will call
engine.invokeService() itself), 'false' means that RM was not used
to send this message so the normal flow can
just continue.
I'll write more
later today to explain how the security plug points can be used with this.
Those are
important for RM since
its possible that the security context will need to be established before
the
RM CreateSeq but it also needs to
be used within the RM CreateSeq element.
thanks,
-Doug
| "Jaliya Ekanayake"
<[EMAIL PROTECTED]>
02/13/2006 03:21 PM
|
Please respond
to
"Jaliya Ekanayake" |
|
|
To
| Doug
Davis/Raleigh/[EMAIL PROTECTED]
|
|
cc
| <[email protected]>
|
|
Subject
| Re: Please revert this
- and a proposal |
|
Hi Doug,
Could you please send me the svn link for the branch where you have the
plug points for RM.
If possible please
point me to the new additions as well.
I would like to see how Sandesha can make use of
these plug points.
Thanks,
Jaliya
----- Original Message -----
From: Doug
Davis
To: [email protected]
Sent: Monday, February 13, 2006 10:16 AM
Subject: Re: Please revert this - and a proposal
Done - apologies for not explaining
this a bit more in the svn commit... the changes that Dims
is referring to are the couple of
lines in the AxisEngines that make calls out to RM code
and Security code. These do not
assume any particulat implementation choice - they
are totally pluggable. In
principle I agree that doing these things as handlers would be
the way to go, however, in
working with these specs I've found that when you start to
look at their requirements it shows
that the handlers can't really meet their needs.
To elaborate a bit on the requirements
that makes using handlers more than a little
difficult, they include things like:
- clearly being able to rerun
the transport chain for each RM retry is required
- being able to rerun it w/o having to
run the other chains is key in scenarios where we
have a DB
persistence and the client is restarted
- need to be able to piggy-back RM headers on
outgoing messages even on messages
that are not sent using RM
- need to be able to add new
RM headers on each retry since the list of Acks may have
changed
since the last retry
- security needs to be run after the RM headers have been added -
in all of the above cases
- the service and global chains should only be invoked once per
message - while I guess
this could be a design choice I haven't
seen anything to make me think that anything other
than the
transport chain should be rerun on RM retries - this means that things like
adding
RM headers or running security can not be on the service or
global chains since they are
only run once and not on each retry.
And of course putting them on the transport chains is
a bad
idea since they're transport independent.
- all of these types of things apply to both the
client and server since they're symmetrical.
As mentioned above, these changes
are only a couple of lines of code and, this is key,
they are optional. If people
would like to use an implementation that does not leverage these
new plug-points they are free
to do so. This means existing add-ons will not be influenced
by
these changes -
I've tried to ensure that during this work no one's existing code stops
working.
I'd be
interested in working with someone from the other ws projects to see if they
want to, or
could,
leverage them - I think they would benefit from it.
To that end I've revert all of the
changes of that commit, even thought most of them were unrelated
to the new plug-points, and
I'd like to propose this... I'll create a new branch in which to add
these
new plug-points so people can see them in their full context and to get a
better sense of
how they might work. Then we can see if it make sense to
move them into the trunk. Comments?
In the meantime, I'd like to complete the WSA
changes I started - I did figure out the issue I was
having earlier with the server-side
changes and have a fix for that (was part of this commit).
Is
there any
objection to me completing the server-side WSA changes?
thanks,
-Doug
|
