axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
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.


> 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
                    XmlDocument signedRequest =
                    XmlDocument response = super.invokeXml(signedRequest);
                    return response;
            // 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- 

        customizedProcessor = new HttpDynamicInfosetProcessor() {
            public XmlDocument processSoap11Envelope(XmlElement envelope)
                if(checkSignature) {
                    SignatureInfo si = 
                    if(!isAuthorized(si.getSubjectDn(), envelope)) {
                        XmlDocument fault = Soap11Util.generateSoap11Fault(
                            XmlConstants.SOAP11_NS, "Client", 
"unauthorized access");
                        return fault;
                XmlDocument respDoc =  
                if(signMessage) {
                    XmlDocument signedDoc =
                    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 

> 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.



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

View raw message