enterprise computing and interoperability

ECIC-1.1

CSE298

CSE300

CSE300

Enterprise Computing and Interoperability

Prof. Steven A. Demurjian

Computer Science & Engineering DepartmentThe University of Connecticut

191 Auditorium Road, Box U-155Storrs, CT 06269-3155

[email protected]://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.2

CSE298

CSE300

CSE300

Overview of PresentationOverview of Presentation

What is Enterprise Computing?What is Enterprise Computing? Interoperability and CORBAInteroperability and CORBA

Primer Key Concepts and Ideas System Design with CORBA/IDL

Interoperability StrategiesInteroperability Strategies General Approaches Java-Based Wrapper

Security Issues for Enterprise ComputingSecurity Issues for Enterprise Computing What are Key Issues re. Security for EC? How are Legacy/COTS Handled?

Concluding RemarksConcluding Remarks

ECIC-1.3

CSE298

CSE300

CSE300

What is Enterprise Computing?What is Enterprise Computing?

Today’s and Tomorrows Applications are System Today’s and Tomorrows Applications are System of Systemsof Systems Facilitate Interactions/Information Exchange Leverage Existing Information, Resources, and

Applications in New Environment Interoperability Key Issue

Strive for New/Innovative Application Usage in Strive for New/Innovative Application Usage in Distributed Environment - For Example …Distributed Environment - For Example … Expand to Multi-User Capabilities Incorporate Modern GUI Introduce Useful Functionality Upgrade to Web-Based Access

ECIC-1.4

CSE298

CSE300

CSE300

Client

Application

Object

Implementation

ORB

Role of an Object Request Broker (ORB)Role of an Object Request Broker (ORB)

ORB Provides the Underlying Infrastructure for ORB Provides the Underlying Infrastructure for Supporting Interoperating Software Systems Supporting Interoperating Software Systems (Applications) Composed of Distributed Objects(Applications) Composed of Distributed Objects ORB Provides the Basic Request Delivery ORB Provides Interface Definitions

Location is Transparent to the Caller and Object Location is Transparent to the Caller and Object ImplementationImplementation

Caller and the Object Implementation Can be in the Caller and the Object Implementation Can be in the Same Process thru Opposite Sides of the WorldSame Process thru Opposite Sides of the World

ORB Manages Local Location and OptimizationORB Manages Local Location and Optimization

ECIC-1.5

CSE298

CSE300

CSE300

Interface Definition Language, IDLInterface Definition Language, IDL

Key Component of CORBA Is the Interface Key Component of CORBA Is the Interface Definition Language, IDLDefinition 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 Primary Support for Interoperability Between Static and Dynamic Request MechanismsStatic and Dynamic Request Mechanisms

ECIC-1.6

CSE298

CSE300

CSE300

ClientApplication

ObjectImplementation

ORB

Object reference Object dispatcher

IDL Boundary

Object Call

IDL Boundary

Methods and Data

Request

ORB and High Level View of RequestsORB and High Level View of Requests

The Request Consists ofThe Request Consists of Target Object Operation (Method) Parameters Request Context (Optional)

ECIC-1.7

CSE298

CSE300

CSE300

ObjectAdapter

ORB Core

One interfaceOne interface per object adaptorOne interface per object operation

ORB internal interface

DynamicInvoke

ClientStubs

ORBInterface

Client Object Implementation

ImplementationSkeletons

CORBA Components and InterfacesCORBA Components and Interfaces

Client Stub: Client Invokes a Particular Object Op.Client Stub: Client Invokes a Particular Object Op. Dynamic Invocation: Run-Time-Construction of Dynamic Invocation: Run-Time-Construction of

Operation InvocationsOperation Invocations Implementation Skeleton: Interface Through Implementation Skeleton: Interface Through

Which a Method Receives a RequestWhich a Method Receives a Request Object Adapter: Provides (De)activation, Object Object Adapter: Provides (De)activation, Object

Creation/Reference Mgmt. for ImplementationsCreation/Reference Mgmt. for Implementations ORB Interface: Common ORB OperationsORB Interface: Common ORB Operations

ECIC-1.8

CSE298

CSE300

CSE300

ClientStubs


Client Object Implementation

InterfaceRepository

ImplementationRepository

Access Includes Includes Describes

IDL InterfaceDefinitions

ImplementationInstallation

InterfacesInterfaces

Objects are Defined in IDL via InterfacesObjects are Defined in IDL via Interfaces Object Definitions (Interfaces) are Manifested as Object Definitions (Interfaces) are Manifested as

Objects in the Interface Repository, as Client Objects in the Interface Repository, as Client Stubs, and as Implementation SkeletonsStubs, and as Implementation Skeletons

Descriptions of Object Implementations are Descriptions of Object Implementations are Maintained as Objects in the Impl. RepositoryMaintained as Objects in the Impl. Repository

ECIC-1.9

CSE298

CSE300

CSE300

ORB Core

ObjectAdapter

Object Implementation


Client

DynamicInvoke

ClientStubs

ORBInterface

ObjectRepository

Client SideClient Side

Clients Perform Requests Using Object ReferencesClients Perform Requests Using Object References Clients Issue Requests through Object Interface Clients Issue Requests through Object Interface

Stubs (Static) or DII (Dynamic Invocation Inter.)Stubs (Static) or DII (Dynamic Invocation Inter.) Clients May Access General ORB Services:Clients May Access General ORB Services:

Interface Repository (IR) Context Management Request Management

ECIC-1.10

CSE298

CSE300

CSE300

ORB Core

ORBInterface


Object Adapter

Implem.Skeletons

DynamicInvoke

ClientStubs

ClientImplementation

Repository

Object Implementation SideObject Implementation Side

Implementations Receive Requests Thru SkeletonsImplementations Receive Requests Thru Skeletons Object Adapter Adapts to Specifics of Object Object Adapter Adapts to Specifics of Object

Implementation SchemesImplementation Schemes Basic Object Adapter (BOA) Provides:Basic Object Adapter (BOA) Provides:

Management of References Method Invocation Authentication Implementation Registration Activation / Deactivation

ECIC-1.11

CSE298

CSE300

CSE300

Dynamic Invocation Interface (DII)Dynamic Invocation Interface (DII)

DII Allows Clients to Dynamically:DII Allows Clients to Dynamically: Discover Objects Discover Objects’ Interfaces Create Requests Invoke Requests (-> Methods) Receive Responses

Major DII Features: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.12

CSE298

CSE300

CSE300

Request ComponentsRequest Components

Object Reference -- Identifies the Target ObjectObject Reference -- Identifies the Target Object Operation -- Identifies Which Operation to Invoke Operation -- Identifies Which Operation to Invoke

(Which Method Will Be Executed)(Which Method Will Be Executed) Parameters -- Input, Output or Inout Method Arg-sParameters -- Input, Output or Inout Method Arg-s Context Object -- the Context Within Which the Context Object -- the Context Within Which the

Request Is to Be PerformedRequest Is to Be Performed Results -- the Result Value(s) ReturnedResults -- the Result Value(s) Returned Environment -- the Exec-n Env-t and Exception Environment -- the Exec-n Env-t and Exception

Info.Info. Request Handle -- the Id. For This Request Request Handle -- the Id. For This Request

InstanceInstance

ECIC-1.13

CSE298

CSE300

CSE300

Repositories: Repositories: Interface and ImplementationInterface and Implementation

Interface RepositoryInterface Repository Dynamic Client Access to Interface Definitions

to Construct a Request Dynamic Type Checking of Request Signatures Traversal of Inheritance Graphs

Implementation RepositoryImplementation Repository Location of Implementations and Methods Activation Information Administration Control Resource Allocation Security

ECIC-1.14

CSE298

CSE300

CSE300 Client Object

RequestORB

ORB and implementations implemented as libraries (routines) resident in the client.

Three Types of ORBsThree Types of ORBs

Single Process Library ResidentSingle Process Library Resident

Client and Implementation ResidentClient and Implementation Resident

Client Object

RequestORB

ORB implemented as libraries (routines) resident in the clients and in the implementations.

ECIC-1.15

CSE298

CSE300

CSE300

Client Object

RequestORB

ORB is implemented as a server (separate process) which brokers requests between client and implementation processes.

ORB is part of the operating system.

Three Types of ORBsThree Types of ORBs

Server or Operating System BasedServer or Operating System Based

ECIC-1.16

CSE298

CSE300

CSE300

Implementation is a permanentor resident multi-threadedprocess

Implementation is a singleprocess that is activatedupon the request delivery


Single Process

Singlemethodinvocation


Single Process

Method CMethod B

Method A

Three Types of ImplementationsThree Types of Implementations

Single Process “one shot” ObjectSingle Process “one shot” Object

Multi-Threaded “resident” ObjectMulti-Threaded “resident” Object

ECIC-1.17

CSE298

CSE300

CSE300

Implementation is a setof processes dedicated toa particular (group of)method(s)

Processes can be distributed


Process 1

Process 2

Process 3

Method A

Method B

Method C

Three Types of ImplementationsThree Types of Implementations

Multi-Process ObjectMulti-Process Object

ECIC-1.18

CSE298

CSE300

CSE300

System Design with CORBASystem Design with CORBA

Scott A. CraigComputer Science & Engineering Department

The University of ConnecticutStorrs, Connecticut 06269-3155

[email protected]

ECIC-1.19

CSE298

CSE300

CSE300

Overview of PresentationOverview of Presentation

Introduction to OMG IDLIntroduction to OMG IDL Object Management ArchitectureObject Management Architecture

CORBAservices Naming Service

Event Service Typed Event ExampleTyped Event Example ReferencesReferences Concluding RemarksConcluding Remarks

ECIC-1.20

CSE298

CSE300

CSE300

Interface Definition Language, IDLInterface Definition Language, IDL

Language used to describe the interfaces that client Language used to describe the interfaces that client objects call and object implementations provide.objects call and object implementations provide.

Obeys the same lexical rules as C++, but Obeys the same lexical rules as C++, but introduces some new keywords.introduces some new keywords.

Supports standard C++ preprocessing features.Supports standard C++ preprocessing features. Interfaces can have operations and attributes.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 Interface specifications are placed in a source file having the extension “.idl”having the extension “.idl”

ECIC-1.21

CSE298

CSE300

CSE300

IDL: Modules and InterfacesIDL: Modules and Interfaces

Module: Used to scope IDL identifiers.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 Interface: Description of set of operations that a

client may request of an object.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.22

CSE298

CSE300

CSE300

IDL: Basic TypesIDL: Basic Types

Type Range

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

CSE298

CSE300

CSE300

IDL: Complex TypesIDL: Complex Types

Structures: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 Discriminated Unions: Cross between the C unionunion and and switchswitch statements. statements.

Enumerations: Ordered list of identifiers.Enumerations: Ordered list of identifiers. enum quality_t { Poor, Fair, Good, Excellent};

ECIC-1.24

CSE298

CSE300

CSE300

IDL: Complex Types (cont.)IDL: Complex Types (cont.)

Sequences: One-dimensional array with maximum Sequences: One-dimensional array with maximum size (fixed at compile time) and length (set at run size (fixed at compile time) and length (set at run time).time). Unbounded Sequence:typdef sequence<long> longSeq;

Bounded Sequence:sequence<long,10> fieldname;

Strings: Declared using keyword Strings: Declared using keyword string.string. May May be bounded or unbounded.be bounded or unbounded. string name<32>; //bounded

Arrays: Multidimensional, fixed-size arrays of any Arrays: Multidimensional, fixed-size arrays of any IDL data type.IDL data type.

ECIC-1.25

CSE298

CSE300

CSE300

IDL Example: GUIIDL 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

ECIC-1.26

CSE298

CSE300

CSE300

IDL Example: ServerIDL 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 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.27

CSE298

CSE300

CSE300

Object Management ArchitectureObject Management Architecture

The Object Management Group, Inc (OMG) has The Object Management Group, Inc (OMG) has established the Object Management Architecture established the Object Management Architecture (OMA), upon which OMG specifications are based(OMA), upon which OMG specifications are based

Components of the OMA Reference Model: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.28

CSE298

CSE300

CSE300

CORBAservicesCORBAservices

OMG specification for Object ServicesOMG specification for Object Services Collection of 15 services (interfaces and objects) Collection of 15 services (interfaces and objects)

that support basic functions for using and that support basic functions for using and implementing objects.implementing objects. Interfaces specified using IDL

Will focus on two services:Will focus on two services: Naming Service Event Service

Security Service: Addresses identification and Security Service: Addresses identification and authentication, authorization and access control, authentication, authorization and access control, security of communication between objects, etc.security of communication between objects, etc. Beyond scope of this presentation (specification

is 386 pages in length)

ECIC-1.29

CSE298

CSE300

CSE300

Naming ServiceNaming Service

Facilitates locating objects in a distributed system.Facilitates locating objects in a distributed system. A A name bindingname binding is a name-to-object association and is a name-to-object association and

is always defined relative to a is always defined relative to a naming context.naming context. A naming context is an object that contains a set of A naming context is an object that contains a set of

name bindings in which each name is unique.name bindings in which each name is unique. Multiple names may be bound to an object.Multiple names may be bound to an object. Servers bind names to objects and clients resolve Servers bind names to objects and clients resolve

names to objects.names to objects. A naming context may be bound to a name in A naming context may be bound to a name in

another naming context creating a another naming context creating a naming graph.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.30

CSE298

CSE300

CSE300

Naming GraphNaming Graph

ContextContext

Application ObjectApplication Object

EngineeringEngineering PharmacyPharmacy

DeanDean DeanDean

<Engineering;Dean><Engineering;Dean> <Pharmacy;Dean><Pharmacy;Dean>

CSECSE

EEEE PracticePractice

ScienceScience

ECIC-1.31

CSE298

CSE300

CSE300

CosNamingModuleCosNamingModule

NamingContext Interface Operations: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 BindingIterator Interface: Allows a client to iterate through the bindings using next_one(…) or iterate through the bindings using next_one(…) or next_n(…) operations.next_n(…) operations.

ECIC-1.32

CSE298

CSE300

CSE300

Event ServiceEvent Service

A standard CORBA request issued by a client A standard CORBA request issued by a client results in the synchronous execution of an results in the synchronous execution of an operation by an object (server).operation by an object (server). Request directed to a particular object. Client must handle exceptions if request fails.

Event Service decouples communication between Event Service decouples communication between objects, defining two roles for objects:objects, defining two roles for objects: Supplier Role: Produce event data Consumer Role: Process event data

Event data are communicated by issuing standard Event data are communicated by issuing standard CORBA requests. No extensions to CORBA are CORBA requests. No extensions to CORBA are necessary to define event interfaces.necessary to define event interfaces.

Communication may be generic or typed.Communication may be generic or typed.

ECIC-1.33

CSE298

CSE300

CSE300

Event Service Design PrinciplesEvent Service Design Principles

Allow multiple consumers and multiple suppliers.Allow multiple consumers and multiple suppliers. Consumers can either request events (pull model) Consumers can either request events (pull model)

or be notified of events (push model).or be notified of events (push model). Software architectural decision.

Supplier can issue a single standard CORBA Supplier can issue a single standard CORBA request to communicate event data to all request to communicate event data to all consumers.consumers.

Suppliers can generate events without knowing the Suppliers can generate events without knowing the identities of consumers and consumers can receive identities of consumers and consumers can receive events without knowing the identities of suppliers.events without knowing the identities of suppliers.

Event Service specification allows multiple Event Service specification allows multiple qualities of service (reliability).qualities of service (reliability). Implementation dependent.

ECIC-1.34

CSE298

CSE300

CSE300

Push ModelPush Model

Suppliers realize Suppliers realize PushSupplierPushSupplier interface and interface and consumers realize consumers realize PushConsumerPushConsumer interface. interface.

Suppliers invoke push operations on Suppliers invoke push operations on PushConsumerPushConsumer interface. interface. Supplier initiates transfer of event data.

Communication set up by exchanging object Communication set up by exchanging object references.references.

Either can break communication by invoking the Either can break communication by invoking the disconnect operation on the other.disconnect operation on the other.

ECIC-1.35

CSE298

CSE300

CSE300

Pull ModelPull Model

Suppliers realize Suppliers realize PullSupplierPullSupplier interface and interface and consumers realize consumers realize PullConsumerPullConsumer interface. interface.

Consumers invoke pull operations on Consumers invoke pull operations on PushSupplierPushSupplier interface.interface. Consumer initiates transfer of event data.

Communication set up by exchanging object Communication set up by exchanging object references.references.

Either can break communication by invoking the Either can break communication by invoking the disconnect operation on the other.disconnect operation on the other.

ECIC-1.36

CSE298

CSE300

CSE300

Event ChannelsEvent Channels

Event Channel is a service that decouples Event Channel is a service that decouples communication between suppliers and consumers.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 ChannelPush-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 ChannelPull-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 Mixed-Style Communication with an Event ChannelChannel

ECIC-1.37

CSE298

CSE300

CSE300

Event Channels (cont.)Event Channels (cont.)

Multiple Consumers and Multiple SuppliersMultiple Consumers and Multiple Suppliers Event Channel consumes events from one or

more suppliers and supplies events to one or more consumers.

:EventChannel:EventChannel

CN:ConsumerCN:ConsumerC1:ConsumerC1:Consumer

S1:SupplierS1:Supplier S2:SupplierS2:Supplier

......

PushSupplierPushSupplier

PushConsumerPushConsumer

PushConsumerPushConsumerPushConsumerPushConsumer



ECIC-1.38

CSE298

CSE300

CSE300

Typed Event CommunicationTyped Event Communication

In the preceding generic models, suppliers must In the preceding generic models, suppliers must insert data into an “any” parameter and consumers insert data into an “any” parameter and consumers must then extract the data.must then extract the data.

Alternative approach is the Typed Push ModelAlternative 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.39

CSE298

CSE300

CSE300

TypedPushConsumerTypedPushConsumer

User_ev

+ notification(val : in User_cs::Notification_t) : void+ update(val : in User_cs::Update_t) : void

<<Interface>>

TypedPushConsumer

+ get_typed_consumer() : Object

(from Common_Interface)

<<Interface>>

PushConsumer

+ push(data : in any) : void+ disconnect_push_consumer() : void


<<Interface>>

ECIC-1.40

CSE298

CSE300

CSE300

Typed Event ExampleTyped Event Example

Problem Statement: Wish to design a distributed Problem Statement: Wish to design a distributed system consisting of two Suppliers, a Typed Event system consisting of two Suppliers, a Typed Event Channel, and multiple Consumers.Channel, and multiple Consumers.

Supplier realizes a Client/Server interface Supplier realizes a Client/Server interface ((User_csUser_cs) that has two operations; one that returns ) that has two operations; one that returns a variable-length structure and one that returns a a variable-length structure and one that returns a fixed-length structure.fixed-length structure.

Consumer realizes an Event interface (Consumer realizes an Event interface (User_evUser_ev) ) that inherits from TypedPushConsumer.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.41

CSE298

CSE300

CSE300

Typed Event Example (cont.)Typed Event Example (cont.)

Event Channel must be running before any Event Channel must be running before any Suppliers or Consumers are started.Suppliers or Consumers are started.

When a Supplier is started, it binds a name to the When a Supplier is started, it binds a name to the object that realizes the object that realizes the User_csUser_cs interface. Each interface. Each Supplier must supply a unique name. It then Supplier must supply a unique name. It then connects to the Event Channel as a push supplier.connects to the Event Channel as a push supplier.

When a Consumer is started, it obtains an object When a Consumer is started, it obtains an object reference to each reference to each User_csUser_cs interface via the interface via the Naming Service. It then connects to the Event Naming Service. It then connects to the Event Channel as a push consumer.Channel as a push consumer.

When a Consumer receives a notification event, it When a Consumer receives a notification event, it retrieves the variable-length struct from the retrieves the variable-length struct from the appropriate Supplier via the C/S interface.appropriate Supplier via the C/S interface.

ECIC-1.42

CSE298

CSE300

CSE300

Class DiagramClass Diagram

TypedPushConsumer

+ get_typed_consumer() : Object


<<Interface>>

User_ev

+ notification(val : in User_cs::Notification_t) : void+ update(val : in User_cs::Update_t) : void

<<Interface>>

User_cs

+ getVarLengthStruct() : VarLengthStruct_t+ getUpdate() : Update_t

<<Interface>>

Notification_t

- timestamp : long- source : source_t

(from User_cs)

source_t

- source1- source2

(from User_cs)

Update_t

- timestamp : long- data : float- source : source_t

(from User_cs)

VarLengthStruct_t

- timestamp : long- source : source_t- data : string

(from User_cs)

ECIC-1.43

CSE298

CSE300

CSE300

Component Diagram: Source FilesComponent Diagram: Source Files

User_cs

User_cs

User_ev

User_ev

ECIC-1.44

CSE298

CSE300

CSE300

Component Diagram: ExecutablesComponent Diagram: Executables

EventChannelEventChannel

ConsumerConsumer

SupplierSupplier

User_evUser_ev

User_evUser_ev



User_csUser_cs

ECIC-1.45

CSE298

CSE300

CSE300

Collaboration DiagramCollaboration Diagram

source1 : User_cs

EC : User_ev

C1 : User_ev

C2 : User_ev

1: notification(...)

5: getVarLengthStruct( )


4: getVarLengthStruct( )


ECIC-1.46

CSE298

CSE300

CSE300

Deployment Diagram (degenerate)Deployment Diagram (degenerate)

:EventChannel:EventChannel

CN:ConsumerCN:ConsumerC1:ConsumerC1:Consumer

S1:SupplierS1:Supplier{source1}{source1}

S2:SupplierS2:Supplier{source2}{source2}

......

PushSupplierPushSupplierUser_evUser_ev

User_evUser_evUser_evUser_ev



User_csUser_cs User_csUser_cs

ECIC-1.47

CSE298

CSE300

CSE300

Design ConsiderationsDesign Considerations

Some form of event strategy should be employed to Some form of event strategy should be employed to avoid having clients polling servers.avoid having clients polling servers.

For performance reasons, only small, fixed-length For performance reasons, only small, fixed-length structures should be pushed using Typed Events.structures should be pushed using Typed Events.

Because of middleware overhead, structure should Because of middleware overhead, structure should be optimally packed.be optimally packed.

Adding the “oneway” attribute to operations with Adding the “oneway” attribute to operations with no return type can improve performance, but no return type can improve performance, but reduces reliability (undetected comm. failures).reduces reliability (undetected comm. failures).

Consumers of aperiodic events may be unaware of Consumers of aperiodic events may be unaware of Event Channel crashes. Event Channels should Event Channel crashes. Event Channels should periodically generate “keep alive” events and periodically generate “keep alive” events and Consumers should reconnect if not received.Consumers should reconnect if not received.

ECIC-1.48

CSE298

CSE300

CSE300

ReferencesReferences

Object Management Group, Inc. (OMG), Object Management Group, Inc. (OMG), http://www.omg.orghttp://www.omg.org

OMG, OMG, A Discussion of the Object Management A Discussion of the Object Management ArchitectureArchitecture, 01/97, 01/97

OMG, OMG, The Common Object Request Broker: The Common Object Request Broker: Architecture and SpecificationArchitecture and Specification, Rev. 2.2, 02/98, Rev. 2.2, 02/98

OMG, OMG, CORBAservices: Common Object Services CORBAservices: Common Object Services SpecificationSpecification, 12/98, 12/98

T. J. Mowbray and R. Zahavi, T. J. Mowbray and R. Zahavi, The Essential The Essential CORBA: Systems Integration Using Distributed CORBA: Systems Integration Using Distributed ObjectsObjects, John Wiley & Sons, Inc., 1995, John Wiley & Sons, Inc., 1995

G. Booch, J. Rumbaugh, I. Jacobson, G. Booch, J. Rumbaugh, I. Jacobson, The Unified The Unified Modeling Language User GuideModeling Language User Guide, AWL, Inc. 1999, AWL, Inc. 1999

ECIC-1.49

CSE298

CSE300

CSE300

Concluding RemarksConcluding Remarks

Introduced OMG IDLIntroduced OMG IDL Mappings to C++, Java, etc.

Provided overview of OMG Object Management Provided overview of OMG Object Management Architecture and the role of Object Services.Architecture and the role of Object Services. Provided overview of Naming Service and

Event Service. Presented a distributed system that makes use of Presented a distributed system that makes use of

Naming and Event Services.Naming and Event Services. Future Work:Future Work:

Investigation of Security Services

ECIC-1.50

CSE298

CSE300

CSE300

Interoperability StrategiesInteroperability Strategies

Architectural Alternatives and FrameworksArchitectural Alternatives and Frameworks Taxonomy of Architectural Variants Integration via Java, CORBA, etc.

Case Study: The ADAM EnvironmentCase Study: The ADAM Environment Upgrading a C++ Legacy Application to be

Java-Compatible Pros and Cons of Effort

Issues for InteroperabilityIssues for Interoperability Outlining Future Efforts and EmphasesOutlining Future Efforts and Emphases Concluding Remarks and DiscussionConcluding Remarks and Discussion

ECIC-1.51

CSE298

CSE300

CSE300

Architectural Alternatives & FrameworkArchitectural Alternatives & Framework

Reviewing Architectural VariantsReviewing 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 Quick Review of Select Material from Summer

1997 White Paper:1997 White Paper: “The Java Programming Language: Impact upon

the Army Technical Architecture (ATA) and Joint Technical Architecture (JTC)” Demurjian/Shin

ECIC-1.52

CSE298

CSE300

CSE300

Java Client to Legacy App via RDBSJava Client to Legacy App via RDBS

Java ClientJava Client

LegacyLegacyApplicationApplication

Relational Relational DatabaseDatabase

System(RDS)System(RDS)

Transformed Transformed Legacy DataLegacy Data

Updated DataUpdated Data

Extract and Extract and Generate DataGenerate Data

Transform andTransform andStore DataStore Data

ECIC-1.53

CSE298

CSE300

CSE300

ORB Integration of Java ClientORB Integration of Java Clientand Legacy Applicationand Legacy Application

Java ClientJava ClientLegacyLegacy

ApplicationApplication

JavaJavaWrapperWrapper

Object Request Broker (ORB)Object Request Broker (ORB)

CORBA is the Medium of Info. Exchange

Requires Java/CORBA Capabilities

ECIC-1.54

CSE298

CSE300

CSE300

Java Client with Wrapper Java Client with Wrapper to Legacy Applicationto Legacy Application

LegacyLegacyApplicationApplication

NetworkNetwork

Java ClientJava Client

Java Application CodeJava Application Code

WRAPPERWRAPPER

Mapping ClassesMapping Classes

JAVA LAYERJAVA LAYER

NATIVE LAYERNATIVE LAYER

Native Functions (C++)Native Functions (C++)RPC Client Stubs (C)RPC Client Stubs (C)

Interactions Between Java ClientInteractions Between Java Clientand Legacy Appl. via C and RPCand Legacy Appl. via C and RPC

C is the Medium of Info. ExchangeC is the Medium of Info. Exchange

Java Client with C++/C WrapperJava Client with C++/C Wrapper

ECIC-1.55

CSE298

CSE300

CSE300

One COTS and One Legacy One COTS and One Legacy Application to Java ClientsApplication to Java Clients

NetworkNetwork


JAVA NETWORK WRAPPERJAVA NETWORK WRAPPER




Native Functions that Native Functions that Map to COTS ApplMap to COTS Appl

Java ClientJava Client Java ClientJava Client


JAVA NETWORK WRAPPERJAVA NETWORK WRAPPER




Native Functions that Native Functions that Map to Legacy ApplMap to Legacy Appl

COTS ApplicationCOTS Application Legacy ApplicationLegacy Application

Java is Medium of Info. Exchange - C/C++ Appls with Java Wrappers

ECIC-1.56

CSE298

CSE300

CSE300

ADAM: User PerspectiveADAM: User Perspective

ServerAbstraction for Design Persistence

C++Ada83, Ada95EiffelJava (on PC/NT)Ascii/Latex Doc.

Ontos OODBS

Multiple Versions: ADAM/Unix: IV3.1, X, Sparcstation ADAM/PC: Win95, Borland C++ ADAM/NT: Under Development

Code/Documentation Generation

ADAM GraphicalUser Interface

OODesign

ECIC-1.57

CSE298

CSE300

CSE300

Case Study: The ADAM EnvironmentCase Study: The ADAM Environment

ADAM is a C++ Legacy Application with: 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: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++ Similar to Providing C/S Interactions for an C++ Legacy/COTS ApplicationLegacy/COTS Application

ECIC-1.58

CSE298

CSE300

CSE300

Characterizing ADAM Software ProfileCharacterizing ADAM Software Profile

C++ Class Library - Intended as a Single-CPU, C++ Class Library - Intended as a Single-CPU, Single-User, Interactive Design EnvironmentSingle-User, Interactive Design Environment

C++ Classes Structured as Multiple Interacting C++ Classes Structured as Multiple Interacting Hierarchies for Different Components: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 SoftwareSource Code Level Access to ADAM Software Goal: Minimize Code-Level Modifications as Goal: Minimize Code-Level Modifications as

ADAM Moves to Java Client/Server ParadigmADAM Moves to Java Client/Server Paradigm

ECIC-1.59

CSE298

CSE300

CSE300

ADAM: Current Software ArchitectureADAM: Current Software Architecture

C++ Classes/Instancesto Store Design and

Code GenerationAlgorithms

DB ServerAbstraction for Design Persistence

C++Ontos C++Ada83, Ada95EiffelJava (on PC)

Ontos OODBS

ADAM/Unix: IV3.1, X, SparcstationADAM/PC: Win95, Borland C++

Design/GenerationCompiler Independent Software

ADAM GraphicalUser Interface

OODesign

ECIC-1.60

CSE298

CSE300

CSE300

Client Requirements and FunctionalitiesClient Requirements and Functionalities

New ADAM Java Client Replicates Core C++ New ADAM Java Client Replicates Core C++ Classes to Allow Transitory Storage of Designs: 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 ServerJava Communications from Client to Server

Transmission of Modified Design to Server Receipt of Existing Design from Server Both Accomplished via Object Serialization

ECIC-1.61

CSE298

CSE300

CSE300

Client Requirements and FunctionalitiesClient Requirements and Functionalities

ADAM C++Legacy Application

(Server)

Java/TwinPeaksWrapper

Existing Designs Sent/Loaded for Local Manipulation

Completed New Designs orRevised Existing Designs

Sent for Persistent Storage

New ADAM JavaUser Interface

(Client)

OODesign

Designs atClient toReduce

CommunicationOverhead

ECIC-1.62

CSE298

CSE300

CSE300

ADAM: Target Software ArchitectureADAM: Target Software Architecture

Java Communications (Object Serialization/Sockets)

New ADAM JavaUser Interface

(Client)

OODesign

Java/TwinPeaksWrapper

ADAM C++Legacy Application

(Server)

Java: Communication and Interpretation

C++: Common Interfaceto Access Server Classes

Modified Design to Server

Existing Design from Server

ECIC-1.63

CSE298

CSE300

CSE300

Wrapper Requirements and FunctionalitiesWrapper Requirements and Functionalities

Transmission/Receipt of Messages from ClientsTransmission/Receipt of Messages from Clients Existing Design from Server to ClientExisting 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 ServerStore 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 Interactions between Java and C++ via Java Native Interface (JNI) or TwinPeaksInterface (JNI) or TwinPeaks

ECIC-1.64

CSE298

CSE300

CSE300

ADAM: Client/Wrapper ComponentsADAM: Client/Wrapper Components

CO

MM

UN

ICA

TIO

NC

OM

MU

NIC

AT

ION

CO

MM

UN

ICA

TIO

NC

OM

MU

NIC

AT

ION

Java

Des

ign

Cla

sses

/In

stan

ces Java D

esign C

lasses/Instan

ces

Java

Com

mu

nic

atio

nC

lass

es/I

nst

ance

sJava C

omm

un

icationC

lasses/Instan

ces

Java Client

GUIClasses

and Instances

Java Wrapper

TranslationJava to C++

LegacyCode

AdamC++

Server

May Not BeNeeded

Depends on Comm. Protocol

ECIC-1.65

CSE298

CSE300

CSE300

ADAM: Java to C++ WrapperADAM: Java to C++ Wrapper

Com

mu

nic

atio

n

Java Design Classes

and Instances

Tra

nsl

atio

nJa

va t

o C

++

Lib

rary

Fol

der C

lass Fold

er

C+

+ C

omm

on In

terfaceADAM

C++ Legacy Classes

and Instances

TwinPeaks

Legacy Application Wrapper

ECIC-1.66

CSE298

CSE300

CSE300

Communication Requirements and Communication Requirements and FunctionalitiesFunctionalities

Layers of Classes/Instances (Client vs. Server)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 Communications

Sockets (Current) Object Serialization (Current) CORBA/ORBs vs. RMI (Future)

ECIC-1.67

CSE298

CSE300

CSE300

ADAM: Socket CommunicationsADAM: Socket Communications

Potential Performance Issue: Multiple Layers of Translation

CO

MM

UN

ICA

TIO

NC

OM

MU

NIC

AT

ION

CO

MM

UN

ICA

TIO

NC

OM

MU

NIC

AT

ION

Java

Com

mu

nic

atio

nC

lass

es/I

nst

ance

sJava C

omm

un

icationC

lasses/Instan

ces

Java

Des

ign

Cla

sses

/In

stan

ces

Java Client

GUIClasses

and Instances

Java Design

Classes/In

stances

Java Wrapper

TranslationJava to C++

LegacyCode

AdamC++

Server

ECIC-1.68

CSE298

CSE300

CSE300

TwinPeaks Requirements and TwinPeaks Requirements and FunctionalitiesFunctionalities

Evaluated Feasibility of JNI Evaluated Feasibility of JNI Directly Access Native Layer Eliminates Platform Independence Difficult to Understand and Use

Exploring TwinPeaks ProductExploring 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.69

CSE298

CSE300

CSE300

ADAM: TwinPeaks ArchitectureADAM: TwinPeaks Architecture

Java Application

C++ DLL

Java/C++Bridge

Lib. Folder

GE

NE

RA

TE

GE

NE

RA

TE

C++Application

C++ HeaderFiles (.h)

C++ Implemen.Files (.c)

INPUT

Java InterfaceClass Folder(.java/.class)

Tw

inP

eak

s

ECIC-1.70

CSE298

CSE300

CSE300

Status of TwinPeaks EffortStatus of TwinPeaks Effort

Established TwinPeaks EnvironmentEstablished 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: 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.71

CSE298

CSE300

CSE300

Status of TwinPeaks EffortStatus of TwinPeaks Effort

As of January 15, 1998As 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 Written a Detailed Report Describing this Effort that will be Critical in Continuing this Workthat will be Critical in Continuing this Work

The Java/C++ Interface is Pivotal for Integrating The Java/C++ Interface is Pivotal for Integrating and Upgrading Legacy Software to Java and Upgrading Legacy Software to Java

ECIC-1.72

CSE298

CSE300

CSE300

Assessment of TwinPeaks ProductAssessment of TwinPeaks Product

PROsPROs 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.73

CSE298

CSE300

CSE300


CONSCONS 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.74

CSE298

CSE300

CSE300


CONsCONs 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: Conclusion: TwinPeaks is not a Stable Tool Falls Short of our Expectations Acceptance/Adoption for EC Applications is

Premature!!

ECIC-1.75

CSE298

CSE300

CSE300


C++ Legacy Applications Upgrade to C/S C++ Legacy Applications Upgrade to C/S Architectural Solution with Java Requires: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.76

CSE298

CSE300

CSE300


C++ Legacy Applications Upgrade to C/S C++ Legacy Applications Upgrade to C/S Architectural Solution with Java Requires: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.77

CSE298

CSE300

CSE300


C++ Legacy Applications Upgrade to C/S C++ Legacy Applications Upgrade to C/S Architectural Solution with Java Requires: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.78

CSE298

CSE300

CSE300


Integration of Java and C++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 ApplicationsApplicability to C Legacy Applications

Techniques Extensible to C Providing that Workable Native C++ Library Available

ECIC-1.79

CSE298

CSE300

CSE300


Utilization of our Efforts on ADAM as BlueprintUtilization 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 Conclusion: Significant Effort with Potential Long-Range Benefit of Common Java MediumLong-Range Benefit of Common Java Medium

ECIC-1.80

CSE298

CSE300

CSE300


PROsPROs Likely Applicable to C and C++ Component-Based, Organized Approach Greatly Facilitates Exchange of Information Solves the N x M Translation Problem

CONsCONs Additional Overhead Due to Translations Instability/Immaturity of TwinPeaks Complexity and Effort of Task Performance Degradation Unacceptable

Conclusion: Do Java, CORBA, etc., Benefits Conclusion: Do Java, CORBA, etc., Benefits Outweigh the Risks and Shortfalls?Outweigh the Risks and Shortfalls?

ECIC-1.81

CSE298

CSE300

CSE300

Concluding Remarks and DiscussionConcluding Remarks and Discussion

What are Keys Issues that Influence and Guide the What are Keys Issues that Influence and Guide the Integration Process for EC?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.

ECIC-1.82

CSE298

CSE300

CSE300

Concluding Remarks and DiscussionConcluding Remarks and Discussion

What are Keys Issues that Influence and Guide the What are Keys Issues that Influence and Guide the Integration Process for EC?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.83

CSE298

CSE300

CSE300

Java Beans andJava Beans andEnterprise Java BeansEnterprise Java Beans

Paul C. BarrThe Mitre Corporation

Eatontown NJ

[email protected]

Kimble Cheron,Prof. Steven A. Demurjian,

and Mitch SabaComputer Science & Engr. Dept.

[email protected]://www.engr.uconn.edu/

~steve(860) 486 - 4818

ECIC-1.84

CSE298

CSE300

CSE300

Changing PerspectivesChanging Perspectives

Computers are Guilty of Creating More Disorder Computers are Guilty of Creating More Disorder then Simplicitythen Simplicity

Current Software Systems are RelicsCurrent 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 MoldDesigner’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?What is Available to Assist in Changing Times?

ECIC-1.85

CSE298

CSE300

CSE300

ComponentsComponents

Reusable Software Building BlocksReusable Software Building Blocks Pre-Constructed from Encapsulated Application Pre-Constructed from Encapsulated Application

CodeCode Easily Combined with Other Components Seamlessly Merged with Custom Code Rapid Prototyping of Complete Applicaiton

What is a Component?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.86

CSE298

CSE300

CSE300

OverviewOverview

A First Look at Java BeansA First Look at Java Beans What are They? How are They Utilized?

Enterprise Java BeansEnterprise 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 EJBMulti-Tiered Architecture and EJB Tiered Development for Extensibility Comparisons of Approaches

Java Blend for Database InteroperabilityJava Blend for Database Interoperability

ECIC-1.87

CSE298

CSE300

CSE300

Java BeansJava Beans

Extends "Write Once, Run Anywhere (WORA)Extends "Write Once, Run Anywhere (WORA)TMTM" " to Include "Reuse Everywhere”to Include "Reuse Everywhere”

What is a Bean?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.88

CSE298

CSE300

CSE300

Java BeansJava Beans

Bean vs. ComponentBean vs. Component Source Code Inaccessible Customizable to Suit Application Needs via

External Properties Powerful Means of Reuse

ExamplesExamples 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 Properties Can be Very Complex and Offer

Significant Power to Application BuildersSignificant Power to Application Builders

ECIC-1.89

CSE298

CSE300

CSE300

What are Enterprise Java Beans ?What are Enterprise Java Beans ?

Expansion of Java Beans (Client-side) to Support Expansion of Java Beans (Client-side) to Support Server Side Reusable ComponentsServer Side Reusable Components Server Components Run on Application Server EJB Integral Part of Java Technology

Component Architecture for Distributed Systems 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 WareFramework for Creating Middle Ware Integration of “New” and “Old” Technologies RMI, IIOP, CORBA, RPC, Active X, etc.

ECIC-1.90

CSE298

CSE300

CSE300

Designer and Developer Roles in Designer and Developer Roles in Enterprise Java Beans (EJB)Enterprise Java Beans (EJB)

Towards Towards “Highly Scalable, Highly Available, “Highly Scalable, Highly Available, Highly Reliable, Highly Secure, Transaction Highly Reliable, Highly Secure, Transaction Distributed Applications”Distributed Applications”

Enterprise Bean Provider Enterprise Bean Provider Creates and Sells EJBs

Application Assembler Application Assembler Uses EJBs to Build an Application

EJB Server Provider EJB Server Provider Creates and Sells EJB Server

EJB Container Provider EJB Container Provider Creates and Sells EJB Containers Server Provider Will Likely Provide Containers

ECIC-1.91

CSE298

CSE300

CSE300

EJB Roles & DeploymentEJB Roles & Deployment

ECIC-1.92

CSE298

CSE300

CSE300

Utilizing EJB TechnologyUtilizing EJB Technology

ECIC-1.93

CSE298

CSE300

CSE300

The EJB ArchitectureThe EJB Architecture

EJB Servers: Analogous to CORBA ORB EJB Servers: Analogous to CORBA ORB Server Software Provides Naming and Transaction Services Makes Containers Visible

EJB Containers: Interface Between EJB Bean and EJB Containers: Interface Between EJB Bean and Outside World Outside World Client Never Accesses Bean Directly Access via Container-Generated Methods These Methods Then Call the Bean’s Methods

EJB Clients EJB Clients Locate EJB Containers Via JNDI Make Use of EJB Beans

Enterprise Java Beans - Discussed ShortlyEnterprise Java Beans - Discussed Shortly

ECIC-1.94

CSE298

CSE300

CSE300

EJB ContainerEJB Container

ECIC-1.95

CSE298

CSE300

CSE300

Enterprise Java APIsEnterprise Java APIs

ECIC-1.96

CSE298

CSE300

CSE300

Enterprise Java Beans Enterprise Java Beans Session BeansSession Beans

Associated With a Particular ClientAssociated With a Particular Client Performs Operations on Behalf of ClientPerforms Operations on Behalf of Client

Accessing a Database Performing Calculations

Created and Destroyed by a Client Created and Destroyed by a Client Can be Transactional - But, Do Not Survive Can be Transactional - But, Do Not Survive

System ShutdownSystem Shutdown Can be Stateless or Maintain Conventional State Can be Stateless or Maintain Conventional State

Across Methods and TransactionsAcross Methods and Transactions Must Manage Own Persistent DataMust Manage Own Persistent Data

ECIC-1.97

CSE298

CSE300

CSE300

Enterprise Java Beans Enterprise Java Beans Entity BeansEntity Beans

Object Representation of Persistent Data Object Representation of Persistent Data Maintained in Permanent Store (DatabaseMaintained in Permanent Store (Database

Identifiable by Primary KeyIdentifiable by Primary Key Shared by Multiple Clients Shared by Multiple Clients Persist Across Multiple Invocations Persist Across Multiple Invocations Survive System ShutdownSurvive System Shutdown Created byCreated by

Inserting Data into Database Creating an Object Instance

ECIC-1.98

CSE298

CSE300

CSE300

Model for PersistenceModel for PersistencePassivation/ActivationPassivation/Activation

Programmatic Model for Managing Persistent Programmatic Model for Managing Persistent ObjectsObjects

EJB Server has the Right to Manage its Working EJB Server has the Right to Manage its Working Set Set

Passivation Passivation Saves State of a Bean to Persistent Storage Then Swaps Bean Out

Activation Activation Restores State of a Bean From Persistent Storage,Then Swaps Bean in

Applies to Both Session and Entity BeansApplies to Both Session and Entity Beans

ECIC-1.99

CSE298

CSE300

CSE300

Stateless vs. Stateful Session BeansStateless vs. Stateful Session Beans

Stateless Stateless No Internal State Do Not Need to Be "Pass-ivated" Can Be Pooled to Service Multiple Clients

Stateful Stateful Possess Internal State Need to Handle Passivation/Activation One Per Client

ECIC-1.100

CSE298

CSE300

CSE300

Entity Bean PersistenceEntity Bean Persistence

Container-Managed Container-Managed Container is Responsible for Saving State In Deployment Descriptor, Specify Container-

Managed Fields Persistence Independent of Data Source

Bean-Managed 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.101

CSE298

CSE300

CSE300

Deploying EJBsDeploying EJBs

EJBs Deployed As .SER Files: EJBs Deployed As .SER Files: Serialized InstanceSerialized Instance Manifest File Used to List EJBs Manifest File Used to List EJBs Must Also Provide a “Deployment Descriptor” Must Also Provide a “Deployment Descriptor” Sample Entry Sample Entry

Name: paul.RestaurantDeployment.ser Enterprise-Bean: True

“ “Name” Line Name” Line Describes a Serialized Deployment Descriptor

“ “Enterprise-Bean” Line Enterprise-Bean” Line Indicates Whether the Entry Should Be Treated

as an EJB (Not All Entries Need to Be EJBs)

ECIC-1.102

CSE298

CSE300

CSE300

Who’s Announced EJB Support?Who’s Announced EJB Support?

WebLogic WebLogic IBM IBM Oracle Oracle GemStone GemStone BEA BEA Borland Borland Netscape Netscape LotusLotus

Forte Forte Progress Progress Novell Novell Novera Novera Borland Borland Informix Informix IONA IONA More...More...

ECIC-1.103

CSE298

CSE300

CSE300

Typical Development and Deployment Typical Development and Deployment ScenarioScenario

EJB Server Provider EJB Server Provider Creates and Sells an EJB Server Provides EJB Containers That Will Run on

These Servers EJB ProvidersEJB Providers

Individuals Responsible for Developing the EJBs

Provide “Tools” and “Components” for Down-Stream Usage

Application AssemblersApplication Assemblers Individuals that Utilize Pre-Built EJBs to

Construct Their Domain-Specific Applications Utilize “State-of-Art-Tools” for EJB and JB

ECIC-1.104

CSE298

CSE300

CSE300

EJB Component-Based ArchitectureEJB Component-Based Architecture

EJB Client

EJB Container

EJB Server

Enterprise Java Bean

Invoke EJB Container Methods

Invoke EJB Methods

ECIC-1.105

CSE298

CSE300

CSE300

Client-Server Component ModelClient-Server Component Model

ECIC-1.106

CSE298

CSE300

CSE300

Two-Tier, Three-Tier, Four-Tier Two-Tier, Three-Tier, Four-Tier Example ArchitecturesExample Architectures

From: http://java.sun.com/javaone/javaone98/sessions/T400/index.html

ECIC-1.107

CSE298

CSE300

CSE300

Wombat SecuritiesWombat Securities

Web Access to Brokerage Accounts Web Access to Brokerage Accounts Only HTML Browser Required on Front End Only HTML Browser Required on Front End "Brokerbean" EJB Provides Business Logic "Brokerbean" EJB Provides Business Logic Login, Query, Trade Servlets Call Brokerbean Login, Query, Trade Servlets Call Brokerbean Use JNDI to Find EJBs, RMI to Invoke ThemUse JNDI to Find EJBs, RMI to Invoke Them Order and History Records from Java Blend Order and History Records from Java Blend

Product Product Records Mapped to Oracle Tables, JDBC Calls Records Mapped to Oracle Tables, JDBC Calls

ECIC-1.108

CSE298

CSE300

CSE300

Four-Tier Architecture ExampleFour-Tier Architecture Example

ECIC-1.109

CSE298

CSE300

CSE300

Nocturnal Aviation, Inc.Nocturnal Aviation, Inc.

Passenger Check-in for Regional Airline Passenger Check-in for Regional Airline Local Database for Seating on Today's Flights Local Database for Seating on Today's Flights Clients Invoke EJBs at Local Site Through RMI Clients Invoke EJBs at Local Site Through RMI EJBs Update Database and Queue Updates EJBs Update Database and Queue Updates JMS Queues Updates to Legacy System JMS Queues Updates to Legacy System DBC API Used to Access Local Database DBC API Used to Access Local Database JTS Synchs Remote Queue With Local UpdatesJTS Synchs Remote Queue With Local Updates

ECIC-1.110

CSE298

CSE300

CSE300

Three-Tier ExampleThree-Tier Example

ECIC-1.111

CSE298

CSE300

CSE300

Santa Cruz WidgetsSanta Cruz Widgets

Small Manufacturer Previously on C++ Small Manufacturer Previously on C++ New Order Entry, Inventory, and Invoicing New Order Entry, Inventory, and Invoicing

Applications in Java Programming Language Applications in Java Programming Language Existing Customer and Order Database Existing Customer and Order Database Most of Business Logic in Stored Procedures Most of Business Logic in Stored Procedures Tool-generated GUI Forms for Java ObjectsTool-generated GUI Forms for Java Objects Located Company on Web Using Widgets and Tcl, Located Company on Web Using Widgets and Tcl,

but Not Widgets and Javabut Not Widgets and Java

ECIC-1.112

CSE298

CSE300

CSE300

Santa Cruz Widgets (2-tier) Santa Cruz Widgets (2-tier)

ECIC-1.113

CSE298

CSE300

CSE300

Architecture ComparisonsArchitecture Comparisons

Two-tier Through JDBC API: Simplest Two-tier Through JDBC API: Simplest Multi-tier: Separate Business Logic, Protect Multi-tier: Separate Business Logic, Protect

Database Integrity, More Scaleable Database Integrity, More Scaleable JMS Queues Vs Synchronous (RMI or IDL): JMS Queues Vs Synchronous (RMI or IDL):

Availability, Response Time, Decoupling JMS Publish & Subscribe: Off-line Notification JMS Publish & Subscribe: Off-line Notification

RMI IIOP Vs JRMP Vs Java IDL: RMI IIOP Vs JRMP Vs Java IDL: Standard Cross-language Calls or Full Java

Functionality JTS: Distributed Integrity, Lockstep ActionsJTS: Distributed Integrity, Lockstep Actions

ECIC-1.114

CSE298

CSE300

CSE300

Further API ComparisonsFurther API Comparisons

Servlets: Simplifies HTML, Connections, Web Servlets: Simplifies HTML, Connections, Web Front-Ending Legacy SystemsFront-Ending Legacy Systems

EJBs: Simplifies Components, Scalability, EJBs: Simplifies Components, Scalability, Transactions, Multi-threading, Security, StateTransactions, Multi-threading, Security, State

JDBC Vs ODMG Vs SQLJ API: JDBC Vs ODMG Vs SQLJ API: Programming Simplicity, Portability, SQL

Knowledge JNDI: Standardized Name Service Access JNDI: Standardized Name Service Access Enterprise Java APIs vs. Proprietary: Enterprise Java APIs vs. Proprietary:

Multi-Platform, Multiple Providers

ECIC-1.115

CSE298

CSE300

CSE300

Summary & Key MessagesSummary & Key Messages

Enterprise Java APIs: EJB, JNDI, Java IDL, RMI, Enterprise Java APIs: EJB, JNDI, Java IDL, RMI, JDBC, ODMG, SQLJ, JMS, JTS, JMAPI, Servlets JDBC, ODMG, SQLJ, JMS, JTS, JMAPI, Servlets

Wide Variety of Architectural Alternatives: Wide Variety of Architectural Alternatives: Synchronous/Asynchronous, Multi-Tier,

Transactional, HTTP/JRMP/IIOP Benefits: Benefits:

WORA Portability Multiple Vendors Legacy Connectivity Java Programming Language Productivity

ECIC-1.116

CSE298

CSE300

CSE300

EJB RoadmapEJB Roadmap

API Specification Complete ProductsEJB JavaSoft 1.0Q1 See PartnersJNDI JavaSoft 1.0 done Download SPJIDL OMG 1.0 Q2 JDK 1.2RMI JavaSoft 1.0 done JDK 1.1JDBC JavaSoft 2.0 Q2 JDK 1.2 PartnerODMG Consortium 2.0 done JavaBlendSQLJ Consortium 1.0 Q2 See PartnersJMS JavaSoft 1.0 Q2 See PartnersJTS OMG 1.0 done PartnersJMAPI JavaSoft 1.0 Q2 See PartnersSevlets JavaSoft 1.1 done Java Web Server

ECIC-1.117

CSE298

CSE300

CSE300

What Is the Java Blend Product?What Is the Java Blend Product?

Product That Integrates Java Programming Product That Integrates Java Programming Language Objects With Enterprise Data Language Objects With Enterprise Data

Provides a Single Object Model Based on Java Provides a Single Object Model Based on Java Programming Language ClassesProgramming 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 Result of Joint Development by the Javasoft

Division, Baan and Tech@spree Division, Baan and Tech@spree

ECIC-1.118

CSE298

CSE300

CSE300

JavaBlend ApplicationsJavaBlend Applications

JavaBlend Software Provides Mapping Capability JavaBlend Software Provides Mapping Capability Between Database Tables and Java Application Between Database Tables and Java Application ClassesClasses

Programmer Deals Only With Java Programming Programmer Deals Only With Java Programming Language Objects, and Does Not Need to Know Language Objects, and Does Not Need to Know SQL or Database RepresentationSQL or Database Representation

ECIC-1.119

CSE298

CSE300

CSE300

Java Blend ComponentsJava Blend Components

Flexible Development Tool for Automatic Flexible Development Tool for Automatic Bi-Directional MappingBi-Directional Mapping Objects to Relational Relational to Objects

Powerful Runtime EnvironmentPowerful Runtime Environment Transaction Management System Query Processor Cache Management System

ECIC-1.120

CSE298

CSE300

CSE300

Java Blend Runtime ArchitectureJava Blend Runtime Architecture

ECIC-1.121

CSE298

CSE300

CSE300

Java Blend Software and Enterprise Java Blend Software and Enterprise JavaBeans Technology JavaBeans Technology

EJB Technology Provides Scaleable Component EJB Technology Provides Scaleable Component Architecture for Business ApplicationsArchitecture for Business Applications

Java Blend Product Provides Transparent Java Blend Product Provides Transparent Persistence for Enterprise Javabeans TechnologyPersistence 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.122

CSE298

CSE300

CSE300

Concluding RemarksConcluding Remarks Enterprise Computing/Interoperability

Technologies Continue to Emerge and MatureTechnologies Continue to Emerge and Mature Complex Problem for Companies and Complex Problem for Companies and

OrganizationsOrganizations 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!Future Difficult to Predict!

enterprise computing and interoperability

Documents