I guess a question that I have, when deploying into production, do most people actually deploy the service using the admin client? Or, do people deploy locally and take the server-config from that and put it into their war for production?
[EMAIL PROTECTED] wrote:
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
