Middleware, Service-Oriented Architectures and Grid Computing

Middleware, Service-Oriented

Architectures and Grid Computing

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!

Java Client Java Client Legacy Client DB Client COTS Client

What is a Distributed Application?

Legacy

Database Server

Legacy

COTS Server Database

COTS

Network Centric Environment

High-Availability

Performance

Heterogeneity

Hardware

OS, PLs

Transparent Interoperation

New/Innovative

Information Use

Increase Productivity

Dynamic

Environment

Another View – Today’s Reality

Legacy Legacy COTS GOTS Database Database NETWOR K Java Client GOTS Client Legacy Client Database

Client COTS_Client

•

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

Why is Distributed Computing

Needed?

•

Today’s Environments Contain Applications …

–

Created with Multiple Prog. Languages

–

Executing on Heterogeneous Platforms

–

Locally and Geographically Distributed

•

Distributed Computing Applications Must …

–

Allow Seamless and Transparent Interoperation

–

Provide Tools for Engineers and Users

•

Result: Inter-Operating Environment

–

Utilize Information in New/Innovative Ways

–

Leveraged to Increase Productivity

–

Support Diverse User Activities

Striving for New

Techniques/Technologies

•

We Must Diverge from Business as Usual

–

_{C Programming with RPC}

–

Customized Development without Reuse

–

Solutions that Aren’t Extensible and Evolvable

–

Cobbling Together Solutions w/o Method or Reason is

Unacceptable and Doomed to Fail!

•

We Must Face Today’s Realities

–

Legacy Code is Fact of Life

–

New Technologies Offer New Challenges

–

_{Adopt to Leverage Their Benefits}

–

We Must Draw Careful Balance to Opt for Mature

Technologies While Targeting Emerging Technologies with

Potential!

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

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

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 Inherently

Often Add-On

Capability

Service Oriented Architecture

& Grid Computing

What is Service Oriented Architecture (SOA)?

•

An SOA application is a

composition of services

•

A “service” is the

atomic unit of an SOA

•

Services encapsulate a

business process

•

Service Providers

Register themselves

•

Service use involves:

Find, Bind, Execute

Servi ce Regis try Servi ce Provi der Servi ce Cons umer Find Register Bind, Execute

SOA Actors

•

Service Provider

–

Provides a stateless, location transparent business service

•

Service Registry

–

Allows service consumers to locate service providers that

meet required criteria

•

Service Consumer

–

Uses service providers to complete business processes

Se rvi ce Re gis try _Se rvi ce Pr ovi der Se rvi ce Co ns um er Find Register Bind, Execute

SOA Benefits

Business Benefits

•

Focus on Business Domain solutions

•

Leverage Existing Infrastructure

•

Agility

Technical Benefits

•

Loose Coupling

•

Autonomous Service

•

Location Transparency

•

Late Binding

Se rvi ce Re gis try _Se rvi ce Pr ovi der Se rvi ce Co ns um er Find Register Bind, Execute

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

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 – Microsoft’s Forward into the Modern Market – C#

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 for Artifacts (Resources and/or

Clients and/or Other Resources) to Interact

–

Support Dynamic Discovery – Find Services Based on Attributes

and Values

–

Location Transparency to Service Requestors

–

Found Service Sets up Binding Between Service Consumer and

Supplier /Consumer Model

SUPPLY

Build New

Wrap Existing

Buy

CONSUME

Assemble

Applications

MANAGE

Publish

Subscribe

Catalog

Browse

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?

•

Objective is to Explore CORBA, JINI, and .NET

•

Various Aspects of Three Technologies

–

Overall Architecture

–

Interoperability Capabilities

–

Access and Usage

•

Exploration of Web Service-Oriented Architectures

–

What are they?

–

How do they Work?

–

WSOAs + Middleware

•

Transition to Grid Computing

–

What is the Grid?

–

What is its Purpose and Role

–

Grid + SOA + Middleware

What is CORBA?

•

Common Object Request Broker Architecture

•

Architecture to Allow:

–

Existing COTS, GOTS, Legacy, DB, etc. to Interact with One

Another

–

Integrate These with New Clients/Servers/Etc.

•

Consists of Following Major Components

–

Object Request Broker (ORB):

•

Arbitrate and Interact

•

Role of Lookup for Service Discovery

–

Interface Definition Language (IDL):

•

Common Definitional Format

•

Means for Different “Software” written in Different Languages to

Interact with One Another

What is CORBA?

•

_{CORBA is a}

Specification for

Interoperability

•

_{OMG (Object}

Management

Group) Supplies a

Set of Flexible

Abstraction and

Concrete Services

•

_{Vendors Must}

Follow Standard

CORBA Language

Mappings

Ada

C and C++

COBOL

Java to IDL

Lisp

CORBA Scripting

Language

Smalltalk

Others

Perl

Haskell

Python

Eiffel

PHP/ORBit

What is CORBA?

•

Differs from Typical Programming Languages

•

Objects can be …

–

Located Throughout Network

–

Interoperate with Objects on other Platforms

–

Written in Ant PLs for which there is mapping from IDL

to that Language

What is CORBA?

•

CORBA Provides a Robust set of Services (COS)

–

Services to Support Integration and Interoperation of

Distributed Objects

–

Services Defined on top of ORB as standard CORBA

Objects with IDL interfaces

–

Vendors Must Implement CORBA Services (COS)

Object Life Cycle Naming Events Relationships Externalization Transactions Trader Query Property

What is CORBA?

•

Allow Interactions from Client to Server CORBA

•

Installed on All Participating Machines

CORBA: Architectural Goals

•

Simplicity

•

Consistency

•

Scalability

•

Usability for End Users

•

Usability for Administrators

•

Usability for Implementers

•

Flexibility of Security Policy

•

Independence of Security Technology

•

Application Portability

•

Interoperability

•

Performance

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

Interface Definition Language, IDL

•

Key Component of CORBA Is the Interface Definition Language, IDL

–

Mapping is Available in C, C++, Java, Ada, Etc.

–

IDL Is Independent of Any Language/Compiler

–

Multiple Inheritance

–

Public Interface Oriented

–

Not for Implementation

•

Primary Support for Interoperability Between Static and Dynamic

Request Mechanisms

•

Advantage: Modification of Client Code without Impacting of

Server Code, and vice-versa

•

Disadvantage:

–

A complete new language with C++ like Syntax

–

Programmers Must Prepare IDL Modules

ORB and High Level View of Requests

•

The Request Consists of

–

Target Object

–

Operation (Method)

–

Parameters

Object Adapter ORB Core

One interface

One interface per object adaptor One interface per object operation

ORB internal interface Dynamic Invoke Client Stubs ORB Interface

Client Object Implementation

Implementation Skeletons

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

Client Stubs

Implementation Skeletons

Client Object Implementation

Interface Repository

Implementation Repository

Access Includes Includes Describes

IDL Interface Definitions

Implementation Installation

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

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

ORB Core Object Adapter Object Implementation Implementation Skeletons Client Dynamic Invoke Client Stubs ORB Interface Object Repository

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

ORB Core ORB Interface Object Implementation Object Adapter Implem. Skeletons Dynamic Invoke Client Stubs Client Implementation Repository

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

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

CORBA: POA Policies

•

Provided to Programmer for Control Over an

Object’s Identity, State, Storage and Life-cycle

•

7 Different Policies

–

Thread Policy

–

Life-Span Policy

–

Object ID Uniqueness Policy

–

ID Assignment Policy

–

Servant Retention Policy

–

Request Processing Policy

–

Implicit Activation Policy

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

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

Dynamic Invocation Interface (DII)

•

DII Allows Clients to Dynamically:

–

_{Discover Objects}

–

Discover Objects’ Interfaces

–

_{Create Requests}

–

Invoke Requests (-> Methods)

–

_{Receive Responses}

•

Major DII Features:

–

Requests Appear as Objects

–

Requests are Reusable

–

Invocation May be Synchronous or Asynchronous

–

Requests Can be Generated Dynamically, Statically or

Using Both Approaches

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

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

Client Object

Request ORB

ORB and implementations implemented as libraries (routines) resident in the client.

Three Types of ORBs

•

Single Process Library Resident

•

Client and Implementation Resident

Client Object

Request ORB

ORB implemented as

libraries (routines) resident in the clients and in the implementations.

Client Object

Request ORB

ORB is implemented as a server (separate process) which brokers requests between client and

implementation processes. ORB is part of the

operating system.

Three Types of ORBs

Implementation is a permanent or resident multi-threaded process

Implementation is a single process that is activated upon the request delivery Object Implementation Single Process Single method invocation Object Implementation Single Process Method C Method B Method A

Three Types of Implementations

•

Single Process “one shot” Object

Implementation is a set of processes dedicated to a particular (group of) method(s)

Processes can be distributed Object Implementation Process 1 Process 2 Process 3 Method A Method B Method C

Three Types of Implementations

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”

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

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 {

IDL: Complex Types (cont.)

•

Sequences: One-dimensional array with maximum

size (fixed at compile time) and length (set at run

time).

–

Unbounded Sequence:

typdef sequence<long> longSeq;

–

_{Bounded Sequence:}

sequence<long,10> fieldname;

•

Strings: Declared using keyword string. May be

bounded or unbounded.

– string name<32>;//bounded

•

Arrays: Multidimensional, fixed-size arrays of any IDL

data type.

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); };

};

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 GUI::MainWindow val, in boolean flag) raises (OperationTimeout); void setMainWindowEnabled( in boolean flag) raises (OperationTimeout); void registerDialog1( in GUI::Dialog1 val, in boolean flag) raises (OperationTimeout); void setDialog1Enabled( in boolean flag) raises (OperationTimeout); GUI::Dialog1Data_t getDialog1Data() raises (OperationTimeout, NotAvailable); void registerDialog2( in GUI::Dialog2 val, in boolean flag) raises (OperationTimeout); void setDialog2Enabled( in boolean flag) raises (OperationTimeout); GUI::Dialog2Data_t getDialog2Data() raises (OperationTimeout, NotAvailable); }; #endif // SERVER_IDL

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

Sun’s 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

JINI Components and Dependencies

Infrastructur

e

Programming

Model

Service

s

Base

Java

Java VM

RMI

Java

Security

Java APIs

JavaBeans

JNDI

Enterprise

Beans

JTS

JMS

Java +

JINI

Discovery/Joi

n

Leasin

g

Transaction

Manager

Distributed

Security

Transaction

s

JavaSpaces

Lookup

Event

s

Lookup

service

How Does JINI Work?

•

Distributed Application Constructed Using One or

More Lookup Services

•

Lookup Service Support Interactions by

–

Resources: “Advertise” Services

Discover, Register Services, Renew Lease

–

_{Client: “Locate/Utilize” Services}

Discover, Search for Services, Invocation

•

Multiple Lookup Services

–

Resources Responsible for Registering All

–

Clients Interact with Multiple Lookups

–

Stakeholders Must Write “Apropos” Code

Discovery by Resource & Client

Client

JINI

Lookup

Service

Resource

Service Object Service Attributes

JINI

Lookup

Service

Discovery to

Register Services

Discovery to

Locate Services

Basic JINI Concepts

•

JINI

Lookup Service

Maintains Registry for Available Services

of Distributed Application

•

Resources Provide

Services

that

Register

and

Join

with JINI

Lookup Service

•

Clients

Discover

and Utilize Services Based on Interface of

Services

–

Ask Lookup for RegisterForCourse(CSE900)

–

Return

Proxy

for Execution of Service

–

Location of Service Transparent to Client

•

Locations of Clients, Services, Lookup Service, etc., can

Change over Time

•

Conceptually, JINI Similar to Distributed OS with

Dynamically Definable/Changeable Resources

Basic JINI Concepts

•

A

Resource

Provides a Set of Services for Use by Clients

(Users) and Other Resources (Services)

•

A

Service

is Similar to a Public Method

–

Exportable - Analogous to API

–

Any Entity Utilized by Person or Program

–

Samples Include:

• Computation, Persistent Store, Printer, Sensor • Software Filter, Real-Time Data Source

• Anything that is Relevant for Your Domain!

–

Services: Concrete Interfaces of Components

•

Services Register with

Lookup Service

–

Clearinghouse

for Resources to Register Services and Clients to

Locate Services

JINI Resources & Services

JINI

Lookup

Service

Printer Resource

Service Object Service Attributes PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob cancelJob

Class and

Methods

Define

Services

to be

Registered

Register

Services

•

Sun’s Initial Perspective

–

JINI for Hardware

–

Printers, Digital

Cameras, etc.

–

Plug-and-Play on Network

•

PrinterActions Class Defines

the “Component” that is

Registered with JINI

Objectives and Utility of JINI

•

For Users, JINI Offers

–

Sharing of Resources (Services) over Network

–

Location Transparency of Users and Services

–

Both Critical for “Moving” Personnel

•

For Stakeholders, JINI Provides

–

Infrastructure

for Federating Services in Distributed

Setting

–

_{Programming Model}

_{to Register & Discover Services}

–

_Availability

_{of Services Throughout Distributed Setting}

Leading to Ease in Constructing, Maintaining, and

Evolving Network Centric Applications

How Does JINI Work?

•

Resources Discover and Join Lookup Service

•

When Resources Leave or Fail to Renew Leases

–

Lookup Service Must Adjust Registry

–

Time Lag Between Departure and Removal of Services from

Registry

–

What Happens When Client Receives Service Just Prior to

Failure?

–

Utilization of Java Exception Handling

–

Client Code Written to Dynamically Adapt

•

Resource Register

–

Services on Class-by-Class Basis

–

Service Object (Java API - Method Signatures)

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

JINI

Lookup

Service

Printer Resource

Service Object Service Attributes

Leasing/Lease Renewal

PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob cancelJob Class and Methods Define Services to be Registered

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

Lease for 5 minutes (3000000 msec)

Must Renew Before 5 Minutes Expire

If Not Renewed, Lookup Removes

If Failure, Lookup May Still Supply

Service Until Expiration (5 mins)

Client MUST be SMART!

JINI Support for Distributed Computing

Legacy Legacy COTS COTS Database Legacy _COTS Database

Resources

Provide

Services

Java Client Java Client Legacy Client Database Client COTS Client

Clients

Using

Services

JINI Lookup Service JINI Lookup Service

Redundant

Lookups

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

Legacy COTS Legacy _COTS Database Java Client JINI Lookup Service

Constructed via Services of

Legacy, COTS, Database, etc.

Lookup Registered Services

Functionality via Service Reuse

Services as Component APIs

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

What Does an Actual System Look

Like?

JINI Lookup Service Java GUI UDB Client University DB Resource (UDB) Java GUI MDB Client UDBServer Service GetClasses(); PreReqCourse(); GetVacantClasses(); EnrollCourse(); AddCourse(); RemoveCourse(); MDBServer GetParts GetRequisition GetReqParts WriteParts WriteRequisition DeletePart DeleteRequisitio n AddParts RemovePart AddRequisition Military Requisition DB Resource

Join, Lookup, and Service Invocation

Client

Resource

Service Object Service Attributes

Lookup Service

Request

Service

AddCourse(CSE900)

Return

Service

Proxy to

AddCourse( )

J

o

i

n

Register & Lease Services

CourseDB Class

Contains Method

AddCourse ( )

1. Client Invokes AddCourse(CSE900) on Resource

2. Resource Returns Status of Invocation

Service Invocation via Proxy

by Transparent RMI Call

Service Object Service Attributes

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

Execution Process of Client using JINI

Security Authorization Services Security Registration Services Lookup Service Military Client

1 Register_Client(Harris,Security Off., Military)

10 Return Result of Check_Privileges(…) 4 Return Result,Create_Token(Security Off., Token)

3 Client OK?

11 Return Result,CreateRequisition(…)

5. Discover/Lookup(MilitaryDb,Modification, CreateRequisition) Returns Proxy to Military Client

7 IsClient_Registered(Token)

9 Check_Privileges(Token, MilitaryDb, Modification, CreateRequisition, [Tank Details, Harris])

2 Verify_UR(Harris, Security Off.)

Security Policy Services MilitaryDB

Resource

8 Return Result of IsClient_Registered(…)

USR

What is .NET?

•

.NET is Microsoft’s Solution to Enterprise

Computing and Interoperability

•

Aimed to Compete with Java/J2EE

•

Interoperability: Old (CORBA, COM) & New

(RMI)

•

Provides Uniform Programming Environment

via Extension of C - C#

.NET Architecture and Usage

•

Three Level Architecture

•

XML and DataSet as Objects of Interaction

Business Tier Data Tier Presentation Tier Windows Forms Web Forms Business to Business

Data Object (Class) DataSet DataSet DataSet Internet Intranet Data Adapter Data Adapter

(BizTalk, for example)

XML

MyApp.Exe

What are .Net Components?

•

CTS (Common Type System)

–

Defines Common Standard for Languages

•

CLR (Common Language Runtime)

–

Manages the Execution of a .Net Application

–

Provides Cross Platform Support By Ensuring

•

Type Safety, Code Verification, Exception Handling

•

Garbage Collection and Memory Management

•

Note: Akin to Java Runtime Environment

•

ASP.NET

–

This Component Provides a Layer of Classes for Web

Services

What are .Net Components?

•

Windows Forms

–

Provides A Layer Of Classes For The Windows User

Interface

•

ADO.NET

–

_{Provides Classes for Data Access Including Database}

and XML

•

Base Class Library

–

Low Level Classes Capture Core .Net Functionality

–

_{Provides Infrastructure for Construction of Remaining}

.net Framework Classes

Remoting in .Net

•

Remoting Makes an Object in One Process

Available to an Application in Another Process

(Akin to RMI)

•

Marshalling Enables a Controlled Data

Communication Between the 2 Processes

•

Marshalling an Object Can Occur in 2 Ways

–

Marshall By Value:

•

Server Creates a Copy of the Object and Passes the Copy to

the Client

–

Marshall By Reference:

•

Server Creates a Reference of the Object and Sends this

Reference to the Client

Remoting in .NET

When a client calls an object marshalled by reference

of the object in the client’s application domain and the

client uses that proxy to access that original object on

Remoting in .NET

When a client calls an object marshaled by value the

server creates and exact copy and sends that copy

to the client. The client then uses the data of the

object and executes the required functionality

directly within the client’s own process without

Recall Similarity to RMI in Java

Start rmiregistery

Unmarshall Marshall Unmarshall Marshall

NDR NDR NDR NDR

Stub Stub Skel Skel

Transport Transport Transport Transport

HelloApplet HelloImpl Hello 1 2 3 4 5

Server

Client

RMI Layer

rmic HelloImpl.java

Java Objects in JVMs (on Different Computers)

Transparently Invoke Each Other's Methods

Web Services ASP.NET

•

Communication Based on Open Protocols

–

Data via XML

–

Schema via XSD

•

Other Supported Protocols Inlcude:

–

UDDI

–

DISCO

–

WSDL

CORBA vs. JINI vs. .NET

•

Important to Differentiate Between

–

Standard (CORBA) – Vendors Implement

–

Technologies (JINI, .NET)

•

Many Different Pros and Cons w.r.t. Infrastructure, Usage,

Environment, Interoperability, Ease of Use, Programming

Requirements, etc. etc. etc.

•

Many Different Perspectives to Compare Capabilities and

Functionalities of Technologies

•

What about Other Approaches?

–

Terrific Presentation by D. Schmidt

–

Combines Patterns and Middleware

–

http://www.cs.wustl.edu/~schmidt/patterns-frameworks-middleware.p

pt

Brief Comparison…

•

Database Connectivity

–

_{Java uses JDBC and .Net uses Ado.net or ODBC.NET}

•

Cross platform interoperability

–

_{J2EE and CORBA Easily Supports Interoperation .Net}

Focuses on Windows Platform

•

Programming Languages

–

.Net and CORBA Support Multiple Languages J2EE Focuses

on Java (with Links to IDL)

•

Cross Vendor Interoperability

–

J2EE and CORBA Guaranteed by Specifications Microsoft is

the only vendor for .Net

Web Service Oriented Architectures

(WSOA)

•

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

WSOA in Practice

•

From Web Services Architecture, W3C

A Web service is a software system designed to

support interoperable machine-to-machine

interaction over a network. It has an interface

described in a machine processable format

(specifically WSDL). Other systems interact with

the Web service in a manner prescribed by its

description using SOAP messages, typically

conveyed using HTTP with an XML serialization in

conjunction with other Web-related standards.

Web Services Architecture from W3C

•

Complex

Architecture with

Many Different

Capabilities and

Features

–

Open Ended (Like

Web)

–

Target Multiple

Domains/Usages

•

Current Web and

Future (Emerging?)

Semantic Web

Another WSOA Example

From:

Another WSOA Example

From:

Service Oriented Architecture

Reference Model

Reference Model

•

An abstract framework for understanding

significant relationships among the entities of

some environment.

•

Consists of a minimal set of unifying concepts,

axioms and relationships within a particular

problem domain.

•

Is independent of specific standards,

technologies, implementations, or other

concrete details.

Service Oriented Architecture

•

Service Oriented Architecture is a paradigm

for organizing and utilizing distributed

capabilities that may be under the control of

different ownership domains.

•

Goal of this reference model is to define the

essence of Service Oriented Architecture

Why Service Oriented Architecture?

•

Drivers:

–

Large scale Enterprise systems

–

Internet scale provisioning of services

–

Reduce the cost of doing business

•

Benefits

–

Build scalable, evolvable systems

•

Scalable because minimizes assumptions

–

Manage complex systems

Why is it different?

•

SOA reflects the reality of ownership

boundaries

–

CORBA, RMI, COM, DCOM, etc. all try to implement

transparent distributed systems

–

Ownership is of the essence in SOA

•

SOA is task oriented

–

Services are organized by function

•

Getting something done

•

SOA is inspired by human organizations

What is not in the RM

•

Service composition

–

Choreography, orchestration

–

Process Oriented Architecture

•

Organizational framework

–

Who is doing what to whom

•

Specific technologies

Service

•

A mechanism to enable access to one

or more capabilities

–

using a prescribed interface

–

consistent with constraints and policies

as specified by the service description.

Visibility

• Awareness

• Service description • Discovery

• Willingness

• Policy & contract

• Reachability

• Communication

Visibility is the relationship between

service participants that is satisfied when they are able to interact with each other

Interaction

Interacting with a service involves performing actions against the service

The extent to which one system can effectively interpret information from another system is governed by the

semantic engagement of the

various systems.

The semantic engagement of a

system is a relationship between the system and information it may

Real World Effect

The purpose of using a capability is to realize one or more real world effects. At its core, an interaction is “an act” as opposed to “an object” and the

result of an interaction is an effect (or a set/series of effects).

The real world effect is couched

in terms of changes to the state shared by the participants and stakeholders in

Conditions and Expectations

•

Policy

– Constraint representing the intention of a participant in a service

•

Contract

– Constraint representing an

agreement between two or more participants.

Description

The service description represents the information needed in order to use, manage or provide a service. • Service reachability • Service Functionality • Service Policies • Service Interface

Execution Context

The execution context is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction,

and thus forms a path between those with needs and those with capabilities

Is a Reference Model an Ontology?

•

Establishing a vocabulary

–

A lot of definitions

•

The RM glossary has 28 entries

•

Formality was considered

–

Audience is not formal

What about UML

•

UML obvious choice for an architecture spec

•

But,

–

Inheritance (is-a) relationship almost never used

–

Extraneous precision

•

E.g. we tried to define Service, not count the number of

service providers

Concepts Maps

Concepts maps

were excellent

graphical indices

to text

Concepts, and

relationships.

All we needed

Where we are

•

Committee Specification published

•

Reference Architecture effort started

Comments on WSOA

•

Wealth of Information on WSOA Available on-Line

•

Let’s Review Four Other Presentations Briefly

–

http://download.microsoft.com/download/b/d/b/bdb2417

5-50bc-4e74-8df9-835cef6521cb/ConnectedSystems.ppt

–

_{http://www.cs.queensu.ca/home/cords/soa.ppt}

–

http://www.rgoarchitects.com/Files/SOA.ppt

–

http://www.wsmo.org/TR/d17/resources/200605-OASIS/S

emanticServiceOrientedArchitectureTutorial.ppt

•

All Links on Course Web Page

•

Last Presentation Transitions from SOA to Semantic

Web

Service Oriented Architecture

& Grid Computing

Marc Brooks, The MITRE Corporation

The author's affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or

What is Grid Computing?

“A computational grid is a hardware and software infrastructure that

provides dependable, consistent, pervasive, and inexpensive access to

high-end computational capabilities.”

-”The Grid: Blueprint for a New Computing Infrastructure”, Kesselman & Foster

Source: “What is the Grid? A Three Point Checklist”, Ian Foster, Argonne National Laboratory & University of Chicago

Criteria for a Grid*:

1. Coordinates resources that are not subject

to centralized control.

2. Uses standard, open, general-purpose

protocols and interfaces.

Grid Computing Benefits

•

Exploit Underutilized resources

–

CPU Scavenging, Hotspot leveling

•

Resource Balancing

•

Virtualize resources across an enterprise

–

Data Grids, Compute Grids

Two Key Grid Computing Groups

The Globus Alliance (www.globus.org)

•

Composed of people from:

Argonne National Labs, University of Chicago, University of Southern California Information Sciences Institute, University of Edinburgh and others.

•

OGSA/I standards initially proposed by the Globus Group

– Based off papers “Anatomy of the Grid” & “Physiology of the Grid”

The Global Grid Forum (www.ggf.org)

•

History

– First meeting in June of 1999, Based off the IETF charter

•

Heavy involvement of Academic Groups and Industry

– (e.g. IBM Grid Computing, HP, United Devices, Oracle, UK e-Science Programme, US DOE, US NSF, Indiana University, and many others)

•

Process

– Meets three times annually

Companies involved in Grid Computing

• Avaki • Axceleon • CapCal • Centrata • DataSynapse • Distributed Science • Elepar • Entropia.com • Grid Frastructure • GridSystems • Groove Networks • IBM • Intel ■ Powerllel ■ ProcessTree

■ Sharman Networks Kazza

■ Sun Gridware ■ Sysnet Solutions ■ Tsunami Research ■ Ubero ■ United Devices ■ Veritas ■ Xcomp ■ Jivalti ■ Mithral ■ Mind Electric ■ Mojo Nation ■ NewsToYou.com ■ NICE, Italy ■ Noemix, Inc. ■ Oracle ■ Parabon ■ Platform Computing ■ Popular Power Source: http://www.gridcomputing.com/

Standards involved with SOA & Grid Computing

SOA Standards

•

WSDL

•

UDDI

•

BPEL

•

WS-Profile

•

WS-Security

•

WS-Choreography

And many others…

Grid Standards

■

OGSI

◻

Extension to WSDL

■

WS-Resource

◻

WS-ResourceLifetime

◻

WS-ResourcePropertie

s

◻

WS-RenewableReferen

ces

◻

WS-ServiceGroup

◻

WS-BaseFaults

Grid and Web Services Standards

Convergence of Core Technology Standards allows

Common base for Business and Technology Services

Grid

OGSi

GT2

GT1

Web

HTTP

WSDL,

SOAP

WS-*

Have been

converging

WSRF

Started far apart in applications & technology

XML

BPEL

WS-I Compliant Technology Stack