扩展性、外接接口、第三方接口指南09.doc

...wd 扩展性、外接接口、第三方接口指南 版本：V1.0 指定人：向延楷目录1.软件扩展性 31.1 产生软件扩展性需求的原因 31.2可扩展性研究背景 31.3 可扩展性研究内容 41.3.1 灵活的可扩展的体系构造 41.3.2 灵活的设计 51. 4 可扩展性解决方案 71. 4. 1 SABEA 的层次构造 81. 4. 2 体系构造的特点 91. 5 总结 102.外接接口 112. 1 引入外接接口的概念 112. 2 如何选用外接接口 112.2.1 JS外接接口方式说明和优缺点 112.2.2 外接接口方式说明和优缺点 122.2.3 WEB SERVICE外接接口 122. 3 使用WEB SERVICE外接接口的优点 132. 4 当前系统已实现的外接接口 142.4.1 一诚通接口实现标准 142.4.2 三统一推接口实现标准 183. 第三方接口指南 203.1 联网接口定义 203.2 联网接口开发例如 201.软件扩展性 当前旅游电子门票业务的飞速开展促使我们必须通过开发具有良好可扩展性、伸缩性，易维护性的软件，迅速高效的满足客户复杂的需求。

而对于当前业务的丰富程度及更新频率来讲，现在我们的客户由传统由门票站慢慢向小型媒体、门户查询网站等多元化开展所以我们所希望的系统应该这样的：在业务初期业务量较小的时候，可以用一个处理能力相当的系统来实现，对于以后日益增长的当业务量，又可以通过软件系统的扩展，提高处理能力，满足新的需求并且在几乎不改变之前的代码根基上能较容易的添加新的功能，并且尽可能小的影响原有系统的业务逻辑所以本系统依据当前需求的特征，定位于一个开放式、高可用、高扩展性的复杂应用系统……1.1 产生软件扩展性需求的原因 一般人会觉得简单的系统比复杂的系统易于建造，易于维护，短小而且运行更快但实际上简洁性的程序通常并不是容易到达的目标，因为团队在开发系统时更倾向于在程序中支持可能在未来才会存在的需求，这就使得系统变得复杂且管理困难然而，因为觉得未来可能会发生什么变化而使代码变得复杂并不是一个好的决策 所以新的开发理念营运而生，我们在编写程序时应该使程序在未来易于添加新的功能或修改现有的功能，而不是现在就增加这些功能因此与其一开场就建造一个复杂的系统，不如考虑开发出一个具有高扩展性的系统，即便之后的业务再复杂也可以方便在缘由根基上进展拓展。

1.2可扩展性研究背景 可扩展性是指软件扩展新功能的容易程度可扩展性越好，表示软件适应“变化〞的能力越强可扩展性是由现代软件的商业模式决定的： (1) 社会的商业越兴旺，需求变化就越快需求变化必将导致修改〔或者扩展〕软件功能，现代软件的规模和复杂性要比十年前的大得多〔比照一下操作系统的变化就明白了〕，如果软件的可扩展性比较差的话，那么修改〔或者扩展〕功能的代价会很高 (2) 现代软件产品通常采用“增量开发模式〞，开发商不断地推出软件产品的新版本，从而不断地获取增值利润如果软件的可扩展性比较差的话，每次开发新版本的代价就会很高所以具有良好可扩展性的系统绝不是仅仅将新的功能参加系统而不考虑其它方面具有良好可扩展性的系统要具备以下特性： (1) 方便地添加新功能2) 扩展后新旧系统之间具有良好的集成性 (3) 扩展后系统仍能满足业务要求的性能，如及时性，可靠性等4) 安全性得到满足由于扩展过程中很容易产生安全问题，因此扩展过程中要有良好的安全解决方案5) 能够进展低本钱扩展 而一个具有可扩展的系统应该具备以下条件： (1) 有灵活的可扩展的体系构造作指导2) 采用灵活的设计。

3) 编写的代码具有可扩展性 1.3 可扩展性研究内容 1.3.1 灵活的可扩展的体系构造 目前软件领域存在着面向过程，面向对象，面向服务三个主要的体系构造就扩展性而言它们之间是一种逐渐灵活的关系 (1) 面向过程是一种以事件为中心的编程思想，首先分析出解决问题的步骤，然后采用函数逐步调用实现的方式使用这种体系构造，系统一旦做出修改则“牵一发而动全身〞，扩展性极差 (2) 面向对象技术是目前非常流行的方式它把构成问题事务分解成各个对象，建设对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为它强调对象的“抽象〞、“封装〞、“继承〞和“多态〞，以重用性、灵活性和扩展性为主要目标随着面向对象技术的开展，又催生了基于对象的组件体系构造在组件开发中，需要进展接口设计，这样软件实体就可以实现和公开其定义的关键局部上述提到的抽象，封装，继承，多态，接口，组件都是利于扩展的概念和技术另外还有一个与可扩展性相关的概念：面向切面的编程〔AOP〕面向方面本质上就是满足扩展的需求，可以在程序中自由扩展功能如果说面向对象是纵向地分析、切割整个系统，那么可以认为 AOP 是横向地对系统作切片。

面向方面可以弥补面向对象的缺陷，两种方式有机的结合在一起，可以更加有效地对系统进展分析 (3)SOA 由一系列相互交互的服务组成，描述了服务之间的交互，并将服务映射到一个或多个具体技术的实现面向服务是系统发布功能的一种方式，利用 Web Service 技术实现不同系统间有效地通信和协作由于 Web Service 的平台中立性和语言中立性使得跨平台的互操作和系统的整合更加容易，因此与基于组件的架构模式相比，SOA 最大的优势在分布式环境领域SOA 与传统软件构造的比较如下表所示： 从上表中的比照中我们发现 SOA 面向流程，以业务为中心，松耦合这些特性都支持系统的可扩展性面向流程与面向对象的 基本区别不仅仅是运营流程的不同，更重要的在于维系企业的 基本构造不同在一个以业务流程为中心的企业中，企业的 基本组成单位是不同的业务流程，不存在刚性的部门，甚至业务流程本身也不是刚性的，而是随着市场的变化可以随时增减改变的；SOA 的显著特点是采用松耦合，对于组成整个应用程序的每个服务的内部构造和实现发生的逐渐的改变能够灵活适应，增强了系统的可扩展性 通过上述分析面向服务的体系构造的优势是比较明显的。

这种软件开发的理念值得推广，而且已经得到应用SOA 更多的是涉及到系统的外部，简单地说就是发布功能它并不关注系统内部构造的实现，所以说面向服务与面向对象并不冲突，系统内部构造完全可以采用基于对象组件的软件体系构造如果把 SOA 和面向对象的理念〔而不是完全照搬和使用〕灵活应用于以后的开发设计中，将会帮助我们设计出更加优秀的架构1.3.2 灵活的设计正如上面所述 SOA 为应用的动态整合提供了一个非常好的思路，一个解决问题的方法然而 SOA 也不是哪种情况都可以使用，下面总结了 4 种 SOA 不适用的场合： 〔1〕同构系统之间互联〔2〕实时、高性能的关键业务处理〔3〕系统架构不需要灵活性〔4〕紧耦合比松耦合的好处更多 因此在针对要开发的系统时我们只需要借鉴 SOA 的先进理念，而不需要完全照搬应套下面针对 SOA 关键概念进展分析： 1．服务本身的独立自主能力与服务之间的松耦合性 这是 SOA 的 基本特征，SOA非常强调架构中提供服务的功能实体的完全独立自主的能力传统的组件技术一般采用宿主来存放和管理这些功能实体；当这些宿主运行完毕时这些组件的寿命也随之完毕这样当宿主本身或者其它功能局部出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。

在不同服务之间，SOA 要求保持一种松耦合的关系，也就是保持一种相对独立无依赖的关系面向服务表示一种别离系统关注面的方法，其实质是将一个比较大的问题分解成一系列较小的、互相关联的子问题，从而降低问题的复杂度，使得我们能够较沉着地分析、解决和管理它传统的面向对象的设计方法其实也是一种别离系统关注面的方法，只不过它是在对象层面来别离关注面，相对业务逻辑较远，而面向服务则是在服务层面来别离关注面，直接关注的是业务逻辑，从而使面向服务能够(至少在理论上)更好地满足业务需求 一个服务就是一个单独的代码模块可以看到，SOA 的出现为企业系统架构提供了更加灵活的构建方式，如果企业架构设计师基于 SOA 来构建系统架构，就可以从底层架构的级别来保证整个系统的松耦合性以及可扩展性 2．构件技术 “基于构件技术提供网络服务〞是 SOA 的重要思想起源，在 SOA 架构中，流动的应该是构件没有构件化时，软件系统的各个局部是严密结合在一起的，因而会“牵一发而动全身〞，采用了构件化技术后，软件的各个功能模块就可以独立地实现、升级，而不会影响系统整体基于构件的软件设计方法学把应用和实现别离，提供标准接口和框架，使软件开发变成构件的组合。

基于构件的软件方法学是以接口为中心、面向行为、基于体系构造设计的，它要求：对构件要有明确的定义；用构件描述语言和标准，如 UML、微软 COM 构件技术中的 IDL、科泰世纪 CAR 构件技术的 CDL SOA 是一种基于对象的构件模型，它将不同的功能单元通过预先定义好的接口和契约联系起来SOA的构件模型决定了软件系统构架在一个 SOA系统中，提供具体服务的是一个实现相应功能的构件 作为面向服务的体系架构，当众多用户屡次重用同一构件、或者需要在不同构件间进展互操作时，SOA 需要提供一套统一的软件标准或协议，这就是构件描述语言 另外服务代表一段完整的业务单元，并且可以根据特定用户的需求组织成为更大和新的服务服务可以由一个或多个构件组合而成服务开发者必须考虑构件的粒度，以及构件的流程和组装，这样他们在改变服务的实现时，可以尽可能少的影响其它构件、应用和服务而服务的设计者则更关心选择适宜的服务，并将它们以可管理的方式组织，并最终将它们组装为完整的业务流程3 编写的代码利于可扩展 随着需求的不断变更，开发者需要进展大量的代码增删改等工作为了提高工作效率，减少编码和测试时间，需要尽可能重用代码。

设计模式主要在代码实现级别上有用，因此设计模式在你考虑代码实现时开场进入我们的视线 设计模式是一种表达，记录和重用软件设计构造和设计经历的新方法，它描述了一个反复出现在特定设计语境中的特殊问题，并为问题的解决方法提供了一个经过充分验证的通用方式一个软件设计模式一般包含如下信息： 〔1〕模式名称：每个模式必须有一个有意义的名称，用于简述模式的本质，可以通过模式名称来鉴别模式〔2〕问题：描述模式要解决的问题，即模式的意图或目标，它解释了设计问题和问题存在的前因后果，在特定的环境和使用动机下该模式所希望到达的目标〔3〕语境：模式解决问题和解决方案出现的前提条件〔4〕解决方案：给出了模式的静态关系和动态规则，描述如何实现期待的结果，以指导构造，它明确说明了模式的构造，参与者和它们之间的协作关系〔5〕 基本原理：给出模式中的执行步骤或规则的正确解释，说明模式如何解决其问题和实现其目标〔6〕效果：描述了模式应用的效果及使用模式应权衡的问题 由于设计模式简化了软件的设计和实现过程，使软件系统的根基架构更加清晰；同时，设计模式可以直接用来指导面向对象系统中至关重要的建模问题，有效地处理需求变更，减。