Title: Enterprise Computing and Interoperability
1Enterprise 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.
2Overview 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
3What 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
4Role 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
5Interface 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
6ORB and High Level View of Requests
- The Request Consists of
- Target Object
- Operation (Method)
- Parameters
- Request Context (Optional)
7CORBA 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
8Interfaces
- 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
9Client 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
10Object 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
11Dynamic 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
12Request 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
13Repositories 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
14Three 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.
15Three 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.
16Three Types of Implementations
- Single Process one shot Object
- Multi-Threaded resident Object
Implementation is a permanent or resident
multi-threaded process
17Three Types of Implementations
Implementation is a set of processes dedicated
to a particular (group of) method(s) Processes
can be distributed
18System Design with CORBA
Scott A. Craig Computer Science Engineering
Department The University of Connecticut Storrs,
Connecticut 06269-3155
scraig_at_engr.uconn.edu
19Overview of Presentation
- Introduction to OMG IDL
- Object Management Architecture
- CORBAservices
- Naming Service
- Event Service
- Typed Event Example
- References
- Concluding Remarks
20Interface 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
21IDL 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.
22IDL Basic Types
23IDL 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
24IDL 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.
25IDL 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
26IDL 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
27Object 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.
28CORBAservices
- 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)
29Naming 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.
30Naming Graph
Engineering
Pharmacy
Dean
Dean
EE
Practice
Science
CSE
ltEngineeringDeangt
ltPharmacyDeangt
Context
Application Object
31CosNamingModule
- 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.
32Event 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.
33Event 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.
34Push 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.
35Pull 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.
36Event 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
37Event 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
...
38Typed 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.
39TypedPushConsumer
40Typed 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.
41Typed 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.
42Class Diagram
43Component Diagram Source Files
44Component Diagram Executables
Supplier
PushSupplier
User_cs
User_ev
EventChannel
User_ev
PushSupplier
Consumer
45Collaboration Diagram
46Deployment Diagram (degenerate)
S1Suppliersource1
S2Supplier source2
PushSupplier
PushSupplier
User_cs
User_cs
User_ev
EventChannel
User_ev
User_ev
PushSupplier
CNConsumer
C1Consumer
...
47Design 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.
48References
- 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
49Concluding 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
50Interoperability 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
51Architectural 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
53ORB 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
54Java 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
55One 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
56ADAM 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
57Case 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
58Characterizing 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
59ADAM 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
60Client 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
61Client Requirements and Functionalities
62ADAM Target Software Architecture
63Wrapper 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
64ADAM Client/Wrapper Components
65ADAM 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
66Communication 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)
67ADAM Socket Communications
Potential Performance Issue Multiple Layers of
Translation
68TwinPeaks 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
69ADAM TwinPeaks Architecture
70Status 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
71Status 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
72Assessment 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!
73Assessment 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
74Assessment 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!!
75Architectural 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
76Architectural 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
77Architectural 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.
78Architectural 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
79Architectural 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
80Architectural 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?
81Concluding 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.
82Concluding 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
83Java 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
84Changing 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?
85Components
- 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)
86Overview
- 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
87Java 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
88Java 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
89What 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.
90Designer 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
91EJB Roles Deployment
92Utilizing EJB Technology
93The 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
94EJB Container
95Enterprise Java APIs
96Enterprise 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
97Enterprise 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
98Model 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
99Stateless 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
100Entity 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
101Deploying 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)
102Whos Announced EJB Support?
- WebLogic
- IBM
- Oracle
- GemStone
- BEA
- Borland
- Netscape
- Lotus
- Forte
- Progress
- Novell
- Novera
- Borland
- Informix
- IONA
- More...
103Typical 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
104EJB Component-Based Architecture
EJB Server
Invoke EJB Methods
Invoke EJB Container Methods
Enterprise Java Bean
EJB Client
EJB Container
105Client-Server Component Model
106Two-Tier, Three-Tier, Four-Tier Example
Architectures
From http//java.sun.com/javaone/javaone98/sessio
ns/T400/index.html
107Wombat 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
108Four-Tier Architecture Example
109Nocturnal 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
110Three-Tier Example
111Santa 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
112Santa Cruz Widgets (2-tier)
113Architecture 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
114Further 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
115Summary 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
116EJB Roadmap
117What 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
118JavaBlend 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
119Java 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
120Java Blend Runtime Architecture
121Java 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
122Concluding 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!