• SOAP/JMS
• SOAP/HTTP
• RMO/IIOP su un EJB

• Il messaggio SOAP viene indirizzato alla Service Destination
• la service Destination ruota il messaggio verso la porta
• la porta consegna il messaggio SOAP al 'bus invoker'
• l' invoker della porta trasmette il messaggio SOAP verso il web service endpoint specificato all'interno del WSDL

• Il client invia un messaggio SOAP nell' endpoint listener
• il listener utilizza le informazioni all'interno dell' InboundPort e dell' InboundService per recuperare la ServiceDestination alla quale inviare il messaggio
• se il WSDL definisce un messaggio a 2 vie (anche ritorno)  in questo caso viene creata una  coda di risposta alla quale l'endpoint listener si mette in   ascolto
• l'endpoint listener attende il messaggio di ritorno e lo inoltra al client

Per brevità non sono riportati tutti i passi da seguire  ma solamente quelli ritenuti più significativi.

Per ogni componente che di seguito creeremo dovremmo proseguire fino a che non apparirà nella finestra di lavoro con l'indicazione che ci avverte che è necessario salvare il lavoro eseguito fino a quel punto.

La console di gestione dell’ Application Server è raggiungibile mediante un URL del tipo:

                http:://host:porta/admin     (generalmente porta=9060)

Iniziamo con la creazione di una nuova istanza del bus di integrazione.

Service Integrations  > Buses > New
(1)


 
Una volta creato il bus dobbiamo associargli il message engine:

Service Integrations  > Buses > WasBus > Bus Members > Add
(2)



Ora ci apprestiamo a creare e configurare l'applicazione di sistema che ci fornirà l'endpoint listener associato al nostro bus di integrazione.
   
Application Servers > server1 > Endpoint Listeners  > New

(3)


 

(4)


 

Nota: durante la creazione dell’ endpoint listener dobbiamo esclusivamente utilizzare:
SOAPHTTPChannel1 e wsgwsoaphttp1.

Creiamo all'interno del bus la destinazione alla quale arriveranno le richieste SOAP provenienti dal web service.

Service Integrations  > Buses > WasBus > Destinations > New

(5)


 
Inseriamo il nome della destinazione.

(6)


 

Prima di procedere con la definizione dei servizi Inbound e Outbound è necessario eseguire il download e il deploy del servizio web (ReverseStringEAR.ear) che utilizzeremo come test e del client per la sua verifica (ReverseStringClientEAR.ear).
Ricordiamoci, dopo aver eseguito la pubblicazione di attivare da console le applicazioni. Se tutto è andato correttamente, invocando:

http://localhost:9085/ReverseString/services/ReverseString/wsdl/ReverseString.wsdl

dovremo vedere come risposta il codice WSDL che definisce il servizio web.
   
(Nota: la porta potrebbe cambiare a seconda della configurazione del server)

Se da console visualizziamo le applicazioni presenti avremo una situazione analoga alla seguente:

(7)



Il prossimo passo consiste nella creazione del servizio di Outbound.

Service Integrations > Buses > Outbound Services > New

(Nota: come location del WSDL inseriamo la URL  indicata sopra)

(8)
 


Ridenominiamo Outbound service name , Service destination name e Port destination name con i seguenti valori:

• ReverseStringOutboundService
• ReverseStringOutboundDestination
• ReverseStringOutboundPort

(9)

Ecco il risultato, dopo aver salvato il servizio creato.

(10)


 
   
Adesso occupiamoci all'aspetto dell' ascolto, ovvero il servizio di Inbound.
   
Service Integrations  > Buses > Inbound Services > New

(11)


 

Specifichiamo il nome del servizio.

(12)


 

Al termine del wizard vedremo il servizio Inbound creato.

(13)

 

Per la definizione del servizio Inbound abbiamo specificato il nome della destinazione: ReverseStringDestination  alla quale arriverà il messaggio SOAP relativo alla richiesta del client, e come si vede dalla figura 3,  mediante un routing statico la destinazione viene rediretta (senza effettuare nessuna mediazione) verso la  ReverseStringOutboundDestination che invocherà automaticamente l'endpoint del servizio web.

 


Figura 3 : Diagramma semplificato nel caso di destinazione intermedia.

Avremmo potuto optare anche per un' altra soluzione, ovvero utilizzare, direttamente per l' Inbound la destinazione ReverseStringOutboundDestination (la destinazione definita per l’Outbound) come si vede nella figura 4. Anche se la seconda     soluzione risulta più intuitiva è consigliabile utilizzare una destinazione 'intermedia', come nel primo caso, poichè questo approccio permette di avere un maggior livello di     separazione dei compiti.

 
 
Figura  4 :   Diagramma semplificato nel caso di singola destinazione.

   

Eseguiamo il routing descritto precedentemente.

Service Integrations  > Buses > Destinations > StringReverseDestination

inseriamo : WasBus:ReverseStringOutboundDestination ,ovvero ridirigi l’input , in questo caso il messaggio SOAP proveniente dal client,  verso la destinazione ReverseStringOutboundDestination all’interno del bus WasBus.

(14)


 

Dopo aver eseguito tutti i passi sopra riportati andiamo a controllare tutte le destinazioni presenti nel bus:

Service Integrations  > Buses > Destinations

(15)

Prepariamoci ora a generare, mediante il wizard, il codice WSDL riferito all’ InboundService precedentemente creato.

Service Integrations  > Buses > Inbound Services > ReverseStringInboundService

(16)


 
Salviamo il contenuto del file ZIP.

(17)


 

All’interno del file ZIP sono presenti I seguenti files:

• WasBusReverseStringInboundServiceBindings.wsdl
• WasBusReverseStringInboundServiceNonBound.wsdl
• WasBusReverseStringInboundServiceBindings.wsdl
• WasBusReverseStringInboundService.wsdl

Apriamo il WasBusReverseStringInboundService.wsdl :

(18)

Selezioniamo e copiamo la URL dell’endpoint (definita nel tag <soap:address> ) ovvero:

http://localhost:9085/wsgwsoaphttp1/soaphttpengine/WasBus/ReverseStringInboundService/localhostNode05_server1_SOAPHTTPChannel1_InboundPort  (**)

   
Nota: Sostituiamo %2F con /

Eseguiamo il test utilizzando l’applicazione client, invocandola tramite la seguente URL:

            http://localhost:9085/ReverseStringClient/sampleReverseStringProxy/TestClient.jsp

Impostiamo l’endpoint del servizio andando sul link: setEndpoint(java.Lang.String)  e copiamo la URL (**) infine rendiamo tutto effettivo premendo il bottone ‘invoke’.

A questo punto non ci resta altro che invocare il servizio web vero e proprio mediante il link: reverse(java.Lang.String) ed ecco il risultato:

(19)



Come controprova  togliamo dalla destinazione ReverseStringDestination la riga WasBus:ReverseStringOutboundDestination e invochiamo nuovamente il client, in questo caso non vedremo nessun risultato in quanto il messaggio SOAP del client  rimane appeso alla destinazione associata al servizio in ingresso.