You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Tom Jordahl <to...@macromedia.com> on 2003/10/30 16:59:12 UTC
RE: modular, small footprint, client side only SOAP Java impl? [R
e: Apache.WebServices.Next?]
Aleksander,
This sounds pretty cool. I think this would be a neat thing to have in the Apache Web Service projects.
We would want to position it carefully. i.e. if you just want to wrap some XML in SOAP and send it or read it, this is the library to use. If you want to do full web services, including WSDL and Serialization/Deserialization, Axis is the tool to use.
Does that sound right?
--
Tom Jordahl
Macromedia Server Development
-----Original Message-----
From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
Sent: Thursday, October 30, 2003 10:43 AM
To: general@ws.apache.org
Cc: axis-dev@ws.apache.org; axis-user@ws.apache.org
Subject: REQ: modular, small footprint, client side only SOAP Java impl? [Re: Apache.WebServices.Next?]
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
Re: modular, small footprint, client side only SOAP Java impl? [R
e: Apache.WebServices.Next?]
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Tom Jordahl wrote:
>This sounds pretty cool. I think this would be a neat thing to have in the Apache Web Service projects.
>
>
>We would want to position it carefully. i.e. if you just want to wrap some XML in SOAP and send it or read it, this is the library to use. If you want to do full web services, including WSDL and Serialization/Deserialization, Axis is the tool to use.
>
>Does that sound right?
>
>
this is i think exactly right approach to look on this.
in true open source and apache way give solution ot immediate problem,
allow people to use it, and accept improvements :-)
thanks,
alek
--
If everything seems under control, you're just not going fast enough. —Mario Andretti