基于SOA的物流平台设计与实现

1 面向服务架构

实施SOA包含3个技术理念:服务, 企业服务总线和松耦合。既然被称为面向服务架构, 那么服务也就是架构和核心, 我们该如何理解服务呢?参照在OASIS SOA Reference Model中的定义, 功能 (方法) 的提供者就是服务。这样的定义还是等于没定义, 对技术人员来说, 服务其实就是一个接口, 提供别人使用, 对程序而言就是一个方法, 但方法的定义是多种多样的, 你可以把增删改包装成一个接口, 也可以提供多个接口, 当然按照REST的Services我们还是要对每一个操作提供一个服务。因此我们尝试去寻找除了简单的方法之外, 服务还应包含的东西。

1.1 可传递性

可传递性是基于协议之上的。为了打造面向服务的体系架构, 一般我们将提供一种基础服务, 其本身用来封装底层协议的一些技术细节, 目的就是为了提供一致的功能, 这样对程序员来说也不用关心太底层的东西, 可以更加专注的提供业务实现上的支持。一般这些基础服务不包含任何的商业逻辑, 而是为上层的服务提供功能上的支持, 为的就是更好的将逻辑和实现区分开来, 以解耦合。往往我们需要多种这样的基础服务用来封装不同的协议, 伴随着可传递性, 我们还需要服务可注册和可发现, 只有有了固定的位置, 服务才能被调用。

1.2 可支配性

这是服务被关注最多的特性, 服务和服务之间必须是可交互信息的, 不管我们使用的哪种整合, 它都应该提高系统之间的交互, 使参与其中的应用系统可以协同工作。这对于整合是非常重要的, 实际上其承担了很多的任务。

首先我们需要辨别出数据来源自哪里, 来自不同服务中的数据被聚合在一起。这被称作集合。因为数据从不同的来源被收集起来以体现一个业务概念, 例如一张发票或者订单。

其次数据将会被传递。我们会再次混合已存的和新产生的系统。因为每个系统有可能采用不同语言编写的, 这样提供出来的数据格式因为语言的不同而不同, 这需要我们在各个系统中采用统一的规范, 使每个具体的应用系统都可以使用。

最后返回的结果也要一致性, 这样才能构成一个集成的整体。这个部分被成为合成, 意思是将结合成一个有意义的商业概念。

1.3 事务性

整合必须提供解决实际问题的事务性方法。也就是说, 能够处理在不同原有系统和新系统中发生的一系列操作, 还必须支持事务的ACID特性和具有赔偿性的长事务管理, 通常和商业事务是息息相关的。

安全, 整合系统应该提供系统访问权限, 虽然集成的各个子系统可能有其自身的身份验证逻辑功能, 但是集成后的系统要提供一个统一的身份验证, 也就是单点登录。这个安全系统不应该以不同的密码, 不同的应用程序, 甚至部分应用程序为基础, 而应该与所有重要的方面有关联, 例如加密技术, 鉴定, 授权和审核。

1.4 生命周期

整合结构应该提供一个可以控制所有有关应用程序生命周期的方法。通过这个方法, 可以使现有的程序实现全部或部分的替换而不会影响整合系统中的其他程序。当出现业务指令而且有足够的可用资源的时候, 可以一步一步的实现替换。这种替换应该在系统在线的时候也可以实现。这项功能通常是通过最小化应用程序之间的联系和具体化应用程序的时候实现的。

1.5 唯一性

一个标准的命名服务可以实现所在地的透明性和改变资源。命名服务通常是通过一个命名和目录来存储和查找与命名相关的信息的。理论上来说, 命名服务是统一的, 它可以为一个企业提供一个合理的图片。但是实际实施过程中通过复制和分类可以避免某一个点的错误。

1.6 可管理性

整合系统也需要一个管理方式。管理层应该为水平的和垂直的服务提供方法和工具。我们需要一个简单的可配置的, 可版本控制的管理功能。一个公开的管理系统应该能不需要修改源代码就可以改变和提高性能。远程的管理层能使管理从较远的地点实施, 从而最小化了对现场专业人员的需要。

2 集成方式

集成一般来说是指应用系统中多个层次的整合。是把一个问题, 分解为多个小的问题, 又将小问题分散到系统中的各个层次上。这样对每个小问题的解决将更加的快速和可控制。大体上可以将集成分为如下层次 (见图1) :

2.1 数据集成

数据集成关注的是在不同的应用系统中移动和共享数据库中的数据。虽然访问数据库的技术不难, 但是要实施数据集成却并不简单。问题在于数据库的复杂性。需要了解什么样的数据以什么样的形式存储在什么样的数据库中, 和什么时候及如何将这些数据提取出来。当然最重要的是对目的数据库的形式和结构的熟悉。只有这样才能将数据存储为所有应用系统都能识别的形式并且在使用这些数据时不会打破数据库的一致性。但实际的情况是, 数据库的集成在很大程度上依赖于数据库采用的技术, 并且数据库自身也因为产品的不同而造成数据结构的不一致。除非各个系统的数据存储方式的都一样否则很难真正实现数据层面上的集成。另外的一个客观因素是一般对数据的访问都是严格受限的, 为了访问到这些数据我们还是不得不去调用相应的程序接口, 如此说来仅仅依靠数据集成的方式很难达到我们的集成目的。

2.2 程序集成

程序集成面临的困难是, 不是每个系统都有预留的接口可供调用, 就算是有接口调用, 不同系统采用的不同语言, 让我们不得不寻找合适的方法去调用他们。因此程序集成面临的2个需要解决的问题:首先是理解程序本身的用途, 其次就是消除不同语言之间的隔阂。后者是通过暴露出接口APIs的服务来实现的。为此之上人们提出了建立一个ESB (Enterprise Service Bus) 企业信息总线来整合各个系统所提供的服务, 并将这些服务集合到总线中来。接口在应用系统之间建立了一个关联。只要接口保持不变, 就意味着各系统之间的关联不变。同时这也意味着接口将各个不同的信息系统连结成一个整体。这样我们可以充分发挥出针对接口编程的优势, 因为我们并不关心提供功能的具体实现是什么。只要接口保持不变, 我们可以在不改变整个信息系统和部分应用系统的情况下改变某个应用系统。

2.2.1 业务集成

当一个业务逻辑需要多个系统参与时, 我们要进行业务集成, 这需要我们将各个系统中的功能高度的抽象化。业务集成利用各个系统提供的服务功能的接口, 并根据接口组织成一个业务流程, 业务集成是我们利用系统的各个服务, 更加准确的解决实际需求中的问题, 我们不需要通盘否决历史遗留的系统, 那么肯定需要我们用新的技术对原有系统进行新的设计和封装, 才能用在我们的业务流程中, 并且为了将这些服务以自然的语言描绘出来, 通常人们使用BPEL (Business Process Execution Language) 工作流来描述实际的业务逻辑。有了更贴近自然语言的工作流, 我们就能更好的用计算机模拟现实的需求, 也能够更加专注的关注业务部分, 实现业务和技术的分离, 实现高度的松耦合。

2.2.2 显示集成

通常在完成了业务逻辑整合之后, 我们需要最后的工作就是表示层的集成。显示集成的结果就是为系统的整合提供了一个统一的显示平台, 用户可以进入这个集成系统的功能区。由于他们使用的是新开发的显示平台, 可能无法关注到现存的应用系统的多样性。显示平台通过提供商业连结, 使普通的接口也可以进入。因此, 显示平台就被隔离了并且不用关注现存应用系统的细节。

随着统一的显示层的发展, 我们隐藏了不同应用的背景, 系统遗留问题, 和其他新开发的东西。这样我们就提高了最终用户的效率, 并提供了不影响系统其他部分而改变遗留系统。

我们不应该将显示集成看成一个简单的用户接口的集成, 插入网页, 图表这类的整合, 这些我们通过应用系统的扩展就可以实现。我们也不应该将显示集成当成一种从现有的应用系统中提取数据的方式。

2.3 B2B集成

集成的最高阶段就是企业的相互集成, 企业的迅速成长使得企业间的服务也需要整合, 因为一个企业不可能行行做的出色, 当它需要其他领域的专业服务时, 他可以选择商业集成来获取更加全面和专业的信息。现在, 一个公司内部的应用系统整合已经远远不够了。企业间整合的需求越来越迫切, 这被称作B2B集成或者电子商务 (E-Business) 。在网页上发布产品分类已经过时, 现在需要的是在线的即时性信息, 和可靠性的品质。即使是知名的传统业务, 如果不付出努力, 在商务电子环境中也不能保持其地位。当然, 高效的电子商务或者B2B整合的先决条件是企业的信息集成系统的建立。现在的用户所希望的是即时的回复, 而不满足于慢节奏的等待。但事实是如果电子商务没有企业信息集成系统支持则无法成功。企业信息和显示系统是即时回复成功的关键。这看起来显而易见, 但现今的许多实例证明企业信息和显示平台的整合通常都是不充分的。这就导致了电子商务的功能不能很好的得以实现。主要的原因就是企业信息整合的不足, 这是影响电子商务是否成功的一个关键因素。另一个重要因素就是大部分显示系统都可以使用现有的和遗留的系统作为企业信息系统。使这两种系统充分的融合是成功的关键因素。为了更好的在各个层次上实现可集成, 对我们的系统提出了多层结构和高度的松耦合。

3 ESB建设和服务整合

在一个组织或者部门中谈到ESB的实施时都需要有一个对ESB管理层的总体理解。本质上来说, ESB是一个解决整合问题的技术产品。让我们从ESB的技术层面来探讨一下其优势。

下图表示的是不通过EAI和ESB如何将应用程序整合起来, 这被成为点对点结构 (见图2) :

这个应用显示的还是解决整合问题的一般方式。在这个例子中, 4个现存的应用通过点对点的方式整合到一起。点对点模型最基本的就是必须使用和保持的客户定制整合方案的数量。如果我们在应用域中增加一个新的应用, 复杂性和维护费用就会相应增加。我们要将新的应用与原有的环境整合在一起需要实施一个将三个应用整合在一起的整个方案。在这种应用环境下, 我们就应该考虑下想ESB这样的整合方案。有这样的整合应用程序的商业驱动器吗?在大多数组织中, 一个真实的商业活动都需要应用整合。新商品必须今天送达市场而不是明天, IT环境中也必须能够做到这点。ESB可以帮助提高IT环境的灵活性, 从而帮助为市场提供及时的新商品。考虑ESB的另一个原因是, 应用域在技术和协议上是世代交替的。当同时处理多个不同的协议时, 比如JMS, FTP, HTTP, SOAP, SMTP和TCP, 在应用间实施新的整合方案是很困难的。ESB提供了协议和技术更新器, 以适合IT环境的更替性。第三个原因是降低了整个应用系统的成本。在点对点模型中, 整合点的管理和维护是很耗时的, 因此很昂贵。使用ESB方案可以使管理和维护变得简单因此不那么费时。

我们已经说明了点对点模型和它的缺点, ESB的引入可以使增加和维护一个新的应用变的简单。接下来请看下面的图例 (见图3) :

从图表中可以看出, 最明显的变化就是减少了不同应用之间的整合点的数量。所有的应用都与ESB相连接。注意在上图中显示的ESB展示的是一个高层次的整合。它隐藏了整合逻辑实施的复杂性, 但是复杂性是依然存在和需要处理的。点对点模型和ESB的最大不同在于ESB的设计可以面临整合的挑战。因为ESB提供了所有整合的功能, 平台和管理环境, 实施系统间的新整合因而变的更简单了。如上图所示, 增加一项新应用也变的前所未有的简单。新应用与ESB通过输送协议和适用于这项应用的技术更新器相连结。在集成的过程中, 通过ESB可以有效的使现存的3个系统和新系统建立联系。

因此我们来总结一下一个ESB所具有的最核心的功能:

服务的位置透明–ESB要提供一个服务注册平台, 使得服务的消费者能搞定位到服务的提供者并消费服务。

不同协议的相互转换-ESB能够集成并转换不同的协议如HTTP (S) to JMS FTP to FILE SMTP to TCP

消息解析-通过使用XSLT和XPATH能够轻松解析出消息做携带的信息

消息路由-一个ESB所最重要的功能, 控制消息。

消息增强-一般针对外部进来的消息, 经常确实一部分信息, 要能搞识别和补充必要的信息。

基本安全能够支持角色权限验证, 以及支持加密解密。

消息的监控和管理一个更高层次上对消息的控制和管理。

JBI作为一种企业服务总线, 主要目的是提供一个基于服务的平台作为对现有Java/J2EE平台功能的扩展, 使用基于JBI的开源实现框架Servicemix能够完成基本的ESB功能, 但是JBI本身部件的可重用性不高, 过于依赖XML, 并且没有得到市场的广泛认可, 因此我们不能冒险将Servicemix作为我们ESB的基础。采用ESB间的相互通信将JBI集成到JBoss ESB中, 因为依靠JBoss社区的多个开源项目的支持JBoss ESB欠缺的只有JBI的相关概念。另一方面作为IBM和BEA携手推出的SCA规范在SOA领域中也占据一部分市场, 但SCA中对服务的生命周期管理还很欠缺因此我们将SCA作为JBI中的Service Units集成进JBI, 这样不但提高了系统的松耦合性, 还充分体现了平台的健壮性。如图4:

摘要：2000年SOA架构理念伴随着Web Services一同出现在软件开发领域。人们在充分认可SOA理念的同时不断对Web Services规范进行完善, 希望借助Web Services的技术优势实现企业软件的SOA目标, 然而Web Services规范众多并且标准不统一, 造成企业在很长一段时间内难以找到统一的标准来实施SOA。本文通过深入分析SOA架构理念, 设计并实现了一个基于SOA的物流软件平台, 建设一条以JBI2.0规范为核心的企业ESB, 集成了企业原有的在线OA系统、财务系统、仓储系统等, 在增强新平台功能的同时避免了二次开发, 节省了大量的人力财力;另一方面将具有SCA标准的功能模块集成到平台中, 充分展示了平台的强壮性, 使得企业更加专注于商业问题的解决, 摆脱技术和标准的制约, 让企业在软件技术的不断发展过程中真正获益。最后以商业集成的方式增强和完善平台功能, 打造一个全新的软件服务平台。

关键词：SOA,面向服务的体系结构,Web Services,网络服务,ESB,企业服务总线