工作流资料合集

从SCA（Service Component Architecture） 看构件图形化软件组装的趋势

发布时间:2007年09月28日 作者:qhyou

---

阅读次数:6460次 类别:原创 永久链接 Trackback 5条评论

、 一、SCA的概念

SCA（Service Component Architecture）面向服务的组件模型，源于IBM 的WSIF （Web Service Invocation Framework，具体请参考http://ws.apache.org/wsif/），SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用（这一点与EOS的思路一致）。

服务组件模型（SCA）中提出了一些新的概念，比如服务组件，模块，共享库，导入和导出。

l服务组件

包括对外提供的接口，所依赖的接口。服务组件的接口类型可以是Java类型，也可以是WSDL定义。例如一个“客户服务”组件，可能包括“获得客户基本信息”、“获得客户帐单”、“新建客户”等接口。这些接口的实现可能是WSDL描述的，也可能是用Java类实现的。服务组件的实现对外是透明的，调用者无需知道该服务是如何实现，以及采用什么技术实现的。

l模块（Module）

模块是由多个服务组件以及服务之间的调用关系组成的，每个模块相当于J2EE应用中的一个项目。通过将不同的“服务组件”用连线组装起来，就成为一个模块。模块是最小的部署单元。

l共享库（Library）

如果多个Module需要共享一些资源，则可使用共享库。但是共享库不包括服务组件（即不包括业务逻辑），只包括数据定义、接口定义、数据映射等。

l导入（Import）

目的是为了调用其它组件（包括SCA组件、JMS、WS等）

l导出（Export）

与导入相反，导出是为了让其它系统可以调用SCA组件，调用方式同样可以是SCA组件、JMS、WS等。

目前，SCA模型已经得到了业界几个主要软件厂商的支持。IBM、Oracle、BEA、SAP、Siebel、Sybase、IONA等厂商联合发布了SCA规范的0.9版本。具体规范可参见IBM DW的网址：http://www.ibm.com/developerworks/library/specification/ws-sca/。

关于服务组件模型（SCA）更详细的概念参见IBM DW网站（http://www-128.ibm.com/developerworks/cn/webservices/ws-sca/）的介绍。

二、IBM对SCA的产品支持

SCA服务组件模型的提出，解决了EJB、POJO等组件模型与实现语言相关的问题，同时也将SOA的抽象概念落到了实处。也为集成软件项目的开发的图形化组装方式提供了基础。

目前IBM对SCA的产品支持为2005年10月发布的WPS （Websphere Process Server）6.0 ，并为之提供了可视化的集成开发工具WID（Websphere Integration Developer）。使用WID开发集成项目，只要有一定基础编程经验或知识，就可以拖拉的方式，进行图形化的组装，不需要了解太多的J2EE技术细节。

三、EOS与SCA的对比

从上文，可以看出，SCA的这些概念在EOS里几乎都有相类似的概念。对比如下（以IBM的WID产品为例）：

SCA中的概念

EOS中的

相应概念

相同点

不同点

服务组件

业务构件

1、都是描述后台业务逻辑；

2、都提供了接口

1、 1、EOS中可以用图形化的方式定义业务逻辑的实现；而且EOS还提供了展现构件、运算构件等；

2、 2、SCA服务组件则要么通过WSDL调用已经开发好的具体组件，要么用编写特定语言的代码来实现

模块

项目、构件包

都是可部署的单元

1、EOS中的构件包、单个构件都是可部署单元

导入

引用构件包

都是为了复用已有软件资产

1、 1、EOS的引用构件包可引用EOS的任何构件，包括展现、业务、数据、运算构件

2、 2、SCA的导入只能复用业务逻辑

导出

导出

都是为了复用已有软件资产

1、 1、SCA在导出时需要指定导出为SCA组件服务、JMS、WS等类型

2、 2、EOS导出后被新的项目引用时，可以直接拖放组装

服务数据对象SDO

数据实体

1、 1、都是XML与RDB之间的映射

2、 2、都支持Xpath访问

3、 3、都是作为展现层、业务层与持久层之间通信的信息载体

1、 1、SDO支持对象的嵌套

2、 2、SDO除了可以Xpath访问，也可以对象的形式访问

3、 3、数据实体是EOS数据总线的基础

从上表可看出，SCA的概念和EOS的一些概念大同小异，可以说是异曲同工。

四、小结

诚然，SCA规范推出的目的是为了对遗留系统进行集成，EOS的定位则在于开发新的应用。虽然两者定位不同，但是不难看出，未来软件开发的趋势必然是朝着以图形化的构件组装的方向前进。EOS不仅提供了图形化的构件组装工具，同时在调试、部署、应用管理与维护方面都提供了一体化的工具，因此在构件化这一步，普元EOS无疑走在了潮流的前面。

---

SCA与SDO开源与商业产品浅析(2)

发布时间:2007年09月28日 作者:qhyou

---

阅读次数:2169次 类别:原创 永久链接 Trackback 6条评论

之二——商业篇

 

四、             IBM WPS和WAS

IBM是SCA和SDO倡导者和大力支持者，在当前市场上公开发布的所有商业产品中，IBM是对SCA 和SDO规范支持最全面的厂商。IBM对SCA的产品支持包括WPS6.0和WAS 6.1。

IBM WPS对SCA的支持

IBM在2005年10月发布了WPS （Websphere Process Server）V6.0 ，并为SCA构件的开发和部署提供了可视化的集成开发工具WID（Websphere Integration Developer）。使用WID开发集成项目，只要有一定基础编程经验或知识，就可以拖拉的方式，通过图形化的方式进行SCA构件的装配，以及Web Service服务的开发。

IBM WAS6.1 对SCA/SDO的支持

IBM于06年上半年推出了WAS 6.1的SOA补丁版，以支持SCA和SDO。 这个版本是通过Tuscany来提供SCA和SDO规范的实现的。这些新的特性只是α版，正式的特性将会包含在WAS 7.0 中。

在SCA0.9方面实现的特性：

1） POJO来实现服务以及Web Services绑定

2） 支持标记（Annotaions）

3） 支持HttpSession范围的构件

4） 提供了HelloWorld以及BigBank样例程序

在SDO2.0的实现的特性：

1)      动态DataObject的支持

2)      基本的静态代码生成

3)      支持静态DataObject

4)      实现了一些帮助类，如XMLHelper、XSDHelper、TypeHelper等

5)      最小化的ChangeSummary支持

DAS（对关系数据库的）支持：

1） 通过SDO对数据库的CRUD操作

2） 存储过程支持

3） 优化的并发控制

4） 数据库自动生成主键

5） 通过SDO变更历史来驱动对数据的更新

五、             普元（Primeton）EOS

普元软件作为国内唯一一家参与SCA/SDO规范制定的公司，将在其产品的下一个新版本EOS6.0中全面支持SCA1.0 和SDO 2.1 规范，EOS6.0预计将于07年底发布β版，08年春季发布正式版，并同时提供免费社区版。

普元EOS 6.0采用全新的产品架构和实现，基于SCA、SDO等标准化技术，以面向构件（COA）、面向服务（SOA）为导向的一体化企业级基础应用平台。EOS6.0为实施SOA应用提供了从构件设计、开发（调试）、部署、应用监管、维护与升级的全生命周期管理功能。同时，EOS还通过“基础应用框架”提供了一套Web框架、菜单与组织机构权限管理功能，使得应用开发不再从零开始。另外，EOS提供的符合SCA规范的基础构件库大大提高了软件的复用度，保证了SOA应用实施的质量。

1、EOS的构件模型

EOS构件模型（如下图）的核心是“业务构件”（也就是SCA规范中的Composite）。业务构件是EOS部署的基本单元。一个业务构件可以由不同的“服务构件（对应SCA规范中的Component）”装配而成。在EOS中，服务构件可以由Java实现的，JMS实现，EJB实现，WebService实现，BPEL实现，甚至可以是通过一个图形来实现的（称为“EOS服务构件”，这是EOS对SCA规范的扩充）。

图 4  EOS 构件模型

              在一个业务构件中，还定义了该构件与其它构件之间的依赖和引用关系。

业务构件通过接口来体现构件对外提供的“Service”，接口的参数类型既可以是普通的Java类型（POJO），也可以是SDO的DataObject类型。

2、图形化的SCA构件设计

提供双向设计支持：提供可视化的构件设计（包括Composite的接口设计、Composite依赖和引用关系设计、Composite的装配设计），既支持从业务视角出发的TopDown设计方式，也支持BottomUp的传统设计方式。

架构一致性保证：设计模型与实现模型完全相同，因此模型和实现之间的一致性能自动得到保证。                                            

图 5双向构件设计 

设计可验证：在设计的同时即可检验模型的正确性，大幅度节省设计时间，也保证了设计阶段的质量。

                                                

3、 图形化的SDO设计：通过图形化的方式进行域模型设计，并支持每个DataObject之间的关联关系（包括单向和双向的1：1，1：n，n：1，n：n关联）。

4、 图形化的SCA构件组装与调试：对于EOS服务构件，其实现是基于一系列基础构件，通过图形化的组装来实现的。由于采用了图形化的组装方式，因此对构件的调试也是通过图形化的方式进行的。对于绝大多数应用，都可以采用图形化的组装方式来实现一个构件，而无需手工编写代码。

六、             总结

爱因斯坦曾经说过，“事情应该尽可能简单，而不是更简单”。SCA和SDO由于简化了编程，统一了对构件的访问方式，随着SCA、SDO等规范的日渐完善，以及SCA和SDO标准化进程的推进，加上行业用户对SOA的了解逐渐深入和客观，SOA将逐渐从概念阶段转到真正的标准化时代。随着这个时代的来临，SCA、SDO的开源和商业产品也会越来越多，越来越好。对于使用SOA进行应用实施的设计人员、开发人员、系统管理人员、行业用户等，都将享受异常SOA盛宴，并最终获得SOA所带来的利益。

---

建造流程企业，该如何选择工作流产品

发布时间:2007年07月18日 作者:qhyou

---

阅读次数:2726次 类别:原创 永久链接 Trackback 2条评论  

作者：游青华

     打造流程企业，逐渐成为众多企业的一个重要目标。然而实际情况是，目前国内绝大多数企业离流程企业的还有很大的差距。银监会主席刘明康曾表示，当前很多中资银行的业务流程都存在着弊端，仍只是“部门银行”，而不是“流程银行”。

打造流程企业，一方面企业管理本身需要改进与优化，另一方面，也离不开工作流引擎（也有的称为业务流程管理BPM）的支撑。本文从IT规划和企业业务需求等多个角度，阐述如何选择合适的工作流产品。

 

一、             从IT规划出发

企业信息化建设已经逐步从以前的以业务部门推动IT部门的被动式建设方式，逐渐向IT部门从整个企业的角度对IT进行主动规划的方式转变。被动的信息化建设方式导致的结果是在企业内部产生大量的“梅花桩”，成为企业内部的信息孤岛。而主动规划则大大改观了这种局面，通过主动规划，各个业务系统之间不再各自为阵，彼此孤立，互不相通，甚至重复建设了。

       对于流程企业的建设，在IT规划过程中，一个重要的目标就是“企业流程整合”，为了达到这个目标，“工作流平台”可以说是不可或缺的。那么从IT规划的角度，如何选择一个适合您的工作流平台呢？

1、是否符合短期与长期规划的需求

由于IT规划一般至少是对信息化进行3～5年的规划，因此现在工作流产品时，既要考虑工作流产品是否符合短期内的业务需求，又要考虑工作流产品是否能够满足企业业务发展的长期需求。

短期的业务需求一般都是比较明确的，这些系统，往往都是由于企业业务发展的需要而要求必须马上进行建设的，因此对IT系统提出的要求都非常具体。比如近期国内电信行业的服务开通系统，业务需求已经比较明确。在考察工作流产品的时候，首先就评估产品是否能满足目前已知的业务系统的需求。这是选择工作流产品的基本点。

对于IT规划中，未来的业务需求，往往是不容易预测的。但是对于选择工作流产品来说，这又是至关重要的。因此这时需要选择专业、成熟的工作流厂商，而且其产品要在各个行业都应该有比较多的应用案例。另外，工作流厂商本身对其产品的规划能力也尤为重要。

2、选择通用而非专用的工作流

目前市场上的工作流产品鱼目混珠，其中大部分都是一些做行业应用软件的集成商为了自用而开发的。这一类工作流产品大多都是专门针对某一类业务系统而开发的（比如OA类），无法应用在其它业务系统。并且这类工作流产品的几乎没有商品化，产品的成熟度、易用性、功能完备性等等都得不到保证。因此这类专用的工作流是不能支撑整个流程企业的IT运行的。

而作为一个要运行在整个企业IT系统的工作流平台，必须具有很好通用性和适应性，比如工作流平台不仅仅能够用于支持企业内部的OA系统运行，还要能支撑企业的业务系统（如电信业务处理、银行的信贷、风险管理等业务）。

3、充分考虑工作流产品的稳定性

对于一个需要支撑整个IT环境中流程运行的工作流平台，对其稳定性的要求是压倒一切的。尤其是许多关键系统，需要7 * 24 的模式运行。当然稳定性也需要根据业务系统本身的要求而定，有些业务系统对稳定性要求不高，而有些业务系统则可能对稳定性的要求非常高。在选择工作流产品的时候一定要根据业务系统的需求来决定，而不是一味的追求高稳定性。毕竟稳定性越高，成本也会越高。

二、             从业务需求出发

工作流平台是用于支撑业务系统的运行，因此在选择工作流产品的时候，一个非常重要的依据就是是否能够满足业务系统本身的需求，这是选择工作流产品的最基本出发点。只有最关键的业务需求满足了，其它的条件才有意义。

不同的行业，关键业务需求也各不相同，下面是几个典型的行业对工作流的关键需求。

1、电信行业对工作流的需求

在电信的MBOSS业务系统中，包含了MSS（管理支撑系统）、BSS（业务支撑系统）和OSS（运营支撑系统）。MSS主要是企业的管理过程，包括财务管理、工程项目管理、人力资源管理和信息数据管理和OA/知识管理。BSS则是面向市场营销和客户服务管理，包括市场营销、综合客服、销售、客户管理、合作伙伴管理、产品管理、营销分析、客服保障、计费数据提供、计费数据处理、结算数据处理等等。OSS是以服务和资源为主，包括综合服务开通、综合服务保障、流程支撑平台、网络资源管理、综合网络管理应用环境等业务。

在上述电信业务中，大部分都是由流程驱动的，尤其是在OSS系统中表现的最为突出。这些业务最关键的特点是：

1）新产品新业务推出频繁

电信市场是一个竞争异常激烈的市场，随着竞争的加剧，新产品推出的频度也越来越高，如几乎每季度都有各种新的资费套餐面市。另一方面，随着3G时代的来临，对电信业务系统的建设也提出了更高的要求。

这些新产品、新业务的频繁推出，需要IT系统能够以更快的速度来响应，以提高业务的敏捷性。而对于以流程为主的系统来说，工作流产品的灵活性、适应性显得尤为重要。如果工作流平台不能支持这种业务的快速变化，则将极大的影响电信新业务的推出，从而最终影响企业在市场的竞争力。

2）海量数据、高并发

以服务开通系统为例，一个省集中系统，每天需要处理的业务量达到20万笔。如此大的业务量，要求工作流产品必须能够保证系统能够在大容量数据运行状况下，保证良好的可靠性与稳定性。

3）系统上线周期短

由于市场竞争的需要，往往要求在尽可能短的时间内开通新业务系统，而且新系统上线往往是在已有系统基础之上进行快速调整。这就要求工作流产品能够在开发效率、系统升级与维护效率方面提供相应的支持。比如基于构件的工作流产品，由于采用了图形化的构件组装技术，能够最大程度的复用已有构件，再结合图形化的工作流，使得新系统上线（或者升级）周期大大缩短。

4）异构系统流程整合

电信行业已经建立了大量的业务系统，如CRM、计费系统等等基本建设完成。新上线系统大多需要将这些已有系统进行整合，包括流程、信息的整合。如一个服务开通业务流程中涉及到的系统可能包括OSS和BSS系统中的功能，并且同时需要进行异步数据交互。

2、电子政务对工作流的需求

电子政务系统也是典型的流程驱动型业务，如对内的各级政府收发文，对外的金网工程、社会保险业务等等。在选择工作流产品的时候，需要考察候选产品能否支持如下这些需求。电子政务系统的主要特点有（限于篇幅本文只列出了一部分）：

1、业务流程跨组织

由于政府机构很多都是矩阵式的组织机构，因此在政府内部的公文处理流程中常常需要在党政四大班子之间跨部委（包括平级和上下级部位之间）交叉、往复流转。甚至很多行文是在不同部委的彼此独立的系统之间进行交互的。

2、流程的灵活性要求高

与电信系统一样，电子政务的流程对灵活性要求非常高，同一个流程往往需要往复运行很多轮才能结束。有时在流程未能固化之前，甚至要求流程按照任意顺序流转，而不受流程本身的逻辑控制（即所谓的自由流）。

另外，对于公文审批规则、会签、退回、批阅、督查督办、机构的岗位设置等等都有比较灵活的要求。

3、严格的权限控制

党政四套班子的行文，每一步的公文处理都有严格的权限控制。比如同一个流程中不同的公文有的人只能看，不能审批签字；同一个处理人员在不同的流程环节中对公文的权限也不相同。有的甚至要求某些公文只能查阅，但是不能复制到本地保留副本。这些需求都是在选择一个工作流引擎时需要重点考察的。

4、安全保密要求高

电子政务中的公文流转，由于涉及到国家机密，因此要求公文在流转过程中，必须保证绝对的安全，不能出现被黑客非法窃取的情况。同时，也不允许直接在外网上运行。

三、             其它角度

以上是从IT规划和业务需求角度来谈如何选择工作流产品，在选择工作流产品时，还有很多角度需要考察的，比如：

1、从产品角度

从工作流产品本身的角度，主要需要关注：

l         功能完备性

l         产品稳定性

l         产品开放性

l         产品的性能

l         开发与维护成本

l         产品的学习成本

l         产品的发展规划

2、从厂商角度

选择工作流产品时，厂商也是一个非常重要的因素，如：

l         厂商的专业程度

l         厂商的服务水平

l         厂商的技术水平

四、             总结

总之，选择工作流产品，首先要明确选择工作流产品的目标。然后从多角度考察，尤其要结合企业自身实际情况与需求，多做产品对比，并尽可能的对候选产品进行测试验证，亲自体验。只有这样才能选择到适合您的工作流平台产品。

---

SCA与SDO开源与商业产品浅析(1)

发布时间:2007年05月17日 作者:qhyou

---

阅读次数:2459次 类别:原创 永久链接 Trackback 1条评论 OSOA于07年3月份发布了SCA 1.0 和SDO 2.1 规范，并已经提交到OASIS标准组织，为SOA的正式落地揭开了序幕。关于SCA（Service Component Architecture）和SDO规范本身以及规范产生的背景和意义，已经有很多资料进行了大量的介绍，本文主要对基于SCA和SDO而实现的开源以及商业产品进行分析。

之一 ——开源篇

OSOA于07年3月份发布了SCA 1.0 和SDO 2.1 规范，并已经提交到OASIS标准组织，为SOA的正式落地揭开了序幕。关于SCA（Service Component Architecture）和SDO规范本身以及规范产生的背景和意义，已经有很多资料进行了大量的介绍，本文主要对基于SCA和SDO而实现的开源以及商业产品进行分析。 

SCA和SDO的开源产品目前并不太多，主要有Apache Tuscany、Eclipse STP（SOA Tools Platform）、PECL SOA for PHP、CodeCauldron Newton等。这些开源产品中，尤其以Apache旗下的Tuscany和Eclipse旗下的STP最为引人注目。

基于SCA和SDO的商业产品目前已经有不少，包括IBM WPS/WAS、AquaLogic Data Services Platform、TIBCO ActiveMatrix、 Rogue Wave HydraSCA、Covansys SCA Framework for SOA、Infiniflow DSF等。这些商业产品基本都是基于SCA或者SDO的早期版本实现，而最新发布的SCA 1.0 版本变化非常大，因此严格的说，目前市场上还没有真正符合SCA 1.0和SDO 2.1规范的产品出现。另一方面，这些SCA、SDO商业产品本身还处于一种试验状态，产品功能也不是很完善，而且使用这些产品来实施SOA（基于SCA/SDO）的用户还比较少。

一、             Apache Tuscany

Tuscany是Apache Incubation的一个开源项目，主要开发人员来自IBM和BEA。Tuscany出身于皇家血统（OSOA联盟），可以算是SCA和SDO的最正宗的开源项目了。与Eclipse STP相比，Tuscany提供的只是一个SOA基础设施，包括SCA运行时环境、SDO和DAS实现，Tuscany项目本身并不提供SOA开发和管理IDE插件。

关于Tuscany的分析请参见杨洪波的文章“SOA与开源双剑合一（http://www.primeton.com/about/read.php?id=576&his=1）”。

二、             Eclipse STP

STP（SOA Tools Platform）是由IONA、IBM、BEA、Sybase、ObjectWeb等公司贡献的，并于2005年成为Eclipse的第九个顶级开源项目。STP目前尚未有正式的版本release，最新的稳定版是07年2月1号发布的（S200702011041）。根据项目计划，STP将于07年6月29号发布Europa版（中文意思为“木卫二”，木星最亮的四颗行星之一，与木星的距离排在其卫星的第七位，最早为伽俐略观测到）。Europa版即是原来的Callisto版。

1、STP的目的与任务

SOA越来越受到软件供应商、行业客户和开发人员的推崇，SOA的前景也可以说是一片大好。但是SOA目前的现状是，一方面SOA本身没有统一的标准，另一方面实施SOA也没有统一的工具。随着SCA和SDO规范的推出，STP项目也应运而生（SCA/SDO0.9规范05年11月发布，STP项目05年12月）。

STP的目的一方面是为了统一SOA应用的开发、部署和管理工具，并使这些工具标准化；另一方面就是提供一个可扩展的SOA应用工具集，包括为开发人员提供构建服务、部署服务和维护服务的工具集；为架构设计师提供装配（Assemble）SOA基础设施的工具集；为系统管理人员提供维护、监控、和策略管理的工具集。

从以上目的来看，STP几乎涵盖了SOA应用的全生命周期，包括设计、开发、测试、部署、维护和治理。在SOA项目生命周期中的每个角色都能在STP中找到对应的工具。

2、STP的项目范围

对于实施一个SOA项目，从图1可以看出，从工具层面，会涉及到设计、开发、测试、部署工具，从管理方面，会涉及到QoS、服务水平协议（SLA Services Level Agreement）、生命周期管理、版本管理；从消息和传输协议层面，会涉及到SOAP、JMS、JDBC、HTTP、SMTP、IIOP、RMI等；从基础服务方面，会涉及到安全、可靠性、事务、异步和服务编排；从应用层面，会涉及到移动应用、门户、商业流程、遗留系统和本地应用。

 

图 1  STP项目的范围

对于STP项目，其范围为图-1中的Tools和Management两部分（图中紫色和黄色区域），主要包括：

1)        STP提供可扩展的SOA应用工具平台；

2)        STP的关键能力包括：服务的设计、配置、装配、开发、监控和管理；

3)        STP的关键规范是SCA和WSDL；

4)        STP的原则是尽可能的复用其它Eclipse项目的技术，如WTP、DTP、SDO；

5)        STP着重于框架

                                       i.              保持供应商中立

                                     ii.              提供可扩展的架构，并且可以鼓励三方和商业扩展。支持SOA系统（SOAS）中部署的服务的编辑、创建和配置工具的扩展；

6)        STP还要提供扩展能力，以支持一些开源的运行时容器，比如Tuscany, Celtix, ServiceMix, OSS JEE 或任何其它支持SCA的容器；

7)        STP会实现并支持SCA装配模型。在创建服务方面，STP目前只支持SCA Java客户端规范（SCA Client and Implementation Model Specification for Java）

从STP的范围来看，STP强调扩展能力，强调Framework，强调SCA，提供SCA的工具插件。而Tuscany是提供基础设施的SCA/SDO运行时环境，因此STP与Tuscany有着很好的互补性。

3、STP的子项目

由于STP涵盖的范围非常大，因此STP被分成了5个子项目，包括：

SOA System(SOAS)：提供SOA系统的打包、构建、配置、部署和管理工具与框架

Services Creation(SC)：服务创建

Core Framework(CF)：STP的核心模型和框架。                              

图 2 STP子项目

BPMN（Business Process Modeling Notaion）：BPMN的编辑器与框架。

BPEL 2 Java(B2J )：BPEL到Java的转换器。

1)        SOA System （SOAS）：

SOAS提供服务的装配、构建、部署、打包和管理的工具和框架。

策略编辑器以及赋值工具。

系统校验工具。

可扩展的包profile编辑器（包括profile模型）。

可扩展的包生成器。

可扩展的部署profile文件编辑器（包括profile模型）

依赖管理工具：对服务或者包之间的依赖进行管理。

测试与调试：测试和调试主要使用Eclipse的TPTP。

2)        Services Creation（SC）

负责服务的创建，包括创建服务的编辑器、绑定编辑器以及服务发现工具。其中创建服务编辑器支持SCA构件和模块的创建，接口编辑器（借助于WTP的WSDL编辑器实现），Composite编辑器、资源生成向导（如项目、SCA构件等），SCA 构件的Component Type文件编辑器。绑定编辑器主要是对传输协议和消息格式的编辑器。

在07年4月9号编译的一个All in one版本中，提供了对JAX-WS和SCA两种服务的生成工具。Europa版发布以后将会支持PHP和C++语言的服务创建。

3)        Core Framework（CF）

CF是STP项目的核心框架与模型，提供核心的API主要包括：SCA服务装配的EMF模型，访问和创建装配模型，支持Java语言的SCA构件，SCA模型的扩展（如服务的绑定和实现类型Implentation Type扩展），校验，以及服务的引用和依赖管理等。

4)        BPMN

BPMN项目提供BPMN（Business Process Modeling Notation）的编辑器以及框架。Europa版将支持BPMN建模功能。BPMN使用EMF作为对象模型，图形编辑器基于GMF实现，对象模型以XMI格式持久化。

STP BPMN模型可以生成与BPEL2.0兼容的模型，因此可以利用BPMN来实现对多个SCA构件的编排，从而生成一个新的SCA Composite构件。

 

图 3  BPMN

5)        BPEL 2 Java（B2J）

B2J子项目是集成框架的一个参考实现，提供了一个标准的BPEL运行时框架，以及BPEL到Java的转换器（即根据BPEL模型生成可以运行的Java代码），并允许Java BPEL编译后运行在任何STP所支持的运行环境中。Europa版将集成BPEL编辑器。

BPEL与WebService之间的关系比较紧密，对于国内的电信、银行等行业用户而言，对BPEL的性能还抱着怀疑的态度，因此不敢冒然大规模使用。另外，BPEL（包括BPMN）解决的主要是集成问题，而国内的集成市场还很小。这些都是造成BPEL或BPMN在国内得不到大规模应用的原因。

4、STP项目的现状

从STP的规划上看，是一个非常全面的SOA应用实施工具和框架。从STP项目今年4月9号编译的一个All in one Eclipse插件所提供的功能来看，开发人员想要使用STP进行SOA项目的开发，还要等待一些日子。

在这个版本中，还只提供了一些简单的SOA应用开发、部署功能，包括JAX-WS和SCA项目的创建向导，BPMN和WDSL的图形化编辑器，SCDL（SCA Defition Language）编辑器、部署文件编辑器等。对于SCDL编辑器甚至基本上就是一个XML编辑器。对于服务装配、服务注册以及服务库，将会在Europa以后的版本中提供支持。

可以预见，STP要完全实现规划中的功能，并发布成熟稳定的版本，还需要等到08年。

三、             CodeCauldron Newton

Newton是Paremus公司Infiniflow Distributed Service Framework (DSF) 产品的一个开源版本，它是基于GPL协议的，这意味着如果你对Newton源代码做了修改，修改后的代码也需要免费开放给第三方使用，并需要将修改后的源代码反馈给Newton项目。

Newton是一个分布式的构件框架，它用SCA标准来描述分布式系统，并且提供了高度动态的SCA实现（基于OSGi技术）。它能够加载和管理部署在分布不同JVM中的SCA构件。

Newton借鉴了Spring的分离关注思想，将域模型和基础设施分离，提供了一个轻量级的分布式构件开发模型。对于分布式模型，面临的最大问题来自于网络状态不稳定、不可预见的系统失效，以及分布式系统的管理（如部署问题、资源释放等）问题。Newton使用OSGi和Jini来解决这些问题。OSGi是Newton整个构件模型的中心，而Jini则是其远程基础设施的基石。

  《未完待续》

---

工作流概念与模型培训PPT下载

发布时间:2007年02月01日 作者:qhyou

---

阅读次数:2978次 类别:原创 永久链接 Trackback 

本文是作者做过的一次工作流培训的PPT，主要内容为：

1. 为什么要使用工作流
2. 工作流的发展历史
3. 工作流的概念
4. 工作流的路由模型
5. 工作流的发展现状与趋势

下载：工作流概念与模型_Youqh_20070201.rar

---

“洛伯定理”与流程管理的联系

发布时间:2006年11月07日 作者:qhyou

---

阅读次数:2946次 类别:转贴 永久链接 Trackback 

洛伯定理 ：对于一个经理人来说，最要紧的不是你在场时的情况，而是你不在场时发生了什么。

如果只想让下属听你的（上级导向），那么当你不在身边时，他们就不知道应该听谁的了。

通过实施流程管理（下游导向/客户导向），让员工知道你不在身边时他应该听谁的。

流程对工作的过程应该有详细的说明：流程应该何时启动？启动之后怎么做？采用什么方法和工具？与谁发生什么关系？交付什么成果给下游客户？说得再通俗一些，流程是一种沟通工具，是流程的制定者与流程的执行者之间的一种沟通，当流程的执行者不清楚应该做什么以及怎么做的时候，就去通过流程进行沟通，而不需要去找流程的制定者，除非这个流程本身没有表达清楚，而制定清晰简单的流程是流程负责人的责任。

最终通过流程相关的绩效管理进行检查和控制。

frank 发表于 AMT Blog

---

业务流程管理的三个层次

发布时间:2006年11月07日 作者:qhyou

---

阅读次数:1590次 类别:转贴 永久链接 Trackback 

业务流程管理的三个层次
　

　

业务流程重组（Business Process Reengineering，BPR）自90年代初由美国的两位管理学专家首次正式提出来以后，迅速风靡全球，近年来随着国内信息化的进程，也日渐被国人所熟悉。然而这个诞生在美国，在大规模生产向个性化定制转变，IT技术被广泛应用的这样一个大背景中的产生的管理理论曾一度受到质疑。其原因是大规模的业务流程重组的成功几率不高，连BPR理论的创始人之一哈默后来也承认BPR理论过于激进，在更多的时候，应该采用业务流程优化(Business Process Improve, BPI）而不是BPR。其实，对于国内的企业来讲，业务流程的管理按照其变革的程度应该分为三个层次：业务流程的建立和规范、业务流程优化和业务流程重组。这三个不同层次的变革分别适用于不同阶段和管理基础的企业。

第一个层次是业务流程的建立和规范。

在一个企业尤其是中小企业建立的初期，由于企业生存的压力，管理者普遍关注市场和销售，对流程和制度不重视，运作基本靠员工的经验和一些简单的制度，企业的成功往往取决于企业主的个人能力和一些偶然的机会，比如拥有该行业成功所需要的特定资源。处于这个层次的企业，当在解决了生存问题，开始走向规模化的时候，面临着从人治向法治的转变。这个时候解决的是一个从无到有的问题，象许多企业推行ISO9001体系或其他一些基本制度的建设，都是为了解决这个问题。国内的大部分中小企业和一些市场化程度不高的行业里的企业大都属于这个层次。

处于第一个层次的企业，面临的最大的问题是无序，通常会出现组织结构不健全，机构因人设岗的，权责不清和没有制度流程。这些企业通常没有成型的组织机构，谁熟悉哪一块也就由谁负责该项业务，职能通常会有交叉，企业的运作基本上依赖于人的经验和惯性，经常会发生越级指挥事件，同时会表现出高度集权的特点。

从流程管理的角度，这个时期的企业急需的是建立起基本的流程和规范，如业务运作流程、作业指引、岗位说明书、人力资源管理体系等。这个时期的企业不能强求业务流程的精细，关键是明确权责，识别和描述流程，使工作例行化，

第二个层次是业务流程优化。

由于企业规模的扩大，组织的机构会逐渐庞大，分工会越来越细，企业官僚化程度也在随着增加，这个时候面临的最大问题是低效，也就是效率的低下，通常这类企业会表现出以下特点：

组织机构完整，甚至大而全，也有书面的职责说明、制度流程，但是会出现部门间合作不畅，跨部门流程工作效率低下，决策时间长，制度流程虽然有但是没有达到精细化的程度，流程执行不到位等等问题。有相当一部分企业还通过了ISO9001认证或有完整的制度流程体系。具备这个特点的企业一般是一些迅速膨胀后颇具规模的民营企业和一些国有企业。其业务模式相对稳定，而且通常企业发展比较快。

在这个阶段的企业需要解决的问题如何提高企业的效率和反应速度。通常采用的方法是先对现有流程的绩效进行评估，识别缺失的关键环节和需要改善的环节，针对流程各环节从可以以下四个角度进行分析：

活动：是否过于复杂，存在精简的可能性

活动实现形式：是否能用更有效率的工具来实现活动

活动的逻辑关系：各环节的先后关系可否作调整以达到改进目标

活动的承担者：是否可以通过改变活动的承担者来使流程更有效率

然后通过对现有流程的简化、整合、增加、调整等方式来提升流程效率，还可以通过明确流程所有者（process owner）的形式来监督流程的整体表现，从而避免部门间推委的问题。

一般在进行流程优化的时候关注的是相对低层次的流程的效率和成本等，可以采用一些方法和工具对现有的流程进行改良，同时强调流程的有效执行，一般不会涉及到大的组织变革和流程变革，这个时候解决一个从有到更好的问题。

以一家家电企业的研发流程为例，该企业有完整的研发流程和制度，但在实际运作中，新产品研发周期很长而且研发效率较低，设计变更频繁，模具空置率高；各类评审的手续复杂，研发与市场以及工艺部门、生产部门之间经常发生推委事件等等。通过对研发流程的绩效表现、流程各个环节以流程的运作情况进行诊断分析，发现流程.各个阶段包括概念阶段、计划阶段、开发阶段、验证阶段、发布阶段、生命周期阶段各个阶段的关键控制要点的操作性不强，缺乏有效的检查清单而使重要的评审点评审受限于评审点的经验甚至流于形式；和各个相关部门之间的接口不清晰、导致重复返工；不同类型和难度的研发项目采用同样的流程导致流程的效率低下等等，找出上述问题后，针对性的优化上述流程以后，就可以有效的解决上述问题，提高研发流程的效率。

业务流程优化的特点是一些局部的变革，对企业的冲击相对较小，相对比较容易实施，缺点是只是一些改良，对一些存在结构性问题的企业往往不能解决根本性问题。

第三个层次是业务流程重组。

这个时候往往是公司的战略转型期，需要对流程进行根本性的变革，需要全面评估业务流程，需要根据战略对流程进行重新设计和重组流程以适应公司的战略，流程重组往往伴随着IT系统的实施、重大的组织变革和业务模式的变革。这个阶段往往是一次重大的管理变革。

这个时候企业的流程本身并没有很多的问题，但是往往不能适应新的战略，一般伴随IT系统的实施或者新的战略调整，需要对企业的流程进行全面的评估和战略性思考，同时随着流程的调整需要进行一系列的配套措施。

以某知名的房地产企业为例，公司的新战略要求能够快速的交付产品，快速的进行存货周转，但是在对房地产开发的整体业务流程进行审视时，发现对现有的业务流程进行简单的优化和完善并不能解决问题，在整个开发流程中，招标采购占了相当长的时间，如果只是对该流程进行一些局部的优化并不能有效的解决快速交付产品的问题，在对整个业务流程进行后战略性思考，提出了从设计角度对一些材料和工程进行标准化设计，在采购方面建立战略采购系统的模式，通过这种标准化的产品设计和战略采购，使得一些费事费力的采购招标过程可以免去，从而极大的加快了产品的交付和提高了效率。这个变革涉及到整个规划设计、采购招标乃至成本预算等流程的变革。
博锐20
业务流程重组因为往往伴随着业务模式的调整，是一次重大的管理变革，存在较大的实施风险，但一旦成功，往往能给企业带来业绩的重大改善。

这三个层次的流程管理适用于不同阶段的企业，当然他们之间的界限不是严格意义上的。在进行业务流程的规范时，最好能对流程进行一些优化，业务流程优化和业务流程重组之间的界限也只是程度上的区别，关键是进行流程管理时根据管理的现状采用合适的方法和步骤。

作者：攀成德

---

SOA 应用五大问题所在

发布时间:2006年10月18日 作者:qhyou

---

阅读次数:1428次 类别:转贴 永久链接 Trackback 

SOA 应用五大问题所在

【2006-09-29 08:32】【Thomas Erl】【TechTarget】

SOA刚刚经历了喧嚣的一年， 而这种刺激和变化才刚刚开始而已。各种机构团体继续对服务设计的多变的前景，服务总线,和服务管理甚至仅仅针对服务本身进行再次检测。这是由多方面的情绪引发的，很多人对于SOA在IT业中的成熟度与大致情况感到困惑。 但是，对于其在联合商业与技术方面的潜力，人们还是抱着毋庸置疑的兴奋。

　　今年许多SOA厂商带着各自的目标和期望值投放市场，有的一败涂地， 有的困难重重。在完成他们最初目标的决定性因素是学习那些已经在竞争中存活下来但是结果不怎么理想的项目经验。这些人留下来讲述他们的故事并警告他人在通向SOA的道路前方等待着他们的将是什么。

　　在我们的工作过程中将会看到不同完成程度的不同项目。我们可以看到一个好的SOA项目陷入困境， 不好的SOA项目变得更差。问题都是能够解决的，错误也可以纠正，但在将事情导向正途的过程总会有一些影响。因而最好的办法就是防患于未然。

　　理解了其他的缺陷之后，在你的SOA道路上构建一个安全路径将成为你的首要任务，你能达到的前景范围退居其次。为了让大家有一个领先他人的开始，我们收集了SOA应用中的五大弊端。

　　第五:不能理解SOA 性能需求

　　松散的连接是有代价的。当实现网络服务之后，SOA实现了数据处理层及架构于此基础上的相关性能。从小做起， 建立能按照预期运转的面向服务方案是较容易的。随着规模的扩大和新功能的增加，以信息为基础的沟通将会增长， 如此以来， 在预计之外的情况将开始经历一个重大的处理反应期。

　　建立成功的面向服务方案关键在于事先理解该方案性能需求及其基础架构的局限性。这就意味着要测试(如果必要的话， 加强)您的外部环境的信息处理能力并密切注意服务设计以达到在传送速度，传送量和能给方案性能带来负面影响的其他服务之间的平衡。

　　第四: 并非建立在XML基础上的架构

　　在今天的SOA世界中，一切皆始于网络服务。 这句话在某些机构当中已然成为了纲领， 但它却并不是完全正确的。其实， 在今天的SOA世界中， 一切始于XML.这个标准是由多层辅助标准演化而来的，目的在于形成既成事实数据的演示架构。这是促使形成今天驱动SOA一系列服务规范的一套核心标准。

　　我们投注了太多的注意在服务之间的数据传送上以至于经常忽略了这些数据是如何建构的，如果在服务线上生效的。这种疏忽将导致持续出现XML数据演示层的错误执行。XML数据演示层是SOA的基础， 它的缺陷将影响到建立在其基础上的所有方案。

第三: 缺乏过渡计划

　　没有全面的过渡计划， 成功转换的几率将大大降低。 由于企业内服务端点的范围将引起外部基础架构的重新定义，执行低质量的转换，其影响将是巨大的。有了过渡计划，你就可以在控制中逐步实现服务定位和SOA特性，从而使转换是在技术，架构及组织层面上进行的。

　　典型的SOA过渡计划包括: 效果分析(即预计SOA的改变对现有资源、程序、制订规则的影响范围)，转换架构(即制订一系列混合进程计划以实现目标SOA)和一个投机分析(即考虑未来的网络服务增长及相应的配套技术发展)。

　　第四: 非标准化SOA

　　于其他架构一样，SOA需要内部设计标准的建立与实施来实现其优势。例如，如果一个项目建立一个与其他软件隔离开的面向服务方案，该方案的关键部分将不会符合临近应用程序，而需要内部操作或者与其他程序共享某种服务。

　　这就会引起许多问题，比如不兼容的数据演示，与不规则界面产生服务协议和非互补页面服务扩展名的应用(或者扩展名以不同形式安装)。

　　SOA 提倡使用抽取末端处理的发展环境以便能在一个应用程序里独立执行和发展。但是，标准化在保障其设计和与融入末端逻辑的其他服务互动的连贯性来说仍然是必要的。

　　第五: 按照传统结构分布建立SOA

　　在实现SOA的过程中面临的最大的障碍就是按照传统分布结构模式来建立SOA，并声称SOA的实现。

　　SOA 并不是简单的CORBA + XML，也不是ASP.NET + WSE。 服务导向并非目标导向，它们之间的联系也没有紧密到所有建立目标导向的组成逻辑在服务导向方案环境中都可以适用的地步。SOA是一种独特的建立在服务导向基础上的架构，一个独特的设计范例。理解其独特性对于建立真正的面向服务自动操作逻辑，使之与SOA全球发展方向一致是至关重要的。

---

Hibernate 3.2 released, certified JPA compatible

发布时间:2006年10月18日 作者:qhyou

---

阅读次数:1124次 类别:转贴 永久链接 Trackback 

Hibernate 3.2 released, certified JPA compatible

Posted by: Joseph Ottinger on October 16, 2006 DIGG

JBoss has released Hibernate 3.2, their popular persistence engine, now certified compliant with the Java Persistence API. In addition to JPA compliance, hibernate adds new query capabilities, declarative data filters, and optimistic locking in a cluster with JBoss Cache.

The Hibernate 3.2 release includes:

• Hibernate Core is the full featured, high performance object/relational persistence and query service that popularized object/relational mapping for Java. Hibernate relieves developers from 95 percent of common data persistence related programming tasks, compared to manual coding with SQL and the JDBC API. Hibernate Core offers a powerful native data management and query API, and object/relational mapping with XML metadata. Hibernate Core requires JDK 1.3 or greater and works with any J2EE 1.4 or Java EE 5.0 application server.
• Hibernate Annotations offers several packages of JDK 5.0 code annotations that developers can use to map classes, as a replacement or in addition to XML metadata. Hibernate Annotations supports standard Java Persistence object/relational mapping annotations, native Hibernate extension annotations, and declarative data integrity rule definition and validation with the Hibernate Validator framework. Hibernate Annotations requires JDK 5.0.
• Hibernate EntityManager implements the Java Persistence programming interfaces, object lifecycle rules, and query options as defined by Java Specification Request 220 (EJB 3.0). Combined with Hibernate Annotations, this wrapper offers a complete Java Persistence provider on top of the mature and powerful Hibernate Core. The Hibernate Java Persistence provider is the default Java Persistence provider of the JBoss EJB 3.0 implementation. Additionally, it can be used inside any other Java EE 5.0 application server or standalone with JDK 5.0.

Message #220447 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Hibernate 3.2 released, certified JPA compatible

Posted by: Roland Altenhoven on October 17, 2006 in response to Message #220401

Congrat for the finally releases of 3.2.

It is much to be hoped, that some existing minor (but sometimes a little bit painful) problems of Annotations and JPA are now solved with 3.2 ...

Hibernate and JPA, Annotations rocks ...

Roland
SOA Kompetenznetzwerk
Information & Collaboration Portal

New Look & Feel and advanced Information- & Collaboration Strategy are upcoming, soon ...
Message #220521 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Hibernate 3.2 released, certified JPA compatible

Posted by: Michael McCutcheon on October 18, 2006 in response to Message #220401

For JPA, which is better, Hibernate or Toplink Essentials?

What are the differences between the two as it relates to JPA?

Which works better with Derby?

Mike
Message #220523 Post reply Post reply Post reply Go to top Go to top Go to top

Re: Hibernate 3.2 released, certified JPA compatible

Posted by: Dorel Vaida on October 18, 2006 in response to Message #220401

Excellent news, congrats to the Hibernate team.

---

AJAX JSF Frameworks Review

发布时间:2006年10月18日 作者:qhyou

---

阅读次数:1036次 类别:转贴 永久链接 Trackback 

Introduction

This review gives a summary on current commercial JSF Frameworks that use Ajax to update the website. The frameworks Icefaces, Netadvantage and Quipukit will be compared by analyzing specific components to each other. Moreover, we will give you detailed information about positive and negative impressions and experiences we gained about them during the installation and using them in practice.

The hybris Product Information Management (PIM) Platform already handles nice web features like treetables, sortable lists and autocompletion. But it still does not use Ajax (Asynchronous JavaScript and XML) for exchanging data dynamically from client to the server, which would allow individual pages to be updated without reloading the whole content. Thus, we're going to try to recreate these objects with the help of those three frameworks.

查看全文：http://www.theserverside.com/tt/articles/content/JSFComparison/article.html