企业应用技术架构的演进

　　企业应用技术架构的演进会经历3个主要阶段：主机架构、客户机/服务器架构、企业服务架构。他们之间的主要区别是：

　　在主机架构下，数据和逻辑是一体的，采用面向过程的设计方法，每个应用是一个孤立的系统，维护相对容易，难于相互集成；

　　客户机/服务器架构将逻辑与数据进行了分离（不论C/S还是B/S模式，本质都是客户机/服务器架构），采用面向对象的设计方法，每个应用是一个孤立的系统，提供了一定后台集成的能力，典型的客户机/服务器架构就是MVC架构；

　　企业服务架构把流程从逻辑中抽象出来，逻辑成为系统对外的服务，通过统一的用户界面、流程打破竖井式结构，采用面向服务的设计方法，企业多个应用之间将成为一个有机的整体。

　　简而言之：目前企业计算的架构正在从关注单系统、单应用的MVC架构向关注多系统、多应用的企业服务架构发展，伴随着支持这种发展，新的技术和产品已经出现。

　　企业服务架构

　　SOBA强调突破应用系统的限制，从整体视图构建企业应用，支持SOBA的企业服务架构采用了SOA的架构风格，以松耦合为特点，将企业应用分为协同、流程、服务、逻辑和资源（数据）5个层面。

　　◆协同层为用户提供了一个统一的交互门户和工作平台，通过RIA（Rich Internet Application）的方式提升用户体验，用户通过协同层更容易以其他人进行协作，例如即时通讯、查看任务列表、查看发布信息，也能够把已有数据、服务或界面快速组合到新应用中。通过协同层，用户不再与多个孤立的系统进行交互，而是面对一个有机的整体；

　　◆流程层维护跨系统之间的业务状态，企业应用的核心是业务流程，流程包括端到端流程和人工参与的流程，流程会产生任务，推送到工作平台。流程把企业中多个应用联接起来；

　　◆服务层将应用系统提供的逻辑以标准化的方式暴露出来，使开发者不需要关心逻辑的对外协议、逻辑的实现方式、逻辑的部署位置，并提供事件的方式降低逻辑间的耦合度，为非侵入式的操作提供基础。

　　◆逻辑层实现了具体的业务逻辑，包括UI逻辑和后台逻辑。逻辑将由多个组件组成，这些组件将以可插拔的方式部署，使用AOP、依赖注入的方式编程，提供逻辑的编排能力；

　　◆资源层解决如何整合数据的问题，需要通过一个统一的数据编程模式统一对不同数据源的访问。

    SOBA基础设施

　　SOBA应用做为企业应用的整体视图，在构建之初就必须考虑到与其他系统的集成问题，SOBA应用应该天然具备集成能力，而不是在构造后再次重新切割。

　　为了实现上述目标，需要有相关技术标准和基础设施的支持，以达到松耦合、非侵入性集成的目的。这些基础设置构建在分布式计算平台之上。

　　◆服务总线

　　服务总线对各系统暴露的对外逻辑进行统一的注册、查找、管理监控、路由，各系统对外暴露的服务统一注册到服务总线，服务调用者不需要关心服务提供者的位置、实现方式等，实现了服务调用者与服务提供者之间的松耦合。为了屏蔽技术细节，服务总线需要提供协议转换的功能，在服务调用者和服务实现者之间转换调用协议；对于不同数据格式接口之间，还需要提供数据转换的功能。

　　SCA标准为服务总线提供了编程模型，实现了协议转换的功能；

　　数据转换的标准一般使用 XSLT；

　　路由、管理、安全等功能可以通过 SCA Policy 实现。

　　◆流程管理

　　业务流程包括端到端流程、人工流程两种，SOBA中流程往往是跨系统的，由流程管理来协调系统之间的业务流转。一般来说，流程管理编排服务总线上暴露的服务。企业通过对流程的管理可以监控企业的运行状况，并通过对流程的优化提高企业对业务的响应时间，降低运营成本。

　　流程管理负责把在流程协调的同时，产生相关人的任务，推送到个人工作台。

　　BPEL、BPEL4People、Human Task、WfMC都是实现流程管理可参考的标准

　　◆事件管理

　　提供对业务事件的支持，帮助各业务模块间实现松耦合。业务逻辑发出事件后不需要关心事件消费者。通过业务事件的方式，可以实现系统间非侵入式的集成。

　　◆构件容器

　　在SOBA整体视图中，应用将以一个或多个业务模块的方式出现，而不再是一个或多个物理上的系统。业务模块的部署是动态的，可以随着业务的发展变更部署方式，这就需要业务模块能够以构件的方式，支持动态的、可插拔的加载方式。

　　此外，构件容器需要支持业务扩展点的方式，在加载新的业务模块时动态增加新的功能。

　　◆RIA

　　RIA解决方案支持SOBA提供更好的用户体验。除了能支持交互密集型的应用外，RIA能够成为新一代的Portal，允许终端用户控制他们自己的业务逻辑组合，将门户信息和本地数据资源集成，甚至离线获取门户信息。RIA还能够提供Mashup的功能，让用户更容易配置自己风格的应用。
　　◆报表服务

　　报表服务为SOBA提供了更多丰富的数据表现手段，用户可以用仪表盘、图表等方式查看数据，并提供一种支持对复杂、变化数据的持续更新、事件驱动、异步和高互动性的存取方式。

　　◆规则服务

　　规则服务通过降低实现复杂业务逻辑构件的复杂性，降低SOBA应用的维护和可扩展成本。

　　◆统一数据访问

　　目前有多种数据的访问方式，SOBA需要一个统一的数据访问层，以一种可以服从工具和框架的易用方式为不同的数据源提供一种数据访问解决方案。

　　SDO技术提供了这样一种实现。

　　SOBA的核心技术

　　◆SOA时代的Spring ：SCA

　　服务构件架构(Service Component Architecture, SCA)为构建建于SOA的应用和解决方案提供了一套编程模型。它的基本理念是：业务功能都是用服务来描述的，通过将这些服务进行组装就可以提供新的业务；在组装的过程中，可能需要新开发一些服务，也可能从企业已有点业务功能重抽取出服务，而进行重用。使用SCA装配模型，我们可以方便的将构件的服务，暴露为不同的调用协议，实现 SOBA 中对各业务模块间服务整合的功能。

　　SCA借鉴了Spring的思想，采用了依赖注入的方式，建立服务构件的属性、以及服务构件间的引用；使用AOP的方式设置服务、引用的事务、安全等策略；使用绑定的方式支持多协议的转换，类似Spring的Exporter；支持通过名称空间扩展的方式对SCA配置文件进行扩展。和Spring不同的是，SCA支持多种语言（Java/C++/PHP等），也支持使用多种实现方式实现服务构件（Spring、BPEL），同时更灵活的支持实现、协议的扩展方式，更加适合 SOBA 多业务模块间集成的功能。

　　简而言之，SCA为SOBA应用开发提供了一个框架，是面向服务架构下的Spring。

　　◆SOA时代的DTO ：SDO

　　在B/S 结构下编程，通常会使用DTO对象，SOBA应用也同样需要，但是SOBA需要能够更加灵活的数据接口，可以屏蔽不同的数据源，SDO提供了这一解决方案。

　　SDO技术提供了静态接口，静态的强类型接口可以为应用程序员提供一种使用编程模型的简单方式；

　　但是只有静态数据API是不够的，如果你在编写代码的时候使用了Map做为接口，意味着你需要一个动态的数据作为接口，SDO 的动态接口支持增加静态接口定义中没有的属性，为数据带来了更大的灵活性；

　　SDO支持内省的API，可以通过 XML Schema 进行定义，建立了和XML Schema之间的映射关系，消除了XML to Java之间的不匹配，为异构系统间数据传输提供了便利，我们不需要再使用诸如 jaxb 那样怪模怪样的Java代码了；

　　SDO内嵌了对 XPath 的支持；

　　SDO支持离线数据的管理，提供了变更记录，能够在数据处理的过程中保持数据的变化，在Hibernate中也有类似的实现，但SDO可以在系统间、系统内部都维护这种变化。

　　简而言之，SDO提供了更为灵活的数据访问方式，以适应 SOBA 应用复杂多变的数据结构，是面向服务架构下的 DTO。

　　◆BPEL/BPEL4People

　　BPEL为企业构建面向服务的端到端业务流程解决方案提供了一套规范，其通过对来自不同异构系统的细粒度服务的编制，提供更为业务性、大粒度的有状态服务。BPEL标准为为不同参与者间的有状态的、长期的交互的业务流程提供了行为的描述模型。如果在一个SOA的环境中有一组代表业务流程各组件的服务，BPEL提供了一种能够把这些服务集成到完整业务流程当中的方法。

　　虽然企业端到端的业务流程更讲究多系统多服务的整合，但也必不可少人工任务的参与。为了更加规范人工任务的处理以及与业务流程交互的标准化，OASIS组织在又推出了两个与BPEL关系密切的补充规范，即”WS-BPEL Extension for People”和”WS-HumanTask”。这两个规范扩充了WS-BPEL 2.0，使得它在业务流程中能够集成和支持人工任务。其中”WS-HumanTask”规范了人工任务的描述，比如什么任务需要被执行，谁来执行这个任务，哪些是相关人员，何时任务被执行以及若没有按时执行需要怎么处理等等。

　　◆OSGI

　　OSGI是面向Java的动态模型系统，为业务模块的可插拔提供了基础。未来SOBA应用中的业务模块可以采用OSGI的格式进行动态的部署。

　　面向服务架构时代，对企业应用提供了更新的要求，构造SOBA（面向服务的商业应用）是我们面临的迫切问题。在SOBA中，企业应用的体系架构将从以MVC为代表的单系统架构发展为更加考虑系统间集成性的企业服务架构，相关技术的出现也给程序员带来了新的挑战和机遇，让我们一起，拥抱这个新的变化。