Making the Grid Pay
Economic Services - Pricing and Payment
William Lee
London e-Science Centre
Imperial College London
Introduction
ƒ In the Grid, we want to
“Decouple hosting and software
provision to enable shared and flexible
access to resource across multiple
administrative domains”
London e-Science Centre
Imperial College London
From Sharing to Trading
ƒ Accessing shared grid resources without any
pre-existing trust relationship.
ƒ Why should I trust that service?
ƒ Why should the service trust you?
ƒ How services differentiate themselves?
London e-Science Centre
Imperial College London
Four Fundamental Steps in a Trade
ƒ Introduction
ƒ Discovery / Semantic Grid
ƒ Price Agreement
ƒ Negotiation as a process to agree a price
ƒ Settling a Contract
ƒ Ends negotiation process with a monetary
commitment
ƒ Executing a Trade
ƒ Service Invocation
ƒ Usage Logging
ƒ Monetary Transaction
London e-Science Centre
Imperial College London
Negotiate and pay for
access to a single service
Application Service
Provider
Software
Provider
Hosting
Provider
Payment
Provider
PaymentPortType
Check Payment
AppSpecificPortType
NegotiationPortType
Invoke Service
Negotiate
Price and QoS
Authorise Payment
Client
London e-Science Centre
Imperial College London
NegotiationPortType Activity Diagram
Client
NegotiationPortType AppSpecificPortType
Price:(Integer, 10,2000)
Param1:(Float, 1, 100)
Param2:(Set, {a, b, c})
getNegotiableTerms()
Param1 > 20 and
Param1 < 40 and
Param2 = {a}
negotiate(Proposal)
Param1 = 30 and
Param2 = {a}
Price = 400
Once all terms have
been instantiated and
client satisfies
Signed document
containing agreed terms
Send Agreement in
SOAP header as ticket
NegotiableTerms
Proposal
Reasoning on internal
constraints and
objectives
…
negotiate(Proposal)
Commit on the last
proposed terms in the
session
Proposal
commit()
Agreement
Sessional Activities
serviceOp()
London e-Science Centre
Imperial College London
Making Service Negotiable
ƒ Decorator Pattern
negotiate()
serviceOp()
commit()
NegotiationPortType
AppSpecificPortType
Assert agreed
usage
London e-Science Centre
Imperial College London
Current Design
ƒ Proposals are defined as constraints on
terms.
ƒ Commit operation can carry payment
information to specify client’s monetary
commitment.
ƒ Session information is carried by a unique id
element in the proposal document. Might
consider other Web Service standards for
session.
London e-Science Centre
Imperial College London
Payment Service Requirements
ƒ Abstraction, Abstraction, Abstraction
ƒ Realisation with multiple Payment Systems
ƒ Identity Delegation
ƒ Commodity Security
ƒ Extensive use of WS-Security, XMLSignature
ƒ Resists Replay Attack
London e-Science Centre
Imperial College London
PaymentPortType Activity Diagram
PaymentInfo
S: Client
Client
ChargeableService
PaymentPortType
commit(PaymentInfo)
authoriseTransaction(PaymentInfo)
PaymentInfo
S: Client, Service
Acknowledgement
Agreement
Terms, ID# , PaymentInfo
S: PaymentProvider, Service
ID# , PaymentInfo
S: PaymentProvider
serviceOp()
Agreement carried in SOAP
header
S: PaymentProvider, Service,
Client
completeTransaction(PaymentInfo)
ID#
S: Client, Service
London e-Science Centre
Imperial College London
PaymentPortType
ƒ getPaymentSystem
ƒ
ƒ
ƒ
Input: None
Output: informational document on supported payment system
Faults: None
ƒ authoriseTransaction
ƒ
ƒ
ƒ
Input: Account Information, Amount, max transactions, expiry
Output: signed acknowledgement of transaction ID#
Faults: FromAccountDoesNotExist, ToAccountDoesNotExist, SignatureFailed,
InsufficientFund
ƒ completeTransaction
ƒ
ƒ
ƒ
Input: signed transaction ID#
Output: none
Faults: SignatureFailed, InsufficientFund, TransactionAlreadyComplete,
TransactionDoesNotExist, TransactionHasExpired, etc..
London e-Science Centre
Imperial College London
Foiled Attacks
ƒ Charging without Permission
ƒ Service invocation requires client signed
authorisation, which the PaymentProvider
recognises
ƒ Replay
ƒ Once and only once. Invocation includes
transaction ID# + signed timestamp. Service
detects replay by keeping a cached list of recent
messages.
ƒ PaymentProvider knows maximum number of
transactions, allows micro-payment.
London e-Science Centre
Imperial College London
Current Implementation
WS-Security JAX-RPC Handler
NegotiationPortType
Reasoning
Engine / Human
Operator
RDBMS
AppSpecificPortType
NegotiationStrategy
Instrumented
NegotiationSessionStore
Service Logic to
Term Assertion ensure terms are
API
not violated
AgreementStore
London e-Science Centre
Imperial College London
Current Implementation
WS-Security JAX-RPC Handler
PaymentPortType
AccountPortType
BACS, VISA, etc..
PaymentPortTypeImpl
London e-Science Centre
Imperial College London
AccountEJB
How ‘standard’ is the service?
ƒ Interface Design
ƒ WSDL to describe interface - WS-I (1)
ƒ SOAP for messaging (1)
ƒ WS-Security to sign message body with
client/service certificate (2)
ƒ XML-Signature and XML-Encryption to
sign and encrypt payment information (1)
Risk: Low
London e-Science Centre
Imperial College London
Service Dependencies
ƒ Implementation
ƒ Java J2EE 1.4 Specification
ƒ Currently using Sun Application Server
v.8.0. Follow standard J2EE API and
deployment model to achieve high
portability across compliant containers.
ƒ Take advantage of persistence and
security role mapping.
ƒ RDBMS: storing agreement
ƒ Verisign TSIK toolkit: WS-Security
London e-Science Centre
Imperial College London
AAA & Security
ƒ What authentication mechanism do you use?
ƒ WS-Security X509 Certificate Profile
ƒ What authorisation mechanism do you use?
ƒ J2EE Role-based System
ƒ What accounting mechanism do you use?
ƒ Java Logging
ƒ Does service interaction need to be encrypted?
ƒ Yes
London e-Science Centre
Imperial College London
The Shape of Things to Come
ƒ Evaluation of monetary Payment Systems
ƒ Complex pricing strategy
ƒ Tradable contracts
ƒ Composition of Chargeable Services
ƒ Workflow Optimisation
ƒ Compensation if the service does not deliver?
ƒ Brokering - e-Science North West
ƒ True decoupling of software and hosting
London e-Science Centre
Imperial College London
Conclusion
ƒ Economic Services enable a public shared
resource grid. Not just a scheduling
mechanism.
ƒ Discovery and Introduction can reuse existing
WS standards.
ƒ Settlement and Execution requires session
feature. Can use any off-the-shelf
specifications once available.
London e-Science Centre
Imperial College London
A Market for Computational Services
ƒ UK core e-Science Programme project
ƒ Explore interface and protocols for trading grid
services
ƒ Funded by the Department of Trade and Industry
ƒ Collaborators
ƒ London e-Science Centre
ƒ e-Science Centre North West
ƒ Southampton e-Science Centre
ƒ UK Grid Support Centre
ƒ Astrophysics at LJM
ƒ http://www.lesc.ic.ac.uk/markets
London e-Science Centre
Imperial College London