london e-science centre imperial college london making the grid pay economic services - pricing and...

London e-Science Centre

Imperial College London

Making the Grid Pay Economic Services - Pricing and Payment

William Lee

London e-Science CentreImperial 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”


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?


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


Application ServiceProvider

SoftwareProvider

PaymentProvider

HostingProvider

Client

Negotiate and pay for access to a single service

Negotiate Price and QoS

Invoke Service

NegotiationPortTypeAppSpecificPortType

PaymentPortType

Authorise Payment

Check Payment


Sessional Activities

NegotiationPortType Activity DiagramClient NegotiationPortType

getNegotiableTerms()

NegotiableTerms

Price:(Integer, 10,2000)Param1:(Float, 1, 100)Param2:(Set, {a, b, c})

negotiate(Proposal)Param1 > 20 and Param1 < 40 andParam2 = {a}

Param1 = 30 andParam2 = {a}Price = 400

Proposal

Reasoning on internal constraints and objectives

commit()

Once all terms have been instantiated and client satisfies

Agreement

Commit on the last proposed terms in the session

Signed document containing agreed terms

negotiate(Proposal)

Proposal

…

AppSpecificPortType

serviceOp()Send Agreement in SOAP header as ticket


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.


Payment Service Requirements

Abstraction, Abstraction, Abstraction Realisation with multiple Payment Systems

Identity Delegation Commodity Security

Extensive use of WS-Security, XML-Signature

Resists Replay Attack


PaymentPortType Activity DiagramClient ChargeableService PaymentPortType

commit(PaymentInfo)

PaymentInfoS: Client

authoriseTransaction(PaymentInfo)

PaymentInfoS: Client, Service

Acknowledgement

ID# , PaymentInfoS: PaymentProvider

Agreement

Terms, ID# , PaymentInfoS: PaymentProvider, Service

serviceOp()

Agreement carried in SOAP headerS: PaymentProvider, Service, Client

completeTransaction(PaymentInfo)

ID#S: Client, Service


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..


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.


Current Implementation

AppSpecificPortTypeNegotiationPortType

WS-Security JAX-RPC Handler

Instrumented Service Logic to ensure terms are not violated

NegotiationSessionStore

AgreementStoreRDBMS

NegotiationStrategyReasoning Engine / HumanOperator

Term Assertion API


Current Implementation

AccountPortTypePaymentPortType

WS-Security JAX-RPC Handler

PaymentPortTypeImplBACS, VISA, etc..

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


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


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


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


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 making the grid pay economic services - pricing and...

Documents