今天在china-pub搜书时又见到有这个名词了，于是搜索了一下，了解了大概的意思。
尽管以下文字仅能看懂20%……还是先做个标记吧 ^^
1. ACE目录结构介绍
ACE(ADAPTIVE Communication Environment),中文的意思就是自适配通讯环境，ACE是一个用于开发网络程序的优秀的C++的框架，在国外有很广泛的使用，在国内一些大的开 发通讯产品的公司也有使用。我接触ACE也有一段时间了，虽然时间不长，但我还是感觉到ACE确实是一个好东西，对于丰富自己的知识面有很大的帮助。虽然 我们项目目前是采用C语言来开发，但是当接触ACE后，你会发现"喔，原来程序还可以这样"。例如：我觉得ACE里面Reactor框架就是一个非常的东 西，我们在开发网络程序的时候，常常采用poll来监视各种网络事件，但当采用该框架后，你现在只是需要关系你的业务逻辑，当发生特定的网络事件后，框架 会回调你的业务逻辑。其实按照这个思路，我们完全可以用C来实现类似的功能，当你完成这个后，你会发现你原来用C语言写的过程风格的代码竟然有了OO的味 道。
ACE确实是好东西，但也不是能轻松的就能掌握的，我们还需要一步一步的来蚕食这个大象。
万丈高楼平地起，首先我们还是了解一下ACE的目录结构，从整体上对ACE有一个认识，为今后的进一步学习打下一个基础。
解开ACE的压缩包后，你会发现一个ACE_wrappers目录，这个目录也就是ACE的HOME目录，它下面还包含着一些子目录：
ace：这个目录是ACE中最重要的目录，它包含了ACE的所有源码，但遗憾的是，ACE的所有源文件和头文件全部杂乱的堆在这个目录里，这可能也 是很多开源软件的缺点。其实ACE的代码完全可以按照不同的功能进行不同目录的划分，例如：Reactor框架和thread框架代码完全可以划分开，我 想一个代码组织良好的ACE，将会给大家的学习带来极大的好处，我将在后面的文章里给出ACE代码划分的方法；
ACEXML：这个目录包含了用ACE实现的一个XML解析器；
apps：这个目录包含了用ACE来实现的一些较大的应用程序，例如：JAWS，一个WEB服务器；
ASNMP：基于ACE的SNMP协议实现；
bin：包含里用例方便开发的perl脚本程序，例如：在WIN32上开发DLL时候，需要导出DLL的接口；
docs：ACE的一些帮助文档，其中ACE-subsets.html文档，对我们划分ACE的代码有很大的帮助；
examples：是用ACE来编写的一些例子程序，方便更好的学习和理解ACE；
include：也是ACE中一个比较重要的目录，它包含了在不同的平台上编译时候的编译规则，库的编译规则等；
netsvcs：一些基于ACE的在分布式系统中常用的程序，例如：分布式系统日志系统，网络锁，时间同步等；
TAO：基于ACE的实时CORBA实现，TAO在分布式系统中使用相当广泛，也是一个不可多得的好资源；
tests：用来对ACE进行回归测试，也提供了一个学习ACE的很好的例子代码；
2. ACE和ICE介绍1
自从上世纪九十年代以来，计算工业一直在使用像DCOM 和CORBA这样的面向对象中间件平台。在使分布式计算能为应用开发者所用的进程中，面向对象中间件是十分重要的一步 。开发者第一次拥有了这样的可能：可以构建分布式应用 ――中间件平台会照管大部分网络杂务，比如整编（marshaling ）和解编（unmarshaling）（对数据进行编码与解码，以进行传送）、把逻辑对象地址映射到物理传输端点、根据客户和服务器的原生机器架构改变数据的表示，以及应需自动启动服务器。然而，由于一些原因，无论是 DCOM 还是 CORBA，都未能成功占领大部分计算市场：(1) DCOM 是Microsoft 的独家解决方案，在异种网络中，各种机器会运行多种操作系统，无法使用 COM。(2) DCOM 不能支持大量对象（数十万或数百万），这在很大程度上是它的分布式垃圾收集机制来的开销造成的。(3) 尽管有多家供应商提供 CORBA 产品，几乎不可能找到一家供应商，能够为异种网络中的所有环境提供实现。尽管进行了大量标准化工作，不同的 CORBA 实现之间仍缺乏互操作性，从而不断地造成各种问题；而且，由于供应商常常会自行定义扩展，而CORBA 又缺乏针对多线程环境的规范，对于像C 或C++ 这样的语言，源码兼容性从未完全实现过 .(4) DCOM和 CORBA 都过于复杂。 在异种环境中，让 DCOM 和CORBA 共存从来都不是一件容易的事情：尽管有供应商提供互操作产，这两种平台之间的互操作从来都不是无缝的，而且难以管理，会产生互不相连的技术孤岛。2002 年，Microsoft .NET 平台取代了 DCOM。但尽管.NET 提供了比DCOM 更强大的分布式计算支持，它仍然是 Microsoft 的独家解决方案，因而不是异种环境下的选择。另一方面，CORBA 近年来已停滞不前，许多供应商离开了市场，给消费者留下了不再受到广泛支持的平台；剩下的少数供应商在进一步标准化方面的兴趣也已衰退，致使CORBA 规范中的许多缺陷未能得到解决，或是在它们被报告多年之后才得到解决。在DCOM 和 CORBA 衰败的同时，分布式计算社群对SOAP 和web services产生了浓厚的兴趣。使用无处不在的 WWW 基础设施和HTTP 来开发中间件平台的想法十分迷人――至少在理论上。 SOAP 和web services 曾经允诺要成为Internet 上的分布式计算通用语言。 但尽管引发了很大的公众效应，发表了许多论文，web services 却没有能兑现其允诺：用web services 架构开发的商业系统非常少。其原因是：无论是在网络带宽方面，还是在 CPU 开销方面， SOAP 都会给应用造成严重的性能恶化，以致于该技术无法适用于许多有苛刻性能要求的系统。尽管SOAP 提供了"on-the-wire" 规范，要开发现实的应用，那仍是不够的，因为该规范提供的抽象层次太低。应用可以把各种 SOAP 消息拼凑在一起，但这样做极其繁琐而易错。缺乏更高级的抽象促使供应商提供各种应用开发平台，使遵从 SOAP 的应用开发自动化。但是，除了协议一级，这些开发平台完全没有标准化，不可避免是私有的，所以用一家供应商开发的应用无法与其他供应商的中间件产品一起使用。
关于SOAP 和web services 的架构安全性，有一些严重的担忧。
这些使人不快的选择， ZeroC, Inc. 决定开发Internet Communications Engine ，简称Ice。 Riverace公司（ http://www.riverace.com）采用开放源码商业模式对 ACE进行商业支持。此外，ACE 开发组的许多成员目前正在进行The ACE ORB（ TAO， http://www.cs.wustl.edu/~schmidt/TAO.html）的开发工作。 ACE自适配通信环境（ADAPTIVE Communication Environment ）是可自由使用、开放源码的面向对象（OO）框架（ framework），它实现了许多用于并发通信软件的核心模式。ACE 提供了一组丰富的可重用C++包装外观（ wrapper facade）和框架组件，可跨多种平台完成通用的通信软件任务，其中包括：事件多路分离和事件处理器分派、信号处理、服务初始化、进程间通信、共享内存管理、消息路由、分布式服务动态（重）配置、并发执行和同步，等等。 ACE的目标用户是高性能和实时通信服务和应用的开发者。它简化了使用进程间通信、事件多路分离、显式动态链接和并发的OO 网络应用和服务的开发。此外，通过服务在运行时与应用的动态链接，ACE 使系统的配置和重配置得以自动化。ICE(Internet Communications Engine)是 ZeroC提供的一款高性能的中间件，基于ICE 可以实现电信级的解决方案。前面我们提到过在设计网站架构的时候可以使用ICE实现对网站应用的基础对象操作，将基础对象操作和数据库操作封装在这一层，在业务逻辑层以及表现层 (java,php,.net,python)进行更丰富的表现与操作，从而实现比较好的架构。基于 ICE的数据层可以在未来方便的进行扩展。ICE 支持分布式的部署管理，消息中间件，以及网格计算等等。 Ice和ACE 在性能与开发简便上深化了.CORBA这是一个老牌的分布式中间件平台，并且以其标准实现困难，开发者使用困难而著称。 Ice 采用的许多思想也能在 CORBA 及以前的一些分布式计算平台中找到。在有些方面， Ice 与CORBA 非常接近，而在另外一些方面，它们的差异则意义深远，并且在架构上有着广泛的影响。如果你曾经使用过 CORBA，了解这些差异十分重要。尽管从表面看来， Ice 对象模型与CORBA 对象模型是一样的，但它们在一些重要方面却有所不同。类型系统 Ice 对象和CORBA 对象一样，都只有一个派生层次最深的（most derived） 主接口。但Ice 对象可以提供其他接口作为facets。重要的是要注意到，一个 Ice 对象的所有facets 都具有相同的对象标识，也就是说，客户看到的是具有多个接口的单个对象，而不是看到多个对象、每个对象有不同的接口。facets 提供了极大的架构灵活性。特别地，它们为版本管理问题提供了一种解决途径：你可以简单地给已经存在的对象增加新的facet，轻松地扩展某个服务器的功能，而不会破坏已有的、已经部署的客户。代理语义 Ice 代理（ CORBA 对象引用的等价物） 不是不透明的。 客户只要知道对象的类型和标识，无需其他系统组件的支持，就可以创建出代理（在使用间接绑定时， 不必了解对象的传输地址）。
ACE 的好处包括：
(1) 增强可移植性：在ACE 组件的帮助下，很容易在一种OS平台上编写并发网络应用，然后快速地将它们移植到各种其他的 OS平台上。而且，因为ACE 是开放源码的自由软件，你无需担心被锁定在特定的操作系统平台或编译器上。
(2) 更好的软件质量：ACE的设计使用了许多可提高软件质量的关键模式，这些质量因素包括通信软件灵活性、可扩展性、重用性和模块性。
(3)更高的效率和可预测性： ACE经仔细设计，支持广泛的应用服务质量（ QoS）需求，包括延迟敏感应用的低响应等待时间、高带宽应用的高性能，以及实时应用的可预测性。
(4) 更容易转换到标准的高级中间件：TAO 使用了ACE提供的可重用组件和模式。它是 CORBA的开发源码、遵循标准的实现，并为高性能和实时系统作了优化。为此，ACE 和TAO被设计为能良好地协同工作，以提供全面的中间件解决方案
3. ACE和ICE介绍2
ACE还包含一个高级的网络编程框架，集成并增强了较低层次的 C++包装外观。该框架支持将并发分布式服务动态配置进应用。ACE 的框架部分包含以下组件：
(1) 事件多路分离组件：ACE Reactor(反应器 )和Proactor （前摄器）是可扩展的面向对象多路分离器，它们分派应用专有的处理器，以响应多种类型的基于I/O、定时器、信号和同步的事件。
(2)服务初始化组件： ACE Acceptor（接受器）和 Connector（连接器）组件分别使主动和被动的初始化任务与初始化一旦完成后通信服务所执行的应用专有的任务去耦合。
(3)服务配置组件： ACE Service Configurator（服务配置器）支持应用的配置，这些应用的服务可在安装时和/ 或运行时被动态装配。
(4) 分层的流组件：ACE Stream组件简化了像用户级协议栈这样的由分层服务组成的通信软件应用的开发。
(5)ORB适配器组件：通过 ORB适配器， ACE可以与单线程和多线程CORBA 实现进行无缝集成。
ACE 框架组件便利了通信软件的开发，它们无需修改、重编译、重链接，或频繁地重启运行中的应用，就可被更新和扩展。在ACE中，这样的灵活性是通过结合以下要素来获得的：（ 1） C++语言特性，比如模板、继承和动态绑定，（2 ）设计模式，比如抽象工厂、策略和服务配置器，以及（3） OS机制.
除了OS适配层、 C++包装外观和框架组件，ACE 还提供了包装成自包含组件的标准分布式服务库。尽管这些服务组件并不是ACE框架库的严格组成部分，它们在 ACE中扮演了两种角色：
1. 分解出可重用分布式应用的" 积木"：这些服务组件提供通用的分布式应用任务的可重用实现，比如名字服务、事件路由、日志、时间同步和网络锁定。
2. 演示常用的 ACE组件的用例：这些分布式服务还演示了怎样用像 Reactor、Service Configurator 、Acceptor和 Connector、Active Object ，以及IPC包装这样的 ACE组件来有效地开发灵活、高效和可靠的通信软件。
Ice是一种面向对象的中间件平台。从根本上说，这意味着Ice 为构建面向对象的客户－服务器应用提供了工具、API 和库支持。Ice应适合在异种环境中使用：客户和服务器可以用不同的编程语言编写，可以运行在不同的操作系统和机器架构上，并且可以使用多种网络技术进行通信。无论部署环境如何，这些应用的源码都是可移植的。
ICE的好处包括：
(1)客户无需询问外部的查找服务，比如命名服务，就能够创建代理。实际上，对象标识和对象的名字被认为是同一事物。这样能够消除命名服务的内容与实际情况失去同步所可能带来的问题；同时，为了让客户和服务器正常工作、必须正常运转的系统组件的数目也会减少。
(2) 通过创建所需的初始对象的代理，客户可以轻松地进行自引导（bootstrap）。这样就无需使用单独的引导服务了。
(3)不需要对串化代理进行不同的编码。一种统一的表示就足够了，而这种表示是人可以阅读的。这样就避免了 CORBA 的三种不同的对象引用编码（ IOR、corbaloc ，以及corbaname）所带来的各种复杂问题。开发者多年使用 CORBA 的经验表明，对象引用的不透明性很成问题：它不仅需要更加复杂的API 和运行时支，还会妨碍我们构建现实的系统。为此， CORBA 增加了像 corbaloc 和corbaname 这样的机制，以及用于进行引用比较的is_equivalent 和 hash 操作（这些操作的定义有问题）。所有这些机制都降低了对象引用的不透明性，但CORBA 平台的其他部分仍试图维持引用是不透明的这样一个错觉。结果，开发者在两方面所得的东西都是最糟的：引用既不是完全不透明的，也不是完全透明的―― 这样所带来的混乱和复杂性相当大。对象标识Ice 对象模型假定对象标识在任何地方都是唯一的（但并没有把这个要求强加给应用开发者）。这种对象标识的主要好处是，你可以迁移服务器，也可以把多个不同服务器中的对象合并进 一个服务器，而不用考虑名字冲突的问题：如果每个 Ice 对象都具有唯一的标识，它就不可能与另外的域中的对象的标识发生冲突。Ice 对象模型还使用了强对象标识：使用本地的客户端操作，你就能确定两个代理表示的是否是同一个对象（在CORBA 中，要进行可靠的标识比较，你必须调用远地对象上的操作）。本地标识比较要高效得多，而且对于有些应用领域而言（比如分布式事务服务），这样的比较也至关紧要。
Ice 在架构上提供的好处
(1) 面向对象的语义:Ice "在线路上 "完全保留了 面向对象范型。所有的操作调用都使用迟后绑定，所以操作的实现的选定，是根据对象在运行时的（而不是静态的）实际类型决定的。
(2) 持同步和异步的消息传递:Ice 提供了同步和异步的操作调用和分派，并且通过 IceStorm 提供了发布－订阅消息传递机制。这样，你可以根据你的应用的需要来选择通信模型，而不必把你的应用硬塞进某种模型里。
(3)支持多个接口 :通过facets ，对象可以提供多个不相关的接口，同时又跨越这些接口、保持单一的对象标识。这提供了极大的灵活性，特别是在这样的情况下：应用在发生演化，但又需要与更老的、已经部署的客户保持兼容。
(4)机器无关性: 客户及服务器与底层的机器架构屏蔽开来。对于应用代码而言，像字节序和填充这样的问题都隐藏了起来。
(5) 语言无关性:客户和服务器可以分别部署，所用语言也可以不同（目前支持 C++、 Java，以及PHP （客户端））。 客户和服务器所用的 Slice 定义建立两者之间的接口合约，这样的定义也是它们唯一需要达成一致的东西。
(6)操作系统无关性:Ice API 完全是可移植的，所以同样的源码能够在Windows 和 UNIX上编译和运行。
(7) 线程支持:Ice run time 完全是线程化的，其API 是线程安全的。 作为应用开发者，（除了在访问共享数据时进行同步）你无需为开发线程化的高性能客户和服务器付出额外努力。
(8) 传输机制无关性 :Ice 目前采用了TCP/IP 和UDP 作为传输协议。客户和服务器代码都不需要了解底层的传输机制（你可以通过一个配置参数选择所需的传输机制）。
(9)位置和服务器透明性:Ice run time 会负责定位对象，并管理底层的传输机制，比如打开和关闭连接。客户与服务器之间的交互显得像是无连接的。如果在客户调用操作时，服务器没有运行，你可以通过IcePack 让它们随需启动。服务器可以迁移到不同的物理地址，而不会使客户持有的代理失效，而客户完全不知道对象实现是怎样分布在多个服务器进程上的。
(10) 安全性: 通过SSL 强加密，可以使客户和服务器完全安全地进行通信，这样，应用可以使用不安全的网络安全地进行通信。你可以使用 Glacier穿过防火墙，实现安全的请求转发，并且完全支持回调。
(11)内建的持久机制 :使用Freeze ，创建持久的对象实现变成了一件微不足道的事情。Ice提供了对高性能数据库 Berkeley DB[18] 的内建支持。 Ice 的源码是开放的。尽管要使用Ice 平台，并不一定要阅读源码，通过源码你可以了解各种事情是怎样实现的，或把这些代码移植到新的操作系统上。
总而言之， Ice 和 ACE 提供了一流的分布式计算开发和部署环境，比我们所知道的其他任何平台都更完整。提供适用于异种环境的面向对象中间件平台 ,提供一组完整的特性，支持广泛的领域中的实际的分布式应用的开发, 避免不必要的复杂性，使平台更易于学习和使用。提供一种在网络带宽、内存使用和CPU 开销方面都很高效的实现 ,提供一种具有内建安全性的实现，使它适用于不安全的公共网络。
No comments:
Post a Comment