Inter-component communication is done via properties, actions and wires. Source components can publish output properties which have names, datatypes, and values. Target components provide actions that have input properties.

The datatype of the output property has to match the datatype of the input property of the action in order to define a wire between two components for communication. The output properties and actions are defined as part of the components.

The wires between components are only defined on the level of the composite applications which ensures the loose coupling. Component interfaces are defined via WSDL (Web Services Description Language) files even though they are not invoked as Web Services.

In WSDL, you define properties, actions and datatypes. You can use either built-in datatypes or you can define your own specialized datatypes. The built-in datatypes are specified by W3C http://www.w3.org/TR/xmlschema-2/#built-in-datatypes. For example, there are datatypes like "xsd:string" (http://www.w3.org/TR/xmlschema-2/#string) that are used to represent character strings.

These datatypes are bound to different programming languages' datatypes/classes. For example, the W3C datatypes are bound to Java(TM) datatypes via JAXB 2.0. This means an xsd:string datatype is bound to a java.lang.String datatype. Similarly there are other bindings to LotusScript and JavaScript for NSF component types.

WSDL also lets you define your own specialized datatypes. The following examples illustrate this point::

<types>

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

<xsd:simpleType name="mailTo">

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

</xsd:simpleType>

</xsd:schema>

</types>

The mailTo datatype in the example is currently used by the Mail component in Lotus Notes. You can trigger an action to display a new mail and pre-populate multiple fields when you use this datatype.

Note This datatype is complex and has its own semantics and syntax as defined by http://ftp.isi.edu/in-notes/rfc2368.txt.

Built-in datatypes and specialized datatypes have pros and cons. Specialized datatypes can make interoperability between different components more complex and sometimes even impossible. For example, if you have one component from one vendor that calls the datatype "mailTo'" but another component from another vendor calls it "rfc2368Type," the components cannot be wired together even though they really use the same semantics and syntax. In another example one component might publish a specialized datatype "url'" but another component only accepts "xsd:string" with a URL in it.

To ensure the best interoperability, components should use the least common denominator in terms of using datatypes. In other words, components should use only built-in datatypes, preferably only "xsd:string." The problem with using only "xsd:string," however, is that you can define wires between all output properties and actions, even if the actions cannot handle a certain property.

For example, without the specialized datatype "mailTo," you could wire the component publishing a URL to the Mail component's action "create new mail." This result would not make any sense. If you only use "xsd:string," the assembly tools (Composite Application Editor and Portal Application Template Editor) will not be able to determine which wires are really possible and actions will have to handle being invoked with properties that they do not understand.

To avoid the issues created by built-in and specialized datatypes, use the following guidelines:

• Use specialized datatypes as little as possible. Instead, use built-in datatypes as defined by W3C http://www.w3.org/TR/xmlschema-2/#built-in-datatypes. In the best case, use only "xsd:string." This will ensure the best interoperability.
• Use specialized datatypes only if you want to prevent wiring from arbitrary "xsd:string" datatypes to your actions. For example, if your action requires a certain semantic of a string to work (mailTo, url, dn, etc.).
• Use different namespaces as little as possible. All datatypes used by IBM Lotus applications should use the same "http://com.ibm.propertybroker.standardtypes" namespace. You should also have the same kind of default namespace in your own enterprise.
• Create a way to manage the existing datatypes (for example, some central registry) and some process that controls how new datatypes are approved. These steps will help avoid the creation of too many datatypes in your enterprise.

Glossary