再看BPEL

昨天和MDA大牛飞哥谈了关于软件架构的问题。让我重新思考关于软件设计中架构设计的问题：即业务架构－大架构，代码设计－小架构的差别。

在软件设计中流程是第一位的。传统的基于UML的设计方法是面向领域模型的。而BPEL被成为是UML的替代者。我这里提到UML和BPEL不是指写文档的时侯的哪些图，关于文档是否用uml表示一定好，那是另一个话题了。我这里是是指最终软件基于的架构设计，到底是从模型开始，开始从架构开始，或者是两者结合？

紧接着就看到了这片文章http://today.java.net/pub/a/today/2006/02/14/separation-of-concerns-and-bpel.html

Separation of Concerns and BPEL, 文中的concern我理解应该是业务中某一个具体的关注点：例如选择日期是一个concern，选择旅馆是一个concern，这些concern通过BPEL组合起来。

John作了一个关于对象，组件，web服务的比较

http://weblogs.java.net/blog/johnreynolds/archive/2005/02/objects_compone.html

他提出BPEL应该使用纯service的方案，Java RMI, C#, Jini, etc。所以象BpelJ这样的项目没有什么意义。

BPEL和ESB一起来实现基于业务架构的设计。所有的服务停靠在ESB这个Hub上，BPEL进行统一协调。

这是一个大的思路，当然还需要很多BPEL的实践来告诉我们到底BPEL在何种程度上能减轻开发者的负担，以使软件架构更加灵活

当然，我们现在依然再寻找对需求的准确表述方式：什么是流程？什么是表单？是否流程加表单就是企业应用？用什么方法能把流程，表单的构件和传统的成熟技术结合？

我们来看看BPEL的定义：

BPEL functionality

BPEL deals explicitly with the functional aspects of business processes:

• control flow (branch, loop, parallel)
• asynchronous conversations and correlation
• non-determinism
• long-running, nested units of work, faults, and compensation

BPEL is NOT:

BPEL is not workflow: there are no explicit abstractions for people, roles, work items, or inboxes in BPEL (among other things).

BPEL is also not BPM: no specified data model for measurement, reporting, or management.

BPEL is not integration: there is no explicit support for transformation, semantic interpolation, or specific protocols.

BPEL is not all-encompassing: there are some patterns that are difficult to model with BPEL.

这里也说了BPEL也有很多不适合的模式

目前主要的开源BPEL引擎有

http://www.activebpel.org/

http://sourceforge.net/projects/wf-twister/

http://bonita.objectweb.org/

BPEL标准在这里

http://www-128.ibm.com/developerworks/library/specification/ws-bpel/

 

John在blog里面强调Process Driven Design the next big thing，他说他不喜欢UML，因为他的工作是收集用户需求和开发用户界面，他关注的是为过程编写文档，理解和实现业务过程。而UML主要是用来关注软件的组件的（这是John的话）

但是也有人通过扩展UML来实现BPEL

http://www-128.ibm.com/developerworks/webservices/library/ws-uml2bpel/

总之，我觉得，首先有必要对业务流程进行明确的区分和定义，什么样的案例才算是业务过程适用的？

继续思考中。。。