软件架构概念和面向服务的架构

摘要

软件架构作为软件开发过程的一个重要组成部分，有着各种各样的方法和路线图，它们都有一些共同的原则。基于架构的方法作为控制系统构建和演化复杂性的一种手段得到了推广。

引言

在计算机历史中，软件变得越来越复杂。也提出了许多方法来解决不同层次的复杂性，例如“结构化编程”[1]，以及Fred Brooks的“概念完整性”思想[2]。软件生命周期的设计阶段通常分为高层设计和详细设计。架构将有助于描述软件，这就产生了“软件架构”一词。软件架构的概念已经成为解决高度复杂问题的设计方案。在1994年底，Denning和Dargan为一个新的软件学科提出了“软件架构”[3]。Garlan和Shaw在1996年指出“明确关注架构作为软件设计的一个独立层次是相对较新的”，因此他们的书的副标题是“对一门新兴学科的展望”[4]。面向服务的架构（SOA）是一种模块化服务的架构。然后，可以将这些服务的集合与业务流程协调起来，可以以各种形式重新组合这些服务，以实现新的或改进的业务流程。SOA的新颖之处在于，它能够更灵活地为服务提供者和使用者选择技术实现。抽象服务接口还允许供应商和消费者独立发展，只要接口保持稳定[5]。SOA的好处主要来自于：接口服务的稳定性。与系统更改的总百分比相比，这种稳定性在实现服务的开发过程中将服务与使用者隔离开来。这种隔离限制了变更的范围和后续修订的成本。如果能够重用现有的服务，就可以借用更多的优势。重用避免了重新实现或修改封装在服务中的功能[5]。

软件架构

软件架构是设计系统、解决问题或满足需求的“第一步”。软件架构的真正含义是，它实际上是一种计划资产，用于指导企业信息基础设施的选择、构建、修改和完美使用，以实现所需的业务未来状态。架构涉及架构元素的选择、它们之间的相互作用以及对这些元素及其相互作用的约束，它还可以被视为用于解决问题框图和线条图。

• 框定义系统的元素或“组件”。
• 线定义了零件之间的相互作用。
  要提供一个框架，以满足要求，并作为设计的基础。设计的一般含义是，设计涉及到设计元素的模块化和详细的接口，它们的算法和过程，以及支持架构和满足需求所需的数据类型[6]。因此需要考虑一下内容：
• 业务的当前和未来愿景。
• 包括投资选择在内的质量决策。
• 以符合业务运营的经济高效的方式使用软件。
• 减少冗余。
• 重用信息和软件组件。
• 利用新的技术解决方案。
• 共享系统和数据。
• 跨企业集成。
• 共同标准。
• 减少应用程序接口的数量。
• 缺失数据的识别和规划。

软件架构通常在需求和实现之间起着桥梁的作用（见图1）。通过提供系统的抽象描述，架构公开某些属性，同时隐藏其他属性。软件架构至少可以在软件开发的六个方面发挥重要作用[7]。

图1

• 理解：软件架构简化了我们理解大型系统的能力，方法是将它们呈现在一个抽象的层次上，在这个层次上，系统的高级设计很容易理解。
• 重用：架构描述支持多层次的重用。当前关于重用的工作主要集中在组件库上。此外，架构设计既支持大型组件的重用，也支持将组件集成到其中的框架。
• 构造：架构描述通过指出主要组件及其之间的依赖关系，为开发提供部分蓝图。
• 演化：软件架构可以揭示系统演化的维度。通过明确系统的“承重墙”，系统维护人员可以更好地理解变更的后果，从而更准确地估计修改的成本。
• 分析：架构描述为分析提供了新的机会，包括系统一致性检查[8]、[9]、与架构样式施加的约束的一致性[10]、与质量属性的一致性[11]、依赖性分析[12]以及针对特定样式中构建的架构的特定领域分析[13]。
• 管理：经验表明，成功的项目将实现可行的软件架构视为工业软件开发过程中的一个关键里程碑。对架构的批判性评估通常会导致对需求、实现策略和潜在风险的更清晰理解[14]。

在导致架构不成功的各种因素有，缺乏足够的架构能力和/或经验，在架构设计和分析上花费了足够的时间，无法恰当地记录和传达架构，认识到“标准不能替代软件架构”，充分理解架构和实现之间的直接关系，随着架构的发展更新文档等[15]。

面向服务的架构

SOA是一种按需连接业务和计算资源（主要是组织、应用程序和数据）的设计，以实现服务使用者（可以是最终用户或其他服务）所需的结果。OASIS1[16]将SOA定义为：一种组织和利用分布式功能的范例。它提供了一种统一的方法来提供、发现、交互和使用能力，以产生符合可测量的前提条件和期望的预期效果。
面向服务的架构（SOA）是20世纪90年代基于组件的架构、基于接口的设计（面向对象）和分布式系统的发展，如DCOM[17]、CORBA[18]、J2EE[19]和Internet。

在分析SOA的细节之前，首先探讨软件架构的概念是很重要的，它由软件的粗粒度结构组成。软件架构描述了系统的组件以及它们在高层的交互方式。这些组件不一定是实体bean或分布式对象。它们是作为一个单元部署到带有其他组件的服务器上的抽象软件模块。组件之间的交互称为连接器。组件和连接器的配置描述了系统的结构和行为方式，如图2所示。

图2

面向服务的架构是一种特殊的软件架构，具有许多独特的特点。对于服务设计者和开发人员来说，理解SOA的概念非常重要，这样他们就可以在自己的环境中最有效地使用Web服务。SOA是一个相对较新的术语，但与软件服务相关的术语“服务”至少在20世纪90年代初就出现了，当时它在Tuxedo中被用来描述“服务”和“服务过程”[20]。图3显示了可以使用其他技术来实现面向服务的架构。

图3

每个系统的软件架构反映了设计者使用的不同原则和权衡。面向服务的软件架构具有以下特征[21]：

1、可发现和动态绑定：SOA支持服务发现的概念。需要服务的服务使用者在运行时根据一组条件发现要使用的服务。服务使用者要求注册中心提供满足其需要的服务。

2、自包含和模块化：服务是自包含和模块化的。SOA最重要的方面之一是模块化的概念。服务支持一组接口。这些接口应该是内聚的，这意味着它们都应该在模块的上下文中相互关联。在设计支持应用程序的服务时，应该遵循模块化原则，这样服务就可以很容易地聚合到具有一些众所周知的依赖关系的应用程序中。因为在创建服务时这是一个非常重要的概念，所以我们将解释模块化的一些原则，特别是它们如何应用于服务的创建。Bertrand Meyer[22]概述了确定组件是否具有足够模块化的以下五个标准。当确定服务是否足够模块化时，这些标准同样适用。

• 模块化可分解性：服务的模块化可分解性是指将一个应用程序分解为许多更小的模块。每个模块负责应用程序中的一个单独的、不同的功能。这有时被称为“自顶向下的设计”，在这种设计中，较大的问题被迭代地分解成较小的问题。可分解性的主要目标是可重用性。服务设计的目标是确定可在不同上下文中重用的最小软件单元。
• 模块化可组合性：服务的模块化可组合性是指软件服务的生产，这些服务可以作为一个整体与其他服务自由组合以生产新的系统。服务设计人员应该创建足够独立的服务，以便在完全不同的应用程序中重用，而这些应用程序与它们最初的目的完全不同。这有时被称为自下而上的设计。
• 模块化可理解性：服务的模块化可理解性是一个人在不了解任何其他服务的情况下理解服务功能的能力。例如，如果银行应用程序实现了一个支票账户服务，该服务不实现存款功能，而是依赖于客户机使用一个单独的存款服务；这将降低该服务的模块化可理解性。
• 模块化连续性：服务的模块化连续性是指一个服务中的更改对其他服务或服务使用者的影响。如果接口没有充分隐藏服务的实现细节，则在需要更改时会产生多米诺效应。当服务的内部实现发生更改时，它将需要更改使用该服务的其他服务和应用程序。每个服务都必须隐藏有关其内部设计的信息。公开此信息的服务将限制其模块化的连续性，因为内部设计决策是通过接口公开的。
• 模块化保护：如果服务中的异常情况没有级联到其他服务或使用者，那么服务的模块化保护就足够了。

3、互操作性：面向服务的架构强调互操作性，即使用不同平台和语言的系统相互通信的能力。

4、松散耦合：耦合是指模块之间依赖的数量。联轴器有两种类型：松式和紧式。松散耦合的模块有一些众所周知的依赖关系。紧耦合模块有许多未知的依赖关系。每个软件架构都力求实现模块之间的松散耦合。面向服务的架构促进了服务使用者和服务提供者之间的松散耦合，以及消费者和提供者之间的一些众所周知的依赖关系。

5、位置透明性：位置透明性是面向服务架构的一个关键特性。服务的使用者直到在注册表中找到服务时才知道它的位置。运行时对服务的查找和动态绑定允许服务实现在客户端不知情的情况下从一个位置移动到另一个位置。移动服务的能力提高了服务可用性和性能。通过使用负载均衡器将请求转发到多个服务实例而服务客户机不知情，我们可以获得更高的可用性和性能。

6、可组合性：服务的可组合性与其模块化结构有关。模块化结构允许将服务组装到开发人员在设计服务时不知道的应用程序中。使用预先存在的、经过测试的服务极大地提高了系统的质量，并且由于易于重用而提高了投资回报率。服务可以用三种方式组合：应用程序组合、服务联合和服务编排。

• 应用程序：通常是服务、组件和应用程序逻辑的集合，它们将这些功能绑定在一起以实现特定的目的。
• 服务联合：是在更大的服务域中一起管理的服务集合。例如，支票账户服务、储蓄账户服务和客户服务可以组成更大的银行账户服务。
• 服务编排：是执行影响组织中一个或多个服务的单个事务。它有时被称为业务流程。它由多个步骤组成，每个步骤都是服务调用。如果任何服务调用失败，整个事务应该回滚到事务执行之前的状态。

对于要组合到事务应用程序、联合或编排中的服务，服务方法本身应该是子事务的。也就是说，它们不能自己执行数据提交。

7、自我修复：随着现代分布式应用程序的规模和复杂性，系统从错误中恢复的能力变得越来越重要。自愈系统是一种在执行过程中无需人工干预就能从错误中恢复的系统。

可靠性实际上衡量系统在受到干扰时的性能。在面向服务的架构中，服务将不时地上下浮动。这对于通过互联网上多个组织的服务组装的应用程序尤其如此。系统自愈的程度取决于几个因素。可靠性取决于硬件从故障中恢复的能力。网络还必须允许在运行时动态连接到不同的系统。现代互联网网络协议固有地提供了这种能力。

一种人工智能平台架构

结论

在过去的十年中，软件架构作为一门学科正在兴起[7]。系统软件架构在较高的层次上描述了它的粗粒度结构和属性。只要该技术考虑到这些结构和属性，就可以使用该技术实现架构。例如，Jini是一种支持面向服务架构的技术，因为SOA的属性。充分利用软件架构这一新技术的概念对于应用软件架构是非常重要的。面向服务的架构是通过Web服务和其他技术实现的，但是由于Web服务的出现，这些术语和概念最近得到了广泛的应用。例如，二十年来，计算机行业一直被用来描述各种平台。SOA的一些特性得到了一些比其他技术更好的支持。

参考文献
[1] O. J. Dahl, E. W. Dijkstra, and C. A. Hoare, Structured Programming. Academic Press, 1972.
[2] F. P. Brooks, The Mythical Man-Month: Essays On Software Engineering, Anniversary Edition. Addison-Wesley, 1995.
[3] P. J. Denning and P. A. Dargan, “A discipline of software architecture,” interactions, vol. 1, no. 1, pp. 55–65, 1994.
[4] M. Shaw and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline. Prentice- Hall, 1996.
[5] P. Brown, Implementing soa: total architecture in practice. AddisonWesley Professional, 2008.
[6] D. E. Perry and A. L. Wolf, “Foundations for the study of software architecture,” ACM SIGSOFT SOFTWARE ENGINEERING NOTES,
vol. 17, no. 4, October 1992.
[7] D. Garlan, “Software architecture: a roadmap,” in ICSE ’00: Proceedings of the Conference on The Future of Software Engineering. New York,
NY, USA: ACM, 2000, pp. 91–101.
[8] R. Allen and D. Garlan, “Formalizing architectural connection,” in ICSE’94: Proceedings of the 16th International Conference on Software Engineering, Sorrento, Italy, May 1994, pp. 71–80.
[9] D. C. Luckham, L. M. Augustin, J. J. Kenny, J. Veera, D. Bryan, and W. Mann, “Specification and analysis of system architecture using rapide,” IEEE Transactions on Software Engineering, vol. 21, no. 4, pp. 336–355, April 1995.
[10] G. Abowd, R. Allen, and D. Garlan, “Using style to understand descriptions of software architecture,” in SIGSOFT ’93: Proceedings of the 1st ACM SIGSOFT symposium on Foundations of software engineering. New York, NY, USA: ACM, 1993, pp. 9–20.
[11] P. Clements, L. Bass, R. Kazman, and G. Abowd, “Predicting software quality by architecture-level evaluation,” in Proceedings of the Fifth International Conference on Software Quality, Austin, Texas, October 1995.
[12] J. A. Stafford, D. J. Richardson, and A. L. Wolf, “Aladdin: A tool for architecture-level dependence analysis of software,” University of Colorado at Boulder, Technical Report CU-CS-858-98, April 1998.
[13] L. Coglianese and R. Szymanski, “Dssa-adage: An environment for architecture-based avionics development,” in AGARD’93, 1993.
[14] B. Boehm, P. Bose, E. Horowitz, and M. J. Lee, “Software requirements negotiation and renegotiation aids: A theory-w based spiral approach,” in ICSE ’95: Proceedings of the 17th international conference on Software engineering. New York, NY, USA: ACM, 1995, pp. 243–253.
[15] L. Northrop, “Software architecture and product quality,” Presentation for the Boston SPIN, Software Engineering Institute, Carnegie Mellon University, May 2003.
[16] Organization for the advancement of structured information standards. [Online]. Available: http://www.oasis-open.org
[17] Distributed component object model. [Online]. Available: www.microsoft.com/com
[18] Corba basics frequently asked questions. [Online]. Available: www.omg.org/gettingstarted/corbafaq.htm
[19] Java EE at a glance. [Online]. Available: http://java.sun.com/j2ee
[20] P. Herzum, “Web services and service-oriented architectures,” Cutter Distributed Enterprise Architecture Advisory Service, Executive Report, 2002.
[21] G. Bieber and J. Carpenter, “Introduction to service-oriented programming,” Online whitepaper: www.openwings.org/download/specs, 2001.
[22] B. Meyer, Object Oriented Software Construction, 2nd ed., ser. International Series in Computer Science. Prentice-Hall, 1997.
[23] United nations centre for trade facilitation and electronic business. [Online]. Available: http://www.unece.org/cefact