POSTECH DPE Lab CORBA Architecture Concepts and SW

POSTECH DPE Lab CORBA: Architecture, Concepts and S/W Development J. Won-Ki Hong Distributed Processing Environment Lab Dept. of Computer Science and Engineering POSTECH Pohang, Korea Tel: +82 -562 -279 -2244 Fax: +82 -562 -279 -5663 Email: jwkhong@postech. ac. kr http: //www. postech. ac. kr/~jwkhong

POSTECH DPE Lab Introduction 2

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 3

POSTECH DPE Lab Existing Tools? • A major problem stands in the way: – There is no single, commercially available, widely recognized & standardized integration approach and framework Existing tools (Sockets, ONC, DCE) are too low-level; do not offer a unified view of all distributed applications. 4

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 5

POSTECH DPE Lab Candidate Solution: CORBA Goals: • Simplify development of distributed applications • Provide flexible foundation for higherlevel services 6

POSTECH DPE Lab CORBA Overview 7

POSTECH DPE Lab Contents • • Background & History Object Management Architecture (OMA) CORBA Architecture Internet Inter-ORB Protocol (IIOP) CORBA Services CORBA Facilities CORBA Implementations 8

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. 9

POSTECH DPE Lab Object Management Group • Non-profit Consortium based in US, with representations in UK, Japan & Germany • Founded in April 1989 • Dedicated to creating and popularizing objectoriented 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 10

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 11

POSTECH DPE Lab Common Facilities Vertical Common Facilities Horizontal Common Facilities Application Objects User Interface Information Management Systems Task Management Object Request Broker Naming Persistence Life Cycle Externalization Events Properties Transactions Concurrency Collections Query Relationships Common Object Services Time Security Trader Change Licensing Management 12

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 13

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 14

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 15

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 16

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 17

POSTECH DPE Lab CORBA Architecture 18

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 19

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 20

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 21

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 objects, passing requests to them, and assigning them object references 22

POSTECH DPE Lab CORBA Components (5) • Interface Repository – a run-time database that contains machine-readable versions of the IDL-defined interfaces • Implementation Repository – a run-time repository of information about the classes a server supports, the objects that are instantiated, and their IDs 23

POSTECH DPE Lab CORBA Inter-ORB Architecture 24

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 25

POSTECH DPE Lab CORBA Implementations (1) • IONA Orbix, Orbix. Web – http: //www. iona. org • Digital Object. Broker – 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 Visi. Broker – http: //www. visigenic. com/prod/vbrok/vb 30 DS. html 26

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. Omni. Broker – http: //www. ooc. com/ob. html • Olivetti & Oracle Research Laboratory Omni. ORB 2 – http: //www. orl. co. uk/omni. ORB. 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 27

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(Win. Sock), ONC-RPC – Provides the Implementation of CORBA services • Orbix. Talk, Orbix. Names, Orbix. Events, Orbix. Trader, Orbix. OTS, Orbix. Security, Orbix. Manager – http: //www. iona. com/ 28

POSTECH DPE Lab IONA’s Orbix (2) • Integration – Orbix for Windows: integration with Microsoft OLE & Active. X – Orbix. Web: 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 29

POSTECH DPE Lab Digital’s Object. Broker • General Features – V 2. 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, DECmessage. Q) (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/ 30

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/ 31

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 messageoriented middleware (MOM) • CORBAplus, Java Edition – Java/CORBA integration • CORBAplus, Active. X Bridge – creates a bridge from CORBA to COM (Windows apps) • CORBAplus, Transaction Service • http: //www. expersoft. com/Products/CORBAC/corbac. htm 32

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 Open. Server 5, Solaris, Sun. OS, AIX 2. 3, CHORUS/Classi. X 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 33

POSTECH DPE Lab S/W Development with CORBA 34

POSTECH DPE Lab Contents • • CORBA Interface Definition Language (IDL) Application Development Steps using CORBA Servers Launching Modes Web-based Application Development using Java/CORBA 35

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. ) 36

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 37

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); }; 38

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 39

POSTECH DPE Lab From IDL to Executables 40

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 41

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 c. MSO : Object. MIO { boolean get_attr(in Token my_token, in SOID so_id, in OID oid, out Attr. Type attr) raises (Invalid. SOID); } 42

POSTECH DPE Lab Implement Remote Objects (1) • 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 c. MSO_i: : get_attr ( CORBA: : Long my_token, SOID so_id, const char* oid, Attr. Type*& attr, CORBA: : Environment &IT_env) { // implementation body goes here } 43

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("c. MSO", "tigris", 1. 2); c. MSO_var cmso_ptr = new c. MSO_i(mio_ptr); try { CORBA: : Orbix. impl_is_ready("c. MSO"); } catch (CORBA: : System. Exception &sys. Ex) { cerr << "Unexpected system exception" << endl; cerr << &sys. Ex; } } 44

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 c. MSO: : get_attr (Token my_token, SOID so_id, const char * oid, Attr. Type*& attr, CORBA: : Environment &IT_p. Env) throw (CORBA: : System. Exception, c. MSO: : Invalid. SOID) { { // compiler generated stub code here } 45

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 = c. MSO: : _bind(": c. MSO", host_name); } catch (CORBA: : System. Exception &sys. Ex) { cerr << "Unexpected system exception" << endl; cerr << &sys. Ex; } 46

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 c. MSO: : Invalid. SOID& user. Ex) { cerr << "Invalid Server ID" << endl; cerr << &user. Ex; } catch (CORBA: : System. Exception &sys. Ex) { cerr << "Unexpected system exception" << endl; cerr << &sys. Ex; } 47

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 48

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 49

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) 50

POSTECH DPE Lab Distributed Applications Development using Java/CORBA 51

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 52

POSTECH DPE Lab WWW CGI-based Application Display request form User host WWW browser Server host HTTP: Request URL HTTP: Download HTML with forms HTTP: Request URL of CGI program WWW server HTTP: Download HTML with results Display requests Spawn CGI program User host WWW browser Resulting HTML file CGI Program 53

POSTECH DPE Lab WWW Java/CORBA-based Application Display request form Display requests User host WWW browser Java applet Server host HTTP: Request URL of applet HTTP: Download executable applet code COR BA: S erver COR BA: User host meth od re od in voca tion sult retur n WWW server Remote Server Remote CORBA Object WWW browser 54

POSTECH DPE Lab CGI vs. JAVA/CORBA Approach 55

POSTECH DPE Lab CGI vs. JAVA/CORBA Approach 56

POSTECH DPE Lab Application Development Steps using Java/CORBA • The development steps are almost identical to using CORBA only 1. 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 57

POSTECH DPE Lab Generate Remote Object Proxies • Use IDL-to-Java compiler to generate client-side proxy class (stub) – e. g. , Orbix. Web 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. Attr. Type attr) throws MSO. _c. MSO. Invalid. SOID, IE. Iona. Orbix 2. CORBA. System. Exception { // compiler generated Java stub code here } 58

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 59

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 60

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] Corba. Man, “http: //amazon. postech. ac. kr/Corba. Man”. [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”. 61