1 / 41

Introduction to

Introduction to. 1999 년 10 월 29 일 김 정 선 jskim@cse.hanyang.ac.kr 한양대학교 공학대학 전자컴퓨터공학부. Agenda. Brief overview of O bject M anagement A rchitecture ( OMA ) C ommon O bject R equest B roker A rchitecture ( CORBA ) CORBA is one of the key components of the OMA.

sonel
Download Presentation

Introduction to

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

  6. Reasons for Heterogeneity • Engineering tradeoff • Cost effectiveness • Legacy systems

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

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

  9. Object ManagementArchitecture (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.

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

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

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

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

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

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

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

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

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

  19. CORBA Architecture

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

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

  22. IDLize Everything in CORBA

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

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

  25. Static Request Invocations

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

  27. 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 dynamicallyat runtime.

  28. Dynamic Request Invocations

  29. 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 dynamicallyissue requests to objects without requiring IDL interface-specific stubs to be linked in. • Unlike IDL stubs (which only allow RPC-style synchronous andoneway (send-only) requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) calls.

  30. Dynamic Skeleton Interface

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

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

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

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

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

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

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

  38. Related Work • Traditional RPC (e.g., DCE) • 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

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

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

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

More Related