APPLICAZIONI COMPOSITE - PROGETTAZIONE E GESTIONE

Utilizzo dei tipi di dati nelle applicazioni composite
Le applicazioni composite in IBM® Lotus® Notes®, Lotus Expeditor e WebSphere Portal utilizzano una tecnologia con broker di proprietà per comunicare con gli altri componenti. L'broker di proprietà permette comunicazione tra componenti che sono associati in modo non esatto. I componenti associati in modo non esatto sono importanti in un'architettura orientata al servizio (SOA) in quanto permettono il riutilizzo di componenti granulari grossolani in applicazioni diverse. Questo permette di costruire applicazioni su richiesta.

La comunicazione tra i componenti avviene per mezzo di proprietà, azioni e fili (cablaggi). I componenti di origine possono pubblicare proprietà di output che hanno nomi, tipi di dati e valori. I componenti di destinazione forniscono azioni che hanno proprietà di input.

Il tipo di dati della proprietà di output deve corrispondere al tipo di dati della proprietà di input dell'azione per definire un filo che permette la comunicazione tra due componenti. Le proprietà e le azioni di output sono definite come parte dei componenti.

I fili tra i componenti sono definiti solo a livello delle applicazioni composite, il che assicura un accoppiamento non stretto. Le interfacce dei componenti sono definite tramite file WSDL (Web Services Description Language) sebbene esse non siano richiamate come servizi Web.

In WSDL si definiscono proprietà, azioni e tipi di dati. È possibile utilizzare i tipi di dati incorporati o definire tipi di dati specializzati. I tipi di dati incorporati sono specificati in W3C http://www.w3.org/TR/xmlschema-2/#built-in-tipi di dati. Ad esempio, vi sono tipi di dati come "xsd:string" (http://www.w3.org/TR/xmlschema-2/#string) che sono utilizzati per rappresentare stringhe di caratteri.

Questi tipi di dati sono collegati ai diversi tipi di dati/classi dei linguaggi di programmazione. Ad esempio, i tipi di dati W3C sono collegati ai tipi di dati Java(TM) tramite i tipi di dati JAXB 2.0. Questo vuol dire che un tipo di dati xsd:string è associato a un tipo di dati java.lang.String. Analogamente ci sono altri collegamenti a LotusScript e JavaScript per i tipi di componenti NSF.

WSDL permette anche di definire tipi di dati specializzati. Gli esempi seguenti illustrano questo punto.

<types>

<xsd:schema targetNamespace="http://com.ibm.propertybroker.standardtypes">

<xsd:simpleType name="mailTo">

<xsd:restriction base="xsd:string"/>

</xsd:simpleType>

</xsd:schema>

</types>



Il tipo di dati mailTo nell'esempio viene attualmente utilizzato dal componente Mail (Posta) di Lotus Notes. Quando si utilizza questo tipo di dati, è possibile attivare un'azione per visualizzare la nuova posta e campi multipli precompilati.

Nota Questo tipo di dati è complesso e ha una propria semantica e sintassi come definito da http://ftp.isi.edu/in-notes/rfc2368.txt.

I tipi di dati incorporati e specializzati hanno dei pro e dei contro. I tipi di dati specializzati possono rendere più complessa e talvolta impossibile l'interoperabilità tra i vari componenti. Ad esempio, se si ha un componente di un produttore che chiama "mailTo" il tipo di dati, ma un altro componente di un altro produttore lo chiama "rfc2368Type", i componenti non possono essere cablati insieme sebbene in realtà utilizzino la stessa semantica e sintassi. In un altro esempio. un componente potrebbe pubblicare un tipo di dati specializzato "url" ma un altro componente accetta solo "xsd: string" con un URL al suo interno.

Per assicurare una migliore interoperabilità, i componenti dovrebbero utilizzare un minimo denominatore comune per l'utilizzo dei tipi di dati. In altre parole, i componenti dovrebbero utilizzare solo tipi di dati incorporati, preferibilmente solo "xsd:string". Il problema con l'utilizzando del solo "xsd:string", tuttavia, è il fatto che è possibile definire fili tra tutte le proprietà e le azioni di output, anche se le azioni non possono gestire una certa proprietà.

Ad esempio, senza il tipo di dati specializzato "mailTo", si potrebbe cablare il componente che pubblica un URL all'azione "crea nuova posta" del componente Mail. Questo risultato non avrebbe alcun senso. Se si usa solo "xsd:string", gli strumenti di assemblaggio (Composite Application Editor e Portal Application Template Editor) non saranno in grado di determinare quali fili sono veramente possibili e le azioni dovranno gestire chiamate con proprietà che non capiscono.

Per evitare i problemi creati dai tipi di dati incorporati e specializzato, utilizzare le seguenti indicazioni:


Un altro suggerimento è di pubblicare due proprietà con tipi di dati diversi -- uno come "xsd:string" e l'altro come tipo di dati specializzato. È possibile anche fornire ogni azione due volte, una volta con "xsd:string" come tipo di dati di input e una volta con un tipo di dati specializzato. Gli strumenti visualizzeranno tuttavia le proprietà e le azioni come "xsd:string".*