Forums de discussion

Integration versus Aggregation

Leo Wadsworth, modifié il y a 15 années.

Integration versus Aggregation

Junior Member Publications: 77 Date d'inscription: 18/11/07 Publications récentes
I thought this community might be amused by my blog post today regarding Integration (Liferay) versus Aggregation (using a bunch of discrete applications).

There is an ongoing debate between integration versus aggregation. Integration in this instance means using a package, such as Liferay (the portal system we use), which includes a number of functions as part of the package. Liferay includes blogs, wikis, message boards, and a lot of other features.

Aggregation refers to combining a bunch of different programs to produce an overall web presence. For example, you might combine WordPress for blogs, PHPbb for message boards, MediaWiki for wikis, and other programs to make an overall website.

Both methods have advantages and disadvantages. Let me use an analogy to explain. I like the Pentel TwistErase mechanical pencil. It has a nice size barrel, writes easily, and has a full-size eraser which works really well. I also like the feel of a Parker jotter ballpoint pen. Nice solid construction, good click, writes well. These are, for me, the best of breed at a reasonable pricepoint. For years I carried these two writing implements in my shirt pocket. They didn’t match, but they did their job well. This is aggregation.

These days I carry a Cross pen and pencil set. They work just fine. The barrels are a bit skinnier than I would prefer and the mechanical pencil has one of those dinky erasers, but they work. They also look better – they match each other. Presumably, this improves my appearance/presentation ever so slightly. This is integration.

For a portal website, integration has advantages such as being able to mix a number of tools on the same page. Each of the tools uses the same database and authentication configurations and schemes. They share a common UI. As the users use the site, they become familiar with the UI of one tool and they already have a headstart towards using the other tools – much like Microsoft Office shares much of the look and feel among different programs in the Office suite. The obvious downside is that all of the tools are from one place, and may not have the complete feature set of the “best of breed” tools. For example, the original Liferay wiki from version 4.4 was lacking various crucial features. The new version of the wiki in version 5.1 has made huge strides in providing a solidly competitive feature set. There are “nice to have” features which are not in the Liferay message boards or blogs…yet. The product is very dynamic, with improvements and new features every release. By using the integrated tools, as the tools are upgraded we automatically get access to the latest and greatest.

For a portal website, aggregation has the advantage of providing “best of breed” functionality for every function. However, each tool has its own UI. While there can be some work that can help to regularize the UI, it remains a significant issue. Each tool has its own authentication mechanism. If you are using open source tools, it is always possible to work to bring the mechanisms together into a common method. The more work you put into aggregation the closer you can come to integration. However, there is also the upgrade issue. The more you modify each application, the harder it is to keep the applications updated to a recent version.

We chose a mixture of integration and aggregation. For the most part the user facing pieces are supplied by Liferay. However, we use aggregation for some backend servers. We use OpenX to provide rotating content, and we use Alfresco to provide some of the big file and multimedia content management. We have integrated both Liferay and Alfresco with CAS authentication hooked to the IEEE LDAP. OpenX uses its own authentication, but the number of users is extremely small (only the people needing to post the content).

In so doing, we recognize that we may not supply the ultimate feature set for each application, but we end up with an environment that works well together and that lets us provide a seamless integrated experience for the website. Is the feature set “good enough”? That’s a judgment call, and good folks can disagree on that one. Obviously I would say “yes, it is.”