昨天和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 deals explicitly with the functional aspects of business processes:
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://sourceforge.net/projects/wf-twister/
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/
总之，我觉得，首先有必要对业务流程进行明确的区分和定义，什么样的案例才算是业务过程适用的？
继续思考中。。。
|