JEUS Web Services

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.

1. Basic Architecture

JEUS 9, which adheres to Jakarta EE 9, 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 Jakarta EE 8-compliant.

The following figure shows the structure of JEUS web services.

figure image003
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.

  • 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. Those described in JEUS Web Engine Guide and JEUS EJB Guide are sufficient for operating with JEUS web services.

2. Designing Web Services

This section describes considerations for designing web services.

2.1. Selecting a Web Service Backend

Web service components are Jakarta 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.

  • Java Class File

    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.

  • Stateless Session EJB

    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.

2.2. Document-oriented Communication

JEUS web services support document-oriented information exchange.

In document-oriented communication, 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 communications: standard document and document-wrapped.

Type Description

Standard document-oriented

Standard document-oriented web service operations take only one parameter, which is XML document.

Document-wrapped

Document-wrapped web service operations can take any number of parameters, but the parameter values are wrapped into one complex data type in the SOAP message.

2.3. Implementing Web Services

Typically, implementing 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 implementation of JAX-WS web service.

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 provides 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.

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 further discussed in Implementing JEUS 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 further described in Implementing JEUS Web Services.

2.4. Creating SOAP Message Handlers

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 Handler Framework.