FeedBot
03-01-2006, 23:15
I wish I knew why people say that BPEL is central to an SOA. They really shouldn't. The idea is flawed for several reasons.
To set context, let's think about run-of-the-mill browser-based applications.
Consider: In a Web-based application, state is maintained in application logic. It's not managed natively in the server calls. You don't maintain state in HTTP POSTs and GETs, because if you did you'd have a heck of a time managing browser sessions, session drops, sudden server outages, and so on. Mechanisms for Web interactions (e.g., POST, GET, etc.) are distinct from mechanisms for state management in the application (e.g., cookies, hidden form values, URL encoding).
In short, a stateless interaction model is key to robust Web applications. Applications maintain state, and services do not.
But BPEL manages stateful business processes. An SOA doesn't need that. Web services provide a stateless interaction model -- as well they should, for the same reasons that Web applications in general provide a stateless interaction model. If you're maintaining state in your services, you're accidentally building an application where a service should be.
Also, BPEL mainly consumes Web services. Yes, some have extensions for Java and the like, but that still leaves a substantial portion of an enterprise's interfaces inaccessible to BPEL. It's a mistake to make something central to SOA when it can only handle a fraction of the IT systems that the services will be created from.
Finally, BPEL mainly provides reuse through Web services. Unfortunately, that renders its services unusable for secure B2B. It also can't plug into all the legacy integration brokers, portals, etc., that still need to be maintained. If you can't use a service in the tool you're using in a project, then you can't reuse it there either -- and there goes one of the primary benefits of SOA.
Don't get me wrong: I think BPEL is a fine technology for building applications. (That's why my company has a BPEL engine (http://www.iwaysoftware.com/products/bpm.html).)
But I think it's a real mistake to use it as the core of your SOA. It requires strict standards adherence whereas the SOA needs the flexibility to plug into many different asset types, and its capability to maintain state doesn't matter in a stateless service model. In short, its strengths are irrelevant to SOA per se, and it's weak where SOA infrastructure needs to be strong.
So BPEL is yet another thing about which you shouldn't believe the hype. The hype could be positively dangerous. Where you should be creating services, a BPEL engine is likely to have you accidentally writing applications instead.
Jake Freivald
Vice President
iWay Software (http://www.iwaysoftware.com)
Link To Original Article (http://www.integrationconsortium.org/icblog/?postid=113)
To set context, let's think about run-of-the-mill browser-based applications.
Consider: In a Web-based application, state is maintained in application logic. It's not managed natively in the server calls. You don't maintain state in HTTP POSTs and GETs, because if you did you'd have a heck of a time managing browser sessions, session drops, sudden server outages, and so on. Mechanisms for Web interactions (e.g., POST, GET, etc.) are distinct from mechanisms for state management in the application (e.g., cookies, hidden form values, URL encoding).
In short, a stateless interaction model is key to robust Web applications. Applications maintain state, and services do not.
But BPEL manages stateful business processes. An SOA doesn't need that. Web services provide a stateless interaction model -- as well they should, for the same reasons that Web applications in general provide a stateless interaction model. If you're maintaining state in your services, you're accidentally building an application where a service should be.
Also, BPEL mainly consumes Web services. Yes, some have extensions for Java and the like, but that still leaves a substantial portion of an enterprise's interfaces inaccessible to BPEL. It's a mistake to make something central to SOA when it can only handle a fraction of the IT systems that the services will be created from.
Finally, BPEL mainly provides reuse through Web services. Unfortunately, that renders its services unusable for secure B2B. It also can't plug into all the legacy integration brokers, portals, etc., that still need to be maintained. If you can't use a service in the tool you're using in a project, then you can't reuse it there either -- and there goes one of the primary benefits of SOA.
Don't get me wrong: I think BPEL is a fine technology for building applications. (That's why my company has a BPEL engine (http://www.iwaysoftware.com/products/bpm.html).)
But I think it's a real mistake to use it as the core of your SOA. It requires strict standards adherence whereas the SOA needs the flexibility to plug into many different asset types, and its capability to maintain state doesn't matter in a stateless service model. In short, its strengths are irrelevant to SOA per se, and it's weak where SOA infrastructure needs to be strong.
So BPEL is yet another thing about which you shouldn't believe the hype. The hype could be positively dangerous. Where you should be creating services, a BPEL engine is likely to have you accidentally writing applications instead.
Jake Freivald
Vice President
iWay Software (http://www.iwaysoftware.com)
Link To Original Article (http://www.integrationconsortium.org/icblog/?postid=113)