[Dev] New bundles. Big change.

[Brett Wooldridge]

You will now need the following two bundles:

org.ziptie.server.metro
org.ziptie.metro.client

This refactor touched a large number of bundles.  You should do a full
update (you can exclude TargetPlatform), perform a FULL clean, do not
operate machinery, may cause drowsiness, objects in mirror are closer than
they appear, depress tabs while turning, shake well, do not expose to open
flame, if irritation continues consult your physician, possible side-effects
include nose bleeds, blury or occluded vision, temporary loss of muscle
control, and dry mouth.

The skinny on these two bundles is that they represent the reference
implementation of the JAX-WS (Google, take first hit) specifications, better
known as jax-ws ri.  It is now providing us with our SOAP implementation.

You can stop reading now, but here¹s the backstory on ³Why Sun Metro?²:

We reached the limits of Axis 1 in this release when we wanted to use the
same objects for Hibernate as well as the SOAP interfaces.  Both require
simple beans, however there were attributes we needed in Hibernate that
should not travel across the wire on SOAP.  JAX-WS is a specification for
Web Services annotations that gives us the flexibility to use the same
objects for both Hibernate and SOAP but exclude certain attributes from the
wire.  There is actually a whole array of very useful annotations.
Additionally, all JAX-WS projects with any credibility use StAX (Streaming
XML API) parsing which provides significant performance improvements over
Axis 1 as well as a better memory profile.

The decision on which JAX-WS implementation to pick was essentially between
three contenders: Apache Axis 2, Apache CXF (formerly Celtix and XFire, now
merged under Apache), and Sun Metro.  Several failed starts at integrating
Axis 2 into OSGi sent us looking elsewhere.  Poking around forums trying to
figure out Axis 2 lead me to Apache CXF.  Apache CXF is a merger to two
projects, XFire and Celtix.  XFire at Codehaus was a JAX-WS effort, and
Celtix at Objectweb ‹ home of Quartz and JOTM ‹ was an Enterprise Service
Bus (ESB) that ventured into Web Services.  Both projects merged under the
Apache banner and renamed CXF.  Celtix brings to the table corporate support
from IONA in Ireland, a formerly big player in the late 90¹s in the CORBA
(Common Object Request Broker Architecture) space, now a player in the ESB
space.  As a result, the CXF project is very vibrant and has a very active
mailing list where response times are typically measured in hours if not
minutes.

Integration of CXF into OSGi was fairly straightforward, taking only a day
or two where Axis 2 had left me cold at a similar point.  However, when
working with the tooling supplied with CXF ‹ used to generate WSDL from Java
interfaces and to generate client stubs from WSDL ‹ some of the shine came
off of CXF.  That¹s not quite true, as some of the shine had come off before
then.  CXF is fairly large and uses Spring heavily.  Even though the
developers will tell you it can be run without Spring, this is an exercise
left to the reader and is similar to saying that you can remove 30% of
what¹s under the hood of your car and still have a running engine if you
want.  These two things are related ‹ the tooling and Springiness ‹ because
when you run the tool to generate the WSDL (for example) it appears to bring
up the entire CXF framework, initialized rather slowly by gobs of Spring,
only to then generate the file and exit.  We have the need to generate at
least 7 WSDL files, with the number growing by the day.  There was some
other weirdness that I won¹t bore you with about having to run the
generation twice and turning a blind eye to reams of error messages that
seem to not affect the output.

While searching the interwebs for information about tweaking the CXF
generated bindings I came across the Sun Metro project ‹ the reference
implementation of JAX-WS.  Sun Metro made all the promises of CXF: StAX
parsing, standards compliant, yada yada.  Integration of Metro into OSGi was
deceptively simple.  I say deceptively because some of the classloading
issues didn¹t rear their head until late in the game.  However, the tooling
is good or rather it fails to suck ‹ about what you would expect but not
everything you would ever want -- which is fine.  But Metro comes without
all of the baggage of Spring ‹ and did I mention the ESB integrated into
CXF, which is way more than we need (or want)?  At some point, out of
curiosity and having both implementations sitting on my system I decided to
compare their sizes:

$ du ­sh apache-cxf-2.0-incubator
34MB

$ du ­sh jaxws-ri
8.5MB

That¹s not a small difference, and basically spurred me to overcome the
classloading issues.  Ultimately I was able to even shave libraries off of
jaxws-ri, so it now comes in at 6.9MB ‹ and there is probably another 1MB or
so that can be shaved still.

So, that¹s it.  In a fierce competition that soaked up waaay to much of my
precious time (5 days just for Metro, probably 10 in toto), we have a
winner.  Don¹t be surprised to see org.ziptie.server.cxf checked in though,
as I don¹t want to loose that work (just in case)...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20070811/9d3908da/attachment.html