Oracle® Application Server Containers for J2EE JSP Tag Libraries and Utilities Reference
10g Release 2 (10.1.2) B14016-02 |
|
Previous |
Next |
Oracle furnishes a tag library with OC4J that enables developers to create JSP pages for use as client programs for Web services. This chapter describes the tag library and consists of the following sections:
This chapter is written with the assumption that you are already familiar with Web services, Simple Object Access Protocol (SOAP), and the Web Services Description Language (WSDL); however, some overview is provided here. There are also references to additional documents, including related specifications from the World Wide Web Consortium (W3C).
The OC4J Web services tag library is based on Oracle Application Server Web Services. See the Oracle Application Server Web Services Developer's Guide for information.
The following sections provide a quick overview of Web services concepts:
Web services are sets of procedures, or actions, that can be invoked by a client over the Internet, regardless of the computing platform. Web services consist of loosely coupled components over a distributed computing environment following a widely adopted set of standards such as SOAP, WSDL, and UDDI (all discussed later in this chapter). As an example, there might be a "World Cup Soccer" service that consists of actions to get scores, schedules, and standings.
A Web service must have the following features:
It must be able to describe itself, such as its functionality and its input and output attributes. A Web service describes itself through an XML-style WSDL document. See "Overview of Web Services Description Language Key Elements".
It must make itself generally available so that client applications can access it. The standard way to do this is to be listed in a Universal Description, Discovery, and Integration (UDDI) directory. Public UDDI directories are available to aggregate groups of businesses or users (or perhaps to anyone on the Internet), while private UDDI directories are available only within a particular business or group.
A client application must be able to invoke it through a standard protocol once the application has found and examined it. A leading protocol for Web services is Simple Object Access Protocol (SOAP). With SOAP, the Web service is behind a SOAP server at the server end and the client application goes through a SOAP server at the client end. Data exchanges are "SOAP-enveloped" and can gain access through firewalls. This SOAP exchange is conceptually similar to a Remote Method Invocation (RMI) exchange, except that RMI exchanges cannot go through firewalls. See "Overview of SOAP and Related Features" below for a brief overview of SOAP.
Once invoked, it must return a response to provide requested results to the client application. This is performed through the same standard protocol, such as SOAP.
For more information about Web services, particularly OracleAS Web Services, you can refer to the Oracle Application Server Web Services Developer's Guide.
For related specifications, refer to the following Web sites for the W3C SOAP specification, W3C WSDL specification, and UDDI specification, respectively:
http://www.w3.org/TR/SOAP
http://www.w3.org/TR/wsdl
http://www.uddi.org/specification.html
This section offers a brief overview of SOAP. See the W3C Simple Object Access Protocol (SOAP) 1.1 specification for details.
SOAP is a lightweight, XML-based protocol for exchanging typed and structured data over the Internet or other distributed environments. Among other features, SOAP supports remote procedure call (RPC) and message-oriented data exchanges.
In a message-oriented implementation, data is exchanged through a modular packaging and encoding model. A message is a WSDL component that specifies input data parts and output data parts associated with an operation. See "Overview of Web Service Messages and XML Schema Definitions" for more information.
RPC is an alternative to sockets, with the communication interface being at the level of procedure calls. It is as though you are calling a local procedure, but arguments of the call are actually packaged and sent to a remote target. The RPC mechanism uses a request/response methodology, where an end-point receives a procedure-oriented message and sends back a corresponding response.
Using SOAP with RPC is independent of the protocol binding. Where HTTP is the protocol binding, HTTP requests correspond to RPC calls, and HTTP responses correspond to RPC responses.
Key aspects of SOAP include the following.
SOAP envelope construct: The envelope encloses a SOAP header and SOAP body and indicates what is in a message, whether it is required, and who should process it.
SOAP encoding rules: Encoding rules define serialization mechanisms for the exchange of instances of the datatypes used in an application.
SOAP RPC representation: The RPC representation specifies a convention for representing RPC calls and responses.
A Web service is described using the XML-based Web Services Description Language in a WSDL (.wsdl
) document.
Following are some key WSDL terms.
Operation: An operation is a particular action performed by a service, such as any of the "get scores", "get schedules", and "get standings" examples for a World Cup service.
Message: A message is an abstract definition that specifies the data that is being input and output for an operation.
Port type: A port type is an abstract definition of the operations supported by a service.
Binding: A binding is a protocol and data format specification for one or more operations supported by a service. A binding mechanism maps the generic or abstract definition of a Web service to a concrete implementation, including data encoding, message protocol, and communication protocol.
Port: A port is a single end-point, a combination of a binding and a network address. Essentially, a port is the concrete manifestation of the capabilities described by a port type. In a SOAP-based implementation, a port is a SOAP location.
To be more precise than previously, a Web service is really a collection of related ports, or end-points, not just a collection of abstract actions or operations.
The WSDL specification outlines the general structure of a WSDL document, which includes the following key elements. Refer to the W3C Web Services Description Language (WSDL) 1.1 specification for complete information.
A <types>
element , through one or more <schema>
subelements, contains descriptions of the data that is exchanged in messages used by the operations of the service.
A <message>
element provides an abstract definition of data being sent as input or output for an operation.
A <portType>
element, through one or more <operation>
subelements, contains abstract definitions of the operations of the Web service. An <operation>
element specifies the message that is used for input and the message that is used for output for the operation.
A <binding>
element, also through <operation>
subelements, binds each operation to the particular protocol and data formats to be used.
A <service>
element defines the ports, or end-points, of the Web service. Within the <service>
element is one or more <port>
subelements, where each <port>
element ties a binding to an address to define the end-point.
Messages define parameters used by the operations, or methods, of a Web service. A message is a typed definition of the data being communicated, consisting of one or more parts. Each part corresponds to a logical entity, such as a "Purchase Order" part and an "Invoice" part. For each part, there are type specifications for the associated data items.
In a SOAP-based implementation, such as for OracleAS Web Services, the datatypes used by a message are defined through the XML Schema Definition (XSD) language, which supports predefined simple types as well as user-defined complex types.
With an implementation that uses XSD, the syntax for defining a message is as follows:
<message name="nmtoken"> <part name="nmtoken" [type="qname"] [element="qname"] /> </message>
In this syntax, the element
attribute refers to where an XSD complex type is defined using XSD syntax, the type
attribute indicates an XSD simple type, "nmtoken
" indicates a standard XML name token, and "qname
" indicates a standard XML qualified name. There can be zero or more messages, and zero or more parts for each message.
For a SOAP encoding style of encoded
, only simple types are allowed, so the element
attribute is not used. For an encoding style of literal
, you can have simple types or complex types, so a <part>
element can use either the type
attribute or the element
attribute, but not both.
Here is an example of a message definition, from "Example: WSDL Definition", which follows shortly:
<message name="GetLastTradePriceInput"> <part name="body" element="xsd1:TradePriceRequest"/> </message>
GetLastTradePriceInput
is the name of the message, which is an input message (as the name implies). In this case, the element
attribute refers to a namespace where a complex type, TradePriceRequest
, is defined. Here is an example of such a definition (also part of "Example: WSDL Definition" below):
<element name="TradePriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string"/> <element name="companyName" type="string"/> </all> </complexType> </element>
An XML schema primer is available from W3C at the following location:
http://www.w3.org/TR/xmlschema-0/
This example shows the WSDL definition of a Web service, illustrating the input and output messages embedded in an HTTP request and HTTP response, respectively.
The W3C Web Services Description Language (WSDL) 1.1 specification provides the following example of a WSDL document that defines a stock quote service taking a ticker symbol as input and returns the current stock price as output. Note this uses a SOAP encoding style of literal
, so complex types are allowed (and used).
<?xml version="1.0"?> <definitions name="StockQuote" targetNamespace="http://example.com/stockquote.wsdl" xmlns:tns="http://example.com/stockquote.wsdl" xmlns:xsd1="http://example.com/stockquote.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <schema targetNamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2000/10/XMLSchema"> <element name="TradePriceRequest"> <complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType> </element> <element name="TradePrice"> <complexType> <all> <element name="price" type="float"/> </all> </complexType> </element> </schema> </types> <message name="GetLastTradePriceInput"> <part name="body" element="xsd1:TradePriceRequest"/> </message> <message name="GetLastTradePriceOutput"> <part name="body" element="xsd1:TradePrice"/> </message> <portType name="StockQuotePortType"> <operation name="GetLastTradePrice"> <input message="tns:GetLastTradePriceInput"/> <output message="tns:GetLastTradePriceOutput"/> </operation> </portType> <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="GetLastTradePrice"> <soap:operation soapAction="http://example.com/GetLastTradePrice"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="StockQuoteService"> <documentation>My first service</documentation> <port name="StockQuotePort" binding="tns:StockQuoteBinding"> <soap:address location="http://example.com/stockquote"/> </port> </service> </definitions>
This WSDL definition first specifies the GetLastTradePriceInput
and GetLastTradePriceOutput
input and output messages, then ties them to the operation GetLastTradePrice
, then defines a binding and a port for that operation.
Notes:
|
Corresponding to the Web service defined in the preceding example, this section shows what the messages would look like, with the soap-enveloped input message embedded in an HTTP request, and the soap-enveloped output message embedded in an HTTP response. These examples are also from the W3C Web Services Description Language (WSDL) 1.1 specification.
Here is a request:
POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "SOAP_URI" <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <m:GetLastTradePrice xmlns:m="xmlns_URI"> <m:tickerSymbol>DIS</m:tickerSymbol> </m:GetLastTradePrice> </soapenv:Body> </soapenv:Envelope>
In this example, xmlns_URI
is a URI value used to identify the namespace where the GetLastTradePrice
operation and its messages are defined, such as the WSDL document in the preceding "Example: WSDL Definition". This is also where tickerSymbol
is defined. The request is for a stock quote for Walt Disney Company. SOAP_URI
is the URI for the SOAP action HTTP header for the HTTP binding of SOAP.
And here is the response:
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<m:GetLastTradePriceResponse xmlns:m="Some_URI">
<m:price>34.5</m:price>
</m:GetLastTradePriceResponse>
</soapenv:Body>
</soapenv:Envelope>
By convention, the response for an operation Xxxx
is called Xxxx
Response
. Some_URI
is a URI value used to identify the namespace where the GetLastTradePriceResponse
operation is defined.
The following sections provide an overview and details of the Web services tag library, as well as an overview of OracleAS Web Services, upon which the tag library implementation is based.
The Web services tag library provided with OC4J enables developers to conveniently create JSP pages for Web service client applications. The implementation uses a SOAP-based mechanism. A client application would access the WSDL document, then use the WSDL information to access the operations of a Web service.
The tag library also uses the Oracle implementation of the dynamic invocation API, described in the Oracle Application Server Web Services Developer's Guide. When a client application acquires a WSDL document at runtime, the dynamic invocation API is the vehicle for invoking any SOAP operation described in the WSDL document. The tag handler uses the API when sending a SOAP request that invokes a Web service and when handling the SOAP response.
The Oracle dynamic invocation API consists of classes and interfaces in the oracle.j2ee.ws.client
and oracle.j2ee.ws.client.wsdl
packages.
The oracle.j2ee.ws.client
package includes the following.
WebServiceProxyFactory
: Given a WSDL document (through a Java input stream that contains the document or through the URL of the document), a WebServiceProxyFactory
instance can use the name of a service and the name of one of its ports, as specified in the WSDL document, to create a WebServiceProxy
instance (an instance of a class that implements the WebServiceProxy
interface).
WebServiceProxy
: Use this interface in representing a service defined in a WSDL document. Each WebServiceProxy
instance is based on the location of the WSDL document and, optionally, on additional qualifiers that identify which service and port should be used. A WebServiceProxy
class exposes methods to determine the WSDL port type, including the syntax and signatures of all operations exposed by the WSDL document, and to invoke the defined operations.
WebServiceMethod
: Use this interface in invoking a Web service method, or operation.
The oracle.j2ee.ws.client.wsdl
package includes the following.
Operation
: This interface represents a WSDL operation.
Message
: This interface represents a message used in the input or output of an operation.
Part
: This interface represents a message part.
Input
: This interface represents an input message.
Output
: This interface represents an output message.
Note: The dynamic invocation API is packaged indsv2.jar in the ORACLE_HOME /lib directory. Also note that the SOAP implementation requires soap.jar in the ORACLE_HOME /soap directory.
|
This section provides an overview of the OC4J Web services tag library and its functionality. The tag library includes support for the following:
Binding to a Web service
Using a Web service operation through SOAP requests and SOAP responses
Defining input and output message parts
Mapping SOAP/XML datatypes to Java types
Setting custom properties for use by the client application
The tag library supports invoking operations defined in WSDL documents that use the W3C XML schema version whose namespace is the following:
http://www.w3.org/2001/XMLSchema
The Web services tag library includes the webservice
tag, optionally with nested map
and property
tags, and the invoke
tag, optionally with nested part
tags. They are used as follows.
webservice
: Use this tag to create a Web service proxy. The tag requires the URL of a WSDL document and then uses one of the following combinations:
A binding and SOAP location, useful for a WSDL document identified in a UDDI registry
A service name and port, provided through tag attributes or through the first service and its first port from the WSDL document
map
: The Web service proxy uses this tag, if specified, to add an entry to the SOAP mapping registry, which is a registry that maps local SOAP/XML types to Java types. Any number of map
tags can be nested within a webservice
tag, one tag for each desired type mapping.
property
: Optionally, use this tag to define any of several supported custom properties for use by the Web service client application. Each property
tag must be nested within the webservice
tag; the property will have the same scope as the parent Web service.
invoke
: Use this tag to invoke an operation of the Web service. An invoke
tag accesses a Web service proxy either by being nested within a webservice
tag, or through a scripting variable.
part
: If an operation has input message parts, use part
tags, nested within an invoke
tag, to define the message parts. Use one part
tag for each part.
Notes:
Because the OC4J Web services tag library implementation is based on the OracleAS Web Services implementation, any additional limitations of OracleAS Web Services also apply to the tag library. |
The following sections supply detailed descriptions of the OC4J Web services tags, a standards-compliant JavaServer Pages tag library implementation, including syntax documentation:
Note the following requirements for the Web services tag library:
The Web services tag library is included in the ojsputil.jar
file. This file is provided with OC4J, in the "well-known" tag library directory. Verify that this file is installed and in your classpath.
The tag library descriptor, wstaglib.tld
, must be available to the application, and any JSP page using the library must have an appropriate taglib
directive. In an Oracle Application Server installation, the TLD is in ojsputil.jar
. The uri
value for wstaglib.tld
is the following:
http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/wstaglib.tld
You can refer to the Oracle Application Server Containers for J2EE Support for JavaServer Pages Developer's Guide for information about taglib
directives, the well-known tag library directory, TLD files, and the meaning of uri
values.
For an example that uses the tags described in this section, see "Web Services Tag Examples".
Notes:
|
Use this tag to create a Web service proxy, an instance of a class that implements the oracle.j2ee.ws.client.WebServiceProxy
interface. The tag requires the URL of a WSDL document and uses a binding and SOAP location or a service name and port, as follows:
First, if tag attributes provide a binding and SOAP location, the tag handler uses them in creating the proxy. Tag attributes for service name and port are ignored in this case.
If no binding and SOAP location are provided, the tag handler uses a service name and port, as follows:
If a service name and port are provided through tag attributes, then the tag handler uses them in creating the proxy.
If no service name and port are provided, the tag handler uses the first service in the WSDL document and the first port listed for that service.
Using a binding and SOAP location is particularly useful for a Web service whose WSDL document is accessed through a UDDI registry. In that case, the binding and location can be determined through UDDI queries and supplied to the tag through request-time expressions.
After the Web service proxy is created, it will use any nested map
tags to add entries to the SOAP mapping registry. See the next section, "Web Services map Tag".
<ws:webservice wsdlUrl = "WSDL_URL_of_Web_service" [ id = "variable_name_for_Web_service_proxy" ] [ scope = "page" | "request" | "session" | "application" ] [ binding = "SOAP_binding_information" ] [ soapLocation = "SOAP_endpoint_URL" ] [ service = "service_name_in_WSDL" ] [ port = "port_name_for_service" ] > ...body / nested tags... </ws:webservice>
Note: Thescope attribute cannot take request-time expressions.
|
wsdlUrl
(required): Use this attribute to specify a URL where the WSDL for the desired Web service can be accessed.
id
: If the Web service is to be accessed by an invoke
tag that is not nested within the webservice
tag, use the id
attribute to specify the name for a WebServiceProxy
scripting variable so that the variable can be referenced by the invoke
tag. The specified name must be a valid Java identifier. When you use the id
attribute, the specified variable will be declared automatically with scope AT_END
(available from the webservice
end-tag to the end of the JSP page).
scope
: Optionally, specify the scope of the webservice
tag. The default setting is "page
".
binding
: In scenario #1 above, use the binding
attribute to specify the SOAP binding information for a SOAP location (end-point URL) that you specify through the soapLocation
attribute. You must use these attributes together. The binding information is as defined in the WSDL document, specifying concrete protocol and data format specifications for the operations and messages defined by a particular port type.
soapLocation
: In scenario #1 above, use soapLocation
to specify a SOAP location (end-point URL) as defined in the WSDL document, for which the binding information specified through the binding
attribute applies. You must use these attributes together.
service
: In scenario #2a above, use the service
attribute to specify the name of a service defined in the WSDL document. You must use this attribute with the port
attribute, but both are ignored if you use binding
and soapLocation
.
port
: In scenario #2a above, use the port
attribute to specify a port for the service that is specified through the service
attribute. You must use these attributes together. The Web service proxy will use the specified port. The port address will be as specified in the corresponding <service>
element in the WSDL document. The service
and port
attributes are ignored if you use binding
and soapLocation
.
For interoperability, a mapping mechanism is necessary to map WSDL-defined SOAP/XML datatypes to the Java types used in JSP pages of a Java client application. This is possible through the OracleAS Web Services SOAP mapping registry.
You can have any number of map
tags nested within a webservice
tag, to have the Web service proxy add entries to the registry. Use one map
tag for each desired type mapping.
The registry is an instance of the XMLJavaMappingRegistry
class of the org.apache.soap.util.xml
package. A WebServiceProxy
instance has a getXMLMappingRegistry()
method to access the registry.
The map
tag includes attributes to specify the encoding style, serialization utility (class name), deserialization utility (class name), and namespace URI to facilitate the type mapping. The Web services tag library supports custom classes for serialization and deserialization, if you want to create your own.
Important: When using amap tag, you must nest it within a webservice tag.
|
<ws:map localName = "local_name_of_SOAPXML_type" namespaceUri = "URI_of_namespace_for_SOAPXML_type" javaType = "Java_type_to_map" encodingStyle = "URL_of_SOAP_encoding_style" java2xmlClassName = "Java_to_XML_serializer" xml2javaClassName = "XML_to_Java_deserializer" />
localName
(required): Specify the local name of the SOAP/XML datatype, such as SOAPStruct
, for example.
namespaceUri
(required): Specify a valid URI for the namespace of the SOAP/XML datatype. The following is an example:
http://soapinterop.org/xsd
javaType
(required): Specify the Java type which you want to map to the SOAP/XML type. The types must be legally mappable.
encodingStyle
(required): Specify a valid URI for a SOAP encoding style. The following is an example:
http://schemas.xmlsoap.org/soap/encoding
java2xmlClassName
(required): Specify the class name with the functionality for serializing the data for Java-to-XML conversion. This can be a custom class. The following is an example:
org.apache.soap.encoding.soapenc.BeanSerializer
xml2javaClassName
(required): Specify the class name with the functionality for deserializing the data for XML-to-Java conversion. This can be a custom class. The following is an example:
org.apache.soap.encoding.soapenc.BeanSerializer
You can optionally use this tag to specify a name/value pair that defines any of several supported custom properties for use by the Web service client application. For example, you could use property
tags to specify an HTTP proxy host and proxy port if a proxy is required for access through a network firewall. The following properties are supported:
http.proxyHost
: Use this property to specify the host name of an HTTP proxy server.
http.proxyPort
: Use this property to specify a port number of an HTTP proxy server.
javax.net.ssl.KeyStore
: Use this property to specify the full path of an Oracle security wallet file.
Important: When using aproperty tag, you must nest it within a webservice tag. The property will have the same scope as the parent Web service.
|
Use this tag to invoke an operation of the Web service. The tag handler will call the remote Web service operation by passing an input message in a SOAP request, then will wait for the SOAP response. You must specify the operation, as well as an object ID for the object that will contain the returned response. The tag handler uses the operation name to find the operation in the WSDL document.
The invoke
tag gains access to a Web service proxy in one of two ways:
The invoke
tag is nested within the webservice
tag that establishes the proxy.
The invoke
tag uses its webservice
attribute to access a WebProxyService
scripting variable created through a webservice
tag id
attribute.
In a situation where there are overloaded operations (two operations of the same name using different I/O messages), the invoke
tag has attributes to specify the input and output message names for the desired operation. In this case, for RPC-style bindings, the specified input and output message names are used to form the RPC signature of the operation. Otherwise, the RPC signature is the default according to the WSDL document.
If the output message has multiple parts, then the returned result is an array of message parts (all within a single SOAP response).
The invoke
tag can act as an XML producer, supporting explicit passing of an XML output object through the toXMLObjName
attribute. This is useful if the invoke
tag is nested inside other kinds of tags such as Web Object Cache tags or the XML transform
tag. Also note that an XML output object can be written to the JspWriter
object of the JSP page for output directly to the user's browser. This is enabled through the xmlToWriter
attribute.
Notes:
|
<ws:invoke id = "variable_name_for_output_result" operation = "operation_to_invoke" [ webservice = "variable_name_of_Web_service_proxy" ] [ inputMsgName = "name_of_input_message" ] [ outputMsgName = "name_of_output_message" ] [ xmlToWriter = "true" | "false" ] [ toXMLObjName = "objectname" ] > ...body / nested tags... </ws:invoke>
id
(required): Specify a scripting variable name for the output result object. The specified name must be a valid Java identifier. See the note preceding the tag syntax above for information about the scope of the id
object.
operation
(required): Specify an operation to be executed (an operation from the WSDL document).
webservice
: Use this attribute if you want to specify the name of a WebServiceProxy
scripting variable corresponding to the service to invoke. This is not necessary if the invoke
tag is nested inside the webservice
tag that accesses the desired service.
inputMsgName
: Optionally specify the input message name—the name of a wsdl:input
tag in the WSDL document—for the operation. This is only necessary if there are overloaded operations (operations with the same name that use different message names).
outputMsgName
: Optionally specify the output message name—the name of a wsdl:output
tag in the WSDL document—for the operation. This is necessary only if there are overloaded operations (operations with the same name that use different message names).
xmlToWriter
: For a document-style Web service, and if the output is an XML object, set this attribute to "true
" if you want to output the XML to the JspWriter
output object of the JSP page. The default setting is "false
".
toXMLObjName
: For a document-style Web service, and if you want to explicitly pass the output in an XML object, use this attribute to specify the name of the object.
Use this tag, nested within an invoke
tag, if the operation being performed requires input message part values, using one part
tag for each input part.
How to specify the part value might depend on whether you are using an RPC-style or document-style Web service. For RPC-style, you must use the value
attribute. For document-style, you have the option of passing the value through an XML request element in the tag body.
Note: If you use both a tag body and thevalue attribute, the tag body is ignored.
|
This section provides a template for use of the Web services tag library, a sample JSP page to invoke an RPC-style Web service, and a sample page to invoke a document-style Web service.
<HTML> <HEAD> <TITLE>Title</TITLE> </HEAD> <BODY> <H2>This is sample HTML text.</H2> <%@ taglib uri="http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/wstaglibrary.tld" prefix="ws" %> <ws:webservice id="myws" wsdlUrl="wsdlurl" { binding="" soapLocation="" | service="" port="" } { scope="page | request | session | application" } > <ws:property name="property" value="string"/> <ws:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" localname="SOAPStruct" namespaceUri="http://soapinterop.org/xsd" javaType="MySoapStructBean" java2xmlClassName="org.apache.soap.encoding.soapenc.BeanSerializer" xml2javaClassName="org.apache.soap.encoding.soapenc.BeanSerializer" /> </ws:webservice> <ws:invoke id="result" webservice="myws" operation="add" inputMsgName="" outputMsgName=""> <ws:part name="part_name" value="{string | <%= expression %>}"/> </ws:invoke> <% =result %> </BODY> </HTML>
<%@ page contentType="text/html"%> <%@ taglib uri="http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/wstaglib.tld" prefix="ws" %> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; "> </HEAD> <BODY> <% String itemID = request.getParameter("itemID"); %> <ws:webservice id="ebay" wsdlUrl="http://www.xmethods.net/sd/2001/EBayWatcherService.wsdl" binding="eBayWatcherBinding" soapLocation="http://services.xmethods.net:80/soap/servlet/rpcrouter" scope="page"> <ws:property name="http.proxyHost" value="www-proxy.us.oracle.com"/> <ws:property name="http.proxyPort" value="80"/> </ws:webservice> <ws:invoke id="price" webservice="ebay" operation="getCurrentPrice"> <ws:part name="auction_id" value="<%=itemID%>"/> </ws:invoke> <B> Action price for eBay Item # <%=itemID%> is : </B> <P> $<%= price%> @ <%= new java.util.Date()%> </P> </BODY> </HTML>
<%@ page contentType="text/xml;"%> <%@ page import= oracle.xml.parser.v2.XMLElement;"%> <%@ taglib uri="http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/wstaglib.tld" prefix="ws" %> <%@ taglib uri="http://xmlns.oracle.com/j2ee/jsp/tld/ojsp/xml.tld" prefix="xml" %> <ws:webservice id="bookService" wsdlUrl="http://hosting.msugs.ch/cheeso9/books/books.asmx?WSDL" binding="LookyBookServiceSoap" soapLocation ="http://hosting.msugs.ch/cheeso9/books/books.asmx" scope="session"> </ws:webservice> <ws:invoke id="bookResult" operation="GetInfo" webservice="bookService"> <ws:part name="parameters"> <GetInfo xmlns="http://dinoch.dyndns.org/webservices/"> <ISBN>SomeISBNNumber</ISBN> </GetInfo> </ws:part> </ws:invoke> <% XMLNode resultNode = (XMLNode) bookResult; resultNode.Error! Bookmark not defined.(new java.io.PrintWriter(out)); %> </BODY> </HTML>