Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Enterprise Computing and Interoperability CSE298 CSE300 Prof. Steven A. Demurjian CSE300 Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155 [email protected] http://www.engr.uconn.edu/~steve (860) 486 - 4818 † Special Thanks to Prof. Alex Shvartsman and Scott Craig for providing portions of this material. ECIC-1.1 Overview of Presentation CSE298 CSE300 CSE300 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 ECIC-1.2 What is Enterprise Computing? CSE298 CSE300 CSE300 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 ECIC-1.3 Role of an Object Request Broker (ORB) CSE298 CSE300 CSE300 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 ORB Clie nt Obje ct Application Imple me ntation ECIC-1.4 Interface Definition Language, IDL CSE298 CSE300 CSE300 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 ECIC-1.5 ORB and High Level View of Requests CSE298 CSE300 CSE300 The Request Consists of Target Object Operation (Method) Parameters Request Context (Optional) Clie nt Application Obje ct Imple me ntation Obje ct Ca ll IDL Boundary Obje ct re fe re nce Me thods a nd D a ta ORB Request IDL Boundary Obje ct dispa tche r ECIC-1.6 CORBA Components and Interfaces CSE298 CSE300 CSE300 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 Client Dynamic Invoke Client Stubs Object Implementation ORB Interface Implementation Skeletons Object Adapter ORB Core One interface One interface per object adaptor One interface per object operation ORB internal interface ECIC-1.7 Interfaces CSE298 CSE300 CSE300 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 IDL Interface Definitions Interface Repository Access Client Stubs Includes Client Implementation Installation Implementation Skeletons Includes Implementation Repository Describes Object Implementation ECIC-1.8 Client Side CSE298 CSE300 CSE300 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 Client Object Repository Object Implementation Dynamic Invoke Client Stubs ORB Interface Implementation Skeletons Object Adapter ORB Core ECIC-1.9 Object Implementation Side CSE298 CSE300 CSE300 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 Object Implementation Client Dynamic Invoke Client Stubs ORB Interface ORB Core Implem. Skeletons Implementation Repository Object Adapter ECIC-1.10 Dynamic Invocation Interface (DII) CSE298 CSE300 CSE300 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 ECIC-1.11 Request Components CSE298 CSE300 CSE300 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 ECIC-1.12 Repositories: Interface and Implementation CSE298 CSE300 CSE300 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 ECIC-1.13 Three Types of ORBs CSE298 CSE300 CSE300 Single Process Library Resident Client ORB Object ORB and implementations implemented as libraries (routines) resident in the client. Request Client and Implementation Resident Client ORB Object ORB implemented as libraries (routines) resident in the clients and in the implementations. Request ECIC-1.14 Three Types of ORBs CSE298 CSE300 Server or Operating System Based CSE300 Client ORB Object Request ORB is implemented as a server (separate process) which brokers requests between client and implementation processes. ORB is part of the operating system. ECIC-1.15 Three Types of Implementations CSE298 CSE300 CSE300 Single Process “one shot” Object Object Implementation Single Process Single method invocation Implementation is a single process that is activated upon the request delivery Multi-Threaded “resident” Object Object Implementation Single Process Implementation is a permanent or resident multi-threaded process Method C Method B Method A ECIC-1.16 Three Types of Implementations CSE298 CSE300 Multi-Process Object CSE300 Object Implementation Process 1 Method A Process 2 Method B Implementation is a set of processes dedicated to a particular (group of) method(s) Process 3 Method C Processes can be distributed ECIC-1.17 System Design with CORBA CSE298 CSE300 CSE300 Scott A. Craig Computer Science & Engineering Department The University of Connecticut Storrs, Connecticut 06269-3155 [email protected] ECIC-1.18 Overview of Presentation CSE298 CSE300 CSE300 Introduction to OMG IDL Object Management Architecture CORBAservices Naming Service Event Service Typed Event Example References Concluding Remarks ECIC-1.19 Interface Definition Language, IDL CSE298 CSE300 CSE300 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” ECIC-1.20 IDL: Modules and Interfaces CSE298 CSE300 CSE300 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. ECIC-1.21 IDL: Basic Types CSE298 CSE300 Type Range CSE300 short -215 .. 215-1 (16-bit) unsigned short 0 .. 216-1 (16-bit) long -231 .. 231-1 (32-bit) unsigned long 0 .. 216-1 (32-bit) float IEEE single-precision floating point double IEEE double-precision floating point char 8-bit quantity boolean TRUE or FALSE octet 8-bit (guaranteed during transmission) any values that can express any IDL type ECIC-1.22 IDL: Complex Types CSE298 CSE300 CSE300 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}; ECIC-1.23 IDL: Complex Types (cont.) CSE298 CSE300 CSE300 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. ECIC-1.24 IDL Example: GUI CSE298 CSE300 /* * File Name: */ CSE300 #ifndef GUI_IDL #define GUI_IDL GUI.idl module GUI { struct timespec_t { long tv_sec; long tv_nsec; }; interface Dialog1 { void update(in Dialog1Data_t val); }; interface Dialog2 { void update(in Dialog2Data_t val); }; }; #endif // GUI_IDL 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); }; ECIC-1.25 IDL Example: Server CSE298 CSE300 /* * File Name: */ CSE300 #ifndef SERVER_IDL #define SERVER_IDL 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 ECIC-1.26 Object Management Architecture CSE298 CSE300 CSE300 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. ECIC-1.27 CORBAservices CSE298 CSE300 CSE300 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) ECIC-1.28 Naming Service CSE298 CSE300 CSE300 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. ECIC-1.29 Naming Graph CSE298 CSE300 Engineering CSE300 Dean EE CSE <Engineering;Dean> Pharmacy Practice Dean Science <Pharmacy;Dean> Context Application Object ECIC-1.30 CosNamingModule CSE298 CSE300 CSE300 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. ECIC-1.31 Event Service CSE298 CSE300 CSE300 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. ECIC-1.32 Event Service Design Principles CSE298 CSE300 CSE300 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. ECIC-1.33 Push Model CSE298 CSE300 CSE300 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. ECIC-1.34 Pull Model CSE298 CSE300 CSE300 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. ECIC-1.35 Event Channels CSE298 CSE300 CSE300 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 ECIC-1.36 Event Channels (cont.) CSE298 CSE300 CSE300 Multiple Consumers and Multiple Suppliers Event Channel consumes events from one or more suppliers and supplies events to one or more consumers. S1:Supplier S2:Supplier PushConsumer PushSupplier PushSupplier :EventChannel PushConsumer PushConsumer PushSupplier C1:Consumer ... CN:Consumer ECIC-1.37 Typed Event Communication CSE298 CSE300 CSE300 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. ECIC-1.38 TypedPushConsumer CSE298 CSE300 CSE300 <<Interface>> PushConsumer (from Common_Interface) + push(data : in any) : void + disconnect_push_consumer() : void <<Interface>> TypedPushConsumer (from Common_Interface) + get_typed_consumer() : Object <<Interface>> User_ev + notification(val : in User_cs::Notification_t) : void + update(val : in User_cs::Update_t) : void ECIC-1.39 Typed Event Example CSE298 CSE300 CSE300 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. ECIC-1.40 Typed Event Example (cont.) CSE298 CSE300 CSE300 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. ECIC-1.41 Class Diagram CSE298 CSE300 source_t (from User_cs) CSE300 - source1 - source2 <<Interface>> TypedPushConsumer (from Common_Interface) + get_typed_consumer() : Object Update_t (from User_cs) - timestamp : long - data : float - source : source_t <<Interface>> User_ev Notification_t + notification(val : in User_cs::Notification_t) : void + update(val : in User_cs::Update_t) : void (from User_cs) - timestamp : long - source : source_t VarLengthStruct_t (from User_cs) - timestamp : long - source : source_t - data : string <<Interface>> User_cs + getVarLengthStruct() : VarLengthStruct_t + getUpdate() : Update_t ECIC-1.42 Component Diagram: Source Files CSE298 CSE300 CSE300 User_cs User_cs User_ev User_ev ECIC-1.43 Component Diagram: Executables CSE298 CSE300 CSE300 Supplier User_cs PushSupplier User_ev EventChannel User_ev PushSupplier Consumer ECIC-1.44 Collaboration Diagram CSE298 CSE300 source1 : User_cs 1: notification(...) CSE300 4: getVarLengthStruct( ) C1 : User_ev 5: getVarLengthStruct( ) EC : User_ev 2: notification(...) C2 : User_ev 3: notification(...) ECIC-1.45 Deployment Diagram (degenerate) CSE298 CSE300 CSE300 S1:Supplier {source1} User_cs S2:Supplier {source2} PushSupplier PushSupplier User_cs User_ev :EventChannel User_ev User_ev PushSupplier C1:Consumer ... CN:Consumer ECIC-1.46 Design Considerations CSE298 CSE300 CSE300 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. ECIC-1.47 References CSE298 CSE300 CSE300 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 ECIC-1.48 Concluding Remarks CSE298 CSE300 CSE300 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 ECIC-1.49 Interoperability Strategies CSE298 CSE300 CSE300 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 ECIC-1.50 Architectural Alternatives & Framework CSE298 CSE300 CSE300 Reviewing Architectural Variants Java Client to Legacy Appl. via RDBS ORB Integration of Java Client and Legacy Application Java Client with Wrapper to Legacy Appl. One COTS and One Legacy Appl. to Java Clients Quick Review of Select Material from Summer 1997 White Paper: “The Java Programming Language: Impact upon the Army Technical Architecture (ATA) and Joint Technical Architecture (JTC)” Demurjian/Shin ECIC-1.51 Java Client to Legacy App via RDBS CSE298 CSE300 CSE300 Transformed Legacy Data Java Client Updated Data Relational Database System(RDS) Extract and Generate Data Transform and Store Data Legacy Application ECIC-1.52 ORB Integration of Java Client and Legacy Application CSE298 CSE300 CSE300 Java Client Legacy Application Java Wrapper Object Request Broker (ORB) CORBA is the Medium of Info. Exchange Requires Java/CORBA Capabilities ECIC-1.53 Java Client with Wrapper to Legacy Application CSE298 CSE300 CSE300 Java Client Java Application Code WRAPPER Mapping Classes JAVA LAYER Interactions Between Java Client and Legacy Appl. via C and RPC C is the Medium of Info. Exchange Java Client with C++/C Wrapper NATIVE LAYER Native Functions (C++) RPC Client Stubs (C) Legacy Application Network ECIC-1.54 One COTS and One Legacy Application to Java Clients CSE298 CSE300 COTS Application Legacy Application CSE300 Java Application Code Java Application Code Native Functions that Map to COTS Appl NATIVE LAYER Native Functions that Map to Legacy Appl NATIVE LAYER JAVA LAYER JAVA LAYER Mapping Classes JAVA NETWORK WRAPPER Mapping Classes JAVA NETWORK WRAPPER Network Java Client Java Client Java is Medium of Info. Exchange - C/C++ Appls with Java Wrapper ECIC-1.55 ADAM: User Perspective CSE298 CSE300 CSE300 Code/Documentation Generation ADAM Graphical User Interface C++ Ada83, Ada95 Eiffel Java (on PC/NT) Ascii/Latex Doc. OO Design Server Abstraction for Design Persistence Multiple Versions: ADAM/Unix: IV3.1, X, Sparcstation ADAM/PC: Win95, Borland C++ ADAM/NT: Under Development Ontos OODBS ECIC-1.56 Case Study: The ADAM Environment CSE298 CSE300 CSE300 ADAM is a C++ Legacy Application with: GUI Interviews/Unidraw Core C++ Internal Classes which are Compiler Independent Designs Stored in Ontos OODBS Redesign/Reformulate ADAM as: Java Client that Replaces C++ GUI Java Server Wraps Core C++ Internal Classes C/S Communications via Java Designs Stored in Jasmine (1998 Task) Similar to Providing C/S Interactions for an C++ Legacy/COTS Application ECIC-1.57 Characterizing ADAM Software Profile CSE298 CSE300 CSE300 C++ Class Library - Intended as a Single-CPU, Single-User, Interactive Design Environment C++ Classes Structured as Multiple Interacting Hierarchies for Different Components: C++ Classes for GUI C++ Classes to Store Design as it is Created C++ Classes for Code Generation Capabilities C++/Ontos Classes for Persistence Source Code Level Access to ADAM Software Goal: Minimize Code-Level Modifications as ADAM Moves to Java Client/Server Paradigm ECIC-1.58 ADAM: Current Software Architecture CSE298 CSE300 CSE300 Design/Generation Compiler Independent Software ADAM Graphical User Interface C++ Classes/Instances to Store Design and Code Generation Algorithms OO Design C++ Ontos C++ Ada83, Ada95 Eiffel Java (on PC) ADAM/Unix: IV3.1, X, Sparcstation ADAM/PC: Win95, Borland C++ DB Server Abstraction for Design Persistence Ontos OODBS ECIC-1.59 Client Requirements and Functionalities CSE298 CSE300 CSE300 New ADAM Java Client Replicates Core C++ Classes to Allow Transitory Storage of Designs: Existing Designs from Legacy Server Storable at ADAM Java Client New/Existing Designs at Java Client Locally Manipulated to Reduce Communication Traffic New/Existing Designs Sent to Legacy Server for Persistent Storage Java Communications from Client to Server Transmission of Modified Design to Server Receipt of Existing Design from Server Both Accomplished via Object Serialization ECIC-1.60 Client Requirements and Functionalities CSE298 CSE300 CSE300 Designs at Client to Reduce Communication Overhead Existing Designs Sent/Loaded for Local Manipulation OO Design ADAM C++ Legacy Application (Server) Java/TwinPeaks Wrapper New ADAM Java User Interface (Client) Completed New Designs or Revised Existing Designs Sent for Persistent Storage ECIC-1.61 ADAM: Target Software Architecture CSE298 CSE300 CSE300 New ADAM Java User Interface (Client) ADAM C++ Legacy Application (Server) OO Design Java Communications (Object Serialization/Sockets) Modified Design to Server Existing Design from Server C++: Common Interface to Access Server Classes Java: Communication and Interpretation Java/TwinPeaks Wrapper ECIC-1.62 Wrapper Requirements and Functionalities CSE298 CSE300 CSE300 Transmission/Receipt of Messages from Clients Existing Design from Server to Client Locating C++ Instances in Legacy Server Creation of Java Instances from C++ Instances Object Serialization of Java Instances to Client Store New/Existing Design from Client to Server Receipt of Java Instances via O-Serialization Creation of C++ Instances from Java Instances Storage of C++ Instances into Legacy Server Interactions between Java and C++ via Java Native Interface (JNI) or TwinPeaks ECIC-1.63 ADAM: Client/Wrapper Components CSE298 CSE300 Java Wrapper Java Client COMMUNICATION Java Communication Classes/Instances Java Design Classes/Instances Java Communication Classes/Instances COMMUNICATION GUI Classes and Instances Java Design Classes/Instances CSE300 Translation Java to C++ Legacy Code Adam C++ Server May Not Be Needed Depends on Comm. Protocol ECIC-1.64 ADAM: Java to C++ Wrapper CSE298 CSE300 TwinPeaks Library Folder Translation Java to C++ Wrapper C++ Common Interface Java Design Classes and Instances Class Folder Communication CSE300 ADAM C++ Legacy Classes and Instances Legacy Application ECIC-1.65 Communication Requirements and Functionalities CSE298 CSE300 CSE300 Layers of Classes/Instances (Client vs. Server) Interface (GUI) Classes and Instances (C) Java Design Classes and Instances (C&S) Java Communication Classes and Instances (C&S) Translation Java to C++ Classes and Instances (S) Communications Sockets (Current) Object Serialization (Current) CORBA/ORBs vs. RMI (Future) ECIC-1.66 ADAM: Socket Communications CSE298 CSE300 Java Client Java Wrapper COMMUNICATION Java Communication Classes/Instances Java Design Classes/Instances Java Communication Classes/Instances COMMUNICATION GUI Classes and Instances Java Design Classes/Instances CSE300 Translation Java to C++ Legacy Code Adam C++ Server Potential Performance Issue: Multiple Layers of Translation ECIC-1.67 TwinPeaks Requirements and Functionalities CSE298 CSE300 CSE300 Evaluated Feasibility of JNI Directly Access Native Layer Eliminates Platform Independence Difficult to Understand and Use Exploring TwinPeaks Product Beta Product from Sun Automatically Generates Java Interface to C or C++ Native Library Analyzes Native Library Header Files to Produce a Java API that Closely Mirrors Original C/C++ API Generates Platform Specific Native Code ECIC-1.68 ADAM: TwinPeaks Architecture CSE298 CSE300 CSE300 Java Application C++ Header Files (.h) C++ Implemen. Files (.c) INPUT TwinPeaks C++ Application Java Interface Class Folder (.java/.class) Java/C++ Bridge Lib. Folder C++ DLL ECIC-1.69 Status of TwinPeaks Effort CSE298 CSE300 CSE300 Established TwinPeaks Environment Downloaded Multiple Times due to Difficulty in Setting up Software and Multiple Releases by SunSoft Worked to Understand the Mechanism and Proper steps Needed to work with TwinPeaks UConn Beta Testing Site of Product: Initial Efforts in Sept and Oct 97 Provided Feedback and Suggestions to SunSoft Many of Suggestions for Improvement Reflected in the Second Release ECIC-1.70 Status of TwinPeaks Effort CSE298 CSE300 CSE300 As of January 15, 1998 Installed Newest TwinPeaks Release Developed Two Test Prototypes that Generates the Java to C++ Mapping for Subset of the ADAM C++ Server Legacy Code Written a Detailed Report Describing this Effort that will be Critical in Continuing this Work The Java/C++ Interface is Pivotal for Integrating and Upgrading Legacy Software to Java ECIC-1.71 Assessment of TwinPeaks Product CSE298 CSE300 CSE300 PROs To Our Knowledge, the Only Available Tool that Supports Java to C/C++ at High Abstract. Automates Tedious/Error Prone Process an of Generating Peer Java classes for C++ Code Offers Clever Techniques to Solve Mismatch Between Java and C/C++ Pointers Multiple Inheritance Operator Overloading Cost - Currently TwinPeaks is Free! ECIC-1.72 Assessment of TwinPeaks Product CSE298 CSE300 CSE300 CONS Supports Very Limited Platform Solais and SunSoft C++ What about Windows 95, NT, and Linux Apps? Based on Native Method Specification and not Up-to-Date JNI Potential for Incompatibility and/or Abandonment in Future Automatic, but Difficult to Use Very Limited Support/Documentation Minimal Small User Community ECIC-1.73 Assessment of TwinPeaks Product CSE298 CSE300 CSE300 CONs Requires Familiarity with SunSoft C++ and Java Native Method No Debugging Facilities Makes Understanding and Correcting Errors Difficult Generics, Unions, and other C/C++ Features not Supported No support for calling Java from C++ Conclusion: TwinPeaks is not a Stable Tool Falls Short of our Expectations Acceptance/Adoption for EC Applications is Premature!! ECIC-1.74 Architectural Alternatives & Framework CSE298 CSE300 CSE300 C++ Legacy Applications Upgrade to C/S Architectural Solution with Java Requires: Ability to Pull-Off or Disable Legacy GUI Needed to Support Wrapping Process May Not be Possible for Every Legacy/COTS application Source-Code Availability or Robust Programming Interface Alternative to Disable A Robust OO API Assist Wrapper Creation and Java to C++ Interactions ECIC-1.75 Architectural Alternatives & Framework CSE298 CSE300 CSE300 C++ Legacy Applications Upgrade to C/S Architectural Solution with Java Requires: Development of a New Java GUI/Client New GUI to Collect, Synthesize, Interpret Information from Multiple Legacy/COTS New/Innovative Uses for Legacy/COTS Applications Short-Term Persistence of Client Data Thin vs. Medium vs. Thick Clients For EC Applications, if Clients Leave Network, Local Storage is Needed Must Also Consider Limited Bandwidth ECIC-1.76 Architectural Alternatives & Framework CSE298 CSE300 CSE300 C++ Legacy Applications Upgrade to C/S Architectural Solution with Java Requires: Message Passing Interface to Legacy Appl. If Not Present, Embed in Communications Layer of both Client and Wrapper For EC Applications, Extra Layers May be Required to Transform Legacy Data to OO/Java Integration of Java and C++ Java Wrapper Requires Bi-Directional Exchange of Information to/from C++ Automated Tools (TwinPeaks) vs. JNI For EC Applications - C, C++, Ada, Fortran, etc. ECIC-1.77 Architectural Alternatives & Framework CSE298 CSE300 CSE300 Integration of Java and C++ Occurs within the Java Wrapper to C++ Server Requires Ability to Encompass and Build C++ Server as Shared Library Shared Library Interacts with TwinPeaks Bi-Directional Translation (Java to/from C++) May Require a New C++ Library for a Uniform Interface to Server C++ Classes Maintains Multiple Layers of Same Information in Different Formats Applicability to C Legacy Applications Techniques Extensible to C Providing that Workable Native C++ Library Available ECIC-1.78 Architectural Alternatives & Framework CSE298 CSE300 CSE300 Utilization of our Efforts on ADAM as Blueprint C++ Legacy Application (with/out GUI) Source Code Availability/Programming Interf. New Java Client Appls/Java Server Wrapper Message Passing Interface Redesign/Development of Java Client Classes that Mirror/Imitate Legacy Server Classes Introduction of Multiple Layers of Translation Increased Overhead with Java or CORBA Applicability to Well-Designed C Appls Conclusion: Significant Effort with Potential Long-Range Benefit of Common Java Medium ECIC-1.79 Architectural Alternatives & Framework CSE298 CSE300 CSE300 PROs Likely Applicable to C and C++ Component-Based, Organized Approach Greatly Facilitates Exchange of Information Solves the N x M Translation Problem CONs Additional Overhead Due to Translations Instability/Immaturity of TwinPeaks Complexity and Effort of Task Performance Degradation Unacceptable Conclusion: Do Java, CORBA, etc., Benefits Outweigh the Risks and Shortfalls? ECIC-1.80 Concluding Remarks and Discussion CSE298 CSE300 CSE300 What are Keys Issues that Influence and Guide the Integration Process for EC? Software Reuse in a Distributed Computing Environment Reuse Existing Legacy/COTS in Innovative Ways Not Cost Effective to Redesign/Reimplement EC Users will Demand Modern Interfaces on Upto-Date Platforms Wrappers for Cohesive/Seamless Interactions Apply to Languages (C, C++, Ada, etc.) and Paradigms (OODBS, CORBA, RPC) Address Communication, Translation, Security, Concurrency, Performance, Bandwidth, etc. ECIC-1.81 Concluding Remarks and Discussion CSE298 CSE300 CSE300 What are Keys Issues that Influence and Guide the Integration Process for EC? Communications Alternatives Dictated by Application Domain Tradeoffs of Low-Level (Sockets) vs. Mid-Level (RCP, RMI) vs. High-Level (CORBA, DCOM, …) Will EC Utilize Combination? Consistency of Information in Distributed Computing Environment When is Data Sent from Client to Legacy Server? Automatic (Regular) vs. User-Initiated? When Network Traffic is Low? EC Likely Spans Broad Spectrum ECIC-1.82 Java Beans and Enterprise Java Beans CSE298 CSE300 CSE300 Paul C. Barr The Mitre Corporation Eatontown NJ Kimble Cheron, Prof. Steven A. Demurjian, and Mitch Saba Computer Science & Engr. Dept. [email protected] [email protected] http://www.engr.uconn.edu/~steve (860) 486 - 4818 ECIC-1.83 Changing Perspectives CSE298 CSE300 CSE300 Computers are Guilty of Creating More Disorder then Simplicity Current Software Systems are Relics Built Largely By and For Technical Computer Users Never Intended to Operate in Today’s Environment Designer’s Need to Break Out of Old Mold Consider Total Design Space Design Should Help Manage Complexity, Not Add to It What is Available to Assist in Changing Times? ECIC-1.84 Components CSE298 CSE300 CSE300 Reusable Software Building Blocks Pre-Constructed from Encapsulated Application Code Easily Combined with Other Components Seamlessly Merged with Custom Code Rapid Prototyping of Complete Applicaiton What is a Component? GUI Widget (Button, Window, etc.) Combination of Components (Window with Elevator Bars and Pull-Down Menus) Application Service (Account Management Function) ECIC-1.85 Overview CSE298 CSE300 CSE300 A First Look at Java Beans What are They? How are They Utilized? Enterprise Java Beans Not Just for Clients Anymore! Capabilities and Usage Relationship to “New” and “Old” Technologies Component-Based Client/Server Model Multi-Tiered Architecture and EJB Tiered Development for Extensibility Comparisons of Approaches Java Blend for Database Interoperability ECIC-1.86 Java Beans CSE298 CSE300 CSE300 Extends "Write Once, Run Anywhere (WORA)TM" to Include "Reuse Everywhere” What is a Bean? Independent Reusable Software Component Visually Manipulated in Builder Tools Can Be Visible Object: AWT Components or Invisible Objects: Queues and Stacks or Composed Objects: Calculator Ops + Keys + Display ECIC-1.87 Java Beans CSE298 CSE300 CSE300 Bean vs. Component Source Code Inaccessible Customizable to Suit Application Needs via External Properties Powerful Means of Reuse Examples GUI Button with Property to Allow Button Name to be Set Account Management Component that Allows Account Database Location to be Set Properties Can be Very Complex and Offer Significant Power to Application Builders ECIC-1.88 What are Enterprise Java Beans ? CSE298 CSE300 CSE300 Expansion of Java Beans (Client-side) to Support Server Side Reusable Components Server Components Run on Application Server EJB Integral Part of Java Technology Component Architecture for Distributed Systems Multi-Tier Distributed Architecture Movement of Application Logic from Client to Server Side Creation of “Thin”, Easier to Maintain Clients Framework for Creating Middle Ware Integration of “New” and “Old” Technologies RMI, IIOP, CORBA, RPC, Active X, etc. ECIC-1.89 Designer and Developer Roles in Enterprise Java Beans (EJB) CSE298 CSE300 CSE300 Towards “Highly Scalable, Highly Available, Highly Reliable, Highly Secure, Transaction Distributed Applications” Enterprise Bean Provider Creates and Sells EJBs Application Assembler Uses EJBs to Build an Application EJB Server Provider Creates and Sells EJB Server EJB Container Provider Creates and Sells EJB Containers Server Provider Will Likely Provide Containers ECIC-1.90 EJB Roles & Deployment CSE298 CSE300 CSE300 ECIC-1.91 Utilizing EJB Technology CSE298 CSE300 CSE300 ECIC-1.92 The EJB Architecture CSE298 CSE300 CSE300 EJB Servers: Analogous to CORBA ORB Server Software Provides Naming and Transaction Services Makes Containers Visible EJB Containers: Interface Between EJB Bean and Outside World Client Never Accesses Bean Directly Access via Container-Generated Methods These Methods Then Call the Bean’s Methods EJB Clients Locate EJB Containers Via JNDI Make Use of EJB Beans Enterprise Java Beans - Discussed Shortly ECIC-1.93 EJB Container CSE298 CSE300 CSE300 ECIC-1.94 Enterprise Java APIs CSE298 CSE300 CSE300 ECIC-1.95 Enterprise Java Beans Session Beans CSE298 CSE300 CSE300 Associated With a Particular Client Performs Operations on Behalf of Client Accessing a Database Performing Calculations Created and Destroyed by a Client Can be Transactional - But, Do Not Survive System Shutdown Can be Stateless or Maintain Conventional State Across Methods and Transactions Must Manage Own Persistent Data ECIC-1.96 Enterprise Java Beans Entity Beans CSE298 CSE300 CSE300 Object Representation of Persistent Data Maintained in Permanent Store (Database Identifiable by Primary Key Shared by Multiple Clients Persist Across Multiple Invocations Survive System Shutdown Created by Inserting Data into Database Creating an Object Instance ECIC-1.97 Model for Persistence Passivation/Activation CSE298 CSE300 CSE300 Programmatic Model for Managing Persistent Objects EJB Server has the Right to Manage its Working Set Passivation Saves State of a Bean to Persistent Storage Then Swaps Bean Out Activation Restores State of a Bean From Persistent Storage,Then Swaps Bean in Applies to Both Session and Entity Beans ECIC-1.98 Stateless vs. Stateful Session Beans CSE298 CSE300 CSE300 Stateless No Internal State Do Not Need to Be "Pass-ivated" Can Be Pooled to Service Multiple Clients Stateful Possess Internal State Need to Handle Passivation/Activation One Per Client ECIC-1.99 Entity Bean Persistence CSE298 CSE300 CSE300 Container-Managed Container is Responsible for Saving State In Deployment Descriptor, Specify ContainerManaged Fields Persistence Independent of Data Source Bean-Managed Bean is Responsible for Saving its Own State Container Doesn’t Need to Generate DB Calls Less Adaptable; Persistence is Hard-Coded ECIC-1.100 Deploying EJBs CSE298 CSE300 CSE300 EJBs Deployed As .SER Files: Serialized Instance Manifest File Used to List EJBs Must Also Provide a “Deployment Descriptor” Sample Entry Name: paul.RestaurantDeployment.ser Enterprise-Bean: True “Name” Line Describes a Serialized Deployment Descriptor “Enterprise-Bean” Line Indicates Whether the Entry Should Be Treated as an EJB (Not All Entries Need to Be EJBs) ECIC-1.101 Who’s Announced EJB Support? CSE298 CSE300 CSE300 WebLogic IBM Oracle GemStone BEA Borland Netscape Lotus Forte Progress Novell Novera Borland Informix IONA More... ECIC-1.102 Typical Development and Deployment Scenario CSE298 CSE300 CSE300 EJB Server Provider Creates and Sells an EJB Server Provides EJB Containers That Will Run on These Servers EJB Providers Individuals Responsible for Developing the EJBs Provide “Tools” and “Components” for DownStream Usage Application Assemblers Individuals that Utilize Pre-Built EJBs to Construct Their Domain-Specific Applications Utilize “State-of-Art-Tools” for EJB and JB ECIC-1.103 EJB Component-Based Architecture CSE298 CSE300 CSE300 EJB Server EJB Client Invoke EJB Container Methods Enterprise Java Bean Invoke EJB Methods EJB Container ECIC-1.104 Client-Server Component Model CSE298 CSE300 CSE300 ECIC-1.105 Two-Tier, Three-Tier, Four-Tier Example Architectures CSE298 CSE300 CSE300 From: http://java.sun.com/javaone/javaone98/sessions/T400/index.html ECIC-1.106 Wombat Securities CSE298 CSE300 CSE300 Web Access to Brokerage Accounts Only HTML Browser Required on Front End "Brokerbean" EJB Provides Business Logic Login, Query, Trade Servlets Call Brokerbean Use JNDI to Find EJBs, RMI to Invoke Them Order and History Records from Java Blend Product Records Mapped to Oracle Tables, JDBC Calls ECIC-1.107 Four-Tier Architecture Example CSE298 CSE300 CSE300 ECIC-1.108 Nocturnal Aviation, Inc. CSE298 CSE300 CSE300 Passenger Check-in for Regional Airline Local Database for Seating on Today's Flights Clients Invoke EJBs at Local Site Through RMI EJBs Update Database and Queue Updates JMS Queues Updates to Legacy System DBC API Used to Access Local Database JTS Synchs Remote Queue With Local Updates ECIC-1.109 Three-Tier Example CSE298 CSE300 CSE300 ECIC-1.110 Santa Cruz Widgets CSE298 CSE300 CSE300 Small Manufacturer Previously on C++ New Order Entry, Inventory, and Invoicing Applications in Java Programming Language Existing Customer and Order Database Most of Business Logic in Stored Procedures Tool-generated GUI Forms for Java Objects Located Company on Web Using Widgets and Tcl, but Not Widgets and Java ECIC-1.111 Santa Cruz Widgets (2-tier) CSE298 CSE300 CSE300 ECIC-1.112 Architecture Comparisons CSE298 CSE300 CSE300 Two-tier Through JDBC API: Simplest Multi-tier: Separate Business Logic, Protect Database Integrity, More Scaleable JMS Queues Vs Synchronous (RMI or IDL): Availability, Response Time, Decoupling JMS Publish & Subscribe: Off-line Notification RMI IIOP Vs JRMP Vs Java IDL: Standard Cross-language Calls or Full Java Functionality JTS: Distributed Integrity, Lockstep Actions ECIC-1.113 Further API Comparisons CSE298 CSE300 CSE300 Servlets: Simplifies HTML, Connections, Web Front-Ending Legacy Systems EJBs: Simplifies Components, Scalability, Transactions, Multi-threading, Security, State JDBC Vs ODMG Vs SQLJ API: Programming Simplicity, Portability, SQL Knowledge JNDI: Standardized Name Service Access Enterprise Java APIs vs. Proprietary: Multi-Platform, Multiple Providers ECIC-1.114 Summary & Key Messages CSE298 CSE300 CSE300 Enterprise Java APIs: EJB, JNDI, Java IDL, RMI, JDBC, ODMG, SQLJ, JMS, JTS, JMAPI, Servlets Wide Variety of Architectural Alternatives: Synchronous/Asynchronous, Multi-Tier, Transactional, HTTP/JRMP/IIOP Benefits: WORA Portability Multiple Vendors Legacy Connectivity Java Programming Language Productivity ECIC-1.115 EJB Roadmap CSE298 CSE300 API EJB CSE300 JNDI JIDL RMI JDBC ODMG SQLJ JMS JTS JMAPI Sevlets Specification Complete Products JavaSoft JavaSoft OMG JavaSoft JavaSoft Consortium Consortium JavaSoft OMG JavaSoft JavaSoft 1.0Q1 1.0 done 1.0 Q2 1.0 done 2.0 Q2 2.0 done 1.0 Q2 1.0 Q2 1.0 done 1.0 Q2 1.1 done See Partners Download SP JDK 1.2 JDK 1.1 JDK 1.2 Partner JavaBlend See Partners See Partners Partners See Partners Java Web Server ECIC-1.116 What Is the Java Blend Product? CSE298 CSE300 CSE300 Product That Integrates Java Programming Language Objects With Enterprise Data Provides a Single Object Model Based on Java Programming Language Classes Automatic Persistent Storage for Java Application Objects Easy, Automatic Access to Existing Relational Databases From Java Applications Result of Joint Development by the Javasoft Division, Baan and Tech@spree ECIC-1.117 JavaBlend Applications CSE298 CSE300 CSE300 JavaBlend Software Provides Mapping Capability Between Database Tables and Java Application Classes Programmer Deals Only With Java Programming Language Objects, and Does Not Need to Know SQL or Database Representation ECIC-1.118 Java Blend Components CSE298 CSE300 CSE300 Flexible Development Tool for Automatic Bi-Directional Mapping Objects to Relational Relational to Objects Powerful Runtime Environment Transaction Management System Query Processor Cache Management System ECIC-1.119 Java Blend Runtime Architecture CSE298 CSE300 CSE300 ECIC-1.120 Java Blend Software and Enterprise JavaBeans Technology CSE298 CSE300 CSE300 EJB Technology Provides Scaleable Component Architecture for Business Applications Java Blend Product Provides Transparent Persistence for Enterprise Javabeans Technology Beans Implementing Business Logic Use Java Blend for Database Access Java Blend Product Works With the Enterprise Javabeans API Transaction Mechanisms ECIC-1.121 Concluding Remarks Enterprise Computing/Interoperability CSE298 CSE300 CSE300 Technologies Continue to Emerge and Mature Complex Problem for Companies and Organizations What are “Good” and “Stable” Technologies? How can they be Leveraged for Gain? Which Technologies Will Emerge in ShortTerm and Long-Term? How will Technologies Interact? CORBA vs. DCOM vs. EJB Java vs. Component Design/Programming Heterogeneous Agent Platforms Future Difficult to Predict! ECIC-1.122