Interoperability Strategies for Enterprise Computing

1. Interoperability Strategies for Enterprise Computing Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818

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

3. Architectural Alternatives & Framework • 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

4. Java Client to Legacy App via RDBS Transformed Legacy Data Java Client Relational Database System(RDS) Updated Data Extract and Generate Data Transform and Store Data Legacy Application

5. ORB Integration of Java Clientand Legacy Application Java Client Legacy Application Java Wrapper Object Request Broker (ORB) CORBA is the Medium of Info. Exchange Requires Java/CORBA Capabilities

6. Java Client with Wrapper to Legacy Application Java Client Interactions Between Java Client and Legacy Appl. via C and RPC C is the Medium of Info. Exchange Java Client with C++/C Wrapper Java Application Code WRAPPER Mapping Classes JAVA LAYER NATIVE LAYER Native Functions (C++) RPC Client Stubs (C) Legacy Application Network

7. One COTS and One Legacy Application to Java Clients COTS Application Legacy Application Java Application Code Java Application Code Native Functions that Map to COTS Appl Native Functions that Map to Legacy Appl NATIVE LAYER NATIVE LAYER JAVA LAYER JAVA LAYER Mapping Classes Mapping Classes JAVA NETWORK WRAPPER JAVA NETWORK WRAPPER Network Java Client Java Client Java is Medium of Info. Exchange - C/C++ Appls with Java Wrappers

8. ADAM: User Perspective ADAM Graphical UserInterface Code/Documentation Generation C++ Ada83, Ada95 Eiffel Java (on PC/NT) Ascii/Latex Doc. OO Design Multiple Versions: ADAM/Unix: IV3.1, X, Sparcstation ADAM/PC: Win95, Borland C++ ADAM/NT: Under Development Server Abstraction for Design Persistence Ontos OODBS

9. Case Study: The ADAM Environment • 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

10. Characterizing ADAM Software Profile • 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

11. ADAM: Current Software Architecture ADAM Graphical UserInterface C++ Classes/Instances to Store Design andCode Generation Algorithms OO Design Ontos OODBS Design/Generation Compiler Independent Software 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

12. Client Requirements and Functionalities • 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

13. Client Requirements and Functionalities Designs at Client to Reduce Communication Overhead ADAM C++ Legacy Application (Server) Existing Designs Sent/Loaded for Local Manipulation OO Design Java/TwinPeaks Wrapper Completed New Designs or Revised Existing Designs Sent for Persistent Storage New ADAM Java User Interface (Client)

14. ADAM: Target Software Architecture New ADAM Java User Interface (Client) ADAM C++ Legacy Application (Server) OO Design C++: Common Interface to Access Server Classes Java Communications (Object Serialization/Sockets) Java: Communication and Interpretation Modified Design to Server Existing Design from Server Java/TwinPeaks Wrapper

15. Wrapper Requirements and Functionalities • 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

16. ADAM: Client/Wrapper Components Java Wrapper Java Client Legacy Code Adam C++ Server GUI Classes and Instances Translation Java to C++ Java Communication Classes/Instances COMMUNICATION Java Communication Classes/Instances Java Design Classes/Instances COMMUNICATION Java Design Classes/Instances May Not Be Needed Depends on Comm. Protocol

17. ADAM: Java to C++ Wrapper TwinPeaks Translation Java to C++ ADAM C++ Legacy Classes and Instances Communication Class Folder C++ Common Interface • Library Folder Java Design Classes and Instances Wrapper Legacy Application

18. Communication Requirements and Functionalities • 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)

19. ADAM: Socket Communications Java Wrapper Java Client Legacy Code Adam C++ Server GUI Classes and Instances Translation Java to C++ Java Communication Classes/Instances COMMUNICATION Java Communication Classes/Instances Java Design Classes/Instances COMMUNICATION Java Design Classes/Instances Potential Performance Issue: Multiple Layers of Translation

20. TwinPeaks Requirements and Functionalities • 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

21. ADAM: TwinPeaks Architecture Java Application C++ Application Java Interface Class Folder (.java/.class) INPUT C++ Header Files (.h) GENERATE TwinPeaks Java/C++ Bridge Lib. Folder C++ Implemen. Files (.c) C++ DLL

22. Status of TwinPeaks Effort • 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

23. Status of TwinPeaks Effort • 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

24. Assessment of TwinPeaks Product • 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!

25. Assessment of TwinPeaks Product • 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

26. Assessment of TwinPeaks Product • 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!!

27. Architectural Alternatives & Framework • 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

28. Architectural Alternatives & Framework • 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

29. Architectural Alternatives & Framework • 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.

30. Architectural Alternatives & Framework • 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

31. Architectural Alternatives & Framework • 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

32. Architectural Alternatives & Framework • 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?

33. Concluding Remarks and Discussion • 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 Up-to-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.

34. Concluding Remarks and Discussion • 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