Composite Applications 101
Van Staub 120000BGUR Visits (3601)
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.
And if you're still confused, read all 750 pages of Building Composite Applications.