Sometimes the answers to simple questions are profound.
I have been asking myself a couple of very simple questions for some time now, and although I initially didn't want to accept some of the answers I got, I guess I can't avoid their implications.
What is SOAP? I'm deliberately not looking at any of the SOAP spec documents for the answer. I want to know the value proposition of SOAP.
Similarly, what is BPEL (or WS-BPEL, if you prefer)?
I can think of two quick answers:
1. The value proposition of SOAP is interoperability.
2. The value proposition of BPEL is portability.
To my mind, interoperability is at least an order of magnitude more important than portability.
SOAP is the "wire protocol" in one view of SOA. Within the "cloud" or "SOA Fabric", the only things one sees are SOAP messages flying past. Nobody sees BPEL within the SOA cloud. BPEL is an implementation language for the execution of processes, just like Java is an implementation language for general-purpose business logic. It runs on a node. All interactions between that node and others are through SOAP messages. A BPEL process consumes SOAP-based services and in turn exposes itself as a SOAP service.
So is BPEL really all that important in the scheme of things? Wouldn't any other portable language do? I think I've stumbled upon a candidate language, and it's not Java.
Lately, I've been playing around with the WSO2 Mashup Server, and I'm increasingly getting the excited feeling of a kid who's somehow come into possession of a machine-gun. This is not a toy, folks. Are the adults aware of what this thing can do?
Most people seem to think mashups are a cute visual gimmick. The WSO2 guys themselves don't have the air of people handing out machine-guns. The examples they bundle with the server are classic mashup fare - TomatoTube, in which you take the top-rated movies from Rotten Tomatoes and mash the list up with trailers from YouTube, enabling you to see the trailers of top-rated movies. Very cute and harmless.
But now for the machine-gun bit. The development language offered by Mashup Server is JavaScript (think general-purpose programming language). JavaScript augmented by E4X (think really easy XML manipulation). Mashup Server hides SOAP very effectively, although its interfaces to the outside world are SOAP (SOAP 1.1 and 1.2, also REST/HTTP, but more about that later). SOAP is out there in the cloud. But here, within this processing node, it's just XML representations of data and JavaScript code to process it with, thanks to the why-didn't-I-think-of-it simplicity of E4X. Surely we can do more than mashups with that kind of power...
I've found myself thinking a disturbing thought: If no one sees BPEL in the forest, then does it really exist? What if BPMN-based process modelling tools spat out E4X-enhanced JavaScript code instead of BPEL? Would anyone know or care? Take the output of the modelling tool and drop the file onto a server. The process is ready to run. All external interfaces are SOAP-based, just like with a BPEL implementation. Got any problems with that?
There's more revolutionary potential here than in the Communist Manifesto. Another of the cutesy examples bundled with Mashup Server is a REST service. You can do HTTP GETs, PUTs, POSTs and DELETEs on a simple city resource to manipulate its weather data. Very harmless, but again, the developer has very simple JavaScript-based access to REST services.
So is the WSO2 Mashup Server the one that will bring balance to the Force? A powerful programming language. Laughably easy XML manipulation. Simple access to SOAP services and REST resources. Transparent publication of itself as a service or resource in turn. Isn't this the holy grail of service composition?
Content management, process orchestration, what's in a name? I'm beginning to think BPEL is dead. Its value proposition doesn't stack up anymore. SOAP still makes sense, but not BPEL.
WSO2 Mashup Server seems to be the industry's best-kept secret for now. Keep the safety catch on, and watch where you point that thing.
I have been asking myself a couple of very simple questions for some time now, and although I initially didn't want to accept some of the answers I got, I guess I can't avoid their implications.
What is SOAP? I'm deliberately not looking at any of the SOAP spec documents for the answer. I want to know the value proposition of SOAP.
Similarly, what is BPEL (or WS-BPEL, if you prefer)?
I can think of two quick answers:
1. The value proposition of SOAP is interoperability.
2. The value proposition of BPEL is portability.
To my mind, interoperability is at least an order of magnitude more important than portability.
SOAP is the "wire protocol" in one view of SOA. Within the "cloud" or "SOA Fabric", the only things one sees are SOAP messages flying past. Nobody sees BPEL within the SOA cloud. BPEL is an implementation language for the execution of processes, just like Java is an implementation language for general-purpose business logic. It runs on a node. All interactions between that node and others are through SOAP messages. A BPEL process consumes SOAP-based services and in turn exposes itself as a SOAP service.
So is BPEL really all that important in the scheme of things? Wouldn't any other portable language do? I think I've stumbled upon a candidate language, and it's not Java.
Lately, I've been playing around with the WSO2 Mashup Server, and I'm increasingly getting the excited feeling of a kid who's somehow come into possession of a machine-gun. This is not a toy, folks. Are the adults aware of what this thing can do?
Most people seem to think mashups are a cute visual gimmick. The WSO2 guys themselves don't have the air of people handing out machine-guns. The examples they bundle with the server are classic mashup fare - TomatoTube, in which you take the top-rated movies from Rotten Tomatoes and mash the list up with trailers from YouTube, enabling you to see the trailers of top-rated movies. Very cute and harmless.
But now for the machine-gun bit. The development language offered by Mashup Server is JavaScript (think general-purpose programming language). JavaScript augmented by E4X (think really easy XML manipulation). Mashup Server hides SOAP very effectively, although its interfaces to the outside world are SOAP (SOAP 1.1 and 1.2, also REST/HTTP, but more about that later). SOAP is out there in the cloud. But here, within this processing node, it's just XML representations of data and JavaScript code to process it with, thanks to the why-didn't-I-think-of-it simplicity of E4X. Surely we can do more than mashups with that kind of power...
I've found myself thinking a disturbing thought: If no one sees BPEL in the forest, then does it really exist? What if BPMN-based process modelling tools spat out E4X-enhanced JavaScript code instead of BPEL? Would anyone know or care? Take the output of the modelling tool and drop the file onto a server. The process is ready to run. All external interfaces are SOAP-based, just like with a BPEL implementation. Got any problems with that?
There's more revolutionary potential here than in the Communist Manifesto. Another of the cutesy examples bundled with Mashup Server is a REST service. You can do HTTP GETs, PUTs, POSTs and DELETEs on a simple city resource to manipulate its weather data. Very harmless, but again, the developer has very simple JavaScript-based access to REST services.
So is the WSO2 Mashup Server the one that will bring balance to the Force? A powerful programming language. Laughably easy XML manipulation. Simple access to SOAP services and REST resources. Transparent publication of itself as a service or resource in turn. Isn't this the holy grail of service composition?
Content management, process orchestration, what's in a name? I'm beginning to think BPEL is dead. Its value proposition doesn't stack up anymore. SOAP still makes sense, but not BPEL.
WSO2 Mashup Server seems to be the industry's best-kept secret for now. Keep the safety catch on, and watch where you point that thing.
4 comments:
You need to sign up to the Apache ODE list if you haven't already.
There is some innovative work happening there on SimPEL that you might want to have a look at.
BPEL may deserve a death, but like JSF, it won't die easily. There is too much tooling and runtime investment by vendors for it to be wiped out in the next two years.
The ODE approach is to create a meta-language that let's developers express Processes without typing tag-intensive XML and then translate it into BPEL for engines to execute.
BPEL's value proposition used to be Portability. But the reality is that most BPEL engines add considerable "extensions" that the customer inevitably invokes resulting in lock-in.
I hope WS02 server doesn't get too good because it will get acquired by IBM and be "Blue Washed"!
Cheers,
Zubin Wadia
CTO
www.imagework.com
Ganesh:
I don't know if you got some time to take a look at WSPER (http://www.wsper.org). WSPER contains a programming language that can be compiled in BPEL that is resource oriented.
The irony is that I don't think I can create an implementation of WSPER based on REST alone, but seem to work fine with WS-* (including SCA, SDO and BPEL).
I don't know why you want to kill BPEL. Nobody has ever said you had to code in "XML" and surely enough something like SimPEL provides no value add to it.
JJ-
JJ,
Thanks, wsper is definitely on my to-read list. (So much to do!)
I'm not trying to kill BPEL. I'm wondering aloud if BPEL is required in its present form. In other words, if BPEL did not exist, would it be necessary to invent it (in its present form)?
I can see that something like a SOAP message would need to be invented if it didn't exist (a mechanism to transport XML payloads and also specify quality of service), but what about BPEL?
Should we instead view BPEL like XML Infoset, an abstract notation that can be translated into any physical execution language depending on the vendor implementation?
These are questions, not opinions.
Ganesh:
well this is a tough question. It is like asking if Java or C# did not exist today, would we need to invent it?
I have fought the battle several years ago that BPEL was a "programming language" and had nothing to do in the Business Process Space. I fought this battle against people like Assaf Arkin, Frank Layman or Howard Smith, or even Edwin K. I won. It is commonly agreed today that BPEL is a language. Some people are still confused about how to use it, but this is a big progress compared to 5 years ago.
For me, if we did not have it, we would need something like BPEL (I don't want to say something exactly like BPEL, but I can live with it).
The major change between BPEL and Java/C# is that BPEL is a language where the message is a primary citizen along data and control structures.
For me "Remoting" has failed and will always fail. REST is successful at what it does because it assumes an application model and creates the middleware around it. The remoting guys have simply "remoted" the classical single threaded application model.
We need to move from a "remoting" mindset to an "inter-action" mindset. We need to define the most basic application model for composite information systems and then build the middleware around it (hopefully it is an extension of REST). This is exactly what I am trying to do with WSPER, I created a technology neutral, resource-centric, programming model and I am mapping it to WS-* (including SCA) as an inter-action focused middelware (not as a remoting middleware).
Anyways, if you read the wsper primer or my book, this should be a bit clearer.
BTW, we think a lot alike, we actually have very similar roles in life.
Cheers,
JJ-
Post a Comment