Service-Oriented Architectures/Middlware - PowerPoint PPT Presentation

1 / 145
About This Presentation

Service-Oriented Architectures/Middlware


Special Thanks to Prof. Alex Shvartsman, Keith Bessette, ... Arbitrate and Interact. Role of Lookup for Service Discovery. Interface Definition Language (IDL) ... – PowerPoint PPT presentation

Number of Views:84
Avg rating:3.0/5.0
Slides: 146
Provided by: stevenad


Transcript and Presenter's Notes

Title: Service-Oriented Architectures/Middlware

Service-Oriented Architectures/Middlware
Prof. Steven A. Demurjian Computer Science
Engineering Department The University of
Connecticut 371 Fairfield Road, Box
U-2155 Storrs, CT 06269-2155 http//
eve (860) 486 - 4818
Special Thanks to Prof. Alex Shvartsman, Keith
Bessette, Scott Craig and Prior CSE333 students
for providing portions of this material.
What is a Distributed Application?
  • 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!

What is a Distributed Application?
Network Centric Environment
System of Systems
Heterogeneity Hardware OS, PLs
Dynamic Environment
Increase Productivity
New/Innovative Information Use
Transparent Interoperation
Another View Todays Reality
  • 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.

Legacy Client
GOTS Client
Database Client
COTS Client
Why is Distributed Computing Needed?
  • Todays 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

Striving for New Techniques/Technologies
  • We Must Diverge from Business as Usual
  • C Programming with RPC
  • Customized Development without Reuse
  • Solutions that Arent Extensible and Evolvable
  • Cobbling Together Solutions w/o Method or Reason
    is Unacceptable and Doomed to Fail!
  • We Must Face Todays 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!

Who are the Players?
  • 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?

Why a Distributed Application?
  • Reasons
  • Data used is Distributed
  • Computation is Distributed
  • Application Users are Distributed
  • 2 Key Issues for Solution
  • Platform-Independent Models and Abstraction
  • 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

Distributed Systems
Fundamental Realities of Distributed Systems
Co-located Distributed
Communication Fast Slower
Failures Objects fail together Objects fail separately, Network can partition
Concurrent Access Only with multiple threads Yes
Secure Yes Not InherentlyOften Add-On Capability
What is a Service Oriented Architecture?
  • 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

Service Oriented Architectures (SOA)
  • 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

Middleware-Based SOA
  • 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
  • .NET Microsofts Forward into the Modern Market

Web-Based SOAs
  • While Not our Focus Important to Understand
    their Role in SOA
  • From Web Services Architecture, W3CA 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
    Web-related standards.

Web Services Architecture from W3C
  • Complex Architecture with Many Different
    Capabilities and Features
  • Open Ended (Like Web)
  • Target Multiple Domains/Usages
  • Current Web and Future (Emerging?) Semantic Web

What Must All SOA Provide?
  • 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

Objectives of SOA
  • Can SOAs Support Highly-Available Distributed
  • 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?

Overview of Presentation
  • Objective is to Explore CORBA, JINI, and .NET
  • Various Aspects of Three Technologies
  • Overall Architecture
  • Interoperability Capabilities
  • Access and Usage
  • 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

What is CORBA?
  • 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

What is CORBA?
  • 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 Ot
hers Perl Haskell Python Eiffel PHP/ORBit
What is CORBA?
  • 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

What is CORBA?
  • 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)

Object Life Cycle Naming Events Relationships Exte
rnalization Transactions Trader Query Property
What is CORBA?
  • Allow Interactions from Client to Server CORBA
  • Installed on All Participating Machines

CORBA Architectural Goals
  • 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

Role of an Object Request Broker (ORB)
  • 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
  • Caller and the Object Implementation Can be in
    the Same Process thru Opposite Sides of the World
  • ORB Manages Local Location and Optimization

Interface Definition Language, IDL
  • 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

ORB and High Level View of Requests
  • The Request Consists of
  • Target Object
  • Operation (Method)
  • Parameters
  • Request Context (Optional)

CORBA Components and Interfaces
  • Client Stub Client Invokes a Particular Object
  • 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

  • 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

CORBA Repositories
  • Interface Repository
  • Client access to definitions
  • Type checking for signatures
  • Traversal of inheritance graphs
  • Implementation Repository
  • Location of implementation
  • Activation information
  • Administration control
  • Security
  • Resource allocation

Client Side
  • 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

Object Implementation Side
  • 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

  • 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

CORBA POA Policies
  • Provided to Programmer for Control Over an
    Objects 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

CORBA POA Policies
  • Thread Policy - Depends on Number of Objects the
    Application Will Have
  • Depends on Operating System
  • Expected Load on System
  • Life Span Policy - Transient object cannot live
    beyond the process which created it
  • Persistent object can live beyond the process
    which created it
  • Object ID Uniqueness Policy

CORBA POA Policies
  • ID Assignment Policy - To specify whether Object
    ID was generated by the application or ORB
  • Servant Retention Policy States if POA retains
    active servants in object map
  • Request Processing Policy States how request
    processed by the POA
  • Implicit Activation Policy Indicates if Implicit
    activation of servants is supported by POA

Dynamic Invocation Interface (DII)
  • DII Allows Clients to Dynamically
  • Discover Objects
  • Discover Objects Interfaces
  • Create Requests
  • Invoke Requests (-gt 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

Request Components
  • 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
  • Request Handle -- the Id. For This Request

Repositories Interface and Implementation
  • 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

Three Types of ORBs
  • Single Process Library Resident
  • Client and Implementation Resident

ORB and implementations implemented as libraries
(routines) resident in the client.
ORB implemented as libraries (routines) resident
in the clients and in the implementations.
Three Types of ORBs
  • Server or Operating System Based

ORB is implemented as a server (separate
process) which brokers requests between client
and implementation processes. ORB is part of
the operating system.
Three Types of Implementations
  • Single Process one shot Object
  • Multi-Threaded resident Object

Implementation is a permanent or resident
multi-threaded process
Three Types of Implementations
  • Multi-Process Object

Implementation is a set of processes dedicated
to a particular (group of) method(s) Processes
can be distributed
Interface Definition Language, IDL
  • Language used to describe the interfaces that
    client objects call and object implementations
  • 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

IDL Modules and Interfaces
  • 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

IDL Basic Types
IDL Complex Types
  • 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

IDL Complex Types (cont.)
  • Sequences One-dimensional array with maximum
    size (fixed at compile time) and length (set at
    run time).
  • Unbounded Sequencetypdef sequenceltlonggt
  • Bounded Sequencesequenceltlong,10gt fieldname
  • Strings Declared using keyword string. May be
    bounded or unbounded.
  • string namelt32gt //bounded
  • Arrays Multidimensional, fixed-size arrays of
    any IDL data type.

IDL Example GUI
/ File Name GUI.idl / ifndef
GUI_IDL define GUI_IDL module GUI struct
timespec_t long tv_sec long
tv_nsec struct Dialog1Data_t
timespec_t DataTime float val
struct Dialog2Data_t timespec_t DataTime
long val interface MainWindow
void logEvent(in timespec_t timestamp,
in string val)
interface Dialog1 void update(in
Dialog1Data_t val) interface Dialog2
void update(in Dialog2Data_t val)
endif // GUI_IDL
IDL Example Server
/ File Name Server.idl / ifndef
SERVER_IDL define SERVER_IDL include
"GUI.idl" interface Server enum reason_t
NotInitialized, ErrorDetected
exception NotAvailable reason_t reason
exception OperationTimeout void
registerMainWindow( in GUIMainWindow val,
in boolean flag) raises (OperationTimeout)
void setMainWindowEnabled( in boolean
flag) raises (OperationTimeout)
void registerDialog1( in GUIDialog1 val,
in boolean flag) raises (OperationTimeout)
void setDialog1Enabled( in boolean flag)
raises (OperationTimeout) GUIDialog1Data_t
getDialog1Data() raises (OperationTimeout,
NotAvailable) void registerDialog2( in
GUIDialog2 val, in boolean flag) raises
(OperationTimeout) void setDialog2Enabled(
in boolean flag) raises (OperationTimeout)
GUIDialog2Data_t getDialog2Data() raises
(OperationTimeout, NotAvailable) endif //
What is JINI?
  • 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

Suns JINI Technology
  • 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

Java Computing Architecture and JINI
JINI Components and Dependencies
Programming Model
Base Java
Java VM
Java APIs
Enterprise Beans
Java Security
How Does JINI Work?
  • Distributed Application Constructed Using One or
    More Lookup Services
  • Lookup Service Support Interactions by
  • Resources Advertise ServicesDiscover,
    Register Services, Renew Lease
  • Client Locate/Utilize ServicesDiscover,
    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

Discovery by Resource Client
JINI Lookup Service
JINI Lookup Service
Discovery to Register Services
Discovery to Locate Services
Basic JINI Concepts
  • 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

Basic JINI Concepts
  • 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

JINI Resources Services
JINI Lookup Service
  • Suns Initial Perspective
  • JINI for Hardware
  • Printers, Digital Cameras, etc.
  • Plug-and-Play on Network
  • PrinterActions Class Defines the Component that
    is Registered with JINI

Objectives and Utility of JINI
  • 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
  • Leading to Ease in Constructing, Maintaining,
    and Evolving Network Centric Applications

How Does JINI Work?
  • 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

JINI Concepts and Terms
  • 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

Registration Leasing
  • 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!
JINI Support for Distributed Computing
Component Perspective and JINI
  • Resources as Components
  • Resources Provide Services
  • What Service Provides Component Interface
  • Clients, Servers, Resources, Use Component
    Interface to Design/Construct Functionality

JINI Lookup Service
Two Example Resources
  • University Application
  • Students can Register/Drop Courses and Check the
  • Faculty can Alter Course DB and Check the
  • 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)

What Does an Actual System Look Like?
Java GUI UDB Client
Java GUI MDB Client
MDBServer GetParts GetRequisition GetReqParts Writ
eParts WriteRequisition DeletePart DeleteRequisiti
on AddParts RemovePart AddRequisition
UDBServer Service GetClasses() PreReqCourse() Ge
tVacantClasses() EnrollCourse() AddCourse() Rem
JINI Lookup Service
University DB Resource (UDB)
Military Requisition DB Resource
Join, Lookup, and Service Invocation
Lookup Service
Registry of Entries
1. Client Invokes AddCourse(CSE900) on
Resource 2. Resource Returns Status of Invocation
Services of Military Application
  • 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

Execution Process of Client using JINI
Services Console
Services GUI
What is .NET?
  • .NET is Microsofts Solution to Enterprise
    Computing and Interoperability
  • Aimed to Compete with Java/J2EE
  • Interoperability Old (CORBA, COM) New (RMI)
  • Provides Uniform Programming Environment via
    Extension of C - C

.NET Architecture and Usage
  • Three Level Architecture
  • XML and DataSet as Objects of Interaction

What are .Net Components?
  • CTS (Common Type System)
  • Defines Common Standard for Languages
  • CLR (Common Language Runtime)
  • Manages the Execution of a .Net Application
  • Provides Cross Platform Support By Ensuring
  • Type Safety, Code Verification, Exception
  • Garbage Collection and Memory Management
  • Note Akin to Java Runtime Environment
  • This Component Provides a Layer of Classes for
    Web Services

What are .Net Components?
  • Windows Forms
  • Provides A Layer Of Classes For The Windows User
  • Provides Classes for Data Access Including
    Database and XML
  • Base Class Library
  • Low Level Classes Capture Core .Net Functionality
  • Provides Infrastructure for Construction of
    Remaining .net Framework Classes

Remoting in .Net
  • Remoting Makes an Object in One Process Available
    to an Application in Another Process (Akin to
  • Marshalling Enables a Controlled Data
    Communication Between the 2 Processes
  • Marshalling an Object Can Occur in 2 Ways
  • Marshall By Value
  • Server Creates a Copy of the Object and Passes
    the Copy to the Client
  • Marshall By Reference
  • Server Creates a Reference of the Object and
    Sends this Reference to the Client

Remoting in .NET
When a client calls an object marshalled by
reference of the object in the clients
application domain and the client uses that proxy
to access that original object on the server
Remoting in .NET
  • 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 clients own
    process without making any additional calls to
    the server

Recall Similarity to RMI in Java
  • Java Objects in JVMs (on Different Computers)
    Transparently Invoke Each Other's Methods
  • RMI Enables Distributed Object Computing

Start rmiregistery
Web Services ASP.NET
  • Communication Based on Open Protocols
  • Data via XML
  • Schema via XSD
  • Other Supported Protocols Inlcude
  • UDDI
  • WSDL
  • SOAP

ADO.NET Architecture
  • Important to Differentiate Between
  • Standard (CORBA) Vendors Implement
  • Technologies (JINI, .NET)
  • Many Different Pros and Cons w.r.t.
    Infrastructure, Usage, Environment,
    Interoperability, Ease of Use, Programming
    Requirements, etc. etc. etc.
  • Many Different Perspectives to Compare
    Capabilities and Functionalities of Technologies

Brief Comparison
  • Database Connectivity
  • Java uses JDBC and .Net uses or ODBC.NET
  • Cross platform interoperability
  • J2EE and CORBA Easily Supports Interoperation
    .Net Focuses on Windows Platform
  • Programming Languages
  • .Net and CORBA Support Multiple Languages J2EE
    Focuses on Java (with Links to IDL)
  • Cross Vendor Interoperability
  • J2EE and CORBA Guaranteed by Specifications
    Microsoft is the only vendor for .Net
  • Remoting Strong Similarities Across All Three

Security in Middleware - Motivation
  • 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
  • Dramatic Turnaround in Support of Security within
    these Modern Middleware Platforms
  • Thanks to Keith Bessette

  • Focus on the Attainment of Security within
  • .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

Security in CORBA, .NET, and J2EE
  • 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
  • Characterizable as Implementations or Instances
    of the CORBA Security Meta-model
  • Transition Concepts into Platform Specific

CORBA Security Capabilities
  • 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
  • Delegation of this Authorization Between Users is
    Tightly Controlled

CORBA Security Capabilities
  • Accountability
  • Users Must be Responsible for All of their
  • 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

CORBA Security Capabilities
  • 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
  • Security Auditing for Accountability
  • Security of Communication Between Users and
  • Non-repudiation to Provide Proof of Access
  • Administration of All of the Security

The CORBA Security Model
  • 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

The CORBA Security Model
Access Control in CORBA
  • 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
  • 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

Access Control in CORBA
  • 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
  • Security Permissions
  • Identity (e.g., User Id) of the Principal
  • Role(s) of the Principal
  • Group(s) That the Principal Belongs to in the
  • 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.

Access Control in CORBA
  • 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

Access Control in CORBA
  • 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

Access Control in CORBA
  • 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 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
  • Group Can Be Managed As a Whole, Thereby Reducing
    the Needed Administrative Effort

Access Control in CORBA
  • 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

CORBA Security User Views
  • 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

CORBA Security Views
  • 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.)
  • Administrators 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.

CORBA Security Execution Model
  • Client Makes a Request to Access the Target
  • 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
  • The Ability to Obtain an Object Reference May
    Involve Interaction with a Policy Object and the
    Domain Manager

Security Binding in CORBA
Domain Objects in CORBA
Security in .NET/Java
  • 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

.NET Security Capabilities
  • Important Initial Definitions
  • Assembly Refers to Compiler Generated Code,
    Specifically, Microsoft Intermediate Language
  • 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
  • Well Revisit in Later Slides in more Detail

.NET Security Execution Model
  • Three Components
  • Hosting Environment is Attempting to Execute an
  • Must Provide Both the Code (Via Assembly) and Its
    Identity (Via Evidence) in Its Interactions With
  • 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

.NET Security Execution Model
C vs. Java - Differences/Similarities
  • 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 Cs MSIL is More Type Neutral

C vs. Java - Differences/Similarities
  • Access Modifiers
  • 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

.NET Security Capabilities
  • Code-based Access Control - CBAC
  • Giving Permissions at the Code Level to Access
  • 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 Users 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

.NET Security Capabilities
  • 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 Hasnt Been Modified Without
  • Utilizes Cryptographic Solutions and Signed
    Distribution Files

.NET Code-Based Access Control
  • 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

.NET CBAC Evidence Based Security
  • Used by the CLR to Determine the Origin(s) of an
  • 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
  • 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

.NET CBAC Permissions
  • 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 Non-local Code to
    Be Tightly Controlled

.NET CBAC Security Policies (SPs)
  • 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 Cant Entirely Restrict

.NET CBAC Security Policies
  • 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

.NET Role-Based Access Control
  • A Role Represents a Logical Grouping of Users
    (e.g., in a Health Care Application Physician,
  • .NET Uses Role-based Security to Authenticate an
    Identity and to Pass on That Identity to
  • 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

.NET Secure Code Verification/Execution
  • Security Checks Verified During the Code
  • Stack Integrity, Bytecode Structure,
  • Buffer Overflows, Semantics
  • Java Sandbox of .NET is Called the Application
  • 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

.NET Secure Communication
  • 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

.NET Secure Code and Data Protection
  • Any Code/data Loaded by the System Must Supply
  • Evidence of Its Source, Version Signature
  • Proof That There Hasnt Been Any Unauthorized
  • .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
  • Version Information is Included in Order to Avoid
    DLL Conflicts During Execution
  • .Nets Encryption Functionality is Tied to the
    Windows Cryptographic API

J2EE Security Capabilities
  • 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

J2EE Security Capabilities
J2EE Code-Based Access Control
  • 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 Cant Affect the
    Rest of the Runtime Environment
  • Bytecode Verifier All Untrusted Code Is Verified
    Before Permitting Execution Within a Namespace

J2EE CBAC The Security Manager
  • 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

J2EE CBAC Permissions
  • 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 Isnt Automatic in J2EE, but Requires
    Programmatic Effort by the Software Engineer

J2EE Role-Based Access Control
  • 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

J2EE Secure Code Verification/Execution
  • 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
  • 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

J2EE Secure Code Verification/Executi
Write a Comment
User Comments (0)