WSDL(Web Services Description Language)

WSDL is an agreement between the service provider and consumer. It states how the service can be accessed and what the service offers, what are the inputs, what are the outputs, and what will be returned.To be more specific WSDL specifies the

Types:The data types used by the web service
Message: The messages used by the web service
Port-type: The operations that can be performed, and the messages that are involved
Binding: The communication protocols used by the web service
Lets see each of them in detail... starting with Types first...

 Types: The <types> element defines the data types that are used by the web service. For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.

<wsdl:types>
<xsd:schema xmlns:mrm="http://tempuri.org/ms_sOaP" targetNamespace="http://tempuri.org/ms_sOaP" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:include schemaLocation="org/tempuri/mssoap/DETAILS_HOLDER_WSDLGenWrapper.mxsd"/>
</xsd:schema>
</wsdl:types>

The hi-lighted line indicates where the message definition files are available, this message definition in turn refers to the actual message definition... lets look into the details in the next post....

Message: This can be compared to the method inputs in java, this specifies what exactly should be the input of that particular service, very similar to parameters of a java method, this also describes what is the return message structure and the fault message structure. the below is xml structure displaying the same...


  <wsdl:message name="Operation1_in">
    <wsdl:part element="tns:Request_Details" name="Request_Details"/>
  </wsdl:message>
  <wsdl:message name="Operation1_out">
    <wsdl:part element="tns:Reply" name="Reply"/>
  </wsdl:message>
  <wsdl:message name="Operation1_fault1">
    <wsdl:part element="tns:Fault" name="Fault"/>
  </wsdl:message>


Quick look at the above xml structure will acknowledge us that Request_Details is the actual  message definition we are using as input for the "Operation1" OPERATION[method], and the reply and faults are Reply,Fault respectively.

Thats 2 parts out of 4 from a wsdl lets take a look at the rest of 2 parts i.e. Port-Type & Binding...

Port type: To understand this more easily i will give you an example... consider a java class which has lot of methods and variables defined in it, now, if you want to use the java class you will most probably access it by using its name... thats the same case with Port-Type too... port type defines Operations and their inputs and outputs...
  <wsdl:portType name="ms_sOaPPortType">
    <wsdl:operation name="GetCustomerDetails">
      <wsdl:input message="tns:Operation1_in" name="Operation1_Input"/>
      <wsdl:output message="tns:Operation1_out" name="Operation1_Output"/>
      <wsdl:fault message="tns:Operation1_fault1" name="Operation1_Fault"/>
    </wsdl:operation>
  </wsdl:portType>

GetCustomerDetails is the name, which service consumer will use to get the customer details, internally it is linked to Operation1,  we previously saw  how the xsd files were linked to these operations names.Lets take a look at the remaining part...

Binding: the binding brings together all the parameters we have declared so far... the binding tag has two attributes they are [name,type] any valid string literal can be used in the name and for the type one of the previously declared port type should be used hear.The soap:binding element has two attributes - style and transport. hear we are using HTTP transport, and the binding style is document, there is another binding style which is rpc...
<wsdl:binding name="ms_sOaPSOAP_HTTP_Binding" type="tns:ms_sOaPPortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="GetCustomerDetails">
      <soap:operation soapAction=""/>
      <wsdl:input name="Operation1_Input">
        <soap:body parts="Request_Details" use="literal"/>
      </wsdl:input>
      <wsdl:output name="Operation1_Output">
        <soap:body parts="Reply" use="literal"/>
      </wsdl:output>
      <wsdl:fault name="Operation1_Fault">
        <soap:fault name="Operation1_Fault" use="literal"/>
      </wsdl:fault>
    </wsdl:operation>
  </wsdl:binding>

the rest of the wsdl:input, wsdl:output, wsdl:fault describe the specific message parts which are used by the web service as input output and fault...

And the last part

<wsdl:service name="ms_sOaPSOAP_HTTP_Service">
    <wsdl:port binding="tns:ms_sOaPSOAP_HTTP_Binding" name="SOAP_HTTP_Port">
      <soap:address location="http://localhost:7800/ms_sOaPSOAP_HTTP_Service"/>
   </wsdl:port>
</wsdl:service>

Binds our binding with an external name by which the end user accesses the service specifies where the service is actually available[Host name] and the port name...Color code is implemented to make it more clear how the elements are linked.... hope you get it.

Distribution in MQ using Commands

 Miscellaneous Functions in MB v7.0

CREATE COMPUTE MODULE miscellaneous_flow_Compute
    CREATE FUNCTION Main() RETURNS BOOLEAN
    BEGIN
    --CALL CopyMessageHeaders();
        --CALL CopyEntireMessage();
       
--------------COALESCE Function------------------
        --SET OutputRoot.XMLNSC.COALESCE = COALESCE(InputRoot.XMLNSC.input1,0);
        --SET OutputRoot.XMLNSC.COALESCE1 = COALESCE(InputRoot.XMLNSC.input12,0);
        --  <input1>12</input1>
        ----------------------------------------
        --SET OutputRoot.XMLNSC.employee.(XMLNSC.Attribute)id ='123';
    -------UUIDASCHAR,UUIDASBLOB-------------------
        --SET OutputRoot.XMLNSC.emp = UUIDASCHAR;
        --SET OutputRoot.XMLNSC.emp1 = UUIDASBLOB;
    ------------------------------------------------
    --DECLARE arg1,arg2 INTEGER;
    --SET arg1 = InputRoot.XMLNSC.args.arg1;
    --SET arg2 = InputRoot.XMLNSC.args.arg2;
--SET OutputRoot.XMLNSC.res.res1 = NULLIF(arg1,arg2);
--CASE WHEN arg1=arg2 THEN NULL ELSE arg1 END
    --<args><arg1>2</arg1><arg2>2</arg2></args>
-------------------------------------------------------


PASSTHRU 'CREATE TABLE customer (
  CustomerNumber INTEGER,
  FirstName      VARCHAR(256),
  LastName       VARCHAR(256),
  Street         VARCHAR(256),
  City           VARCHAR(256),
  Country        VARCHAR(256)
)' TO Database.sample;
--PASSTHRU 'DROP TABLE passthru' TO Database.sample;
    END;

 CREATE PROCEDURE CopyMessageHeaders() BEGIN
        DECLARE I INTEGER 1;
        DECLARE J INTEGER;
        SET J = CARDINALITY(InputRoot.*[]);
        WHILE I < J DO
            SET OutputRoot.*[I] = InputRoot.*[I];
            SET I = I + 1;
        END WHILE;
    END;

    CREATE PROCEDURE CopyEntireMessage() BEGIN
        SET OutputRoot = InputRoot;
    END;
END MODULE;

SOAP 

SOAP was originally an acronym for Simple Object Access Protocol. (Now it’s just a name.) SOAP 1.1 is the standard messaging protocol used by J2EE Web Services, and is the de facto standard for Web services in general. SOAP’s primary application is Application-to-Application (A2A) communication. Specifically, it’s used in Business-to-Business (B2B) and Enterprise Application Integration (EAI), which are two sides of the same coin: Both focus on integrating software applications and sharing data. To be truly effective in B2B and EAI, a protocol must be platform-independent,flexible, and based on standard, ubiquitous technologies. Unlike earlier B2B and EAI technologies, such as CORBA and EDI, SOAP meets these requirements, enjoys widespread use, and has been endorsed by most enterprise software vendors and major standards organizations (W3C, WS-I, OASIS, etc.).Despite all the hoopla, however, SOAP is just another XML markup language accompanied by rules that dictate its use. SOAP has a clear purpose: exchanging data over networks. Specifically, it concerns itself with encapsulating and encoding XML data and defining the rules for transmitting and receiving that data. In a nutshell, SOAP is a network application protocol.A SOAP XML document instance, which is called a SOAP message,is usually carried as the payload of some other network protocol. For example, the most common way to exchange SOAP messages is via HTTP (HyperText Transfer Protocol), used by Web browsers to access HTML Web pages. The big difference is that you don’t view SOAP messages with a browser as you do HTML. SOAP messages are exchanged between applications on a network and are not meant for human

1.The SOAP XML document is also called the SOAP envelope.30166 04 pp079-126 r2jm.ps  10/2/03  3:56 PM  Page 8182 Chapter 4 SOAP consumption. HTTP is just a convenient way of sending and receiving SOAP messages.SOAP messages can also be carried by e-mail using SMTP (Simple Mail Transfer Protocol) and by other network protocols, such as FTP (File Transfer Protocol) and raw TCP/IP (Transmission Control Protocol/Internet Protocol). At this time, however, the WS-I Basic Profile 1.0 sanctions the use of SOAP only over HTTP.

Web services can use One-Way messaging or Request/Response messaging. In the former, SOAP messages travel in only one direction, from a sender to a receiver. In the latter, a SOAP message travels from the sender to the receiver, which is expected to send a reply back to the sender. Figure 4–2 illustrates these two forms of messaging.SOAP defines how messages can be structured and processed by software in a way

that is independent of any programming language or platform, and thus facilitates interoperability between applications written in different programming languages and running on different operating systems. Of course, this is nothing new: CORBA IIOP and DCE RPC also focused on cross-platform interoperability. These legacy protocols were never embraced by the software industry as a whole, however, so they never became pervasive technologies. SOAP, on the other hand, has enjoyed