Re: footprint, modularity, pluggability, and LEGO blocks ... [Re: REQ: modular, small footprint, client side only SOAP Java impl? [Re: Apache.WebServices.Next?]]

[Anne Thomas Manes <an...@manes.net>]

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.

Anne

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.
>>http://ksoap.enhydra.org/
>
>
>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?
>
>thanks,
>
>alek
>
>>
>>At 10:42 AM 10/30/2003, you wrote:
>>
>>>hi,
>>>
>>>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 (http://ws.apache.org/axis/java/requirements.html) 
>>>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 
>>>(http://www.extreme.indiana.edu/xgws/xydra/) 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();
>>>invoker.setLocation("http://localhost:"+port);
>>>// 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 
>>>licenses).
>>>
>>>thanks,
>>>
>>>alek
>>>
>>>Davanum Srinivas wrote:
>>>
>>>>Folks,
>>>>
>>>>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
>>>>in.
>>>>
>>>>#1: WS-FX - umbrella for WS-* specification implementation
>>>>#2: WSS4J - WS-Security Implementation under WS-FX
>>>>#3: SANDESHA - WS-Reliability Implementation under WS-FX
>>>>
>>>>URL:
>>>>http://nagoya.apache.org/wiki/apachewiki.cgi?WebServicesProjectPages/WebServicesProjectProposals 
>>>>
>>>>
>>>>Thanks,
>>>>dims
>>>>
>>>>=====
>>>>Davanum Srinivas - http://webservices.apache.org/~dims/
>>>
>>>
>>>--
>>>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
>