Re: Apache.WebServices.Next?
I've modified the Wiki pages to account for a) the need for a general extensibility architecture before we start having too many extensions, and b) the fact that there are currently two WS-RM prototypes over Axis (probably three, counting Dug's! But we won't see that one :)). --Glen - Original Message - From: Davanum Srinivas [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 11:17 AM Subject: Apache.WebServices.Next? 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/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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(getNodepathhello/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?]
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(getNodepathhello/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
WSS4J Impl moved back to http://sf.net/projects/wss4j/
FYI. Just ran across the IPR statement from RSA Security to the WSS group at OASIS(http://lists.oasis-open.org/archives/wss/200309/msg00066.html). Am pulling back sources from axis' CVS to ensure that we don't step on anyone's toes. code is now at sf.net (http://sf.net/projects/wss4j/). Am being paranoid, let's stop using Apache resources and work offline till we WSS4J get official status at Apache and we get an official ok from RSA. Send me a private email if you need access to the sf.net cvs for wss4j. thanks, dims = Davanum Srinivas - http://webservices.apache.org/~dims/
