xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Noel Gadreau <jngadr...@activcard.com>
Subject RE: Soap Provider classes need access to servlet data
Date Tue, 08 Aug 2000 22:37:12 GMT
I agree that one of the nice thing of the current implementation of the RPC
stuff is nice because the provider class does not need to know anything
about SOAP. So, just because of this I think the current implementation
needs to be there no matter what. This "ExtendedRPCCall" would be just
another way to perform the calls.
 
What I am trying to solve here is the following:
- I want to perform access control based on some permissions the user has.
So, using this context, I can extract this information, check the
permissions, and perform the service.
- My provider also needs to be able to log some information, but at this
level, it does not know who is performing the operation or from what IP it
comes from. What I was thinking is define a "log" method in the
EnvelopeContext (or in a subclass) and have the provider perform a
'log("doing this")'. Some information would be extracted from the context
and added by the logger so that what you really log is "<jean-noel
[192.168.1.2]> 'doing this' ...".
 
I am sure this solution is not perfect and I would welcome other solutions,
ideas,... that would help me work around this problem.
 
 
About the unmarshalling, I think the minimum unmarshalling you need is
lexical XML parsing (done by XML parser to get the DOM Document) and
validation of the Envelope. All the header entries and body entries are
still as Elements (that's actually how the Envelope.unmarshall works right
now). Then, you can process the headers separately from the body and you
won't need to unmarshall the body at that point. Is that what you have in
mind or am I missing something ?
 
 
Jean-Noel 
=============
Jean-Noel GADREAU
Software Engineer, ActivCard Inc.( http://www.activcard.com
<http://www.activcard.com/>  )
E-mail: jngadreau@activcard.com
Tel (main): 510-574-0100
Tel (direct): 510-574-1736

  

-----Original Message-----
From: Blaine Horrocks [mailto:blaine.horrocks@cp.net]
Sent: Tuesday, August 08, 2000 2:31 PM
To: soap-dev@xml.apache.org
Subject: Re: Soap Provider classes need access to servlet data


Jean-Noel Gadreau wrote: 

In my proposal, I was also mentionning a kind of "extended RPCCall" where
the class providing the service (like StockQuoteService) would take as first
parameter the "EnvelopeContext". This way, this class performing the service
can have access to all the information in the context. For instance, the
ExtendedStockQuoteService" could check if the user is authenticated and then
provide real-time quotes compared to delayed quotes for non-members. 
 

I have to say that I really *don't* like this approach.   It really makes it
difficult to share underlying application logic implementations between a
soap based api and another type of interface such as one based on
servlet/jsp based UI.   The present decoupling facilitates this reuse. 

I would also suggest that, going back to your original proposal, that the
unmarshalling of the entire Call, which you were trying to avoid, doesn't
necessarily follow from the  Envelope.unmarshall(payload) call.   It is
certainly feasible that the Headers could be unmarshalled and made available
by the envelope implementation separately from the Body.  Indeed the body
could be handled with some form of lazy unmarshalling code. 


$0.01 (not complete analysis but ...) 


Mime
View raw message