10/21/2010 1 Distributed Objects & RMI Tham khảo : Dr Simon Blake Chủ đề của bài giảng •Middleware •Interfaces (IDL) •Mô hình đối tượng phân tán (The Distributed Object Model ) •RMI: Remote Method Invocation –Một mở rộng việc gọi method cục bộ để cho phép gọi method từ xa •Middleware –CORBA –COM and DCOM •SOAP Lý do cần học bài này •Chúng ta cần xem xét các chương trình đang thực thi với các tiến trình khác nhau trên các máy tính khác nhau •Các chương trình cần gọi các method trên các tiến trình khác ở trên các áy tính khác •Làm thế nào chúng ta thực hiện điều này cùng với việc bảo đảm các tính chất sau: –Tính mở rộng –Tính trong suốt –Độ tin cậy –Tính an toàn –Tính mở Dẫn nhập •Sockets API được sử dụng để gởi và nhận các lời triệu gọi (simple IO) •Remote Procedure Calls (RPC) –Được thiết kế để cung cấp interface cho các dịch vụ phân tán (từ xa) –Mục tiêu là để tạo sự trong suốt của các dịch vụ đối với lập trình viên –Tuy vậy, cách này không còn phù hợp •Remote Method Invocation (RMI) –Tổ hợp của RPC và hướng đối tượng –Cho phép các đối tượng trong một tiến trình có thể gọi các method của một đối tượng trong một tiến trình khác Middleware •Middleware che dấu/ cung cấp cái gì –Cung cấp sự trong suốt về vị trí: •Một lập trình viên có thể gọi một method mà không cần biết method đó thực sự đang tồn tại ở đâu (cùng máy, khác máy) –Che dấu nghi thức truyền thông bên dưới •UDP hay TCP –Che dấu chi tiết về quá trình marshall tự động –Độc lập với OS –CORBA cho phép các ngôn ngữ lập trình khác nhau có thể “nói chuyện) với nhau •Sử dụng interface definition language (IDL) Interfaces • interface là gì ? –Không phải là GUI –Interface là các phương tiện kết nối hai hệ thống khác nhau 10/21/2010 2 Interfaces private void myCalc(){ System.out.println(sumNumbers(10,10)); System.out.println(sumNumbers(5,7)); } public int sumNumbers(int a, int b){ return a+b; } Here we have a method that sums two integers together And here we have another method that references and calls the above Interfaces •Interfaces –Gọi method mà không cần biết code của nó được viết thế nào –Chỉ cần interface không đổi thì vẫn có thể gọi như cũ private voidmyCalc(){ System.out.println(sumNumbers(10,10)); System.out.println(sumNumbers(5,7)); } public int sumNumbers(inta, int b){ int result = a+b; return result; } Here we have changed the INTERNAL implementation of sumNumbers However, no change is required in the client code as the INTERFACE remained the same Interfaces •Interfaces trong hệ thống thông tin phân tán –Không truyền tham chiếu –Các đối số hoặc là đối số Input hoặc Output •Input đối số chứa các giá trị sẽ được server sử dụng •Output đối số được dùng để server trả giá trị cho client –Việc truy xuẩ trực tiếp là không được phép •Mọi trao đổi thông qua thông điệp (messages) Interfaces •Interfaces trong HTTT phân tán –IDL: Interface Definition Language •Cung cấp một sự thỏa thuận để mô tả interfaces giữa các methods •Bao gồm việc phân biệt giữa tham số Input và Output Interfaces •Một ví dụ về CORBA IDL struct Person { string name; string place; long year; }; Interface PersonList{ readonly attribute string listname; void addPerson(in Person p); void getPerson(in string name, out Person p); long number(); }; Contains marshalling information Interfaces •An example CORBA IDL struct Person { string name; string place; long year; }; Interface PersonList{ readonly attribute string listname; void addPerson(in Person p); void getPerson(in string name, out Person p); long number(); }; And also remote method interfaces 10/21/2010 3 Truyền thông giữa các đối tượng phân tán •The object model –Objects have their own data + their own methods –Objects interact via methods –Objects may allow other objects to access internal data •However in a DIS this is not possible due to non-locality of reference data methods class Mô hình đối tượng phân tán •Trong mô hình đối tượng –Chỉ truy xuất thông qua interfaces –Các đối tượng có thể thực thi trong các tiến trình phân biệt •Các đối tượng phân tán cũng thực thi như các tiến trình độc lập và truyền thông thông qua interfaces •Tuy vậy, trong các tiến trình trong DIS có thể chạy trên các máy khác nhau –Truyền thông có thể thông qua RMI •Trong một DIS một chương trình có thể sử dụng một chuỗi các tiến trình cục bộ hoặc từ xa Các đối tượng phân tán RI A RI = Remote Invocation LI = Local Invocation = an object = a message client RI RI LI LI LI C B E F D G server • Một ví dụ client server The Distributed Object Model •Các đối tượng có thể được định nghĩa để nhận các yêu cầu cục bộ hay từ xa •Để tạo một lời gọi từ xa, người gọi phải có một tham chiếu đối tượng từ xa •Các đối tượng từ xa phải có một interfaces từ xa trong đó xác định rõ các method có thể gọi từ xa The Distributed Object Model •Remote interface example Data Remote object m4 m5 m6 Implementation of methods m1 m2 m3 Remote interface A process A process Mô hình đối tượng phân tán •Extensions to the the Object Model (see slides 12,13) –Object references •Similar to the classic Object Model •+++Uses a remote object reference, essentially analogous to a regular local object reference –Interfaces •Similar to the classic Object Model •+++ defines methods that can be remotely invocated –Actions •Similar to the classic Object Model •+++Actions may require methods from remote objects, these remote objects have to be available –Exceptions •Similar to the classic Object Model •+++There are more reasons to fail and more exceptions, remote process failure, timeouts, etc. –Garbage collection •+++remote garbage collection requires coordination is required between local garbage collectors •Similar to the classic Object Model 10/21/2010 4 RMI (Remote Method Invocation) •RMI được cài đặt thế nào? –RMI tổ hợp nhiều đối tượng và modules •Module truyền thông •Module tham chiếu từ xa •Phần mềm RMI –Proxy –Dispatcher –Skeleton •binder •Garbage collection •Activation mechanisms •And there are more RMI –>>> PICTURE HERE <<< –Client •Chứa các proxies đại diện cho các đối tượng từ xa •Module tham chiếu từ xa •Cũng có thể có một binder đến cấc đối tượng từ xa •Một modue truyền thông –Server •Chứa các skeletons và các dispatchers •Module truyền thông request reply Skeleton, dispatcher for B Remote reference module Remote reference module Proxy For B Communication module BA Ví dụ: đối tượng A tạo một lời gọi từ xa đến đối tượng B RMI •How RMI is implemented –An example of a request request reply Skeleton, dispatcher for B Remote reference module Remote reference module Proxy For B BA Example: Objects A makes a remote method invocation of object B RMI •Module truyền thông –Cái đặt các nghi thức yêu cầu-trả lờ (Request-Reply) dùng trong truyền thông •Module tham chiếu từ xa –Xác định các tham chiếulà cục bộ hay từ xa –Đảm nhiệm việc tạo các tham chiếu đối tượng –Chứa bảng các đối tượng từ xa RMI •Proxy –Làm cho các methods trong suốt với các tiến trình cục bộ –Tham chiếu đối tượng từ xa trực tiếp gởi đến proxy để chuyển chúng đến các method từ xa –proxy sẽ chuyển đổi dữ liệu theo dạng ngoài (marshals) và chuyển đổi kết quả thành dạng dữ liệu trong (un-marshals) –The proxy chứa các interfaces của các methods từ xa và gởi lời gọi đến chúng thông qua các interface này RMI •Dispatcher –Nhận thông điệp từ module truyền thông, chọn và chuyển thông điệp đến đúng skeleton cho đối tượng từ xa •Skeleton –Un-marshals yêu cầu và gọi các method từ xa liên quan –Marshals câu trả lời –Gởi câu trả lời đến Proxy yêu cầu (thông qua module truyền thông) 10/21/2010 5 RMI •Servant – cung cấp cai đặt cho một lớp từ xa. –Chạy trên một tiến trình server process –là một biên nhận cho yêu cầu từ xa phát ra skeleton RMI –An example of a request request reply Skeleton, dispatcher for B Remote reference module Remote reference module Proxy For B BA Example: Objects A makes a remote method invocation of object B RMI •Triệu gọi tỉnh –Các Proxies được tạo trước khi thực hiện sử dụng interfaces từ xa •Triệu gọi động –Thường dùng khi tất cả các methods từ xa là chưa xác định lúc thiết kế –Client cung cấp một tham chiếu đối tượng từ xa (remote object reference), tên method và các đối số –Rồi middleware sẽ xác định đối tuong từ xa nào đươc triệu gọi RMI •Binder –Một service ở client nhận và lưu trữ các tham chiếu đối tượng từ xa •Java RMIregistry, CORBA Naming service –Ánh xạ từ tên đến tham chiếu của đối tượng từ xa –Servers cần đăng ký các dịch vụ đang được cung cấp cho binder •Sever –Có thể chọn thực hiện một thread cho mỗi RMI RMI Activation of remote objects –Active and passive objects •Một Active object là một xuất hện của đối tượng trong một tiến trình thực hiện •Một Passive object là đối tượng hiện thời không hoạt động nhưng có thể kích hoạt –i.e. its Implementation, and marshalled state are stored on disk –Activator có nhiệm vụ •Ghi nhận các passive objects sắn sàng được kích hoạt •Theo vết các vị trí các servers có các đối tượng đã được kích hoạt •Khởi tạo tiến trình xử tên và kích hoạt các đối tượng RMI •Lưu trữ đối tượng bền vững(Persistent object stores) –Một đối tượng sống giữa các lần kích hoạt của các tiến trình được gọi là persistent Object –Lưu trữ trạng thái của một đối tượng ở dạng marshalled (serialised) xuống đĩa •Recall in Java the implements serialisable •Dịch vụ định vị (Location service) –Các đối tượng có thể di chuyển(Migrate)từ hệ thống này đến thệ thống khác –Cần giải pháp để quản lý ánh xạ giữa tham chiếu của đối tượng với vị trí thật của đối tượng 10/21/2010 6 RMI –Distributed garbage collection •Local hosts have their own garbage collectors •Traditionally an object is dead when it is no longer referenced •However, in a DIS a remote method might still reference the object •Java’s solution –Servers keep a list of references –When a client proxy is created addReference to server list –When a client proxy is deleted removeReference from server list Events and Notification •Rationale –Objects can react to changes in other objects –Local event driver applications are common place •Windows is event driven –User events trigger actions (onClick, etc.) •Changes to data might precipitate an update –Distributed event •Similar but needs to account for distribution •Change state of a remote object might require a change in state of other remote objects Events and Notification •Operates using the publish/subscriber pattern –Objects publish a list of events that maybe subscribed too –Subscribers register their interest in those events –The publisher is then responsible for publishing notifications to all of the events subscribers when the event occurs –A notification is an object that represents the event –This scheme helps with heterogeneity •A subscriber simply has to implement an interface to process notifications –Choice of delivery is also important (reliable or unreliable) CORBA •What is it? “CORBA is a middleware that allows application programs to communicate with one another irrespective of their programming languages, their hardware and software platforms, the networks they communicate with and their implementers” [Coulouris et al, 2001] –Sponsored by the OMG (Object Modelling Group) CORBA basics •Key components: –ORBs –IDL –CORBA Services CORBA: Architecture •Key concepts –ORB core –Object adaptor –Skeletons –Client stub/proxies –And some others: •Repositories (implementation & interface) •Dynamic invocation interface •Dynamic interface 10/21/2010 7 CORBA: Architecture •Object Request Broker (ORB) –The ORB allows clients to invoke operations in remote objects –Remote objects are called as CORBA objects but are essentially regular objects wrapped in CORBA IDL –Clients make a request of the ORB –The ORB is responsible for: •locating objects, •activating objects •and communicating client requests to objects CORBA: Architecture CORBA: Architecture •The ORB provides: –Access transparency •Object methods are invoked in the same manner whether they are local or remote to the requesting object –Location transparency •The location of an object is not known and does not need to be known when invoking that object’s methods –Implementation transparency •The way an application is implemented (language, Activation Policy, platform, operating system etc.) is hidden –Distribution transparency •The communications network, specific node - server mappings, and relative locations of communicating objects are hidden CORBA: Architecture •Skeletons –RMI messages are sent via skeletons to appropriate server implementations (known in CORBA as servants) –Skeletons performs un-marshalling and marshalling duties •Client stubs/proxies –Stubs for procedural languages –Proxies used in OO languages –Marshal client arguments of invocations CORBA: Architecture •The Object Adaptor –Bridges the gap between CORBA IDL and programming languages –Its responsibilities: •Creating remote object references for CORBA objects •Dispatching ach RMI via a skeleton •Activating the object CORBA: Architecture •Portable object adaptor (POA) –Separates the creation of CORBA objects from the creation of servants –An object adapter that can be used with multiple ORB implementations –Allows persistent objects - at least, from the client's perspective 10/21/2010 8 CORBA: Architecture •The CORBA Architecture ORB core ORB core Object Adaptor Skeletons Proxy for A Servant AClient program request reply CORBA: Architecture "Distributed Object Computing with CORBA," http://www.cs.wustl.edu/~schmidt/corba-overview.html CORBA: Architecture •Interface repository –Provides similar facilities to Java reflection –Stores information about interfaces for client / server use •Implementation repository –stores information about the object implementations –maps them to the names of object adaptors –Entries contain: • the object adaptor name •the pathname of the object implementation •the hostname and port number of the server CORBA: Architecture •Dynamic implementation interface (DII) –Server interface's) may not have been available at client deployment –Clients can make requests without using stubs/proxies –Client discover services at run-time (using trading service) –ORB plays crucial role supplying interfaces and performing marshalling CORBA: Architecture Dynamic Skeleton Implementations (DSI) –The server side equivalent to DII –A skeleton might not be present on the server in a development environment –This facility allows requests for an object that does not have skeletons on the server –A sever has to allow invocations on the interfaces of the CORBA objects –Examine the contents of the invocation and discover the target object and method. CORBA: IDL •CORBA IDL –Is used to define the remote methods for use by clients –Servers define IDL for the methods that will use the ORB –Server implements the IDL –Clients program to the IDL specification –Provides facilities for defining modules, interface types, attributes and method signatures Interface Stock{ readonly attribute double stockPrice; readonly attribute string stockCode; void getStockPrice(in string stockCode, out double stockPrice); } Defines: 1 method 2 attributes A Server must then implement the method A Client may call the server method using the IDL signature 10/21/2010 9 IDL: more complex 1 exception NoCashException { 2 string reason; 3 }; 4 5 interface Account { 6 readonly attribute double balance; 7 readonly attribute string owner; 8 void add(in double amount); 9 void remove(in double amount) raises (NoCashException); 10 }; 13 module bank { 14 exception OpenException { 15 string reason; 16 }; 17 18 interface Position { 19 void open(in string name,in double init) raises (OpenException); 20 double close(in ::Account account); 21 ::Account get(in string name); 22 }; 23 }; CORBA: Protocols •CORBA Protocols –CORBA GIOP (General Inter ORB Protocol) handles external data using CDR •This provides hardware/software independence –GIOP also handles R-R protocol for different operating systems –IIOP implements R-R protocol of TCP-IP CORBA: remote references •IOR (Inter-Operable References) –Contains: •Interface repository identifier •IIOP •Host domain name •Port number •Adapter name •Object name CORBA: remote references IOR (Inter-Operable Reference) IIOP Host domain name Port number IDL interface type id Protocol & address details Object key Interface repository identifier Adaptor name Object name CORBA: Services •CORBA provides a set of services for use by distributed objects •These include: –Naming service –Security service –Trading service –Transaction and concurrency service –Persistent object service –Event service CORBA: Services •Naming service –The CORBA naming service is essentially it is a binder –Each ORB has an initial naming context –Objects may bind to the initial naming context –Context’s may also exist within the initial naming context –Objects may then bind to sub-context also –Objects are referenced through their context and names Initial naming context A B Initial naming context Sub-context A C D 10/21/2010 10 CORBA: Services •Security service –Essentially this service authenticates principals –Client sends credentials in requests –Upon receipt the server decides whether to process has the right to access the remote object –If sufficient rights exists the server execute the remote invocation –Also ensures non-repudiation and secure communications •Transaction services and concurrency control –Enforces concurrency control into RMI transactions –Uses commit, rollback, and a two-phase commit cycle CORBA: Services •Event Services –This service defines a means for implementing the Publisher/Subscriber pattern (suppliers and consumers in CORBA) –Push: suppliers push events to consumers –Pull: consumers request events from suppliers Supplier Supplier Supplier Event Channel Supplier Supplier Supplier Supplier CORBA: Services •Persistent object service –Each CORBA object is responsible for saving its state when it id de-activated –The POS (Persistent Object Service) provides a means for CORBA objects to save their state –Can use PSDL or persistence transparency technique CORBA: Services •Trading service –Rather than accessing objects by name trading services allow objects to be accessed by attributes –In other words, this service allows clients to access remote objects based on the which of the remote objects is best able to meet the request of the client rather than the client specifying a specific object –Example •If we want to find a plumber we can either use the name of the company •Or some criteria, –Local area=‘london’, service=‘emergency’ Microsoft DDE to DCOM • History – DDE (Dynamic Data Exchange) – OLE (Object Linking and Embedding) – COM (Compound Object Model) – ActiveX – DCOM (Distributed Computing Environment DCE + COM) • We are going to talk briefly about COM and DCOM COM • Its interfaces are defined in IDL • Supports dynamic discovery • Uses Unique component ID mechanism • Invocation from one component to another occurs using virtual tables, known in COM as vtables – Essentially this is just a list of pointers – clients have pointers to the vtable which point to server functions – This is all stored in binary so it is language independent [...]...10/21/2010 COM: interfaces COM: Objects • Interfaces in COM have Globally Unique Identifier (GUID) • Its using the GUID that clients can locate required interfaces – vtable look-up – Vtable is a fast method! COM: Objects • • • • • In COM objects have states and methods Contain code that implements a service Objects can be in different languages Access to objects occurs through defined interfaces... defined interfaces COM supports multiple interfaces for objects DCOM • A COM object must have the IUnknown interface • This provides functions – QueryInterface, AddRef and Release • But a COM object could have more interfaces but must have IUnknown DCOM • Distributed COM (DCOM) extends COM for distributed systems allowing remote calls • Based on Distributed Communication Exchange (DCE) • Can uses proxies... From the: Simple Object Access Protocol (SOAP) 1.1 ©W3C Note 08 May 2000 Conclusions •Middleware •Interfaces (IDL) •The Distributed Object Model RMI: Remote Method Invocation –An extension to local method invocation that allows remote method invocation also •Middleware –CORBA –COM and DCOM •SOAP END 14 . xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <m:GetLastTradePriceDetailed xmlns:m="Some-URI"> <Symbol>DIS</Symbol> <Company>DIS Corp</Company> <Price>34.1</Price> </m:GetLastTradePriceDetailed> </SOAP-ENV:Body> </SOAP-ENV:Envelope> From. nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Header> <t:Transaction xmlns:t="some-URI" xsi:type="xsd:int" mustUnderstand="1"> 5 </t:Transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m="Some-URI"> <Price>34.5</Price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> From. mustUnderstand="1"> 5 </t:Transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m="Some-URI"> <Price>34.5</Price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> From