Where are the composite app standards?

In reading about composite applications, I was surprised to see how little work in terms of open source and open standards is being done in this area. I found the following standards:

• XForms for web based forms
• BPEL for orchestration
  
• WS-CAF from OASIS has only released one part of 3 planned standards.
  
• and of course the whole raft of web services standards
  

Missing are standards for:

• Screen flow, i.e. controlling the order of screens presented to the user.
• Work flow in terms of transferring work between people (the so called BPEL4People standard has yet to be published and maybe is not what we want.
• Screen layout.
• Packing all the bits of a composite app together so that it can be shipped (similar to web apps today).
  

All this is available in propriety products, which makes me surprised to find that nobody is working on standards in this area and even more surprised that nobody is working on an open source version of a composite application framework.

Will the real composite app please stand up

In trying to get to grips with what is meant by a composite application I came across this blog entry from Jeff Calow of IBM. He writes that the usual definitions of composite applications all deal with automation, but then asks about the user interface aspects. I would like to extend this and assert that a composite application consists of three optional aspects:

• A user interface which brings together in one place everything the user needs to carry out a task. This could be a portal or a scripted front end as found in many mashups . Rich clients are another possibility.
  
• A business process execution environment that not only handles the automation of processes, but also deals with user centric aspects such as workflow and screenflow.
  
• An integration infrastructure that allows data to be transformed from one format to another.
  

IMHO any self respecting composite application framework should support all three aspects.

More on BPM and OO

Keith Harrison-Broninski starts to ask in his blog why process modelling is based on a series of activities rather than business objects. He believes that we need an additional object based modelling layer for high level objects and their interactions.

I’ve tried to show in a previous post that BPM and object orientation are, at a deep level, conceptually similar. Rather than yet another layer which represents yet another set of concepts, we really need a unified model which lets modellers (and the underlying software) do what the business wants without having to constantly bamboozle them with different representations.

Reuse and SOA

In the last week I have heard and read the usual lament that software reuse is hard and has been a dismal failure. As many claim that the main value preposition for SOA is based on reuse, the argument is that it also will be a dismal failure.

Here I have to take a heretical POV and contend that software reuse is maybe hard, but that it exists, has been an enormous success and forms the mainstay of software development today.

Let’s look at UIs. Nobody would develop a UI today without a set of reusable components. What about basic programming. One only needs to look at how rich and extensive the J2EE or .NET class libraries are and how much their (re)use is part of standard software development practices is to see that reusability is the norm rather than the exception.

But what about the bit in the middle, the so called business logic? The enormous success of ERP companies such as SAP is surely adequate proof that reusable business logic is a reality.

The only thing that stands out here is that reusable components are not developed in-house by IT-Shops (as David Chappell pointed out when he asked about in-house reuse programs), but are developed by vendors who:

a) invest heavily into their products and

b) have an industry wide view point instead of a restricted company view point.

Perhaps this is clear indicator to where we can expect the majority of reusable business services to come from.

Difference between OO and BPM Part II - Inheritance

I tried to show in a previous post that the difference between the brave new world of BPM and the old traditional world of object orientation is really not so different. I left off wondering about inheritance and how that manifests itself in the BPM world.

Now every OO programmer knows what inheritance is. Or do they? It seems that inheritance is a slippery concept. Way back in 1996, Bertrand Meyer (the inventor of Eiffel) published an article in IEEE Computer in which he listed 12 different types of inheritance. It's no wonder that the usual advice given to an OO developer is to keep the inheritance hierarchy shallow – if you don’t, you’ll get swallowed up in the complexity.

Judging by the amount of academic papers written on this theme, it seems that process inheritance is also a complex topic. One which caught my eye, was a paper by Guangxin Yang as part of his Ph.D.. In it, he models process as a set of activities, each of which can trigger events which, in turn, cause messages to flow to other activities. In this way he can allow inherited processes to add new activities, add events, enable/disable triggers and also to change the semantics of the activities so they fit more closely to the business requirements. Although these seem to be powerful ideas, Yang’s paper doesn’t seem to have attracted much attention, only getting 2 citations according to Google Scholar.

So far, process inheritance does not seem to have reached commercial products, although this would seem to be a very useful feature to have. For instance, a typical business process could be defined and customer specific extensions could then be made to the inherited process in the same way that specific features are added to inherited classes in the OO paradigm. Some readers may recognise this. It is how most ERP systems are implemented today, only the “inheritance” mechanism is implemented by programming user exits and/or adding new customer build activities. The disadvantage here is that these changes are specific and propriety to the ERP system being implemented. If we want to implement processes over a heterogeneous environment (i.e. a lot of different applications or over the web) then inheriting from a process running in an external process engine would be an obvious solution. And with the rise of web services, composite apps a.k.a mashups, it wouldn’t surprise me if we start to see inheritance mechanisms creeping into the feature sets of process engine vendors.

Speeding up SOAP requests in a SOA

In a previous post I mentioned how efforts are under way to inprove the speed of XML processing. Another approach is taken in this article I came across in which the author shows how SOAP requests in a SOA can be cached in a middle tier.

My very own homepage

I finally got around to creating my own home page. It is extremely simplistic, but still does not reach the minimalist heights demonstrated by this web site.

I was keen to write the HTML by hand, so I have been using SelfHTML which is an excellent web based and downloadable guide to HTML. An English version doesn’t exist as yet, but they’re looking for volunteers to do the translation.

Update: Reread this old blog post and clicked on the minimalist web page link (actually from Creative Artists Agency). Previously this was was just the equivalent of a business card - company name and contact details. It's now been updated with a more dynamic javascript enabled interface. Only it doesn't do much more than before.

I guess their message is very simple - You have to talk to us.

What is the difference between OO and BPM?

The answer is … none!

I know that this is a heretical viewpoint, BPM (and in particular the use of a process engine or BPMS) being regarded as the next great step. I’m not disputing that, I just saying that at a fundamental level OO and BPM are just the same.

To justify my viewpoint lets take at look at what was regarded as OO when people were first thinking about it (Xerox PARC and all that). Objects were considered as things which had the following properties:

1. Each object could receive messages and change their internal state accordingly.
2. Each object could send messages to collaborating objects
3. Many instances of an object could exist at the same time, each having their own state.Objects could inherit parts of their behavior from other objects.

It was a lovely idea, but over the years it just got more and more watered down due to limitations in how technology could support it, market forces and misunderstanding. Look at message transfer between objects. This became nothing more than a (synchronous) procedure call. Look at the idea of state. If more than one user is involved then our objects have to be “stateless” if we want to achieve anything like a decent response time. Inheritance became something to treat very carefully if we want to avoid building brittle, difficult to change, programs. Over time, objects degenerated more and more into simple data objects and the functionality happened someplace else, in modules which had names such as “session beans”.

What about BPM? The BPM paradigm talks about processes, and each process has the following properties:

1. A process can receive messages and change their internal state accordingly. For example, a user can fill in a credit application and sent this (as a message) to the credit acceptance process. The process changes its state to reflect that the credit application has been received.
2. A process can send messages to collaborating processes. Continuing with the following example, the process now sends a message to another process, which checks the credit worthiness of the applicant.
3. Many process instances can exists at the same time, each having their own state, e.g. different credit applications.

Replace process with object and you get the point.

But, I hear you say, an important part of the OO paradigm is inheritance. Where is that in the BPM paradigm? Currently, the idea of process inheritance does seem to be getting much attention, but does that mean it that it is an idea without value?

That is something that I’d like to explore in a later entry.

AJAX goes mainstream

It seems that AJAX is finally making it to mainstream (in the sense that traditional IT is starting to see its potential). Integration product vendors are starting to provide tools - see, for instance, the TIBCO General Interface - and even Microsoft are getting into the act with the Atlas project.

Design Pattern Books

After a long hiatus due to project and personal commitments, I thought I should start posting here again.

I was asked today, do I know any good books on patterns. So, for future reference, here is my list, stating off with the classic:

Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series)
by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Patterns of Enterprise Application Architecture
by Martin Fowler

Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions
by Gregor Hohpe, Bobby Woolf

Pattern-Oriented Software Architecture, Volume 1: A System of Patterns
by Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, Peter Sommerlad, Michael Stal

Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects
by Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann

Analysis Patterns : Reusable Object Models (Addison-Wesley Object Technology: Addison-Wesley Object Technology Series)
by Martin Fowler