1999년 10월 29일 김 정 선 jskim@cse.hanyang.ac.kr 한양대학교 공학대학 전자컴퓨터공학부 Introduction to 1999년 10월 29일 김 정 선 jskim@cse.hanyang.ac.kr 한양대학교 공학대학 전자컴퓨터공학부

Agenda Brief overview of Object Management Architecture (OMA) Common Object Request Broker Architecture (CORBA) CORBA is one of the key components of the OMA.

Distributed Object Computing Object-Oriented Programming Distributed Object Computing Driving force: Internet & Multithreaded, net-aware OS, etc Consequences: Client/Server & Components Revolution

Distributed Objects Distributed objects are self-contained objects that can plug-and-play across languages, operating systems, and networks. Extremely well-suited for creating flexible C/S systems because data and business logic is encapsulated within objects, allowing them to be located anywhere.

Facts of Life Today ATM FDDI WAN Ethernet Gateway/Router MVS - IBM SunOS - Sparc HP/UX - HPPA OS/2 - PowerPC Windows NT - Alpha Windows - Pentium WAN Ethernet ATM FDDI

Reasons for Heterogeneity Engineering tradeoff Cost effectiveness Legacy systems

Motivation for CORBA Ideally, heterogeneity and open systems enable us to use the best combination of HW & SW components. However, without standards for interoperability, the development of software applications whose components are interoperable, reusable, portable, and collaborate efficiently, reliably, transparently, and scalably in a distributed heterogeneous environment is very, very hard.

Object Management Group (OMG) To help address this challenge, the Object Management Group (OMG) is formed (1989) to develop, adopt, and promote standards for the development and deployment of applications in distributed heterogeneous environment.  OMG is a consortium of over 800 computer companies e.g., Sun, HP, DEC, IBM, IONA, etc.

Object Management Architecture (OMA) The OMA is a common architectural framework on which every OMG’s object technologies are based. The Object Model defines the semantics of the objects distributed across a heterogeneous environment (i.e., CORBA objects) can be described. The Reference Model characterizes interface boundaries and interactions between those objects.

The Object Model An object is an identifiable, encapsulated entity that provides one or more services that can be requested by a client. A client of a service is any entity capable of requesting the service. Clients can issue requests for services only through well-defined object’s interface, described by Interface Definition Language (IDL). An interface is a set of possible operations that a client may request of an object.

The Object Model (Cont’d) An object reference is an opaque object name that reliably denotes a particular object. The implementation and location of each object are hidden from the requesting client.

OMA Reference Model The ORB delivers requests to objects and returns any responses to the clients making the request.

Object Services CORBAservices Domain-independent interfaces that are used by many distributed object programs. For example, a service providing for the discovery of other available services is almost always necessary regardless of the application domain:  Naming Service -- allows clients to find objects based on names;  Trader Service -- allows clients to find objects based on their properties. Other object services include lifecycle, security, transactions, events, as well as many others.

Object Services (Cont’d) Service Category Description CORBAservices Infrastructure services Services related to the ORB Security, Time mechanisms Information management Services to retrieve and Collection, Externalization, manipulate data Persistent, Property, Query, Relationship Task management Services to manage Concurrency, Event, distributed events and Transaction transactions System management Services to manage Licensing, Lifecycle, metadata, licensing, and Naming, Trader object life cycle

Common Facilities Like CORBAservices, horizontally-oriented interfaces, but they are oriented towards end-user applications. Examples include:  Compound documents  Printing  Task management  Electronic mails

Domain Interfaces Vertically-oriented, domain specific interfaces For example,  Manufacturing domain  Telecommunications domain  Health care (medical) domain  Financial domain.

Application Interfaces These are interfaces developed specifically for a given application. Because they are application-specific, and because the OMG does not develop applications (only specifications), these interfaces are not standardized. However, if over time it appears that certain broadly useful services emerge out of a particular application domain, they might become candidates for future OMG standardization.

CORBA The CORBA defines standard interfaces and characteristics of the ORB component of the OMA. The main features of CORBA are:  ORB Core  OMG Interface Definition Language (IDL)  Interface Repository/Implementation Repository  Language Mappings  Stubs and Skeletons  Dynamic Invocation and Dispatch  Object Adapters  Inter-ORB Protocols (GIOP/IIOP)

CORBA Architecture

CORBA IDL OMG IDL is an object-oriented interface definition language. Used to specify interfaces containing operations and attributes. OMG IDL support interface inheritance (both single and multiple inheritance). OMG IDL is designed to map onto multiple programming languages. e.g., C, C++, Smalltalk, COBOL, Ada, Java OMG IDL is not a complete programming language, it is just a declarative language. Language-independence

OMG IDL Features OMG IDL supports the following features:  Modules  Interfaces  Operations  Attributes  Inheritance  Basic types (e.g., char, short, double, string etc)  Arrays  Sequences  Struct, enum, union, typedef  Constants  Exceptions

IDLize Everything in CORBA

Stubs and Skeletons IDL compiler automatically generates client-side stubs and server-side skeletons. Sometimes called proxy or surrogates. Client Server ORB Stub Skeleton Local host Remote host

Stubs and Skeletons (Cont’d) A stub effectively creates and issues requests on behalf of a client. It works directly with ORB to marshal the request. Once the request arrives at the server, the ORB and the skeleton cooperate to unmarshal the request and dispatch it to the object implementation. Any response is sent back the way it came.

Static Request Invocations

Static Request Invocations (Cont’d) Dispatching through stub and skeleton is called static invocation. Stubs and skeletons are built directly into the client application and the object implementation. Therefore, they both have a complete a priori knowledge of the IDL interface of the CORBA objects being invoked. The primary advantage of the SI is its simplicity, typesafety, and efficiency.

Interface Repository Every CORBA-based application requires access to the IDL type system when it is executing, because it needs to know the types of interfaces supported by objects, signatures of operations, etc. Sometimes static knowledge of IDL type system is enough, but sometimes it is not. The Interface Repository (IR) allows the IDL type system to be accessed and written dynamically at runtime.

Dynamic Request Invocations

Dynamic Invocation Interface The DII interface allows a client to directly access the underlying request mechanisms provided by an ORB. Applications use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in. Unlike IDL stubs (which only allow RPC-style synchronous and oneway (send-only) requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) calls.

Dynamic Skeleton Interface

Dynamic Skeleton Interface (Cont’d) The DSI is the server side's analogue to the client side's DII. The DSI 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. The client making the request has no idea whether the implementation is using the type-specific IDL skeletons or is using the dynamic skeletons.

Dynamic Skeleton Interface (Cont’d) Likewise, the object implementation receiving the request has no idea whether the request is using the static invocation or dynamic invocation. The DSI is useful for a certain class of applications, especially for bridges between ORBs and for applications that serve to bridge CORBA systems to non-CORBA services and implementations.

Object Adapters The object adapter assists the ORB with delivering requests to the object and with activating the object. More importantly, an object adapter associates object implementations with the ORB. Responsibilities of object adapters include: Object registration Object reference generation Server process activation Object activation Request demultiplexing Object upcalls

Object Adapters (Cont’d) Object adapters can be specialized to provide support for certain object implementation styles (such as OODB object adapters for persistence and library object adapters for non-remote objects). Basic Object Adapter (BOA) is a mandatory for every CORBA ORB implementation. Portable Object Adapter (POA) is adopted as a new standard (CORBA 3.0).

ORB Interface An ORB is a logical entity (pseudo object) that may be implemented in various ways (such as one or more processes or a set of libraries). To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB. This interface 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 described soon.

Interoperability Protocols General Inter-ORB Protocol (GIOP) specifies request format and transmission protocol that enables ORB-ORB interoperability Internet Inter-ORB Protocol (IIOP) specifies a standard interoperability protocol for the Internet GIOP implemented on top of TCP/IP CORBA 2.0 compliant ORBs must support IIOP Environment-specific inter-ORB protocols (ESIOPs) e.g,, DCE

CORBA Interoperability Java ORB C++ ORB Small talk IIOP IIOP Networks ORB Cobol ORB C

Related Work Traditional RPC (e.g., DCE) Windows COM/DCOM Only supports “procedural” integration of application services Doesn’t provide object abstractions, message passing, or dynamic invocation Doesn’t address inheritance of interfaces Windows COM/DCOM Traditionally limited to desktop applications Does not address heterogeneous distributed computing (yet) Distributed COM (DCOM) is now appearing on multiple platforms

Related Work (Continued) Java RMI Limited to Java only Can be extended into other languages (e.g., C or C++) by using a bridge across the Java Native Interface (JNI) Well-suited for all-Java applications because of its tight integration with Java virtual machine

CORBA Implementations Many ORBs are now available: Visibroker from Visigenic/Borland/Inprise Orbix from IONA JavaIDL from JavaSoft etc. In theory, CORBA facilitates vendor-independent and platform-independent application collaboration In practice, heterogeneous ORB interoperability and portability still an issue ...

Summary of CORBA Features Interface Definition Language (IDL) A mapping from IDL onto many programming languages A Static Invocation Interface, used to compose method requests via proxies A Dynamic Invocation Interface, used to compose method requests at run-time Interface and Implementation Repositories containing meta-data queried at run-time The Portable Object Adapter (POA), allows service programmers to interface their code with an ORB