Unable to find a WSDL that has a definition for service

Issue –> While deploying a SOA project in Jdeveloper i got the below error.

Error –>

Received HTTP response from the server, response code=500
Error deploying archive sca_myTaxProcess_rev1.0.jar to partition “default” on server soa_server1 [http://localhost:8001] 
HTTP error code returned [500]
Error message from server:
There was an error deploying the composite on soa_server1: Deployment Failed: Unable to find a WSDL that has a definition for service {http://xmlns.oracle.com/soa/soaTaxProcess/TaxRateProcess}TaxRateProcess.service and port TaxProcessPort.  Please make sure that the port attribute for the binding defined in the composite file is correct by checking the namespace, service name, and port name.  In addition, check that the WSDL associated with the binding namespace is imported and currently reachable (check the import nodes at the top of the composite file). Finally, validate the HTTP proxy settings for the server..

Solution –> 

Actually the referenced webservice’s hostname mapping was missing in my “new” environment because of which the SOA composite was unable to find the WSDL during deployment.

oracle.webservices Authentication

HTTP basic authentication can have two types of authentication handshake methods, one is Reactive another one is Preemptive,

Reactive:

• The client makes a request for a resource which needs authentication;
• The server returns an HTTP 401 Authorization required response (indicating the authentication scheme and realm) with WWW-Authenticate header.
• The client re-submits the request with an Authentication header;
• The server verifies client credentials and returns the resource if authenticated successfully..

Preemptive:

The client can preemptively pass the credentials on the first request. The server returns immediately the resource if authenticated successfully.

Not all the authentication server accepts the Preemptive authentication mode, The NTLM authentication will not support the Preemptive handshake method it should be Reactive.

In Oracle SOA 11g the parnerlink binding property oracle.webservices.preemptiveBasicAuth will help us to set the handshake method accordingly.

• oracle.webservices.preemptiveBasicAuth=false - Reactive mode
• oracle.webservices.preemptiveBasicAuth=true - Preemptive mode

oracle.fabric.common.FabricInvocationException: Unable to find the WSDL service defined for service name

I was working on an integration with siebel system .When I am trying to invoke their service,

it used throw the below mentioned error :

 <fault>
  <bpelFault>
    <faultType>0</faultType>
    <remoteFault>
      <part name="summary">
        <summary>oracle.fabric.common.FabricInvocationException: Unable to find
                 the WSDL service defined for service name
                 {http://abcd.com/}CC_spcDC_spcNotifications. Please make sure
                 that the port attribute for the binding defined in the
                 composite file is correct by checking the namespace and service
                 name in the #wsdl.endpoint element. In addition, check that the
                 WSDL associated with the binding namespace is imported and
                 currently reachable (check the import nodes at the top of the
                 composite file). Finally, validate any HTTP proxy settings for
                 the server.</summary>
      </part>
      <part name="detail">
        <detail>Unable to find the WSDL service defined for service name
                {http://abcd.com}CC_spcDC_spcNotifications. Please make sure
                that the port attribute for the binding defined in the composite
                file is correct by checking the namespace and service name in
                the #wsdl.endpoint element. In addition, check that the WSDL
                associated with the binding namespace is imported and currently
                reachable (check the import nodes at the top of the composite
                file). Finally, validate any HTTP proxy settings for the server.</detail>
      </part>
      <part name="code">
        <code>null</code>
      </part>
    </remoteFault>
  </bpelFault>
</fault>

How To Tackle This Problem :

1) First take out the wsdl file and put in xml spy  or any online validator to check whether structure is of correct format.

2) The wsdl file should have a structure called "service" at bottom like mentioned below.If its missing it throws out  mentioned error intermittently(ideally it should not) :

<service name="Notifications">

      <port binding="tns:spcNotifications" name="C_spcNotifications">

         <soap:address location="http://abcd.com"/>

      </port>

   </service

3) Check with target partner system whether their service is up or running.


4) Most Imp:


This  can be resolved temporarily by bouncing the SOA Server.Issue might come up again if same wsdl is uploaded again.

I have spent nights in resolving this issue....happy programming!! :) 

XML Standards for XML-Message based integrations (Oracle SOA).

XML Standards for XML-Message based integrations (Oracle SOA).

Background:

• Now a days, majority of the enterprise integration solutions (especially that are using SOA design patterns) and packaged ESB applications such as Oracle's SOA/OSB/BPM, SoftwareAG's Webmethod, TIbco's ActiveMetrix, IBM's Websphere, Mule's MuleESB and many more are are extensively using XML based configurations and messages to integrate different kinds of heterogeneous applications.

• So, standardizing the XML-Model is one of the key-success criteria in designing the SOA based integration solutions.

XML Message/Schema Standards

• Always define the definition of an xml message in hierarchical pattern.  example: xml structure for an employee in finance department should follow : <department><finance><employee>xxxx</employee></finance></department>, instead <dep_fin_emp>xxx</dep_fin_emp>. 

• Where ever possible, use elements rather attributes.  There is always a debate whether to use attributes or elements to represent the properties of an object. Using elements (instead attributes) provides more flexibility to extend the properties of that object/element. Here the main point is - element can easily extendable, where as attribute is not. Example: extending <department><name>xx</name><rev>xx</rev><exp>xx</exp></department> causes lesser cost than changing <department name="XX" rev="xxx" exp="XXX"/>.  Reason: Elements are more flexible than attributes, particularly when it comes to writing extensible schemas, as you can always add additional elements to an element. However, once an attribute has defined, it cannot be extended any further.

• Always follow a specific pattern to name the xml elements and attributes. Meaning, either follow the camelcase or simplecase but not both. Example: use either xxxXXX or xxx_XXX but not both patterns (there is nothing harm in using both, but it looks ugly especially when you expose your service to external world).

• If you are defining types (complex or simple types) then always post-fix name with "type" for better readability . Example <complexType name="employeeType"> .. </complexType>

• Always keep Elements and attributes name between 12 char to 15 char length. 

• Always tend to use real-life objects for Element names.  Example: use employee, party, partner, address, user, status etc for element names., instead prefix with company or product names. example : use <item><type>engineering</type> .. </item> instead <enggItem> .. </enggItem>

• Always define schema with a target namespace. Namespace is equivalent to a package name in plsql and java programming languages.  This approach provides better readability and clarity on the elements that are using in the messages.

• Where ever possible, use Qualified element and attribute names in the XML messages.  This approach provides clarity on what namespace an element belongs to, and removes the confusion or ambiguity and provides the context in which an element is defined.

• Namespace should follow http://org.<<your company name>>.com/<<domainname>>/<<xsd or wsdl>>/<<functional area>>  example: http://org.ppk.com/purchasing/xsd/order

• Preferably,  try to define element types (complex or simple types) and use it while defining the elements (messages) instead creating the local elements.  Example: use <xsd:schema ...> <complexType name="employeeType"><sequence><firstname type="xxx"/><lastname type="xxx"/></sequence></complexType>  and refer this type in the element <department><employee type="employeeType"/></department>  instead <department><firstname type="xxx"/><lastname type="xxx"/></department>.  This approach provides modularity and reusability in defining the XML Elements and messages.

• Preferably, try to construct a canonical model based on multiple, reusable and logical schema models.  Example: avoid creating a single schema definition abc.xsd  by "including" sales.xsd, employee.xsd, order.xsd, finance.xsd, though it provides single namespace and easy development. Instead "import" required schemas to create a name space for your particular domain/project (just like importing required packages in a java classes).

• For Oracle SOA (SOAP) based message integrations, due to the limitations defined by WS-I  , preferably choose document style binding with the combination of Document Wrapped style (with this approach, the request and response parameters for an operation are wrapped within a single request and response element).  This ensures that the SOAP body only contains a single nested element who name matches that of the operation. 

• Make sure that, all the canonical schemas and common xml types stored/procured in a common repository from where all the SOA projects (Oracle SOA Projects) shares/references these schemas and types appropriately.   In my next blog, I will provide more details on common-repository (MDS) setup and usage.

Creating a WSDL File From XSD File

In this post, lets learn how we can create services interface - WSDL from schema file using Oracle JDeveloper 11g. Here, we attempt to create a service which when provided with an Employee Id returns the Employee Name. Incase no matching records are found for an Id, it simply returns the string value - "Unknown".


# We start with opening the JDeveloper 11g


# Create an application - "MyWSDLApplication" using the Generic Application template.


# Name the project as "MyWSDLProject" and select "Web Services" as the project technologies.


# The Application Navigator view should look like this


# Lets create the schema file first. For this, right click on the project and from the context menu, select New. In the Gallery that opens, select General -> XML -> XML Schema

# Name the schema as Employee.xsd

# The schema editor window opens as shown in the figure below.

# We will be adding two elements - EmpId and EmpName here. Right click on the root schema element and from the context menu, select Insert inside schema -> element 

# Once the two elements are specified, we provide them types by right click on the element and from context menu - select Set Type as shown below

# As depicted in the figure below, EmpId type is taken as long while EmpName type is string.

# With the schema defined, we move onto creating the WSDL document. Right click on the project and from context Menu, select New. In the gallery, choose Business Tier -> Web Services -> WSDL Document. Press OK button.

# Name WSDL document as EmployeeWSDL

# Once OK button is presses, the JDeveloper editor view would look like this

# Arrange the schema and WSDL editor windows in a vertical split arrangement like as shown below. This can be achieved by dragging the Employee.xsd tab below.

# Now, we begin creating the WSDL document. Drag and Drop the EmpId element (input for our case) onto the Port Type window. This opens the 'Create Port Type' window. Lets name it as EmployeeDetail.

# After our previous action, the WSDL editor should look like this

# We have a problem here as can be seen from the image. The output is shown as EmpId while we expect it to be EmpName.

# To correct this, we select the output node in the Port Types window. Drag and Drop EmpName element from the schema onto this node. With this, the WSDL document appears like 

# Next we change the name of the messages to EmployeeRequestMessage and EmployeeResponseMessage using the property inspector window.

# With the changes in message name, we need to remap these to the operation messages as else these appear with errorneous icon like we have output icon below. To correct this, drag and drop the relevant messages onto the correct nodes. Example : EmployeeRequestMessage is dropped onto the input node of EmpIdOperation and EmployeeResponseMessage is dropped onto the output of EmpIdOperation

# Here, we make the operation name more meaningful using property Inspector - getEmployeeNameOperation.

# The complete WSDL view should appear like this

# Now, we drag and drop the EmployeeDetail node onto the Bindings/Partner Link Types window. In the Create Binding window, we check the SOAP12.

# This should result in the view as shown below :

# Next, drag and drop the root node from the Bindings window onto the Services window. This results in the view as shown below

# At this point, the structure window should look like this. This completes our WSDL document creation process.

# We can validate our WSDL document by doing right click on the EmployeeWSDL (in the Applications Navigator Window) and from context menu, choose Validate WSDL. Confirm the message in the Messages- Log window.

This completes our exercise to create WSDL document using the schema file. Next, we will create Web Service using this WSDL document.

Securing SOA Composites/Services With OWSM Policies

Oracle Web Services Manages (OWSM) is an integral component of the SOA Infrastructure in SOA Suite 11g. It provides a policy-based, completely declarative way of implementing secure SOA applications. OWSM supports centrally managed generalized, standards-based policy management, attachment policies by providing policy management functions that are available through the Oracle Enterprise Manager (EM). 

For the SERVICE that needs to be secured:

1. Right click on the composite client, and  choose select the option Configure WS Policies.
2. Click the + sign on the security tab and select security policy "wss_username_token_service_policy"

 

3. Press OK and deploy the service. Alternatively, the service can also be secured from EM


 For the CLIENT that needs access the secured service:

The client side policies have to be attached to the client that needs to access the service 

1. Right click the  secured web. service component in the composite and choose the option to Configure WS Policies.
2. Click the + sign on the security tab and select security policy "wss_username_token_client_policy".
3. Create the binding properties  oracle.webservices.auth.username and oracle.webservices.auth.password for the user and password respectively
4. The source code for the composite after the policy has been added will look like

<wsp:PolicyReference URI="oracle/wss_username_token_client_policy"
                           orawsp:category="security" orawsp:status="enabled"/>
      <property name="weblogic.wsee.wsat.transaction.flowOption"
                type="xs:string" many="false">WSDLDriven</property>
      <property name="oracle.webservices.auth.username" type="xs:string"
                many="false" override="may">username</property>
      <property name="oracle.webservices.auth.password" type="xs:string"
                many="false" override="may">passwd</property>


  5. Deploy the composites to test the services

WSDL

·         WSDL stands for Web Services Description Language

·         WSDL is an XML based protocol for information exchange in decentralized and distributed environments.

·         WSDL is the standard format for describing a web service.

·         WSDL definition describes how to access a web service and what operations it will perform.

·         WSDL is a language for describing how to interface with XML-based services.

·         WSDL is a language for describing how to interface with XML-based services.

Sample WSDL:

<?xml version="1.0" encoding="UTF-8"?>

<description xmlns="http://www.w3.org/ns/wsdl"

             xmlns:tns="http://www.tmsws.com/wsdl20sample"

             xmlns:whttp="http://schemas.xmlsoap.org/wsdl/http/"

             xmlns:wsoap="http://schemas.xmlsoap.org/wsdl/soap/"

             targetNamespace="http://www.tmsws.com/wsdl20sample">

<!-- Abstract type -->

   <types>

      <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

                xmlns="http://www.tmsws.com/wsdl20sample"

                targetNamespace="http://www.example.com/wsdl20sample">

         <xs:import namespace=http://www.example.org schemaLocation=”abc.xsd”/>

      </xs:schema>

   </types>

<!-- Abstract interfaces -->

   <interface name="Interface1">

      <fault name="Error1" element="tns:response"/>

      <operation name="Opp1" pattern="http://www.w3.org/ns/wsdl/in-out">

         <input messageLabel="In" element="tns:request"/>

         <output messageLabel="Out" element="tns:response"/>

      </operation>

   </interface>

<!-- Concrete Binding Over HTTP -->

   <binding name="HttpBinding" interface="tns:Interface1"

            type="http://www.w3.org/ns/wsdl/http">

      <operation ref="tns:Get" whttp:method="GET"/>

   </binding>

<!-- Concrete Binding with SOAP-->

   <binding name="SoapBinding" interface="tns:Interface1"

           type="http://www.w3.org/ns/wsdl/soap"

           wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"

           wsoap:mepDefault="http://www.w3.org/2003/05/soap/mep/request-    response">

      <operation ref="tns:Ge99t" />

   </binding>

<!-- Web Service offering endpoints for both bindings-->

   <service name="Service1" interface="tns:Interface1">

      <endpoint name="HttpEndpoint"

                binding="tns:HttpBinding"

                address="http://www.example.com/rest/"/>

      <endpoint name="SoapEndpoint"

                binding="tns:SoapBinding"

                address="http://www.example.com/soap/"/>

   </service>

</description>

WSDL Types Element

A Web service needs to define its inputs and outputs and how they are mapped into and out of services. WSDL <types> elements take care of defining the data types that are used by the web service. Types are XML documents, or document parts.

  <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>

WSDL Message Element

·         The <message> element describes the data being exchanged between the Web service providers and consumers.

·         Each Web Service has two messages: input and output.

·         The input describes the parameters for the Web Service and the output describes the return data from the Web Service.

·         Each message contains zero or more <part> parameters, one for each parameter of the Web Service's function.

·         Each <part> parameter associates with a concrete type defined in the <types>container element.

   <message name="SayHelloRequest">

      <part name="firstName" type="xsd:string"/>

   </message>

   <message name="SayHelloResponse">

      <part name="greeting" type="xsd:string"/>

   </message>

WSDL portType Element

The <portType> element combines multiple message elements to form a complete oneway or round-trip operation.

For example, a <portType> can combine one request and one response message into a single request/response operation. This is most commonly used in SOAP services. A portType can define multiple operations.

Sync WSDL

<portType name="Hello_PortType">

      <operation name="sayHello">

         <input message="tns:SayHelloRequest"/>

         <output message="tns:SayHelloResponse"/>

      </operation>

   </portType>

Async WSDL

<portType name="Hello_PortType">

      <operation name="sayHello">

         <input message="tns:SayHelloRequest"/>

      </operation>

</portType>

<portType name="Hello_PortType">

      <operation name="sayHello">

         <input message="tns:SayHelloRequest"/>

      </operation>

   </portType>

WSDL Binding Element

·         The <binding> element provides specific details on how a portType operation will actually be transmitted over the wire.

·         The bindings can be made available via multiple transports, including HTTP GET, HTTP POST, or SOAP.

·         The bindings provide concrete information on what protocol is being used to transferportType operations.

·         The bindings provide information where the service is located.

·         For SOAP protocol, the binding is <soap:binding>, and the transport is SOAP messages on top of HTTP protocol.

·         You can specify multiple bindings for a single portType.

·         The binding element has two attributes - the name attribute and the type attribute.

  <wsdl:binding name="PrepaidAccountSOAP" type="tns:PrepaidAccount">

    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>  

 <wsdl:operation name="viewRechBarInfo">

      <soap:operation soapAction="http://www.telenor.mm/PrepaidAccount/viewRechBarInfo"/>

      <wsdl:input>

        <soap:body use="literal"/>

      </wsdl:input>

      <wsdl:output>

        <soap:body use="literal"/>

      </wsdl:output>

    </wsdl:operation>

    <wsdl:operation name="QueryAvailableOffers">

      <soap:operation soapAction="http://www.telenor.mm/PrepaidAccount/QueryAvailableOffers"/>

      <wsdl:input>

        <soap:body use="literal"/>

      </wsdl:input>

      <wsdl:output>

        <soap:body use="literal"/>

      </wsdl:output>

    </wsdl:operation>

  </wsdl:binding>

WSDL Ports Element

A <port> element defines an individual endpoint by specifying a single address for a binding.

·         The port element has two attributes - the name attribute and the binding attribute.

·         The name attribute provides a unique name among all ports defined within in the enclosing WSDL document.

·         The binding attribute refers to the binding using the linking rules defined by WSDL.

·         Binding extensibility elements (1) are used to specify the address information for the port.

·         A port MUST NOT specify more than one address.

·         A port MUST NOT specify any binding information other than address information.

<service name="Hello_Service">

      <documentation>WSDL File for HelloService</documentation>

      <port binding="tns:Hello_Binding" name="Hello_Port">

         <soap:address

            location="http://www.examples.com/SayHello/">

      </port>

   </service>

WSDL Service Element

·         The <service> element defines the ports supported by the Web service. For each of the supported protocols, there is one port element. The service element is a collection of ports.

·         Web service clients can learn from the service element where to access the service, through which port to access the Web service, and how the communication messages are defined.

·         The service element includes a documentation element to provide human-readable documentation.

Different Types of WSDL

1.       Abstract WSDL : Contain Types, Messages, PortTypes

2.       Concrete WSDL: Contain Types, Messages, PortTypes and Bindings, Services

Different Styles of WSDL

1.       Document

2.       RPC

Document vs RPC

1.       In document style, the SOAP (Simple Object Access Protocol) message is sent as a Single Document whereas in the RPC Style, the SOAP body may contain several elements.

2.       The document style is loosely coupled whereas the RPC is tightly coupled.

3.       In the document style, the client sends the service parameters in simple XML format, whereas in the RPC style, the parameters are sent as discrete of values.

4.       The document style losses the operation name in the SOAP message whereas the RPC style keeps the operation name in the SOAP message.

5.       In the document style, messages can always be validated using any XML validator, whereas in the RPC style, the transformed data is difficult to validate by the SOAP message.