icechatdemo资源-CSDN文库

共13个文件

mht：9个

zip：3个

pdf：1个

chat

demo

3星 · 超过75%的资源需积分: 9 14 浏览量 2010-04-09 08:10:29 上传评论收藏 15.76MB RAR 举报

资源推荐

资源详情

资源评论

收起资源包目录

ICE chat demo.rar （13个子文件）

ICE chat demo

ZeroC - Chat Demo - C++ Clients.mht 44KB

ZeroC - Chat Demo - Firewalls.mht 150KB

ZeroC - Chat Demo - Graphical Clients.mht 52KB

ChatDemo-ThirdParty-Sources-1.2.1.zip 12.88MB

ZeroC - Chat Demo - Concepts.mht 217KB

ZeroC - The Ice Programming Model.mht 67KB

ZeroC - Chat Demo - Security.mht 132KB

ChatDemoGUI-Java-1.2.1.zip 1.76MB

ZeroC - Chat Demo - Slice Interfaces.mht 44KB

ZeroC - Chat Demo - Design.mht 107KB

ZeroC - Chat Demo - Sessions.mht 94KB

ChatDemo-1.2.1.zip 479KB

java-async.pdf 480KB

A New Asynchronous Method

Invocation API for Ice for Java

Michi Henning, Chief Scientist, ZeroC, Inc.

Introduction

Ice has had an API for asynchronous method invocation (AMI) since its inception. However, that API

is quite verbose and not all that easy to use, as well as inflexible. With the release of Ice 3.4, ZeroC

introduces a new API for asynchronous method invocation that does not suffer from these problems

and provides programmers with far more choice as to how they can structure their code. The new

API is available for Java, .NET, C++, and Python.

This article provides an overview of the new Java API and explains its most important features. (As

always, you should consult the Ice Manual for complete documentation.) Companion articles

describe the corresponding new APIs for .NET, C++, and Python.

The old API is still available and it is possible to use both the new and the old API in the same

program. This allows you to gradually migrate code away from the old API without having to change

all your code at once. For new code, we strongly recommend that you use the new API. (The old API

is deprecated and will eventually be removed entirely.)

Contents

Introduction ...................................................................................................................................... 1

The Problems of the Old API .............................................................................................................. 2

The New Approach ............................................................................................................................ 3

No Need for Metadata................................................................................................................... 4

Basic Asynchronous Invocations .................................................................................................... 4

Polling and Waiting for Call Completion ......................................................................................... 5

Completion Callbacks..................................................................................................................... 7

Using a Single Callback Method for Many Operations .................................................................... 9

Passing State from the begin_ Method to the end_ Method ................................................... 10

Type-Safe Callbacks ..................................................................................................................... 11

Flow Control ................................................................................................................................ 12

Oneway Invocations .................................................................................................................... 13

Asynchronous Invocation of Operations on Ice.Object .......................................................... 13

Concurrency ................................................................................................................................ 13

Summary ......................................................................................................................................... 14

The Problems of the Old API

Suppose you have the following Slice definition:

// Slice

module Demo

{

["ami"]

interface Employees

{

string getName(int number);

};

With the old API, to allow you to invoke getName asynchronously, slice 2java generates the

following proxy methods:

public interface EmployeesPrx extends Ice.ObjectPrx

{

public boolean getName_async(AMI_Employees_getName __cb,

int number);

public boolean getName_async(

AMI_Employees_getName __cb,

int number,

java.util.Map<String, String> __ctx);

}

Note that the getName_async method is overloaded so you can add a per-invocation context

instead of sending the default context. (The new API also permits you to supply a context, but we do

not discuss contexts further in this article. Please see the Ice Manual for a full description.)

To call getName asynchronously, you must implement a class that derives from the

Demo.AMI_Employees_getName class that is generated by slice2java. Your derived class

must implement two methods, ice_response and ice_exception. (If an operation raises user

exceptions, you need a third method to that is called for user exceptions.) These methods are the

callback methods that are called by the Ice run time to inform you when an asynchronous call of

getName completes. For example:

private class AMI_Employees_getNameI

extends Demo.AMI_Employees_getName

{

public void ice_response(String name)

{

System.out.println("Name is: " + name);

}

public void ice_exception(Ice.LocalException ex)

{

System.out.println("Exception is: " + ex);

}

When you call getName asynchronously, you must supply an instance of this callback class, for

example:

EmployeesPrx e = ...;

AMI_Employees_getNameI cb = new AMI_Employees_getNameI();

e.getName_async(cb, 99);

This invokes the getName operation in the server without blocking the caller; some time later, once

the call completes, the Ice run time calls ice_response on the callback instance (if the call

succeeded) or ice_exception (if the call failed).

This is fine as far as it goes. However, there are a number of disadvantages with this API:

You must implement a separate class for every operation you call asynchronously.

The class must implement two methods with the names ice_response and

ice_exception.

There is no way to poll for completion of an asynchronous call.

There is no simple way to block until a particular call completes. (To achieve this, you have to

use a monitor that is signaled from the ice_response and ice_exception callbacks.)

The base class from which you derive your callback class stores the state of the asynchronous

call. This means that you cannot use the same callback instance for multiple concurrent calls.

(You can reuse a callback instance, but only once the previous invocation using that instance is

complete.)

The above points boil down to two major points: verbosity and inflexibility. The verbosity is not

immediately obvious, but becomes clear when you consider an application of more realistic size. For

example, if you have eight interfaces with six operations each (all of which you want to call

asynchronously), you must implement 48 classes and 96 methods. This is tedious, to say the least.

The inflexibility of the API also is a concern: you cannot poll for call completion and you cannot easily

block until a particular call is complete. The only way to get the results of an invocation is an

asynchronous callback. Moreover, there is no easy way to share code on a call-by-call basis. For

example, if in a particular section of your application, you want to treat a particular error condition

in a different way, you must write a new callback class for every operation that implements the

different error handling (or, alternatively, pass additional state into your callback instance so it can

select inside the ice_exception callback which behavior is needed).

In summary, the old API is as rigid as steel: there is one and only one way of doing things. This is

inconvenient if, for example, you have many simple get/set operations that substantially perform

the same actions when they complete, or if you would like to block until a particular invocation or

group of invocations is complete.

The New Approach

The new asynchronous API eliminates both the verbosity and inflexibility of the old API. Not only can

you do more things with the new API, but you can also do so with less code. In turn, this reduces

development time and maintenance effort.

The following sections provide an overview of the capabilities of the new API and show some

examples of how and why you might want to use a particular API feature.

No Need for Metadata

Here is our simple Employees interface once more:

// Slice

module Demo

{

interface Employees

{

string getName(int number);

};

Note that the ["ami"] metadata directive is absent. This is because the new asynchronous API is

always generated by slice2java, so no separate metadata directive is necessary. (If you do add

the ["ami"] directive, slice2java generates both the old and the new API; you can use both

APIs in the same program.)

Basic Asynchronous Invocations

The asynchronous proxy methods look as follows:

public interface EmployeesPrx extends Ice.ObjectPrx

{

public Ice.AsyncResult begin_getName(int number);

public String end_getName(Ice.AsyncResult __result);

}

Note that the getName operation now has a begin_ method and an end_ method. The

begin_getName method starts the asynchronous call and is guaranteed not to block the caller.

The end_getName method is used to collect the result of the invocation. If, at the time the client

calls end_getName, the operation is not complete yet, end_getName blocks the calling thread

until the call is complete. On the other hand, if the call completed earlier, some time after the client

called begin_getName but before it calls end_getName, end_getName completes

immediately.

The API generated by slice2java has several overloads of the begin_ method (of which we

only show the first one in the preceding example); the other overloads deal with contexts (see the

Ice Manual for details) as well as callbacks, which we will discuss shortly.

Here is an example of how a client can make such an asynchronous invocation:

EmployeesPrx e = ...;

Ice.AsyncResult r = e.begin_getName(99); // Does not block

// Continue to do other things here...

String name = e.end_getName(r); // Blocks until result is available

Now, at first glance, this does not look particularly useful: if you call end_getName immediately

after calling begin_getName, you get the same effect as having used an ordinary synchronous

call.

However, because begin_getName is guaranteed not to block, you can continue to do other

things. This is useful if you know that a particular operation invocation may take some time, and

there are other tasks you can perform before you need to collect the result of the invocation. That

way, you get increased concurrency between client and server without having to use separate

threads.

The begin_ method has one parameter for each in-parameter of the corresponding Slice

operation. Similarly, the end_ method has one parameter for each out-parameter of the

corresponding Slice operation. (If a Slice operation has a return value, the end_ method returns that

value in the same way that a synchronous invocation would.)

If an operation raises a user exception or Ice run-time exception, the exception is thrown by the

end_ method. (The begin_ method does not throw Ice exceptions other than

CommunicatorDestroyedException.)

Polling and Waiting for Call Completion

Note that the begin_ method returns an AsyncResult instance. This instance encapsulates the

state of the asynchronous call and allows you to learn something about the details of the call. You

must pass the AsyncResult you obtained from the begin_ method to the corresponding end_

method. The information in the AsyncResult allows the Ice run time to locate the reply from the

server and to call the appropriate unmarshaling code. (The unmarshaling of the reply is done by the

end_ method, that is, the Ice run time stores the reply from the server until the end_ method is

called, and the decoding of the reply is done by the end_ method.)

The AsyncResult class contains a few methods that allow you to check call progress and

completion:

public class AsyncResult

{

public final boolean sentSynchronously();

public final boolean isSent();

public final void waitForSent();

public final boolean isCompleted();

public final void waitForCompleted();

// ...

}

sentSynchronously reports whether the Ice run time was able to immediately pass the

invocation to the client’s local transport. The method returns true if the invocation was written to

the local transport immediately; otherwise, the method returns false, indicating that the Ice run time

queued the invocation for later transmission because the local transport could not accept it at the

time the begin_ method was called.

评论收藏

内容反馈

ToConnection

2013-06-25

谢谢，官网上的例子，不错
hhli

2014-09-08

还行，但是我觉得刚接触的别看这个例子，先把基础做好！！！

farbrausch

粉丝: 1
资源: 20

ice chat demo

最新资源

ice chat demo

Ice chat demo

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

ICE完整的DEMO

icechat--a free and open source irc client

ICEDemo C#版本

ice同步demo

ice demo ice是很好的网络通讯中间件

winform ICE异步demo

IceChat:IceChat IRC客户端

Demo_ice.zip_DEMO_Demo_ice_ICE_ICE demo_ice mysql

ICE通信Demo文档

ice包以及一个用ice做的demo

ice-3.6.3 eclipse ice通信demo

ICE异步调用Demo源码

ICE-demo2.tar.gz_ICE_linux ICE C++

ice-3.4.1-demos.zip

icedemo-android:安卓版 icedemo

Ice的安装步骤和运行demo

Ice双向通信Demo

微信小程序源码-合集6.rar

微信小程序源码-合集5.rar

微信小程序源码-合集4.rar

微信小程序源码-合集3.rar

微信小程序源码-合集2.rar

浏览器插件 Auto Refresh Plus 7.4.4 ctx

品优购项目 素材及代码

学生宿舍管理系统源码文件

全能电子地图下载器1.9.5完善版.zip

大学生网页设计大作业-5个网页设计制作作品自己任选

最新资源

品优购项目素材及代码