 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA News > Co-evolution of BPMN and BPEL drives BPM in SOA settings |
| |
|
|
|
|
| SOA News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||||||||||||
While Business Process Execution Language (BPEL) has gotten a lot attention in the developer community, the Business Process Modeling Notation (BPMN) has grown in importance in the business community. Technologies built on both standards promise to simplify the communication between analysts and developers and the development of SOA applications. But challenges remain in translating business models built in BPMN into applications written in BPEL. The BPMN notation provides a set of standards for describing what the elements of an application look like. It has gained popularity as companies learn how to use it to enable business analysts to create applications. "The big surge in interest comes when the pretty picture not only helps me figure it out, but helps me build it," said Dan Sholler, Research Director at Gartner. "But no matter how good this becomes, I think people would be fooling themselves to assume that we will come to a time when you can draw a picture and have it run on a huge multi-vendor multi-technology kind of instance. There are still going to be a lot of dependencies here." For its part, the BPEL language was born as an off-shoot of the great Web services standards parade, and interest in BPEL tends much to reside on the developer side. There are concepts in BPMN that don't exist in BPEL. They were excluded from BPEL to make it easier to implement. The simplest one is loops. You can draw a BPMN process that loops back on itself. This is not allowed in BPEL. "We have this one notation language that shows us how to diagram a picture, and this other language that shows us how to invoke the steps in the process. What we don't have is a way of cleanly translating from one to another," noted Gartner's Sholler. "There is a generally accepted way of translating from BPMN to BPEL. The real difficulty is doing roundtrip engineering. I want to have the BPMN diagram be a direct and accurate representation of my process. I want every change in the BPMN diagram to be reflected in the execution of the process, and every change in the execution to be reflected in the BPMN diagram. That is difficult for a whole lot of technical reasons." History Sanjiva Weerawarana Chairman and CEO of WS02, who helped craft both standards said, "One of the visions of workflow is to bridge the gap between business and IT. The business person wants to do X, and then it takes two years to get expressed and implemented, which is what workflow is trying to solve. "BPEL was not intended to be that kind of bridge," said Weerawarana. "It was always clearly designed as an executable language. We never had any intention that a non-technical person would write BPEL. If we had realized how valuable it was while doing BPEL, we would have created a visual notation language," said Weerawarana. "We did not do that, and it was a big miss. There was an underestimation of the importance for visual notation for workflows." BPMN emerged from the need to model the process. It was essentially a standard for visual notation. BPMN is a higher level abstraction for giving business persons the tools they need, and BPEL is the lower level abstraction - how you execute the plan. Roundtripping BPMN and BPEL Rowley explained, "There is a huge amount of effort that goes into taking that basic control flow and taking it into something that can execute. When you put that much effort into something you don't want to be locked in. The main problem is in data. Data manipulation is completely outside of the standards of BPMN, and yet it is a huge aspect of what you do when you are trying to get this to execute." It is also important to be able to convert finished BPEL code into a diagram the business person can understand. Engineers, versed in exceptions, often locate workflow incidents that the business people may overlook. Rowley said, "The engineer might have thought of execution cases, like what if the services are down or the person doing the work has been fired. They might flesh it out in a way that is different from the diagram. Then they can show the business person. This promotes collaboration between the developer and the business analyst." Marlon Dumas, Professor of Software Engineering, Institute of Computer Science, University of Tartu said, "BPMN to BPEL roundtripping does not come for free. There are licensing costs. There are setup costs. There are training costs. There is additional development effort to keep things synchronized. So the payoff has to be tangible. For example, if BPMN-to-BPEL round-tripping allowed companies to avoid vendor lock-in, maybe this could be a payoff. But I have yet to see vendors keen in moving towards interoperability. Even interoperability between BPMN tools or between BPEL tools is problematic." Two sides to the BPM story He noted, "BPMN is here to stay for a long time. At the very least, BPMN will remain used in the business analyst community. BPMN has already replaced flowcharts, IDEF and Event-driven Process Chains in many large organizations that conduct process re-design projects." He questions whether BPEL's adoption by vendors will lead to broad adoption by users. Weerawarana sees a bright future for BPEL, as most vendors in the industry now support it. Meanwhile, he says BPMN will continue to grow in the business analyst space. He thinks that both standards will continue to grow because they are addressing valuable components of automatic business execution. "This is not a question of two competing standards fighting for control," said Gartner's Sholler. "This is a question of two good ideas tackling parts of the problem, neither of which is concise or consistent." Read our new BPEL tutorial.
|
|
|
|
|||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
