当前位置：文档库 › A Distributed Object Model for the Java System

A Distributed Object Model for the Java System

The following paper was originally published in the

Proceedings of the USENIX 1996

Conference on Object-Oriented Technologies

Toronto, Ontario, Canada, June 1996.

A Distributed Object Model for the Java System

Ann Wollrath, Roger Riggs, and Jim Waldo

Sun Microsystems, Inc.

For more information about USENIX Association contact:

1. Phone:510 528-8649

2. FAX:510 548-5738

3. Email:office@https://www.wendangku.net/doc/1d6889277.html,

4. WWW URL:https://www.wendangku.net/doc/1d6889277.html,

Abstract

We show a distributed object model for the Java?1 System [1,6] (hereafter referred to simply as “Java”) that retains as much of the semantics of the Java ob-ject model as possible, and only includes differences where they make sense for distributed objects. The distributed object system is simple, in that a) distribut-ed objects are easy to use and to implement, and b) the system itself is easily extensible and maintainable. We have designed such a model and implemented a system that supports remote method invocation (RMI) for distributed objects in Java. This system combines aspects of both the Modula-3 Network Objects system [3] and Spring’s subcontract [8] and includes some novel features.

To achieve its goal of seamless integration in the lan-guage, the system exploits the use of pickling [14] to transmit arguments and return values and also exploits unique features of Java in order to dynamically load stub code to clients2. The ?nal system will include distributed reference-counting garbage collection for distributed objects as well as lazy activation [11,16].

1 Introduction

Distributed systems require entities which reside in different address spaces, potentially on different ma-chines, to communicate. The Java? system (hereafter referred to simply as “Java”) provides a basic commu-nication mechanism, sockets [13]. While ?exible and suf?cient for general communication, the use of sock-ets requires the client and server using this medium to engage in some application-level protocol to encode and decode messages for exchange. Design of such protocols is cumbersome and can be error-prone.

1.Java and other Java-based names and logos are trade-

marks of Sun Microsystems, Inc., and refer to Sun’s fam-ily of Java-branded products and services.

2.Patent pending An alternative to sockets is Remote Procedure Call (RPC) [13]. RPC systems abstract the communication interface to the level of a procedure call. Thus, instead of application programmers having to deal directly with sockets, the programmer has the illusion of call-ing a local procedure when, in fact, the arguments of the call are packaged up and shipped off to the remote target of the call. Such RPC systems encode argu-ments and return values using some type of an exter-nal data representation (e.g., XDR).

RPC, however, does not translate well into distributed object systems where communication between pro-gram-level objects residing in different address spaces is needed. In order to match the semantics of object invocation, distributed object systems require remote method invocation or RMI. In such systems, the pro-grammer has the illusion of invoking a method on an object, when in fact the invocation may act on a re-mote object (one not resident in the caller’s address space).

In order to support distributed objects in Java, we have designed a remote method invocation system that is speci?cally tailored to operate in the Java environ-ment. Other RMI systems exist (such as CORBA) that can be adapted to handle Java objects, but these sys-tems fall short of seamless integration due to their in-ter-operability requirement with other languages. CORBA presumes a heterogeneous, multi-language environment and thus must have a language neutral object model. In contrast, the Java language’s RMI system assumes the homogeneous environment of the Java Virtual Machine, and the system can therefore follow the Java object model whenever possible.

We identify several important goals for supporting distributed objects in Java:

?support seamless remote invocation between Java

objects in different virtual machines;?integrate the distributed object model into the Java

language in a natural way while retaining most of Java’s object semantics;

A Distributed Object Model for the Java? System

Ann Wollrath, Roger Riggs, and Jim Waldo

JavaSoft

{ann.wollrath, roger.riggs, jim.waldo}@https://www.wendangku.net/doc/1d6889277.html,

?make differences between the distributed object

model and the local Java object model apparent;?minimize complexity seen by the clients that use

remote objects and the servers that implement

them;

?preserve the safety provided by the Java runtime

environment.

These goals fall under two main categories: the sim-plicity and naturalness of the model. It is most impor-tant that remote method invocation in Java be simple (easy to use) and natural (?t well in the language).

In addition, the RMI system should perform garbage collection of remote objects and should allow exten-sions such as server replication and the activation of persistent objects to service an invocation. These ex-tensions are transparent to the client and add minimal implementation requirements on the part of the serv-ers that use them. These additional features motivate our system-level goals. Thus, the system must sup-port:

?several invocation capabilities

?simple invocation (unicast)

?invocation to multicast groups (to enable server replication)

?extensibility to other invocation paradigms ?various reference semantics for remote objects ?live (or non-persistent) references to

remote objects

?persistent references to and lazy activation of remote objects

?the safe Java environment provided by security

managers and class loaders

?distributed garbage collection of active objects ?capability of supporting multiple transports

In this paper we will brie?y describe the Java object model, then introduce our distributed object model for Java. We will also describe the system architecture and relevant system interfaces. Finally, we discuss re-lated work and conclusions.

2 Java Object Model

Java is a strongly-typed object-oriented language with a C-style syntax. The language incorporates many ideas from languages such as Smalltalk [5], Modula-3 [10], Objective C [12] and C++ [4]. Java attempts to be simple and safe while presenting a rich set of fea-tures in the object-oriented domain.

Interfaces and Classes

One of the interesting features of Java is its separation of the notion of interface and class. Many object-ori-ented languages have the abstraction of “class” but provide no direct support (at the language level) for interfaces.

An interface, in Java, describes a set of methods for an object, but provides no implementation. A class, on the other hand, can describe as well as implement methods. A class may also include fields to hold data, but interfaces cannot. Thus, a class is the implementa-tion vehicle in Java; an interface provides a powerful abstraction that contains no implementation detail. Java allows subtyping of interfaces and classes by the use of extension. An interface may extend one or more interfaces; this capability is known as multiple-inherit-ance. Classes, however, are single-inheritance and may extend at most one other class.

While a class may extend at most one other class, it may implement any number of interfaces. A class that implements an interface provides implementations for all the methods described in that interface. If a class is de?ned to implement an interface, but does not pro-vide an implementation for a particular method of that interface, it must declare that method to be abstract.

A class containing abstract methods may not be in-stantiated.

An example of an arbitrary class de?nition in Java is as follows:

class Bar

extends Foo

implements Ping, Pong { ... }

where Bar is the class name,Foo is the name of the class being extended and Ping and Pong are the names of interfaces implemented by the class Bar.

Object Class Methods

All classes in Java extend the class Object, either im-plicitly or explicitly. The class Object has several methods which an extended class can override to have behavior speci?c to that class. These methods are:?equals — tests the argument for equality with the object

?hashCode — returns a hash code for the object ?toString— returns a string representing the object ?clone — returns a clone of the object

??nalize — called to allow cleanup when the object is garbage collected

These methods are integral to the semantics of objects in Java.

Method Invocation

Method invocation in Java has the following syntax:

result = object.method(arg1, arg2, ...); where:object is the entity which is being acted upon, method is the name of the method being called,argN is a parameter to the method, and result is the return value.

Method Parameters and Return Values

In Java, all parameters to and return values from a method are passed by-value. Only references to ob-jects exist in Java, so object references (not objects) are passed by value. Thus, a change to an object passed to a method will be visible to the caller of the method.

The type of an object passed polymorphically does not change the type of the underlying object.

3 Distributed Object Model

In our model, a remote object is one whose methods can be accessed from another address space, potential-ly on a different machine. An object of this type is de-scribed by a remote interface, which is an interface (in Java) that declares the methods of a remote object. Remote method invocation (or RMI) is the action of invoking a method (of a remote interface) on a remote object. Most importantly, a method invocation on a re-mote object has the same syntax as a method invoca-tion on a local object.

Clients of remote objects program to remote interfac-es, not to the implementation classes of those interfac-es. Since the failure modes of accessing remote objects are inherently different than the failure seman-tics of local objects, clients must deal with an addi-tional exception that can occur during any remote method invocation.

What follows is a brief comparison of the distributed object model and the Java object model. The similari-ties between the models are:

? a reference to a remote object can be passed as an argument or returned as a result in any method

invocation (local or remote);

? a remote object can be cast to any of the set of remote interfaces supported by the implementation using the built-in Java syntax for casting;?the built-in Java instanceof operator can be used to test the remote interfaces supported by a remote

object.

There are several basic differences between the dis-tributed object model and the Java object model:?clients of remote objects interact with remote interfaces, never with the implementation classes of those interfaces;?clients must handle an additional exception for

each remote method invocation;?parameter passing semantics are slightly different

in calls to remote objects;

?semantics of Object methods are de?ned to make

sense for remote objects.

Remote Interfaces

In order to implement a remote object, one must ?rst de?ne a remote interface for that object. A remote in-terface must extend (either directly or indirectly) a distinguished interface called java.rmi.Remote. This interface is completely abstract and has no methods. interface Remote {}

For example, the following code fragment de?nes a remote interface for a bank account that contains methods that deposit to the account, withdraw from the account, and get the account balance:

import java.rmi.*;

public interface BankAccount

extends Remote

{

public void deposit(float amount)

throws RemoteException;

public void withdraw(float amount)

throws OverdrawnException,

RemoteException;

public float balance()

throws RemoteException;

}

As shown above, each method declared in an interface for a remote object must include java.rmi.RemoteEx-ception in its throws clause. If RemoteException is thrown during a remote call, then some communica-tion failure happened during the call. Remote objects have very different failure semantics than local ob-jects. These failures cannot be hidden from the pro-grammer since they cannot be masked by the underlying system [15]. Therefore, we choose to ex-pose the additional exception RemoteException in all remote method calls, so that programmers can handle this failure appropriately.

Remote Implementations

There are two ways to implement a remote interface (such as BankAccount). The simplest implementation route is for the implementation class, e.g.,BankAc-ctImpl, to extend the class RemoteServer. We call this ?rst scheme remote implementation reuse. Figure 1 below is an illustration of the interface and class hier-

archies for remote interfaces and implementations in this scheme.

Figure 1. Reusing a remote implementation

The default constructor for RemoteServer takes care of making an implementation object remotely accessi-ble to clients by exporting the remote object imple-mentation to the RMI runtime. The class RemoteObject overrides methods inherited from Ob-ject to have semantics that make sense for remote ob-jects. We will discuss what the appropriate semantics for these methods are in the section on “Object Meth-od Semantics”.

In the second implementation scheme, called local im-plementation reuse, the implementation class for a re-mote object does not extend RemoteServer but may extend any other local implementation class as appro-priate. However, the implementation must explicitly export the object to make it remotely accessible.

Figure 2. Reusing a local implementation class

The “local implementation reuse” scheme (shown in Figure 2), while allowing the class to reuse existing implementation code, does require that the class deal with the details of making instances of that class re-motely accessible (by exporting the object to the RMI runtime). Such exporting is already taken care of in the RemoteServer constructor used in the ?rst scheme.

Implementations using the second scheme must also be responsible for their own Java Object semantics and therefore must rede?ne methods inherited from the class Object appropriately. These object methods are already taken care of in the implementation of Re-moteObject, used in the other scheme.

We deem the “remote implementation reuse” scheme more seamlessly integrated into the Java object model as well as requiring less implementation detail; so we will explain that implementation scheme in depth here. The other scheme, local implementation reuse, is included for implementation ?exibility if such is re-quired by the programmer.

Thus,BankAcctImpl, an implementation class of the remote interface BankAccount can be de?ned by ex-tending RemoteServer as follows and would imple-ment all the methods of BankAccount:

package myPackage;

import java.rmi.RemoteException;

import java.rmi.server.RemoteServer;

public class BankAcctImpl

extends RemoteServer

implements BankAccount

{

public void deposit(float amount)

throws RemoteException {...};

public void withdraw(float amount)

throws OverdrawnException,

RemoteException {...};

public float balance()

throws RemoteException {...};

}

A few additional notes about implementing remote in-terfaces are:

?An implementation class may implement any number of remote interfaces.

?An implementation class may extend any other implementation class of a remote interface.?Only those methods that appear in a remote interface (one that extends Remote either directly or indirectly) can be accessed remotely; thus non-remote methods in an implementation class can

only be accessed locally.

The server implementation scheme ?ts very well into the Java object model and the Java language. Remote Reference Types

In the distributed object model, clients interact with stub (surrogate) objects that have exactly the same set of remote interfaces de?ned by the remote object’s class; the stub class does not include the non-remote portions of the class hierarchy that constitutes the ob-ject’s type graph. This is because the stub class is gen-erated from the most re?ned implementation class that implements one or more remote interfaces. For exam-ple, if C extends B and B extends A, but only B im-plements a remote interface, then a stub is generated from B, not C.

Because the stub implements the same set of remote interfaces as the remote object’s class, the stub has, from the point of view of the Java system, the same type as the remote portions of the server object’s type graph. A client, therefore, can make use of the built-in Java operations to check a remote object's type and to cast from one remote interface to another, e.g.: Remote obj = ...;// lookup object

if (obj instanceof BankAccount) {

BankAccount acct = (BankAccount)obj;

//...

}

The system employs a mechanism called dynamic stub loading to make the correct stub for the remote object available to the client (this technique is fully de-scribed in the section “System Architecture”). Remote Method Invocation

For a client to invoke a method on a remote object, that client must ?rst obtain a reference to the object.

A reference to a remote object is obtained in the usual manner: as a return value in a method call or as a pa-rameter passed to a method. The RMI system provides a simple bootstrap name server from which to obtain remote objects on given hosts.

Invoking a method on a remote object has the same syntax as invoking a method on any Java object. For example, here's how the bank account could be ac-cessed (without exception handling):

BankAccount acct = ...;// lookup account float balance;

acct.deposit(243.50);

acct.withdraw(100.00);

balance = acct.balance();Since remote methods include RemoteException in their signature, the caller must be prepared to handle those exceptions in addition to other application spe-ci?c exceptions. So, for each of the calls above (de-posit,withdraw, and balance), the code needs to catch RemoteException (and the withdraw call would need to also catch OverdrawnException).

If RemoteException is thrown during a remote call, then some communication failure happened during the call. The client has little to no information on the out-come of the call—whether a failure happened before, during, or after the call completed. Thus, remote inter-faces should be designed with these failure semantics in mind [9,15]. The semantics of a remote method may need to be idempotent whereas calls within the local address space likely do not have to be. Note that the above bank account interface does not support idempotent operations, so if an operation fails, the cli-ent needs to perform some type of recovery to deter-mine the true state of the bank account (using transactions would solve this problem).

In most cases, a method invoked on a remote object is indirected through the remote object’s stub to which the caller has a reference. In a method invocation to a remote object which actually resides in the same vir-tual machine as the caller, the call may be a local in-vocation and not a call via the stub for the remote object. If the caller has an actual reference to the re-mote object implementation, the method call is local and is not forwarded via a stub. However, a caller may receive, from a remote object in a different virtual ma-chine, a remote reference to the object whose imple-mentation is in the same virtual machine. In this case, the client (the caller) has a reference to a stub for the remote object; thus, a method call on this reference would be indirected through the stub.

Object Method Semantics

The default implementations for the methods of class Object (equals,hashCode,toString,clone, and?nal-ize) are not appropriate for remote objects. The class RemoteObject provides implementations for these methods that have semantics more appropriate for re-mote objects.

In order for a remote object to be used as a key in a hash table, the methods equals and hashCode need to be overridden in a remote object implementation. The semantics of equals for a remote object must be de-?ned such that remote objects have reference equality. Thus, given any two remote references to the same underlying object, those objects will be equal. No stronger equality, such as “content” equality, may be de?ned for remote objects, since determining the

equality of contents would require a remote call. Re-member that in a remote call, a RemoteException may be raised, and the method equals has no such excep-tion in its throws clause. Due to the different failure semantics between local and remote calls, we chose to implement only reference equality for remote objects. The hashCode method will return the same value for remote references that refer to the same underlying object.

The toString method is de?ned to return a string which represents the reference of the object. In the current implementation that supports unicast method invocation, the contents of this string includes trans-port speci?c information about the object (e.g., host name and port number) and an object identi?er. Objects are only cloneable using the Java language’s default mechanism if they support the https://www.wendangku.net/doc/1d6889277.html,ng.Clone-able interface. Remote objects do not implement this interface, but do implement the clone method so that if subclasses need to implement Cloneable, the remote classes will function correctly.

Cloning a reference to a remote object is a local oper-ation and cannot be used by clients to create a new re-mote object.

For RemoteServer objects,clone is implemented to make a new remote object distinct from the original. Cloning a remote object is only available in the server process where the remote object exists. If a remote object does not extend RemoteServer, it must imple-ment its own version of clone and be able to export a cloned object.

The clone method for a remote object is de?ned to re-turn a reference to the remote object. This operation does not copy any contents of the remote object, it simply returns a reference (since determining contents would require a remote call, and clone does not have RemoteException in its throws clause which would be raised in the event of a remote call failure).

The?nalize method is used in speci?c circumstances depending on the type of remote object (for example, if a remote object is one that can be activated, some cleanup may be necessary).

There are several other methods de?ned in the class Object. These methods, however, are declared as ?nal, which means that they cannot be overridden in an ex-tended class. The methods are:getClass,notify,notify-All, and wait.

The default implementation for getClass is appropri-ate for all Java objects, local or remote. The method needs no special implementation for remote objects.When used on a remote object, the getClass method reports the exact type of the generated stub object. Note that this type re?ects only the remote interfaces implemented by the object, not its local interfaces. The wait/notify methods of Object deal with waiting and noti?cation in the context of Java’s threading model. While use of these methods for remote objects does not break the Java threading model, these meth-ods do not have the same semantics as they do for lo-cal Java objects. Use of these methods would only operate on the client’s local reference to the remote object, not the actual object at the remote site. Since these methods are ?nal, they cannot be extended to have behavior speci?c to remote objects.

Due to the differing failure modes of local and remote objects, distributed wait and noti?cation requires a more sophisticated protocol between the entities in-volved (so that, for example, a client crash does not cause a remote object to be locked forever), and as such, cannot be easily ?tted into the local threading model in Java. Hence, a client can use notify and wait methods on a remote reference, but that client must be aware that such actions will not involve the actual re-mote object, only the local proxy (stub) for the remote object.

Parameter Passing in Remote Invocation

A parameter of any Java type can be passed in a re-mote call. These types include both Java primitive types and Java objects (both remote and non-remote). The parameter passing semantics for remote calls are the same as the Java semantics except:

?non-remote objects contained in a parameter of a remote call are passed by copy; and,

?non-remote objects returned as the result of a remote call are also passed by copy.

That is, when a non-remote object is passed in a re-mote call, the content of the non-remote object is cop-ied before invoking the call on the remote object. Thus, there is no relationship between the non-remote object the client holds and the one it sends to a remote server in a call. For example, let's suppose that the re-mote object bank has a method to obtain the bank ac-count given a name and social security number; the account information info is not a remote object but a local Java object:

Bank bank = ...;

String ssn = "999-999-9999";

AccountInfo info =

new AccountInfo("Robin Smith", ssn); BankAccount acct = bank.getAccount(info);

info.setName("Robyn Smith");

The contents of the object info is copied before invok-ing the remote call on the bank. A client can make changes to info without effecting the server's copy and vice versa.

Locating Remote Objects

A simple bootstrap name server is provided for storing named references to remote objects. A remote object reference can be stored using the URL-based interface java.rmi.Naming.

For a client to invoke a method on a remote object, that client must ?rst obtain a reference to the object.

A reference to a remote object is usually obtained as a return value in a method call. The RMI system pro-vides a simple bootstrap name server from which to obtain remote objects on given hosts. The Naming in-terface provides Uniform Resource Locator (URL) based methods to lookup, bind, rebind, unbind and list the name and object pairings maintained on a particu-lar host and port.

Here's an example of how to bind and lookup remote objects:

BankAccount acct = new BankAcctImpl();

URL url = new URL(“rmi://zaphod/account”); // bind url to remote object

java.rmi.Naming.bind(url, acct);

// ...

// lookup account

acct = java.rmi.Naming.lookup(url);

In the current implementation, a “naming” registry contains a non-persistent database of name-object bindings. This database does not survive system crashes.

4 System Architecture

We have designed our RMI system in order to support the distributed object model discussed above. The sys-tem consists of three basic layers: the stub/skeleton layer,remote reference layer, and transport. A specif-ic interface and protocol de?nes the boundary at each layer. Thus, each layer is independent of the next and can be replaced by an alternate implementation with-out effecting the other layers in the system. For exam-ple, the current transport implementation is TCP-based (using Java sockets), but a transport based on UDP could be used interchangeably.

To accomplish transparent transmission of objects from one address space to another, the technique of pickling [14] (designed speci?cally for Java) is used.Another technique, that we call dynamic stub loading, is used to support client-side stubs which implement the same set of remote interfaces as a remote object it-self. Since a stub of the exact type is available to the client of a remote object, a client can use Java’s built-in operators for casting and typechecking remote in-terfaces.

Architectural Overview

The three layers of the RMI system consist of the fol-lowing:

?stub/skeletons — client-side stubs (proxies) and server-side skeletons (dispatchers)

?remote reference layer — invocation behavior and reference semantics (e.g., unicast, multicast)?transport — connection set up and management and remote object tracking

The application layer sits on top of the RMI system.

Figure 3. System Architecture

Figure 3 is an illustration of the layers of the RMI system. A remote method invocation from a client to a remote server object travels down through the layers of the RMI system to the client-side transport, then up through the server-side transport to the server. The rest of this section summarizes the functionality at each layer in the system.

A client invoking a method on a remote server object actually makes use of a stub or proxy for the remote object as a conduit to the remote object. A client-held reference to a remote object is a reference to a local stub. This stub is an implementation of the remote in-terfaces of the remote object and forwards invocation requests to that server object via the remote reference layer.

The remote reference layer is responsible for carrying out the semantics of the type of invocation. For exam-ple this layer is responsible for handling unicast or multicast invocation to a server. Each remote object

implementation chooses its own invocation seman-tics—whether communication to the server is unicast, or the server is part of a multicast group (to accom-plish server replication).

Also handled by the remote reference layer are the reference semantics for the server. For example, the remote reference layer handles live and/or persistent references to remote objects. Persistent object refer-ences are required in order to activate objects to sup-port long-running servers.

The transport is responsible for connection set-up with remote locations and connection management, and also keeping track of and dispatching to remote objects (the targets of remote calls) residing in the transport’s local address space.

In order to dispatch to a remote object, the server’s transport forwards the remote call up to the remote reference layer (speci?c to the server). The remote reference layer handles any server-side behavior that needs to be done before handing off the request to the server-side skeleton. The skeleton for a remote object makes an up-call to the remote object implementation which carries out the actual method call.

The return value of a call is sent back through the skeleton, remote reference layer and transport on the server side, and then up through the transport, remote reference layer and stub on the client side.

Stub/Skeleton Layer

The stub/skeleton layer is the interface between the application layer and the rest of the RMI system. This layer does not deal with speci?cs of any transport, but transmits data to the remote reference layer via the ab-straction of marshal streams. Marshal streams employ a mechanism called pickling which enables Java ob-jects to be transmitted between address spaces. Ob-jects transmitted using the pickling system are passed by copy to the remote address space.

A stub for a remote object is the client-side proxy for the remote object. Such a stub implements all the in-terfaces that are supported by the remote object imple-mentation. A client-side stub is responsible for:?initiating a call to the remote object (by calling the remote reference layer)

?marshaling arguments to a marshal stream (obtained from the remote reference layer)?informing the remote reference layer that the call should be invoked

?unmarshaling the return value from a marshal stream ?informing the remote reference layer that the call is complete

A skeleton for a remote object is a server-side entity that contains a method which dispatches calls to the actual remote object implementation. The skeleton is responsible for:

?unmarshaling arguments from the marshal stream ?making the up-call to the actual remote object implementation

?marshaling the return value of the call onto the marshal stream

Remote Reference Layer

The remote reference layer deals with the lower level transport interface. This layer is also responsible for carrying out a speci?c invocation protocol which is in-dependent of the client stubs and server skeletons. Each remote object implementation chooses its own invocation protocol that operates on its behalf. Such an invocation protocol is ?xed for the life of the ob-ject. Various invocation protocols can be carried out at this layer, for example:

?unicast invocation

?multicast invocation

?support for a speci?c replication strategy ?support for a persistent reference to the remote object (enabling activation of the remote object)?reconnection strategies (if remote object becomes inaccessible)

These invocation protocols are not mutually exclusive, but may be combined. For example, a remote object may require both persistent reference semantics and replication. Both of these protocols would be carried out in the remote reference layer.

The invocation protocol is divided into two cooperat-ing components: the client-side and the server-side components. The client-side component contains in-formation speci?c to the remote server (or servers, if invocation is to a multicast group) and communicates via the transport to the server-side component. During each method invocation, the client and server-side components are given a chance to intervene in order to accomplish the speci?c invocation and reference se-mantics. For example, if a remote object is part of a multicast group, the client-side component can for-ward the invocation to the multicast group rather than just a single remote object.

In a corresponding manner, the server-side component is given a chance to intervene before delivering a re-mote method invocation to the skeleton. This compo-nent, for example, could handle ensuring atomic

multicast delivery by communicating with other repli-cas in the multicast group.

The remote reference layer transmits data to the trans-port layer via the abstraction of a stream-oriented con-nection. The transport takes care of the implementation details of connections. Although con-nections present a streams-based interface, a connec-tionless transport may actually be implemented beneath the abstraction.

Transport

In general, the transport of the RMI system is respon-sible for:

?setting up connections to remote address spaces ?managing connections

?monitoring connection liveness

?listening for incoming calls ?maintaining a table of remote objects that reside in the local address space

?setting up a connection for an incoming call ?locating the dispatcher for the target of the remote call and passing the connection to this dispatcher The concrete representation of a remote object refer-ence consists of an endpoint and an object identi?er. We call this representation a live reference. Thus, giv-en a live reference for a remote object, a transport can use the endpoint to set up a communication channel to the address space in which the remote object resides. On the server side, the transport uses the object iden-ti?er to look up the target of the remote call.

The transport for the RMI system consists of four ba-sic abstractions (based somewhat on the transport of the Modula-3 network object system):?Endpoint — An endpoint denotes an address space.

In the implementation, an endpoint can be mapped to its transport. That is, given an endpoint, a

speci?c transport instance can be obtained.?Transport — The transport abstraction manages channels. Each channel is a virtual connection

between two address spaces. Within a transport,

only one channel exists per pair of address spaces, the local address space and a remote address

space. Given an endpoint to a remote address

space, a transport sets up a channel to that address space. The transport abstraction is also responsible for accepting calls on incoming connections to the address space, setting up a connection object for

the call, and dispatching to higher layers in the

system.?Channel — Abstractly, a channel is the conduit between two address spaces. As such, it is

responsible for managing connections between the local address space and the remote address space for which it is a channel.

?Connection —A connection is the abstraction for transferring data (performing input/output).

A transport de?nes what the concrete representation of an endpoint is, so multiple transport implementa-tions may exist. The design and implementation also allow multiple transports per address space (so both TCP and UDP can be supported in the same address space). Thus, client and server transports can negoti-ate to ?nd a common transport between them. Garbage Collection

In a distributed system, just as in the local system, it is desirable to automatically delete those remote ob-jects that are no longer referenced by any client. This frees the programmer from needing to keep track of a remote object’s clients so that the remote object can terminate appropriately. RMI uses a reference count-ing garbage collection algorithm similar to the one used for Modula-3 Network Objects [2].

To accomplish reference-counting garbage collection, the RMI runtime keeps track of all live references within each Java virtual machine. When a live refer-ence enters a Java virtual machine its reference count is incremented. The ?rst reference to an object sends a “referenced” message to the server for the object. As live references are found to be unreferenced in the lo-cal virtual machine, their ?nalization decrements the count. When the last reference has been discarded an unreferenced message is sent to the server. Many sub-tleties exist in the protocol, most related to maintain-ing the ordering of referenced and unreferenced messages to insure the object is not prematurely col-lected.

When a remote object is not referenced by any client, the RMI runtime refers to it using a weak reference. The weak reference allows the Java virtual machine’s garbage collector to discard the object if no other lo-cal references to the object exist. The distributed gar-bage collection algorithm interacts with the local Java virtual machine’s garbage collector in the usual ways by holding normal or weak references to objects. As in the normal object life-cycle,?nalize will be called after the garbage collector determines that no more references to the object exist.

As long as a local or remote reference to a remote ob-ject exists, the remote object cannot be garbage col-lected and it may be passed in remote calls or returned

to clients. Passing a remote object adds the client or server to which it was passed to the remote object’s referenced set. A remote object needing unreferenced noti?cation must implement the java.rmi.server.Unref-erenced interface. When those references no longer exist,unreferenced will be invoked.unreferenced is called when the set of references is found to be empty so it may be called more than once. Remote objects are only collected when no more references, either lo-cal or remote, still exist.

Note that if there exists a network partition between a client and remote server object, it is possible that pre-mature collection of the remote object will occur (since the transport may think that the client crashed). Because of the possibility of premature collection, re-mote references cannot guarantee referential integrity; in other words, it is always possible that a remote ref-erence may in fact not refer to an existing object. An attempt to use such a reference will generate a Remo-teException which must be handled by the application. Dynamic Stub Loading

In remote procedure call systems, client-side stub code must be generated and linked into a client before a remote procedure call can be done. This code may be either statically linked into the client or linked in at run-time via dynamic linking with libraries available locally or over a network ?le system. In either the case of static or dynamic linking, the speci?c code to handle an RPC must be available to the client machine in compiled form.

This approach to code linking is static in that the stub code must be compiled and directly available to the client in binary-compatible form at compile time and at run time. Also with these systems, the stub code that the client uses is determined and ?xed at compile time. Because of the static nature of the stub code available to clients in such systems, the code may not be the actual stub code that the client needs at run time, but perhaps the closest matched code that can be determined at compile time. For example in an RMI system, perhaps only a supertype (less speci?c form) of a more speci?c stub is available to the client at run-time. This code mismatch can lead to run-time errors if the client in fact needs a subtype (more speci?c form) of the stub that has been linked in at compile-time.

Our approach solves this code mismatch by loading the exact stub code (in Java’s architecture neutral bytecode format) at run-time to handle method invo-cations on a remote object. This mechanism, called dynamic stub loading, exploits the Java mechanism for downloading code.Dynamic stub loading is used only when code for a needed stub is not already available. The argument and return types speci?ed in the remote interfaces are made available using the same mechanism. Loading arbitrary classes into clients or servers presents a po-tential security problem; this problem is addressed by requiring that a security manager check any classes downloaded for RMI.

In this scheme, client-side stub code is generated from the remote object implementation class, and therefore supports the same set of remote interfaces as support-ed by the remote implementation. Such stub code re-sides on the server’s host (or perhaps another location), and can be downloaded to the client on de-mand (if the correct stub code is not already available to the client). Stub code for a remote implementation could be generated on-the-?y at the remote site and shipped to the client or could be generated on the cli-ent-side from the list of remote interfaces supported by the remote implementation.

Dynamic stub loading employs three mechanisms: a specialized Java class loader, a security manager, and the pickling system. When a remote object reference is passed as a parameter or as the result of a method call, the marshal stream that transmits the reference includes information indicating where the stub class for the remote object can be loaded from, if its URL is known.

A marshal stream is implemented by an underlying pickle stream. Pickle streams provide an opportunity to embed information for each class and object that is transmitted. When transmitting class information for a remote object being marshaled, a marshal stream em-beds a URL that speci?es where the stub code resides. Thus, when a reference to a remote object is unmar-shaled at the destination site, the marshal stream can locate and load the stub code (via the specialized class loader, checked by the security manager) so that the correct stub is available to the client.

Security

The security of a process using RMI is protected by existing Java mechanisms of the security manager and class loader. The security manager regulates access to sensitive functions, and the class loader makes sure that loaded classes are subject to the security manager and adhere to the standard Java safety guarantees. The JDK (Java Developer Kit) 1.0 security manager does not regulate resource consumption, so the current RMI system has no mechanisms available to prevent classes loaded from abusing resources. As new securi-

ty manager mechanisms are developed to control re-source use, RMI will use them.

The Applet Environment

In the applet environment, the AppletSecurityManager and AppletClassLoader are used exclusively. RMI uses only the established security manager and class load-er. In this environment remote object stubs, parameter classes and return object classes can be loaded only from the applet host or its designated code base hosts. This requires that applet developers install the appro-priate classes on the applet host.

The Server Environment

In the server environment, where a Java process is be-ing used to serve RMI requests, the server may need to use a security manager to isolate itself from stub misbehavior. The server functions will usually be im-plemented by classes loaded from the local system and therefore not subject to the restrictions of the se-curity manager. If the remote object interfaces allow objects, either local or remote, to be passed to the server, then those object classes must be accessible to the server. Usually those classes will be built-in class-es or will be de?ned by the server. As long the classes are available locally there is no need for a specialized security manager or stub loader. To support this case, if no security manager is speci?ed, stub loading from network sources is disabled.

When a server is passed a remote object for which it has no corresponding stub code, it may also be passed the location from which the classes for that remote object may be loaded. Two properties control if and from where the stub class can be loaded.

java.rmi.server.ClientClassDisable controls whether the URL’s supplied by clients are used; if set to true, URL’s from clients are ignored and stub classes are loaded using the stub class base.

java.rmi.server.StubClassBase de?nes the URL from which stub classes will be loaded. This is the URL that is passed along with remote object references so clients will know the location from which to load stub classes.

The StubClassLoader is a specialized class loader used by the RMI runtime to load classes. When load-ing any class, the runtime ?rst attempts to use this class loader. If it succeeds those classes will be sub-ject to the current security manager and any classes the stub needs will be loaded and then regulated by that security manager. If the security manager disal-lows creating the class loader, the class (including stub classes) will be loaded using the default Class.forName mechanism. Thus, a server may de?ne its own policies via the security manager and stub loader and the RMI system will operate within them.

5 Related Work

The Common Object Request Broker Architecture (CORBA) [11] is designed to support remote method invocation between heterogeneous languages and sys-tems. In CORBA, distributed objects are described in an interface de?nition language (IDL). IDL presents its own object model, and interfaces de?ned in IDL must be mapped into a target language and object model.

Because of IDL’s language neutrality, the semantics of its object model does not match the object model se-mantics of any implementation language. This mis-match inhibits seamless integration of the CORBA distributed object model into any speci?c target lan-guage. Hence, programmers must deal with two very different object models when writing distributed pro-grams: the local object model of the language, and the distributed object model mapped from IDL.

Our system differs from CORBA in two essential ways: it language-dependence and its ability to load stub code dynamically. Since our system is language-dependent, we can integrate the distributed object model more closely with the target language, Java. Al-so, systems that are CORBA compliant are unable to exploit the use of dynamic stub loading, since COR-BA generally assumes that stub code is linked in at compile time.

Our approach is more akin to the Modula-3 (M3) net-work object system [3]. The Modula-3 system sup-ports remote method invocation on objects in a language-dependent fashion (i.e., the system does not support interoperability with other languages). A sec-ond similarity is that the M3 system transmits objects via pickling. Our RMI system is similar in those re-spects (it depends on the architecture neutrality of Java bytecodes); however, our system is less static in its determination of stub code. The M3 network object system uses the closest matching stub code (called the most-speci?c surrogate) available at compile-time, rather than our approach in which the exact matching stub code is determined at run-time and downloaded over the network if such code is unavailable on the client.

The implementation of our system is similar to the M3 system in another respect: that is, the inclusion of a distinct abstraction for the transport. While the net-work object system has a similar notion of a transport abstraction, it does not include a separate remote ref-

erence layer to handle varying types of invocation se-mantics. Because of this limitation, this type of functionality is not easily layered on the network ob-ject system without adding some burden to the pro-grammer.

Spring [7] is an object oriented operating system de-signed as a successor to UNIX. Spring has the notion of a subcontract [8] which has similar functionality to the remote reference layer in the RMI system. Our system differs in that the remote reference layer has a narrower interface that is more tailored to handling re-mote method invocation semantics. Subcontract is also very intimate with its doors-based transport, and as such does not support alternate transport implemen-tations as readily as our approach.

Like CORBA, Spring uses an interface de?nition lan-guage to describe remote objects. Spring uses mar-shaling code generated from IDL descriptions of objects, whereas our system pickles exact representa-tions of objects at run-time.

6 Future Work

The current system supports unicast remote method invocation to remote objects in Java. The system also implements pickling, dynamic stub loading, and gar-bage collection. We have fully designed and partially implemented activation for distributed objects in this framework. This effort is on-going. Also included will be the capability for server replication in this para-digm.

7 Conclusions

Our RMI system design leverages the two basic as-sumptions of platform homogeneity and language-de-pendence. We can assume homogeneity due to the architecture neutrality that the Java virtual machine provides. Since we are able to focus on language-de-pendent distributed objects, the resulting system pre-sents a simple model that ?ts well into the Java framework, is highly ?exible, and is accessible on a wide variety of machines.

Availability

The Java RMI system will be released with JDK 1.1. Early access versions of this system can be obtained from the https://www.wendangku.net/doc/1d6889277.html, web site. Acknowledgments

We would like to thank Eduardo Pelegri-Llopart and Peter Kessler for useful discussions during the devel-opment of this system.Authors

Ann Wollrath (ann.wollrath@https://www.wendangku.net/doc/1d6889277.html,) is a Staff En-gineer at Sun Microsystems Laboratories, East Coast Division, working in the area of reliable large-scale distributed systems. Prior to joining Sun, she worked in the Parallel Computing Group at the MITRE Cor-poration investigating optimistic execution schemes for parallelizing sequential object-oriented programs. Roger Riggs(roger.riggs@https://www.wendangku.net/doc/1d6889277.html,) is a staff engi-neer at Sun Microsystems Laboratories, East Coast Division, working on large scale distribution and reli-able distributed systems. Prior to joining the group, he worked on client-server text retrieval and CORBA based information retrieval, and scabability issues on the Web.

Jim Waldo (jim.waldo@https://www.wendangku.net/doc/1d6889277.html,) is a Senior Staff Engineer at Sun Microsystems Laboratories, East Coast Division, working in the area of reliable large-scale distributed systems. Prior to joining Sun, he worked in distributed systems and object-oriented software development at Apollo Computer (later Hewlett Packard), where he was one of the original designers of what has become the Common Object Request Broker Architecture (CORBA). References

[1]Arnold, Ken, and James Gosling,The Java?

Programming Language. Addison-Wesley (1996).

[2]Birrell, Andrew, David Evers, Greg Nelson, Susan

Owicki, and Edward Wobber,Distributed Garbage Collection for Network Objects. Digital Equipment Corporation Systems Research Center Technical Report 116 (1993).

[3]Birrell, Andrew, Greg Nelson, Susan Owicki, and

Edward Wobber,Network Objects. Digital Equipment Corporation Systems Research Center Technical Report 115 (1994).

[4]Ellis, Margaret A., and Bjarne Stroustrup,The

Annotated C++ Reference Manual. Addison-Wesley (1990).

[5]Goldberg, Adele, and David Robson,Smalltalk-

80: The Language and Its Implementation.

Addison-Wesley (1983).

[6]Gosling, James, Bill Joy, and Guy Steele, The

Java? Language Specification. Addison-Wesley (1996).

[7]Hamilton, G., and P. Kougiouris, “The Spring

Nucleus: A Microkernel for Objects.”USENIX Summer Conference (July 1993).

[8]Hamilton, Graham, Michael L. Powell, and James

G. Mitchell,Subcontract: A Flexible Base for

Distributed Programming. Sun Microsystems Laboratories Technical Report, SMLI TR-93-13 (April 1993).

[9]Mullender, Sape (ed.),Distributed Systems

(second edition). Addison-Wesley (1993). [10]Nelson, Greg (ed.),Systems Programming with

Modula-3. Prentice Hall (1991).

[11]The Object Management Group,Common Object

Request Broker: Architecture and Specification.

OMG Document Number 91.12.1 (1991).

[12]Pinson, Lewis J. and Richard S. Wiener,Objective

C: Object-Oriented Programming Techniques.

Addison-Wesley (1991).

[13]Rago, Steven A.,UNIX System V Network

Programming. Addison-Wesley (1993).

[14]Riggs, Roger, Jim Waldo, Ann Wollrath, and

Krishna Bharat, “Pickling State in the Java?System.” The2nd USENIX Conference on Object-Oriented Technologies. (1996).

[15]Waldo, Jim, Geoff Wyant, Ann Wollrath, and Sam

Kendall,A Note on Distributed Computing. Sun Microsystems Laboratories Technical Report, SMLI TR-94-29 (November 1994).

[16]Wollrath, Ann, Geoff Wyant, and Jim Waldo,

“Simple Activation for Distributed Objects.”1st USENIX Conference on Object-Oriented Technologies. Monterey, CA (June 1995), pp. 1-

11.

美国常青藤名校的由来

美国常青藤名校的由来以哈佛、耶鲁为代表的“常青藤联盟”是美国大学中的佼佼者，在美国的3000多所大学中，“常青藤联盟”尽管只是其中的极少数，仍是许多美国学生梦想进入的高等学府。常青藤盟校(lvy League)是由美国的8所大学和一所学院组成的一个大学联合会。它们是：马萨诸塞州的哈佛大学，康涅狄克州的耶鲁大学，纽约州的哥伦比亚大学，新泽西州的普林斯顿大学，罗德岛的布朗大学，纽约州的康奈尔大学，新罕布什尔州的达特茅斯学院和宾夕法尼亚州的宾夕法尼亚大学。这8所大学都是美国首屈一指的大学，历史悠久，治学严谨，许多著名的科学家、政界要人、商贾巨子都毕业于此。在美国，常青藤学院被作为顶尖名校的代名词。常青藤盟校的说法来源于上世纪的50年代。上述学校早在19世纪末期就有社会及运动方面的竞赛，盟校的构想酝酿于1956年，各校订立运动竞赛规则时进而订立了常青藤盟校的规章，选出盟校校长、体育主任和一些行政主管，定期聚会讨论各校间共同的有关入学、财务、援助及行政方面的问题。早期的常青藤学院只有哈佛、耶鲁、哥伦比亚和普林斯顿4所大学。4的罗马数字为“IV”，加上一个词尾Y，就成了“IVY”，英文的意思就是常青藤，所以又称为常青藤盟校，后来这4所大学的联合会又扩展到8所，成为现在享有盛誉的常青藤盟校。这些名校都有严格的入学标准，能够入校就读的学生，自然是品学兼优的好学生。学校很早就去各个高中挑选合适的人选，许多得到全国优秀学生奖并有各种特长的学生都是他们网罗的对象。不过学习成绩并不是学校录取的惟一因素，学生是否具有独立精神并且能否快速适应紧张而有压力的大一新生生活也是他们考虑的重要因素。学生的能力和特长是衡量学生综合素质的重要一关，高中老师的推荐信和评语对于学生的入学也起到重要的作用。学校财力雄厚，招生办公室可以完全根据考生本人的情况录取，而不必顾虑这个学生家庭支付学费的能力，许多家境贫困的优秀子弟因而受益。有钱人家的子女，即使家财万贯，也不能因此被录取。这也许就是常青藤学院历经数百年而保持“常青”的原因。布朗大学(Brown University) 1754年由浸信会教友所创，现在是私立非教会大学，是全美第七个最古老大学。现有学生7000多人，其中研究生近1500人。该校治学严谨、学风纯正，各科系的教学和科研素质都极好。学校有很多科研单位，如生物医学中心，计算机中心、地理科学中心、化学研究中心、材料研究实验室、Woods Hole 海洋地理研究所海洋生物实验室、Rhode 1s1and反应堆中心等等。设立研究生课程较多的系有应用数学系、生物和医学系、工程系等，其中数学系海外研究生占研究生名额一半以上。布朗大学的古书及1800年之前的美国文物收藏十分有名。哥伦比亚大学(Columbia University) 私立综合性大学，位于纽约市。该校前身是创于1754年的King’s College，独立战争期间一度关闭，1784年改名力哥伦比亚学院，1912年改用现名。

第四章景观模型制作

第四章景观模型制作第一节主要工具的使用方法 —、主要切割材料工具的使用方法（—）美术刀美术刀是常用的切割工具，一般的模型材料（纸板，航模板等易切割的材料）都可使用它来进行切割，它能胜任模型制作过程中，从粗糙的加工到惊喜的刻划等工作，是一种简便，结实，有多种用途的刀具。美术刀的道具可以伸缩自如，随时更换刀片;在细部制作时，在塑料板上进行划线，也可切割纸板，聚苯乙烯板等。具体使用时，因根据实际要剪裁的材料来选择刀具，例如，在切割木材时，木材越薄越软，刀具的刀刃也应该越薄。厚的刀刃会使木材变形。使用方法：先在材料商画好线，用直尺护住要留下的部分，左手按住尺子，要适当用力（保证裁切时尺子不会歪斜），右手捂住美术刀的把柄，先沿划线处用刀尖从划线起点用力划向终点，反复几次，直到要切割的材料被切开。（二）勾刀勾刀是切割切割厚度小于10mm的有机玻璃板，ABS工程塑料版及其他塑料板材料的主要工具，也可以在塑料板上做出条纹状机理效果，也是一种美工工具。使用方法：首先在要裁切的材料上划线，左手用按住尺子，护住要留下的部分，右手握住勾刀把柄，用刀尖沿线轻轻划一下，然后再用力度适中地沿着刚才的划痕反复划几下，直至切割到材料厚度的三分之二左右，再用手轻轻一掰，将其折断，每次勾的深度为0.3mm 左右。（三）剪刀模型制作中最常用的有两种刀：一种是直刃剪刀，适于剪裁大中型的纸材，在制作粗模型和剪裁大面积圆形时尤为有用；另外一种是弧形剪刀，适于剪裁薄片状物品和各种带圆形的细部。（四）钢锯主要用来切割金属、木质材料和塑料板材。使用方法：锯材时要注意，起锯的好坏直接影响锯口的质量。为了锯口的凭证和整齐，握住锯柄的手指，应当挤住锯条的侧面，使锯条始终保持在正确的位置上，然后起锯。施力时要轻，往返的过程要短。起锯角度稍小于15°，然后逐渐将锯弓改至水平方向，快钜断时，用力要轻，以免伤到手臂。（五）线锯主要用来加工线性不规则的零部件。线锯有金属和竹工架两种，它可以在各种板材上任意锯割弧形。竹工架的制作是选用厚度适中的竹板，在竹板两端钉上小钉，然后将小钉弯折成小勾，再在另一端装上松紧旋钮，将锯丝两头的眼挂在竹板两端即可使用。使用方法：使用时，先将要割锯的材料上所画的弧线内侧用钻头钻出洞，再将锯丝的一头穿过洞挂在另一段的小钉上，按照所画弧线内侧1左右进行锯割，锯割方向是斜向上下。二、辅助工具及其使用方法（一）钻床是用来给模型打孔的设备。无论是在景观模型、景观模型还是在展示模型中，都会有很多的零部件需要镂空效果时，必须先要打孔。钻孔时，主要是依靠钻头与工件之间的相对运动来完成这个过程的。在具体的钻孔过程中，只有钻头在旋转，而被钻物体是静止不动的。钻床分台式和立式两种。台式钻床是一种可以放在工台上操作的小型钻床，小巧、灵活，使

新整理描写常青藤优美句段写常青藤作文散文句子

描写常青藤优美句段写常青藤作文散文句子描写常青藤优美句段写常青藤作文散文句子第1段： 1.睁开朦胧的泪眼，我猛然发觉那株濒临枯萎的常春藤已然绿意青葱，虽然仍旧瘦小，却顽强挣扎，嫩绿的枝条攀附着窗格向着阳光奋力伸展。 2.常春藤是一种常见的植物，我家也种了两盆。可能它对于很多人来说都不足为奇，但是却给我留下了美好的印象。常春藤属于五加科常绿藤本灌木，翠绿的叶子就像火红的枫叶一样，是可爱的小金鱼的尾巴。常春藤的叶子的长约5厘米，小的则约有2厘米，但都是小巧玲珑的，十分可爱。叶子外圈是白色的，中间是翠绿的，好像有人在叶子上涂了一层白色的颜料。从叶子反面看，可以清清楚楚地看见那凸出来的，一根根淡绿色的茎。 3.渴望到森林里探险，清晨，薄薄的轻雾笼罩在树林里，抬头一看，依然是参天古木，绕着树干一直落到地上的常春藤，高高低低的灌木丛在小径旁张牙舞爪。 4.我们就像马蹄莲，永不分开，如青春的常春藤，紧紧缠绕。 5.我喜欢那里的情调，常春藤爬满了整个屋顶，门把手是旧的，但带着旧上海的味道，槐树花和梧桐树那样美到凋谢，这是我的上海，这是爱情的上海。 6.当我离别的时候，却没有你的身影；想轻轻地说声再见，已是人去楼空。顿时，失落和惆怅涌上心头，泪水也不觉悄悄滑落我伫立很久很久，凝望每一条小路，细数每一串脚印，寻找你

的微笑，倾听你的歌声――一阵风吹过，身旁的小树发出窸窸窣窣的声音，像在倾诉，似在安慰。小树长高了，还有它旁边的那棵常春藤，叶子依然翠绿翠绿，一如昨天。我心头不觉一动，哦，这棵常春藤陪伴我几个春秋，今天才惊讶于它的可爱，它的难舍，好似那便是我的生命。我蹲下身去。轻轻地挖起它的一个小芽，带着它回到了故乡，种在了我的窗前。 7.常春藤属于五加科常绿藤本灌木，翠绿的叶子就像火红的枫叶一样，是可爱的小金鱼的尾巴。常春藤的叶子的长约5厘米，小的则约有2厘米，但都是小巧玲珑的，十分可爱。叶子外圈是白色的，中间是翠绿的，好像有人在叶子上涂了一层白色的颜料。从叶子反面看，可以清清楚楚地看见那凸出来的，一根根淡绿色的茎。 8.常春藤是多么朴素，多么不引人注目，但是它的品质是多么的高尚，不畏寒冷。春天，它萌发出嫩绿的新叶；夏天，它郁郁葱葱；秋天，它在瑟瑟的秋风中跳起了欢快的舞蹈；冬天，它毫不畏惧呼呼作响的北风，和雪松做伴常春藤，我心中的绿色精灵。 9.可是对我而言，回头看到的只是雾茫茫的一片，就宛如窗前那株瘦弱的即将枯死的常春藤，毫无生机，早已失去希望。之所以叫常春藤，可能是因为它一年四季都像春天一样碧绿，充满了活力吧。也许，正是因为如此，我才喜欢上了这常春藤。而且，常春藤还有许多作用呢！知道吗？一盆常春藤能消灭8至10平

关于美国常青藤

一、常青藤大学目录联盟概述联盟成员名称来历常春藤联盟（The Ivy League）是指美国东北部八所院校组成的体育赛事联盟。这八所院校包括：布朗大学、哥伦比亚大学、康奈尔大学、达特茅斯学院、哈佛大学、宾夕法尼亚大学、普林斯顿大学及耶鲁大学。美国著名的体育联盟还有太平洋十二校联盟（Pacific 12 Conference）和大十联盟（Big Ten Conference）。常春藤联盟的体育水平在美国大学联合会中居中等偏下水平，远不如太平洋十校联盟和大十联盟。联盟概述常春藤盟校（Ivy League）指的是由美国东北部地区的八所大学组成的体育赛事联盟（参见NCAA词条）。它们全部是美国一流名校、也是美国产生最多罗德奖学金得主的大学联盟。此外，建校时间长，八所学校中的七所是在英国殖民时期建立的。美国八所常春藤盟校都是私立大学，和公立大学一样，它们同时接受联邦政府资助和私人捐赠，用于学术研究。由于美国公立大学享有联邦政府的巨额拨款，私立大学的财政支出和研究经费要低于公立大学。常青藤盟校的说法来源于上世纪的50年代。上述学校早在19世纪末期就有社会及运动方面的竞赛，盟校的构想酝酿于1956年，各校订立运动竞赛规则时进而订立了常青藤盟校的规章，选出盟校校长、体育主任和一些行政主管，定期聚会讨论各校间共同的有关入学、财务、援助及行政方面的问题。早期的常青藤学院只有哈佛、耶鲁、哥伦比亚和普林斯顿4所大学。4的罗马数字为"IV"，加上一个词尾Y，就成了"IVY"，英文的意思就是常青藤，所以又称为常青藤盟校，后来这4所大学的联合会又扩展到8所，成为如今享有盛誉的常青藤盟校。这些名校都有严格的入学标准，能够入校就读的学生，必须是品学兼优的好学生。学校很早就去各个高中挑选合适的人选，许多得到全国优秀学生奖并有各种特长的学生都是他们网罗的对象。不过学习成绩并不是学校录取的惟一因素，学生是否具有独立精神并且能否快速适应紧张而有压力的大一新生生活也是他们考虑的重要因素。学生的能力和特长是衡量学生综合素质的重要一关，高中老师的推荐信和评语对于学生的入学也起到重要的作用。学校财力雄厚，招生办公室可以完全根据考生本人的情况录取，而不必顾虑这个学生家庭支付学费的能力，许多家境贫困的优秀子弟因而受益。有钱人家的子女，即使家财万贯，也不能因

角色模型制作流程

幻想之旅角色模型制作流程 1.拿到原画后仔细分析角色设定细节，对不清楚的结构、材质细节及角色身高等问题与原画作者沟通，确定对原画理解准确无误。 2.根据设定，收集材质纹理参考资料。 3.开始进行低模制作。 4.制作过程中注意根据要求严格控制面数（以MAX为例，使用Polygon Counter工具查看模型面数）。 5.注意关节处的合理布线，充分考虑将来动画时的问题。如有疑问与动作组同事讨论咨询。 6.由于使用法线贴图技术不能使用对称复制模型，可以直接复制模型，然后根据具体情况进行移动、放缩、旋转来达到所需效果。 7.完成后，开始分UV。分UV时应尽量充分利用空间，注意角色不同部位的主次，优先考虑主要部位的贴图（例如脸，前胸以及引人注意的特殊设计），为其安排充分的贴图面积。使用Relax Tool 工具确保UV的合理性避免出现贴图的严重拉伸及反向。 8.低模完成后进入法线贴图制作阶段。现在我们制作法线贴图的方法基本上有三种分别是： a.在三维软件中直接制作高模，完成后将低模与高模对齐，然后使用软件工具生成法线贴图。 b.将分好UV的低模Export成OBJ格式文件，导入ZBrush软件。在ZB中添加细节制作成高模，然后使用Zmapper插件生成法线贴图。 c.在Photoshop中绘制纹理或图案灰度图，然后使用PS的法线贴图插件将灰度图生成法线贴图。（具体制作方法参见后面的制作实例）建议在制作过程中根据实际情况的不同，三种方法结合使用提高工作效率。 9.法线贴图完成后，将其赋予模型，查看法线贴图的效果及一些细小的错误。 10.进入Photoshop,打开之前生成的法线贴图，根据其贴在模型上的效果对法线贴图进行修整。（例如边缘的一些破损可以使用手指工具进行修补，或者在绿色通道中进行适当的绘制。如需加强某部分法线贴图的凹凸效果可复制该部分进行叠加可以起到加强

什么是美国常青藤大学

https://www.wendangku.net/doc/1d6889277.html, 有意向申请美国大学的学生，大部分听过一个名字，常青藤大学联盟。那么美国常青藤大学盟校到底是怎么一回事，又是由哪些大大学组成的呢？下面为大家介绍一下美国常青藤大学联盟。立思辰留学360介绍，常青藤盟校(lvy League)是由美国的七所大学和一所学院组成的一个大学联合会。它们是：马萨诸塞州的哈佛大学，康涅狄克州的耶鲁大学，纽约州的哥伦比亚大学，新泽西州的普林斯顿大学，罗德岛的布朗大学，纽约州的康奈尔大学，新罕布什尔州的达特茅斯学院和宾夕法尼亚州的宾夕法尼亚大学。这8所大学都是美国首屈一指的大学，历史悠久，治学严谨，许多著名的科学家、政界要人、商贾巨子都毕业于此。在美国，常青藤学院被作为顶尖名校的代名词。常青藤由来立思辰留学介绍，常青藤盟校的说法来源于上世纪的50年代。上述学校早在19世纪末期就有社会及运动方面的竞赛，盟校的构想酝酿于1956年，各校订立运动竞赛规则时进而订立了常青藤盟校的规章，选出盟校校长、体育主任和一些行政主管，定期聚会讨论各校间共同的有关入学、财务、援助及行政方面的问题。早期的常青藤学院只有哈佛、耶鲁、哥伦比亚和普林斯顿4所大学。4的罗马数字为“IV”，加上一个词尾Y，就成了“IVY”，英文的意思就是常青藤，所以又称为常青藤盟校，后来这4所大学的联合会又扩展到8所，成为现在享有盛誉的常青藤盟校。这些名校都有严格的入学标准，能够入校就读的学生，自然是品学兼优的好学生。学校很早就去各个高中挑选合适的人选，许多得到全国优秀学生奖并有各种特长的学生都是他们网罗的对象。不过学习成绩并不是学校录取的惟一因素，学生是否具有独立精神并且能否快速适应紧张而有压力的大一新生生活也是他们考虑的重要因素。学生的能力和特长是衡量学生综合素质的重要一关，高中老师的推荐信和评语对于学生的入学也起到重要的作用。学校财力雄厚，招生办公室可以完全根据考生本人的情况录取，而不必顾虑这个学生家庭支付学费的能力，许多家境贫困的优秀子弟因而受益。有钱人家的子女，即使家财万贯，也不能因此被录取。这也许就是常青藤学院历经数百年而保持“常青”的原因。

模型制作方法

动画精度模型制作与探究 Animation precision model manufacture and inquisition 前言写作目的：三维动画的制作，首要是制作模型，模型的制作会直接影响到整个动画的最终效果。可以看出精度模型与动画的现状是随着电脑技术的不断发展而不断提高。动画模型走精度化只是时间问题，故精度模型需要研究和探索。现实意义：动画需要精度模型，它会让动画画面更唯美和华丽。游戏需要精度模型，它会让角色更富个性和激情。广告需要精度模型，它会让物体更真实和吸引。场景需要精度模型，它会让空间更加开阔和雄伟。研究问题的认识：做好精度模型并不是草草的用基础的初等模型进行加工和细化，对肌肉骨骼，纹理肌理，头发毛发，道具机械等的制作更是需要研究。在制作中对于层、蒙版和空间等概念的理解和深化，及模型拓扑知识与解剖学的链接。模型做的精，做的细，做的和理，还要做的艺术化。所以精度模型的制作与研究是很必要的。论文的中心论点：对三维动画中精度模型的制作流程，操作方法，实践技巧，概念认知等方向进行论述。本论序言：本设计主要应用软件为Zbrsuh4.0。其中人物设计和故事背景都是以全面的讲述日本卡通人设的矩阵组合概念。从模型的基础模型包括整体无分隔方体建模法，Z球浮球及传统Z球建模法（对称模型制作。非对称模型制作），分肢体组合建模法（奇美拉，合成兽），shadow box 建模和机械建模探索。道具模型制作，纹理贴图制作，多次用到ZBURSH的插件，层概念，及笔刷运用技巧。目录： 1 角色构想与场景创作一初步设计：角色特色，形态，衣装，个性矩阵取样及构想角色的背景二角色愿望与欲望。材料采集。部件及相关资料收集三整体构图和各种种类基本创作 2 基本模型拓扑探究和大体模型建制 3 精度模型大致建模方法一整体无分隔方体建模法二Z球浮球及传统Z球建模法（对称模型制作。非对称模型制作）三分肢体组合建模法（奇美拉，合成兽）四shadow box 建模探索和机械建模 4 制作过程体会与经验：精度细节表现和笔刷研究 5 解剖学，雕塑在数码建模的应用和体现（质量感。重量感。风感。飘逸感）

2019年美国常春藤八所名校排名

2019年美国常春藤八所名校排名享有盛名的常春藤盟校现在是什么情况呢？接下来就来为您介绍一下！以下常春藤盟校排名是根据2019年美国最佳大学进行的。接下来我们就来看看各个学校的状态以及真实生活。完整的常春藤盟校名单包括耶鲁大学、哈佛大学、宾夕法尼亚大学、布朗大学、普林斯顿大学、哥伦比亚大学、达特茅斯学院和康奈尔大学。同时我们也看看常春藤盟校是怎么样的？也许不是你所想的那样。 2019年Niche排名 3 录取率5% 美国高考分数范围1430-1600 财政援助：“学校选择美国最优秀的学生，想要他们来学校读书。如果你被录取，哈佛会确保你能读得起。如果你选择不去入学的话，那一定不是因为经济方面的原因。”---哈佛大三学生2019年Niche排名 4 录取率6% 美国高考分数范围1420-1600 学生宿舍：“不可思议！忘记那些其他学校的学生宿舍吧。在耶鲁，你可以住在一个豪华套房，它更像是一个公寓。一个公寓有许多人一起住，包括一个公共休息室、洗手间和多个卧室。我再不能要求任何更好的条件了。这个套房很大，很干净，还时常翻修。因为学校的宿舍深受大家喜爱，现在有90%的学生都住在学校！”---耶鲁大二学生

2019年Niche排名 5 录取率7% 美国高考分数范围1400-1590 综合体验：“跟任何其他学校一样，普林斯顿大学有利有弊。这个学校最大的好处也是我选择这个学校的主要原因之一就是它的财政援助体系，任何学生想要完成的计划，它都会提供相应的财政支持。”---普林斯顿大二学生 2019年Niche排名 6 录取率9% 美国高考分数范围1380-1570 自我关心：“如果你喜欢城市的话，宾夕法尼亚大学是个不错的选择。这里对于独立的人来说也是一个好地方，因为在这里你必须学会自己发展。要确保进行一些心理健康的训练，因为这里的人通常会过量工作。如果你努力工作并且玩得很嗨，二者都会使你精疲力尽，所以给自己留出点儿时间休息。”---宾夕法尼亚大一学生 2019年Niche排名7 录取率7% 美国高考分数范围1410-1590 综合体验：“学校的每个人都很关心学生，包括我们的身体状况和学业成绩。在这里，你可以遇到来自世界各地的多种多样的学生。他们在学校进行的安全防范教育让我感觉受到保护。宿舍生活非常精彩，你会感觉跟室友们就像家人一样。总之，能成为学校的一员我觉得很棒，也倍感荣幸！”---哥伦比亚大二学生2019年Niche排名9 录取率9% 美国高考分数范围1370-1570 学术点评：“新的课程培养学术探索能力，在过去的两年中我

美国常青藤大学研究生申请条件都有哪些

我国很多学子都想前往美国的常青藤大学就读于研究生，所以美国常青藤大学研究生申请条件都有哪些? 美国常青藤大学研究生申请条件： 1、高中或本科平均成绩(GPA)高于3.8分，通常最高分是4分，平均分越高越好; 2、学术能力评估测试I(SAT I，阅读+数学)高于1400分，学术能力评估测试II(SAT II，阅读+数学+写作)高于2000分; 3、托福考试成绩100分以上，雅思考试成绩不低于7分; 4、美内国研究生入学考试(GRE)成绩1400分以上，经企管理研究生入学考试(GMAT)成绩700分以上。大学先修课程(AP)考试成绩并非申请美国大学所必需，但由于大学先修课程考试对于高中生来说有一定的挑战性及难度，美国大学也比较欢迎申请者提交大学先修课程考试的成绩，作为入学参考标准。

有艺术、体育、数学、社区服务等特长者优先考容虑。获得国际竞赛、辩论和科学奖等奖项者优先考虑，有过巴拿马国际发明大赛的得主被破例录取的例子。中国中学生在奥林匹克数、理、化、生物比赛中获奖也有很大帮助。常春藤八所院校包括：哈佛大学、宾夕法尼亚大学、耶鲁大学、普林斯顿大学、哥伦比亚大学、达特茅斯学院、布朗大学及康奈尔大学。新常春藤包括：加州大学洛杉矶分校、北卡罗来纳大学、埃默里大学、圣母大学、华盛顿大学圣路易斯分校、波士顿学院、塔夫茨大学、伦斯勒理工学院、卡内基梅隆大学、范德比尔特大学、弗吉尼亚大学、密歇根大学、肯阳学院、罗彻斯特大学、莱斯大学。纽约大学、戴维森学院、科尔盖特大学、科尔比学院、瑞德大学、鲍登学院、富兰克林欧林工程学院、斯基德莫尔学院、玛卡莱斯特学院、克莱蒙特·麦肯纳学院联盟。小常春藤包括：威廉姆斯学院、艾姆赫斯特学院、卫斯理大学、斯沃斯莫尔学院、明德学院、鲍登学院、科尔比学院、贝茨学院、汉密尔顿学院、哈弗福德学院等。

模型的制作工艺及流程

□所需要的设备有：电脑，设计软件AutoCAD，雕刻机，工作台，油漆喷枪等。 □所需要的原材料有：各种厚度的有机玻璃板，各种厚度的PVC板，普通海绵，大孔海绵，背胶纸，各色绒线末，粗鱼线，铜丝电线，0.5mm漆包线，涂料，各色油漆，绒面墙纸，三氯甲烷，干花，发胶，小彩灯等。 □所需要的工具有：美工刀、锯条刀、木工工具、电工工具等。一、沙盘台子首先，要将顾客交付持房地产平面布置图和施工图纸研究透，组装部根据平面布置图及沙盘的比例来制作沙盘的台子。台子一般做成台球桌状，如果是大型的沙盘，要做成几个小台子，拼到一起。二、PVC板喷漆喷漆部根据楼房图纸的设色调出相应颜色的油漆来，喷在相应的PVC板上，送到设计部进行雕刻。三、雕刻楼房部件设计部根据施工图按比例设计出楼房的结构，并在电脑上分解成不同的板块，按施工的要求设计出墙面的花纹、房顶的瓦棱、窗子等，然后发送到雕刻机在PVC板上雕刻出楼房的板块，送到制作部制作。四、组合楼房制作部根据设计部送来的楼房板块，根据说明和粘合方式，用三氯甲烷将PVC板块粘合成楼房的大致形状。窗子的形状是直接雕刻在PVC板上的，用薄而透明的有机玻璃板粘在内部窗子的位置作为窗子的玻璃。五、置景置景部根据组装部所作的台子和平面布置图，在台子上划分出平面布局，用绿色绒面墙纸作为草地粘在绿化区，大孔海绵浸上绿色油漆晾干，裁成长条作为绿化带粘在小灌木区。如果布局中有水和湖泊，可以用波纹面的有机玻璃板，背面喷湖蓝色漆，裁成河流或湖泊的形状放在相应的位置。若是有高地，可将有机玻璃板或PVC板层层堆积并修整成形，再抹上涂料填充缝隙，晾干后覆上草地。用灰色的背胶纸粘成公路，用白色背胶纸刻成公路线标粘在上面。六、制作配件制作部将铜丝电线剥皮，将铜丝拧成树干的形状，喷上漆。普通海绵浸漆，晾干后粉碎，将树干的枝丫浸胶，粘上碎海绵，做成树。若是绿树，海绵可浸绿漆，若是秋天的树，可浸橙色漆。柳树可用0.2mm的漆包线拧成树干与树枝，然后在树枝上粘上绿色绒线末。松树是将粗鱼线剪成细段，用夹子夹住，再将两根0.5mm的漆包线夹住绞动，松开夹子，就成了松树的形状，修剪一下，粘上绿色绒线末即可。其它的花草可以用干花剪下来染色来制作。用医用棉签或牙签做成路灯。泡沫塑料可以用刀片雕刻成假山石的形状，喷上漆。七、整体组合置景部将制作部送来的花草树木及楼房按布置粘在相应的地方。组装部根据每栋楼房所在的位置，打孔并装上小彩灯，使楼房模型内部能发光，如同开灯的效果，并接好线路。

留学美国常春藤八大院校

留学美国常春藤八大院校美国常春藤声誉：几乎所有的常春藤盟校都以苛刻的入学标准著称，近年来尤其如此：在过去的10多年里常春藤盟校的录取率正在下降。很多学校还在特别的领域内拥有极大的学术声誉，例如：哥伦比亚大学的法学院、商学院、医学院和新闻学院；康乃尔大学的酒店管理学院和工程学院；达特茅斯学院的塔克商学院（TuckSchoolofBusiness）；哈佛大学的商学院、法学院、医学院、教育学院和肯尼迪政府学院；宾夕法尼亚大学的沃顿商学院、医学院、护理学院、法学院和教育学院；普林斯顿大学的伍德鲁·威尔逊公共与国际事务学院；耶鲁大学的法学院、艺术学院、音乐学院和医学院；美国常春藤八大名校【哈佛大学】哈佛大学（HarvardUniversity）是一所位于美国马萨诸塞州波士顿剑桥城的私立大学，常春藤盟校成员之一，1636年由马萨诸塞州殖民地立法机关立案成立。该机构在1639年3月13日以一名毕业于英格兰剑桥大学的牧师约翰·哈佛之名，命名为哈佛学院，1780年哈佛学院更名为哈佛大学。直到19世纪，创建了一个半世纪的哈佛学院仍然以英国的牛津大学、剑桥大学两所大学为模式，以培养牧师、律师和官员为目标，注重人文学科，学生不能自由选择课程。19世纪初，高等教育课程改革的号

角在哈佛吹响了，崇尚“学术自由”和“讲学自由”。“固定的学年”和“固定的课”的老框框受到冲击，自由选修课程的制度逐渐兴起。哈佛大学是一所在世界上享有顶尖大学声誉、财富和影响力的学校，被誉为美国政府的思想库，其商学院案例教学也盛名远播。作为全美的大学之一，在世界各研究机构的排行榜中，也经常名列世界大学第一位。美国常春藤八大名校【耶鲁大学】耶鲁大学（YaleUniversity）是一所坐落于美国康涅狄格州纽黑文（纽黑文市CityofNewHaven）的私立大学，创于1701年，初名“大学学院”（CollegiateSchool）。耶鲁起初是一所教会学校，1718年，英国东印度公司高层官员伊莱休·耶鲁先生向这所教会学校捐赠了9捆总价值562英镑12先令的货物、417本书以及英王乔治一世的肖像和纹章，在当时对襁褓之中的耶鲁简直是雪中送炭。为了感谢耶鲁先生的捐赠，学校正式更名为 “耶鲁学院”，它就是今日耶鲁大学的前身。18世纪30年代至80年代，耶鲁在伯克利主教、斯泰尔斯牧师、波特校长等的不懈努力下，逐渐由学院发展为大学。至20世纪初，随着美国教育的迅猛发展，耶鲁大学已经发展到了惊人的规模，在世界的影响力也达到了新的高度。耶鲁大学是美国历建立的第三所大学（第一所是哈佛大学，第二所是威廉玛丽学院），该校教授阵容、学术创新、课程设置和场馆设施等方面堪称一流，与哈佛大学、普林斯顿大学齐名，历年来共同角逐美国大学和研究生院前三的位置。哈佛大学注重闻名于研究生教育，威廉玛丽学院闻名于本科生教育，耶鲁则是双脚走路，都非常，在世界大学排名中名列前茅。美国常春藤八大名校【宾夕法尼亚】宾夕法尼亚大学(UniversityofPennsylvania)是一所私立大学，是在美国开国元勋本杰明·富兰克林的倡导下于1740年建立起来的。它是美国东北部常春藤大学之一，坐落于合众国的摇篮——费城，独

建筑模型制作流程

建筑制作项目流程 1、制作前期策划根据甲方提供的平面图、立面图、效果图及模型要求，制定模型制作风格。 2、模型报价预算预算员根据[1]、模型比例大小、材料工艺及图纸深度确定模型收费、签订制作服务订单。 3、制作组织会审技术人员将核对分析图纸，确定模型材质、处理工艺、制作工期及效果要求。 (1)建筑制作进程：建筑制作师根据甲方提供的图纸施工制作，效果以真实、美观为原则。所有建筑均采用AutoCAD绘图，电脑雕刻机切割细部、建筑技师手工粘接的流水线作业法，既保证了各部件的质量又保证了工期。 (2)环境景观设计制作进程：总体环境将由专业景观设计师进行把控。专业制作人员结合图纸进行设计制作。原则是根据甲方的设计图纸再现设计师的设计意图。切不可胡乱操作，自由发挥。同时使用仿真树木、小品、雕塑等进行点缀，使得整个景观部分美观精致。 (3)建筑环境灯光组装：灯光系统根据甲方要求进行设计制作，体现沙盘的夜景效果。 4、制作完工检验质检部经理及项目负责人对照图纸，进行细部检查和调整。 5、模型安装调试模型服务人员在模型展示地现场调试安装清洁，达到甲方满意后离开。编辑本段建筑模型分类黏土模型黏土材料来源广泛取材方便价格低廉经过“洗泥”工序和“炼熟过程其质地更加细腻。黏土具有一定的粘合性可塑性极强在塑造过程中可以反复修改任意调整修刮填，补比较方便。还可以重复使用是一种比较理想的造型材料,但是如果黏土中的水分失去过多则容易使黏土模型出现收缩龟裂甚至产生断裂现象不利于长期保存。另外，在黏土模型表面上进行效果处理的方法也不是很多,黏土制作模型时一定要选用含沙量少，在使用前要反复加工，把泥和熟，使用起来才方便。一般作为雕塑、翻模用泥使用。油泥模型油泥是一种人造材料。凝固后极软，较软，坚硬。油泥可塑性强，黏性、韧性比黄泥（黏土模型）强。它在塑造时使用方便，成型过程中可随意雕塑、修整，成型后不易干裂，可反复使用。油泥价格较高，易于携带，制作一些小巧、异型和曲面较多的造型更为合适。一般像车类、船类造型用油泥极为方便。所以选用褐油泥作为油泥的最外层是很明智的选择。油泥的材料主要成分有滑石粉62%、凡士林30%、工业用蜡8%。石膏模型石膏价格经济，方便使用加工，用于陶瓷、塑料、模型制作等方面。石膏质地细腻，成型后易于表面装饰加工的修补，易于长期保存，适用于制作各种要求的模型，便于陈列展示。塑料模型塑料是一种常用制作模型的新材料。塑料品种很多，主要品种有五十多种，制作模型应

美国常青藤名校的由来

哈佛、耶鲁、哥伦比亚和普林斯顿4所大学。4的罗马数字为“IV”，加上一个词尾Y，就成了“IVY”，英文的意思就是常青藤，所以又称为常青藤盟校，后来这4所大学的联合会又扩展到8所，成为现在享有盛誉的常青藤盟校。这些名校都有严格的入学标准，能够入校就读的学生，自然是品学兼优的好学生。学校很早就去各个高中挑选合适的人选，许多得到全国优秀学生奖并有各种特长的学生都是他们网罗的对象。不过学习成绩并不是学校录取的惟一因素，学生是否具有独立精神并且能否快速适应紧张而有压力的大一新生生活也是他们考虑的重要因素。学生的能力和特长是衡量学生综合素质的重要一关，高中老师的推荐信和评语对于学生的入学也起到重要的作用。学校财力雄厚，招生办公室可以完全根据考生本人的情况录取，而不必顾虑这个学生家庭支付学费的能力，许多家境贫困的优秀子弟因而受益。有钱人家的子女，即使家财万贯，也不能因此被录取。这也许就是常青藤学院历经数百年而保持“常青”的原因。布朗大学(Brown University)

美国常青藤大学

一、常春藤大学的综合考察 1 （一）秉承传统，注重办学特色 2 （二）讲求质量，保持领先地位 4 （三）避免封闭，与盟校切磋交流 7 二、常春藤大学的分别考察（一）哈佛大学 9 （二）耶鲁大学 13 （三）哥伦比亚大学 18 （四）普林斯顿大学 23 （五）康乃尔大学 25 （六）宾西法尼亚大学 27 （七）布朗大学 29 （八）达特茅斯学院 34 三、常春藤大学面向未来开展教育创新 36 （一）调整课程体系 37 （二）倡导学术诚信 37 （三）加强科研攻关 37 （四）推动数字建设 38 （五）服务经济发展 38 （六）加强国际交流 39 （七）营造优美校园 39 （八）提高管理效率 40

美国常春藤大学美国著名的八所常春藤大学均位于纽约领区，在一定程度上体现了我领区的优秀教育资源。本资料基于教育组领事对全部常春藤大学的实地考察编写而成。一、常春藤大学的综合考察美国常春藤大学历史悠久，崇尚学术，注重特色，塑造校风，规范办学，教授水平高，学生质量好，在美国乃至全世界高教领域都有较大影响，“常春藤”（Ivy League）几乎成了一流大学的代名词，成了这些名牌老校的无形资产。在21世纪的头几年，常春藤大学通过委任资深校长，聘用杰出教师，招收优秀学生，致力于发现知识、传授知识、培养人才、贡献社会，并制定出面向未来的规划，意欲在激烈的竞争中，始终处于不败之地。（一）秉承传统，注重办学特色源于竞技，代表名校。20世纪三、四十年代，美国各大学之间体育比赛如火如荼，并将体育比赛成绩与学校水平相提并论。各校为在比赛中独占鳌头，纷纷降低录取条件，提供高额奖学金，争招体育运动尖子，客观上造成为比赛而比赛，为名次而降分的局面，引起一些名校的不满。1945年，哈佛大学（建于1636）、耶鲁大学（1701）、哥伦比亚大学（1754）、和普林斯顿大学（1746）、四校达成共识，声明取消体育项目奖学金，并结成橄榄球竞赛联盟，在四校间进行比赛。“四”的罗马数字为I V,音同I V Y，意为长春藤，于是有人称这些大学为长春藤大学。 1954年，康乃尔大学（建于1868）、宾夕法尼亚大学(1740)、达特茅斯学院（1769）、布郎大学（1764）入盟。八校共同签署协议，决定各种体育比赛项目均在八校间开展。这八所名校皆为私立，除康乃尔建于19世纪外，其余都有数百年历史，比美国建国还早。这些大学均有古色古香的建筑物，墙壁上爬满了常春藤，从而强化了对常春藤的称谓。由于常春藤大学的历史久、水平高、名气大，尽管学费高昂，人们仍然心向神往。一些人上名校不只为读书，也为广泛交友，八面得风，预埋一张无形的社会关系网。挟其声威，广揽财源。借助于在学术上的显赫气焰，常春藤大学一般很会造势。每年召开很多会议，邀请知名校友和著名财团、政要成为校董，以使财脉不段。校友乐于回馈母校，报答社会，向母校捐赠成为风尚。学术自由，独立办学。常春藤大学享有充分的自主权。开什么专业，由学校决定；开什么课，由院系决定；如何上课，由教师决定。这些大学认为，学术自由是宪法修正案中明确赋予大学的权利，惟有如此，方能不媚权贵，追求真理，培育英才。当然，自由是相对的，有自由就有责任。发展强项，注重特色。常春藤大学根据实际情况规划学校发展，有所为有所不为。注重特色，讲究比较优势，扬长避短。哈佛的政府学院历来第一，哥大的国际关系学院首屈一指，宾大的沃顿商学院傲视同行，耶鲁的法学院赫赫有名。达特茅斯学院曾有发展成研究型大学的机会，但它不改校名高扬本科教育的旗帜；布郎一贯实施课程的完全选修制，让学生自主学习；普林斯顿尽管财力雄厚，但不设医学院，集中力量办好原有系科；康乃尔农牧见长，农业推广项目享誉全美。优美环境，优良校风。常春藤大学校园美丽，清静整洁，建筑典雅，错落有致，春夏秋冬各具风光，是理想的学习研究之地。这些大学提倡严谨诚信，以人为本，培养品德高尚、独立思考、身体健康、具有领导才能和创新精神的杰出人才。依法治校，规范管理。常春藤大学均设有法律事务处，依据学校规模，内设3----18名专职法律顾问，总顾问常由一名副校长兼任。他们对外协调法律纠纷，努力维护学校权益，对内理顺部门关系，协助校长监管学校运作和教师操行。同时，各校均有一整套详尽的管理制度，实行规范管理。学校总部负责重大事项，院系则安排具体的教育教学活动，各司其职，各负其责。校董会(Corporation)是学校最高决策机构，由上院（Board of Fellows）和下院（Board of Trustees）组成。校董会的主要职责是：保证办学诚信，任命校长，确保教学管理有序，通过预算，筹款并管理大学的基金，却保足够的物质设施，总揽长远规划，充当大学于社区的桥梁，保持大学自治，仲裁校内纠纷。

模型制作基础教程

模型制作基础教程 2008-06-14 16:27:08 来源: 作者: 【大中小】评论：3条第一章制作工具的准备做为一个新入门的模型爱好者，首先遇到的问题就是：做模型需要一些什么工具呢？什么工具是即省钱又好用的呢？在这里我想谈一下自己的经验，希望对您有所帮助。 1.模型剪/钳刃口由高强度金属制成且成斜口(也称斜口钳)，是将模型零件从板子上取下的工具，由于是斜口的，所以不会损坏零件。建议购买国产奥迪的，价格在18元左右。 2.笔刀将零件剪下后，要将零件上多余的流道削去，就要用到笔刀，建议购买田岛的28元/把(8片刀片)在这里要提醒初学者由于笔刀很锋利，使用笔刀时刀口不要朝向自己，以免造成伤害。 3.锉刀零件取下之后，还要进行打磨的工作，这时你就需要它。锉刀可以分为钻石粉锉刀(表面上附有廉价的钻石粉)以及螺纹锉刀，前者很适合打磨塑料;后者可以打磨蚀刻片。建议购买有各种形状的套装，一般价格不贵在20~50元左右。锉刀的清理可以用废旧的牙刷刷几下既可。 4.砂纸在经过锉刀的粗打磨后，就要使用砂纸进行细加工，砂纸分为各种号数，号数越大就越细，建议购买800，1000。1200号水砂纸(在五金店均有售，价格在0。6元/张左右) 5.胶水零件打磨完毕以后，就要使用专门的模型胶水进行粘接，在这里笔者强烈建议购买田宫的溜缝胶水(25元/瓶)它流动性相当好，而且粘接强度适中，最重要的是它具有“渗” 的作用，这样就避免了由于胶水涂太多而溢出损坏零件。其他胶水还有模王的瓶装(小瓶10元/瓶大瓶25元/瓶)威龙胶水(8元/瓶现以不多见)等。 6.镊子模型制作中经常要碰到细小零件，这时你就需要一把好用的镊子，建议购买弯头尖嘴，而且后面有锁扣的那种。 7.补土一些模型由于开模的原因，在组合后会产生缝隙，这时就需要使用补土来填补。补土有很多种类:水补土，牙膏状补土，AB补土，保丽补土，红补土等，就功能上可以分为填补类:牙膏状补土塑型类:AB补土，保丽补土，红补土表面处理类:水补土。这里只介绍属填补类的牙膏状补土:一般市面上常见的是田宫和郡仕的产品，价格均为25元/支，笔者个人认为田宫的补土较为细腻，容易上手，但有干后收缩大的缺点，但还是建议初学者使用;郡仕补土为胶状，干后硬度大，且收缩小，但较难上手，不太适合初学者。以上几种就是模型制作中最最基础的工具(不包括涂装工具，将另文介绍)，对于初学者来

常青藤代表着什么教育理念

来源：南方人物周刊作者：南方人物周刊特约撰稿薛涌最后更新：2012-08-29 08:27:02 “常青藤”在中国已经甚为耳熟。人们对于耳熟的东西，也往往误会很多。10年前，中国掀起了“建设世界一流大学”的运动，常青藤作为“研究性大学”被当成模仿的标本。如今，中国的留学潮从研究院蔓延到了本科，常青藤的博雅教育、“完人”（well-rounded person）培养的理念，也被广为讨论，成为批判中国“应试教育”的有力武器。另外，在制度上，常青藤基本属于私立，和官办的中国高等教育体制形成了鲜明的对照。这似乎也成为市场效率的明证，值得中国的大学借鉴。在我看来，对常青藤的这些认识，都有简单化之嫌。我个人作为美国教育制度的介绍者，对此也并非没有责任。现在的常青藤固然多为研究性大学，但却来自于和研究性大学非常不同的传统。教育的“完人”理想固然可贵，但这种贵族性的理念长期以来被用于维护上流社会的既得利益，有着相当丑陋的历史。相比之下，常青藤录取中的“应试化”，倒是一种进步的趋势。作为私立的常青藤，充分利用了市场模式，比起欧洲的官办大学来显示出巨大的优势。但是，常青藤在战后的进步，往往和联邦资金的大量介入、政府的一系列法规有密切关系。总之，常青藤有着悠久丰富的传统，但很难代表一个一成不变的教育理念。理解常青藤，就必须分析其复杂的历史基因。耶鲁大学校园，布什和克里都曾在这里加入“骷髅会”（一个秘密精英社团，成员包括许多美国政界、商界、教育界的重要人物） “牛桥传统” 美国的高等教育是几大传统的汇流。追根寻源，哈佛、耶鲁、普林斯顿等常青藤盟校属于盎格鲁-萨克逊传统，或称“牛桥传统”（Oxbridge），即牛津-剑桥所代表的高等教育。这派的要旨，是培养“完人”，强调通才教育而轻视专业研究。牛津、剑桥到20世纪初尚不授予博士学位。人，而非专业，是教育的核心。平民社会急剧扩张，几所贵族气十足的常青藤自然无法满足高等教育的需求。南北战争后，联邦政府通过了“颁地法”，即1862年的Merrill Land Grant Act和1887年的Hatch Act，拨给各州大量的联邦土地，让其用卖地所得的款项建立和发展州立大学，其宗旨是传授实用的生产技艺，特别是农业生产的技艺。密歇根、威斯康星以及加利福尼亚的州立大学体系，就是在这个时期成型的。直到今天，州立大学大多比较强调实用技能，也是和这种下里巴人的起源有关。到19世纪末，德国的研究型大学崛起，其基本理念是把大学建成学术工厂，以学术带头人为中心组成专门的科系，研究人员在严格的分工下推进知识的新边疆。这种专业化体制，使德国在科学研究上突飞猛进，很快就成为诺贝尔奖得主最多的国家。爱因斯坦等一代科学巨子，实际上都是德国体制的产品。美国高等教育界人士显然在第一时间注意到了这一体制的优势，仿照德国模式建立了一系列私立的研究型大学。芝加哥大学、约翰·霍普金斯大学等等，都是在这一潮流中问世的。到20世纪，这种研究型大学和顶尖的州立大学汇流，强调专业训练，强调课程，和标举“完人”教育理想的常青藤形成了鲜明的对照。在南北战争后，美国进入了急剧的工业扩张，一跃而成为世界第一大经济体。在这样一个激荡的年代，常青藤依然还是盎格鲁-萨克逊白人清教徒（WASP）精英阶层的私人俱乐部。其学生来源，主要是纽约、新

A Distributed Object Model for the Java System

美国常青藤名校的由来

第四章 景观模型制作

新整理描写常青藤优美句段 写常青藤作文散文句子

关于美国常青藤

角色模型制作流程

什么是美国常青藤大学

模型制作方法

2019年美国常春藤八所名校排名

美国常青藤大学研究生申请条件都有哪些

模型的制作工艺及流程

留学美国常春藤八大院校

建筑模型制作流程

美国常青藤名校的由来

最新模型制作教案5-4建筑模型制作步骤教案(精)

美国常青藤大学

模型制作基础教程

常青藤代表着什么教育理念

第四章景观模型制作

新整理描写常青藤优美句段写常青藤作文散文句子