So what is a container? For that matter, what is a component? Hopefully when you finish reading this article, I will have cleared up some of the confusion between IBM composite application components and IBM composite application containers.
Components are a rich decoupled part with a well defined purpose. A component in our Composite Application (CA) context is a stateless self contained piece of function that has configuration information and well defined inputs and outputs. More often than not, they have a visual interface. I like to compare CA components to visual web services. They provide the end user with a slice of information. They provide an assembler with a building block. Several slices can be combined to give the user a more complete picture. These slices can be combined and reused in numerous ways providing flexibility for the individual combining them (the assembler role).
The visual web service analogy is a little misleading though because not all components have visual representations. We denote some components as hidden because they perform an operation on the value of an input parameter and output the result without any user interaction required. This form of component does not require a visual interface at run time, and is referred to as a hidden component or if it will be global to the application (instead of being hidden on a page) is typically referred to as a hidden service component.
Component examples are mail, calendar, search, and map components, where each could take inputs, like the date for a calendar, and/or provide outputs, like the “to: members” of the currently selected email. Components are usually created by developers in a development environment.
Containers are the vehicle to wrapper (bridge) around a pre-existing application types, like terminal emulation or a web application in an IBM Composite Application. While the container itself is a development artifact, the goal of the container is to give the assembler an easy declarative way to create a CA component from an existing application type (i.e. a web component from a web application, or a notes component from a notes database).
Take the browser container for example. A web application is in and of itself not a CA component, that is, it is shown in a browser and your other applications have no way to interact with it. A
developer can create a CA component by using the browser widget in a rcp swt view, interact with the DOM to update and retrieve DOM elements and create the input and outputs programmatically using a WSDL, while the browser container allows an
assembler to configure it for a specific web application without any awareness of rcp, swt, Dom or WSDLs.
The assembler can assign the home URL, and can instrument input and output properties to any and all pages of that application. The result is a browser container configuration and is the CA component that can now be integrated with other CA components. An assembler can create as many browser configurations as they like.
Examples of containers are the browser container, Host on Demand (HOD) container, Notes container, and the Symphony Spread Sheet Container.
The container infrastructure makes it easier to handle some of the nuances of building a generic bridge which will generate the equivalent of a CA component. This includes dynamically creating properties, getting property values at initialization, handling property changes without requiring action handlers and providing a mechanism to instrument properties across states of the existing application.
A lot of the container infrastructure, like the elimination of WSDLs and retrieving property values during initialization, could be leveraged to create a CA component, but there is a lot of overhead in the container infrastructure to support the bridging and state functionality.
The Container Component allows you to easily convert/create an SWT View Part to a CA component which leverages the container infrastructure under the covers.
So in general, if you want to make a bridge to an existing application type, create a container. If you want to create a component that has well defined inputs and outputs, then create a CA component. If you want to create a CA component and don’t want to deal with WSDLs, action handlers, and managing initialization of properties then use the Container Component.