Pay As You Go – Associating
Costs with Jini Leases
By: Peer Hasselmeyer and
Markus Schumacher
Presented By: Nathan Balon
Introduction




The paper is proposing an extension to the Jini
Architecture to provide for the ability to charge for the
usage of a Jini lease.
Jini already has the ability to provide a lease for a
resources, so the authors are proposing an extension to
the leasing framework.
The authors then go on to provide a number of
solution to the problems that come from using billable
leases.
The main focus of the paper is the problems of
starting and stopping a leased service.
Background Information on Jini


The goal of Jini is to create a distributed
computing environment that allows for rapid
configuration of software and devices using a
“plug and play” model.
When a Jini device is attached to a network it
announces its presence. After its presence has
been announced, other components can then
use the services it has to offer.
How Jini Works

There are three central components of Jini.
1.
2.
3.
The service is a piece of independent functionality
made available to other users.
The client is a device or software component that
would like to use a service.
The lookup service is a special service that keeps
track of the other services in a community.
Lookup Service
Lookup
Service
1. The Service
publishes service
items with each
lookup service it finds
2. Client downloads
proxy object to
access service
Proxy
Service
3. Client uses the
proxy to
communicate with
the service
Client
Jini Leases





A Jini lease is a contract between two parties.
The lease grantor has a resource they are willing to
grant to another party.
Lease holder then uses the resource of the lease
grantor.
Before granting access to a resource, a length of time is
negotiated between the two parties. The lease grantor
always has the final say in the negotiation of time
length.
Jini leases are primarily used for garbage collection. It
provides a convenient way for unused resources to be
freed when the lease expires.
Lease Interface

Any object that wishes to grant a lease must
implement the lease interface.
public interface Lease {
// duration is in milliseconds
void cancel() throws UnknownLeaseException, RemoteException;
long getExpiration();
void renew(long duration) throws LeaseDeniedException,
UnknownLeaseException, RemoteException;
…
}
Extension to Jini Leases





The authors envision using Jini leases in a commercial
environment.
Service providers could then charge a fee for the use of their
services.
In a Jini system software entities communicate with each other.
This poses a problem, the typical model used on world-wide web
is to generate revenue for the services provided through
advertising, this model is unacceptable in this case.
Two pricing models could be used in the charging for a service.
They are: unit-based pricing and time-based pricing.
A few examples of services that could be leased for a fee are: a
storage service which could be used to perform temporary
calculations, also software components that rarely used could be
leased.
Problems with Jini Leases



Using Jini leases in a commercial environment poses a number
of problems.
The majority of the problems deal with the security threats to
the Jini lease model when used in a commercial environment.
Problems that arise:






Violation of Integrity
Theft of Information
Denial of Service
Repudiation: it cannot be verified that a user has performed a certain
action.
For integrity and confidentiality authors propose the use of
encryption to combat these threats.
The intent of the paper was to focus on the threat of
repudiation.
Problems with Charging for Services
1.
2.
3.
4.
The service provider must be sure that a client
has really ordered a service.
Clients want to be sure that a service provider
has received an order.
It should be impossible for a client to use a
service and not pay for it.
A service provider should not be able to get
money for a service they have failed to
provide.
Non-repudiation



The parties involved must have some way of
guaranteeing that each one completes their part
of a contract.
If a dispute arises between the parties there
must be a way to determine who is right or
wrong.
The authors state “the goal of non-repudiation
is to transfer the concept of proofable contracts
to the users action in IT systems.”
Requirements for Non-repudiation




All participants must trust the concept of and
functionality of a service.
All participants must be willing to accept the
result of the validation of proofs.
The judgment must be enforceable.
A legal binding must be established for the basic
cryptographic mechanisms.
External Dependencies

A number of additional external services are
need along with the non-repudiation service the
authors are proposing.
Public Key Infrastructure: key management is need
to provide digital signatures.
 Secure Time Service: a trusted time service is
required.
 Secure Storage: electronic evidence must be stored in
a secure location.
 All communication channels must be secure.

Proposed Architecture

First, there is set of rules that the service must obey.






Java interfaces are used to define a number of methods that must be
implemented.
The authors propose extending the Lease interface with a BillableLease
interface.
Every service must also implement the AccessCharge interface to
associate a cost to a service.
The two proposed interfaces use some additional objects which are : a
Contract object and a Evidence object.
Contracts must be remotely accessible object that link a service to a
specific contract. The authors envision contracts as being signed xml
documents.
The Evidence objects are objects created by the non-repudiation service
which we will see shortly.
Proposed Interfaces
public interface BillableLease extends Lease{
Contract getContract();
long getCost();
Evidence renew(long duration, Evidence ProofOfOrgin);
Evidence cancel(Evidence ProofOfOrgin);
}
public interface AccessCharge{
AccessGrant start(Contract termsAndConditions,
Evidence proofOfOrgin,
long duration);
}
Proposed Architecture

The second part of the architecture are the
run-time services.



Non-repudiation service
Time service
Accounting service
Non-repudiation Service



It Creates pieces of evidence (proofs).
It persistently stores evidence (proofs).
Evidences contained in proofs:







The contract that has been applied
Type of action or event (method name called)
Parameters of the method
A signed time stamp
The identity of issuer of proof
The identity of both parties
Hash value for validation of the proof
Non-repudiation Service

Steps required for the non-repudiation service.
1.
2.
3.
4.

Evidence generation
The transmission, storage and retrieval of evidence
Validation of evidence
Settlements of conflicts
The authors note that settlements of conflicts
will usually be done by human intervention.
Time Service



The time service is a trusted entity that supplies
time stamps.
The time service is needed because of lack of
synchronized time in a distributed systems.
The non-repudiation service will then use the
timestamps generated from the time service.
Accounting Service


The accounting service is responsible for storing
and retrieving billing records.
Contains information such as the time and
length of service usage, type of service used,
identification of the client and a reference to the
contract used.
Component Interaction
Starting a Billable Lease
1.
2.
3.
4.
5.
6.
7.
To initiate the use of a service the client sends a message to the nonrepudiation service to generate a proof of origin.
The client then receives the proof of origin from the non-repudiation
service.
The client then calls the start method from the AccessCharge interface
and supplies the proof of origin along with the additional required
parameters which is sent to the service provider.
When the service provider receives the start request, the service provider
then asks the non-repudiation service to generate a proof of receipt.
The service provider upon receiving the proof of receipt from the nonrepudiation service, then returns to the client a proof of receipt and a
billable lease.
The client has now established a lease and can use the services.
At the completion of the service usage the service provider sends a billing
record to the account service.
Starting a Lease
Future Work



There is no standardized and usable nonrepudiation service.
Ways to negotiate contracts between parties
needs to be established.
Ways to keep clients and service providers
anonymous.