Here are the lessons we learned from deploying a J2EE 1.4 Web Service:
Adding Web Services to your application doesn't have a huge impact on your server-side code, but it increases the complexity of your deployment.
If you already have a Stateless Session Bean, you only have to modify and add some XDoclet tags to expose its methods as Web Services.
Make sure that the Java classes you're using as parameters and return values follow the Java Beans conventions.
Java 2 Collections and arrays of custom data types are incompatible with Web Services, so wrap an array of custom data types in a Java Bean.
If your Web Service uses custom data types as parameters or return values, make sure you use JBoss 4.0.1sp1 or higher.
Set your Web Service URL to something meaningful in jboss.xml.
The tools that generate Web Services server-side deployment artifacts are still maturing.
XDoclet 1.2.3 has limited support for Web Services. Use XDoclet to:
Generate the <service-endpoint> element in ejb-jar.xml.
Generate the Service Endpoint Interface.%
Due to XDoclet's limitations, use JWSDP's wscompile tool to generate the JAX-RPC Mapping and WSDL files.
Check your Web Service deployment by viewing the JBossWS Page (http://localhost:8080/ws4ee) on your JBoss instance.
On the client side, use the WSDL to generate proxy and custom data type objects in your native programming language to communicate with a Web Service. Using WSDL-based client code tests the interoperability of your Web Service.
Even if you're using Java, using the Axis toolkit to invoke a Web Service gives you a simple, elegant Object Oriented interface that hides the low-level API calls.
If you're using Java 5, make sure you use Axis 1.2 or higher.