You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by kpalania <kp...@yahoo.com> on 2008/10/02 02:14:34 UTC
JAX-WS Frontend vs Simple Frontend
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.
Re: JAX-WS Frontend vs Simple Frontend
Posted by Glen Mazza <gl...@gmail.com>.
One advantage of JAX-WS is that it is portable to other web service stacks,
primarily GlassFish Metro.
Glen
kpalania 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-tp19771467p19781834.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JAX-WS Frontend vs Simple Frontend
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 01 October 2008, kpalania 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?
Well, the main advantage, of course, is that it's completely standards
based and is thus portable. Applications written purely to JAX-WS
should run unaltered with Metro or JBoss's JAX-WS implementation or
others. Of course, most reasonably complex applications have to go
outside of the spec for things like configuration, security, etc... and
then end up getting slightly tied to an implementation anyway.
The major differentiator between jaxws and the simple frontend, however,
is the controllability and reproducability of the resulting "contract".
The simple binding doesn't provide that as easily or reliably.
For example, if you want to control the namespaces or service names, or
even parameter names, that's very easy to do with jax-ws by specifying
the right value in the right annotation. With the simple frontend, you
would actually need to right some code (ServiceConfiguration object) and
wire that in.
JAX-WS frontend is also ahead of the simple frontend in a few areas.
JAX-WS can handle "multiple out" and "in/out" params (via Holders) where
the simple frontend does not. It can also handle Soap w/Attachments
and soap headers. Finally, currently, if you need request specific
context, that's only available in the jaxws frontend. (there is a JIRA
to push that down a layer)
The "tooling" aspect is another issue. The wsdl2java tool is obviously
geared toward jax-ws. There is eclipse tooling in the works for jaxws.
Etc...
--
J. Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: CXF & POJO WebService Server & Clien
Posted by Benson Margulies <bi...@gmail.com>.
The proxy factory will hand you back a proxy class that uses your pojos. It
will do this based on the @nnotations on the SEI, which you will identify as
the service class.
On Thu, Oct 2, 2008 at 10:38 PM, Coder One <co...@yahoo.com> wrote:
> How do say when I call this WebService, use these pojos from this package?
> I need to tell CXF where my pojos are in addition to the WSDL right?
>
> Thanks,
>
> --- On Thu, 10/2/08, Benson Margulies <bi...@gmail.com> wrote:
>
> > From: Benson Margulies <bi...@gmail.com>
> > Subject: Re: CXF & POJO WebService Server & Client
> > To: users@cxf.apache.org, coder_lol@yahoo.com
> > Date: Thursday, October 2, 2008, 5:01 AM
> > Certainly. Pass the WSDL URL into the service factory
> > instead of using the
> > Dynamic client.
> >
> > On Wed, Oct 1, 2008 at 10:23 PM, Coder One
> > <co...@yahoo.com> wrote:
> >
> > > I created a number of POJOs and exposed them as a
> > webservice with
> > > CXF/Spring. For example
> > >
> > > BasicService.java (exposed as WebService with CXF)
> > > User.java
> > > Company.java
> > >
> > > I also let CXF generate the WSDL for me. On the
> > client side, rather than
> > > consuming the WSDL and auto-generate the beans, well,
> > I already have the
> > > beans, can I somehow "link/map" the
> > auto-generated WSDL to the existing
> > > beans from which the WSDL was generated to start with?
> > >
> > > Thanks,
> > >
> > >
> > >
> > >
> > >
> > >
> > >
>
>
>
>
>
Re: CXF & POJO WebService Server & Client
Posted by Coder One <co...@yahoo.com>.
How do say when I call this WebService, use these pojos from this package? I need to tell CXF where my pojos are in addition to the WSDL right?
Thanks,
--- On Thu, 10/2/08, Benson Margulies <bi...@gmail.com> wrote:
> From: Benson Margulies <bi...@gmail.com>
> Subject: Re: CXF & POJO WebService Server & Client
> To: users@cxf.apache.org, coder_lol@yahoo.com
> Date: Thursday, October 2, 2008, 5:01 AM
> Certainly. Pass the WSDL URL into the service factory
> instead of using the
> Dynamic client.
>
> On Wed, Oct 1, 2008 at 10:23 PM, Coder One
> <co...@yahoo.com> wrote:
>
> > I created a number of POJOs and exposed them as a
> webservice with
> > CXF/Spring. For example
> >
> > BasicService.java (exposed as WebService with CXF)
> > User.java
> > Company.java
> >
> > I also let CXF generate the WSDL for me. On the
> client side, rather than
> > consuming the WSDL and auto-generate the beans, well,
> I already have the
> > beans, can I somehow "link/map" the
> auto-generated WSDL to the existing
> > beans from which the WSDL was generated to start with?
> >
> > Thanks,
> >
> >
> >
> >
> >
> >
> >
Re: CXF & POJO WebService Server & Client
Posted by Benson Margulies <bi...@gmail.com>.
Certainly. Pass the WSDL URL into the service factory instead of using the
Dynamic client.
On Wed, Oct 1, 2008 at 10:23 PM, Coder One <co...@yahoo.com> wrote:
> I created a number of POJOs and exposed them as a webservice with
> CXF/Spring. For example
>
> BasicService.java (exposed as WebService with CXF)
> User.java
> Company.java
>
> I also let CXF generate the WSDL for me. On the client side, rather than
> consuming the WSDL and auto-generate the beans, well, I already have the
> beans, can I somehow "link/map" the auto-generated WSDL to the existing
> beans from which the WSDL was generated to start with?
>
> Thanks,
>
>
>
>
>
>
>
CXF & POJO WebService Server & Clients
Posted by Coder One <co...@yahoo.com>.
I created a number of POJOs and exposed them as a webservice with CXF/Spring. For example
BasicService.java (exposed as WebService with CXF)
User.java
Company.java
I also let CXF generate the WSDL for me. On the client side, rather than consuming the WSDL and auto-generate the beans, well, I already have the beans, can I somehow "link/map" the auto-generated WSDL to the existing beans from which the WSDL was generated to start with?
Thanks,
Re: JAX-WS Frontend vs Simple Frontend
Posted by Benson Margulies <bi...@gmail.com>.
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 <kp...@yahoo.com> 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.
>
>