Enterprise Computing and Interoperability

1. Enterprise Computing and Interoperability Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818 † Special Thanks to Prof. Alex Shvartsman and Scott Craig for providing portions of this material.

2. Overview of Presentation • What is Enterprise Computing? • Interoperability and CORBA • Primer • Key Concepts and Ideas • System Design with CORBA/IDL • Interoperability Strategies • General Approaches • Java-Based Wrapper • Security Issues for Enterprise Computing • What are Key Issues re. Security for EC? • How are Legacy/COTS Handled? • Concluding Remarks

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

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

6. ORB and High Level View of Requests • The Request Consists of • Target Object • Operation (Method) • Parameters • Request Context (Optional)

7. CORBA Components and Interfaces Client Object Implementation Object Adapter Dynamic Invoke Client Stubs ORB Interface Implementation Skeletons ORB Core One interface ORB internal interface One interface per object adaptor One interface per object operation • 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

8. Interfaces IDL Interface Definitions Implementation Installation Interface Repository Implementation Repository Client Stubs Implementation Skeletons Access Includes Includes Describes Client Object Implementation • 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

9. Client Side Client Object Repository Object Implementation Dynamic Invoke Client Stubs ORB Interface Implementation Object Adapter Skeletons ORB Core • 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

10. Object Implementation Side Object Implementation Implementation Repository Client Implem. ORB Interface Skeletons Dynamic Invoke Client Stubs Object Adapter ORB Core • 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

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

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

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

14. Three Types of ORBs Client Object Request ORB Client Object Request ORB • Single Process Library Resident • Client and Implementation Resident ORB and implementations implemented as libraries (routines) resident in the client. ORB implemented as libraries (routines) resident in the clients and in the implementations.

15. Three Types of ORBs Client Object Request ORB • Server or Operating System Based ORB is implemented as a server (separate process) which brokers requests between client and implementation processes. ORB is part of the operating system.

16. Three Types of Implementations Object Implementation Single Process Single method invocation Implementation is a single process that is activated upon the request delivery Object Implementation Single Process Method C Method B Method A • Single Process “one shot” Object • Multi-Threaded “resident” Object Implementation is a permanent or resident multi-threaded process

17. Three Types of Implementations Object Implementation Process 1 Method A Process 2 Method B Process 3 Method C • Multi-Process Object Implementation is a set of processes dedicated to a particular (group of) method(s) Processes can be distributed

18. System Design with CORBA Scott A. Craig Computer Science & Engineering Department The University of Connecticut Storrs, Connecticut 06269-3155 scraig@engr.uconn.edu

19. Overview of Presentation • Introduction to OMG IDL • Object Management Architecture • CORBAservices • Naming Service • Event Service • Typed Event Example • References • Concluding Remarks

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

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

22. IDL: Basic Types

23. IDL: Complex Types • Structures: • struct FixedLengthStruct { long field1; // 32-bit short field2; // 16-bit}; • struct VariableLengthStruct { long field1; // 32-bit string field2;}; • Discriminated Unions: Cross between the C union and switch statements. • Enumerations: Ordered list of identifiers. • enum quality_t { Poor, Fair, Good, Excellent};

24. 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<long> longSeq; • Bounded Sequence:sequence<long,10> fieldname; • Strings: Declared using keyword string. May be bounded or unbounded. • string name<32>; //bounded • Arrays: Multidimensional, fixed-size arrays of any IDL data type.

25. 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_t DataTime; float val; }; struct Dialog2Data_t { timespec_t DataTime; long val; }; 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

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

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

28. CORBAservices • 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)

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

30. Naming Graph Engineering Pharmacy Dean Practice Dean EE Science CSE <Engineering;Dean> <Pharmacy;Dean> Context Application Object

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

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

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

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

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

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

37. 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. S2:Supplier S1:Supplier PushConsumer PushSupplier PushSupplier :EventChannel PushConsumer PushConsumer PushSupplier C1:Consumer CN:Consumer ...

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

39. TypedPushConsumer

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

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

42. Class Diagram

43. Component Diagram: Source Files

44. Component Diagram: Executables Supplier User_cs PushSupplier User_ev EventChannel User_ev PushSupplier Consumer

45. Collaboration Diagram

46. Deployment Diagram (degenerate) S1:Supplier{source1} S2:Supplier {source2} User_cs PushSupplier PushSupplier User_cs User_ev :EventChannel User_ev User_ev PushSupplier C1:Consumer CN:Consumer ...

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

48. References • Object Management Group, Inc. (OMG), http://www.omg.org • 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

49. Concluding Remarks • Introduced OMG IDL • 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. • Future Work: • Investigation of Security Services

50. Interoperability Strategies • Architectural Alternatives and Frameworks • Taxonomy of Architectural Variants • Integration via Java, CORBA, etc. • Case Study: The ADAM Environment • Upgrading a C++ Legacy Application to be Java-Compatible • Pros and Cons of Effort • Issues for Interoperability • Outlining Future Efforts and Emphases • Concluding Remarks and Discussion