I had the opportunity to demonstrate a wired composite application to a client as well as a team member who's also support Expeditor. What's the best way to do that? Screenshots. Start with an out of the box Expeditor desktop client (don't forget to install the add ons in the updates/platform directory). Get a composite app by doing:
Create a new Composite Application.
Add any plugins which you've developed and any plugins shipped with Expeditor.
Preview and layout the components by dragging them on to the page.
Wire the source component (bookmark) to send information to the target (browser).
Wire the specific information you want to send - a URL as output from the source to input in the target (drag from one to the other).
View your masterpiece.
Viola! Now whenever you click Go with a URL selected, the URL is sent from the bookmarks source to the browser target.
Screenshots are good filler, but how does all this work? Composite applications are designed for "line of business" users or so I've been told. This means that we expect users to assemble an application on the fly depending on a business need. For example, instead of a browser links pair, imagine a product store location pair. When you select an item in the inventory component, the store locations which have the item in stock display. As the "user", don't worry about how it works. I find that more people don't grasp the concept of composite applications because they don't "get" how it works. As a user, just know that that when you create the wire from X to Y for Z information that something interesting will happen. If the developer understands you, the user, then that interesting event should lead to business value.
If you are the developer, then composite applications need to be created with purpose. Composite applications don't exist in a vacuum - you can't just send output and inputs ad hoc and hope they make a good application. Fortunately, most developers are likely familiar with decoupled components, and CAs are the extreme. Composite apps consist of many decoupled components in a publish subscribe (pubsub) architecture. The inventory widget publishes
product SKUs or some other identifier - why? Because that's it's purpose. The store location widget finds (subscribes)
products based on the SKU - again why? Because how else would you find them? That sounds a bit contrived, but it's more than likely what the user expects.
So, the bookmarks component is simple. It defines a WSDL file to publish the URL, an extension to let Expeditor know (so the user can create the wire in the composite application editor), and some small code to actually do the publish. The embedded browser component in turn does the same: a WSDL file to define the input URL, an extension to allow the wire, and some code to handle the incoming data. You might now be asking, "could you be more specific?"
Our component, the bookmarks plugin, doesn't care about the publish. It just sends out a broadcast message with a property name and value. We don't care who gets it - that's not our job. Our job is to simply make sure that when the user hits the Go button with a value selected in the list that we publish the correct property with the user's selection.
So who gets notified? That's the job of the composite application editor. The wire we created uses a medium called the Property Broker (an Expeditor component). The property broker is our air traffic controller. Out goes the message to the property broker, and it's the PB's job to make sure it's delivered to all interested parties. Those interested parties in turn have registered themselves via an extension to accept properties. But again, they don't have a say in what properties the receive - that's the property broker's job. The receivers simply need to ensure that given X property, they should do Y action (such as showing a web page or store location).
Make sense? To make it just a bit more succinct. Publishers normally follow the same boilerplate code to send a property value pair to the property broker. The intended receiver implements an interface which receives all property value pairs and should decide what to do with them. Finally, the WSDL files let Expeditor know what can be connected. Once connected (wired by the user in the composite app editor), the property broker will ensure that the publisher's property value pair gets sent to the intended receiver.
If composite applications are still a bit hazy, grab some Purple Haze
and start debugging with the provided sample: com.ibm.rcp.support.browser_1.0.0
And if you're still confused, read all 750 pages of Building Composite Applications