300
Middleware, CSE 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
[e-mail] http://www.engr.uconn.edu/~stev e (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 300
Distributed Computing/Applications are ... Systems of Systems Interoperation of New & Existing Applications Legacy, Databases, COTS, New Clients, etc. Network Centric Environment Distributed Computing Applications must ... Manage, Control, Access, and Modify Data Allow Humans to Interact with Data Provide High-Availability and Performance Evolvable Over Time Present & Future Army Systems Exhibit All of These Characteristics and More!
MW+SOA-2
What is a Distributed Application?
CSE 300
System of Systems Heterogeneity Hardware OS, PLs
Network Centric Environment High-Availability
Performance
Legacy Client Database COTS Server Legacy COTS DB Client Legacy Server
Java Client
Database
Dynamic Environment
Java Client
COTS Client
Increase Productivity New/Innovative Transparent Interoperation Information Use
MW+SOA-3
Another View Today's Reality
CSE 300
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 Legacy Java Client
COTS Legacy Client GOTS NETWORK
GOTS Client Legacy Database Database Client COTS Client
MW+SOA-4
Why is Distributed Computing Needed?
CSE 300
Today's Environments Contain Applications ... Created with Multiple Prog. Languages Executing on Heterogeneous Platforms Locally and Geographically Distributed Distributed Computing Applications Must ... Allow Seamless and Transparent Interoperation Provide Tools for Engineers and Users Result: Inter-Operating Environment Utilize Information in New/Innovative Ways Leveraged to Increase Productivity Support Diverse User Activities Dynamically Respond to Changes
MW+SOA-5
Striving for New Techniques/Technologies
CSE 300
We Must Diverge from Business as Usual C Programming with RPC Customized Development without Reuse Solutions that Aren't Extensible and Evolvable Cobbling Together Solutions w/o Method or Reason is Unacceptable and Doomed to Fail! We Must Face Today's Realities Legacy Code is Fact of Life New Technologies Offer New Challenges Adopt to Leverage Their Benefits We Must Draw Careful Balance to Opt for Mature Technologies While Targeting Emerging Technologies with Potential!
MW+SOA-6
Who are the Players?
CSE 300
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 300
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 300
Fundamental Realities of Distributed Systems
Co-located Communication Failures Concurrent Access Secure Fast Objects fail together Only with multiple threads Yes Distributed Slower Objects fail separately, Network can partition Yes Not Inherently Often Add-On Capability
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 services Service 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
SOA Actors
Service Registry Find Service Consumer Register Bind, Execute Service Provider
Service Provider
Provides
service
a stateless, location transparent business
Service Registry
Allows
service consumers to locate service providers that meet required criteria service providers to complete business processes
Service Consumer
Uses
SOA Benefits
Service Registry Find Service Consumer Register Bind, Execute Service Provider
Business Benefits Focus on Business Domain solutions Leverage Existing Infrastructure Agility Technical Benefits Loose Coupling Autonomous Service Location Transparency Late Binding
What is a Service Oriented Architecture?
CSE 300
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 300
Distributed Object Computing Platforms are Well Established in the Field - Historically DCE (Distributed Computing Environment) COM/OLE (Component Object Model/Object Linking and Embedding) Modern Middleware (JINI, CORBA, .NET): CORBA Standards Committee (OMG) Controls Technology Many Programming Languages JINI Sun-Based Product The Poor Mans CORBA Java .NET Microsoft's Forward into the Modern Market C#
MW+SOA-15
What Must All SOA Provide?
CSE 300
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 300
MW+SOA-17
Supplier /Consumer Model
CSE 300
SUPPLY Build New Wrap Existing Buy
CONSUME Assemble Applications
MANAGE Publish Subscribe Catalog Browse
MW+SOA-18
Objectives of SOA
CSE 300
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?
MW+SOA-19
Overview of Presentation
CSE 300
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
MW+SOA-20
What is CORBA?
CSE 300
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 300
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 300
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 300
CORBA Provides a Robust set of Services (COS) Services to Support Integration and Interoperation of Distributed Objects Services Defined on top of ORB as standard CORBA Objects with IDL interfaces Vendors Must Implement CORBA Services (COS)
Object Life Cycle Naming Events Relationships Externalization Transactions Trader Query Property
Factory
Naming Context
Event Channel
Object Request Broker
MW+SOA-24
What is CORBA?
CSE 300
Allow Interactions from Client to Server CORBA Installed on All Participating Machines
Client Application Server Application
Static Stub
DII
ORB Interface
ORB Interface
Skel eton
DSI Object Adapter
Client ORB Core
Network
Server ORB Core
IDL - Independent
Same for all applications
There may be multiple object adapters
MW+SOA-25
CORBA: Architectural Goals
CSE 300
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 300
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 300
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 300
The Request Consists of Target Object Operation (Method) Parameters Request Context (Optional)
Client Application
Object Call
Object Implementation
Methods and Data
IDL Boundary
Object reference
ORB
Request
IDL Boundary
Object dispatcher
MW+SOA-29
CORBA Components and Interfaces
CSE 300
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 Object Implementation
Dynamic Invoke
Client Stubs
ORB Interface ORB Core
Implementation Skeletons
Object Adapter
One interface One interface per object adaptor One interface per object operation
ORB internal interface
MW+SOA-30
Interfaces
CSE 300
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 Implementation Installation
Interface Repository
Client Stubs Includes
Implementation Skeletons Includes
Implementation Repository
Access
Describes
Client
Object Implementation
MW+SOA-31
CORBA: Repositories
CSE 300
Interface Repository
Implementation Repository
Client access to definitions Type checking for signatures Traversal of inheritance graphs
Location of implementation Activation information Administration control Security Resource allocation
Implementation Installation
IDL Interface Definitions
Interface Repository Access
Client Stubs
Implementation Skeletons
Implementation Repository Describes
Includes
Includes
Client
Object Implementation
MW+SOA-32
Client Side
CSE 300
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 300
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 Object Adapter
Implementation Repository
MW+SOA-34
CORBA
CSE 300
Basic Object Adapter (BOA) Provides Basic Services to Allow Variety Of CORBA Objects to be Created Ambiguous Portable Object Adapter (POA) Allow Developers yo Construct Object Implementations that are Portable Between ORBs Mediator Between ORB And Server
Server Applications Servants Client Incoming Request ORB POA
MW+SOA-35
CORBA: POA Policies
CSE 300
Provided to Programmer for Control Over an Object's Identity, State, Storage and Life-cycle 7 Different Policies Thread Policy Life-Span Policy Object ID Uniqueness Policy ID Assignment Policy Servant Retention Policy Request Processing Policy Implicit Activation Policy We Briefly Review each in Turn
MW+SOA-36
CORBA: POA Policies
CSE 300
Thread Policy - Depends on Number of Objects the Application Will Have Depends on Operating System Expected Load on System
ORB_CTRL_MODEL/SINGLE_THREAD_MODEL
Life Span Policy - Transient object cannot live beyond the process which created it Persistent object can live beyond the process which created it TRANSIENT / PERSISTENT Object ID Uniqueness Policy UNIQUE_ID / MULTIPLE_ID
MW+SOA-37
CORBA: POA Policies
CSE 300
ID Assignment Policy - To specify whether Object ID was generated by the application or ORB USER_ID / SYSTEM_ID Servant Retention Policy: States if POA retains active servants in object map RETAIN / NON_RETAIN Request Processing Policy: States how request processed by the POA USE_ACTIVE_OBJECT_MAP_ONLY / USE_DEFAULT_SERVANT / USE_SERVANT_MANAGER Implicit Activation Policy: Indicates if Implicit activation of servants is supported by POA IMPLICIT_ACTIVATION / NO_IMPLICIT_ACTIVATION
MW+SOA-38
Dynamic Invocation Interface (DII)
CSE 300
DII Allows Clients to Dynamically: Discover Objects Discover Objects' Interfaces Create Requests Invoke Requests (-> Methods) Receive Responses Major DII Features: Requests Appear as Objects Requests are Reusable Invocation May be Synchronous or Asynchronous Requests Can be Generated Dynamically, Statically or Using Both Approaches
MW+SOA-39
Request Components
CSE 300
Object Reference -- Identifies the Target Object Operation -- Identifies Which Operation to Invoke (Which Method Will Be Executed) Parameters -- Input, Output or Inout Method Arg-s Context Object -- the Context Within Which the Request Is to Be Performed Results -- the Result Value(s) Returned Environment -- the Exec-n Env-t and Exception Info. Request Handle -- the Id. For This Request Instance
MW+SOA-40
Repositories: Interface and Implementation
CSE 300
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-41
Three Types of ORBs
CSE 300
Client Object ORB and implementations implemented as libraries (routines) resident in the client.
Single Process Library Resident
ORB
Request
Client and Implementation Resident
Client
Object
ORB implemented as libraries (routines) resident in the clients and in the implementations.
ORB
Request
MW+SOA-42
Three Types of ORBs
CSE 300
Server or Operating System Based
Client
Object
ORB
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-43
Three Types of Implementations
CSE 300
Single Process "one shot" Object
Single Process Single method invocation Implementation is a single process that is activated upon the request delivery
Object Implementation
Multi-Threaded "resident" Object
Single Process Method C Method B Method A Implementation is a permanent or resident multi-threaded process
Object Implementation
MW+SOA-44
Three Types of Implementations
CSE 300
Multi-Process Object
Object Implementation Process 1 Process 2 Process 3 Method A Method B Method C
Implementation is a set of processes dedicated to a particular (group of) method(s) Processes can be distributed
MW+SOA-45
Interface Definition Language, IDL
CSE 300
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-46
IDL: Modules and Interfaces
CSE 300
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-47
IDL: Basic Types
CSE 300
Type short unsigned short long unsigned long float double char boolean octet any
Range -215 .. 215-1 (16-bit) 0 .. 216-1 (16-bit) -231 .. 231-1 (32-bit) 0 .. 216-1 (32-bit) IEEE single-precision floating point IEEE double-precision floating point 8-bit quantity TRUE or FALSE 8-bit (guaranteed during transmission) values that can express any IDL type
MW+SOA-48
IDL: Complex Types
CSE 300
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-49
IDL: Complex Types (cont.)
CSE 300
Sequences: One-dimensional array with maximum size (fixed at compile time) and length (set at run time). Unbounded Sequence: typdef sequence<long> longSeq; Bounded Sequence: sequence<long,10> fieldname; Strings: Declared using keyword string. May be bounded or unbounded. string name<32>; //bounded Arrays: Multidimensional, fixed-size arrays of any IDL data type.
MW+SOA-50
IDL Example: GUI
CSE 300
/* * File Name: */ #ifndef GUI_IDL #define GUI_IDL module GUI { struct timespec_t { long tv_sec; long tv_nsec; }; struct Dialog1Data_t { timespec_t DataTime; float val; }; struct Dialog2Data_t { timespec_t DataTime; long val; }; interface MainWindow { void logEvent(in timespec_t timestamp, in string val); };
MW+SOA-51
GUI.idl
interface Dialog1 { void update(in Dialog1Data_t val); }; interface Dialog2 { void update(in Dialog2Data_t val); }; }; #endif // GUI_IDL
IDL Example: Server
CSE 300
/* * File Name: */ Server.idl void registerDialog1( in GUI::Dialog1 val, in boolean flag) raises (OperationTimeout); void setDialog1Enabled( in boolean flag) raises (OperationTimeout); GUI::Dialog1Data_t getDialog1Data() raises (OperationTimeout, NotAvailable); void registerDialog2( in GUI::Dialog2 val, in boolean flag) raises (OperationTimeout); void setDialog2Enabled( in boolean flag) raises (OperationTimeout); GUI::Dialog2Data_t getDialog2Data() raises (OperationTimeout, NotAvailable); }; #endif // SERVER_IDL
#ifndef SERVER_IDL #define SERVER_IDL #include "GUI.idl" interface Server { enum reason_t { NotInitialized, ErrorDetected }; exception NotAvailable { reason_t reason; }; exception OperationTimeout {}; void registerMainWindow( in GUI::MainWindow val, in boolean flag) raises (OperationTimeout); void setMainWindowEnabled( in boolean flag) raises (OperationTimeout);
MW+SOA-52
What is JINI?
CSE 300
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-53
Sun's JINI Technology
CSE 300
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-54
Java Computing Architecture and JINI
CSE 300
MW+SOA-55
JINI Components and Dependencies
CSE 300
Infrastructure Base Java Java VM RMI Java Security
Programming Model Java APIs JavaBeans
Services JNDI Enterprise Beans JTS JMS Transaction Manager JavaSpaces Lookup service
Java + JINI
Discovery/Join Distributed Security Lookup
Leasing Transactions Events
MW+SOA-56
How Does JINI Work?
CSE 300
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-57
Discovery by Resource & Client
CSE 300
JINI Lookup Service
JINI Lookup Service
Discovery to Locate Services
Discovery to Register Services
Resource Client
Service Object Service Attributes
MW+SOA-58
Basic JINI Concepts
CSE 300
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-59
Basic JINI Concepts
CSE 300
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-60
JINI Resources & Services
CSE 300
JINI Lookup Service
Register Services
Printer Resource
Service Object Service Attributes
PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob cancelJob
Sun's Initial Perspective JINI for Hardware Class and Methods Printers, Digital Define Cameras, etc. Services Plug-and-Play on to be Network Registered PrinterActions Class Defines the "Component" that is Registered with JINI
MW+SOA-61
Objectives and Utility of JINI
CSE 300
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-62
How Does JINI Work?
CSE 300
Resources Discover and Join Lookup Service When Resources Leave or Fail to Renew Leases Lookup Service Must Adjust Registry Time Lag Between and Departure 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-63
JINI Concepts and Terms
CSE 300
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-64
Registration & Leasing
CSE 300
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 Printer Resource
Service Object Service Attributes
Class and PrinterActions Class enqueuePrintJob Methods dequeuePrintJob Define getPrinterStatus Services getPrinterType to be installPrinter Registered removePrinter startJob cancelJob
MW+SOA-65
Lease for 5 minutes (3000000 msec) Must Renew Before 5 Minutes Expire If Not Renewed, Lookup Removes If Failure, Lookup May Still Supply Service Until Expiration (5 mins) Client MUST be SMART!
JINI Support for Distributed Computing
CSE 300
Clients Using Services
Java Client Java Client Legacy Client Database Client COTS Client
JINI Lookup Service
Redundant Lookups
Database
Legacy
Resources Provide Services
COTS Legacy
COTS
Database JINI Lookup Service
Legacy
COTS
MW+SOA-66
Component Perspective and JINI
CSE 300
Resources as Components Resources Provide Services What Service Provides: Component Interface Clients, Servers, Resources, Use Component Interface to Design/Construct Functionality
Java Client JINI Lookup Service Legacy
COTS
Constructed via Services of Legacy, COTS, Database, etc. Lookup Registered Services Functionality via Service Reuse Services as Component APIs
Database
Legacy
COTS
MW+SOA-67
Two Example Resources
CSE 300
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)
MW+SOA-68
What Does an Actual System Look Like?
CSE 300
Java GUI UDB Client Java GUI MDB Client
UDBServer Service GetClasses(); PreReqCourse(); GetVacantClasses(); EnrollCourse(); AddCourse(); RemoveCourse();
JINI Lookup Service
MDBServer GetParts GetRequisition GetReqParts WriteParts WriteRequisition DeletePart DeleteRequisition AddParts RemovePart AddRequisition
University DB Resource (UDB) Military Requisition DB Resource
MW+SOA-69
Join, Lookup, and Service Invocation
CSE 300
Request Service AddCourse(CSE900)
Lookup Service
Registry of Entries
Service Object Service Attributes
Return Service Proxy to AddCourse( ) Client
J Register & Lease Services CourseDB Class o i Contains Method AddCourse ( ) n Resource
Service Object Service Attributes
Service Invocation via Proxy by Transparent RMI Call
1. Client Invokes AddCourse(CSE900) on Resource 2. Resource Returns Status of Invocation
MW+SOA-70
Services of Military Application
CSE 300
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-71
Execution Process of Client using JINI
CSE 300
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)
Security Registration Services
3 Client OK?
USR
Security Authorization Services
11 Return Result,CreateRequisition(...)
Lookup Service
7 IsClient_Registered(Token) 9 Check_Privileges(Token, MilitaryDb, Modification, CreateRequisition, [Tank Details, Harris])
MilitaryDB Resource
8 Return Result of IsClient_Registered(...) 10 Return Result of Check_Privileges(...)
Security Policy Services
MW+SOA-72
Services Console
CSE 300
MW+SOA-73
Services GUI
CSE 300
MW+SOA-74
What is .NET?
CSE 300
.NET is Microsoft's Solution to Enterprise Computing and Interoperability Aimed to Compete with Java/J2EE Interoperability: Old (CORBA, COM) & New (RMI) Provides Uniform Programming Environment via Extension of C - C#
MW+SOA-75
.NET Architecture and Usage
CSE 300
Three Level Architecture XML and DataSet as Objects of Interaction
Presentation Tier
Windows Forms
MyApp.Exe
DataSet
Business Tier
Web Forms
IE
Data Tier
Internet Intranet
Data Object (Class) DataSet
Data Adapter Data Adapter
DataSet
XML
Business to Business
(BizTalk, for example)
MW+SOA-76
What are .Net Components?
CSE 300
CTS (Common Type System) Defines Common Standard for Languages CLR (Common Language Runtime) Manages the Execution of a .Net Application Provides Cross Platform Support By Ensuring
Type Safety, Code Verification, Exception Handling Garbage Collection and Memory Management Note: Akin to Java Runtime Environment
ASP.NET This Component Provides a Layer of Classes for Web Services
MW+SOA-77
What are .Net Components?
CSE 300
Windows Forms Provides A Layer Of Classes For The Windows User Interface ADO.NET Provides Classes for Data Access Including Database and XML Base Class Library Low Level Classes Capture Core .Net Functionality Provides Infrastructure for Construction of Remaining .net Framework Classes
MW+SOA-78
Remoting in .Net
CSE 300
Remoting Makes an Object in One Process Available to an Application in Another Process (Akin to RMI) Marshalling Enables a Controlled Data Communication Between the 2 Processes Marshalling an Object Can Occur in 2 Ways Marshall By Value:
Server Creates a Copy of the Object and Passes the Copy to the Client
Marshall By Reference:
Server Creates a Reference of the Object and Sends this Reference to the Client
MW+SOA-79
Remoting in .NET
CSE 300
When a client calls an object marshalled by reference of the object in the client's application domain and the client uses that proxy to access that original object on the server
MW+SOA-80
Remoting in .NET
CSE 300
When a client calls an object marshaled by value the server creates and exact copy and sends that copy to the client. The client then uses the data of the object and executes the required functionality directly within the client's own process without making any additional calls to the server
MW+SOA-81
Recall Similarity to RMI in Java
CSE 300
Java Objects in JVMs (on Different Computers) Transparently Invoke Each Other's Methods RMI Enables Distributed Object Computing
Client
HelloApplet 5 Stub Unmarshall 1 Stub Marshall
Server
HelloImpl
Hello
rmic HelloImpl.java 2 Skel Unmarshall 3 Skel Marshall
NDR Transport
NDR Transport
RMI Layer
NDR
NDR Transport
Start rmiregistery Transport 4
MW+SOA-82
Web Services ASP.NET
CSE 300
Communication Based on Open Protocols Data via XML Schema via XSD Other Supported Protocols Inlcude: UDDI DISCO WSDL SOAP
MW+SOA-83
ADO.NET Architecture
CSE 300
MW+SOA-84
CORBA vs. JINI vs. .NET
CSE 300
Important to Differentiate Between Standard (CORBA) Vendors Implement Technologies (JINI, .NET) Many Different Pros and Cons w.r.t. Infrastructure, Usage, Environment, Interoperability, Ease of Use, Programming Requirements, etc. etc. etc. Many Different Perspectives to Compare Capabilities and Functionalities of Technologies What about Other Approaches? Terrific Presentation by D. Schmidt Combines Patterns and Middleware http://www.cs.wustl.edu/~schmidt/patternsframeworks-middleware.ppt
MW+SOA-85
Brief Comparison...
CSE 300
Database Connectivity Java uses JDBC and .Net uses Ado.net or ODBC.NET Cross platform interoperability J2EE and CORBA Easily Supports Interoperation .Net Focuses on Windows Platform Programming Languages .Net and CORBA Support Multiple Languages J2EE Focuses on Java (with Links to IDL) Cross Vendor Interoperability J2EE and CORBA Guaranteed by Specifications Microsoft is the only vendor for .Net Remoting: Strong Similarities Across All Three
MW+SOA-86
Web Service Oriented Architectures (WSOA)
CSE 300
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-87
WSOA in Practice
CSE 300
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-88
Web Services Architecture from W3C
CSE 300
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-89
Another WSOA Example
CSE 300
From: http://www.service-architecture.com/
MW+SOA-90
Another WSOA Example
CSE 300
From: http://www.service-architecture.com/
MW+SOA-91
Service Oriented Architecture Reference Model
An informal SOA Ontology
http://ontolog.cim3.net/file/resource/workshop/jul-2006/soa2006-07.ppt
Reference Model
An abstract framework for understanding significant relationships among the entities of some environment. Consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain. Is independent of specific standards, technologies, implementations, or other
Reference Model
Service Oriented Architecture
Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. Goal of this reference model is to define the essence of Service Oriented Architecture
Why Service Oriented Architecture?
Drivers:
Large scale Enterprise systems Internet scale provisioning of services Reduce the cost of doing business
Benefits
Build scalable, evolvable systems
Scalable because minimizes assumptions
Manage complex systems Encourage re-use of business function E
Why is it different?
SOA reflects the reality of ownership boundaries
CORBA, RMI, COM, DCOM, etc. all try to implement transparent distributed systems Ownership is of the essence in SOA
SOA is task oriented
Services are organized by function
Getting something done
SOA is inspired by human organizations
It worked for us, it should work for machines
What is not in the RM
Service composition
Choreography, orchestration Process Oriented Architecture
Organizational framework
Who is doing what to whom
Specific technologies
not even specific architectures
Key concepts
Service
A mechanism to enable access to one or more capabilities
using a prescribed interface consistent with constraints and policies as specified by the service description.
Visibility
Visibility is the relationship between service participants that is satisfied when they are able to interact with each other
Awareness
Service description Discovery
Willingness
Policy & contract
Reachability
Communication
Interaction
Interacting with a service involves performing actions against the service
The extent to which one system can effectively interpret information from another system is governed by the semantic engagement of the various systems. The semantic engagement of a system is a relationship between the system and information it may encounter.
Real World Effect
The purpose of using a capability is to realize one or more real world effects. At its core, an interaction is "an act" as opposed to "an object" and the result of an interaction is an effect (or a set/series of effects).
The real world effect is couched in terms of changes to the state shared by the participants and stakeholders in a service interaction
About Services
Conditions and Expectations
Policy
Constraint representing the intention of a participant in a service
Contract
Constraint representing an agreement between two or more participants.
Description
The service description represents the information needed in order to use, manage or provide a service.
Service reachability Service Functionality Service Policies Service Interface
Execution Context
The execution context is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities
Is a Reference Model an Ontology?
Establishing a vocabulary
A lot of definitions
The RM glossary has 28 entries
Formality was considered
Audience is not formal Mechanical processing of RM not expected
What about UML
UML obvious choice for an architecture spec But,
Inheritance (is-a) relationship almost never used Extraneous precision
E.g. we tried to define Service, not count the number of service providers
It's so ugly <duck/>
An early concept map
Concepts Maps
Concepts maps were excellent graphical indices to text
Concepts, and relationships. All we needed
On the cutting-room floor...
Where we are
Committee Specification published Reference Architecture effort started
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=soarm
Comments on WSOA
CSE 300
Wealth of Information on WSOA Available on-Line Let's Review Four Other Presentations Briefly http://download.microsoft.com/download/b/d/b/bd b24175-50bc-4e74-8df9835cef6521cb/ConnectedSystems.ppt http://www.cs.queensu.ca/home/cords/soa.ppt http://www.rgoarchitects.com/Files/SOA.ppt http://www.wsmo.org/TR/d17/resources/200605OASIS/SemanticServiceOrientedArchitectureTuto rial.ppt All Links on Course Web Page Last Presentation Transitions from SOA to Semantic Web
MW+SOA-114
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 Foste...