Top Banner
MW+SOA-1 CSE 300 Middleware, Service-Oriented Architectures and Grid Computing Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269-2155 [email protected] http://www.engr.uconn.edu/ ~steve (860) 486 - 4818 Special Thanks to Prof. Alex Shvartsman, Keith Bessette, Scot d Prior CSE333 students for providing portions of this materi
140

Middleware, Service-Oriented Architectures and Grid Computing

Jan 13, 2016

Download

Documents

Jia Xuan

Middleware, Service-Oriented Architectures and Grid Computing. Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269-2155. [email protected] http://www.engr.uconn.edu/~steve (860) 486 - 4818. - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-1

CSE300

Middleware, Service-Oriented Architectures and Grid Computing

Prof. Steven A. Demurjian

Computer Science & Engineering DepartmentThe University of Connecticut

371 Fairfield Road, Box U-2155Storrs, CT 06269-2155

[email protected]://www.engr.uconn.edu/

~steve(860) 486 - 4818

† Special Thanks to Prof. Alex Shvartsman, Keith Bessette, Scott Craig and Prior CSE333 students for providing portions of this material.

Page 2: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-2

CSE300

What is a Distributed Application?What is a Distributed Application? Distributed Computing/Applications are …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 …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 Present & Future Army Systems Exhibit All of These Characteristics and More!These Characteristics and More!

Page 3: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-3

CSE300

JavaClient

JavaClient

LegacyClient

DB Client

COTSClient

What is a Distributed Application?What is a Distributed Application?

LegacyDatabase

Server

Legacy

COTSServer

Database

COTS

Network Centric Environment

High-AvailabilityPerformanceHeterogeneity Hardware OS, PLs

Transparent Interoperation New/Innovative Information Use

Increase ProductivityDynamic

Environment

System of Systems

Page 4: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-4

CSE300

Another View – Today’s RealityAnother View – Today’s Reality

Legacy

Legacy

COTS

GOTS

Database

Database

NETWORK

JavaClient

GOTSClient

LegacyClient

DatabaseClient

COTSClient

Premise: Premise: ArtifactsArtifacts - set of - set of DB, Legacy, COTS,

GOTS, Each w/ API Premise: Premise: UsersUsers

New and Existing Utilize Artifact APIs

Distributed Application, Distributed Application, DADA Artifacts + Users

What are the Issues?What are the Issues? How Do they Interact? Heterogeneity Security Concerns Different Programmatic

Models Etc. Etc. Etc.

Page 5: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-5

CSE300

Why is Distributed Computing Needed?Why is Distributed Computing Needed? Today’s Environments Contain Applications … Today’s Environments Contain Applications …

Created with Multiple Prog. Languages Executing on Heterogeneous Platforms Locally and Geographically Distributed

Distributed Computing Applications Must … Distributed Computing Applications Must … Allow Seamless and Transparent Interoperation Provide Tools for Engineers and Users

Result: Inter-Operating Environment Result: Inter-Operating Environment Utilize Information in New/Innovative Ways Leveraged to Increase Productivity Support Diverse User Activities Dynamically Respond to Changes

Page 6: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-6

CSE300

Striving for New Techniques/TechnologiesStriving for New Techniques/Technologies We Must Diverge from Business as UsualWe 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 RealitiesWe 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!

Page 7: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-7

CSE300

Who are the Players?Who are the Players? StakeholdersStakeholders

Software Architects (Requirements) System Designers (Solutions) Application Builders (Implementation)

Stakeholders Striving to Provide …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 End-Users at Various Skill Levels and with Specific

and Limited Access Requirementsand Limited Access Requirements Novice vs. Adept vs. Expert Who Uses What When and for How Long?Who Uses What When and for How Long?

Page 8: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-8

CSE300

Why a Distributed Application?Why a Distributed Application? Reasons:Reasons:

Data used is Distributed Computation is Distributed Application Users are

Distributed 2 Key Issues for Solution: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

Page 9: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-9

CSE300

Distributed SystemsDistributed Systems

Co-locatedCo-located DistributedDistributed

CommunicationCommunication FastFast SlowerSlower

FailuresFailures Objects fail togetherObjects fail togetherObjects fail Objects fail

separately, Network separately, Network can partitioncan partition

Concurrent AccessConcurrent Access Only with multiple Only with multiple threadsthreads YesYes

SecureSecure YesYesNot InherentlyNot InherentlyOften Add-On Often Add-On

CapabilityCapability

Fundamental Realities of Distributed Systems

Page 10: Middleware, Service-Oriented Architectures and Grid Computing

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 viewpoints expressed by the author.

http://colab.cim3.net/file/work/EmergingTechnology_Conference/2004-06-03_MITRE/Brooks_2004_03_24.ppt

Page 11: Middleware, Service-Oriented Architectures and 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

ServiceRegistry

ServiceProvider

ServiceConsumer

Find Register

Bind,Execute

Page 12: Middleware, Service-Oriented Architectures and Grid Computing

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

ServiceRegistry

ServiceProvider

ServiceConsumer

Find Register

Bind,Execute

Page 13: Middleware, Service-Oriented Architectures and Grid Computing

SOA Benefits

Business Benefits Focus on Business Domain solutions Leverage Existing Infrastructure Agility

Technical Benefits Loose Coupling Autonomous Service Location Transparency Late Binding

ServiceRegistry

ServiceProvider

ServiceConsumer

Find Register

Bind,Execute

Page 14: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-14

CSE300

What is a Service Oriented Architecture?What is a Service Oriented Architecture? Solutions that Focus on Services that Need to be Solutions that Focus on Services that Need to be

Available to Meet Need of Users (Entities)Available to Meet Need of Users (Entities) Users are Assumed to be Interacting via Client Users are Assumed to be Interacting via Client

Applications (Browser or Standalone)Applications (Browser or Standalone) Interactions with Services Transparent to Users

(Integrated into Software) Interactions Between Entities Occur via a Message Interactions Between Entities Occur via a Message

Exchange - ConceptualExchange - 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 SettingsBoth Web-Based and Middleware Settings

Page 15: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-15

CSE300

Middleware-Based SOAMiddleware-Based SOA Distributed Object Computing Platforms are Well Distributed Object Computing Platforms are Well

Established in the Field - HistoricallyEstablished in the Field - Historically DCE (Distributed Computing Environment) COM/OLE (Component Object Model/Object

Linking and Embedding) Modern Middleware (JINI, CORBA, .NET):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#

Page 16: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-16

CSE300

What Must All SOA Provide?What Must All SOA Provide? Both Middleware & Web-Based SOAs Must ProvideBoth 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 Lookup Service: Middleware for Artifacts (Resources and/or Clients and/or Other Resources) to Interactand/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 Service Provider

Page 17: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-17

CSE300

SOA Akin to CBDSOA Akin to CBD

Page 18: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-18

CSE300

Supplier /Consumer ModelSupplier /Consumer Model

SUPPLY Build New Wrap Existing Buy

CONSUME Assemble Applications

MANAGE Publish Subscribe Catalog Browse

Page 19: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-19

CSE300

Objectives of SOAObjectives of SOA Can SOAs Support Can SOAs Support Highly-Available Distributed Highly-Available Distributed

ApplicationsApplications?? Can Replicated Services be Registered and Available Can Replicated Services be Registered and Available

for Use by Clients?for Use by Clients? Can SOAs Support a Network-Centric Environment Can SOAs Support a Network-Centric Environment

with with Dynamic Clients and ServicesDynamic Clients and Services?? Will Clients Continue to Operate Effectively if a Will Clients Continue to Operate Effectively if a

Replicated Service FailsReplicated Service Fails?? Can SOAs be Utilized to Can SOAs be Utilized to Maintain Data ConsistencyMaintain Data Consistency

of Replicas?of Replicas? Are SOAs Easy to Learn and Use?Are SOAs Easy to Learn and Use? What is Maturity Level of SOAs Technology?What is Maturity Level of SOAs Technology?

Page 20: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-20

CSE300

Overview of PresentationOverview of Presentation Objective is to Explore CORBA, JINI, and .NETObjective is to Explore CORBA, JINI, and .NET Various Aspects of Three TechnologiesVarious Aspects of Three Technologies

Overall Architecture Interoperability Capabilities Access and Usage

Exploration of Web Service-Oriented ArchitecturesExploration of Web Service-Oriented Architectures What are they? How do they Work? WSOAs + Middleware

Transition to Grid ComputingTransition to Grid Computing What is the Grid? What is its Purpose and Role Grid + SOA + Middleware

Page 21: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-21

CSE300

What is CORBA?What is CORBA? Common Object Request Broker ArchitectureCommon Object Request Broker Architecture Architecture to Allow: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 ComponentsConsists 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

Page 22: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-22

CSE300

What is CORBA?What is CORBA? CORBA is a CORBA is a

Specification for Specification for InteroperabilityInteroperability

OMG (Object OMG (Object Management Management Group) Supplies a Group) Supplies a Set of Flexible Set of Flexible Abstraction and Abstraction and Concrete ServicesConcrete Services

Vendors Must Vendors Must Follow StandardFollow Standard

CORBA Language Mappings

AdaC and C++

COBOLJava to IDL

LispCORBA Scripting

LanguageSmalltalk

OthersPerl

HaskellPythonEiffel

PHP/ORBit

Page 23: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-23

CSE300

What is CORBA?What is CORBA? Differs from Typical Programming LanguagesDiffers from Typical Programming Languages Objects can be …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

Object Request Broker

ApplicationInterfaces

Domain Interfaces

Object Services

Page 24: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-24

CSE300

What is CORBA?What is CORBA? CORBA Provides a Robust set of Services (COS)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 Request Broker

FactoryNamingContext

EventChannel

Object Life CycleNamingEventsRelationshipsExternalizationTransactionsTraderQueryProperty

Page 25: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-25

CSE300

What is CORBA?What is CORBA? Allow Interactions from Client to Server CORBA Allow Interactions from Client to Server CORBA Installed on All Participating MachinesInstalled on All Participating Machines

Client Application Server Application

Client ORB Core Server ORB Core

StaticStub

DII DSISkeleton

ORBInterface

ORBInterface

Object Adapter

Network

IDL - Independent Same for allapplications

There may be multipleobject adapters

Page 26: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-26

CSE300

CORBA: Architectural GoalsCORBA: Architectural Goals SimplicitySimplicity ConsistencyConsistency ScalabilityScalability Usability for End UsersUsability for End Users Usability for AdministratorsUsability for Administrators Usability for ImplementersUsability for Implementers Flexibility of Security PolicyFlexibility of Security Policy Independence of Security TechnologyIndependence of Security Technology Application PortabilityApplication Portability InteroperabilityInteroperability PerformancePerformance Object OrientationObject Orientation

Page 27: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-27

CSE300

Client

Application

Object

Implementation

ORB

Role of an Object Request Broker (ORB)Role of an Object Request Broker (ORB) ORB Provides the Underlying Infrastructure for ORB Provides the Underlying Infrastructure for

Supporting Interoperating Software Systems Supporting Interoperating Software Systems (Applications) Composed of Distributed Objects(Applications) Composed of Distributed Objects ORB Provides the Basic Request Delivery ORB Provides Interface Definitions

Location is Transparent to the Caller and Object Location is Transparent to the Caller and Object ImplementationImplementation

Caller and the Object Implementation Can be in the Caller and the Object Implementation Can be in the Same Process thru Opposite Sides of the WorldSame Process thru Opposite Sides of the World

ORB Manages Local Location and OptimizationORB Manages Local Location and Optimization

Page 28: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-28

CSE300

Interface Definition Language, IDLInterface Definition Language, IDL Key Component of CORBA Is the Interface Key Component of CORBA Is the Interface

Definition Language, IDLDefinition 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 Primary Support for Interoperability Between Static and Dynamic Request Mechanismsand Dynamic Request Mechanisms

Advantage: Modification of Client Code without Advantage: Modification of Client Code without Impacting of Server Code, and vice-versaImpacting of Server Code, and vice-versa

Disadvantage: Disadvantage: A complete new language with C++ like Syntax Programmers Must Prepare IDL Modules

Page 29: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-29

CSE300

ClientApplication

ObjectImplementation

ORB

Object reference Object dispatcher

IDL Boundary

Object Call

IDL Boundary

Methods and Data

Request

ORB and High Level View of RequestsORB and High Level View of Requests The Request Consists ofThe Request Consists of

Target Object Operation (Method) Parameters Request Context (Optional)

Page 30: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-30

CSE300

ObjectAdapter

ORB Core

One interfaceOne interface per object adaptorOne interface per object operation

ORB internal interface

DynamicInvoke

ClientStubs

ORBInterface

Client Object Implementation

ImplementationSkeletons

CORBA Components and InterfacesCORBA Components and Interfaces Client Stub: Client Invokes a Particular Object Op.Client Stub: Client Invokes a Particular Object Op. Dynamic Invocation: Run-Time-Construction of Dynamic Invocation: Run-Time-Construction of

Operation InvocationsOperation Invocations Implementation Skeleton: Interface Through Which a Implementation Skeleton: Interface Through Which a

Method Receives a RequestMethod Receives a Request Object Adapter: Provides (De)activation, Object Object Adapter: Provides (De)activation, Object

Creation/Reference Mgmt. for ImplementationsCreation/Reference Mgmt. for Implementations ORB Interface: Common ORB OperationsORB Interface: Common ORB Operations

Page 31: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-31

CSE300

ClientStubs

ImplementationSkeletons

Client Object Implementation

InterfaceRepository

ImplementationRepository

Access Includes Includes Describes

IDL InterfaceDefinitions

ImplementationInstallation

InterfacesInterfaces Objects are Defined in IDL via InterfacesObjects are Defined in IDL via Interfaces Object Definitions (Interfaces) are Manifested as Object Definitions (Interfaces) are Manifested as

Objects in the Interface Repository, as Client Stubs, Objects in the Interface Repository, as Client Stubs, and as Implementation Skeletonsand as Implementation Skeletons

Descriptions of Object Implementations are Descriptions of Object Implementations are Maintained as Objects in the Impl. RepositoryMaintained as Objects in the Impl. Repository

Page 32: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-32

CSE300

CORBA: RepositoriesCORBA: Repositories Interface RepositoryInterface Repository

Client access to definitions

Type checking for signatures

Traversal of inheritance graphs

IDL InterfaceDefinitions

InterfaceRepository

ClientStubs

Client

ImplementationInstallation

ImplementationSkeletons

ImplementationRepository

Object Implementation

AccessIncludes Includes Describes

Implementation RepositoryImplementation Repository Location of

implementation Activation information Administration control Security Resource allocation

Page 33: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-33

CSE300

ORB Core

ObjectAdapter

Object Implementation

ImplementationSkeletons

Client

DynamicInvoke

ClientStubs

ORBInterface

ObjectRepository

Client SideClient Side Clients Perform Requests Using Object ReferencesClients Perform Requests Using Object References Clients Issue Requests through Object Interface Stubs Clients Issue Requests through Object Interface Stubs

(Static) or DII (Dynamic Invocation Inter.)(Static) or DII (Dynamic Invocation Inter.) Clients May Access General ORB Services:Clients May Access General ORB Services:

Interface Repository (IR) Context Management Request Management

Page 34: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-34

CSE300

ORB Core

ORBInterface

Object Implementation

Object Adapter

Implem.Skeletons

DynamicInvoke

ClientStubs

ClientImplementation

Repository

Object Implementation SideObject Implementation Side Implementations Receive Requests Thru SkeletonsImplementations Receive Requests Thru Skeletons Object Adapter Adapts to Specifics of Object Object Adapter Adapts to Specifics of Object

Implementation SchemesImplementation Schemes Basic Object Adapter (BOA) Provides:Basic Object Adapter (BOA) Provides:

Management of References Method Invocation Authentication Implementation Registration Activation / Deactivation

Page 35: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-35

CSE300

CORBACORBA Basic Object Adapter (BOA)Basic Object Adapter (BOA)

Provides Basic Services to Allow Variety Of CORBA Objects to be Created – Ambiguous

Portable Object Adapter (POA)Portable Object Adapter (POA) Allow Developers yo Construct Object

Implementations that are Portable Between ORBs Mediator Between ORB And Server

Client ORB POA

Incoming Request

Server Applications

Servants

Page 36: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-36

CSE300

CORBA: POA PoliciesCORBA: POA Policies Provided to Programmer for Control Over an Object’s Provided to Programmer for Control Over an Object’s

Identity, State, Storage and Life-cycleIdentity, State, Storage and Life-cycle 7 Different Policies7 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 TurnWe Briefly Review each in Turn

Page 37: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-37

CSE300

CORBA: POA PoliciesCORBA: POA Policies Thread Policy - Depends on Number of Objects the Thread Policy - Depends on Number of Objects the

Application Will HaveApplication Will Have Depends on Operating System Expected Load on System ORB_CTRL_MODEL/SINGLE_THREAD_MODEL

Life Span Policy - Transient object cannot live Life Span Policy - Transient object cannot live beyond the process which created itbeyond the process which created it Persistent object can live beyond the process

which created it TRANSIENT / PERSISTENT

Object ID Uniqueness PolicyObject ID Uniqueness Policy UNIQUE_ID / MULTIPLE_ID

Page 38: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-38

CSE300

CORBA: POA PoliciesCORBA: POA Policies ID Assignment Policy - To specify whether Object ID ID Assignment Policy - To specify whether Object ID

was generated by the application or ORBwas generated by the application or ORB USER_ID / SYSTEM_ID

Servant Retention Policy: States if POA retains active Servant Retention Policy: States if POA retains active servants in object mapservants in object map RETAIN / NON_RETAIN

Request Processing Policy: States how request Request Processing Policy: States how request processed by the POAprocessed by the POA USE_ACTIVE_OBJECT_MAP_ONLY /

USE_DEFAULT_SERVANT / USE_SERVANT_MANAGER

Implicit Activation Policy: Indicates if Implicit Implicit Activation Policy: Indicates if Implicit activation of servants is supported by POAactivation of servants is supported by POA IMPLICIT_ACTIVATION /

NO_IMPLICIT_ACTIVATION

Page 39: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-39

CSE300

Dynamic Invocation Interface (DII)Dynamic Invocation Interface (DII) DII Allows Clients to Dynamically:DII Allows Clients to Dynamically:

Discover Objects Discover Objects’ Interfaces Create Requests Invoke Requests (-> Methods) Receive Responses

Major DII Features: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

Page 40: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-40

CSE300

Request ComponentsRequest Components Object Reference -- Identifies the Target ObjectObject Reference -- Identifies the Target Object Operation -- Identifies Which Operation to Invoke Operation -- Identifies Which Operation to Invoke

(Which Method Will Be Executed)(Which Method Will Be Executed) Parameters -- Input, Output or Inout Method Arg-sParameters -- Input, Output or Inout Method Arg-s Context Object -- the Context Within Which the Context Object -- the Context Within Which the

Request Is to Be PerformedRequest Is to Be Performed Results -- the Result Value(s) ReturnedResults -- the Result Value(s) Returned Environment -- the Exec-n Env-t and Exception Info.Environment -- the Exec-n Env-t and Exception Info. Request Handle -- the Id. For This Request InstanceRequest Handle -- the Id. For This Request Instance

Page 41: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-41

CSE300

Repositories: Interface and ImplementationRepositories: Interface and Implementation Interface RepositoryInterface Repository

Dynamic Client Access to Interface Definitions to Construct a Request

Dynamic Type Checking of Request Signatures Traversal of Inheritance Graphs

Implementation RepositoryImplementation Repository Location of Implementations and Methods Activation Information Administration Control Resource Allocation Security

Page 42: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-42

CSE300

Client Object

RequestORB

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

Three Types of ORBsThree Types of ORBs Single Process Library ResidentSingle Process Library Resident

Client and Implementation ResidentClient and Implementation Resident

Client Object

RequestORB

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

Page 43: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-43

CSE300

Client Object

RequestORB

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 ORBsThree Types of ORBs Server or Operating System BasedServer or Operating System Based

Page 44: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-44

CSE300

Implementation is a permanentor resident multi-threadedprocess

Implementation is a singleprocess that is activatedupon the request delivery

Object Implementation

Single Process

Singlemethodinvocation

Object Implementation

Single Process

Method CMethod B

Method A

Three Types of ImplementationsThree Types of Implementations

Single Process “one shot” ObjectSingle Process “one shot” Object

Multi-Threaded “resident” ObjectMulti-Threaded “resident” Object

Page 45: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-45

CSE300

Implementation is a setof processes dedicated toa 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 ImplementationsThree Types of Implementations

Multi-Process ObjectMulti-Process Object

Page 46: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-46

CSE300

Interface Definition Language, IDLInterface Definition Language, IDL Language used to describe the interfaces that client Language used to describe the interfaces that client

objects call and object implementations provide.objects call and object implementations provide. Obeys the same lexical rules as C++, but introduces Obeys the same lexical rules as C++, but introduces

some new keywords.some new keywords. Supports standard C++ preprocessing features.Supports standard C++ preprocessing features. Interfaces can have operations and attributes.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 Interface specifications are placed in a source file having the extension “.idl”having the extension “.idl”

Page 47: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-47

CSE300

IDL: Modules and InterfacesIDL: Modules and Interfaces Module: Used to scope IDL identifiers.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 Interface: Description of set of operations that a

client may request of an object.client may request of an object. Multiple inheritance supported Interface body may contain the following kinds of

declarations: constant, type, attribute, and operation.

Page 48: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-48

CSE300

IDL: Basic TypesIDL: Basic Types

Type Range

short -215 .. 215-1 (16-bit)

unsigned short 0 .. 216-1 (16-bit)

long -231 .. 231-1 (32-bit)

unsigned long 0 .. 216-1 (32-bit)

float IEEE single-precision floating point

double IEEE double-precision floating point

char 8-bit quantity

boolean TRUE or FALSE

octet 8-bit (guaranteed during transmission)

any values that can express any IDL type

Page 49: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-49

CSE300

IDL: Complex TypesIDL: Complex Types Structures: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 Discriminated Unions: Cross between the C unionunion and and switchswitch statements. statements.

Enumerations: Ordered list of identifiers.Enumerations: Ordered list of identifiers. enum quality_t { Poor, Fair, Good, Excellent};

Page 50: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-50

CSE300

IDL: Complex Types (cont.)IDL: Complex Types (cont.) Sequences: One-dimensional array with maximum Sequences: One-dimensional array with maximum

size (fixed at compile time) and length (set at run size (fixed at compile time) and length (set at run time).time). Unbounded Sequence:typdef sequence<long> longSeq;

Bounded Sequence:sequence<long,10> fieldname;

Strings: Declared using keyword Strings: Declared using keyword string.string. May be May be bounded or unbounded.bounded or unbounded. string name<32>; //bounded

Arrays: Multidimensional, fixed-size arrays of any Arrays: Multidimensional, fixed-size arrays of any IDL data type.IDL data type.

Page 51: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-51

CSE300

IDL Example: GUIIDL 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

Page 52: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-52

CSE300

IDL Example: ServerIDL 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

Page 53: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-53

CSE300

What is JINI?What is JINI? An Infrastructure for Network Centric Applications in An Infrastructure for Network Centric Applications in

Spontaneous EnvironmentSpontaneous 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 JINIGoals 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

Page 54: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-54

CSE300

Sun’s JINI TechnologySun’s JINI Technology JINI is a Sophisticated Java APIJINI is a Sophisticated Java API Construct Distributed Applications Using JINI by Construct Distributed Applications Using JINI by

Federating Groups of Users Resources Provide Services (Database Access,

Printing, Real-Time Sensor) for Users JINI and StakeholdersJINI and Stakeholders

Core of Technologies to Architect, Design, Implement, and Test Distributed Applications

Construct Software “Resistant” to Failure JINI and UsersJINI and Users

High Availability Through Redundancy Dynamic Responses to User Requests

Regardless of Network & Resource Changes

Page 55: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-55

CSE300

Java Computing Architecture and JINIJava Computing Architecture and JINI

Page 56: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-56

CSE300

JINI Components and DependenciesJINI Components and Dependencies

Infrastructure Programming Model

Services

Base Java

Java VM

RMI

Java Security

Java APIs

JavaBeans

JNDI

Enterprise Beans

JTS

JMS

Java + JINI

Discovery/Join Leasing Transaction Manager

Distributed Security

Transactions JavaSpaces

Lookup Events Lookup service

Page 57: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-57

CSE300

How Does JINI Work?How Does JINI Work? Distributed Application Constructed Using One or Distributed Application Constructed Using One or

More Lookup ServicesMore Lookup Services Lookup Service Support Interactions by Lookup Service Support Interactions by

Resources: ““Advertise”Advertise” ServicesDiscover, Register Services, Renew Lease

Client: “Locate/Utilize”“Locate/Utilize” ServicesDiscover, Search for Services, Invocation

Multiple Lookup ServicesMultiple Lookup Services Resources Responsible for Registering All Clients Interact with Multiple Lookups Stakeholders Must Write “Apropos” Code

Discovery Initiates Process for Client or ResourceDiscovery Initiates Process for Client or Resource

Page 58: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-58

CSE300

Discovery by Resource & ClientDiscovery by Resource & Client

Client

JINILookupService

Resource

Service ObjectService Attributes

JINILookupService

Discovery toRegister Services

Discovery toLocate Services

Page 59: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-59

CSE300

Basic JINI ConceptsBasic JINI Concepts JINI JINI Lookup ServiceLookup Service Maintains Registry for Maintains Registry for

Available Services of Distributed ApplicationAvailable Services of Distributed Application Resources Provide Resources Provide ServicesServices that that RegisterRegister and and JoinJoin

with JINI Lookup Servicewith JINI Lookup Service Clients Clients DiscoverDiscover and Utilize Services Based on and Utilize Services Based on

Interface of ServicesInterface 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., Locations of Clients, Services, Lookup Service, etc., can Change over Timecan Change over Time

Conceptually, JINI Similar to Distributed OS with Conceptually, JINI Similar to Distributed OS with Dynamically Definable/Changeable ResourcesDynamically Definable/Changeable Resources

Page 60: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-60

CSE300

Basic JINI ConceptsBasic JINI Concepts A A ResourceResource Provides a Set of Services for Use by Provides a Set of Services for Use by

Clients (Users) and Other Resources (Services)Clients (Users) and Other Resources (Services) A A ServiceService is Similar to a Public Method 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 Services Register with Lookup ServiceLookup Service

Clearinghouse for Resources to Register Services and Clients to Locate Services

Page 61: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-61

CSE300

JINI Resources & ServicesJINI Resources & Services

JINILookupService

Printer Resource

Service ObjectService Attributes

PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob cancelJob

Class and Methods Define Servicesto beRegistered

Register Services

Sun’s Initial PerspectiveSun’s Initial Perspective JINI for Hardware Printers, Digital

Cameras, etc. Plug-and-Play on

Network PrinterActions Class Defines PrinterActions Class Defines

the the “Component”“Component” that is that is Registered with JINIRegistered with JINI

Page 62: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-62

CSE300

Objectives and Utility of JINIObjectives and Utility of JINI For Users, JINI OffersFor Users, JINI Offers

Sharing of Resources (Services) over Network Location Transparency of Users and Services Both Critical for “Moving” Personnel

For Stakeholders, JINI ProvidesFor Stakeholders, JINI Provides Infrastructure for Federating Services in

Distributed Setting Programming Model to Register & Discover

Services Availability of Services Throughout Distributed

SettingLeading to Ease in Constructing, Maintaining, and Leading to Ease in Constructing, Maintaining, and Evolving Network Centric ApplicationsEvolving Network Centric Applications

Page 63: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-63

CSE300

How Does JINI Work?How Does JINI Work? Resources Discover and Join Lookup ServiceResources Discover and Join Lookup Service When Resources Leave or Fail to Renew Leases 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 RegisterResource Register Services on Class-by-Class Basis Service Object (Java API - Method Signatures) Optional Descriptive Service Attributes

Page 64: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-64

CSE300

JINI Concepts and TermsJINI Concepts and Terms RegistrationRegistration of Services via of Services via Leasing MechanismLeasing 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-AvailabilityLeasing Supports High-Availability Registration and Renewal Process Upon Failure, Services Removed from Registry

Clients, Resources, Lookup Can Occupy Same or Clients, Resources, Lookup Can Occupy Same or Different Computing NodesDifferent Computing Nodes

Page 65: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-65

CSE300

JINILookupService

Printer Resource

Service ObjectService Attributes

Leasing/Lease Renewal

PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob cancelJob

Class and Methods Define Servicesto beRegistered

Registration & LeasingRegistration & Leasing FOREVER or EXPIRATION DATE (millisecs)FOREVER or EXPIRATION DATE (millisecs) Renewal Must Occur Prior to ExpirationRenewal Must Occur Prior to Expiration JINI Provides Lease Renewal Manager to Allow JINI Provides Lease Renewal Manager to Allow

Resource to Delegate Renewal ResponsibilityResource 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!

Page 66: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-66

CSE300

JINI Support for Distributed ComputingJINI Support for Distributed Computing

Legacy

Legacy

COTS

COTS

Database

Legacy COTS

Database

Resources Provide ServicesJava

Client

JavaClient

LegacyClient

DatabaseClient

COTSClient

ClientsUsingServices

JINI LookupService

JINI LookupService

RedundantLookups

Page 67: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-67

CSE300

Component Perspective and JINIComponent Perspective and JINI Resources as ComponentsResources 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

JavaClient

JINI LookupService

Constructed via Services of Legacy, COTS, Database, etc.Lookup Registered ServicesFunctionality via Service ReuseServices as Component APIs

Page 68: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-68

CSE300

Two Example ResourcesTwo Example Resources University ApplicationUniversity 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 PartsMilitary Application - Database of Parts Ability to Requisition/Add/Delete Parts Different User Authority Based on Rank

For Both:For Both: Client to JINI to Discover Services Client to Resource for Method Invocation

(Resembles RMI)

Page 69: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-69

CSE300

What Does an Actual System Look Like?What Does an Actual System Look Like?

JINILookupService

JavaGUI

UDB Client

University DBResource (UDB)

JavaGUI

MDB Client

UDBServer ServiceGetClasses();PreReqCourse();GetVacantClasses();EnrollCourse();AddCourse();RemoveCourse();

MDBServerGetPartsGetRequisitionGetReqPartsWritePartsWriteRequisitionDeletePartDeleteRequisitionAddPartsRemovePartAddRequisition

Military Requisition

DB Resource

Page 70: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-70

CSE300

Join, Lookup, and Service InvocationJoin, Lookup, and Service Invocation

ClientResource

Service ObjectService Attributes

Lookup ServiceRequestServiceAddCourse(CSE900)

ReturnService

Proxy toAddCourse( )

Join

Register & Lease Services CourseDB ClassContains Method AddCourse ( )

1. Client Invokes AddCourse(CSE900) on Resource2. Resource Returns Status of Invocation

Service Invocation via Proxy by Transparent RMI Call

Service Object

Service Attributes

Registry of Entries

Page 71: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-71

CSE300

Services of Military ApplicationServices of Military Application Query Service: Query Service:

GetParts: Queries DB for Parts GetRequisition: Queries DB for Requisition GetReqParts: All Requisition Details for a

Particular Part Update Service: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 OmittedOther Services/Methods Omitted Notice: These are Just Public Methods Organized into Notice: These are Just Public Methods Organized into

Logical GroupingsLogical Groupings JINI Allows Searching of Groupings by ServiceJINI Allows Searching of Groupings by Service

Page 72: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-72

CSE300

Execution Process of Client using JINIExecution Process of Client using JINI

SecurityAuthorization

Services

Security Registration

Services

LookupService

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

SecurityPolicy

ServicesMilitaryDB

Resource8 Return Result of IsClient_Registered(…)

USR6 CreateRequisition(Token, Tank Details, Harris)

Page 73: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-73

CSE300

Services ConsoleServices Console

Page 74: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-74

CSE300

Services GUIServices GUI

Page 75: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-75

CSE300

What is .NET?What is .NET? .NET is Microsoft’s Solution to Enterprise .NET is Microsoft’s Solution to Enterprise

Computing and InteroperabilityComputing and Interoperability Aimed to Compete with Java/J2EEAimed to Compete with Java/J2EE Interoperability: Old (CORBA, COM) & New (RMI)Interoperability: Old (CORBA, COM) & New (RMI) Provides Uniform Programming Environment via Provides Uniform Programming Environment via

Extension of C - C#Extension of C - C#

Page 76: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-76

CSE300

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

Business TierBusiness Tier Data TierData Tier

Presentation TierPresentation Tier

Windows Forms

Web Forms

Business to Business

Data Object (Class)

DataSet

DataSetDataSet

InternetInternetIntranetIntranet

Data AdapterData Adapter

Data AdapterData Adapter

(BizTalk, for example)

XML

MyApp.Exe

IE

Page 77: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-77

CSE300

What are .Net Components?What are .Net Components? CTS (Common Type System) CTS (Common Type System)

Defines Common Standard for Languages CLR (Common Language Runtime)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.NETASP.NET This Component Provides a Layer of Classes for

Web Services

Page 78: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-78

CSE300

What are .Net Components?What are .Net Components? Windows FormsWindows Forms

Provides A Layer Of Classes For The Windows User Interface

ADO.NETADO.NET Provides Classes for Data Access Including

Database and XML Base Class LibraryBase Class Library

Low Level Classes Capture Core .Net Functionality

Provides Infrastructure for Construction of Remaining .net Framework Classes

Page 79: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-79

CSE300

Remoting in .NetRemoting in .Net Remoting Makes an Object in One Process Available Remoting Makes an Object in One Process Available

to an Application in Another Process (Akin to RMI)to an Application in Another Process (Akin to RMI) Marshalling Enables a Controlled Data Marshalling Enables a Controlled Data

Communication Between the 2 ProcessesCommunication Between the 2 Processes Marshalling an Object Can Occur in 2 WaysMarshalling 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

Page 80: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-80

CSE300

Remoting in .NETRemoting 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

the server

Page 81: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-81

CSE300

Remoting in .NETRemoting 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 making any

additional calls to the server

Page 82: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-82

CSE300

Recall Similarity to RMI in JavaRecall Similarity to RMI in Java

Start rmiregistery

Unmarshall UnmarshallMarshall Marshall

NDR NDR NDR NDR

Stub Stub Skel Skel

Transport Transport Transport Transport

HelloApplet HelloImpl

Hello

1 2 3

4

5

ServerClient

RMI Layer

rmic HelloImpl.java

Java Objects in JVMs (on Different Computers) Java Objects in JVMs (on Different Computers) Transparently Invoke Each Other's MethodsTransparently Invoke Each Other's Methods

RMI Enables RMI Enables Distributed Object ComputingDistributed Object Computing

Page 83: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-83

CSE300

Web Services ASP.NETWeb Services ASP.NET Communication Based on Open ProtocolsCommunication Based on Open Protocols

Data via XML Schema via XSD

Other Supported Protocols Inlcude:Other Supported Protocols Inlcude: UDDI DISCO WSDL SOAP

Page 84: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-84

CSE300

ADO.NET ArchitectureADO.NET Architecture

Page 85: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-85

CSE300

CORBA vs. JINI vs. .NETCORBA vs. JINI vs. .NET Important to Differentiate BetweenImportant to Differentiate Between

Standard (CORBA) – Vendors Implement Technologies (JINI, .NET)

Many Different Pros and Cons w.r.t. Infrastructure, Many Different Pros and Cons w.r.t. Infrastructure, Usage, Environment, Interoperability, Ease of Use, Usage, Environment, Interoperability, Ease of Use, Programming Requirements, etc. etc. etc.Programming Requirements, etc. etc. etc.

Many Different Perspectives to Compare Capabilities Many Different Perspectives to Compare Capabilities and Functionalities of Technologiesand Functionalities of Technologies

What about Other Approaches?What about Other Approaches? Terrific Presentation by D. Schmidt Combines Patterns and Middleware http://www.cs.wustl.edu/~schmidt/patterns-

frameworks-middleware.ppt

Page 86: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-86

CSE300

Brief Comparison… Brief Comparison… Database ConnectivityDatabase Connectivity

Java uses JDBC and .Net uses Ado.net or ODBC.NET

Cross platform interoperability Cross platform interoperability J2EE and CORBA Easily Supports

Interoperation .Net Focuses on Windows Platform Programming LanguagesProgramming Languages

.Net and CORBA Support Multiple Languages J2EE Focuses on Java (with Links to IDL)

Cross Vendor InteroperabilityCross Vendor Interoperability J2EE and CORBA Guaranteed by Specifications

Microsoft is the only vendor for .Net Remoting: Strong Similarities Across All ThreeRemoting: Strong Similarities Across All Three

Page 87: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-87

CSE300

Web Service Oriented Architectures (WSOA)Web Service Oriented Architectures (WSOA) An SOA is often Cast in a Web-Based SettingAn SOA is often Cast in a Web-Based Setting Possible Services include:Possible Services include:

Data Transfer (e.g. FTP) or Storage Service Troubleshooting Service

Service Operations (Messages) are Encapsulated Service Operations (Messages) are Encapsulated Behind a Message-Oriented Service InterfaceBehind 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

Page 88: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-88

CSE300

WSOA in PracticeWSOA in Practice From 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.

Page 89: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-89

CSE300

Web Services Architecture from W3CWeb Services Architecture from W3C Complex Complex

Architecture with Architecture with Many Different Many Different Capabilities and Capabilities and Features Features Open Ended

(Like Web) Target Multiple

Domains/Usages Current Web and Current Web and

Future (Emerging?) Future (Emerging?) Semantic WebSemantic Web

Page 90: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-90

CSE300

Another WSOA ExampleAnother WSOA Example

From: http://www.service-architecture.com/

Page 91: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-91

CSE300

Another WSOA ExampleAnother WSOA Example

From: http://www.service-architecture.com/

Page 92: Middleware, Service-Oriented Architectures and Grid Computing

Service Oriented ArchitectureReference Model

An informal SOA Ontology

http://ontolog.cim3.net/file/resource/workshop/jul-2006/soa2006-07.ppt

Page 93: Middleware, Service-Oriented Architectures and Grid Computing

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.

Page 94: Middleware, Service-Oriented Architectures and Grid Computing

Reference Model

Page 95: Middleware, Service-Oriented Architectures and Grid Computing

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

Page 96: Middleware, Service-Oriented Architectures and Grid Computing

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• Encourage re-use of business function

Page 97: Middleware, Service-Oriented Architectures and Grid Computing

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• It worked for us, it should work for machines

Page 98: Middleware, Service-Oriented Architectures and Grid Computing

What is not in the RM

• Service composition• Choreography, orchestration• Process Oriented Architecture

• Organizational framework• Who is doing what to whom

• Specific technologies• not even specific architectures

Page 99: Middleware, Service-Oriented Architectures and Grid Computing

Key concepts

Page 100: Middleware, Service-Oriented Architectures and Grid Computing

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.

Page 101: Middleware, Service-Oriented Architectures and Grid Computing

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

Page 102: Middleware, Service-Oriented Architectures and Grid Computing

InteractionInteracting 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 thesemantic engagement of the various systems.The semantic engagement of a system is a relationship between the system and information it may encounter.

Page 103: Middleware, Service-Oriented Architectures and Grid Computing

Real World EffectThe 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 theresult of an interaction is an effect (or a set/series of effects).

The real world effect is couchedin terms of changes to the state shared bythe participants and stakeholders ina service interaction

Page 104: Middleware, Service-Oriented Architectures and Grid Computing

About Services

Page 105: Middleware, Service-Oriented Architectures and Grid Computing

Conditions and Expectations

• Policy• Constraint representing the

intention of a participant in a service

• Contract• Constraint representing an

agreement between two or more participants.

Page 106: Middleware, Service-Oriented Architectures and Grid Computing

DescriptionThe service description represents the informationneeded in order to use, manage or provide a service.

• Service reachability• Service Functionality• Service Policies• Service Interface

Page 107: Middleware, Service-Oriented Architectures and Grid Computing

Execution ContextThe execution context is the set of infrastructure elements,process entities, policy assertions and agreements that areidentified as part of an instantiated service interaction,and thus forms a path between those with needs and thosewith capabilities

Page 108: Middleware, Service-Oriented Architectures and Grid Computing

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• Mechanical processing of RM not expected

Page 109: Middleware, Service-Oriented Architectures and Grid Computing

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

• It’s so ugly <duck/>

Page 110: Middleware, Service-Oriented Architectures and Grid Computing

An early concept map

Page 111: Middleware, Service-Oriented Architectures and Grid Computing

Concepts MapsConcepts maps were excellent graphical indices to text

Concepts, and relationships. All we needed

Page 112: Middleware, Service-Oriented Architectures and Grid Computing

On the cutting-room floor…

Page 113: Middleware, Service-Oriented Architectures and Grid Computing

Where we are

• Committee Specification published

• Reference Architecture effort started

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

Page 114: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-114

CSE300

Comments on WSOAComments on WSOA Wealth of Information on WSOA Available on-LineWealth of Information on WSOA Available on-Line Let’s Review Four Other Presentations BrieflyLet’s Review Four Other Presentations Briefly

http://download.microsoft.com/download/b/d/b/bdb24175-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/SemanticServiceOrientedArchitectureTutorial.ppt

All Links on Course Web PageAll Links on Course Web Page Last Presentation Transitions from SOA to Semantic Last Presentation Transitions from SOA to Semantic

WebWeb

Page 115: Middleware, Service-Oriented Architectures and Grid Computing

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 viewpoints expressed by the author.

Page 116: Middleware, Service-Oriented Architectures and Grid Computing

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.3.Delivers nontrivial qualities of service

Page 117: Middleware, Service-Oriented Architectures and Grid Computing

Grid Computing Benefits

Exploit Underutilized resources CPU Scavenging, Hotspot leveling

Resource Balancing Virtualize resources across an enterprise

Data Grids, Compute Grids

Enable collaboration for virtual organizations

Page 118: Middleware, Service-Oriented Architectures and Grid Computing

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 Solicits involvement from industry, research groups, and academics

Page 119: Middleware, Service-Oriented Architectures and Grid Computing

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/

Page 120: Middleware, Service-Oriented Architectures and Grid Computing

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-

ResourceProperties WS-

RenewableReferences WS-ServiceGroup WS-BaseFaults

Page 121: Middleware, Service-Oriented Architectures and Grid Computing

Grid and Web Services Standards

Convergence of Core Technology Standards allows Common base for Business and Technology Services

Grid

OGSi

GT2

GT1

Web HTTPWSDL,

SOAP

WS-*

Have beenconverging

WSRF

Started far apart in

applications &

technology

XML

BPEL

WS-I Compliant

TechnologyStack

Page 122: Middleware, Service-Oriented Architectures and Grid Computing

Service Oriented Architecture

“What is Service-Oriented Architecture?”. Hao He. http://webservices.xml.com/lpt/a/ws/2003/09/30/soa.html

“Service-Oriented Architecture: A Primer”. Michael S. Pallos. http://www.bijonline.com/PDF/SOAPallos.pdf

“The Benefits of a Service-Oriented Architecture”. Michael Stevens. http://www.developer.com/design/article.php/1041191

Web Services Specifications - http://www.w3.org/2002/ws/

Grid Computing

Global Grid Forum (http://www.ggf.org)

The Globus Alliance ( http://www.globus.org)

“The Physiology of the Grid”. Ian Foster, Carl Kesselman, Jeffrey M. Nick, Steven Tuecke. http://www.globus.org/research/papers/ogsa.pdf

“The Anatomy of the Grid”. Ian Foster, Carl Kesselman, Steven Tuecke. http://www.globus.org/research/papers/anatomy.pdf

Web Services Resource Framework - http://www.globus.org/wsrf/

Page 123: Middleware, Service-Oriented Architectures and Grid Computing

What is the Grid?

• The World Wide Web provides seamless access to information that is stored in many millions of different geographical locations

• In contrast, the Grid is an emerging infrastructure that provides seamless access to computing power and data storage capacity distributed over the globe.

From: http://gridcafe.web.cern.ch/gridcafe/demos/Grid-beginners.ppt

Page 124: Middleware, Service-Oriented Architectures and Grid Computing

• The term Grid was coined by Ian Foster and Carl Kesselman (Grid bible “The Grid: blueprint for a new computing infrastructure”).

• The name Grid is chosen by analogy with the electric power grid: plug-in to computing power without worrying where it comes from, like a toaster.

• The idea has been around under other names for a while (distributed computing, metacomputing, …).

•This time, technology is in place to realise the dream on a global scale.

What is the Grid?

Page 125: Middleware, Service-Oriented Architectures and Grid Computing

• The Grid relies on advanced software, called middleware, which ensures seamless communication between different computers and different parts of the world

How will it work?

• The Grid search engine will not only find the data the scientist needs, but also the data processing techniques and the computing power to carry them out

• It will distribute the computing task to wherever in the world there is spare capacity, and send the result to the scientist

Page 126: Middleware, Service-Oriented Architectures and Grid Computing

How will it work?The GRID middleware:• Finds convenient places for the scientists “job” (computing task) to be run

• Optimises use of the widely dispersed resources

• Organises efficient access to scientific data

• Deals with authentication to the different sites that the scientists will be using

• Interfaces to local site authorisation

and resource allocation policies

• Runs the jobs

• Monitors progress

• Recovers from problems

… and ….

Tells you when the work is complete and transfers the result back!

Page 127: Middleware, Service-Oriented Architectures and Grid Computing

What are the challenges?

Must share data between thousands of scientists with multiple interests

Must link major computer centres, not just PCs

Must ensure all data accessible anywhere, anytime

Must grow rapidly, yet remain reliable for more than a decade

Must cope with different management policies of different centres

Must ensure data security: more is at stake than just money!

Must be up and running by 2007

Page 128: Middleware, Service-Oriented Architectures and Grid Computing

Benefits for Science

• More effective and seamless collaboration of dispersed communities, both scientific and commercial

• Ability to run large-scale applications comprising thousands of computers, for wide range of applications

• Transparent access to distributed resources from your desktop, or even your mobile phone

• The term “e-Science” has been coined to express these benefits

Page 129: Middleware, Service-Oriented Architectures and Grid Computing

Grid projects in the world

•NASA Information Power Grid•DOE Science Grid•NSF National Virtual Observatory•NSF GriPhyN•DOE Particle Physics Data Grid•NSF TeraGrid•DOE ASCI Grid•DOE Earth Systems Grid•DARPA CoABS Grid•NEESGrid•DOH BIRN•NSF iVDGL

•UK e-Science Grid•Netherlands – VLAM, PolderGrid•Germany – UNICORE, Grid proposal•France – Grid funding approved•Italy – INFN Grid•Eire – Grid proposals•Switzerland - Network/Grid proposal•Hungary – DemoGrid, Grid proposal•Norway, Sweden - NorduGrid

•DataGrid (CERN, ...)•EuroGrid (Unicore)•DataTag (CERN,…)•Astrophysical Virtual Observatory•GRIP (Globus/Unicore)•GRIA (Industrial applications)•GridLab (Cactus Toolkit)•CrossGrid (Infrastructure Components)•EGSO (Solar Physics)

Page 130: Middleware, Service-Oriented Architectures and Grid Computing

Grid Applications for Science

• Medical/Healthcare (imaging, diagnosis and treatment )

• Bioinformatics (study of the human genome and proteome to understand genetic diseases)

• Nanotechnology (design of new materials from the molecular scale)

• Engineering (design optimization, simulation, failure analysis and remote Instrument access and control)

• Natural Resources and the Environment (weather forecasting, earth observation, modelingand prediction of complex systems)

Page 131: Middleware, Service-Oriented Architectures and Grid Computing

Medical/Healthcare Applications

“The Grid makes it possible to use large collections of images in new, dynamic ways, including medical diagnosis.”

“The ability to visualise 3D medical images is key to the diagnosis of pathologies and pre-surgical planning”

“The Grid will enable a standardized, distributed digital mammography resource for improving diagnostic confidence"

Quotes from: http://gridoutreach.org.uk

• Digital image archives

• Collaborative virtual environments

• On-line clinical conferences

Page 132: Middleware, Service-Oriented Architectures and Grid Computing

Bioinformatics

“Every time a new genome is sequenced the result is compared in a variety of ways with other genomes. Each code is made of 3.5 billion pairs of chemicals…”

• Capturing the complex and evolving patterns of genetic information, determining the development of an embryo

• Understanding the genetic interactions that underlie the processes of life-form development, disease and evolution.

Page 133: Middleware, Service-Oriented Architectures and Grid Computing

Nanotechnology

“The Grid has the potential to store and analyze data on a scale that will support faster, cheaper synthesis of a whole range of new materials.”

Quotes from: http://gridoutreach.org.uk

• New and 'better' materials

• Benefits in pharmaceuticals, agrochemicals, food production, electronics manufacture from the faster, cheaper discovery of new catalysts, metals, polymers, organic and inorganic materials

Page 134: Middleware, Service-Oriented Architectures and Grid Computing

Natural Resources/Environment

“Federations of heterogeneous databases can be exploited through the Grid to solve complex questions about global issues such as biodiversity.”

Quotes from: http://gridoutreach.org.uk

• Modeling and prediction of earthquakes

• Climate change studies and weather forecast

• Pollution control

• Socio-economic growth planning, financial modeling and performance optimization

Page 135: Middleware, Service-Oriented Architectures and Grid Computing

Precursors of the Grid

• SETI@home: sharing of spare PC processing power to analyze radio signals

• Napster: sharing of data (music) between computers

• Entropia DCGrid: commercial solution for sharing workstations within a company

The difference:The Grid CERN is developing will combine resources at major computer centers, and require dedicated equipment and sophisticated middleware to monitor and allocate resources

Page 136: Middleware, Service-Oriented Architectures and Grid Computing

SETI@home: a grassroots Grid

>1 million years of computer processing time

>3.5 million have downloaded the screensaver

>30 Teraflops rating (ASCI White = 12 Teraflops)

Page 137: Middleware, Service-Oriented Architectures and Grid Computing

Spawned a cottage industryXpulsar@home, Genome@home, Folding@home, evolutionary@home, FightAIDS@home, SARS@home...

Spawned a real industryEntropia, United Devices, Popular Power...

Major limitations:Only suitable for “embarrasingly parallel” problemsCycle scavenging relies on goodwill

Spinoff from SETI@home

Page 138: Middleware, Service-Oriented Architectures and Grid Computing

Who will use Grids?

• Computational scientists & engineers: large scale modeling of complex structures

• Experimental scientists: storing and analyzing large data sets

• Collaborations: large scale multi-institutional projects

• Corporations: global enterprises and industrial partnership

• Environmentalists: climate monitoring and modeling

• Training & education: virtual learning rooms and laboratories

Page 139: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-139

CSE300

Comments on Grid ComputingComments on Grid Computing What is Applicability of Grid Computing to the What is Applicability of Grid Computing to the

Medical Domain and its Applications?Medical Domain and its Applications? Let’s Review Three Other Presentations BrieflyLet’s Review Three Other Presentations Briefly

http://www.aci-agir.org/publis/posterAgirParistic2006.PPT

http://bmi.osu.edu/resources/presentations/BISR_overview_poster.ppt

http://www.dma.unina.it/~murli/ISSGC06/session-31.5/ISSGC06%20Experience%20with%20biomed%20applications%20v1.ppt

All Links on Course Web PageAll Links on Course Web Page

Page 140: Middleware, Service-Oriented Architectures and Grid Computing

MW+SOA-140

CSE300

Final CommentsFinal Comments Three Converging Technologies:Three Converging Technologies:

Classic (CORBA) and Emerging (Jini, .NET) Middleware

Web-Based Service Oriented Architectures and Computing

Grid Computing Think back to “Macro Architectures” Think back to “Macro Architectures”

Systems of Systems Old + New Centralized + Distributed Solving “Huge” Problems Facilitating Access (Services)