论文部分内容阅读
摘 要：如何在原有信息系统的基础上进行业务流程重组关系到企业竞争力的提升以及能对市场快速反应的敏捷企业的构建。本文在介绍EJB、WEB SERVICES、SPRING等分布式技术的基础上，以信息系统耦合度为主要指标，分析了传统面向对象的体系结构特点，并提出可配置面向对象体系，用于搭建可自动业务流程重组的信息系统。
关键词：业务流程重组 面向对象 分布式系统
一、几种流行的分布式技术对BPR的支持
分布式对象技术旨在建立一个开放式的软件总线结构.从而满足异构环境下系统的集成。分布式应用系统能运行于各种软件和硬件平台.能够将旧的应用同新的应用集成起来并且使原有的架构继续得到利用。另外。企业级的分布式应用在伸缩性、高可用性、易管理性、高性能及数据的完整性等方面也得到实现。虽然分布式技术最早是为了解决异构访问而提出的.但是其固有的开放结构为系统开发提供了较小的技术耦合.从而使BPR成为可能。J2EE环境中比较流行的分布式技术包括EJB（Enterprise Java Bean。企业Java bean）、WEB SERVICES和SPRING（严格地说.SPRING是一种J2EE框架，不是纯粹的分布式技术。但它对分布式有很好的支持.这里将其作为分布式技术进行讨论）。
EJB技术以Java Bean技术为基础。充分利用Java的跨平台能力。结合接121技术的应用.能够使服务以一种”黑盒”方式进行调用，因此调用者与被调用服务之间的耦合度大大降低。
日B组件技术保证了系统的可扩展性的提高.利于BPR的实现。
WEB SERVICES以SOAP（Simple Object Access Protocal.简单对象访问协议）通信协议为基础。在服务提供者与调用者之间实行一种弱绑定。同时服务利用标准WSDL（Web Service DescripfionLanguage。web服务描述语言）对服务进行描述并定义访问接121，在方法调用层次上实现了较高的松耦合度.比EJB的组件层更灵活。实际上目前很多实现BPR的企业均是采用WEB SERVICE模式。
SPRING是一种优秀的J2EE框架.其技术基础一依赖注入（dependence injection）以及面向切面编程AOP（Aspoet Oriented Programing）分别从类层次与方法层次降低耦合度、同时SPRING支持的JMS（Java Message Service，Java消息服务）、Remoting和WEBMVC等也可以用于构建松耦合度的信息系统。以上各种分布式技术各有特点.分别从不同的方面消除了系统的技术耦合。这些技术都是建立在面向对象编程OOP（Object Oriented Pmgraming）的基础之上，OOP主要是为了解决面向问题域的开发以及代码重用问题的。因此不可能对BPR有足够的支持.下面着重探讨OOP体系在BPR实现方面的限制以及如何对OOP进行改良.以便适应BPR的需要。
二、面向对象技术与BPR
OOP技术发展至今已有近20年的历史.从最早的simula到如今的面向切面开发.OOP技术都是J2EE信息系统开发的主要技术支撑。OOP技术主要是为了解决软件复用性问题而提出的.其三大特性封裝、继承及多态与两种基本体系（基于继承、基于接口）相互配合.的确大大增加了代码的可重用度，同时提高了系统的可扩展性。但纯粹的OOP技术对于BPR却没有足够灵活的支持.造成BPR实现的困难。造成上述现象的主要原因是在传统OOP基础上开发出来的系统其各个构件之间的耦合度过高（这里的构件是主要指OOP层次的.传统信息系统要在模块层次才具有较低的耦合）BPR的关键就是各个构件的耦合度尽可能的低。构件可以指代各种不同的耦合层次.由下到上分别是：方法、类、组件、功能、模块等。不难看出，在构件层次中，越靠下的层次的耦合度越低.就越容易实现BPR。
一般来说.可以将J2EE系统抽象成五个部分：边界类、业务逻辑类、控制类、业务实体类、业务数据实体类。业务实体类是对企业业务流程中的业务对象进行建模得到的.企业的任何业务都是在实体之间触发的：业务数据实体是业务实体中特殊的一种.是对业务数据模型的抽象，业务逻辑类是一种规定在业务数据实体之上的”运算法则”.是业务规则的抽象；控制类用于控制、调度逻辑类对业务数据实体类的运算并协调各种其他业务实体的关系：边界类用于界定业务逻辑类或控制类的作用范围，同时定义业务实体类及业务数据实体类的可见性和生命周期。对于任一业务系统而言.业务可以视为“数据+逻辑”的组合，在OOP的层次上，即对应业务数据实体类及业务逻辑类。要实现可自动重组，关键是构造出耦合度足够低的业务系统。 传统OOP中.类属性都有访问范围，OOP利用它来实现封装，如果映射的属性具有不同的访问范围，则逻辑类进行处理时仍会出现问题.在业务系统中。类属性的访问范围一般不是用于实现纯粹的OOP封装特性，更重要的是访问权限的配置，这一般是通过角色/账户等机制实现的.没有一定的账户权限，即使逻辑类拥有对数据实体类完全的访问.仍是没有意义的。权限机制在这方面与访问范围功能上有所重复，因此在数据实体中，完全可以不考虑属性访问范围.而利用权限分配得到保障。经过类的映射机制.逻辑类与实体类的耦合度进一步降低了。耦合仅在于映射中。但传统信息系统难以进行BPR的另一重要原因是逻辑类之问的耦合度太高.通常一个比较复杂的事务常常需要几个逻辑类进行协同工作.伴随着逻辑类之问方法的相互调用.这时便形成一条调用链。这个调用链的任何一环都是通过类名以及类方法签名紧密耦合的.因此任何对这两者的改变（无论是调用者或被调用者），都会引起调用链的脱节。在一个松耦合的系统中，调用链是可以运行时配置的（软配置），可并发的调用链分别封装在不同的边界类中。调用链可以灵活的方式进行配置。组成调用链的方法隶属于某一边界类的分类原则不是固定的.应根据企业的业务情况改变而改变。大体上有两大原则，一是以业务实体类作为分类原则.一般适用于DSS等，另一是以事务功能为分类原则，比女IIERP：前者业务数据实体会对业务方法产生影响，后者则主要在于体现事务功能.对于系统中不同的业务实体都是一样的。无论在哪一种体系中.配置型调用链都必须要有一种机制来保证方法调用的正确性。称之为约束。在这种体系中，约束也是以配置文件形式出现的.将原本阻碍方法之间进行调用的部分分离出来作为独立的因素。可以提高系统的松耦合度。进行BPR时可以优先考虑对约束进行修改，以便适应新的业务需求。调用链还有一个好处是，可以方便地进行回滚操作。
作者简介：孙茜（1975-），女，浙江杭州人，江西科技学院商商学院工程训练中心，本科。研究方向：面向对象技术。
关键词：业务流程重组 面向对象 分布式系统
一、几种流行的分布式技术对BPR的支持
分布式对象技术旨在建立一个开放式的软件总线结构.从而满足异构环境下系统的集成。分布式应用系统能运行于各种软件和硬件平台.能够将旧的应用同新的应用集成起来并且使原有的架构继续得到利用。另外。企业级的分布式应用在伸缩性、高可用性、易管理性、高性能及数据的完整性等方面也得到实现。虽然分布式技术最早是为了解决异构访问而提出的.但是其固有的开放结构为系统开发提供了较小的技术耦合.从而使BPR成为可能。J2EE环境中比较流行的分布式技术包括EJB（Enterprise Java Bean。企业Java bean）、WEB SERVICES和SPRING（严格地说.SPRING是一种J2EE框架，不是纯粹的分布式技术。但它对分布式有很好的支持.这里将其作为分布式技术进行讨论）。
EJB技术以Java Bean技术为基础。充分利用Java的跨平台能力。结合接121技术的应用.能够使服务以一种”黑盒”方式进行调用，因此调用者与被调用服务之间的耦合度大大降低。
日B组件技术保证了系统的可扩展性的提高.利于BPR的实现。
WEB SERVICES以SOAP（Simple Object Access Protocal.简单对象访问协议）通信协议为基础。在服务提供者与调用者之间实行一种弱绑定。同时服务利用标准WSDL（Web Service DescripfionLanguage。web服务描述语言）对服务进行描述并定义访问接121，在方法调用层次上实现了较高的松耦合度.比EJB的组件层更灵活。实际上目前很多实现BPR的企业均是采用WEB SERVICE模式。
SPRING是一种优秀的J2EE框架.其技术基础一依赖注入（dependence injection）以及面向切面编程AOP（Aspoet Oriented Programing）分别从类层次与方法层次降低耦合度、同时SPRING支持的JMS（Java Message Service，Java消息服务）、Remoting和WEBMVC等也可以用于构建松耦合度的信息系统。以上各种分布式技术各有特点.分别从不同的方面消除了系统的技术耦合。这些技术都是建立在面向对象编程OOP（Object Oriented Pmgraming）的基础之上，OOP主要是为了解决面向问题域的开发以及代码重用问题的。因此不可能对BPR有足够的支持.下面着重探讨OOP体系在BPR实现方面的限制以及如何对OOP进行改良.以便适应BPR的需要。
二、面向对象技术与BPR
OOP技术发展至今已有近20年的历史.从最早的simula到如今的面向切面开发.OOP技术都是J2EE信息系统开发的主要技术支撑。OOP技术主要是为了解决软件复用性问题而提出的.其三大特性封裝、继承及多态与两种基本体系（基于继承、基于接口）相互配合.的确大大增加了代码的可重用度，同时提高了系统的可扩展性。但纯粹的OOP技术对于BPR却没有足够灵活的支持.造成BPR实现的困难。造成上述现象的主要原因是在传统OOP基础上开发出来的系统其各个构件之间的耦合度过高（这里的构件是主要指OOP层次的.传统信息系统要在模块层次才具有较低的耦合）BPR的关键就是各个构件的耦合度尽可能的低。构件可以指代各种不同的耦合层次.由下到上分别是：方法、类、组件、功能、模块等。不难看出，在构件层次中，越靠下的层次的耦合度越低.就越容易实现BPR。
一般来说.可以将J2EE系统抽象成五个部分：边界类、业务逻辑类、控制类、业务实体类、业务数据实体类。业务实体类是对企业业务流程中的业务对象进行建模得到的.企业的任何业务都是在实体之间触发的：业务数据实体是业务实体中特殊的一种.是对业务数据模型的抽象，业务逻辑类是一种规定在业务数据实体之上的”运算法则”.是业务规则的抽象；控制类用于控制、调度逻辑类对业务数据实体类的运算并协调各种其他业务实体的关系：边界类用于界定业务逻辑类或控制类的作用范围，同时定义业务实体类及业务数据实体类的可见性和生命周期。对于任一业务系统而言.业务可以视为“数据+逻辑”的组合，在OOP的层次上，即对应业务数据实体类及业务逻辑类。要实现可自动重组，关键是构造出耦合度足够低的业务系统。 传统OOP中.类属性都有访问范围，OOP利用它来实现封装，如果映射的属性具有不同的访问范围，则逻辑类进行处理时仍会出现问题.在业务系统中。类属性的访问范围一般不是用于实现纯粹的OOP封装特性，更重要的是访问权限的配置，这一般是通过角色/账户等机制实现的.没有一定的账户权限，即使逻辑类拥有对数据实体类完全的访问.仍是没有意义的。权限机制在这方面与访问范围功能上有所重复，因此在数据实体中，完全可以不考虑属性访问范围.而利用权限分配得到保障。经过类的映射机制.逻辑类与实体类的耦合度进一步降低了。耦合仅在于映射中。但传统信息系统难以进行BPR的另一重要原因是逻辑类之问的耦合度太高.通常一个比较复杂的事务常常需要几个逻辑类进行协同工作.伴随着逻辑类之问方法的相互调用.这时便形成一条调用链。这个调用链的任何一环都是通过类名以及类方法签名紧密耦合的.因此任何对这两者的改变（无论是调用者或被调用者），都会引起调用链的脱节。在一个松耦合的系统中，调用链是可以运行时配置的（软配置），可并发的调用链分别封装在不同的边界类中。调用链可以灵活的方式进行配置。组成调用链的方法隶属于某一边界类的分类原则不是固定的.应根据企业的业务情况改变而改变。大体上有两大原则，一是以业务实体类作为分类原则.一般适用于DSS等，另一是以事务功能为分类原则，比女IIERP：前者业务数据实体会对业务方法产生影响，后者则主要在于体现事务功能.对于系统中不同的业务实体都是一样的。无论在哪一种体系中.配置型调用链都必须要有一种机制来保证方法调用的正确性。称之为约束。在这种体系中，约束也是以配置文件形式出现的.将原本阻碍方法之间进行调用的部分分离出来作为独立的因素。可以提高系统的松耦合度。进行BPR时可以优先考虑对约束进行修改，以便适应新的业务需求。调用链还有一个好处是，可以方便地进行回滚操作。
作者简介：孙茜（1975-），女，浙江杭州人，江西科技学院商商学院工程训练中心，本科。研究方向：面向对象技术。