• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (8)

1 localhost commented Permalink

When you have two components with the same logical property but different type, do you think it's possible to address it by building a third non-visual component that act like a gateway? IMO, in a future version of Expeditor it will be useful a mapping-service similar to the Websphere Process Server one.

Thanks, Diego

2 localhost commented Permalink

Yes, this is exactly what you have to do today. In Lotus Notes and Lotus Expeditor you can build Eclipse ViewParts that are placed on hidden pages. These components can provide actions that tranform datatypes and publish the new new datatypes as output.

At some point of time we want to support real hidden components that don't require the workaround of hidden pages.
Another idea I really like are transformations on wires. In the assembly tools there could be palettes with transformation objects. You program these transformation objects via script/formulas. In the wiring UIs the assembly tools then don't only show the actions with input properties that match exactly but also the actions with datatypes that can be converted via transformaion objects.
There should also be simple transformation objects that define if datatypes with different names and/or namespaces are really identical.

3 localhost commented Trackback

I agree with your guideline to use as little as possible specialized datatypes. In fact I would go even further to say that people should only use a specialised datatype when you have two or more input/output properties which could be easily confused. For example if your component had two actions, one of which expected an internet style email address and the other expected a Notes style email address - then using specialised datatypes would avoid the possibility that you could accidentally wire to the wrong action. But if your two actions expected an email address and a country name, there would be much less chance of confusion and hence the benefit of the specialised datatypes would be less useful.

I also wonder if there would be any benefit in having the wiring tool implement some form of type casting. For example in Java it is useful to specify a URL data type as being different from a generic string because some operations only make sense on a URL, but other operations (e.g. printing to the screen) should not have to be separately implemented for strings and URLs.

4 localhost commented Trackback

I really like the whole property broker concept and I see the difficulties in implementing and managing specialized datatypes in composite applications. In my oppinion however the problem seems to be the same as in any other programming language when defining an API. You'll have to read the documentation to see whether a String may be null to signal an "empty" value or whether you need to supply an empty string (""). If you do not follow the contract defined by the API you might get in trouble and things might break.

IMHO it all comes down to how you're able to document the properties of a component. I think it is okay to define a property as xsd:string if there is a way to inform the consumer/provider that you expect it to be of a certain structure e.g. a valid URL.
This in fact brings up a whole new subject about how users/programmers are informed about runtime exceptions caused by incompatible datatypes. Any input there?

5 localhost commented Permalink

Mikkel, I agree that documentation will be important. We need some sort of Javadoc for components' datatypes, properties and actions that can be used as interchangeable format rather than sending WSDL back and forth with additional comments about semantics.

Right now we only support wires between compatible types. The property broker doesn't allow to create wires but even if there is such a wire (e.g. if datatype of property changed after wire was created) the property broker catches this at runtime and doesn't invoke the wire. The next time you open the application in the Composite Application Editor it tells you that there is a problem with that wire.

6 localhost commented Trackback

Could the need for documentation be solved by extending the WSDL schema to allow to additional tags via an IBM namespace inside the WSDL document? That would allow for documentation/help tags to be added to the types and/or messages tag to describe what you are doing and what the contents of a type should be (url/e-mail address etc.).

I'm not totally into WSDL so the tags might already be there but I don't think so. The beauty of extending the WSDL schema would be that even if the wires were only defined in pure WSDL the wired would still work and the additional tags would augment the experience from the users/developers point of view. It would also keep the format as WSDL.
Just a thought.

7 localhost commented Permalink

Mikkel, I'll investigate this. Sounds like a good idea but I have not seen such attributes yet. I think we'd still need some tool like javadoc that generates a more consumable format.

8 localhost commented Permalink

XML Schema has specific documentation attributes and elements, but we don't currently show these in the wiring tools.

If you are building one side of the wire, then the use of custom datatypes by the other component doesn't really matter (as long as it's documented somehow) as you can adapt your component to it. However, our goal is to allow the wiring together of components that were developed at different times by different people, and this requires the use of common conventions.
I'm going to do a post soon that talks about our future thinking in this area to get feedback from folks.

Add a Comment Add a Comment