Architectural Overview

The following sections provide an overview of WebLogic Web Services architecture and three types of WebLogic Web Service operations:

 

Overview of WebLogic Web Services Architecture

You develop a WebLogic Web Service, by using standard J2EE components, such as stateless session EJBs, and Java classes. Because WebLogic Web Services are based on the J2EE platform, they automatically inherit all the standard J2EE benefits, such as a simple and familiar component-based development model, scalability, support for transactions, life-cycle management, easy access to existing enterprise systems through the use of J2EE APIs (such as JDBC and JTA), and a simple and unified security model.

A single WebLogic Web Service consists of one or more operations; you can implement each operation using different back-end components and SOAP message handlers. For example, an operation might be implemented with a single method of a stateless session EJB or with a combination of SOAP message handlers and a method of a stateless session EJB.

 

Back-end Component Operation

The following figure describes the architecture of a WebLogic Web Service operation that is implemented with only a back-end component, such as a method of a stateless session EJB.

Figure 2-1 WebLogic Web Service with Back-end Component


Here is what happens when a client application invokes this type of WebLogic Web Service operation:

  1. The client application sends a SOAP message request to WebLogic Server over HTTP. Based on the URI in the request, WebLogic Server identifies the Web Service being invoked.
  2. The Web Service reads the SOAP message request and identifies the operation that it needs to run. The operation corresponds to a method of a stateless session EJB or a Java class, to be invoked in a later step.
  3. The Web Service converts the operation's parameters in the SOAP message from their XML representation to their Java representation using the appropriate deserializer class. The deserializer class is either one provided by WebLogic Server for built-in data types or a user-created one for non-built-in data types.
  4. The Web Service invokes the appropriate back-end component method, passing it the Java parameters.
  5. The Web Service converts the method's return value from Java to XML using the appropriate serializer class, and packages it into a SOAP message response.
  6. The Web Service sends the SOAP message response back to the client application that invoked the Web Service.

 

Back-end Component and SOAP Message Handler Chain Operation

The following figure describes a WebLogic Web Service operation that is implemented with both a SOAP message handler chain and a back-end component.

Figure 2-2 WebLogic Web Service Operation with Back-end Component and SOAP Message Handler Chain


Here is what happens when a client application invokes this type of WebLogic Web Service operation:

  1. The client application sends a SOAP message request to WebLogic Server over HTTP. Based on the URI in the request, WebLogic Server identifies the Web Service being invoked.
  2. The Web Service reads the SOAP message request and identifies the operation that it needs to run. The operation in this case corresponds to a SOAP message handler chain followed by a method of a stateless session EJB or a Java class, to be invoked in later steps.
  3. The Web Service invokes the appropriate handler chain. The handler chain accesses the contents of the SOAP message request, possibly changing it in some way.
  4. The Web Service converts the operation's parameters in the [possibly modified] SOAP message from their XML representation to their Java representation using the appropriate deserializer class. The deserializer class is either one provided by WebLogic Server for built-in data types or a user-created one for non-built-in data types.
  5. The Web Service invokes the appropriate back-end component method, passing it the Java parameters.
  6. The Web Service converts the method's return value from Java to XML using the appropriate serializer class, and packages it into a SOAP message response.
  7. The Web Service invokes the appropriate SOAP message handler chain. The handler chain accesses the contents of the SOAP message response, possibly changing it in some way.
  8. The Web Service sends the [possibly modified] SOAP message response back to the client application that invoked the Web Service.

 

SOAP Message Handler Chain Operation

The following figure describes the architecture of a WebLogic Web Service operation that is implemented with only a SOAP message handler chain.

Figure 2-3 WebLogic Web Service Operation with SOAP Message Handler Chain Only


Here is what happens when a client application invokes this type of WebLogic Web Service operation:

  1. The client application sends a SOAP message request to WebLogic Server over HTTP. Based on the URI in the request, WebLogic Server identifies the Web Service being invoked.
  2. The Web Service reads the SOAP message request and identifies the operation that it needs to run. The operation in this case corresponds to an invoke of a SOAP message handler chain, to be invoked in the next step.
  3. The Web Service invokes the appropriate handler chain. The handler chain accesses the contents of the SOAP message request, possibly changing it in some way.
  4. The Web Service invokes the appropriate handler chain. The handler chain creates the SOAP message response.
  5. The Web Service sends the SOAP message response back to the client application that invoked the Web Service.

Skip navigation bar  Back to Top Previous Next