La comunicación entre componentes se realiza mediante propiedades, acciones y conexiones. Los componentes de origen pueden publicar propiedades de salida que tengan nombres, tipos de datos y valores. Los componentes de destino proporcionan acciones que tienen propiedades de entrada.

El tipo de datos de la propiedad de salida debe coincidir con el de la propiedad de entrada de la acción para poder definir una conexión que permita la comunicación entre dos componentes. Las propiedades de salida y las acciones se definen como parte de los componentes.

Las conexiones entre los componentes sólo se definen en el nivel de las aplicaciones compuestas, lo que asegura la conexión poco rígida. Las interfaces de los componentes se definen a través de archivos WSDL (del inglés Web Services Description Language, lenguaje de descripción de servicios Web), aunque estos no se invoquen como servicios Web.

En WSDL, se definen las propiedades, las acciones y los tipos de datos. Puede usar los tipos de datos incorporados o puede definir sus propios tipos de datos especializados. Los tipos de datos incorporados se especifican en W3C http://www.w3.org/TR/xmlschema-2/#built-in-datatypes. Por ejemplo, hay tipos de datos como "xsd:string" (http://www.w3.org/TR/xmlschema-2/#string) que se usan para representar cadenas de caracteres.

Estos tipos de datos están vinculados a los tipos de datos y las clases de distintos lenguajes de programación. Por ejemplo, los tipos de datos W3C están vinculados a los tipos de datos de Java(TM) a través de JAXB 2.0. Esto significa que un tipo de datos xsd:string está vinculado a un tipo de datos java.lang.String. De forma similar, existen otros enlaces con LotusScript y JavaScript para los tipos de componentes NSF.

WSDL también le permite definir sus propios tipos de datos especializados. En los ejemplos siguientes se ilustra este aspecto:

<types>

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

<xsd:simpleType name="mailTo">

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

</xsd:simpleType>

</xsd:schema>

</types>

El tipo de datos mailTo del ejemplo lo utiliza actualmente el componente de correo de Lotus Notes. Por medio de este tipo de datos, puede desencadenar una acción para mostrar un correo nuevo y llenar previamente distintos campos.

Nota Este tipo de datos es complejo y posee una semántica y una sintaxis propias definidas por http://ftp.isi.edu/in-notes/rfc2368.txt.

Los tipos de datos incorporados y los tipos de datos especializados tienen pros y contras. Los tipos de datos especializados pueden hacer que la interoperatividad entre los diferentes componentes resulte más compleja e incluso llegue a ser imposible. Por ejemplo, si tiene un componente de un proveedor que denomina "mailTo" al tipo de datos, pero otro componente de otro proveedor lo denomina "rfc2368Type", los componentes no podrán conectarse aunque en realidad utilicen la misma semántica y la misma sintaxis. También podría darse el caso de un componente que publique un tipo de datos especializado "url" pero otro componente solamente acepte una "xsd:string" que contenga una URL.

Para garantizar la mejor interoperatividad, los componentes deberían utilizar el mínimo común denominador en lo que se refiere al uso de tipos de datos. Es decir, los componentes deberían utilizar solamente tipos de datos incorporados, preferiblemente sólo "xsd:string". No obstante, el problema de usar sólo "xsd:string" es que puede definir conexiones entre todas las propiedades de salida y las acciones, incluso si las acciones no pueden manejar una propiedad determinada.

Por ejemplo, sin el tipo de datos especializado "mailTo", podría conectar el componente que publica una URL con la acción del componente de correo "crear correo nuevo". Este resultado no tendría ningún sentido. Si sólo utiliza "xsd:string", las herramientas de ensamblaje (Editor de aplicaciones compuestas y Editor de plantillas de aplicaciones de WebSphere Portal) no serán capaces de determinar qué conexiones son posibles realmente, y las acciones tendrán que ser invocadas con propiedades que no entienden.

Para evitar los problemas provocados por los tipos de datos incorporados y especializados, utilice las directrices siguientes:

• Utilice los tipos de datos especializados lo menos posible. En su lugar, utilice los tipos de datos incorporados definidos por W3C http://www.w3.org/TR/xmlschema-2/#built-in-datatypes. En el mejor de los casos, utilice solamente "xsd:string". Esto garantizará la mejor interoperatividad.
• Utilice los tipos de datos especializados solamente si desea evitar la conexión procedente de tipos de datos "xsd:string" arbitrarios con sus acciones. Por ejemplo, si su acción requiere una cadena con una cierta semántica para funcionar correctamente (mailTo, url, dn, etc.).
• Utilice los tipos de datos distintos lo menos posible. Todos los tipos de datos utilizados por las aplicaciones IBM Lotus deberían utilizar el mismo espacio de nombres "http://com.ibm.propertybroker.standardtypes". También debería tener el mismo tipo de espacio de nombres predeterminado en su propia empresa.
• Cree una manera de gestionar los tipos de datos existentes (por ejemplo, un registro centralizado) y algún proceso que controle la aprobación de los nuevos tipos de datos. Estos pasos le ayudarán a evitar la creación de demasiado tipos de datos en su empresa.

Glosario