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 [EMAIL PROTECTED] http://www.dankulp.com/blog
