Middleware, Service-Oriented
Architectures and Grid Computing
What is a Distributed Application?
• Distributed Computing/Applications are …
– Systems of Systems
– Interoperation of New & Existing Applications – Legacy, Databases, COTS, New Clients, etc.
– Network Centric Environment
• Distributed Computing Applications must …
– Manage, Control, Access, and Modify Data – Allow Humans to Interact with Data
– Provide High-Availability and Performance – Evolvable Over Time
• Present & Future Army Systems Exhibit All of These
Characteristics and More!
Java Client
Java Client Legacy
Client
DB Client
COTS Client
What is a Distributed Application?
Legacy
Database Server
Legacy
COTS Server
Database COTS
Network Centric Environment High-Availability Performance
Heterogeneity Hardware OS, PLs
Transparent Interoperation New/Innovative Information Use
Increase Productivity Dynamic
Environment
System of Systems
Another View – Today’s Reality
Legacy
Legacy
COTS
GOTS
Database Database
NETWORK Java
Client
GOTS Client Legacy
Client
Database
Client COTS
Client
• Premise: Artifacts - set of
– DB, Legacy, COTS, GOTS, Each w/ API
• Premise: Users
– New and Existing – Utilize Artifact APIs
• Distributed Application, DA
– Artifacts + Users
• What are the Issues?
– How Do they Interact?
– Heterogeneity – Security Concerns
– Different Programmatic Models
– Etc. Etc. Etc.
Why is Distributed Computing Needed?
• Today’s Environments Contain Applications …
– Created with Multiple Prog. Languages – Executing on Heterogeneous Platforms – Locally and Geographically Distributed
• Distributed Computing Applications Must …
– Allow Seamless and Transparent Interoperation – Provide Tools for Engineers and Users
• Result: Inter-Operating Environment
– Utilize Information in New/Innovative Ways – Leveraged to Increase Productivity
– Support Diverse User Activities – Dynamically Respond to Changes
Striving for New Techniques/Technologies
• We Must Diverge from Business as Usual
– C Programming with RPC
– Customized Development without Reuse
– Solutions that Aren’t Extensible and Evolvable
– Cobbling Together Solutions w/o Method or Reason is Unacceptable and Doomed to Fail!
• We Must Face Today’s Realities
– Legacy Code is Fact of Life
– New Technologies Offer New Challenges – Adopt to Leverage Their Benefits
– We Must Draw Careful Balance to Opt for Mature Technologies
While Targeting Emerging Technologies with Potential!
Who are the Players?
• Stakeholders
– Software Architects (Requirements) – System Designers (Solutions)
– Application Builders (Implementation)
• Stakeholders Striving to Provide …
– System Interaction and Information Exchange
– Utilization of Existing Applications in New and Innovative Ways
• End-Users at Various Skill Levels and with Specific and Limited Access Requirements
– Novice vs. Adept vs. Expert
– Who Uses What When and for How Long?
Why a Distributed Application?
• Reasons:
– Data used is Distributed
– Computation is Distributed – Application Users are
Distributed
• 2 Key Issues for Solution:
– Platform-Independent Models and Abstraction Techniques
– Hide Low-Level Details
– Provide a Well-Performing Solution
– Works Today and Tomorrow!
Shared Objects
• Easy to Re-use
• Easy to distribute
• Easy to maintain
Distributed Systems
Co-located Distributed
Communication
Fast Slower
Failures
Objects fail together Objects fail
separately, Network can partition
Concurrent Access
Only with multiple
threads Yes
Secure
Yes Not Inherently
Often Add-On Capability
Fundamental Realities of Distributed Systems
Service Oriented Architecture
& Grid Computing
What is Service Oriented Architecture (SOA)?
• An SOA application is a composition of services
• A “service” is the
atomic unit of an SOA
• Services encapsulate a business process
• Service Providers Register themselves
• Service use involves:
Find, Bind, Execute
Service Registry
Service Provider Service
Consumer
Find Register
Bind, Execute
SOA Actors
• Service Provider
– Provides a stateless, location transparent business service
• Service Registry
– Allows service consumers to locate service providers that meet required criteria
• Service Consumer
– Uses service providers to complete business processes
Service Registry
Service Provider Service
Consumer
Find Register Bind, Execute
SOA Benefits
Business Benefits
• Focus on Business Domain solutions
• Leverage Existing Infrastructure
• Agility
Technical Benefits
• Loose Coupling
• Autonomous Service
• Location Transparency
• Late Binding
Service Registry
Service Provider Service
Consumer
Find Register Bind, Execute
What is a Service Oriented Architecture?
• Solutions that Focus on Services that Need to be Available to Meet Need of Users (Entities)
• Users are Assumed to be Interacting via Client Applications (Browser or Standalone)
– Interactions with Services Transparent to Users (Integrated into Software)
• Interactions Between Entities Occur via a Message Exchange - Conceptual
– Resources are Software Artifact Accessible via API Consisting of Services – Services are Logical Grouping of Methods (Functions) that are Available for
Use
– Services are Utilized When Messages are Invoked Against Them by Outside Users
• Both Web-Based and Middleware Settings
Middleware-Based SOA
• Distributed Object Computing Platforms are Well Established in the Field - Historically
– DCE (Distributed Computing Environment)
– COM/OLE (Component Object Model/Object Linking and Embedding)
• Modern Middleware (JINI, CORBA, .NET):
– CORBA –Standards Committee (OMG) Controls Technology – Many Programming Languages
– JINI – Sun-Based Product – The Poor Mans CORBA – Java
– .NET – Microsoft’s Forward into the Modern Market – C#
What Must All SOA Provide?
• Both Middleware & Web-Based SOAs Must Provide
– Middle Layer Infrastructure that Provides Bridge Between Software Artifacts
• Clients and Resources in Middlware Setting
• Clients (Browsers) and Resources in Web Setting
– Allow Software Artifacts (Resources) to Register/Publish their APIs (Services and Methods) for use by Clients/Other Resources
• Lookup Service: Middleware for Artifacts (Resources and/or Clients and/or Other Resources) to Interact
– Support Dynamic Discovery – Find Services Based on Attributes and Values – Location Transparency to Service Requestors
– Found Service Sets up Binding Between Service Consumer and Service Provider
SOA Akin to CBD
Supplier /Consumer Model
SUPPLY Build New
Wrap Existing Buy
CONSUME Assemble Applications
MANAGE Publish Subscribe Catalog Browse
Objectives of SOA
• Can SOAs Support Highly-Available Distributed Applications?
• Can Replicated Services be Registered and Available for Use by Clients?
• Can SOAs Support a Network-Centric Environment with Dynamic Clients and Services?
• Will Clients Continue to Operate Effectively if a Replicated Service Fails?
• Can SOAs be Utilized to Maintain Data Consistency of Replicas?
• Are SOAs Easy to Learn and Use?
• What is Maturity Level of SOAs Technology?
• Objective is to Explore CORBA, JINI, and .NET
• Various Aspects of Three Technologies
– Overall Architecture
– Interoperability Capabilities – Access and Usage
• Exploration of Web Service-Oriented Architectures
– What are they?
– How do they Work?
– WSOAs + Middleware
• Transition to Grid Computing
– What is the Grid?
– What is its Purpose and Role – Grid + SOA + Middleware
What is CORBA?
• Common Object Request Broker Architecture
• Architecture to Allow:
– Existing COTS, GOTS, Legacy, DB, etc. to Interact with One Another – Integrate These with New Clients/Servers/Etc.
• Consists of Following Major Components
– Object Request Broker (ORB):
• Arbitrate and Interact
• Role of Lookup for Service Discovery
– Interface Definition Language (IDL):
• Common Definitional Format
• Means for Different “Software” written in Different Languages to Interact with One Another
What is CORBA?
• CORBA is a
Specification for Interoperability
• OMG (Object Management
Group) Supplies a Set of Flexible
Abstraction and Concrete Services
• Vendors Must Follow Standard
CORBA Language Mappings Ada
C and C++
COBOL Java to IDL
Lisp
CORBA Scripting Language
Smalltalk Others
Perl Haskell
Python
Eiffel
PHP/ORBit
What is CORBA?
• Differs from Typical Programming Languages
• Objects can be …
– Located Throughout Network
– Interoperate with Objects on other Platforms
– Written in Ant PLs for which there is mapping from IDL to that Language
Object Request Broker Application
Interfaces Domain Interfaces
Object Services
What is CORBA?
• CORBA Provides a Robust set of Services (COS)
– Services to Support Integration and Interoperation of Distributed Objects
– Services Defined on top of ORB as standard CORBA Objects with IDL interfaces
– Vendors Must Implement CORBA Services (COS)
Object Request Broker
Factory Naming
Context
Event Channel
Object Life Cycle
Naming Events
Relationships Externalization Transactions Trader
Query Property
What is CORBA?
• Allow Interactions from Client to Server CORBA
• Installed on All Participating Machines
Client Application Server Application
Client ORB Core Server ORB Core
Static
Stub DII ORB Skeleton DSI
Interface
ORB Interface
Object Adapter
Network
IDL - Independent Same for all applications
There may be multiple object adapters
CORBA: Architectural Goals
• Simplicity
• Consistency
• Scalability
• Usability for End Users
• Usability for Administrators
• Usability for Implementers
• Flexibility of Security Policy
• Independence of Security Technology
• Application Portability
• Interoperability
• Performance
• Object Orientation
Client Application
Object Implementation ORB
Role of an Object Request Broker (ORB)
• ORB Provides the Underlying Infrastructure for Supporting Interoperating Software Systems (Applications) Composed of Distributed Objects
– ORB Provides the Basic Request Delivery – ORB Provides Interface Definitions
• Location is Transparent to the Caller and Object Implementation
• Caller and the Object Implementation Can be in the Same Process thru Opposite Sides of the World
• ORB Manages Local Location and Optimization
Interface Definition Language, IDL
• Key Component of CORBA Is the Interface Definition Language, IDL
– Mapping is Available in C, C++, Java, Ada, Etc.
– IDL Is Independent of Any Language/Compiler – Multiple Inheritance
– Public Interface Oriented – Not for Implementation
• Primary Support for Interoperability Between Static and Dynamic Request Mechanisms
• Advantage: Modification of Client Code without Impacting of Server Code, and vice-versa
• Disadvantage:
– A complete new language with C++ like Syntax – Programmers Must Prepare IDL Modules
Client Application
Object
Implementation
ORB
Object reference Object dispatcher
IDL Boundary
Object Call
IDL Boundary
Methods and Data
Request
ORB and High Level View of Requests
• The Request Consists of
– Target Object
– Operation (Method) – Parameters
– Request Context (Optional)
Object Adapter ORB Core
One interface
One interface per object adaptor One interface per object operation
ORB internal interface Dynamic
Invoke
Client Stubs
ORB Interface
Client Object Implementation
Implementation Skeletons
CORBA Components and Interfaces • Client Stub: Client Invokes a Particular Object Op.
• Dynamic Invocation: Run-Time-Construction of Operation Invocations
• Implementation Skeleton: Interface Through Which a Method Receives a Request
• Object Adapter: Provides (De)activation, Object Creation/Reference Mgmt. for Implementations
• ORB Interface: Common ORB Operations
Client Stubs
Implementation Skeletons
Client Object Implementation
Interface Repository
Implementation Repository
Access Includes Includes Describes
IDL Interface Definitions
Implementation Installation
Interfaces
• Objects are Defined in IDL via Interfaces
• Object Definitions (Interfaces) are Manifested as Objects in the Interface Repository, as Client Stubs, and as
Implementation Skeletons
• Descriptions of Object Implementations are Maintained
as Objects in the Impl. Repository
CORBA: Repositories
• Interface Repository
– Client access to definitions
– Type checking for signatures
– Traversal of inheritance graphs
Implementation Repository
Location of
implementation
Activation information
Administration control
Security
Resource allocation
ORB Core
Object Adapter Object Implementation
Implementation Skeletons
Client
Dynamic Invoke
Client Stubs
ORB Interface Object
Repository
Client Side
• Clients Perform Requests Using Object References
• Clients Issue Requests through Object Interface Stubs (Static) or DII (Dynamic Invocation Inter.)
• Clients May Access General ORB Services:
– Interface Repository (IR)
– Context Management
– Request Management
ORB Core ORB Interface
Object Implementation
Object Adapter Implem.
Skeletons
Dynamic
Invoke Client
Stubs
Client Implementation
Repository
Object Implementation Side
• Implementations Receive Requests Thru Skeletons
• Object Adapter Adapts to Specifics of Object Implementation Schemes
• Basic Object Adapter (BOA) Provides:
– Management of References – Method Invocation
– Authentication
– Implementation Registration
– Activation / Deactivation
CORBA
• Basic Object Adapter (BOA)
– Provides Basic Services to Allow Variety Of CORBA Objects to be Created – Ambiguous
• Portable Object Adapter (POA)
– Allow Developers yo Construct Object
Implementations that are Portable Between ORBs
– Mediator Between ORB And Server
CORBA: POA Policies
• Provided to Programmer for Control Over an Object’s Identity, State, Storage and Life-cycle
• 7 Different Policies
– Thread Policy – Life-Span Policy
– Object ID Uniqueness Policy – ID Assignment Policy
– Servant Retention Policy – Request Processing Policy – Implicit Activation Policy
• We Briefly Review each in Turn
CORBA: POA Policies
• Thread Policy - Depends on Number of Objects the Application Will Have
– Depends on Operating System – Expected Load on System
– ORB_CTRL_MODEL/SINGLE_THREAD_MODEL
• Life Span Policy - Transient object cannot live beyond the process which created it
– Persistent object can live beyond the process which created it – TRANSIENT / PERSISTENT
• Object ID Uniqueness Policy
– UNIQUE_ID / MULTIPLE_ID
CORBA: POA Policies
• ID Assignment Policy - To specify whether Object ID was generated by the application or ORB
– USER_ID / SYSTEM_ID
• Servant Retention Policy: States if POA retains active servants in object map
– RETAIN / NON_RETAIN
• Request Processing Policy: States how request processed by the POA
– USE_ACTIVE_OBJECT_MAP_ONLY / USE_DEFAULT_SERVANT / USE_SERVANT_MANAGER
• Implicit Activation Policy: Indicates if Implicit activation of servants is supported by POA
– IMPLICIT_ACTIVATION / NO_IMPLICIT_ACTIVATION
Dynamic Invocation Interface (DII)
• DII Allows Clients to Dynamically:
– Discover Objects
– Discover Objects’ Interfaces – Create Requests
– Invoke Requests (-> Methods) – Receive Responses
• Major DII Features:
– Requests Appear as Objects – Requests are Reusable
– Invocation May be Synchronous or Asynchronous
– Requests Can be Generated Dynamically, Statically or Using
Both Approaches
Request Components
• Object Reference -- Identifies the Target Object
• Operation -- Identifies Which Operation to Invoke (Which Method Will Be Executed)
• Parameters -- Input, Output or Inout Method Arg-s
• Context Object -- the Context Within Which the Request Is to Be Performed
• Results -- the Result Value(s) Returned
• Environment -- the Exec-n Env-t and Exception Info.
• Request Handle -- the Id. For This Request Instance
Repositories: Interface and Implementation
• Interface Repository
– Dynamic Client Access to Interface Definitions to Construct a Request
– Dynamic Type Checking of Request Signatures – Traversal of Inheritance Graphs
• Implementation Repository
– Location of Implementations and Methods – Activation Information
– Administration Control
– Resource Allocation
– Security
Client Object
Request ORB
ORB and implementations implemented as libraries (routines) resident in the client.
Three Types of ORBs
• Single Process Library Resident
• Client and Implementation Resident
Client Object
Request ORB
ORB implemented as
libraries (routines) resident in the clients and in the implementations.
Client Object
Request ORB
ORB is implemented as a server (separate process) which brokers requests between client and
implementation processes.
ORB is part of the operating system.
Three Types of ORBs
• Server or Operating System Based
Implementation is a permanent or resident multi-threaded process
Implementation is a single process that is activated upon the request delivery Object Implementation
Single Process Single method invocation
Object Implementation Single Process
Method C Method B
Method A
Three Types of Implementations
• Single Process “one shot” Object
• Multi-Threaded “resident” Object
Implementation is a set of processes dedicated to a particular (group of) method(s)
Processes can be distributed Object Implementation
Process 1 Process 2 Process 3
Method A Method B Method C
Three Types of Implementations
• Multi-Process Object
Interface Definition Language, IDL
• Language used to describe the interfaces that client objects call and object implementations provide.
• Obeys the same lexical rules as C++, but introduces some new keywords.
• Supports standard C++ preprocessing features.
• Interfaces can have operations and attributes.
– Operation declaration consists of a return type, an identifier, a parameter list, and an optional raises expression (exceptions).
– Attribute declaration is logically equivalent to declaring a pair of accessor operations. May be declared as readonly.
• Interface specifications are placed in a source file having the
extension “.idl”
IDL: Modules and Interfaces
• Module: Used to scope IDL identifiers.
– Mapped to C++ namespace with the same name. Mapped to a C++ class if the namespace construct is not supported.
– Mapped to Java package with the same name.
– IDL declarations not enclosed in any module have global scope when mapped.
• Interface: Description of set of operations that a client may request of an object.
– Multiple inheritance supported
– Interface body may contain the following kinds of
declarations: constant, type, attribute, and operation.
IDL: Basic Types
Type Range
short -2
15.. 2
15-1 (16-bit) unsigned short 0 .. 2
16-1 (16-bit)
long -2
31.. 2
31-1 (32-bit)
unsigned long 0 .. 2
16-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
IDL: Complex Types
• Structures:
– struct FixedLengthStruct { long field1; // 32-bit short field2; // 16-bit };
– struct VariableLengthStruct { long field1; // 32-bit
string field2;
};
• Discriminated Unions: Cross between the C union and switch statements.
• Enumerations: Ordered list of identifiers.
– enum quality_t {
Poor, Fair, Good, Excellent};
IDL: Complex Types (cont.)
• Sequences: One-dimensional array with maximum size (fixed at compile time) and length (set at run time).
– Unbounded Sequence:
typdef sequence<long> longSeq;
– Bounded Sequence:
sequence<long,10> fieldname;
• Strings: Declared using keyword string. May be bounded or unbounded.
– string name<32>; //bounded
• Arrays: Multidimensional, fixed-size arrays of any IDL data
type.
IDL Example: GUI
/*
* File Name: GUI.idl */
#ifndef GUI_IDL
#define GUI_IDL module GUI {
struct timespec_t { long tv_sec;
long tv_nsec;
};
struct Dialog1Data_t { timespec_t DataTime;
float val;
};
struct Dialog2Data_t { timespec_t DataTime;
long val;
};
interface MainWindow {
void logEvent(in timespec_t timestamp, in string val);
};
interface Dialog1 {
void update(in Dialog1Data_t val);
};
interface Dialog2 {
void update(in Dialog2Data_t val);
};
};
#endif // GUI_IDL
IDL Example: Server
/*
* File Name: Server.idl */
#ifndef SERVER_IDL
#define SERVER_IDL
#include "GUI.idl"
interface Server { enum reason_t { NotInitialized, ErrorDetected };
exception NotAvailable { reason_t reason;
};
exception OperationTimeout {};
void registerMainWindow(
in GUI::MainWindow val, in boolean flag)
raises (OperationTimeout);
void setMainWindowEnabled(
in boolean flag)
raises (OperationTimeout);
void registerDialog1(
in GUI::Dialog1 val, in boolean flag)
raises (OperationTimeout);
void setDialog1Enabled(
in boolean flag)
raises (OperationTimeout);
GUI::Dialog1Data_t getDialog1Data() raises (OperationTimeout,
NotAvailable);
void registerDialog2(
in GUI::Dialog2 val, in boolean flag)
raises (OperationTimeout);
void setDialog2Enabled(
in boolean flag)
raises (OperationTimeout);
GUI::Dialog2Data_t getDialog2Data() raises (OperationTimeout,
NotAvailable);
};
#endif // SERVER_IDL
What is JINI?
• An Infrastructure for Network Centric Applications in Spontaneous Environment
– Clients Enter/Leave Network Unpredictably
– Resources and Services Enter/Leave due to Failure, Redundancy,
Topology Change– Both Typify Present/Future Army Systems
• Goals of JINI
– Plug-and-Play of Clients and Services
– Erasing Hardware/Software Distinction: Everything is a Service – Enable Spontaneous Network Applications
– Architecture where Services Define Function
– Strive for Easy to Use/Understand Technology
Sun’s JINI Technology
• JINI is a Sophisticated Java API
• Construct Distributed Applications Using JINI by
– Federating Groups of Users
– Resources Provide Services (Database Access, Printing, Real-Time Sensor) for Users
• JINI and Stakeholders
– Core of Technologies to Architect, Design, Implement, and Test Distributed Applications
– Construct Software “Resistant” to Failure
• JINI and Users
– High Availability Through Redundancy
– Dynamic Responses to User Requests Regardless of Network & Resource Changes
Java Computing Architecture and JINI
JINI Components and Dependencies
Infrastructure Programming Model
Services
Base Java
Java VM RMI
Java Security
Java APIs JavaBeans
JNDI
Enterprise Beans JTS
JMS Java +
JINI
Discovery/Join Leasing Transaction Manager Distributed
Security Transactions JavaSpaces
Lookup Events Lookup service
How Does JINI Work?
• Distributed Application Constructed Using One or More Lookup Services
• Lookup Service Support Interactions by
– Resources: “Advertise” Services
Discover, Register Services, Renew Lease – Client: “Locate/Utilize” Services
Discover, Search for Services, Invocation
• Multiple Lookup Services
– Resources Responsible for Registering All – Clients Interact with Multiple Lookups – Stakeholders Must Write “Apropos” Code
• Discovery Initiates Process for Client or Resource
Discovery by Resource & Client
Client
JINI Lookup
Service
Resource
Service Object Service Attributes
JINI Lookup
Service
Discovery to
Register Services Discovery to
Locate Services
Basic JINI Concepts
• JINI Lookup Service Maintains Registry for Available Services of Distributed Application
• Resources Provide Services that Register and Join with JINI Lookup Service
• Clients Discover and Utilize Services Based on Interface of Services
– Ask Lookup for RegisterForCourse(CSE900) – Return Proxy for Execution of Service
– Location of Service Transparent to Client
• Locations of Clients, Services, Lookup Service, etc., can Change over Time
• Conceptually, JINI Similar to Distributed OS with Dynamically
Definable/Changeable Resources
Basic JINI Concepts
• A Resource Provides a Set of Services for Use by Clients (Users) and Other Resources (Services)
• A Service is Similar to a Public Method
– Exportable - Analogous to API
– Any Entity Utilized by Person or Program – Samples Include:
• Computation, Persistent Store, Printer, Sensor
• Software Filter, Real-Time Data Source
• Anything that is Relevant for Your Domain!
– Services: Concrete Interfaces of Components
• Services Register with Lookup Service
– Clearinghouse for Resources to Register Services and Clients to Locate Services
JINI Resources & Services
JINI Lookup
Service
Printer Resource
Service Object Service Attributes
PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob
cancelJob
Class and Methods Define Services to be
Registered Register
Services
• Sun’s Initial Perspective – JINI for Hardware – Printers, Digital
Cameras, etc.
– Plug-and-Play on Network
• PrinterActions Class Defines
the “Component” that is
Registered with JINI
Objectives and Utility of JINI
• For Users, JINI Offers
– Sharing of Resources (Services) over Network – Location Transparency of Users and Services – Both Critical for “Moving” Personnel
• For Stakeholders, JINI Provides
– Infrastructure for Federating Services in Distributed Setting – Programming Model to Register & Discover Services
– Availability of Services Throughout Distributed Setting
Leading to Ease in Constructing, Maintaining, and
Evolving Network Centric Applications
How Does JINI Work?
• Resources Discover and Join Lookup Service
• When Resources Leave or Fail to Renew Leases
– Lookup Service Must Adjust Registry
– Time Lag Between Departure and Removal of Services from Registry
– What Happens When Client Receives Service Just Prior to Failure?– Utilization of Java Exception Handling
– Client Code Written to Dynamically Adapt
• Resource Register
– Services on Class-by-Class Basis
– Service Object (Java API - Method Signatures)
– Optional Descriptive Service Attributes
JINI Concepts and Terms
• Registration of Services via Leasing Mechanism
– Resource Leases Services to Lookup Service – Resources Renew Services Prior to Expiration – If not, Services Become Unavailable
– Lookup Service Maintains Registry
– Limit Availability of Services Based on Time, Workload, User Requirements, etc.
– Services as Available “Components”
• Leasing Supports High-Availability
– Registration and Renewal Process
– Upon Failure, Services Removed from Registry
• Clients, Resources, Lookup Can Occupy Same or
Different Computing Nodes
JINI Lookup
Service
Printer Resource
Service Object Service Attributes
Leasing/Lease Renewal
PrinterActions Class enqueuePrintJob dequeuePrintJob getPrinterStatus getPrinterType installPrinter removePrinter startJob
cancelJob Class and
Methods Define Services to be
Registered
Registration & Leasing
• FOREVER or EXPIRATION DATE (millisecs)
• Renewal Must Occur Prior to Expiration
• JINI Provides Lease Renewal Manager to Allow Resource to Delegate Renewal Responsibility
Lease for 5 minutes (3000000 msec) Must Renew Before 5 Minutes Expire If Not Renewed, Lookup Removes
If Failure, Lookup May Still Supply
Service Until Expiration (5 mins)
Client MUST be SMART!
JINI Support for Distributed Computing
Network
Legacy
Legacy COTS
COTS Database
Legacy COTS
Database
Resources Provide Services
Java Client
Java Client Legacy
Client Database
Client COTS
Client
Clients Using Services
JINI Lookup Service
JINI Lookup Service
Redundant Lookups
Component Perspective and JINI
• Resources as Components
– Resources Provide Services
– What Service Provides: Component Interface
– Clients, Servers, Resources, Use Component Interface to Design/Construct Functionality
Legacy
COTS
Legacy COTS
Database Java
Client
JINI Lookup
Service
Constructed via Services of
Legacy, COTS, Database, etc.
Lookup Registered Services Functionality via Service Reuse Services as Component APIs
Two Example Resources
• University Application
– Students can Register/Drop Courses and Check the Schedule/Catalog
– Faculty can Alter Course DB and Check the Schedule/Catalog
• Military Application - Database of Parts
– Ability to Requisition/Add/Delete Parts – Different User Authority Based on Rank
• For Both:
– Client to JINI to Discover Services
– Client to Resource for Method Invocation (Resembles RMI)
What Does an Actual System Look Like?
JINI Lookup
Service
Java GUI UDB Client
University DB Resource (UDB)
Java GUI MDB Client
UDBServer Service GetClasses();
PreReqCourse();
GetVacantClasses();
EnrollCourse();
AddCourse();
RemoveCourse();
MDBServer GetParts
GetRequisition GetReqParts WriteParts
WriteRequisition DeletePart
DeleteRequisitio n
AddParts RemovePart AddRequisition
Military Requisition
DB Resource
Join, Lookup, and Service Invocation
Client Resource
Service Object Service Attributes
Lookup Service Request
Service
AddCourse(CSE900)
Return Service Proxy to AddCourse( )
J o i n
Register & Lease Services CourseDB Class
Contains Method AddCourse ( )
1. Client Invokes AddCourse(CSE900) on Resource 2. Resource Returns Status of Invocation
Service Invocation via Proxy by Transparent RMI Call
Service Object Service Attributes
Registry of Entries
Services of Military Application
• Query Service:
– GetParts: Queries DB for Parts
– GetRequisition: Queries DB for Requisition
– GetReqParts: All Requisition Details for a Particular Part
• Update Service:
– WriteParts: Store Part to DB
– WriteRequisition: Requisition Changes to DB – DeletePart: Deletes Part from DB
– DeleteRequisition: Deletes Requisition from DB
• Other Services/Methods Omitted
• Notice: These are Just Public Methods Organized into Logical Groupings
• JINI Allows Searching of Groupings by Service
Execution Process of Client using JINI
Security Authorization
Services Security Registration
Services
Lookup Service
Military Client
1 Register_Client(Harris,Security Off., Military)
10 Return Result of Check_Privileges(…) 4 Return Result,Create_Token(Security Off., Token)
3 Client OK?
11 Return Result,CreateRequisition(…)
5. Discover/Lookup(MilitaryDb,Modification, CreateRequisition) Returns Proxy to Military Client
7 IsClient_Registered(Token)
9 Check_Privileges(Token, MilitaryDb, Modification, CreateRequisition, [Tank Details, Harris])
2 Verify_UR(Harris, Security Off.)
Security Policy Services MilitaryDB
Resource
8 Return Result of IsClient_Registered(…) 6 CreateRequisition(Token, Tank Details, Harris)
USR
Services Console
Services GUI
What is .NET?
• .NET is Microsoft’s Solution to Enterprise Computing and Interoperability
• Aimed to Compete with Java/J2EE
• Interoperability: Old (CORBA, COM) & New (RMI)
• Provides Uniform Programming Environment
via Extension of C - C#
.NET Architecture and Usage
• Three Level Architecture
• XML and DataSet as Objects of Interaction
Business Tier
Data Tier
Presentation Tier
Windows Forms
Web Forms
Business to Business
Data Object (Class) DataSet
DataSet
DataSet Internet
Intranet
Data Adapter Data Adapter
(BizTalk, for example)
XML MyApp.Exe
IE
What are .Net Components?
• CTS (Common Type System)
– Defines Common Standard for Languages
• CLR (Common Language Runtime)
– Manages the Execution of a .Net Application – Provides Cross Platform Support By Ensuring
• Type Safety, Code Verification, Exception Handling
• Garbage Collection and Memory Management
• Note: Akin to Java Runtime Environment
• ASP.NET
– This Component Provides a Layer of Classes for Web Services
What are .Net Components?
• Windows Forms
– Provides A Layer Of Classes For The Windows User Interface
• ADO.NET
– Provides Classes for Data Access Including Database and XML
• Base Class Library
– Low Level Classes Capture Core .Net Functionality
– Provides Infrastructure for Construction of Remaining
.net Framework Classes
Remoting in .Net
• Remoting Makes an Object in One Process Available to an Application in Another Process (Akin to RMI)
• Marshalling Enables a Controlled Data Communication Between the 2 Processes
• Marshalling an Object Can Occur in 2 Ways
– Marshall By Value:
• Server Creates a Copy of the Object and Passes the Copy to the Client
– Marshall By Reference:
• Server Creates a Reference of the Object and Sends this Reference to the Client
Remoting in .NET
When a client calls an object marshalled by reference of the object in the client’s application domain and the client uses that proxy to access that original object on
the server
Remoting in .NET
When a client calls an object marshaled by value the server creates and exact copy and sends that copy to the client.
The client then uses the data of the object and executes
the required functionality directly within the client’s own
process without making any additional calls to the server
Recall Similarity to RMI in Java
Start rmiregistery
Unmarshall Marshall Unmarshall Marshall
NDR NDR NDR NDR
Stub Stub Skel Skel
Transport Transport Transport Transport
HelloApplet HelloImpl
Hello
1 2 3
4 5
Server Client
RMI Layer
rmic HelloImpl.java
Java Objects in JVMs (on Different Computers) Transparently Invoke Each Other's Methods
RMI Enables Distributed Object Computing
Web Services ASP.NET
• Communication Based on Open Protocols
– Data via XML – Schema via XSD
• Other Supported Protocols Inlcude:
– UDDI
– DISCO
– WSDL
– SOAP
ADO.NET Architecture
CORBA vs. JINI vs. .NET
• Important to Differentiate Between
– Standard (CORBA) – Vendors Implement – Technologies (JINI, .NET)
• Many Different Pros and Cons w.r.t. Infrastructure, Usage, Environment, Interoperability, Ease of Use, Programming Requirements, etc. etc. etc.
• Many Different Perspectives to Compare Capabilities and Functionalities of Technologies
• What about Other Approaches?
– Terrific Presentation by D. Schmidt – Combines Patterns and Middleware
– http://www.cs.wustl.edu/~schmidt/patterns-frameworks-middleware.ppt
Brief Comparison…
• Database Connectivity
– Java uses JDBC and .Net uses Ado.net or ODBC.NET
• Cross platform interoperability
– J2EE and CORBA Easily Supports Interoperation .Net Focuses on Windows Platform
• Programming Languages
– .Net and CORBA Support Multiple Languages J2EE Focuses on Java (with Links to IDL)
• Cross Vendor Interoperability
– J2EE and CORBA Guaranteed by Specifications Microsoft is the only vendor for .Net
• Remoting: Strong Similarities Across All Three
Web Service Oriented Architectures (WSOA)
• An SOA is often Cast in a Web-Based Setting
• Possible Services include:
– Data Transfer (e.g. FTP) or Storage Service – Troubleshooting Service
• Service Operations (Messages) are Encapsulated Behind a Message- Oriented Service Interface
– Hides Details of Service Implementation/Location – Assumes an Architecture for Access
– Provides a Logical View that is Message-Oriented
– Available Service/Messages are Descriptively Supplied for Purpose of Discovery/Lookup
– Network-Oriented
– Scalable – Add New Services/Extend Existing Services for New/Improved Functionality
WSOA in Practice
• From Web Services Architecture, W3C
A Web service is a software system designed to support interoperable machine-to-machine
interaction over a network. It has an interface described in a machine processable format
(specifically WSDL). Other systems interact with the Web service in a manner prescribed by its
description using SOAP messages, typically
conveyed using HTTP with an XML serialization in
conjunction with other Web-related standards.
Web Services Architecture from W3C
• Complex
Architecture with Many Different Capabilities and Features
– Open Ended (Like Web)
– Target Multiple Domains/Usages
• Current Web and
Future (Emerging?)
Semantic Web
Another WSOA Example
From: http://www.service-architecture.com/
Another WSOA Example
From: http://www.service-architecture.com/
Service Oriented Architecture Reference Model
An informal SOA Ontology
Reference Model
• An abstract framework for understanding
significant relationships among the entities of some environment.
• Consists of a minimal set of unifying concepts, axioms and relationships within a particular problem domain.
• Is independent of specific standards,
technologies, implementations, or other
concrete details.
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
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
• Awareness
• Service description
• Discovery
• Willingness
• Policy & contract
• Reachability
• Communication
Visibility is the relationship between service participants that is satisfied when they are able to interact with each other
Interaction
Interacting with a service involves performing actions against the service
The extent to which one system can effectively interpret information from another system is governed by the semantic engagement of the various systems.
The semantic engagement of a
system is a relationship between the system and information it may
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.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
