| Oracle® Application Server Web Services Developer's Guide 10g (10.1.3.5.0) Part Number E13982-01 |
|
|
View PDF |
| Oracle® Application Server Web Services Developer's Guide 10g (10.1.3.5.0) Part Number E13982-01 |
|
|
View PDF |
This chapter provides an overview of Oracle Application Server Web Services for the 10.1.3.1 release. Chapter 3, "OracleAS Web Services Architecture and Life Cycle", describes the architecture of Oracle Application Server Web Services.
Compatibility with Previous Versions of OracleAS Web Services
OC4J in a Standalone Versus Oracle Application Server Environment
Web services comprise a set of messaging protocols, programming standards, and network registration and discovery facilities. When they are used together, these features enable the publication of business functions to authorized parties over the Internet from any device connected to the Web.
A Web service is a software application identified by a Universal Resource Identifier (URI), whose interfaces and binding are capable of being defined, described, and discovered by XML artifacts. A Web service supports direct interactions with other software applications using XML-based messages and Internet-based products.
A Web service:
Exposes and describes itself—A Web service defines its functionality and attributes so that other applications can understand it. By providing a Web Service Description Language (WSDL) file, a Web service makes its functionality available to other applications.
Enables other services to locate it on the Web—A Web service can be registered in a Universal Description, Discover, and Integration (UDDI) Registry so that applications can locate it.
Can be invoked—Once a Web service has been located and examined, the remote application can invoke the service using an Internet standard protocol.
A Web service style is either two-way request and response, or one-way. It can use either synchronous or asynchronous communication. However, the fundamental unit of exchange between a Web service client and a Web service, of either style or type of communication, is a message.
Web services offer a standards-based infrastructure through which any business can do the following:
Offer appropriate internal business processes as value-added services that can be used by other organizations
Integrate its internal business processes and dynamically link them with those of its business partners
With the current release, Oracle has extended the Web services infrastructure to implement versions 1.4 and 5 (1.5) of the Java 2 Enterprise Edition (J2EE) specification for Web services. This section lists the standards that this release of Web services complies with.
The current release of Web services is compatible with these Java J2EE standards:
JAX-RPC 1.1—defines client APIs, support for message handlers, and ways to implement service endpoints
EJB 2.1—defines the EJB API. The standard JAX-RPC 1.1 specifies how to expose an EJB as a Web service endpoint
SAAJ 1.2—defines how to process SOAP messages with attachments
Enterprise Web Services 1.1 specification—(also known as JSRs 109 and 921) specifies how to deploy and execute Web services
The Simple Object Access Protocol (SOAP) is a lightweight, XML-based protocol for exchanging information in a decentralized distributed environment. SOAP supports different styles of information exchange, including Remote Procedure Call style (RPC) and message-oriented exchange. RPC style information exchange allows for synchronous request and response processing, where an endpoint receives a procedure oriented message and replies with a correlated response message. Message-oriented information exchange supports organizations and applications that must exchange business or other styles of documents in which a message is sent but the sender may not expect or wait for an immediate response (asynchronous). Message-oriented information exchange is also called document-style exchange.
SOAP has these features:
Protocol independence
Language independence
Platform and operating system independence
Support for RPC/Encoded and Document/Literal message formats
Support for SOAP XML messages incorporating attachments (using the multipart MIME structure)
The current release of Oracle Application Server Web services supports the SOAP 1.2 protocol and is backward compatible with SOAP 1.1.
See Also:
http://www.w3.org/TR/SOAP for more detailed information on the SOAP 1.1 and 1.2 specifications.
Web Services Description Language (WSDL) is an XML format for describing network services containing RPC-oriented and message-oriented information. Programmers or automated development tools can create WSDL files to describe a service and can make this description available over the Internet. Client-side programmers and development tools can use published WSDL descriptions to obtain information about available Web services and to build and create client proxies or program templates that access available services.
See Also:
http://www.w3.org/TR/wsdl for information on the WSDL format.
Web Service-Interoperability (WS-I) is an organization that promotes Web services interoperability across platforms, applications, and programming languages. The current release conforms to the WS-I Basic Profile 1.1.
Web Services Inspection Language (WS-Inspection or WSIL) is a lightweight Web services directory protocol that provides an extensible schema for a single document catalog of services. The document lists services with some metadata (including extensible data) and links to other directories.
Typically, a WSIL document lists services deployed on a particular server or cluster. It includes anything that is exposed as a provider, including BPEL processes. WSIL allows tighter integration between SOA components in that it provides BPEL and OWSM users with a simple way to browse services deployed to OC4J.
The WSIL document can be viewed and managed as a Web application by Application Server Control and by BPEL and OWSM tools. This application relies on MBeans registered with Oracle's Web services stack to generate its list of services.
The Web application is typically located at the server root or under the services context:
http://yourdomain.com /inspection.wsil, or
http://yourdomain.com /services/inspection.wsil
To move the Web application, you can redeploy it and map it to a different context path.
To increase security, you can disable WSIL by removing the Web application. This will prevent information about other services deployed on the server from being exposed.
In addition to the preceding standards, the current release of OracleAS Web Services contains these new and enhanced features:
Web Service Security for Authentication, Integrity, and Confidentiality
Web Services Management Framework and Application Server Control
Web Services Metadata for the Java Platform (J2SE 5.0 Web Service Annotations)
Web Services Invocation Framework for Describing WSDL Programming Artifacts
The WS-Security standard, published and maintained by the Organization of the Advancement of Structure Information Standards (OASIS), provides profiles for Web services authentication, message encryption, and digital signatures. The current release provides an implementation of WS-Security with the following capabilities:
XML Signature
XML Encryption
Username Token
X.509 Token
SAML Token
See Also:
Oracle Application Server Web Services Security Guide for more information on Web service security.
The management framework provides configuration and monitoring capabilities for security, reliability, logging, and auditing through the Web-based Application Server Control. These features are exposed through a series of Java Management Extensions (JMX) Management beans (Mbeans).
See Also:
"Managing Web Services" in the Oracle Application Server Advanced Web Services Developer's Guide for more information on Web services management.
"Web Service MBeans" in the Oracle Application Server Advanced Web Services Developer's Guide for more information on the Web service features that you can control through MBeans.
The current release provides support for J2SE 5.0 Web Service annotations (also known as the Web Services Metadata for the Java Platform (JSR-181) specification). The specification defines an annotated Java syntax for programming Web services.
See Also:
Chapter 11, "Assembling Web Services with Annotations" for a description of how annotations are supported and of Oracle extensions to the specification.
The current release provides support for Representational State Transfer (REST) services. This architecture leverages the architectural principles of the Web. It uses the semantics of HTTP whenever possible.
Unlike SOAP Web Services, REST is a "style" and has no standards or tools support from vendors. Also, REST Web services use XML documents, not SOAP envelopes, for sending messages.
You can assemble REST Web services with the WebServicesAssembler tool or by adding J2SE 5.0 Web Service annotations to your source files. You can then use the Web Service Test Page to see if they deployed successfully and to test their functionality.
See Also:
Chapter 12, "Assembling REST Web Services" for more information on assembling REST Web services.
The functionality of the Web Service Test Page has been expanded beyond testing whether the Web Service deployed correctly. The Test Page lets you exercise Web service operations with different input values. You can display and edit the SOAP request that will be sent to the service. It also displays the response returned by the service. If your Web service defines security and reliability features, then editors in the Test Page allow you to exercise the service with different security and reliability values.
The Test Page also enables you to exercise Web Service Providers and REST Web Services. For a REST Web service, the Test Page provides the same functionality as for JAX-RPC Web Services, however, it also lets you invoke the REST POST and REST GET operations.
See Also:
Chapter 13, "Testing Web Services Deployment" for more information on how to use the Web Service Test Page.
The current release provides Ant tasks for Web services development, with a focus on enabling the scripting and automation of Web service client and server development. Sample Ant tasks are provided throughout this manual.
See Also:
"How to Set Up Ant for WebServicesAssembler" provides many of the details for setting up Ant for your environment.
Chapter 18, "Using WebServicesAssembler" provides examples of how to write Ant tasks for Web service assembly commands.
Web services in complex systems are often required to map data types beyond the native types automatically serialized into XML by the Web services runtime. The current release offers a custom type-mapping framework for mapping custom data types.
See Also:
"Custom Serialization of Java Value Types" in the Oracle Application Server Advanced Web Services Developer's Guide. for more information on working with nonstandard data types in your Web service.
The current release continues to support publishing PL/SQL as a Web service and using OracleAS Web Services as the Java runtime in the Oracle Database 10g for call-outs to Web services.
The current release extends the runtime and tool support to declaratively define the following database artifacts as Web services:
PL/SQL stored procedures
SQL queries
DML statements
Java classes loaded within the database virtual Java machine
Oracle Streams AQ (Advanced Queues)
See Also:
Chapter 10, "Assembling Database Web Services" for more information on implementing database artifacts as a Web service.
The current release facilitates advanced manipulation of SOAP headers using two JAX-RPC-compliant mechanisms:
A mechanism to programmatically intercept SOAP headers using JAX-RPC handlers. This mechanism allows processing SOAP headers out-of-band from the processing of the main SOAP message.
A mechanism to automatically map SOAP headers to member variables in Java classes. This mechanism enables you to treat SOAP headers as variables in the Web service implementation through a declarative mapping process instead of a programmatic process.
See Also:
Chapter 16, "Using JAX-RPC Handlers" for more information on SOAP headers.
Chapter 17, "Processing SOAP Headers" for more information on processing SOAP headers.
To facilitate efficient transfer of binary documents and large XML documents, the current release supports MIME and DIME attachments:
Multipurpose Internet Mail Extensions (MIME) attachments conform to the WS-I Attachment Profile for both WSDL to Java consumption, and Java to WSDL publication of Web services requiring SOAP with MIME attachments.
Direct Internet Message Encapsulation (DIME) attachments conforming to the Microsoft Corporation analog to MIME. Oracle offers DIME support for backward compatibility with other implementations, because Microsoft no longer encourages DIME for attachments.
See Also:
"Working with Message Attachments" in the Oracle Application Server Advanced Web Services Developer's Guide for more information on how OracleAS Web Services supports MIME and DIME attachments.
The current release enables you to send binary content between the client and server in MTOM (SOAP Message Transmission Optimization Mechanism) format. Using MTOM, binary content can be sent as a MIME attachment, which reduces the transmission size on the wire. The binary is semantically part of the XML document. This is an advantage over SWA (SOAP Messages with Attachments), in that it enables you to apply operations such as WS-Security signature on the message.
See Also:
"Working with Attachments containing Binary Data" in the Oracle Application Server Advanced Web Services Developer's Guide for more information on how OracleAS Web Services supports MIME and DIME attachments.
The current release provides an OASIS Web Service Reliability (WS-Reliability) implementation with guaranteed at-least-once message delivery, duplicate message elimination (at most once delivery), exactly once message delivery (guaranteed delivery and duplicate elimination), and message ordering within groups of messages.
See Also:
"Ensuring Web Service Reliability" in the Oracle Application Server Advanced Web Services Developer's Guide for more information on reliability.
As an alternative to HTTP, the current release enables the use of JMS queues as a transport for SOAP messages. JMS provides a higher level of reliable message delivery for SOAP messages.
Where HTTP is required as the transport, the current release continues to support the ability to put and get SOAP messages from JMS queues and topics, and adds the functionality of correlating messages processed in this manner.
See Also:
Chapter 9, "Assembling Web Services with JMS Destinations" for more information on using JMS to develop Web services.
"Using JMS as a Web Service Transport" in the Oracle Application Server Advanced Web Services Developer's Guide for more information on using JMS as a transport mechanism for Web services.
The Provider API lets you define custom processing logic for a Web services endpoint that is not tied to any particular service endpoint implementation strategy, such as JAX-RPC. The Provider model can be used to provide common functionality to a number of endpoints. Rather than incorporating the same functions into many Web services, the Provider model enables you to add the logic into the runtime directly.
See Also:
"Using Web Service Providers" in the Oracle Application Server Advanced Web Services Developer's Guide for more information on Web service providers.
The Web Services Invocation Framework (WSIF) provides a general purpose, extensible mechanism to describe programmatic artifacts using WSDL and a framework to invoke those artifacts using their native protocols. The current release supports an initial implementation of WSIF.
See Also:
"Using Web Services Invocation Framework" in the Oracle Application Server Advanced Web Services Developer's Guide for more information on WSIF.
The current release provides the ability to record inbound and outbound SOAP messages into logging and auditing files. Entire messages or parts of messages can be logged by subquerying through the use of Xpath statements.
See Also:
"Auditing and Logging Messages" in the Oracle Application Server Advanced Web Services Developer's Guide for more information on logging and auditing messages.
BPEL (Business Process Execution Language) is a standard published by the Organization of the Advancement of Structure Information Standards (OASIS) and backed by major vendors including Oracle. BPEL describes an XML syntax for describing a business process through a "composition of invocations of (other) Business Processes—typically Web services". A BPEL process definition, therefore, is an XML document composed according to an XSD that is maintained by OASIS.
A business process, in BPEL terms, is composed of invocations (call-outs to Web services), receptions (call-ins from external services), decision points with simple conditional logic and parallel flows or sequences, that in turn consist of invocations, decision points, and so on. Variables can be defined as part of a business process. They can be assigned values from parameters passed to the business process at startup, passed along in invocations, given values from the results of invocations, and returned as the final result of the business process. A business process itself is also implemented as a Web service—in the BPEL (runtime) engine.
The Oracle implementation of BPEL uses WSIF technology to directly invoke business processes. In certain cases, the actual invocation from BPEL can be a direct call to a Java class without the Web service overhead of marshalling and unmarshalling SOAP messages.
See Also:
The following Web site provides more information on Oracle BPEL:
http://www.oracle.com/technology/products/ias/bpel/index.html
Oracle Web Services Manager is a comprehensive solution for managing service oriented architectures. It allows IT managements to centrally define policies that govern Web services operations such as access policy, logging policy, and content validation, and then wrap these policies around services, with no modification to existing web services required. Also, Oracle Web Services Manager collects monitoring statistics to ensure service levels and security, and displays them in a web dashboard. As a result, Oracle Web Services Manager brings enterprises better control and visibility over their web services.
See Also:
The following Web site provides more information on Oracle Web Services Manager:
http://www.oracle.com/technology/products/webservices_manager/index.html
The 10.1.3.1 release of OracleAS Web Services is fully compatible with the 10.1.3 release.
Applications designed to run with versions 9.0.4 or 10.1.2 of the Oracle Application Server can be used with version 10.1.3.1. While you can still deploy your 9.0.4 or 10.1.2 Web Services in the 10.1.3.1 Application Server, you will not be able to see them in the management console.
For backward compatibility, Oracle Application Server 10g Release 3 (10.1.3.1) includes the underlying software required to run 10g Release 2 (10.1.2) Web services. As a result, Web services applications designed to run with Oracle Application Server 10g (9.0.4) and 10g Release 2 (10.1.2) can be used without modification with Release 3.
However, there are significant advantages to re-creating your Web services for 10g Release 3 (10.1.3.1). For example, you can take advantage of the all the new features such as quality of service (QOS), a standard-based development model (JAX-RPC), and JMX-based management.
See Also:
Oracle Application Server Upgrade Guide provides more information on redeploying your existing Web service applications to OracleAS Web Services 10.1.3.1.
The version 10.1.2 Web services stack is being deprecated. However, it is still supported in version 10.1.3.1.
The ws.debug system property and its related behavior have been deprecated.
The oracle.webservices.ClientConstants.WSM_INTERCEPTOR_PIPELINE_CONFIG property has been deprecated and replaced by oracle.webservices.ClientConstants.CLIENT_CONFIG. For more information on this property, see "How to Pass a Management Configuration to a Client Programmatically" in the Oracle Application Server Advanced Web Services Developer's Guide.
The oracle.webservices.OracleStub properties ENCODING_STYLE_PROPERTY and OPERATION_STYLE_PROPERTY have been deprecated.
To use OracleAS Web Services in a clustered environment, you must install the service on every machine in the cluster. Application Server Control enables you to easily deploy a service to a group of instances within an Oracle Application Server cluster.
If you install a standard, stateless Web service, then a clustered deployment will result in multiple instances that can process requests, but cannot share state.
If you install a stateful Web service, then those instances will share state. If the service is not installed on all machines in a cluster, then the cluster dispatcher might dispatch a service request to a machine that does not have the service, resulting in an error on the service invocation.
To support a clustered environment, for stateful Java Web services with serializable Java classes, the WebServicesAssembler adds a <distributable> tag in the web.xml of the Web service¹s generated J2EE EAR file.
See Also:
"Deploying to OC4J Instances Within a Cluster" in the Oracle Containers for J2EE Deployment Guide for more information on deploying to a group of instances.
"Java Classes and Stateful Web Services" for information on assembling stateful Web services.
During development, it is typical to use OC4J by itself, outside an OracleAS Web Services environment. We refer to this as standalone OC4J (or, sometimes, as unmanaged OC4J). In this scenario, OC4J can use its own Web listener and is not managed by any external Oracle Application Server processes.In contrast, a full Oracle Application Server environment (sometimes referred to as managed OC4J), includes the use of Oracle HTTP Server as the Web listener, and the Oracle Process Manager and Notification Server (OPMN) to manage the environment.
See Also:
Oracle Containers for J2EE Configuration and Administration Guide for additional information about Oracle Application Server versus standalone environments and about the use of Oracle HTTP Server and OPMN with OC4J.
Oracle HTTP Server Administrator's Guide for general information about the Oracle HTTP Server and the related mod_OC4J module. (Connection to the OC4J servlet container from Oracle HTTP Server is through this module.)
Oracle Process Manager and Notification Server Administrator's Guide for general information about OPMN.
|
 Copyright © 2006, 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
