axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Best Practice
Date Tue, 16 Nov 2004 17:47:32 GMT

Due to a few issues generating the WSDL files from java code (in the area of 
custom exceptions mostly) I personal found the following approach suited me 

We already had the business class we wanted to expose as a web service so I 
originaly generated the WSDL from the java class. I then fixed the namespace 
problem in the WSDL where custom exceptions were thrown. We also had an issue 
with one of our clients wanting the parameters named as in our interface spec 
instead of arg0, arg1...argn as provided by the java2WSDL utility. This helps 
our client with his debugging problems (they use GLUE).

Within this initial WSDL I hand code changes and new methods directly into the 
WSDL and use the WSDL2Java utility to generate the service classes and transfer 
objects. I also put my WSDL into the classpath and modify the deploy.wsdd file 
to use this instead of the one generated by axis with the ?wsdl parameter.

The impl class is then modified by hand to delegate down to the underlying 
business class. This bit isn't to bad as the compiler will complain about 
missing methods or incorrect parameter types in the impl class.

Although this isn't a one shop stop I personally find it relatively easy this 
way. If I had another set of hands I would probably modify the source to do 
most of this work for me (except for the impl class, or maybe not :)

Just as a further note. Both WSDL2Java and Java2WSDL are utilities that are not 
part of the Axis runtime and as such require almost as much effort (maybe more) 
to keep upto date as far as possible with the specs. I take my hat off to the 
Axis team for their great work in this area allowing us at the coal face to be 
more productive. Without these utilities my work would be much harder.



> Thanks, Joe.
> I've had a quick glance through the mailing list, back a year, but 
> couldn't find anything obvious, in the best practice area.
> In this particular aspect, I prefer to work from Java. The way I see it, 
> I'm developing some business functionality, that might be usable in many 
> ways, not just as a web service. In developing the business function, 
> without any web services infrastructure, it can be kept clean and easily 
> testable. Once the function is sorted, expose it as a web service, using 
> Java2WSDL, some WSDL clean-up, WSDL2Java, with server side generation. 
> Then the web services implementation template can hook up to the business 
> functionality. Apart from the clean separation of business functionality 
> and web services infrastructure, there are some small mods one can make to 
> the WSDL and web service class, without needing to alter the business 
> class.
> Any more best practices anyone?
> Tony
> Funny you should ask this question.
> When I asked it about 6 months ago it spawned a week long thread that, 
> in my opinion never reached a conclusion. But, this is what I gathered 
> from it. There are three schools of thought when it comes to creating 
> Axis web services. 1) Start with a WSDL and generate your code from 
> that. 2) Start with a class and generate a WSDL so that you can generate 
> the WSDD. 3)Start with a JWS or message service that accepts a string 
> and parse it with Castor or some other xml binding engine. Remember each 
> one has it's own specific merits and drawbacks.
> 1) The WSDL approach; you start with a WSDL and it is rather simple to 
> create. Plus, it's the one location where you define your service. And 
> then everything gets generated. The drawback comes in when you add 
> future functionality, you end up regenerating things over and over 
> again. And if you've added any functionality to any of the generated 
> classes outside of the impl class, you have to be careful when doing 
> your generation, it will get over written.
> 2) The class approach; you start with a class, I don't think there is an 
> easier starting point for java developers. You create your code and 
> expose it to the world using the WSDD's. The drawback of this is 
> generating the WSDD's. WSDD's are a little bit more complicated than 
> WSDL's. You could create them by hand, but it's more prone to error. And 
> to generate them you have to be pretty comfortable in ant, it can be 
> very hackish.
> 3) The String approach; I've never attempted using this approach but 
> there is a relatively popular article that recommends this. If you are 
> heavily invested into Castor or some other framework, I see the merits 
> of implementing this approach. Also, you theoretically could get by with 
> exposing only one service. The drawbacks of this, you're adding another 
> layer to an increasingly complex puzzle. Axis does all of the parsing 
> for you already, why add another layer?
> I couldn't tell you which technique is the most popular, I would say 
> that the WSDL and Class approaches are the most common and are split 
> fairly evenly. The people that I've have personally run into have used 
> the class approach exclusively. But, some of them were exposing EJB's so 
> take that with a grain of salt.
> As for books/documentation, keep waiting for an Axis specific book. None 
> exist show what you can really do with this technology. Most just 
> explain the architecture. One thing I have noticed though, version 1.2 
> documentation is way better than version 1.1.
> For tools, Mindreef SoapScope, is an excellent testing tool. Reads in 
> and validates WSDL's. You can also test the service by inputing data 
> into a form. I use this all the time. Cape Clear has a WSDL tool that 
> I've used a couple times. Very easy to create a WSDL from scratch.
> Axis is an excellent tool. It does have a lot of power in it and can be 
> used in just about any way you wish. But, like EJB and other distributed 
> technologies they need to be used where appropriate. Deciding where it's 
> appropriate is something that comes with experience not reading it from 
> somewhere.
> Have a great day,
> Joe Plautz

View raw message