Transcript SUlecture.tom

Introduction to
Distributed Component Models
Tomasz Haupt
Overview
•
•
•
•
•
What is a software component?
Two examples: AWT and JavaBeans
Distributed objects: CORBA
Distributed components: EJB
Academic example: WebFlow
What is a component?
• Very intuitive, but often vaguely defined
• A semiconductor chip is a component
The chip vendor publishes manuals that tell developers the functionality of each pin
A0-A16
D0-D8
ACK
I/O Address bus
I/O Data bus
O Acknowledge: Accepted when low
Building complex systems
• Hardware system integrators connect pins of chips together
according to their functions to build complex electronic
devices such as computers.
Component
one
Component
two
• Pins functionality defines behavior of the chip.
• Pins functionality is standardized to match functionality of
the board (and take advantage of common services).
Software components
• The software component model takes a very similar
approach:
– the “pins” of software components are called interfaces
– an interface is a set of methods that the component implements
Component
one
component’s interface
Component
two
methods
– software integrators connects components according to the
descriptions of the methods within the interface.
Software components (2)
• Component technology is still young, and there isn’t even
agreement on the definition of its most important element the component.
• “a component is a software module that publishes or
registers its interfaces”, a definition by P. Harmon, Component
Development Strategy newsletter (1998).
• Note: a component does not have to be an object!
An object can be implemented in any language as long as
all the methods of its interface are implemented.
• Often COM (Microsoft) components are not objects.
• For Java developer, a component is a specialized object.
Component wiring
Component
one
Component
two
• The traditional programming model is caller-driven (application calls
methods of a component’s interface, information is pulled from the
callee as needed). Component never calls back.
• In the component programming model, connecting components may
call each other (connection-oriented programming).
• The components can interacts with each other through event
notification (a component pushes information to another component as
some event arises). This enables wiring components at runtime.
Pragmatic definition
• Software Components:
– predictable behavior: implement a common
interface
– embedded in a framework that provides
common services (events, persistence, security,
transactions,…)
– developer implements only business logic
Examples of component models
• Before discussing distributed components
let us see our definition at work:
– AWT components
– JavaBeans
AWT Component model:
common behavior
Java.lang.Object
everything in Java is an object
Java.awt.Component
Start
Save
Submit
Exit
This is a text area. The user can display and
modify a text
specialized object; knows its position
on the screen, how to paint itself,
knows its parent, fires events
Java.awt.Button
Java.awt.Canvas
Java.awt.TextArea
Java.awt. Container
specialized component type
that can contain other AWT
components; methods: add, remove,
getComponents
Java.awt.Panel
Java.awt.Window
Java.awt.Frame
AWT Component model:
common behavior
Java.lang.Object
everything in Java is an object
Java.awt.Component
Predictable behavior
Framework:
event mechanism
specialized object; knows its position
on the screen, how to paint itself,
knows its parent, fires events
Java.awt.Button
Java.awt.Canvas
Java.awt.TextArea
Java.awt. Container
specialized component type
that can contain other AWT
components; methods: add, remove,
getComponents
Java.awt.Panel
Java.awt.Window
Java.awt.Frame
JavaBeans: Power of the container
• Generic Java objects that follow the JavaBeans
coding conventions. This allows introspection.
Thus no specific “common interface”.
• Container (environment in which beans live
– BeanBox, JSP, Java Development Environment)
– discovers bean properties, methods and events
– properties editors (bean customization)
– event based communication
– persistence (object serialization)
• Take an off-shell bean and use it in your application
Distributed objects
• What if the objects live in different address
spaces?
Class A {
B b =new B();
Object c = b.m(); }
?
Class B {
Object m() {…;
return Object o}; }
• Standard Java method invocation will not work.
We need a remote method invocation (RMI)
mechanism.
Distributed Objects (2)
Class A {
B b =new B();
Object c = b.m(); }
CLIENT
SERVER
Class B {
Object m() {…;
return Object o}; }
interface B {
Object m() ; }
Class A {
B b =new b();
Object c = b.m(); }
Class Bimpl implements B {
Object m() {…;
return Object o};
Class StubB implements B {
Object m() {
send request;
return Object o;}
}
Class skeletonB {
receive request;
Object o = B.m();
send(o);
}
Distributed Objects (3): CORBA
ORB:
object request broker
Class StubB implements B {
Object m() {
send request;
return Object o;}
}
Vendor provided classes
interface B {
Object m() ; }
IIOP
Class skeletonB {
receive request;
Object o = B.m();
send(o);}
INTERNET INTER-ORB PROTOCOL
Client
Class A {
B b =new B();
Object c = b.m(); }
Language independent IDL
(Interface Definition Language)
Server
Class Bimpl implements B {
Object m() {…;
return Object o};
CORBA IDL
• Language independent, totally declarative
language to define object interface (contract
with a potential client)
• The IDL grammar is a subset of C++ with
additional keywords to support distributed
concepts
• Can be mapped to many languages,
including Java
BTW: Java RMI does not need IDL; DCOM uses binary interfaces
package
Java
Example IDL
Module MyAnimals {
String
interface Dog:Animal {
Java
attribute integer age;
exception NotInterested {string explanation};
int
Java
void Bark(in long how_long) raises (NotInterested);
void Sit(in string where) raises(NotInterested);
}
interface Cat:Animal{
string saySomething();
}
}
Developing CORBA applications
Create IDL
definitions
Developer’s
Task
IDL
precompilation
Extend Skeleton or
implement interface
Object
Implementation
Compilation
Interface
Repository
Client
Stubs
Client
Server
Stubs
Object Adapter
Object
Implementations
Server
Implementation
Repository
Dynamic CORBA
Responsible for life cycle of server objects
Dynamic Stub Invocation (DSI) and Dynamic Skeleton Invocation (DII)
allows constructing applications at runtime, without prior knowledge
of stubs and skeletons.
Figure taken from: R. Orfali, D. Harkey, J. Edwards, “The Essential Distributed Object Survival Guide”,John Wiley & Sons
Yes, you have seen this slide!
Distributed Objects (3): CORBA
ORB:
object request broker
Class StubB implements B {
Object m() {
send request;
return Object o;}
}
Client
Vendor provided classes
interface B {
Object m() ; }
IIOP
Class skeletonB {
receive request;
Object o = B.m();
send(o);}
Language independent IDL
(Interface Definition Language)
Class A {
B
new B();
B b = getObjectReference(…);
Object c = b.m(); }
Server
Class Bimpl implements B {
Object m() {…;
return Object o};
How to get an object reference
• IOR: interoperable object reference
• part of IIOP definition
• includes all information needed to invoke
• created when the object is created
– orb.object_to_string(o);
– can be stored in a file (make sure that is not stalled!)
– maintained by the CORBA naming service
Simple Client
Public class Client {
public static void main(String args[]) {
ORB orb = ORB.init(args, new java.util.Properties(...));
Instantiate ORB
(vendor specific)
String masterURL = args[0];
String ref=getIORFromURL(masterURL);
Read IOR from
a web server
org.omg.CORBA.Object obj=orb.string_to_object(ref);
MyRemoteObject mro=MyRemoteObjectHelper.narrow(obj);
Deserialize IOR
mro.method();
}
Generated by JIDL
Ready to use
CORBA: the Big Picture
Figure taken from: R. Orfali, D. Harkey, J. Edwards, “The Essential Distributed Object Survival Guide”,John Wiley & Sons
Distributed Component Models
•
•
•
•
•
Hide implementation details
Remove vendor dependencies
Bring power of a container
Focus on business logic
Enable development of third-party
interoperable components
Enterprise JavaBeans
• Java objects that implement EJB interfaces
• Container that provides environment for beans
– implements common object services such as
life cycle, security, naming, persistence,
communication, transaction processing,
resource pooling, …
– provides tools or bean development such as idl
compiler
Enterprise JavaBeans (2)
CORBA enthusiast’s view
Off-shell Beans
Custom Beans
EJB Container
Of course, can be implemented in pure Java (RMI, JNDS,…)
Enterprise JavaBeans (3)
server
client
home interface
EJB container
home interface
EJB home stub
EJB home
remote interface
remote interface
EJB remote stub
EJB object
EJB bean implements only business logic
EJB bean
Enterprise JavaBeans (4)
• Home interface:
– provides methods for a client to create, locate,
and destroy EJB objects that it uses
• Remote interface:
– defines business methods of the bean
Types of Components
• Sessions beans
– provide business logic to a client, is accessed
by a single client at a time and is nonpersistent.
• Entity beans
– representation of persistent data, it can be
accessed by multiple clients concurrently.
• Note:
– COM: only session components
– CCM: services, sessions, processes and entities
WebFlow Component Model
• Developed at NPAC, Syracuse University
– most of coding done by Erol Akarsu
• Used to implement the Middle Tier of
computational Web portals
• Build on top of CORBA
• Exploits both common behavior and power
of the container
Compare AWT and WebFlow
Java.lang.Object
everything in Java is an object
Java.awt.Component
specialized object; knows its position
on the screen, how to paint itself,
knows its parent, fires events
Java.awt.Button
Java.awt.Canvas
Java.awt.TextArea
Java.awt. Container
specialized component type
that can contain other AWT
components; methods: add, remove,
getComponents
Java.awt.Panel
Java.awt.Window
Java.awt.Frame
Org.omg.CORBA.Object
WebFlow Component
specialized CORBA object
implements BeanContextChild
WebFlow Module
WebFlowContext (a Container)
can contain other WebFlow components
responsible for life cycle,
persistency, communications
WebFlow Distributed Applications
Application A
Host B
Host A
Application C
Context B
Host C
Module A
Module B
Host D
Context C
Context D
Module C1
Module C2
Module D
WebFlow component model
• A WebFlow component is a CORBA object implemented in Java
• A WebFlowContext object implements an extended BeanContext
interface, maintains a persistent state, controls its children life-cycle,
and is responsible for inter-JVM communications through a custom
event model. The master (“root”) context maintains a hierarchy of
proxy objects to facilitate communication with clients implemented as
Java applets without violating the sandbox restrictions.
Acts both as a CONTAINER and an ENTITY component.
• A WebFlow Module implements BeanContextChild interface, is
stateless (more precisely, it maintains a conversational state), and has
access to all data maintained by its parent context.
Acts as a SESSION component.
WebFlow Contexts and Modules (2)
User Context
Problem Context
Session Context
Org.omg.CORBA.Object
WebFlow Component
specialized CORBA object
implements BeanContextChild
WebFlow Module
WebFlowContext (a Container)
can contain other WebFlow components
responsible for life cycle,
persistency, communications
Job context
code descriptor, job id,
date submitted, completed,
input file(s), output file(s)
A module in a context extends the
context functionality
Middle Tier Components
Task Specification
PSE
support
Component Container
User Context
Credentials
(proxy)
profile
context
lifecycle
XML
parser
data flow
manager
Multidisciplinary
task control
Session Context
Job
Job
object
object
Job
object
File
access &
transfer
access
control
Information
services
resource
broker
batch
script
generator
job
control
Resource Specification
data
analysis
NetSolve
Linear Algebra
proxy
archivization
database
access
WebFlow Events
• WebFlow components (modules) are developed
independently of each other.
• They can interact with each other through WebFlow
events. (They can use remote invocation, but it requires the
caller to have reference to the target module, which
violates the WebFlow “module independence” rule).
• There is only one type of WebFlow events. An event is an
(self-describing) object that encapsulates data to be
transferred from one module to another.
• Each module can serve as a sink.
• Event sources and sinks are associated at run time.
Client
WebFlow Events
A
B
Event
Adapter
uses
Context 1
CORBA
DSI,DII
Event e
A
B
Method m
Dynamic
Interfaces
Module A does not care who is
expecting the event; method fire Event
invokes a method of its parent context
Context 2
Method m is a public method:
anyone can invoke it, including
the Event Adapter of Context 1.
No protection against misuse!
Summary
• A pragmatic definition of software
components:
– predictable behavior: implement a common interface
– embedded in a framework that provides common
services (events, persistence, security, transactions,…)
– developer implements only business logic
Summary (2)
• Best known distributed component models:
– DCOM (Microsoft)
– Enterprise JavaBeans (Sun Microsystems)
– CCM: CORBA Component Model (OMG)
• Academic example:
– WebFlow system
End
Distributed Objects are less secure
• can play both client and server
–
in client/server you trust the server, but not the clients
• evolve continually
–
objects delegate parts of their implementation to the other objects (also dynamically composed
at runtime). Because of subclassing, the implementation of an object may change over time
• interactions are not well defined
–
because of encapsulation, you cannot understand all the interactions between objects
• are polymorphic (ideal for Trojan horses!)
• can scale without limit
–
how do you manage the access right to millions of servers?
• are very dynamic
CORBA security is built into ORB
Client
Server
Object
Adapter
ORB
Credentials
Authentication Encryption
Encryption
Audit
Secure Communications
Authorization
Authentication
• A principal is authenticated once by ORB and
given a set of credentials, including one or more
roles, privileges, and an authenticated ID.
• An authenticated ID is automatically propagated
by a secure ORB; it is part of the caller context
authenticate
Principal
Client
Server
Credentials
Current
set_credentials
get_attributes
IIOP
• No delegation
– The intermediary uses its own credentials
• Simple delegation
– The intermediary impersonates the client
• Composite delegation
– The intermediary uses both
Client
Target
Client
Target
Client
Client
Target
Privilege Delegation
Target
Object
Secure CORBA connection
client
Instantiate ORB
(creates credentials object)
server
get IOR and deserialize
(server authentication)
make request
(ORB appends the current
and encrypts)
=binding=
receive request
(decryption
client authentication)
(client authorization)