Title: Service-Oriented Architectures/Middlware
1Service-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.
2What 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!
3What 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
4Another 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
5Why 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
6Striving 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!
7Who 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?
8Why 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
9Distributed 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
10What 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
11Service 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
12Middleware-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
13Web-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.
14Web 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
15What 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
16Objectives 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?
17Overview of Presentation
- Objective is to Explore CORBA, JINI, and .NET
- Various Aspects of Three Technologies
- A
- B
- C
- D
- Comparison of CORBA, J2EE (Java), and .NET from
Security Perspective - What Does Each Support?
- Limits and Capabilities of Security Models
- Multi-Tier Architectural Solutions
- Examples of Various Architectures
- Interplay and Interactions of Technologies
18What 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
19What 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
20What 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
21What 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
22What is CORBA?
- Allow Interactions from Client to Server CORBA
- Installed on All Participating Machines
23CORBA 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
24Role 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
25Interface 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
26ORB and High Level View of Requests
- The Request Consists of
- Target Object
- Operation (Method)
- Parameters
- Request Context (Optional)
27CORBA 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
28Interfaces
- 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
29CORBA 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
30Client 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
31Object 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
32CORBA
- 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
33CORBA 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
34CORBA 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
35CORBA 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
36Dynamic 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
37Request 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
38Repositories 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
39Three 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.
40Three 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.
41Three Types of Implementations
- Single Process one shot Object
- Multi-Threaded resident Object
Implementation is a permanent or resident
multi-threaded process
42Three Types of Implementations
Implementation is a set of processes dedicated
to a particular (group of) method(s) Processes
can be distributed
43System Design with CORBA
Scott A. Craig Computer Science Engineering
Department The University of Connecticut Storrs,
Connecticut 06269-3155
scraig_at_engr.uconn.edu
44Overview of Presentation
- Introduction to OMG IDL
- Object Management Architecture
- CORBAservices
- Naming Service
- Event Service
- Typed Event Example
- References
- Concluding Remarks
45Interface 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
46IDL 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.
47IDL Basic Types
48IDL 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
49IDL 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.
50IDL 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
51IDL 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
52Object Management Architecture
- The Object Management Group, Inc (OMG) has
established the Object Management Architecture
(OMA), upon which OMG specifications are based - Components of the OMA Reference Model
- Object Request Broker (CORBA)
- Provides communications infrastructure.
- Object Services (CORBAservices)
- Collection of fundamental services (interfaces
and objects) for using and implementing objects. - Common Facilities (CORBAfacilities)
- Services such as system management.
- Application Objects
- Not standardized.
53CORBAservices
- OMG specification for Object Services
- Collection of 15 services (interfaces and
objects) that support basic functions for using
and implementing objects. - Interfaces specified using IDL
- Will focus on two services
- Naming Service
- Event Service
- Security Service Addresses identification and
authentication, authorization and access control,
security of communication between objects, etc. - Beyond scope of this presentation (specification
is 386 pages in length)
54Naming Service
- Facilitates locating objects in a distributed
system. - A name binding is a name-to-object association
and is always defined relative to a naming
context. - A naming context is an object that contains a set
of name bindings in which each name is unique. - Multiple names may be bound to an object.
- Servers bind names to objects and clients resolve
names to objects. - A naming context may be bound to a name in
another naming context creating a naming graph. - Directed graph with labeled edges in which nodes
are objects. - Compound names are formed by the sequence of
names along a path from the root to the leaf.
55References
- Object Management Group, Inc. (OMG),
http//www.omg.org - OMG, A Discussion of the Object Management
Architecture, 01/97 - OMG, The Common Object Request Broker
Architecture and Specification, Rev. 2.2, 02/98 - OMG, CORBAservices Common Object Services
Specification, 12/98 - T. J. Mowbray and R. Zahavi, The Essential CORBA
Systems Integration Using Distributed Objects,
John Wiley Sons, Inc., 1995 - G. Booch, J. Rumbaugh, I. Jacobson, The Unified
Modeling Language User Guide, AWL, Inc. 1999
56JINI
57What 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
58Suns 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
59Java Computing Architecture and JINI
60JINI Components and Dependencies
Programming Model
Services
Infrastructure
Base Java
Java VM
Java APIs
JNDI
RMI
JavaBeans
Enterprise Beans
Java Security
JTS
JMS
Java JINI
61How 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
62Discovery by Resource Client
JINI Lookup Service
JINI Lookup Service
Discovery to Register Services
Discovery to Locate Services
Client
63Basic 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
64Basic 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
65JINI 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
66Objectives 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
67How 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
68JINI 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
69Registration 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!
70JINI Support for Distributed Computing
71Component 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
72Two 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)
73What 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
74Join, Lookup, and Service Invocation
Lookup Service
Registry of Entries
Client
1. Client Invokes AddCourse(CSE900) on
Resource 2. Resource Returns Status of Invocation
75Services 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
76Execution Process of Client using JINI
77Services Console
78Services GUI
79Microsofts .NET
80.NET Framework Architecture
81.Net
- CTS (Common Type System)
- Defines Common standard that languages should
adhere to. - CLR (Common Language Runtime)
- Manages the execution of a .Net application,
provides cross platform support by ensuring type
safety, code verification, exception handling,
garbage collection and memory management - ASP.NET
- This component provides a layer of classes for
Web services
82.Net
- Windows Forms
- Provides a layer of classes for the windows user
interface - ADO.NET
- Provides classes for data access including
database and XML - Base Class Library
- Provides the low level classes on which most of
the .Net functionality and other gtnet Framework
classes are built
83Remoting
- Remoting makes an object in one process available
to an application in another process - Marshalling enables a controlled data
communication between the 2 processes - Marshalling an object can be done in 2 ways
- Marshall by valueServer creates a copy of the
object and passes the copy to the client - Marshall by reference The server creates a
reference of the object ans send this reference
to the client
84Remoting
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
85Remoting
- 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
86.NET Framework Architecture
87.Net
- CTS (Common Type System)
- Defines Common standard that languages should
adhere to. - CLR (Common Language Runtime)
- Manages the execution of a .Net application,
provides cross platform support by ensuring type
safety, code verification, exception handling,
garbage collection and memory management - ASP.NET
- This component provides a layer of classes for
Web services
88.Net
- Windows Forms
- Provides a layer of classes for the windows user
interface - ADO.NET
- Provides classes for data access including
database and XML - Base Class Library
- Provides the low level classes on which most of
the .Net functionality and other gtnet Framework
classes are built
89Remoting
- Remoting makes an object in one process available
to an application in another process - Marshalling enables a controlled data
communication between the 2 processes - Marshalling an object can be done in 2 ways
- Marshall by valueServer creates a copy of the
object and passes the copy to the client - Marshall by reference The server creates a
reference of the object ans send this reference
to the client
90Remoting
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
91Remoting
- 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
92Web Services ASP.NET
- Communication based on open protocols
- - Data XML
- -Schema XSD
- UDDI
- DISCO
- WSDL
- SOAP
- Security
93ADO.NET
94Security 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
95Overview
- 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
96Security 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
97CORBA 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
98CORBA 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
99CORBA 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
100The 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
101The CORBA Security Model
102Access 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
103Access 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.
104Access 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
105Access 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
106Access 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
107Access 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
108CORBA 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
109CORBA 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.
110CORBA 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
111Security Binding in CORBA
112Domain Objects in CORBA
113CORBA Security Considerations
- Threat to CORBA System
- Authorized user gaining access to data that
should be hidden from him - User masquerading as someone else so that
actions are attributed to the wrong person - Security controls being by-passed
- Eaves-dropping on communication line gaining
access to confidential data - Tampering with objects
- Lack of accountability
114CORBA Security Considerations
- Security Reference Model (SRM)
- Security Specification is meta-model
- Specification that is comprehensive (MAC,
Encryption) - Language Independent (C, Java.)
115CORBA Security
- API
- Which implements abstraction defined in the
reference model - Security Technology
- Constitutes mechanisms like encryption, validation
Encapsulated within IDL modules Security basic
interface and data types SecurityLevel1 most
basic, provides security feature to all
app. SecurityLevel2 permits access
to credentials policies SecurityAdmin
permits manipulation of administrative features
116CORBA Security Specifications
- 4 key aspects of security
- Confidentiality
- Authenticate use principal authentication
Object - Integrity
- Prevents undetected, unauthorized modification of
messages - Detects message addition, deletion or change of
order - Accountability
- Availability
117CORBA Security Specifications
- Security Conformance Level
- Applications unaware
- Applications aware
- Policy controlling
- Policy enforcing
118CORBA Security
Client Application (Message Sender)
Target Object
ORB
Security Enforcement Subsystem
Execution Context
Message
Domain
Credential
Policy Enforcement Code
Domain Policy
Identity
Privileges
119CORBA Understanding
- Will run on any platform as long as ORB
implementation exist. - Provides extensibility, but is difficult
- Does not provide cross-language inheritance and
exception capabilities - Responsibility of locating an object
implementation is on ORB - Parameters between client and remote objects
interface types are passed by reference others
by value
120CORBA Understanding
- Does not attempt to perform general-purpose
distributed garbage collection - Exception handling is taken care by the Exception
object - Provides location independence
121Microsofts .NET
- .NET is Microsofts Solution to Enterprise
Computing and Interoperability - Aimed to Compete with Java/J2EE
- Interoperability with Old (CORBA, COM) and New
(RMI) - Provide Uniform Programming Environment
- Extension of C - C
- Well Briefly Compare/Contrast/Introduce .NET
122Security 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
123.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
124.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
125.NET Security Execution Model
126C 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
127C 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)
128.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
129.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
130.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
131.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
132.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
133.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 S