Developing and Deploying Java Class Web Services - XML

Creating Web services from Java classes is a straightforward process. The class must have one or more methods that a servlet running under Oracle9iAS Web services can invoke. This invocation happens when a client of that Web service calls the corresponding Web service method. This ection discusses the theory and issues involved in creating Web services out of Java classes for Oracle9iAS.

Oracle9iAS Web services support two types of implementations for Java classes running as Web services:

  • Stateful Java implementation. For this type, Oracle9iAS Web services allow a single Java instance to serve the Web service requests from an individual client.
  • Stateless Java implementation. For this type, Oracle9iAS Web services create multiple instances of the Java class in a pool. You can use any one of the instances from the pool to service a request. After servicing the request, the object is returned to the pool for use by a subsequent request.

To deploy a Java class Web service, you need to package a J2EE .ear file that includes the required files and deployment descriptors. You also need to make some modifications in the web.xml file and package the Java class file into a .war file.

To use a Java class as a Web service, you need to add a <servlet> entry and a corresponding <servlet-mapping> entry into web.xml. The resulting web.xml file is assembled as part of a J2EE .war file that is included in the .ear file, which defines the Web service. Following is the syntax for these tags:

Adding these tags allows the Oracle9iAS Web services servlet to access the Java class for the Web service.

The following list presents the servlet tags and the tags under them:

  • <INIT-PARAM>.This tag contains a name value pair in <param-name>and <param-value>. The Web services servlet definition requires at least one <param-name>with the value class-name and a corresponding <param-value> set to the fully qualified name of the Java class used for the Web service implementation.

An optional <param-name> with the value session-timeout and a corresponding <param-value> set to an integer value in seconds specify the timeout for the session. This optional parameter only applies for stateful Java Web services. The default value for the session timeout for stateful Java sessions, in which no session timeout is specified, is 60 seconds. An optional <param-name> with the value interface-name and a corresponding <param-value> set to the fully qualified name of the Java interface specify the methods to include in the Web service. This init parameter tells the Web service servlet generation code which methods the Web service should expose. If the parameter interface-name is not included in the <servlet> definition, then all public methods in the class are included in the Web service.

  • <SERVLET-CLASS>. This tag takes the value for all stateless Java Web services and for all stateful Java Web services.
  • <SERVLET-NAME>. This tag specifies the name for the servlet that runs the Web service.

Here is an example of a sample web.xml file:

After the web.xml file is modified, add the Java class, which provides the functionality of the Web service, and any other support files to a .jar file either under WEB-INF/classes or WEBINF/ lib.

To add Web services based on Java classes, you need to include an application.xml file and package the application.xml and .war file containing the Java classes into a J2EE .ear file. Here is the code of a sample application.xml file:

After you have created the .ear file, your Web service is ready for deployment and use. From there, you can deploy the Web service as you would deploy any standard J2EE application that is stored in an .ear file (to run under OC4J).

Notice that we haven't really spoken of what tools to use for various tasks, such as creating the .ear file. That is because JDeveloper automates the whole process.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

XML Topics