Service-Oriented Architectures/Middlware - PowerPoint PPT Presentation

About This Presentation
Title:

Service-Oriented Architectures/Middlware

Description:

Service-Oriented Architectures/Middlware Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 – PowerPoint PPT presentation

Number of Views:274
Avg rating:3.0/5.0
Slides: 165
Provided by: StevenAD2
Category:

less

Transcript and Presenter's Notes

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

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
System Design with CORBA
Scott A. Craig Computer Science Engineering
Department The University of Connecticut Storrs,
Connecticut 06269-3155
scraig_at_engr.uconn.edu
44
Overview of Presentation
  • Introduction to OMG IDL
  • Object Management Architecture
  • CORBAservices
  • Naming Service
  • Event Service
  • Typed Event Example
  • References
  • Concluding Remarks

45
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

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

47
IDL Basic Types
48
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

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

50
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
51
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
52
Object 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.

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

54
Naming 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.

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

56
JINI
57
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

58
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

59
Java Computing Architecture and JINI
60
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
61
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

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

64
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

65
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

66
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

67
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

68
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

69
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!
70
JINI Support for Distributed Computing
71
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
72
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)

73
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
74
Join, Lookup, and Service Invocation
Lookup Service
Registry of Entries
Client
1. Client Invokes AddCourse(CSE900) on
Resource 2. Resource Returns Status of Invocation
75
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

76
Execution Process of Client using JINI
77
Services Console
78
Services GUI
79
Microsofts .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

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

84
Remoting
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
85
Remoting
  • 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

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

90
Remoting
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
91
Remoting
  • 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

92
Web Services ASP.NET
  • Communication based on open protocols
  • - Data XML
  • -Schema XSD
  • UDDI
  • DISCO
  • WSDL
  • SOAP
  • Security

93
ADO.NET
94
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

95
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

96
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

97
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

98
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

99
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

100
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

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

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

104
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

105
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

106
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

107
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

108
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

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

110
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

111
Security Binding in CORBA
112
Domain Objects in CORBA
113
CORBA 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

114
CORBA Security Considerations
  • Security Reference Model (SRM)
  • Security Specification is meta-model
  • Specification that is comprehensive (MAC,
    Encryption)
  • Language Independent (C, Java.)

115
CORBA 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
116
CORBA 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

117
CORBA Security Specifications
  • Security Conformance Level
  • Applications unaware
  • Applications aware
  • Policy controlling
  • Policy enforcing

118
CORBA Security
Client Application (Message Sender)
Target Object
ORB
Security Enforcement Subsystem
Execution Context
Message
Domain
Credential
Policy Enforcement Code
Domain Policy
Identity
Privileges
119
CORBA 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

120
CORBA Understanding
  • Does not attempt to perform general-purpose
    distributed garbage collection
  • Exception handling is taken care by the Exception
    object
  • Provides location independence

121
Microsofts .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

122
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

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

127
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)
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
Write a Comment
User Comments (0)
About PowerShow.com