Download finSOAandMWv02 - University of Connecticut

Service-Oriented Architectures/Middlware
CSE
333
Prof. Steven A. Demurjian
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-2155
Storrs, CT 06269-2155
[email protected]
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
† Special Thanks to Prof. Alex Shvartsman, Keith Bessette, Scott Craig
and Prior CSE333 students for providing portions of this material.
SOA+MW-1.1
What is a Distributed Application?

CSE
333


Distributed Computing/Applications are …
 Systems of Systems
 Interoperation of New & Existing Applications
 Legacy, Databases, COTS, New Clients, etc.
 Network Centric Environment
Distributed Computing Applications must …
 Manage, Control, Access, and Modify Data
 Allow Humans to Interact with Data
 Provide High-Availability and Performance
 Evolvable Over Time
Present & Future Army Systems Exhibit All of
These Characteristics and More!
SOA+MW-1.2
What is a Distributed Application?
CSE
333
System of Systems
Heterogeneity
Hardware
OS, PLs
Network Centric Environment
DB Client
Legacy
Client
Legacy
Database
COTS
Dynamic
Environment
High-Availability
Performance
Java
Client
Server
Server
Legacy
Java
Client
Database
COTS
COTS
Client
Increase Productivity
New/Innovative
Transparent Interoperation
Information Use
SOA+MW-1.3
Another View – Today’s Reality

CSE
333



Premise: Artifacts - set of
 DB, Legacy, COTS,
GOTS, Each w/ API
Premise: Users
 New and Existing
 Utilize Artifact APIs
Distributed Application, DA
 Artifacts + Users
What are the Issues?
 How Do they Interact?
 Heterogeneity
 Security Concerns
 Different Programmatic
Models
 Etc. Etc. Etc.
Database
COTS
Legacy
Legacy
Client
Java
Client
GOTS
NETWORK
GOTS
Client
Legacy
Database
Database
Client
COTS
Client
SOA+MW-1.4
Why is Distributed Computing Needed?

CSE
333


Today’s Environments Contain Applications …
 Created with Multiple Prog. Languages
 Executing on Heterogeneous Platforms
 Locally and Geographically Distributed
Distributed Computing Applications Must …
 Allow Seamless and Transparent Interoperation
 Provide Tools for Engineers and Users
Result: Inter-Operating Environment
 Utilize Information in New/Innovative Ways
 Leveraged to Increase Productivity
 Support Diverse User Activities
 Dynamically Respond to Changes
SOA+MW-1.5
Striving for New Techniques/Technologies

CSE
333

We Must Diverge from Business as Usual
 C Programming with RPC
 Customized Development without Reuse
 Solutions that Aren’t Extensible and Evolvable
 Cobbling Together Solutions w/o Method or
Reason is Unacceptable and Doomed to Fail!
We Must Face Today’s Realities
 Legacy Code is Fact of Life
 New Technologies Offer New Challenges
 Adopt to Leverage Their Benefits
 We Must Draw Careful Balance to Opt for
Mature Technologies While Targeting
Emerging Technologies with Potential!
SOA+MW-1.6
Who are the Players?

CSE
333


Stakeholders
 Software Architects (Requirements)
 System Designers (Solutions)
 Application Builders (Implementation)
Stakeholders Striving to Provide …
 System Interaction and Information Exchange
 Utilization of Existing Applications in New and
Innovative Ways
End-Users at Various Skill Levels and with Specific
and Limited Access Requirements
 Novice vs. Adept vs. Expert
 Who Uses What When and for How Long?
SOA+MW-1.7
Why a Distributed Application?

CSE
333

Reasons:
 Data used is Distributed
 Computation is Distributed
 Application Users are
Distributed
2 Key Issues for Solution:
 Platform-Independent
Models and Abstraction
Techniques
 Hide Low-Level Details
 Provide a Well-Performing
Solution
 Works Today and
Tomorrow!
Shared Objects
• Easy to Re-use
• Easy to distribute
• Easy to maintain
SOA+MW-1.8
Distributed Systems
Fundamental Realities of Distributed Systems
CSE
333
Co-located
Distributed
Fast
Slower
Failures
Objects fail together
Objects fail
separately, Network
can partition
Concurrent Access
Only with multiple
threads
Yes
Yes
Not Inherently
Often Add-On
Capability
Communication
Secure
SOA+MW-1.9
What is a Service Oriented Architecture?

CSE
333



Solutions that Focus on Services that Need to be
Available to Meet Need of Users (Entities)
Users are Assumed to be Interacting via Client
Applications (Browser or Standalone)
 Interactions with Services Transparent to Users
(Integrated into Software)
Interactions Between Entities Occur via a Message
Exchange - Conceptual
 Resources are Software Artifact Accessible via
API Consisting of Services
 Services are Logical Grouping of Methods
(Functions) that are Available for Use
 Services are Utilized When Messages are Invoked
Against Them by Outside Users
Both Web-Based and Middleware Settings
SOA+MW-1.10
Service Oriented Architectures (SOA)

CSE
333


An SOA is often Cast in a Web-Based Setting
Possible Services include:
 Data Transfer (e.g. FTP) or Storage Service
 Troubleshooting Service
Service Operations (Messages) are Encapsulated
Behind a Message-Oriented Service Interface
 Hides Details of Service Implementation/Location
 Assumes an Architecture for Access
 Provides a Logical View that is Message-Oriented
 Available Service/Messages are Descriptively
Supplied for Purpose of Discovery/Lookup
 Network-Oriented
 Scalable – Add New Services/Extend Existing
Services for New/Improved Functionality
SOA+MW-1.11
Middleware-Based SOA

CSE
333

Distributed Object Computing Platforms are Well
Established in the Field - Historically
 DCE (Distributed Computing Environment)
 COM/OLE (Component Object Model/Object
Linking and Embedding)
Modern Middleware (JINI, CORBA, .NET):
 CORBA –Standards Committee (OMG) Controls
Technology – Many Programming Languages
 JINI – Sun-Based Product – The Poor Mans
CORBA – Java
 .NET – Microsoft’s Forward into the Modern
Market – C#
SOA+MW-1.12
Web-Based SOAs

CSE
333

While Not our Focus – Important to Understand their
Role in SOA
From Web Services Architecture, W3C
A Web service is a software system designed to
support interoperable machine-to-machine interaction
over a network. It has an interface described in a
machine processable format (specifically WSDL).
Other systems interact with the Web service in a
manner prescribed by its description using SOAP
messages, typically conveyed using HTTP with an
XML serialization in conjunction with other Webrelated standards.
SOA+MW-1.13
Web Services Architecture from W3C

CSE
333

Complex
Architecture with
Many Different
Capabilities and
Features
 Open Ended
(Like Web)
 Target Multiple
Domains/Usages
Current Web and
Future (Emerging?)
Semantic Web
SOA+MW-1.14
What Must All SOA Provide?

CSE
333
Both Middleware & Web-Based SOAs Must Provide
 Middle Layer Infrastructure that Provides Bridge
Between Software Artifacts
 Clients and Resources in Middlware Setting
 Clients (Browsers) and Resources in Web Setting
Allow Software Artifacts (Resources) to
Register/Publish their APIs (Services and
Methods) for use by Clients/Other Resources
Lookup Service:
 Middleware that Provides Means for Software
Artifacts (Resources and/or Clients and/or Other
Resources) and to Interact
 Support Dynamic Discovery – Find Services
Based on Attributes and Values
 Location Transparency to Service Requestors


SOA+MW-1.15
Objectives of SOA

CSE
333






Can SOAs Support Highly-Available Distributed
Applications?
Can Replicated Services be Registered and Available
for Use by Clients?
Can SOAs Support a Network-Centric Environment
with Dynamic Clients and Services?
Will Clients Continue to Operate Effectively if a
Replicated Service Fails?
Can SOAs be Utilized to Maintain Data Consistency
of Replicas?
Are SOAs Easy to Learn and Use?
What is Maturity Level of SOAs Technology?
SOA+MW-1.16
Overview of Presentation

CSE
333



Objective is to Explore CORBA, JINI, and .NET
Various Aspects of Three Technologies
 A
 B
 C
 D
Comparison of CORBA, J2EE (Java), and .NET from
Security Perspective
 What Does Each Support?
 Limits and Capabilities of Security Models
Multi-Tier Architectural Solutions
 Examples of Various Architectures
 Interplay and Interactions of Technologies
SOA+MW-1.17
What is CORBA?

CSE
333


Common Object Request Broker Architecture
Architecture to Allow:
 Existing COTS, GOTS, Legacy, DB, etc. to
Interact with One Another
 Integrate These with New Clients/Servers/Etc.
Consists of Following Major Components
 Object Request Broker (ORB):
 Arbitrate and Interact
 Role of Lookup for Service Discovery

Interface Definition Language (IDL):
 Common Definitional Format
 Means for Different “Software” written in Different
Languages to Interact with One Another
SOA+MW-1.18
What is CORBA?

CSE
333


CORBA is a
Specification for
Interoperability
OMG (Object
Management
Group) Supplies a
Set of Flexible
Abstraction and
Concrete Services
Vendors Must
Follow Standard
CORBA Language Mappings
Ada
C and C++
COBOL
Java to IDL
Lisp
CORBA Scripting
Language
Smalltalk
Others
Perl
Haskell
Python
Eiffel
PHP/ORBit
SOA+MW-1.19
What is CORBA?

CSE
333

Differs from Typical Programming Languages
Objects can be …
 Located Throughout Network
 Interoperate with Objects on other Platforms
 Written in Ant PLs for which there is mapping
from IDL to that Language
Application
Interfaces
Domain Interfaces
Object Request Broker
Object Services
SOA+MW-1.20
What is CORBA?

CSE
333
CORBA Provides a Robust set of Services (COS)
 Services to Support Integration and Interoperation of
Distributed Objects
 Services Defined on top of ORB as standard CORBA
Objects with IDL interfaces
 Vendors Must Implement CORBA Services (COS)
Factory
Naming
Context
Object Request Broker
Event
Channel
Object Life
Cycle
Naming
Events
Relationships
Externalization
Transactions
Trader
Query
Property
SOA+MW-1.21
What is CORBA?

CSE
333

Allow Interactions from Client to Server CORBA
Installed on All Participating Machines
Client Application
Static
Stub
DII
Server Application
ORB
Interface
ORB
Interface
Skel
eton
DSI
Object Adapter
Client ORB Core
Network
IDL - Independent
Same for all
applications
Server ORB Core
There may be multiple
object adapters
SOA+MW-1.22
CORBA: Architectural Goals

CSE
333











Simplicity
Consistency
Scalability
Usability for End Users
Usability for Administrators
Usability for Implementers
Flexibility of Security Policy
Independence of Security Technology
Application Portability
Interoperability
Performance
Object Orientation
SOA+MW-1.23
Role of an Object Request Broker (ORB)

CSE
333



ORB Provides the Underlying Infrastructure for
Supporting Interoperating Software Systems
(Applications) Composed of Distributed Objects
 ORB Provides the Basic Request Delivery
 ORB Provides Interface Definitions
Location is Transparent to the Caller and Object
Implementation
Caller and the Object Implementation Can be in the
Same Process thru Opposite Sides of the World
ORB Manages Local Location and Optimization
ORB
Clie nt
Obje ct
Application
Imple me ntation
SOA+MW-1.24
Interface Definition Language, IDL

CSE
333



Key Component of CORBA Is the Interface
Definition Language, IDL
 Mapping is Available in C, C++, Java, Ada, Etc.
 IDL Is Independent of Any Language/Compiler
 Multiple Inheritance
 Public Interface Oriented
 Not for Implementation
Primary Support for Interoperability Between Static
and Dynamic Request Mechanisms
Advantage: Modification of Client Code without
Impacting of Server Code, and vice-versa
Disadvantage:
 A complete new language with C++ like Syntax
 Programmers Must Prepare IDL Modules
SOA+MW-1.25
ORB and High Level View of Requests

CSE
333
The Request Consists of
 Target Object
 Operation (Method)
 Parameters
 Request Context (Optional)
Clie nt
Application
Obje ct
Imple me ntation
Object Call
IDL Boundary
Object reference
Methods and D ata
ORB
Request
IDL Boundary
Object dispatcher
SOA+MW-1.26
CORBA Components and Interfaces
CSE
333





Client Stub: Client Invokes a Particular Object Op.
Dynamic Invocation: Run-Time-Construction of
Operation Invocations
Implementation Skeleton: Interface Through Which a
Method Receives a Request
Object Adapter: Provides (De)activation, Object
Creation/Reference Mgmt. for Implementations
ORB Interface: Common ORB Operations
Client
Dynamic
Invoke
Client
Stubs
Object Implementation
ORB
Interface
Implementation
Skeletons
Object
Adapter
ORB Core
One interface
One interface per object adaptor
One interface per object operation
ORB internal interface
SOA+MW-1.27
Interfaces

CSE
333


Objects are Defined in IDL via Interfaces
Object Definitions (Interfaces) are Manifested as
Objects in the Interface Repository, as Client Stubs,
and as Implementation Skeletons
Descriptions of Object Implementations are
Maintained as Objects in the Impl. Repository
IDL Interface
Definitions
Interface
Repository
Access
Client
Stubs
Includes
Client
Implementation
Installation
Implementation
Skeletons
Includes
Implementation
Repository
Describes
Object Implementation
SOA+MW-1.28
CORBA: Repositories

CSE
333
Interface Repository




Client access to
definitions
Type checking for
signatures
Traversal of
inheritance graphs
Implementation Repository





IDL Interface
Definitions
Interface
Repository
Location of
implementation
Activation information
Administration control
Security
Resource allocation
Implementation
Installation
Client
Stubs
Implementation
Skeletons
Implementation
Repository
Access
Includes
Client
Describes
Includes
Object Implementation
SOA+MW-1.29
Client Side

CSE
333


Clients Perform Requests Using Object References
Clients Issue Requests through Object Interface Stubs
(Static) or DII (Dynamic Invocation Inter.)
Clients May Access General ORB Services:
 Interface Repository (IR)
 Context Management
 Request Management
Client
Object
Repository
Object Implementation
Dynamic
Invoke
Client
Stubs
ORB
Interface
Implementation
Skeletons
Object
Adapter
ORB Core
SOA+MW-1.30
Object Implementation Side

CSE
333


Implementations Receive Requests Thru Skeletons
Object Adapter Adapts to Specifics of Object
Implementation Schemes
Basic Object Adapter (BOA) Provides:
 Management of References
 Method Invocation
 Authentication
 Implementation Registration
 Activation / Deactivation
Object Implementation
Client
Dynamic
Invoke
Client
Stubs
ORB
Interface
ORB Core
Implem.
Skeletons
Implementation
Repository
Object Adapter
SOA+MW-1.31
CORBA

CSE
333

Basic Object Adapter (BOA)
 Provides Basic Services to Allow Variety Of
CORBA Objects to be Created – Ambiguous
Portable Object Adapter (POA)
 Allow Developers yo Construct Object
Implementations that are Portable Between ORBs
 Mediator Between ORB And Server
Server Applications
Servants
Client
ORB
POA
Incoming Request
SOA+MW-1.32
CORBA: POA Policies

CSE
333


Provided to Programmer for Control Over an Object’s
Identity, State, Storage and Life-cycle
7 Different Policies
 Thread Policy
 Life-Span Policy
 Object ID Uniqueness Policy
 ID Assignment Policy
 Servant Retention Policy
 Request Processing Policy
 Implicit Activation Policy
We Briefly Review each in Turn
SOA+MW-1.33
CORBA: POA Policies

CSE
333
Thread Policy - Depends on Number of Objects the
Application Will Have
 Depends on Operating System
 Expected Load on System



ORB_CTRL_MODEL/SINGLE_THREAD_MODEL
Life Span Policy - Transient object cannot live
beyond the process which created it
 Persistent object can live beyond the process
which created it
 TRANSIENT / PERSISTENT
Object ID Uniqueness Policy
 UNIQUE_ID / MULTIPLE_ID
SOA+MW-1.34
CORBA: POA Policies

CSE
333



ID Assignment Policy - To specify whether Object ID
was generated by the application or ORB
 USER_ID / SYSTEM_ID
Servant Retention Policy: States if POA retains active
servants in object map
 RETAIN / NON_RETAIN
Request Processing Policy: States how request
processed by the POA
 USE_ACTIVE_OBJECT_MAP_ONLY /
USE_DEFAULT_SERVANT /
USE_SERVANT_MANAGER
Implicit Activation Policy: Indicates if Implicit
activation of servants is supported by POA
 IMPLICIT_ACTIVATION /
NO_IMPLICIT_ACTIVATION
SOA+MW-1.35
Dynamic Invocation Interface (DII)

CSE
333

DII Allows Clients to Dynamically:
 Discover Objects
 Discover Objects’ Interfaces
 Create Requests
 Invoke Requests (-> Methods)
 Receive Responses
Major DII Features:
 Requests Appear as Objects
 Requests are Reusable
 Invocation May be Synchronous or Asynchronous
 Requests Can be Generated Dynamically,
Statically or Using Both Approaches
SOA+MW-1.36
Request Components

CSE
333






Object Reference -- Identifies the Target Object
Operation -- Identifies Which Operation to Invoke
(Which Method Will Be Executed)
Parameters -- Input, Output or Inout Method Arg-s
Context Object -- the Context Within Which the
Request Is to Be Performed
Results -- the Result Value(s) Returned
Environment -- the Exec-n Env-t and Exception Info.
Request Handle -- the Id. For This Request Instance
SOA+MW-1.37
Repositories: Interface and Implementation

CSE
333

Interface Repository
 Dynamic Client Access to Interface Definitions to
Construct a Request
 Dynamic Type Checking of Request Signatures
 Traversal of Inheritance Graphs
Implementation Repository
 Location of Implementations and Methods
 Activation Information
 Administration Control
 Resource Allocation
 Security
SOA+MW-1.38
Three Types of ORBs

Single Process Library Resident
CSE
333
Client
ORB

Object
ORB and implementations
implemented as libraries
(routines) resident in
the client.
Request
Client and Implementation Resident
Client
ORB
Object
ORB implemented as
libraries (routines) resident
in the clients and in the
implementations.
Request
SOA+MW-1.39
Three Types of ORBs

Server or Operating System Based
CSE
333
Client
ORB
Object
Request
ORB is implemented as
a server (separate process)
which brokers requests
between client and
implementation processes.
ORB is part of the
operating system.
SOA+MW-1.40
Three Types of Implementations
CSE
333

Single Process “one shot” Object
Object Implementation
Single Process
Single
method
invocation

Implementation is a single
process that is activated
upon the request delivery
Multi-Threaded “resident” Object
Object Implementation
Single Process
Implementation is a permanent
or resident multi-threaded
process
Method C
Method B
Method A
SOA+MW-1.41
Three Types of Implementations
CSE
333

Multi-Process Object
Object Implementation
Process 1
Method A
Process 2
Method B
Implementation is a set
of processes dedicated to
a particular (group of)
method(s)
Process 3
Method C
Processes can be distributed
SOA+MW-1.42
System Design with CORBA
CSE
333
Scott A. Craig
Computer Science & Engineering Department
The University of Connecticut
Storrs, Connecticut 06269-3155
[email protected]
SOA+MW-1.43
Overview of Presentation
CSE
333


Introduction to OMG IDL
Object Management Architecture

CORBAservices
 Naming Service
 Event Service



Typed Event Example
References
Concluding Remarks
SOA+MW-1.44
Interface Definition Language, IDL

CSE
333




Language used to describe the interfaces that client
objects call and object implementations provide.
Obeys the same lexical rules as C++, but introduces
some new keywords.
Supports standard C++ preprocessing features.
Interfaces can have operations and attributes.
 Operation declaration consists of a return type, an
identifier, a parameter list, and an optional raises
expression (exceptions).
 Attribute declaration is logically equivalent to
declaring a pair of accessor operations. May be
declared as readonly.
Interface specifications are placed in a source file
having the extension “.idl”
SOA+MW-1.45
IDL: Modules and Interfaces

CSE
333

Module: Used to scope IDL identifiers.
 Mapped to C++ namespace with the same
name. Mapped to a C++ class if the namespace
construct is not supported.
 Mapped to Java package with the same name.
 IDL declarations not enclosed in any module have
global scope when mapped.
Interface: Description of set of operations that a
client may request of an object.
 Multiple inheritance supported
 Interface body may contain the following kinds of
declarations: constant, type, attribute, and
operation.
SOA+MW-1.46
IDL: Basic Types
CSE
333
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
SOA+MW-1.47
IDL: Complex Types

CSE
333


Structures:
 struct FixedLengthStruct {
long
field1; // 32-bit
short
field2; // 16-bit
};
 struct VariableLengthStruct {
long
field1; // 32-bit
string
field2;
};
Discriminated Unions: Cross between the C union
and switch statements.
Enumerations: Ordered list of identifiers.
 enum quality_t {
Poor, Fair, Good, Excellent};
SOA+MW-1.48
IDL: Complex Types (cont.)

CSE
333


Sequences: One-dimensional array with maximum
size (fixed at compile time) and length (set at run
time).
 Unbounded Sequence:
typdef sequence<long> longSeq;
 Bounded Sequence:
sequence<long,10> fieldname;
Strings: Declared using keyword string. May be
bounded or unbounded.
 string name<32>; //bounded
Arrays: Multidimensional, fixed-size arrays of any
IDL data type.
SOA+MW-1.49
IDL Example: GUI
CSE
333
/*
* File Name:
*/
GUI.idl
#ifndef GUI_IDL
#define GUI_IDL
module GUI {
struct timespec_t {
long tv_sec;
long tv_nsec;
};
interface Dialog1 {
void update(in Dialog1Data_t val);
};
interface Dialog2 {
void update(in Dialog2Data_t val);
};
};
#endif
// GUI_IDL
struct Dialog1Data_t {
timespec_t
DataTime;
float
val;
};
struct Dialog2Data_t {
timespec_t
DataTime;
long
val;
};
interface MainWindow {
void logEvent(in timespec_t timestamp,
in string val);
};
SOA+MW-1.50
IDL Example: Server
CSE
333
/*
* 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
SOA+MW-1.51
Object Management Architecture

CSE
333

The Object Management Group, Inc (OMG) has
established the Object Management Architecture
(OMA), upon which OMG specifications are based
Components of the OMA Reference Model:
 Object Request Broker (CORBA):
 Provides communications infrastructure.

Object Services (CORBAservices):
 Collection of fundamental services (interfaces and
objects) for using and implementing objects.

Common Facilities (CORBAfacilities):
 Services such as system management.

Application Objects
 Not standardized.
SOA+MW-1.52
CORBAservices

CSE
333



OMG specification for Object Services
Collection of 15 services (interfaces and objects) that
support basic functions for using and implementing
objects.
 Interfaces specified using IDL
Will focus on two services:
 Naming Service
 Event Service
Security Service: Addresses identification and
authentication, authorization and access control,
security of communication between objects, etc.
 Beyond scope of this presentation (specification is
386 pages in length)
SOA+MW-1.53
Naming Service
CSE
333






Facilitates locating objects in a distributed system.
A name binding is a name-to-object association
and is always defined relative to a naming context.
A naming context is an object that contains a set of
name bindings in which each name is unique.
Multiple names may be bound to an object.
Servers bind names to objects and clients resolve
names to objects.
A naming context may be bound to a name in
another naming context creating a naming graph.
 Directed graph with labeled edges in which
nodes are objects.
 Compound names are formed by the sequence
of names along a path from the root to the leaf.
SOA+MW-1.54
References

CSE
333





Object Management Group, Inc. (OMG),
http://www.omg.org
OMG, A Discussion of the Object Management
Architecture, 01/97
OMG, The Common Object Request Broker:
Architecture and Specification, Rev. 2.2, 02/98
OMG, CORBAservices: Common Object Services
Specification, 12/98
T. J. Mowbray and R. Zahavi, The Essential CORBA:
Systems Integration Using Distributed Objects, John
Wiley & Sons, Inc., 1995
G. Booch, J. Rumbaugh, I. Jacobson, The Unified
Modeling Language User Guide, AWL, Inc. 1999
SOA+MW-1.55
JINI
CSE
333
SOA+MW-1.56
What is JINI?

CSE
333

An Infrastructure for Network Centric Applications in
Spontaneous Environment
 Clients Enter/Leave Network Unpredictably
 Resources and Services Enter/Leave due to
Failure, Redundancy, Topology Change
 Both Typify Present/Future Army Systems
Goals of JINI
 Plug-and-Play of Clients and Services
 Erasing Hardware/Software Distinction:
Everything is a Service
 Enable Spontaneous Network Applications
 Architecture where Services Define Function
 Strive for Easy to Use/Understand Technology
SOA+MW-1.57
Sun’s JINI Technology

CSE
333



JINI is a Sophisticated Java API
Construct Distributed Applications Using JINI by
 Federating Groups of Users
 Resources Provide Services (Database Access,
Printing, Real-Time Sensor) for Users
JINI and Stakeholders
 Core of Technologies to Architect, Design,
Implement, and Test Distributed Applications
 Construct Software “Resistant” to Failure
JINI and Users
 High Availability Through Redundancy
 Dynamic Responses to User Requests
Regardless of Network & Resource Changes
SOA+MW-1.58
Java Computing Architecture and JINI
CSE
333
SOA+MW-1.59
JINI Components and Dependencies
CSE
333
Base
Java
Infrastructure
Programming
Model
Services
Java VM
Java APIs
JNDI
RMI
JavaBeans
Enterprise Beans
Java Security
JTS
JMS
Java +
JINI
Discovery/Join
Leasing
Distributed
Security
Lookup
Transactions
Transaction
Manager
JavaSpaces
Events
Lookup service
SOA+MW-1.60
How Does JINI Work?

CSE
333



Distributed Application Constructed Using One or
More Lookup Services
Lookup Service Support Interactions by
 Resources: “Advertise” Services
Discover, Register Services, Renew Lease
 Client: “Locate/Utilize” Services
Discover, Search for Services, Invocation
Multiple Lookup Services
 Resources Responsible for Registering All
 Clients Interact with Multiple Lookups
 Stakeholders Must Write “Apropos” Code
Discovery Initiates Process for Client or Resource
SOA+MW-1.61
Discovery by Resource & Client
CSE
333
JINI
Lookup
Service
Discovery to
Locate Services
JINI
Lookup
Service
Discovery to
Register Services
Resource
Client
Service Object
Service Attributes
SOA+MW-1.62
Basic JINI Concepts

CSE
333




JINI Lookup Service Maintains Registry for Available
Services of Distributed Application
Resources Provide Services that Register and Join
with JINI Lookup Service
Clients Discover and Utilize Services Based on
Interface of Services
 Ask Lookup for RegisterForCourse(CSE900)
 Return Proxy for Execution of Service
 Location of Service Transparent to Client
Locations of Clients, Services, Lookup Service, etc.,
can Change over Time
Conceptually, JINI Similar to Distributed OS with
Dynamically Definable/Changeable Resources
SOA+MW-1.63
Basic JINI Concepts

CSE
333

A Resource Provides a Set of Services for Use by
Clients (Users) and Other Resources (Services)
A Service is Similar to a Public Method
 Exportable - Analogous to API
 Any Entity Utilized by Person or Program
 Samples Include:
 Computation, Persistent Store, Printer, Sensor
 Software Filter, Real-Time Data Source
 Anything that is Relevant for Your Domain!
Services: Concrete Interfaces of Components
Services Register with Lookup Service
 Clearinghouse for Resources to Register Services
and Clients to Locate Services


SOA+MW-1.64
JINI Resources & Services
CSE
333
JINI
Lookup
Service


Register
Services
Printer Resource
Service Object
Service Attributes
Sun’s Initial Perspective
 JINI for Hardware
Class and
Methods
 Printers, Digital
Define
Cameras, etc.
Services
 Plug-and-Play on
to be
Network
PrinterActions Class Defines Registered
the “Component” that is
Registered with JINI
PrinterActions Class
enqueuePrintJob
dequeuePrintJob
getPrinterStatus
getPrinterType
installPrinter
removePrinter
startJob
cancelJob
SOA+MW-1.65
Objectives and Utility of JINI

CSE
333

For Users, JINI Offers
 Sharing of Resources (Services) over Network
 Location Transparency of Users and Services
 Both Critical for “Moving” Personnel
For Stakeholders, JINI Provides
 Infrastructure for Federating Services in
Distributed Setting
 Programming Model to Register & Discover
Services
 Availability of Services Throughout Distributed
Setting
Leading to Ease in Constructing, Maintaining, and
Evolving Network Centric Applications
SOA+MW-1.66
How Does JINI Work?

CSE
333


Resources Discover and Join Lookup Service
When Resources Leave or Fail to Renew Leases
 Lookup Service Must Adjust Registry
 Time Lag Between Departure and Removal of
Services from Registry
 What Happens When Client Receives Service
Just Prior to Failure?
 Utilization of Java Exception Handling
 Client Code Written to Dynamically Adapt
Resource Register
 Services on Class-by-Class Basis
 Service Object (Java API - Method Signatures)
 Optional Descriptive Service Attributes
SOA+MW-1.67
JINI Concepts and Terms

CSE
333


Registration of Services via Leasing Mechanism
 Resource Leases Services to Lookup Service
 Resources Renew Services Prior to Expiration
 If not, Services Become Unavailable
 Lookup Service Maintains Registry
 Limit Availability of Services Based on Time,
Workload, User Requirements, etc.
 Services as Available “Components”
Leasing Supports High-Availability
 Registration and Renewal Process
 Upon Failure, Services Removed from Registry
Clients, Resources, Lookup Can Occupy Same or
Different Computing Nodes
SOA+MW-1.68
Registration & Leasing

CSE
333


FOREVER or EXPIRATION DATE (millisecs)
Renewal Must Occur Prior to Expiration
JINI Provides Lease Renewal Manager to Allow
Resource to Delegate Renewal Responsibility
JINI
Lookup
Service
Leasing/Lease Renewal
Lease for 5 minutes (3000000 msec)
Must Renew Before 5 Minutes Expire
If Not Renewed, Lookup Removes
If Failure, Lookup May Still Supply
Service Until Expiration (5 mins)
Client MUST be SMART!
Printer Resource
Service Object
Service Attributes
Class and
Methods
Define
Services
to be
Registered
PrinterActions Class
enqueuePrintJob
dequeuePrintJob
getPrinterStatus
getPrinterType
installPrinter
removePrinter
startJob
cancelJob
SOA+MW-1.69
JINI Support for Distributed Computing
CSE
333
Clients
Using
Services
JINI Lookup
Service
Redundant
Lookups
Java
Client
Database
Legacy
Resources
Provide
Services
COTS
Java
Client
Legacy
Legacy
Client
COTS
Database
Client
COTS
Client
Database
JINI Lookup
Service
Legacy
COTS
SOA+MW-1.70
Component Perspective and JINI

CSE
333
Resources as Components
 Resources Provide Services
 What Service Provides: Component Interface
 Clients, Servers, Resources, Use Component
Interface to Design/Construct Functionality
Java
Client
Constructed via Services of
Legacy, COTS, Database, etc.
Lookup Registered Services
Functionality via Service Reuse
Services as Component APIs
Legacy
COTS
JINI
Lookup
Service
Database
Legacy
COTS
SOA+MW-1.71
Two Example Resources

CSE
333


University Application
 Students can Register/Drop Courses and Check
the Schedule/Catalog
 Faculty can Alter Course DB and Check the
Schedule/Catalog
Military Application - Database of Parts
 Ability to Requisition/Add/Delete Parts
 Different User Authority Based on Rank
For Both:
 Client to JINI to Discover Services
 Client to Resource for Method Invocation
(Resembles RMI)
SOA+MW-1.72
What Does an Actual System Look Like?
CSE
333
Java
GUI
UDB Client
UDBServer Service
GetClasses();
PreReqCourse();
GetVacantClasses();
EnrollCourse();
AddCourse();
RemoveCourse();
Java
GUI
MDB Client
JINI
Lookup
Service
MDBServer
GetParts
GetRequisition
GetReqParts
WriteParts
WriteRequisition
DeletePart
DeleteRequisition
AddParts
RemovePart
AddRequisition
University DB
Resource (UDB)
Military
Requisition
DB
Resource
SOA+MW-1.73
Join, Lookup, and Service Invocation
CSE
333
Request
Service
AddCourse(CSE900)
Lookup Service
Registry of Entries
Return
Service
Proxy to
AddCourse( )
Client
Service Object
Service Attributes
J Register & Lease Services
CourseDB Class
o
i Contains Method
AddCourse ( )
n
Service Invocation via Proxy
by Transparent RMI Call
Resource
Service Object
Service Attributes
1. Client Invokes AddCourse(CSE900) on Resource
2. Resource Returns Status of Invocation
SOA+MW-1.74
Services of Military Application

CSE
333




Query Service:
 GetParts: Queries DB for Parts
 GetRequisition: Queries DB for Requisition
 GetReqParts: All Requisition Details for a
Particular Part
Update Service:
 WriteParts: Store Part to DB
 WriteRequisition: Requisition Changes to DB
 DeletePart: Deletes Part from DB
 DeleteRequisition: Deletes Requisition from DB
Other Services/Methods Omitted
Notice: These are Just Public Methods Organized into
Logical Groupings
JINI Allows Searching of Groupings by Service
SOA+MW-1.75
Execution Process of Client using JINI
CSE
333
1 Register_Client(Harris,Security Off., Military)
Military
Client
4 Return Result,Create_Token(Security Off., Token)
2 Verify_UR(Harris, Security Off.)
5. Discover/Lookup(MilitaryDb,Modification,
CreateRequisition) Returns Proxy to Military Client
6 CreateRequisition(Token, Tank Details, Harris)
11 Return Result,CreateRequisition(…)
Lookup
Service
Security
Registration
Services
3 Client OK?
USR
Security
Authorization
Services
7 IsClient_Registered(Token)
9 Check_Privileges(Token, MilitaryDb, Modification,
CreateRequisition, [Tank Details, Harris])
MilitaryDB
Resource
8 Return Result of IsClient_Registered(…)
Security
Policy
Services
10 Return Result of Check_Privileges(…)
SOA+MW-1.76
Services Console
CSE
333
SOA+MW-1.77
Services GUI
CSE
333
SOA+MW-1.78
Microsoft’s .NET
CSE
333
SOA+MW-1.79
.NET Framework Architecture
CSE
333
SOA+MW-1.80
.Net
CSE
333



CTS (Common Type System)
 Defines Common standard that languages should
adhere to.
CLR (Common Language Runtime)
 Manages the execution of a .Net application,
provides cross platform support by ensuring type
safety, code verification, exception handling,
garbage collection and memory management
ASP.NET

This component provides a layer of classes for Web
services
SOA+MW-1.81
CSE
333
.Net



Windows Forms
 Provides a layer of classes for the windows user
interface
ADO.NET
 Provides classes for data access including database
and XML
Base Class Library
 Provides the low level classes on which most of the
.Net functionality and other >net Framework classes
are built
SOA+MW-1.82
Remoting

CSE
333


Remoting makes an object in one process available to an
application in another process
Marshalling enables a controlled data communication
between the 2 processes
Marshalling an object can be done in 2 ways
 Marshall by value:Server creates a copy of the object
and passes the copy to the client
 Marshall by reference: The server creates a reference
of the object ans send this reference to the client
SOA+MW-1.83
Remoting
CSE
333
When a client calls an object marshalled by reference of
the object in the client’s application domain and the
client uses that proxy to access that original object on
the server
SOA+MW-1.84
Remoting
CSE
333
When a client calls an object marshaled by value the server creates and
exact copy and sends that copy to the client. The client then uses
the data of the object and executes the required functionality
directly within the client’s own process without making any
additional calls to the server
SOA+MW-1.85
.NET Framework Architecture
CSE
333
SOA+MW-1.86
.Net
CSE
333



CTS (Common Type System)
 Defines Common standard that languages should
adhere to.
CLR (Common Language Runtime)
 Manages the execution of a .Net application,
provides cross platform support by ensuring type
safety, code verification, exception handling,
garbage collection and memory management
ASP.NET

This component provides a layer of classes for Web
services
SOA+MW-1.87
CSE
333
.Net



Windows Forms
 Provides a layer of classes for the windows user
interface
ADO.NET
 Provides classes for data access including database
and XML
Base Class Library
 Provides the low level classes on which most of the
.Net functionality and other >net Framework classes
are built
SOA+MW-1.88
Remoting

CSE
333


Remoting makes an object in one process available to an
application in another process
Marshalling enables a controlled data communication
between the 2 processes
Marshalling an object can be done in 2 ways
 Marshall by value:Server creates a copy of the object
and passes the copy to the client
 Marshall by reference: The server creates a reference
of the object ans send this reference to the client
SOA+MW-1.89
Remoting
CSE
333
When a client calls an object marshalled by reference of
the object in the client’s application domain and the
client uses that proxy to access that original object on
the server
SOA+MW-1.90
Remoting
CSE
333
When a client calls an object marshaled by value the server creates and
exact copy and sends that copy to the client. The client then uses
the data of the object and executes the required functionality
directly within the client’s own process without making any
additional calls to the server
SOA+MW-1.91
Web Services ASP.NET
Communication based on open protocols
- Data
XML
-Schema
XSD
 UDDI
 DISCO
 WSDL
 SOAP
 Security

CSE
333
SOA+MW-1.92
ADO.NET
CSE
333
SOA+MW-1.93
Security in Middleware - Motivation

CSE
333





Distributed Computing Applications are Constructed
From Legacy, COTS, Database, and Client/Server
Applications
Solutions Facilitate the Interoperation of Applications
in a Network Centric Environment
CORBA, DCOM/OLE, J2EE/EJB, JINI, and .NET
have Enabled the Parallel and Distributed Processing
of Large, Computation-intensive Applications
Security has Historically Often Been an Afterthought
Dramatic Turnaround in Support of Security within
these Modern Middleware Platforms
Thanks to Keith Bessette…
SOA+MW-1.94
Overview

CSE
333



Focus on the Attainment of Security within
 CORBA
 .NET
 J2EE
Represent Three Dominant Middlware Platforms
Emphasis on Exploring the RBAC/MAC Capabilities
of Each
 What Can Each Offer in Support of Security?
 How do the Different Technologies Compare?
Later - Focus on Using Middlware (e.g., CORBA,
JINI) to Attain MAC/RBAC for Distributed Setting
SOA+MW-1.95
Security in CORBA, .NET, and J2EE

CSE
333

The CORBA Security Specification is a Meta-model,
 Similar in Concept to the UML Meta-model with
Implementations (e.g., Together, Rational, etc.)
 Offers Wide Variety of Security Capabilities at the
Model Level - RBAC, MAC, Encryption, Etc.
 Language Independent (Not Tied to Java,
C++, .NET, Etc.)
In Contrast, .NET and J2EE are Commercial Products
 Characterizable as Implementations or Instances
of the CORBA Security Meta-model
 Transition Concepts into Platform Specific
Implementations
SOA+MW-1.96
CORBA Security Capabilities

CSE
333


The CORBA Security Service Specification Focuses
on Four Keys Aspects of Security
Confidentiality:
 Concerned with Access to Information
 Limit Access to Those Individuals (Programs)
That Have Been Given Explicit Permission
Integrity:
 Only Authorized Users are Allowed to Modify
Information
 Delegation of this Authorization Between Users is
Tightly Controlled
SOA+MW-1.97
CORBA Security Capabilities

CSE
333

Accountability:
 Users Must be Responsible for All of their Actions
 Security Mechanisms Must be able to Monitor and
Track the Accountability
Availability:
 If Users have Been Appropriately Authorized, then
their Authorizations Require the System's
Availability
SOA+MW-1.98
CORBA Security Capabilities

CSE
333
Collectively, These Four Features Underlie the
Security Offered in the Meta Model for
 Identification and Authentication of Users
 Authorization and Access Control of Users to
Objects
 Security Auditing for Accountability
 Security of Communication Between Users
and Objects
 Non-repudiation to Provide Proof of Access
 Administration of All of the Security
Requirements
SOA+MW-1.99
The CORBA Security Model

CSE
333



The Structural Model of CORBA is Comprised of
Different Levels used to Facilitate Secure Object
Invocation by Clients
Application Components: Client Request Services and
a Target Object Providing Services
ORB Security Services:
 Access Control Service - If the Operation Being
Requested Is Permitted
 Secure Invocation Service - Protect the Target
Object in Its Interactions With the Client
Implementation of Security Services:
 Available in actual CORBA Implementations
 Platform Specific, must Interact with Security
supported by OS and Hardware
SOA+MW-1.100
The CORBA Security Model
CSE
333
SOA+MW-1.101
Access Control in CORBA

CSE
333


Must Verify the Characteristics of a Subject's
Permissions (via Privilege Attributes) Against the
Target Objects
Target Objects Are Managed via Control Attributes
(Grouped As Domains) and Operations (Grouped as
Rights)
Combination of Privilege Attributes, Control
Attributes, and Domains Provides
 Means to Define Security Requirements
 Basis for Enforcing Those Requirements by
Actual Clients Against Target Objects
SOA+MW-1.102
Access Control in CORBA

CSE
333


Privilege Attributes are Associated with the Client,
Referred to as the Principal
Privilege Attributes are Used to Capture All of the
Various Security Permissions for Access Control
Security Permissions:
 Identity (e.g., User Id) of the Principal
 Role(s) of the Principal
 Group(s) That the Principal Belongs to in the
Organization
 Security Clearance (e.g., Secret, Classified, Etc.)
Of the Principal
 Target Objects and Operations to Which the
Principal Has Been Granted Access, and Any
Other Enterprise-wide Privileges.
SOA+MW-1.103
Access Control in CORBA

CSE
333



Control Attributes are Associated with Each Target
Object, to Track the Security Privileges from an
Object's Perspective
Control Attributes can also Track Security
Information on the Target Object Itself
Control Attributes Track All of the Principals on a
Target-Object-by-Target-Object Basis
 List of all Principles for an Object
Privilege Attributes Focus on Capabilities of
Individual Principals
SOA+MW-1.104
Access Control in CORBA

CSE
333

Rights of a Target Object are the Set of Operations
That Are Available for Assignment to Each Principal
Examples:
 An Access Control List Entry for Each Target
Object would Track the List of Principals Who
Have Been Authorized the Role(s) of the Principal
 A Target Object Itself
 Might have a Security Classification (e.g., Secret,
Classified, etc.)
 May Be Limited in Access to Certain Time Periods
SOA+MW-1.105
Access Control in CORBA

CSE
333



To Assist in the Security Definition Process of
Principles and Objects for an Organization, Domains
can be Utilized
Domain: Provides a Context to Define Common
Characteristics and Capabilities Related to Security
Security Policy Domain Represents the Scope Over
Which Each Security Policy is Enforced
 An Organization May Have Multiple Policies
Security Policy Domain Permits the Definition of
Security Requirements for a Group of Target Objects
 Group Can Be Managed As a Whole, Thereby
Reducing the Needed Administrative Effort
SOA+MW-1.106
Access Control in CORBA

CSE
333

Policy Domain Hierarchies:
 Allows a Security Administrator to Design a
Hierarchy of Policy Domains
 Delegate Subsets of the Hierarchy (Sub-domain)
to Different Individuals
Example: a Health Care Organization
 Sub-domains for Patient Objects, Test-result
Objects, Employee Objects, Etc.
 Security for These Sub-domains Delegated to
Different People in Hospital Administration
SOA+MW-1.107
CORBA Security User Views

CSE
333


Views to Provide a Hierarchical Structure of the
Security Requirements for an Organization
Enterprise Management View
 Organization-wide Perspective on the Treatment
of Security Requirements
 Risk Assessment, Protection Against Malicious &
Inadvertent Security Breaches, Countermeasures
 End Result Will Be the Definition of Security
Policies, As Appropriate, for Different Portions of
an Organization
End User View
 Involves the Privilege Attributes (E.G., User Id,
Role, Clearance, Etc.)
 Focus on the Privileges That Are Authorized, and
Action Authentications of Users
SOA+MW-1.108
CORBA Security Views

CSE
333

Application Developer View
 Security Definitions Maybe Transparent to the
Majority of Stakeholders (Programmers,
Developers, Etc.)
 Security May Be the Strict Responsibility of All
Stakeholders (Programmers, Developers, Etc.)
Administrator’s View
 Security Management Perspective
 Creating and Maintaining the Domains
 Assigning the Privilege Attributes to End Users,
 Administrating the Security Policies, Monitoring
the Control Attributes of Target Objects, Etc.
SOA+MW-1.109
CORBA Security Execution Model

CSE
333



Client Makes a Request to Access the Target Object.
Must Obtain a Binding to the Target Object
 Requires a Check to See If the Client Has the
Permissions (Via the Privilege Attributes) to
Invoke an Operation on the Target Object (Via the
Control Attributes)
The Binding is Established, and a Reference to the
Target Object is Returned, Allowing the Invocation
The Ability to Obtain an Object Reference May
Involve Interaction with a Policy Object and the
Domain Manager
SOA+MW-1.110
Security Binding in CORBA
CSE
333
SOA+MW-1.111
Domain Objects in CORBA
CSE
333
SOA+MW-1.112
CORBA: Security Considerations

CSE
333
Threat to CORBA System
 Authorized user gaining access to data that should be
hidden from him
 User masquerading as someone else; so that actions
are attributed to the wrong person
 Security controls being by-passed
 Eaves-dropping on communication line – gaining
access to confidential data
 Tampering with objects
 Lack of accountability
SOA+MW-1.113
CORBA: Security Considerations

CSE
333

Security Reference Model (SRM)
Security Specification is meta-model
 Specification that is comprehensive (MAC,
Encryption)
 Language Independent (C++, Java….)
SOA+MW-1.114
CORBA: Security
CSE
333
Encapsulated within IDL modules:

Security: basic interface and data
types
SecurityLevel1: most basic, provides
security feature to all app.
SecurityLevel2: permits access to
credentials & policies
SecurityAdmin: permits manipulation
of administrative features

API
 Which implements
abstraction defined
in the reference
model
Security Technology
 Constitutes
mechanisms like
encryption,
validation
SOA+MW-1.115
CORBA: Security Specifications
CSE
333

4 key aspects of security
 Confidentiality
User
Sponsor
 Authenticate – use principal
authentication Object



Security Service
Integrity
 Prevents undetected,
unauthorized modification of
messages
 Detects message addition,
deletion or change of order
Client
Application
ORB Core
Security Technology
User
Sponsor
Accountability
Availability
Principal
Authenticator
Object
Client
Application
Security
Current
Object
ORB
Credentials
Object
SOA+MW-1.116
CORBA: Security Specifications
CSE
333

Security Conformance Level
 Applications unaware
 Applications aware
User
Sponsor
 Policy controlling
 Policy enforcing
Client
Application
Security Service
ORB Core
Security Technology
User
Sponsor
Principal
Authenticator
Object
Client
Application
Security
Current
Object
ORB
Credentials
Object
SOA+MW-1.117
CORBA: Security
CSE
333
Client Application
Target Object
(Message Sender)
Execution Context
Credential
Identity
Privileges
Message
Domain
Policy
Enforcement
Code
Domain
Policy
Security Enforcement Subsystem
ORB
SOA+MW-1.118
CORBA: Understanding

CSE
333




Will run on any platform as long as ORB implementation
exist.
Provides extensibility, but is difficult
Does not provide cross-language inheritance and
exception capabilities
Responsibility of locating an object implementation is on
ORB
Parameters between client and remote objects: interface
types are passed by reference; others by value
SOA+MW-1.119
CORBA: Understanding

CSE
333


Does not attempt to perform general-purpose distributed
garbage collection
Exception handling is taken care by the Exception object
Provides location independence
SOA+MW-1.120
Microsoft’s .NET

CSE
333





.NET is Microsoft’s Solution to Enterprise Computing
and Interoperability
Aimed to Compete with Java/J2EE
Interoperability with Old (CORBA, COM) and New
(RMI)
Provide Uniform Programming Environment
Extension of C - C#
We’ll Briefly Compare/Contrast/Introduce .NET
SOA+MW-1.121
Security in .NET/Java

CSE
333


Secure Development and Execution Environments via
a Number of Different Capabilities:
 Code-Based Access Control - CBAC: Permission
for Code to Access Resources
 Role-Based Access Control - RBAC: Permission
for Users/roles to Access Resources
 Code Verification and Execution: Semantics,
Bytecode, Safe Execution Environment
 Secure Communication: Pass Data/messages
Securely
 Code and Data Integrity: No Unauthorized Code
Modification, Cryptography
Our Objective - Explore their Attainment in .NET
Apply Similar Framework to J2EE for Comparison
SOA+MW-1.122
.NET Security Capabilities

CSE
333
Important Initial Definitions
 Assembly: Refers to Compiler Generated Code,
Specifically, Microsoft Intermediate Language
(MSIL)
 Evidence: Refers to the “Proof” that is Supplied
Regarding Identity
 Permissions: Refers to a Privilege that is Given to
Perform an Operation on a Resource
 In the Case of an Assembly, the Permission Set for All
Allowable Privileges on All Required Resources

We’ll Revisit in Later Slides in more Detail
SOA+MW-1.123
.NET Security Execution Model

CSE
333
Three Components:
 Hosting Environment is Attempting to Execute
an Application
 Must Provide Both the Code (Via Assembly) and Its
Identity (Via Evidence) in Its Interactions With CLR


Common Language Runtime (CLR) Provides a
Secure Execution Environment Through Managed
Code and Code Access Security
CLR Contains the Security System That Realizes
Policy Files Comprised of Rules Defined by a
Security Administrator (Security Setting)
 The Rules Allow Permission Sets to Different Types of
Code or Users Based on Evidence
SOA+MW-1.124
.NET Security Execution Model
CSE
333
SOA+MW-1.125
C# vs. Java - Differences/Similarities

CSE
333

Class Hierarchies
 Both have Single Rooted Class Hierarchies
System.Object and Java.Lang.Object
 Both Classes have Methods Sharing Some
Similarities and Difference
Execution Environment
 JAVA Compiled to Bytecodes
 Interpreted or Natively Compiled and Run in Managed
Execution Environment JVM

C# Code Gets Compiled to MSIL (Microsoft
Intermediate Language) which Runs in CLR
 C# Code is Never Interpreted, it is Always Natively
Compiled C#’s MSIL is More Type Neutral
SOA+MW-1.126
C# vs. Java - Differences/Similarities

CSE
333
Access Modifiers
C# access modifier
(Continued)
Private
Public
Internal
protected
internal protected

Java access modifier
Private
public
protected
N/A
N/A
Serialization and Documentation
 C# supports XML format as well as binary format
for serialization while Java only supports binary
format by default.
 JAVA uses Javadoc while C# uses XML for
documentation
SOA+MW-1.127
.NET Security Capabilities

CSE
333


Code-based Access Control - CBAC:
 Giving Permissions at the Code Level to Access
Resources
 Based on the Application Domain That the Code is
Assigned to (Information in Evidences)
Role-based Access Control - RBAC:
 Giving Permissions to a User to Access Resources
Based on the User’s Role in the System
Secure Code Verification & Execution:
 Similar in Concept to Bytecode Verification in
Java, MSIL in .NET
 Insures That the Executing Code is Staying Within
Its Allowed Domain
SOA+MW-1.128
.NET Security Capabilities

CSE
333

Secure Communication
 Provides the Ability to Pass Data and Messages
Locally or Remotely in a Secure Manner
 Avoids Both Intentional and Inadvertent
Data/message Modification
Secure Code and Data Protection:
 Insures That Code Hasn’t Been Modified Without
Authorization
 Utilizes Cryptographic Solutions and Signed
Distribution Files
SOA+MW-1.129
.NET Code-Based Access Control

CSE
333


The Determination of What a Piece of Code is
Allowed to Do is Decided by the Origins and
Intentions of the Code Itself
Can Be Decomposed Into Evidence Based Security,
Permissions, and a Security Policy
During Execution, the CLR
 Reviews Evidence of an Assembly
 Determines an Identity for the Assembly
 Looks up and Grants Permissions Based on the
Security Policy for That Assembly Identity
SOA+MW-1.130
.NET CBAC Evidence Based Security

CSE
333



Used by the CLR to Determine the Origin(s) of an
Assembly
At Runtime the CLR
 Examines the Meta-data of an Assembly to
Determine the Origin of the Code
 Determine the Creator of the Assembly
 Determine the URL and Zone That the Assembly
Came From
A Zone Represents the Domain That the Assembly Is
From, E.G., Internet, LAN, Local Machine, Etc.
The Association of the Meta-data and Its
Corresponding Assembly Is Verified by the CLR
SOA+MW-1.131
.NET CBAC Permissions

CSE
333




An Assembly will Request Permissions to Execute
Requests are Answered at Runtime by the CLR,
Assuming that the Assembly Has Provided Evidence
Partially Denied Requests; the CLR Dynamically
Assigning the Assembly a Lower-level Permission
Than Requested
Permissions are Grouped Into Sets Where Each Set
Has the Same Level of Security and Trust
Example:
 An Assembly that has Originated From the
Internet Zone May Be Granted an Internet
Permission Set that Pertains to the Execution of
Un-trusted Code, Allowing the Behavior of Nonlocal Code to Be Tightly Controlled
SOA+MW-1.132
.NET CBAC Security Policies (SPs)

CSE
333




The Grouping of Assemblies Establishes Different
Security Policies for Different Code Groupings
Security Policy Groups Are Hierarchically
Categorized Based on the Identity That the CLR
Determines From the Evidence in the Meta-data
An Actual Security Policy can be Specified As
Permissions for All Assemblies in a Group
This is Accomplished Using Security Policy Files to
Capture Security Requirements
A Policy File May Limit the Permissions of Another
Policy File, but Can’t Entirely Restrict It
SOA+MW-1.133
.NET CBAC Security Policies

CSE
333




SP is Set by an Admin to Make Permission Decisions
for Assemblies and Domains
Three Policies: Total Enterprise, Machine Executing
Code, Requesting User
Any Policy File May Partially Restrict Permissions of
Another Policy File
SP Groups Code into Hierarchical Categories Based
on Identity Determined by the CLR
SP Determines Permissions for Assembly After Code
is Grouped and Categorized
SOA+MW-1.134
.NET Role-Based Access Control

CSE
333




A Role Represents a Logical Grouping of Users (e.g.,
in a Health Care Application: Physician, Nurse)
.NET Uses Role-based Security to Authenticate an
Identity and to Pass on That Identity to Resources
Resources Authorize the Users Playing Roles Access
According to Policies and Permissions
Principal Defines a Role Membership, and the
Permissions of Role-based Security are Managed by
the Principalpermission Object
Windows Authentication, Passport Authentication, IIS
Authentication, Impersonation Authentication
SOA+MW-1.135
.NET Secure Code Verification/Execution

CSE
333




Security Checks Verified During the Code Execution:
 Stack Integrity, Bytecode Structure, Accessibility
 Buffer Overflows, Semantics
‘Java Sandbox’ of .NET is Called the Application
Domain
Multiple Assemblies May Be Loaded into the Same
Application Domain
No Way for an Object to Directly Reference Another
Object in a Different Application Domain
All of the Security Checks to Verify Code are Done
on Managed Code in a the CLR
SOA+MW-1.136
.NET Secure Communication

CSE
333



Transmission and Communication of Sensitive Data
Across Systems Must Be Securely Accomplished
Secure Communications Occurs at the Application
Level Via SSL and Transport Layer Security (TLS)
.NET Applications Can Use the Windows SSPI, but
Only As Unmanaged Code With Managed Wrappers
.NET Promotes the Exclusive Use of IIS
 IIS Supports SSL and TLS
 But IIS has an Extensive History of Security
Flaws
SOA+MW-1.137
.NET Secure Code and Data Protection

CSE
333




Any Code/data Loaded by the System Must Supply
 Evidence of Its Source, Version Signature
 Proof That There Hasn’t Been Any Unauthorized
Modification
.NET Uses Strong-named Assemblies That Include
the Assembly Name and Version Information
Assemblies Are Signed With an RSA Keypair
Nullifying the Chance of Unauthorized Modification
Version Information is Included in Order to Avoid
DLL Conflicts During Execution
.Net’s Encryption Functionality is Tied to the
Windows Cryptographic API
SOA+MW-1.138
J2EE Security Capabilities

CSE
333



Platform Independent Java Bytecode That Is Able to
Execute Either Locally or Remotely
Bytecode Execution Process Involves a Number of
Different Components:
 The Class Loader (With Bytecode Verifier)
 Java Class Libraries (Apis)
 Java Virtual Machine (JVM) Which Interacts With
the OS
All Three Provide a Secure Runtime Environment
The Security Manager and Access Controller
Examine and Implement the Security Policy
SOA+MW-1.139
J2EE Security Capabilities
CSE
333
SOA+MW-1.140
J2EE Code-Based Access Control

CSE
333





CBAC Implemented Through the JVM, Class Loader,
and the Security Manager and Access Controller.
The Hierarchy of the Class Loader Prevents
Unauthorized and Untrusted Code From Replacing
Any Code in the Base Classes
Multiple Class Loaders Are Permitted, Each With Its
Own Namespace, Are Simultaneously Active.
Namespaces Allow the JVM to Group Classes Based
on Where They Originated (Local, Remote)
Namespaces Insure an Application Can’t Affect the
Rest of the Runtime Environment
Bytecode Verifier: All Untrusted Code Is Verified
Before Permitting Execution Within a Namespace
SOA+MW-1.141
J2EE CBAC: The Security Manager

CSE
333





The Security Manager Enforces the Boundaries
Around the Sandbox by Implementing and Imposing
the Security Policy for Applications
All Classes Must Ask the Security Manager for
Permission to Perform Certain Operations
By Default, an Application Has No Security Manager,
So All Operations Are Allowed
Java Only Has Two Security Policy Levels, One for
the Executing Machine, and One for the User
Each Level Can Expand or Restrict All of the
Permissions of Another Level
There Can Be Multiple Policy Files at Each Level
SOA+MW-1.142
J2EE CBAC Permissions

CSE
333




Permissions Are Determined by the Security Policy at
Runtime
Granted by the Security Policy Based on Evidence, a
Publisher Signature and Location Origin
Permissions Are Also Grouped Into Protection
Domains (Similar to Security Policy Domains in
CORBA and to Security Policy Files in .NET)
Permissions Are Associated With Groups of Classes
in Java, and Classes Are Grouped by Their Origins
CBAC Isn’t Automatic in J2EE, but Requires
Programmatic Effort by the Software Engineer
SOA+MW-1.143
J2EE Role-Based Access Control

CSE
333



J2EE Uses the Java Authentication and Authorization
Service (JAAS)
JAAS: an Integrated Package That Implements a Java
Version of the Pluggable Authentication Module
(PAM) Framework
Using JAAS, Software Engineers Are Allowed to
Modify and Then Plug-in Domain/application
Specific Authentication Modules
JAAS Currently Supports Authentication Methods
Including Unix, JNDI, and Kerberos
SOA+MW-1.144
J2EE Secure Code Verification/Execution

CSE
333




J2EE Security Checks Are Performed During the
Code Execution Process, and Have Their Roots in the
JVM and JRE.
Java Interprets Compiled Bytecodes
A Bytecode Verifier Traverse the Bytecodes Before It
Goes to the Just-in-time (JIT) Compiler or JVM.
Java's ‘Sandbox’ Protected Domains, Are Similar to
Application Domains in .NET
Protected Domains Constitute an Extension of the
Sandbox, Determining the Domain and Scope in
Which an Application Can Execute
SOA+MW-1.145
J2EE Secure Code Verification/Execution

CSE
333

Two Different Protected Domains Can Interact
 Through Trusted Code
 Explicit Consent of Both Parties (Remotely
Possible in .NET)
An Object Can Access Another Object in Another
Protection Domain
 As Long As They Were Both Loaded From the
Same Class Loader
 This Is Due to the Hierarchical Class Loader
Structure
SOA+MW-1.146
J2EE Secure Communication

CSE
333



Like .NET, J2EE Supports Secure Sockets Layer
(SSL) and Transport Layer Security (TLS)
Java Provides Java Secure Sockets Extensions (JSSE)
for Implementing Secure Communications
JSSE Is a Configurable and Flexible Solution That
Uses SSL and TLS to Create a Secure Connection
Using Sockets (Sslsocketfactory)
The Secure Connection Can Be Used for Remote
Method Invocations (RMI)
SOA+MW-1.147
J2EE Secure Code and Data Protection

CSE
333




J2EE Provides Java Cryptography Extensions (JCE)
and Java Cryptography Architecture (JCA)
Java Provides the Functionality of a Message Digest
Algorithm for Use of Digital Signatures
A Supplier Bundles Java Code Into a JAR (Java
Archive), Signing the File With a Digital Signature
The JAR is Released As a Version, and the Client Can
Verify the Authenticity of the Supplier by Verifying
the Signature
An Unsigned Class May Be Added to a JAR File, but
Not to a Package Within a JAR File
SOA+MW-1.148
Java CBAC vs. .NET CBAC

CSE
333







Permissions Are Grouped Into Protection Domains
and Associated W/ Groups of Classes
Permissions Are Grouped Into Sets and Associated
with Code Groups
Classes Are Grouped by Their Origin Like Code Is
Categorized by Assembly’s Zone
No Security Manager by Default in Java
J2EE Has 2 Security Policy Types:
 Executing Machine & Requesting User
.NET Provides a Lot of Standard Permissions
Stronger Credentials Needed for Permissions in .NET
(Evidence)
SP Files Are More Configurable in Java, but Doesn’t
Help W/o All Perm Sets
SOA+MW-1.149
J2EE RBAC vs. .NET RBAC

CSE
333






.Net Supports Both Imperative and Declarative Role
Permission Checking
Java Servlets Provide Declarative Checking at the
Servlet Level
EJB’s Provide Declarative Checking Down to Method
Level
JAAS Provides Imperative Checking Within Method
Level
.Net Flexibility is Limited Severely
IIS is Only Supported Server of .Net Framework
Passport Requires Users to Be Members of Microsoft
Passport Service
SOA+MW-1.150
Code Verification/Execution

CSE
333






Prevent System Weaknesses Exposure by Application
Errors; Malicious or Not
.NET and Java Perform Security Checks During Code
Execution
Stack Integrity, Bytecode Structure, Buffer
Overflows, Semantics
Application Domains Have Static Boundaries
Protection Domains Have Dynamic Boundaries
All Security Checks to Verify Code Are Done on
Managed Code
Both .NET and Java Allow Unmanaged Code to
Bypass the CLR and JRE
SOA+MW-1.151
Concluding Remarks

CSE
333


Objective of this Material:
 Detail Security Requirements for Middleware
(CORBA’s Meta Model)
 Illustrate the Realization of the Meta-Model
(Microsoft’s .NET and Java’s J2EE)
 Compare and Contrast .NET and J2EE
Touching Only Surface of Capabilities and
Functionalities
See Paper on Web Site and Various References for
Additional Detail
SOA+MW-1.152
Interoperability via Architectures

CSE
333


Reviewing Simple 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
Explore Java Based Architectural Variants
 Two Tier
 Three Tier
 Four Tier
Pros/Cons – What to Use When?
SOA+MW-1.153
Java Client to Legacy App via RDBS
CSE
333
Transformed
Legacy Data
Java Client
Updated Data
Relational
Database
System(RDS)
Extract and
Generate Data
Transform and
Store Data
Legacy
Application
SOA+MW-1.154
ORB with Java Client & Legacy Application
CSE
333
Java Client
Legacy
Application
Java
Wrapper
Object Request Broker (ORB)
CORBA is the Medium of Info. Exchange
Requires Java/CORBA Capabilities
SOA+MW-1.155
Wrapped Java Client to Legacy Application
CSE
333
Java Client
Java Application Code
WRAPPER
Mapping Classes
JAVA LAYER
Interactions Between Java Client
and Legacy Appl. via C and RPC
C is the Medium of Info. Exchange
Java Client with C++/C Wrapper
NATIVE LAYER
Native Functions (C++)
RPC Client Stubs (C)
Legacy
Application
Network
SOA+MW-1.156
Two-, Three-, & Four-Tier Architectures
CSE
333
From: http://java.sun.com/javaone/javaone98/sessions/T400/index.html
SOA+MW-1.157
Wombat Securities

CSE
333






Web Access to Brokerage Accounts
Only HTML Browser Required on Front End
"Brokerbean" EJB Provides Business Logic
Login, Query, Trade Servlets Call Brokerbean
Use JNDI to Find EJBs, RMI to Invoke Them
Order and History Records from Java Blend Product
Records Mapped to Oracle Tables, JDBC Calls
SOA+MW-1.158
Four-Tier Architecture Example
CSE
333
SOA+MW-1.159
Nocturnal Aviation, Inc.

CSE
333






Passenger Check-in for Regional Airline
Local Database for Seating on Today's Flights
Clients Invoke EJBs at Local Site Through RMI
EJBs Update Database and Queue Updates
JMS Queues Updates to Legacy System
DBC API Used to Access Local Database
JTS Synchs Remote Queue With Local Updates
SOA+MW-1.160
Three-Tier Example
CSE
333
SOA+MW-1.161
Santa Cruz Widgets

CSE
333





Small Manufacturer Previously on C++
New Order Entry, Inventory, and Invoicing
Applications in Java Programming Language
Existing Customer and Order Database
Most of Business Logic in Stored Procedures
Tool-generated GUI Forms for Java Objects
Located Company on Web Using Widgets and Tcl, but
Not Widgets and Java
SOA+MW-1.162
Santa Cruz Widgets (2-tier)
CSE
333
SOA+MW-1.163
Architecture Comparisons

CSE
333




Two-tier Through JDBC API: Simplest
Multi-tier: Separate Business Logic, Protect Database
Integrity, More Scaleable
JMS Queues Vs Synchronous (RMI or IDL):
 Availability, Response Time, Decoupling
JMS Publish & Subscribe: Off-line Notification RMI
IIOP Vs JRMP Vs Java IDL:
 Standard Cross-language Calls or Full Java
Functionality
JTS: Distributed Integrity, Lockstep Actions
SOA+MW-1.164