|
Oracle® Application Server Web Services Developer's Guide
10g Release 2 (10.1.2) Part No. B14027-01 |
|
 Previous |
 Next |
|
Oracle® Application Server Web Services Developer's Guide
10g Release 2 (10.1.2) Part No. B14027-01 |
|
|
Previous |
Next |
This chapter describes the Oracle Application Server Web Services features, architecture, and implementation.
This chapter covers the following topics:
Oracle Application Server OC4J (J2EE) and Oracle SOAP Based Web Services
About Universal Description, Discovery, and Integration Registry
Oracle Application Server supports two different Web Services options, a J2EE based Web Services environment built into Oracle Application Server Containers for J2EE (OC4J), and an Apache SOAP based Web Services environment called Oracle Application Server SOAP.
The chapters in this manual describe the OC4J (J2EE) Web Services environment. This environment makes it easy to develop and deploy services using J2EE artifacts, and is moving the Oracle Application Server Web Services features toward the evolving Web Services standards included in the next release of J2EE (J2EE 1.4). The Oracle Application Server Web Services environment includes many development and deployment features that are integrated with the advanced Oracle Application Server features.
Appendix A, "Using Oracle Application Server SOAP" describes the Oracle Application Server support for Apache SOAP (Oracle Application Server SOAP). Oracle Application Server includes support for Apache SOAP because this implementation was one of the earliest SOAP implementations and it supports existing Web Services applications.
|
Note: Oracle recommends using the Oracle Application Server OC4J (J2EE) Web Services environment for developing Web Services. The Apache SOAP (Oracle Application Server SOAP) implementation is currently in maintenance mode. |
Oracle Application Server Web Services supports the following Web Services standards:
SOAP 1.1, including the following:
RPC/Encoded
Document/Literal
WSDL 1.1
UDDI 2.0
Oracle Application Server provides advanced runtime features and comprehensive support for developing and deploying Web Services. The Oracle Application Server infrastructure includes support for the following:
Oracle Application Server Web Services provides comprehensive support for developing Web Services, including:
Development Environment – Oracle Application Server Web Services allows application developers to implement Web Services using J2EE components. In addition, you can use Java Classes or PL/SQL Stored Procedures to implement Web Services. Web Services inherit all the runtime and lifecycle management elements of J2EE Applications.
Development Tools and Wizards – Oracle Application Server Web Services Developers can use the same set of command line utilities to create, package, and deploy Web Services as other Oracle Application Server Containers for J2EE (OC4J) applications.
Automatically Generating WSDL – Oracle Application Server Web Services can generate WSDL and client-side proxy stubs. This generation occurs when the Web Service is assembled using the WebServices Assembly tool or alternatively, for a deployed Web Service, the first time the WSDL or the client-side proxy stubs are requested (after the first request, the previously generated WSDL or client-side proxy stubs are sent when requested).
Registration, Publishing, and Discovery – Oracle Application Server Web Services provides a standards-compliant UDDI registry where Web Services can be published and discovered. The Oracle UDDI registry supports both a private and public UDDI registry and can also synchronize information with other UDDI nodes.
Developer Simplicity – Using Oracle Application Server Web Services, developers do not need to learn a completely new set of concepts – Web Services are developed, deployed and managed using the same programming concepts and tools as with J2EE Applications.
Business Logic Reuse – Application developers can transparently publish their J2EE Applications to new Web Services clients with no change in the application itself. Their existing business logic developed in J2EE can be transparently accessed from existing J2EE/EJB clients or from a new Web Service client.
Common Runtime Services – Oracle Application Server has a common runtime and brokering environment for J2EE Applications and Web Services. As a result, Web Services transparently inherit various services available with the J2EE Container including Transaction Management, Messaging, Naming, Logging, and Security Services.
Oracle Enterprise Manager 10g and the Web Services Assembly Tool assist with deploying and managing Oracle Application Server Web Services. These tools provide the following support for Web Services:
Packaging and Assembly - The Web Services Assembly Tool assists with assembling Web Services and producing a J2EE .ear file.
Deployment – Oracle Enterprise Manager 10g provides a comprehensive set of facilities to deploy Web Services to Oracle Application Server. Oracle Enterprise Manager 10g provides a single, consistent Deploy Applications wizard for deploying Web Services to Oracle Application Server. It accepts a J2EE .ear file, and walks you through a set of steps to get information about the application to be deployed, and then deploys the application.
Register Web Service - The Deploy Applications wizard is only available when deploying Web Services. This step provides access to facilities for registering Web Services in the UDDI Registry.
Browse the UDDI Registry - Oracle's UDDI Registry provides the UDDI standards compliant pre-defined, hierarchical categorization schemes. Oracle Enterprise Manager 10g can drill-down through these categories and look up specific Web Services registered in any category.
Monitoring and Administration – Once deployed, Oracle Enterprise Manager 10g provides facilities to de-install a Web Service and also to monitor Web Service performance, as measured by response-time and throughput, and status, as measured by up-time, CPU, and memory consumption. Oracle Enterprise Manager 10g also provides facilities to identify and list all the Web Services deployed to a specific Oracle Application Server instance.
The Oracle JDeveloper IDE supports Oracle Application Server Web Services. Oracle JDeveloper is the industry's most advanced Java and XML IDE and provides unparalleled productivity and end-to-end J2EE and integrated Web Services standards compliance.
Oracle JDeveloper supports Oracle Application Server Web Services with the following features:
Allows developers to create Java stubs from Web Services WSDL descriptions to programmatically use existing Web Services.
Allows developers to create a new Web Service from Java or EJB classes, automatically producing the required deployment descriptor, web.xml, and WSDL file for you.
Provides schema-driven WSDL file editing.
Offers significant J2EE deployment support for Web Services J2EE .ear files, with automatic deployment to OC4J.
Oracle Enterprise Manager 10g secures Oracle Application Server Web Services in the same way that it secures J2EE Servlets running under OC4J. This provides a comprehensive set of security facilities, including:
Complete, standards-based security architecture for encryption, authentication, and authorization of Web Services.
Single Sign-on to enable users to access several Web Services with a single password.
Single Point of administration to enable users to centrally manage the security for Web Services.
Oracle Application Server Containers for J2EE (OC4J) provides the foundation for building applications as components and supports Oracle Application Server Web Services. Oracle Application Server Web Services supports both RPC Style and Document Style web services.
Oracle Application Server Web Services supports the following RPC Web Services:
Java Classes
Stateless Session Enterprise Java Beans (EJBs)
Stateless PL/SQL Stored Procedures or Functions
Oracle Application Server Web Services supports the following Document Style web services:
Java Class Document Style Web Services
JMS Document Style Web Services
For each implementation type, Oracle Application Server Web Services uses a different Servlet that conforms to J2EE standards to provide an entry point to a Web Service implementation. Figure 2-1 shows the Web Services runtime architecture, including the Servlet entry points.
The Oracle Application Server Web Services runtime architecture discussion includes the following:
Figure 2-1 Web Services Runtime Architecture (RPC and Document Style with Servlet Entry Points)
To use Oracle Application Server Web Services, you need to deploy a J2EE .ear file to Oracle Application Server. The J2EE .ear file contains a Web Services Servlet configuration and includes an implementation of the Web Service. Oracle Application Server Web Services supplies the Servlet classes, one for each supported implementation type. At runtime, Oracle Application Server uses the Servlet classes to access the user supplied Web Service implementation.
The Oracle Application Server Web Services Servlet classes support the following Web Services implementation types:
Java Class (Stateless) - The object implementing the Web Service is any arbitrary Java class. The Web Service is stateless.
Java Class (Stateful) -The object implementing the Web Service is any arbitrary Java class. The Web Service is considered stateful. A Servlet HttpSession maintains the object state between requests from the same client.
Stateless Session EJBs - Stateless Session EJBs can be exposed as Web Services. The Web Service is considered to be stateless.
PL/SQL Stored Procedure or Function - The object implementing the Web Service is a Java class that accesses the PL/SQL stored procedure or function. The Web Service is considered to be stateless. The Oracle JPublisher tool generates the Java access class for the PL/SQL stored procedure or function.
Java Class Document Style Web Service (Stateless) - The object implementing the Web Service is a Java class using a supported method signature. The Web Service is stateless.
Java Class Document Style Web Service (Stateful) -The object implementing the Web Service is a Java class using a supported method signature. The Web Service is considered stateful. A Servlet HttpSession maintains the object state between requests from the same client.
Java JMS Web Service - Supports sending and receiving messages to or from JMS destinations. Using the JMS Web Service you can include an MDB to handle or generate messages.
When a Web Service is deployed, a unique instance of the Servlet class manages the Web Service. The Servlet class is implemented as part of Oracle Application Server Web Services runtime support. To make Web Services accessible, you deploy the Web Service implementation with the corresponding Web Services Servlet.
|
Note: Using Oracle Application Server SOAP, based on Apache SOAP 2.3.1, there is only a single instance of a single Servlet entry point for all the Web Services in the entire system. The Oracle Application Server Web Services architecture differs; under Oracle Application Server Web Services, a unique Servlet instance supports each Web Service. |
RPC Style Web Service implementations under Oracle Application Server Web Services that take values as parameters or that return values to a client need to restrict the types passed. This restriction allows the types passed to be converted between XML and Java objects (and between Java objects and XML). Table 2-1 lists the supported types for passing to or from Oracle Application Server Web Services.
Document Style Web Service implementations under Oracle Application Server Web Services restrict the signature of the Java methods that implement the Web Service. Only org.w3c.dom.Element can be passed to or sent from these Web Services.
|
Note: The preceding restriction means thatorg.w3c.dom.Element types cannot be mixed as a parameter with other types in methods that implement a Web Service.
|
Table 2-1 Web Services Supported Data Types (for RPC Parameters and Return Values)
| Primitive Type | Object Type |
|---|---|
Boolean
|
java.lang.Boolean
|
byte
|
java.lang.Byte
|
double
|
java.lang.Double
|
float
|
java.lang.Float
|
int
|
java.lang.Integer
|
long
|
java.lang.Long
|
short
|
java.lang.Short
|
string
|
java.lang.String
|
|
|
java.util.Date
|
|
|
java.util.Map
|
|
|
org.w3c.dom.Element
|
|
|
org.w3c.dom.Document
|
|
|
org.w3c.dom.DocumentFragment
|
|
|
Java Beans (whose property types are listed in this table or are another supported Java Bean) |
|
|
Single-dimensional arrays of types listed in this table |
Oracle Application Server Web Services are accessed as Servlets, thus, Web Services need to be assembled. The WebServicesAssembler tool prepares J2EE .ear files for Web Services by configuring a web.xml file that is a component of a J2EE .war file, and including the required resources and the implementation and support classes.
To build a Web Service with the assembly tool, you can supply a Jar file, .war file, ebj.jar, or .ear file that includes your Web Service implementation. The assembly tool then builds the Web Service using configuration information specified in its XML configuration file.
The first time Oracle Application Server Web Services receives a request for a service, the Servlet entry point automatically does the following (this discussion does not apply for JMS Web Services, which are handled differently):
Validates the class loading. All the classes that are required for the Web Service implementation must conform to standard J2EE class loading norms.
Validates the data types. All the Java classes or EJBs must conform to the restrictions on supported parameter and return types as shown in Table 2-1.
Generates server skeleton code. The server skeleton code is only generated the first time the Web Service is accessed or when the ear file is redeployed (when an application is redeployed, the server skeleton code and other Web Services support files are regenerated). The generated code is stored in the temporary directory associated with the Servlet context. The server skeleton code controls the lifecycle of the EJB (for Stateless Session EJB implementations), handles the marshaling of the parameters and return types (for SOAP RPC based Web Services), and dispatches to the actual Java class or EJB methods that implement the service.
After the server skeleton class is generated, when subsequent requests for a service are received, the server skeleton directly handles marshalling and then invokes the method that implements the service (for Web Services implemented with PL/SQL stored procedures or functions, the server skeleton invokes the Java class that accesses the Database containing the PL/SQL stored procedure or function).
For document style Web Services, the server skeleton passes the DOM element to the method that implements the service.
Oracle Application Server Web Services provides a tool to generate a WSDL file that can be packaged with a Web Service at assembly time, (if you do not package the WSDL file, it can be generated at runtime). This tool also supports generating client-side proxy stubs, given a WSDL file.
There are several elements to Oracle Application Server Web Services WSDL support. First, RPC style Web Services are based on interoperable XML data representations and arbitrary Java objects do not in general map to XML. Oracle Application Server Web Services supports a set of XML types corresponding to a set of Java types (see Table 2-1 for the list of supported Java types).
Second, using Oracle Application Server Web Services, an application developer can either statically generate the WSDL interfaces for a Web Service or the Oracle Application Server Web Services runtime can generate WSDL and client-side proxy stubs if they are not provided when a Web Service is deployed. These files can be generated by the runtime on the server-side and delivered when they are requested by a Web Services client.
Oracle Application Server also provides a client-side tool to statically generate WSDL given a Java class or a J2EE application. Likewise, the Web Services Assembly tool can generate the client-side proxy given a generated WSDL file or a known WSDL endpoint.
Using Web Services, a client application sends a SOAP request that invokes a Web Service and handles the SOAP response from the service. To facilitate client application development, the Oracle Application Server Web Services runtime can generate WSDL to describe a Web Service. Using the WSDL, development tools can assist developers in building applications that invoke Web Services.
Using Web Services, a client application sends a SOAP request that invokes a Web Service and handles the SOAP response from the service. To facilitate client-side application development, Oracle Application Server Web Services can generate client-side proxy stubs. The client-side proxy stubs hide the details of composing a SOAP request and decomposing the SOAP response. The generated client-side proxy stubs support a synchronous invocation model for requests and responses. The generated stubs make it easier to write a Java client application to make a Web Service (SOAP) request and handle the response.
Oracle Application Server Web Services provides a Web Service Home Page for each deployed Web Service.
A Web Service Home Page provides the following:
A Link to the WSDL file - To obtain the WSDL file for a Web Service, select the Service Description link and save the file.
Links to Web Service Test Pages for each supported operation-To test the available Web Service operations enter the parameter values for the operation, if any, and select the Invoke button.
Links to the Web Service client-side proxy Jar and the client-side proxy source - To obtain the client-side proxy Jar or the client-side proxy source, select the appropriate link, Proxy Jar or Proxy Source, and save the file.
Figure 2-2 shows a sample Web Service Home Page.
The Universal Description, Discovery, and Integration (UDDI) specification consists of a four-tier hierarchical XML schema that provides the base information model to publish, validate, and invoke information about Web Services. The four types of information that the UDDI XML schema defines are:
Business Entity - The top level XML element in a UDDI entry captures the starting set of information required by partners seeking to locate information about a business' services including its name, its industry or product category, its geographic location, and optional categorization and contact information. This includes support for Yellow Pages taxonomies to search for businesses by industry, product, or geography.
Business Service - The businessService structure groups a series of related Web Services together so that they can be related to either a business process or a category of services. An example of a business process could be a logistics/delivery process which could include several Web Services including shipping, routing, warehousing, and last-mile delivery services. By organizing Web Services into groups associated with categories or business processes, UDDI allows more efficient search and discovery of Web Services.
Binding Information - Each businessService has one or more technical Web Service Descriptions captured in an XML element called a binding template. The binding template contains the information that is relevant for application programs that need to invoke or to bind to a specific Web Service. This information includes the Web Service URL address, and other information describing hosted services, routing and load balancing facilities.
Compliance Information - While the bindingTemplate contains the information required to invoke a service, it is not always enough to simply know where to contact a particular Web Service. For instance, to send a business partner's Web Service a purchase order, the invoking service must not only know the location/URL for the service, but what format the purchase order should be sent in, what protocols are appropriate, what security required, and what form of a response will result after sending the purchase order. Before invoking a Web Service, it is useful to determine whether the specific service being invoked complies with a particular behavior or programming interface. Each bindingTemplate element, therefore, contains an element called a tModel that contains information which enables a client to determine whether a specific Web Service is a compliant implementation.
