昨天和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/
总之,我觉得,首先有必要对业务流程进行明确的区分和定义,什么样的案例才算是业务过程适用的?
继续思考中。。。