Table of Contents
This chapter describes the concepts of JEUS web services and supported specifications. It also introduces the configuration files, tools, and system variables for JEUS web services.
JEUS 8, which conforms to Java EE 7, supports JAX-WS. The most useful feature of JAX-WS is the implementation of POJO (Plain Old Java Object) web services. JEUS web services guarantee compatibility with vendors that are JavaEE 7 compliant.
The following figure shows the structure of JEUS web services.
-
Annotations and XML Configuration Files
JEUS web services use EJB or Java class for its business logic. An EJB runs inside the EJB container and Java classes run inside the web engine.
By using the annotations provided by Java SE 5, JEUS web services support the implementation of JAX-WS web services that are used to configure web service related settings. For backward compatibility, JEUS web services also support the JAX-RPC web service for configuring these settings in a web service deployment descriptor like webservices.xml.
-
Tools and Utilities
JEUS web services use the command line tool and Apache Ant tool to create and manage WSDL files and Java classes. The following sections explain how to use these tools.
Apache Ant 1.6.1 or later must be installed in order to use the Ant tool functions. Apache Ant can be downloaded from 'http://ant.apache.org'.
-
System Environment Variables
There are no special system environment variables for JEUS web services. The system environment variables described in "JEUS Web Engine Guide" and "JEUS EJB Guide" are sufficient for working with JEUS web services.
This section describes things to consider when designing web services.
Web service components are Java EE components that run in a web engine or an EJB container.
The following are the entities that can be published as a web service backend.
-
A Java class file runs in a web container. It's faster and easier to process tasks using Java classes than by creating an EJB.
Java class web service backend is a good choice when persistence, security, and transactions that are provided by an EJB container are not required.
-
An EJB is a programming model, which is good for any transaction-oriented systems, where a stateless session EJB runs in an EJB container.
An EJB is a good choice for implementing the business logic for efficiently managing transactions in those systems that require frequent DB updates or deletions.
An EJB backend can be a good choice as the web service backend even for non-transaction-oriented systems. A Container Managed Persistence (CMP) Bean is a good example of this. For more information regarding CMP bean, refer to JEUS Enterprise JavaBeans Guide.
As already stated, the existing business logic may be implemented as an EJB as needed (stateless session bean or CMP). If the business logic is already implemented as a stateless session bean, it is recommended to use stateless session bean web service backend to expose the existing EJB logic as a web service.
Since EJB web services usually allow only stateless session beans as a web service backend, CMP may seem not useful for web services. However, CMP business logic can be exposed as web services. This can be done by implementing a stateless session bean as the business logic interface for the CMP bean and exposing the stateless session bean as a web service. A stateless session bean web service backend can be a good choice because it provides the strength of the existing CMP business logic with added web service functionality.
JEUS web services support RPC-oriented and document-oriented information exchanges.
-
RPC-oriented Information Exchange
According to WSDL 1.1 specification, the parameters and return values are included in the SOAP message for RPC-oriented exchanges and XML documents are included for Document-oriented exchanges. In RPC-oriented exchanges, a message exchange in the Remote Procedure Call (RPC) mode, the client and server applications must be built using a well-defined programming model. The client invokes methods with parameters, and the server returns a single value as a response.
There are no restrictions on the number of parameters for an RPC-oriented operation.
-
Document-oriented Information Exchange
In document-oriented exchanges, when XML documents are exchanged, the content is interpreted by the client and server. Therefore, the restrictions on the body structure of the SOAP messages are not defined by SOAP. Instead, an application program or a separate XML schema determines the structure of an XML document of the SOAP body.
JEUS web services provide 2 types of Document-oriented information exchanges, standard document and document-wrapped.
The implementation of a web service can start out with a service endpoint or WSDL. Since each path has its own advantages, a developer can decide which path to take. They can be implementations of JAX-WS and JAX-RPC JEUS web services.
Starting with Web Service Endpoint
By starting out with creating a web service endpoint, developers can generate a WSDL file from it. This method has the advantages of an easy and intuitive implementation process. This enables a developer to develop service endpoint and implementation in a familiar environment without having to worry about interoperability with other platforms in a Java environment. The developer can then derive a platform independent WSDL from the Java codes.
JAX-WS and JAX-RPC provide guidelines on how to derive WSDL from service endpoints so that WSDL can be platform independent. This is the easiest method for developing web services for JAVA developers.
-
JAX-WS
The only thing to note about JAX-WS is that it does not require descriptions about service configurations. According to JAX-WS specification, a web service can be implemented using the wsgen toolkit without a service configuration file.
Web service implementation using the JAX-WS method is discussed in "Chapter 3. Implementing JEUS Web Services".
-
JAX-RPC
JAX-RPC requires descriptions about service configurations. JAX-RPC specification defines additional information on mapping Java to WSDL in detail. However, a service endpoint Interface alone can not generate a complete WSDL. Moreover, a service endpoint interface does not provide information on binding with a WSDL service. For implementing a JEUS web service, such information should be provided in the Java-to-WSDL toolkit by generating an additional configuration file.
JAX-RPC web service implementation is discussed in "Chapter 21. Implementing JAX-RPC Web Services".
Starting with WSDL
First create a WSDL file, and then generate web service Implementation from it.
Core objective of a web service is its interoperability with different platforms. This method is appropriate for generating interoperable service that is independent of the programming language. The platform's characteristics will be reflected in the WSDL generated from a web service implementation, leaning towards Java. The descriptions derived from a WSDL, on the other hand, are more neutral than the XML types and terms used for web service descriptions. This allows developers who are not familiar with the Java language to create a WSDL using general nomenclature.
However, it will require developers to have a deeper understanding of WSDL. JAX-WS web service implementation is discussed in "Chapter 3. Implementing JEUS Web Services", and JAX-RPC web service implementation is described in "Chapter 21. Implementing JAX-RPC Web Services".
A message handler needs to be created in order to directly handle the SOAP message's header, body, or attachment.
-
The handler framework can be used for JAX_WS. For more information, refer to "Chapter 7. Handler Framework".
-
In a JAX-RPC web service, a JAX-RPC standard handler for a SOAP message is created and SOAP with Attachments API for Java (SAAJ) is used to directly handle the message. For more information, refer to "Chapter 24. Creating SOAP Message Handler of JAX-RPC Web Service".