A free market in telescope time II: a test implementation

1
A free market in telescope time II a test
implementation

• Iain Steele, Neil Clay, Chris Mottram (Liverpool
  JMU)
• Jeremy Cohen, William Lee (London e-Science
  Centre)

2
Many moons ago(SPIE 2004)

• Distributed telescope networks are starting to
  emerge
• Achieving a global optimization of their use is a
  hard problem
• Dynamic demands (observe this outbursting GRB
  now, stop observing this quiescent DN now, )
• Dynamic constraints (my spectrograph is broken,
  the seeing here is excellent at the moment, )
• Valuation problem (how much is my time worth in
  exchange for your time?)
• We presented a paper suggesting a free market
  based approach to scheduling the emerging
  distributed telescope networks

3
Two Questions

• Can we use emerging grid and web service
  technologies that are being developed to support
  markets in computer based services in astronomy?
• What parameters can we negotiate on sensibly in
  an astronomical context?

4
Computational Markets Toolkit

• A Project in the UK e-Science Core Technology
  Programme

The London e-Science Centre The CLRC e-Science
Centre E-Science Centre North West The
Southampton e-Science Centre The University of
Wales at Swansea The Astrophysics Research
Institute at Liverpool John Moores University
Computer Sciences Corporation Numerical
Algorithms Group GreenGrid RealTime Engineering
Ltd Sun Microsystems Ltd SGI Inc Oracle
5
Toolkit overview

• Initially investigated OGSI-based grid
  infrastructures, now working with Web Services
  reflecting the growing shift in the Grid world to
  Web Service technologies.
• Underlying services
• London e-Science Centre
• Negotiation service
• Payment service
• Manchester Computing
• Resource Usage Service
• Real Time Engineering Ltd
• PayPal Integration

6
Test Cases

• GEODISE FEA Meshing Service Matlab Client
• Telescope Access (this talk)
• CSAR, NGS compute jobs for image compression
• Sun PpC for image rendering

7
Project Information

• Project web pages
• http//www.lesc.ic.ac.uk/markets
• Password protected developer site CVS password
• Installation and Developer guides
• Built using Apache Forrest
• Simple XML based site design
• Project Twiki
• https//twiki.lesc.ic.ac.uk/markets
• CVS Repository for project code

8
The toolkit

• Enable existing Web Services for negotiation and
  payment.
• Use standard protocols and tools
• J2EE 1.4, SOAP, WSDL, HTTP(S), WS-Security, X.509
  Certificates, Digital Signatures
• Using Sun J2EE Application Server
• Currently support only Update 1 June 15th
  2004 version
• Negotiation interface provides functionality for
  brokers.
• Programmatic payments can be made through the
  GMarkets Payment Service.

9
Making a service chargeable
Payment Service
ChargeableTelescopeService
TelescopeService
RTML Functionality
RTML PortType
Invoke observing operation
User Agent
User Agent
Perl / Java / etc
10
Architecture
Browse statement
ResourceUsageService
PaymentService
Market Manager ?
Set pricing policy ?
Record usage
Browse statement authorise payment
Complete payment
Pricing Policy 1
Pricing Policy N

ChargeableTelescopeService 1
ChargeableTelescopeService N

User Agent 1
User Agent n
Java
Perl
11
Negotiation

• Why negotiate?
• Different services represent different value to
  different users
• Process of agreeing on a price and the operating
  range of parameters
• What we have developed?
• Protocol for representing a negotiation session
  and expressing requirements
• Negotiation port type to make existing service
  negotiable

12
Negotiation
User Agent
NegotiationPortType
RTMLPortType
I would like to observe a 20th magnitude object
with a gt1 metre telescope obtaining a SNR of 10
in 50 seconds in the next 10 minutes.
13
Payment Service

• Two-phase commit protocol for authorisation and
  payment
• Web service port type for programmatic access to
  payment service
• Client-side library to enable new and existing
  services for charging
• Integrated with PayPal using Web Services API,
  designed with connection to other real-world
  payment systems in mind

14
Payment Service Operation
UserAgent
Web Service (Negotiable Telescope)
Payment Web Service (PaymentProviderPortType)
User
15
(No Transcript)
16
Negotiation Terms

• Remember that negotiation not done through
  RTML/HTN standards for this project
• In principle everything is negotiable!
• In practice not true - consider location and SNR
• For GRBs you care deeply about location, in some
  deep surveys you may not
• You can go very deep with a small telescope if
  you integrate long enough (but what about
  tracking accuracy, cosmic rays etc)
• We chose Mirror diameter, SNR, Exposure Time,
  Expiry Date, Price
• But also need to provide location, object
  brightness

17
Problems

• Everything must be cast as integers (specific
  limitation of current toolkit)
• Even with a full cast of types, things like
  area on the sky are pretty astronomy domain
  specific and hard to map onto generic tools
  without making many assumptions at both client
  and server about the exact meaning of a large
  number of parameters.
• Offer/counter-offer can become circular or be
  slow to converge
• inefficiency of the market translates into a
  cost.
• i.e. if I offer enough I can always get something
  (the GRB) done quickly but it will cost me dear..
• Can brokers (speculators) provide a solution?

18
Conclusions

• Trust and/or Verify
• Generic toolkits can provide useful uncheatable
  accounting and payment services
• Negotiations
• Models (offer/counter-offer, auctions) etc. map
  onto astronomy
• Terms of negotiation are not well supported by
  generic toolkits