ICE中间件技术详细教程

ICE中间件技术及其应用研究

赖性导致其移植性和可扩展性不够强大，限制了在工业级实时控制环境下的应用。ＩＥ中间件是ＺｒＣ，Ｃｅｏ
Ｉｃ司开发的…种新的分布式中间件，ｎ公支持多种网络通讯协议并实现多种渊用方式。本文将对其体系结构、应用模型以及优点进行讨论，最后基于ＩＥ中Ｃ
计
２１０２年第５期
文章编号：０６２７（０２０－１２０１０－４５２１）５０９－３
算
机

与
现
代
化
第２１０期
ＪＵＮＩＹ１ＮＡｔＡＩＡＪＵＸＡＤＩｔＳＵ
ＩＥ中间件技术及其应用研究Ｃ
ＯｊｃＲｑｅｔｒｋｒｒｈｔｔｒ）型刮和ＳＮ公ｂｅｔｅｕｓＢｏｅＡｃｉｃｅ模ｅｕＵ司的ＥＢ（ｎｅｒｅＪｖｅｎ模型。这些技术ＪＥｔｐｓａａＢａ）ｒｉ
张俊军，章旋
（中广核（京）真技术有限公司，东深圳５８３）北仿广１０１摘要：集散式控制系统（Ｃ）ＤＳ的仿真需要考虑到实时、定和高精度的要求。ＩＥＩｔｍｅＣｍｕｉｔｎＥｇｅ是一种稳Ｃ（ｎｅｔｏｍｎｃｉｎｉ）ａｏｎ面向对象的中间件平台，具有高度的可扩展性和重用性，构建复杂的分布式客户一务器计庠环境提供了工具。本文为服介绍ＩＥ中间件技术的基本概念、用模型以及它的优势，Ｃ应最后应用于ＤＳ仿真中。Ｃ关键词：中间件；Ｃ集散式控制系统；真ＩＥ；仿

Ice中间件研究

Ice中间件研究简介Ice 是一种面向对象的中间件平台。

从根本上说，这意味着Ice为构建面向对象的客户－服务器应用提供了工具、API 和库支持。

Ice 应用适合在异构环境中使用：客户和服务器可以用不同的编程语言编写，可以运行在不同的操作系统和机器架构上，并且可以使用多种网络技术进行通信。

无论部署环境如何，这些应用的源码都是可移植的。

安装windowsWindows平台安装比较简单，下载安装文件然后安装即可。

Windows安装文件已带有demo。

Linux1.下载Ice-3.4.1-rhel5-i386-rpm.tar.gz2.安装文件放到linux任意目录，打开linux终端3.解压文件#tar xzvf Ice-3.4.1-rhel5-i386-rpm.tar.gz4.安装必要的rpm#rpm -ivh ice-3.4.1-1.rhel5.noarch.rpm#rpm -ivh db48-4.8.30-1ice.rhel5#rpm -ivh ice-libs-3.4.1-1.rhel5#rpm -ivh ice-servers-3.4.1-1.rhel5#rpm -ivh ice-utils-3.4.1-1.rhel55.根据需要安装宿主语言支持，本例为java#rpm -ivh db48-java-4.8.30-1ice.rhel5#rpm -ivh ice-java-3.4.1-1.rhel5#rpm -ivh ice-java-devel-3.4.1-1.rhel5安装完毕，如需要demo,需要下载Ice-3.4.1-demos.tar.gzIce服务Ice 核心为分布式应用开发提供了一个完善的客户－服务器平台。

但现实应用需要的常常不止是远程通信能力：你通常还需要拥有这样的能力：随需启动服务器、把代理分发给客户、分发异步事件、配置你的应用、分发应用补丁，等等。

在Ice 中有一些服务，能够提供上述特性及其他一些特性。

ICE中间件研究笔记2

ICE中间件研究笔记22.6 ICE网格计算IceGrid用于支持分布式网络服务应用，一个IceGrid域由一个注册表(Registry)和任何数目的节点(Node)构成。

注册表(Registry)和节点(Node)一起合作管理一些信息以及包含一些应用(Application)的服务进程。

每项应用(Application)被指定在特定节点上的服务。

这个注册表(Registry)持久记录了这些信息，而节点(Node)负责启动和监测其指定的服务器进程。

对于一个典型的配置，一个节点(Node)运行在一台计算机(称之为Ice服务器主机)。

注册表(Registry)并不消耗很多处理器时间，所以它常常是和一个节点(Node)运行在同一台计算机上的，注册表(Registry)还可以和一个节点(Node)可以运行在同一进程中.如果需要容错，注册表(Registry)还可以用主从式的设计支持复制(Replication)。

注册表(Registry)的主要责任，是解决作为Ice定位服务的间接代理问题，当客户端第一次尝试使用一种间接代理，客户端Ice run time首先连接注册表(registry)，注册表将间接代理的符号信息转化为直接代理的endpoint，然后客户端和直接代理建立一个连接。

通过适配器复制，同名适配器可以分布在多个节点上，间接代理可以映射到多个节点上的直接代理，在运行时由注册表服务根据负载均衡自动选择一个直接代理给客户端。

使用间接代理时，客户端可以用以下方式直接获取服务对象代理：MyProxy=theObject@theAdapter//对象@适配器更简单一点的话可以用以下方式MyProxy=theObject//对象2.6.1分布式部署在部署IceGrid分布式服务时，需要启动注册表服务(icegridregistry)，并配置注册表服务地址端口、通信协议和注册信息保存的目录地址(ICE的注册信息保存为BerkeleyDB的数据库文件)：IceGrid.Registry.Client.Endpoints=tcp-p 4061IceGrid.Registry.Data=/opt/ripper/registry在服务器节点中和客户端都需要配置注册表服务的地址端口和通信协议：Ice.Default.Locator=IceGrid/Locator：tcp-h 172.0.0.1-p 4061然后分别启动注册表服务(icegridregistry)和节点服务(icegridnode).ICE提供了部署工具icegridadmin,这个icegridadmin工具也需要定义Ice.Default.Locator属性.接下需要编写应用部署文件，应用部署文件以XML方式保存。

面向对象的分布式中间件ICE

技术概览
用的应用服务器。ＣＥｏ可以ＩＢｘ轻松地运行和管理Ｉ服务，ＣＥ
档由国内权威中间件专家马维进行分布式程序设计 ” 。
Ｉ是一种现代的面向对这些服务可作为ＤＬ、共享库ＣＥＬ
批注本地保存成功开通会员云端永久保存去开通
维普资讯
ｉ系统ｌ界＝敖｝ｉ＝
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ ’
的介绍，以期待更多的爱好者加入Ｉｅ的应用开发中。ｃ
面向对象的分布式中间件ｌＣＥ
■ 李志明在分布式计算领域，ＰｔｏｎＰＨＰ、Ｃ撑和ＶＢ等版。２０ｙｈ、０３年３月，Ｏｒｉ２０ｂｘ００ＣｏＲＢＡ和ＣｏＭ＋占有重要的多种开发语言。地位。然而，又分别由于 “ 复
为ＣｏＲＢＡ开发一系列产品
之后，深感于ＣｏＲＢＡ的复杂，是走到一起致力于创造于
一
种全新的分布式计算模型。
ＺｏｅｒＣ公司成立之后，速推迅出一系列遵循ＧＰＬ、合这个符理念的分布式计算产品，成构
责编／陈杰ｋｎｙｘｍａ．ｍ美编／庆琨ｅｎｃ＠ｇｉｏｌｃ
架构。
雄传Ｏｎｉｅ）款国产在线游功能一一可能达到数百万个ｌ）这ｎＩＣＥ对象。

ICE

实现原理
实现原理
客户与服务器
按照常规的理解，客户与服务器的划分在于两者承担的角色不同：客户是发出请求的一方，服务器是响应请求、提供服务的一方。然而在实际应用中，很多服务器并不是纯粹的服务器，它们常常充当某些客户的服务器，但为了完成它们的客户的请求，它们又会充当其他的服务器的客户。
ICE同理，很多客户机也不是纯粹的客户。例如，客户可以在服务器上启动一个长时间运行的操作，在启动该操作时，客户可以向服务器提供回调对象（ callback object），供服务器用于在操作完成时向客户发出通知。在这种情况下，客户在启动操作时充当客户，而在接收操作完成通知时充当服务器。
在设计网站架构的时候可以使用ICE实现对网站应用的基础对象操作，将基础对象操作和数据库操作封装在这一层，在业务逻辑层以及表现层(java,php,.net,python)进行更丰富的表现与操作，从而实现比较好的架构。基于ICE的数据层可以在未来方便的进行扩展。ICE支持分布式的部署管理，消息中间件，以及网格计算等等。
ቤተ መጻሕፍቲ ባይዱ术简介
技术简介
中间件(middleware)是基础软件的一大类，属于可复用软件的范畴。顾名思义，中间件处于操作系统软件与用户的应用软件的中间。中间件在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。
ICE
面向对象中间件
01 技术简介
03 实现过程 05 优点
目录
02 实现原理 04 设计目标
基本信息
网络通信引擎ICE(Internet Communications Engine)是Zero C公司的分布式系统开发专家实现的一种新的高性能的面向对象中间件平台。从根本上说， ICE为构建面向对象的客户-服务器应用提供了工具、 API （ Application Program Interface）和库支持。基于ICE可以实现电信级的解决方案。

一种可用于分布式作战指控系统仿真的新中间件——ICE

ＨｕｎｅａｇＷｌ
（ｈｎＤｇａＥｇｅｒｇＩｓｔｔ，ｈｎ３０７）ＷｕａｉｔｎｉｅｉｔｕｅＷｕａ４０４ｉｌｎｎｎｉ
Ａｓｒｃ：ＣｓａｎｍｉｄｅａｅｔｃｎｌｇｅｅｏｉｇｉｅｅｙａｓｌｋｎｓｏｘｅｌｎｈｒｃｅｓｃｏＣｉｔｄｃｄｉｂｌａｔＩＥｉｄｌｗｒｈｏｏｙｄｖｌｐｎｔｓｅｒ．ＡｌｉｄｆｃｌｔａａｔｒｔｆＩＥａｎｒｕｅｅｎｈｅｅｃｉｉｏｎｔｉｌｅ．ｎｌｕｈａ８ｙｇｒ（ｉｍｎｆｓｌｔｎｏｉｔｂｔｏａｏｈｓ￣ｐｒＩｇｎｌ五ｎＩｒｅｔｉａｏｆｄｓｉｕｅｃｍｂｔｃｍｍａｄａｄｃｎｒｌｙｔｍ，ｔｉｐｐｒｐｉｔｕｓｏｅｏｅｕｅｏｍｕｉｒｄｎｎｏｔｓｅｏｓｈｓａｅｏｎｓｏｔｅｆｒ— ｕ
式作战指控系统研究的热点和难点问题。指挥控制系统对信息安全的要求很高，信息要求实时处
和操作系统ＡＩＰ的细节，使得开发人员可以专注于实现组件的功能本身。在中间件技术当中，现在应
用最为成熟的当数ＣＲＡＣｍｏｂｃＲｑｒｔＯＢ（ｏｍｎＯｊｔｅｅｅｕｓＢｏｅＡｃｉｃｒ。它是上世纪九十年代中期出ｒｒｒｔｔｅｋｈｅｕ）
现的技术。能够在多种不同操作系统和实现语言
上运行。曾被认为是通信基础设施领域取得突破性进展的标志。但是，尽管它成功建立了分布式体系架构，由于其难于学习，使用复杂，受设计和协议的低效困扰，并且不支持一些常用的特性，以无所法被广泛的采用，限制了它的发展。本文介绍的

国家能源ice操作手册

国家能源ice操作手册一、引言国家能源ICE（Internet Control Energy）系统是一个集能源管理、控制和优化于一体的先进系统。

本操作手册旨在为操作人员提供全面、详细的操作指南，确保系统稳定、高效地运行。

二、系统概述国家能源ICE系统采用先进的互联网技术，实现对能源设备的远程监控、控制和优化。

系统具备实时数据采集、数据分析、故障诊断、远程控制等功能，为企业提供全面的能源管理解决方案。

三、操作流程1.登录系统操作人员使用个人账号登录系统，确保账号与权限相符。

账号分为管理员、操作员和访客三种类型，权限各不相同。

2.数据采集与监控系统自动采集能源设备数据，实时展示设备运行状态、能耗情况等信息。

操作人员可对设备进行实时监控，确保设备正常运行。

3.数据分析与优化系统对采集的数据进行深入分析，为企业提供能源消耗报告、设备效率分析等数据支持。

操作人员可根据报告进行设备优化调整，降低能源消耗。

4.故障诊断与处理当设备出现故障时，系统自动报警并提示故障原因。

操作人员根据提示进行处理，确保设备及时恢复正常运行。

5.远程控制与调整操作人员可根据实际需求，对能源设备进行远程控制和调整。

通过系统界面，可实现对设备的开关机、参数设置等操作。

四、注意事项1.确保系统环境安全稳定，避免因外部因素导致系统崩溃或数据丢失。

2.定期对系统进行维护和升级，确保系统功能不断完善，满足企业需求。

3.严格遵守操作规程，避免因误操作导致设备损坏或数据异常。

4.定期备份数据，确保数据安全可靠，防止意外情况发生。

5.在处理故障时，应先切断设备电源，确保人员安全。

然后根据故障提示进行处理，切勿盲目操作。

6.保持与设备供应商的沟通与联系，及时了解产品更新和技术支持情况。

7.定期对操作人员进行培训和考核，提高操作技能和安全意识。

8.建立完善的应急预案和故障处理机制，确保在突发情况下能够迅速响应并解决问题。

ICE中间件技术详细教程

ICE中间件技术详细教程一、ICE中间件概述ICE中间件是一种基于网络的通信框架，它允许不同机器上的应用程序进行通信，并提供了高性能和可扩展性。

ICE基于面向对象的编程模型，将通信对象抽象为接口，并通过接口定义通信协议，从而隐藏了底层通信细节，使开发者可以专注于业务逻辑的实现。

ICE中间件支持多种编程语言，包括C++, Java, Python等，这使得开发者可以使用自己熟悉的编程语言来开发分布式应用程序。

ICE中间件还提供了丰富的工具和库，以便开发者可以更加方便地开发和调试应用程序。

二、ICE中间件的安装和配置安装完成后，需要配置ICE的环境变量。

在Windows系统下，可以在系统环境变量中添加ICE_HOME变量，并将ICE的安装路径作为其值。

在Linux系统下，可以在.bashrc文件中添加exportICE_HOME=/path/to/ice命令。

完成配置后，重新启动终端使其生效。

三、ICE中间件的基本使用在ICE中，应用程序之间的通信是通过接口进行的。

首先，需要定义接口，并使用Slice语言编写其接口规范。

Slice语言是一种专门为ICE设计的领域特定语言，用于定义接口的数据类型和方法。

例如，以下是一个简单的Slice接口定义：```slicemodule MyModuleinterface MyInterfacevoid sayHello(;};};```接口定义完成后，可以使用Slice编译器将其编译为不同语言的接口代码。

例如，可以使用slice2java命令将上述接口编译为Java代码。

接口代码生成后，可以在应用程序中使用该接口。

首先，需要创建ICE运行时环境并初始化。

然后，可以通过接口代理创建一个远程对象。

远程对象代表了另一个应用程序中的接口对象，可以通过它来调用远程接口的方法。

以下是一个简单的Java示例代码：```javaimport MyModule.*;public class Mainpublic static void main(String[] args)MyInterfacePrx myInterface =MyInterfacePrx.checkedCast(proxy);if (myInterface == null)throw new Error("Invalid proxy");}myInterface.sayHello(;}}```上述代码中，通过调用stringToProxy方法创建一个接口代理。

ICE系列培训(三)

1. ICE运行时
1.3 通信器的初始化
例如：定制一个类型为MyLogger的日志记录器 … Ice::InitializationData id; id.logger = new MyLoggerI; Ice::CommunicatorPtr ic = Ice::initialize(argc, argv, id); … 例如，我们的总线客户端的通信器是在下面所示函数内初始化的： void CBusClientForRpcClient::ClientInit(const string &strUnmBusRegistryServerAddress, const string &strClientName) { Ice::InitializationData initData; … m_poVar->m_poRpcCommunicator = Ice::initialize(initData); … }
namespace Ice 示例：运行时属性集可从文件中读取 { InitializationData initData; struct InitializationData initData.properties = createProperties(); { initData.properties->load(configFile); PropertiesPtr properties; LoggerPtr logger; StatsPtr stats; StringConverterPtr stringConverter; WstringConverterPtr wstringConverter; ThreadNotificationPtr threadHook; DispatcherPtr dispatcher; }; }；

Ice中间件

西工大计算机学院
中间件的特点
• • • • 标准的协议和接口。分布计算，提供网络、硬件、操作系统透明性。满足大量应用的需要。能运行于多种硬件和操作系统平台。
西工大计算机学院
中间件的作用
• 简单来说就是试图通过屏蔽各种复杂的技术细节使技术问题简单化。 • 具体地说，中间件屏蔽了底层操作系统的复杂性，使程序开发人员面对一个简单而统一的开发环境，减少程序设计的复杂性，将注意力集中在自己的业务上，不必再为程序在不同系统软件上的移植而重复工作，从而大大减少了技术上的负担。
西工大计算机学院
目录
1. 中间件的介绍 2. 什么是ICE以及特点 3. ICE核心功能架构 4. ICE与CORBA 5. ICE与网络安全
西工大计算机学院
一、中间件的介绍
1.什么是中间件
2.中间件的特点
3.中间件的作用 4.中间件的分类
西工大计算机学院
什么是中间件
中间件是在计算机硬件和操作系统之上 , 支持应用软件开发和运行的系统软件,它能够使应用软件相对独立于计算机硬件和操作系统平台,为当今的大型分布式应用搭起了一个标准的平台,把大型企业分散的系统和技术组合在一起,实现大型企业应用软件系统的集成。
网络通信引擎（Internet Communications Engine, Ice）是由ZeroC的分布式系统开发专家实现的一种新的高性能的面向对象中间件平台。它号称标准统一，开源，跨平台，跨语言，分布式，安全，服务透明，负载均衡，面向对象，性能优越，防火期穿透，通讯屏蔽。因此相比 CORBA，DCOM，SOAP，J2EE等的中间件技术，自然是集众多优点于一身，而却没有他们的缺点。

ICE中间件

Slice的开发过程
ICE的调用方法
同步调用：
在调用期间，客户线程被挂起，并在调用完成（及所有结果可用）时恢复
异步调用：
AMI是针对客户端而言的，当客户端使用AMI发出远程调用时，客户端需要提供一个实现了回调接口的类用于接收通知。然后不等待调用完成立即返回，这时可以继续其它活动，当得到服务器端的答复时，客户端的回调类中的方法就会被执行。
对象适配器(Ice::ObjectAdapter)
--对象适配器实现了一个向上调用接口，把Ice run time 与服务器中的应
用代码连接在一起。 --客户通过这些端点访问适配器所提供的Ice对象，即通过适配器访问 servant.一个对象适配器与一个端口绑定。 --如果服务器端同时监听两个端口的话必须建立两个适配器．
ICE整体架构示意图
通信器&对象适配器
通信器(Ice::Communicator)
-- ICE在进行通信时，服务器和客户端都必须建立一个通信器，通信器为该通信进程
分配和管理资源，可以把通信器看做通信双方的一个专用线路。
代理对象和字符串之间互相转换的ing(const Ice::ObjectPrx&) const; Ice::ObjectPrx stringToProxy(const std::string&) const;
Ice 核心为远地通信提供了客户端和服务器端运行时支持 Ice 核心的通用部分可通过Ice API 访问，如Icerun time 的初始化等代理代码是根据你的Slice 定义生成的,它为客户提供了一个向下调用（down-call）接口，并提供了整编和解码功能骨架代码是客户端代理代码的服务器端等价物：它提供了向上调用 (up-call)接口，允许Ice run time 把控制线程转交给你编写的应用代码对象适配器（object adapter）是专用于服务器端的Ice API 的一部分

ICE简单介绍及使用示例

ICE简单介绍及使用示例1、ICE是什么？ICE是ZEROC的开源通信协议产品，它的全称是：The Internet Communications Engine，翻译为中文是互联网通信引擎，是一个面向对象的中间件，使我们能够以最小的代价构建分布式应用程序。

ICE使我们专注于应用逻辑的开发，它来处理所有底层的网络接口编程，这样我们就不用去考虑这样的细节：打开网络连接、网络数据传输的序列化与反序列化、连接失败的尝试次数等。

2、为什么会有ICE？ICE是分布式应用的一种比较好的解决方案，虽然现在也有一些比较流行的分布式应用解决方案，如微软的.NET（以及原来的DCOM）、CORBA及WEB SERVICE 等，但是这些面向对象的中间件都存在一些不足：.NET是微软产品，只面向WINDOWS系统，而实际的情况是在当前的网络环境下，不同的计算机会运行不同的系统，如LINUX上面就不可能使用.NET；CORBA虽然在统一标准方面做了很多的工作，但是不同的供应商实现之间还是缺乏互操作性，并且目前还没有一家供应商可以针对所有的异种环境提供所有的实现支持，且CORBA的实现比较复杂，学习及实施的成本都会比较高；WEB SERVICE最要命的缺点就是他的性能问题，对于要求比较高的行业是很少会考虑WEB SERVICE的。

ICE的产生就是源于.NET、CORBA及WEB SERVICE这些中间件的不足，它可以支持不同的系统，如WINDOWS、LINUX等，也可以支持在多种开发语言上使用，如C++、C、JAVA、RUBY、PYTHON、VB等，服务端可以是上面提到的任何一种语言实现的，客户端也可以根据自己的实际情况选择不同的语言实现，如服务端采用C语言实现，而客户端采用JAVA语言实现，底层的通讯逻辑通过ICE的封装实现，我们只需要关注业务逻辑。

3、ICE是如何工作的？Ice 是一种面向对象的中间件平台，这意味着 Ice为构建面向对象的客户－服务器应用提供了工具、API 和库支持。

基于ICE的安全中间件的研究与实现

它的接口访问安全服务：下提供不同的实现接口．对以
提供安全服务是近年研究的热点问题当前几个主流
的面向对象中间件是：ＣＯＣＲＢＭｉｒｓｆＮＴ、ＤＭ、ＯＡ、ｃｏｏｔＥ．
ＳＡＯＰ和ＷｅｅｉｓｂＳｒｃ等ＤＯ和Ｍｉｏｏ．ＥｖｅＣＭｃｓｆＮＴ是ｒｔ
０引言
随着计算机技术的快速发展．各种应用软件需要
技术的基础部分．出了一种基于ＩＥ的安全中间件提Ｃ架构模型，实现这种基于ＩＥ技术的安全中间件。Ｃ
在多种不同的平台之间进行移植．越来越多的单一应用正被不同来源的中间件软件代替这样安全服务也
组完整的特性．支持广泛领域中实际分布式应用的开习和使使
用：提供～种在网络带宽，内存使用和开销方面都高效地实现：提供一种具有内建安全性的实现．使得它适用
于不安全的公共网络本文结合当前成熟的信息安全
了基于ＩＥ的安全中间件Ｃ
环境的规范．于Ｃ或Ｃ＋言．对＋语源码兼容性从未实现过［ＳＡ１ＯＰ无论在网络带宽方面还是在ＣＵ开销方ＪＰ面．会给应用造成严重的性能恶化，都以至于其无法适应许多有苛刻性能要求的系统。Ｗｅｅｖｅ低效，ｂＳｒｉｓｃ同时需要使用私有开发平台，并且安全问题难于解决。ＩＥ是一种适用于异种环境的面向对象中间件：提供一Ｃ

ICE开发实例指南

一IEC框架介绍Ice 是一种面向对象的中间件平台。

从根本上说，这意味着Ice 为构建面向对象的客户－服务器应用提供了工具、API和库支持。

Ice 应用适合在异种环境中使用：客户和服务器可以用不同的编程语言编写，可以运行在不同的操作系统和机器架构上，并且可以使用多种网络技术进行通信。

无论部署环境如何，这些应用的源码都是可移植的。

什么是ICE?ICE(internet communications engine)是适用于异种环境的面向对象中间件平台。

那么什么是中间件呢?比较流行的定义是:中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。

中间件位于客户机/服务器的操作系统之上，管理计算资源和网络通讯。

从中间件的定义可以看出，中间件是一类软件，而非一种软件；中间件不仅仅实现互连，还要实现应用之间的互操作；中间件是基于分布式处理的软件，定义中特别强调了其网络通讯功能.2.ICE的一些概念服务器/客户端(server/client):这个的定义与一般的定义相同,主动的一方被认为是clientICE对象:跟OOP中的对象类似,不同之处在于,在分布式的环境中,同一个ICE对象在不同的地址空间中都可能存在着.ICE对象也提供了一组接口(facets).ICE对象还有一个特殊的接口:主接口.代理(proxies):是ICE对象引用,代理是在客户地址空间,客户对ICE对象的操作就是通过代理来进行的.代理封装了完成:ICE对象的寻址(包括服务器的寻址),激活ICE对象,传入参数,等待执行并返回执行结果servant:在服务器上的执行体,ICE对象对服务器的操作就是通过调用servant."最多一次"原则:一次对目的的访问,只会执行一次(并不排除出错重试)ICE的5个服务Summary这里介绍了ICE的五个服务Ice为分布式开发提供了技术完善的客户-服务平台。

Embedded Middleware Solution ICE分布式中间件教程

Off-the-shelf Embedded Middleware Solution for UA Vs HW-SW Platform DevelopmentJ.Barba,F.J.Villanueva,M.J.Abaldea,D.Villa,O.Acena and J.Carlos L´o pezARCO Research Group.School of Computer Science.University of Castilla la Mancha.Ciudad Real(Spain)Email:jesus.barba@uclm.esAbstract—In this paper a Commercial-off-the-Self(COTS) platform for Unmanned Aerial Vehicles(UA V)is presented.The goal of this work is to provide the industry with aﬂexible and efﬁcient solution to smooth the integration and heterogeneous de-velopment challenges in this scenario.On one hand,the proposed platform enables transparent and efﬁcient interaction with the control station implemented in ZeroC Ice.On the other hand, the proposed approach abstracts both embedded and desktop software developers from the platform details.A customized hardware-software layer assures a high-level,efﬁcient reliable communication while a complete tool-chain automatizes the generation of application speciﬁc code,reducing the development time.Index Terms—Middleware;UA V;ZeroC-Ice;Hw-Sw Integra-tion;I.I NTRODUCTIONUnmanned Aerial Vehicles(UA V)are extending its appli-cationﬁeld from military scenarios to civil applications[1]. The domain of civil UA V applications is dominated by low-cost vehicles which are devoted to speciﬁc tasks like smart agriculture[2],smart city[3],rescue tasks[4],etc.These type of UA Vs usually rely on an embedded board with key features such as low-weight and low power consumption so as to extend UA V operation lifetime.One of the most promising approaches for next-generation UA V on-board platforms is the use of hybrid systems where micro-controller and reconﬁgurable logic come together,for example.These type of boards areﬂexible enough to support a wide range of applicationﬁelds,ranging from vision-based applications-where FPGAs(Field-Programmable Gate Array)can apply their computing power to avoid sending raw multimedia data through the wireless link-to sensor-based applications,cryptography,etc.In this paper an object-oriented software platform for UA V application development is introduced.The main contributions of our work are:•Seamless integration of application speciﬁc hardware and software components which eases the development of hybrid systems.This is achieved because of the use of a common,high-level model which abstracts our platform functionality(either hardware or software)as a series of objects.•Reduction of the development time.The developer is provided with a toolchain(interface deﬁnition languageand interface compiler)which automatizes the generation of the integration infrastructure.•Optimal and efﬁcient implementation of the middleware engine.Traditional distributed object-oriented frame-works require excessive resources for most of the UA V HW platforms.As it will be shown later,the footprint of the core components is minimized in order toﬁt in the smallest embedded boards.The remainder of this article is organized as follows. Next section describes the state of art in UA V application development and also establishes a set of requirements for a software platform in this applicationﬁeld.Section III and IV thoroughly describes the proposed architecture along with in-terface speciﬁcation and development process.In section V the communication engine called IceC is described.Finally,some of the most relevant quantitative and qualitative aspects of the prototype are described,along with the main conclusions.II.P REVIOUS WORKSThere are a great market opportunity and a lot of companies are setting up their own platforms to support UA V applications. As consequence of this great expansion of these type of vehicles,there is a lack of embedded standard computing platforms for UA V app development.Already in2001,Boeing realized the need of a middleware for this type of vehicles,in[5]Boeing proposes an Open Control Platform(OCP)in order to deal with UA V control tasks.OCP uses ACE(Adaptive Communication Environment) an TAO(an ACE ORB)forﬂight control tasks modeling following the CORBA model.A similar approach is followed in[6].We agree in this object-oriented vision but we extend to HW components in order to deal with HW implemented algorithms(e.g a vision-processing VHDL algorithm)like any other software object in a transparent way.The component model also has been applied to UA V market. In[7]a C++component-based middleware is developed providing with components related mainly withﬂight mission. Again there is a lack of a toolchain in order to automate the work in application speciﬁc components or any reference to HW component integration.The service-oriented middleware(SOM)has been proposed for UA V development,in[8]an exhaustive listing of needed services for UA V application development is elaborated.In2016 30th International Conference on Advanced Information Networking and Applications Workshopsspite of the well-know set of beneﬁts of SOM(quite similar to object-oriented middleware)in terms of software reuse and time-to-market reduction,there is no speciﬁc proposal in this work about toolchain or speciﬁc interfaces so it is about a top-level design exercise.Data Distribution Service(DDS)from Object Management Group(OMG)[9]is used in the UA Vﬁeld.When commu-nications or interaction between components are stateless is a good approach however when we have to model more complex interactions with state,this approach doesn’tﬁt with this type of applications.Speciﬁc middlewares have been developed for speciﬁc tasks (coordination functions[10],avionics subsystems[11],etc.), we are more devoted to design a generic middleware providing guidelines and tools for implement any type of functionality. None of the middlewares presented in this section have considered hybrid platforms or how to integrate HW com-ponents.We consider that there is a lack of solutions for this type of platforms which will play a key role in future UA V development.Our motivation is to build a middleware with:•Focus on hybrid platforms e.g.support hardware compo-nents and with transparent integration with the rest of the infrastructure.•A well-deﬁned set of interfaces as guideline for develop-ers but providing theﬂexible reusability to adapt to each speciﬁc application.•A toolchain for automatic stub and skeleton generation to reduce the error-prone tasks of communication between components of the system(e.g UA V to ground station) and for interaction between SW and HW components.•Support for a efﬁcient,commercial,legacy object-oriented middleware.In order to avoid reinventing the wheel effect,ZeroC Ice[12]is used as the starting point.The idea is to integrate the UA V control and communi-cation operations as another remote object in the system.Thus,the application running in the ground station,could access the services provided by the UA V in a transparent way,using the standard middleware mechanisms.How toﬁt all these requirements is a cross-layer challenge that it has not been addressed by previous works.III.UAV EMBEDDED PLATFORMAlthough many of the concepts and modules developed in our solution are platform agnostic,we set the Silica Xynergy board as the initial target for our solution.The reasons behind this election stem from lessons learned in a former versions of the UA V-platform and the evolution of the application re-quirements.Among this requirements,it is worth noting:cost-reduction,high-performance computing capabilities,a lower power budget to increaseﬂying time and a reduction of the overall weight of the solution.The Xynergy board is a heterogeneous platform which consists of a ARM Cortex-M3based STMicroelectronics controller and a low-cost FPGA from Xilinx.Due to a rich collection of dedicated and general I/O ports and built-in protocol interfaces,the Xynergy board is suitable for a widerange of applications.The FPGA fabric,a Spartan-6chip,is tightly coupled tothe ARM controller and is intended to hold Hw acceleratingblocks for computing intensive applications:video,digitalﬁltering,cryptography,etc.FPGA technology provides a closeto custom hardware performance while being able to changetheir behavior through time.The development of applications and custom IP(IntellectualProperty)cores for the Xynergy board can be accomplishedby means of off-the-shelf tools freely available for multipleplatforms.A.Hardware supportIn this section,a description of the System-on-a-Chip de-ployed in the FPGA fabric is presented.The role of thereconﬁgurable device is multiple and comprises:•Interface between the DDR3RAM memory and the ARM controller which has no other mechanism to access thedata.•Accelerator of computing intensive functions by means of dedicated hardware.•Communication manager through a tailored hardwarecontroller.Fig.1.Architecture of the SoC deployed in the Spartan-6FPGA to support UA V embedded operations.Figure1graphically represents the main modules and the architecture of the hardware infrastructure which supports the above-mentioned functionality.The FSMC(Flexible Static Memory Controller)bridge implements a translator between the NOR/SRAM memory access protocol and the in-house internal bus protocol.The DDR3access has been implemented using the Xilinxs Multi Port Memory Controller core,conﬁguring a minimum of two64-bit NPI ports depending on the number of cores that must have access to the RAM memory.The modem controller abstracts the access to the radio/wiﬁmodem providing the same low-level operations for modem conﬁguration and data transmission/reception(i.e.source and target MAC addresses,reset,baud-rate,memory map,etc.).The controller logic generates the corresponding AT com-mands to the network modem which is connected to the FPGA via a serial link.Finally,several IP cores can be instantiate whenever there were available resources in the FPGA.The functionality of each core may vary depending on the application,but the interface to the rest of the system remains unaltered.Low-level Hw-Sw interfacing:Communication between the software routines and the hardware components is imple-mented through a register-based interface and an interrupt mechanism.First,16memory words are assigned to the control and conﬁguration registers for each processing IP core. Then,one or more memory blocks are assigned to the hard-ware cores.The number and the size of the blocks is deﬁned by the application developer at design time.These memory blocks are used as input/output buffers where processing cores will write the data produced as the result of their operation or read the input data to be processed.Thus,it is established a producer-consumer integration pattern between the involved pairs in the communication process.The core bus wrapper decodes the addresses only within the control and conﬁguration memory range.The content of the buffer memory can be accessed through the memory con-troller by the software routines but not through the individual core wrappers.Processing IPs are conﬁgured with the base addresses for their respective input/output buffers.The modem controller is an example of processing core. Conﬁguration and control operations are done by means of regular write and read FSMC primitives.The FSMC bridge translates them into bus transactions and the register content is written or read.To send a data packet via the radio interface, the processor writes the content of the packet in RAM memory and then signals the core via a write operation that the packet is ready to be sent.The value to write indicates the modem controller the total size in bytes of the packet.Once the packet has been sent,the modem controller triggers an interrupt that wakes up a service routine responsible for checking error conditions.The receive operation for a data packet works conversely;ﬁrst the modem controller signals the processor via an interrupt that a new packet is ready to be processed.The modem controller will have written the content of the packet in main memory,into the output buffer region assigned.The service routine will,ﬁnally,process the incoming packet.IV.S OFTWARE P LATFORMThe FPGA SoC,previously described,provides the UA V platform with hardware support for essential services such as external data storage and efﬁcient radio packet management. Also,a placeholder for UA V hardware-accelerated functions and a protocol to access them and manage the movement of the data is available to developers.Based on a traditional register/memory mapped approach, a layered software infrastructure has been builtﬁrstly.The ultimate goal is to abstract all the communication details to the application level so that the embedded software developer will only have to deal with a set of high-level,automatically generated software routines.TheμC/OS-II operating system is at the basis of the software stack due to its low footprint,real-time and task model features.Inﬁgure2,the reader canﬁnd a representation of the whole software architecture for the middleware infrastructure. Focusing on the physical and transport layers,a customized FSMC driver has been coded in order to be compliant with the functional speciﬁcation of the FSMC bridge;providing read and write primitives to access the DDR3and radio IPs. The radio driver is a standalone task in charge of transferring packet fragments from/to the DDR3memory and provides the next layer in the hierarchy(reliable network layer)with send and receive primitives.A send operation copies the packet fragment in the output buffer assigned to the radio controller and then signals the hardware to read it from memory and transfer to the radio interface.The radio driver manages the DDR3output buffer as a circular buffer using aﬁxed size vector with all the necessary control information.A receive operation exposes a bit more complex behavior.Once the radio controller has ﬁnished writing a packet fragment in its DDR3input buffer,it raises/triggers an interrupt that is trapped by the radio driver. Depending on the nature of the packet,the radio driver must generate either the acknowledge messages(a new fragment has been received)or update the sending status of a packet(when an acknowledge has been received)which will be interpreted by the reliable network protocol layer later on.The network layer implements a reliable transmission pro-tocol since it is foreseen the use of restrictive wireless links for UA V to ground communication.The IEEE802.15.4RFC [13]has been considered for its use in the implementation of theﬁrst prototype of the UA V platform.This standard is suitable for low-cost and low-power wireless communications at the price of a low-bandwidth and small MTU(Maximum Transmission Unit).The overhead per fragment is small(just 4or5bytes)together with an acknowledge message that is generated by the receiver when a fragment is processed. AlthoughμC/OS-II comes with a implementation of the TCP/IP protocol stack,the requirements for the envisioned UA V platform open the door to the usage of a simpler and less resource demanding network protocol.So far,only point-to-point communication is required so it is only needed a reliable mechanism to fragment and reassemble application packets, which are likely not toﬁt into the physical MTU,leaving out all aspects regarding the routing of packets.A.IceC and application layersFrom the application’s point of view,the embedded software developer might make use of the reliable send and reliable receive primitives which are part of the API exposed by the reliable network layer.However,in order to ease the integra-tion and access of functionality from ground to UA V and vice verse,the UA V programmer is provided with the same system abstractions,work-ﬂow and tools as the ones already availableFig. 2.Functional decomposition of the developed layered middleware infrastructure.in communication middlewares for networked systems.As a result,no special training nor skills are needed,leveraging previous background on distributed system application devel-opment.The embedded IceC1layer is the key element to make the magic happen.IceC is a lightweight implementation of IceP, the standard protocol of ZeroC Ice middleware2.Therefore, our UA V embedded platform is fully compatible with other ZeroC compliant systems.The only requirement is to reach an agreement on the deﬁnition of the services to be implemented.Since ZeroC Ice features an object-oriented model,the service declaration con-sists in a list of method and user-deﬁned data type deﬁnitions. To this end,the developer uses a straightforward Interface Deﬁnition Language called Slice.As an example,Figure3shows a fragment of a simpliﬁed Slice deﬁnition of the communication interface used between the Ground Station(Station interface)and the UA V(Vehicle and HwProcessingEngine interface).When it comes to the speciﬁcation of functionality which is going to be implemented as a hardware module,the interface speciﬁcation must be tagged with the[”:hw”]meta-data directive.At this point,the Slice deﬁnition is processed by a home-made interface compiler which generates a set of functions providing the high-level,object-oriented stylish API to the application programmer.This functions or communication stubs(namely,proxies and skeletons)interact both with the client,server tasks and the IceC runtime so as to progressively translate the invocations into Ice Protocol messages to be sent through the radio interface.1IceC source code is available at:https:///arco_group/icec2 module Autopilot{enum TypeCode{boolT,intT,uintT,floatT,timevalT,byteseqT,stringT };[...]sequence<byte>ByteSeq;struct Param{ParamId id;TypeCode type;ByteSeq data;};sequence<Param>ParamSeq;[":hw"]interface HwProcessingEngine{void setParameterA(short value);void startProcessing(void);void getResult(ResultType*res);};interface Vehicle{bool isAlive(short sessionId);};interface Station{void vehicleState(Vehicle*uav,ParamSeq params);};};Fig.3.Example of Slice speciﬁcation for IceC.V.D EEPLY EMBEDDED MIDDLEWAREThis section aims to provide an insight into the architecture and implementation details of the IceC engine.The IceC runtime layer is a minimal realization of the ZeroC Ice middleware,optimized for our UA V platform needs.In order to keep the compatibility with ZeroC Ice PC-based applications (the target platform for the Ground Station logic)and maintain the same philosophy and work-ﬂow in the UA V side,several extensions and engineering works has had to be carried out. First and foremost,the development of the main architec-tural components of the commercial version following a low-footprint policy.The layer IceC comprises the core elements such as Communicator,Object Adapter,Servant Management, Connections and other helper functions.As a result,a complete static ad-hoc implementation of the principal ZeroC features has been obtained using ANSI C(C90standard)which allows:•An impressive reduction of the memory requirements.•Being supported by Keil compiler for ARM,the IDE used to develop the embedded software.•The resulting application to be potentially certiﬁcated when real-time restrictions apply.Second,the implementation of a transport speciﬁc conﬁg-urable plugin(PC and UA V)for the xbee connection:the xbee-at endpoint.This was necessary due to the following reasons:(a)Xbee is the choice for UA V-Ground Station radio link;and(b)is a necessary step in order to make it usable conventional ZeroC Ice vendor-libraries,tools and C++ bindings over GNU/Linux.And last but not least,the deﬁnition of a mapping of the ZeroC Ice Protocol for ANSI C language which did not exist before.This step comprises a set of rules and languages equivalences to transform Slice grammar and semantics into C structures.As a starting point,CORBA C language Map-ping Speciﬁcation[14]and conventions used in the Ice C++mapping were taken into account.The result of all this work is a fully new language binding together with a interface compiler which generates the middleware stubs responsible for the marshalling and unmarshalling processes.As mentioned in the previous section,these communication stubs depend upon the Slice deﬁnition and they are produced speciﬁcally for an application in an automatic way.static void Autopilot_Vehicle_vehicleState(Autopilot_StationPrxPtr this,Autopilot_VehiclePrxPtr uav,Autopilot_ParamSeq params){Ptr_check(this);Ice_ObjectPrx_connect(this);Ice_OutputStreamPtr os=&(this->stream);/*request header*/Ice_OutputStream_writeBlob(os,Ice_header,sizeof(Ice_header));Ice_OutputStream_writeIdentity(os,this->identity);Ice_OutputStream_writeString(os,"vehicleState");[...]/*encapsulated params*/Ice_OutputStream_writeShort(os,sessionId);Ice_OutputStream_writePrx(os,uav);Autopilot_ParamSeq_writeToOutputStream(&(params),os);Ice_OutputStream_setMessageSize(os);Ice_ObjectPrx_send(this);}Fig.4.IceC generated code for a proxy.Figure4shows and example of the generated ANSI C code for the vehicleState method deﬁned in Figure3,Section IV-A.This function is a proxy to the actual functionality implemented as a server in the Ground Station.The client task,which runs in the UA V,only needs to call the procedure as it is deﬁned by its signature.By means of a set of utility functions implemented in the core of IceC middleware,the different parts of an IceP messages are generated and all the parameters serialized and stored in memory through the Ice OutputStream object.This object is a high-level abstraction of the memory write buffers, where the IceP messages are temporally held before they are sent.For each user data type deﬁned in Slice(i.e.ParamSeq) a pair of functions are also generated which knows how to marshall and unmarshall such data type,according to the Slice(Autopilot ParamSeq writeToOutputStream)deﬁnition. Finally,the built message is sent out to the network using the reliable send primitive provided by the network layer. Client-server communication between UA V and ground station is performed by referring to remote objects.Coding in the UA V must be programmed in ANSI C(forμC-OSII) but for the ground station we have theﬂexibility to use any programming language supported by ZeroC Ice.Figure5shows the code for the server running at the UA V platform(upper half)and the code of the corresponding client executing on a standard PC written in Python(lower side).The objects that we can be identiﬁed are:(a)the communicator is part of the middleware core library and represents the object broker in ZeroC Ice parlance;(b)the PROXY and HWOBJECT void Autopilot_HwProcessingEngine_setParam(short value){ //servant goes here,registers acces through FSMC ifaceFSMC_write(...)[...]}void Autopilot_HwProcessingEngine_startProcessing(void){ //servant goes here,registers acces through FSMC ifaceFSMC_write(...)[...]}void appMainTask(void){XBeeInitTypeDef xbeeConf={XBEE_BD_115200,0x0000,0x0000};Ice_Communicator ic;Ice_ObjectAdapter adapter;Autopilot_HwProcessingEngine servant;xbeeInit(&xbeeConf);Ice_initialize(&ic);XBeeATEndpoint_init(&ic,"xbee-at");Ice_Communicator_createObjectAdapterWithEndpoints(&ic, "Adapter","xbee-at",&adapter);Ice_ObjectAdapter_activate(&adapter);Autopilot_HwProcessingEngine_init(&servant);Ice_ObjectAdapter_add(&adapter,(Ice_ObjectPtr)&servant,"hwengine1");Ice_Communicator_waitForShutdown(&ic);[...]}class Client(Ice.Application):def run(self,args):ic=municator()proxy=ic.stringToProxy(’hwengine1-o:xbee-at’)hwobject=Autopilot.HwProcessEnginePrx.uncheckCast(proxy) paramValue=0hwobject.setParameterA(paramValue)[...]Fig.5.UA V embedded server(ANSI C forμC-OSII)and Python client (ground station)are a local references of remote objects.In theﬁrst linesof the program,the necessary declarations are made and conﬁguration and initialization of the XBee modem takes place as well.Following,the Ice Communicator is created,setting “xbee-at”as the endpoint to use3.Finally,the objects and references to objects needed by the application are got and the data structures containing the parameters to send areﬁlled out before invoking the SET P ARAMETER A remote method.In this scenario,the server requires of theI CE C OMMUNICATOR object(already explained),the ADAPTER and the SERVANT.The ADAPTER providesvisibility to the objects registered by the server,exposing their functionality to the rest of the network.A SERVANT is the piece of code which actually implements the functionalityof the interface.In this example,the reader can identify the interface Hw-ProcessingEngine which corresponds to an simpliﬁed exampleof a possible hardware object running on the FPGA platform. For each method declared in the Sliceﬁle for such interface3XBee-AT endpoint implementation is available at https:///arco_group/xbee-at-endpoints/a function is generated which represents the API to be used from the ground station to,for example,setting up the algo-rithm parameters(i.e.setParameterA)or start the accelerating function.VI.R ESOURCE USAGEThe implementation of the UA V embedded platform de-scribed in the preceding sections has been carried out focusing in size optimizations.TABLE IS YNTHESIS RESULTS FOR THE FPGA S O C.Resource Total amountFlip Flops1537(8%)LUTs1728(18%)Slices772(33%)Table I summarizes the total amount of FPGA resources used by a basic conﬁguration of the UA V SoC.It is only considered the FSMC bridge,the Memory Controller and the Radio IP.More than two thirds of the reconﬁgurable logic area is available for user application purposes.The results have been obtained with the ISE Design Suite11.3from Xilinx, targeting the XC6SLX16Spartan-6chip.The design runs at a clock frequency of100Mhz but the FSMC interface is limited by the Xynergy board to25Mhz which represents a serious bottleneck.TABLE IIS IZE IN BYTES OF THE DIFFERENT SOFTWARE LAYERS.Code Size Subsystem1116FSMC Driver1795Radio Driver1307Network Layer2622IceCConcerning the footprint in memory of the developed soft-ware stack,the results shown in table II conﬁrm the high compactness of the solution with a total size of approximately just7KB.The generation of the object code has been done using the integrated compiler from theμVision IDE from Keil with the highest optimization level and disabling the debugging symbols.It has not been considered the inclusion of the memory overhead due to the IceC communication stubs.Since these pieces of generated software are application dependant,there is no impartial way to measure the impact in general terms. For the same reason,no timing analysis has been taken into account in this work.VII.C ONCLUSIONHW-SW hybrid boards are emerging platforms for UA V applications,however there is a lack of solutions/tools for developing on these type of platforms.In this paper,it has been dissected the architecture and im-plementation details of a tailored middleware infrastructure for hybrid embedded system.With extremely little resources,it is assured the compatibility with standard ZeroC Ice subsystems. No special tools,languages or design skills are required in order to integrate HW or SW components with our solution into an object-oriented networked system.The application use case,ground to UA V communication,introduces additional challenges which are faced using a combination of hardware and software.From an industrial point of view,apart from certiﬁcation issues,our current efforts are devoted to extend the number of heterogeneous embedded platforms and legacy middlewares supported which can integrate in IceC.A CKNOWLEDGMENTThis work has been partly funded by the Spanish Ministry of Economy and Competitiveness under project REBECCA (TEC2014-58036-C4-1-R)and by the Regional Government of Castilla-La Mancha under project SAND(PEII-2014-046-P).R EFERENCES[1]AIA,“Unmanned aircraft systems:Perceptions&potential,”AerospaceIndustries Association,Tech.Rep.,2013.[2]J.Barcelo-Ordinas,J.Chanet et al.,“A survey of wireless sensortechnologies applied to precision agriculture,”in Precision agriculture 13,J.Stafford,Ed.Wageningen Academic Publishers,2013,pp.801–808.[3] F.Mohammed,A.Idries et al.,“Opportunities and challenges of usinguavs for dubai smart city,”in New Technologies,Mobility and Security (NTMS),20146th International Conference on,March2014,pp.1–4.[4]P.Doherty and P.Rudol,“A uav search and rescue scenario with humanbody detection and geolocalization,”in AI2007:Advances in Artiﬁcial Intelligence,ser.Lecture Notes in Computer Science,un and J.Thornton,Eds.Springer Berlin Heidelberg,2007,vol.4830,pp.1–13.[5]J.Paunicka,B.Mendel,and D.Corman,“The ocp-an open middlewaresolution for embedded systems,”in American Control Conference,2001.Proceedings of the2001,vol.5,June2001,pp.3445–3450vol.5. [6]J.Paunicka,D.Corman,and B.Mendel,“A corba-based middlewaresolution for uavs,”in Object-Oriented Real-Time Distributed Computing, 2001.ISORC-2001.Proceedings.Fourth IEEE International Sympo-sium on,May2001,pp.261–267.[7]J.Kwon and S.Hailes,“Mirea:Component-based middleware forreconﬁgurable,embedded control applications,”in Intelligent Control (ISIC),2010IEEE International Symposium on,Sept2010,pp.2385–2390.[8]P.Royo,J.Lpez et al.,“Service abstraction layer for uavﬂexibleapplication development,”in Proceedings of the46th AIAA Aerospace Sciences Meeting and Exhibit.Reno,Nevada(USA):AIAA,Jan2008.[9]G.Pardo-Castellote,“Omg data-distribution service:Architecturaloverview,”in Proceedings of the2003IEEE Conference on Military Communications-Volume I,COM’03.Washington,DC,USA: IEEE Computer Society,2003,pp.242–247.[10]M.Tortonesi, C.Stefanelli et al.,“Multiple-uav coordination andcommunications in tactical edge networks,”Communications Magazine, IEEE,vol.50,no.10,pp.48–55,October2012.[11] E.Santamaria,P.Royo et al.,“Increasing uav capabilities throughautopilot andﬂight plan abstraction,”in Digital Avionics Systems Confer-ence,2007.DASC’07.IEEE/AIAA26th,Oct2007,pp.5.B.5–1–5.B.5–10.[12]M.Henning,“A new approach to object-oriented middleware,”IEEEInternet Computing,vol.8,no.1,pp.66–75,2004.[13]G.Montenegro,N.Kushalnagar et al.,“RFC4944–transmission ofIPv6packets over IEEE802.15.4networks,”IETF RFC.[14]C Language Mapping Speciﬁcation,Object Management Group,June1999.。

IceGrid应用配置手册

IceGrid应用配置手册V 2.1中诚信资讯科技有限公司目录1.概述 (3)1.1 配置目标 (3)1.2 实验环境 (3)1.3 局限 (3)2.配置过程 (3)2.1 服务器端配置 (3)2.1.1 主注册服务配置 (5)2.1.2 从注册服务配置 (7)2.1.3 应用部署配置 (10)2.1.4 节点配置 (13)2.2客户端配置 (14)3.结果验证 (14)3.1 程序方式 (14)3.2 工具方式 (14)4.高级应用配置 (20)4.1 集成IceBox (20)4.1.1 IceBox服务程序编写 (20)4.1.2 IceGrid集成IceBox服务 (21)4.1.3 测试验证 (25)4.2 集成IcePatch2 (27)1.概述1.1 配置目标本文档是描述Ice中间件中的IceGrid服务的应用配置，通过使用IceGrid服务来实现：1.服务器端服务分布式部署。

2.服务器端服务按需激活。

3.服务器端服务多节点负载均衡。

4.注册服务主/从热备（Master/Slaves）5.集成IceBox服务1.2 实验环境1.硬件：hp服务器，3台2.操作环境：Red Hat 53.服务器程序：ServerApp.jar4.说明：实际应用中，服务器节点可任意扩充、操作系统可被更换、服务器程序可用实际项目的服务程序替换，本文档所描述的配置方式具有通用性，适用但不局限于当前实验环境。

1.3 局限本文档不详细描述IceGrid服务的运行机制和实现原理，不详细介绍服务器端和客户端程序的实现，主要描述IceGrid服务应用的配置步骤、主要配置项及验证配置结果等。

2.配置过程2.1 服务器端配置配置步骤：1.创建主注册服务（Master）的配置文件config_master.grid，文件名称可以任意2.创建从注册服务（Slave）的配置文件 config_slave.grid，文件名称可以任意3.创建各节点服务的配置文件config.node，文件名称可以任意4.创建分布式应用配置文件app.xml，文件名称可以任意，但格式最好定义成xml5.运行Ice提供的工具，启动我们的分布式应用，主要有如下两个工具：icegridnode和icegridadmin。

ICE中间件技术详细教程

ICE中间件技术及其应用研究

Ice中间件研究

ICE中间件研究笔记2

面向对象的分布式中间件ICE

ICE

一种可用于分布式作战指控系统仿真的新中间件——ICE

国家能源ice操作手册

ICE中间件技术详细教程

ICE系列培训(三)

Ice中间件

ICE中间件

ICE简单介绍及使用示例

基于ICE的安全中间件的研究与实现

最新ICE网络编程利用ICE通信中间件构建分布式应用程序开发框架PPT课件

ICE开发实例指南

Embedded Middleware Solution ICE分布式中间件教程

IceGrid应用配置手册