Ice3.4.2技术手册：Slice语言与多语言应用开发

5星 · 超过95%的资源需积分: 15 177 浏览量更新于2024-07-26 收藏 4.8MB PDF 举报

"ice manual 3.4.2 - 英文版，涵盖了Ice架构、术语、Slice语言、编程语言映射、客户端与服务器结构、Ice协议概述、Ice服务、架构优势以及各种编程语言（C++、Java、C#、Visual Basic、Objective-C、Python、Ruby、PHP）下的Hello World应用示例，还包括Slice语言的编译、源文件、词法规则、模块、基础类型和用户自定义类型等详细内容。" 《Ice手册3.4.2》是ZeroC公司版权所有的一份技术文档，专注于介绍Ice框架的相关知识。Ice是一种分布式计算框架，提供了跨平台的通信机制，使得不同编程语言之间能够进行高效的数据交换和远程方法调用。 1. Ice概述 - Ice架构：介绍了Ice的基础结构，包括其组件、通信方式以及如何在分布式系统中工作。 - 术语：定义了诸如“Slice”、“客户端”、“服务器”等核心概念。 - Slice（Ice的规范语言）：Slice是用于定义接口和数据类型的高级语言，是构建Ice应用的基础。 - 语言映射：Ice支持多种编程语言，如C++、Java等，并详细解释了如何将Slice映射到这些语言中。 - 客户端和服务器结构：描述了客户端如何与服务器进行交互，以及通信协议的结构。 - Ice协议概述：简述了Ice协议的工作原理和数据传输格式。 2. Ice服务 - Ice服务提供了管理和控制分布式系统的功能，如定位服务、监控服务等，增强了Ice框架的可扩展性和管理性。 3. 架构优势 - 讨论了Ice在分布式系统设计中的优点，如高效率、安全性、可移植性等。 4. Hello World应用 - 提供了使用不同编程语言（C++、Java、C#、Visual Basic、Objective-C、Python、Ruby、PHP）编写简单的Ice应用的步骤，帮助开发者快速入门。 5. The Slice Language - Slice编译：说明了如何将Slice源代码转换为目标语言的代码。 - Slice源文件：讨论了Slice源文件的组织和结构。 - 词法规则：详细规定了Slice语言的语法和符号。 - 模块： Slice中的模块系统，允许组织和导入不同的接口和数据类型。 - 基础类型：包括基本的数据类型，如整型、浮点型、字符串等。 - 用户自定义类型：涵盖了枚举、结构、序列、字典、常量和字面量的定义和使用方法。《Ice手册3.4.2》是开发者学习和使用Ice框架的重要参考资料，无论你是初学者还是经验丰富的开发者，都能从中找到你需要的信息。

Ice 3.4.2 Documentation

Any object of the object adapter can be accessed using such a proxy, regardless of whether that object is also a well-known object.

Notice that an indirect proxy contains no addressing information. To determine the correct server, the client-side run time passes the proxy

information to a . In turn, the location service uses the object identity or the object adapter identifier as the key in a lookuplocation service

table that contains the address of the server and returns the current server address to the client. The client-side run time now knows how to

contact the server and dispatches the client request as usual.

The entire process is similar to the mapping from Internet domain names to IP address by the Domain Name Service (DNS): when we use a

domain name, such as , to look up a web page, the host name is first resolved to an IP address behind the scenes and,www.zeroc.com

once the correct IP address is known, the IP address is used to connect to the server. With Ice, the mapping is from an object identity or

object adapter identifier to a protocol-address pair, but otherwise very similar. The client-side run time knows how to contact the location

service via configuration (just as web browsers know which DNS server to use via configuration).

Direct Versus Indirect Binding

The process of resolving the information in a proxy to protocol-address pair is known as . Not surprisingly, is used forbinding direct binding

direct proxies, and is used for indirect proxies.indirect binding

The main advantage of indirect binding is that it allows us to move servers around (that is, change their address) without invalidating existing

proxies that are held by clients. In other words, direct proxies avoid the extra lookup to locate the server but no longer work if a server is

moved to a different machine. On the other hand, indirect proxies continue to work even if we move (or ) a server.migrate

Fixed Proxies

A is a proxy that is bound to a particular connection: instead of containing addressing information or an adapter name, the proxyfixed proxy

contains a connection handle. The connection handle stays valid only for as long as the connection stays open so, once the connection is

closed, the proxy no longer works (and will never work again). Fixed proxies cannot be marshaled, that is, they cannot be passed as

parameters on operation invocations. Fixed proxies are used to allow , so a server can make callbacks to a clientbidirectional communication

without having to open a new connection.

Routed Proxies

A is a proxy that forwards all invocations to a specific target object, instead of sending invocations directly to the actual target.routed proxy

Routed proxies are useful for implementing services such as , which enables clients to communicate with servers that are behind aGlacier2

firewall.

Replication

In Ice, involves making object adapters (and their objects) available at multiple addresses. The goal of replication is usually toreplication

provide redundancy by running the same server on several computers. If one of the computers should happen to fail, a server still remains

available on the others.

The use of replication implies that applications are designed for it. In particular, it means a client can access an object via one address and

obtain the same result as from any other address. Either these objects are stateless, or their implementations are designed to synchronize

with a database (or each other) in order to maintain a consistent view of each object's state.

Ice supports a limited form of replication when a proxy specifies multiple addresses for an object. The Ice run time selects one of the

addresses at random for its and tries all of them in the case of a failure. For example, consider this proxy:initial connection attempt

SimplePrinter:tcp -h server1 -p 10001:tcp -h server2 -p 10002

The proxy states that the object with identity is available using TCP at two addresses, one on the host andSimplePrinter server1

another on the host . The burden falls to users or system administrators to ensure that the servers are actually running on theseserver2

computers at the specified ports.

Replica Groups

In addition to the proxy-based replication described above, Ice supports a more useful form of replication known as thatreplica groups

requires the use of a .location service

A replica group has a unique identifier and consists of any number of object adapters. An object adapter may be a member of at most one

replica group; such an adapter is considered to be a .replicated object adapter

After a replica group has been established, its identifier can be used in an indirect proxy in place of an adapter identifier. For example, a

replica group identified as can be used in a proxy as shown below:PrinterAdapters

Ice 3.4.2 Documentation

SimplePrinter@PrinterAdapters

The replica group is treated by the location service as a "virtual object adapter." The behavior of the location service when resolving an

indirect proxy containing a replica group id is an implementation detail. For example, the location service could decide to return the

addresses of all object adapters in the group, in which case the client's Ice run time would select one of the addresses at random using the

limited form of replication discussed earlier. Another possibility is for the location service to return only one address, which it decided upon

using some heuristic.

Regardless of the way in which a location service resolves a replica group, the key benefit is indirection: the location service as a middleman

can add more intelligence to the binding process.

Servants

As we mentioned, an is a conceptual entity that has a type, identity, and addressing information. However, client requestsIce Object

ultimately must end up with a concrete server-side processing entity that can provide the behavior for an operation invocation. To put this

differently, a client request must ultimately end up executing code inside the server, with that code written in a specific programming

language and executing on a specific processor.

The server-side artifact that provides behavior for operation invocations is known as a . A servant provides substance for (or servant

) one or more Ice objects. In practice, a servant is simply an instance of a class that is written by the server developer and that isincarnates

registered with the server-side run time as the servant for one or more Ice objects. Methods on the class correspond to the operations on the

Ice object's interface and provide the behavior for the operations.

A single servant can incarnate a single Ice object at a time or several Ice objects simultaneously. If the former, the identity of the Ice object

incarnated by the servant is implicit in the servant. If the latter, the servant is provided the identity of the Ice object with each request, so it

can decide which object to incarnate for the duration of the request.

Conversely, a single Ice object can have multiple servants. For example, we might choose to create a proxy for an Ice object with two

different addresses for different machines. In that case, we will have two servers, with each server containing a servant for the same Ice

object. When a client invokes an operation on such an Ice object, the client-side run time sends the request to exactly one server. In other

words, multiple servants for a single Ice object allow you to build redundant systems: the client-side run time attempts to send the request to

one server and, if that attempt fails, sends the request to the second server. An error is reported back to the client-side application code only

if that second attempt also fails.

At-Most-Once Semantics

Ice requests have semantics: the Ice run time does its best to deliver a request to the correct destination and, depending onat-most-once

the exact circumstances, may retry a failed request. Ice guarantees that it will either deliver the request, or, if it cannot deliver the request,

inform the client with an appropriate exception; under no circumstances is a request delivered twice, that is, retries are attempted only if it is

known that a previous attempt definitely failed.

One exception to this rule are datagram invocations over UDP transports. For these, duplicated UDP packets can lead to a

violation of at-most-once semantics.

At-most-once semantics are important because they guarantee that operations that are not can be used safely. An idempotentidempotent

operation is an operation that, if executed twice, has the same effect as if executed once. For example, is an idempotent operation:x = 1;

if we execute the operation twice, the end result is the same as if we had executed it once. On the other hand, is not idempotent: if wex++;

execute the operation twice, the end result is not the same as if we had executed it once.

Without at-most-once semantics, we can build distributed systems that are more robust in the presence of network failures. However,

realistic systems require non-idempotent operations, so at-most-once semantics are a necessity, even though they make the system less

robust in the presence of network failures. Ice permits you to mark individual operations as idempotent. For such operations, the Ice run time

uses a more aggressive error recovery mechanism than for non-idempotent operations.

Synchronous Method Invocation

By default, the request dispatch model used by Ice is a synchronous remote procedure call: an operation invocation behaves like a local

procedure call, that is, the client thread is suspended for the duration of the call and resumes when the call completes (and all its results are

available).

Asynchronous Method Invocation

Ice also supports : clients can invoke operations , that is, the client uses a proxy asasynchronous method invocation (AMI) asynchronously

Ice 3.4.2 Documentation

usual to invoke an operation but, in addition to passing the normal parameters, also passes a and the client invocationcallback object

returns immediately. Once the operation completes, the client-side run time invokes a method on the callback object passed initially, passing

the results of the operation to the callback object (or, in case of failure, passing exception information).

The server cannot distinguish an asynchronous invocation from a synchronous one — either way, the server simply sees that a client has

invoked an operation on an object.

Asynchronous Method Dispatch

Asynchronous method dispatch (AMD) is the server-side equivalent of AMI. For synchronous dispatch (the default), the server-side run time

up-calls into the application code in the server in response to an operation invocation. While the operation is executing (or sleeping, for

example, because it is waiting for data), a thread of execution is tied up in the server; that thread is released only when the operation

completes.

With asynchronous method dispatch, the server-side application code is informed of the arrival of an operation invocation. However, instead

of being forced to process the request immediately, the server-side application can choose to delay processing of the request and, in doing

so, releases the execution thread for the request. The server-side application code is now free to do whatever it likes. Eventually, once the

results of the operation are available, the server-side application code makes an API call to inform the server-side Ice run time that a request

that was dispatched previously is now complete; at that point, the results of the operation are returned to the client.

Asynchronous method dispatch is useful if, for example, a server offers operations that block clients for an extended period of time. For

example, the server may have an object with a operation that returns data from an external, asynchronous data source and that blocksget

clients until the data becomes available. With synchronous dispatch, each client waiting for data to arrive ties up an execution thread in the

server. Clearly, this approach does not scale beyond a few dozen clients. With asynchronous dispatch, hundreds or thousands of clients can

be blocked in the same operation invocation without tying up any threads in the server.

Another way to use asynchronous method dispatch is to complete an operation, so the results of the operation are returned to the client, but

to keep the execution thread of the operation beyond the duration of the operation invocation. This allows you to continue processing after

results have been returned to the client, for example, to perform cleanup or write updates to persistent storage.

Synchronous and asynchronous method dispatch are transparent to the client, that is, the client cannot tell whether a server chose to

process a request synchronously or asynchronously.

Oneway Method Invocation

Clients can invoke an operation as a operation. A oneway invocation has "best effort" semantics. For a oneway invocation, theoneway

client-side run time hands the invocation to the local transport, and the invocation completes on the client side as soon as the local transport

has buffered the invocation. The actual invocation is then sent asynchronously by the operating system. The server does not reply to oneway

invocations, that is, traffic flows only from client to server, but not vice versa.

Oneway invocations are unreliable. For example, the target object may not exist, in which case the invocation is simply lost. Similarly, the

operation may be dispatched to a servant in the server, but the operation may fail (for example, because parameter values are invalid); if so,

the client receives no notification that something has gone wrong.

Oneway invocations are possible only on that do not have a return value, do not have out-parameters, and do not throw useroperations

exceptions.

To the application code on the server-side, oneway invocations are transparent, that is, there is no way to distinguish a twoway invocation

from a oneway invocation.

Oneway invocations are available only if the target object offers a stream-oriented transport, such as TCP/IP or SSL.

Note that, even though oneway operations are sent over a stream-oriented transport, they may be processed out of order in the server. This

can happen because each invocation may be dispatched in its own thread: even though the invocations are in the order in which theinitiated

invocations arrive at the server, this does not mean that they will be in that order — the vagaries of thread scheduling can result inprocessed

a oneway invocation completing before other oneway invocations that were received earlier.

Batched Oneway Method Invocation

Each oneway invocation sends a separate message to the server. For a series of short messages, the overhead of doing so is considerable:

the client- and server-side run time each must switch between user mode and kernel mode for each message and, at the networking level,

each message incurs the overheads of flow-control and acknowledgement.

Batched oneway invocations allow you to send a series of oneway invocations as a single message: every time you invoke a batched

oneway operation, the invocation is buffered in the client-side run time. Once you have accumulated all the oneway invocations you want to

send, you make a separate API call to send all the invocations at once. The client-side run time then sends all of the buffered invocations in

a single message, and the server receives all of the invocations in a single message. This avoids the overhead of repeatedly trapping into

the kernel for both client and server, and is much easier on the network between them because one large message can be transmitted more

efficiently than many small ones.

Ice 3.4.2 Documentation

The individual invocations in a batched oneway message are dispatched by a single thread in the order in which they were placed into the

batch. This guarantees that the individual operations in a batched oneway message are processed in order in the server.

Batched oneway invocations are particularly useful for messaging services, such as , and for fine-grained interfaces that offer IceStorm set

operations for small attributes.

Datagram Invocations

Datagram invocations have "best effort" semantics similar to oneway invocations. However, datagram invocations require the object to offer

UDP as a transport (whereas oneway invocations require TCP/IP).

Like a oneway invocation, a datagram invocation can be made only if the operation does not have a return value, out-parameters, or user

exceptions. A datagram invocation uses UDP to invoke the operation. The operation returns as soon as the local UDP stack has accepted

the message; the actual operation invocation is sent asynchronously by the network stack behind the scenes.

Datagrams, like oneway invocations, are unreliable: the target object may not exist in the server, the server may not be running, or the

operation may be invoked in the server but fail due to invalid parameters sent by the client. As for oneway invocations, the client receives no

notification of such errors.

However, unlike oneway invocations, datagram invocations have a number of additional error scenarios:

Individual invocations may simply be lost in the network.

This is due to the unreliable delivery of UDP packets. For example, if you invoke three operations in sequence, the middle invocation

may be lost. (The same thing cannot happen for oneway invocations — because they are delivered over a connection-oriented

transport, individual invocations cannot be lost.)

Individual invocations may arrive out of order.

Again, this is due to the nature of UDP datagrams. Because each invocation is sent as a separate datagram, and individual

datagrams can take different paths through the network, it can happen that invocations arrive in an order that differs from the order

in which they were sent.

Datagram invocations are well suited for small messages on LANs, where the likelihood of loss is small. They are also suited to situations in

which low latency is more important than reliability, such as for fast, interactive internet applications. Finally, datagram invocations can be

used to multicast messages to multiple servers simultaneously.

Batched Datagram Invocations

As for batched oneway invocations, allow you to accumulate a number of invocations in a buffer and thenbatched datagram invocations

send the entire buffer as a single datagram by making an API call to flush the buffer. Batched datagrams reduce the overhead of repeated

system calls and allow the underlying network to operate more efficiently. However, batched datagram invocations are useful only for

batched messages whose total size does not substantially exceed the PDU limit of the network: if the size of a batched datagram gets too

large, UDP fragmentation makes it more likely that one or more fragments are lost, which results in the loss of the entire batched message.

However, you are guaranteed that either all invocations in a batch will be delivered, or none will be delivered. It is impossible for individual

invocations within a batch to be lost.

Batched datagrams use a single thread in the server to dispatch the individual invocations in a batch. This guarantees that the invocations

are made in the order in which they were queued — invocations cannot appear to be reordered in the server.

Run-Time Exceptions

Any operation invocation can raise a . Run-time exceptions are pre-defined by the Ice run time and cover common errorrun-time exception

conditions, such as connection failure, connection timeout, or resource allocation failure. Run-time exceptions are presented to the

application as native exceptions and so integrate neatly with the native exception handling capabilities of languages that support exception

handling.

User Exceptions

A server indicates application-specific error conditions by raising to clients. User exceptions can carry an arbitrary amount ofuser exceptions

complex data and can be arranged into inheritance hierarchies, which makes it easy for clients to handle categories of errors generically, by

catching an exception that is further up the inheritance hierarchy. Like run-time exceptions, user exceptions map to native exceptions.

Properties

Much of the Ice run time is configurable via . Properties are name-value pairs, such as .properties Ice.Default.Protocol=tcp

Properties are typically stored in text files and parsed by the Ice run time to configure various options, such as the thread pool size, the level

of tracing, and various other configuration parameters.

剩余1766页未读，继续阅读

kevinlynx

粉丝: 59
资源: 7

Ice3.4.2技术手册：Slice语言与多语言应用开发

Ice-3.4.2安装包

Ice-3.4.2_Manual

Ice-3.4.2-rhel5-i386-rpm.tar.gz

Ice-3.4.2.msi-windows-ICE-3.4.2

Ice-3.4.2.msi

zeroc win ice-3.4.2.msi

zeroc ice 3.4.2 source demo

Ice 3.4.2 Third Party Packages readme

Redhat 5d的ice3.4.2版本

Ice3.4.2：现代分布式应用构建工具

最新资源