[For a YouTube introduction to this article, see here.]
When you create an XPage application, you do so by adding certain new design elements: XPages, Core and Container Controls, Custom Controls, Themes, Style Sheets, Javascript libraries, etc. Although some of these can be used for traditional Notes client development, you do not often use the same instances for both traditional development and XPages development. So the artifacts used to create an XPages application stand apart from those used for the main business logic of your application.
Another point to note is that these XPages elements bear no special relationship to the database they are in. An XPages control may reference data in the current database, but it can just as easily reference data in a separate database. Even image resources can be indirected to different databases. So XPages elements are, largely, agnostic, about where they live with respect to the data and logic they are referencing.
If you put these two points together, it is easy to see how XPages can be quite easily used to combine data from multiple databases. Since a control can just as easily get data from a different database, you can have two controls that each pull data from different databases. Logic can be called where needed, to allow different buttons in the same page to call the logic of two different applications, or you a single button that calls logic in two different places.
There are a large number of workflow applications written with Notes that involve processing data and moving it from database to database. XPages have the ability to streamline these processes and make the overall flow more natural between repositories. Of course Notes has been able to integrate different databases using framesets for quite some time and composite applications in Notes 8.0. You can achieve the same end with XPages, but you can also go beyond it. XPages do not limit you to nested frames of atomic information. You can integrate them to any level of granularity you desire.

Large Granularity
When integrating in "large granularity" mode, you are adding elements together in the same model as you would for framesets or composite applications. Custom controls can be created to surface data from the different data sources. They will have parameters to specify more specifically what aspect of the data source to show. For example a custom control based on a form might be told the document ID. One based on a view might be told which category to filter by. These controls can then be aggregated on the XPage to display the different data sources together. It is, essentially, a mashup done at design time.
Each custom component will have it's properties set to control what is correct to display for the context. Some may be static. For example, if you always what to show the "Needs Approval" category in an expense processing application you might set that statically on the custom control when deployed to the XPage. Some may be set dynamically. For example if a "view and preview" style is used the XPage would have two controls. The view control would set a sessionScope parameter. The form custom control would set the document ID property to be a calculated field set to that entry in the sessionScope. So after a line in a view is selected and the sessionScope updated, it can direct the framework to redraw the form and it will preview the appropriate data.
In addition to the "view and preview" style, another common technique of doing large granularity integration is with a "dashboard" effect. With integration you have the ability to add relevant information to the context of the process you are working on. However you still need to be able to devote the majority of your attention to your central activity. One way to balance these two needs is to use a style where the main elements required to do the main activity for this page occupy the central space. These are usual ly custom controls for viewing, manipulating, or processing individual records and collections of data. Then along the periphery of the screen, other custom controls are arranged bringing in additional information and context to the central operation. This "dashboard" can wrap around the left, bottom, right or even top of the main central area, depending on your design needs. The ability to arrange components in a tab container is a highly useful way of managing screen real estate and providing a wealth of information that is immediately accessible, but without taking up large areas of your layout.
In the Lead Manager sample application the lead details page is arranged in this style. In the main area of the screen are the details for the lead. Then, along the bottom is a tabbed container with further information on the company for this lead, a view into the discussion category for this lead, a view into the contract processing for this lead, and a profile sheet for the main contract for the lead. Each of these other information panels gets it's data from a different database by calculating the appropriate key from a field(s) in the main area. They are integrated together here for ease of operation.



Small Granularity
As mentioned above, you are not restricted to sticking to a single data domain for each custom control. This makes sense for large granularity development, but there are also plenty of circumstances where a tighter and more focused integration makes sense.
For example you may have a single semantic process that is enacted through multiple forms in multiple databases. Previously your application was probably required to be "data centric" (i.e. to display each data element as makes sense for where it is in the process). That is fine for some tasks. But other tasks may benefit from being more process centric. In that case you want to show the information that is relevant for processing the item based on where it is in the workflow; irrespective of where the data comes from. So, if, say, you are signing off a work order for some artwork to be done by an external company for a marketing campaign, you may not be interested in the details of what artwork is being commissioned, but you will be interested in knowing what department it's for, their budget, maybe some details on the company and your credit history with them. These are unlikely to all be in the same database. XPages gives you the flexibility of creating a custom control that surfaces just the data elements you want from any and all sources they may reside in.
In another example, you may have a view in a database that contains simple information: say a list of invoices that have been sent out. It might be helpful for the operator to view any invoices for a company currently in arrears by turning their name red. The overall balance for the company is not going to be in the invoice document. But the name is and a quick lookup into the accounting database could be used to determine their solvency and make a choice about what style to display that column in for that entry.
Not all integration has to take place immediately or visibly. In the above example, it may be too computationally intensive to look up a company's balance for each and every line rendered in the view. You could present an alternative UI, when the user hovered over the name, or clicked on an embedded icon, a pop up panel floated up and gave the balance for that one company.
With small granularity integration you can really increase the information density of what you present to the user. Information can be realized in various ways that make the data accessible, but do not clutter or complicate the view. Similarly the ability for XPages to only render what is important lets you only look up the data you need when you need it, easing performa nce concerns that might otherwise have been an issue for fetching all that data.

For other examples of using XPages as an integration platform, please see this article.