Sounds like you really just need server-side
authentication and a server side handler. Also, not
sure how you are accessing http session, but I do
something similair via a Stateful session bean in
Jboss.
Also, I got deep into handlers due to security, and
one
project that may help you out is:
http://ws.apache.org/ws-fx/wss4j/
They probably have something for simple login, they
use Handlers pretty extensively. I wrote my own
Handlers because I started two years ago and they just
hit 1.0 .
Regarding your other question - the reason I'm on this
list is because I'm currently on a project that chose
Sun style RPC before I came on. Here's an article -
can't find the link now - that compares Sun Web
services to Axis and helped me out:
WSDL Client
The key issue for WSDL stub-skeleton based
systems, as illustrated with the MessageObject service
being used in this discussion, is to substitute the
following core statements:
MessageObjectService service = new
MessageObjectServiceLocator();
localhost.MessageObject port =
service.getMessageObject();
msg = port.getMessage();
for
String endpoint =
"
http://localhost:8888/axis/MessageObject.jws";
Service service = new Service();
Call call = (Call) service.createCall();
call.setTargetEndpointAddress( new
java.net.URL(endpoint) );
call.setOperationName(new
QName("
http://soapinterop.org/", "getMessage") );
msg = (String) call.invoke( new Object[]{} );
The second sequence of code involves direct
interaction with the service through package-supported
generation of SOAP protocol messages. It requires the
user to know the network address of the service, to
create the call, and to invoke it.
The first is based on RPC- or RMI-style access.
The Axis tools generate the ServiceLocator object from
the automatically generated WSDL for the service. The
locator is used to get a stub for the service which,
in turn, allows the client to call the desired method
of the service -- i.e., getMessage(). Here, the
client is not required to know the network address of
the service or to perform the call by creating the
service, getting a call object, and then invoking the
method through it.
However, the WSDL-based stub-skeleton approach
does exactly what the SOAP approach does, only all of
the paraphernalia to do so is generated automatically.
In the example code below, the calling sequences are
shown to map from the RPC-like code shown at the top
to its SOAP implementation, resembling the code shown
at the bottom..
HTH,
iksrazal
--- Edoardo Causarano <curious.corn_at_katamail.com>
wrote:
> At the moment I use a remote call to login,
> initialize and populate
> an HttpSession. All methods that refer to the
> Session data have to
> initialize local variables and check for the session
> validity. I'd
> like to put all this in the message context and
> place a single check
> in a Handler.
> I also have other methods that I originally defined
> in different
> ports but had to dump in a single one as they
> wouldn't share
> HttpSessions and I'm not very happy with this
> solution.
> I'd also like to zip the attachments without
> polluting the WSDL so
> I'd like to put a handler that transparently does
> the comp/
> docompression for me.
>
> With Axis Handlers were quite straightforward, but I
> can't seem to
> get the jwsdp dialect ;-) Is there some detailed
> documentation on the
> difference you pointed out?
>
> e
>
> Il giorno 06/giu/05, alle ore 18:14, trebor iksrazal
> ha scritto:
>
> > Do you want the Handler to intercept the
> > request/response on the client machine/container,
> the
> > request/response on the server machine/container,
> or
> > both?
> >
> > If its the client or both, you need code similair
> to
> > what you are doing.
> >
> > If its the server/both, you need a configuartion
> file
> > that the web service itself uses during
> configuration.
> > In this case, you would _not_ call
> HandlerRegistry,
> > because its encapsulated from the client.
> >
> > Keep in mind there are reasons to have a
> client/both
> > architecture, such as to digitally sign/encrypt
> the
> > data the client is sending to the web service, or
> log
> > all client traffic, etc.
> >
> > iksrazal
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail:
> users-help_at_jax-rpc.dev.java.net
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com