ICE学报第三期资源-CSDN文库

4星 · 超过85%的资源需积分: 9 92 浏览量 2011-11-12 09:25:11 上传评论收藏 918KB PDF 举报

Issue Number 3, June 2005 An Introduction to IceStorm .......................................2 Interpreted Ice: Distributed Application Development on Steroids...8 The Grim Reaper: Making Objects Meet Their Maker...................13 FAQ Corner ........................................................18 ### ICE 学报第三期知识点梳理与解析 #### 一、Introduction to IceStorm **背景介绍：** 在2005年6月发行的《ICE 学报》第三期中，第一篇文章介绍了IceStorm，这是一篇旨在帮助读者理解IceStorm的基本概念和应用场景的文章。 **主要内容概述：** IceStorm作为Ice框架的一部分，提供了高级功能，尤其是对于分布式应用中的发布-订阅模式的支持。该部分首先解释了为何选择IceStorm以及其相对于自定义解决方案的优势。接下来，通过具体的案例分析来展示IceStorm如何简化开发流程，并提供可靠且高效的通信机制。 **知识点提炼：** 1. **Ice框架简介**：Ice是一个成熟的中间件平台，用于构建可扩展且高性能的分布式应用程序。 2. **发布-订阅模式**：一种消息传递模型，在此模型中，发送者不会将消息直接发送给特定接收者，而是将它们发布到一个主题上，而订阅者则根据兴趣订阅这些主题。 3. **IceStorm特点**： - **高级抽象层**：提供了一个高级抽象层，使开发者可以专注于业务逻辑而不是底层通信细节。 - **跨平台兼容性**：支持多种操作系统和编程语言。 - **性能优化**：通过内置的优化措施提高通信效率，减少带宽消耗。 4. **成本效益分析**：自定义开发中间件通常需要大量的人力物力投入，而IceStorm已经经过充分测试和优化，可以大大降低项目成本。 #### 二、Interpreted Ice: Distributed Application Development on Steroids **背景介绍：** 第二篇文章探讨了Interpreted Ice的概念，这是一种基于Ice框架的高级开发工具，旨在进一步提高分布式应用程序的开发效率。 **主要内容概述：** 本文主要讨论了Interpreted Ice如何加速分布式应用程序的开发过程，特别是在代码编写、调试和部署阶段。它通过提供一系列自动化工具和服务，使得开发人员能够更加专注于业务逻辑而非基础设施搭建。 **知识点提炼：** 1. **Interpreted Ice概述**：Interpreted Ice是一种增强型开发环境，它在原有的Ice框架基础上添加了更多高级特性，如动态编译、即时运行等。 2. **动态编译技术**：Interpreted Ice支持动态编译，即开发者可以在不重新编译整个应用程序的情况下进行更改并立即查看结果。 3. **即时运行**：允许开发人员快速启动和运行分布式应用程序实例，大大减少了等待时间。 4. **集成开发环境（IDE）支持**：提供了一系列集成开发环境的插件，使得开发过程更加高效。 #### 三、The Grim Reaper: Making Objects Meet Their Maker **背景介绍：** 第三篇文章讨论了对象生命周期管理的问题，特别是如何处理不再需要的对象。 **主要内容概述：** 本文主要介绍了对象生命周期管理和内存回收的概念。它讨论了在分布式环境中，如何有效地管理和释放不再使用的对象资源，以避免内存泄漏和其他潜在问题。 **知识点提炼：** 1. **对象生命周期管理**：包括创建、使用和销毁对象的过程。 2. **内存回收机制**：自动管理对象的生命周期，当对象不再被引用时，自动释放其占用的内存。 3. **分布式环境下的挑战**：在分布式系统中，由于网络延迟等因素的影响，对象生命周期管理变得更加复杂。 4. **Grim Reaper的作用**：一种机制或服务，用于跟踪和管理分布式环境中的对象，确保及时回收不再使用的资源。 #### 四、FAQ Corner **背景介绍：** 最后一部分是常见问题解答，这里提供了一些关于Ice和IceStorm的常见问题及其解答。 **主要内容概述：** 这部分汇总了来自社区的一系列问题，包括但不限于Ice和IceStorm的安装配置、基本用法、故障排查等方面。 **知识点提炼：** 1. **安装与配置**：涵盖不同操作系统上的安装步骤和配置技巧。 2. **基础操作**：提供关于如何使用Ice和IceStorm的基础指南。 3. **故障排查**：列举了常见的错误信息及解决方法，帮助开发者快速定位问题。 4. **最佳实践**：分享了使用Ice和IceStorm的最佳实践建议，以提高程序的稳定性和性能。《ICE 学报》第三期涵盖了从基础概念到高级应用等多个层面的内容，为读者提供了全面深入的了解Ice框架的机会。无论是初学者还是有经验的开发人员，都可以从中受益匪浅。

资源推荐

资源详情

资源评论

Connections

ZeroC’s Newsletter for the Ice community

Page 1 Issue 3, June 2005

Connections

ZeroC’s Newsletter for the Ice Community

Issue Number 3, June 2005

Invent It or Use It?

I recently had a conversation with a

prospective customer about an applica-

tion development project. The application

required publish–subscribe functional-

ity, but had no other unusual distribution

requirements. I was amazed when I learned

that the customer was seriously considering

implementing a complete publish–subscribe middleware layer for

this application, even though middleware was neither the focus of

the customer’s business, nor did the customer have any in-depth

experience in developing communications software. Unfortunately,

I see this sort of thinking a lot: the “not-invented-here” syndrome

is alive and well, often driven by the desire of engineers to work on

what they ﬁnd interesting, rather than build what is needed in order

to make a proﬁt.

Yes, building middleware can be rewarding and a lot of fun. At

least for a while—until reality sets in and you end up spending

weeks of effort porting to new platforms, working around bugs

in compilers and TCP/IP implementations, or hunting down that

pesky race condition that shows up only once every two weeks.

And you spend even more time improving performance, reducing

bandwidth consumption, creating portability libraries, and invent-

ing error handling strategies. I could go on in this vein for a long

time—sufﬁce it to say that many thousands of hours of work by

very experienced developers have gone into Ice in order to turn it

into a robust, reliable, portable, and high-performance product.

The chance that any in-house middleware development, es-

pecially when carried out by people with little experience in the

ﬁeld, will end up being cost-effective is very slim indeed. And

even slimmer is the chance that the result will end up performing

signiﬁcantly better than Ice. For our customer, after a closer look

at the requirements, IceStorm turned out to be a good solution, and

one that did not require inventing anything.

Which brings me to Matthew Newhook’s article in this issue…

Matthew shows you how you can use IceStorm for your own appli-

cations, and with surprisingly little effort. Please, give this a good

look—chances are that you will consider it time well spent. And,

trust me: developing your own middleware is a lot less rewarding

and fun than you might think!

Michi Henning

Chief Scientist

ZeroC, Inc.

Issue Features

An Introduction to IceStorm

In this installment of his multi-part article series, Matthew

Newhook shows you how to extend the chat room application to

support multiple chat rooms with the help of IceStorm.

Interpreted Ice

Ice and Python form a powerful combination for rapid prototyp-

ing, debugging, and maintenance. This article provides many

tips and tricks that you can use to make your development more

productive, regardless of whether your application is written in

Python or another language.

The Grim Reaper

Stateful interactions between client and server are a fact of life

and raise the problem of how to clean up server-side state in

case something goes wrong with the client. This article presents

a simple and effective way to get rid of stale objects in a server

without writing reams of code.

Contents

An Introduction to IceStorm ........................................... 2

Interpreted Ice: Distributed Application Development on

Steroids ........................................................................... 8

The Grim Reaper: Making Objects Meet Their Maker 13

FAQ Corner ................................................................... 18

Connections

ZeroC’s Newsletter for the Ice community

Page 2 Issue 3, June 2005

Page 3Issue 3, June 2005

Connections

ZeroC’s Newsletter for the Ice community

Connections

ZeroC’s Newsletter for the Ice community

Page 2 Issue 3, June 2005

Page 3Issue 3, June 2005

Connections

ZeroC’s Newsletter for the Ice community

An Introduction to IceStorm

Matthew Newhook, Senior Software Engineer

Introduction

The previous article focused on using advanced features of

Glacier2 to make the chat server more robust. This article discuss-

es how to add support for multiple chat rooms to the chat server

using IceStorm.

Interface Changes

The chat server we have developed up to this point is very limited.

An obvious extension to its functionality is to add support for

multiple chat rooms. First a review of the current ChatSession

interface:

// Slice

interface ChatCallback

{

void message(string data);

};

interface ChatSession

extends Glacier2::Session

{

void setCallback(ChatCallback* callback);

void say(string data);

};

From the perspective of a client, a ChatSession object has two

functions: it allows the client to send messages to a room, and it

informs the client when a message has arrived from a room via the

callback object. To extend this functionality to multiple rooms, we

could identify each chat room by a name and pass the room name

to the say and message operations, as follows:

// Slice

interface ChatCallback

{

void message(string room, string data);

};

interface ChatSession

extends Glacier2::Session

{

void setCallback(ChatCallback* callback);

void say(string room, string data);

};

This approach, while viable, isn’t very clean and is deﬁnitely

not object-oriented. It also lacks extensibility: as our application

evolves, we expect to add other room-speciﬁc data, such as a chat

room participant list.

A better approach is to use a separate interface that receives

state changes, but to make the identity of chat room implicit in the

instance of the interface:

// Slice

interface ChatRoomObserver

{

void message(string data);

};

This interface is identical to the ChatRoomCallback class in the

previous implementation but, by using separate instances of this

interface, one for each chatroom, the client can receive messages

from different rooms. Similarly, we need an interface that allows

the client to send a message to a speciﬁc room; again, we can do

this with the room implicitly identiﬁed by the instance:

// Slice

interface ChatRoomParticipant

{

void say(string data);

};

See Figure 1 for a class diagram. (The ChatRoomModel object in

the diagram is purely a server side-concept, and is not accessible to

the client.)

Figure 1: Class Diagram

































We also need a method to allow the client to join a chat room.

Where should this go? Access to all the server-side functionality is

provided by the session interface, so this seems like a logical place:

// Slice

interface ChatSession

extends Glacier2::Session

{

ChatRoomParticipant* join(string room);

};

This allows the user to join a chat room. However, the new inter-

faces require one ChatRoomObserver proxy per chat room, not

a single ChatRoomObserver for all chat rooms. The simplest

way to deal with this is to pass the ChatRoomObserver proxy

as an extra parameter to the join operation. We can remove the

setCallback operation that was formerly on ChatSession,

as well as the say operation (which has been replaced by

ChatRoomParticipant::say). This leaves the following:

AN INTRODUCTION TO ICESTORM

Page 3Issue 3, June 2005

Connections

ZeroC’s Newsletter for the Ice community

Page 3Issue 3, June 2005

Connections

ZeroC’s Newsletter for the Ice community

// Slice

interface ChatSession

extends Glacier2::Session

{

ChatRoomParticipant* join(string room,

ChatRoomObserver* observer);

};

Client-Side Support

Let’s run through the changes that are required in the client to sup-

port multiple chat rooms.

Firstly, we replace the ChatCallback implementation with the

ChatRoomObserver implementation. It is largely unchanged from

its previous version:

// C++

class ChatRoomObserverI : public ChatRoomObserver

{

public:

ChatRoomObserverI(const string& room) :

_room(room)

{

}

virtual void message(const string& data,

const Current&)

{

cout << _room << ": " << data << endl;

}

private:

const string _room;

};

Next, we need to have a way of keeping track of the chat rooms the

client has joined. We’ll add a new class called ChatRoomManager:

// C++

class ChatRoomManager

{

public:

ChatRoomParticipantPrx find(

const string& room) const;

void join(const string& roomName);

};

The class maintains a map of room names to

ChatRoomParticipant proxies.

map<string, ChatRoomParticipantPrx> _rooms;

The implementation of join then is as follows:

// C++

void ChatRoomManager::join(const string& roomName)

{

Identity id;

id.name = "observer." + roomName;

id.category = _category;

ChatRoomObserverPrx observer =

ChatRoomObserverPrx::uncheckedCast(

_adapter->add(

new ChatRoomObserverI(roomName),id));

ChatRoomParticipantPrx room = _session->join(

roomName, observer);

_rooms.insert(make_pair(roomName, room));

}

The object identity name is constructed from the name of the room.

(Recall that Glacier2 requires all client-side callback objects to use

a speciﬁc per-session category, as described in

Session Manage-

ment with Glacier2

in Issue 1 of

Connections

.) The remainder of

the client-side implementation is straightforward—see the source

code for this application in the Ice distribution.

Server-Side Support

The server-side needs to be modiﬁed to support the new interfaces

as well.

ChatSessionI Implementation

First, we’ll look at the implementation of ChatSessionI.

// C++

ChatRoomParticipantPrx ChatSessionI::join(

const string& room,

const ChatRoomObserverPrx& observer,

const Current& current)

{

Lock sync(*this);

Identity id;

id.category = "_" + _userId;

id.name = IceUtil::generateUUID();

ChatRoomParticipantPrx proxy =

ChatRoomParticipantPrx::uncheckedCast(

current.adapter->add(

new ChatRoomParticipantI(

room, _userId, observer), id));

_rooms.push_back(proxy);

return proxy;

}

AN INTRODUCTION TO ICESTORM

剩余17页未读，继续阅读

评论收藏

内容反馈

ttzzz123321

2012-11-29

都是英文的~~看的有点难啊

Falcon_soft

粉丝: 1
资源: 17

ICE 学报 第三期

ICE 学报 第一期

ICE 学报 第二期

ICE 学报 第五期

ICE 学报 第四期

zeroc ice教程 ice环境配置 Ice中文教程 C++ ICE java ICE ICE入门 ice基础教程 ice开发文档

ice教程和ice中文版手册

Ice-3.3.1 ICE

ICE第三方依赖库

ice.rar_ice matlab_ice.m matlab_matlab ice_matlab ice_matlab i

ice安装包 for windows.zip

Linux下安装ICE包

ICE框架 C++示例程序

zeroc ICE 3.3.1文档

Ice-3.4.2安装包

ICE系列培训教程

ice-3.6.3 eclipse ice通信demo

ice.fig.rar_ ice.fig_ice.fig_ice函数_matlab ice_matlab ice函数

ICE入门 文章集

ZeroC Ice 3.7 手册

Ice-3.5.1.zip

ICE 的聊天demo 含有ICE的配置文档

ice中间件平台_中文教程

ICE中间件技术详细教程_ICE_中间件_

ice_3.7.0_linux版

Ice-3.1.1.pdf

ICE客户端实现代码

最新资源

ICE 学报第三期

ICE 学报第一期

ICE 学报第二期

ICE 学报第五期

ICE 学报第四期

ICE入门文章集