Enterprise Computing and Interoperability - PowerPoint PPT Presentation

Loading...

PPT – Enterprise Computing and Interoperability PowerPoint presentation | free to download - id: 155eee-Yjk3Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Enterprise Computing and Interoperability

Description:

Discriminated Unions: Cross between the C union and switch statements. ... enum quality_t { Poor, Fair, Good, Excellent}; ECIC-1.24. CSE298. CSE300. CSE300 ... – PowerPoint PPT presentation

Number of Views:288
Avg rating:3.0/5.0
Slides: 123
Provided by: stevenad
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Enterprise Computing and Interoperability


1
Enterprise Computing and Interoperability
Prof. Steven A. Demurjian Computer Science
Engineering Department The University of
Connecticut 191 Auditorium Road, Box
U-155 Storrs, CT 06269-3155
steve_at_engr.uconn.edu http//www.engr.uconn.edu/st
eve (860) 486 - 4818
Special Thanks to Prof. Alex Shvartsman and
Scott Craig for providing portions of this
material.
2
Overview of Presentation
  • What is Enterprise Computing?
  • Interoperability and CORBA
  • Primer
  • Key Concepts and Ideas
  • System Design with CORBA/IDL
  • Interoperability Strategies
  • General Approaches
  • Java-Based Wrapper
  • Security Issues for Enterprise Computing
  • What are Key Issues re. Security for EC?
  • How are Legacy/COTS Handled?
  • Concluding Remarks

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

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

5
Interface Definition Language, IDL
  • Key Component of CORBA Is the Interface
    Definition Language, IDL
  • Mapping is Available in C, C, Java, Ada, Etc.
  • IDL Is Independent of Any Language/Compiler
  • Multiple Inheritance
  • Public Interface Oriented
  • Not for Implementation
  • Primary Support for Interoperability Between
    Static and Dynamic Request Mechanisms

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

7
CORBA Components and Interfaces
  • Client Stub Client Invokes a Particular Object
    Op.
  • Dynamic Invocation Run-Time-Construction of
    Operation Invocations
  • Implementation Skeleton Interface Through Which
    a Method Receives a Request
  • Object Adapter Provides (De)activation, Object
    Creation/Reference Mgmt. for Implementations
  • ORB Interface Common ORB Operations

8
Interfaces
  • Objects are Defined in IDL via Interfaces
  • Object Definitions (Interfaces) are Manifested as
    Objects in the Interface Repository, as Client
    Stubs, and as Implementation Skeletons
  • Descriptions of Object Implementations are
    Maintained as Objects in the Impl. Repository

9
Client Side
  • Clients Perform Requests Using Object References
  • Clients Issue Requests through Object Interface
    Stubs (Static) or DII (Dynamic Invocation Inter.)
  • Clients May Access General ORB Services
  • Interface Repository (IR)
  • Context Management
  • Request Management

10
Object Implementation Side
  • Implementations Receive Requests Thru Skeletons
  • Object Adapter Adapts to Specifics of Object
    Implementation Schemes
  • Basic Object Adapter (BOA) Provides
  • Management of References
  • Method Invocation
  • Authentication
  • Implementation Registration
  • Activation / Deactivation

11
Dynamic Invocation Interface (DII)
  • DII Allows Clients to Dynamically
  • Discover Objects
  • Discover Objects Interfaces
  • Create Requests
  • Invoke Requests (-gt Methods)
  • Receive Responses
  • Major DII Features
  • Requests Appear as Objects
  • Requests are Reusable
  • Invocation May be Synchronous or Asynchronous
  • Requests Can be Generated Dynamically, Statically
    or Using Both Approaches

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

13
Repositories Interface and Implementation
  • Interface Repository
  • Dynamic Client Access to Interface Definitions to
    Construct a Request
  • Dynamic Type Checking of Request Signatures
  • Traversal of Inheritance Graphs
  • Implementation Repository
  • Location of Implementations and Methods
  • Activation Information
  • Administration Control
  • Resource Allocation
  • Security

14
Three Types of ORBs
  • Single Process Library Resident
  • Client and Implementation Resident

ORB and implementations implemented as libraries
(routines) resident in the client.
ORB implemented as libraries (routines) resident
in the clients and in the implementations.
15
Three Types of ORBs
  • Server or Operating System Based

ORB is implemented as a server (separate
process) which brokers requests between client
and implementation processes. ORB is part of
the operating system.
16
Three Types of Implementations
  • Single Process one shot Object
  • Multi-Threaded resident Object

Implementation is a permanent or resident
multi-threaded process
17
Three Types of Implementations
  • Multi-Process Object

Implementation is a set of processes dedicated
to a particular (group of) method(s) Processes
can be distributed
18
System Design with CORBA
Scott A. Craig Computer Science Engineering
Department The University of Connecticut Storrs,
Connecticut 06269-3155
scraig_at_engr.uconn.edu
19
Overview of Presentation
  • Introduction to OMG IDL
  • Object Management Architecture
  • CORBAservices
  • Naming Service
  • Event Service
  • Typed Event Example
  • References
  • Concluding Remarks

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

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

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

24
IDL Complex Types (cont.)
  • Sequences One-dimensional array with maximum
    size (fixed at compile time) and length (set at
    run time).
  • Unbounded Sequencetypdef sequenceltlonggt
    longSeq
  • Bounded Sequencesequenceltlong,10gt fieldname
  • Strings Declared using keyword string. May be
    bounded or unbounded.
  • string namelt32gt //bounded
  • Arrays Multidimensional, fixed-size arrays of
    any IDL data type.

25
IDL Example GUI
/ File Name GUI.idl / ifndef
GUI_IDL define GUI_IDL module GUI struct
timespec_t long tv_sec long
tv_nsec struct Dialog1Data_t
timespec_t DataTime float val
struct Dialog2Data_t timespec_t DataTime
long val interface MainWindow
void logEvent(in timespec_t timestamp,
in string val)
interface Dialog1 void update(in
Dialog1Data_t val) interface Dialog2
void update(in Dialog2Data_t val)
endif // GUI_IDL
26
IDL Example Server
/ File Name Server.idl / ifndef
SERVER_IDL define SERVER_IDL include
"GUI.idl" interface Server enum reason_t
NotInitialized, ErrorDetected
exception NotAvailable reason_t reason
exception OperationTimeout void
registerMainWindow( in GUIMainWindow val,
in boolean flag) raises (OperationTimeout)
void setMainWindowEnabled( in boolean
flag) raises (OperationTimeout)
void registerDialog1( in GUIDialog1 val,
in boolean flag) raises (OperationTimeout)
void setDialog1Enabled( in boolean flag)
raises (OperationTimeout) GUIDialog1Data_t
getDialog1Data() raises (OperationTimeout,
NotAvailable) void registerDialog2( in
GUIDialog2 val, in boolean flag) raises
(OperationTimeout) void setDialog2Enabled(
in boolean flag) raises (OperationTimeout)
GUIDialog2Data_t getDialog2Data() raises
(OperationTimeout, NotAvailable) endif //
SERVER_IDL
27
Object Management Architecture
  • The Object Management Group, Inc (OMG) has
    established the Object Management Architecture
    (OMA), upon which OMG specifications are based
  • Components of the OMA Reference Model
  • Object Request Broker (CORBA)
  • Provides communications infrastructure.
  • Object Services (CORBAservices)
  • Collection of fundamental services (interfaces
    and objects) for using and implementing objects.
  • Common Facilities (CORBAfacilities)
  • Services such as system management.
  • Application Objects
  • Not standardized.

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

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

30
Naming Graph
Engineering
Pharmacy
Dean
Dean
EE
Practice
Science
CSE
ltEngineeringDeangt
ltPharmacyDeangt
Context
Application Object
31
CosNamingModule
  • NamingContext Interface Operations
  • Binding Names bind(...), rebind(...),
    bind_context(), rebind_context()
  • Resolving Names resolve()
  • Unbinding Names unbind()
  • Creating Naming Contexts new_context(),
    bind_new_context()
  • Deleting Contexts destroy()
  • Listing a Naming Context list()
  • BindingIterator Interface Allows a client to
    iterate through the bindings using next_one() or
    next_n() operations.

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

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

34
Push Model
  • Suppliers realize PushSupplier interface and
    consumers realize PushConsumer interface.
  • Suppliers invoke push operations on PushConsumer
    interface.
  • Supplier initiates transfer of event data.
  • Communication set up by exchanging object
    references.
  • Either can break communication by invoking the
    disconnect operation on the other.

35
Pull Model
  • Suppliers realize PullSupplier interface and
    consumers realize PullConsumer interface.
  • Consumers invoke pull operations on PushSupplier
    interface.
  • Consumer initiates transfer of event data.
  • Communication set up by exchanging object
    references.
  • Either can break communication by invoking the
    disconnect operation on the other.

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

37
Event Channels (cont.)
  • Multiple Consumers and Multiple Suppliers
  • Event Channel consumes events from one or more
    suppliers and supplies events to one or more
    consumers.

S2Supplier
S1Supplier
PushConsumer
PushSupplier
PushSupplier
EventChannel
PushConsumer
PushConsumer
PushSupplier
CNConsumer
C1Consumer
...
38
Typed Event Communication
  • In the preceding generic models, suppliers must
    insert data into an any parameter and consumers
    must then extract the data.
  • Alternative approach is the Typed Push Model
  • The interface that the consumer will realize is
    defined in IDL, subject to restrictions.
  • Only in parameters are allowed.
  • No return values are permitted.
  • Operations may be declared as oneway.
  • The user defined interface must inherit from
    CosTypedEventCommTypedPushConsumer.

39
TypedPushConsumer
40
Typed Event Example
  • Problem Statement Wish to design a distributed
    system consisting of two Suppliers, a Typed Event
    Channel, and multiple Consumers.
  • Supplier realizes a Client/Server interface
    (User_cs) that has two operations one that
    returns a variable-length structure and one that
    returns a fixed-length structure.
  • Consumer realizes an Event interface (User_ev)
    that inherits from TypedPushConsumer.
  • Fixed-length structure is pushed via the
    update operation.
  • Notification structure is pushed via the
    notification operation.
  • Structures contain field to identify Supplier.

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

42
Class Diagram
43
Component Diagram Source Files
44
Component Diagram Executables
Supplier
PushSupplier
User_cs
User_ev
EventChannel
User_ev
PushSupplier
Consumer
45
Collaboration Diagram
46
Deployment Diagram (degenerate)
S1Suppliersource1
S2Supplier source2
PushSupplier
PushSupplier
User_cs
User_cs
User_ev
EventChannel
User_ev
User_ev
PushSupplier
CNConsumer
C1Consumer
...
47
Design Considerations
  • Some form of event strategy should be employed to
    avoid having clients polling servers.
  • For performance reasons, only small, fixed-length
    structures should be pushed using Typed Events.
  • Because of middleware overhead, structure should
    be optimally packed.
  • Adding the oneway attribute to operations with
    no return type can improve performance, but
    reduces reliability (undetected comm. failures).
  • Consumers of aperiodic events may be unaware of
    Event Channel crashes. Event Channels should
    periodically generate keep alive events and
    Consumers should reconnect if not received.

48
References
  • Object Management Group, Inc. (OMG),
    http//www.omg.org
  • OMG, A Discussion of the Object Management
    Architecture, 01/97
  • OMG, The Common Object Request Broker
    Architecture and Specification, Rev. 2.2, 02/98
  • OMG, CORBAservices Common Object Services
    Specification, 12/98
  • T. J. Mowbray and R. Zahavi, The Essential CORBA
    Systems Integration Using Distributed Objects,
    John Wiley Sons, Inc., 1995
  • G. Booch, J. Rumbaugh, I. Jacobson, The Unified
    Modeling Language User Guide, AWL, Inc. 1999

49
Concluding Remarks
  • Introduced OMG IDL
  • Mappings to C, Java, etc.
  • Provided overview of OMG Object Management
    Architecture and the role of Object Services.
  • Provided overview of Naming Service and Event
    Service.
  • Presented a distributed system that makes use of
    Naming and Event Services.
  • Future Work
  • Investigation of Security Services

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

51
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

52
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
53
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
54
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
55
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
56
ADAM User Perspective
Code/Documentation Generation
ADAM Graphical User Interface
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
57
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

58
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

59
ADAM Current Software Architecture
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
60
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

61
Client Requirements and Functionalities
62
ADAM Target Software Architecture
63
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

64
ADAM Client/Wrapper Components
65
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
Legacy Application
Wrapper
66
Communication Requirements and Functionalities
  • Layers of Classes/Instances (Client vs. Server)
  • Interface (GUI) Classes and Instances (C)
  • Java Design Classes and Instances (CS)
  • Java Communication Classes and Instances (CS)
  • Translation Java to C Classes and Instances (S)
  • Communications
  • Sockets (Current)
  • Object Serialization (Current)
  • CORBA/ORBs vs. RMI (Future)

67
ADAM Socket Communications
Potential Performance Issue Multiple Layers of
Translation
68
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

69
ADAM TwinPeaks Architecture
70
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

71
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

72
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!

73
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

74
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!!

75
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

76
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

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

78
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

79
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

80
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?

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

82
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

83
Java Beans andEnterprise Java Beans
  • Paul C. Barr
  • The Mitre Corporation
  • Eatontown NJ
  • poobarr_at_mitre.org

Kimble Cheron, Prof. Steven A. Demurjian, and
Mitch Saba Computer Science Engr. Dept.
steve_at_engr.uconn.edu http//www.engr.uconn.edu/st
eve (860) 486 - 4818
84
Changing Perspectives
  • 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 Todays Environment
  • Designers 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?

85
Components
  • 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)

86
Overview
  • 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

87
Java Beans
  • 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

88
Java Beans
  • 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

89
What are Enterprise Java Beans ?
  • 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.

90
Designer and Developer Roles in Enterprise Java
Beans (EJB)
  • 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

91
EJB Roles Deployment
92
Utilizing EJB Technology
93
The EJB Architecture
  • 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 Beans Methods
  • EJB Clients
  • Locate EJB Containers Via JNDI
  • Make Use of EJB Beans
  • Enterprise Java Beans - Discussed Shortly

94
EJB Container
95
Enterprise Java APIs
96
Enterprise Java Beans Session Beans
  • 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

97
Enterprise Java Beans Entity Beans
  • 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

98
Model for PersistencePassivation/Activation
  • 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

99
Stateless vs. Stateful Session Beans
  • 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

100
Entity Bean Persistence
  • Container-Managed
  • Container is Responsible for Saving State
  • In Deployment Descriptor, Specify
    Container-Managed Fields
  • Persistence Independent of Data Source
  • Bean-Managed
  • Bean is Responsible for Saving its Own State
  • Container Doesnt Need to Generate DB Calls
  • Less Adaptable Persistence is Hard-Coded

101
Deploying EJBs
  • 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)

102
Whos Announced EJB Support?
  • WebLogic
  • IBM
  • Oracle
  • GemStone
  • BEA
  • Borland
  • Netscape
  • Lotus
  • Forte
  • Progress
  • Novell
  • Novera
  • Borland
  • Informix
  • IONA
  • More...

103
Typical Development and Deployment Scenario
  • 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 Down-Stream
    Usage
  • Application Assemblers
  • Individuals that Utilize Pre-Built EJBs to
    Construct Their Domain-Specific Applications
  • Utilize State-of-Art-Tools for EJB and JB

104
EJB Component-Based Architecture
EJB Server
Invoke EJB Methods
Invoke EJB Container Methods
Enterprise Java Bean
EJB Client
EJB Container
105
Client-Server Component Model
106
Two-Tier, Three-Tier, Four-Tier Example
Architectures
From http//java.sun.com/javaone/javaone98/sessio
ns/T400/index.html
107
Wombat Securities
  • 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

108
Four-Tier Architecture Example
109
Nocturnal Aviation, Inc.
  • 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

110
Three-Tier Example
111
Santa Cruz Widgets
  • 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

112
Santa Cruz Widgets (2-tier)
113
Architecture Comparisons
  • 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

114
Further API Comparisons
  • 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

115
Summary Key Messages
  • 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

116
EJB Roadmap
117
What Is the Java Blend Product?
  • 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_at_spree

118
JavaBlend Applications
  • 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

119
Java Blend Components
  • 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

120
Java Blend Runtime Architecture
121
Java Blend Software and Enterprise
JavaBeans Technology
  • 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

122
Concluding Remarks Enterprise Computing/Interoper
ability
  • 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 Short-Term and
    Long-Term?
  • How will Technologies Interact?
  • CORBA vs. DCOM vs. EJB
  • Java vs. Component Design/Programming
  • Heterogeneous Agent Platforms
  • Future Difficult to Predict!
About PowerShow.com