Bring information and collaboration into the context of your daily business processes using composite applications
[UPDATED 11/28/06 by Jeff Calow to remove references to the internal division name that was causing confusion and added links to product home pages]
Welcome to our new group blog. It brings together all the key technical architects and user experience design professionals for the major products from the Lotus software division that provide support for user facing composite applications. These products include IBM Websphere Portal 6.0, IBM Lotus Notes 8.0, IBM Lotus Domino 8.0, IBM Lotus Expeditor 6.1 and future products to be named when they are announced. The folks that will be helping with this blog on a regular basis are:
Art Thomas -> Lead architect for Domino administration
Bob Balfe -> Lead architect for Portal projection in Expeditor
Brian O'Donnovan -> Overall development manager for user facing composite applications
Craig Wolpert -> Lead architect for Notes/Domino ISV enablement
Eric Masselle -> User experience designer for composite application editing and portal document workflow
Jeff Calow (me) -> Chief architect for user facing composite applications
Kristina Beckley -> Lead user experience designer for composite applications in Notes/Domino
Niklas Heidloff -> Lead architect for composite applications in Notes
Peter Fischer -> Lead architect for Application Infrastructure in Portal
Stanley Dunne -> Lead architect for composite application composition tools
Thomas Stober -> Release architect for the next version of Portal
The impact of composite applications is so broad that we will also be having many guest speakers from across our product lines. Our goal with this blog is provide a personal, direct line of communication between experts working in this exciting and often confusing technology area and our customers and partners. Each poster brings their own diverse perspective and ideas to the conversation, so don't expect a marketing pitch or a single voice or style :-) We'll also be "trying out" various ways of explaining what we are doing and why, so we value your feedback in helping refine our technical story to be crisp and understandable. We'll also be posting direct questions to gather your feedback in time to affect ongoing product plans.
It's important to note that none of us speak officially for IBM, nor can we make product commitments or discuss products that have not been announced.
As a way of starting the conversation, each of the regulars will be posting a short bio of themselves and then a short description of how the product they are associated with fits into the Lotus software composite application strategy. We'll then be posting about topics that we find personally interesting as well as looking out into the industry. If you have a topic that you're burning to get information about, let us know.
The Lotus software Composite Application Team
Many people have been asking if composite applications and mashups are really the same thing. The short answer is that they are similar, but not quite the same thing.
When we talk about composite applications, we mean applications which have been assembled out of existing components that have been "wired" to work together. When people speak about mashups they are talking about applications which have been built by writing a small amount of code to combine the capabilities of two or more existing sites.
In both cases we are talking about reusing existing assets. In addition, both ideas involve combining the existing assets in innovative ways so that "the whole becomes more valuable than the sum of its parts". However, there are a number of key differences:
We are not saying that mashups are better or worse than composite application, just subtly different. I hope this explaination is helpful for people to understand the difference.[Read More]
Now that I'm back from Thanksgiving vacation and caught up on all my email, I figured I'd start by defining what I mean when I talk about "Composite Applications". (and yes you can see my philosophical side being exposed here :-)
Let's start with a dictionary definition of composite. The only part of the definition even related to computing is "1: made up of distinct parts". So then a composite application is an application made up of distinct parts. That's pretty broad. The definition of distinct is "distinguishable to the eye or mind as discrete". Thus the questions and confusion in this space comes down to:
1) What are the parts that are distinct?
2) And to whose eye or mind are they distinct?
Computer Architecture Oriented Definitions:
The current general industry trend for the use of the term "composite application" is that it is related to application integration and Service Oriented Architectures (SOA). The parts are existing applications or whole systems of applications that are integrated together within some kind of composition framework.
Doing a quick Goggle search and just looking at some of the first page of results:
The IBM SOA Definition:
...composite applications, which are applications that draw upon functionality from multiple sources within and beyond the enterprise to support horizontal business processesFrom Loosely Coupled.com
An application built by combining multiple services. A composite application consists of functionality drawn from several different sources within a service oriented architecture (SOA). The components may be individual web services, selected functions from within other applications, or entire systems whose outputs have been packaged as web services (often legacy systems).Oasis has a Web Services Composite Application Framework TC
...define a generic and open framework for applications that contain multiple services used in combination (composite applications).Here is the Wikipedia entry (sorry Brian, they consider Mashups as composite apps and so do I...)
...expresses a perspective of software engineering that defines an application built by combining multiple servicesWhat do all these definitions have in common? The parts that are distinct are services and they are distinct in the eyes of the composite application assembler.
In general, the perspective is that the assembler is bringing together back end services (generally exposed as web services) to perform some kind of automated application integration. That is an important goal and great for automating those processes that can be automated. But this blog is about "Composite Applications for People" and by definition, people are not very involved in an automated process (except maybe to kick them off or solve "exception problems" that the computers can't)...
Relating this back to people:
To relate this back to people, we think about creating compositions by bringing the user interface of distinct systems together into a unified visible context. This is done to increase the productivity of the end user in executing the tasks that are part of the actual processes of doing business (vs just those processes that can be automated). It does it by providing the user access to relevant and appropriate information based on the current context (e.g. the kind of process or the step in the process). We'll talk much more about the importance of context in another post.
Developer created compositions (aka Mashups):
The assembler in all these case is still a developer and there is tight coupling between the user interface and the custom control. Each control generally has it's own custom API even if they are conceptually doing similar things (e.g. the different Map controls) This is also the level that most Mashups work today.
To facilitate development, there have been many "tools" created that allow for the rapid, visual assembly of controls into a user experience and binding the data between controls using gestures or scripting. Some Web 2.0 trends in this area are the "application wiki's". However, I still class these all as development tools and development created compositions.
Non-developer assembly (aka Portals):
In contrast to that we have the Portal pattern. This is were a "mini-application" component owns a piece of real estate and many of these components can be assembled together on a single visible page. This mini-application is one of our units of distinction and can be considered a UI service. I'll generically call it a Portlet . (this also happens to be what the Java world calls the standard component. In Eclipse it would be a ViewPart and Microsoft calls them Web Parts). This is the unit of aggregation, not necessarily the unit of deployment (e.g. in Java the unit of deployment is a web application archive or WAR and in Eclipse the unit of deployment is an OSGi bundle)
The key distinction with this pattern is the strong separation between developing the Portlet and it's deployment unit (which is still a developer task), deploying the Portlet's deployment unit (which is an administrator task) and the creating a composition of various Portlets, sourced from different, independent providers, on sets of pages to create a portal or a section of a portal (which is an administrator or end user task). We call this "UI level aggregation" or "integration on the glass". Portlets provide a fragment of the total UI for a specific back end application or service and are generally coarser grained than the above mentioned UI controls (but the Map controls above are a great example of the intended granularity).
In WebSphere Portal this distinction is supported by a specific framework with a standard component interface for plugging in the UI blocks and mediating loosely coupled interaction between them. A design goal was to allow for a variety of different programming models to create components (e.g. hand coded Java, JSP, Java Server Faces, Portlet Factory models, Lotus Component Designer, Lotus Domino, remote web service name your favorite web template system) unified by a common interface to the framework. This way, the composer sees all components as the same "kind" and picks based on the capability, not the underlying implementation language. Administration, roles and access control can also be handled at the high level component level.
We also use this same, centrally manged, composition definition to "project" to our rich client based "portal" in Lotus Expeditor (more about that in another post).
Now many developers out there will say "That's just bait and switch. You just created a component model at another layer of abstraction that everyone now needs to conform with. I can do the same thing with my favorite XYZ tool in my favorite GHI programming language". In one sense that is true (and it's what various 4GL's have done many times in the past). On the other hand, this interface level is intended to be coarser grained than a custom control, it's based on industry standards for both Java (Portlet 1.0 JSR 168, Portlet 2.0 JSR 286) and for interaction based web services in any implementation language (WSRP).
This has gone much longer than I intended and I need to save some words for other posts :) In summary I'd just like to reiterate that "Composite Applications for People" involves UI integration "on the glass" and a separation of the roles and skills between component creation and component assembly.
In upcoming posts we'll talk about some new features in WebSphere Portal 6.0 that add templates and application instances to the previous composition model, what we mean when we talk about business components and some business component patterns for "by-reference" and "by-value" component instances. We'll also talk more about the importance of the different levels of context, remote portlets, WSRP and rich client projection in Lotus Expeditor.
Thanks for reading,