I am often asked what it means to be a component in a composite application in the Lotus Expeditor and Hannover. In general, because components are wired at the UI level, the component in Eclipse terms is called a ViewPart. The ViewPart is what makes up the different boxes in an Eclipse application. If you want to start creating components in a manner that is compatible with RCP applications and Composite Applications, then start making your views independent from other code. For instance, your view should not require other plug-ins or views unless it is necessary. Think of your view as a first class ActiveX control and you can not have any dependencies on other ActiveX controls. Write your view with the mindset that others may use this piece of real-estate in another context. Declare your interfaces to the component through the Property Broker and WSDL files. This means if any other component wants to interact with or receive information from your ViewPart you do it over the Property Broker.
Why you ask?
You can easily argue that the Eclipse selection model listener is already in place for this purpose, and yes it is. The major difference is a developer has to take those components, place them on a perspective and code the two together. In the Property Broker model, a novice user or administrator (not a developer) can bring these components together using Portal Admin or one of the other tools being released by IBM - Component Designer, Composite Application Editor, etc.
Tying in with Portal
In Portal, the parts are called portlets and are considered the same level of componentry as a ViewPart. You use the portal wiring tool to wire the components together on a portal page. This exact same model is used for Composite Applications coming from Portal in the Lotus Expeditor. You can have your portlets map to actual portlets (that run in the local container) or they can map to an Eclipse based SWT view. There are a series of new portlets that will show in portal when the Expeditor's Network Client Installer (NCI) is installed on top of the portal. You will get a new Rich Client tab when modifying pages and portlets. These portlets assist in describing how your portlets should render on the client. When the Expeditor client requests an application from portal the portal responds with Composite Application XML - or CA XML. This CA XML describes the entire application to the client; it describes the navigation, the layouts for the pages, and any preferences set on the pages and portlets by the administrator. The Rich Client tab in the portal administrator gives a user interface that makes it easier to set these preferences which tell the Expeditor how to project the application.
Running in Expeditor
Since Expeditor is Eclipsed based, any application running in it must be described as Eclipse Features and Plug-ins. The portlet preferences is where these features are listed for the Expeditor to resolve. When the Expeditor sees a feature requirement on a particular portlet it tells the Expeditor that it must attempt to resolve that feature prior to launching the application - meaning, see if the feature is currently installed and if not look to the remote site, download, and install the feature. If the feature resolves then the application UI is dynamically created by the Composite Application Infrastructure and displayed.
Hopefully this answers some questions and sparks some good discussion and questions.