Payment and Negotiation for the Next Generation
Grid and Web
Jeremy Cohen, John Darlington, William Lee
London e-Science Centre, Imperial College London, South Kensington Campus, London SW7 2AZ, UK
Email: lesc-staff@doc.ic.ac.uk
Abstract. We present a proposal for a next-generation Internet based on chargeable Web
Services and Utility Computing realised by a series of open but interacting markets. We
demonstrate through the UK e-Science project “A Market for Computational Services” the
development of some of the fundamental building blocks to enable such a computational
marketplace for the Grid. This paper describes the motivation behind this restructuring
of the Internet and Web-based activities as a series of markets and how Grid Computing
technologies can contribute towards this goal. The paper details the work undertaken at
the London e-Science Centre to build a framework to create and support negotiable and
chargeable Web Services.
1
Introduction
Computational Grids consist of large numbers of
resources that may be distributed over a wide
area and owned by many organisations. Given
that these resources – including computational
and storage resources as well as instruments –
may be highly expensive to own and operate,
it is an unsustainable vision that organisations
will share their resources altruistically or simply allow trusted parties to utilise their excess
capacities when utilisation is low. There is a
clear need to charge and account for service access and the supporting mechanisms to transfer
funds between entities.
The UK e-Science/DTI funded project “A
Market for Computational Services” [9] set out
to investigate and develop mechanisms to support markets in computational Grids. This included research on negotiation and brokering of
Grid services along with the development of accounting and payment mechanisms for services.
These aspects would be demonstrated through
a set of e-Science exemplars. In this paper we
present the services produced at the London eScience Centre, in co-operation with a Glasgowbased IT consultancy firm, Real Time Engineering Ltd, to develop a negotiation and payment
framework for Web Services.
Grid computing is a potentially revolutionary technology in that it could make high-end
resources accessible to a much wider community.
However its development and deployment will
be hampered unless a proper economic model,
addressing the supply and use of such services
can be developed.
The adoption, by the e-Science community of
standard Web Services, for both its middleware
and application framework, had radical implications for the Markets for Computational Services project. It changed the emphasis of the
project from providing accounting and charging
mechanisms for Grid Services in an academic
context to exploring the creation of a new public market in chargeable Web Services and utility computing. In this arena, chargeable Web
Services would form the basis for the Next Generation Internet [5].
The application and adoption of e-Science
and Grid computing technologies on the public
web would provide new opportunities, whereby
the creativity and inventiveness that has been
demonstrated on the current Web could be applied to the creation and making of even more
complex and useful computational services.
Section 2 sets out the case for a market
in Web-based services. We examine the stakeholders and conditions for the development of
such a market. Section 3 details the negotiation
framework that has been developed. Following
negotiation, consumers need to pay for their services. The architecture and API of the payment
service are introduced in Section 4 with the Web
interface and user-view of the service being detailed in Section 5.
2
A Market in Services
As computational Grids are being developed,
the Grid community has been moving increasingly towards standardised Web Services tech-
nologies to support a service-oriented architec- each entity has only a single area in which to
ture of Grid Computing with enhanced inter- concentrate (see Figure 1).
operability and simplicity. The Computational
Markets project initially utilised Grid technologies such as OGSI but subsequently recognised
the advantages of in shifting to an interoperable and vendor-supported subset of Web Service
standards.
In tandem with this technological shift, increasing emphasis has been put on outsourcing
and managed services within business. Utility
computing providers and services are appearing
such as the Sun Grid [12] and HP’s Utility Rendering Service [7]. Businesses are realising that
the cost, both in terms of the hardware and the
maintenance, of managing their own computing
resources may be reduced by buying in capacity
on resources that are hosted and managed elsewhere. The cost and risk of operating large-scale
computing centres can be amortised among a
varied portfolio of clients. Resources are depreciating increasingly rapidly and utility computing can provide for transparent technology refresh as well as simplicity. Add to this the use of
managed services and applications, avoiding the
costs of internal sofware management, and the
cost of computing can be reduced dramatically.
Existing Grid middleware provides limited
support for the dynamic deployment of applications securely across organisational boundaries.
These have resulted in more efficient utilisation of computational power. The lower overall costs presented by the use of managed services in utility computing environments lead us
to predict the development of an open, composable market in services that we refer to as the
Next Generation Internet [5]. Figure 2 depicts
the stake-holders in such a market. To support
this, we have been working to prototype a framework that will support negotiation and payment
for access to remote use-on-demand, pay-per-use
services.
The decoupling of processes into clearly
defined elements brings about specialisation
within the market. Software providers can specialise in producing software services. They can
divert resources that would have have been used
for managing hardware and networking to aid
faster and more advanced development. In turn,
hardware providers can specialise in developing,
operating and maintaining their hardware resources in order to provide a more reliable and
efficient execution environment for use by the
software providers. The process of specialisation
should in turn drive increased innovation since
Fig. 1. Drivers in a Service-oriented market
Services may take the form of general execution provision, offering a service-based frontend for the execution of traditional HPC applications. These applications generally utilise
large amounts of CPU time but with a relatively small job count. A pay-per-use, use-ondemand model for services also suits low value,
high-throughput services. These are the services
that would not normally have access to expensive HPC resources. They are accessed by many
different users in different locations and their
throughput may be erratic. Obtaining a dedicated large-scale resource would generally be too
expensive for the service provider since the resource may be idle for a large proportion of the
time. However, when a large number of requests
are received at once, the service provider may
be unable to service the demand, users receive
poor quality of service and the service provider’s
reputation may be damaged. Using a managed
service model, the provider can pull in resources
when required in order to service demand and
pay only for the time that is used on those resources.
The creation of services and their deployment onto remote resources can be achieved using existing tools. One of the major barriers to
a service economy is the asymmetric information flow between the sellers and the buyers.
Buyers cannot reliably assess the value of the
goods being offered and the quality of the goods
traded are forced down (the Lemons Hypothesis). There is, therefore, a clear need and hence
a market opportunity, especially in the Internet economy, for brokers to intervene to act as
intermediaries between users and services. Such
brokers, by their reputation and longevity, could
organise and safeguard payments and provide
a level of trust for the market to operate efficiently.
Another barrier to a service economy is the
issue of payment. There are two sides to this
problem. How the price of a service is determined and how payment is actually made. We
introduce the concept of a chargeable service,
a service that, in addition to its general functionality, has a wrapper that manages charging
for its usage. Chargeable services may provide
straightforward functionality at a fixed price. In
the case of more complex services, for example,
an SME wanting to carry out some 3D rendering, the array of options for service operation
may be substantial and a personalised quote
would be most appropriate to ensure that both
the provider and consumer know what they are
getting and what it will cost. Auctioning and online exchange are popular price formation models because of their simplicity and well-known
economic characteristics.
parameters of a complex managed service provision. In a highly competitive market, where
many services claim to offer the same product,
a consumer may want to survey the offers from
all available providers in order to select the best
one. To this end, the negotiation interface is
seen as both something end-users may choose
to interact with directly, as well as a connector
through which brokers will communicate with
services in order to find the best deal for their
clients.
The Southampton e-Science Centre and
Swansea University have produced a chargeable Meshing Service, based on work from the
GEODISE project [6], as an exemplar for the
negotiation and payment framework. The Meshing Service is a complex, computationally intensive service used for generating 2D meshes for
use in engineering design and optimisation. It
has several negotiable parameters that affect the
amount of compute time required for its generation and the quality of the mesh produced.
3.1
Negotiation API
The negotiation API provides server and clientside tools to make an existing J2EE Web Service negotiable. We utilise Web Service standards including Web Service Description Language (WSDL) for describing services and the
Simple Object Access Protocol (SOAP) over
HTTP or HTTPS for transmission of messages
between services and their clients.
Fig. 2. Stake-holders in a Internet service market
Server-side The NegotiationPortType is an
additional port added to a service interface to
signal to potential users that the service is negotiable. The NegotiationPortType and the accompanying protocol allows the client to hold
a conversation with the negotiable service. A
client wishing to obtain a quote from a negotiable service would initiate a negotiation session with the service by passing a set of requirements in the constraints document. The constraints document describes a set of terms and
their relationships, for example:
In the remaining sections of the paper, we
will focus on a one-to-one negotiation model for
service access and the incorporation of payment urn:economic:Price = 3.54 and
urn:image:Quality > 45 and
that accounts for service usage.
urn:economic:Bundle <= 5
3
Negotiation
Negotiation is a practical mechanism to enable
providers and users to agree on the operating
Terms are identified by the URNs. A set of
common terms have been defined in the markets
toolkit to convey economic parameters, such as
Fig. 3. Negotiation client GUI
price, number of invocations, bundling and quality of service parameters. It is envisaged that
domain-specific terms would be defined in a
shared ontology, standardised by experts in the
particular application domain.
The Negotiable Service replies with a set
of refined constraints taking into account the
posted requirements. The client might refine
the constraints further by continuing the ongoing conversation with the service. The client
might eventually abandon the offers or commit
to the agreed terms proposed by the service. The
client would then be issued with an electronically signed token that will be used as a ticket
of entry along with payment confirmation when
the service operation is invoked before the expiry time.
ified to ensure that when the service is invoked,
it takes into account the negotiated parameters
for service use. The Negotiation engine API provides a series of assertion statements that can
be instrumented into the service code to ensure
agreed constraints are not violated at run-time
(e.g. number of iterations in an optimisation
loop).
Client-side Client-side use of the negotiation
API is significantly simpler than enabling a service for negotiation. The negotiation client API
manages the session with a negotiable service
and the security support in contacting and storing the secured token. From the API, a service’s negotiable parameters and their descriptions can be accessed and proposals can be made
for accessing the service. As part of the offer acceptance, the Payment Service is contacted to
ensure that the user has the means to pay the
agreed charge and a payment authorisation token is generated (see Section 4.1).
The Markets Toolkit allows service providers
to augment an existing J2EE compliant Web
Service implementation with negotiation capability. A configuration file, defining the set of
negotiable terms and the negotiation strategy,
is fed into the negotiation engine API. This represents the service provider’s private constraints
on how pricing is calculated. The existing framework adopts a simple constraints optimisation
module, which optimises on the service conA negotiation client GUI (see Figure 3) has
straints while attempting to satisfy the client been produced to allow manual negotiation with
requirements.
services. This has been used in the demonstraOnce the negotiation parameters are speci- tions of the prototype framework and example
fied, the code of the service itself must be mod- services.
4
Payment Service
The Payment Service is a J2EE compliant Web
Service that allows payments to be made, programatically, between entities that are known to
the service. The ability to make programmatic
payments means that complex HPC computations and brokering operations can take place
without user interaction, provided the user has
given their permission for this. In addition to
the Payment Web Service and client-side API
for making payments, we provide a web interface similar to an online banking service. This
enables users to register for accounts, view their
account statement and credit money to their account. An important aim of this work has been
to allow the transfer of real money rather than
simply using virtual funds. The service has been
linked to PayPal [10] using PayPal’s Web Services API. Users can credit real funds from their
PayPal account into their account in the Payment Service and, when accessing chargeable
services, payment is remitted to the PayPal account of the service provider.
4.1
Payment Service Architecture
Payment Protocol The Payment protocol
that is being used for this service was originally
presented in [4]. Payment is managed using tokens. A payment token is generated following a
request from one party to make a payment to another. This request may be generated from the
negotiation framework, alternatively it may be a
direct request through the Payment API. A set
of authorisation/authentication tests are carried
out on the payment authorisation request. If
these tests are successful, a unique token is generated representing the specific payment that
the user has requested. Within a given time limit
– determined when the token is generated – the
token may be submitted to the Payment Service with a request to complete payment. If the
requirements of this request are accepted, the
transfer of funds takes place.
Figure 4 shows the interactions involved in
the negotiation, authentication and completion
of a payment. Following the negotiation process
to agree a price, the payment is carried out as
follows:
1. The client creates an XML document that
details the requested transaction. This includes the source account (this must belong
to the client), the destination account, the
payment amount and a description of the
transaction. This message is signed using
the client’s private key. The client creates a
secure connection with the Payment Service
and sends the authorisation request.
2. The Payment Service evaluates the client’s
request. It first checks the signature on the
message. If the signature is valid, it checks
that the source account belongs to the person who signed the message. This check ensures that, unless a private key has been
compromised, no user within the system can
request the transfer of money from an account they do not own. If either the source
or destination account does not exist, an
error is generated. The service then checks
that the source account has sufficient funds
for the requested payment. If this check is
successful, a unique transaction identifier is
generated and an XML response document
is created. The Payment Service signs this
document in case the client wishes to check
that it has genuinely been communicating
with the Payment Service. This response
document is the token that can be presented
to the Payment service to complete the payment at a later time. The token contains
an expiry time, after which any attempt to
complete the payment will fail. This expiry
time may be specified by the client in the
original request.
3. The user eventually may wish to make use
of the Web Service for which they have obtained an authorisation token. They present
this token to the Web Service in the SOAP
header, along with a request to invoke it.
The Web Service then generates a payment
completion request document that wraps
the authorisation token and is specific to the
payment model being used (see Section 4.2).
The Web Service creates a secure connection
to the Payment Service and passes it the
completion document in a signed request.
The Payment Service will try and make the
transfer of funds and return a response to
the Web Service detailing the transaction
result. If the transaction is successful, the
Web Service can return its results to the
end-user. The digital signatures on the message ensure that the source and destination
accounts and amount stored within the token are secure. If this information is altered,
the digital signature verification will fail and
the Payment Service will refuse to transfer
the funds.
Fig. 4. Interaction diagram for payment negotiation, authentication and completion procedure
Implementation The implementation of the
Payment Service has been created using J2EE
1.4 compliant Web Services hosted on the Sun
Application Server Platform Edition 8. We have
used existing standards where possible and have
paid particular attention to security and crossplatform interoperability. All code has been
written in Java.
Security is an important issue in any distributed system, but particularly those where
transfer of money is involved. In order to secure the payment service, all users are identified by an X.509 certificate. All communications with the Payment Web Service are encrypted using SSL connections with mutual authentication, with the user’s X.509 certificate
identifying them. For negotiation, either transport or message-level security may be used. We
have produced example services that demonstrate both forms of security and have used
a Java WS-Security implementation to provide
message-level security.
We are currently using the Pointbase
database that is provided as part of Sun’s J2EE
Server to provide persistence for account information. The service implementation is compatible with other JDBC compliant databases,
such as Oracle. To ease the Interaction with the
relational database, the Enterprise Java Beans
(EJBs) abstraction has been adopted.
4.2
Payment Models
The Payment Service currently supports three
different payment models in order to provide
flexibility for service providers. Various other
models may be appropriate in different situations and the service may be modified in future
to support other payment models. The models
currently supported are:
– Standard Payment: The payment is authorised for a fixed amount and a token representing this amount is produced. When
payment is to be completed, the token is
presented to the Payment Service and the
authorised amount is transferred between
the source and destination accounts. A token may only be presented to the Payment
Service once.
– Variable Usage Payment: This payment
model is particularly suited to the purchase
of execution time. The exact amount of time
required on a resource may be difficult to
judge prior to the computation taking place.
Payment Authorisation can be made for an
amount that represents a cap on the maximum amount that can be spent. Once the
final amount is determined, the payment can
be completed. The authorisation token is
presented to the Payment Service along with
the final amount that is to be paid. Providing this amount is less than or equal to the
authorisation amount, the funds are transferred. Once the token has been presented
it has been used and is invalid. This is the
case even if the funds transferred are less
than the original authorisation amount.
– Partial Payment: The partial payment
model allows a payment to be authorised for
a particular amount but to be completed in
several stages. This is the one model of payment where a token may be presented multiple times. This model is useful for users purchasing multiple invocations of a fixed price
service. Unlike a pre-pay scenario, where
consumers pay up front a given sum, this
method allows a token to be generated that
will allow a given amount of money to be
transferred within a given time period. The
token can be presented multiple times, each
time specifying the amount to transfer. The
token becomes invalid when all the authorised funds attached to that token have been
transferred, or when the validity window is
passed.
transfers to other accounts registered with the
Payment Service. The account statement lists
all transactions along with their unique transaction identifier, the transaction date and time
and amount (see Figure 5).
6
Further Work
Integration with real-world payment systems
has been investigated in the development of the
prototype but is acknowledged to be a complex
issue. The integration with PayPal has allowed
transfer of real funds but integration with a system such as WorldPay, allowing direct credit or
debit card payments, would be valuable.
Simplification of the framework to allow services to be automatically wrapped for negotiation and charging would help adoption of such
a system. The aim would be to develop a utility
that can take existing Web Services, a set of negotiable parameters and domain of values and
then wrap the service automatically.
7
Related Work
Groups investigating problems related to the
economics of computational Grids include Rajkumar Buyya, University of Melbourne [3, 1]
and the IBM Zurich Research Laboratory [8].
Although there is much work surrounding this
area, there is little that has been focussed to5 Payment Service Interface
wards the practical issues relating to payment
for Grid Services. We therefore feel that our
The Payment Service Web Interface provides work and that of our partners within the Market
a browser-based interface for users to register for Computational Services project is of particand manage their accounts with the Payment ular value to the field of Grid Economics.
Service. When accessing the interface, a user
must have their certificate embedded in their
browser – they are identified using SSL Mutual 8 Conclusion
Authentication. To obtain an account with the
service, a user visits the payment interface us- With computational Grids becoming more coming their browser. From their certificate Distin- mon and their power becoming increasingly
guished Name (DN) they are identified and, if clear to both software and hardware providers,
they are not already registered, a registration the prospect of an open Grid market in services
page is displayed. The user enters their regis- is becoming more realistic. With Grids traverstration details which are stored in the database ing organisations and providing the means for
and a new account is generated. On subsequent resource owners to recoup some of the cost of
visits to the payment interface, users are pre- expensive equipment, a secure way to automatsented with a list of all the accounts they hold ically transfer funds between entities is imporand can select an account to view the account tant.
management page.
We have demonstrated a framework for supThe account management page displays a porting some of these needs, along with invesstatement for the account and enables users tigations into service negotiation and pricing to
to credit money into the account from the ac- support a market in distributed services. Our
count holder’s PayPal account and make manual work has provided a base upon which other
Fig. 5. Payment Service Web Interface account statement
project partners have been able to build exemplar services to demonstrate the power of a managed Web Service environment, as well as other
fundamental building blocks, such as resource
usage and accounting services.
Developments in the e-Science programme
have helped to erode many of the differences
and divisions that have separated various sectors and disciplines. Many of the products and
mechanisms of the e-Science programme have
potential applications in the public domain.
Complex e-Science or HPC methods, suitably
encapsulated, could become consumer-oriented
commercial services. We envisage virtual service
providers will make use of third-party services
to provide value-added products that might include highly complex methods requiring large
computational resources. These are currently
out-of-reach for most small to medium sized organisations who cannot afford to maintain such
an IT infrastructure. Advances in Grid computing technologies and innovative charging models could produce a radical change in the provisioning and use of information technology across
academia, business and society.
9
2.
3.
4.
5.
6.
7.
Acknowledgements
8.
We would like to thank the UK e-Science Core
Programme and the DTI who have funded the
“A Market for Computational Services” project.
References
1. R. Buyya, D. Abramson, J. Giddy, and
H. Stockinger. Economic models for resource
management and scheduling in grid computing. Special Issue on Grid Computing Environ-
9.
10.
11.
12.
ments, The Journal of Concurrency and Computation: Practice and Experience (CCPE),
14(13-15):1507–1542, December 2002.
R. Buyya, D. Abramson, and S. Venugopal. The
grid economy. In Manish Parashar and Craig
Lee, editors, Special Issue on Grid Computing,
Proceedings of the IEEE, volume 93, pages 698–
714. IEEE Press, New York, USA, March 2005.
Rajkumar Buyya. Economic-based Distributed
Resource Management and Scheduling for Grid
Computing. PhD thesis, Monash University,
Melbourne, Australia, April 2002.
J. Cohen, W. Lee, A. Mayer, and S. Newhouse.
Making the Grid Pay - Economic Web Services. In Building Service Based Grids Workshop, GGF11, Honolulu, Hawaii, USA, June
2004.
J. Darlington, J. Cohen, and W. Lee. An architecture for a next-generation internet based
on web services and utility computing. Technical report, London e-Science Centre, Imperial
College London, London, UK, 2005.
Grid Enabled Optimisation and Design Search
for Engineering (GEODISE) Project. http:
//www.geodise.org/.
Hewlett-Packard Development Company, L.P.
Servicing the animation industry: Hp’s utility
rendering service provides on-demand computing resources. http://www.hpl.hp.com/se3d/
whitepaper-urs.pdf, 2004.
Chris Kenyon. IBM Zurich Research Laboratory: Grid Economics. http://www.zurich.
ibm.com/grideconomics/.
London e-Science Centre. A Market for Computational Services. http://www.lesc.ic.ac.
uk/markets/.
PayPal (Europe) Ltd. Paypal. http://www.
paypal.co.uk.
Spring
Framework.
http://www.
springframework.org/.
Sun Microsystems, Inc. Sun grid. http://www.
sun.com/service/sungrid/overview.jsp.