[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
I thought about using Axis2 or XFire which is now CXF and bring that
in. I think the reason why I and maybe others thinks twice before
doing that is because these SOAP stacks are all soooo big. There are
always multiple Jars and the total size of a SOAP stack in JARs (only
the binary) is between 10MB and 15 MB. So getting that through IP is
certainly a task by itself.
Just FYI, the minimal CXF comes in at around 6MB:
512 wstx-asl-3.2.6.jar
32 geronimo-stax-api_1.0_spec-1.0.1.jar
200 geronimo-javamail_1.4_spec-1.3.jar
16 geronimo-annotation_1.0_spec-1.1.1.jar
36 geronimo-activation_1.1_spec-1.0.2.jar
60 commons-logging-1.1.1.jar
3976 cxf-2.1.3.jar
140 XmlSchema-1.4.2.jar
36 neethi-2.0.4.jar
84 xml-resolver-1.2.jar
48 geronimo-jaxws_2.1_spec-1.0.jar
20 saaj-api-1.3.jar
272 saaj-impl-1.3.2.jar
148 wsdl4j-1.6.2.jar
104 jaxb-api-2.1.jar
836 jaxb-impl-2.1.7.jar
and some of those jars are already in Orbit, or are
in the process of going in there, so the queue isn't
as daunting as you might think!
Why are these WS stacks so big? It's because they are
WS stacks :) When you are trying to get these things
out into the world, users look for awkward things like
standard APIs, standard XML bindings, schema validation,
WS-Policy processing, Attachment support, WSDL capabilities,
fast XML processing and that's really just the tip of
the iceberg. The WS-* frenzy of the late nineties and
early oughties has made these Web services stacks
obese.
Add to this JMS and Atom support, WSDL compilers and
JAXB compilers, Spring integration, and more, and CXF
tops up to a 26MB lib folder.
If you're looking to get a feel for what the footprint
looks like in terms of OSGi bundles, you should
check out the Distributed OSGi Reference Implementation
here:
http://cwiki.apache.org/confluence/display/CXF/Distributed+OSGi
--oh
