COMPOSITE APPLICATIONS - DESIGN AND MANAGEMENT


Using data types in composite applications
Composite applications in IBMR LotusR NotesR, Lotus Expeditor and WebSphere Portal use a property broker technology to communicate with other components. The property broker allows inter-component communication among components that are loosely coupled. Loosely coupled components are important in a service oriented architecture (SOA) as they allow reuse of coarse grained components in different applications. This lets you build applications on demand.

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:


Another suggestion is to publish two properties with different datatypes -- one as "xsd:string" and the other as a specialized datatype. You can also provide every action twice, once with "xsd:string" as the input datatype and once with a specialized datatype. Your tools will still display all properties and actions as "xsd:string," however.*