Thanks for understanding Fred. I got into CXF when a vendor recommended
I use it. I was initially quite pleased with the quality of client-side
code it generated, you know, human-readable and all that. The footprint
issue only hit me later.
And of course I'm under the gun.
I can't help thinking that a minimum-footprint tool engineered for the
client side specifically, that generated client-side code of the same
quality as what CXF generates, would be a wonderful thing.
Web-Service Client-siders merely want to connect to someone else's web
service. They don't want the fuss, the muss, or the heavy footprint that
builders of the web services have to be concerned with by necessity. For
us, the web service is just a tool to do a particular job, like
Hibernate or Log4j. We tend to rebel when we're told about the
complexity that needs to happen "behind the scenes". "Shouldn't be my
problem", we think. We have our own server-side issues to worry about.
If it's impossible for CXF to be that kind of tool, what would you
recommend instead as the simple but high-quality SOAP-stack I'm looking for?
Steve
Fred Dushin wrote:
Steve, just so you understand, CXF is more than just another SOAP
stack. In contains a SOAP stack as a component, but it's "oh so much
more" than that. It may be that it provides too much for what you are
trying to do.
That being said, I do sympathize with your initial impression that the
amount of dependencies is overwhelming, and it would be an interesting
exercise to see how much the CXF "kernel" could be pared down to
having a minimal set of dependencies, and then allow you to bolt on
the parts that you need. The current distribution is a bit monolithic
in that sense ("here are all the jars; go for it"), but it's the tool
that launched this thread (maven) that is really what you should be
using to get your minimal set of dependencies; the internal maven
components are all quite modular.
Though note that there have been discussions on this forum that have
advocated for less granularity, than more ("I just want one jar file
-- what's so hard about that?"). Well it is hard, if you have version
x of lib y, but your customer needs to use version z, no ifs ands or
buts.
-Fred
