1. London e-Science Centre Imperial College London Making the Grid Pay Economic Services - Pricing and Payment William Lee

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

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

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

5. London e-Science Centre Imperial College London Application Service Provider Software Provider Payment Provider Hosting Provider Client Negotiate and pay for access to a single service Negotiate Price and QoS Invoke Service NegotiationPortTypeAppSpecificPortType PaymentPortType Authorise Payment Check Payment

6. London e-Science Centre Imperial College London Sessional Activities NegotiationPortType Activity Diagram ClientNegotiationPortType getNegotiableTerms() NegotiableTerms Price:(Integer, 10,2000) Param1:(Float, 1, 100) Param2:(Set, {a, b, c}) negotiate(Proposal) Param1 > 20 and Param1 < 40 and Param2 = {a} Param1 = 30 and Param2 = {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

7. London e-Science Centre Imperial College London Making Service Negotiable  Decorator Pattern AppSpecificPortTypeNegotiationPortType serviceOp() Assert agreed usage negotiate() commit()

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

9. 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, XML- Signature  Resists Replay Attack

10. London e-Science Centre Imperial College London PaymentPortType Activity Diagram ClientChargeableServicePaymentPortType commit(PaymentInfo) PaymentInfo S: Client authoriseTransaction(PaymentInfo) PaymentInfo S: Client, Service Acknowledgement ID#, PaymentInfo S: PaymentProvider Agreement Terms, ID#, PaymentInfo S: PaymentProvider, Service serviceOp() Agreement carried in SOAP header S: PaymentProvider, Service, Client completeTransaction(PaymentInfo) ID# S: Client, Service

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

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

13. London e-Science Centre Imperial College London Current Implementation AppSpecificPortTypeNegotiationPortType WS-Security JAX-RPC Handler Instrumented Service Logic to ensure terms are not violated NegotiationSessionStore AgreementStore RDBMS NegotiationStrategy Reasoning Engine / Human Operator Term Assertion API

14. London e-Science Centre Imperial College London Current Implementation AccountPortTypePaymentPortType WS-Security JAX-RPC Handler PaymentPortTypeImpl BACS, VISA, etc.. AccountEJB

15. London e-Science Centre Imperial College London 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

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

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

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

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

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