|
|
| Service Oriented Enterprise |
|
|
Saturday, November 22, 2003 Service Hijacking 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. posted by jeff | 7:47 AM Friday, November 21, 2003 BPEL Validator :-) It might be time to get that BPEL Validator routine up and running.... just in case any company were to release a few BPEL extensions... :-) And congratulations on the release. posted by jeff | 5:51 PM Monday, November 17, 2003 Bean-counters to Join Programmers VentureWire had great news today. More accounting and finance jobs will be moved offshore!! It is clear that geeky American programmers have no idea on how to influence congress. Surely our accounting brothers can help out... ============================= Ephinay Raises $10M Series B By VentureWire Staff Reporters 11/17/2003 Charlotte, N.c.Ephinay, a finance and accounting business process outsourcing firm, said it received $10 million in Series B financing. [full story] http://www.ephinay.com ============================= Outsource Partners International Raises a Potential $20M in Series B By VentureWire Staff Reporters 11/17/2003 Outsource Partners International (OPI), a provider of finance and accounting outsourcing services, said it has raised $12 million in its Series B round. The round could potentially bring in $8 million more. [full story] http://www.opiglobal.com ============================= Two in one day!!! Kwe Kwe is going to get crowded!! posted by jeff | 6:40 AM Sunday, November 16, 2003 Junglemen Hex American Programmers In a rare move, the normally friendly tribesmen of the Zimbabwe jungle put a voodoo-like-hex on the American programmers working there. Frank, who was laid off from General Electric's I.T. department some time back explained, "After training my Indian replacement at G.E., I decided I was going to beat the game. If the trans-national corporations were only interested in low-cost labor, it was clear that I'd have to reduce my cost-of-living expenses. That's why our whole development team moved to the jungles of Zimbabwe."  "Unfortunately, we were found by the local tribesman. I don't fully understand their language, although it appears to be a blend of Morse-code and ASCII. From what I've gathered, they are concerned about too many U.S. programmers coming here." In an effort to remedy the concerns, Frank intends to meet with the local governing council. "I will explain to the council that we can put 'caps' on the number of American programmers that can come to the jungle - AND... they will be forced to leave after a certain number of years. In essence, we are pitching them a variation of the H1 and L1 programs!!!"  The city of Kwe Kwe, Zimbabwe is quickly becoming a technology hotbed. In addition to American programmers, recently displaced developers from Hyderabad, India are also flocking over. Amit Maheshwari explains, "Yes, we used to specialize in convincing American companies to come to India... now, we make our money selling the U.S. trans-nationals infrastructure to create wireless zones in the jungle. We have also tried to get them to subsidize the mosquito repellent, but so far haven't had any luck." posted by jeff | 7:14 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
