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 steve@engr. uconn. edu http: //www. engr. uconn. edu/~stev e (860) 486 - 4818 † Special Thanks to Prof. Alex Shvartsman, Keith Bessette, Scott Craig and Prior CSE 333 students for providing portions of this material. MW+SOA-1

What is a Distributed Application? m CSE 5810 m m Distributed Computing/Applications are … q Systems of Systems q Interoperation of New & Existing Applications q Legacy, Databases, COTS, New Clients, etc. q Network Centric Environment Distributed Computing Applications must … q Manage, Control, Access, and Modify Data q Allow Humans to Interact with Data q Provide High-Availability and Performance q 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 Database COTS Dynamic Environment High-Availability Performance Java Client Server Legacy Database COTS Java Client COTS Client Increase Productivity New/Innovative Transparent Interoperation Information Use MW+SOA-3

Another View – Today’s Reality m CSE 5810 m m m Premise: Artifacts - set of q DB, Legacy, COTS, GOTS, Each w/ API Premise: Users q New and Existing q Utilize Artifact APIs Distributed Application, DA q Artifacts + Users What are the Issues? q How Do they Interact? q Heterogeneity q Security Concerns q Different Programmatic Models q Etc. Database COTS Legacy Client Java Client GOTS NETWORK GOTS Client Legacy Database Client COTS Client MW+SOA-4

Why is Distributed Computing Needed? m CSE 5810 m m Today’s Environments Contain Applications … q Created with Multiple Prog. Languages q Executing on Heterogeneous Platforms q Locally and Geographically Distributed Computing Applications Must … q Allow Seamless and Transparent Interoperation q Provide Tools for Engineers and Users Result: Inter-Operating Environment q Utilize Information in New/Innovative Ways q Leveraged to Increase Productivity q Support Diverse User Activities q Dynamically Respond to Changes MW+SOA-5

Striving for New Techniques/Technologies m CSE 5810 m We Must Diverge from Business as Usual q C Programming with RPC q Customized Development without Reuse q Solutions that Aren’t Extensible and Evolvable q Cobbling Together Solutions w/o Method or Reason is Unacceptable and Doomed to Fail! We Must Face Today’s Realities q Legacy Code is Fact of Life q New Technologies Offer New Challenges q Adopt to Leverage Their Benefits q We Must Draw Careful Balance to Opt for Mature Technologies While Targeting Emerging Technologies with Potential! MW+SOA-6

Who are the Players? m CSE 5810 m m Stakeholders q Software Architects (Requirements) q System Designers (Solutions) q Application Builders (Implementation) Stakeholders Striving to Provide … q System Interaction and Information Exchange q Utilization of Existing Applications in New and Innovative Ways End-Users at Various Skill Levels and with Specific and Limited Access Requirements q Novice vs. Adept vs. Expert q Who Uses What When and for How Long? MW+SOA-7

Why a Distributed Application? m CSE 5810 m Reasons: q Data used is Distributed q Computation is Distributed q Application Users are Distributed 2 Key Issues for Solution: q Platform-Independent Models and Abstraction Techniques q Hide Low-Level Details q Provide a Well-Performing Solution q 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 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. cim 3. net/file/work/Emerging. Technology_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 n A “service” is the atomic unit of an Find Register SOA n Services encapsulate Service Bind, a business process Consumer Execute Provider n Service Providers Register themselves n Service use involves: Find, Bind, Execute n

Service Registry SOA Actors Find Service Consumer n Bind, Execute Service Provider ¨ Provides service n Register a stateless, location transparent business Service Registry ¨ Allows service consumers to locate service providers that meet required criteria n Service Consumer ¨ Uses service providers to complete business processes Service Provider

SOA Benefits Service Registry Find Service Consumer Business Benefits n Focus on Business Domain solutions n Leverage Existing Infrastructure n Agility Technical Benefits n Loose Coupling n Autonomous Service n Location Transparency n Late Binding Register Bind, Execute Service Provider

What is a Service Oriented Architecture? m CSE 5810 m m m 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) q Interactions with Services Transparent to Users (Integrated into Software) Interactions Between Entities Occur via a Message Exchange - Conceptual q Resources are Software Artifact Accessible via API Consisting of Services q Services are Logical Grouping of Methods (Functions) that are Available for Use q Services are Utilized When Messages are Invoked Against Them by Outside Users Both Web-Based and Middleware Settings MW+SOA-14

Middleware-Based SOA m CSE 5810 m Distributed Object Computing Platforms are Well Established in the Field - Historically q DCE (Distributed Computing Environment) q COM/OLE (Component Object Model/Object Linking and Embedding) Modern Middleware (JINI, CORBA, . NET): q CORBA –Standards Committee (OMG) Controls Technology – Many Programming Languages q JINI – Sun-Based Product – The Poor Mans CORBA – Java q. NET – Microsoft’s Forward into the Modern Market – C# (we will skip) MW+SOA-15

What Must All SOA Provide? m CSE 5810 Both Middleware & Web-Based SOAs Must Provide q 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 q Support Dynamic Discovery – Find Services Based on Attributes and Values q Location Transparency to Service Requestors q Found Service Sets up Binding Between Service Consumer and Service Provider q m 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 m CSE 5810 m m m m 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 m CSE 5810 m m Objective is to Explore CORBA, JINI, and. NET Various Aspects of Three Technologies q Overall Architecture q Interoperability Capabilities q Access and Usage Exploration of Web Service-Oriented Architectures q What are they? q How do they Work? q WSOAs + Middleware Transition to Grid Computing q What is the Grid? q What is its Purpose and Role q Grid + SOA + Middleware Where does Cloud Computing Fit? MW+SOA-20

What is CORBA? m CSE 5810 m m Common Object Request Broker Architecture to Allow: q Existing COTS, GOTS, Legacy, DB, etc. to Interact with One Another q Integrate These with New Clients/Servers/Etc. Consists of Following Major Components q Object Request Broker (ORB): Ø Arbitrate and Interact Ø Role of Lookup for Service Discovery q 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? m CSE 5810 m m 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? m CSE 5810 m Differs from Typical Programming Languages Objects can be … q Located Throughout Network q Interoperate with Objects on other Platforms q Written in Ant PLs for which there is mapping from IDL to that Language MW+SOA-23

What is CORBA? m CSE 5810 CORBA Provides a Robust set of Services (COS) q Services to Support Integration and Interoperation of Distributed Objects q Services Defined on top of ORB as standard CORBA Objects with IDL interfaces q Vendors Must Implement CORBA Services (COS) Object Life Cycle Naming Events Relationships Externalization Transactions Trader Query Property MW+SOA-24

What is CORBA? m CSE 5810 m Allow Interactions from Client to Server CORBA Installed on All Participating Machines MW+SOA-25

CORBA: Architectural Goals m CSE 5810 m m m 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) m CSE 5810 m m m ORB Provides the Underlying Infrastructure for Supporting Interoperating Software Systems (Applications) Composed of Distributed Objects q ORB Provides the Basic Request Delivery q 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 MW+SOA-27

Interface Definition Language, IDL m CSE 5810 m m m Key Component of CORBA Is the Interface Definition Language, IDL q Mapping is Available in C, C++, Java, Ada, Etc. q IDL Is Independent of Any Language/Compiler q Multiple Inheritance q Public Interface Oriented q 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: q A complete new language with C++ like Syntax q Programmers Must Prepare IDL Modules MW+SOA-28

ORB and High Level View of Requests m CSE 5810 The Request Consists of q Target Object q Operation (Method) q Parameters q Request Context (Optional) MW+SOA-29

CORBA Components and Interfaces CSE 5810 m m m 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 per object adaptor One interface per object operation ORB internal interface MW+SOA-30

Interfaces m CSE 5810 m m 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 m CSE 5810 Interface Repository q q q Client access to definitions Type checking for signatures Traversal of inheritance graphs m Implementation Repository q q q Location of implementation Activation information Administration control Security Resource allocation MW+SOA-32

Client Side m CSE 5810 m m 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: q Interface Repository (IR) q Context Management q 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 m CSE 5810 m m Implementations Receive Requests Thru Skeletons Object Adapter Adapts to Specifics of Object Implementation Schemes Basic Object Adapter (BOA) Provides: q Management of References q Method Invocation q Authentication q Implementation Registration q 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 m CSE 5810 m Interface Repository q Dynamic Client Access to Interface Definitions to Construct a Request q Dynamic Type Checking of Request Signatures q Traversal of Inheritance Graphs Implementation Repository q Location of Implementations and Methods q Activation Information q Administration Control q Resource Allocation q Security MW+SOA-35

Three Types of ORBs m Single Process Library Resident CSE 5810 Client ORB m Object ORB and implementations implemented as libraries (routines) resident in the client. Request Client and Implementation Resident Client ORB Object Request ORB implemented as libraries (routines) resident in the clients and in the implementations. MW+SOA-36

Three Types of ORBs m 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 m Single Process “one shot” Object Implementation Single Process Single method invocation m Implementation is a single process that is activated upon the request delivery Multi-Threaded “resident” 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 m Multi-Process 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 m CSE 5810 m m 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. q Operation declaration consists of a return type, an identifier, a parameter list, and an optional raises expression (exceptions). q 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 m CSE 5810 m Module: Used to scope IDL identifiers. q Mapped to C++ namespace with the same name. Mapped to a C++ class if the namespace construct is not supported. q Mapped to Java package with the same name. q 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. q Multiple inheritance supported q Interface body may contain the following kinds of declarations: constant, type, attribute, and operation. MW+SOA-41

IDL: Basic Types CSE 5810 MW+SOA-42

IDL: Complex Types m CSE 5810 m m Structures: q struct Fixed. Length. Struct { long field 1; // 32 -bit short field 2; // 16 -bit }; q struct Variable. Length. Struct { long field 1; // 32 -bit string field 2; }; Discriminated Unions: Cross between the C union and switch statements. Enumerations: Ordered list of identifiers. q enum quality_t { Poor, Fair, Good, Excellent}; MW+SOA-43

IDL: Complex Types (cont. ) m CSE 5810 m m Sequences: One-dimensional array with maximum size (fixed at compile time) and length (set at run time). q Unbounded Sequence: typdef sequence long. Seq; q Bounded Sequence: sequence fieldname; Strings: Declared using keyword string. May be bounded or unbounded. q 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 Dialog 1 { void update(in Dialog 1 Data_t val); }; GUI. idl #ifndef GUI_IDL #define GUI_IDL module GUI { struct timespec_t { long tv_sec; long tv_nsec; }; interface Dialog 2 { void update(in Dialog 2 Data_t val); }; }; #endif // GUI_IDL struct Dialog 1 Data_t { timespec_t Data. Time; float val; }; struct Dialog 2 Data_t { timespec_t Data. Time; long val; }; interface Main. Window { void log. Event(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 register. Dialog 1( in GUI: : Dialog 1 val, in boolean flag) raises (Operation. Timeout); void set. Dialog 1 Enabled( in boolean flag) raises (Operation. Timeout); GUI: : Dialog 1 Data_t get. Dialog 1 Data() raises (Operation. Timeout, Not. Available); enum reason_t { Not. Initialized, Error. Detected }; exception Not. Available { reason_t reason; }; void register. Dialog 2( in GUI: : Dialog 2 val, in boolean flag) raises (Operation. Timeout); void set. Dialog 2 Enabled( in boolean flag) raises (Operation. Timeout); GUI: : Dialog 2 Data_t get. Dialog 2 Data() raises (Operation. Timeout, Not. Available); exception Operation. Timeout {}; void register. Main. Window( in GUI: : Main. Window val, in boolean flag) raises (Operation. Timeout); void set. Main. Window. Enabled( in boolean flag) raises (Operation. Timeout); }; #endif // SERVER_IDL MW+SOA-46

A Comparison of Jini and CORBA Andrew See Liyuan Yu Zhongying Wang Michael Collins

What is CORBA? n n n 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) n A software component that mediates transfer of messages from a program to an object located on a remote host. n 0. Invocation ( with an Client ORB invocation 0 1 Network ORB n 1. Locate CORBA objects and marshal parameters CORBA Object 2 3 5 6 7 Server object reference) 4 execution n 2. Network Delay n 3. Unmarshal parameters n 4. Method Execution n 5. Result marshal n 6. Network Delay n 7. Result unmarshal

CORBA Objects and IDL n n n 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 stock. Market. idl module stock. Market{ interface Stock. Server { float get. Stock. Value (in string stock. Name); void set. Stock. Value (in string stock. Name, in long value); } …………. . } No Implementation details in IDL

Stub and Skeleton n “Glue” that connects language-independent IDL interface specifications to language –specific implementation Client Object Stub Client Stub ORB n Automatically generated by IDL compiler

Design of the Game Project with CORBA n Centralized Version:

Two Games: n Guess Game:

Two Games (Cont. ) n Hang. Man:

Design Details--IDL module Game. App{ interface Player { void display. Message(in string m); string get. Player. ID(); }; interface Guess. Player: Player { }; interface Hangman. Player: Player { void draw. Man(in long num. Wrong); }; interface Server { void add. Player(in Player p); void remove. Player(in string player. ID); void start. Game(in string player. ID); void Quit. Game(in string player. ID); void take. Turn(in string player. ID); }; interface Guess. Server: Server { void take. Turn(in long number, in string player. ID); }; interface Hangman. Server: Server { void take. Turn(in char w, in string word, in string player. ID); }; };

Design Details--UML

Design of the Game Project with CORBA n Decentralized Version play Player 1 return server info locate service return server info Naming Service Player 2 locate service register Service Return partner info Create playerlist Game Server Return partner info

Design Details-IDL module Game. App { interface Player { void receive. Message(in string m); string get. Player. ID(); void start. Game(in string data); void start. New. Game(in string data); void Quit. Game(); void response(string number, in string data); void take. Turn(); }; interface Server { string add. Player(in string p, in string nc. Ref); };

Design Details- UML Interface generated By IDL Compile Implement by programmer

What is JINI? m CSE 5810 m An Infrastructure for Network Centric Applications in Spontaneous Environment q Clients Enter/Leave Network Unpredictably q Resources and Services Enter/Leave due to Failure, Redundancy, Topology Change q Both Typify Present/Future Army Systems Goals of JINI q Plug-and-Play of Clients and Services q Erasing Hardware/Software Distinction: Everything is a Service q Enable Spontaneous Network Applications q Architecture where Services Define Function q Strive for Easy to Use/Understand Technology MW+SOA-61

Sun’s JINI Technology m CSE 5810 m m m JINI is a Sophisticated Java API Construct Distributed Applications Using JINI by q Federating Groups of Users q Resources Provide Services (Database Access, Printing, Real-Time Sensor) for Users JINI and Stakeholders q Core of Technologies to Architect, Design, Implement, and Test Distributed Applications q Construct Software “Resistant” to Failure JINI and Users q High Availability Through Redundancy q Dynamic Responses to User Requests Regardless of Network & Resource Changes MW+SOA-62

Current Status of JINI m CSE 5810 m m Now an Apache Project q https: //river. apache. org/about. html q https: //river. apache. org/doc/specs/html/jinispec. html 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 Infrastructure Base Java Programming Model Services Java VM Java APIs JNDI RMI Java. Beans Enterprise Beans Java Security JTS JMS Java + JINI Discovery/Join Leasing Distributed Security Lookup Transactions Transaction Manager Java. Spaces Events Lookup service MW+SOA-65

How Does JINI Work? m CSE 5810 m m m Distributed Application Constructed Using One or More Lookup Services Lookup Service Support Interactions by q Resources: “Advertise” Services Discover, Register Services, Renew Lease q Client: “Locate/Utilize” Services Discover, Search for Services, Invocation Multiple Lookup Services q Resources Responsible for Registering All q Clients Interact with Multiple Lookups q 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 m CSE 5810 m m 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 q Ask Lookup for Register. For. Course(CSE 900) q Return Proxy for Execution of Service q 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 m CSE 5810 m A Resource Provides a Set of Services for Use by Clients (Users) and Other Resources (Services) A Service is Similar to a Public Method q Exportable - Analogous to API q Any Entity Utilized by Person or Program q 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 q Clearinghouse for Resources to Register Services and Clients to Locate Services q m MW+SOA-69

JINI Resources & Services CSE 5810 JINI Lookup Service m m Register Services Printer Resource Service Object Service Attributes Sun’s Initial Perspective Class and q JINI for Hardware Methods q Printers, Digital Define Cameras, etc. Services q Plug-and-Play on to be Network Registered Printer. Actions Class Defines the “Component” that is Registered with JINI Printer. Actions Class enqueue. Print. Job dequeue. Print. Job get. Printer. Status get. Printer. Type install. Printer remove. Printer start. Job cancel. Job MW+SOA-70

Objectives and Utility of JINI m CSE 5810 m For Users, JINI Offers q Sharing of Resources (Services) over Network q Location Transparency of Users and Services q Both Critical for “Moving” Personnel For Stakeholders, JINI Provides q Infrastructure for Federating Services in Distributed Setting q Programming Model to Register & Discover Services q Availability of Services Throughout Distributed Setting Leading to Ease in Constructing, Maintaining, and Evolving Network Centric Applications MW+SOA-71

How Does JINI Work? m CSE 5810 m m Resources Discover and Join Lookup Service When Resources Leave or Fail to Renew Leases q Lookup Service Must Adjust Registry q Time Lag Between Departure and Removal of Services from Registry q What Happens When Client Receives Service Just Prior to Failure? q Utilization of Java Exception Handling q Client Code Written to Dynamically Adapt Resource Register q Services on Class-by-Class Basis q Service Object (Java API - Method Signatures) q Optional Descriptive Service Attributes MW+SOA-72

JINI Concepts and Terms m CSE 5810 m m Registration of Services via Leasing Mechanism q Resource Leases Services to Lookup Service q Resources Renew Services Prior to Expiration q If not, Services Become Unavailable q Lookup Service Maintains Registry q Limit Availability of Services Based on Time, Workload, User Requirements, etc. q Services as Available “Components” Leasing Supports High-Availability q Registration and Renewal Process q Upon Failure, Services Removed from Registry Clients, Resources, Lookup Can Occupy Same or Different Computing Nodes MW+SOA-73

Registration & Leasing m CSE 5810 m m 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 Printer. Actions Class enqueue. Print. Job dequeue. Print. Job get. Printer. Status get. Printer. Type install. Printer remove. Printer start. Job cancel. Job 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 Client COTS Database Client COTS Client Database JINI Lookup Service Legacy COTS MW+SOA-75

Component Perspective and JINI m CSE 5810 Resources as Components q Resources Provide Services q What Service Provides: Component Interface q 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 m CSE 5810 m m m University Application q Students can Register/Drop Courses and Check the Schedule/Catalog q Faculty can Alter Course DB and Check the Schedule/Catalog Military Application - Database of Parts q Ability to Requisition/Add/Delete Parts q Different User Authority Based on Rank For Both: q Client to JINI to Discover Services q 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 Get. Classes(); Pre. Req. Course(); Get. Vacant. Classes(); Enroll. Course(); Add. Course(); Remove. Course(); Java GUI MDB Client JINI Lookup Service MDBServer Get. Parts Get. Requisition Get. Req. Parts Write. Requisition Delete. Part Delete. Requisition Add. Parts Remove. Part Add. Requisition University DB Resource (UDB) Military Requisition DB Resource MW+SOA-78

Join, Lookup, and Service Invocation CSE 5810 Request Service Add. Course(CSE 900) Lookup Service Registry of Entries Return Service Proxy to Add. Course( ) Client Service Object Service Attributes J Register & Lease Services Course. DB Class o i Contains Method Add. Course ( ) n Service Invocation via Proxy by Transparent RMI Call Resource Service Object Service Attributes 1. Client Invokes Add. Course(CSE 900) on Resource 2. Resource Returns Status of Invocation MW+SOA-79

Services of Military Application m CSE 5810 m m Query Service: q Get. Parts: Queries DB for Parts q Get. Requisition: Queries DB for Requisition q Get. Req. Parts: All Requisition Details for a Particular Part Update Service: q Write. Parts: Store Part to DB q Write. Requisition: Requisition Changes to DB q Delete. Part: Deletes Part from DB q Delete. Requisition: 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(Military. Db, Modification, Create. Requisition) Returns Proxy to Military Client 6 Create. Requisition(Token, Tank Details, Harris) 11 Return Result, Create. Requisition(…) Lookup Service Security Registration Services 3 Client OK? USR Security Authorization Services 7 Is. Client_Registered(Token) 9 Check_Privileges(Token, Military. Db, Modification, Create. Requisition, [Tank Details, Harris]) Military. DB Resource 8 Return Result of Is. Client_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 n Networks are dynamic; so is Jini n Object interface; not network protocol n Service: A network-accessible device that provides a useful function n Client: Any user who requests services n

Runtime Architecture n Federation of services ¨ No n 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 n Services may grant varying access to clients ¨ Entire service is downloaded and run locally ¨ Service object is a proxy to remote server n Methods are remote calls to service, which actually does the work ¨ Both local and remote objects share work

Separation of Interface & Implementation n n 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 n Player ¨ One n player for all Games ¨ Separate communication from game specific rules ¨ Generalize common game tasks Add/remove a player n Take a turn n Update Player state n

Design – Games Interface Game. Proxy Interface Game Interface Remote. Game Basic. Game. Proxy Abstract. Game Turn. Based. Game Hangman. Proxy Blackjack. Proxy Guessing. Game Hangman Blackjack

Design – Players Interface Player. Impl (terminal based) Gui. Player (GUI based)

Terminal and GUI based clients have same functionality.

Implementation Lease Jini name service Register Game. Proxy Server Remote Game. Proxy Lookup Player add. Player, Take. Turn add. Player, Game. Proxy Take. Turn (local processing)

Implementation – Code samples n Creating the server-side object: Game impl = new Guessing. Game(); Remote. Game impl. Proxy = (Remote. Game)exporter. export(impl); n Creating the proxy: smart. Proxy = new Basic. Game. Proxy(impl. Proxy); n Registering the proxy: Service. Item item = new Service. Item(null, smart. Proxy, attrs); … reg = registrar. register(item, Lease. FOREVER);

Implementation – Code samples (cont. ) n Player taking a turn: Player: protected void take. Turn(String action){ game. take. Turn(action, id); } ¨ Game. Proxy – this version just forwards to remote implementation: public void take. Turn(String action, Object id) throws Remote. Exception { impl. take. Turn(action, id); } … player. set. Game. Data(data); ¨ n The rules for the game could be in the Remote. Game implementation, or the Game Proxy, or split between them.

Web Service Oriented Architectures (WSOA) m CSE 5810 m m An SOA is often Cast in a Web-Based Setting Possible Services include: q Data Transfer (e. g. FTP) or Storage Service q Troubleshooting Service Operations (Messages) are Encapsulated Behind a Message-Oriented Service Interface q Hides Details of Service Implementation/Location q Assumes an Architecture for Access q Provides a Logical View that is Message-Oriented q Available Service/Messages are Descriptively Supplied for Purpose of Discovery/Lookup q Network-Oriented q Scalable – Add New Services/Extend Existing Services for New/Improved Functionality MW+SOA-97

WSOA in Practice m CSE 5810 From Web Services Architecture, W 3 C 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 Webrelated standards. MW+SOA-98

Web Services Architecture from W 3 C m CSE 5810 m Complex Architecture with Many Different Capabilities and Features q Open Ended (Like Web) q 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 n Exploit Underutilized resources ¨ CPU Scavenging, Hotspot leveling Resource Balancing n Virtualize resources across an enterprise n ¨ n Data Grids, Compute Grids Enable collaboration for virtual organizations

Two Key Grid Computing Groups The Globus Alliance (www. globus. org) n Composed of people from: Argonne National Labs, University of Chicago, University of Southern California Information Sciences Institute, University of Edinburgh and others. n 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) n History ¨ n Heavy involvement of Academic Groups and Industry ¨ n 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 n n n n Avaki Axceleon Cap. Cal Centrata Data. Synapse Distributed Science Elepar Entropia. com Grid Frastructure Grid. Systems Groove Networks IBM Intel n n n Jivalti Mithral Mind Electric Mojo Nation News. To. You. com NICE, Italy Noemix, Inc. Oracle Parabon Platform Computing Popular Power Source: http: //www. gridcomputing. com/ n n n n n Powerllel Process. Tree Sharman Networks Kazza Sun Gridware Sysnet Solutions Tsunami Research Ubero United Devices Veritas Xcomp

Standards involved with SOA & Grid Computing SOA Standards n WSDL n UDDI n BPEL n WS-Profile n WS-Security n WS-Choreography And many others… Grid Standards n OGSI ¨ Extension to WSDL n WS-Resource ¨ WS-Resource. Lifetime ¨ WS- Resource. Properties ¨ WSRenewable. References ¨ WS-Service. Group ¨ WS-Base. Faults

Grid and Web Services Standards Grid GT 1 Started far apart in applications & technology Web GT 2 Have been converging OGS i -* , WS L WSD ML P X SOAP TT H 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. w 3. 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, Polder. Grid • Germany – UNICORE, Grid proposal • France – Grid funding approved • Italy – INFN Grid • Eire – Grid proposals • Switzerland - Network/Grid proposal • Hungary – Demo. Grid, Grid proposal • Norway, Sweden - Nordu. Grid • NASA Information Power Grid • DOE Science Grid • NSF National Virtual Observatory • NSF Gri. Phy. N • DOE Particle Physics Data Grid • NSF Tera. Grid • DOE ASCI Grid • Data. Grid (CERN, . . . ) • DOE Earth Systems Grid • Euro. Grid (Unicore) • DARPA Co. ABS Grid • Data. Tag (CERN, …) • NEESGrid • Astrophysical Virtual Observatory • DOH BIRN • GRIP (Globus/Unicore) • NSF i. VDGL • GRIA (Industrial applications) • Grid. Lab (Cactus Toolkit) • Cross. Grid (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 3 D 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 • 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

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)

Spinoff from SETI@home Spawned a cottage industry Xpulsar@home, Genome@home, Folding@home, evolutionary@home, Fight. AIDS@home, SARS@home. . . 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 m CSE 300 m m What is Applicability of Grid Computing to the Medical Domain and its Applications? Let’s Review Three Other Presentations Briefly q http: //www. aciagir. org/publis/poster. Agir. Paristic 2006. PPT q http: //bmi. osu. edu/resources/presentations/BISR_o verview_poster. ppt q http: //www. dma. unina. it/~murli/ISSGC 06/session 31. 5/ISSGC 06%20 Experience%20 with%20 biome d%20 applications%20 v 1. ppt All Links on Course Web Page MW+SOA-126

Final Comments m CSE 300 m m Three Converging Technologies: q Classic (CORBA) and Emerging (Jini, . NET) Middleware q Web-Based Service Oriented Architectures and Computing q Grid Computing Think back to “Macro Architectures” q Systems of Systems q Old + New q Centralized + Distributed q Solving “Huge” Problems q Facilitating Access (Services) How Does Cloud Computing Fit In? MW+SOA-127