PLM Standards Modelling for Enterprise Interoperability: A ...
Enterprise Computing and Interoperability
description
Transcript of 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
ImplementationSkeletons
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
ImplementationSkeletons
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 Implementation
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
Object Implementation
Single Process
Singlemethodinvocation
Object Implementation
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
Object Implementation
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
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
PushSupplierPushSupplier
PushSupplierPushSupplier
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
(from Common_Interface)
<<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
(from Common_Interface)
<<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
PushSupplierPushSupplier
PushSupplierPushSupplier
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( )
2: notification(...)
4: getVarLengthStruct( )
3: notification(...)
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
PushSupplierPushSupplier
PushSupplierPushSupplier
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 Application CodeJava Application Code
JAVA NETWORK WRAPPERJAVA NETWORK WRAPPER
Mapping ClassesMapping Classes
NATIVE LAYERNATIVE LAYER
JAVA LAYERJAVA LAYER
Native Functions that Native Functions that Map to COTS ApplMap to COTS Appl
Java ClientJava Client Java ClientJava Client
Java Application CodeJava Application Code
JAVA NETWORK WRAPPERJAVA NETWORK WRAPPER
Mapping ClassesMapping Classes
NATIVE LAYERNATIVE LAYER
JAVA LAYERJAVA LAYER
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
Assessment of TwinPeaks ProductAssessment of TwinPeaks Product
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
Assessment of TwinPeaks ProductAssessment of TwinPeaks Product
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
Architectural Alternatives & FrameworkArchitectural Alternatives & Framework
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
Architectural Alternatives & FrameworkArchitectural Alternatives & Framework
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
Architectural Alternatives & FrameworkArchitectural Alternatives & Framework
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
Architectural Alternatives & FrameworkArchitectural Alternatives & Framework
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
Architectural Alternatives & FrameworkArchitectural Alternatives & Framework
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
Architectural Alternatives & FrameworkArchitectural Alternatives & Framework
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
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!