Transcript Design of Secure Multi-Tier Web

ZEN
Towards Highly Configurable Realtime Object Request Brokers
Raymond Klefstad, Douglas C. Schmidt, and Carlos O'Ryan
University of California at Irvine
Presented by: S. M. Sadjadi
Software Engineering and Networking Systems Laboratory
Department of Computer Science and Engineering
Michigan State University
www.cse.msu.edu/sens
Fifth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing.
Acknowledgement:
Douglas C. Schmidt
 Raymond Klefstad
 Carlos O'Ryan
 Other DOC members

Backgroud:

The purpose:
– To support advanced R&D on distributed object computing middleware
using an open source software development model.

The DOC Group is a distributed research consortium
consisting of:
–
–
–
–
Vanderbilt University in Nashville, Tennessee. (southern office)
Washington University in St. Louis, Missouri. (midwest office)
University of California in Irvine, California. (west coast office)
Members at:




Siemens ZT in Munich, Germany.
Bell Labs in Murray Hill, New Jersey.
OCI in St. Louis, MO.
…
Agenda:



Motivation
ZEN Solution
Background
– CORBA and Real-Time CORBA
– Java and Real-Time Java





ORB Generations
Micro-ORB vs. Monolithic-ORB
Virtual Component Pattern
ZEN Architecture
Concluding Remarks
Motivations:

ZEN Project Goal:
– Supporting development of distributed, real-time, and embedded
(DRE) systems.

DRE systems:
– “The right answer delivered too late becomes the wrong answer.”
[ZEN]
– Examples:





Telecommunication Networks (e.g., wireless phone services).
Tele-medicine (e.g., remote surgery).
Manufacturing Process Automation (e.g., hot rolling mills).
Defense Applications (e.g., avionics mission computing systems).
DRE Challenging Requirements:
– As Distributed Systems:

managing connections and message transfer.
– As Real-Time Systems:

predictability and end-to-end resource control.
– As Embedded Systems:

resource limitations.
ZEN’s Solution:

Integration of the Best Aspects of:
– CORBA:

Standards-based distributed applications
– Real-time CORBA:

CORBA with Real-time QoS capabilities
– Java:

Simple, less error-prone, large user-base
– Real-time Java:


Real-time support
Pattern-Oriented Programming:
– Virtual Component Pattern:



Factory Method Pattern
Proxy Pattern
Component Configurator Pattern
Agenda:



Motivation
ZEN Solution
Background
– CORBA and Real-Time CORBA
– Java and Real-Time Java





ORB Generations
Micro-ORB vs. Monolithic-ORB
Virtual Component Pattern
ZEN Architecture
Concluding Remarks
OMG Reference Model Architecture [CORBA-Overview]

Object Services

– (a.k.a, CORBA Services)
– Domain-independent services.
– Naming Service and Trading Service.

Common Services
– (a.k.a, Common Facilities and Horizontal
Facilities)

– are less oriented towards end-user
applications.
– Distributed Document Component
Facility (DDCF).
:
Domain Services
– (a.k.a, Domain Interfaces and Vertical
Facilities)
– are more oriented towards specific app
domains.
– Product Data Management (PDM)
Enablers for the manufacturing domain.
Application Services
– (a.k.a, Application Interfaces and
Application Objects)
– are services developed specifically for a
given application.
CORBA ORB Architecture [CORBA-Overview]:

Object
–

is a running program (or process) entity.
is a program entity that invokes an
operation.
Object Request Broker (ORB)
–



provides transparent comm. Mechanisms.
ORB Interface
–
decouples an application from an ORB impl.
allows generating dynamic requests.
Dynamic Skeleton Interface (DSI)
–

the ``glue'' between the client and server
applications, respectively, and the ORB.
Dynamic Invocation Interface (DII)
–
Client
–

An implementation programming language
entity.
CORBA IDL stubs and skeletons
–
Server
–

A CORBA programming entity.
Servant
–


server side's analogue to DII.
Object Adapter
–
–
–
assists the ORB with delivering requests.
associates object with the ORB.
can be specialized to provide support for
certain object implementation styles.
Real-Time CORBA [ZEN]:

Features:
– Adds QoS control capabilities to
regular CORBA.
– Improve application predictability by
bounding priority inversion
– Manage system resources end-to-end.



Processor resources
Communication resources
Memory resources

Shortcommings:
– Focuses primarily on “fixed-priority”
real-time applications, where priorities
are assigned statically.
– Steep learning curve:

Cause by the complex C++ mapping.
– Run-time and memory footprint
overhead
Java:

Features:
–
–
–
–
–
–
–

Real-Time Java:

Simple
Growing programmer
Powerful and standard library
JVM
Strong typing
Portable concurrency
Lazy class loading
– New memory management
model



Non-determinism
Non-predictable
Instead of garbage collector
– Access to physical memory
– A higher resolution time
granularity
– Stronger guarantees on
thread semantics.
Shortcomings:
– No fine grain memory
management
– No precise thread priority
– Garbage collector
Features:


The highest priority thread
will always run
Shortcomings:
– No facilities for distributed
applications
Agenda:



Motivation
ZEN Solution
Background
– CORBA and Real-Time CORBA
– Java and Real-Time Java





ORB Generations
Micro-ORB vs. Monolithic-ORB
Virtual Component Pattern
ZEN Architecture
Concluding Remarks
ORB Generations and ZEN Design Process:
1. Static Monolithic ORB:
–
–



Excessive memory footprint
Growth of footprint with each extension


–
5.

–
–

Reduced footprint


Hard to code the application
–
3. Dynamic Micro-ORB:
–
–
–
Only a small ORB kernel is loaded
Component Configurator and Virtual Component
Advantages:



–
Source code is generated using the
configuration description for a new
custom ORB
Advantages:
Disadvantages:

Reduced footprint
Dynamic reconfiguration
Easier to code the application
Disadvantages:


Potential jitter
May not be suitable for some systems
Fast
Small footprint
Easy to code
Disadvantages:


Not suitable for some embedded systems
Static Reflective Micro-ORB:
–
Allows a variety of different configurations
Advantages:
Neer minimal footprint adaptively
Eliminate jitter
Disadvantages:

2. Monolothic ORB with Compile-Time
Configurable Flags:
–
–
Builds a configuration description for
each application based on the history.
Advantages:
–
Efficient
Easy to code
Supports all CORBA services
Disadvantages:

Dynamic Reflective Micro-ORB:
–
All code is loaded in one executable.
Advantages:

–
4.
Automatic customization is still an open
research issue
ZEN Design Process
1.
2.
3.
Dynamic Micro-ORB
Dynamic Reflective Micro-ORB
Static Reflective Micro-ORB
Micro-ORB vs. Monolithic-ORB:

Context:
– Implementing full-service can yield a
monolithic-ORB with large footprint

Problem:
– Embedded Systems often have
severe memory limitations
Monolithic-ORB Architecture [ZEN]

Solution
– Micro-Kernel pattern
– Virtual Component Pattern


Identify core ORB services whose
behavior may vary
Move each core ORB service out of
the ORB
Micro-ORB Architecture [ZEN]
Virtual Component Configurator:

Intent
– to factor out components that may not be needed

Solution
– Use abstract interfaces for all components
– Upon ‘component-fault’ load concrete implementations using:



Factory Method
Proxy
Component Configurator
Virtual Component Static Structure [VirtualComponent]
Component Loading Strategies:
Eager Static Loading Strategy [VirtualComponent]
Eager Dynamic Loading Strategy [VirtualComponent]
Lazy Dynamic Loading Strategy [VirtualComponent]
Agenda:



Motivation
ZEN Solution
Background
– CORBA and Real-Time CORBA
– Java and Real-Time Java





ORB Generations
Micro-ORB vs. Monolithic-ORB
Virtual Component Pattern
ZEN Architecture
Concluding Remarks
Pluggable GIOP Message Handling:

Context:
– GIOP defines 8 types of
messages
– Each requires two marshal
and demarshal
– Three versions: 1.0, 1.1, and
1.2


Problem:
– 8*2*3 makes 48 methods
– Space overhead
– Hard to modify
Solution:
– Virtual Component:

Fine-grain
– 48 separate classes

Client/Server pairing
– Groups complementary
methods into a single class
Pluggable GIOP Message Handling [ZEN]
Pluggable Object Adapter:

Context:
– Maps client requests to the
servants
– Different types of POAs:




The Standard POA
Minimun POA
Real-Time POA

Problem:
– A POA is just necessary for
server applications.
– Space overhead
– Hard to add new standards
Solution:
– Virtual Component:

If the application plays the
role of a server, at most one
of POA types will be loaded.
Pluggable Object Adapter [ZEN]
Pluggable Transport Protocols:

Context:
– GIOP can run over many
transport protocols.
– Each protocol roughly need 5
methods to implement.
– Each containing:




Problem:
– About 20 to 30 methods
required to handle the most
common protocols.
– Space overhead
– Hard to modify
Client-oriented classes
Server-oriented classes
Solution:
– Virtual Component:


Allows one (or more) desired
protocol(s) to be loaded.
Only the required subclasses
will be loaded dynamically.
Pluggable Transport Protocols [ZEN]
Pluggable CDR Stream Reader/Writer:

Context:
– CORBA is platform independent
and must handle diverse end
system instruction set.
– CORBA defines Character Data
Representation for marshalling
and demarshalling.


Problem:
– each possible read or write for
each data type, such as
readDouble() and readLong(), needs
an if statement to check big/little
endian.
– Space overhead
– Hard to modify
Solution:
– Virtual Component:


Each CDRInputStream class
in divided into two classes
(for big and little endian).
Improve in space and
performance (“if” executes
once).
Pluggable CDR Reader [ZEN]
Pluggable Any Handler:

Context:
– Any used for generic services
– Each any is preceded by a
type code of the value it
contains.
– Many DRE apps do not use
Any at all.


Problem:
– A lot of code is required to
support Any.
– To read, write, marshal,
demarshal, and to insert and
extract any from each type.
– Space overhead
Solution:
– Virtual Component:



Removing Any methods.
Keep minimal proxy object
(AnyReader and AnyWriter).
The rest will be loaded on
demand.
Pluggable Any Handler [ZEN]
Pluggable IOR Parsers (cont.):

Context:
– Interoperable ORB
References are CORBA
object pointer.
– Variety of formats:


– Virtual Component:


Problem:
– Parsing every possible format
– Space overhead
– Hard to modify
“IOR:,” “FILE:,” “HTTP:,”
“CORBALOC:,” and “FTP:.”
Solution:


Define an interface that
parses and handles IORs.
Derive separate class
strategies that handles each.
Load the class on demand.
Example IOR [ZEN]
Pluggable IOR Parser [ZEN]
Pluggable Object Resolver:

Context:
– ORB::resolve_initial_reference() is
used to obtain references to
ORB objects such as
RootPOA and Naming.
– The number of objects are
large and growing.


Problem:
– Cascade if statements to
check each object string
name.
– Space overhead
– Hard to modify
Solution:
– Virtual Component:



An abstract base class with a
factory method at the base.
Factory method takes a string
and returns a ref to an object.
A naming convention is used.
Pluggable Object Resolver [ZEN]
Pluggable Message Buffer Allocators:

Context:
– To ensure efficient
interprocess communication
and avoid unnecessary
garbage collection.
– But which specific dynamic
storage allocation algorithm?


Problem:
– Must include all possible
algorithms for flexibility.
– Fast fit, buddy system, …
– Space overhead
– Hard to modify
Solution:
– Strategy Pattern:

To support each algorithm
– Thread Specific Pattern

To make them pluggable.
– Virtual Component:

Dynamic on demand loading.
Pluggable Allocator [ZEN]
ZEN Current Status:




Functional Java-based ORB with POA, GIOP, IDL
compiler, etc.
Interoperable with the TAO C++ ORB
Missing: COS Services, DII/DSI
Current focus is on:
– Factoring out more functionality from the ORB core to
reduce footprint for embedded systems
– Completing Real-time CORBA support utilizing Real-time
Java features
– Ahead-of-time Real-time Java native compilation
– Using refection to determine ideal minimal configuration
– Using aspects for static custom configuration
Concluding Remarks:

ZEN Objectives:
– Supporting development of DRE systems
 Faster,
easier, more extensible, and more portable
– Reducing the footprint
– Providing an infrastructure for DOC
middleware R&D by releasing ZEN in opensource

Technologies integrated in ZEN:
– CORBA and Real-Time CORBA
– Java and Real-Time Java
References:






[ZEN]
http://www.computer.org/proceedings/isorc/1558/15580437abs.htm?SM
SESSION=NO
[CORBA-Overview]
http://www.cs.wustl.edu/~schmidt/corba-overview.html
[ZEN-Web]
http://www.zen.uci.edu
[RT-Java] Real-time Java (JSR-1)
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_001_real_time.
html
[Dist-RT-Java] Distributed Real-time Java (JSR-50)
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_050_drt.html
[VirtualComponent]
http://www.cs.wustl.edu/~schmidt/PDF/virtual-component.pdf