The last piece of the process integration puzzle, looking at the UI part

Process integration is a subject that always comes back when you're defining a Software Architecture. There are different types of of Process integration, based upon integration partners involved, integration types, amount of users involved, connection type, length of the process etc. In the past loads of books have been written about process integration and a lot of patterns have been defined.
When looking at the Application to Application (A2A) and Human to Application (H2A) type of processes cross technology solutions have been defined in an XML type of language BPEL. BPEL is the conductor of a process and does call-outs to functionality by means of Web services and adapters to legacy systems.
The ease of functionality that BPEL offers for process integration however is not very usefull for a UI type of process like a close-out sequence of a book ordering process on the Web. These are typically hard-wired within UI frameworks, like in Java we do (or used to) in Struts or JSF. In these solutions there is no flexibity or reuse. Rearranging a UI process requires rework and redeployment, and on avarage there's not so much reuse of UI process components. When looking at a SOA perspective, you'd like to reuse (groups of) pages and handle them as services in order to create composite applications.
There is some movement in this market. Oracle came up in de Fusion Middleware 11 version with a UI Taskflow mechanism.
The basis for the Oracle Solution is Java Server Faces, or JSF, and is called ADF Taskflows. Components in these Taskflows are complete pages (JSF), page fragments (parts of JSF), Java call-outs and the most important one, the Taskflow definition. This Taskflow definition resembles the BPEL type of working, and is conductor using for handling a process from a UI perspective. It uses a plain XML file referencing all the needed components, or services.
Two types of Taskflow exist, the unbounded and the bounded taskflows.
Unbounded taskflows are just a predefined set of pages used to complete a task, this taskflow can be entered from all pages within the taskflow.
The Bounded taskflow acts more like a Service, only entry one entry point exists and zero or more exit points which can result in an output result. The inner behavior is 'private' and cannot be changed or interfered by the outside world.
Bounded taskflows are the most neat ones, I've been searching for these for quite some time now. Finally the possibility to reuse a group of pages within a new composite.
I hope the market picks up this initiative and creates a cross technology integration language for UI based process integration, just like we have now with BPEL.
For more information see

Oracle Application Development Framework ADF

Fusion Developer's Guide for Oracle, Part III Creating ADF Task Flows

Nice example pages

Aim for Stability Based Architecture (SBA)

Software Architecture is the art of translating Business needs into a suitable and working technical solution.
The same as in architecting and creating houses our sponsor expects that the product will be stable and last for quiete a time. Looking back in time we see that at the time of Cobol, applications were able to last more then 20 years (and even now exist, even after the retirement of their creators). But with the speed of new developments and the coming of hype driven development the application lifespan (or time that it gets outdated), is getting less and less. Java, among others, has got a bad reputation in this area, for instance Struts lasted some 2 to 3 years, after which you were the laugh of the year when you decided to choose Struts in your solution. SOA is another example, finally it paid of working with it, when somebody decided that SOA is dead and we have to run after the latest hype, Cloud computing. The half-time of a Software Architecture is getting shorter and shorter, and it happens too often that at the time of go-live we almost have to think about upgrading, because the version is almost outdated.
I'd like to propose a new architecture type, Stability Based Architecture (SBA), in which we aim for stable (core of the) application and add an expected life-time of the application. The core of the application should be stable and last for a long time, just like rock under pressure, it folds but doesn't break. Only then can we justify the costs of implementation.