sviluppatori@openspcoop.org
<prev [Datenext>
<prev [Threadnext>

Re: [OpenSPCoop-Dev] Re: Modalità d'inte

To: sviluppatori@openspcoop.org
Subject: Re: [OpenSPCoop-Dev] Re: Modalità d'integrazione dei servizi applicativi
From: Andrea Poli <apoli@link.it>
Date: Tue, 17 Apr 2007 15:24:17 +0200
In-reply-to: <290222dd0703261023w3c9ed147v70d7a68954bbe6dc@mail.gmail.com>
List-archive: </pipermail/sviluppatori>
List-help: <mailto:sviluppatori-request@openspcoop.org?subject=help>
List-id: sviluppatori.openspcoop.org
List-post: <mailto:sviluppatori@openspcoop.org>
List-subscribe: <http://www.openspcoop.org/mailman/listinfo/sviluppatori>,<mailto:sviluppatori-request@openspcoop.org?subject=subscribe>
List-unsubscribe: <http://www.openspcoop.org/mailman/listinfo/sviluppatori>,<mailto:sviluppatori-request@openspcoop.org?subject=unsubscribe>
References: <4602BD1F.4080005@link.it><290222dd0703261023w3c9ed147v70d7a68954bbe6dc@mail.gmail.com>
Reply-to: sviluppatori@openspcoop.org
User-agent: Thunderbird 1.5.0.10 (X11/20070221)
Poli Andrea wrote:
> Il problema e' dovuto al fatto che il client sta usando mustUnderstand=1
> e Actor non specificato. Questo puo' andar bene in un'interazione SOAP
> peer to peer, ma non va bene se ci sono dei nodi intermediari che non
> devono interpretare l'header, come avviene in questo caso per le Porte
> di Dominio.
In alternativa, se non puoi intervenire sugli applicativi, puoi fare in
> modo che la PdD ignori comunque l'header, aggiungendo un handler che
> marchi l'header WSS come gestito.
Domenico Loiacono wrote:
Questa seconda alternativa, già utilizzata nel post http://www.openspcoop.org/pipermail/sviluppatori/msg00092.html in riferimento alla PA, in effetti è quella che abbiamo utilizzato nei nostri scenari di test per ovviare al problema e ci sembra la strada preferibile per non intervenire sui servizi applicativi ed evitare di aggiungere complessità nell'integrazione dei client.

Nel caso in cui la situazione, actor non specificato e mustUnderstand=1, si verificasse per altri tipi di header, occorrerebbe per quanto detto aggiungere ulteriori "bypass". E' corretto ?

La versione 0.9 appena rilasciata permette una configurazione personalizzata dei bypass handler.
La configurazione e' attuabile nel file 'openspcoop.properties' attraverso le proprieta' con suffisso/ //org.openspcoop.pdd.services.BypassMustUnderstandHandler/.
Un filtro, e' stato inserito in testa ai servizi axis di OpenSPCoop (in un handler) e permette di bypassare il problema degli header con mustUnderstand=1 senza actor, segnalando come /processed/ l' header.
L'opzione /org.openspcoop.pdd.services.BypassMustUnderstandHandler.allHeaders/ (default /false/) impostata a /true/ abilita l'utilizzo del filtro per qualsiasi HeaderElement che possiede mustUnderstand=1 e non possiede un actor.
Se si desidera invece abilitare un filtro piu' selettivo, e' possibile operare con la proprieta' /org.openspcoop.pdd.services.BypassMustUnderstandHandler.header/ fornendo nome e namespace uri dell'header. Esempi di filtri abilitati per default sono i seguenti:


  1. /org.openspcoop.pdd.services.BypassMustUnderstandHandler.header.Security/,
     abilita gli header di WS-Security (namespace uri:
     
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd).//
  2. /org.openspcoop.pdd.services.BypassMustUnderstandHandler.header.Sequence/,
     abilita gli header di WS-Reliability (namespace uri:
     http://schemas.xmlsoap.org/ws/2005/02/rm).


Andrea.
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date:  Re: [OpenSPCoop-Dev] Test interoperabilità profilo sincrono (fwd), Andrea Poli
Next by Date:  [OpenSPCoop-Dev] Autenticazione SSL, Luciano Zu
Previous by Thread:  Re: [OpenSPCoop-Dev] Re: Modalità d'integrazione dei servizi applicativi, Andrea Poli
Next by Thread:  [OpenSPCoop-Dev] Test interoperabilità profilo sincrono, Luca Simbula
Indexes:  [Date] [Thread]