Oracle® Fusion Middleware Upgrade Guide for Oracle SOA Suite, WebCenter, and ADF 11g Release 1 (11.1.1) E10127-02 |
|
![]() Previous |
![]() Next |
This chapter provides important supplementary information upgrading Oracle SOA applications to Oracle Fusion Middleware 11g.
Use Chapter 8, "Overview of Upgrading Oracle SOA Suite, WebCenter, and ADF Applications" for the tasks required to upgrade any Oracle SOA Suite, WebCenter, and ADF application.
Use the following sections to understand tasks specific to upgrading Oracle SOA applications:
Section 14.1, "Upgrade Tasks Associated with Oracle Enterprise Service Bus"
Section 14.2, "Upgrade Tasks Associated with Technology Adapters"
Section 14.3, "Upgrade Tasks Associated with Human Workflow Tasks"
Section 14.4, "Upgrade Tasks Associated with Oracle Business Rules"
Section 14.5, "Upgrading Oracle SOA Suite Client Applications"
Refer to the following sections for information about upgrading Oracle Enterprise Service Bus 10g to Oracle Mediator 11g:
Upgrading Oracle Enterprise Service Bus Routing Rules That Are Not Exposed as Services
Upgrading Oracle Enterprise Service Bus Domain Value Maps (DVMs) and Cross References
Upgrading Oracle Enterprise Service Bus Projects with SOAP Headers to Oracle Mediator 11g
Upgrading Projects with Multiple Routing Services That Use the Same Namespace
Upgrading Filtering or Setting Message Headers in Oracle Enterprise Service Bus
If you upgrade an Oracle Enterprise Service Bus 10g project that contains an ESB routing service that is not exposed as a Web service, then the routing service and related composites cannot be invoked after upgrade.
To resolve this issue, modify the routing service in Oracle Mediator 11g so it is exposed as a Web service. For more information, see "Creating Mediator Routing Rules" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Alternatively, you can ensure that all routing services in your Oracle Enterprise Service Bus 10g projects are exposed as Web services before you begin the upgrade process.
If you use domain value maps in your and Oracle Enterprise Service Bus 10g projects, then note that while the xPath functions for DVMs and cross-references are upgraded automatically, you must perform a post-upgrade task to upgrade the DVM and cross reference metadata to 11g.
For more information, see Section 9.3.6.7, "Upgrading Domain Value Maps (DVMs) and Cross References with the Oracle SOA Suite Command-Line Upgrade Tool".
If you used XSLT functions to manipulate SOAP headers in Enterprise Service Bus (ESB) 10g, then after you upgrade your application, those header manipulation will be modeled as assignments in Oracle Mediator 11g.
For complex header manipulations, you should manually verify the SOAP headers before deploying the upgraded Oracle Mediator 11g projects.
For more information, see "Creating Static Routing Rules" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Oracle Enterprise Service Bus 10g supports multiple routing services that have WSDLs that reference the same targetNameSpace
within a single ESB project.
For example, at least one of the sample 10g applications available on the Oracle Technology Network (the samples_102_responseForward
sample application) supported this scenario.
However, Oracle Mediator 11g no longer supports this configuration. During the upgrade of the application in Oracle JDeveloper 11g, whenever a second service is found to have the WSDL pointing to the same targetNameSpace
, the namespace is modified by suffixing _service-qname to the namespace. In addition, a warning message is added to the log file.
For example, in the Samples_102_ResponseForward
sample application, the targetNameSpace
of the service DispatchShipmentDetails is:
@ http://oracle.com/esb/namespaces/Samples_102_ResponseForward
After the upgrade of the application, it appears as follows:
@ http://oracle.com/esb/namespaces/ Samples_102_ResponseForward_Samples.102_ResponseForward.DispatchShipmentDetails
In this example, Samples.102_ResponseForward.DispatchShipmentDetails is the qname of service DispatchShipmentDetails
.
In Oracle Enterprise Service Bus 10g, there was no support for asynchronous routing services. Instead, when Oracle Enterprise Service Bus called an Oracle BPEL Process Manager asynchronous process, then a OneWay service was created.
If you created a project that uses such a OneWay service, then after you open and upgrade the application in Oracle JDeveloper 11g, you can remove the old routing service and recreate the routing service to use an Oracle Mediator 11g asynchronous routing instead of the OneWay invocation.
Oracle Enterprise Service Bus 10g supports filtering or setting message headers for standard and custom header properties for adapters, such as SOAP, JCA, JMS, and AQ adapters. Filtering in Oracle Enterprise Service Bus is done as part of the <filterExpression>
tag of the routing rule.
When you open your Oracle Enterprise Service Bus projects in Oracle JDeveloper 11g, each routing rule is upgraded into case, and the filter expression is converted to condition. These changes can be found in the mplan file of the Routing Service.
For example, the following code snippet shows the filter expression in an Oracle Enterprise Service Bus 10g routing rule:
<filterExpression>{ehdr:getRequestHeader ('/fhdr:InboundFileHeaderType/fhdr:fileName') = 'Mobile.xml'};{ namespace fhdr=http://xmlns.oracle.com/pcbpel/adapter/file/ namespace ehdr=http://www.oracle.com/XSL/Transform/java /oracle.tip.esb.server.headers.ESBHeaderFunctions } </filterExpression>
During upgrade, this example is converted to the equivalent condition of the case in the mplan file:
<condition language="xpath" xmlns:ehdr="http://www.oracle.com/XSL /Transform/java/oracle.tip.esb.server.headers.ESBHeaderFunctions" xmlns:fhdr="http://xmlns.oracle.com/pcbpel/adapter/file/"> <expression>$in.property.jca.file.FileName ='Mobile.xml'</expression> </condition>
Setting message headers is accomplished as part of the transformation files and these are upgraded to assign statements.
The following code snippet shows an example of setting message headers in Oracle Enterprise Service Bus 10g:
<xsl:variable name="inputCountry" select="/imp1:CustomerData/Country"/> <select="ehdr:setOutboundHeader ('/jhdr:JMSOutboundHeadersAndProperties /jhdr:JMSOutboundProperties/jhdr:Property[position()=1]/@value',$inputCountry, 'jhdr=http://xmlns.oracle.com/pcbpel/adapter/jms/;')"/>
During upgrade, this example is converted to the following equivalent assign element t in 11g:
<assign> <copy expression="$in.CustomerData/CustomerData/Country" target="$out.CustomerData/jhdr:JMSOutboundHeadersAndProperties /jhdr:JMSOutboundProperties/jhdr:Property[position()=1]/@value"/> </assign>
Most of the standard header properties are upgraded to their equivalent 11g headers. Customized headers are upgraded using a best effort approach, but it is not possible to upgrade all the variations of customized headers.
As a result, you must manually upgrade any customized headers the equivalent condition or assign element and equivalent mplan artifacts.
For more information, see "Getting Started with Oracle Mediator" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
The following sections describe upgrade tasks you might need to perform when upgrading Technology Adapters to Oracle Fusion Middleware 11g:
Verifying Adapters with the Oracle JDeveloper 11g Adapter Configuration Wizard
Upgrading Non-Managed Connection Information in the Adapter JCA File
After upgrading your Oracle SOA Suite 10g projects to Oracle SOA Suite 11g, Oracle recommends that you use the adapter configuration wizard to verify the upgrade of your technology adapters. This will ensure that all required fields in your 11g are populated and that the adapter connections to your new Oracle Fusion Middleware 11g environment are valid.
For more information, see the information the specific adapters you are using in the Oracle Fusion Middleware User's Guide for Technology Adapters.
After you upgrade an application that uses adapter headers, you will likely receive an error after you open the application in Oracle JDeveloper 11g. The error will indicate that a variable or parameter was not recognized while it was parsing a header function.
This is caused by a change in the way adapter header variables are defined in Oracle Fusion Middleware 11g.
In Oracle Application Server 10g Release 3 (10.1.3), you create adapter header variables in a wsdl
file that has a name such as the following, or a similar name for the direction and adapter type you are using:
fileAdapterOutboundHeader.wsdl
In Oracle Fusion Middleware 11g, adapter header variables are now properties that you set on the Properties tab of the Invoke dialog box in Oracle JDeveloper.
For example, the properties you can set for the JCA Adapter for Files/FTP are described in the section, "Inbound Headers" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
After you open your project in Oracle JDeveloper 11g, the wsdl header files you created for Oracle Application Server 10g will no longer be attached to the project. You must define each of the variables in the wsdl files as properties for each adapter type that uses header variables.
For more information, refer to the appropriate chapter for each adapter type in the Oracle Fusion Middleware User's Guide for Technology Adapters.
In Oracle Application Server 10g, you can use non-managed connections in the JCA file to point to your development resources. For example, data source definitions can be specified using the non-managed-connection
element in the JCA file.
In Oracle Application Server 10g, using non-managed connections was reserved for development only. In Oracle Fusion Middleware 11g, non-managed connections are not supported.
Ideally, before upgrading your Oracle Application Server 10g projects to Oracle Fusion Middleware 11g, you should already be using JCA files that include only JNDI references to connections that are defined properly in the datasources.xml or oc4j-ra.xml files.
If you attempt to upgrade applications that use non-managed connections for adapter connections, you must modify the projects after upgrade to use proper connections defined by using supported administration tools, such as the Oracle WebLogic Server Administration Console.
If you created an 10g Release 3 (10.1.3) technology adapter using the Adapter Configuration Wizard, and you entered a description for the adapter in the Description field of the wizard, the description will be lost when you open and migrate the project in Oracle JDeveloper 11g.
This is because the documentation
element in removed from the WSDL file during the upgrade.
If the adapter is important, you can use the Oracle JDeveloper 11g Adapter Configuration Wizard to add the description after you have upgraded the project.
In Oracle SOA Suite 10g, if you used the MQSeries Adapter inbound synchronous request-reply use case, you will notice that there is only one message type, which is REQUEST.
In Oracle SOA Suite 11g, the MQAdapter supports two message types: REQUEST and NORMAL. The REQEUST MQ message type always has replyToQueue
set on its header so there is no need for FallbackQueueName
and FallbackQueueManagerName
. On the other hand, a NORMAL Message may or may not have FallbackQueueName
and FallbackQueueManagerName
.
So, when a 10g inbound synchronous request-reply scenario is upgraded to 11g, then the Message Type remains as REQUEST type. Therefore, at runtime, there is no need for FallbackQueueName
and FallbackQueueManagerName
, even though these properties would resides in the .jca
file. If you want to use these properties, you must set the message type to NORMAL.
For more information about the inbound synchronous request-reply use case, see "Oracle MQ Series Adapter Use Cases" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
If you used the MQSeries Adapter outbound dequeue use case, which was a documented use case scenario in 10g Release 3 (10.1.3), then note that these types of projects cannot be upgraded by Oracle JDeveloper 11g.
Instead, you must recreate these types of projects after the upgrade to Oracle JDeveloper 11g. While recreating the project you must ensure that you set the value for UITransmissionPrimitive
to SynchronousDequeue
.
For more information, see "Outbound Dequeue Scenario" in the Oracle Fusion Middleware User's Guide for Technology Adapters.
If you are upgrading an application that uses the Oracle Application Server Adapter for Advanced Queuing (AQ adapter), then note that the AQ Adapter header is accessed differently in Oracle Fusion Middleware 11g.
Specifically, you must perform the following post-upgrade steps for AQ adapter headers after you upgrade to Oracle SOA Suite 11g. This procedure is required for both Oracle BPEL Process Manager and for Oracle Enterprise Service Bus projects that are upgraded to Oracle Mediator.
After upgrading to Oracle Mediator, assign the "jca.aq.HeaderDocument" value from inbound to outbound in the .mplan
file of the Oracle Mediator file.
After upgrading to Oracle BPEL Process Manager 11g:
Define a new variable 'vInboundHeaders' of type string.
For example:
<variable name="vInboundHeaders" type="xsd:string"/>
In the receive activity, make sure that the jca.aq.HeaderDocument
property gets written to the above variable.
For example:
<bpelx:property name="jca.aq.HeaderDocument" variable="vInboundHeaders"/>
At the time of invocation, make sure that the "vInboundHeaders" value is copied back to the jca.aq.HeaderDocument
property:
<invoke name="Invoke_1" inputVariable="Invoke_1_Enqueue_InputVariable" partnerLink="EnqueueClobPayload" portType="ns2:Enqueue_ptt" operation="Enqueue"> <bpelx:inputProperty name="jca.aq.HeaderDocument" variable="vInboundHeaders"/> </invoke>
In Oracle Fusion Middleware 11g, the procedure you use to create AQ outbound request-reply scenarios for Oracle BPEL Process Manager projects has changed.
As a result, when you upgrade an Oracle SOA Suite 10g application that uses this scenario, the WSDL file that is created during the upgrade does not contain the required binding information.
To correct this problem, do the following after you open and upgrade the application in Oracle JDeveloper 11g:
Add the JCA entry to the WSDL file created by the upgrade, as follows:
<?binding.jca CombinedRequestReply_aq.jca?> <wsdl:definitions name="CombinedRequestReply" ... > . . . </wsdl:definitions>
Add the binding entry in the composite.xml
file:
<reference ui:wsdlLocation="CombinedRequestReply.wsdl" name="CombineRequestReply"> <interface.wsdl interface="http://xmlns.oracle.com/pcbpel /adapter/aq/EnqueueRequest/#wsdl.interface(Enqueue_ptt)" callbackInterface="http://xmlns.oracle.com/pcbpel /adapter/aq/DequeueReply/#wsdl.interface(Dequeue_ptt)" xmlns:ns="http://xmlns.oracle.com/sca/1.0"/> <binding.jca config="CombinedRequestReply_aq.jca"/> </reference>
Remove any unused WSDL references from the .bpel
file.
As described in Section 9.1, "About Using the Oracle JDeveloper 11g Migration Wizard for Oracle SOA Suite Applications", Oracle recommends that you apply the latest patch sets to your Oracle SOA Suite environment and use the latest 10g Release 3 (10.1.3) Oracle JDeveloper before upgrading to 11g.
However, if you are upgrading from 10g Release 3 (10.1.3.3) or earlier, note the following if you are using a database adapter for stored procedures.
In Oracle SOA Suite 10g Release 3 (10.1.3.3) and earlier, the XSD generator of the adapter generated an XSD that contained unqualified elements. You can identify unqualified elements by viewing the InputParameters
root element in the XSD file. The unqualified element appears as follows:
<db:InputParameters ... ></db:InputParameters>
The db:
namespace is specified in the definition of the schema, which is the same as the target namespace.
In 10g Release 3 (10.1.3.4) and later, the XSD generator generates qualified elements, which appear as follows in the InputParameters
root element:
<InputParameters ..></InputParameters>
Note that the db:
namespace has been removed.
If you were using a version of Oracle JDeveloper 10g Release 3 (10.1.3) that was incompatible with the Oracle SOA Suite version, you could also encounter a scenario where the elements are removed:
<null>(some value)</null>
The solution is as follows:
First, make sure that you are using a version of Oracle JDeveloper that matches the version of your Oracle SOA Suite environment.
Second, after you upgrade to Oracle JDeveloper and Oracle SOA Suite10g Release 3 (10.1.3.4) or to Oracle SOA Suite and Oracle JDeveloper 11g, regenerate the XSD.
After you upgrade and regenerate the XSD, you must then modify any related assign activities and any xPath expressions accordingly.
The following upgrade tasks should be considered when you are upgrading Oracle SOA Suite applications that use human workflow tasks:
Upgrading Task Details for an Associated Human Workflow Task
Upgrading Multiple Projects That Share a Common Human Workflow Task
When you are upgrading Oracle SOA Suite 10g applications that include task details for a human task, note the following:
In Oracle SOA Suite 10g Release 3 (10.1.3), task details were generated inside same composite project and was deployed during composite deployment.
In Oracle SOA Suite 11g, task details are generated as a separate project that must be deployed separately.
As a result, during the upgrade of Oracle Human Workflow, Oracle JDeveloper 11g automatically creates a new project for the task details UI and upgrades the task detail pages. You must then deploy this project separately, after deploying the associated composite application.
If you are upgrading an application that contains multiple Oracle JDeveloper projects that share a common human workflow task, then be sure to review the upgraded application carefully in Oracle JDeveloper 11g.
In some cases, because the projects are moved into a common directory during the upgrade, data associated with the workflow task in one project may overwrite data from another project if the workflow task in the second project uses the same name.
When you upgrade projects that use Oracle Business Rules, refer to the following documentation resources:
While you are in the process of upgrading your Oracle SOA Suite applications to 11g, and while your Oracle SOA Suite 10g environment is still up and running, you should begin to review, upgrade, and test the client applications that depend upon your Oracle SOA Suite environment.
Use the following list to analyze your client applications for required updates that will allow them to work with your newly upgraded 11g Oracle SOA Suite environment:
Review the client applications to understand which remote Oracle SOA Suite APIs they are using.
For more information, refer to Section 9.3.1, "Understanding Oracle SOA Suite API Changes for Oracle Fusion Middleware 11g".
Search your client applications for any references to Oracle SOA Suite HTTP URLs. The syntax of the Oracle SOA Suite 11g HTTP URLs has changed from 10g.
To obtain the new URL that a client can use to access a deployed Oracle SOA Suite 11g application, use the home page of the application deployment in Oracle Enterprise Manager Fusion Middleware Control. For more information, see "Monitoring SOA Composite Applications" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.
If any of your client applications are using Web Services Addressing (WS-Addressing), then you must modify the client.
Oracle SOA Suite 11g supports WS-Addressing 1.0 for clients. As a result, you must either use a SOAP processor that understands WS-Addressing 1.0, or if you are using a SOAP processor that does not support WS-Addressing 1.0, then you must manually modify the 11g WSDL and change the client to get or set the WS-Addressing 1.0 headers.
Refer to Example 14-1 and Example 14-2 for a before and after example of how to modify a WSDL so it can be invoked by a SOAP processor that does not support WS-Addressing 1.0.
If the clients using WS-Addressing are running on a Oracle SOA Suite 10g environment that you do not plan to upgrade at the same time, then you must apply the following patch to the Oracle SOA Suite environment before the client applications running on the 10g server can invoke 11g BPEL processes.
For more information, see "Applying Patch Sets to Address Specific Upgrade Interoperability Issues" in the Oracle Fusion Middleware Upgrade Planning Guide.
Review your client applications for references to message targets, such as JMS queues and data source. Any references to these resources must be updated to point to the upgraded, Oracle SOA Suite 11g environment.
If a client application is using Oracle Service Bus (OSB) to invoke an Oracle BPEL Process Manager process with the optimized transport, you must modify the client application so it uses SOAP/HTML to invoke the Oracle BPEL Process Manager process.
For more information, see the Oracle Service Bus 10g Release 3 (10.3) documentation, which is available on the Oracle Technology Network (OTN):
http://www.oracle.com/technology/documentation/bea.html
Example 14-1 Example of WSDL Code That Can Be Used by a SOAP Processor that Supports WS-Addressing 1.0
<?xml version="1.0" encoding="UTF-8" ?> <definitions name="UnitedLoan" targetNamespace="http://services.otn.com" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:s1="http://www.autoloan.com/ns/autoloan" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://services.otn.com"> <plnk:partnerLinkType name="UnitedLoan"> <plnk:role name="UnitedLoanProvider"> <plnk:portType name="tns:UnitedLoan"/> </plnk:role> <plnk:role name="UnitedLoanRequester"> <plnk:portType name="tns:UnitedLoanCallback"/> </plnk:role> </plnk:partnerLinkType> <wsp:Policy xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="wsaddr_policy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> <wsaw:UsingAddressing xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"/> </wsp:Policy> <documentation> <abstractWSDL>http://stadg55.us.oracle.com:7001/soa-infra/services/default/ UnitedLoan!1.0/UnitedLoan.wsdl </abstractWSDL> </documentation> <types> <schema xmlns="http://www.w3.org/2001/XMLSchema"> <import namespace="http://www.autoloan.com/ns/autoloan" schemaLocation="http://stadg55.us.oracle.com:7001/soa-infra/services/ default/UnitedLoan!1.0*05ed6481-93e6-4b46-b2d7-a21fa27a36a9/ UnitedLoan_client?XSD=AutoLoanTypes.xsd"/> </schema> </types> <message name="UnitedLoanResultMessage"> <part name="payload" element="s1:loanOffer"/> </message> <message name="UnitedLoanRequestMessage"> <part name="payload" element="s1:loanApplication"/> </message> <portType name="UnitedLoanCallback"> <operation name="onResult"> <input message="tns:UnitedLoanResultMessage"/> </operation> </portType> <portType name="UnitedLoan"> <operation name="initiate"> <input message="tns:UnitedLoanRequestMessage"/> </operation> </portType> <binding name="UnitedLoanBinding" type="tns:UnitedLoan"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/> <wsp:PolicyReference xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" URI="#wsaddr_policy" wsdl:required="false"/> <operation name="initiate"> <soap:operation style="document" soapAction="initiate"/> <input> <soap:body use="literal" namespace="http://services.otn.com"/> </input> </operation> </binding> <binding name="UnitedLoanCallbackBinding" type="tns:UnitedLoanCallback"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="onResult"> <soap:operation style="document" soapAction="onResult"/> <input> <soap:body use="literal" namespace="http://services.otn.com"/> </input> </operation> </binding> <service name="UnitedLoan"> <port name="UnitedLoanPort" binding="tns:UnitedLoanBinding"> <soap:address location="http://stadg55.us.oracle.com:7001/soa-infra/services/ default/UnitedLoan!1.0*05ed6481-93e6-4b46-b2d7-a21fa27a36a9/ UnitedLoan_client"/> </port> </service> </definitions>
Example 14-2 Example of WSDL Code Modified So It Can Be Used by a SOAP Processor That Does Not Support WS-Addressing 1.0
<?xml version="1.0" encoding="UTF-8" ?> <definitions name="UnitedLoan" targetNamespace="http://services.otn.com" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s1="http://www.autoloan.com/ns/autoloan" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:tns="http://services.otn.com" > <plnk:partnerLinkType name="UnitedLoan"> <plnk:role name="UnitedLoanProvider"> <plnk:portType name="tns:UnitedLoan"/> </plnk:role> <plnk:role name="UnitedLoanRequester"> <plnk:portType name="tns:UnitedLoanCallback"/> </plnk:role> </plnk:partnerLinkType> <types> <schema xmlns="http://www.w3.org/2001/XMLSchema"> <import namespace="http://www.autoloan.com/ns/autoloan" schemaLocation="http://stadg55.us.oracle.com:7001/ soa-infra/services/default/ UnitedLoan!1.0*05ed6481-93e6-4b46-b2d7-a21fa27a36a9/ UnitedLoan_client?XSD=AutoLoanTypes.xsd"/> </schema> <schema xmlns="http://www.w3.org/2001/XMLSchema"> <import namespace="http://www.w3.org/2005/08/addressing" schemaLocation="http://www.w3.org/2006/03/ addressing/ws-addr.xsd"/> </schema> </types> <message name="UnitedLoanResultMessage"> <part name="payload" element="s1:loanOffer"/> </message> <message name="UnitedLoanRequestMessage"> <part name="payload" element="s1:loanApplication"/> </message> <message name="WSAMessageIDHeader"> <part name="MessageID" element="wsa:MessageID"/> </message> <message name="WSAReplyToHeader"> <part name="ReplyTo" element="wsa:ReplyTo"/> </message> <message name="WSARelatesToHeader"> <part name="RelatesTo" element="wsa:RelatesTo"/> </message> <portType name="UnitedLoanCallback"> <operation name="onResult"> <input message="tns:UnitedLoanResultMessage"/> </operation> </portType> <portType name="UnitedLoan"> <operation name="initiate"> <input message="tns:UnitedLoanRequestMessage"/> </operation> </portType> <binding name="UnitedLoanBinding" type="tns:UnitedLoan"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="initiate"> <soap:operation style="document" soapAction="initiate"/> <input> <soap:header message="tns:WSAReplyToHeader" part="ReplyTo" use="literal"/> <soap:header message="tns:WSAMessageIDHeader" part="MessageID" use="literal"/> <soap:body use="literal" namespace="http://services.otn.com"/> </input> </operation> </binding> <binding name="UnitedLoanCallbackBinding" type="tns:UnitedLoanCallback"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="onResult"> <soap:operation style="document" soapAction="onResult"/> <input> <soap:header message="tns:WSARelatesToHeader" part="RelatesTo" use="literal"/> <soap:body use="literal" namespace="http://services.otn.com"/> </input> </operation> </binding> <service name="UnitedLoan"> <port name="UnitedLoanPort" binding="tns:UnitedLoanBinding"> <soap:address location="http://stadg55.us.oracle.com:7001/ soa-infra/services/default/ UnitedLoan!1.0*05ed6481-93e6-4b46-b2d7-a21fa27a36a9/ UnitedLoan_client"/> </port> </service> </definitions>