1 / 24

Pay As You Go – Associating Costs with Jini Leases By: Peer Hasselmeyer and Markus Schumacher

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.

duer
Download Presentation

Pay As You Go – Associating Costs with Jini Leases By: Peer Hasselmeyer and Markus Schumacher

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Pay As You Go – Associating Costs with Jini LeasesBy: Peer Hasselmeyer and Markus Schumacher Presented By: Nathan Balon

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

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

  4. How Jini Works • There are three central components of Jini. • 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.

  5. Lookup Service

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

  7. 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; … }

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

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

  10. Problems with Charging for Services • 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.

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

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

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

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

  15. 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); }

  16. Proposed Architecture • The second part of the architecture are the run-time services. • Non-repudiation service • Time service • Accounting service

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

  18. Non-repudiation Service • Steps required for the non-repudiation service. • 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.

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

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

  21. Component Interaction

  22. Starting a Billable Lease • To initiate the use of a service the client sends a message to the non-repudiation 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 non-repudiation 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.

  23. Starting a Lease

  24. Future Work • There is no standardized and usable non-repudiation service. • Ways to negotiate contracts between parties needs to be established. • Ways to keep clients and service providers anonymous.

More Related