Composite applications in Lotus Notes, Lotus Expeditor and WebSphere Portal use a technology called property broker to do inter component communication. The property broker allows inter component communication among components that are loosely coupled. Loosely coupled components are important in an service oriented architecture (SOA) to allow reuse of coarse grained components in different applications that can be built 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. 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. The component interfaces are defined via WSDL (web service description language) even though they are not invoked as web services. In WSDL you can define properties, actions and datatypes. You can use either built-in datatypes or you can define your own specialized datatypes.
WSDL also allows you to define your own specialized datatypes. Example:
This mailTo datatype is currently used by the mail component in Lotus Notes 8.0 beta. You can trigger an action to display a new mail and prepopulate multiple fields via this datatype. This datatype is rather complex and has its own semantic and syntax as defined by http://ftp.isi.edu/in-notes/rfc2368.txt.
Both built-in datatypes and specialized datatypes have pros and cons. The problem with specialized datatypes is that they make interoperability between different components more complex and sometimes even impossible. For example if you have one component from one vendor that calls this datatype 'mailTo' but another component from another vendor calls it 'rfc2368Type' you currently cannot wire them together even though they really use the same semantic and syntax. In another sample one component might publish a specialized datatype 'url' but another component only accepts xsd:string with an URL in it.
So in order to ensure maximal 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.
However the problem with only using xsd:string is that you can now 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 an URL to the mail component's action 'create new mail' which wouldn't make any sense. So if you only use xsd:string the assembly tools (Composite Application Editor and Portal Application Template Editor) wouldn't be able to help with the determination what wires are really possible and actions would have to handle being invoked with properties that they don't understand.
Because of the pros and cons of built-in and specialized datatypes I suggest the following guidelines how to use datatypes.
- Use as little as possible specialized datatypes. 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 is to ensure the maximal interoperability. - Only if you want to prevent wiring from arbritary xsd:string datatypes to your actions use specialized datatypes, e.g. if your action requires a certain semantic of a string to work (e.g. mailTo, url, dn, etc.).
- Use as little as possible different namespaces. All datatypes used by IBM WPLC/Lotus applications should use the same namespace "http://com.ibm.propertybroker.standardtypes". You should have such a default namespace in your enterprise too.
- To avoid the creation of too many datatypes in your enterprise you should have a way to manage the existing datatypes (some central registry) and some process how new datatypes are approved.
Another theoretic alternative is also to publish two properties with different datatypes, one just as xsd:string and the other one as specialized datatype. Vice versa you could provide every action twice, once with xsd:string as input datatype and once with a specialized datatype. While this might not cause real performance issues it doesn't make the tooling nicer either since you still see all properties and actions as xsd:string. So I'm not sure whether this is really a good idea.
We'd like to get some feedback about this. Please let us now how you'd want to use datatypes.