CSE 5810 Middleware, Service-Oriented Architectures and Grid Computing

CSE 5810 Middleware, Service-Oriented Architectures and Grid Computing

CSE 5810 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, Scott Craig and Prior CSE333 students for providing portions of this material. MW+SOA-1 What is a Distributed Application? CSE 5810

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 Health IT Systems and Health Information Exchange Exhibit All of These Characteristics and More! MW+SOA-2 What is a Distributed Application? CSE 5810 System of Systems Heterogeneity Hardware OS, PLs

Network Centric Environment DB Client Legacy Client Legacy Database COTS Dynamic Environment High-Availability Performance Java Client Server Server Legacy

Database COTS Java Client COTS Client Increase Productivity Transparent Interoperation New/Innovative Information Use MW+SOA-3 Another View Todays Reality CSE 5810 Premise: Artifacts - set of DB, Legacy, COTS,

GOTS, Each w/ API Premise: Users New and Existing Utilize Artifact APIs Distributed Application, DA Artifacts + Users What are the Issues? How Do they Interact? Heterogeneity Security Concerns Different Programmatic Models Etc. Etc. Etc. Database COTS Legacy Legacy Client Java Client GOTS

NETWORK GOTS Client Legacy Database Database Client COTS Client MW+SOA-4 Why is Distributed Computing Needed? CSE 5810 Todays Environments Contain Applications Created with Multiple Prog. Languages Executing on Heterogeneous Platforms Locally and Geographically Distributed

Distributed Computing Applications Must Allow Seamless and Transparent Interoperation Provide Tools for Engineers and Users Result: Inter-Operating Environment Utilize Information in New/Innovative Ways Leveraged to Increase Productivity Support Diverse User Activities Dynamically Respond to Changes MW+SOA-5 Striving for New Techniques/Technologies CSE 5810 We Must Diverge from Business as Usual C Programming with RPC Customized Development without Reuse Solutions that Arent Extensible and Evolvable Cobbling Together Solutions w/o Method or Reason is Unacceptable and Doomed to Fail! We Must Face Todays Realities Legacy Code is Fact of Life New Technologies Offer New Challenges

Adopt to Leverage Their Benefits We Must Draw Careful Balance to Opt for Mature Technologies While Targeting Emerging Technologies with Potential! MW+SOA-6 Who are the Players? CSE 5810 Stakeholders Software Architects (Requirements) System Designers (Solutions) Application Builders (Implementation) Stakeholders Striving to Provide System Interaction and Information Exchange Utilization of Existing Applications in New and Innovative Ways End-Users at Various Skill Levels and with Specific and Limited Access Requirements Novice vs. Adept vs. Expert

Who Uses What When and for How Long? MW+SOA-7 Why a Distributed Application? CSE 5810 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 MW+SOA-8 Distributed Systems CSE 5810 Fundamental Realities of Distributed Systems Co-located Distributed Fast Slower Failures

Objects fail together Objects fail separately, Network can partition Concurrent Access Only with multiple threads Yes Yes Not Inherently Often Add-On Capability Communication Secure MW+SOA-9

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 What is Service Oriented Architecture (SOA)? An SOA application is a composition of Service services Registry A service is the atomic unit of an Find Register SOA Services encapsulate Service Service Bind,

a business process Consumer Execute Provider Service Providers Register themselves Service use involves: Find, Bind, Execute Service Registry SOA Actors Find Service Consumer Bind, Execute Service Provider Provides service

Register a stateless, location transparent business Service Registry Allows service consumers to locate service providers that meet required criteria Service Consumer Uses service providers to complete business processes Service Provider SOA Benefits Business Benefits Focus on Business Domain solutions

Leverage Existing Infrastructure Agility Technical Benefits Loose Coupling Autonomous Service Location Transparency Late Binding Service Registry Find Service Consumer Register Bind, Execute Service Provider What is a Service Oriented Architecture? CSE 5810

Solutions that Focus on Services that Need to be Available to Meet Need of Users (Entities) Users are Assumed to be Interacting via Client Applications (Browser or Standalone) Interactions with Services Transparent to Users (Integrated into Software) Interactions Between Entities Occur via a Message Exchange - Conceptual Resources are Software Artifact Accessible via API Consisting of Services Services are Logical Grouping of Methods (Functions) that are Available for Use Services are Utilized When Messages are Invoked Against Them by Outside Users Both Web-Based and Middleware Settings MW+SOA-14 Middleware-Based SOA CSE

5810 Distributed Object Computing Platforms are Well Established in the Field - Historically DCE (Distributed Computing Environment) COM/OLE (Component Object Model/Object Linking and Embedding) Modern Middleware (JINI, CORBA, .NET): CORBA Standards Committee (OMG) Controls Technology Many Programming Languages JINI Sun-Based Product The Poor Mans CORBA Java .NET Microsofts Forward into the Modern Market C# (we will skip) MW+SOA-15 What Must All SOA Provide? CSE 5810 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 Service Provider MW+SOA-16 SOA Akin to CBD CSE 5810 MW+SOA-17

Supplier /Consumer Model CSE 5810 SUPPLY Build New Wrap Existing Buy CONSUME Assemble Applications MANAGE Publish Subscribe Catalog Browse MW+SOA-18 Objectives of SOA CSE 5810

Can SOAs Support Highly-Available Distributed Applications? Can Replicated Services be Registered and Available for Use by Clients? Can SOAs Support a Network-Centric Environment with Dynamic Clients and Services? Will Clients Continue to Operate Effectively if a Replicated Service Fails? Can SOAs be Utilized to Maintain Data Consistency of Replicas? Are SOAs Easy to Learn and Use? What is Maturity Level of SOAs Technology? How can SOA be Leverage for HIE/HIT? MW+SOA-19 Overview of Presentation CSE

5810 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 Where does Cloud Computing Fit? MW+SOA-20

What is CORBA? CSE 5810 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 MW+SOA-21

What is CORBA? CSE 5810 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 MW+SOA-22 What is CORBA? CSE 5810 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 Application

Interfaces Domain Interfaces Object Request Broker Object Services MW+SOA-23 What is CORBA? CSE 5810 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) Factory Naming Context

Object Request Broker Event Channel Object Life Cycle Naming Events Relationships Externalization Transactions Trader Query Property MW+SOA-24 What is CORBA? CSE 5810

Allow Interactions from Client to Server CORBA Installed on All Participating Machines Client Application Static Stub DII Server Application ORB Interface ORB Interface Skel eton DSI Object Adapter Client ORB Core Network

IDL - Independent Same for all applications Server ORB Core There may be multiple object adapters MW+SOA-25 CORBA: Architectural Goals CSE 5810

Simplicity Consistency Scalability Usability for End Users Usability for Administrators Usability for Implementers Flexibility of Security Policy Independence of Security Technology Application Portability Interoperability Performance Object Orientation MW+SOA-26 Role of an Object Request Broker (ORB) CSE 5810

ORB Provides the Underlying Infrastructure for Supporting Interoperating Software Systems (Applications) Composed of Distributed Objects ORB Provides the Basic Request Delivery ORB Provides Interface Definitions Location is Transparent to the Caller and Object Implementation Caller and the Object Implementation Can be in the Same Process thru Opposite Sides of the World ORB Manages Local Location and Optimization ORB Client Application Object Implementation MW+SOA-27 Interface Definition Language, IDL CSE 5810

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 MW+SOA-28 ORB and High Level View of Requests CSE 5810 The Request Consists of Target Object

Operation (Method) Parameters Request Context (Optional) Client Application Object Implementation Object Call IDL Boundary Methods and Data ORB Object referenceRequest IDL Boundary Object dispatcher MW+SOA-29 CORBA Components and Interfaces CSE

5810 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 Dynamic Invoke Client Stubs Object Implementation

ORB Interface Implementation Skeletons Object Adapter ORB Core One interface One interface per object adaptor One interface per object operation ORB internal interface MW+SOA-30 Interfaces CSE 5810

Objects are Defined in IDL via Interfaces Object Definitions (Interfaces) are Manifested as Objects in the Interface Repository, as Client Stubs, and as Implementation Skeletons Descriptions of Object Implementations are Maintained as Objects in the Impl. Repository IDL Interface Definitions Interface Repository Access Client Stubs Includes Client Implementation Installation Implementation Skeletons

Includes Implementation Repository Describes Object Implementation MW+SOA-31 CORBA: Repositories CSE 5810 Interface Repository Client access to definitions Type checking for

signatures Traversal of inheritance graphs Implementation Repository IDL Interface Definitions Interface Repository Location of implementation Activation information Administration control Security Resource allocation Implementation Installation

Client Stubs Implementation Skeletons Implementation Repository Access Includes Client Describes Includes Object Implementation MW+SOA-32 Client Side CSE 5810

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 Client Object Repository Object Implementation Dynamic Invoke Client Stubs ORB Interface

Implementation Skeletons Object Adapter ORB Core MW+SOA-33 Object Implementation Side CSE 5810 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

Object Implementation Client Dynamic Invoke Client Stubs ORB Interface ORB Core Implem. Skeletons Implementation Repository Object Adapter MW+SOA-34 Repositories: Interface and Implementation CSE

5810 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 MW+SOA-35 Three Types of ORBs Single Process Library Resident CSE 5810 Client

Object ORB and implementations implemented as libraries (routines) resident in the client. Request Client and Implementation Resident ORB Client ORB Object Request ORB implemented as libraries (routines) resident in the clients and in the

implementations. MW+SOA-36 Three Types of ORBs Server or Operating System Based CSE 5810 Client ORB Object Request ORB is implemented as a server (separate process) which brokers requests between client and implementation processes. ORB is part of the

operating system. MW+SOA-37 Three Types of Implementations CSE 5810 Single Process one shot Object Object Implementation Single Process Single method invocation Implementation is a single process that is activated upon the request delivery Multi-Threaded resident Object

Object Implementation Single Process Implementation is a permanent or resident multi-threaded process Method C Method B Method A MW+SOA-38 Three Types of Implementations CSE 5810 Multi-Process Object Object Implementation Process 1 Method A

Process 2 Method B Implementation is a set of processes dedicated to a particular (group of) method(s) Process 3 Method C Processes can be distributed MW+SOA-39 Interface Definition Language, IDL CSE 5810

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 MW+SOA-40 IDL: Modules and Interfaces CSE 5810 Module: Used to scope IDL identifiers.

Mapped to C++ namespace with the same name. Mapped to a C++ class if the namespace construct is not supported. Mapped to Java package with the same name. IDL declarations not enclosed in any module have global scope when mapped. Interface: Description of set of operations that a client may request of an object. Multiple inheritance supported Interface body may contain the following kinds of declarations: constant, type, attribute, and operation. MW+SOA-41 IDL: Basic Types CSE 5810 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 MW+SOA-42 IDL: Complex Types CSE 5810 Structures: struct FixedLengthStruct { long field1; // 32-bit short field2; // 16-bit

}; struct VariableLengthStruct { long field1; // 32-bit string field2; }; Discriminated Unions: Cross between the C union and switch statements. Enumerations: Ordered list of identifiers. enum quality_t { Poor, Fair, Good, Excellent}; MW+SOA-43 IDL: Complex Types (cont.) CSE 5810 Sequences: One-dimensional array with maximum size (fixed at compile time) and length (set at run time).

Unbounded Sequence: typdef sequence longSeq; Bounded Sequence: sequence 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. MW+SOA-44 IDL Example: GUI CSE 5810 /* * File Name: */ interface Dialog1 { void update(in Dialog1Data_t val); }; GUI.idl

#ifndef GUI_IDL #define GUI_IDL module GUI { struct timespec_t { long tv_sec; long tv_nsec; }; interface Dialog2 { void update(in Dialog2Data_t val); }; }; #endif // GUI_IDL 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); }; MW+SOA-45 IDL Example: Server CSE 5810 /* * File Name: */ Server.idl #ifndef SERVER_IDL #define SERVER_IDL #include "GUI.idl" interface Server { 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); enum reason_t { NotInitialized, ErrorDetected }; exception NotAvailable { reason_t reason; }; 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);

exception OperationTimeout {}; void registerMainWindow( in GUI::MainWindow val, in boolean flag) raises (OperationTimeout); void setMainWindowEnabled( in boolean flag) raises (OperationTimeout); }; #endif // SERVER_IDL MW+SOA-46 A Comparison of Jini and CORBA Andrew See Liyuan Yu Zhongying Wang Michael Collins What is CORBA?

Common Object Request Broker Architecture (CORBA) specification defines a framework for object-oriented distributed applications.. It is an open standard for heterogeneous computing. Allows distributed programs in different languages and different platforms to interact as though they were in a single programming language on one computer Object Request Broker (ORB) A software component that mediates transfer of messages from a program to an object located on a remote host. 0. Client ORB invocation 0

1 Network ORB 1. Locate CORBA objects and marshal parameters CORBA Object 2 3 5 6 7 Server Invocation ( with an object reference) 4

execution 2. Network Delay 3. Unmarshal parameters 4. Method Execution 5. Result marshal 6. Network Delay 7. Result unmarshal

CORBA Objects and IDL Each CORBA object has a clearly defined interface specified in CORBA interface definition language (IDL). Distributed objects are identified by object references, which are typed by the IDL interfaces. The interface definition specifies the member functions available to the client without any assumption about the implementation of the object. Example of IDL stockMarket.idl module stockMarket{ interface StockServer { float getStockValue (in string stockName); void setStockValue (in string stockName, in long value); } ..

} No Implementation details in IDL Stub and Skeleton Glue that connects language-independent IDL interface specifications to language specific implementation Client Object Object Stub Client Stub ORB Automatically generated by IDL compiler Design of the Game Project with CORBA Centralized Version:

l ocat e servi ce ret urn server ref erence l ocat e servi ce Nami ng Servi ce ret urn server ref erence Pl ayer1 Pl ayer2 pl ay regi st er Servi ce pl ay Game Server pl ay Two Games: Guess Game: Two Games (Cont.)

HangMan: Design Details--IDL module GameApp{ interface Player { void displayMessage(in string m); string getPlayerID(); }; interface GuessPlayer: Player { }; interface HangmanPlayer: Player { void drawMan(in long numWrong); }; interface Server { void addPlayer(in Player p); void removePlayer(in string playerID); void startGame(in string playerID); void QuitGame(in string playerID); void takeTurn(in string playerID);

}; interface GuessServer: Server { void takeTurn(in long number, in string playerID); }; interface HangmanServer: Server { void takeTurn(in char w,in string word, in string playerID); }; }; Design Details--UML <> GuessPl ayer <> Hangm anPl ayer <> GuessServer <> Hangm

anServer +t akeTurn( ) +t akeTur n( ) <> I nterface1 <> Pl ayer +addPl ayer ( ) +r emovePl ayer( ) +St art Game( ) +Qui t Game( ) +t akeTurn( ) +get Pl ayerI D( ) +di spl ayMessage( ) i mpl ement s Aut omat i cal l y generat ed by I DLt oJ AVA compi l er

i mpl ement s J ava I mpl ement at i on Gam eServerI m pl Pl ayerI m pl +addPl ayer( ) +removePl ayer( ) +St art Game( ) +Qui t Game( ) +t akeTurn( ) +get Pl ayerI D( ) +Di spl ayMessage( ) GuessPl ayer Hangm anPl ayer GuessServerI m pl

Hangm anServerI m pl +DrawMan( ) +t akeTur n( ) +t akeTurn( ) Design of the Game Project with CORBA Decentralized Version play Player1 return server info locate service return server info Naming Service

Player2 locate service register Service Return partner info Create playerlist Game Server Return partner info Design Details-IDL module GameApp { interface Player { void receiveMessage(in string m); string getPlayerID(); void startGame(in string data); void startNewGame(in string data); void QuitGame(); void response(string number, in string data);

void takeTurn(); }; interface Server { string addPlayer(in string p, in string ncRef); }; }; Design Details- UML Interface generated By IDL Compile Implement by programmer What is JINI? CSE 5810 An Infrastructure for Network Centric Applications in Spontaneous Environment

Clients Enter/Leave Network Unpredictably Resources and Services Enter/Leave due to Failure, Redundancy, Topology Change Both Typify Present/Future Army Systems Goals of JINI Plug-and-Play of Clients and Services Erasing Hardware/Software Distinction: Everything is a Service Enable Spontaneous Network Applications Architecture where Services Define Function Strive for Easy to Use/Understand Technology MW+SOA-61 Suns JINI Technology CSE 5810 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 MW+SOA-62 Current Status of JINI CSE 5810 Now an Apache Project https://river.apache.org/about.html https://river.apache.org/ https://river.apache.org/doc/specs/html/jini-spec.ht ml

Continued Further Development and Advancement of JINI Apache River 2.2.3 Released - February 21, 2016 MW+SOA-63 Java Computing Architecture and JINI CSE 5810 MW+SOA-64 JINI Components and Dependencies CSE 5810 Base Java Infrastructure Programming Model Services

Java VM Java APIs JNDI RMI JavaBeans Enterprise Beans Java Security JTS JMS Java + JINI Discovery/Join Leasing Distributed Security

Lookup Transactions Transaction Manager JavaSpaces Events Lookup service MW+SOA-65 How Does JINI Work? CSE 5810 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 Initiates Process for Client or Resource MW+SOA-66 Discovery by Resource & Client CSE 5810 JINI Lookup Service Discovery to Locate Services JINI Lookup

Service Discovery to Register Services Resource Client Service Object Service Attributes MW+SOA-67 Basic JINI Concepts CSE 5810 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 MW+SOA-68 Basic JINI Concepts CSE 5810 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 MW+SOA-69 JINI Resources & Services CSE 5810 JINI Lookup Service Register

Services Printer Resource Service Object Service Attributes Suns Initial Perspective JINI for Hardware Class and Printers, Digital Methods Define Cameras, etc. Services Plug-and-Play on to be Network Registered PrinterActions Class Defines the Component that is Registered with JINI PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus

getPrinterType installPrinter removePrinter startJob cancelJob MW+SOA-70 Objectives and Utility of JINI CSE 5810 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 MW+SOA-71 How Does JINI Work? CSE 5810 Resources Discover and Join Lookup Service When Resources Leave or Fail to Renew Leases Lookup Service Must Adjust Registry Time Lag Between Departure and Removal of Services from Registry What Happens When Client Receives Service Just Prior to Failure? Utilization of Java Exception Handling Client Code Written to Dynamically Adapt Resource Register Services on Class-by-Class Basis Service Object (Java API - Method Signatures) Optional Descriptive Service Attributes

MW+SOA-72 JINI Concepts and Terms CSE 5810 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 MW+SOA-73

Registration & Leasing CSE 5810 FOREVER or EXPIRATION DATE (millisecs) Renewal Must Occur Prior to Expiration JINI Provides Lease Renewal Manager to Allow Resource to Delegate Renewal Responsibility JINI Lookup Service Leasing/Lease Renewal Lease for 5 minutes (3000000 msec) Must Renew Before 5 Minutes Expire If Not Renewed, Lookup Removes If Failure, Lookup May Still Supply Service Until Expiration (5 mins) Client MUST be SMART! Printer Resource

Service Object Service Attributes Class and Methods Define Services to be Registered PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob cancelJob MW+SOA-74 JINI Support for Distributed Computing CSE 5810 Clients Using

Services JINI Lookup Service Redundant Lookups Java Client Database Legacy Resources Provide Services COTS Java Client Legacy Legacy

Client COTS Database Client COTS Client Database JINI Lookup Service Legacy COTS MW+SOA-75 Component Perspective and JINI CSE 5810 Resources as Components Resources Provide Services What Service Provides: Component Interface

Clients, Servers, Resources, Use Component Interface to Design/Construct Functionality Java Client Constructed via Services of Legacy, COTS, Database, etc. Lookup Registered Services Functionality via Service Reuse Services as Component APIs Legacy COTS JINI Lookup Service Database Legacy COTS MW+SOA-76

Two Example Resources CSE 5810 University Application Students can Register/Drop Courses and Check the Schedule/Catalog Faculty can Alter Course DB and Check the Schedule/Catalog Military Application - Database of Parts Ability to Requisition/Add/Delete Parts Different User Authority Based on Rank For Both: Client to JINI to Discover Services Client to Resource for Method Invocation (Resembles RMI) How Would Health Care Application Define Resources? MW+SOA-77

What Does an Actual System Look Like? CSE 5810 Java GUI UDB Client UDBServer Service GetClasses(); PreReqCourse(); GetVacantClasses(); EnrollCourse(); AddCourse(); RemoveCourse(); Java GUI MDB Client JINI Lookup Service MDBServer

GetParts GetRequisition GetReqParts WriteParts WriteRequisition DeletePart DeleteRequisition AddParts RemovePart AddRequisition University DB Resource (UDB) Military Requisition DB Resource MW+SOA-78 Join, Lookup, and Service Invocation CSE 5810 Request Service AddCourse(CSE900)

Lookup Service Registry of Entries Return Service Proxy to AddCourse( ) Client Service Object Service Attributes J Register & Lease Services CourseDB Class o i Contains Method AddCourse ( ) n Service Invocation via Proxy by Transparent RMI Call Resource Service Object Service Attributes

1. Client Invokes AddCourse(CSE900) on Resource 2. Resource Returns Status of Invocation MW+SOA-79 Services of Military Application CSE 5810 Query Service: GetParts: Queries DB for Parts GetRequisition: Queries DB for Requisition GetReqParts: All Requisition Details for a Particular Part Update Service: WriteParts: Store Part to DB WriteRequisition: Requisition Changes to DB DeletePart: Deletes Part from DB DeleteRequisition: Deletes Requisition from DB

Other Services/Methods Omitted Notice: These are Just Public Methods Organized into Logical Groupings JINI Allows Searching of Groupings by Service MW+SOA-80 Execution Process of Client using JINI CSE 5810 1 Register_Client(Harris,Security Off., Military) Military Client 4 Return Result,Create_Token(Security Off., Token) 2 Verify_UR(Harris, Security Off.) 5. Discover/Lookup(MilitaryDb,Modification, CreateRequisition) Returns Proxy to Military Client 6 CreateRequisition(Token, Tank Details, Harris) 11 Return Result,CreateRequisition() Lookup Service Security

Registration Services 3 Client OK? USR Security Authorization Services 7 IsClient_Registered(Token) 9 Check_Privileges(Token, MilitaryDb, Modification, CreateRequisition, [Tank Details, Harris]) MilitaryDB Resource 8 Return Result of IsClient_Registered() Security Policy Services 10 Return Result of Check_Privileges() MW+SOA-81 Services Console

CSE 5810 MW+SOA-82 Services GUI CSE 5810 MW+SOA-83 Jini Jini Background Embedded hardware is network-centric, not disk-centric Networks are dynamic; so is Jini Object interface; not network protocol Service: A network-accessible device that provides a useful function Client: Any user who requests services Runtime Architecture

Federation of services No central authority Lookup Service Directory of currently available services Services can be searched by clients Execution of services is independent of Jini As backup, Jini also allows network protocol How Jini Works Separation of Interface & Implementation Services may grant varying access to clients Entire service is downloaded and run locally

Service object is a proxy to remote server Methods are remote calls to service, which actually does the work Both local and remote objects share work Separation of Interface & Implementation Client is not required to know network protocol between proxy & service Service responsible for service object; may communicate using RMI, CORBA, DCOM, etc. Jini Program Design Player One

player for all Games Games Separate communication from game specific rules Generalize common game tasks Add/remove a player Take a turn Update Player state Design Games Interface GameProxy Interface Game Interface RemoteGame BasicGameProxy AbstractGame

TurnBasedGame HangmanProxy BlackjackProxy GuessingGame Hangman Blackjack Design Players Interface Player PlayerImpl (terminal based) GuiPlayer (GUI based) Terminal and GUI based clients have same functionality. Implementation Lease Jini

name service Register GameProxy Server Remote Game GameProxy Lookup Player addPlayer, TakeTurn addPlayer, GameProxy TakeTurn (local processing) Implementation Code samples Creating the server-side object: Game impl = new GuessingGame(); RemoteGame implProxy = (RemoteGame)exporter.export(impl);

Creating the proxy: smartProxy = new BasicGameProxy(implProxy); Registering the proxy: ServiceItem item = new ServiceItem(null, smartProxy, attrs); reg = registrar.register(item, Lease.FOREVER); Implementation Code samples (cont.) Player taking a turn: Player: protected void takeTurn(String action){ game.takeTurn(action,id); } GameProxy this version just forwards to remote

implementation: public void takeTurn(String action, Object id) throws RemoteException { impl.takeTurn(action,id); } player.setGameData(data); The rules for the game could be in the RemoteGame implementation, or the Game Proxy, or split between them. Web Service Oriented Architectures (WSOA) CSE 5810 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 MW+SOA-97 WSOA in Practice CSE 5810 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. MW+SOA-98 Web Services Architecture from W3C CSE 5810 Complex Architecture with Many Different Capabilities and Features Open Ended (Like Web) Target Multiple Domains/Usages Current Web and Future (Emerging?) Semantic Web MW+SOA-99

Another WSOA Example CSE 5810 From: http://www.service-architecture.com/ MW+SOA-100 Another WSOA Example CSE 5810 From: http://www.service-architecture.com/ MW+SOA-101 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. 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 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 Source: What is the Grid? A Three Point Checklist, Ian Foster, Argonne National Laboratory & University of Chicago 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 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

Heavy involvement of Academic Groups and Industry First meeting in June of 1999, Based off the IETF charter (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 Companies involved in Grid Computing

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

Jivalti Mithral Mind Electric Mojo Nation NewsToYou.com NICE, Italy Noemix, Inc. Oracle Parabon Platform Computing Popular Power Source: http://www.gridcomputing.com/

Powerllel ProcessTree Sharman Networks Kazza Sun Gridware Sysnet Solutions Tsunami Research Ubero United Devices Veritas Xcomp 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 WSRenewableReferences WS-ServiceGroup WS-BaseFaults Grid and Web Services Standards Grid GT1 Started far apart in applications & technology Web

GT2 OGS i Have been converging SDL, W ML X P SOAP HTT WS-* BPEL WSRF WS-I Compliant Technology Stack

Convergence of Core Technology Standards allows Common base for Business and Technology Services 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/ 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 What is the Grid? 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. How will it work? The Grid relies on advanced software, called middleware, which ensures seamless communication between different computers and different parts of the world 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 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! 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 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 Grid projects in the world 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 NASA Information Power Grid

DOE Science Grid NSF National Virtual Observatory NSF GriPhyN DOE Particle Physics Data Grid NSF TeraGrid DOE ASCI Grid DataGrid (CERN, ...) DOE Earth Systems Grid EuroGrid (Unicore) DARPA CoABS Grid DataTag (CERN,) NEESGrid Astrophysical Virtual Observatory DOH BIRN GRIP (Globus/Unicore) NSF iVDGL GRIA (Industrial applications) GridLab (Cactus Toolkit) CrossGrid (Infrastructure Components) EGSO (Solar Physics) 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, modeling and prediction of complex systems) Medical/Healthcare Applications Digital image archives Collaborative virtual environments On-line clinical conferences The Grid will enable a standardized, distributed digital mammography resource for improving diagnostic confidence" 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 presurgical planning Quotes from: http://gridoutreach.org.uk Bioinformatics 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. 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 Nanotechnology 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 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 Natural Resources/Environment Modeling and prediction of earthquakes Climate change studies and weather forecast Pollution control Socio-economic growth planning, financial modeling and performance optimization 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 Precursors of the Grid [email protected]: 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 [email protected]: a grassroots Grid >1 million years of computer processing time >3.5 million have downloaded the screensaver >30 Teraflops rating (ASCI White = 12 Teraflops) Spinoff from [email protected] Spawned a cottage industry [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Spawned a real industry Entropia, United Devices, Popular Power... Major limitations: Only suitable for embarrasingly parallel problems

Cycle scavenging relies on goodwill 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 Comments on Grid Computing CSE 300 What is Applicability of Grid Computing to the Medical Domain and its Applications? Lets 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/session31.5/ISSGC06%20Experience%20with %20biomed%20applications%20v1.ppt All Links on Course Web Page MW+SOA-126 Final Comments CSE 300 Three Converging Technologies: Classic (CORBA) and Emerging (Jini, .NET) Middleware Web-Based Service Oriented Architectures and Computing Grid Computing Think back to Macro Architectures

Systems of Systems Old + New Centralized + Distributed Solving Huge Problems Facilitating Access (Services) How Does Cloud Computing Fit In? MW+SOA-127

Recently Viewed Presentations

  • Introduction to Chemistry

    Introduction to Chemistry

    They may have had a poor experience in high school chemistry and make you nervous about the class: or they may have had a fantastic experience and you are thrilled to be in my chemistry class. * Your experience of...
  • Anglo-Saxon &amp; Medieval Literature Background

    Anglo-Saxon & Medieval Literature Background

    Anglo-Saxon & Medieval Literature Background. Years: 449-1485. We are covering almost 1000 years here. A big span of rapidly changing times. I took about 8 pages of information for you an compressed it all down so that it was in...
  • Tutorial II General Information  Chemical equation in which

    Tutorial II General Information Chemical equation in which

    Different Reactions Exchange Reactions Precipitation Reactions Gas-Forming Reactions Acid-Base Reactions Exchange Reaction Metathesis or double displacement reactions Interchange of reactant cation/anion partners AB + XY AY + XB Precipitation Reactions Produce an insoluble precipitate from soluble reactants.
  • 合成化学の現状と将来性 - d2cax41o7ahm5l.cloudfront.net

    合成化学の現状と将来性 - d2cax41o7ahm5l.cloudfront.net

    Rafts contain proteins attached to the exoplasmic leaflet of the bilayer by their GPI anchors, proteins binding to the cytoplasmic leaflet by acyl tails (the Src-family kinase Yes is shown), or proteins associating through their transmembrane domains, like the influenza...
  • Courtroom Knowledge of Forensic Technology Workshop Forensic DNA

    Courtroom Knowledge of Forensic Technology Workshop Forensic DNA

    -Defense's Hypothesis = the mixture is a result of the victim's DNA profile and an unidentified random individual in the population. DNA Statistical Calculations - LR If the likelihood ratio is < 1, then the defense's hypothesis is supported. If...
  • MOTORCYCLE SAFETY Fort Sill FY 2005 Army Motorcycle

    MOTORCYCLE SAFETY Fort Sill FY 2005 Army Motorcycle

    MOTORCYCLE SAFETY Fort Sill FY 2005 Army Motorcycle Accident Statistics (FY 2005) The U.S. Army had 135 reported motorcycle accidents in FY 2005.
  • Text summarization Tutorial ACM SIGIR New Orleans, Louisiana

    Text summarization Tutorial ACM SIGIR New Orleans, Louisiana

    Text summarization Tutorial ACM SIGIR New Orleans, Louisiana September 9, 2001 Dragomir R. Radev School of Information, Department of Electrical Engineering and Computer Science, and Department of Linguistics
  • Historical Traditions

    Historical Traditions

    This explains the process going on behind the timeline Long-Term, Comprehensive Our Culture in characterized by rapid, radical, and recurrent change As a result, curricula (curriculums, if you prefer) are constantly changing in this day and age CRRV is a...