Enterprise Computing and Interoperability CSE 298 CSE 300 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/~stev e (860) 486 - 4818 † Special Thanks to Prof. Alex Shvartsman and Scott Craig for providing portions of this material. ECIC-1. 1
Overview of Presentation CSE 298 CSE 300 m m m m What is Enterprise Computing? Interoperability and CORBA q Primer q Key Concepts and Ideas q System Design with CORBA/IDL Interoperability Strategies q General Approaches q Java-Based Wrapper Security Issues for Enterprise Computing q What are Key Issues re. Security for EC? q How are Legacy/COTS Handled? Concluding Remarks ECIC-1. 2
What is Enterprise Computing? CSE 298 CSE 300 m Today’s and Tomorrows Applications are System of Systems q Facilitate Interactions/Information Exchange q Leverage Existing Information, Resources, and Applications in New Environment q Interoperability Key Issue Strive for New/Innovative Application Usage in Distributed Environment - For Example … q Expand to Multi-User Capabilities q Incorporate Modern GUI q Introduce Useful Functionality q Upgrade to Web-Based Access ECIC-1. 3
Role of an Object Request Broker (ORB) CSE 298 m CSE 300 m m m ORB Provides the Underlying Infrastructure for Supporting Interoperating Software Systems (Applications) Composed of Distributed Objects q ORB Provides the Basic Request Delivery q 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 ECIC-1. 4
Interface Definition Language, IDL CSE 298 CSE 300 m Key Component of CORBA Is the Interface Definition Language, IDL q Mapping is Available in C, C++, Java, Ada, Etc. q IDL Is Independent of Any Language/Compiler q Multiple Inheritance q Public Interface Oriented q Not for Implementation Primary Support for Interoperability Between Static and Dynamic Request Mechanisms ECIC-1. 5
ORB and High Level View of Requests CSE 298 CSE 300 m CSE 300 The Request Consists of q Target Object q Operation (Method) q Parameters q Request Context (Optional) ECIC-1. 6
CORBA Components and Interfaces CSE 298 m CSE 300 m m m 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 per object adaptor One interface per object operation ORB internal interface ECIC-1. 7
Interfaces CSE 298 CSE 300 m m 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 CSE 298 CSE 300 m m 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: q Interface Repository (IR) q Context Management q 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 CSE 298 CSE 300 m m CSE 300 m Implementations Receive Requests Thru Skeletons Object Adapter Adapts to Specifics of Object Implementation Schemes Basic Object Adapter (BOA) Provides: q Management of References q Method Invocation q Authentication q Implementation Registration q 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) CSE 298 CSE 300 m DII Allows Clients to Dynamically: q Discover Objects’ Interfaces q Create Requests q Invoke Requests (-> Methods) q Receive Responses Major DII Features: q Requests Appear as Objects q Requests are Reusable q Invocation May be Synchronous or Asynchronous q Requests Can be Generated Dynamically, Statically or Using Both Approaches ECIC-1. 11
Request Components CSE 298 CSE 300 m m m m 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 CSE 298 CSE 300 m Interface Repository q Dynamic Client Access to Interface Definitions to Construct a Request q Dynamic Type Checking of Request Signatures q Traversal of Inheritance Graphs Implementation Repository q Location of Implementations and Methods q Activation Information q Administration Control q Resource Allocation q Security ECIC-1. 13
Three Types of ORBs CSE 298 CSE 300 m CSE 300 Single Process Library Resident Client ORB m Object ORB and implementations implemented as libraries (routines) resident in the client. Request Client and Implementation Resident Client ORB Object Request ORB implemented as libraries (routines) resident in the clients and in the implementations. ECIC-1. 14
Three Types of ORBs CSE 298 CSE 300 m Server or Operating System Based CSE 300 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 CSE 298 CSE 300 m CSE 300 Single Process “one shot” Object Implementation Single Process Single method invocation m Implementation is a single process that is activated upon the request delivery Multi-Threaded “resident” 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 CSE 298 CSE 300 m Multi-Process Object CSE 300 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 CSE 298 CSE 300 Scott A. Craig Computer Science & Engineering Department The University of Connecticut Storrs, Connecticut 06269 -3155 scraig@engr. uconn. edu ECIC-1. 18
Overview of Presentation CSE 298 CSE 300 m Introduction to OMG IDL Object Management Architecture q CORBAservices Ø Naming Service Ø Event Service m m m Typed Event Example References Concluding Remarks ECIC-1. 19
Interface Definition Language, IDL CSE 298 CSE 300 m m m m 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. q Operation declaration consists of a return type, an identifier, a parameter list, and an optional raises expression (exceptions). q 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 CSE 298 CSE 300 m Module: Used to scope IDL identifiers. q Mapped to C++ namespace with the same name. Mapped to a C++ class if the namespace construct is not supported. q Mapped to Java package with the same name. q 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. q Multiple inheritance supported q Interface body may contain the following kinds of declarations: constant, type, attribute, and operation. ECIC-1. 21
IDL: Basic Types CSE 298 CSE 300 ECIC-1. 22
IDL: Complex Types CSE 298 CSE 300 m m Structures: q struct Fixed. Length. Struct { long field 1; // 32 -bit short field 2; // 16 -bit }; q struct Variable. Length. Struct { long field 1; // 32 -bit string field 2; }; Discriminated Unions: Cross between the C union and switch statements. Enumerations: Ordered list of identifiers. q enum quality_t { Poor, Fair, Good, Excellent}; ECIC-1. 23
IDL: Complex Types (cont. ) CSE 298 CSE 300 m m Sequences: One-dimensional array with maximum size (fixed at compile time) and length (set at run time). q Unbounded Sequence: typdef sequence<long> long. Seq; q Bounded Sequence: sequence<long, 10> fieldname; Strings: Declared using keyword string. May be bounded or unbounded. q string name<32>; //bounded Arrays: Multidimensional, fixed-size arrays of any IDL data type. ECIC-1. 24
IDL Example: GUI CSE 298 CSE 300 /* * File Name: */ CSE 300 #ifndef GUI_IDL #define GUI_IDL interface Dialog 1 { void update(in Dialog 1 Data_t val); }; GUI. idl module GUI { struct timespec_t { long tv_sec; long tv_nsec; }; interface Dialog 2 { void update(in Dialog 2 Data_t val); }; }; #endif // GUI_IDL struct Dialog 1 Data_t { timespec_t Data. Time; float val; }; struct Dialog 2 Data_t { timespec_t Data. Time; long val; }; interface Main. Window { void log. Event(in timespec_t timestamp, in string val); }; ECIC-1. 25
IDL Example: Server CSE 298 CSE 300 /* * File Name: */ CSE 300 #ifndef SERVER_IDL #define SERVER_IDL Server. idl #include "GUI. idl" interface Server { void register. Dialog 1( in GUI: : Dialog 1 val, in boolean flag) raises (Operation. Timeout); void set. Dialog 1 Enabled( in boolean flag) raises (Operation. Timeout); GUI: : Dialog 1 Data_t get. Dialog 1 Data() raises (Operation. Timeout, Not. Available); enum reason_t { Not. Initialized, Error. Detected }; exception Not. Available { reason_t reason; }; void register. Dialog 2( in GUI: : Dialog 2 val, in boolean flag) raises (Operation. Timeout); void set. Dialog 2 Enabled( in boolean flag) raises (Operation. Timeout); GUI: : Dialog 2 Data_t get. Dialog 2 Data() raises (Operation. Timeout, Not. Available); exception Operation. Timeout {}; void register. Main. Window( in GUI: : Main. Window val, in boolean flag) raises (Operation. Timeout); void set. Main. Window. Enabled( in boolean flag) raises (Operation. Timeout); }; #endif // SERVER_IDL ECIC-1. 26
Object Management Architecture CSE 298 CSE 300 m 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: q Object Request Broker (CORBA): Ø Provides communications infrastructure. q Object Services (CORBAservices): Ø Collection of fundamental services (interfaces and objects) for using and implementing objects. q Common Facilities (CORBAfacilities): Ø Services such as system management. q Application Objects Ø Not standardized. ECIC-1. 27
CORBAservices CSE 298 CSE 300 m m m OMG specification for Object Services Collection of 15 services (interfaces and objects) that support basic functions for using and implementing objects. q Interfaces specified using IDL Will focus on two services: q Naming Service q Event Service Security Service: Addresses identification and authentication, authorization and access control, security of communication between objects, etc. q Beyond scope of this presentation (specification is 386 pages in length) ECIC-1. 28
Naming Service CSE 298 m CSE 300 m m 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. q Directed graph with labeled edges in which nodes are objects. q Compound names are formed by the sequence of names along a path from the root to the leaf. ECIC-1. 29
Naming Graph CSE 298 CSE 300 Engineering CSE 300 Dean EE CSE <Engineering; Dean> Pharmacy Practice Dean Science <Pharmacy; Dean> Context Application Object ECIC-1. 30
Cos. Naming. Module CSE 298 CSE 300 m Naming. Context Interface Operations: q Binding Names: bind(. . . ), rebind(. . . ), bind_context(…), rebind_context(…) q Resolving Names: resolve(…) q Unbinding Names: unbind(…) q Creating Naming Contexts: new_context(), bind_new_context(…) q Deleting Contexts: destroy() q Listing a Naming Context: list(…) Binding. Iterator Interface: Allows a client to iterate through the bindings using next_one(…) or next_n(…) operations. ECIC-1. 31
Event Service CSE 298 CSE 300 m m m A standard CORBA request issued by a client results in the synchronous execution of an operation by an object (server). q Request directed to a particular object. q Client must handle exceptions if request fails. Event Service decouples communication between objects, defining two roles for objects: q Supplier Role: Produce event data q 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 CSE 298 CSE 300 m m m m Allow multiple consumers and multiple suppliers. Consumers can either request events (pull model) or be notified of events (push model). q 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). q Implementation dependent. ECIC-1. 33
Push Model CSE 298 CSE 300 m m m Suppliers realize Push. Supplier interface and consumers realize Push. Consumer interface. Suppliers invoke push operations on Push. Consumer interface. q 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 CSE 298 CSE 300 m m m Suppliers realize Pull. Supplier interface and consumers realize Pull. Consumer interface. Consumers invoke pull operations on Push. Supplier interface. q 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 CSE 298 CSE 300 m m m Event Channel is a service that decouples communication between suppliers and consumers. q Allows multiple suppliers to communicate with multiple consumers asynchronously. q Is both a consumer and a supplier of events. Push-Style Communication with an Event Channel q Supplier pushes event data to Event Channel, which then pushes event data to consumer. Pull-Style Communication with an Event Channel q 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. ) CSE 298 CSE 300 m CSE 300 Multiple Consumers and Multiple Suppliers q Event Channel consumes events from one or more suppliers and supplies events to one or more consumers. S 1: Supplier S 2: Supplier Push. Consumer Push. Supplier : Event. Channel Push. Consumer Push. Supplier C 1: Consumer . . . CN: Consumer ECIC-1. 37
Typed Event Communication CSE 298 CSE 300 m 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 q The interface that the consumer will realize is defined in IDL, subject to restrictions. Ø Only “in” parameters are allowed. Ø No return values are permitted. q q Operations may be declared as “oneway. ” The user defined interface must inherit from Cos. Typed. Event. Comm: : Typed. Push. Consumer. ECIC-1. 38
Typed. Push. Consumer CSE 298 CSE 300 ECIC-1. 39
Typed Event Example CSE 298 CSE 300 m m 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 Typed. Push. Consumer. q Fixed-length structure is pushed via the “update” operation. q Notification structure is pushed via the “notification” operation. q Structures contain field to identify Supplier. ECIC-1. 40
Typed Event Example (cont. ) CSE 298 CSE 300 m m m 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 CSE 298 CSE 300 ECIC-1. 42
Component Diagram: Source Files CSE 298 CSE 300 ECIC-1. 43
Component Diagram: Executables CSE 298 CSE 300 Supplier User_cs Push. Supplier User_ev Event. Channel User_ev Push. Supplier Consumer ECIC-1. 44
Collaboration Diagram CSE 298 CSE 300 ECIC-1. 45
Deployment Diagram (degenerate) CSE 298 CSE 300 S 1: Supplier {source 1} User_cs S 2: Supplier {source 2} Push. Supplier User_cs User_ev : Event. Channel User_ev Push. Supplier C 1: Consumer . . . CN: Consumer ECIC-1. 46
Design Considerations CSE 298 CSE 300 m m m m 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 CSE 298 CSE 300 m m m 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 CSE 298 CSE 300 m m m Introduced OMG IDL q Mappings to C++, Java, etc. Provided overview of OMG Object Management Architecture and the role of Object Services. q Provided overview of Naming Service and Event Service. Presented a distributed system that makes use of Naming and Event Services. Future Work: q Investigation of Security Services ECIC-1. 49
Interoperability Strategies CSE 298 CSE 300 m m m m Architectural Alternatives and Frameworks q Taxonomy of Architectural Variants q Integration via Java, CORBA, etc. Case Study: The ADAM Environment q Upgrading a C++ Legacy Application to be Java-Compatible q Pros and Cons of Effort Issues for Interoperability Outlining Future Efforts and Emphases Concluding Remarks and Discussion ECIC-1. 50
Architectural Alternatives & Framework CSE 298 CSE 300 m Reviewing Architectural Variants q Java Client to Legacy Appl. via RDBS q ORB Integration of Java Client and Legacy Application q Java Client with Wrapper to Legacy Appl. q 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 CSE 298 CSE 300 Transformed Legacy Data Java Client Updated Data Relational Database System(RDS) Extract and Generate Data Transform and Store Data Legacy Application ECIC-1. 52
CSE 298 CSE 300 ORB Integration of Java Client and Legacy Application Java Client Legacy Application Java Wrapper Object Request Broker (ORB) CORBA is the Medium of Info. Exchange Requires Java/CORBA Capabilities ECIC-1. 53
CSE 298 CSE 300 Java Client with Wrapper to Legacy Application Java Client Java Application Code WRAPPER Mapping Classes JAVA LAYER NATIVE LAYER Native Functions (C++) RPC Client Stubs (C) Interactions Between Java Client and Legacy Appl. via C and RPC C is the Medium of Info. Exchange Java Client with C++/C Wrapper Legacy Application Network ECIC-1. 54
One COTS and One Legacy Application to Java Clients CSE 298 CSE 300 COTS Application Legacy Application CSE 300 Java Application Code Native Functions that Map to COTS Appl NATIVE LAYER Native Functions that Map to Legacy Appl NATIVE LAYER JAVA LAYER Mapping Classes JAVA NETWORK WRAPPER Network Java Client Java is Medium of Info. Exchange - C/C++ Appls with Java Wrapper ECIC-1. 55
ADAM: User Perspective CSE 298 CSE 300 Code/Documentation Generation ADAM Graphical User Interface C++ Ada 83, Ada 95 Eiffel Java (on PC/NT) Ascii/Latex Doc. OO Design Server Abstraction for Design Persistence Multiple Versions: ADAM/Unix: IV 3. 1, X, Sparcstation ADAM/PC: Win 95, Borland C++ ADAM/NT: Under Development Ontos OODBS ECIC-1. 56
Case Study: The ADAM Environment CSE 298 CSE 300 m m ADAM is a C++ Legacy Application with: q GUI Interviews/Unidraw q Core C++ Internal Classes which are Compiler Independent q Designs Stored in Ontos OODBS Redesign/Reformulate ADAM as: q Java Client that Replaces C++ GUI q Java Server Wraps Core C++ Internal Classes q C/S Communications via Java q 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 CSE 298 CSE 300 m m m C++ Class Library - Intended as a Single-CPU, Single-User, Interactive Design Environment C++ Classes Structured as Multiple Interacting Hierarchies for Different Components: q C++ Classes for GUI q C++ Classes to Store Design as it is Created q C++ Classes for Code Generation Capabilities q 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 CSE 298 CSE 300 Design/Generation Compiler Independent Software ADAM Graphical User Interface C++ Classes/Instances to Store Design and Code Generation Algorithms OO Design C++ Ontos C++ Ada 83, Ada 95 Eiffel Java (on PC) ADAM/Unix: IV 3. 1, X, Sparcstation ADAM/PC: Win 95, Borland C++ DB Server Abstraction for Design Persistence Ontos OODBS ECIC-1. 59
Client Requirements and Functionalities CSE 298 CSE 300 m New ADAM Java Client Replicates Core C++ Classes to Allow Transitory Storage of Designs: q Existing Designs from Legacy Server Storable at ADAM Java Client q New/Existing Designs at Java Client Locally Manipulated to Reduce Communication Traffic q New/Existing Designs Sent to Legacy Server for Persistent Storage Java Communications from Client to Server q Transmission of Modified Design to Server q Receipt of Existing Design from Server q Both Accomplished via Object Serialization ECIC-1. 60
Client Requirements and Functionalities CSE 298 CSE 300 Designs at Client to Reduce Communication Overhead Existing Designs Sent/Loaded for Local Manipulation OO Design New ADAM Java User Interface (Client) ADAM C++ Legacy Application (Server) Java/Twin. Peaks Wrapper Completed New Designs or Revised Existing Designs Sent for Persistent Storage ECIC-1. 61
ADAM: Target Software Architecture CSE 298 CSE 300 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/Twin. Peaks Wrapper ECIC-1. 62
Wrapper Requirements and Functionalities CSE 298 CSE 300 m m m Transmission/Receipt of Messages from Clients Existing Design from Server to Client q Locating C++ Instances in Legacy Server q Creation of Java Instances from C++ Instances q Object Serialization of Java Instances to Client Store New/Existing Design from Client to Server q Receipt of Java Instances via O-Serialization q Creation of C++ Instances from Java Instances q Storage of C++ Instances into Legacy Server Interactions between Java and C++ via Java Native Interface (JNI) or Twin. Peaks ECIC-1. 63
ADAM: Client/Wrapper Components CSE 298 CSE 300 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 CSE 300 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 CSE 298 CSE 300 Twin. Peaks Library Folder Translation Java to C++ Wrapper C++ Common Interface Java Design Classes and Instances Class Folder Communication CSE 300 ADAM C++ Legacy Classes and Instances Legacy Application ECIC-1. 65
Communication Requirements and Functionalities CSE 298 CSE 300 m Layers of Classes/Instances (Client vs. Server) q Interface (GUI) Classes and Instances (C) q Java Design Classes and Instances (C&S) q Java Communication Classes and Instances (C&S) q Translation Java to C++ Classes and Instances (S) Communications q Sockets (Current) q Object Serialization (Current) q CORBA/ORBs vs. RMI (Future) ECIC-1. 66
ADAM: Socket Communications CSE 298 CSE 300 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 CSE 300 Translation Java to C++ Legacy Code Adam C++ Server Potential Performance Issue: Multiple Layers of Translation ECIC-1. 67
Twin. Peaks Requirements and Functionalities CSE 298 CSE 300 m Evaluated Feasibility of JNI q Directly Access Native Layer q Eliminates Platform Independence q Difficult to Understand Use Exploring Twin. Peaks Product q Beta Product from Sun q Automatically Generates Java Interface to C or C++ Native Library q Analyzes Native Library Header Files to Produce a Java API that Closely Mirrors Original C/C++ API q Generates Platform Specific Native Code ECIC-1. 68
ADAM: Twin. Peaks Architecture CSE 298 CSE 300 Java Application C++ Implemen. Files (. c) INPUT GENERATE C++ Header Files (. h) Twin. Peaks C++ Application Java Interface Class Folder (. java/. class) Java/C++ Bridge Lib. Folder C++ DLL ECIC-1. 69
Status of Twin. Peaks Effort CSE 298 CSE 300 m Established Twin. Peaks Environment q Downloaded Multiple Times due to Difficulty in Setting up Software and Multiple Releases by Sun. Soft q Worked to Understand the Mechanism and Proper steps Needed to work with Twin. Peaks UConn Beta Testing Site of Product: q Initial Efforts in Sept and Oct 97 Provided Feedback and Suggestions to Sun. Soft q Many of Suggestions for Improvement Reflected in the Second Release ECIC-1. 70
Status of Twin. Peaks Effort CSE 298 CSE 300 m m As of January 15, 1998 q Installed Newest Twin. Peaks Release q 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 Twin. Peaks Product CSE 298 CSE 300 m CSE 300 PROs q To Our Knowledge, the Only Available Tool that Supports Java to C/C++ at High Abstract. q Automates Tedious/Error Prone Process an of Generating Peer Java classes for C++ Code q Offers Clever Techniques to Solve Mismatch Between Java and C/C++ Ø Pointers Ø Multiple Inheritance Ø Operator Overloading q Cost - Currently Twin. Peaks is Free! ECIC-1. 72
Assessment of Twin. Peaks Product CSE 298 CSE 300 m CONS q Supports Very Limited Platform Ø Solais and Sun. Soft C++ Ø What about Windows 95, NT, and Linux Apps? q q q 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 Twin. Peaks Product CSE 298 CSE 300 m CONs q Requires Familiarity with Sun. Soft C++ and Java Native Method q No Debugging Facilities Makes Understanding and Correcting Errors Difficult q Generics, Unions, and other C/C++ Features not Supported q No support for calling Java from C++ Conclusion: q Twin. Peaks is not a Stable Tool q Falls Short of our Expectations q Acceptance/Adoption for EC Applications is Premature!! ECIC-1. 74
Architectural Alternatives & Framework CSE 298 CSE 300 m CSE 300 C++ Legacy Applications Upgrade to C/S Architectural Solution with Java Requires: q Ability to Pull-Off or Disable Legacy GUI Ø Needed to Support Wrapping Process Ø May Not be Possible for Every Legacy/COTS application q 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 CSE 298 CSE 300 m CSE 300 C++ Legacy Applications Upgrade to C/S Architectural Solution with Java Requires: q 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 q 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 CSE 298 CSE 300 m CSE 300 C++ Legacy Applications Upgrade to C/S Architectural Solution with Java Requires: q 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 q Integration of Java and C++ Ø Java Wrapper Requires Bi-Directional Exchange of Information to/from C++ Ø Automated Tools (Twin. Peaks) vs. JNI Ø For EC Applications - C, C++, Ada, Fortran, etc. ECIC-1. 77
Architectural Alternatives & Framework CSE 298 CSE 300 m Integration of Java and C++ q Occurs within the Java Wrapper to C++ Server q Requires Ability to Encompass and Build C++ Server as Shared Library q Shared Library Interacts with Twin. Peaks q Bi-Directional Translation (Java to/from C++) q May Require a New C++ Library for a Uniform Interface to Server C++ Classes q Maintains Multiple Layers of Same Information in Different Formats Applicability to C Legacy Applications q Techniques Extensible to C Providing that Workable Native C++ Library Available ECIC-1. 78
Architectural Alternatives & Framework CSE 298 CSE 300 m Utilization of our Efforts on ADAM as Blueprint q C++ Legacy Application (with/out GUI) q Source Code Availability/Programming Interf. q New Java Client Appls/Java Server Wrapper q Message Passing Interface q Redesign/Development of Java Client Classes that Mirror/Imitate Legacy Server Classes q Introduction of Multiple Layers of Translation q Increased Overhead with Java or CORBA q Applicability to Well-Designed C Appls Conclusion: Significant Effort with Potential Long -Range Benefit of Common Java Medium ECIC-1. 79
Architectural Alternatives & Framework CSE 298 CSE 300 m m PROs q Likely Applicable to C and C++ q Component-Based, Organized Approach q Greatly Facilitates Exchange of Information q Solves the N x M Translation Problem CONs q Additional Overhead Due to Translations q Instability/Immaturity of Twin. Peaks q Complexity and Effort of Task q Performance Degradation Unacceptable Conclusion: Do Java, CORBA, etc. , Benefits Outweigh the Risks and Shortfalls? ECIC-1. 80
Concluding Remarks and Discussion CSE 298 CSE 300 m CSE 300 What are Keys Issues that Influence and Guide the Integration Process for EC? q 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 Up-to -Date Platforms q 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 CSE 298 CSE 300 m CSE 300 What are Keys Issues that Influence and Guide the Integration Process for EC? q 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? q 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
CSE 298 CSE 300 Java Beans and Enterprise Java Beans Paul C. Barr The Mitre Corporation Eatontown NJ Kimble Cheron, Prof. Steven A. Demurjian, and Mitch Saba Computer Science & Engr. Dept. poobarr@mitre. org steve@engr. uconn. edu http: //www. engr. uconn. edu/~stev e (860) 486 - 4818 ECIC-1. 83
Changing Perspectives CSE 298 CSE 300 m m m Computers are Guilty of Creating More Disorder then Simplicity Current Software Systems are Relics q Built Largely By and For Technical Computer Users q Never Intended to Operate in Today’s Environment Designer’s Need to Break Out of Old Mold q Consider Total Design Space q Design Should Help Manage Complexity, Not Add to It What is Available to Assist in Changing Times? ECIC-1. 84
Components CSE 298 CSE 300 m m Reusable Software Building Blocks Pre-Constructed from Encapsulated Application Code q Easily Combined with Other Components q Seamlessly Merged with Custom Code q Rapid Prototyping of Complete Applicaiton What is a Component? q GUI Widget (Button, Window, etc. ) q Combination of Components (Window with Elevator Bars and Pull-Down Menus) q Application Service (Account Management Function) ECIC-1. 85
Overview CSE 298 CSE 300 m m m A First Look at Java Beans q What are They? q How are They Utilized? Enterprise Java Beans q Not Just for Clients Anymore! q Capabilities and Usage q Relationship to “New” and “Old” Technologies q Component-Based Client/Server Model Multi-Tiered Architecture and EJB q Tiered Development for Extensibility q Comparisons of Approaches Java Blend for Database Interoperability ECIC-1. 86
Java Beans CSE 298 CSE 300 m Extends "Write Once, Run Anywhere (WORA)TM" to Include "Reuse Everywhere” What is a Bean? q Independent Reusable Software Component q Visually Manipulated in Builder Tools q Can Be Visible Object: Ø AWT Components q or Invisible Objects: Ø Queues and Stacks q or Composed Objects: Ø Calculator Ops + Keys + Display ECIC-1. 87
Java Beans CSE 298 CSE 300 m m Bean vs. Component q Source Code Inaccessible q Customizable to Suit Application Needs via External Properties q Powerful Means of Reuse Examples q GUI Button with Property to Allow Button Name to be Set q 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 ? CSE 298 CSE 300 m m Expansion of Java Beans (Client-side) to Support Server Side Reusable Components q Server Components Run on Application Server q EJB Integral Part of Java Technology Component Architecture for Distributed Systems q Multi-Tier Distributed Architecture q Movement of Application Logic from Client to Server Side q Creation of “Thin”, Easier to Maintain Clients Framework for Creating Middle Ware q Integration of “New” and “Old” Technologies q RMI, IIOP, CORBA, RPC, Active X, etc. ECIC-1. 89
Designer and Developer Roles in Enterprise Java Beans (EJB) CSE 298 CSE 300 m m m m Towards “Highly Scalable, Highly Available, Highly Reliable, Highly Secure, Transaction Distributed Applications” Enterprise Bean Provider q Creates and Sells EJBs Application Assembler q Uses EJBs to Build an Application EJB Server Provider q Creates and Sells EJB Server EJB Container Provider q Creates and Sells EJB Containers q Server Provider Will Likely Provide Containers ECIC-1. 90
EJB Roles & Deployment CSE 298 CSE 300 ECIC-1. 91
Utilizing EJB Technology CSE 298 CSE 300 ECIC-1. 92
The EJB Architecture CSE 298 CSE 300 m m m EJB Servers: Analogous to CORBA ORB q Server Software q Provides Naming and Transaction Services q Makes Containers Visible EJB Containers: Interface Between EJB Bean and Outside World q Client Never Accesses Bean Directly q Access via Container-Generated Methods q These Methods Then Call the Bean’s Methods EJB Clients q Locate EJB Containers Via JNDI q Make Use of EJB Beans Enterprise Java Beans - Discussed Shortly ECIC-1. 93
EJB Container CSE 298 CSE 300 ECIC-1. 94
Enterprise Java APIs CSE 298 CSE 300 ECIC-1. 95
Enterprise Java Beans Session Beans CSE 298 CSE 300 m m m Associated With a Particular Client Performs Operations on Behalf of Client q Accessing a Database q 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 CSE 298 CSE 300 m m m 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 q Inserting Data into Database q Creating an Object Instance ECIC-1. 97
Model for Persistence Passivation/Activation CSE 298 CSE 300 m m m m Programmatic Model for Managing Persistent Objects EJB Server has the Right to Manage its Working Set Passivation q Saves State of a Bean to Persistent Storage q Then Swaps Bean Out Activation q Restores State of a Bean From Persistent q Storage, Then Swaps Bean in Applies to Both Session and Entity Beans ECIC-1. 98
Stateless vs. Stateful Session Beans CSE 298 CSE 300 m Stateless q No Internal State q Do Not Need to Be "Pass-ivated" q Can Be Pooled to Service Multiple Clients Stateful q Possess Internal State q Need to Handle Passivation/Activation q One Per Client ECIC-1. 99
Entity Bean Persistence CSE 298 CSE 300 m Container-Managed q Container is Responsible for Saving State q In Deployment Descriptor, Specify Container. Managed Fields q Persistence Independent of Data Source Bean-Managed q Bean is Responsible for Saving its Own State q Container Doesn’t Need to Generate DB Calls q Less Adaptable; Persistence is Hard-Coded ECIC-1. 100
Deploying EJBs CSE 298 CSE 300 m m m EJBs Deployed As. SER Files: Serialized Instance Manifest File Used to List EJBs Must Also Provide a “Deployment Descriptor” Sample Entry q Name: paul. Restaurant. Deployment. ser q Enterprise-Bean: True “Name” Line q Describes a Serialized Deployment Descriptor “Enterprise-Bean” Line q 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? CSE 298 CSE 300 m m m m Web. Logic IBM Oracle Gem. Stone BEA Borland Netscape Lotus m m m m Forte Progress Novell Novera Borland Informix IONA More. . . ECIC-1. 102
Typical Development and Deployment Scenario CSE 298 CSE 300 m m EJB Server Provider q Creates and Sells an EJB Server q Provides EJB Containers That Will Run on These Servers EJB Providers q Individuals Responsible for Developing the EJBs q Provide “Tools” and “Components” for Down. Stream Usage Application Assemblers q Individuals that Utilize Pre-Built EJBs to Construct Their Domain-Specific Applications q Utilize “State-of-Art-Tools” for EJB and JB ECIC-1. 103
EJB Component-Based Architecture CSE 298 CSE 300 EJB Server EJB Client Invoke EJB Container Methods Enterprise Java Bean Invoke EJB Methods EJB Container ECIC-1. 104
Client-Server Component Model CSE 298 CSE 300 ECIC-1. 105
Two-Tier, Three-Tier, Four-Tier Example Architectures CSE 298 CSE 300 From: http: //java. sun. com/javaone 98/sessions/T 400/index. html ECIC-1. 106
Wombat Securities CSE 298 CSE 300 m m m m 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 CSE 298 CSE 300 ECIC-1. 108
Nocturnal Aviation, Inc. CSE 298 CSE 300 m m m m 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 CSE 298 CSE 300 ECIC-1. 110
Santa Cruz Widgets CSE 298 CSE 300 m m m 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) CSE 298 CSE 300 ECIC-1. 112
Architecture Comparisons CSE 298 CSE 300 m m m m Two-tier Through JDBC API: Simplest Multi-tier: Separate Business Logic, Protect Database Integrity, More Scaleable JMS Queues Vs Synchronous (RMI or IDL): q Availability, Response Time, Decoupling JMS Publish & Subscribe: Off-line Notification RMI IIOP Vs JRMP Vs Java IDL: q Standard Cross-language Calls or Full Java Functionality JTS: Distributed Integrity, Lockstep Actions ECIC-1. 113
Further API Comparisons CSE 298 CSE 300 m m m m Servlets: Simplifies HTML, Connections, Web Front-Ending Legacy Systems EJBs: Simplifies Components, Scalability, Transactions, Multi-threading, Security, State JDBC Vs ODMG Vs SQLJ API: q Programming Simplicity, Portability, SQL Knowledge JNDI: Standardized Name Service Access Enterprise Java APIs vs. Proprietary: q Multi-Platform, Multiple Providers ECIC-1. 114
Summary & Key Messages CSE 298 CSE 300 m m Enterprise Java APIs: EJB, JNDI, Java IDL, RMI, JDBC, ODMG, SQLJ, JMS, JTS, JMAPI, Servlets Wide Variety of Architectural Alternatives: q Synchronous/Asynchronous, Multi-Tier, Transactional, HTTP/JRMP/IIOP Benefits: q WORA Portability q Multiple Vendors q Legacy Connectivity q Java Programming Language Productivity ECIC-1. 115
EJB Roadmap CSE 298 CSE 300 ECIC-1. 116
What Is the Java Blend Product? CSE 298 CSE 300 m m Product That Integrates Java Programming Language Objects With Enterprise Data Provides a Single Object Model Based on Java Programming Language Classes q Automatic Persistent Storage for Java Application Objects q 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
Java. Blend Applications CSE 298 CSE 300 m m Java. Blend 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 CSE 298 CSE 300 m Flexible Development Tool for Automatic Bi-Directional Mapping q Objects to Relational q Relational to Objects Powerful Runtime Environment q Transaction Management System q Query Processor q Cache Management System ECIC-1. 119
Java Blend Runtime Architecture CSE 298 CSE 300 ECIC-1. 120
Java Blend Software and Enterprise Java. Beans Technology CSE 298 CSE 300 m EJB Technology Provides Scaleable Component Architecture for Business Applications Java Blend Product Provides Transparent Persistence for Enterprise Javabeans Technology q Beans Implementing Business Logic Use Java Blend for Database Access q Java Blend Product Works With the Enterprise Javabeans API Transaction Mechanisms ECIC-1. 121
Concluding Remarks Enterprise Computing/Interoperability CSE 298 CSE 300 m Technologies Continue to Emerge and Mature Complex Problem for Companies and Organizations q What are “Good” and “Stable” Technologies? q How can they be Leveraged for Gain? q Which Technologies Will Emerge in Short. Term and Long-Term? q How will Technologies Interact? Ø CORBA vs. DCOM vs. EJB Ø Java vs. Component Design/Programming Ø Heterogeneous Agent Platforms m Future Difficult to Predict! ECIC-1. 122
Скачать презентацию Enterprise Computing and Interoperability CSE 298 CSE 300
26807a4e7f0dd6091d901074d5f24978.ppt