Found an interesting initiative called WSPER (“whisper”) at that aims to define a formal syntax for defining composable SOA applications.  Reading the primer is a bit like an acid trip… lots of colors, not much meaning.

Now, to be fair, it is difficult to tell very much from a primer that basically contains a list of metamodels and describes the nature of metamodeling.  How fun is that?  My concern is that the language may be an unnecessary abstraction. 

I can create thousands of abstractions.  I can create abstractions layered within one another forever.  That’s the power of abstractions… but not all of them would be useful.

To make an abstraction useful, it has to seperate two areas of natural change.

An area of natural change is a concept that is not defined or is likely to change.  For example, if we talk about all types of cars, then the entire list of models of cars will change.  Manufacturers release new models every year.  We can also say that the features of a car can be seen as a list that changes.  This year, cars of satellite radio, something that you didn’t see on cars a few years ago.

So, if you want to describe the generic notion of a car, complete with features, you need to seperate the list of models from the list of model features.  You need an abstract ‘car’ that can hold information about models and information about features.  Each structure that defines an abstract ‘car’ can hold model information and feature information seperately.

What I cannot see, and this is with considerable thought about the problem space, are the ‘two things’ that WSPER is attempting to seperate.  Between SCA and BPEL4people, there’s not much need for an abstraction here. 

Of course, the WSPER primer is correct in pointing out that we need abstractions… that the SOA programming model is not well defined by existing elements.  However, the WSPER attempt at defining the ‘SOA spanning layer’ falls short of understanding the necessary seperation that must exist… that of a seperation between automatable tasks in a business process and concrete services.  In the middle we need abstract solutions. 

WSPER comes close, but then falls short.  There is too much overlap with workflow and process model standards (think BPEL4People) and not enough coverage of the user interaction elements that would live in a portal. 

Yes,we need something there.  But, from what I can tell by reading early documents, WSPER isn’t it.