I'd advise you to wait until you see what some others have to say before
taking the following as gospel.

The simple front-end came over from XFire. When it was first invented in
XFire, JAX-WS probably didn't exist.  the Simple front-end went along with
the Aegis databinding, which provided XML configuration files for things
like parameter names. It provided useful services by default with no XML
files.

XFire eventually supported JAX-WS, but never completely.

CXF implemented JAX-WS in a way that is nearly, and, in fact possibly,
equally as convenient as Simple. Where the standard requires all sorts of
wrappers and such, CXF's JAX-WS will default just about everything.

When you look at things today, I would say that the Simple front end is just
not that much more simple than JAX-WS. Side-by-side, at worst, JAX-WS in CXF
probably requires one @nnotation (WebService), and perhaps not even that.

Over time, in XFire, there was a tendency to look to invent compatibility
with JAX-WS and JAXB by adding support for the corresponding annotations. As
you've discovered, we've still got some holes in there.

So, I'd say this: if you are willing to use @nnotations at all, I'd
recommend JAX-WS. I think that the only really compelling reason to use
Simple is to avoid them. But I may be missing something; I'm a bit of a
junior member of the firm here.



On Wed, Oct 1, 2008 at 8:14 PM, kpalania <[EMAIL PROTECTED]> wrote:

>
> I've started out using the Simple Frontend and it seems super-easy to
> expose
> existing APIs as web services with absolutely no annotations and/or WSDLs.
> Given this, it seems like a no-brainer to take this approach as opposed to
> using the JAX-WS Frontend. But, it can't be true, and I am clearly missing
> some pros of the JAX-WS approach.
>
> Would someone mind clarifying? When should we use one versus the other?
> --
> View this message in context:
> http://www.nabble.com/JAX-WS-Frontend-vs-Simple-Frontend-tp19771467p19771467.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>

Reply via email to