ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Thomas Manes <>
Subject Re: footprint, modularity, pluggability, and LEGO blocks ... [Re: REQ: modular, small footprint, client side only SOAP Java impl? [Re: Apache.WebServices.Next?]]
Date Sun, 02 Nov 2003 23:50:54 GMT
I don't know of a core SOAP engine that is quite as modular as you're 
describing, but I think the basic extension architecture of Axis and of the 
JAX-RPC handler system in general is designed to support modular extensions 
to support security, reliability, transactions, etc.

I agree with you, though, that if you want the ability to custom-tailor the 
core SOAP engine (for example -- to build a highly optimized SOAP processor 
that can handle a particular subset of SOAP messages), you would need a 
much more modular design of the basic engine.


At 03:25 PM 11/1/2003, you wrote:
>Anne Thomas Manes wrote:
>>You might take a look at kSOAP -- it's a J2ME-based client.
>hi Anne,
>thanks for pointer (i know kSOAP author very well :-)).
>it looks like kSOAP is absolutely the best if minimal footprint *and* J2ME 
>functionality is required and it is open source!).
>i was thinking more in direction of modularity and ability to compose 
>desired functionality by pluggable modules (like LEGO ...) that are ready 
>to use and compose (not just that framework is extensible) so if you want 
>to use XML security or reliable messaging you just plug such module.
>however it seems that that to make this happen requires to think in such 
>way from beginning and maintain very strict policy on not creating 
>intermingled "spaghetti" of dependencies between modules. i wonder if you 
>know anybody experimented with such approach?
>>At 10:42 AM 10/30/2003, you 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.
>>>in AXIS requirements ( 
>>>there is identified need for "*A single SUPER TINY .jar file must be 
>>>enough for a client to communicate via SOAP*" but based on my recent 
>>>(and limited!) experience with extracting functionality from AXIS this 
>>>is very very difficult to do due to monolithic source tree (i do not 
>>>mind to be proven wrong!).
>>>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.
>>>i am very interested to learn about open source Java SOAP 
>>>implementations that are in such space (modular, small footprint, client 
>>>side only SOAP Java).
>>>as proof of concept i have built Web XML Services Utility Library that 
>>>currently has following modules:
>>>* common (no dependencies except for XML pull parsing API - currently 
>>>uses XPP3/XB1 for XML Infoset API)
>>>* http_client (depends on common)
>>>- provides basic HTTP 1.x client side support with simple HTTP 
>>>connection manager
>>>* http_server (depends on common)
>>>- provide basic HTTP 1.x server side support with simplified 
>>>Servlet-like API
>>>* invoker (depends on http_client)
>>>- allows simple invocation of service by sending XML on top of HTTP
>>>* processor (depends on http_server)
>>>- provides basic support for processing incoming XML over HTTP
>>>* dsig_globus (depends on common and security jar file from lib/dsig*)
>>>- provides XML digital signature and limited WS SEC support using Globus 
>>>Toolkit 3 grid proxy certificates
>>>(later: SOAP 1.1 Section 4 encoding (de)serialization support, small 
>>>footprint WSDL, dynamic invocations using WSDL, WS-RM, and other modules)
>>>client footprint for common + http_client + invoker is currently 40K jar 
>>>(+ 70K for XPP3).
>>>the previous version of this client side library is used in Xydra - An 
>>>automatic form generator for Web Services 
>>>( and was tested for last few 
>>>months so i am thinking about releasing it if there is enough interest. 
>>>to give you idea how it works here is small code snippet (interfaces 
>>>XmlElement, XmlDocument directly model XML Infoset Element and Document 
>>>Information Items and are implemented by XPP3/XB1):
>>>//construct XML
>>>XmlPullBuilder builder = XmlPullBuilder.newInstance();
>>>XmlElement request = builder.parseFragmentFromReader(
>>>new StringReader("<getNode><path>hello</path></getNode>"));
>>>// create XML service invoker
>>>HttpDynamicInfosetInvoker invoker = new HttpDynamicInfosetInvoker();
>>>// do actual invocation by wrapping message in SOAP 1.1 Envelope and 
>>>sending it over HTTP
>>>XmlDocument response = invoker.invokeSoap11(request);
>>>String r = builder.serializeToString(response);
>>>System.out.println("got back "+r);
>>>so let me know about other open source Java SOAP implementations that 
>>>are very modular and/or have good client side and i would like to hear 
>>>if there is need for such library (i noticed some interest in axis-dev 
>>>mailing list archives but i could not find any references to open source 
>>>toolkit only mentioned were GLUE and Wingfoot both not under Apache-like 
>>>Davanum Srinivas wrote:
>>>>Please review the latest proposals that we are working on. We can have 
>>>>a VOTE next week to start
>>>>the ball rolling for the following. As usual, feel free to sign up for 
>>>>anything you are interested
>>>>#1: WS-FX - umbrella for WS-* specification implementation
>>>>#2: WSS4J - WS-Security Implementation under WS-FX
>>>>#3: SANDESHA - WS-Reliability Implementation under WS-FX

>>>>Davanum Srinivas -
>>>If everything seems under control, you're just not going fast enough. 
>>>¬óMario Andretti
>If everything seems under control, you're just not going fast enough. 
>¬óMario Andretti

View raw message