水青木华

四川广安人,98年硕士毕业于东北大学。从事过6年的企业级应用软件开发,04年开始涉足面向构件中间件领域,主要兴趣为面向构件中间件、工作流、BPEL、SCA/SDO。目前致力于面向服务软件(SOA)的产品定位与产品管理工作。您可以通过MSN:qhyou2002@hotmail.com 与我联系。
构客网首页  博客  论坛

 
  用户信息
 
帐号:  新手必读
密码: 保存密码
 
  分类列表
全部类别(29 篇)
学习笔记(4 篇)
原创(6 篇)
转贴(19 篇)
  按月归档
2005年-10月(2 篇)
2006年-01月(14 篇)
2006年-10月(7 篇)
2007年-02月(5 篇)
2008年-10月(1 篇)
  SOA2007 - SOA实践
我们何时迈向SOA
——SOA在中国的整体发展现状究竟如何?
我们如何迈向SOA
——中国企业如何迈出实施SOA的第一步?
我们应采用何种技术
——SOA国际标准SCA/SDO的具体内涵?
我们还需要何种技能
——SOA将如何改变系统架构设计以及项目管理过程?

显示第 1-10 条记录,共 29 条记录 首页 前页 后页 尾页  到第 页,共 3

BPM给客户带来的主要价值

发布时间:2008年10月30日 作者:qhyou

阅读次数:131次 类别:学习笔记 永久链接 Trackback 
根据Forrester Research的调查,客户对于实施BPM所带来的价值情况:
  1. 提高流程工人的生产率 (24%调查者) Increased productivity for process workers, cited by 24 percent;
  2. 关键流程的实时可见性(18%)Real-time visibility into key processes, 18 percent;
  3. 能够迅速、容易地修改流程的灵活性 (15%) Flexibility to change processes quickly and easily, 15 percent;
  4. 对业务流程建模的能力(13%) Ability to model business processes, 13 percent;
  5. 一致的跨部门流程执行(12%) Consistent process execution across units, 12 percent;
  6. 流程优化(12%) Process optimization, 12 percent.   

结论:

      对于欧美企业,BPM的价值体主要现在三个方面:提高生产率流程实时可见性流程变化的灵活性


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

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

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

、 一、SCA的概念

SCAService 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组件、JMSWS等)

l 导出(Export

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

目前,SCA模型已经得到了业界几个主要软件厂商的支持。IBMOracleBEASAPSiebelSybaseIONA等厂商联合发布了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/)的介绍。

二、 IBMSCA的产品支持

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

目前IBMSCA的产品支持为200510月发布的WPS Websphere Process Server6.0 ,并为之提供了可视化的集成开发工具WIDWebsphere Integration Developer)。使用WID开发集成项目,只要有一定基础编程经验或知识,就可以拖拉的方式,进行图形化的组装,不需要了解太多的J2EE技术细节。

三、 EOSSCA的对比

从上文,可以看出,SCA的这些概念在EOS里几乎都有相类似的概念。对比如下(以IBMWID产品为例):

SCA中的概念

EOS中的

相应概念

相同点

不同点

服务组件

业务构件

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

2、都提供了接口

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

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

模块

项目、构件包

都是可部署的单元

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

导入

引用构件包

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

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

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

导出

导出

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

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

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

服务数据对象SDO

数据实体

1、 1、都是XMLRDB之间的映射

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

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

之二——商业篇

 

四、             IBM WPSWAS

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

IBM WPSSCA的支持

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

IBM WAS6.1 SCA/SDO的支持

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

SCA0.9方面实现的特性:

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

2)  支持标记(Annotaions

3)  支持HttpSession范围的构件

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

SDO2.0的实现的特性:

1)      动态DataObject的支持

2)      基本的静态代码生成

3)      支持静态DataObject

4)      实现了一些帮助类,如XMLHelperXSDHelperTypeHelper

5)      最小化的ChangeSummary支持

DAS(对关系数据库的)支持:

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

2)  存储过程支持

3)  优化的并发控制

4)  数据库自动生成主键

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

五、             普元PrimetonEOS

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

普元EOS 6.0采用全新的产品架构和实现,基于SCASDO等标准化技术,以面向构件(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服务构件”,这是EOSSCA规范的扩充)。

4  EOS 构件模型

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

业务构件通过接口来体现构件对外提供的“Service”,接口的参数类型既可以是普通的Java类型(POJO),也可以是SDODataObject类型。

2、 图形化的SCA构件设计

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

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

5 双向构件设计 

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

                                                

3、  图形化的SDO设计:通过图形化的方式进行域模型设计,并支持每个DataObject之间的关联关系(包括单向和双向的111nn1nn关联)。

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

六、             总结

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


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

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

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

作者:游青华

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

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

 

一、             IT规划出发

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

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

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

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

短期的业务需求一般都是比较明确的,这些系统,往往都是由于企业业务发展的需要而要求必须马上进行建设的,因此对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、计费系统等等基本建设完成。新上线系统大多需要将这些已有系统进行整合,包括流程、信息的整合。如一个服务开通业务流程中涉及到的系统可能包括OSSBSS系统中的功能,并且同时需要进行异步数据交互。

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

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

1、 业务流程跨组织

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

2、 流程的灵活性要求高

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

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

3、 严格的权限控制

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

4、 安全保密要求高

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

三、             其它角度

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

1、 从产品角度

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

l         功能完备性

l         产品稳定性

l         产品开放性

l         产品的性能

l         开发与维护成本