I've been playing with a BPEL concept that I'd like to share... I'm calling it 'service hijacking'. It goes like this:
Some company releases a web service; for example, Amazon. This web service has a wsdl describing all of the operations and messages. The wsdl is published in a public directory for consumption.
Some other company, "OnlineBooks", decides to launch a marketplace for book shopping. So they create a BPEL service that front-ends the Amazon service, but adds calls to "Barnes & Noble" and a few others. Perhaps they even kept their wsdl the same as the original Amazon wsdl in order to allow the 'consumers' to easily switch over. At this point, we have added new value to the consumer, so all is good.
Then, some other company, "MarketResearchBooks", launches a new service to front-end the "OnlineBooks" service. They support all of the same features, but also keep records of who had the lowest price and then sell that information back to the original retailer. And yes, to the best extent possible, they kept their wsdl looking like the original WSDL Amazon wsdl. At this point, we didn't *really* add new value to the consumer, but we didn't take any value away.
Then, another company, "OnlineSuckers", launches a service to front-end the "MarketResearchBooks". It adds no new value, but asks people to pay for the service on a per-use basis. Now, we have a problem. The value of the service went down, not up.
Making information available online in a structured format for public consumption is a tricky proposition. In some cases, you don't care what people do with your information, while in other cases (OnlineSuckers), you might care. In my opinion, a service is hijacked when the value of the service goes down (rather than up) from the re-purposing of the call.
The earlier examples ("Online Books" and "MarketResearchBooks") are what I call either 'service piping' or 'service chaining'. These are good things. They take information and add or maintain the same level of value. Of course, there is a different technical argument to be made against long chains of services, but I'll save that for another day.
---- after thought----
It just hit me that if you don't write BPEL scripts everday, you might be wondering what this concept has to do with BPEL. Yes, service hijacking can be accomplished through your favorite programming language (java, c#, etc.) However, BPEL facilitates this functionality with VERY little effort. With the OpenStorm suite, I can service chain Amazon in under a minute, add marketing statistics in a couple of minutes and hijack on a payment service in under a minute. I guess my point is that BPEL makes this stuff very easy to do.