Overview of WebLogic Web Services


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| Download Documentation \| Contact \| Glossary

\| WebLogic Server Doc Home \| Web Services \| Previous Topic \| Next Topic \| Contents \| Index \| View as PDF

The following sections provide an overview of Web services, and how they are implemented in WebLogic Server:

What Are Web Services?

Web services are a type of service that can be shared by and used as components of distributed Web-based applications. They commonly interface with existing back-end applications, such as customer relationship management systems, order-processing systems, and so on.

Traditionally, software application architecture tended to fall into two categories: huge monolithic systems running on mainframes or client-server applications running on desktops. Although these architectures work well for the purpose the applications were built to address, they are relatively closed to the outside world and can not be easily accessed by the diverse users of the Web.

Thus the software industry is evolving toward loosely coupled service-oriented applications that dynamically interact over the Web. The applications break down the larger software system into smaller modular components, or shared services. These services can reside on different computers and can be implemented by vastly different technologies, but they are packaged and transported using standard Web protocols, such as XML and HTTP, thus making them easily accessible by any user on the Web.

The concept of services is not new—RMI, COM, and CORBA are all service-oriented technologies. However, applications based on these technologies require them to be written using that particular technology, often from a particular vendor. This requirement typically hinders widespread acceptance of an application on the Web. To solve this problem, Web services are defined to share the following properties that make them easily accessible from heterogeneous environments:

Web services are accessed over the Web.
Web services describe themselves using an XML-based description language.
Web services communicate with clients (both end-user applications or other Web services) through XML messages that are transmitted by standard Internet protocols, such as HTTP.

Why Use Web Services?

The major reasons for using Web services are to gain:

interoperability among distributed applications that span diverse hardware and software platforms.
accessibility of applications through firewalls using Web protocols.
a cross-platform, cross-language data model (XML) that facilitates developing heterogeneous distributed applications.

Because Web services are accessed using standard Web protocols, such as XML and HTTP, the diverse and heterogeneous applications on the Web (which typically already understand XML and HTTP) can automatically access Web services, solving the ever-present problem of how different systems communicate with each other.

These different systems might be Microsoft SOAP ToolKit clients, J2EE applications, legacy applications, and so on. These systems might be written in a variety of programming languages, such as Java, C++, or Perl. As long as the application that provides the functionality is packaged as a Web service each of these systems can communicate with any other.

Web Service Components

A Web service consists of the following components:

An implementation hosted by a server on the Web.
WebLogic Web Services are hosted by WebLogic Server, are implemented using standard J2EE components (such as Enterprise Java Beans and JMS), and are packaged as standard J2EE Enterprise Applications.
A standardized way to transmit data and Web service invocation calls between the Web service and the user of the Web service.
WebLogic Web Services use Simple Object Access Protocol (SOAP) 1.1 as the message format and HTTP as the connection protocol. For a description of SOAP, see SOAP 1.1 with Attachments.
A standard way to describe the Web service to clients so they can invoke it.
WebLogic Web Services use Web Services Description Language (WSDL) 1.1, an XML-based specification, to describe themselves. For more information on WSDL, see WSDL 1.1.

SOAP 1.1 with Attachments

SOAP (Simple Object Access Protocol) is a lightweight XML-based protocol used to exchange information in a decentralized, distributed environment. The protocol consists of:

An envelope that describes the SOAP message. In particular, the envelope contains the body of the message, identifies who should process it, and describes how to process it.
A set of encoding rules for expressing instances of application-specific data types.
A convention for representing remote procedure calls and responses.

This information is embedded in a Multipurpose Internet Mail Extensions (MIME)-encoded package that can be transmitted over HTTP or other Web protocols. MIME is a specification for formatting non-ASCII messages so that they can be sent over the Internet.

The following example shows a SOAP request for stock trading information embedded inside an HTTP request:

POST /StockQuote HTTP/1.1
Host: www.sample.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"

<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
         SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
     <SOAP-ENV:Body>
          <m:GetLastStockQuote xmlns:m="Some-URI">
               <symbol>BEAS</symbol>
          </m:GetLastStockQuote>
     </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

WSDL 1.1

Web Services Description Language (WSDL) is an XML-based specification used to describe a Web service. A WSDL document describes the methods provided by a Web service, the input and output parameters, and how to connect to it.

Developers of WebLogic Web Services do not need to create the WSDL files; these files can be generated automatically as part of the WebLogic Web Services development process.

The following example, for informational purposes only, shows a WSDL file that describes the stock trading Web service StockQuoteService that contains the method GetLastStockQuote:

<?xml version="1.0"?>
  <definitions name="StockQuote"
               targetNamespace="http://sample.com/stockquote.wsdl"
               xmlns:tns="http://sample.com/stockquote.wsdl"
               xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
               xmlns:xsd1="http://sample.com/stockquote.xsd"
               xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
               xmlns="http://schemas.xmlsoap.org/wsdl/">
      <message name="GetStockPriceInput">
          <part name="symbol" element="xsd:string"/>
      </message>
      <message name="GetStockPriceOutput">
          <part name="result" type="xsd:float"/>
      </message>
      <portType name="StockQuotePortType">
          <operation name="GetLastStockQuote">
             <input message="tns:GetStockPriceInput"/>
             <output message="tns:GetStockPriceOutput"/>
          </operation>
      </portType>
      <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
          <soap:binding style="rpc" 
                        transport="http://schemas.xmlsoap.org/soap/http"/>
          <operation name="GetLastStockQuote">
             <soap:operation soapAction="http://sample.com/GetLastStockQuote"/>
             <input>
                 <soap:body use="encoded" namespace="http://sample.com/stockquote"
                           encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
             </input>
             <output>
             <soap:body use="encoded" namespace="http://sample.com/stockquote"
                           encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
             </output>
          </operation>>
      </binding>
      <service name="StockQuoteService">
          <documentation>My first service</documentation>
          <port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
             <soap:address location="http://sample.com/stockquote"/>
          </port>
      </service>
  </definitions>

WebLogic Web Service Features

This section discusses the features of the WebLogic Web Services subsystem:

Web Services Programming Model

The programming model describes how to implement, assemble, deploy, and invoke Web services that are hosted by a WebLogic Server. Apart from writing the Enterprise JavaBeans code that performs the actual work of the Web service, you develop most of the Web service itself by using a Java Ant task, called wsgen, that generates and packages the components of the Web service.

WebLogic Server supports two types of Web services: remote procedure call (RPC)-style and message-style.

RPC-Style Web Services

A remote procedure call (RPC)-style Web service is implemented using a stateless session EJB. It appears as a remote object to the client application.

The interaction between a client and an RPC-style Web service centers around a service-specific interface. When clients invoke the Web service, they send parameter values to the Web service, which executes the required methods, and then sends back the return values. Because of this back and forth conversation between the client and the Web service, RPC-style Web services are tightly coupled and resemble traditional distributed object paradigms, such as RMI or DCOM.

RPC-style Web services are synchronous, meaning that when a client sends a request, it waits for a response before doing anything else.

Message-Style Web Services

A message-style Web service is implemented using a JMS message listener, such as a message-driven bean, and must be associated with a JMS destination.

Message-style Web services are loosely coupled and document-driven rather than being associated with a service-specific interface. When a client invokes a message-style Web service, the client typically sends it an entire document, such as a purchase order, rather than a discrete set of parameters. The Web service accepts the entire document, processes it, and may or may not return a result message. Because no tightly-coupled request-response between the client and Web service occurs, message-style Web services promote a looser coupling between client and server.

Message-style Web services are asynchronous. A client that invokes the Web service does not wait for a response before it can do something else. The response from the Web service, if any, can appear hours or days later.

A client can either send or receive a document to or from a message-style Web service; the client can not do both using the same Web service.

SOAP 1.1 Implementation

WebLogic Server includes its own implementation of both the SOAP 1.1 and SOAP 1.1 With Attachments specifications that developers can use to create clients that invoke Web services.

RPC-style Web services use the SOAP 1.1 message format and message-style Web services use the SOAP 1.1 With Attachments message format.

Note: WebLogic Web Services currently ignore the actual attachment of a SOAP with attachments message.

Web Services Run-time Component

The WebLogic Web Services run-time component is a set of servlets and associated infrastructure needed to create a Web service. One element of the run-time is a set of servlets that handle SOAP requests from a client. You do not need to write these servlets; they are automatically included in the WebLogic Server distribution. Another element of the run-time is an Ant task that generates and assembles all the components of a WebLogic Web Service.

Standardized J2EE Web Services Assembly and Deployment

Web services developers use an Ant task, called wsgen, and the Administration Console to assemble and deploy Web services as standard J2EE Enterprise applications in an *.ear file. The *.ear file contains all the components of the Web service: for example, the EJBs, references to the SOAP servlets, the web.xml file, the weblogic.xml file, and so on.

Generation of the WSDL File

Developers that create clients that invoke a WebLogic Web Service need the WSDL that describes the Web service. WebLogic Server automatically generates the WSDL of a deployed Web service. You access the WSDL of a Web service through a special URL.

Java Client to Invoke a WebLogic Web Service

WebLogic Server can automatically generate a thin Java client that developers use to develop Java clients that invoke Web services. The Java client JAR file includes all the classes you need to invoke a Web service. These classes include the Java client API classes and interfaces, a parser to parse the SOAP requests and responses, the Java interface to the EJB, and so on. Client applications that use this Java client JAR file to invoke Web services do not need to include the full WebLogic Server JAR file on the client computer.

You download the Java client JAR file from the WebLogic Web Services Home Page. For detailed information on this Web page, see Invoking the WebLogic Web Services Home Page in Invoking WebLogic Web Services.

Note: BEA does not currently license client functionality separately from the server functionality, so, if needed, you can redistribute this Java client JAR file to your own customers.

Examples of Creating and Invoking Web Services

WebLogic Server includes examples of creating both RPC-style and message-style Web services and examples of both Java and Microsoft VisualBasic client applications that invoke the Web services.

The examples are located in the BEA_HOME/samples/examples/webservices directory, where BEA_HOME refers to the main WebLogic Server installation directory. The RPC-style Web service example is in the rpc directory and the message-style Web service example is in the message directory.

For detailed instructions on how to build and run the examples, invoke the Web page BEA_HOME/samples/examples/webservices/package-summary.html in your browser.

WebLogic Web Services Architecture

When you develop a WebLogic Web Service, you use standard J2EE components, such as stateless session EJBs, message-driven beans, and JMS destinations. Because WebLogic Web Services are based entirely on the J2EE platform, they automatically inherit all the standard J2EE benefits, such as a simple and familiar component-based development model, easy scalability, support for transactions, automatic 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.

WebLogic Server Web services are packaged as standard J2EE Enterprise applications that consist of the following specific components:

A Web application that contains, at a minimum, a servlet that sends and receives SOAP messages to and from the client.
Developers do not write this servlet themselves; rather, it is automatically included as part of the Web services development process.
A stateless session EJB that implements an RPC-style Web service or a JMS listener (such as a message-driven bean) for a message-style Web service.
In RPC-style Web service, the stateless session EJBs might do all the actual work of the Web service, or they may parcel out the work to other EJBs. The implementer of the Web service decides which EJBs do the real work. In message-style Web services, a J2EE object (typically a message-driven bean) gets the messages from the JMS destination and processes them.

WebLogic Web Services are packaged as Enterprise archive (*.ear) files that contain the Web archive (*.war) files of the Web application and EJB archive (*.jar) files.

The following two sections describe the architecture of RPC-style and message-style Web services.

RPC-Style WebLogic Web Services Architecture

Figure 1-1 illustrates the architecture of RPC-style WebLogic Web Services.

Figure 1-1 RPC-Style WebLogic Web Services Architecture

Here's what happens when a client invokes an RPC-style WebLogic Web Service:

A client sends a SOAP message to WebLogic Server over HTTP/HTTPS. The SOAP message contains instructions, conforming to the WSDL of the Web service, to invoke an RPC-style Web service.
The SOAP servlet designed to handle RPC SOAP requests (which is part of the Web application invoked by the client) unwraps the SOAP message envelope and uses the unwrapped information to identify the appropriate stateless session EJB target. This servlet then unmarshals the parameters, binds them into the appropriate Java objects, invokes the target stateless session EJB, and passes it the parameters.
The stateless session EJB might perform all the work of the Web service, or it might parcel out some or all of the work to other EJBs.
The invoked stateless session EJB sends return values, if any, back to the RPC SOAP servlet.
The RPC SOAP servlet marshals the return values from the stateless session EJB into a SOAP message, and sends it back to the client over HTTP/HTTPS.
If errors have occurred, the RPC SOAP servlet also sends a SOAP error message (called a SOAP fault) back to the client.

Message-Style WebLogic Web Services Architecture

Message-style Web services support a one-way communication; the client application either sends or receives a document to or from the Web service, but a single message-style Web service does not allow the client to do both. When you develop a message-style Web service, you specify whether the client sends or receives messages to or from the Web service. You can combine two message-style Web services, one for sending and one for receiving, in order to support round-trip communication. The same client can use both types, or either type, of service.

Figure 1-2 describes a possible architecture for both styles of message-style WebLogic Web Services working together.

Note: The dotted lines encapsulate two different message-style Web services. You do not have to use message-driven beans to take messages off the JMS destinations, although this is typically the best way to go.

Figure 1-2 Message-Style WebLogic Web Services Architecture

Here's what happens when a client invokes message-style WebLogic Web Services:

A client sends a SOAP message to WebLogic Server over HTTP/HTTPS. The SOAP message contains instructions, conforming to the WSDL of the Web service, to invoke a message-style Web service.
The messaging SOAP servlet that is part of the Web application invoked by the client unwraps the SOAP envelope, decodes the body of the message, and puts the resulting object on the appropriate JMS destination.
Note: In WebLogic Server 6.1 there is no support for accessing the contents of the attachments to the SOAP 1.1 With Attachments message.
The message sits in the JMS destination until the appropriate JMS listener (typically a message-driven bean) picks it up.
The message-driven bean picks up the message from the JMS destination. The message-driven bean might do all the work of the Web service, or it might parcel out some or all of the work to other EJBs.
The message-driven bean sends the resulting document to another JMS destination that is associated with a separate message-style Web service that is configured to allow clients to receive messages.
The messaging SOAP servlet associated with the second Web service picks up the message from the JMS destination.
The messaging SOAP servlet sends the document back to the client when the client invokes the second receive Web service.

This sample architecture shows two message-style Web services working together to get and send back information to the client. Note that the client has to invoke two message-style Web services.

SOAP and WSDL Features Not Supported by WebLogic Web Services

The following SOAP features are not supported by WebLogic Web Services:

the Header element - this means that you cannot set or get SOAP Header elements using the WebLogic Web Services client API. Additionally, the internal WebLogic Web services runtime ignores the SOAP Header; it only handles the SOAP Body.
the SOAP attachment

The following WSDL features are not supported by WebLogic Web Services:

the import element
the element attribute of the part element

Editing XML Files

When creating or invoking WebLogic Web services, you might need to edit XML files, such as the EJB deployment descriptors, the Java Ant build files, and so on. To edit these files, BEA provides the BEA XML Editor, an entirely Java-based XML stand-alone editor.

The BEA XML Editor is a simple, user-friendly tool for creating and editing XML files. It displays XML file contents both as a hierarchical XML tree structure and as raw XML code. This dual presentation of the document provides you with the following two methods of editing the XML document:

The hierarchical tree view allows structured, limited constrained editing, providing you with a set of allowable functions at each point in the hierarchical XML tree structure. The allowable functions are syntactically dictated and in accordance with the XML document's DTD or schema, if one is specified.
The raw XML code view allows free-form editing of the data.

BEA XML Editor can validate XML code according to a specified DTD or XML schema.

For detailed information about using the BEA XML Editor, see its on-line help.

You can download the BEA XML Editor from the BEA dev2dev.