![]() |
![]() |
|
|
| |
Overview of WebLogic Web Services
The following sections provide an overview of Web services, and how they are implemented in WebLogic Server:
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:
The major reasons for using Web services are to gain:
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.
A Web service consists of the following components:
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.
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.
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 (Simple Object Access Protocol) is a lightweight XML-based protocol used to exchange information in a decentralized, distributed environment. The protocol consists of:
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>
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>
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.
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.
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.
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.
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:
Developers do not write this servlet themselves; rather, it is automatically included as part of the Web services development process.
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:
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.
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:
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.
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 following WSDL features are not supported by WebLogic Web Services:
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:
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.
![]() |
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|