axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Services AOP way: using Java to weave handlers instead of XML [Re: REQ: modular, small footprint, client side only SOAP Java impl? [Re: Apache.WebServices.Next?]]
Date Sat, 01 Nov 2003 22:02:04 GMT
hi Steve,

see my comments inline below.

Steve Loughran wrote:

> Aleksander Slominski wrote:
>
>> replying to Dims' "Apache.WebServices.Next" post i would like to look 
>> on more fundamental question concerning Apache WS modularity: i am 
>> interested to find out if there is any interest in very modular, low 
>> footprint, Java SOAP implementation that is based around XML Infoset 
>> object model with XPath support.
>
>> i also think that on client side what is really required is just HTTP 
>> and doc/literal support, in other words to allow direct manipulation 
>> of XML, and there is no real need for sophisticated 
>> serialization/deserialization infrastructure.
>
>
> If you choose to live in a pure XML world, embracing xpath rather than 
> automatic bindings, then you could be a lot more svelte.

agreed.

> I think this could be interesting, especially if it works for 
> REST-style work as well as SOAP. But to do SOAP nicely you will soon 
> encounter the need to have a handler chain design, so you can plug in 
> client side implementation of header handlers.

i was thinking about it recently* a lot* and i am no longer sure that 
separation of deployment description (in XML or any config file or GUI 
tools) is such good idea for *all* applications.

i would like to be able to add header (or message) handlers directly 
when i write client or server side code and do it using Java mechanisms 
such as inheritance or objects composition.

so i am thinking along those lines that to extend functionality and to 
to add XML dsig module and WS-RM headers i could do this:

            // create XML service invoker and augments it with dsig and 
header handlers
            HttpDynamicInfosetInvoker invoker = new 
HttpDynamicInfosetInvoker() {
                public XmlDocument invokeXml(XmlDocument request)
                    throws DynamicInfosetInvokerException
                {
                    WSRMHandler.getInstance().augmentRequest(request);
                    XmlDocument signedRequest =
                        
SOAPEnvelopeSigner.getInstance().signSoapMessage(request);
                    XmlDocument response = super.invokeXml(signedRequest);
                    
SOAPEnvelopeVerifier.getInstance().verifySoapMessage(response);
                    WSRMHandler.getInstance().processResponse(response);
                    return response;
                }
            };
            invoker.setLocation("http://localhost:"+port);
            // do actual invocation by wrapping message in SOAP 1.1 
Envelope and sending it over HTTP
            XmlElement request = builder.parseFragmentFromReader(
                new StringReader("<getNode><path>/hello</path></getNode>"));
            XmlDocument response = invoker.invokeSoap11(request);

similarly on server side using inheritance to add pre- and post- 
interceptors.

        customizedProcessor = new HttpDynamicInfosetProcessor() {
            public XmlDocument processSoap11Envelope(XmlElement envelope)
            {
                if(checkSignature) {
                    SignatureInfo si = 
SOAPEnvelopeVerifier.getInstance().verifySoapMessage(envelope);
                    if(!isAuthorized(si.getSubjectDn(), envelope)) {
                        XmlDocument fault = Soap11Util.generateSoap11Fault(
                            XmlConstants.SOAP11_NS, "Client", 
"unauthorized access");
                        return fault;
                    }
                }
                WSRMHandler.getInstance().processRequest(request);
                XmlDocument respDoc =  
super.processSoap11Envelope(envelope);
                WSRMHandler.getInstance().augmentResponse(respDoc);
                if(signMessage) {
                    XmlDocument signedDoc =
                        
SOAPEnvelopeSigner.getInstance().signSoapMessage(respDoc);
                    return signedDoc;
                } else {
                    return respDoc;
                }
            }



this approach is similar to using AOP advice on method pointcut so it 
could be automated by using AspectJ - i think it may be a neat way to 
develop SOA code in some cases :-)

> These could all be xpath based themselves, of course.

strong XPath support can make XML processing in Java much /less/ painful...

> Targeting Soap1.2 would make life simpler. Would you expect to go 
> doc/lit right from the outset; deny all rpc/enc support? That may 
> simplify a lot, at the risk of incompatibility. 

i am thinking about approaching it in a modular way - you can use 
rpc/enc module if you want or decide not to use it (and decrease memory 
footprint).

> Maybe the goal would be WS-I compliance only, no added features or 
> legacy support.

good idea.

> It'd be nice with a runtime that is an easy download into an applet or 
> java web start -i.e. lightweight and runs in a sandbox. 

that would be definitely a nice goal.

> Why, it might even make applets useful :)

one fully loaded HTML page with with images can easily be 150K so if 
applet is of similar size it should work OK.

thanks,

alek

-- 
If everything seems under control, you're just not going fast enough. --Mario Andretti


Mime
View raw message