This chapter describes Web Service Definition Language (WSDL) documents and how you can use them in Service Bus projects to generate business and proxy services, pipelines, and split-joins. A WSDL document is the formal description of a web service, defining what the service can do, where it resides, and how to invoke it.
This chapter contains the following sections:
A WSDL document describes a service, its location, its operations, and how clients can communicate with it. This section provides a brief introduction to WSDL, to provide context for discussing Service Bus features.
Table 11-1 summarizes the main elements used to define WSDL services.
Table 11-1 High-level WSDL Elements
| Element | Description |
|---|---|
|
types |
Type definitions for message content. |
|
message |
Abstract definition of the data being exchanged. A message consists of parts, which describe the logical, abstract content of the message. |
|
portType |
Abstract collection of operations supported by the service. |
|
operation |
Abstract description of an action supported by the service. |
|
binding |
Concrete protocol and data format specification for a port type. |
|
port |
A single endpoint, consisting of a network address and a binding. |
|
service |
Collection of related ports, or endpoints. |
WSDL specifies SOAP, HTTP, MIME, and Service Bus-specific binding extensions, which extend the WSDL binding mechanism to support features specific to the protocol or message format.
The types element is a container for data type definitions. It uses a type system, such as XML Schema (XSD), to define the vocabulary of messages handled by this service. For example, a service that provides stock quotes might define an XML vocabulary, with the terms TradePriceRequest and TradePrice, as shown in the following example.
Example -WSDL Types Example
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2001/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>
The message element provides an abstract, typed definition of the data being communicated. A message consists of parts, each of which describes one logical, abstract unit of the message. A WSDL document can define one or more messages, each of which may have one or more parts. For example, the WSDL fragment in the following example defines four message types, sellerInfoMessage, buyerInfoMessage, response, and negotiationMessage, each of which has one or more parts.
Example - WSDL Message Example
<message name="sellerInfoMessage">
<part name="inventoryItem" type="xsd:string"/>
<part name="askingPrice" type="xsd:integer"/>
</message>
<message name="buyerInfoMessage">
<part name="item" type="xsd:string"/>
<part name="offer" type="xsd:integer"/>
</message>
<message name="response">
<part name="result" type="xsd:string"/>
</message>
<message name="negotiationMessage">
<part name="item" type="xsd:string"/>
<part name="price" type="xsd:integer"/>
<part name="outcome" type="xsd:string"/>
</message>
The portType element defines a set of operations supported by one or more endpoints, which are defined in the port element (see WSDL Services and Ports). The port type provides the public interface for the operations provided by the service. Each operation is defined in an <operation> element, each of which is an abstract description of an action supported by the service.
For example, the following example defines a port type with one operation, GetLastTradePrice, which can handle an input message, GetLastTradePriceInput, and an output message, GetLastTradePriceOuput. The concrete descriptions of these messages are defined in the WSDL binding, as shown in the soap:operation subelement in the following example.
Example - WSDL Port Type and Operation Example
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
The binding element specifies a concrete data format specification and a concrete transport protocol for a port type. The following example specifies the binding for the StockQuotePortType port type, which is provided as the value for the type attribute. The soap:binding subelement signifies that the binding is bound to the SOAP protocol format. In that subelement, the style attribute specifies that the data format is SOAP document style, and the transport attribute specifies that the transport protocol is HTTP.
Example - WSDL Binding Example
<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>
The service element defines a collection of related endpoints, each of which is defined in a child port element. A port is defined as a binding associated with a network address. The following example defines two ports, StockQuotePort, and StockQuotePortUK. They both use the same binding, tns:StockQuoteSoapBinding, which is concretely defined in binding, but they have different network addresses: http://example.com/stockquote and http://example.uk/stockquote. These are alternative ports available for this service.
Example - WSDL service and port Example
<service name="StockQuoteService">
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com:9999/stockquote"/>
</port>
<port name="StockQuotePortUK" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.uk:9999/stockquote"/>
</port>
</service>
In Service Bus, a WSDL document describes a proxy or business service, pipeline, or split-join. You can base SOAP and XML services on an existing WSDL resource.
Service Bus defines some types of business services, proxy services, and pipelines using a WSDL document, an XML-based specification for describing web services. All split-joins are based on a WSDL document. A WSDL document describes service operations, input and output parameters, and how a client application connects to the service. For the WSDL 1.1 specification, see the W3C Note, "W3C Web Services Description Language (WSDL) 1.1," at http://www.w3.org/TR/wsdl.
Oracle Service Bus defines proxy services and business services in terms of two WSDL entities:
The abstract WSDL interface, which defines the operations in that interface and the types of message parts in the operation signature.
The binding WSDL interface, which defines the binding of the message parts to the message (packaging), and the binding of the message to the transport.
If a service has a well-defined WSDL interface, it is recommended, although not required, that you use the WSDL document to define the service. There are three types of WSDL documents you can define:
A document wrapped web service is described in a WSDL file as a Document Style Service. However, it follows some additional conventions. Standard document-oriented web service operations take only one parameter or message part, typically an XML document. This means that the methods that implement the operations must also have only one parameter. Document-wrapped web service operations, however, can take any number of parameters, although the parameter values will be wrapped into one complex data type in a SOAP message. This wrapped complex data type is described in the WSDL document as the single document for the operation.
You can configure Service Bus services as SOAP-style services. The following example provides an example of a WSDL for a sample document style web service using SOAP 1.1.
Example - WSDL for a Sample Document Style Web Service
<definitions name="Lookup"
targetNamespace="http://example.com/lookup/service/defs"
xmlns:tns="http://example.com/lookup/service/defs"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:docs="http://example.com/lookup/docs"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<xs:schema targetNamespace="http://example.com/lookup/docs"
elementFormDefault="qualified">
<xs:element name="PurchaseOrg" type="xs:string"/>
<xs:element name="LegacyBoolean" type="xs:boolean"/>
</xs:schema>
</types>
<message name="lookupReq">
<part name="request" element="docs:purchaseorg"/>
</message>
<message name="lookupResp">
<part name="result" element="docs:legacyboolean"/>
</message>
<portType name="LookupPortType">
<operation name="lookup">
<input message="tns:lookupReq"/>
<output message="tns:lookupResp"/>
</operation>
</portType>
<binding name="LookupBinding" type="tns:lookupPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="lookup">
<soap:operation/>
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
</definitions>
The service has an operation (equivalent to a method in a Java class) called lookup. The binding indicates that this is a SOAP 1.1 document style web service.
When the WSDL document shown above is used for a request, the value of the body variable ($body) that the document style proxy service obtains is displayed in the following example.
Note:
Namespace declarations have been removed from the XML in the listings that follow for the sake of clarity.
Example - Body Variable Value
<soap-env:body> <req:purchaseorg>Oracle</req:purchaseorg> </soap-env:body>
In the previous example, soap-env is the predefined SOAP 1.1 namespace and req is the namespace of the PurchaseOrg element (http://example.com/lookup/docs).
If the business service to which the proxy service is routing uses the above WSDL file, the value for the body variable ($body) given above is the value of the body variable ($body) from the proxy service.
The value of the body variable ($body) for the response from the invoked business service that the proxy service receives is displayed in the following example.
Note:
Namespace declarations have been removed from the XML in the listings that follow for the sake of clarity.
Example - Body Variable Value
<soap-env:body> <req:legacyboolean>true</req:legacyboolean> </soap-env:body>
This is also the value of the body variable ($body) for the response returned by the proxy service using this WSDL file.
There are many tools available that take the WSDL file of a proxy service (obtained by adding the ?WSDL suffix to the URL of the proxy service in the browser) and generate a Java class with the appropriate request and response parameters to invoke the operations of the service. This Java class can be used to invoke the proxy service that uses this WSDL file.
You can configure proxy services and business services as RPC-style services. The following example provides an example of a WSDL file for a sample RPC style web service using SOAP 1.1.
Example - WSDL File for a Sample RPC Style Web Service
<definitions name="Lookup"
targetNamespace="http://example.com/lookup/service/defs"
xmlns:tns="http://example.com/lookup/service/defs"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:docs="http://example.com/lookup/docs"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<xs:schema targetNamespace="http://example.com/lookup/docs"
elementFormDefault="qualified">
<xs:complexType name="RequestDoc">
<xs:sequence>
<xs:element name="PurchaseOrg" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ResponseDoc">
<xs:sequence>
<xs:element name="LegacyBoolean" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</types>
<message name="lookupReq">
<part name="request" type="docs: RequestDoc"/>
</message>
<message name="lookupResp">
<part name="result" type="docs: ResponseDoc"/>
</message>
<portType name="LookupPortType">
<operation name="lookup">
<input message="tns:lookupReq"/>
<output message="tns:lookupResp"/>
</operation>
</portType>
<binding name="LookupBinding" type="tns:lookupPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="lookup">
<soap:operation/>
<input>
<soap:body use="literal" namespace="http://example.com/lookup/service"/>
</input>
<output>
<soap:body use="literal" namespace="http://example.com/lookup/service"/>
</output>
</operation>
</binding>
</definitions>
The service described in the preceding listing includes an operation (equivalent to a method in a Java class) called lookup. The binding indicates that this is a SOAP RPC web service. In other words, the web service's operation receives a set of request parameters and returns a set of response parameters. The lookup operation has a parameter called request and a return parameter called result. The namespace of the operation in the binding is:
http://example.com/lookup/service/defs
When the WSDL document shown in the previous WSDL File for a sample RPC Style Web Service Example is used for a request, the value of the body variable ($body) that the SOAP RPC proxy service obtains is displayed in the following example.
Note:
Namespace declarations have been removed from the XML in the listings that follow for the sake of clarity.
Example - Body Variable Value
<soap-env:body>
<ns:lookup>
<request>
<req:purchaseorg>Oracle</req:purchaseorg>
</request>
</ns:lookup>
<soap-env:body>
In the above, soap-env is the predefined SOAP 1.1 name space, ns is the operation namespace (http://example.com/lookup/service) and, req is the namespace of the PurchaseOrg element (http://example.com/lookup/docs).
If the business service to which the proxy service routes the messages uses the WSDL file shown in the previous example, the value for the body variable ($body), shown in the following example, is the value of the body variable ($body) from the proxy service.
When this WSDL document is used for a request, the value of the body variable ($body) for the response from the invoked business service that the proxy service receives is displayed in the following example.
Example - Body Variable Value
<soap-env:body>
<ns:lookupResponse>
<result>
<req:legacyboolean>true</req:legacyboolean>
</result>
</ns:lookupResponse>
<soap-env:body>
This is also the value of the body variable ($body) for the response returned by the proxy service using this WSDL file.
There are many tools available that take the WSDL file of a proxy service (obtained by adding the ?WSDL suffix to the URL of the proxy in the browser) and generate a Java class with the appropriate request and response parameters to invoke the operations of that service. You can use such Java classes to invoke the proxy services that use this WSDL file.
The benefits of using a WSDL document include the following:
The system can provide metrics for each operation in a WSDL document.
Operational branching is possible in the pipeline. For more information, see Branching in Pipelines.
For SOAP 1.1 services, the SOAPAction header is automatically populated for services invoked by a proxy service. For SOAP 1.2 services, the action parameter of the Content-Type header is automatically populated for services invoked by a proxy service.
A WSDL file is required for services using WS-Security. WS-Policies are attached to WSDL files.
The system supports the <url>?WSDL syntax, which allows you to dynamically obtain the WSDL file of an HTTP proxy service. This is useful for a number of SOAP client generation tools. For more information, see Viewing Service Bus Resources in a Web Browser.
In the XQuery and XPath editors and condition builders, it is easy to manipulate the body content variable ($body) because the editor provides a default mapping of $body to the request message in the WSDL file of a proxy service. SeeMessage Context.
The runtime contents of $body for a specific action can be different from the default mapping displayed in the editor. This is because Service Bus is not a programming language in which typed variables are declared and used. Instead, variables are untyped and are created dynamically at runtime when a value is assigned. In addition, the type of the variable is the type that is implied by its contents at any point in the message flow. To enable you to easily create XQuery and XPath expressions, the editor allows you to map the type for a given variable by mapping the variable to the type in the editor. To learn about using the XQuery and XPath editor to create expressions, see Using Variable Structures.
In Service Bus, you can base a new service on an existing WSDL file (called a WSDL resource) and then override or add configuration properties. In the runtime, Service Bus generates an effective WSDL document for the service that includes the configuration of the WSDL resource along with additional transport and runtime configuration.
For WSDL-based services, Service Bus uses effective WSDL documents in the runtime instead of the actual .wsdl files you create when you develop Service Bus services. The effective WSDL document represents a service's WSDL properties as configured in Service Bus and also includes additional properties configured outside of the source WSDL document. The source WSDL document serves as a template for the effective WSDL document.
When you create a service based on a WSDL document, Service Bus generates an effective WSDL document at runtime by combining properties from the original WSDL document, any transport properties you configured, runtime settings (like the target server), and any WS-Policy configurations. Any properties you add or change from the original WSDL document during runtime are included in the effective WSDL document. Properties from the source WSDL document that are not used in the new configuration are omitted from the effective WSDL document.
Service Bus can generate effective WSDL documents for SOAP and XML services that are created from a WSDL document and that use any transport that supports WSDL-based services, such as HTTP, JMS, SB, and so on. Service Bus cannot generate effective WSDL documents for services of the following types: Any SOAP, Any XML, and messaging.
Effective WSDL documents have different characteristics for proxy services and business services and for services based on WSDL ports or on WSDL bindings. For more information, see Services Based on WSDL Ports and on WSDL Bindings.
A generated WSDL document is an effective WSDL document that Service Bus generates for transport-type services that were not created from a WSDL resource but that can be described using a WSDL document. For example, you can generate a WSDL document from an EJB-based service.
When you create a service based on a WSDL resource, you must base the service on a WSDL port or on a WSDL binding.
When you create a new service based on a binding in a WSDL resource, you are choosing the protocol and data format defined in the selected binding element in the WSDL resource.
When you create a new service based on a port in a WSDL resource, you are choosing the binding and the network address defined in the port element.
When you create or modify the service, you can change the transport, but you cannot override the data format. The port and binding definitions from the original WSDL resource are modified in the effective WSDL depending on various factors, as described in the following sections.
The following characteristics apply to effective WSDL documents generated for proxy services:
The effective WSDL document has one and only one wsdl:service section.
The wsdl:service section has one and only one wsdl:port section.
For SOAP services, any existing <wsdl:service> definition is removed, and a new service definition containing a single <wsdl:port> is created.
For SOAP binding over any of the supported transports the wsdl:binding section contains the standard WSDL SOAP binding elements along with a unique transport URI that identifies the transport.
For XML binding over HTTP, the wsdl:binding section uses the standard binding elements specified in the WSDL 1.1 specification.
For XML binding over any of the other supported transports the wsdl:binding section uses Oracle (Service Bus) proprietary WSDL XML binding elements.
If the service is based on a binding, the following characteristics apply:
The effective WSDL document defines a new service and port (<bindingname>QSService and <bindingname>QSPort). None of the ports defined in the WSDL resource are included in the effective WSDL document.
There may be multiple ports in that WSDL document associated with that binding. Each port can use a different URL. Therefore, the effective WSDL document uses the binding but generates an artificial port from the configuration on the service for that binding. All other ports are removed.
If the service is based on a port, the following characteristics apply:
The port on which the service is based is also defined in the effective WSDL document. Any other ports defined in the WSDL resource are not included. Furthermore, if you base the proxy service on a WSDL port, the effective WSDL document uses that port name. The binding is determined from the port, and in turn, the port type is determined from the binding.
The effective WSDL document preserves any WS-Policies associated with the port defined in the WSDL resource.
The transport address specified in the port definition in the source WSDL document is never used as the address for a proxy service in the effective WSDL document:
For HTTP services, you must specify a transport address when configuring the transport. That address is used in the port definition in the effective WSDL document.
The URL specified as the transport address for a proxy service is always relative to a path in a Service Bus domain, because Service Bus always hosts proxy services.
For SOAP-protocol WSDL services, the transport URI in the SOAP binding depends on the transport implementation. For standard transports (like HTTP and JMS), this value is as per the SOAP specification or another universally accepted value. For transports for which SOAP does not define a standard value, Service Bus sets one consisting of a predefined namespace with the transport ID appended at the end: http://www.oracle.com/transport/2007/05/.
There is one service element in the effective WSDL document, and the port address contains a URL whose syntax and semantic are defined by the transport selected in the binding.
The following characteristics apply to effective WSDL documents generated for business services that are not transport typed:
The effective WSDL document has one and only one wsdl:service section.
The wsdl:service section may have more than one wsdl:port sections. This is generally true when load balancing is used and there are multiple endpoint addresses that can be used using one of the load-balance algorithms supported.
For SOAP binding over any of the supported transports, the wsdl:binding section contains the standard WSDL SOAP binding elements along with a unique transport URI that identifies the transport.
For XML binding over any of the supported transports, the wsdl:binding section contains the Oracle WSDL XML binding elements.
The URL specified as the transport address is a remote location where the remote service is hosted.
If the service is based on a port, the following characteristics apply:
The effective WSDL document defines a port with the same name as the port in the source WSDL document. If multiple endpoint addresses are configured for the business service, the effective WSDL document generated from it defines ports for all the endpoints, with the names <portname_in_template>_1, <portname_in_template>_2,...
The binding for the new service is determined from the port, and the port type is in turn determined from the binding.
The transport address URL is a remote location where the remote service is hosted.
If the service is based on a binding, the following characteristics apply:
The effective WSDL document defines a new service and port, based on the port in the WSDL resource. None of the ports defined in the WSDL resource are included in the effective WSDL file.
A binding in the WSDL resource may be associated with multiple ports. Each port can use a different URL and have a different WS-Policy attached to it. Therefore, the generated WSDL document uses the binding but generates an artificial port for that binding with no WS-Policy.
For XML-based WSDL services, standard HTTP binding is used only if the service uses HTTP transport. For all other services created from an XML-based WSDL file, the effective WSDL document uses Oracle binding.
Service Bus does not guarantee one and only one wsdl:service section in effective WSDL documents generated for transport-type business services. Because the WSDL document is generated by the transport, Service Bus does not generate nor clean up extra service-port sections. Service Bus does, however, evaluate dependencies and sets their references during export.
The following example shows fragments of port and binding definitions in a WSDL resource.
Example - WSDL Resource
<portType name="StockQuotePortType"> ... </portType> <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> ... </binding> <service name="StockQuoteService"> <port name="StockQuotePort" binding="tns:StockQuoteSoapBinding"> <soap:address location="http://example.com:9999/stockquote"/> </port> <port name="StockQuotePortUK" binding="tns:StockQuoteSoapBinding"> <soap:address location="http://example.uk:9999/stockquote"/> </port> </service>
If you create a proxy service based on the example in Examples of Proxy Services Based on a Port and on a Binding, the effective WSDL document will look similar to the fragment in the following example.
Example - Effective WSDL File for a Proxy Service Based on a Port
<binding name="StockQuoteSoapBinding" type="ns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> ... </binding> <service name="StockQuoteService"> <port name="StockQuotePort" binding="ns:StockQuoteSoapBinding"> <soap:address location="http://host:port/project/proxyname"/> </port> </service>
Notice the following about the above example:
The service name, StockQuoteService, is the same in both the template and the effective WSDL document.
The binding is the same in both the template and the effective WSDL document. In this example, it specifies that the service will use the HTTP transport protocol for SOAP document style messages. The binding also specifies the same binding operation in both the WSDL resource and the effective WSDL document, but that is not shown in this example.
The second port defined in the WSDL resource, StockQuotePortUK, is not defined in the effective WSDL document.
The transport address (URI) defined in the WSDL resource's port, http://example.com:9999/stockquote, is different from the address generated in the effective WSDL document's port, http://host:port/project_path/proxy_service_name. The effective WSDL document uses the address that was specified for the transport when it was being configured.
If you create a proxy service based on the StockQuoteBinding binding in Examples of Proxy Services Based on a Port and on a Binding, the effective WSDL document will look something like the fragment in the following section.
Example - Effective WSDL Document for a Proxy Service Based on a Binding
<binding name="StockQuoteSoapBinding" type="ns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> ... </binding> <wsdl:service name="StockQuoteSoapBindingQSService" <wsdl:port name="StockQuoteSoapBindingQSPort" binding="ns:StockQuoteSoapBinding"> <soap:address location="http:/host:port/project/proxyname"/> </wsdl:port> </wsdl:service>
Notice the following about the above example:
The service and the port in the WSDL resource are different from the service and the port generated in the effective WSDL document.
The service name in the WSDL resource and the effective WSDL document are different: StockQuoteService in the template and StockQuoteSoapBindingQSService in the effective WSDL document.
The binding is the same in both the WSDL resource and effective WSDL document. In this example, it specifies that the service will use the HTTP transport protocol for SOAP document style messages.
The binding also specifies the same binding operation in both the template and the effective WSDL document, but that is not shown in this example.
The transport address (URI) defined in the WSDL resource's port, http://example.com:9999/stockquote, is different from the address generated in the effective WSDL's port, http://host:port/project/stockquote.
Exporting a WSDL document generates a JAR file that contains the effective WSDL document along with any associated dependencies, such as XML schemas.
Service Bus evaluates the dependencies, and the appropriate location is added to the location attribute of the WSDL import element. You cannot export a generated WSDL document.
For more information about importing and exporting resources, see Importing and Exporting Resources and Configurations .
In JDeveloper, a WSDL file is generated and added to the Service Bus project when you create a new proxy or business service based on a JCA adapter. You can also create a WSDL file from scratch using standard JDeveloper tools.
WSDL files are not generated in the Oracle Service Bus Console. Import the required WSDL file to use it with a service.
WSDL files are a standard feature in JDeveloper. For information about the editors and tools you use to create WSDL files, see Developing Applications Using XMLin Developing Applications with Oracle JDeveloper.
If the WSDL resource you want to create contains URL references to external schemas that do not currently exist in JDeveloper, such as http://www.w3.org/2001/XMLSchema.xsd, you must add those URL-referenced schemas, along with any dependent schemas, to Service Bus by creating XML Schema resources. WSDL resources in Service Bus can only reference locally available schemas. You can generate the WSDL file using an XML schema definition (XSD) file or using a sample file.
Defining input and output types for a new WSDL document requires specifying an XML type for the message parts. If you want to use a schema XSD file that resides on your local file system, make sure the XSD file and any XSD files that it imports all reside in the JDeveloper project directory. This ensures that the schema is deployed with the project and is made available at runtime.
To create a WSDL document in JDeveloper:
Do one of the following:
To create a new WSDL resource: In the Application Navigator, right-click the project or folder in which you want to place the new WSDL file. Point to New and select SOA WSDL Document.
To create a new WSDL resource from within a service's creation wizard: Click the Generate WSDL icon to the right of the WSDL field.
The Create WSDL dialog appears.
On the Create WSDL dialog, enter a unique name for the WSDL file, and enter the directory where you want to store the file or accept the default.
By default, files are stored in the project folder. This must be the current project directory or one of its subdirectories. If the specified directory does not exist, Oracle JDeveloper creates it.
In the Namespace field, enter a namespace address for the WSDL file; for example, http://example.com/OrderProcess/wsdl.
The namespace that you specify is defined as the tns namespace in the WSDL file.
In the Binding field, enter the name of the binding in the WSDL file to create for the service. Select the binding type from the list of available options (SOAP 1.1, SOAP 1.2, or XML).
Select Create Port Type to create a new port type and operation for the WSDL document, or select Select Port Type to select a port type from an existing WSDL document.
Do one of the following:
In the Port Type field, enter a name for the port type that will contain the operation to use.
In the Operation field, enter the name for the operation to use.
Note:
Spaces and special characters are not allowed in an operation name or port type. Only alphabetic and numeric characters are supported, and the first character cannot be a number.
In the Interface Type field, select One-Way Interface for request-only messaging, or select Synchronous Interface for request-response messaging.
The available fields change based on your selection.
To the upper right of the Input field, click Add a new message part.
On the Add Message Part dialog, do the following:
In the Part Name field, enter a name for the message part.
To the right of the URL field, click the browse for schema file icon to browse for and select an XML type.
The Type Chooser dialog appears with a list of the schema and WSDL files to choose from.
Expand the Type Explorer tree to locate and select the schema root element to use, and click OK.
The Add Message Part dialog reappears with the URL and Schema Element fields populated from the Type Chooser dialog. If you selected an XSD simple type, the Schema Element field is replaced by a Simple Type field.
Tip:
If the schema you want to use is not located in the project in which you are working, you can import a schema XSD file or WSDL file into the project using the Import Schema File or Import WSDL icon in the upper right corner of the dialog.
Click OK again.
The new message part information appears in the Input field of the Create WSDL dialog.
If needed, repeat the above steps to define additional message parts.
If you selected Synchronous Interface as the interface type, repeat the above steps to define the output and fault message parts.
Click OK.
Note:
Partner link types are generally used in BPEL, so you do not need to select Generate partnerlinkType extension for Service Bus.
A generated WSDL file is a WSDL file resource that Service Bus generates for a service that did not start with a WSDL resource but that can be described using a WSDL file. You can generate a WSDL file associated with an EJB or JEJB transport-typed business service or a JEJB proxy service.
To generate a WSDL file from service in JDeveloper:
Once you create a WSDL document, you can further configure them using the standard XML Editor in JDeveloper. For information about the editor and tool you use to view and configure WSDL documents, see "Developing Applications Using XML" in Developing Applications with Oracle JDeveloper.
Once you create a WSDL document, you can delete it from the project and the file system. Using the refactoring feature of JDeveloper, you can view any resources that reference the WSDL document. To view dependencies before deleting, right-click the WSDL document and select Explore Dependencies.
To delete a WSDL document in JDeveloper:
If you are using the Oracle Service Bus Console, you can create WSDL documents by importing them or by creating a WSDL resource.
For more information on importing, see Importing and Exporting Resources and Configurations . Use the following procedure to create WSDL resources manually. You should have an existing WSDL file to upload into the WSDL resource.
If the WSDL resource you want to create contains URL references to external schemas that do not currently exist in Service Bus, such as http://www.w3.org/2001/XMLSchema.xsd, you must import those URL-referenced schemas—and any dependent schemas—into the Oracle Service Bus Console by creating XML Schema resources. WSDL resources in Service Bus can only reference locally available schemas.
To create a WSDL resource in the Console:
If you have not already done so, click Create to create a new session or click Edit to enter an existing session.
In the Project Navigator, right-click the project or folder to contain the new WSDL document, point to Create, and select Resource. Click Interfaces, then click WSDL, and then click OK.
The Create WSDL dialog appears.
Do one of the following:
To create the resource from an existing WSDL file, click Browse next to the File Upload field and then navigate to and select the WSDL file to use.
The Resource Name field is automatically populated with the file name minus the file extension. You can change this name.
To create a new WSDL file, enter a unique name for the WSDL resource.
Optionally, enter a brief description of the resource.
Click Create.
The WSDL elements, if defined, appear in the WSDL Definition Editor.
To modify the WSDL file content, do the following:
Click Edit Source in the toolbar.
The Edit Source dialog appears.
To browse to and select a new WSDL file to upload, click Browse.
To modify the contents of the file, update the code directly in the Contents section of the dialog.
Click Save.
In the WSDL Definition Editor toolbar, click Save.
If there are any unresolved references for the new WSDL document, a Conflict icon appears next to the editor's title bar. Use the previous and next arrow buttons to scroll through any errors.
To end the session and deploy the configuration to the runtime, click Activate.
Use the Project or Folder Definition Editor to export a WSDL file associated with a proxy service or a business service. Service Bus exports the WSDL file as a JAR file. You can export a WSDL file only when you are outside a session.
By exporting a WSDL document, you make it available for consumption by external tools such as IDEs. Note that the WSDL export feature is different from the Export Resources feature, which you use to move and stage resources between two domains. This feature is not available for all service types.
To export a WSDL file from a project or folder in the console:
A generated WSDL file is a WSDL file resource that Service Bus generates for a service that did not start with a WSDL resource but that can be described using a WSDL file. Use the Project or Folder Definition Editor to generate a WSDL file associated with an EJB or JEJB transport-typed business service or a JEJB proxy service. You must be working within a session to generate a WSDL file.
To generate a WSDL file from a business service in the console:
Once you create a WSDL resource in the Oracle Service Bus Console, you can modify the file as needed, but only by modifying the source code directly.
To edit a WSDL Document:
If any resources reference the WSDL document you want to delete, remove those references before deleting the WSDL resource. In the Oracle Service Bus Console, open the WSDL document in the WSDL Definition Editor and click the Tools icon in the upper right, and then select References to find out if it has any references.
To delete a WSDL document in the console:
You can view both the design-time and the effective WSDL documents through a web browser. Accessing the files through a browser window displays the contents of the file in XML format.
There are three ways to access an effective WSDL document:
In a web browser, enter the fixed HTTP URL, using the following syntax:
http://host:port/sbresource?PROXY/project_path/proxy_service_name
or
http://host:port/sbresource?BIZ/project_path/business_service_name
This syntax works for all services for which Service Bus can generate effective WSDL documents.
In a web browser, enter the URL for an HTTP-based proxy service, appended with ?WSDL.
This syntax works only for HTTP-transport-based services for which Service Bus can generate effective WSDL documents.
Export the WSDL resource. For more information, see How to Export a WSDL File in the Console and How to Generate a WSDL File from a Service in the Console. For general export information, see Importing and Exporting Resources and Configurations .
Service Bus provides a resource servlet that is used to expose the resources registered in Service Bus through a URL. For more information on accessing Service Bus resources with a URL, see Viewing Service Bus Resources in a Web Browser.
To view the design-time WSDL document, enter the URL using the following syntax:
http://host:port/sbresource?WSDL/project_path/wsdl_name