Download Microsoft PPT 97 - University of Connecticut

Enterprise Computing and
Interoperability
CSE298
CSE300
Prof. Steven A. Demurjian
CSE300
Computer Science & Engineering Department
The University of Connecticut
191 Auditorium Road, Box U-155
Storrs, CT 06269-3155
[email protected]
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
† Special Thanks to Prof. Alex Shvartsman and Scott Craig for providing
portions of this material.
ECIC-1.1
Overview of Presentation
CSE298
CSE300 

CSE300



What is Enterprise Computing?
Interoperability and CORBA
 Primer
 Key Concepts and Ideas
 System Design with CORBA/IDL
Interoperability Strategies
 General Approaches
 Java-Based Wrapper
Security Issues for Enterprise Computing
 What are Key Issues re. Security for EC?
 How are Legacy/COTS Handled?
Concluding Remarks
ECIC-1.2
What is Enterprise Computing?
CSE298
CSE300 
CSE300

Today’s and Tomorrows Applications are System
of Systems
 Facilitate Interactions/Information Exchange
 Leverage Existing Information, Resources, and
Applications in New Environment
 Interoperability Key Issue
Strive for New/Innovative Application Usage in
Distributed Environment - For Example …
 Expand to Multi-User Capabilities
 Incorporate Modern GUI
 Introduce Useful Functionality
 Upgrade to Web-Based Access
ECIC-1.3
Role of an Object Request Broker (ORB)
CSE298

CSE300
CSE300



ORB Provides the Underlying Infrastructure for
Supporting Interoperating Software Systems
(Applications) Composed of Distributed Objects
 ORB Provides the Basic Request Delivery
 ORB Provides Interface Definitions
Location is Transparent to the Caller and Object
Implementation
Caller and the Object Implementation Can be in the
Same Process thru Opposite Sides of the World
ORB Manages Local Location and Optimization
ORB
Clie nt
Obje ct
Application
Imple me ntation
ECIC-1.4
Interface Definition Language, IDL
CSE298
CSE300 
CSE300

Key Component of CORBA Is the Interface
Definition Language, IDL
 Mapping is Available in C, C++, Java, Ada, Etc.
 IDL Is Independent of Any Language/Compiler
 Multiple Inheritance
 Public Interface Oriented
 Not for Implementation
Primary Support for Interoperability Between
Static and Dynamic Request Mechanisms
ECIC-1.5
ORB and High Level View of Requests
CSE298
CSE300 
CSE300
The Request Consists of
 Target Object
 Operation (Method)
 Parameters
 Request Context (Optional)
Clie nt
Application
Obje ct
Imple me ntation
Obje ct Ca ll
IDL Boundary
Obje ct re fe re nce
Me thods a nd D a ta
ORB
Request
IDL Boundary
Obje ct dispa tche r
ECIC-1.6
CORBA Components and Interfaces
CSE298

CSE300

CSE300



Client Stub: Client Invokes a Particular Object Op.
Dynamic Invocation: Run-Time-Construction of
Operation Invocations
Implementation Skeleton: Interface Through Which
a Method Receives a Request
Object Adapter: Provides (De)activation, Object
Creation/Reference Mgmt. for Implementations
ORB Interface: Common ORB Operations
Client
Dynamic
Invoke
Client
Stubs
Object Implementation
ORB
Interface
Implementation
Skeletons
Object
Adapter
ORB Core
One interface
One interface per object adaptor
One interface per object operation
ORB internal interface
ECIC-1.7
Interfaces
CSE298
CSE300 

CSE300

Objects are Defined in IDL via Interfaces
Object Definitions (Interfaces) are Manifested as
Objects in the Interface Repository, as Client Stubs,
and as Implementation Skeletons
Descriptions of Object Implementations are
Maintained as Objects in the Impl. Repository
IDL Interface
Definitions
Interface
Repository
Access
Client
Stubs
Includes
Client
Implementation
Installation
Implementation
Skeletons
Includes
Implementation
Repository
Describes
Object Implementation
ECIC-1.8
Client Side
CSE298
CSE300 

CSE300

Clients Perform Requests Using Object References
Clients Issue Requests through Object Interface
Stubs (Static) or DII (Dynamic Invocation Inter.)
Clients May Access General ORB Services:
 Interface Repository (IR)
 Context Management
 Request Management
Client
Object
Repository
Object Implementation
Dynamic
Invoke
Client
Stubs
ORB
Interface
Implementation
Skeletons
Object
Adapter
ORB Core
ECIC-1.9
Object Implementation Side
CSE298
CSE300


CSE300

Implementations Receive Requests Thru Skeletons
Object Adapter Adapts to Specifics of Object
Implementation Schemes
Basic Object Adapter (BOA) Provides:
 Management of References
 Method Invocation
 Authentication
 Implementation Registration
 Activation / Deactivation
Object Implementation
Client
Dynamic
Invoke
Client
Stubs
ORB
Interface
ORB Core
Implem.
Skeletons
Implementation
Repository
Object Adapter
ECIC-1.10
Dynamic Invocation Interface (DII)
CSE298
CSE300 
CSE300

DII Allows Clients to Dynamically:
 Discover Objects
 Discover Objects’ Interfaces
 Create Requests
 Invoke Requests (-> Methods)
 Receive Responses
Major DII Features:
 Requests Appear as Objects
 Requests are Reusable
 Invocation May be Synchronous or
Asynchronous
 Requests Can be Generated Dynamically,
Statically or Using Both Approaches
ECIC-1.11
Request Components
CSE298
CSE300 

CSE300





Object Reference -- Identifies the Target Object
Operation -- Identifies Which Operation to Invoke
(Which Method Will Be Executed)
Parameters -- Input, Output or Inout Method Arg-s
Context Object -- the Context Within Which the
Request Is to Be Performed
Results -- the Result Value(s) Returned
Environment -- the Exec-n Env-t and Exception
Info.
Request Handle -- the Id. For This Request
Instance
ECIC-1.12
Repositories:
Interface and Implementation
CSE298
CSE300 
CSE300

Interface Repository
 Dynamic Client Access to Interface Definitions
to Construct a Request
 Dynamic Type Checking of Request Signatures
 Traversal of Inheritance Graphs
Implementation Repository
 Location of Implementations and Methods
 Activation Information
 Administration Control
 Resource Allocation
 Security
ECIC-1.13
Three Types of ORBs
CSE298
CSE300 
CSE300
Single Process Library Resident
Client
ORB

Object
ORB and implementations
implemented as libraries
(routines) resident in
the client.
Request
Client and Implementation Resident
Client
ORB
Object
ORB implemented as
libraries (routines) resident
in the clients and in the
implementations.
Request
ECIC-1.14
Three Types of ORBs
CSE298
CSE300 
Server or Operating System Based
CSE300
Client
ORB
Object
Request
ORB is implemented as
a server (separate process)
which brokers requests
between client and
implementation processes.
ORB is part of the
operating system.
ECIC-1.15
Three Types of Implementations
CSE298
CSE300 
CSE300
Single Process “one shot” Object
Object Implementation
Single Process
Single
method
invocation

Implementation is a single
process that is activated
upon the request delivery
Multi-Threaded “resident” Object
Object Implementation
Single Process
Implementation is a permanent
or resident multi-threaded
process
Method C
Method B
Method A
ECIC-1.16
Three Types of Implementations
CSE298
CSE300

Multi-Process Object
CSE300
Object Implementation
Process 1
Method A
Process 2
Method B
Implementation is a set
of processes dedicated to
a particular (group of)
method(s)
Process 3
Method C
Processes can be distributed
ECIC-1.17
System Design with CORBA
CSE298
CSE300
CSE300
Scott A. Craig
Computer Science & Engineering Department
The University of Connecticut
Storrs, Connecticut 06269-3155
[email protected]
ECIC-1.18
Overview of Presentation
CSE298
CSE300 
CSE300

Introduction to OMG IDL
Object Management Architecture

CORBAservices
 Naming Service
 Event Service



Typed Event Example
References
Concluding Remarks
ECIC-1.19
Interface Definition Language, IDL
CSE298
CSE300 
CSE300 



Language used to describe the interfaces that client
objects call and object implementations provide.
Obeys the same lexical rules as C++, but
introduces some new keywords.
Supports standard C++ preprocessing features.
Interfaces can have operations and attributes.
 Operation declaration consists of a return type,
an identifier, a parameter list, and an optional
raises expression (exceptions).
 Attribute declaration is logically equivalent to
declaring a pair of accessor operations. May be
declared as readonly.
Interface specifications are placed in a source file
having the extension “.idl”
ECIC-1.20
IDL: Modules and Interfaces
CSE298
CSE300 
CSE300

Module: Used to scope IDL identifiers.
 Mapped to C++ namespace with the same
name. Mapped to a C++ class if the
namespace construct is not supported.
 Mapped to Java package with the same name.
 IDL declarations not enclosed in any module
have global scope when mapped.
Interface: Description of set of operations that a
client may request of an object.
 Multiple inheritance supported
 Interface body may contain the following kinds
of declarations: constant, type, attribute, and
operation.
ECIC-1.21
IDL: Basic Types
CSE298
CSE300
Type
Range
CSE300
short
-215 .. 215-1 (16-bit)
unsigned short
0 .. 216-1 (16-bit)
long
-231 .. 231-1 (32-bit)
unsigned long
0 .. 216-1 (32-bit)
float
IEEE single-precision floating point
double
IEEE double-precision floating point
char
8-bit quantity
boolean
TRUE or FALSE
octet
8-bit (guaranteed during transmission)
any
values that can express any IDL type
ECIC-1.22
IDL: Complex Types
CSE298
CSE300 
CSE300


Structures:
 struct FixedLengthStruct {
long
field1; // 32-bit
short
field2; // 16-bit
};
 struct VariableLengthStruct {
long
field1; // 32-bit
string
field2;
};
Discriminated Unions: Cross between the C
union and switch statements.
Enumerations: Ordered list of identifiers.
 enum quality_t {
Poor, Fair, Good, Excellent};
ECIC-1.23
IDL: Complex Types (cont.)
CSE298
CSE300 
CSE300


Sequences: One-dimensional array with maximum
size (fixed at compile time) and length (set at run
time).
 Unbounded Sequence:
typdef sequence<long> longSeq;
 Bounded Sequence:
sequence<long,10> fieldname;
Strings: Declared using keyword string. May
be bounded or unbounded.
 string name<32>; //bounded
Arrays: Multidimensional, fixed-size arrays of any
IDL data type.
ECIC-1.24
IDL Example: GUI
CSE298
CSE300
/*
* File Name:
*/
CSE300
#ifndef GUI_IDL
#define GUI_IDL
GUI.idl
module GUI {
struct timespec_t {
long tv_sec;
long tv_nsec;
};
interface Dialog1 {
void update(in Dialog1Data_t val);
};
interface Dialog2 {
void update(in Dialog2Data_t val);
};
};
#endif
// GUI_IDL
struct Dialog1Data_t {
timespec_t
DataTime;
float
val;
};
struct Dialog2Data_t {
timespec_t
DataTime;
long
val;
};
interface MainWindow {
void logEvent(in timespec_t timestamp,
in string val);
};
ECIC-1.25
IDL Example: Server
CSE298
CSE300
/*
* File Name:
*/
CSE300
#ifndef SERVER_IDL
#define SERVER_IDL
Server.idl
#include "GUI.idl"
interface Server {
enum reason_t {
NotInitialized,
ErrorDetected
};
exception NotAvailable {
reason_t reason;
};
exception OperationTimeout {};
void registerMainWindow(
in GUI::MainWindow val,
in boolean flag)
raises (OperationTimeout);
void setMainWindowEnabled(
in boolean flag)
raises (OperationTimeout);
void registerDialog1(
in GUI::Dialog1 val,
in boolean flag)
raises (OperationTimeout);
void setDialog1Enabled(
in boolean flag)
raises (OperationTimeout);
GUI::Dialog1Data_t getDialog1Data()
raises (OperationTimeout,
NotAvailable);
void registerDialog2(
in GUI::Dialog2 val,
in boolean flag)
raises (OperationTimeout);
void setDialog2Enabled(
in boolean flag)
raises (OperationTimeout);
GUI::Dialog2Data_t getDialog2Data()
raises (OperationTimeout,
NotAvailable);
};
#endif
// SERVER_IDL
ECIC-1.26
Object Management Architecture
CSE298
CSE300 
CSE300

The Object Management Group, Inc (OMG) has
established the Object Management Architecture
(OMA), upon which OMG specifications are based
Components of the OMA Reference Model:
 Object Request Broker (CORBA):
 Provides communications infrastructure.

Object Services (CORBAservices):
 Collection of fundamental services (interfaces and
objects) for using and implementing objects.

Common Facilities (CORBAfacilities):
 Services such as system management.

Application Objects
 Not standardized.
ECIC-1.27
CORBAservices
CSE298
CSE300 

CSE300


OMG specification for Object Services
Collection of 15 services (interfaces and objects)
that support basic functions for using and
implementing objects.
 Interfaces specified using IDL
Will focus on two services:
 Naming Service
 Event Service
Security Service: Addresses identification and
authentication, authorization and access control,
security of communication between objects, etc.
 Beyond scope of this presentation (specification
is 386 pages in length)
ECIC-1.28
Naming Service
CSE298

CSE300

CSE300




Facilitates locating objects in a distributed system.
A name binding is a name-to-object association
and is always defined relative to a naming context.
A naming context is an object that contains a set of
name bindings in which each name is unique.
Multiple names may be bound to an object.
Servers bind names to objects and clients resolve
names to objects.
A naming context may be bound to a name in
another naming context creating a naming graph.
 Directed graph with labeled edges in which
nodes are objects.
 Compound names are formed by the sequence
of names along a path from the root to the leaf.
ECIC-1.29
Naming Graph
CSE298
CSE300
Engineering
CSE300
Dean
EE
CSE
<Engineering;Dean>
Pharmacy
Practice
Dean
Science
<Pharmacy;Dean>
Context
Application Object
ECIC-1.30
CosNamingModule
CSE298
CSE300 
CSE300

NamingContext Interface Operations:
 Binding Names: bind(...), rebind(...),
bind_context(…), rebind_context(…)
 Resolving Names: resolve(…)
 Unbinding Names: unbind(…)
 Creating Naming Contexts: new_context(),
bind_new_context(…)
 Deleting Contexts: destroy()
 Listing a Naming Context: list(…)
BindingIterator Interface: Allows a client to
iterate through the bindings using next_one(…) or
next_n(…) operations.
ECIC-1.31
Event Service
CSE298
CSE300 
CSE300



A standard CORBA request issued by a client
results in the synchronous execution of an
operation by an object (server).
 Request directed to a particular object.
 Client must handle exceptions if request fails.
Event Service decouples communication between
objects, defining two roles for objects:
 Supplier Role: Produce event data
 Consumer Role: Process event data
Event data are communicated by issuing standard
CORBA requests. No extensions to CORBA are
necessary to define event interfaces.
Communication may be generic or typed.
ECIC-1.32
Event Service Design Principles
CSE298
CSE300 

CSE300



Allow multiple consumers and multiple suppliers.
Consumers can either request events (pull model)
or be notified of events (push model).
 Software architectural decision.
Supplier can issue a single standard CORBA
request to communicate event data to all
consumers.
Suppliers can generate events without knowing the
identities of consumers and consumers can receive
events without knowing the identities of suppliers.
Event Service specification allows multiple
qualities of service (reliability).
 Implementation dependent.
ECIC-1.33
Push Model
CSE298
CSE300 
CSE300 


Suppliers realize PushSupplier interface and
consumers realize PushConsumer interface.
Suppliers invoke push operations on
PushConsumer interface.
 Supplier initiates transfer of event data.
Communication set up by exchanging object
references.
Either can break communication by invoking the
disconnect operation on the other.
ECIC-1.34
Pull Model
CSE298
CSE300 
CSE300 


Suppliers realize PullSupplier interface and
consumers realize PullConsumer interface.
Consumers invoke pull operations on PushSupplier
interface.
 Consumer initiates transfer of event data.
Communication set up by exchanging object
references.
Either can break communication by invoking the
disconnect operation on the other.
ECIC-1.35
Event Channels
CSE298
CSE300 
CSE300



Event Channel is a service that decouples
communication between suppliers and consumers.
 Allows multiple suppliers to communicate with
multiple consumers asynchronously.
 Is both a consumer and a supplier of events.
Push-Style Communication with an Event Channel
 Supplier pushes event data to Event Channel,
which then pushes event data to consumer.
Pull-Style Communication with an Event Channel
 Consumer pulls event data from Event Channel
which then pulls event data from the supplier.
Mixed-Style Communication with an Event
Channel
ECIC-1.36
Event Channels (cont.)
CSE298
CSE300 
CSE300
Multiple Consumers and Multiple Suppliers
 Event Channel consumes events from one or
more suppliers and supplies events to one or
more consumers.
S1:Supplier
S2:Supplier
PushConsumer
PushSupplier
PushSupplier
:EventChannel
PushConsumer
PushConsumer
PushSupplier
C1:Consumer
...
CN:Consumer
ECIC-1.37
Typed Event Communication
CSE298
CSE300 
CSE300

In the preceding generic models, suppliers must
insert data into an “any” parameter and consumers
must then extract the data.
Alternative approach is the Typed Push Model
 The interface that the consumer will realize is
defined in IDL, subject to restrictions.
 Only “in” parameters are allowed.
 No return values are permitted.


Operations may be declared as “oneway.”
The user defined interface must inherit from
CosTypedEventComm::TypedPushConsumer.
ECIC-1.38
TypedPushConsumer
CSE298
CSE300
CSE300
<<Interface>>
PushConsumer
(from Common_Interface)
+ push(data : in any) : void
+ disconnect_push_consumer() : void
<<Interface>>
TypedPushConsumer
(from Common_Interface)
+ get_typed_consumer() : Object
<<Interface>>
User_ev
+ notification(val : in User_cs::Notification_t) : void
+ update(val : in User_cs::Update_t) : void
ECIC-1.39
Typed Event Example
CSE298
CSE300 
CSE300


Problem Statement: Wish to design a distributed
system consisting of two Suppliers, a Typed Event
Channel, and multiple Consumers.
Supplier realizes a Client/Server interface
(User_cs) that has two operations; one that
returns a variable-length structure and one that
returns a fixed-length structure.
Consumer realizes an Event interface (User_ev)
that inherits from TypedPushConsumer.
 Fixed-length structure is pushed via the
“update” operation.
 Notification structure is pushed via the
“notification” operation.
 Structures contain field to identify Supplier.
ECIC-1.40
Typed Event Example (cont.)
CSE298
CSE300 
CSE300 


Event Channel must be running before any
Suppliers or Consumers are started.
When a Supplier is started, it binds a name to the
object that realizes the User_cs interface. Each
Supplier must supply a unique name. It then
connects to the Event Channel as a push supplier.
When a Consumer is started, it obtains an object
reference to each User_cs interface via the
Naming Service. It then connects to the Event
Channel as a push consumer.
When a Consumer receives a notification event, it
retrieves the variable-length struct from the
appropriate Supplier via the C/S interface.
ECIC-1.41
Class Diagram
CSE298
CSE300
source_t
(from User_cs)
CSE300
- source1
- source2
<<Interface>>
TypedPushConsumer
(from Common_Interface)
+ get_typed_consumer() : Object
Update_t
(from User_cs)
- timestamp : long
- data : float
- source : source_t
<<Interface>>
User_ev
Notification_t
+ notification(val : in User_cs::Notification_t) : void
+ update(val : in User_cs::Update_t) : void
(from User_cs)
- timestamp : long
- source : source_t
VarLengthStruct_t
(from User_cs)
- timestamp : long
- source : source_t
- data : string
<<Interface>>
User_cs
+ getVarLengthStruct() : VarLengthStruct_t
+ getUpdate() : Update_t
ECIC-1.42
Component Diagram: Source Files
CSE298
CSE300
CSE300
User_cs
User_cs
User_ev
User_ev
ECIC-1.43
Component Diagram: Executables
CSE298
CSE300
CSE300
Supplier
User_cs
PushSupplier
User_ev
EventChannel
User_ev
PushSupplier
Consumer
ECIC-1.44
Collaboration Diagram
CSE298
CSE300
source1 :
User_cs
1: notification(...)
CSE300
4: getVarLengthStruct( )
C1 :
User_ev
5: getVarLengthStruct( )
EC :
User_ev
2: notification(...)
C2 :
User_ev
3: notification(...)
ECIC-1.45
Deployment Diagram (degenerate)
CSE298
CSE300
CSE300
S1:Supplier
{source1}
User_cs
S2:Supplier
{source2}
PushSupplier
PushSupplier User_cs
User_ev
:EventChannel
User_ev
User_ev
PushSupplier
C1:Consumer
...
CN:Consumer
ECIC-1.46
Design Considerations
CSE298
CSE300 
CSE300 



Some form of event strategy should be employed to
avoid having clients polling servers.
For performance reasons, only small, fixed-length
structures should be pushed using Typed Events.
Because of middleware overhead, structure should
be optimally packed.
Adding the “oneway” attribute to operations with
no return type can improve performance, but
reduces reliability (undetected comm. failures).
Consumers of aperiodic events may be unaware of
Event Channel crashes. Event Channels should
periodically generate “keep alive” events and
Consumers should reconnect if not received.
ECIC-1.47
References
CSE298
CSE300 
CSE300 




Object Management Group, Inc. (OMG),
http://www.omg.org
OMG, A Discussion of the Object Management
Architecture, 01/97
OMG, The Common Object Request Broker:
Architecture and Specification, Rev. 2.2, 02/98
OMG, CORBAservices: Common Object Services
Specification, 12/98
T. J. Mowbray and R. Zahavi, The Essential
CORBA: Systems Integration Using Distributed
Objects, John Wiley & Sons, Inc., 1995
G. Booch, J. Rumbaugh, I. Jacobson, The Unified
Modeling Language User Guide, AWL, Inc. 1999
ECIC-1.48
Concluding Remarks
CSE298
CSE300 
CSE300



Introduced OMG IDL
 Mappings to C++, Java, etc.
Provided overview of OMG Object Management
Architecture and the role of Object Services.
 Provided overview of Naming Service and
Event Service.
Presented a distributed system that makes use of
Naming and Event Services.
Future Work:
 Investigation of Security Services
ECIC-1.49
Interoperability Strategies
CSE298
CSE300 
CSE300




Architectural Alternatives and Frameworks
 Taxonomy of Architectural Variants
 Integration via Java, CORBA, etc.
Case Study: The ADAM Environment
 Upgrading a C++ Legacy Application to be
Java-Compatible
 Pros and Cons of Effort
Issues for Interoperability
Outlining Future Efforts and Emphases
Concluding Remarks and Discussion
ECIC-1.50
Architectural Alternatives & Framework
CSE298
CSE300 
CSE300

Reviewing Architectural Variants
 Java Client to Legacy Appl. via RDBS
 ORB Integration of Java Client and Legacy
Application
 Java Client with Wrapper to Legacy Appl.
 One COTS and One Legacy Appl. to Java
Clients
Quick Review of Select Material from Summer
1997 White Paper:
 “The Java Programming Language: Impact upon
the Army Technical Architecture (ATA) and Joint
Technical Architecture (JTC)” Demurjian/Shin
ECIC-1.51
Java Client to Legacy App via RDBS
CSE298
CSE300
CSE300
Transformed
Legacy Data
Java Client
Updated Data
Relational
Database
System(RDS)
Extract and
Generate Data
Transform and
Store Data
Legacy
Application
ECIC-1.52
ORB Integration of Java Client
and Legacy Application
CSE298
CSE300
CSE300
Java Client
Legacy
Application
Java
Wrapper
Object Request Broker (ORB)
CORBA is the Medium of Info. Exchange
Requires Java/CORBA Capabilities
ECIC-1.53
Java Client with Wrapper
to Legacy Application
CSE298
CSE300
CSE300
Java Client
Java Application Code
WRAPPER
Mapping Classes
JAVA LAYER
Interactions Between Java Client
and Legacy Appl. via C and RPC
C is the Medium of Info. Exchange
Java Client with C++/C Wrapper
NATIVE LAYER
Native Functions (C++)
RPC Client Stubs (C)
Legacy
Application
Network
ECIC-1.54
One COTS and One Legacy
Application to Java Clients
CSE298
CSE300
COTS Application
Legacy Application
CSE300
Java Application Code
Java Application Code
Native Functions that
Map to COTS Appl
NATIVE LAYER
Native Functions that
Map to Legacy Appl
NATIVE LAYER
JAVA LAYER
JAVA LAYER
Mapping Classes
JAVA NETWORK WRAPPER
Mapping Classes
JAVA NETWORK WRAPPER
Network
Java Client
Java Client
Java is Medium of Info. Exchange - C/C++ Appls with Java Wrapper
ECIC-1.55
ADAM: User Perspective
CSE298
CSE300
CSE300
Code/Documentation
Generation
ADAM Graphical
User Interface
C++
Ada83, Ada95
Eiffel
Java (on PC/NT)
Ascii/Latex Doc.
OO
Design
Server
Abstraction
for Design
Persistence
Multiple Versions:
ADAM/Unix: IV3.1, X, Sparcstation
ADAM/PC: Win95, Borland C++
ADAM/NT: Under Development
Ontos
OODBS
ECIC-1.56
Case Study: The ADAM Environment
CSE298
CSE300 
CSE300


ADAM is a C++ Legacy Application with:
 GUI Interviews/Unidraw
 Core C++ Internal Classes which are Compiler
Independent
 Designs Stored in Ontos OODBS
Redesign/Reformulate ADAM as:
 Java Client that Replaces C++ GUI
 Java Server Wraps Core C++ Internal Classes
 C/S Communications via Java
 Designs Stored in Jasmine (1998 Task)
Similar to Providing C/S Interactions for an C++
Legacy/COTS Application
ECIC-1.57
Characterizing ADAM Software Profile
CSE298
CSE300 
CSE300



C++ Class Library - Intended as a Single-CPU,
Single-User, Interactive Design Environment
C++ Classes Structured as Multiple Interacting
Hierarchies for Different Components:
 C++ Classes for GUI
 C++ Classes to Store Design as it is Created
 C++ Classes for Code Generation Capabilities
 C++/Ontos Classes for Persistence
Source Code Level Access to ADAM Software
Goal: Minimize Code-Level Modifications as
ADAM Moves to Java Client/Server Paradigm
ECIC-1.58
ADAM: Current Software Architecture
CSE298
CSE300
CSE300
Design/Generation
Compiler Independent Software
ADAM Graphical
User Interface
C++ Classes/Instances
to Store Design and
Code Generation
Algorithms
OO
Design
C++
Ontos C++
Ada83, Ada95
Eiffel
Java (on PC)
ADAM/Unix: IV3.1, X, Sparcstation
ADAM/PC: Win95, Borland C++
DB Server
Abstraction
for Design
Persistence
Ontos
OODBS
ECIC-1.59
Client Requirements and Functionalities
CSE298
CSE300 
CSE300

New ADAM Java Client Replicates Core C++
Classes to Allow Transitory Storage of Designs:
 Existing Designs from Legacy Server Storable
at ADAM Java Client
 New/Existing Designs at Java Client Locally
Manipulated to Reduce Communication Traffic
 New/Existing Designs Sent to Legacy Server
for Persistent Storage
Java Communications from Client to Server
 Transmission of Modified Design to Server
 Receipt of Existing Design from Server
 Both Accomplished via Object Serialization
ECIC-1.60
Client Requirements and Functionalities
CSE298
CSE300
CSE300
Designs at
Client to
Reduce
Communication
Overhead
Existing Designs Sent/Loaded
for Local Manipulation
OO
Design
ADAM C++
Legacy Application
(Server)
Java/TwinPeaks
Wrapper
New ADAM Java
User Interface
(Client)
Completed New Designs or
Revised Existing Designs
Sent for Persistent Storage
ECIC-1.61
ADAM: Target Software Architecture
CSE298
CSE300
CSE300
New ADAM Java
User Interface
(Client)
ADAM C++
Legacy Application
(Server)
OO
Design
Java Communications
(Object Serialization/Sockets)
Modified Design to Server
Existing Design from
Server
C++: Common Interface
to Access Server Classes
Java: Communication
and Interpretation
Java/TwinPeaks
Wrapper
ECIC-1.62
Wrapper Requirements and Functionalities
CSE298
CSE300 
CSE300



Transmission/Receipt of Messages from Clients
Existing Design from Server to Client
 Locating C++ Instances in Legacy Server
 Creation of Java Instances from C++ Instances
 Object Serialization of Java Instances to Client
Store New/Existing Design from Client to Server
 Receipt of Java Instances via O-Serialization
 Creation of C++ Instances from Java Instances
 Storage of C++ Instances into Legacy Server
Interactions between Java and C++ via Java Native
Interface (JNI) or TwinPeaks
ECIC-1.63
ADAM: Client/Wrapper Components
CSE298
CSE300
Java Wrapper
Java Client
COMMUNICATION
Java Communication
Classes/Instances
Java Design Classes/Instances
Java Communication
Classes/Instances
COMMUNICATION
GUI
Classes
and
Instances
Java Design Classes/Instances
CSE300
Translation
Java to C++
Legacy
Code
Adam
C++
Server
May Not Be
Needed
Depends on Comm. Protocol
ECIC-1.64
ADAM: Java to C++ Wrapper
CSE298
CSE300
TwinPeaks
Library Folder
Translation
Java to C++
Wrapper
C++ Common Interface
Java Design
Classes
and Instances
Class Folder
Communication
CSE300
ADAM
C++ Legacy
Classes
and Instances
Legacy Application
ECIC-1.65
Communication Requirements and
Functionalities
CSE298
CSE300 
CSE300

Layers of Classes/Instances (Client vs. Server)
 Interface (GUI) Classes and Instances (C)
 Java Design Classes and Instances (C&S)
 Java Communication Classes and Instances
(C&S)
 Translation Java to C++ Classes and Instances
(S)
Communications
 Sockets (Current)
 Object Serialization (Current)
 CORBA/ORBs vs. RMI (Future)
ECIC-1.66
ADAM: Socket Communications
CSE298
CSE300
Java Client
Java Wrapper
COMMUNICATION
Java Communication
Classes/Instances
Java Design Classes/Instances
Java Communication
Classes/Instances
COMMUNICATION
GUI
Classes
and
Instances
Java Design Classes/Instances
CSE300
Translation
Java to C++
Legacy
Code
Adam
C++
Server
Potential Performance Issue: Multiple
Layers of Translation
ECIC-1.67
TwinPeaks Requirements and
Functionalities
CSE298
CSE300 
CSE300

Evaluated Feasibility of JNI
 Directly Access Native Layer
 Eliminates Platform Independence
 Difficult to Understand and Use
Exploring TwinPeaks Product
 Beta Product from Sun
 Automatically Generates Java Interface to C or
C++ Native Library
 Analyzes Native Library Header Files to
Produce a Java API that Closely Mirrors
Original C/C++ API
 Generates Platform Specific Native Code
ECIC-1.68
ADAM: TwinPeaks Architecture
CSE298
CSE300
CSE300
Java Application
C++ Header
Files (.h)
C++
Implemen.
Files (.c)
INPUT
TwinPeaks
C++
Application
Java Interface
Class Folder
(.java/.class)
Java/C++
Bridge
Lib. Folder
C++ DLL
ECIC-1.69
Status of TwinPeaks Effort
CSE298
CSE300 
CSE300

Established TwinPeaks Environment
 Downloaded Multiple Times due to Difficulty
in Setting up Software and Multiple Releases
by SunSoft
 Worked to Understand the Mechanism and
Proper steps Needed to work with TwinPeaks
UConn Beta Testing Site of Product:
 Initial Efforts in Sept and Oct 97 Provided
Feedback and Suggestions to SunSoft
 Many of Suggestions for Improvement
Reflected in the Second Release
ECIC-1.70
Status of TwinPeaks Effort
CSE298
CSE300 
CSE300


As of January 15, 1998
 Installed Newest TwinPeaks Release
 Developed Two Test Prototypes that Generates
the Java to C++ Mapping for Subset of the
ADAM C++ Server Legacy Code
Written a Detailed Report Describing this Effort
that will be Critical in Continuing this Work
The Java/C++ Interface is Pivotal for Integrating
and Upgrading Legacy Software to Java
ECIC-1.71
Assessment of TwinPeaks Product
CSE298
CSE300 
CSE300
PROs
 To Our Knowledge, the Only Available Tool
that Supports Java to C/C++ at High Abstract.
 Automates Tedious/Error Prone Process an of
Generating Peer Java classes for C++ Code
 Offers Clever Techniques to Solve Mismatch
Between Java and C/C++
 Pointers
 Multiple Inheritance
 Operator Overloading

Cost - Currently TwinPeaks is Free!
ECIC-1.72
Assessment of TwinPeaks Product
CSE298
CSE300
CSE300

CONS
 Supports Very Limited Platform
 Solais and SunSoft C++
 What about Windows 95, NT, and Linux Apps?





Based on Native Method Specification and
not Up-to-Date JNI
Potential for Incompatibility and/or
Abandonment in Future
Automatic, but Difficult to Use
Very Limited Support/Documentation
Minimal
Small User Community
ECIC-1.73
Assessment of TwinPeaks Product
CSE298
CSE300 
CSE300

CONs
 Requires Familiarity with SunSoft C++ and
Java Native Method
 No Debugging Facilities Makes Understanding
and Correcting Errors Difficult
 Generics, Unions, and other C/C++ Features
not Supported
 No support for calling Java from C++
Conclusion:
 TwinPeaks is not a Stable Tool
 Falls Short of our Expectations
 Acceptance/Adoption for EC Applications is
Premature!!
ECIC-1.74
Architectural Alternatives & Framework
CSE298
CSE300 
CSE300
C++ Legacy Applications Upgrade to C/S
Architectural Solution with Java Requires:
 Ability to Pull-Off or Disable Legacy GUI
 Needed to Support Wrapping Process
 May Not be Possible for Every Legacy/COTS
application

Source-Code Availability or Robust
Programming Interface
 Alternative to Disable
 A Robust OO API Assist Wrapper Creation and
Java to C++ Interactions
ECIC-1.75
Architectural Alternatives & Framework
CSE298
CSE300 
CSE300
C++ Legacy Applications Upgrade to C/S
Architectural Solution with Java Requires:
 Development of a New Java GUI/Client
 New GUI to Collect, Synthesize, Interpret
Information from Multiple Legacy/COTS
 New/Innovative Uses for Legacy/COTS
Applications

Short-Term Persistence of Client Data
 Thin vs. Medium vs. Thick Clients
 For EC Applications, if Clients Leave Network,
Local Storage is Needed
 Must Also Consider Limited Bandwidth
ECIC-1.76
Architectural Alternatives & Framework
CSE298
CSE300 
CSE300
C++ Legacy Applications Upgrade to C/S
Architectural Solution with Java Requires:
 Message Passing Interface to Legacy Appl.
 If Not Present, Embed in Communications Layer of
both Client and Wrapper
 For EC Applications, Extra Layers May be
Required to Transform Legacy Data to OO/Java

Integration of Java and C++
 Java Wrapper Requires Bi-Directional Exchange
of Information to/from C++
 Automated Tools (TwinPeaks) vs. JNI
 For EC Applications - C, C++, Ada, Fortran, etc.
ECIC-1.77
Architectural Alternatives & Framework
CSE298
CSE300 
CSE300

Integration of Java and C++
 Occurs within the Java Wrapper to C++ Server
 Requires Ability to Encompass and Build C++
Server as Shared Library
 Shared Library Interacts with TwinPeaks
 Bi-Directional Translation (Java to/from C++)
 May Require a New C++ Library for a
Uniform Interface to Server C++ Classes
 Maintains Multiple Layers of Same
Information in Different Formats
Applicability to C Legacy Applications
 Techniques Extensible to C Providing that
Workable Native C++ Library Available
ECIC-1.78
Architectural Alternatives & Framework
CSE298
CSE300 
CSE300

Utilization of our Efforts on ADAM as Blueprint
 C++ Legacy Application (with/out GUI)
 Source Code Availability/Programming Interf.
 New Java Client Appls/Java Server Wrapper
 Message Passing Interface
 Redesign/Development of Java Client Classes
that Mirror/Imitate Legacy Server Classes
 Introduction of Multiple Layers of Translation
 Increased Overhead with Java or CORBA
 Applicability to Well-Designed C Appls
Conclusion: Significant Effort with Potential
Long-Range Benefit of Common Java Medium
ECIC-1.79
Architectural Alternatives & Framework
CSE298
CSE300 
CSE300


PROs
 Likely Applicable to C and C++
 Component-Based, Organized Approach
 Greatly Facilitates Exchange of Information
 Solves the N x M Translation Problem
CONs
 Additional Overhead Due to Translations
 Instability/Immaturity of TwinPeaks
 Complexity and Effort of Task
 Performance Degradation Unacceptable
Conclusion: Do Java, CORBA, etc., Benefits
Outweigh the Risks and Shortfalls?
ECIC-1.80
Concluding Remarks and Discussion
CSE298
CSE300 
CSE300
What are Keys Issues that Influence and Guide the
Integration Process for EC?
 Software Reuse in a Distributed Computing
Environment
 Reuse Existing Legacy/COTS in Innovative Ways
 Not Cost Effective to Redesign/Reimplement
 EC Users will Demand Modern Interfaces on Upto-Date Platforms

Wrappers for Cohesive/Seamless Interactions
 Apply to Languages (C, C++, Ada, etc.) and
Paradigms (OODBS, CORBA, RPC)
 Address Communication, Translation, Security,
Concurrency, Performance, Bandwidth, etc.
ECIC-1.81
Concluding Remarks and Discussion
CSE298
CSE300 
CSE300
What are Keys Issues that Influence and Guide the
Integration Process for EC?
 Communications Alternatives Dictated by
Application Domain
 Tradeoffs of Low-Level (Sockets) vs. Mid-Level
(RCP, RMI) vs. High-Level (CORBA, DCOM, …)
 Will EC Utilize Combination?

Consistency of Information in Distributed
Computing Environment




When is Data Sent from Client to Legacy Server?
Automatic (Regular) vs. User-Initiated?
When Network Traffic is Low?
EC Likely Spans Broad Spectrum
ECIC-1.82
Java Beans and
Enterprise Java Beans
CSE298
CSE300
CSE300
Paul C. Barr
The Mitre Corporation
Eatontown NJ
Kimble Cheron,
Prof. Steven A. Demurjian,
and Mitch Saba
Computer Science & Engr. Dept.
[email protected]
[email protected]
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
ECIC-1.83
Changing Perspectives
CSE298
CSE300 
CSE300 


Computers are Guilty of Creating More Disorder
then Simplicity
Current Software Systems are Relics
 Built Largely By and For Technical Computer
Users
 Never Intended to Operate in Today’s
Environment
Designer’s Need to Break Out of Old Mold
 Consider Total Design Space
 Design Should Help Manage Complexity, Not
Add to It
What is Available to Assist in Changing Times?
ECIC-1.84
Components
CSE298
CSE300 

CSE300

Reusable Software Building Blocks
Pre-Constructed from Encapsulated Application
Code
 Easily Combined with Other Components
 Seamlessly Merged with Custom Code
 Rapid Prototyping of Complete Applicaiton
What is a Component?
 GUI Widget (Button, Window, etc.)
 Combination of Components (Window with
Elevator Bars and Pull-Down Menus)
 Application Service (Account Management
Function)
ECIC-1.85
Overview
CSE298
CSE300 
CSE300



A First Look at Java Beans
 What are They?
 How are They Utilized?
Enterprise Java Beans
 Not Just for Clients Anymore!
 Capabilities and Usage
 Relationship to “New” and “Old” Technologies
 Component-Based Client/Server Model
Multi-Tiered Architecture and EJB
 Tiered Development for Extensibility
 Comparisons of Approaches
Java Blend for Database Interoperability
ECIC-1.86
Java Beans
CSE298
CSE300 
CSE300 
Extends "Write Once, Run Anywhere (WORA)TM"
to Include "Reuse Everywhere”
What is a Bean?
 Independent Reusable Software Component
 Visually Manipulated in Builder Tools
 Can Be Visible Object:
 AWT Components

or Invisible Objects:
 Queues and Stacks

or Composed Objects:
 Calculator Ops + Keys + Display
ECIC-1.87
Java Beans
CSE298
CSE300 
CSE300


Bean vs. Component
 Source Code Inaccessible
 Customizable to Suit Application Needs via
External Properties
 Powerful Means of Reuse
Examples
 GUI Button with Property to Allow Button
Name to be Set
 Account Management Component that Allows
Account Database Location to be Set
Properties Can be Very Complex and Offer
Significant Power to Application Builders
ECIC-1.88
What are Enterprise Java Beans ?
CSE298
CSE300 
CSE300


Expansion of Java Beans (Client-side) to Support
Server Side Reusable Components
 Server Components Run on Application Server
 EJB Integral Part of Java Technology
Component Architecture for Distributed Systems
 Multi-Tier Distributed Architecture
 Movement of Application Logic from Client to
Server Side
 Creation of “Thin”, Easier to Maintain Clients
Framework for Creating Middle Ware
 Integration of “New” and “Old” Technologies
 RMI, IIOP, CORBA, RPC, Active X, etc.
ECIC-1.89
Designer and Developer Roles in
Enterprise Java Beans (EJB)
CSE298
CSE300 
CSE300




Towards “Highly Scalable, Highly Available,
Highly Reliable, Highly Secure, Transaction
Distributed Applications”
Enterprise Bean Provider
 Creates and Sells EJBs
Application Assembler
 Uses EJBs to Build an Application
EJB Server Provider
 Creates and Sells EJB Server
EJB Container Provider
 Creates and Sells EJB Containers
 Server Provider Will Likely Provide Containers
ECIC-1.90
EJB Roles & Deployment
CSE298
CSE300
CSE300
ECIC-1.91
Utilizing EJB Technology
CSE298
CSE300
CSE300
ECIC-1.92
The EJB Architecture
CSE298
CSE300 
CSE300



EJB Servers: Analogous to CORBA ORB
 Server Software
 Provides Naming and Transaction Services
 Makes Containers Visible
EJB Containers: Interface Between EJB Bean and
Outside World
 Client Never Accesses Bean Directly
 Access via Container-Generated Methods
 These Methods Then Call the Bean’s Methods
EJB Clients
 Locate EJB Containers Via JNDI
 Make Use of EJB Beans
Enterprise Java Beans - Discussed Shortly
ECIC-1.93
EJB Container
CSE298
CSE300
CSE300
ECIC-1.94
Enterprise Java APIs
CSE298
CSE300
CSE300
ECIC-1.95
Enterprise Java Beans
Session Beans
CSE298
CSE300 

CSE300




Associated With a Particular Client
Performs Operations on Behalf of Client
 Accessing a Database
 Performing Calculations
Created and Destroyed by a Client
Can be Transactional - But, Do Not Survive
System Shutdown
Can be Stateless or Maintain Conventional State
Across Methods and Transactions
Must Manage Own Persistent Data
ECIC-1.96
Enterprise Java Beans
Entity Beans
CSE298
CSE300 
CSE300 




Object Representation of Persistent Data
Maintained in Permanent Store (Database
Identifiable by Primary Key
Shared by Multiple Clients
Persist Across Multiple Invocations
Survive System Shutdown
Created by
 Inserting Data into Database
 Creating an Object Instance
ECIC-1.97
Model for Persistence
Passivation/Activation
CSE298
CSE300 
CSE300 



Programmatic Model for Managing Persistent
Objects
EJB Server has the Right to Manage its Working
Set
Passivation
 Saves State of a Bean to Persistent Storage
 Then Swaps Bean Out
Activation
 Restores State of a Bean From Persistent
 Storage,Then Swaps Bean in
Applies to Both Session and Entity Beans
ECIC-1.98
Stateless vs. Stateful Session Beans
CSE298
CSE300 
CSE300

Stateless
 No Internal State
 Do Not Need to Be "Pass-ivated"
 Can Be Pooled to Service Multiple Clients
Stateful
 Possess Internal State
 Need to Handle Passivation/Activation
 One Per Client
ECIC-1.99
Entity Bean Persistence
CSE298
CSE300 
CSE300

Container-Managed
 Container is Responsible for Saving State
 In Deployment Descriptor, Specify ContainerManaged Fields
 Persistence Independent of Data Source
Bean-Managed
 Bean is Responsible for Saving its Own State
 Container Doesn’t Need to Generate DB Calls
 Less Adaptable; Persistence is Hard-Coded
ECIC-1.100
Deploying EJBs
CSE298
CSE300 

CSE300




EJBs Deployed As .SER Files: Serialized Instance
Manifest File Used to List EJBs
Must Also Provide a “Deployment Descriptor”
Sample Entry
 Name: paul.RestaurantDeployment.ser
 Enterprise-Bean: True
“Name” Line
 Describes a Serialized Deployment Descriptor
“Enterprise-Bean” Line
 Indicates Whether the Entry Should Be Treated
as an EJB
 (Not All Entries Need to Be EJBs)
ECIC-1.101
Who’s Announced EJB Support?
CSE298
CSE300 

CSE300






WebLogic
IBM
Oracle
GemStone
BEA
Borland
Netscape
Lotus








Forte
Progress
Novell
Novera
Borland
Informix
IONA
More...
ECIC-1.102
Typical Development and Deployment
Scenario
CSE298
CSE300 
CSE300


EJB Server Provider
 Creates and Sells an EJB Server
 Provides EJB Containers That Will Run on
These Servers
EJB Providers
 Individuals Responsible for Developing the
EJBs
 Provide “Tools” and “Components” for DownStream Usage
Application Assemblers
 Individuals that Utilize Pre-Built EJBs to
Construct Their Domain-Specific Applications
 Utilize “State-of-Art-Tools” for EJB and JB
ECIC-1.103
EJB Component-Based Architecture
CSE298
CSE300
CSE300
EJB Server
EJB Client
Invoke EJB
Container
Methods
Enterprise
Java Bean
Invoke
EJB
Methods
EJB Container
ECIC-1.104
Client-Server Component Model
CSE298
CSE300
CSE300
ECIC-1.105
Two-Tier, Three-Tier, Four-Tier
Example Architectures
CSE298
CSE300
CSE300
From: http://java.sun.com/javaone/javaone98/sessions/T400/index.html
ECIC-1.106
Wombat Securities
CSE298
CSE300 

CSE300





Web Access to Brokerage Accounts
Only HTML Browser Required on Front End
"Brokerbean" EJB Provides Business Logic
Login, Query, Trade Servlets Call Brokerbean
Use JNDI to Find EJBs, RMI to Invoke Them
Order and History Records from Java Blend
Product
Records Mapped to Oracle Tables, JDBC Calls
ECIC-1.107
Four-Tier Architecture Example
CSE298
CSE300
CSE300
ECIC-1.108
Nocturnal Aviation, Inc.
CSE298
CSE300 
CSE300






Passenger Check-in for Regional Airline
Local Database for Seating on Today's Flights
Clients Invoke EJBs at Local Site Through RMI
EJBs Update Database and Queue Updates
JMS Queues Updates to Legacy System
DBC API Used to Access Local Database
JTS Synchs Remote Queue With Local Updates
ECIC-1.109
Three-Tier Example
CSE298
CSE300
CSE300
ECIC-1.110
Santa Cruz Widgets
CSE298
CSE300 
CSE300





Small Manufacturer Previously on C++
New Order Entry, Inventory, and Invoicing
Applications in Java Programming Language
Existing Customer and Order Database
Most of Business Logic in Stored Procedures
Tool-generated GUI Forms for Java Objects
Located Company on Web Using Widgets and Tcl,
but Not Widgets and Java
ECIC-1.111
Santa Cruz Widgets (2-tier)
CSE298
CSE300
CSE300
ECIC-1.112
Architecture Comparisons
CSE298
CSE300 
CSE300




Two-tier Through JDBC API: Simplest
Multi-tier: Separate Business Logic, Protect
Database Integrity, More Scaleable
JMS Queues Vs Synchronous (RMI or IDL):
 Availability, Response Time, Decoupling
JMS Publish & Subscribe: Off-line Notification
RMI IIOP Vs JRMP Vs Java IDL:
 Standard Cross-language Calls or Full Java
Functionality
JTS: Distributed Integrity, Lockstep Actions
ECIC-1.113
Further API Comparisons
CSE298
CSE300 
CSE300




Servlets: Simplifies HTML, Connections, Web
Front-Ending Legacy Systems
EJBs: Simplifies Components, Scalability,
Transactions, Multi-threading, Security, State
JDBC Vs ODMG Vs SQLJ API:
 Programming Simplicity, Portability, SQL
Knowledge
JNDI: Standardized Name Service Access
Enterprise Java APIs vs. Proprietary:
 Multi-Platform, Multiple Providers
ECIC-1.114
Summary & Key Messages
CSE298
CSE300 
CSE300 

Enterprise Java APIs: EJB, JNDI, Java IDL, RMI,
JDBC, ODMG, SQLJ, JMS, JTS, JMAPI, Servlets
Wide Variety of Architectural Alternatives:
 Synchronous/Asynchronous, Multi-Tier,
Transactional, HTTP/JRMP/IIOP
Benefits:
 WORA Portability
 Multiple Vendors
 Legacy Connectivity
 Java Programming Language Productivity
ECIC-1.115
EJB Roadmap
CSE298
CSE300
API
EJB
CSE300 JNDI
JIDL
RMI
JDBC
ODMG
SQLJ
JMS
JTS
JMAPI
Sevlets
Specification
Complete
Products
JavaSoft
JavaSoft
OMG
JavaSoft
JavaSoft
Consortium
Consortium
JavaSoft
OMG
JavaSoft
JavaSoft
1.0Q1
1.0 done
1.0 Q2
1.0 done
2.0 Q2
2.0 done
1.0 Q2
1.0 Q2
1.0 done
1.0 Q2
1.1 done
See Partners
Download SP
JDK 1.2
JDK 1.1
JDK 1.2 Partner
JavaBlend
See Partners
See Partners
Partners
See Partners
Java Web Server
ECIC-1.116
What Is the Java Blend Product?
CSE298
CSE300 
CSE300 

Product That Integrates Java Programming
Language Objects With Enterprise Data
Provides a Single Object Model Based on Java
Programming Language Classes
 Automatic Persistent Storage for Java
Application Objects
 Easy, Automatic Access to Existing Relational
Databases From Java Applications
Result of Joint Development by the Javasoft
Division, Baan and Tech@spree
ECIC-1.117
JavaBlend Applications
CSE298
CSE300
CSE300


JavaBlend Software Provides Mapping Capability
Between Database Tables and Java Application
Classes
Programmer Deals Only With Java Programming
Language Objects, and Does Not Need to Know
SQL or Database Representation
ECIC-1.118
Java Blend Components
CSE298
CSE300 
CSE300

Flexible Development Tool for Automatic
Bi-Directional Mapping
 Objects to Relational
 Relational to Objects
Powerful Runtime Environment
 Transaction Management System
 Query Processor
 Cache Management System
ECIC-1.119
Java Blend Runtime Architecture
CSE298
CSE300
CSE300
ECIC-1.120
Java Blend Software and Enterprise
JavaBeans Technology
CSE298
CSE300 
CSE300 
EJB Technology Provides Scaleable Component
Architecture for Business Applications
Java Blend Product Provides Transparent
Persistence for Enterprise Javabeans Technology
 Beans Implementing Business Logic Use Java
Blend for Database Access
 Java Blend Product Works With the Enterprise
Javabeans API Transaction Mechanisms
ECIC-1.121
Concluding Remarks
Enterprise Computing/Interoperability
CSE298
CSE300 

CSE300
Technologies Continue to Emerge and Mature
Complex Problem for Companies and
Organizations
 What are “Good” and “Stable” Technologies?
 How can they be Leveraged for Gain?
 Which Technologies Will Emerge in ShortTerm and Long-Term?
 How will Technologies Interact?
 CORBA vs. DCOM vs. EJB
 Java vs. Component Design/Programming
 Heterogeneous Agent Platforms

Future Difficult to Predict!
ECIC-1.122