Deploying Java Web Services

Introduction

Over the past few years, Web services have changed a great deal, as the World Wide Web CONSORTIUM,W3C has updated its core specifications and introduced new specifications to compensate for the initial flaws in Web services. The specification maintained by the Web Services activity team of the consortium handles the Web service as a set of XML specifications in a vendor-independent manner.

At the same time, java™community Process (JCP) is maintaining its own set of specifications to incorporate the recommendations of the consortium into the Java language. Java APIs for XML (JAX-RPC, JAXB, JAXP, JAXR, and SAAJ) is a set of interfaces that implement Web service specifications in the Java language.

The current Web service specification maintained by the JCP and the Java Web Services API maintained by the Consortium handle Web services on the "web" to ensure platform independence and language independence. Developers who follow the XML specification or use the Java API will ensure that applications can communicate with Web services written in any language on any platform using any communication protocol. Web services can extend access to any application and are validated as an integrated technology that is valuable to current web-based applications.

However, cross-network compatibility is not sufficient when web-based applications need to be deployed across multiple Web application containers (such as Ibm®websphere®application Server, BEA WebLogic, and Tomcat, where only three are indicated). For Java Web Services, the "Web.xml" of standard deployments that are not implemented across multiple Web application containers are available.

If you want your application to support Web service implementations provided by multiple Web application containers, the deployment of a Java Web service application can be a challenge. You can use a single Web service implementation in a Web application, such as axis from the Apache Web service project. For Web service clients, this policy can often work across multiple web containers because client code does not depend on any Web service deployment descriptor. For Web service providers (servers), if a Web service implementation is embedded in a Web application archive (Web application Archive,war) file, it can cause unexpected loader conflicts, so using a vendor's Web service implementation is the ideal deployment option.

The rest of this article discusses the deployment of Java Web Services, shows you various deployment descriptor implementations, and discusses how the Java community can begin to address this issue.

Development of a single Web service deployed across multiple containers

For Web application deployments, we want an open choice. If your customers invest in business Java EE implementations such as WebSphere or WebLogic, they will want to leverage their investment platform. On the other hand, if your customer wants to reduce initial cost of input, you may want to adopt an open source solution such as JBoss or Apache Tomcat. In both cases, if you want to maximize the reusability of your development work, you may not be able to rely on the available vendor-specific IDE. Developing with the IDE provided by the Java application vendor may limit the flexibility of the processing of a Web service, and hide many of the details of deploying it.

The example in this article builds a Web service deployment descriptor for each target Web application container using the free standard development toolset provided by the open source community. All of these tools are widely used by developers and support a wide range of open standards technologies.

Our goal is to obtain a single project capable of generating Web services that can be deployed using Axis across target Web application containers (WebSphere, WebLogic, JBoss, and Tomcat). The corresponding war file should be able to deploy to our target Web application container with minimal modification and no need to recompile the source code.

This article is not intended to be a tutorial on the deployment of Web services or Web services, but is intended to illustrate a problem with Java Web Services and to describe how you can handle the problem in the future. If you are using only one Web application container, and you do not intend to change the Web application container, you can skip the section on Web Services Metadata (JSR-181) (this JSR may affect your future development efforts).