Section 10.20. Final Thoughts on J2EE 1.4 Web Services

10.20. Final Thoughts on J2EE 1.4 Web Services

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.

  • Create webservice.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.

• If you're using J2SE 1.4, use Axis 1.1.