It is a really bad practice to generate schema types from Java code.
Schema types are the essence of interoperability, and you should view
them as extremely valuable, reusable assets within your organization.
They should be modelled with care to ensure semantic integration
across numerous applications.
Contract-first is definitely the better way to go.
Anne
On 10/17/06, Vijesh A.V. <vijesh.av_at_emirates.com> wrote:
> Hi Vijay,
>
> Thanks for the response.
> I have seen your tech tip and benefited from it.
>
> My first reluctant attempt with code-first approach turned out to be a
> good experience. Except for a few things, in general it looks good. One
> concern is that in order to generate client artefacts service has to be
> deployed. In overcome this issue I am thinking of using "wsgen" after
> "apt" to generate wsdl then use that wsdl to generate client artefacts.
>
> The reason I wanted to go for contract first is because the application
> we are developing is the entity who define the service interface (so in
> web services it is wsdl) despite being the consumer of the services.
> Ours is an application which collates information from similar
> applications used in a particular business domain. Any company involved
> in this business can collaborate with us, provided they expose the
> services through web service which conforms to our wsdl. In this way our
> service invocation code will remain same and can use a common service
> locator, just a matter of changing address (hostname and port).
>
> You might be wondering why I am interested in both service and client
> deployment/code generation activities. Because one of the participating
> enterprise app servers happened to be ours.
>
> What I would like to do is: (We are using maven build system)
>
> Interface subproject (say interface.jar) : input artefact wsdl file. All
> data binding class files are generated through wsimport.
> Service subproject (wsservice.jar): input artefact is Impl file. Service
> related artefacts generated by using wsdl file and data binding classes
> in the interface.jar
> Client subproject (wsclient.jar) : no input artefact. All classes
> required in the client side will be generated by using the wsdl in
> interface.jar. Data binding classes need not be generated, since it is
> already there in interface.jar
>
> This way interface.jar will be used both in the server side and client
> side.
>
> Is it possible to generate only the data binding class files using
> wsimport?
>
> I guess in order to achieve the above, I have to do filtering when
> packaging the artefacts into the jar.
>
> Vijesh
>
>
> -----Original Message-----
> From: Vijay Ramachandran [mailto:Vijay.Ramachandran_at_Sun.COM]
> Sent: 16 October 2006 22:01
> To: users_at_jax-ws.dev.java.net
> Subject: Re: Contract First approach in JAX-WS 2.0
>
> BTW, for more information on moving your JAXWS-RI specific service to a
> portable one, refer to this :
> http://java.sun.com/developer/EJTechTips/2006/tt0429.html#1
>
> Hope this helps
>
> Vijay
>
> Vijay Ramachandran wrote:
> >
> >> I used JAX-WS 2.1 RI for Contract-First approach and it worked
> >> beautifully. This being non portable makes it less attractive. BTW,
> >> can I use this in production environment? If so, how much/what
> changes
> >> should I have to do to make it portable later?
> >
> > JAXWS2.1 will be available as part of GlassFish-V2 from build 24
> onwards.
> >
> >> I understand that portable JAX-WS can be developed/deployed in
> >> Glassfish. But it seems to be in favour of Code-First approach.
> >>
> >
> > That is not true - GlassFish treats both the same way.
> >
> >> Probably a foolish attempt:
> >> The same war created from JAX-WS RI is deployed in Glassfish after
> >> removing sun-jaxw.xml and web.xml (don't know this is a proper way,
> >> just an attempt). The server is not recognising the included wsdl,
> >> instead it is looking for one with the name MyClassImplService.wsdl
> >> (MyClassImpl being the endpoint implementation) !!!. I.e. as if the
> >> deployed war for code-first approach!!!
> >>
> >
> > This is because your service does not conform to JSR109 standard. Of
> > course, a JAXWS2.1-RI based service (with the sun-jaxws.xml) will work
>
> > as is on GF -but as far as GF is concerned, this is just a web app and
>
> > this service is not portable across JavaEE platforms. So you should
> > either use the same WAR that worked in stand alone JAXWS2.1RI or
> > develop a proper 109-based service.
> >
> >> What could've went wrong?
> >>
> >> Also I don't find any example/article about using contract-first
> >> approach in glassfish. I have a feeling that contract-first (top
> >> down) is not recommended in EE5 (or at least in Glassfish).
> >>
> >
> > That is not true - GF does not differentiate between the two
> >
> > Vijay
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
> > For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
>
>