Service-Oriented Architectures/Middlware

1
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
steve_at_engr.uconn.edu http//www.engr.uconn.edu/st
eve (860) 486 - 4818
Special Thanks to Prof. Alex Shvartsman, Keith
Bessette, Scott Craig and Prior CSE333 students
for providing portions of this material.
2
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!

3
What is a Distributed Application?
Network Centric Environment
System of Systems
High-Availability
Performance
Heterogeneity Hardware OS, PLs
Dynamic Environment
Increase Productivity
New/Innovative Information Use
Transparent Interoperation
4
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.

Database
COTS
Legacy
Legacy Client
GOTS
NETWORK
GOTS Client
Legacy
Database
Database Client
COTS Client
5
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

6
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!

7
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?

8
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
  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

9
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
10
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

11
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

12
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
  Java
• .NET Microsofts Forward into the Modern Market
  C

13
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.

14
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

15
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

16
Objectives of SOA

• 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?

17
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

18
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

19
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
20
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

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

• Allow Interactions from Client to Server CORBA
• Installed on All Participating Machines

23
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

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

25
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

26
ORB and High Level View of Requests

• The Request Consists of
• Target Object
• Operation (Method)
• Parameters
• Request Context (Optional)

27
CORBA Components and Interfaces

• 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

28
Interfaces

• 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

29
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

30
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

31
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

32
CORBA

• 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

33
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

34
CORBA POA Policies

• 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

35
CORBA POA Policies

• 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

36
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

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

38
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

39
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.
40
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.
41
Three Types of Implementations

• Single Process one shot Object
• Multi-Threaded resident Object

Implementation is a permanent or resident
multi-threaded process
42
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
43
Interface Definition Language, IDL

• 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

44
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
  operation.

45
IDL Basic Types
46
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

47
IDL Complex Types (cont.)

• Sequences One-dimensional array with maximum
  size (fixed at compile time) and length (set at
  run time).
• Unbounded Sequencetypdef sequenceltlonggt
  longSeq
• 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.

48
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
49
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 //
SERVER_IDL
50
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

51
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

52
Java Computing Architecture and JINI
53
JINI Components and Dependencies
Programming Model
Services
Infrastructure
Base Java
Java VM
Java APIs
JNDI
RMI
JavaBeans
Enterprise Beans
Java Security
JTS
JMS
Java JINI
54
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

55
Discovery by Resource Client
JINI Lookup Service
JINI Lookup Service
Discovery to Register Services
Discovery to Locate Services
Client
56
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

57
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

58
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

59
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
  Setting
• Leading to Ease in Constructing, Maintaining,
  and Evolving Network Centric Applications

60
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

61
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

62
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!
63
JINI Support for Distributed Computing
64
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
65
Two Example Resources

• 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)

66
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
oveCourse()
JINI Lookup Service
University DB Resource (UDB)
Military Requisition DB Resource
67
Join, Lookup, and Service Invocation
Lookup Service
Registry of Entries
Client
1. Client Invokes AddCourse(CSE900) on
Resource 2. Resource Returns Status of Invocation
68
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

69
Execution Process of Client using JINI
70
Services Console
71
Services GUI
72
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

73
.NET Architecture and Usage

• Three Level Architecture
• XML and DataSet as Objects of Interaction

74
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
  Handling
• Garbage Collection and Memory Management
• Note Akin to Java Runtime Environment
• ASP.NET
• This Component Provides a Layer of Classes for
  Web Services

75
What are .Net Components?

• 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
• Low Level Classes Capture Core .Net Functionality
• Provides Infrastructure for Construction of
  Remaining .net Framework Classes

76
Remoting in .Net

• Remoting Makes an Object in One Process Available
  to an Application in Another Process (Akin to
  RMI)
• 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

77
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
78
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

79
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
80
Web Services ASP.NET

• Communication Based on Open Protocols
• Data via XML
• Schema via XSD
• Other Supported Protocols Inlcude
• UDDI
• DISCO
• WSDL
• SOAP

81
ADO.NET Architecture
82
CORBA vs. JINI vs. .NET

• 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

83
Brief Comparison

• Database Connectivity
• Java uses JDBC and .Net uses Ado.net 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

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

85
Overview

• 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

86
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
  Products
• Characterizable as Implementations or Instances
  of the CORBA Security Meta-model
• Transition Concepts into Platform Specific
  Implementations

87
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
  Information
• Delegation of this Authorization Between Users is
  Tightly Controlled

88
CORBA Security Capabilities

• 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

89
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
  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

90
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

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

93
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
  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.

94
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

95
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

96
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
• 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

97
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

98
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

99
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.

100
CORBA Security Execution Model

• 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

101
Security Binding in CORBA
102
Domain Objects in CORBA
103
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

104
.NET Security Capabilities

• 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
• Well Revisit in Later Slides in more Detail

105
.NET Security Execution Model

• 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

106
.NET Security Execution Model
107
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

108
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
  documentation

(Continued)
109
.NET Security Capabilities

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

110
.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
  Authorization
• Utilizes Cryptographic Solutions and Signed
  Distribution Files

111
.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

112
.NET CBAC Evidence Based Security

• 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

113
.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

114
.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
  It

115
.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

116
.NET Role-Based Access Control

• 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

117
.NET Secure Code Verification/Execution

• 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

118
.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
  Flaws

119
.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
  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
• .Nets Encryption Functionality is Tied to the
  Windows Cryptographic API

120
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

121
J2EE Security Capabilities
122
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

123
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

124
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

125
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

126
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
  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

127
J2EE Secure Code Verification/Executi