Webservice Scenario in Wmb V7.0

Only available on StudyMode
  • Topic: Web service, XML, Java
  • Pages : 7 (1067 words )
  • Download(s) : 136
  • Published : April 10, 2013
Open Document
Text Preview
WebService scenario in WMB V7.0
This post elaborates a particulate scenario where Aggregation is being implemented using different web service nodes ( SOAP & HTTP Nodes)

Background :
Aggregation is the generation and fan-out of related requests that are derived from a single input message. It is also the fan-in of the corresponding replies to produce a single aggregated reply message.

Aggregation is an advanced form of message routing. With aggregation, a request message is received, and multiple new different request messages are generated. Each new message is routed to its  destination using a request-reply interaction. Aggregation Nodes:

* AggregateControl, AggregateRequest nodes (Used in Fan-Out to broadcast the request message to multiple destinations  * AggregateReply (Used in Fan-In to collect responses)
* ‘Aggregate Name’ property of AggregateControl & AggregateReply nodes should be the same. * ‘Folder Name’ property of the AggregateRequest node decide how the input will be structured  in Fan-Out flow. * The AggregateReply node creates a folder in the combined message tree below Root, called ComIbmAggregateReplyBody. Below this folder, the node creates a number of subfolders using the names that you set in the AggregateRequest nodes. These subfolders are populated with the associated reply messages.

Broker internally maintains aggregation state in following queues: * SYSTEM.BROKER.AGGR.REQUEST
* SYSTEM.BROKER.AGGR.CONTROL
* SYSTEM.BROKER.AGGR.REPLY
* SYSTEM.BROKER.AGGR.UNKNOWN
* SYSTEM.BROKER.AGGR.TIMEOUT

Core Aggregation Flows :

Fan Out Flow :

Fan In Flow :

Input :
      <myms:SaleEnvelope  xmlns:myms="http://tempuri.org/MyMS">          <myms:SaleList>
            <myms:Invoice>
               <myms:Initial>A</myms:Initial>                <myms:Balance>B</myms:Balance>                <myms:Currency>C</myms:Currency>             </myms:Invoice>

         </myms:SaleList>
       <myms:SaleList>
            <myms:Invoice>
               <myms:Initial>A1</myms:Initial>                <myms:Balance>B1</myms:Balance>                <myms:Currency>C1</myms:Currency>             </myms:Invoice>

         </myms:SaleList>
      </myms:SaleEnvelope>

Output :
<ABC>
 <AG2>
  <SaleEnvelope>
   <SaleList>
    <Invoice xmlns:NS1="http://tempuri.org/MyMS">
     <Initial>a</Initial>
     <Balance>60.16</Balance>
     <Currency>Dollar</Currency>
    </Invoice>
   </SaleList>
  </SaleEnvelope>
 </AG2>
 <AG1>
  <SaleEnvelope>
   <SaleList>
    <Invoice xmlns:NS1="http://tempuri.org/MyMS">
     <Initial>S</Initial>
     <Balance>07.55</Balance>
     <Currency>Rupees</Currency>
    </Invoice>
   </SaleList>
  </SaleEnvelope>
 </AG1>
</ABC>

Wrapper (Web Service) Flows :

The same flow can be called by HTTPInput Node or SOAPInput Node.

HTTPCaller Flow :

Input & Output for the above flow would be same as normal flow mentioned above.

Different ways of calling HTTPInput node (Web Service implemented using HTTP nodes) : * nettool (Its a tool ; Need to give the URL & input xml) * Another message flow which uses HTTPRequest node to call HTTPCaller flow. * Java : Can be called through plain Java code; following code sample is a standalone Java program to call HTTPCaller flow. Code :

import java.io.BufferedReader;
import java.io.DataOutputStream;
import java.io.FileReader;
import java.io.InputStreamReader;
import java.net.URL;
import java.net.URLConnection;

public class HTTPCaller{
public static void main(String[] args) throws Exception {
// Default port for HTTPInput node is 7080
// Path...
tracking img