体系结构

开篇：润墨网以专业的文秘视角，为您筛选了八篇体系结构范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

体系结构范文第1篇

关键词：软件体系结构；重用；模式

中图分类号：TP311文献标识码：A文章编号：1009-3044(2008)35-2519-02

A Comprehensive Introduction to the Study of Software Architecture

WANG Qiang

(AnHui Technical College of Mechanical and Electrical Engineering, Wuhu 241000, China)

Abstract: Software architecture is the hotspot in software engineering research. This article discusses about the purpose and current situation of software architecture researching.

Key words: software architecture; reuse; mode

1 引言

随着计算机技术的发展和应用的不断深入，软件系统的规模和复杂度日益增加，在软件设计过程中人们所面临的问题不仅仅是考虑软件系统的功能问题，而是面临要解决更难处理的可修改性，性能，可靠性等非功能性问题。特别是80年代以来，对软件适应变更的要求越来越高，所以对软件整体的设计已经超过了算法和数据结构，成为系统开发关注的主要问题。软件开发最大的风险来自需求变更，但一蹴而就搞定需求不现实，好的体系结构是易改动的基础。 能否复用很重要，设计复用比代码复用更有用更难。因此，研究软件体系结构研究的能提高软件生产率和简化维护。提高软件生产率的关键在于软件相关部分的复用，而简化维护的关键是减少软件理解的成本和提高软件的质量，这就是研究软件体系结构的目的。

2 软件体系结构的概念

软件系统的规模在迅速增大的同时，软件开发方法也经历了一系列的变革.在此过程中，软件体系结构也由最初模糊的概念发展到一个渐趋成熟的技术。

1) 1992年Perry 和Wo1f 在他们早期关于软件体系结构的论文中指出:软件体系结构是一组具有一定形式的结构化元素或称为设计元素组成。

2) 1993年Shaw 和Garlan 认为软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。

3) 1994年Hayes Roth 则认为软件体系结构是一个抽象的系统规范，主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。

4) 1995年Garlan 和Perry 在IEEE 软件工程学报上又采用如下的定义：软件体系结构是一个程序各构件的结构、它们之间的相互关系以及进行设计的原则和随时间进化的指导方针。

5) 1996年Boehm 和他的学生提出，一个软件体系结构包括一个软件和系统构件，互联及约束的集合。

6) 1997年Ctements 和Kazman在《使用软件体系结构》一书中给出如下的定义：一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。

3 软件体系结构的现状

下面介绍几种常见的体系结构。

模型-视图-控制结构是交互式应用程序广泛使用的一种体系结构。它有效地在存储和展示数据的对象中区分功能模块以降低它们之间的连接度，这种体系结构将传统的输入、处理和输入模型转化为图形显示的用户交互模型，或者换一种说法，是多层次的Web商业应用；MVC体系结构具有三个层面：模型（Model）、视图(View)和控制(Controller)，每个层面有其各自的功能作用。

模型层负责表达和访问商业数据，执行商业逻辑和操作。也就是说，这一层就是现实生活中功能的软件模拟；在模型层变化的时候，它将通知视图层并提供后者访问自身状态的能力，同时控制层也可以访问其功能函数以完成相关的任务。

视图层负责显示模型层的内容。它从模型层取得数据并指定这些数据如何被显示出来。在模型层变化的时候，它将自动更新。另外视图层也会将用户的输入传送给控制器。控制层负责定义应用程序的行为。它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作；在一个图形界面中，常见的用户输入包括点击按钮和菜单选择。在Web应用中，它包括对Web层的HTTP GET和POST的请求；控制层可以基于用户的交互和模型层的操作结果来选择下一个可以显示的视图，一个应用程序通常会基于一组相关功能设定一个控制层的模块，甚至一些应用程序会根据不同的用户类型具有不同的控制层设定，这主要是由于不同用户的视图交互和选择也是不同的。

在模型层、视图层和控制层之间划分责任可以减少代码的重复度，并使应用程序维护起来更简单。同时由于数据和商务逻辑的分开，在新的数据源加入和数据显示变化的时候，数据处理也会变得更简单。

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。

对软件体系结构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。体系结构风格的不变部分使不同的系统可以共享同一个实现代码。只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的体系结构。例如，如果某人把系统描述为"客户／服务器"模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。

下面是Garlan和Shaw对通用体系结构风格的分类：

1) 数据流风格：批处理序列；管道/过滤器

2) 调用/返回风格：主程序/子程序；面向对象风格；层次结构

3) 独立构件风格：进程通讯；事件系统

4) 虚拟机风格：解释器；基于规则的系统

5) 仓库风格：数据库系统；超文本系统；黑板系统

设计模式使人们可以更简单方便地复用成功地设计和体系架构。将以证实的技术表述成设计模式也会使新系统开发者更容易理解其设计思路。设计模式帮助你做出有利于系统复用的选择，避免设计损害了系统复用性。通过提供一个显示类和对象作用关系以及它们之间潜在联系的说明规范，设计模式甚至能够提高已有系统的文档管理和系统维护的有效性。简而言之，设计模式可以帮助设计者更快更好地完成系统设计。

一个设计模式描述了对于特定设计问题被验证的解决方案，它综合了所有开发者对这个问题所在领域的知识和见解；同时也是对于常见问题的可重用方案，它们一般适用于单个问题，但是组织在一起就可以提供整个企业系统的解决方案。J2EE平台就用到很多设计模式，列举如下：

1) 前控制器。

2) 控制器

3) 视图

4) 视图帮助

5) 会话面

6) 数据访问对象

7) 值对象或传输对象

8) 截取过滤器

随着软件体系结构的不断发展，出现了一种新型的体系结构即SOA。SOA被称为软件体系结构的划时代革命。

SOA是一种结构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件交互的人为依赖性。SOA的关键是“服务”的概念，W3C将服务定义为：“服务提供者完成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。将SOA定义为：“本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。” 将SOA定义为：“按需连接资源的系统。在SOA中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，SOA规定了资源间更为灵活的松散耦合关系。” Gartner则将SOA描述为：“客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成……SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。” Gartner相信BPM和SOA的结合对所有类型的应用集成都大有助益――“SOA极大的得益于BPM技术和方法论，但是SOA面临的真正问题是确立正确的企业意识，即：强化战略化的SOA计划（针对供应和使用）并鼓励重用。”虽然不同厂商或个人对SOA有着不同的理解，但是我们仍然可以从上述的定义中看到SOA的几个关键特性：一种粗粒度、松耦合服务结构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

4 软件体系结构存在的不足

尽管软件体系结构研究领域取得了若干成果，但在应用方面，软件体系结构仍然有很多可以改进的地方。N. Medvovonic认为，目前对软件体系结构的理解还仅限于直观、或当作稀奇事、或当作民间传说；语义丰富但不严谨。体系结构似乎没有解决实际问题。由此可见，若要有效地指导软件工程实践、为软件开发提供一个好的结构及其设计结构的指导原则，软件体系结构研究还有若干问题需要解决。比如缺乏统一的软件体系结构的概念，各种软件体系结构的不易操作性，ADL繁多，缺乏统一的ADL支持等等。

5 前景展望

目前，软件体系结构领域研究非常活跃。随着研究的不断深入，软件复用的层次越来越高，人们在开发新的系统时不必总是重复别人已经创造的东西，而是可在软件开发中复用已有成果，这样可以把注意力投入到软件新增功能上，提高软件开发效率。

针对软件体系结构发展趋势，Clements预测在未来的5~10年内软件体系结构研究将围绕如下5个方向展开:体系结构创建与选择；体系结构表示；体系结构分析；基于体系结构开发；体系结构演化.而Perry在IFIP 2000 年世界计算机大会主题演讲中认为，最为重要的3个研究方向是:体系结构风格、体系结构连接件和动态体系结构。

参考文献：

[1] 王霞俊.浅谈软件体系结构[J].常州轻工职业技术学院学报,2007(1).

[2] 邓伦丹,罗丹,汪伟.几种主要的软件体系结构风格的分析[J].科技信息,2007(32):102.

[3] 孙昌爱,金茂忠,刘超.软件体系结构研究综述[J].软件学报,2002(13)

[4] 秦建超,杜友福,孟珍伟.浅谈软件体系结构科技信息[J],2007(2)

[5] Michale Kircher.面向模式的软件体系结构[M].1版.北京:机械工业出版社,2005:5-6.

体系结构范文第2篇

关键词：WebService，软件体系，结构分析

 

使用Web Service模式进行软件设计越来越受到业界的欢迎，Web Service技术解决了很多以前的技术难以解决或者解决起来比较困难的问题，当然，新技术也带来了一些新的固有问题，本文对web service的体系结构，以及使用的技术进行介绍。

1，软件体系结构简介：

虽然软件体系结构已经在软件工程领域中有着广泛的应用，但迄今为止还没有一个被大家所公认的定义，一般认为：

1，软件体系结构是软件在设计构成上的基本、可供设计选择的形态和总体结构。

2，软件体系结构定义软件的局部和总体计算部件的构成，以及这些部件之间的相互作用关系。即结构（静态）和行为（动态）。

软件体系结构是对子系统、软件系统组件以及他们之间相互关系的描述。论文格式，软件体系。子系统和组件一般定义在不同的视图内，以显示软件系统的相关功能属性和非功能属性。系统的软件体系结构是一件人工制品，这是软件设计活动的结果。

2，软件体系结构的发展基于软件模型的发展

软件模型包括过程模型、对象模型、组件模型、配置型组件模型、Web Services模型、GridServers模型、Intelligence Services模型。

不同的模型决定了不同的软件体系，各种模型的发展是螺旋式的，不是抛弃式的。因此，软件体系的重心也是不同的。

3，web service模型中的体系结构

Web service的定义：Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。

Web service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面(interface)的平台提供了一些方法来描述界面、方法和参数。同样的，Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。最后，我们还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。

Web Service结构如图1-1

图1-1

Web service的执行模式如图1-2

图1-2

3.1 XML和XSD

可扩展的标记语言XML是Web Service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既与平台无关，又与厂商无关。XML是由万维网协会(W3C)创建，W3C制定的XML SchemaXSD定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。XML结构如下图1-3

图1-3

Web Service平台是用XSD来作为数据类型系统的。当你用某种语言如VB.NET或C#来构造一个Web Service时，为了符合Web Service标准，所有你使用的数据类型都必须被转换为XSD类型。如想让它使用在不同平台和不同软件的不同组织间传递，还需要用某种东西将它包装起来。这种东西就是一种协议，如 SOAP。

3.2 SOAP

SOAP即简单对象访问协议(Simple Object Access Protocol)，它是用于交换XML编码信息的轻量级协议。它有三个主要方面：XML-envelope为描述信息内容和如何处理内容定义了框架，将程序对象编码成为XML对象的规则，执行远程过程调用(RPC)的约定。SOAP可以运行在任何其他传输协议上。例如，你可以使用 SMTP，即因特网电子邮件协议来传递SOAP消息，这可是很有诱惑力的。在传输层之间的头是不同的，但XML有效负载保持相同。论文格式，软件体系。

SOAP消息封装的模型如图1-4

图1-4

Web Service 希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态，实现“基于Web无缝集成”的目标。

3.3 WSDL

Web Service描述语言WSDL就是用机器能阅读的方式提供的一个正式描述文档而基于XML的语言，用于描述Web Service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的。论文格式，软件体系。WSDL 你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web service。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。论文格式，软件体系。论文格式，软件体系。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。图1-5为WSDL文档的元素结构

图1-5

3.4 UDDI

UDDI 的目的是为电子商务建立标准；UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web Service注册，以使别的企业能够发现的访问协议的实现标准。图1-6为UDDI的原理

图1-6

3.5 远程过程调用RPC与消息传递

Web Service本身其实是在实现应用程序间的通信。我们现在有两种应用程序通信的方法：RPC远程过程调用和消息传递。使用RPC的时候，客户端的概念是调用服务器上的远程过程，通常方式为实例化一个远程对象并调用其方法和属性。RPC系统试图达到一种位置上的透明性：服务器暴露出远程对象的接口，而客户端就好像在本地使用的这些对象的接口一样，这样就隐藏了底层的信息，客户端也就根本不需要知道对象是在哪台机器上。

4 总结

Web service是创建可互操作的分布式应用程序的新平台。Web service 的主要目标是跨平台的可互操作性。为了达到这一目标，Web service 是完全基于XML、XSD等独立于平台、独立于软件供应商的标准的。

Webservice在应用程序跨平台和跨网络进行通信的时候是非常有用的。Web service适用于应用程序集成、B2B集成、代码和数据重用，以及通过Web进行客户端和服务器的通信的场合。

当然，Web service也不是万能的，你不能到处滥用Web service。在有些情况下，Web service 会降低应用程序的性能，而不会带来任何好处。论文格式，软件体系。例如，一台机器或一个局域网里面运行的同构应用程序就不应该用Web service 进行通信。

参考文献

1．《大型软件体系结构：使用UML实践指南》 （美）盖兰德等著 叶俊民等译

2．《应用框架的设计与实现——.NET平台》 XIN CHEN 等著

体系结构范文第3篇

关键词：城市轨道交通  自动化  体系结构  自律分布系统

abstract: based on analysis of characteristics of the urban railroad transportation systems, the technical requirements of railroad transportation systems are proposed, the design principle and method of urban railroad transportation automation system are also discussed in this paper. compare with the conventional system architecture, we argue that the autonomous decentralized system architecture is an ideal architecture for urban railroad transportation automation system. finally, the outline of autonomous decentralized system was described from technical maturity and advantage point of view respectively.

keywords: urban railroad transportation; automation; system architecture; autonomous decentralized system

一、 城市轨道交通系统的特点及其技术需求

      在讨论城市轨道交通系统自动化系统之前，对城市轨道交通系统的特点进行分析是十分必要的。下面从七个方面逐一进行分析。

1． 城市轨道交通规划的可持续性

      随着中国城市化进程的发展，主城区向外扩展、主城区和卫星城连成一体是一个明显的趋势。城市轨道交通系统规划要能适应这一不断发展和扩展的需求。然而，存在的主要问题是：准确地预测未来的发展具有很多不确定因素。也就是说，当前的规划在将来是要变的。这就要求我们的规划要充分考虑系统的变化因素，反过来也要考虑现有系统和未来系统的平滑衔接和升级。用技术的语言讲就是系统结构的灵活性和可扩展性。

2． 城市轨道交通系统建设的阶段性

      城市轨道交通系统建设受投资、征地等诸多因素制约，不可能像大铁路那样一次设计、一次建设，需要分阶段地建设和实施，一般的形态是逐线建设，即使是一条线也要求分段建设。这样的建设模式给系统运行带来很大的挑战。对于分阶段实施的系统而言，很明显要求系统具有扩充性。对于能够一次建成的系统，建成后的系统升级和改造，要求不中断系统的运行，从这个角度看，要求系统具有在线特性，即边测试，边运行。此外，还应考虑系统运用过程中的在线培训。系统的扩充性和在线特性对于降低系统的开发成本，运行成本都是有直接好处的。这一问题也可以归结为系统结构的灵活性和可扩展性。

3． 运输组织的多样化和高密度化

      运输组织的多样化是指根据节假日和重大活动适时地调整运输计划并付诸实施。这就要求建立在线实时的运输计划系统，即运行图系统，实现小时级计划的调整。

      在上下班的高峰期实现列车的高密度运行是必须的，比如120秒的运行间隔。高密度运行与列车自动控制方式（atc）和行车指挥系统密切相关。在这样的需求之下，存在两条不同的技术路线：信息集中控制集中，信息集中控制分散。就行车指挥系统而言，如何进行选择可用下面的事例来说明。

      日本的新干线由jr东日本，jr西日本，jr东海道等铁路公司运营。因此，新干线的运输调度指挥系统分为二大类：其一为comtrac（jr西日本，jr东海道采用），其二为cosmos（jr东日本采用）。comtrac采用的是信息集中控制集中模式，而cosmos采用的是信息集中控制分散模式。

      基于可靠的理由，在阪神大地震后，comtrac建有第二指令所（调度所）。

      需强调指出是信息集中是指列车计划信息（运行图）的集中，以及列车运行实绩（在线状态）的集中。控制分散是指列车进路控制由各个车站的系统——程序进路控制装置（prc）完成。站间协调的准则就是列车运行图。

      从上面的分析中可以看出，车站prc只要有运行图信息就可以实施进路控制。在正常情况下，由调度中心向车站prc传送运行图信息；而在非正常情况下（灾害），由各车站prc定期保存基本运行图信息，以备紧急情况下使用。

      至于列车在线信息的集中，可以这样考虑，在灾害时，只需收集列车运行状态的最少基本信息，而不必建设1：1的备用中心。

      日本东京圈自律交通运行控制系统（atos）是目前世界上最大的自律分布系统，它管理着东京地区的200多个车站和2000多公里线路。实现了行车指挥、设备监控和旅客信息服务综合自动化，实现了列车的高密度运行（120秒），实现了系统的分阶段的建设。具有典型性和代表性。这一系统也是采用的信息集中控制分散模式。

      就列车自动控制系统而言，有两种模式。一是在地面系统生成速度指令，发送到轨道电路上，列车按速度指令行车；一个是地面系统只发送停车点信息，列车根据这一信息和自身的位置以及制动性能自律地生成平滑的制动曲线。后一种模式也可以称为（列车位置）信息集中（制动）控制分散，可以适应不同车辆不同的制动性能，最大限度地实现高密度运行。

      因此，实现运输组织的多样化和高密度化时，采用何种技术路线是必须认真研究解决的问题。

4． 旅客服务的实效性

    为旅客提供列车运行信息的显示和广播是基本的要求。在非正常运行情况下，实时地信息是关键。要求旅客服务系统和行车指挥系统实现互连。

5． 维护作业管理模式

      系统的维护模式是一个较少探讨的问题，面前维护作业管理很难实现自动化。系统维护模式也决定着系统的设计和开发方式。

      第一个问题涉及系统自身的维护。是不中断运行维护，还是在线维护与测试。即系统是否具备在线维护的能力。这又与系统的体系结构密切相关。

      第二个问题是维护的管理模式。是集中还是分担。现有的维护管理模式可以说是一种集中模式，一切均在调度人员管制下完成。分担的维护管理模式是指由调度中心、车站和现场作业人员共同完成维护作业。在这种模式下，调度中心负责信息（维护作业计划）集中，车站负责进路控制，现场作业人员负责维护作业时的进路申请和作业实施。可以说，将过去调度中心的相当权限下放给了车站和现场作业人员。各个环节具有相当的自主权并相互协调。支持这一维护管理模式，需要相应的系统结构和技术。

6． 安全性

      安全性是城市轨道交通系统的基本要求。具体地讲就是在轨道交通系统的各个环节如通信信号、行车指挥、列车控制、牵引供电和车辆等领域采用故障-安全设计原则。故障-安全涉及硬件、软件和通信编码等方面。如何应用故障-安全的理论和方法是我们面临的问题。

7． 可用性

      对城市轨道交通系统而言，故障-安全是不够的。故障-安全从本质上讲是一种被动的技术措施。如何保证运输服务的连续稳定性，即可用性是我们的首要目标。做到100%的可用在技术上是可行的，但代价往往是高的。有时由于外界因素（如灾害、人身伤亡事故等）的影响导致服务中断是不可避免的，但不是无限期的。非正常情况下的快速恢复是一个关键。

      在高密度运行区间，为防止列车故障或事故时引发混乱、尽量减小列车晚点，需要灵活快捷的列车群自动控制系统。在正常情况下，列车群自动控制依赖于运行图；在非正常情况下，要实现列车群的协调，如安排列车的避让或折返、避免列车在站间停车等。传统的列车群控制大多依赖于调度员的指挥，难于实现快速的事故恢复。

      为保证运输服务的可用性，快捷的列车群自动控制系统是必不可少的。从技术上讲，实现可用性也有两条技术路线：容错和防错。防错主要采用冗余技术，100%的备用，系统的成本太高。容错是真正容许模块的错误和故障的发生，采用模块级备用方式，实现低成本化。

综上所述，城市轨道交通系统的技术需求可以归纳为如下几个方面：

（1） 系统的在线扩展性

（2） 系统的在线维护和测试性

（3） 系统的在线容错性

（4） 信息集中、控制分散的技术路线

（5） 调度中心-车站-现场作业人员协同的业务分担模式

二、 城市轨道交通自动化系统的设计开发理念和方法

      为满足城市轨道交通系统的技术需求，需要建立新的设计开发理念和方法。提出如下观点和方法供参考。

1．信息集中、控制分散的技术路线

      为实现城市轨道交通系统运输组织的多样化和高密度化，采用信息集中、控制分散的技术路线是一种理想选择。

2．调度中心-车站-现场作业人员协同的业务分担模式

    这一模式对实现城市轨道交通系统的高效协同运行有重要意义。

3．城市轨道交通自动化系统体系结构

      目前广泛采用的是集中式体系结构和客户/服务器体系结构。对于大规模城市轨道交通自动化系统而言，集中式的体系结构已不能满足系统动态变化和扩展的要求，而客户/服务器结构又存在着系统负荷过于集中在服务器方等问题。因此，研究适合于大规模城市轨道交通自动化系统体系结构，以满足系统动态扩展的要求是一项重大课题。

4．系统设计方法学

      目前，系统设计大多采用自顶向下的方法，包括结构化设计和面向对象设计等方法。这些方法假定在设计阶段系统的结构、规模和功能是确定的。系统的扩展和变化，必将引起整个系统的变化，可谓“牵一发动全身”。对于大规模系统而言，不可能一次设计、一次建成，需要分阶段地设计和建设实施。采用自底向上，由子系统逐步构成整个系统的系统设计方法学势在必行。

5．系统容错技术(可靠性)

      目前的双机或多机冗余备用技术从根本上讲是一种防错技术，即防止错误的发生。在实际应用中，存在着成本高，防不胜防等问题。针对城市轨道交通自动化系统的特点，研究开发低成本的、实现真正意义上的容错技术是必要的。

6．故障-安全技术

    对于轨道交通电气化自动化系统这类要求故障-安全特性的系统，需要从硬件、软件和通信等层面对故障-安全技术进行系统研究，并重点解决工程实用化问题。目前这一方面的研究相对薄弱。

三、 城市轨道交通自动化系统的体系结构

1．体系结构对系统运用成败的影响

      在讨论城市轨道交通自动化系统的体系结构之前，先以ctc系统为例，说明体系结构对系统运用成败的影响。

      铁路行车调度指挥系统采用ctc已有漫长的历史。美国1927年开发了第一套ctc系统，以单线无人站为控制对象，以增加区间列车运行数为目标。实践证明，其投资效果是明显的，到1955年所有干线基本实现了ctc化。欧洲（1943）、日本（1954）开始采用ctc系统，其目标是实现车站的无人化和经营的效率化。

      我国开展ctc的研究已有40余年的历史，广深、大秦、郑武等线装备了ctc系统而没有开通或使用。其主要问题是：调度集中模式下，行车和调车作业的矛盾没有解决。

      基于ctc的运输管理模式可以说是一种集中模式，一切均在调度人员管制下完成。但调度员的管制能力又是有限的。

      从技术上讲，ctc采用的是典型的集中式体系结构，对于大规模城市轨道交通自动化系统而言，集中式的体系结构已不能满足系统动态变化和扩展的要求，而客户/服务器结构又存在着系统负荷过于集中在服务器方等问题。

      在高密度区间、客货混跑条件下，传统的ctc系统面临如下问题：（1）大规模枢纽站仍然由人控制，不能实现自动化；（2）发生故障恢复运行时相当费时；（3）维护作业依赖于人，存在安全隐患。

在城市轨道交通系统中，仍然存在上述（2）（3）之问题。

      在第一部分已经提到，调度中心-车站-现场作业人员协同的业务分担模式。在这种模式下，调度中心负责信息集中，车站负责进路控制，现场作业人员负责维护作业时的进路申请和作业实施。可以说，将过去调度中心的相当权限下放给了车站和现场作业人员。各个环节具有相当的自主权并相互协调。这一业务模式可称为自律分布模式。

      以“信息集中、控制分散”为基本理念的自律分布铁路调度指挥模式是解决我国ctc系统主要问题的一种理想选择。支持自律分布模式的体系结构是一种对等式体系结构，又称为自律分布体系结构。

2．集中式体系结构

      在自动化系统中，广泛采用的是集中式结构。对于城市轨道交通自动化系统而言，集中式的体系结构已不能满足系统动态变化和扩展的要求。在运行过程中，其缺点表现为：

图1 集中式体系结构

（1） 所有的现场设备信息必须汇总到通讯前置机后再由通讯前置机发送到控制中心。这增加了信息传输中间环节，并且随着现场设备的扩展，增加了通讯前置机的负担，通讯前置机是现场设备和控制中心交互的咽喉，如果它出现故障，则整个监控系统处于瘫痪状态。

（2）现场的所有信息都是最终汇总到控制中心，控制中心的计算机进行各种数据处理，最后由操作员工作站的屏幕上显示出来。同时将各种控制信息发送给现场设备，进行统一监督和控制。这种集中式的监控系统随着监控规模的不断扩大，必将大大加大控制中心的负担。

（3）若要对集中式结构的监控系统增加新的设备时，必须停止整个系统的运               行，并且还必须将控制中心的软件进行修改，甚至重新编写软件，这也将大大影响 监控系统的运行，而且将消耗大量的人力物力。

3．  客户/服务器体系结构

客户/服务器结构虽然减少了中间环节，方便了动态扩充，却又存在着系统负荷过于集中在服务器的问题。

图2  客户/服务器式体系结构

（1）客户端每一次操作必须通过服务器统一处理。这样使信息交互中的大量负担集中到了服务器，客户端只执行一些简单任务。特别是在如今系统规模不断扩大的情况下，对服务容量要求必然会迅速增加，负荷进一步加重，严重情况下，很可能导致网络拥塞，服务器处于瘫痪状态。

（2）同时由于客户/服务器结构中服务器必须处理大量的信息，且客户端均由服务器连接，如若要加入新的客户端虽不影响其它客户端的运行性能，但必须对服务器进行调整修改，服务器软件也将被修改后才能使得整个系统运行正常，这时，修改服务器将导致服务器部分失效或全部停止运行。其它客户端无法交换信息进行连接，必然影响到整个监控系统的正常运行。

（3）传统的客户/服务器应用软件模式大都是基于“肥客户机”结构下的两层结构。它面临的一个主要的问题是系统的扩展及安装维护困难。开发人员写出的程序在客户端运行，占用了大量的系统资源和网络资源。而在分布式实时控制系统中，c/s结构更显出他的不足：

client与server直接连接，没有中间结构来处理请求，server定位通常需要网络细节，server必须是活动的（active），客户端的应用程序严格依赖于服务器端数据存储和组织方式。应用接口的异构性严重影响系统间的互操作。许多相同的功能模块被多次重复开发，代码的重用很困难。无法保证数据的实时性，系统可扩展性差（无法实现在线维护和在线扩展），容错性差，对多数据类型的应用支持较差。

由一个中心服务器处理所有数据，所有的数据都必须通过服务器的中转，而不是直接的点对点的方式，从而增加了不必要的延时。这种模式在服务器具备所有需要的信息的时候可以正常工作，而当数据来源于多个节点且同时又被多个节点使用的时候就显得力不从心了。而且服务器还是整个系统的性能瓶颈，若服务器由于某种原因出现故障，则整个系统的通信都将陷入瘫痪。

所以，客户/服务器结构无法满足分布式实时应用系统的需求。 4.  系统的通信模型

      传统的通信模型对应于其传统的体系结构，同样具有一些技术上的问题需要解决。传统的通信分为polling型和请求/应答型（request/reply）。

（1）polling通信模型

     

              

      其主要问题在于控制中心的服务器采用定时轮询技术，控制中心发出信息后，各个客户端是按照与控制中心联接的顺序来接收信息并对控制中心的信息做出反应，例如在master对slave1发出信息后，slave1接收信息并做出反应后将发出回馈信息到master, master在接收到slave1的信息后再向slave2发送信息，以此类推，在最末端的slave i将在最后接收到master发出的信息，在这个过程中如若其中某一个slave出现问题或联接中断，则该slave后的其他客户端将接收不到信息，无法做出反应。并且这种通信方式将花费大量的时间，对于监控系统的可靠性和实时性造成很大的障碍。

（2） 请求/应答通信模型（request/reply）则对应于客户/服务器体系结构。

          

           

      请求/应答通信模型是基于tcp/ip协议的一种网络化通信模型。它是一种客户端向服务器发出发送信息的请求后，在得到服务器应答后才能发送信息的通信模式。与polling通信模型相比较而言，其优点在于无需各客户端按照顺序来进行应答，从而节省了大量的时间，但是如若一旦服务器发生故障，则通信就无法进行，也将影响到监控系统的正常运行。

     从上述两种通信模型来看，两者都有一些技术上的问题有待解决，而影响了监控系统的动态扩展及可靠性，需要有新的通信模型来加以改进。

5. 自律分布系统结构

      自律分布系统(autonomous -decentralized system---ads)，在降低系统复杂程度、实现系统的扩展方面是一个很大的进步。自律分布的思想是向生物学习而提出来的。在生物体中，每个细胞具有相同的遗传信息。据此，自律分布系统认为构成系统的各个节点具有相同的潜在能力，任何一个节点可以从其他节点接收信息，然后选择必要的信息加以自律地处理。在自律分布系统中，任何程序只与数据域(池)发生联系，从而避免了程序之间的直接连接，有效地降低了系统的整体复杂性。在自律分布系统中，采用功能码通信方式。发送数据的节点将数据与表示其内容的功能码组成一对，向数据域（池）发送。接收数据的节点从数据域中读取数据。当一个程序所需的数据到达数据域时，由系统自动启动该程序。这种方式称为数据驱动方式。数据域、功能码通信、数据驱动是自律分布系统的三大特征。自律分布系统已从专用控制网络扩展到通用网络如以太网。自律分布系统在降低系统复杂性和实现系统在线扩展、在线维护和在线容错方面是有效的。

四、解决方案---自律分布系统（ads）技术

1．ads技术综述

      系统规模不断扩大的趋势表明，在设计自动化系统时，不可能一次性将各个部分、各个环节都考虑完整周全，而必须随着系统的分阶段建设不断扩充规模、不断完善功能。现有的自动化系统都是一次性建设完毕，如要进行扩充和维护，只能终止整个系统的运行，这必然会给运输造成极大的经济损失。自律分布系统，即ads（autonomous decentralized system）。构成自律分布系统的首要条件是子系统的存在性。整个ads 系统是不能事先定义的，只能笼统地定义为若干子系统的集成。ads 系统最关键的特点就是子系统的自我控制和自我协调的能力。

(1)自我控制表现在一旦某个子系统出现故障、进行维修或刚刚加入，其它子系统可以不受干扰地管理和运行自己的功能。

(2)自我协调是指一旦某个子系统出现故障、进行维修或刚刚加入，其它子系统能够在在它们内部协调处理完成各自的任务。

      正是子系统的这两个特点保证了整个系统的在线扩展、在线维护和容错。因此根据ads 思路设计的自动化系统体现了以下优点：

      首先，它不再基于传统的c/s 模型，而是由若干子系统构成。各个子系统之间是相互平等的，不存在依附关系，可以自主运作，但这并不表明它们不与外界交换信息。实际上，各个子系统不断向外界以广播方式发送信息，同时又根据各自需求接收来自外界的信息以为自己服务。这样一来，c/s 模式中服务器大量的负担被有限地分散了，而且加快了子系统间信息的交换速度。

      ads的核心协议adp是建立在tcp/ip的udp协议之上的一个应用层协议。因此，只要支持tcp/ip协议的环境都可以支持ads技术。目前，ads标准草案（iso/tc184/sc5/sg5）已提交给国际标准化组织，即将被采纳为国际标准。另外，ads 与opc（ole  for process control）和corba的融合及其标准化工作正在进行之中。

      日本东京圈自律交通运行控制系统（atos）是目前世界上最大的自律分布系统，它管理着东京地区的200多个车站和2000多公里线路。实现了行车指挥、设备监控和旅客信息服务综合自动化，实现了列车的高密度运行（120秒），实现了系统的分阶段的建设。具有典型性和代表性。如下图所示。

2.  ads的技术成熟性

      自律分布系统体系结构和相关技术是成熟的、可靠的，其理由如下：

（1）ads是一种开放的技术

ads的核心协议adp是建立在tcp/ip的udp协议之上的一个应用层协议。因此，只要支持tcp/ip协议的环境都可以支持ads技术。

（2）ads即将被采纳为iso国际标准

目前，ads标准草案（iso/tc184/sc5/sg5）已提交给国际标准化组织，即将被采纳为国际标准。

另外，ads 与opc（ole  for process control）和corba的融合及其标准化工作正在进行之中。

（3）ads有成功的应用实践

日本东京圈自律交通运行控制系统（atos）是目前世界上最大的自律分布系统，它管理着东京地区的200多个车站和2000多公里线路。实现了行车指挥、设备监控和旅客信息服务综合自动化。实现了列车的高密度运行（90秒），实现了系统的分阶段的建设。具有典型性和代表性。

（4）ads有较成熟的开发平台和工具

目前，自律分布系统的主要开发工具有：nxdlink, nxdfs, nxconstructor32, nxmart-view, nxmart-watch等。均支持目前主流的操作系统平台如unix, windows nt, 还支持plc和设备网（devicenet）。

因此，采用自律分布系统在技术上是完全可行的，其产品是可靠的。

3．采用ads技术的城市轨道交通自动化系统主要特点

3．1 在线可扩展性

（1）在系统中假如有新节点（车站）加入，在数据域中的所有节点都将接收这一信息，同时可在控制中心看见这个新站加入系统中。

（2）假如在线的车站突然因为网络故障退出了网络系统，其他所有节点都会知道这一状况，当网络故障被排除以后，节点重新加入系统，并且自动向控制中心发送自己最新的信息。并且尽力来恢复故障前的状态，可见系统有很好的伸缩性。

3．2 在线可维护性

      运行图文件可以在控制中心在线修改，修改后可以下传到各个车站控制子系统。在节点在线的情况下可以自由地对软件系统内容进行修改和维护。

3．3 在线容错性

（1）假如控制中心主机发生了故障，在控制中心的其它备用主机就会自动取得控制中心的控制权，同时系统中的其它节点也会重新确认新的控制中心节点，向它传输最新的信息。当发生故障的原控制中心主机重新加入系统以后，系统会自动的接纳它，同时它也会确认为新的控制中心。

（2）处于远程控制模式下的车站节点，在发生本地网络故障时，该节点会将自己升级为控制中心并且由远程控制模式切换为本地控制模式。

（3）在发生灾害时普通节点可以通过请求应答的方式来向控制中心请求成为控制中心，这样控制中心就可以自由的漂移。可见系统有较为理想的在线容错性。

3．4 能较好地贯彻信息集中控制分散的技术路线

      信息集中要保证信息的实时性。这里有二层含义：调度中心实时地得到列车在线信息；各个车站平等地得 到调度中心的运行图信息。ads系统采用的/定购通信模型能很好地保证信息的实时性。控制命令在网络上传输的话，通信线路故障或主机故障将导致系统失效。采用ads技术实现控制分散可有效避免系统失效的风险。

      在ads体系中，由于各个系统节点是对等的，任何一个节点都具有潜在的相同的能力，区别只是应用层的功能不同而已，而且这种区别是由管理者的方便造成的，而不是设计阶段决定的。这意味着系统中的任何一个节点随时可以成为控制中心。这种灵活性对保证系统的可用性是非常有效的，特别是在灾害发生时。此外，车站节点的本地/远程运行模式能方便地实现调度中心临时管制。

五、结论

      本文从七个方面对城市轨道交通系统的特点进行了分析，进而提出了轨道交通系统的五大技术需求，分别是1）系统的在线扩展性；2）系统的在线维护和测试性；3） 系统的在线容错性；4）信息集中、控制分散的技术路线；5）调度中心-车站-现场作业人员协同的业务分担模式。

      在此基础上，提出了城市轨道交通自动化系统新的设计开发理念和方法。为满足城市轨道交通系统的技术需求，需要建立设计开发理念和方法。为实现城市轨道交通系统运输组织的多样化和高密度化，采用信息集中、控制分散的技术路线是一种理想选择；调度中心-车站-现场作业人员协同的业务分担模式对实现城市轨道交通系统的高效协同运行有重要意义；自律分布体系结构是适合于大规模城市轨道交通自动化系统的理想选择；采用自底向上，由子系统逐步构成整个系统的系统设计方法学可以支持城市轨道交通自动化系统分阶段建设实施。

      最后对自律分布系统技术进行了综述，并从技术成熟性和技术特点的角度对其进行了分析和讨论。采用自律分布系统技术在技术上完全可行的，同时自律分布系统能很好地满足城市轨道交通自动化系统的技术需求并支持本文提出的设计开发理念和方法。

参考文献

[l] f. kitahara et al. “distributed management for software maintenance in a wide-area railway system”, proc. of isads97, berlin, germany, 1997, pp. 311-318

[2] f. kitahara,et al. “widely-distributed train-traffic computer control system and its step by step construction”, proc.of isads95, phoenix, u.s.a., 1995, pp.93-102

[3] k. mori, et al. “autonomous decentralized software structure and its application”, proc. of fjcc’86, dallas, u.s.a., 1986, pp. 1056- 1063

[4] k. mori, “autonomous decentralized systems: concept, data field architecture and future trends”, proc. of isads93, kawasaki, japan, 1993, pp.28-34

[5] k. kawano, et al. “autonomous decentralized system test technique”, proc. of compsac89, florida, u.s.a., 1989, pp.52-57

[6] h. yamamoto, et al. “on-line software test techniques based on autonomous decentralized system concept”, proc. of the forth workshop on future trends of distributed computing systems, lisbon, portugal, 1993, pp.29 l-296

[7] tetsuo takashige, “signalling systems for safe railway transport”, japan railway & transport review 21, september 1999, pp.44-50

[8] kazuo kera, et al.  “hitachi’s initiatives in addressing the challenges of 21st century railway systems”, hitachi review vol. 48 (1999), no. 3, pp.126-133

[9] fumio kitahara, et al.  “phased-in construction method of atos”, proc. of isads99, tokyo, japan, 1993, pp.415-424

[10] hiroshi wataya et al. “the cooperating autonomous decentralized system architecture”, proc. of isads95, phoenix, u.s.a., 1995, pp.40-47

[11] takashi kawakami, “future framework for maglev train traffic control system utilizing autonomous decentralized architecture”, proc. of isads97, berlin, germany, 1997, pp.327-333

体系结构范文第4篇

关键词：WEB服务；面向服务的体系结构（SOA）；XML；SOAP；WSDL；UDDI；ESB

1 引言

最近几年，在企业级的IT行业中讨论最热门的话题莫过于面向服务的架构体系（Service-Oriented Architecture，SOA）。那究竟什么是SOA， SOA发展的怎样，它又会给我们带来什么好处呢？

2 背景介绍

自从上世纪70年代“软件危机”这个名词出现以来，软件业的许多从业人员都一直致力于摆脱这个问题。著名学者、中科院软件所仲萃豪研究员曾经说，为了解决软件危机，软件开发方法在20多年的时间里取得了三大成果，即基于构件体系结构的开发方法、基于UML的建模语言、面向服务的体系结构（SOA），而软件发展的下一个里程碑就是SOA。同时，迅猛发展的网络技术，如网络服务（Web Service），也为SOA的发展奠定了良好的基础。由此可见，SOA是软件工程未来发展的一个重要方向。

3 国内外现状

许多企业都很看好SOA。来自中国2005IBM整合论坛上针对1000多位企业IT决策者的调查显示，曾经有65％的企业认为SOA能够保持IT和业务协调一致，加强企业中IT和业务运营的管理水平，有21％的企业认为SOA能够充分利用现有的IT投资，增强重复使用的能力。

同时，数据也显示，只有6％的企业已经开始使用SOA进行整合，因此，对于大部分企业来说，SOA是一个热门话题。但是，数据也显示，有39％的企业，考虑过在企业中实施SOA。

另外，Gartner在一份报告中也曾经指出，截止到2008年，80％的客户将使用SOA用于新产品开发。在目前许多企业还是通过硬线（Hard－wired）关联的模式之下实现企业内外部应用沟通的情况下，企业很难快速响应市场需求变化。

4 SOA的基本含义

SOA是service-oriented architecture的缩写，即面向服务的架构，或者称为面向服务的体系结构。

从SOA字面上不难看出，SOA是一种软件体系架构，是一种组织IT基础结构及业务功能的方法，是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）的模型。它将会给计算机软件工程的发展产生深远的影响。

下面是几个关于SOA的定义：

IBM公司是这样给SOA定义的：“SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。”

将SOA定义为：“本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。”

定义的SOA为：“按需连接资源的系统。在SOA中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，SOA规定了资源间更为灵活的松散耦合关系。” [1]

虽然不同厂商或个人对SOA有着不同的理解，但是我们仍然可以看到SOA中的关键是“服务”。另外还可以看出它的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

5 使用SOA的好处

在讨论SOA的好处之前，我们先来看一个场景。A企业的IT系统已有十余年的历史，其主要的业务系统构建于上世纪九十年代，围绕核心系统又开发了许多基于UNIX的非核心业务系统以及基于.NET的简单应用。这些形形的应用，采用不同的技术开发，有的用汇编或COBOL编写，有的用PB编写。近年来，A企业面临越来越强烈的信息整合需求，为生产经营提供决策支持。然而，要想最大限度地减少对现有系统的更改，同时又要实现高度的数据集成，A企业意识到困难重重。[2]

相信大家从上面这个场景，不难看出，SOA确实会给我们的企业带来很大的好处。

其一，可以使业务更加灵活。众所周知，SOA体现的是一种松耦合的系统。松耦合系统的最大好处就是可以使业务灵活自如。这样业务应用程序可以根据业务的需要变得更加灵活，从而适应不断变化的业务环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素等。这就是行业经常提及的“On-demand Businiss（按需业务）”。因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常灵活。

其二，可以节约企业成本。“重用”概念在SOA的系统中尤为突出。SOA要求开发人员跳出应用本身进行思考，考虑他们的服务如何能够被其他项目重用。这样可以为开发人员节约大量时间。另一方面，基于SOA的企业系统架构通常都是在现有系统架构投资的基础上发展起来的，我们并不需要彻底重新开发全部的子系统；SOA可以通过利用当前系统已有的资源（开发人员、软件语言、硬件平台、数据库和应用程序）来重复利用系统中现有的系统和资源。这样就可以使现有的IT资产得到充分利用，从而大大的节省了企业的运营成本。

其三，可以增强系统间协作性。目前，许多大的信息系统的各子系统间的协作性不是很强。尤其是在大型公司，如单一的全球化公司、分区域组织（每个地区独立运作但协同支持）的公司、多种业务划分的公司、有分支网络的公司、分级制的公司等公司的系统中，协作性工作更为重要。这样就可以基于现有网络的基础设施使用SOA模式建立系统，允许分散于各地且采用不同技术的资源协同工作，从而使系统间的协作性更强。

其四，可以使公司业务和IT保持更高的一致性。众所周知，由于市场的变化日趋迅速，需要企业及时做出响应，而基于传统软件架构模式构建的软件信息系统是依据事先的需求分析和系统架构设计来完成的，这种需求反映的往往只是企业过去某一时间点的业务流程。待到系统开发设计完成，企业的需求已经发生了变化，系统架构和业务流程之间存在偏差，系统必定不能发挥其最大功效。然而，基于SOA的软件架构模式构建的软件信息系统要求系统在企业需求发生变化后，其业务流程会随之实时改变。这样，就可以保证使IT与业务高度一致。从而，企业的信息系统真正变成了实时企业系统。这也就是有人曾经提出的“并行业务工程”的概念。

其五，可以标准化整个企业内的流程，从而易于集中企业控制。构建SOA系统，需要通过规范的业务流程将一个个的服务组织起来。同时，SOA也是一种集中系统，这其中可以包含来自组织的不同部门的服务，甚至还能包含来自组织外的服务。如果没有恰当的控制，这种系统很容易失控。这就要求企业来集中控制流程管理，从而形成标准化

的流程规范。

6 SOA关键技术

面向服务的架构SOA主要用到以下关键技术：

6.1 XML

XML 1.0（可扩展标记语言，Extensible Markup Language）标准是一个基于文本的 World Wide Web 组织 (W3C) 规范的标记语言，是用于网络上数据交换的语言。XML 严格地定义了可移植的结构化数据。

6.2 SOAP

简单对象访问协议（SOAP）是一种轻量的、简单的、基于XML的协议，它被设计成在网络上交换结构化的和固化的信息。它可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。主要包括三个部分：封装、编码规则、RPC表示。

6.3 WSDL

Web服务描述语言WSDL(Web Services Description Language)是用于描述Web服务的一种XML语言。Web服务通过描述SOAP消息接口的 WSDL文档来提供可重用的应用程序功能，并使用标准的传输协议来进行传递消息。WSDL是基于XML的，它的描述包含请求消息格式、响应消息格式和向何处发送消息等几个必要的细节，以便服务请求者能够使用特定服务。

6.4 UDDI

统一描述、发现和集成（Universal Description, Discovery and Integration）规范提供了一组公用的SOAP API，使得服务得以实现。UDDI为服务的可用性和发现所需服务定义了一个基于SOAP消息的标准接口。UDDI 实现将和发现服务的SOAP请求解释为用于基本数据存储的数据管理功能调用。

为了和发现其他SOA服务，UDDI通过定义标准的SOAP消息来实现服务注册。注册是一种服务，它是在UDDI上需要发现服务的请求者和服务的提供者之间的中介。一旦请求者决定使用特定的服务，开发者通常借助于开发工具并通过创建以发送请求并处理响应的方式访问服务的代码来绑定服务。[3]

6.5 ESB

企业服务总线ESB（Enterprise Service Bus）是SOA架构的一个支柱技术。它包含了服务、服务提供者、服务使用者、服务定位器、服务、服务管理等几个部分，其主要功能有：通信和消息处理、服务交互和安全性控制、服务质量和服务级别管理、建模、管理和自治、基础架构智能等。

图1展示了ESB中面向服务的体系结构中的协作关系。

图1 ESB中的协作（错误！文档中没有指定样式的文字）

从图1可以看出，在ESB中的协作流程为：

(1)服务使用者发起对注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。服务使用者根据接口契约来执行服务。

(2)服务提供者接受和执行来自使用者的请求。它将自己的服务和接口契约到服务注册中心，以便服务使用者可以发现和访问该服务。

(3)服务注册中心是服务发现的支持者。它包含一个可用服务的服务储备库，并允许感兴趣的服务使用者查找服务提供者接口。

服务管理所集成的元素可以分成功能元素和服务质量元素两部分，如图2所示。其中左半部分为功能元素，右半部分为服务质量元素。

功能性方面包括：

(1)传输：是一种通信机制，用于将来自服务使用者的服务请求传送给服务提供者，并且将来自服务提供者的响应传送给服务使用者；

(2)服务通信协议：是一种经过协商的机制，通过这种机制，服务提供者和服务使用者可以就将要请求的内容和将要返回的内容进行沟通；

(3)服务描述：是一种经过协商的模式，用于描述服务是什么、应该如何调用服务以及成功地调用服务需要什么数据；

(4)服务：描述实际可供使用的服务；

(5)业务流程：是一个服务的集合，可以按照特定的顺序并使用一组特定的规则进行调用，以满足业务要求。注意，可以将业务流程本身看作是服务，这样就产生了业务流程可以由不同粒度的服务组成的观念；

(6)服务注册中心：是一个服务和数据描述的存储库，服务提供者可以通过服务注册中心它们的服务，而服务使用者可以通过服务注册中心发现或查找可用的服务。服务注册中心可以给需要集中式存储库的服务提供其他的功能。

服务质量方面包括：

(1)策略：是一组条件和规则，在这些条件和规则之下，服务提供者可以使服务可用于使用者。策略既有功能性方面，也有与服务质量有关的方面；因此，我们在功能和服务质量两个区中都有策略功能；

(2)安全性：是规则集，可以应用于调用服务的服务使用者的身份验证、授权和访问控制；

(3)事务：是属性集，可以应用于一组服务，以提供一致的结果。例如，如果要使用一组服务来完成一项业务功能，则所有的服务必须都完成，或者没有一个完成；

(4)管理：是属性集，可以应用于管理提供的服务或使用的服务。

7 结束语

总的来说，SOA目前还处在一个发展阶段，很多标准目前还在制定，不同厂商间还存在不兼容的现象，因此SOA还不能说已经是一个成熟的技术，还在“进行中”，需要时间的检验。所以，在这个充满变数的激烈竞争市场中，我们应该冷静分析自己的系统，权衡利弊，不盲目跟进。只有冷静务实才能生存、发展。

参考文献：

[1]崔晓波. SOA概览[EB/OL]. /csdn_document/archive/2004/08/19/79262.aspx.

[2]喻思成. 跨平台实施SOA不再遥远[J/OL]. 软件世界，2006,(8).

[3]庞引明. 实现SOA的相关技术[J/OL]. 计算机世界报，2005.9.15.

[4]袁红岗. SOA现在进行时[J/OL]. 软件世界, 2006(8).

[5]Min Luo，Mark Endrei, Philippe Comte, Pal Krogdahl, Jenny Ang，Tony Newling. 《面向服务的体系结构概述》，IBM 红皮书, Patterns: Service-Oriented Architecture and Web Services.

[6]李大成，陈莘萌. UDDI技术及应用概览[J]. 计算机工程，2002,(12).

体系结构范文第5篇

［关键词］ 装备保障；任务规划；系统；体系结构

doi : 10 . 3969 / j . issn . 1673 - 0194 . 2012 . 16. 035

［中图分类号］ E917 ［文献标识码］ A ［文章编号］ 1673 - 0194（2012）16- 0055- 03

任务规划是一门伴随现代信息技术而发展起来的高新技术，已被广泛应用机、水面舰艇、地面车辆的导航系统中。目前国内关于任务规划的研究主要集中在作战指挥方面，而装备保障指挥方面的研究则十分欠缺。为提高和确保装备保障力量的保障效能和生存能力，故对装备保障任务规划系统体系结构进行研究，以适应未来战争的信息化、智能化和无人化发展趋势。

装备保障任务规划系统，指在从保障任务目标确定到保障任务完成的整个过程中，安排装备保障力量执行何种保障任务以及如何实施保障，使装备保障力量生存概率和整体保障效能达到最佳。整个规划系统由威胁建模、威胁评估、任务分配、路径规划、战术决策以及指控中心等子系统组成，并在指控中心系统的指挥控制下，实现对装备保障任务的规划与实时重新规划。规划系统最后所给出的具体规划结果包括装备保障力量分配、保障任务分配和保障路径。

1 系统需求分析

装备保障是为满足部队遂行各项任务的需要，对装备保障采取的一系列保证性措施以及进行的相应活动的统称。装备保障力量是实施装备保障的主体，装备保障的对象是装备保障任务，装备保障的过程即装备保障力量完成装备保障任务的过程。装备保障力量与装备保障任务，在正常情况下，二者是一一对应关系，即有多少的保障任务就有多少对应的装备保障力量。但实际上，通常情况下实际的装备保障力量是少于装备保障任务所需的装备保障力量的，战时这种差距更大。信息化战争条件下，战场环境复杂、作战样式多变，首先直接导致了装备保障任务的多样、多变及不确定性，难以准确预测装备保障任务类型、数量、发生地点等；其次也导致装备保障力量的战损、补充的动态变化。二者关系如图1所示。二者的这种不确定性与动态性，最终导致装备保障复杂性、不确定性甚至是低下的装备保障效率。这就需要对装备保障任务与装备保障力量进行规划，减少二者之间对应的不确定性，增强装备保障效益。

由于战时装备保障任务主要是由敌方攻击导致装备的战损而产生装备保障任务，这导致装备保障任务的不确定性远远高于装备保障力量，因此上述规划应以装备保障力量为基础。未来装备保障力量模块化编组是装备保障力量发展的趋势，加之战时装备保障力量是按照群—队—组的形式区分编组装备保障力量的， 因此，该规划系统中将装备保障力量划分为装备保障力量单元，并以装备保障力量单元为基本研究对象。

2 系统基本功能

对装备保障而言，装备保障任务规划系统的基本功能是根据装备保障能力和装备保障任务地域地理环境、威胁环境等因素，为装备保障任务目标规划出满足要求的保障力量与保障路径，并可以根据需要进行局部重新规划。为确保装备保障过程中装备保障力量的有效利用和任务的完成，一般需要多种装备保障力量单元进行协同，因此对于装备保障任务规划系统而言，协同功能尤为重要。其主要功能包括：

2．1 系统内的多装备保障力量单元保障任务规划与分配

将保障任务按重要性、紧迫性进行区分，按照保障任装备保 障力量单元在保障地域的分布，调配相应的装备保障力量单元。例如：有M个装备保障力量单元要对N个保障任务目标进行保障，如何对这些装备保障任务进行分配要根据保障效能以及目标的重要程度进行合理分配。首先任务规划系统按照重要性与紧迫性选取任务目标进行保障，并确定任务目标的保障顺序及任务路径。

2．2 装备保障力量单元间共享资源的协调

为完成所分配的任务，合理地将系统中的共享资源（如通用工具子系统、技术人员、通信、控制系统以及各种信息等）分配给各个装备保障力量单元。这要求装备保障力量单元具有较强的数据通信能力以及数据融合的能力，以便装备保障力量单元之间要进行最低限度的通信，既能实现相互协同，又能保证隐蔽性，不容易被敌方侦察和干扰。

2．3 多装备保障力量单元之间的协同任务路径规划

在装备保障过程中，当某个装备保障力量单元被指派去完成某个确定的装备保障任务，二者之间的能力与需求关系是确定的，那么装备保障力量单元如何到达装备保障任务地点即选择机动路径就十分重要。规划系统根据保障任务地域环境，综合评估战场威胁、通行条件、任务时间、通信条件等，规划装备保障任务路径。同时，在任务路径规划过程中，需要做好装备保障力量单元之间的协同，避免多个装备保障力量单元进行同一个保障任务等造成的保障力量局部过剩、重要保障任务目标装备保障力量稀缺的现象。

2.4 多装备保障力量单元之间的协同控制

主要指多装备保障力量单元在机动途中的协调控制，避免装备保障局部过度集中造成目标过大，及共同完成某项任务时力量单元之间的协调操纵及其控制。

3 多保障力量单元协同任务规划系统的体系结构

在复杂多变的战场环境中，装备保障任务规划系统的体系结构在很大程度上决定着系统作战的效率和灵活性，体系结构的选择应能使系统满足良好的伸缩性、高鲁棒性、高可靠性、快速反应能力、动态重构能力以及容错能力等要求。

体系结构范文第6篇

关键词：远程医疗；健康监护；体系结构；躯域传感器网络

中图分类号：TP393

老年人口在社会所占比重越来越大，老年人患病率高，慢性病患者多，且有相当一部分人行动不便，尤其空巢老人的健康管理问题越来越突出[1]。因此，如何利用现有的医疗资源，为病人提供更为高效的医疗和监护服务成为一个亟待解决的问题。近年来，随着信息技术、电子技术的发展，远程医疗监控系统[2]随之迅速发展起来，西方发达国家已广泛开展了远程医疗监控系统的研究。

哈佛大学开展了“Code-Blue”项目[3]，该项目提供紧急救助或灾难情况下的现场医疗监控。研究人员自行开发设计了便于携带的小型血氧仪、心电监护仪，并结合ZigBee通讯协议[4]，将信号传输给医疗救助人员。Lin等人介绍了一套以PDA技术和无线网络技术为基础的移动病人监护系统[5]，用PDA来持续采集病人的生理信号，PDA与远程控制中心通过无线连接。

1 体系结构

远程医疗监护系统的体系结构如图1所示，主要包括：生理信号采集传感器节点、躯域传感器网络（Body Sensor Network，BSN）、健康监测服务终端、远程医疗服务系统四大部分。生理信号采集传感器节点实现人体多种生理信号的准确无创伤采集功能；BSN实现生理信号采集传感器节点与监测服务终端的自组网和无线传输；健康监测服务终端将采集到的各种生命体征数据通过无线技术传送至远程医疗服务系统；远程医疗服务系统对数据作进一步的解析、保存，为医院、医生、患者提供服务。

（1）生理信号采集传感器节点实时监测人体生理信号，具体包括：心电信号、血氧饱和度（SPO2）、血脂、血压、人体体温、呼吸等生理信号的监测；并将采集后的结果无线发送给健康监测服务终端。

（2）躯域传感器网络是实现人体生理信号获取与处理的基本平台。生理信号采集传感器节点与健康监测服务终端组成一个BSN，健康监测服务终端是该BSN的汇聚节点，生理信号采集传感器节点通过一跳或多跳的自组织网络把数据发送到健康监测服务终端。

（3）健康监测服务终端主要实现用户与远程医疗服务系统的交互功能。目前有两种形式的服务终端：一是研发健康监测专用服务终端；另一种是利用用户已有的智能手机、平板电脑等作为服务终端。服务终端的功能具体包括：

存储并以图形方式显示采集到的各种生命体征数据；

对接收的数据进行实时分析，检测健康状况；

通过GPRS、WIFI等无线通信技术将监测数据传送至远程医疗服务系统；

实时下载远程医疗服务系统上最新诊断信息，查看历史诊断、和处方信息；

病人自感不适时可手动触发紧急事件按钮，通过远程医疗服务系统请求医生进行远程诊断。

（4）远程医疗服务系统是面向社区服务中心、医生、医院、家庭用户的综合服务系统。该系统对用户健康数据实现存储、管理及分析功能，具体包括：

接收健康监测数据，并保存到数据库，为每个人建立健康信息档案；

远程终端控制，医生通过该系统可以控制患者的终端，例如：启动生理参数测量、启动生理信号的传输、向特定用户推送处方及诊断结果等；

海量监测数据的挖掘，协助医生做出诊断；

对多类用户进行管理，并提供服务；

诊断信息以短信形式发送到病人用户的手机中，或者到健康监测服务终端。

2 面临的关键问题

虽然目前在远程医疗监护技术已经取得了大量的研究进展，但也面临着如下关键问题：

抗干扰生理信号检测技术。生理信号的连续监测对掌握患者全面的身体情况尤为关键。虽然远程医疗的出现使连续监测成为可能，但由于家庭用户的生理信号检测容易受到运动等因素的干扰，目前，抗干扰的生理信号连续检测技术仍处在研发过程中。

生理信号智能诊断。智能诊断是远程医疗的难题之一，可采取在服务终端对健康监测数据进行实时分析，运行时间复杂度及空间复杂度较低的智能诊断算法，例如：异常阈值检测、心率计算、异常自动报警等；在远程医疗服务器上利用数据挖掘等方式对大规模健康监控数据实现复杂的智能诊断。

BSN关键问题研究。用户在日常生活中，所处环境多变，要求BSN具有良好的抗干扰能力：运动抗干扰能力、电磁辐射抗干扰能力、数据传输抗干扰能力等。另外节点间的时间同步，区分服务的网络拥塞控制也是BSN要解决的关键问题。

3 结论

远程医疗技术已成为一个重要研究领域，发展远程医疗技术，越来越被证明是大幅降低医疗和就医成本、改善医疗资源分布及提高医疗整体水平的重要手段。本文设计了远程医疗监护系统体系结构，并提出其面临的关键问题，有助于推动远程医疗监护系统的实施和研发。

参考文献：

[1]穆光宗，张团.我国人口老龄化的发展趋势及其战略应对[J].华中师范大学学报（人文社会科学版），2011，5（3）：29-36.

[2]周笑，李明，卜佳俊.移动远程医疗监护系统的设计与实现[J].计算机工程，2010，10（6）：251-253.

[3]S.Patel，K.Lorincz，R.Hughes，N.Huggins，et al.Monitoring Motor Fluctuations in Patients With Parkinson's Disease Using Wearable Sensors [J].IEEE Transactions on Information Technology in Biomedicine，November 2009，13（6）：864-873.

[4]P.Baronti，P.Pillaia，et al.Wireless sensor networks：a survey on the state of the art and the 802.15.4 and ZigBee standards[J].Computer Communications，2007，30（7）：1655-1695.

[5]Y.Lin，I.Jan，P.Ko，et al.A wireless PDA-based physiological monitoring system for patient transport[J].IEEE Transactions on Information Technology in Biomedicine，2004，8（4）：439-447.

体系结构范文第7篇

物联网体系结构可分为三层：感知层、网络层和应用层。

物联网（TheInternetofThings，简称IOT）是指通过各种信息传感器、射频识别技术、全球定位系统、红外感应器、激光扫描器等各种装置与技术，实时采集任何需要监控、连接、互动的物体或过程，采集其声、光、热、电、力学、化学、生物、位置等各种需要的信息，通过各类可能的网络接入，实现物与物、物与人的泛在连接，实现对物品和过程的智能化感知、识别和管理。物联网是一个基于互联网、传统电信网等的信息承载体，它让所有能够被独立寻址的普通物理对象形成互联互通的网络。

物联网的基本特征从通信对象和过程来看，物与物、人与物之间的信息交互是物联网的核心。物联网的基本特征可概括为整体感知、可靠传输和智能处理。整体感知―可以利用射频识别、二维码、智能传感器等感知设备感知获取物体的各类信息。可靠传输―通过对互联网、无线网络的融合，将物体的信息实时、准确地传送，以便信息交流、分享。

（来源：文章屋网 ）

体系结构范文第8篇

国际标准化组织ISO于1983年正式提出了一个七层参考模型，叫做开放式系统互联模型（通称ISO/OSI）。[1]OSI参考模型将整个网络通信的功能划分为7个层次，由底层到高层分别是物理层、链路层、网络层、传输层、会话层、表示层和应用层。每层完成一定的功能，都直接为其上层提供服务，并且所有层次都互相支持。第4层到第7层主要负责互操作性，而1～3层则用于创造两个网络设备间的物理连接。

一、第1层：物理层

物理层是OSI参考模型的最低层，且与物理传输介质相关联，该层是实现其他层和通信介质之间的接口。物理层协议是各种网络设备进行互联时必须遵守的低层协议。

物理层为传送二进制比特流数据而激话、维持、释放物理连接提供机械的、电气特征、功能的、规程性的特性。这种物理连接可以通过中继系统，每次都在物理层内进行二进制比特流数据的编码传输。这种物理连接允许进行今双工或半双工的二进制比特流传输的通

物理层相应设备包括网络传输介质（如同轴电缆、双绞线、光缆、无线电、红外等）和连接器等，以及保证物理通信的相关设备，如中继器、共享式HUB、信号中继、放大设备等。

二、第2层：数据链路层

数据链路层是OSI参考模型的第2层，介于物理层与网络层之间，其存在形式分为物理链路与逻辑链路。

设立数据链路层的主要目的是利用在物理层所建立的原始的、有差错的物理连接线路变为对网络层无差错的数据链路，因此数据链路层必须有链路管理、帧传输、流量控制、差错控制等功能。数据链路层所关心的主要是物理地址、网络拓扑结构、线路选择与规划等。

数据链路层的数据传输是以帧为单位。在OSI中，帧被称为数据链路协议数据单元，它把从物理层来的原始数据打包成帧。数据链路层负责帧在计算机之间的无差错信息传递。

数据链路层设备主要包括：网络接口卡（NIC）及其驱动程序、网桥、二层交换机等。

三、第3层：网络层

网络层是OSI参考模型中最复杂、最重要的一层。这一层定义网络操作系统通信用的协议，为信息确定地址，把逻辑地址和名字翻译成物理的地址。它也确定从信源机（源节点）沿着网络到信宿机（目的节点）的路由选择，并处理交通问题，例如交换、路由和对数据包阻塞的控制。

网络层的主要提供以下功能

1.路径选择与中继。路径选择是指在通信子网中，为源节点和中间节点选择后继节点，以便将报文分组传送到目的节点。“最短时间”是选择路径的标准。[2]

2.流量控制。网络中链路层、网络层、传输层等都存在流量控制问题，其控制方法大体相一致。其目的是防止通信量过大造成通信于网性能下降。

3.拥塞控制。当到达通信子网中某一部分的分组数高于一定的水平，使得该部分网络来不及处理这些分组时，就会使这部分以至整个网络的性能下降。拥塞控制的主要任务是保证网络高性能运转，保证子网不被它的用户发送的数据所淹没。

工作在网络层的设备主要有路由器和三层交换机。路由器通过转发数据包来实现网络互连,其支持的协议有TCP/IP、IPX/SPX、AppleTalk等。三层交换机使用了三层交换技术，解决了局域网中网段划分之后，网段中子网必须依赖路由器进行管理的局面，解决了传统路由器低速、复杂所造成的网络瓶颈问题。

四、第4层：传输层

传输层是OSI参考模型的第4层中，是比较特殊的一层。该层的为源主机与目的主机进程之间提供可靠的，透明的数据传输，并给端到端数据通信提供最佳性能。

传输层从会话层接收数据，负责错误的确认和恢复，以确保信息的可靠传递。如果有必要，它也对信息重新打包，把过长信息分成小包发送，确保到达对方的各段信息正确无误，而在接收端，把这些小包重构成初始的信息。

传输层目的在于它既可以划分在OSI参考模型高层，又可以划分在低层。如果从面向通信和面向信息处理角度进行分类，传输层一般划在低层：如果从用户功能与网络功能角度进行分类，传输层又被划在高层。这种差异正好反映出传输层在OSI参考模型中的特殊地位和作用。

传输层所支持的协议有：TCP/IP的传输控制协议TCP、Novell的顺序包交换SPX以及MicrosoftNetBIOS/NetBEUI等。

五、第5层：会话层

会话层对高层通信进行控制，允许在不同机器上的应用之间建立、使用和结束会话，对进行会话的两台机器间建立对话控制，管理会话如管理哪边发送，何时发送，占用多长时间等。

会话层负责协调两个应用进程进行的通信，以便使应用进程专注于信息交互。从OSI参考模型看，会话层之上各层是面向应用的，会话层之下各层是面向网络通信的。

会话层提供的功能有：为会话实体间建立连接，并组织，同步数据传输。最后通过“有序释放”，“废弃”，“有限量透明用户数据传送”等功能单元来释放会话连接的。[3]

会话层与传输层有明显的区别。传输层负责建立和维护端到端之间的逻辑连接。目的是提供一个可靠的传输服务。但是由于传输层所使用的通信子网类型很多，并且网络通信质量差异很大，这就造成传输协议的复杂性。会话法在发出一个会话协议数据单元时，传输层可以保证将它正确地传送到对等的会话实体，从这点看会话协议得到了简化。

六、第6层：表示层

表示层包含了处理网络应用程序数据格式的协议。它从应用层获得数据，并把它们格式化以供网络通信使用。该层将应用程序数据排序成一个有含义的格式并提供给会话层。这一层也通过提供诸如数据加密的服务来负责安全问题，并压缩数据以使得网络层需要传送的数据尽可能少。

表示层位于OSI参考模型的第6层，在应用层的下面，会话层的上面。它将数据在计算机内部的表示法与网络的表示法之间进行转换，保证所传输的数据经传送后其意义不改变，因此如何描述数据结构并使之与机器无关是表示层要解决的问题。在计算机网络中，互相通信的应用进程需要传输的是信息的语义，它对通信过程中信息的传送语法并不关心。表示层的主要功能是通过一些编码规则定义在通信中传送这些信息所需要的传送语法。

表示层负责决定在主机间交换数据的格式，包括：数据加密、数据压缩传输、字符集转换等。在不同的时间，可以使用不同的传送语法，如使用加密算法、数据压缩算法等。

七、第7层：应用层

应用层是最终用户应用程序访问网络服务的地方，它负责识别并证实通信双方的可用性，进行数据传输完整性控制，使网络应用程序（如电子邮件、P2P文件共享、多用户网络游戏、网络浏览、目录查询等）能够协同工作。[4]

应用层是OSI参考模型的最高层，它为用户的应用进程访问OSI环境提供服务。应用层关心的主要是进程之间的通信行为，因而对应用进程所进行的抽象只保留了应用产程与应用进程间交互行为的有关部分。这种现象实际上是对应用进程某种程度上的简化。

应用层所承处的网络安全功能可粗分为保密、鉴别、反拒认、完整性等。保密足指保护信息不被未授权者访问。鉴别是指在交换信息之前先要确认对方的身份。反拒认功能主要与电子签名有关，比如对拒绝承认所签约的客户必须惟一的确定电子反拒认，以满足法律手续。完整体是指如何确认白己所收到的信息是原始发来的信息，而不是被窜改或伪造的。

八、结语

OSI参考模型将整个网络通信的功能划分为7个层次，由底层到高层分别是物理层、链路层、网络层、传输层、会话层、表示层和应用层。并有选择地给出了各个层次的主要功能，定义与相应的设备等。

【摘要】OSI参考模型（开放式系统互联模）将整个网络通信的功能划分为7个层次。文章对这七个层次做了深入的探讨。

【关键词】物理层；数据链路层；网络层；传输层；会话层

【参考文献】

[1]杨威，王云，刘景宜．网络工程设计与系统集成[M]．人民邮电出版社．

[2]张瑞武．智能建筑的系统集成及其工程实施(上)[M]．清华大学出版社．