二、解压缩后放在D盘
    D:\ACE_wrappers

三、在D:\ACE_wrappers\ace目录下新建文件config.h加入一行
    #include "ace/config-win32.h"
   
四、编译：用VC6.0打开D:\ACE_wrappers\ace\ace.dsw
    左侧显示    ACE DLL classes
               ACE LIB classes
    或1、从菜单上选择“编译”，“放置可远行配置”，选择你需要的工程配置
        “编译”，“重建全部”（或任一，如ACE DLL - Win32 MFC Debug）
        此过程可能持续半小时至一个小时不等
    或2、从菜单上选择“编译”，“批构建”，选择你需要的工程配置
        此过程可能持续二至四个钟头
       
    产生的.lib文件位于D:\ACE_wrappers\ace\下，
    产生的.dll文件位于D:\ACE_wrappers\bin\下
   
   
    同样打开ace_static.dsw
    编译
    ACEs.lib
    ACEsd.lib
    ACE_RMCasts.lib
    ACE_RMCastsd.lib
    TMCasts.lib
    TMCastsd.lib

    ACE生成的dll和lib文件的命名规则：（d = debug，s = static）

    debug - aced.lib、debug+static - acesd.lib、release - ace.lib、 release+static - aces.lib


五、样例程序的编译
    用VC打开D:\ACE_wrappers\tests\tests.dsw
    “编译”，“批构建”
   
六、自写程序的工程配置
   
    中篇：ACE程序员教程.pdf中的样例程序：
    网址：http://www.cs.wustl.edu/~schmidt/ACE_wrappers/docs/tutorials/guide-tutorials.html
   
    将网页上的原代码复制到一新建文件，并命名为server.cpp
    用ＶＣ打开，编译，重建全部，弹出对话框，“This build command require ...“，点”是“
   
    会出现以下错误
   
    如果有“Cannot open include file: 'ace/SOCK_Acceptor.h': No such file or directory”
    工程-设置-C/C++: Preprocessor,附加包含路径：D:/ACE_wrappers
   
    如果有“ You must link against multi-threaded libraries when using ACE (check your project settings)”
    工程-设置-C/C++: Code Generation - Use run-time library : Debug Multithreaded Dll
   
    如果有“error C2065: 'ACE_ERROR' : undeclared identifier”
            error C2065: 'ACE_DEBUG' : undeclared identifier
    #include "ace/Log_Msg.h"

    error C4716: 'ace_main_i' : must return a value
        在main中加入
            return 0;
   
    “error LNK2001: unresolved external symbol "__declspec(dllimport) int __cdecl”
    工程-设置-Link-Input: 对象/库模块：添加aced.lib                         附加库路径：D:\ACE_wrappers\ace
                       
   
                       
    编译client中遇到的问题
    1、error C2039: 'sprintf' : is not a member of 'ACE_OS'
       
        #include "ace/OS_NS_stdio.h"
       
    2、error C2039: 'strlen' : is not a member of 'ACE_OS'
   
        #include "ace/OS_NS_string.h"
    3、error C2059: syntax error : '?'
        错误在这一句：  ACE_DEBUG((LM_DEBUG,?Usage egX <hostname> <port_number>\n?));
        将?改为"
       
    4、无法找到动态链接库aced.dll于指定的路径
        为系统变量PATH加上D:\ACE_wrappers\bin
            
    静态包含：
       工程-设置-C/C++-预处理程序定义中加入 ,ACE_AS_STATIC_LIBS
      
      
例１server编译后生成
    server.exe 16K  serverd.exe 97K     servers.exe 124K serversd.exe 669K
    （servers.exe较适合发布）
   
例2 client编译后生成
    client.exe 16K  clientd.exe 97K     clients.exe 124K clientsd.exe 669K
   （clients.exe较适合发布）
   
    测试 clients 127.0.0.1 1919
        servers 1919


下面是马维达老师写的：(转自huihoo)

发表于： 3/31/2003 - 04:24

翻译的一点小东西，希望能对大家有帮助。 其实也不敢称为是翻译的，水平太烂了，大家将就着看吧 ：） 使用Microsoft Visual C++ 在win32平台上生成和安装ACE： 注意：关于MSVC5.0和Service Pack 3的使用有一些问题，过去一些用户在sp2中使用良好的代码在sp3种却会引发一些问题。感谢Bill 的细心查找，这一神秘的问题被解决了。答案？（哦，这儿有一个好答案。。。）这可能是因为有多个版本的sp3较早版本的sp3有一些bug，而后来的版本修正了这些错误，从微软网站上下载的1998年6月16日版本的sp3是一个良好的版本。如果X03-50158是那些拥有sp3的光盘序列号的一部分，那么这些版本也是良好的。但是不管任何版本的sp3，其STL的实现都有错误，详细情况请浏览http://www.dinkumware.com/vc_fixes.html。感谢Ben Eng对这些错误的修正。 现在的SP4(希望只有一个版本)已经修正了STL中的死锁问题。 我们现在将不再积极的支持MSVC 4.X以及以前的版本，ACE可和这些编译器一起工作但是可能会丢失一些好处。 1. 将ACE分发包界压缩到一个目录中，这将在那个目录中生成一个包含ACE的目录ACE_wrappers。接下来的步骤中假设ACE分发包被解压缩到ACE_ROOT=C:\ACE_wrappers中，因此ACE将会存在于ACE_ROOT\ace目录中。 2. 在ACE_ROOT\ace目录中创建一个文件，命名为config.h，其内容为： #include "ace/config-win32.h" 3. 在VC++中加载ACE的工程文件（ACE_ROOT\ace\ace.dsw） 4. 每个工程都会包含多个配置，这些配置是Debug/Release, MFC/Non-MFCh和Static/Dynamic库版本等选项的混合。确定你所需要的构造(例如，调试代码需要ACE的调试版本)。所有这些不同的配置可以为你提供一些便利，你可以或者采用不同的模式以构造不同配置的应用，或者通过改变ace\config.h来改变在NT上的不同配置。 注意：如果你使用动态连接，请保证ACE_ROOT\bin被添加到你的path环境变量中，否则你将在运行程序的时候碰到寻找ace.dll或者aced.dll的问题。 5. 如果你在Windows NT或者Windows 2k上构建ACE，你可以马上开始构造她而不需任何改变，如果你在Windows 9x/me上构建，那么你必须在 ACE_ROOT\ace\config.h.的#include块之前添加一行： #define ACE_HAS_WINNT4 0 这将在ACE中移掉一些WinNT/Win2K中特有的代码。 6. 如果你希望使用MSVC自带的标准C++头文件（C++ Standard Draft 2种定义的iostream,cstdio…..）,则应该在 ACE_ROOT\ace\config.h.的#include块之前添加一行： #define ACE_HAS_STANDARD_CPP_LIBRARY 1 7. 如果需要和MFC一起使用，增加如下定义到你的config.h文件中，注意，如果你想使用spawn一个新的线程，则必须保证使用THR_USE_AFX标志来spawn线程。 #define ACE_HAS_MFC 1 缺省的，ACE工程使用MSVC运行时的动态DLL版本，你也可以选择使用ACE的不关心运行时库的静态（LIB）版本。我们选择仅与动态运行时库连接的原因在于基本上所有的NT机器上都会安装这些库，而我们则可以因此而减小代码的大小。如果你希望ACE与MFC的静态版本连接，则可以在config.h中定义ACE_USES_STATIC_MFC。然而，如果你希望静态的连接所有的库（包括MSVC运行时库），就需要自己修改工程文件了。 8. 如果要构建ACE的静态版本，则需要在config.h中定义ACE_AS_STATIC_LIBS，此宏在那些希望使用ACE的静态版本的应用工程中也必须定义。 作为一个可选项，你可以在 #include statement in ACE_ROOT\ace\config.h.之前添加一行： #define ACE_NO_INLINE 来取消函数内联从而减小静态库（和你的运行码）的大小。 9. ACE DLL和LIB库的命名规则： 我们使用如下的规则明明使用MSVC的ACE的DLL和LIB文件。 "Library/DLL name" + (是静态库吗 ? "s" : "") + (包含调试信息 ? "d" : "") + {".dll"|".lib"} 在MSVC环境中使用ACE的更多信息可以在这里找到。

-----------------------------------------------------------------------
一、安装TAO，需要先编译并安装ACE。

二、ACE的编译和安装步骤见http://www.cs.wustl.edu/~schmidt/ACE_wrappers/ACE-INSTALL.html。TAO的编译和安装步骤见http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/TAO-INSTALL.html。如果你英文程度还可以的话，最好直接阅读这两篇文档。说到底，中文文档只是“权宜之计”；汉语并不太适合进行逻辑性的表述。

但我还是把其中的一些段落编译如下（VC 6.0 + ACE-5.2.1 + TAO-1.2.1）：

ACE的编译与安装

一般规则

ACE中的许多特性可以通过在$ACE_ROOT/ace/config.h中定义一些宏来进行修改。这些宏应该总是在包括针对你的平台的配置文件之前出现。

但是，如果你想要取消/重定义在针对特定平台的配置文件中定义的宏，#undef应该在配置文件之后出现。

如果你计划在多种平台上编译ACE，你也许需要考虑克隆源码树。

步骤：

1. 将ACE发布文件解压缩到某个目录中，在其中将会创建含有所有文件的ACE_wrappers目录。在下面的步骤中，ACE_wrappers目录将以ACE_ROOT为名来指称。

2. 在ACE_ROOT\ace目录中创建一个名为config.h的文件，在其中包含：

#include “ace/config-win32.h”

3. 现在加载ACE的项目文件（ACE_ROOT\ace\ace.dsw）。

4. 其中的每个项目都含有若干不同的配置（可混合Debug/Release、MFC/Non-MFC、Static/Dynamic library版本）。你可以从中选择你所需的配置，或是使用ace/config.h来进行调整。
注意：如果你使用动态链接库，在运行使用ACE的程序时，确定你在PATH中包括了ACE_ROOT\bin。

5. 如果你的系统平台是WinNT或2000，那么无需任何改动你就可以开始编译了。如果是Windows 9x/Me，你需要在ACE_ROOT\ace\config.h中的#include语句之前增加：

#define ACE_HAS_WINNT4 0

6. 如果你想要使用MSVC标准C++头（iostream、cstdio……），在ACE_ROOT\ace\config.h中的#include语句之前增加：

#define ACE_HAS_STANDARD_CPP_LIBRARY 1

7. 要与MFC一起使用ACE，再增加下面的定义：

#define ACE_HAS_MFC 1

注意如果你想要通过CWinThread派生新线程，一定要设置THR_USE_AFX。在缺省情况下，所有的ACE项目都使用DLL版本的MSVC运行时库。尽管如此，你仍然可以选择使用static（LIB）版本的ACE库。如果你想要将MFC作为静态库链接进ACE，你可以在config.h文件中定义ACE_USES_STATIC_MFC。但如果你想要静态链接所有的东西（包括MSVC运行时库），你就需要自己修改ACE的项目文件。

8. ACE的静态版本是通过定义ACE_AS_STATIC_LIBS来编译的。在链接静态ACE库的应用项目中也应该使用这个宏。
你也可以在config.h文件中增加

#define ACE_NO_INLINE

来取消函数内联并减小静态库（和你的可执行程序）的大小。

9. ACE DLL和LIB的命名方案：

"Library/DLL名" + (是否为静态库 ? "s" : "") + (是否启用了Debugging ? "d" : "") + {".dll"|".lib"}

10. 配置完毕后编译即可。选择dll版本，编译生成的dll文件在ACE_ROOT\bin中，相应的lib文件在ACE_ROOT\ace中。

ACE测试

各测试程序在ACE_ROOT\tests中。在其中也有一个工作空间文件可用来编译所有的测试程序（tests.dsw）。
一旦你编译了所有测试程序（可使用批编译），你可以运行tests目录中的perl脚本run_test.pl或批处理文件run_tests.bat来进行所有测试。

TAO的编译与安装

确定VC的CL.EXE在你的访问路径上。设置ACE_ROOT或TAO_ROOT环境变量。例如：

set ACE_ROOT=C:\ACE_wrappers

TAO最好放置在ACE_wrappers（这也是缺省情况）。

1.确定ACE已经编译和安装。

2.确定ACE_wrappers\bin已在“Tools|Options”中的“Executable Directories”中列出。如果在MSVC下使用TAO_IDL编译器就需要进行此设置。

3.加载tao\TAO.dsw，并编译TAO库。

4.要编译Cubit测试，加载performance-tests\Cubit\TAO\IDL_Cubit\IDL_Cubit.dsw，并编译客户和服务器。

TAOACE.dsw

TAOACE.dsw是一个Visual C++ 5.0/6.0工作空间文件，它加载的项目包括ACE、TAO、TAO_IDL（编译器）、gperf、orb服务库，以及一些单独的可执行程序（比如Naming Service，等等）。它可以用于编译所有的用于编译/运行TAO应用的文件。

三、我选择编译的是dll版本（Release），并在ACE的config.h文件中定义了“#define ACE_HAS_STANDARD_CPP_LIBRARY 1”。编译后我所得到的ace.dll的大小是1.13MB，相应的ace.lib的大小是1.77MB；TAO.dll的大小是1.47MB，相应的TAO.lib的大小是2.74MB。所有文件约有 MB，包括源程序、编译生成的中间文件，等等，但有些例子及服务我没有编译。

祝学有所成！

马维达

-------------------------------------
将ACE与VC6集成在一起

一.打开 Tools>Options>Directories
加入以下内容:
Executable File:
C:\ACE_wrappers\bin

Include File:
C:\ACE_wrappers\
C:\ACE_wrappers\TAO
C:\ACE_wrappers\TAO\orbsvcs

Library Files:
C:\ACE_wrappers\ace
C:\ACE_wrappers\TAO\tao
C:\ACE_wrappers\TAO\orbsvcs\orbsvcs

Source Files:
C:\ACE_wrappers\ace
C:\ACE_wrappers\TAO\tao
C:\ACE_wrappers\TAO\orbsvcs\orbsvcs

二.加入 C:\ACE_wrappers\bin 到系统环境变量 path中

三.设置系统变量
ACE_ROOT=C:\ACE_wrappers
TAO_ROOT=C:\ACE_wrappers\TAO

设计不受传统网络限制的 P2P 系统

作者： chris∣来源：Matrix∣原文地址∣2003-6-11

随着移动计算的普及和嵌入式可联网微处理器的无处不在的应用，TCP/IP 终于显露出它已经显得过时。设计 Jxta 的初衷就是要突破当今基于 TCP/IP 的网络的限制，从而扩展因特网所能触及的范围。在 developerWorks 的讨论 Jxta 的系列的这最后一篇文章中，Sing Li 举例说明了体现这种扩展的系统，并解决了一个实际问题。您将看到 Jxta 不受客户机／服务器网络的典型约束的限制。请单击本文顶部或底部的讨论，在讨论论坛与作者及其他读者共享关于本文的心得。

到本系列文章的 这里为止，我们仔细考察了 Jxta，一个 Java 参考实现的新 P2P 平台，是如何工作的。在第一部分中，我们了解了 Jxta 的互操作特征。Jxta 被定义为一组互操作协议，可以跨硬件平台、操作系统和编程语言实现。我们也讨论了 Jxta 的操作模型和包括对等机、对等组、服务和管道在内的许多重要概念。在第二部分中，我们的着眼点是建立和运行 Jxta。我们探讨了一个 Jxta 应用程序 — Jxta shell — 并经历了创建管道并从一个对等机发送消息到另一个对等机的情形。在我们编写 Jxta shell 扩展时，我们第一次获得了用 Jxta API 编程的经验。迄今为止，我们讨论 Jxta 的方式都是从下到上的。对于像我们这样具有系统编程和网络工程背景的人来说，这是再自然不过的。

在本系列的这第三篇也即最后一篇文章中，我们要把事情颠倒过来。从那些从事应用级设计和体系结构的人的角度来说，本文是自上而下看待 Jxta 的。我们从一个特定的示例问题开始，对这个问题进行分析并设计出一个解决方案，从而展示 Jxta 是如何自然地解决该问题的。

随着本文的进行，我们讨论 Jxta 如何通过并列（juxtaposition）改变联网的前景展望，我们还提供一个 Jxta 服务和客户机的设计和代码。

解决一个分布式数据收集问题
设 想一下我们需要创建一个大规模的气象数据收集和分析系统。在这个系统中，我们有数百个气象数据收集点；每个收集点配备一个微型气象站，这些气象站将当前温 度（和其它大气状态）提供给一组数据集中器。收集器遍布世界各地；这些收集器并不是都直接连接到因特网，任何时候都可能有新的数据收集器连接上来或脱开连 接。在这个项目中，参与进来的收集器的确切数量经常在变化；数据分析和处理基于区域平均值。

开始时只有 10 个集中器。每个集中器监视来自许多个收集器的数据，这些数据被实时提供给关系数据库。随后，来自关系数据库的数据被提供给运行气象分析和预测的仿真模型的 超级计算机并由它处理。集中器的数量和位置会发生变化，但它们的行为则大多更稳定。一旦安装后，集中器就会保持运转，除非碰到系统失效。

我们必须解决的问题：我们的系统如何能够持续运转，并能考虑到在几乎不影响整体性能的条件下，允许动态添加或除去收集器和集中器。

初始分析：特定网络的复杂性
系 统中的某些收集器可直接访问因特网；其它的通过无线电传输技术进行连接，它们处在恶劣的外部环境中。事实上，在这些基于无线电的收集器中，许多都被设计成 了节能的，以延长电池寿命；收集器的有效范围仅够与下一个最近的收集器或基站联系。这些收集器中许多都不支持 TCP/IP，而是使用基本的分组无线技术。一些更独立的收集器仅仅靠其太阳能电池板获得能量，并使用卫星传输进行通信。还有另外一些收集器则连接到标准 蜂窝电话上，用 SMS（short message service，短消息服务）消息传递来发送消息。

在项目的整个生命周期中， 可用的收集器的数量会发生变化；在项目开始时，我们无法预测将会构建到未来收集器中的连接类型，也无法预测收集器将使用的技术。例如，在项目的某个阶段， 在一个超级计算机群集内使用软件仿真来仿真数量巨大的收集器。我们的解决方案必须能适应所有收集器，不管是真正的还是仿真的，现在的还是将来的。

解决方案：并列（Juxtaposition）
图 1 显示用来解决这个问题的高层次设计。

图 1. 解决数据收集问题

请 注意，并列 P2P 网络用来适应网络的多种不同情况，而集中器提供 P2P 网络和传统的客户机／服务器网络之间的连接，数据库服务器和超级计算机驻留在客户机／服务器网络。集中器充当两个网络之间的网桥 — 每个集中器在 P2P 网络上具有动态特性，在客户机／服务器网络具有静态特性。

这个体系结构反映了 Jxta 对传统系统的补充作用和提供并行于这些传统系统的增值的能力 — 通过并列（juxtaposition），Jxta 的名称就源于这个词语。

我们不想深入讨论这里的客户机／服务器网络的细节，因为其中并没有什么独特之处；我们甚至可以使用 VPN 技术在因特网上运行它。有趣的部分在 P2P 网络。图 2 显示了它的组成，它可随将来的变化而变化。请注意其中用到的多种不同技术。

图 2. 数据收集器网络的组成


在实现这个 P2P 网络时，我们可以利用 Jxta，从而获得以下优点：

容易地添加或除去新的收集器或集中器，这得益于 Jxta 的统一分散寻址


设计简单性，这得益于 Jxta 的网络虚拟化


持续运转，这得益于 Jxta 支持故障弹性


免维护运转，这得益于 Jxta 支持动态自我组织网络


支持跨越许多硬件平台和编程语言的多种不同实现，支持所用的各种不同通信协议
让我们来更详细地研究一下其中几个益处，并看看 Jxta 如何为体系结构的各个方面作出独特的贡献。

统一分散寻址
统一分散寻址的字面意思是，对等机可以为自己生成一个 ID 并立即加入到网络，而不必与任何注册人或中央认证机构联系，而当今的 DNS 则必须这样。这一特征使我们任何时候都可以向网络添加收集器和集中器。

在 本文附带的代码包中（您可以从参考资料下载它），我们提供了名为 mdidgen 的实用程序，它可以用来为新的 Jxta 服务和管道生成地址。（要更多了解 mdidgen，请参阅旁注 mdidgen 实用程序。）您可以阅读本系列的第一篇文章，了解 Jxta ID 是如何用来对 Jxta 对象（例如：对等机、对等组、服务和管道）进行统一寻址的。

请注意，Jxta 网络中的对等机不一定要有一个独立的物理存在。在我们的示例中，我们用一个超级计算机群集来仿真数量巨大的收集器，每个收集器有它自己的统一地址。这些仿 真收集器的每一个在 P2P 网络的其它部分看来都是一个与那些具有物理存在的对等机没有什么差别的对等机。

网络虚拟化
通过分散寻址为所有收集器和集中器赋予网络中唯一的标识后，它们立即就成为网络中的对等机并开始彼此通信。尽管它们可能通过许多种不同的消息传递机制进行相互联系，但在 Jxta 级别上，它们都只是一个虚拟网状网络中的节点，如图 3 所示。

图 3. 网络虚拟化


请 注意，将收集器和对等机实际相互连接起来的所有不同的传输和寻址模式都被虚拟化了，只留下一个网状网络，其中的每个对等机都与其它每一个对等机相连接。 Jxta 通过使用统一寻址模式和极迟绑定（very late binding），在多个端点协议上添加一个智能消息路由层做到这一点。从本质上说，每一个端点协议或传输协议栈都成为虚拟 Jxta 网络的一个驱动程序，将虚拟网络映射到物理网络上。图 4 显示了这种设置。

图 4. 端点协议作为驱动程序


通 信协议要成为合格的端点协议，只需要它能够在两个物理节点之间发送或接收 XML 消息。对传输可靠性或消息广播支持没有什么要求。因而，最简单的分组无线协议也可以用作端点协议驱动程序，与像 TCP/IP 这样的复杂多层协议并列。这也解释了为什么 HTTP 和 TCP/IP 在 Jxta 协议栈内都是同一级别的端点协议，尽管它们的物理级别非常不同。HTTP 是一个受支持的端点协议，因为只要有必要，它就能够穿越尽可能多的防火墙，从而获取从一个 Jxta 对等机传送到另一个的消息。

Jxta 网络中的每个对等机可以同时支持多个端点协议，Jxta 虚拟网络机制会以一种尽可能迟的方式将虚拟化的统一网络地址映射到物理网络地址（在 Jxta 中称为网络端点）。从本质上说，一个对等机对应于一组物理端点，其中的每个物理端点可以在完全不同的物理通信协议上实现。较高级别的虚拟化和路由服务隐藏 了这一点。许多人或许能看出这就是多协议路由器的一个非常高级的形式 — 正是这相同的设备使当今的因特网成为现实。这一概念的发展将把我们带向一个更加普遍的因特网，这是再自然不过的了。

让我们更详细地研究一下图 5 所示的示例。对等机 A 是网络中的一个收集器，它试图通过一系列中介收集器（对等机 B、C 和 D）将其数据发送到集中器（对等机 E）。在图中每个对等机的下面是该对等机所支持的一组协议。

图 5. Jxta 路由示例


因为对等机 A 不直接连接到对等机 E，所以它的消息必须通过中介对等机 B、C 和 D 进行路由。Jxta 将自动对消息进行路由：

使用 TCP/IP 从对等机 A 到对等机 B


使用分组无线协议从对等机 B 到对等机 C


使用 SMS 从对等机 C 到对等机 D


使用 HTTP 从对等机 D 到对等机 E
对 等机 E 将在它创建的管道上接收来自对等机 A 的消息，完全未觉察 Jxta 为它所执行的复杂工作。请注意，对等机 C 到对等机 D 的路径是非对称的；Jxta 就是专门设计来处理这种状况的。如果有条消息要从对等机 E 发送回对等机 A，则 Jxta 将使用拨号调制解调器 PPP 自动地从对等机 D 路由到对等机 C。

故障弹性
尽管上面所描述的路由功能已经令人非常惊奇，但更为重要的是， Jxta 必须能够适合 P2P 网络不断变化的拓扑结构。特别是它必须能够处理充当消息路由代理的 P2P 对等机与生俱来的不可靠性。在我们的例子中，如果中继收集器不可用，那么，依赖另一个收集器来路由它的消息的收集器将不能进行通信。

当 有对等机加入或离开网络时，Jxta 要能够实时对消息进行重路由。再考虑一下图 5 中的路由示例。请设想一下，由于某些原因，就在对等机 A 已经发送出消息（现在正在传输）而尚未到达对等机 C 时，对等机 C 和对等机 D 之间的卫星链路却断了。Jxta 必须能够动态地通过某些替代路径（可能是通过另一组中间节点）将该消息重路由到对等机 E。这种动态重路由是基于最大努力（best-effort）完成的；偶而有这样的情况，如果没有可能的路由（除非中介传输支持持久队列），则消息可能会 被丢失。由于这种重路由能够改换实际用来到达对等机 E 的端点协议（例如：从 HTTP 到 TCP/IP），所以，要一直达到路由的最后一个跳数时，对等机到物理端点的绑定才会发生。这就是 Jxta 的极迟绑定的本质。

在对等组级别上（请参阅本系列的第一篇文章了解有关对等组的更多知识），Jxta 通过支持对等组服务 — 在对等组内总是可用的、冗余地实现的服务 — 支持故障弹性。

动态自我组织网络
当具有统一虚拟网络 ID 的对等机插入到 Jxta 网络中时，它必须这样来自我引导：

定位本地对等机并发现它们的功能


发现可用的对等组并加入其中一个


发现对等组中可用的服务并开始使用它们
我 们从本系列的第二篇文章中了解到，这一切都是在消息级别上通过发布、中继、中介高速缓存和搜索称为广告的不同类型的消息完成的。Jxta 的 Java 参考实现有一个解析器和使发布-高速缓存-搜索（publish-cache-search）过程简便的集中服务层。

Jxta 中的对等组的作用是作为网络分区（network-partitioning）机制，确保广告只被中继到能够使用这些广告的组成员。不同的对等组可以包含对等机和对等组服务的不同组合，充当功能性的捆束机制。对等组也可以起到特定应用程序的认证域的作用。

mdidgen 实用程序


实 用类 com.ibm.jxta.mdidgen 可以用来以分散方式为 Jxta 对象生成统一地址。它生成一个新的 ModuleClassID、一个相应的 ModuleSpecID 和一个与某个组（在启动时被读取的配置文件中指定）关联的新 PipeID。所生成的这些 ID 是立即可以使用的 Java 声明形式，并且立即可以插入到您的代码中。这就是我们为 ModuleSpecAdvertisement 和集中器服务管道生成 ID 的方式。

设计 Jxta 服务和 Jxta 客户机
让我们回到气象站示例上来。从概念上说，集中器实现必须：

读取并处理适当的配置文件，这个文件告诉集中器加入到哪个 Jxta 组。（样本代码包中包含有我们示例的配置文件。）


启动 Jxta。


加入到配置文件所指定的组。


进行搜索，以判断集中器服务的服务广告是否存在；如果不存在，就创建一个并发布它。


创建一条相应于该服务的输入管道。


在管道等待来自收集器的消息。


一旦消息到达，就处理它并存储到 RDBMS 中。


回到第 6 步。
这个逻辑在 com.ibm.jxta.Concentrator 类中实现。您可以从参考资料部分下载这个类及所有来自本文的代码。

收集器实现必须：

读取并处理上述配置文件。


启动 Jxta。


加入到配置文件所指定的组。


发现集中器服务的服务广告；如果服务广告不可用，我们就无法继续。


从服务广告抽取管道信息。


每隔一段时间收集数据。


创建包含收集器位置和数据的消息。


通过管道将消息发送到集中器服务。


回到第 6 步。
上述逻辑在 com.ibm.jxta.Collector 类中实现。

将公共任务分解到 DwJxtaPeer 超类
有很多任务对收集器和集中器角色都是公共的。为了消除不必要的代码重复并使将来的维护更简单，让我们把这些公共任务分解出来放入名为 com.ibm.jxta.DWJxtaPeer 的超类。

其中一个公共任务是执行 ModuleSpecAdvertisement 的发现（请参阅旁注 JXTA 中的服务广告了解关于这个广告的更多知识）。这由清单 1 中的 findModuleSpecAdv() 方法执行：

清单 1. findModuleSpecAdv()
protected ModuleSpecAdvertisement findModuleSpecAdv() {
return (ModuleSpecAdvertisement) findAdv("ModuleSpecAdvertisement",
"Name",ModuleSpecName, new ModuleSpecAdvValidator(), false );
}



请注意，findModuleSpecAdv() 调用另一个名为 findAdv() 的通用方法，我们用这个方法发现广告。findAdv() 的参数是：

参数 描述
AdvType 广告类型的字符串描述 — 例如，PipeAdvertisement。
Attr 搜索广告时要匹配的标记 — 例如，Name。
Value 与所指定的属性匹配的值。
Validator 一个实现 FindValidate 接口的对象。这个接口有一个方法 checkAdv()，当找到一条广告时，这个方法就被用来立即对这条广告进行验证。
LocalOnly 一个布尔标志，表明该发现是否只应在本地执行，还是跨网络在远程执行。

如清单 2 所示，该方法的第一部分通过使用组的发现服务的 getLocalAdvertisement() 方法，仅根据本地广告高速缓存执行对广告的发现。请注意对 validator.checkAdv() 调用，用来对所找到的任何广告进行验证。

清单 2. findAdv()，第 1 部分
protected Advertisement findAdv(String advType, String attr, String val,
FindValidate validator, boolean localOnly) {
Enumeration enum = null;
System.out.println("Looking for " + advType + ", please wait...");
// First look in the local storage
try {
enum = discovery.getLocalAdvertisements(DiscoveryService.ADV,
attr, val);

} catch (Exception e) {
}



if ((enum != null) && (enum.hasMoreElements())) {
Advertisement adv = null;
while (enum.hasMoreElements()) {
try {
adv = (Advertisement) enum.nextElement();
if( validator.checkAdv(adv))
return adv;
} catch(Exception e) {
continue;
}
} // while
} // if



如果该发现是本地的，则逻辑就在这里停止。否则，我们就发送一条查询到网络，执行远程发现。发现服务将把所找到的任何广告都存储到本地高速缓存。我们只要给点时间就可以让远程发现发生。在清单 3 中，循环大约持续了五秒钟：

清单 3. findAdv()，第 2 部分
if (localOnly)
return null;

System.out.println(" cannot find it locally, trying remote");
// Now, search remote
discovery.getRemoteAdvertisements(null, DiscoveryService.ADV,
attr, val, 2, null);

// Wait a bit in order to get an answer.
int i=0;
while (true) {
try {
if (i>MAXRETRIES){
System.out.print(".");
break;
}
Thread.sleep(WaitingTime);
i++;
} catch (Exception e) {
}
System.out.println("");



此时，已发现的任何广告都应可在本地高速缓存中找到。在清单 4 中，我们再次执行一个本地检查。

清单 4. findadv()，第 3 部分
// Look in the local storage again
try {
enum = discovery.getLocalAdvertisements(DiscoveryService.ADV,
attr, val);

if ((enum != null) && (enum.hasMoreElements())) {
Advertisement adv = null;

while (enum.hasMoreElements()) {
try {
adv = (Advertisement) enum.nextElement();
if( validator.checkAdv(adv))
return adv;
} catch(Exception e) {
continue;
}
} // while
}
} catch (Exception e) {
}
}
return null;
}



超类中的另两个公共方法的描述在下表中；您可以作为练习完成对它们的分析。

方法 描述
PublishModuleSpecAdv() 如果发现过程没有为服务找到现有的 ModuleSpecAdvertsiement，则这个方法被集中器调用。这个方法将创建一个服务（根据我们所生成的、固定的服务 ID）。这条广告将在本地和远程发布。仅在集中器第一次启动时，当配置改变时，或者在本地高速缓存被清除后，才有创建广告的必要。
JoinGroupIfExists() 这个方法为收集器和集中器所调用；它尝试加入到一个已命名的子组（subgroup），这个子组是全局 NetPeerGroup（缺省情况下大家都在这个组）的子（child）组。

请看一下清单 5，它是 DwJxtaPeer 类的常数声明部分的一部分：

清单 5. 模块 ID 定义
public static final String ClassID =
"urn:jxta:uuid-EE99266A1DE84E3DB34D9CC842EC889105";
public static final String SpecID =
"urn:jxta:uuid-EE99266A1DE84E3DB34D9CC842EC8891B9EB13ECA6FE44DDA112B5F5E357763006";


Jxta 中的服务广告


服务广告概念分解成一组相互联系的广告（共三条）：
ModuleClassAdvertiseent
ModuleSpecAdvertisement
MdouleImplAdvertisement

为了减小在系统中循环的广告的大小，也为了将服务的通用类（例如：银行）、该类的特定规范（例如：存款和提款 API）和该服务（例如：API 基于 Java 的实现）的实现之间的关系规格化，这样做都是必要的。

应用程序或 Jxta 服务不必使用所有这些广告，只要使用它所需要的就行了。在我们的系统中，我们只需要ModuleSpecAdvertisement，我们用它将服务连到管道上，并使这条广告是远程可发现的。

ModuleClassID 和 ModuleSpecID 用 mdidgen 实用程序生成并以硬编码方式置于模块中；它们与一个集中器服务的 ID 相对应。所有的集中器都知道这个服务的 ID，而且这个 ID 一旦生成就一直保持不变，所以组中的收集器肯定能够找到这个集中器服务。因为生成 ModuleSpecID 时需要 ModuleClassID，所以这里有 ModuleClassID。为了轻松生成这些 ID，我们使用一个名为 AdvCooker 的库，它是 W.R. Bauer（vasha@jxta.org）创建的名为 jxta-wire 的 Jxta 项目的一部分。

网络中运行的所有集中器实例将对同一个集中器对等组服务（通过使用相同的 ModuleSpecID 和侦听广播管道的同一个逻辑实例）作出应答。这种冗余实现将确保集中器服务在对等组中始终可用。

集中器：一个 Jxta 对等组服务
我们来看一下 com.ibm.jxta.Concentrator 实现。我们已经提到过，它继承（扩展）自 DwJxtaPeer 类。这里是逐个方法地对 Concentrator 进行的描述：

方法 描述
init() 它应该是该类被调用的第一个方法。这个方法调用私有 jxtaInit() 方法，然后创建输入集中器服务管道的一个实例。
process() 这个方法进入一个无限循环。它在输入集中器服务管道上侦听传入的收集器数据提交。对每一个提交，它都调用 processData() 对数据进行处理。
findPipeAdv() 这个方法对服务管道广告执行本地发现（也就是说，它检查本地高速缓存）。
jxtaInit() 这个方法首先读取配置文件并设定我们想要加入到的组。接着，它启动 Jxta 和 NetPeerGroup 网络，然后调用超类的 joinGroupIfExist() 加入到指定的组。接着，如果能够，它就从本地高速缓存检索服务管道广告；否则，它将创建一个新的服务管道广告（通过使用 createInputPipeAdvIfNotExist()）。最后，它执行发现，看看是否可以找到 ModuleSpecAdvertisement；如果不能找到，它就创建一个并发布它。
processData() 这个方法是占位符。在实际的项目中，它将使用后端客户机／服务器网络将所收集到的数据提交给 RDBMS（可能使用 JDBC）。
createInputPipeAdvIfNotExist() 这个助手方法首先检查高速缓存，看看服务管道广告是否可用。如果不可用，它将创建该广告并将它存储到高速缓存中。在任一种情况下都返回正确的广告。

静态类型定义如下：


public static String servicePipeID =
"urn:jxta:uuid-969610EE8945417CA56F9771197EE3965207E4C303154E7EB5878751AE22761804";




这 是由 mdidgen 实用程序生成的管道 ID。它是该服务管道的统一地址，被所有集中器使用。它是一条广播管道，因而侦听消息的所有集中器都应接收到那些来自收集器的消息。收集器从作为 ModuleSpecAdvertisement 的一部分的管道广告中获得这个管道 ID；收集器通过发现过程找到该广告。

收集器：编写 Jxta 客户机逻辑的代码
最后，我们来看一下 com.ibm.jxta.Collector 类的本地方法。

方法 描述
init() 它应该是从这个类中调用的第一个方法。这个方法调用私有 jxtaInit()，然后创建用来将所收集到的数据发送到集中器服务的输出管道。
process() 这个方法有一个无限循环，这个循环首先调用 collectData() 获得测量的数据，接着，创建一条 Jxta 消息并沿集中器服务管道将它发送到正在等待的集中器。循环内每次采样都延迟一段固定时间。
jxtaInit() 这个方法首先读取配置文件并对我们想要加入到的组进行设置，接着确定收集器的位置。接着，它启动 Jxta 和 NetPeerGroup 网络，然后调用超类的 joinGroupIfExist() 加入到指定的组。接着，它执行发现，看看是否可以找到相应于众所周知的集中器服务的 ModuleSpecAdvertisement；如果找不到，则退出。一旦找到了 ModuleSpecAdvertisment，它就将抽取集中器服务管道广告并为输出管道的创建做好准备。
collectData() 这个方法是一个占位符，用于实际的数据收集。在实际的项目中，这个方法将访问各种数据输入通道（可能使用输入／输出端口或本机代码）并将所收集到的数据返回给调用者。

实际运转 Jxta：在您自己的机器上测试这个动态网络
本文附带的源代码包中有一个便于您实验的目录结构。下面的目录在 code 子目录下：

目录 描述
lib 来自 Jxta 核心最新稳定版的所有 jar 文件，用于 Jxta shell 的所有 jar 文件以及来自 jxta-wire 项目的 jxta-wire.jar 文件都放在这里。（请参阅参考资料了解关于 Jxta shell 和 jxta-wire 的更多信息。）
src 包含我们系统的源代码。
classes 包含我们系统的编译好的类文件。
shell1 第一个实验目录。我们将在这个目录创建一个带有一个集中器的 shell。我们还将在这里充分考查 mdidgen 实用程序。
shell2 设置为网络中的第二个对等机。这将运行另一个集中器。
shell3 设置为网络中的第三个对等机。这将运行一个收集器。

要编译这些代码，您需要安装 JDK 1.3 或更新版本。在 code 目录时，执行 MAKEIT.BAT 批处理文件。这将编译代码并在 classes 目录中创建类文件。

接着，运行 MAKEJAR.BAT 批处理文件。这将创建一个包含所有代码的 dwjxta.jar 文件；将它放到 lib 目录，为实验做好准备。

现在，请启动三个不同的命令窗口。将它们的目录分别改到 shell1、shell2 和 shell3。

在 shell1 目录中编辑 runshell.bat 文件，将您在配置期间用来设置安全性的用户标识和密码反映出来（密码必须至少八个字符长）。编辑 runconc.bat 和 mdidgen.bat 文件，同样要有这个用户标识和密码。

使用 runshell.bat 运行这个 shell，并按以下所示配置这个对等机：

对等机名： node1
传输： TCP/IP 启用，HTTP 禁用，选中作为集中点，无中继
所用 TCP 端口： 9701
安全性用户名和密码： 如在批处理文件中所定制

因为我们的系统假设已经创建了一个用于操作的组，所以我们需要在该 shell 中创建这个组。在这个 shell 中时，使用以下命令创建 dwtest 组：


Jxta> myadv = mkadv -g dwtest
Jxta> mygrp = mkpgrp -d myadv dwtest



这将创建我们将使用的 dwtest 组。您可以这样来确认它已经被创建：


Jxta>groups
group0: name = dwtest



现在您可以退出该 shell。

现在，请使用 mdidgen.bat 文件试验统一地址（ID）的分散生成。当您运行这个文件时，应得到类似这样的输出：

清单 6. mdidgen.bat 的输出
remote group discovery message sent
group joined successfully
public static final String ClassID =
"urn:jxta:uuid-DCDD418FCC194040AA13A52A334B967105";
public static final String SpecID =
"urn:jxta:uuid-DCDD418FCC194040AA13A52A334B96716C515B975C2941AD9FBC90178B6918A806";
public static final String PipeID =
"urn:jxta:uuid-2184CACA259B42E0A866AEA788A923054C519D304E07415195B0917C81238FD004";



请注意所生成的 ModuleClassID、ModuleSpecID 和 PipeID。这就是我们获得在集中器服务用到的 ID 的办法。

通过执行 runconc.bat 文件启动集中器。这将读取 dwConfig 文件，这个文件告诉集中器加入到 dwtest 组。您的输出应与此有些相似：

清单 7. 1 号集中器（runconc.bat）的输出
Starting Jxta...
Joining default NetPeerGroup...
Attempting to join group: dwtest
remote group discovery message sent
group joined successfully
group dwtest joined successfully
Look for previously created Pipe Adv, create one if not exist
Looking for PipeAdvertisement, please wait...
Previously published pipe advertisement not found, creating a new one.
Locally caching the new pipe advertisement...
Checking to see if MSA previously published...
Looking for ModuleSpecAdvertisement, please wait...
cannot find it locally, trying remote
... MSA not found, need to create it
Creating new MSA
Locally and remotely publish the MSA
Creating pipe for data collection...
pipe created successfully
Waiting for data from collector...



到这里，集中器实例就建立好了，并且为接收来自收集器的数据做好了准备。

现在，到 shell2 命令窗口中编辑 runconc.bat 文件，将您的安全性用户标识和密码反映出来。接着，使用 runconc.bat 文件运行集中器实例。在配置过程中设置以下参数：

对等机名： node2
传输： TCP/IP 启用，HTTP 禁用，无集中点，无中继
所用 TCP 端口： 9702
安全性用户名和密码： 如在批处理文件中所定制

如果一切都正确运行，则您应看到与此相似的输出：

清单 8. 2 号集中器（来自 Shell2 的 runconc.bat 输出）
Starting Jxta...
Joining default NetPeerGroup...
Attempting to join group: dwtest
remote group discovery message sent
group joined successfully
group dwtest joined successfully
Look for previously created Pipe Adv, create one if not exist
Looking for PipeAdvertisement, please wait...
Checking to see if MSA previously published...
Looking for ModuleSpecAdvertisement, please wait...
.. found previously published MSA
Creating pipe for data collection...
pipe created successfully
Waiting for data from collector...



请注意，集中器的 ModuleSpecAdvertisement 被找到了，所以这个集中器实例不必另外创建一个 ModuleSpecAdvertisement。现在它也在等待来自收集器的输入。

最 后，到 shell3 命令窗口中编辑 runcoll.bat 文件，将您的安全性用户标识和密码反映出来。接着，使用 runcoll.bat 文件运行收集器实例。这个实例将使用 shell3 目录中的 dwColConfig 文件，该文件告诉收集器应加入到 dwtest 组，这个组的位置是“Timbuktu North”。在配置过程中设置以下参数：

对等机名： node3
传输： TCP/IP 启用，HTTP 禁用，无集中点，无中继
所用 TCP 端口： 9703
安全性用户名和密码： 如在批处理文件中所定制

这个收集器实例将开始查找 ModuleSpecAdvertisement 并且应该能找到。然后，它将创建一条管道与已经运行的集中器通信。您应看到与此相似的输出：

清单 9. 收集器（来自 Shell3 的 runcoll.bat 的输出）
Reading config file, dwColConfig, and processing...
group to join will be dwtest
collector location is Timbuktu North
Starting Jxta...
Joining default NetPeerGroup...
Attempting to join group: dwtest
remote group discovery message sent
group joined successfully
group dwtest joined successfully
Searching for collector's MSA...
Looking for ModuleSpecAdvertisement, please wait...
cannot find it locally, trying remote
.. found collector's MSA
Extracting pipe adv from MSA...
Connecting to concentrator network...
pipe created successfully
... collecting data....
... data collected, sending to concentrator
waiting until next sample...
... collecting data....
... data collected, sending to concentrator
waiting until next sample...



请注意，数据被收集起来并定期发送到集中器服务。当数据穿过 P2P 网络以及两个集中器接收这些数据并进行处理时，请注意观察。

高难度的应用模式
我 们的气象收集示例说明了这样一个应用模式：在一般的方面，它使用普遍流行的应用 P2P 系统；从特定的方面，它使用 Jxta。这个模式包含两个耦合极其松散的群体：消费者和生产者。当消费者想要生产者所生产的产品时，消费者不愿作出坚定的许诺，也不愿受限于特定生产 者。在这种想法背后可能有几个现实动机。消费者可能想：

可以在任意时间进行选择，以选择最佳的可用生产者


降低对某个生产者的成功或失败的依赖风险


从非常庞大的动态社区中选择，这种社区的大小和拓扑结构在物理上是难于管理的
当 消费者群体和生产者群体出现交迭时，这种模式变得十分有趣，当前可用的、流行的、世界范围内的文件共享系统就例证了这一点。与传统的联网技术不同，P2P 系统从一开始就是设计来适应这种应用模式的。特别地，与使用传统的客户机／服务器技术进行设计时，必须提供的复杂的解决方案不同，Jxta 使得创建这些系统既容易又轻松。

超越 TCP/IP 的联网
为了真正突出 Jxta 带来的价值，我选择了全球气象信息收集系统作为一个示例。然而，这个问题及解决方案具有许多业务模式（business scenario）的典型特征，这些业务情形如移动销售队伍自动化、商品贸易、内容分发和企业到企业电子商务等等，可以列出很多。您可以同时使用 P2P 网络和传统的客户机／服务器网络，从而构建大大超出当今静态边界的新型网络解决方案。开放源代码的 Jxta 平台将是这些新型解决方案的实现工具。我希望本系列已经激起您探索 Jxta 提供的可能性的愿望。

from-ibm developer