扩展性外接接口第三方接口指南09Word格式文档下载.docx
《扩展性外接接口第三方接口指南09Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《扩展性外接接口第三方接口指南09Word格式文档下载.docx（30页珍藏版）》请在冰豆网上搜索。
一般人会觉得简单的系统比复杂的系统易于建造，易于维护，短小而且运行更快。
但实际上简洁性的程序通常并不是容易达到的目标，因为团队在开发系统时更倾向于在程序中支持可能在未来才会存在的需求，这就使得系统变得复杂且管理困难。
然而，因为觉得未来可能会发生什么变化而使代码变得复杂并不是一个好的决策。
所以新的开发理念营运而生，我们在编写程序时应该使程序在未来易于添加新的功能或修改现有的功能，而不是现在就增加这些功能。
因此与其一开始就建造一个复杂的系统，不如考虑开发出一个具有高扩展性的系统，即便之后的业务再复杂也可以方便在缘由基础上进行拓展。
1.2可扩展性研究背景
可扩展性是指软件扩展新功能的容易程度。
可扩展性越好，表示软件适应“变化”的能力越强。
可扩展性是由现代软件的商业模式决定的：
（1）社会的商业越发达，需求变化就越快。
需求变化必将导致修改（或者扩展）软件功
能，现代软件的规模和复杂性要比十年前的大得多（对比一下操作系统的变化就明白了），
如果软件的可扩展性比较差的话，那么修改（或者扩展）功能的代价会很高。
（2）现代软件产品通常采用“增量开发模式”，开发商不断地推出软件产品的新版本，从
而不断地获取增值利润。
如果软件的可扩展性比较差的话，每次开发新版本的代价就会很高。
所以具有良好可扩展性的系统绝不是仅仅将新的功能加入系统而不考虑其它方面。
具有良好
可扩展性的系统要具备以下特性：
（1）方便地添加新功能。
（2）扩展后新旧系统之间具有良好的集成性。
（3）扩展后系统仍能满足业务要求的性能，如及时性，可靠性等。
（4）安全性得到满足。
由于扩展过程中很容易产生安全问题，因此扩展过程中要有良好
的安全解决方案。
（5）能够进行低成本扩展。
而一个具有可扩展的系统应该具备以下条件：
（1）有灵活的可扩展的体系结构作指导。
（2）采用灵活的设计。
（3）编写的代码具有可扩展性。
1.3可扩展性研究内容
1.3.1灵活的可扩展的体系结构
目前软件领域存在着面向过程，面向对象，面向服务三个主要的体系结构。
就扩展性而言它们之间是一种逐渐灵活的关系。
（1）面向过程是一种以事件为中心的编程思想，首先分析出解决问题的步骤，然后采用函数逐步调用实现的方式。
使用这种体系结构，系统一旦做出修改则“牵一发而动全身”，扩展性极差。
（2）面向对象技术是目前非常流行的方式。
它把构成问题事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。
它强调对象的“抽象”、“封装”、“继承”和“多态”，以重用性、灵活性和扩展性为主要目标。
随着面向对象技术的发展，又催生了基于对象的组件体系结构。
在组件开发中，需要进行接口设计，这样软件实体就可以实现和公开其定义的关键部分。
上述提到的抽象，封装，继承，多态，接口，组件都是利于扩展的概念和技术。
另外还有一个与可扩展性相关的概念：
面向切面的编程（AOP）。
面向方面本质上就是满足扩展的需求，可以在程序中自由扩展功能。
如果说面向对象是纵向地分析、切割整个系统，那么可以认为AOP是横向地对系统作切片。
面向方面可以弥补面向对象的缺陷，两种方式有机的结合在一起，可以更加有效地对系统进行分析。
（3）SOA由一系列相互交互的服务组成，描述了服务之间的交互，并将服务映射到一个或多个具体技术的实现。
面向服务是系统发布功能的一种方式，利用WebService技术实现不同系统间有效地通信和协作。
由于WebService的平台中立性和语言中立性使得跨平台的互操作和系统的整合更加容易，因此与基于组件的架构模式相比，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）效果：
描述了模式应用的效果及使用模式应权衡的问题。
由于设计模式简化了软件的设计和实现过程，使软件系统的基础架构更加清晰；
同时，设计模式可以直接用来指导面向对象系统中至关重要的建模问题，有效地处理需求变更，减少各类之间的耦合和依赖，为软件工程的应用和软件开发提供了良好的途径。
但是模式容易使代码复杂化，而且没有严格的规则告诉我们什么时候使用模式比较好，它是一种直觉的判断。
这种敏感来自于多年的经验，许多资历尚浅的设计人员/程序员不可能拥有。
因此过多地使用设计模式将导致糟糕的程序，仅仅使用模式并不能确保成功，因此使用模式时需要慎重。
1.4可扩展性解决方案
构建可扩展性系统的关键是系统架构具有灵活性、开放性和易配置性。
这些特性具体体现在构建系统的各个功能部件之间合理的功能划分和相互之间松耦合的交互。
针对以上分析，本文设计了一套解决方案，命名为基于SOA和设计模式的可扩展的体系结构（SOAandDesignpatternBasedExtensibleArchitecture，SABEA）。
该框架以可扩展性为主要特征，实现处理逻辑之间灵活挂接和易配置，能够使服务随业务流程变化而快速适应，业务处理单元之间建立松耦合的交互关系，实现数据交换和服务的透明处理。
1.4.1SABEA的层次结构
SABEA在整体设计上采用了分层的体系结构和SOA架构。
本框架总体上分为3层：
接入层；
业务层和数据层。
其结构如下图1所示：
每一
升级会员 