It's always been possible to use service bridges to delegate tasks between Drupal sites. Recently however a lot of new modules have been implemented for Drupal that are (going to) making this a lot easier. So much easier that I believe that Drupal service clouds, in which features are distributed over more than one specialized site, will become one of the great architecture options (together with organic groups, domain access and installation profile powered multi-site setups) to keep in mind when planning a project. Together with the renaissance of installation profiles and Drupal distributions, this will make it more interesting to integrate a couple of distributions with a custom site than to try building all the features into 1 site. This is already happening with third party software integration projects such as the Alfresco and Apache Solr modules. A similar distributed feature architecture could however also be very interesting if implemented with a series of specialized Drupal sites. In this post I'll talk about the pro and contra's of this approach and do a short review of the technologies that could be used to implement it.
When confronted with a great number of features the first reflex of most developers is to try to integrate all functionality into 1 website. The main reasons are:
- reduced maintenance costs
- reduced communication costs – less traffic required
- greater flexibility (easy to put a block from one business application on a page of another)
- no data transfer required (so no custom XML RPC scripts)
- better performance (no network latency)
Having too much functionality in 1 site is however not always practical:
- You will probably run into module overbloat (resulting in slower performance and potential integration issues)
- You might get into trouble with different sections needing different permissions
- You might have to over-abstract your views to accommodate different use cases
- You might run into content pollution from other sections of your site
- You might have to accommodate way too many persona's and navigation might get a mess
When planning a complex set of interconnected services, you have 3 options:
- A) you can pull in (and locally store) all data and build your "view" on the client side
- B) you can build local queries of remote data sources
- C) you can display processed and (pre)themed information from the remote data sources
Scenario A used to be the default choice: keep the data in one Drupal database and then do some node access magic, classical examples of this technique are Drupal's great “content separation tools”: Organic groups and the Domain access modules.
- RSS: Back in the days of Drupal 5, when I was still playing with PHP myself, I put together a little add-on module for views-rss that made it possible to dump the fields of a view into extra RSS elements. That way you could set up a data connection between sites using RSS and FeedAPI and the Feed element mapper. Recently Kornel created a patch for Views RSS that enables the same basic data transfer functionality for Drupal 6
- Table wizard + migrate module: You can use the table wizard to build views from arbitrary databases and then use those to import that content into your Drupal database.
- you could use Deploy to push out the data that you need.
Scenario B works with the raw data from the source. The advantage is that since it contains all the information it's probably the most flexible solution. In some cases you'll have to send all data that you query of the network/between the sites. There are however also solutions that will distribute to processing and only get back the results.
- Since Table wizard lets you create views from external database tables, you could engineer your database infrastructure so that the tables are available to all of your client sites.
- Views 3: Views 3 will be able to query remote databases, so you could build a view in your site with data from a second site. Here's an interesting writeup by Robert Douglass
- RDF: A whole suite of modules is being built to bring RDF to Drupal. Especially if you want your data to be openly available for third party mashups, you should consider using RDF.
- Services module: is a platform for a range of add-on modules. Services module let's you do Views and Node service calls, but you'll have to build some custom code blocks to get your data back in.
Scenario C is something we now started experimenting with:
- Remote blocks: is a module that allows you to load blocks from a different Drupal site. Right now you could for example use it to display a news views block from your “news” site without having to aggregate all the news items and duplicating the view on the other site. But we would like to make these blocks context aware, so that you could get things like related content, etc. Tamas wrote a blog post about this module last week.
Other technologies we would like to work on to make this possible are:
- Remote node references: that allow you to reference a node from another Drupal site
- Remote views: use a view from another site as if it would have been a local view (useful when a view is used to enable certain options e.g. to identify the nodes you can use for a nodereference, etc.), this is not to be confused with the remote data view in views3.
For example a University could have the following sites in a Drupal service cloud architecture:
- A Managing News or a Tattler site for news scanning, that provides a relevant news block Open Atrium for project management and on the job knowledge management
- A CRM site to manage contacts details and communication reports, could provide an about the author block
- A website that provides information to externals about the organization
- An Alfresco site as a document repository
- An installation profile to deploy department sites
- OpenSolr for search across all these sites
- An Aegir site to manage all the above
- An LDAP server to provide access to all the above
