Presentation is loading. Please wait.

Presentation is loading. Please wait.

ECC-1.1 CSE298 CSE300 CSE333 Enterprise Computing and CORBA Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut.

Similar presentations

Presentation on theme: "ECC-1.1 CSE298 CSE300 CSE333 Enterprise Computing and CORBA Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut."— Presentation transcript:

1 ECC-1.1 CSE298 CSE300 CSE333 Enterprise Computing and CORBA Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155 (860) 486 - 4818 † Special Thanks to Prof. Alex Shvartsman and Scott Craig for providing portions of this material.

2 ECC-1.2 CSE298 CSE300 CSE333 Overview of Presentation  What is Enterprise Computing?  Interoperability and CORBA  What is CORBA?  Primer  Key Concepts and Ideas  System Design with CORBA/IDL

3 ECC-1.3 CSE298 CSE300 CSE333 What is Enterprise Computing?  Today’s and Tomorrows Applications are System of Systems  Facilitate Interactions/Information Exchange  Leverage Existing Information, Resources, and Applications in New Environment  Interoperability Key Issue  Strive for New/Innovative Application Usage in Distributed Environment - For Example …  Expand to Multi-User Capabilities  Incorporate Modern GUI  Introduce Useful Functionality  Upgrade to Web-Based Access

4 ECC-1.4 CSE298 CSE300 CSE333 What is CORBA?  Common Object Request Broker Architecture  Architecture to Allow:  Existing COTS, GOTS, Legacy, DB, etc. to Interact with One Another  Integrate These with New Clients/Servers/Etc.  Consists of Following Major Components  Object Request Broker (ORB):  Arbitrate and Interact  Interface Definition Language (IDL):  Common Definitional Format  Means for Different “Software” written in Different Languages to Interact with One Another

5 ECC-1.5 CSE298 CSE300 CSE333 Role of an Object Request Broker (ORB)  ORB Provides the Underlying Infrastructure for Supporting Interoperating Software Systems (Applications) Composed of Distributed Objects  ORB Provides the Basic Request Delivery  ORB Provides Interface Definitions  Location is Transparent to the Caller and Object Implementation  Caller and the Object Implementation Can be in the Same Process thru Opposite Sides of the World  ORB Manages Local Location and Optimization

6 ECC-1.6 CSE298 CSE300 CSE333 Interface Definition Language, IDL  Key Component of CORBA Is the Interface Definition Language, IDL  Mapping is Available in C, C++, Java, Ada, Etc.  IDL Is Independent of Any Language/Compiler  Multiple Inheritance  Public Interface Oriented  Not for Implementation  Primary Support for Interoperability Between Static and Dynamic Request Mechanisms

7 ECC-1.7 CSE298 CSE300 CSE333 ORB and High Level View of Requests  The Request Consists of  Target Object  Operation (Method)  Parameters  Request Context (Optional)

8 ECC-1.8 CSE298 CSE300 CSE333 Object Adapter ORB Core One interface One interface per object adaptor One interface per object operation ORB internal interface Dynamic Invoke Client Stubs ORB Interface ClientObject Implementation Implementation Skeletons CORBA Components and Interfaces  Client Stub: Client Invokes a Particular Object Op.  Dynamic Invocation: Run-Time-Construction of Operation Invocations  Implementation Skeleton: Interface Through Which a Method Receives a Request  Object Adapter: Provides (De)activation, Object Creation/Reference Mgmt. for Implementations  ORB Interface: Common ORB Operations

9 ECC-1.9 CSE298 CSE300 CSE333 Client Stubs Implementation Skeletons ClientObject Implementation Interface Repository Implementation Repository AccessIncludes Describes IDL Interface Definitions Implementation InstallationInterfaces  Objects are Defined in IDL via Interfaces  Object Definitions (Interfaces) are Manifested as Objects in the Interface Repository, as Client Stubs, and as Implementation Skeletons  Descriptions of Object Implementations are Maintained as Objects in the Impl. Repository

10 ECC-1.10 CSE298 CSE300 CSE333 ORB Core Object Adapter Object Implementation Implementation Skeletons Client Dynamic Invoke Client Stubs ORB Interface Object Repository Client Side  Clients Perform Requests Using Object References  Clients Issue Requests through Object Interface Stubs (Static) or DII (Dynamic Invocation Inter.)  Clients May Access General ORB Services:  Interface Repository (IR)  Context Management  Request Management

11 ECC-1.11 CSE298 CSE300 CSE333 ORB Core ORB Interface Object Implementation Object Adapter Implem. Skeletons Dynamic Invoke Client Stubs Client Implementation Repository Object Implementation Side  Implementations Receive Requests Thru Skeletons  Object Adapter Adapts to Specifics of Object Implementation Schemes  Basic Object Adapter (BOA) Provides:  Management of References  Method Invocation  Authentication  Implementation Registration  Activation / Deactivation

12 ECC-1.12 CSE298 CSE300 CSE333 Dynamic Invocation Interface (DII)  DII Allows Clients to Dynamically:  Discover Objects  Discover Objects’ Interfaces  Create Requests  Invoke Requests (-> Methods)  Receive Responses  Major DII Features:  Requests Appear as Objects  Requests are Reusable  Invocation May be Synchronous or Asynchronous  Requests Can be Generated Dynamically, Statically or Using Both Approaches

13 ECC-1.13 CSE298 CSE300 CSE333 Request Components  Object Reference -- Identifies the Target Object  Operation -- Identifies Which Operation to Invoke (Which Method Will Be Executed)  Parameters -- Input, Output or Inout Method Arg-s  Context Object -- the Context Within Which the Request Is to Be Performed  Results -- the Result Value(s) Returned  Environment -- the Exec-n Env-t and Exception Info.  Request Handle -- the Id. For This Request Instance

14 ECC-1.14 CSE298 CSE300 CSE333 Repositories: Interface and Implementation  Interface Repository  Dynamic Client Access to Interface Definitions to Construct a Request  Dynamic Type Checking of Request Signatures  Traversal of Inheritance Graphs  Implementation Repository  Location of Implementations and Methods  Activation Information  Administration Control  Resource Allocation  Security

15 ECC-1.15 CSE298 CSE300 CSE333 ClientObject Request ORB ORB and implementations implemented as libraries (routines) resident in the client. Three Types of ORBs  Single Process Library Resident  Client and Implementation Resident ClientObject Request ORB ORB implemented as libraries (routines) resident in the clients and in the implementations.

16 ECC-1.16 CSE298 CSE300 CSE333 ClientObject Request ORB ORB is implemented as a server (separate process) which brokers requests between client and implementation processes. ORB is part of the operating system. Three Types of ORBs  Server or Operating System Based

17 ECC-1.17 CSE298 CSE300 CSE333 Implementation is a permanent or resident multi-threaded process Implementation is a single process that is activated upon the request delivery Object Implementation Single Process Single method invocation Object Implementation Single Process Method C Method B Method A Three Types of Implementations  Single Process “one shot” Object  Multi-Threaded “resident” Object

18 ECC-1.18 CSE298 CSE300 CSE333 Implementation is a set of processes dedicated to a particular (group of) method(s) Processes can be distributed Object Implementation Process 1 Process 2 Process 3 Method A Method B Method C Three Types of Implementations  Multi-Process Object

19 ECC-1.19 CSE298 CSE300 CSE333 System Design with CORBA Scott A. Craig Computer Science & Engineering Department The University of Connecticut Storrs, Connecticut 06269-3155

20 ECC-1.20 CSE298 CSE300 CSE333 Overview of Presentation  Introduction to OMG IDL  Object Management Architecture  CORBAservices  Naming Service  Event Service  Typed Event Example  References  Concluding Remarks

21 ECC-1.21 CSE298 CSE300 CSE333 Interface Definition Language, IDL  Language used to describe the interfaces that client objects call and object implementations provide.  Obeys the same lexical rules as C++, but introduces some new keywords.  Supports standard C++ preprocessing features.  Interfaces can have operations and attributes.  Operation declaration consists of a return type, an identifier, a parameter list, and an optional raises expression (exceptions).  Attribute declaration is logically equivalent to declaring a pair of accessor operations. May be declared as readonly.  Interface specifications are placed in a source file having the extension “.idl”

22 ECC-1.22 CSE298 CSE300 CSE333 IDL: Modules and Interfaces  Module: Used to scope IDL identifiers.  Mapped to C++ namespace with the same name. Mapped to a C++ class if the namespace construct is not supported.  Mapped to Java package with the same name.  IDL declarations not enclosed in any module have global scope when mapped.  Interface: Description of set of operations that a client may request of an object.  Multiple inheritance supported  Interface body may contain the following kinds of declarations: constant, type, attribute, and operation.

23 ECC-1.23 CSE298 CSE300 CSE333 IDL: Basic Types

24 ECC-1.24 CSE298 CSE300 CSE333 IDL: Complex Types  Structures:  struct FixedLengthStruct { longfield1;// 32-bit shortfield2;// 16-bit };  struct VariableLengthStruct { longfield1;// 32-bit stringfield2; };  Discriminated Unions: Cross between the C union and switch statements.  Enumerations: Ordered list of identifiers.  enum quality_t { Poor, Fair, Good, Excellent};

25 ECC-1.25 CSE298 CSE300 CSE333 IDL: Complex Types (cont.)  Sequences: One-dimensional array with maximum size (fixed at compile time) and length (set at run time).  Unbounded Sequence: typdef sequence longSeq;  Bounded Sequence: sequence fieldname;  Strings: Declared using keyword string. May be bounded or unbounded.  string name ;//bounded  Arrays: Multidimensional, fixed-size arrays of any IDL data type.

26 ECC-1.26 CSE298 CSE300 CSE333 IDL Example: GUI /* * File Name: GUI.idl */ #ifndef GUI_IDL #define GUI_IDL module GUI { struct timespec_t { long tv_sec; long tv_nsec; }; struct Dialog1Data_t { timespec_tDataTime; floatval; }; struct Dialog2Data_t { timespec_tDataTime; longval; }; interface MainWindow { void logEvent(in timespec_t timestamp, in string val); }; interface Dialog1 { void update(in Dialog1Data_t val); }; interface Dialog2 { void update(in Dialog2Data_t val); }; #endif// GUI_IDL

27 ECC-1.27 CSE298 CSE300 CSE333 IDL Example: Server /* * File Name: Server.idl */ #ifndef SERVER_IDL #define SERVER_IDL #include "GUI.idl" interface Server { enum reason_t { NotInitialized, ErrorDetected }; exception NotAvailable { reason_t reason; }; exception OperationTimeout {}; void registerMainWindow( in GUI::MainWindow val, in boolean flag) raises (OperationTimeout); void setMainWindowEnabled( in boolean flag) raises (OperationTimeout); void registerDialog1( in GUI::Dialog1 val, in boolean flag) raises (OperationTimeout); void setDialog1Enabled( in boolean flag) raises (OperationTimeout); GUI::Dialog1Data_t getDialog1Data() raises (OperationTimeout, NotAvailable); void registerDialog2( in GUI::Dialog2 val, in boolean flag) raises (OperationTimeout); void setDialog2Enabled( in boolean flag) raises (OperationTimeout); GUI::Dialog2Data_t getDialog2Data() raises (OperationTimeout, NotAvailable); }; #endif// SERVER_IDL

28 ECC-1.28 CSE298 CSE300 CSE333 Object Management Architecture  The Object Management Group, Inc (OMG) has established the Object Management Architecture (OMA), upon which OMG specifications are based  Components of the OMA Reference Model:  Object Request Broker (CORBA):  Provides communications infrastructure.  Object Services (CORBAservices):  Collection of fundamental services (interfaces and objects) for using and implementing objects.  Common Facilities (CORBAfacilities):  Services such as system management.  Application Objects  Not standardized.

29 ECC-1.29 CSE298 CSE300 CSE333CORBAservices  OMG specification for Object Services  Collection of 15 services (interfaces and objects) that support basic functions for using and implementing objects.  Interfaces specified using IDL  Will focus on two services:  Naming Service  Event Service  Security Service: Addresses identification and authentication, authorization and access control, security of communication between objects, etc.  Beyond scope of this presentation (specification is 386 pages in length)

30 ECC-1.30 CSE298 CSE300 CSE333 Naming Service  Facilitates locating objects in a distributed system.  A name binding is a name-to-object association and is always defined relative to a naming context.  A naming context is an object that contains a set of name bindings in which each name is unique.  Multiple names may be bound to an object.  Servers bind names to objects and clients resolve names to objects.  A naming context may be bound to a name in another naming context creating a naming graph.  Directed graph with labeled edges in which nodes are objects.  Compound names are formed by the sequence of names along a path from the root to the leaf.

31 ECC-1.31 CSE298 CSE300 CSE333 Naming Graph Context Application Object Engineering Pharmacy Dean Dean <Engineering;Dean><Pharmacy;Dean> CSE EE Practice Science

32 ECC-1.32 CSE298 CSE300 CSE333CosNamingModule  NamingContext Interface Operations:  Binding Names: bind(...), rebind(...), bind_context(…), rebind_context(…)  Resolving Names: resolve(…)  Unbinding Names: unbind(…)  Creating Naming Contexts: new_context(), bind_new_context(…)  Deleting Contexts: destroy()  Listing a Naming Context: list(…)  BindingIterator Interface: Allows a client to iterate through the bindings using next_one(…) or next_n(…) operations.

33 ECC-1.33 CSE298 CSE300 CSE333 Event Service  A standard CORBA request issued by a client results in the synchronous execution of an operation by an object (server).  Request directed to a particular object.  Client must handle exceptions if request fails.  Event Service decouples communication between objects, defining two roles for objects:  Supplier Role: Produce event data  Consumer Role: Process event data  Event data are communicated by issuing standard CORBA requests. No extensions to CORBA are necessary to define event interfaces.  Communication may be generic or typed.

34 ECC-1.34 CSE298 CSE300 CSE333 Event Service Design Principles  Allow multiple consumers and multiple suppliers.  Consumers can either request events (pull model) or be notified of events (push model).  Software architectural decision.  Supplier can issue a single standard CORBA request to communicate event data to all consumers.  Suppliers can generate events without knowing the identities of consumers and consumers can receive events without knowing the identities of suppliers.  Event Service specification allows multiple qualities of service (reliability).  Implementation dependent.

35 ECC-1.35 CSE298 CSE300 CSE333 Push Model  Suppliers realize PushSupplier interface and consumers realize PushConsumer interface.  Suppliers invoke push operations on PushConsumer interface.  Supplier initiates transfer of event data.  Communication set up by exchanging object references.  Either can break communication by invoking the disconnect operation on the other.

36 ECC-1.36 CSE298 CSE300 CSE333 Pull Model  Suppliers realize PullSupplier interface and consumers realize PullConsumer interface.  Consumers invoke pull operations on PushSupplier interface.  Consumer initiates transfer of event data.  Communication set up by exchanging object references.  Either can break communication by invoking the disconnect operation on the other.

37 ECC-1.37 CSE298 CSE300 CSE333 Event Channels  Event Channel is a service that decouples communication between suppliers and consumers.  Allows multiple suppliers to communicate with multiple consumers asynchronously.  Is both a consumer and a supplier of events.  Push-Style Communication with an Event Channel  Supplier pushes event data to Event Channel, which then pushes event data to consumer.  Pull-Style Communication with an Event Channel  Consumer pulls event data from Event Channel which then pulls event data from the supplier.  Mixed-Style Communication with an Event Channel

38 ECC-1.38 CSE298 CSE300 CSE333 Event Channels (cont.)  Multiple Consumers and Multiple Suppliers  Event Channel consumes events from one or more suppliers and supplies events to one or more consumers. :EventChannel CN:ConsumerC1:Consumer S1:Supplier S2:Supplier... PushSupplier PushConsumer PushConsumerPushConsumer PushSupplier PushSupplier

39 ECC-1.39 CSE298 CSE300 CSE333 Typed Event Communication  In the preceding generic models, suppliers must insert data into an “any” parameter and consumers must then extract the data.  Alternative approach is the Typed Push Model  The interface that the consumer will realize is defined in IDL, subject to restrictions.  Only “in” parameters are allowed.  No return values are permitted.  Operations may be declared as “oneway.”  The user defined interface must inherit from CosTypedEventComm::TypedPushConsumer.

40 ECC-1.40 CSE298 CSE300 CSE333TypedPushConsumer

41 ECC-1.41 CSE298 CSE300 CSE333 Typed Event Example  Problem Statement: Wish to design a distributed system consisting of two Suppliers, a Typed Event Channel, and multiple Consumers.  Supplier realizes a Client/Server interface ( User_cs ) that has two operations; one that returns a variable-length structure and one that returns a fixed-length structure.  Consumer realizes an Event interface ( User_ev ) that inherits from TypedPushConsumer.  Fixed-length structure is pushed via the “update” operation.  Notification structure is pushed via the “notification” operation.  Structures contain field to identify Supplier.

42 ECC-1.42 CSE298 CSE300 CSE333 Typed Event Example (cont.)  Event Channel must be running before any Suppliers or Consumers are started.  When a Supplier is started, it binds a name to the object that realizes the User_cs interface. Each Supplier must supply a unique name. It then connects to the Event Channel as a push supplier.  When a Consumer is started, it obtains an object reference to each User_cs interface via the Naming Service. It then connects to the Event Channel as a push consumer.  When a Consumer receives a notification event, it retrieves the variable-length struct from the appropriate Supplier via the C/S interface.

43 ECC-1.43 CSE298 CSE300 CSE333 Class Diagram

44 ECC-1.44 CSE298 CSE300 CSE333 Component Diagram: Source Files

45 ECC-1.45 CSE298 CSE300 CSE333 Component Diagram: Executables EventChannel Consumer Supplier User_ev User_ev PushSupplier PushSupplier User_cs

46 ECC-1.46 CSE298 CSE300 CSE333 Collaboration Diagram

47 ECC-1.47 CSE298 CSE300 CSE333 Deployment Diagram (degenerate) :EventChannel CN:ConsumerC1:Consumer S1:Supplier {source1} S2:Supplier{source2}... PushSupplier User_ev User_evUser_ev PushSupplier PushSupplier User_csUser_cs

48 ECC-1.48 CSE298 CSE300 CSE333 Design Considerations  Some form of event strategy should be employed to avoid having clients polling servers.  For performance reasons, only small, fixed-length structures should be pushed using Typed Events.  Because of middleware overhead, structure should be optimally packed.  Adding the “oneway” attribute to operations with no return type can improve performance, but reduces reliability (undetected comm. failures).  Consumers of aperiodic events may be unaware of Event Channel crashes. Event Channels should periodically generate “keep alive” events and Consumers should reconnect if not received.

49 ECC-1.49 CSE298 CSE300 CSE333References  Object Management Group, Inc. (OMG),  OMG, A Discussion of the Object Management Architecture, 01/97  OMG, The Common Object Request Broker: Architecture and Specification, Rev. 2.2, 02/98  OMG, CORBAservices: Common Object Services Specification, 12/98  T. J. Mowbray and R. Zahavi, The Essential CORBA: Systems Integration Using Distributed Objects, John Wiley & Sons, Inc., 1995  G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide, AWL, Inc. 1999

50 ECC-1.50 CSE298 CSE300 CSE333 Overall Concluding Remarks  Introduced CORBA Concepts and Components  ORB and Overall Architecture  OMG IDL with Mappings to C++, Java, etc.  Provided Overview of OMG Object Management Architecture and the Role of Object Services.  Provided overview of Naming Service and Event Service.  Presented a Distributed System that Makes use of Naming and Event Services.  How Does CORBA Related to Java Technologies?  RMI  JINI  EJB

Download ppt "ECC-1.1 CSE298 CSE300 CSE333 Enterprise Computing and CORBA Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut."

Similar presentations

Ads by Google