Transcript 面向对象技术 - 南京大学计算机科学与技术系

1
Distributed Objects
分布对象(1)
Institute of Computer Software
Nanjing University
2015/7/20
摘要
2

背景
 Why,



What, How
一般框架
CORBA
Java RMI
Institute of Computer Software
Nanjing University
2015/7/20
Acknowledgement
3

本节ppt 有关CORBA部分内容从下列文献摘录或
改编：
 Bamshad
Mobasher
 http://maya.cs.depaul.edu/~mobasher/classes/ds520/

Douglas C. Schmidt
 http://www.cs.wustl.edu/~schmidt/corba.html
Institute of Computer Software
Nanjing University
2015/7/20
摘要
4

背景
 Why,



What, How
一般框架
CORBA
Java RMI
Institute of Computer Software
Nanjing University
2015/7/20
背景
5

分布式计算（Distributed computing）
 What:
 the
process of running a single computational task on more
than one distinct computer
-from Wikipedia
 Compare to “Parallel Computing”
 Why?
 How?
 实践表明，分布式应用系统的开发比集中式应用系统开
发困难的多。
Institute of Computer Software
Nanjing University
2015/7/20
分布式计算
6

Why?
 “世界是分布的”。
 有时将涉及的用户、应用、数据集中化不合适、不可行。
 资源共享
 并行处理
 冗余容错
The main goal of a distributed computing system is to connect users and resources in a
transparent, open, and scalable way. Ideally this arrangement is drastically more fault
tolerant and more powerful than many combinations of stand-alone computer systems.
Institute of Computer Software
Nanjing University
2015/7/20
The Business Model
 Every application is part of your business model
 must make them work together!
Payables/
Receivables
Sales
Accounting
Manufacturing
Inventory
Shipping/
Receiving
Engineering
Distributed Systems Frameworks
7
The Problem
 Application Integration and Distributed Processing are the same
thing
Constructing information-sharing distributed systems from
diverse sources:
heterogeneous
networked
physically disparate
multi-vendor
Distributed Systems Frameworks
8
常见分布式应用模式
• Client – Server Computing
Client Code
Server Code
Stub
Skeleton
Infrastructure
Client: Thin or Fat?
Distributed Systems Frameworks
9
常见分布式应用模式
 Multi-Tier Systems
Business Logic
User Interface
Persistent Store
 separates persistence from logic and logic from presentation
 all activity originates in user interface
 arrows represent client-server relation
Distributed Systems Frameworks
10
常见分布式应用模式
 Web Applications
Firewall
HTTP Servers
Business
Logic
CGI / Servlets
User Interface
Data Store
 interaction initiated by user
 UI based on HTML, Java, Javascript, etc.
 CGI/Servlet composes HTML, forwards interaction requests to business logic
Distributed Systems Frameworks
11
常见分布式应用模式
 Peer-to-Peer Systems
Application
Message
queue
Persistent Store
User Interface
(mixed initiative)
Monitor
Enterprise Applications
• An architecture where there is no special machine or machines that provide a
service or manage the network resources.
• Instead all responsibilities are uniformly divided among all machines, known as
peers. Peers can serve both as clients and servers.
Distributed Systems Frameworks
12
分布式应用的构成
3 layers of a distributed application:
 network level (TCP/IP, network protocols)
 higher-level services (directory services, security protocols, etc.)
 application level
At the application level:
 processes
 threads
 objects: processes can be made up of one or more objects which can be
accessed by one or more threads within the process
 agents: an “independent” functional element (e.g., in a banking application
we may have a customer agent, a transaction agent, an information
brokerage agent)
Distributed Systems Frameworks
13
分布式应用的一般技术需求
Partitioning and Distributing Data and Functions
data-driven distribution
functional distribution
object-based distribution
Flexible, Extendible Communication Protocols
allocation of tasks to agents has a direct influence on the
complexity of the communication protocol (type of data,
amount of data, persistence of connections)
may also be dictated by legacy systems that need to be
incorporated
Distributed Systems Frameworks
14
分布式应用的一般技术需求
Multi-threading Requirements
server object may need to service multiple remote clients at
once
effective way to optimize resources
Security Requirements
authentication of client identities
define resource access levels
data encryption
Distributed Systems Frameworks
15
分布计算
16

How？
 理想主义：Distributed
Operating System
 现实主义：
 操作系统提供网络通信功能
 （中间件）
 分布应用程序
Institute of Computer Software
Nanjing University
2015/7/20
分布计算
17

Socket programming in Java
// listen to port 5000 on the local host for socket
connection requests
ServerSocket s = new ServerSocket(5000);
while (true) {
// wait for connection request from client
Socket clientConn = s.accept();
InputStream in = clientConn.getInputStream();
OutputStream out = clientConn.getOutputStream();
// now IO streams are connected to client; do
something with them...
Institute of Computer Software
Nanjing University
2015/7/2017
分布计算
18
// create the socket
InetAddress addr =
InetAddress.getByName(“our.remote.host”);
Socket s = new Socket(addr, 5000);
InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();
// now we have IO streams to remote process;
do something with them...
Institute of Computer Software
Nanjing University
2015/7/2018
分布计算
19

Message Passing Libraries
 PVM
(Parallel Virtual Machine), MPI (Message Passing
Interface)
 Send/Recv, Multicast

Virtual Shared Memory
 OpenMP
Institute of Computer Software
Nanjing University
2015/7/20
分布计算
20

远程过程调用(RPC，Remote Procedure Call)
 让应用程序开发者可以
 象调用本地过程一样调用分布在远程节点上的过程
 将结构化方法用于分布环境
 实现上
– Response 消息传递模式
 provides a function-oriented interface to socket-level
communications (sits on top of the TCP/IP transport layer)
 Request
Institute of Computer Software
Nanjing University
2015/7/20
摘要
21

背景
 Why,



What, How
一般框架
CORBA
Java RMI
Institute of Computer Software
Nanjing University
2015/7/20
General Pattern for Remote Invocation
Client Code
Server Code
Stub
Skeleton
Infrastructure
Call:
 marshal arguments
 convert to network
format
 locate server
 transmit data
Distributed Systems Frameworks
Serve:
 receive data
 convert & unmarshal
 invoke method
 marshal return value
 transmit data
22
Procedural API for Remote Invocation
 DCE (Distributed Computing Environment)
OSF standard for RPC
provides a common set of services
Directory Services--Store the names of resources that are available
within the distributed environment. The Cell Directory Service (CDS)
supports naming within a cell, and the Global Directory Service
(GDS) supports naming across all cells within an enterprise. GDS
implements the X.500 directory service standard.
Distributed File Service (DFS)--An optional DCE service that
provides a seamless file system that operates across all computers
contained within a cell.
Distributed Time Service (DTS)--Used for synchronization.
Security Service--Used for authentication and control access.
DCE Threads--Similar to Java threads. They are lightweight
processes that simplify the design of client/server applications.
Distributed Systems Frameworks
23
分布对象计算（DOC）
24


让应用程序开发者可以象使用本地对象一样使
用远程对象
对象计算模型和分布计算模型的结合
 自然
 decentralized
nature of dist. computing
 encapsulation required by distributed components
 information hiding requirements (location transparency,
security, etc.)
 优越:
Institute of Computer Software
Nanjing University
2015/7/20
分布对象技术
25

Location Transparency
Caller
Machine 1
local
call
Machine 2
remote
call
Implementor
Proxy
Institute of Computer Software
Nanjing University
2015/7/20
分布对象技术
26

Proxy Pattern
Institute of Computer Software
Nanjing University
2015/7/20
分布对象技术
27

Providing the same enhancements to procedural RPC
toolkits that OO languages provide to conventional
procedural languages

实现对象计算的全面支持


encapsulation, interface inheritance, object-based exception
handling
良好的软件组织
promotes separation of interface from implementation (crucial for
scalable distributed applications)
 甚至DbC

Institute of Computer Software
Nanjing University
2015/7/20
Key Advantages of DOC
28

Enabling interworking between applications at a
higher level of abstraction



developing distributed applications using familiar techniques such as
method calls on objects
again, location transparency
Providing a foundation for building higher-level
mechanisms that facilitate collaboration among
services in distributed applications

common object services (e.g., global naming, transactional messaging,
quality of service facilities, etc.)
Institute of Computer Software
Nanjing University
2015/7/20
分布对象计算
29

实现分布对象计算的几个核心概念
 接口
 对象引用
 参数传递
 相关服务设施
 底层通信协议
Institute of Computer Software
Nanjing University
2015/7/20
显式、抽象的对象接口定义
30


allow clients to access objects regardless of implementation details
allow object server flexibility in implementing objects


platform-independent specification languages



existing services may be incorporated via wrappers
interface descriptions can be converted into server skeletons which can
be compiled and implemented in any language
some object interfaces also generate client stub interfaces.
Examples:


CORBA: Interface Definition Language (IDL)
DCOM: Component Object Model language
Institute of Computer Software
Nanjing University
2015/7/20
远程对象引用
31

对象通过相互引用来通信
 本地对象引用：仅在当前地址空间有效
 运行系统维护；

远程对象引用
 不同地址空间？
 异构？
 生命周期？

需要某种“对象管理器”来支持、维护之
Institute of Computer Software
Nanjing University
2015/7/20
对象管理器（Object Manager）
32
The core of a distributed object system
 Manages object skeletons and object references on the
server
 E.g., Object Request Broker (ORB) in CORBA or Registry
Service in RMI
 When a client requests a new object, the object manager





locates the skeleton for the class of the requested object
creates new instance based on skeleton
stores new object in the object storage
sends a reference to the new object back to the client
Institute of Computer Software
Nanjing University
2015/7/20
对象管理器
33
Remote method calls by clients are routed by object
manager to the proper object on the server
 Object manager may also destroy objects after clients are
done
 Some other possible features of OM



dynamic object activation/deactivation
persistent objects
Institute of Computer Software
Nanjing University
2015/7/20
Registration / Naming Service
34
Acts as an intermediary between the object client and the
object manager
 Once the interface to an object is defined, an
implementation of the interface must be registered with the
service so that it can be addressed by clients
 Through the naming service the client can specify



the type of the object it needs
or the name of a particular object, if it already exists
Institute of Computer Software
Nanjing University
2015/7/20
对象通信协议
35
General protocol for handling remote object requests
 Must support a means of transmitting and receiving object
and method references, and data in the form of objects or
basic data types
 Ideally should be transparent to clients


should interact with local object proxies (stubs) and let the object
distribution scheme handle communication behind the scenes
Institute of Computer Software
Nanjing University
2015/7/20
分布计算的一般框架
36
Registration
Service
Object
Skeleton
Object
Storage
Server
Implementation
Object
Interface
Specification
IDL Compilers
Object Manager
Naming Service
Client Stub
Interface
Client Application
2015/7/20
运行时刻远程对象交互
37
Server Object
Implementation
Object
Skeleton
4. Object
Interactions
2. Resolve
Object
Object Manager Naming Service
1. Request
Object
Client
Application
3. Object
Handle
Object
Stubs
Institute of Computer Software
Nanjing University
2015/7/20
Comparing DOC Frameworks
38

Distributed Object Computing Frameworks



CORBA - Common Object Request Broker Architecture, an industry standard
developed by OMG
DCOM - Microsoft’s Distributed Component Object Model, a descendant of DCE RPC
RMI - Java’s Remote Method Invocation
CORBA
DCOM
RMI
Cross
Platform
Cross
Lang.
Complexity
Client
Server
Portability Portability
Security
yes
yes
medium
high
medium
many options
limited
yes
high
low
low
NT security
yes
no
low
high
high
add-on
Institute of Computer Software
Nanjing University
2015/7/20
摘要
39

背景
 Why,



What, How
一般框架
CORBA
Java RMI
Institute of Computer Software
Nanjing University
2015/7/20
OMG Reference Model Architecture
40
Institute of Computer Software
Nanjing University
2015/7/20
Object Management Architecture
41

Object Services


Domain-independent foundational services for use by
developers of implementation objects
some published services:
 Naming: allows clients to find objects based on names
 Trading: allows clients to find objects based on their properties
 Lifecycle
management
 Event notification
 Transactions
 Security
…
Institute of Computer Software
Nanjing University
2015/7/20
Object Management Architecture
42

Common Facilities
 object
services provide functionality for use by objects,
CORBA facilities provide standards for services used by
applications
 generic functionality needed by many applications (e.g.,
printing, document management, email, etc.)
Institute of Computer Software
Nanjing University
2015/7/20
Object Management Architecture
43

Domain Interfaces
 provide
domain-specific objects for vertical application
domains
 Examples:
Finance, Healthcare, Manufacturing, Telecom,
Electronic Commerce, Transportation

Application Interfaces

Thus not standardized
Institute of Computer Software
Nanjing University
2015/7/20
Common Object Request Broker
Architecture
44


一个典型的分布对象计算架构
The architecture
 对象
Objects and Clients
 接口 OMG IDL
 “对象管理器” ORB
 底层通信协议 IIOP
 其他
Institute of Computer Software
Nanjing University
2015/7/20
45
Institute of Computer Software
Nanjing University
2015/7/20
Overview of CORBA Objects
CORBA Object
<identity, interface, implementation>
CORBA objects differ from typical programming
language objects:
 CORBA objects can be located anywhere on a network.
 CORBA objects (like Java objects) can run on any platform.
 CORBA objects can be written in any of several languages.
CORBA object developers need know nothing of
where their clients will be, what hardware or OS
they will run on, or what language they will be
written in.
 CORBA objects approach universal accessibility.
Distributed Systems Frameworks
46
Overview of CORBA Objects
An object implementation provides the
semantics of the object, usually by defining data
for the object instance and code for the object's
methods. (called a “servant”)
A client of an object has access to an object
reference for the object, and invokes operations
on the object.
 A client knows only the logical structure of the object according to its
interface and experiences the behavior of the object through
invocations.
 Client code has no knowledge of the implementation of the object or
which ORB is used to access the implementation.
Distributed Systems Frameworks
47
Role of OMG IDL
Object Implementation
Side
Client Side
C
COBOL
IDL
IDL
C++
C
IDL
IDL
COBOL
Ada
IDL
IDL
ORB
ORB
IDL
Internet InterORB
Protocol (IIOP)
IDL
Ada
IDL
IDL
IDL
IDL
Small
talk
C++
JAVA
Distributed Systems Frameworks
Small
talk
JAVA
48
OMG IDL
OMG Interface Definition Language (IDL):
mappings for many languages/compilers;
independent of any particular language/compiler;
multiple-inheritance, public interface-structured
specification language;
not for implementation.
primary support for interoperability between static and
dynamic requests mechanisms.
Distributed Systems Frameworks
49
OMG IDL
 IDL Structure
Module
Module auction {
exception NotAllowed {};
a namespace
struct Sale {
int price;
string item;
}
Interface
abstract type
multiple inheritance
Struct
interface Auction {
void bid (in long price)
raises NotAllowed;
}
structured data
}
Distributed Systems Frameworks
50
A Request
A request consists of:
 Target object (target object identified by a unique object reference)
 Operation
 Parameters (the input, output and in-out parameters defined for the
operation; may be specified individually or as a list)
 Optional request context
Client
Object Implementation
Client Proxy
(stub code)
Skeleton
code
Request
ORB
Distributed Systems Frameworks
51
CORBA Framework Elements
Object Request Broker (ORB)
 This is the object manager in CORBA
Mechanisms for specifying interfaces
 Interface Definition Language (IDL) - for static interface definitions
 Dynamic Invocation Interface (DII) - lets clients access interfaces as
first-class objects at run-time from an Interface Repository.
Internet Inter-Orb Protocol (IIOP)
 A binary protocol for communication between ORBs.
 Was added in CORBA 2.0
Distributed Systems Frameworks
52
Object Request Broker (ORB)
 The Object Manager in CORBA
 Both on the client side and the server side (allows user programs
to act as both clients and servers of remote objects)
 On client side the ORB is responsible for
 accepting requests for a remote object
 finding implementation of the object
 accepting client-side reference to the remote object(converted to a language
specific form, e.g., a Java stub object)
 routing client method calls through the object reference to the object
implementation
 On server side the ORB
 lets object servers register new objects
 receives requests from the client ORB
 uses object’s skeleton interface to invoke object’s activation method
 creates reference for new object and sends it back to client
Distributed Systems Frameworks
53
Internet Inter-Orb Protocol (IIOP)
 CORBA specification is neutral with respect to network protocols
 the CORBA standard specifies what is known as the General Inter-ORB Protocol (GIOP)
 GIOP is a high-level standard protocol for communication between ORBs
 not used directly; instead, it is specialized by a particular protocol that would then be
used directly
 Internet Inter-ORB Protocol (IIOP)
 IIOP is the GIOP-based protocol for TCP/IP networks
 As of the 2.0 version of the CORBA specification, vendors are required to implement the
IIOP protocol
 CORBA Networking Model
 CORBA applications are built on top of GIOP-derived protocols such as IIOP
 these protocols, in turn, rest on top of TCP/IP, DCE, or other underlying transport
protocol the network uses
 an application architecture can be designed to use a bridge that would interconnect, for
instance, DCE-based application components with IIOP-based ones.
Distributed Systems Frameworks
54
Passing Objects by Reference
 In a distributed application, there are two possible methods for
an application component to obtain access to an object in
another process:
 When an object is passed by reference, the object itself remains "in place"
while an object reference for that object is passed. Operations on the object
through the object reference are actually processed by the object itself.
 When an object is passed by value, the object's state is copied and passed to its
destination (via object serialization), where a new copy of the object is
instantiated. Operations on that object's copy are processed by the copy, not by
the original object.
 Note: in CORBA, objects are only passed by reference (however, the new
CORBA specifications include facilities for passing objects by value).
Distributed Systems Frameworks
55
Object References
 An Object Reference is the information needed to specify an object
within an ORB.
 The representation of an object reference handed to a client is only valid for the lifetime
of that client.
 The language mapping also provides additional ways to access object references in a
typed way for the convenience of the programmer.
 There is a distinguished object reference, the null reference, guaranteed to be different
from all object references, that denotes no object. In Java, this is a Java null.
 To invoke a CORBA object, you need a reference for the object. There
are two ways to get a reference for a CORBA object:
 from another object, such as a factory or a name service
 from a string that was specially created from an object reference
 Interoperable Object References
 CORBA uses IOR as a “pointer” to a specific instance of a class in a distributed
environment
 encodes host, port, object identity
 may be externalized (using object_to_string)
Distributed Systems Frameworks
56
CORBA Components
 Client stub
 Each stub represents (it is a proxy) an object operation (a possible request) which a client
invokes in a language-dependent manner (e.g., by calling a subroutine which represents
the operation).
 The stubs make calls on the rest of the ORB using interfaces that are private to Java IDL.
 Alternatively, a client may dynamically construct and invoke request objects which can
represent any object operation.
 Implementation Skeleton
 Each skeleton provides the interface through which a method receives a request
(dynamic and static skeletons)
 Object Adapter
 Purpose is to interface an object's implementation with its ORB
 Each object adapter provides access to those services of an ORB (such as activation,
deactivation, object creation, object reference management) used by a particular type of
object implementation.
 ORB Interface
 The interface to the small set of ORB operations common to all objects, e.g., the
operation which returns an object's interface type.
Distributed Systems Frameworks
57
CORBA Components
Object Implementation
Client
Dynamic
Invocation
Client
Stubs
ORB
Interface
Implementation
Skeletons
Object
Adapter
ORB Core
standard interface
Proprietary ORB interface
One interface per object adaptor
Normal call interface
Up call interface
One interface per object operation
Distributed Systems Frameworks
58
Client Side
Clients perform requests using object references.
Clients may issue requests through
object interface stubs (static) or
dynamic invocation interface.
Client
Dynamic
Invocation
Client
Stubs
Distributed Systems Frameworks
ORB
Interface
Clients may access general ORB
services:
• Interface Repository.
• Context Management.
• List Management.
• Request Management.
59
Implementation Side
Implementations receive requests through skeletons (without
knowledge of invocation approach).
Object Implementation
ORB
Interface
Implementation
Skeletons
Object
Adapter
The Object Adapter provides for:
• management of references;
• method invocation;
• authentication;
• implementation registration;
• activation/deactivation.
Distributed Systems Frameworks
60
Static v. Dynamic Invocation
 Static Invocation
 Static interfaces are generated in form of client stubs by the IDL (pre-)
compiler.
 This means that the structure of the object has to be known before hand (at
compile time).
 Allows for better type checking; less runtime overhead; self-documentation.
 Dynamic Invocation
 Dynamic Invocation Interface (DII) allows clients to invoke operations on
remote objects without having access to object stubs (another way to do this
without dynamic invocation is to download static client stubs via a Java applet).
 Clients must discover interface-related information at runtime (e.g., using the
interface repository)
 Servers can offer new services anytime without the need for recompilation on
the client side.
Distributed Systems Frameworks
61
Dynamic Requests
 The Dynamic Invocation Interface (DII) allows clients to
dynamically:





discover objects;
discover objects’ interfaces;
create requests;
invoke requests;
receive responses.
 Major features of Dynamic Invocation Interface:
 requests appear as objects themselves;
 requests are reusable;
 invocation may be synchronous or asynchronous;
 requests may be generated dynamically, statically or in combination approach.
Distributed Systems Frameworks
62
CORBA Interface Repository
 The Interface Repository is a service that provides persistent
objects that represent the IDL information in a form available
at runtime.
 Note: The Java IDL runtime does not include an implementation of an Interface
Repository and one is not generally required by clients at runtime.
 Using the IR, it is possible for a program to encounter an object whose
interface was not known at compile time, yet be able to determine what
operations are valid on the object and make invocation on it.
 Interface Repository provides:
 Dynamic client access to interface definitions to construct a request.
 Dynamic type-checking of request signatures.
 Traversal of inheritance graphs.
 ORB-to-ORB interoperability.
Distributed Systems Frameworks
63
CORBA Implementation Repository
 The Implementation Repository contains information that allows the
ORB to locate and activate implementations of objects.
 Ordinarily, installation of implementations and control of policies
related to the activation and execution of object implementations is
done through operations on the Implementation Repository.
 In addition to its role in the functioning of the ORB, the
Implementation Repository is a common place to store additional
information associated with implementations of ORB objects. (e.g.,
debugging information, administrative control, resource allocation,
security, etc)
 The Implementation Repository supports the implementation of
object servers. It is not needed by clients in order to access servers.
Distributed Systems Frameworks
64
Summary of CORBA Interfaces
Implementation
Installation
IDL Interface
Definitions
Interface
Repository
Accesses
Client
Stubs
Includes
Client
Implementation
Skeletons
Implementation
Repository
Includes
Describes
Object Implementation
 All objects are defined in IDL by specifying their interfaces.
 Object definitions (interfaces) are manifested as objects in the Interface
Repository, as client stubs, and as implementation skeletons.
 Descriptions of object implementations are maintained as objects in the
Implementation Repository.
Distributed Systems Frameworks
65
Summary: CORBA Remote Method Invocation
 Clients use “object interfaces” through language mapping
 Java clients should work on any ORB that supports the Java language bindings.
 Clients can call any object instance remotely, so long as the object instance
implements the interface.
 Clients can call remote objects statically or dynamically
 The server cannot tell whether the client is using static or dynamic invocation.
 Objects are identified using a unique id: Interoperable Object
Reference (IOR)
 CORBA normally passes objects by reference
 IOR was Introduced in CORBA 2.0
 Object references can be converted to strings and back to “live” objects via
ORB interface functions.
Distributed Systems Frameworks
66
摘要
67

背景
 Why,



What, How
一般框架
CORBA
Java RMI
Institute of Computer Software
Nanjing University
2015/7/20
RMI:
Java distributed object model
68


Remote Method Invocation
Java语言之内，充分利用这一点！
 Stub可下载！
 可以传“对象”！
 Garbage

Collection!
传“引用”
 java.rmi.Remote
(RemoteException)
Institute of Computer Software
Nanjing University
2015/7/20
69
Institute of Computer Software
Nanjing University
2015/7/20
作业
70


与DOC（分布对象计算）相比，传统的Socket编
程有什么优势和劣势？为什么需要DOC？
在分布式应用中，在不同进程中传递对象有哪
两种方法？COBRA采用的是哪种？
Institute of Computer Software
Nanjing University
2015/7/20