postech dpe lab corba: architecture, concepts and s/w development j. won-ki hong distributed...
TRANSCRIPT
POSTECH DPE Lab
CORBA: Architecture, Concepts and
S/W Development
J. Won-Ki HongDistributed Processing Environment Lab
Dept. of Computer Science and EngineeringPOSTECH
Pohang, KoreaTel: +82-562-279-2244
Fax: +82-562-279-5663
Email: [email protected]
http://www.postech.ac.kr/~jwkhong
2
POSTECH DPE Lab
Introduction
3
POSTECH DPE Lab
The Problem• Today’s computing, telecommunication and service
environments are inherently distributed and heterogenous– inter-networked computing and telecommunication devices
running different operating systems
• Distributed applications are needed in most areas– banking, retail, education, medical, government,
telecommunication, management, etc.
• Developing distributed applications whose components collaborate efficiently, reliably, transparently and scalably is very hard
4
POSTECH DPE Lab
Existing tools (Sockets, ONC, DCE) are too low-level; do not offer a unified view of all distributed applications.
Existing Tools?
• A major problem stands in the way:– There is no single, commercially available, widely
recognized & standardized integration approach and framework
5
POSTECH DPE Lab
Distributed Object Technology
• It is widely believed that an approach based on distributed object technology simplifies the problem:– offers a single view of a distributed, heterogeneous
system– three key concepts in object technology help
integration of distributed systems:• Encapsulation
• Inheritance
• Polymorphism
6
POSTECH DPE Lab
Candidate Solution: CORBA
Goals:
• Simplify development of distributed applications
• Provide flexible foundation for higher-level services
7
POSTECH DPE Lab
CORBA Overview
8
POSTECH DPE Lab
Contents
• Background & History• Object Management Architecture (OMA)• CORBA Architecture• Internet Inter-ORB Protocol (IIOP)• CORBA Services• CORBA Facilities• CORBA Implementations
9
POSTECH DPE Lab
Background & History• Object Management Group's (OMG) answer to the
need for interoperability among the rapidly proliferating number of hardware and software products available today
• CORBA Specification Version 1.1 in 1991– failed to provide out-of-box multi-vendor interoperability
among ORB implementations
• CORBA 2.0 in December 1994– defines true interoperability by specifying how ORBs from
different vendors can interoperate.
10
POSTECH DPE Lab
• Non-profit Consortium based in US, with representations in UK, Japan & Germany
• Founded in April 1989• Dedicated to creating and popularizing object-
oriented standards for application integration based on existing technology
• Object World subsidiary for market studies, training, seminars and conferences
• No internal development carried out• Over 500 members from around the world
Object Management Group
11
POSTECH DPE Lab
Object Management Architecture (OMA)
• A high-level vision of a complete distributed environment
• System Oriented Components – Object Request Broker (ORB)– Common Object Services
• Application Oriented Components– Application Objects– Common Facilities
12
POSTECH DPE Lab
Object Request Broker
Application Objects
Common Facilities
Vertical Common Facilities
Horizontal Common Facilities
UserInterface
InformationManagement
SystemsManagement
TaskManagement
Naming Persistence Life Cycle Properties Concurrency Collections Security Trader
Externalization Events Transactions Query Relationships TimeChange
ManagementLicensing
Common Object Services
13
POSTECH DPE Lab
OMA Components (1)
• Object Request Broker (ORB)– The mechanism and interfaces that enables objects to make
requests and receive responses.– Provides an infrastructure allowing objects to converse,
independent of the specific platforms and techniques used to implement the objects.
• Application Objects– specific end-user client/server applications
14
POSTECH DPE Lab
OMA Components (2)• Common Object Services
– A collection of services for maintaining objects
– Interfaces are provided to create objects, to control access to objects, to keep track of relocated objects, and to control the relationship between objects
– Event Notification, Persistence, Lifecycles, Naming, Concurrency Control, Relationships, Transactions, Collections, Externalization, Time, Security, Query Service, Licensing, Trading, Change Management, Properties, etc.
– Much of these services are currently being defined
15
POSTECH DPE Lab
OMA Components (3)• Common Facilities
– a set of generic application functions that can be configured to the specific requirements of a particular application
• e.g., printing, document management, database, and electronic mail facilities
– Horizontal Common Facilities • User Interface
• Information Management
• Systems Management
• Task Management
– Vertical Common Facilities support various vertical market segments:
• Healthcare, Retailing, CAD, etc.
– Much of these services are currently being defined
16
POSTECH DPE Lab
OMG Object Model• Underlying specification for all OMG compliant
technologies• The goal is to support interoperability and application
portability• Provides the semantics that define the interfaces that
are used to interact with the object• The basic core concepts of Object Model:
– Objects: instances of types– Operations: the actions that can be performed on data in
objects and are defined by a signature (name, parameters)– Subtyping: defining a type via inheritance
17
POSTECH DPE Lab
Common Object Request Broker Architecture (CORBA)
• An OMA-compliant ORB specification of an architecture and interface that allows an application to make request of objects (servers) in a transparent, independent manner, regardless of platform, operating system or location considerations
• Based on the OMG Object Model
18
POSTECH DPE Lab
CORBA Architecture
19
POSTECH DPE Lab
CORBA Components (1)• Object Implementation• Client• Object Request Broker (ORB) Core• ORB Interface• CORBA IDL Stubs & Skeletons• Dynamic Invocation Interface (DII)• Dynamic Skeleton Interface (DSI)• Object Adapter• Interface Repository• Implementation Repository
20
POSTECH DPE Lab
CORBA Components (2)
• Object Implementation– defines operations that implement a CORBA IDL interface.– can be written in a variety of languages including C, C++,
Java, Smalltalk, and Ada
• Client – the program entity that invokes an operation on an object
implementation
• Object Request Broker (ORB) – provides a mechanism for transparently communicating
client requests to target object implementations– makes client requests appear to be local procedure calls
21
POSTECH DPE Lab
CORBA Components (3)
• ORB Interface– an abstract interface for an ORB– de-couples applications from implementation details– provides various helper functions such as converting object
references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface
• CORBA IDL Stubs & Skeletons– the static interface between client and server– generated by an IDL compiler
22
POSTECH DPE Lab
CORBA Components (4)
• Dynamic Invocation Interface (DII)– allows a client to directly access the underlying request
mechanisms provided by an ORB
• Dynamic Skeleton Interface (DSI)– the server side's analogue to the client side's DII– allows an ORB to deliver requests to an object implementation
that does not have compile-time knowledge of the type of the object it is implementing
• Object Adapter – provides the run-time environment for instantiating server obje
cts, passing requests to them, and assigning them object references
23
POSTECH DPE Lab
CORBA Components (5)
• Interface Repository– a run-time database that contains machine-readable version
s of the IDL-defined interfaces
• Implementation Repository– a run-time repository of information about the classes a serv
er supports, the objects that are instantiated, and their IDs
24
POSTECH DPE Lab
CORBA Inter-ORB Architecture
25
POSTECH DPE Lab
Interoperability Protocols
• General Inter-ORB Protocol (GIOP)– specifies request format and transmission protocol that
enables ORB-to-ORB interoperability
• Internet Inter-ORB Protocol (IIOP)– specifies a standardized interoperability protocol for the
Internet– works directly over TCP/IP, no RPC necessary– can be used with any transport mechanism that meets
certain requirements
• Environment-specific inter-ORB protocols (ESIOPs)– e.g., DCE
26
POSTECH DPE Lab
CORBA Implementations (1)• IONA Orbix, OrbixWeb
– http://www.iona.org• Digital ObjectBroker
– http://www.digital.com/info/objectbroker/• IBM DSOM
– http://www.software.ibm.com/ad/somobjects/• Expersoft CORBAplus
– http://www.expersoft.com/Products/products.htm• HP ORB+
– http://www.hp.com/gsy/orbplus.html• CHORUS/COOL
– http://www.chorus.com/Products/Cool/index.html• Visigenic VisiBroker
– http://www.visigenic.com/prod/vbrok/vb30DS.html
27
POSTECH DPE Lab
CORBA Implementations (2)• Sunsoft NEO
– http://www.sun.com/software/neo/• Netscape Internet Service Brokers
– http://developer.netscape.com/one/corba/• Object-Oriented Concepts, Inc. OmniBroker
– http://www.ooc.com/ob.html• Olivetti & Oracle Research Laboratory OmniORB2
– http://www.orl.co.uk/omniORB/omniORB.html• Object-Oriented Technologies Ltd. DOME
– http://www.netlink.co.uk/users/oot/dome-index.html• ICL Inc. DAIS
– http://www.iclsoft.com/sbs/daismenu.html
28
POSTECH DPE Lab
IONA’s Orbix (1)• General Features
– Orbix 1.0 (93), 2.0 (95), 2.2 (97), 2.3 (Nov. 97)– Supports C++ binding– Runs on multiple OSs (Windows 3.1, Windows 95, Windows
NT & most Unix platforms) – TCP/IP, socket(WinSock), ONC-RPC– Provides the Implementation of CORBA services
• OrbixTalk, OrbixNames, OrbixEvents, OrbixTrader, OrbixOTS, OrbixSecurity, OrbixManager
– http://www.iona.com/
29
POSTECH DPE Lab
IONA’s Orbix (2)• Integration
– Orbix for Windows: integration with Microsoft OLE & ActiveX– OrbixWeb: a full Java implementation of Orbix– Integration with Peerlogic's PIPES, Black & White Software's
UIM, Objectstore, Versant, ODAF and more.– Orbix-Isis: integration Isis Reliable run-time technology for
reliable distributed computing
• Orbix CORBA Extensions– C++ class libraries as a framework for programming– Filter: mechanism to attach one or more callback functions
to different ORB events– Smart Proxy: normal proxy(marshal) + filters(cache,
callbacks) to extend or customize
30
POSTECH DPE Lab
Digital’s ObjectBroker• General Features
– V2.7 is compliant with the CORBA 1.2 specification and parts of the CORBA 2.0 specification (including the Initialization Service)
– TCP/IP, DECnet, socket, (DCE RPC, MS COM, DECmessageQ) (DCE & Kerberos)
• Includes– Implementation Mapping Language (IML)– Method Mapping Language (MML)– Dynamic Data Exchange (DDE), Object Linking and
Embedding (OLE) interfaces• http://www.digital.com/info/objectbroker/
31
POSTECH DPE Lab
IBM’s DSOM
• SOMobject (System Object Model object)– provides an object-structured protocol that allows
applications to access objects, regardless of the programming language and regardless of where the object resides
• DSOM (Distributed SOM)– a distributed framework which ships with the SOMobjects
Toolkit and a CORBA-compliant ORB
• SOM 3.0 for AIX, OS/2 and Windows NT is freely available at http://www.software.ibm.com/ad/somobjects/
32
POSTECH DPE Lab
Expersoft CORBAplus• General Features
– CORBA 2.0 compliant ORB– available for Windows 95/NT, Solaris, HP-UX and AIX
• CORBAplus, Enterprise Edition– integration between a CORBA-based ORB and message-
oriented middleware (MOM)
• CORBAplus, Java Edition– Java/CORBA integration
• CORBAplus, ActiveX Bridge– creates a bridge from CORBA to COM (Windows apps)
• CORBAplus, Transaction Service• http://www.expersoft.com/Products/CORBAC/corbac.htm
33
POSTECH DPE Lab
Chorus’s CHORUS/COOL
• General Features– a CORBA 2.0 compliant ORB for distributed real-time
embedded systems– Optimized on CHORUS products– Supports Windows NT, Windows 95, SCO OpenServer5,
Solaris, SunOS, AIX 2.3, CHORUS/ClassiX 3.1, HP/UX, Linux 1.2
• CHIC: CHORUS IDL Compiler• CHORUS/COOL ORB 4.1 is freely available at
http://www.chorus.com/Products/Cool/index.html
34
POSTECH DPE Lab
S/W Development with CORBA
35
POSTECH DPE Lab
Contents
• CORBA Interface Definition Language (IDL)• Application Development Steps using CORBA• Servers Launching Modes• Web-based Application Development using
Java/CORBA
36
POSTECH DPE Lab
CORBA IDL (1)• Used to specify the interfaces (operations and data)
of an object• Not a programming language itself• Provides no implementation details• IDL compilers are used to compile IDL definitions and
generate language specific client and server stubs• Actual body of client and server applications are
written in ordinary programming languages (C, C++, Java, Smalltalk, etc.)
37
POSTECH DPE Lab
CORBA IDL (2)• Basic Types: long, unsigned long, short, unsigned short, float,
double, octet, char, boolean, any• Constructed Types: structure, discriminated union• Template Types : sequence, string, array• Interface
– Inheritance Specification– Type Declaration– Constant Declaration– Exception Declaration– Attribute Declaration– Operation Declaration
• Module (can be nested any number of times)– Type, Constant, and Exception Declaration– Interface Declaration– Module Declaration
38
POSTECH DPE Lab
An IDL Specification
// IDL in file grid.idl
interface Grid {
readonly attribute short height;
readonly attribute short width;
void set (in short n, in short m, in long value);
long get (in short n, in short m);
};
39
POSTECH DPE Lab
Application Development Steps using CORBA
1. Allocate Tasks
2. Define Remote Object Interfaces
3. Implement Remote Objects
4. Generate Client Stubs
5. Obtain Remote Object References
6. Invoke Remote Methods
7. Configure the System
40
POSTECH DPE Lab
From IDL to Executables
41
POSTECH DPE Lab
Allocate Tasks
• Decide how to allocate responsibilities• Client Side: UI & user input error checking• Server Side: shared resources, software that controls
access to the resources• Multi-threading allows the user some GUI interaction
event while a remote invocation is pending
42
POSTECH DPE Lab
Define Remote Object Interfaces
• Using IDL, define interfaces in terms of the operations that clients can invoke on the remote objects
interface cMSO : ObjectMIO { boolean get_attr(in Token my_token,
in SOID so_id, in OID oid, out AttrType attr) raises (InvalidSOID);
}
43
POSTECH DPE Lab
• IDL compiler generate some of the remote object’s server program (skeleton) which includes – definitions for the types defined in the IDL – codes for dispatching incoming requests– the empty bodies of the methods
CORBA::Boolean cMSO_i::get_attr (CORBA::Long my_token,SOID so_id,const char* oid, AttrType*& attr,
CORBA::Environment &IT_env) {// implementation body goes here
}
Implement Remote Objects (1)
44
POSTECH DPE Lab
Implement Remote Objects (2)• Implement the source code of these methods to
provide the remote object’s capabilities• Build a server program which activates a server
– e.g., using CORBA Basic Object Adapter (BOA)
int main() {MIO_i *mio_ptr = new MIO_i("cMSO", "tigris", 1.2);
cMSO_var cmso_ptr = new cMSO_i(mio_ptr);try {
CORBA::Orbix.impl_is_ready("cMSO");} catch (CORBA::SystemException &sysEx) { cerr << "Unexpected system exception" << endl; cerr << &sysEx;}
}
45
POSTECH DPE Lab
Generate Client Stubs• Use IDL compiler to generate client-side stub• Write a client program which invokes the remote
object interfaces• Stub relays an invocation to the real remote object
via ORB
CORBA::Boolean cMSO:: get_attr (Token my_token,SOID so_id, const char * oid, AttrType*& attr, CORBA::Environment &IT_pEnv)
throw (CORBA::SystemException,cMSO::InvalidSOID) {
{// compiler generated stub code here
}
46
POSTECH DPE Lab
Obtain Remote Object References• Obtain a reference to an instance of the remote
object’s class• Suggested mechanisms
– object_to_string(), string_to_object(): convert ORB-specific object references to a standard string form and vice-versa
– Naming Service Interface: allows remote object servers to register their objects by name
try { cmso_var = cMSO::_bind(":cMSO", host_name); } catch (CORBA::SystemException &sysEx) { cerr << "Unexpected system exception" << endl;
cerr << &sysEx; }
47
POSTECH DPE Lab
Invoke Remote Methods
• Invoke methods on an object as if it were a local object• Stub handles all of the transport-level messaging and
data marshaling
try { cmso_var->get_attr(my_token, so_id, buffer, attr); } catch (const cMSO::InvalidSOID& userEx) { cerr << "Invalid Server ID" << endl;
cerr << &userEx; } catch (CORBA::SystemException &sysEx) { cerr << "Unexpected system exception" << endl;
cerr << &sysEx; }
48
POSTECH DPE Lab
Configure the System
• Check if an ORB daemon is running on the server host
• Install the remote server program on the server host• Make its object reference available• Install the compiled stub class files and a client
program on each client host
49
POSTECH DPE Lab
Servers and Implementation Repository
• Each server has a name, unique within its host machine.
• The name of an object (object reference) contains:– A unique name within its server (object's marker)– Its server name (implementation name)– The host name of its server
• Implementation Repository maintains a mapping from a server's name to the file name of the executable code which implements that server --> the developer of the server must register it
50
POSTECH DPE Lab
Modes for Launching Servers
• Shared Mode– at most one process for any given server
• Unshared Mode– one process per active object
• Per-method-call Mode– a separate process for each operation call
• Persistent Mode– always active (i.e., not started by Object Adaptor)
51
POSTECH DPE Lab
Distributed Applications
Development using Java/CORBA
52
POSTECH DPE Lab
Introduction of CGI vs. Java/CORBA for Web-based applications
• Various applications are being developed and used in Internet/Intranet environments
• WWW Common Gateway Interface (CGI) has been used widely for providing simple Web-based client/server applications
• WWW, Java and CORBA can provide a powerful set of tools for developing and deploying distributed applications
• Java applets for WWW-downloadable client software and CORBA objects for server software
53
POSTECH DPE Lab
WWW CGI-based Application
Display request form
Display requests
WWW browser
User host
WWW browser
User host
WWW server
Spawn CGI program
CGI
Program
Server host
Resulting HTML file
HTTP:Request URL
HTTP:Download HTML with forms
HTTP:Request URL of CGI program
HTTP:Download HTML with results
54
POSTECH DPE Lab
WWW Java/CORBA-based Application
Display request form
Display requests
WWW browser
User host
WWW browser
User host
WWW server
Server hostHTTP: Request URL of applet
HTTP: Download executable applet code
CORBA: Server method invocationCORBA: method result return
Javaapplet
RemoteCORBAObject
RemoteCORBAObject
RemoteServer
55
POSTECH DPE Lab
CGI vs. JAVA/CORBA ApproachCGI Java/CORBA
Flexibility UI and operations definitions arecoupled in HTML forms.
Client limited to displaying UIand invoking remote operations.
Remote operation argumentsare string only; no structuredtypes.
UI and remote operations aredefined separately.
Client may perform other tasks inaddition to managing UI andinvoking remote operations.
Remote operation arguments maybe of any type, including structured.
Maintainability Changes to an HTML form mustbe manually accounted for in itscorresponding CGI program.
Changes to IDL can beautomatically propagated to bothclient and server via output of IDLcopiler.
ServerConfiguration
HTML files are installed on theWWW server host.
A CGI program is written tohandle one distinct remoteoperation.
The WWW server spawns a newCGI program instance to handleeach remote invocation.
Java applet client software isinstalled on the WWW server host.
A remote object server programmay be written to handle manydistinct remote operations.
A single remote object serverinstance may handle many remoteinvocations.
56
POSTECH DPE Lab
CGI vs. JAVA/CORBA ApproachCGI Java/CORBA
ClientDeployment
Automatic, on demand, viaWWW Platform independent.
Automatic, on demand, via WWWPlatform independent.
User InterfaceIntuitiveness
Developer has limited controlover UI component layout.
Developer limited to using HTMLINPUT tag components.
Developer has broad control overUI component layout.
Developer may create newcomponents with available ones.
Responsiveness Simple UI update requires downloading a new HTML files.
Each remote invocation isslowed by the spawning of a CGIprogram.
Each remote invocation slowedby acquisition of neededresources.
Client is single-threaded.
Simple UI updates are handled bythe client applet.
Each remote invocation may behandled by an already executingserver program.
Remote object server may alreadyhave acquired needed resourcewhen remote invocation arrives.
Client can exploit multi-threading.
57
POSTECH DPE Lab
Application Development Steps using Java/CORBA
• The development steps are almost identical to using CORBA only1. Allocate Tasks
2. Define Remote Object Interfaces
3. Implement Remote Objects
4. Generate Remote Object Proxies
5. Obtain Remote Object References
6. Invoke Remote Methods
7. Configure the System
• The differences are in steps 4 and 7
58
POSTECH DPE Lab
Generate Remote Object Proxies• Use IDL-to-Java compiler to generate client-side
proxy class (stub)– e.g., OrbixWeb IDL compiler
• Proxy relays an invocation to the real remote object via ORB
public boolean get_attr ( int my_token, short so_id,
String oid, MSO.AttrType attr) throws MSO._cMSO.InvalidSOID,
IE.Iona.Orbix2.CORBA.SystemException {
// compiler generated Java stub code here }
59
POSTECH DPE Lab
Configure the System
• Install the remote server program on the server host• Make its remote object’s reference available• Install the compiled Java class files of each client
applet on the WWW server host• Install an HTML file for each applet on the WWW
server host• User sites need not install any executable or data
files other than those for a Java-enabled browser
60
POSTECH DPE Lab
Summary• CORBA is more than a “hype”• Most widely-used distributed object technology today• Applications
– building distributed systems and applications– telecommunication network & management software– many other areas (such as healthcare, banking/finance, retail,
and transportation) are beginning to use CORBA
• WWW, Java and CORBA combination can provide a powerful set of tools for developing and deploying distributed applications
• Future Work– defining more object services – work on light-weight, lean, efficient ORBs– development & experience of more diverse applications
61
POSTECH DPE Lab
Useful References[1] OMG CORBA Documents, “http://www.omg.org/library/schedule/Technology_Adoptions.htm”
[2] Jon Siegel, CORBA, Fundamentals and Programming, Wiley Computer Publishing Group, 1996.
[3] R. Orfali, D. Harkey and J. Edwards, The Essential Distributed Objects, Survival Guide, John Wiley & Sons, Inc., 1996.
[4] Java CORBA Integration Strategies, “http://nittany.ca.sandia.gov:8001/java.corba.html”.
[5] CORBA for Beginners, “http://www.omg.org/news/begin.htm”.
[6] schmidt’s CORBA page (Overview, Tutorial, Papers, Researches, Product, Real-time ORB), “http://www.cs.wustl.edu/~schmidt/corba.html”.
[7] Inter Domain Management, “http://www.bell-labs.com/user/mazum/recent_work.html”.
[8] CORBA and OMG Information Resources, “http://www.acl.lanl.gov/CORBA/”.
[9] Real-time CORBA with TAO (The ACE ORB), “http://www.cs.wustl.edu/~schmidt/TAO.html”.
[10] CORBA software, “http://www.infosys.tuwien.ac.at/Research/Corba/software.html”.
[11] CORBA FAQ, “http://www.cerfnet.com/~mpcline/corba-faq/toc-alphabetical.html”.
[12] CORBA Interoperability, “http://mordor.cs.hut.fi/~kta/corba-interop/”.
[13] CorbaMan, “http://amazon.postech.ac.kr/CorbaMan”.
[14] CORBA Object Trader Service, “http://amazon.postech.ac.kr/trader.html”.
[15] MAESTRO, “http://amazon.postech.ac.kr/maestro”.
[16] Web-based Management, “http://amazon.postech.ac.kr/wbm”.