WSPER quietly, then go away

Found an interesting initiative called WSPER ("whisper") at https://www.wsper.org/ 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.

Comments

• Anonymous
  September 10, 2007
  PingBack from http://msdnrss.thecoderblogs.com/2007/09/11/wsper-quietly-then-go-away/

• Anonymous
  September 11, 2007
  Nick: thanks for taking the time to read the primer. First and foremost, wsper is a work that is starting, I can't even claim that it is in progress. But it's progressing. I just finished a book on the rationale for wsper, it will be available for download (for free) shortly on InfoQ.com I am not surprised at the bashing, Wsper makes a certain number of arguments that I am not sure you have caught: a) the SOA programming model is ill defined. It seems that you got that one, but then you say: "Between SCA and BPEL4people, there's not much need for an abstraction here." Do you really mean that statement? Do people agree with that statement? you want to implement a service today, what are your choices? C#, Java? is that all you need? You are not even mentioning BPEL? Even if you through BPEL in the mix, do you really believe that people are suited with the best implementation languages to implement their service? (Is Microsoft going to join and support SCA?) I don't claim of having the programming model right. This is just a primer to explain that there is indeed a programming model in SO and that model is not OO. Do you at least agree that an assembly mechanism is essential to SO? b) the most important point made by wsper is that it is an abstract framework, this means that it aims at enabling you to write your business logic, in abstraction from existing products and standards. It looks at the SOA standard stack (including SCA) as being the byte code level of SOA. There is tremendous value for an organization to abstract your business logic from a rapidly evolving set of standards and products. Not to mention that most SOA infrastructures (your SOA VM) are a mashup of (disparate) technologies. wsper allows you to embed best practices in schema design, interface design, naming conventions, policies, versioning ... below the abstraction. You don't have to teach your developers how to design a schema. This is very different from the way WCF is trying to solve the problem. WCF starts in OO and ends in OO. I don't see much SO there. WCF is about giving interop capability to .Net, not to offer a SO programming model. There was just a little oversight in the process, contract-first. Yes, it is kind of needed for interop. This is why contract-first was added after the fact, and not even by the WCF team, by the Pattern & Practices (PP) team. wsper is at the same level of PP, but with an overarching abstraction for SOA. So saying that you don't need wsper because you have everything, is like saying you don't need PP to do things that WCF was never designed for and will never bother implementing. c) wsper is an attempt to bridge the declarative and imperative style. There is a continuum there, not a dichotomy. The OO world has imposed an iron curtain on the programming model evolution. wsper is above and beyond about smashing the curtain (not OO) and enabling reasonable evolutions of the programming model with the needs of the developer. Cheers, JJ-

• Anonymous
  September 12, 2007
  Hello JJ, I believe that the existing languages have a difficult time providing the extra guidance that we may want to provide to allow services to be developed in a consistent fashion.  However, in the world of service developers and service consumers, service developers have it easy.  There is little need to develop an abstraction for them.   Service consumers could use an abstraction.  I think you are right about that.  However, I think wsper missed the use case completely with respect to service consumers.   By the way: BPEL4People is a superset of BPEL.  So, yes, I did mention BPEL.   Also, I believe that SCA is a good idea.  It is not, however, the only way to answer the problem that it attempts to answer.  That's all I will say for now. Schema-first design is a requirement of enterprise SOA.  We completely agree.  However, regardless of it's origins, it is in there.   As far as bridging the declarative and imperative style... is that needed?   Look, my problem is that there is a vision for what is supposed to happen next, and WSPER doesn't align with that vision.  That is the vision of composability.  This language adds very little of the things that are needed, at a time when we need those things more than ever. Sorry, JJ.  I don't see anything worth endorsing at this time.  That doesn't mean that your work is not interesting.  With refinement and adoption of standards, I'm sure that it could grow to fill the space it has jumped in to.  But the current version, as described in the primer, is lacking.

• Anonymous
  September 12, 2007
  fair enough, BTW my e-book is called "Composite Software Construction" and deals with "composability" at length. It was not my understanding that BPEL4PEOPLE included BPEL, but I'll check. So many spec came out this year, it's hard to keep track of all of them in detail. JJ-

• Anonymous
  September 12, 2007
  Hi JJ, I retain the right to be completely wrong.  If BPEL4People is not a superset of BPEL, then I retract my prior statement and accept the criticism that I should have mentioned BPEL as well. I, too, have a difficult time keeping up with all the changes in the standards.  ;-) --- Nick

• Anonymous
  September 12, 2007
  Nick: the official phrasing is "BPEL4People extends the capabilities of WS-BPEL to support a broad range of human interaction patterns, allowing for expanded modeling of business processes within the WS-BPEL language" which I can interpret as BPEL is embedded in BPEL4People. Actually, the point I would like to make is that I am not sure composability is achieved as much by BPEL4People as it is by BPEL+SCA. BPEL-like languages are the one really enabling composability and SCA-like capability is the keystone of achieving composability. It is on my task list to construct the metamodels of all these specs to see it a bit clearly. I will publish them (sorry in UML, I have tried to use the .net modeling tool in visual studio but seems to have limited expressivity). The "People" extensions have little (anything?) to do with composability. It is unfortunate that this whole mess was created around "business process" since BPEL alone does not support meaningful business processes (needs the extensions). This has generated one more lost opportunity to create a true Service Oriented Programming language (which could have been BPEL). At the end of the day BPEL is not a real programming "language" and has nothing to do with BP. Fortunately you can "E"xecute it.  

• Anonymous
  September 12, 2007
  Hi JJ, Don't get me wrong.  Things that handle the ability to distribute a service, on demand, are important to composability "in the wild."  SCA does this.  Other things do too.  (I won't say more at this time). I like UML.  'nuff said.   I also agree that BPEL is an odd language for describing business processes, because it doesn't describe business processes.  It describes orchestration.  Business Processes are better described by other mechanisms.   (I ran into this just yesterday.  I'm a bit frustrated by having to explain that to people.) Please continue with your work.  You may win me over yet.  I like your thinking... just not convinced of the scope.

• Anonymous
  September 12, 2007
  Cool ! thanks. It's time to look forward.