软件部署的研究

通过对服务流程化的组织来构建分布式系统的模型，既是体系结构模型，又是编程模型。这种松散耦合的分布式系统，具有复用度高和扩充性好的优点。

随着学校对教学、科研、设备和生活服务等信息的数字化管理，学校内部的计算机应用系统越来越多。这些应用系统服务于不同的职能部门，实现了各职能部门内、外业务的管理。

但是由于这些应用系统是在不同的时期、采用不同的技术独立开发的，所以造成各系统之间缺乏信息共享和交互，很多功能和数据是交叉、甚至是重复的。

要实现科学规范的管理，就应当对这些应用系统进行整合和集成，以构成统一的用户管理、统一的资源管理和统一的权限控制，把学校建设成面向校园内，也面向社会的一个超越时间、超越空间的大学。

SOA可以不考虑各应用系统的运行平台和开发环境，而使被重用的模块方便地由旧系统纳入新系统。

SOA的体系结构及特征

面向服务的架构(Service Oriented Archetecture SOA)是Gartner在1996年提出的，到了2002年12月，Gartner又提出了SOA是“现代应用开发领域最重要的课题”，并预计到2008年，SOA将成为占有绝对优势的软件工程实践方法。SOA是一个组件模型，他将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。

图1 SOA 的结构

图2 Web服务协议栈

接口是采用中立的方式进行定义的，他应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

服务请求者 需要使用服务的应用程序或其他的服务。通过对注册中心的服务进行查询，根据接口说明信息并使用某种传输协议与服务绑定来执行服务功能。

服务提供者 创建服务的实体。可以从服务消费者处接受请求并远程执行所请求的服务。通过向注册中心服务接口信息以供服务消费者发现和访问服务。

服务注册中心 展示服务的功能。服务消费者通过查询存储有服务信息库的注册中心，找到所需服务的接口信息。

为了被访问，服务的描述信息必须被以便服务消费者发现和调用。发现服务请求者通过查询注册中心去定位符合其需求标准的服务。

绑定和调用 在获得服务描述信息之后，服务消费者据此去调用服务。

SOA的特征

SOA有众多的特征，其中非常重要的几条包括:

松耦合

服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台等。

服务请求者往往通过消息调用操作即请求消息和响应而不是通过使用API和文件格式。这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。

在一个极端的情况下，服务提供者可以将以前基于遗留代码(例如COBOL)的实现完全用基于Java语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真实的，只要新代码支持相同的消息模式。

明确定义的接口

服务交互必须是明确定义的。web服务描述语言(Web Services Description Language，WSDL)是受到广泛支持的方法，用于描述服务请求者所要求的绑定到服务提供者的细节。

服务描述的重点在于与下面几部分交互所用的操作:服务、调用操作的消息、构造这种消息的细节。

关于向何处发送用于构造这种消息的处理细节的消息的信息;WSDL不包括服务实现的任何技术细节。

服务请求者不知道也不关心服务究竟是由Java代码、C、COBOL，还是由某种其他的程序设计语言编写的。他可以描述使用HTTP的SOAP调用。

图3 高层抽象的Domain

图4 Service管理及分布

由于他的扩展机制，他也可以定义其他类型的交互，比如通过JMS提交的XML内容、直接方法调用、由管理遗留代码的适配器处理的调用(CICS)等。

WSDL的通用定义允许开发工具创建各种各样类型的交互的通过接口，同时隐藏他是如何由应用程序代码调用服务的细节。

例如，如果服务是以多种交互类型公开的，Web服务调用框架(Web Services Invocation Frame work，WSIF)通过允许运行时决定调用高质量服务的最优方法来使用这种能力。

无状态的服务设计

服务应该是独立的、自包含的请求，在实现时他不需要从一个请求到另一个请求的信息或状态。

服务不应该依赖于其他服务的上下文和状态。当需要依赖时，他们最好定义成通用业务流程、函数和数据模型，而不是实现构件(比如会话密钥)。当然，请求者应用程序需要服务调用之间的持久状态，但是这不应该与服务提供者分开。

服务粒度

操作的粒度是一项重要的设计要点。对于外部的消耗推荐使用粗粒度的接口，而细粒度的接口可能用于企业内部。

虽然细粒度的接口为请求者应用程序提供了更多的灵活性，他同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。

粗粒度接口保证服务请求者将以一致的方式使用服务。

面向服务的体系结构(SOA)不要求使用粗粒度接口，但是推荐使用他们作为外部集成的最佳实践。

服务编排可以用来创建运行由细粒度操作组成的业务流程的粗粒度接口。

Web Service的核心技术

SOA代表着一种标准化、松耦合、粗粒度的软件体系结构，代表着一种不拘泥于具体实现技术的新的软件开发思想。

从SOA强调跨越异构平台和不同开发环境方面考虑，Web Service是目前分布式技术中符合SOA提倡标准化的不多的选择之一，所以在实践过程中往往被优先考虑。基本的Web服务栈由SOAP，WSDL，UDDI等技术组成，其服务栈结构如图2所示。

图5 服务规划

图6 平台软件买施视图

数字化校园平台分析

这里以一个高校的数字校园系统平台为实例，进行SOA应用部署的研究。该学校各部门已经建立了各自的应用系统。由于是部门独立开发，没有从学校的整体进行考虑，致使各系统之间的数据和功能等内容不能共享，出现数据的重复收集和功能的重复开发等弊端。随着校园业务的逐步扩充，系统访问范围的进一步扩大，迫切需要解决以下问题:

(1)各系统间的数据能充分共享。

(2)各系统间的功能可以高度复用。

(3)可以实现对整个校园系统的全局管理、控制。各系统间构成一种松散的联合。

(4)系统具有扩充能力。

(5)系统具有向下兼容能力。让原有系统在做最小改动的情况下，满足要求。

(6)系统需提供安全、可控的服务访问。

引入SOA架构可以解决上述问题，并使原有的应用得以延续，又能够为新应用的部署提供一种灵活的扩展平台。

SOA在校园系统中的应用

要对校园内存在的各种运行于不同环境的应用系统、数据、及其用户实现功能与数据的共享，就应当把原来属于具体应用系统(APP)的功能(service)、数据(data)及用户(user)独立出来，其高层抽象的Domain如图3所示。

在这个Domain下，应用程序成为建立的平台下的元素，这些元素构建一个分布的系统。该系统可以使用基于Web Service的SOA架构进行实现。

SOA的核心是服务，因此部署SOA的重点就是如何管理服务。由于系统服务将以Web Service形式分布于各子系统中，所以需要提供一种自己的服务管理来定位和这些分散的服务，以保证服务的正确访问。

实质上这是一个UDDI的本地实现。但是对于本案例来说，并未完整实施庞大的UDDI，而是采用了一些简单的替代方式，其实现如图4所示。

因为SOA是开放的，所以在支持功能复用时，必须考虑其安全性，如:教师的资料、科研资料等等。

在此应用中，提供了安全认证服务措施来解决这个问题，实施认证与受权策略必须得到Web Service服务提供者的支持。对于校外用户的访问，还必须先结合防火墙从更低层保障安全。

由于该校原有应用程序多是采用Microsoft．net平台技术开发，在核心服务实现上以．net技术为主，一些基本网络信息服务，其运行环境为Unix／Linux系统。系统基本划分为以下几部分：

支撑系统：包括email服务、账号管理系统、流量统计；学生管理：新生入学注册等系统；师资管理；教学管理：初步建立学分制教学管理系统；后勤工作管理系统。

最后，可对各应用系统所涉及的数据、服务进行分析、规划和建模，明晰各服务间交互关系，如：学生管理系统、师资管理系统、教学管理系统和后勤管理系统。

为了将分布式的系统作为一个整体呈现给用户，用户与权限环境将是全局的，需要建立一种用户共享机制和权限的全局设置机制，即建立一种跨系统的用户注册(registration)，认证(authentication)，授权(authorization)机制，单一登录(single sign on)机制，以取代原有系统的各自的用户认证过程。

权限控制与应用系统注册、服务注册紧密结合，应用程序及服务被要求完成注册，以目录树结构定义自己的功能节点视图，所有权限绑定到功能节点，所有功能通过权限分配给用户。根据之前讨论的服务管理和安全策略，该规划如图5所示。

上述规划获得不同服务，基本上可分为2类。

一类为实现集成的支撑服务(core service)，构建其他应用系统得以交互的基础;另一类为应用服务(business service)，严格依赖于各部门的业务。根据服务的应用级别、部署需要结合软件系统的设计模式。平台软件实施视图如图6所示。

至此，SOA在数字化校园系统中的规划、部署基本完成，今后当业务需求发生变化，只对Service或应用程序进行调整、扩展即可，对平台没有影响。

对原有系统使用Web Service部署SOA，可以节省IT扩展的投资。

因为不需要重新创建系统，只要利用原有资源和资产，就可以使不同部门的应用系统集成到S0A的基础架构中，从而使基础架构成为商品化的元素。

同时服务组件的创造性重用也可以缩短设计、开发、测试和部署产品的时间，也会降低项目开发过程中的风险。业务逻辑流程模型的清晰表示和优化可进一步改进所部署的应用系统的功能。

由于SOA自身具有的优势符合未来软件发展的趋势，他必然会成为成熟的下一代主流开发技术，而得到广泛支持和应用。