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 Aleksander Slominski <as...@cs.indiana.edu> on 2003/10/30 16:42:47 UTC
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: REQ: modular, small footprint, client side only SOAP Java impl?
[Re: Apache.WebServices.Next?]
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Alek,
I've been working on something similar based on my JiBX data binding
framework (http://www.jibx.org). The idea is to both reduce the size and
increase the speed of operation over a generalized framework such as
AXIS, since many applications don't appear to need the generality - they
just want something that can be used for *their* Web services. In tests
so far it looks like this type of approach will give major performance
benefits.
I'll try to take this further within the next couple of weeks and
release some code for people to try. Initially it'll require
hand-generated WSDL, but I'm hoping to add support for generating WSDL
from the mapping file and Java classes in the longer term.
- Dennis
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support - http://www.sosnoski.com
JiBX Lead Developer - http://www.jibx.org
Redmond, WA 425.885.7197
Aleksander Slominski 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/
>>
>>
>>
>>
>
>
>
>
Re: footprint, modularity, pluggability, and LEGO blocks ... [Re: REQ: modular, small footprint, client side only SOAP Java impl? [Re: Apache.WebServices.Next?]]
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>
> 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?
And maybe use BPEL to compose the modules to form a specific
SOAP engine? Cool! Let's do it ;-).
Sanjiva.
Re: footprint, modularity, pluggability, and LEGO blocks ...
[Re: REQ: modular, small footprint, client side only SOAP Java impl?
[Re: Apache.WebServices.Next?]]
Posted by 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
>
footprint, modularity, pluggability, and LEGO blocks ... [Re: REQ:
modular, small footprint, client side only SOAP Java impl? [Re: Apache.WebServices.Next?]]
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
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
Re: REQ: modular, small footprint, client side only SOAP Java
impl? [Re: Apache.WebServices.Next?]
Posted by Anne Thomas Manes <an...@manes.net>.
Alek,
You might take a look at kSOAP -- it's a J2ME-based client.
http://ksoap.enhydra.org/
Anne
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
>
Re: REQ: modular, small footprint, client side only SOAP Java impl?
[Re: Apache.WebServices.Next?]
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Alek,
I've been working on something similar based on my JiBX data binding
framework (http://www.jibx.org). The idea is to both reduce the size and
increase the speed of operation over a generalized framework such as
AXIS, since many applications don't appear to need the generality - they
just want something that can be used for *their* Web services. In tests
so far it looks like this type of approach will give major performance
benefits.
I'll try to take this further within the next couple of weeks and
release some code for people to try. Initially it'll require
hand-generated WSDL, but I'm hoping to add support for generating WSDL
from the mapping file and Java classes in the longer term.
- Dennis
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support - http://www.sosnoski.com
JiBX Lead Developer - http://www.jibx.org
Redmond, WA 425.885.7197
Aleksander Slominski 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/
>>
>>
>>
>>
>
>
>
>
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?]]
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
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
Re: REQ: modular, small footprint, client side only SOAP Java impl?
[Re: Apache.WebServices.Next?]
Posted by Steve Loughran <st...@iseran.com>.
Aleksander Slominski 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.
> 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. These could all be xpath based
themselves, of course.
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. Maybe the goal would be
WS-I compliance only, no added features or legacy support.
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. Why, it might
even make applets useful :)
Re: REQ: modular, small footprint, client side only SOAP Java impl?
[Re: Apache.WebServices.Next?]
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Alek,
I've been working on something similar based on my JiBX data binding
framework (http://www.jibx.org). The idea is to both reduce the size and
increase the speed of operation over a generalized framework such as
AXIS, since many applications don't appear to need the generality - they
just want something that can be used for *their* Web services. In tests
so far it looks like this type of approach will give major performance
benefits.
I'll try to take this further within the next couple of weeks and
release some code for people to try. Initially it'll require
hand-generated WSDL, but I'm hoping to add support for generating WSDL
from the mapping file and Java classes in the longer term.
- Dennis
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services Support - http://www.sosnoski.com
JiBX Lead Developer - http://www.jibx.org
Redmond, WA 425.885.7197
Aleksander Slominski 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/
>>
>>
>>
>>
>
>
>
>
Re: modularity and supporting SAAJ/JAX-RPC [Re: REQ: modular, small
footprint, client side only SOAP Java impl? [Re: Apache.WebServices.Next?]]
Posted by Steve Loughran <st...@iseran.com>.
Aleksander Slominski wrote:
> Ganga Sah wrote:
>
>> Alek,
>>
>> It will be nice if your implementation can support
>> SAAJ/JAX-RPC interface(eg. javax.xml.rpc.Service/Call)
>> to write portable SOAP client code.
>>
>>
> this /support/ dimension is greatly complicated by requirements that SUN
> puts to get JSR TCK compliance. it seems that only big organizations
> (and limited subset of Apache developers) can get hands on them and to
> be able to fulfill requirements to claim SAAJ or JAX-RPC support - do i
> miss something?
>
I think the current status (and I have the docs somewhere to find out
what it really is, but am writing this from memory are)
-Apache Axis has the rights to run the test kit for the SAAJ/JAX-RPC
(dont know about JAX-M)
-You have to be a member of the JCP to actually see the kits.
(a) If you are a full member of the Apache software foundation then you
get access to the TCK that way.
(b) If your employing organisation is a full member (IBM, Macromedia)
then you get it that way
(c) If you are an individual member then you can get it too
(d) Axis has to pass the tests before we release.
If you meet any of (a), (b) or (c) then you can get at the TCK tests. I
think I meet both (a) and (b), but have avoided getting hold of the
tests to date, though I should do it.
modularity and supporting SAAJ/JAX-RPC [Re: REQ: modular, small footprint,
client side only SOAP Java impl? [Re: Apache.WebServices.Next?]]
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Ganga Sah wrote:
>Alek,
>
>It will be nice if your implementation can support
>SAAJ/JAX-RPC interface(eg. javax.xml.rpc.Service/Call)
>to write portable SOAP client code.
>
>
this /support/ dimension is greatly complicated by requirements that SUN
puts to get JSR TCK compliance. it seems that only big organizations
(and limited subset of Apache developers) can get hands on them and to
be able to fulfill requirements to claim SAAJ or JAX-RPC support - do i
miss something?
anyway i think that strong and simple to use XML message support
(including SOAP doc/literal support) is way more important regardless of
API as what matters is what goes on the wire ...
thanks,
alek
>thx
>ganga
>--- Aleksander Slominski <as...@cs.indiana.edu> 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
>>
>>
>>
>>
>
>
>__________________________________
>Do you Yahoo!?
>Exclusive Video Premiere - Britney Spears
>http://launch.yahoo.com/promos/britneyspears/
>
>
--
If everything seems under control, you're just not going fast enough. —Mario Andretti
Re: REQ: modular, small footprint, client side only SOAP Java impl? [Re: Apache.WebServices.Next?]
Posted by Ganga Sah <ga...@yahoo.com>.
Alek,
It will be nice if your implementation can support
SAAJ/JAX-RPC interface(eg. javax.xml.rpc.Service/Call)
to write portable SOAP client code.
thx
ganga
--- Aleksander Slominski <as...@cs.indiana.edu> 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
>
>
__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/