Metering and Licensing of Resources: Kala's General Purpose Approach
by Sergiu S. Simmel and Ivan Godard
ABSTRACT
This paper describes the licensing and metering capabilities of Kala[1], a persistent data server. Kala offers a suite of low-level
primitives for constructing both simple and sophisticated licensing
(pay-per-user) and metering (pay-per-use) models. Kala allows the licensing
and/or metering of access to any software facilities, both data (passive
resources) and executable code and associated services (active resources). A
few examples model concrete business needs, bridging the gap between
technologically motivated mechanism and business motivated policies.
INTRODUCTION
This section motivates the work on economic grounds. It also introduces several
terms used throughout the paper.
Components, Subassemblies and Applications
It is natural to think of software as being an assemblage of
components. Software structure starts with small-grain components
such as functions, classes, and data values. These are grouped in
subassemblies, such as a library or a subsystem. Successive
composition finally yields what we all think of as applications
-- a conventional packaging of functionality.
The basic distinction between components, subassemblies and applications is
that of granularity. In electronic hardware the analogous entities are
electronic components (such as integrated circuits and passive components),
boards (usually ready to be plugged into bus connectors), and systems (such as
personal computers).
For simplicity, we will use the term component to mean both
components and subassemblies. We will use the term subassembly
only if there is need to distinguish them from small-grain components.
Both program components and data components exist. The former includes such
examples as operating system subsystems, runtime libraries, specialized
classes, etc. The latter includes font collections, clip-art sheets, economic
indicators, and so on.
Components, subassemblies, and applications go through an economic cycle which
includes two mechanisms relevant to our discussion: the distribution mechanism
and the revenue collection mechanism.
Distribution is the mechanism by which a component is made available to
another component or final consumer (end-user). Several distribution techniques
are conventionally used throughout the industry: embedding (static linking),
runtime linking, and runtime loading.
Revenue Collection is the mechanism by which payment for a component is
made to reach the producing vendor, regardless of the context in which the
component is actually used. Conventionally, revenue collection is done at the
time the component is distributed.
The Economics of Components
Markets for software applications have been established for some time. There is
a market for subassemblies as well, although substantially smaller and with
much less potential for growth and diversification. The market for small-grain
components is very small, although a great many are given away free or bundled
with larger units.
Many analysts attribute the relative lack of an open market for components to
the tight coupling between delivery and revenue collection. The reasons
include, among others:
- Hard to Control Scarcity. Distribution cannot be effectively
controlled because information is easy to duplicate. This leads to large
percentages of fraudulent use.[2] Since the software
industry needs to collect enough revenue to pay its own bills, the result is
higher prices paid by a small fraction of users, with a secondary effect of
diminishing market sizes.
- Hard to Select. It is difficult and inconvenient to "test-drive"
software components and applications, because users are asked to pay the high
price of acquisition before being able to determine whether the software is of
adequate quality or even needed.
- Hard to Get Fair Revenue. It is difficult to predict actual
distribution volumes at the time redistribution arrangements are made. For
simplicity, many such arrangements are based on a flat fee. Inevitably, many
end up being unfair to one of the parties, with negative effects on the entire
industry.
An unprofitable component market deprives the software industry at large of:
- Well Crafted Components. Components should be produced by the best
specialists in the relevant technology. However, there is no incentive for them
to enter this market, since there is little chance that their efforts would pay
off.
- Higher Quality Infrastructure. Most of the industry's focus is on
producing applications -- the only merchandise one can make real money on. This
strong bias has negative long-term effects on the quality of the software
infrastructure and the specialized components out of which the industry builds
these applications.
- Slower development of technology. Fewer quality components leads to
less reuse and more reinventing the wheel.
The natural solution to all of these problems is to decouple delivery and
revenue collection: make the delivery mechanism direct, easy, and largely free,
and then use a separate mechanism that insures collection and proper allocation
of revenue. The only charges at distribution time should be to cover media
manufacturing (including printed documentation, if any), and physical
transportation, if any. These charges can also be eliminated in many (but not
all) instances through delivery via high-speed networks.
A simple solution, indeed. Why has it not happened? Reasons are multiple,
including:
- Cultural Barriers. We've done business in one way for over 40 years
now. The basic methods were established in an era where mainframe software was
the predominant product. Additional techniques were added with the advent of
standalone personal computers. While most of the software (by revenue) to be
sold over the next decade will not fall into either of these categories, the
culture that generated the practices is still strong.
- Opposition by Monopolies. The large monopolies perceive change that
may establish a fairer way of compensating value, emphasizing quality, and
encouraging the small but highly skilled producer to be not in their best
immediate interest. While one could argue that this is just a matter of
perception, and that in fact change is in everybody's best long-term interest,
the perceptions remain and strongly influence the attitude of many of the
larger participants in this industry.
- Absence of Supporting Infrastructure. To actually effect such a
change, a simple, secure, flexible, and general purpose infrastructure must
exist and support the new manner of collecting revenue well. In its absence,
the discussion remains academic.
While we recognize the importance and seriousness of the first two barriers
listed above, we are not addressing them here.[3] This paper
is about the third barrier. Our thesis is that such a technological
infrastructure now exists. We are presenting both a model and a concrete,
industrial-quality, commercial implementation of it, as part of the Kala
technology and persistent data server product.
Revenue Collection
To be useful in practice, the revenue collection mechanism must satisfy several
requirements:
a. Be safe. The mechanism must address safety very seriously, so that it
seen as truly solving the revenue loss problem, as opposed to replacing it with
another variant of it. Thus, the mechanism must be foolproof against major
fraud.
b. Be recursive. The mechanism must not only allow the collection of
revenue, but also the allocation of some portion of it to subsidiary suppliers.
This reflects the components-made-out-of-components structure of software.
c. Be flexible. The mechanism must be just that: a mechanism. It
should allow the component vendor the maximum flexibility to establish policies
and reflect business arrangements and special cases.
d. Be efficient. The mechanism must introduce very little, if any,
overhead to the normal functions of the components and applications it
supports.
e. Be invisible. The mechanism must be largely transparent, and
simplify customers' lives, rather than become a nuisance like dongle chains.
There are two principal arrangements possible between the producer and the
consumer of a component:
- Pay-per-use. This is an arrangement whereby the consumer pays the
producer for as much of the producer's software as the consumer's software
actually uses. The measurement of use is specified as part of the arrangement.
This technique is often referred to as metering.
- Pay-per-user. This is an arrangement whereby the consumer's
software is permitted to use the producer's software for a fixed period of time
in return for a fixed fee, independent of whether or how much the consumer's
software actually uses the producer's software. This technique is usually known
as licensing, and sometimes referred to as
pay-per-copy.
The pay-per-user technique is certainly the dominant one in today's software
industry, but the pay-per-use technique is hardly unknown. Pay-per-use is used
extensively by utilities (your gas and electricity consumption is metered, and
so is most of your telephone use), postal services (through the now widespread
postal meters), city services (parking meters), music industry (jukeboxes),
etc.
In the information industries, pay-per-use is employed extensively by
information database providers (e.g., reference searches, legal databases,
medical databases), bulletin board operations, and consumer information
providers (e.g., CompuServe, Prodigy).
For component distribution and revenue collection purposes, we submit the
following additional requirement:
f. Provide Dual Technique. Both pay-per-use and pay-per-user arrangements
must be supported; metering becomes the default mechanism in the absence of any
pre-paid license.
We motivate this requirement with an example involving end-users and an
application. Similar examples can be constructed to involve software components
only.
Suppose that you are the manager of a medium-size software development group,
say 30 people. You have 25 software engineers and 5 technical writers. Your
platform is a network of Unix workstations. You must purchase an authoring
system to be the technical writers' main tool, and also to be used occasionally
by the software engineers. Typically, you'll be presented with products based
on floating licenses.
You know that your writers will use the system every day, intensively. You also
know that your engineers will rarely use it, but once a month they will all
want to use it simultaneously to write their status reports to the management.
The question is: how many floating licenses should you buy?
If you buy 5, then either no engineer will be able to use it, or they will
constantly fight over licenses with the writers. This decision will waste you
time, energy, and perhaps even people!
If you buy 30, then everybody will be happy, except for your CFO: you will end
up with 25 licenses sitting around unused for most of the time. This decision
will waste you quite a bit of money!
If you buy any number between 5 and 30, you'll still waste purchasing money and
still have to force people to come to work at odd hours to abide by their
licenses.
You don't have to worry about any of the above if the application offers both
pay-per-user and pay-per-use. You buy 5 licenses to satisfy the predictable,
steady use by the writers. You also pre-pay some amount of use, and have the
application run off the meter any time more than 5 people try to use it. If you
run out of meter, you call your vendor with your credit card and buy more.
Problem solved: save both headaches and money at the same time with a simple
but flexible approach.
THE RESOURCE MODEL
This section introduces the resource management conceptual model of metering
and licensing. We introduce several new notions, including resource, vendor,
account, etc. We also explain in detail the concept of acquiring a resource,
and the resource acquisition algorithm.
Resources and Sub-resources
A resource is an abstraction representing access to a software
component, such as:
- software subsystem (e.g., a math library, a persistence library, etc.), or
- data (e.g., a font family, an encyclopedia entry, a stored movie, etc.), or
- generally, an object or cluster of objects.
The relationship between a resource and the related software component is such
that one can only access the component via the associated resource.
Accounts, Vendors and End-Users
Each resource has an account, which contains the current balance,
measured in meter units. If the account has a negative balance,
the resource owes units to one or more resources. If the account has a positive
balance, the resource is owed units by one or more resources.
Meter units are the currency in which all transactions between resources take
place. Meter units are converted to cash when revenue is distributed to or
collected from vendors.
Each component and the corresponding resource is owned by a
vendor. The vendor can be the manufacturer of that component, an
agent for the manufacturer, or anyone who has acquired the legal right to sell
access to that component.
For accounting purposes, end-users are also represented by resources. Thus,
each end-user's resource has an account. This account is debited any time the
end-user uses metered resources, and credited any time the end-user purchases
more meter units for cash. The end user may be a real person
(based on whatever the local system uses for user identifier), budget
pseudo-people (virtual users set up simply as means to implement budgeting
classifications), or an installation as a whole if finer grain accounting is
not required.
Periodically payments are made to the vendors whose resource's accounts had
positive balances.
In summary, resources deal in meter units, while vendors (and users) deal in
monetary currency (e.g. U.S Dollars, Deutsche Marks, etc.).
The Structure of a Resource
A software component uses other software components to implement
its functionality. Correspondingly, a resource uses other
resources, which become its sub-resources. In Figure 1, resource A uses
resources X, Y, and Z, which are its sub-resources.
Each resource is identified by a resource identifier (or a
rid). Resource identifiers are universally unique, so that
accounting integrity is preserved.
Thus, conceptually, a resource has the following components:
- a set of sub-resources,
- an account with a balance, and
- an associated software component.
Resources are implemented as persistent objects, subject to the same
persistence and visibility properties as any other object in the Kala
system.
Licensed vs. Metered Use
The use relationship between a resource and any of its sub-resources can be
based either on a license or on a metered basis. The subsections below explore
in detail each of these two alternatives.
Licensed ("pay-per-user") use
A license is a deal between a grantee resource M and a grantor resource N
whereby N grants to M's component access to N's component for a certain period
of time, in return for a pre-negotiated license fee (see Figure 2).
In this context, the license fee is the monetary exchange between
the vendors that own the two resources M and N, or between an end-user
represented by resource M and the vendor that owns resource N.
A license is implemented as a persistent object in the system. The mere
existence of a license object implies that the license fee has been paid. The
connection between the existence of a license object and the actual payment for
the license can be enforced by the software under certain circumstances,
explored in more detail in the Section on "The Architecture".
The license duration is the time for which a license exists.
License durations can be expressed either as elapsed time (measured in days) or
as a fixed date, denoting the license's expiration time. A perpetual
license is a license whose duration is infinite. A temporary
license is a license whose duration is finite, and usually shorter than
the usefulness of the granting component.
Thus, a license consists of:
- Grantor. This is the rid (resource id) of the resource granting
access to its component.
- Grantee. This is the rid of the resource whose component gains
access to another component. This may be wildcarded, i.e. `any using resource'
or specified by predicate.
- Duration. This is the time validity of the license.
A licensed use engenders a fee regardless of whether or not the licensed
resource (the grantor) is used or not. Through a license, the grantee gains
access to the grantor's associated component without additional charge, but the
grantee need not actually access it.
Metered ("pay-per-use") Use
A metered charge is an exchange between a grantee resource M and a grantor
resource N taking place at execution time, whereby N grants to M's component
access to N's component in return for a metered fee.
As in the licensed case, there is a grantor resource and a grantee resource.
However, the relation between them is established at runtime, based on two
pieces of information:
- The potential grantor's provisional charge. Each resource defines
charges (in meter units) that it will ask for if its component is requested. A
provisional charge is an object that specifies both a potential
grantor and a potential grantee, thus allowing different charges to be applied
to different requestors. These party specifications can be wildcarded. The
model does not specify how the charge is defined, what are the terms, etc. This
is a matter of policy, left to the users of the resource manager to negotiate
and define.
- The potential grantee's acceptable provisional charge. Each resource
defines a method by which it decides whether it will accept a charge or not.
While the model allows this definition to be associated with a resource, it
does not specify how this acceptance should be determined. This is a matter of
policy, left to the users of the resource manager to define for their
resources.
The metered use involves a runtime provisional charge acceptance step. Once the
potential grantee accepts the potential grantor's provisional charge, the
access is granted. Thereafter, metering engenders a fee only if the granted
resource is actually used. Upon access (use), the resource manager debits
metered units from the grantee's account and credits them to the grantor's
account.
The transfer is done by the resource manager after completion of all use of the
granted component, according an actual charge definition presented by the
grantor resource and accepted by the grantee. This actual charge is checked for
error and inconsistency against the provisional charge and acceptance is
recorded during the resource acquisition phase prior to the grant of
access.
The Resource Graph
For both licensed and metered use relationships between resources and their
sub-resources, the totality of resources that make up an application form a
directed graph, called the resource graph. The resource graph is
not a tree because some components may be independently used by several
different components that enter into the making of an application.
For the purposes of the model detailed in this paper, we assume the resource
graph to be static. That is, its structure is determined at a time prior to the
execution of the application. For example, this could be at static linking
time, or at application definition time.[4] In other words,
for simplicity we assume that the knowledge of all components that could be
potentially used by an application is present before the application is
actually launched.
The model is easily extended to allow for a dynamic resource graph. This
provides for the general case in which the set of components potentially
used by an application is not known at application launch time.
The resource graph has a root node, corresponding to the resource associated
with the application. In the example in Figure 4, the root node is A. The set
of all nodes in the graph is obtained by the transitive closure of the use
relationship.
The example in Figure 4 shows the resource U corresponding to the end-user who
runs the application. It also shows B and C having self-pointing arrows. These
arrows indicate that both B and C add value beyond the value acquired from
their own sub-resources (K in C's case, none in B's case), and therefore their
own use is not free.
For an application to run successfully, the top level code (the application's
main program) must gain access to all its components, and so on recursively.
This translates into the resource A acquiring its sub-resources,
its sub-resources acquiring their own sub-resources, and so forth until all
resources in the resource graph have been acquired.
Acquiring a Resource: The Basic Algorithm
Acquiring a resource is a recursive process, starting from the root of a
resource graph and working its way down until all resources have acquired all
their sub-resources. There are three kinds of information that are used in the
process:
- the resource graph,
- the existing license objects, and
- the provisional charge and charge acceptance definitions associated with each
resource.
When an attempt is made to acquire a resource X, the following algorithm is
followed:
Step 1: For each of X's sub-resources Y:
1.a Attempt to acquire Y.
1.b If successful, then go to next sub-resource,
if any.
1.c If Y requests a charge, and there is a
license from Y to X or any parent of X, then
acquire Y with license.
1.d If Y requests a charge, and there is no
license for Y, then accumulate charge.
Step 2: Add local added value to accumulated charge.
Step 3: If X's parent has a license for X, then
3.a Accept provisional charges from all X's
sub-resources, and remember to pay all charges
to X's sub-resources from X's account.
3.b Return success.
Step 4: If X's parent has no license for X,
then propose to charge accumulated charge
to parent.
Step 5: If X's parent accepts provisional charge,
then
5.a Accept provisional charges from all X's
sub-resources, and remember to pay all charges
to X's sub-resources from the actual charge
received from X's parent.
5.b Return success.
Step 6: If X's parent refuses the provisional
charge, then return failure.
As the algorithm shows, negotiations take place between a resource and each of
its sub-resources. The negotiations take place entirely outside the resource
manager, which is totally unaware of the nature, methods, and means of these
negotiations. A negotiation may be a complex dialog between the two resources,
or may be empty (no negotiation at all).
However determined, the result of the negotiation is communicated to the
resource manager by both parties. The potential grantor communicates to the
resource manager a provisional charge (in Step 4), while the
potential grantee communicates a provisional acceptable charge
(in Steps 3a and 5a).
The resource is able to acquire the sub-resource if it either has a license for
it or is ready to accept metered charges, based on the provisional description
of the charges presented by the sub-resource. If neither of these happens, the
resource is unable to acquire the sub-resource, and the entire algorithm fails,
all the way up to the root of the resource graph. In other words, an
application can execute if and only if it is able to acquire all resources in
its resource graph.[5]
When proposing or accepting a provisional charge, the resources inform the
resource manager of the fact by supplying a pair of two numbers (a range). The
lower number represents the provisional minimum charge: if the
provisional charge is accepted then the grantor resource's account will be
credited at least that many meter units, whether or not the grantee accepts the
final actual charge (see Section on "Charging and Disbursing"). The provisional
minimum charge may be zero, but not negative.
The upper number represents the provisional maximum charge. It
means that the grantor resource's account will be credited no more than that
many meter units (see Section on "Charging and Disbursing"). If the final
actual charge exceeds the provisional maximum charge, the resource manager
considers this an error (a sign of potential run-away charges), credits the
grantor's account with only the provisional minimum charge, and refuses to
acquire the grantor resource for the grantee resource until the bug is fixed.
The provisional maximum charge may be infinity, but not smaller than the
provisional minimum charge.
Charging and Disbursing
After having successfully acquired all the resources it needs, an application
can now execute. As it runs, some resources are actually used. Some resources
may never be used.
As they are used, those components that have been acquired on a metered basis
(as opposed to a licensed basis) tally their running charges using their
internal algorithms and internal data structures to hold the running
tallies. At the same time, those components which acquired other components
on a metered basis may also keep a tally of the charges they are expecting to
eventually receive from those components based on the actual pattern of usage.
This tally too is performed entirely by internal algorithms, possibly based
upon information about the grantor resources which was obtained during the
negotiation phase.
At the end of the application execution, the grantor resource presents the
accumulated actual charge tally and the grantee resource presents
the accumulated expected charge tally (as an actual acceptable charge) to the
resource manager, which compares them to each other and against the provisional
charges specified by the grantor and provisional limits accepted by the grantee
resource.
If the actual charges conform to the agreement represented by the agreed
provisional charges, the resource manager transfers the amount of metered units
actually charged from the account of the grantee resource to the account of the
grantor resource. The same process occurs for all components which were
provided on a metered basis. These transfers are known as actual
charges. They may include charges to the end-user's account.
The tally by the grantee of expected actual charges is intended to provide a
check on the veracity of the grantor beyond the rather broad limits of the
provisional agreement. The grantee presents the expected actual charge to the
resource manager in the form of a range, and so need not be exact in its
calculation of the expected actual charges. Indeed if the grantor is trusted,
the grantee may omit the expected tally altogether and present the resource
manager with an expected actual charge range of zero to infinity, effectively
taking the grantor's word for the actual charges.
Accounting
Periodically, the resource accounts must be converted into cash, so that the
corresponding vendors can be paid cash for the use of their components. This
can be done at specific times (such as whenever end-users refill their own
resource accounts), or regularly (for example, on a quarterly basis).
The resource accounts conversion is an activity of summarizing
the balances of all resources in a resource manager installation, communicating
the summary to the agency that does the conversion (the equivalent of the
bank), the agency paying the corresponding vendors the equivalent amounts of
cash, and finally resetting the paid accounts to zero, ready for the next
cycle.
The resource accounts conversion can be carried out manually or mechanically. A
manual process involves running a batch program at the installation site, which
will create an accounting dump file; sending the accounting dump file to the
metering agency (the resource manager vendor); and finally reinitializing
vendor account balances at the site.
The same activity can be carried out entirely mechanically over a modem or
other transmission line. The activity can be manually started or could even be
started automatically (by the resource manager itself), thus making it largely
transparent to the end users.
A RESOURCE ACQUISITION EXAMPLE
To provide a simple example, this section traces the execution of the basic
resource acquisition algorithm presented in Section on "Acquiring a Resource:
The Basic Algorithm" .
The Resource Graph
The example involves four resources: A (the root resource, likely standing for
the application), B, C, and K. The resource graph is shown in Figure 5.
Here, resource A uses resources B and C, and resource C uses resource K.
Resource B does not use anything else, but adds its own value B'.
We also assume that A has a license for C, and that there are no other
licenses. Let's assume that K submits a provisional charge with a minimum of uK
meter units and a maximum of infinity (with the actual charge computed on
usage), and that B' proposes a provisional charge with a minimum of uB units
and a maximum of uB units as well (fixed fee).
Tracing Through a Resource Acquisition
The execution of the algorithm in Section on "Acquiring a Resource: The Basic
Algorithm" to acquire resource A entails the following sequence of events:
- The end-user attempts to run the application, i.e. the end user's resource
attempts to acquire the application's resource A.
- A attempts to acquire B (cf. A's step 1).
- B has no sub-resources, but has a local charge of a minimum uB meter units
(cf. B's step 2).
- B proposes the provisional charge (uB, uB) back to A (cf. B's step 4). This
provisional charge is accumulated by A (cf. A's step 1d).
- A attempts to acquire C (cf. A's step 1a).
- C attempts to acquire K (cf. C's step 1a).
- K has no sub-resources, but has a provisional local charge of (uK,
[[infinity]]) which it proposes to C (cf. K's step 4).
- C has accumulated provisional charges of {(uK, [[infinity]])} (cf. C's steps
1 and 2), and proposes them up to A.
- A has a license for C, and presents it in response to C's provisional
charge (cf. A's step 1c).
- C accepts K's provisional charge, but must commit to pay out of its own
account (cf. C's step 3a).
- Since C accepted K's provisional charge, K returns success (cf. K's step
5b).
- C has successfully acquired all its sub-resources, and it returns success
(cf. C's step 3b).
- A still has an accumulated provisional charge (from B) of {(uB, uB)}, and
it asks the end-user resource whether it accepts this provisional charge (cf.
A's step 4).
- The end-user resource accepts, either by silent pre-specified provisional
acceptance of the charges or interactively by responding "Yes" to the "Accept
charges?" dialog box (cf. A's step 5).
- A accepts B's provisional charge of (uB, uB) meter units (cf. A's step
5a).
- B receives the acceptance to its provisional charge and returns success
(cf. B's step 5b).
- A has acquired all its sub-resources, and it returns success (cf. A's step
5b).
- All components of the resource graph have returned success, and so their
respective components have been acquired. A proceeds with execution of its
associated component.
- During execution, K internally accumulates the actual charges for the
actual use made of its component (as opposed to the provisional charges used
during resource acquisition). B need not do this as it is using flat fee
charging.
- At completion of execution (signaled by A) B and K present their final
bills based on actual usage to the resource manager. B presents a uB* actual
charge equal to the uB provisional. K presents a uK* actual charge, greater
than or equal to the provisional charge uK.
- The user resource, which knows that it is expecting a uB charge from B,
presents an acceptance of a {(uB, uB)} actual charge to the resource manager.
C, which has been keeping rough track of the use it has been making of K,
presents an acceptance of a {(uK, uK)} actual charge to the Resource Manager,
where uK is somewhat larger than the uK* computed by K but low enough to catch
any error or cheating by K.
- After verification, the Resource Manager debits uB* units from the user
(resource U) and credits them to B, and uK* units from C and credits them to K.
The transaction is complete.
Resulting Charges
Since the charge contracts between A and B, and between C and K involve metered
usage, the balances of the U (end-user), B, C, and K accounts are modified:
- U's balance was debited uB* meter units, to pay for the use of B (there was
no license for B, nor was there one for any of its ancestors up the chain to
U).
- B's balance was credited uB* units.
- C's balance was debited uK* meter units, to pay for the use of K (C had to
pay this itself, because A had a license for C, and so C could not ask A for
payment).
- K's account was credited uK* units.
THE ARCHITECTURE
This section provides an overview of the architecture supporting the main
activities of the resource model.
Three Activities
The resource management model involves three distinct activities and related
sets of objects:
- The Definition Activity. This activity creates and modifies resource
and license objects. This activity is described in detail in the Section on
"The Definition Activity".
- The Resource Acquisition and Charging Activity. This activity takes
place every time an application executes for an end-user. This activity is
described in detail in the Section on "The Resource Model".
- The Accounting Activity. This activity takes place periodically, both
at each installation and at the account agency site. This activity is described
in the Section on "The Accounting Activity".
The Definition Activity
Definition is the activity by which resources are defined, licenses are
installed, and meters (resource accounts) are filled with meter currency. While
the times and frequency of the resource definitions differ from those of
installing licenses and filling up meters, the notions are related and share
several common properties:
- They all involve interactions between a customer, using one or
more applications based on Kala's resource manager, and a vendor,
able to provide the customer with both the application and related licenses and
meter currency.
Note that by "vendor" we don't necessarily mean a vendor of software --
ultimately, it is not software that's being sold here. By vendor, we mean any
agency that has acquired the legal right to sell and administer licenses and
meter currency for various components and applications. This may be a software
distributor, a software manufacturer, an Independent Software Vendor (ISV), an
independent licensing and metering authority, or the manufacturers of the
resource management software itself.
- They all reflect cash transactions between the customer and the vendor. The
cash exchanges don't necessarily have to mimic the definition actions. However,
each such definition action is related to either a past, a concurrent, or a
future cash exchange between the vendor and the customer.
- As a consequence of the previous item, they all must be totally safe, thus
offering trusted protection against fraud. The Kala Resource Manager insures
this safety through a cookie exchange protocol described below.
The Cookie Exchange Protocol
The "Cookie Exchange Protocol" is a mechanism designed to insure the safe and
unforgeable definition of resources, installation of licenses and filling of
meters at the customer sites. The mechanism is based on the exchange of "magic
numbers" between vendors and customers. These magic numbers are also known as
cookies.
For each definition action, two cookies are involved:
a. The Customer Cookie. This cookie is generated by the customer on the
customer computer, and transmitted (either manually or mechanically) to the
vendor. The customer generates the customer cookie using the Cookie utility
program or a version of it embedded in the application itself. The customer
cookie encodes information that makes it unique, reflecting this particular
customer site (specifically, this particular Kala-based resource manager
instance). The customer cookie identifies the customer uniquely throughout the
subsequent activity.
b. The Vendor Cookie. This cookie is generated by the vendor in response to
a customer cookie and to information the vendor has about the associated cash
transaction (such as whether the customer's check cleared or the credit card
transaction went through). The vendor cookie encodes the originating customer
cookie, the vendor's identity, and the action to be performed on the basis of
customer payment. It is generated by the vendor, using a unique per-vendor copy
of the NewCookie program. It is passed back to the customer, who uses it to
perform the definition action.
The cookie exchange protocol is safe against fraud as long as:
- The vendor's NewCookie program is safeguarded by the vendor. Since the vendor
has material interests in preventing fraud, we assume that it will take good
precautionary measures to insure the program's safety (for example, installing
it only on a physically protected, standalone (un-networked) machine.
- The customer's site is able to generate customer cookies that uniquely
identify the site. Satisfaction of this requirement is guaranteed by the
mechanism Kala uses to guarantee universal uniqueness of identifiers [6].
- Valid cookies from NewCookie only work on sites which generated the original
customer cookie.
- Invalid cookies don't work at all.
Since the customer cookie is not useful to anyone other than the vendor who
generates a vendor cookie with it, and the vendor cookie is useful only to the
originator of the customer cookie the vendor cookie was generated from, cookies
can be transmitted safely over unsafe communication media, such as regular
electronic mail or voice telephone.
The application developer may embed the customer cookie generation in the
application itself, so it can benefit from the already existing Graphical User
Interface (GUI), communication facilities, etc. This is done by calling the
Kala Cookie API function, which returns a datum of type cookie. The datum can
then be either displayed to the end-user (for manual communication to the
vendor), or embedded into a message silently sent to the vendor via some
communication link (e.g., modem connection, electronic mail, etc.).
Defining Resources
The sub-activity of defining resources is part of the process of "installing"
the software on the customer's computer from the delivery medium (e.g.,
diskettes, tapes, network, CDs, etc.). A resource is defined in the Resource
Manager for each installed component.
To define a resource, the installation program calls DefineResource, a function
that is part of Kala's API. For example, the following defines the K in the
example resource graph in the Section on "The Resource Graph". This resource
has a resource identifier K, no sub-resources, and represents some given
component. The definition is controlled by a vendor-supplied magicNumber.
rid K = ...;
cookie magicNumberK = ...;
DefineResource (K, nilRow,
magicNumber, component, state);
The following code fragment defines the C resource in the same example in the
Section on "The Resource Graph":
rid C = ...;
cookie magicNumberC = ...;
DefineResource (C, Only (K, 1),
magicNumberC, componentC,
stateC);
Defining Charges and Acceptable Charges
Once a resource is defined, one can define the provisional charge the resource
would present to a potential grantee (another resource attempting to acquire
this resource) using the DefineProvisionalCharge function. For example, the
following defines the charge presented by the K resource defined above (see the
section on "Defining Resources"):
span uK = ...;
DefineProvisionalCharge (K,
Range (uK, maxInt),
magicNumberK);
Note that DefineProvisionalCharge (like DefineResource) is controlled by a
vendor cookie. The same is true for the next function,
DefineProvisionalAcceptableCharge.
This defines an acceptable charge that a grantee (using) resource can accept
when charged back by any of its sub-resources:
DefineProvisionalAcceptableCharge (
C, K, Range(uK, maxInt),
magicNumberC);
Installing Licenses and Refilling Meters
Finally, an application's code can install licenses or refill meters using two
additional Kala API functions: InstallLicense and RefillAccount. They both
require a vendor cookie to operate.
For example, the following installs 2 one-year licenses of resource C to
resource A:
rid A = ..., C = ...;
InstallLicense (A, C, 2, 365,
magicNumberC);
To refill U's account with 100,000 meter units, you call:
rid U = ...;
cookie magicNumberU = ...;
/* from meter vendor */
RefillAccount (U, 100000,
magicNumberU);
The Accounting Activity
The accounting activity has three parts; the first and the last take place at
the customer site, and the middle takes place at the accounting vendor's
site:
a. Balance Information Collection. This activity takes place periodically.
It consists of (i) summarizing the account balances (their magnitude, not the
actual units or money) for all resources defined at the customer site, and (ii)
communicating this data to the accounting vendor. The communication can be
either manual (via paper, removable magnetic media, etc.) or mechanized (via
modem and telephone lines, high-speed network, etc.).
b. Accounting. This activity takes place at the accounting vendor site. The
balance for each resource is merged with the corresponding accounts for the
same resource from other customers, and those with net positive balances
trigger cash payments to the corresponding vendors.
c. Balance Reinitialization. Upon successful delivery of balance summary
information (per step a. above), the balance of each resource account at the
customer site is brought to zero.
The Resource Acquisition and Charging Activity
This activity was described in detail in the Section on "Acquiring a Resource:
The Basic Algorithm". Here, we need only mention two Kala API functions called
in the process. The first is the function that starts the resource acquisition
activity: AcquireResource. This function is called by the application as part
of its initialization. For example, if the application's resource id is r, the
following call acquires the application component on behalf of the end-user:
p = AcquireResource (r,
ResourceOfClient (myCid), 1);
The call above makes use of the second relevant Kala API function:
ResourceOfClient. Given a client identifier (for example, myCid, the well known
wildcard identifier of the calling client process itself), ResourceOfClient
returns the resource identifier associated with that client.
If resource acquisition (and all sub-acquisition) was successful,
AcquireResource returns a pointer to the component associated with the acquired
resource. The Resource Manage automatically loads the component from the
persistent store. If the resource acquisition activity fails, the pointer is
nil. Because the components are kept on protected and inaccessible persistent
store by Kala, the application has no way to get at any of the components other
than through a successful AcquireResource.
COMMON BUSINESS MODELS
The resource management model and its implementation as part of the Kala
technology is useful in practice only as long as it is able to support useful
and desired business models. A good test is to explore its support for a few
simple ones in wide use.
While this section only explores a few simple models, many more can be
implemented atop Kala's resource management primitives, opening the doors to
creative business deals that are both mechanically and legally enforceable, and
inexpensive to administer.
Perpetual Floating Licensing
Contemporary software implemented on network computers commonly employs
perpetual floating license schemes. These schemes allow up to a specific number
of users to use the application concurrently. The number can be increased by
purchasing more licenses. Once purchased, a license never expires. If a site
has N licenses and the (N+1)[th] user attempts to access the
application, she gets a message informing her that the system is temporarily
out of licenses, and that she needs to wait until one of the current users logs
off this application.
Such a perpetual floating licensing scheme can be implemented trivially using
Kala's resource management mechanism. Perpetual licenses are implemented as
Kala licenses with infinite durations (represented as maxInt values). For each
application (or component) subject to such a licensing scheme, a resource will
be created as part of that application's (or component's) installation.
For example, let's assume an application that uses Kala to store its persistent
data. The application uses no other component that is subject to resource
management. The resource graph is shown in Figure 9. A is the resource
associated with the application, and K is the resource associated with
Kala itself, viewed as a software subassembly.
We assume that Kala's own installation (the coldKala program) installs the K
resource. The application's own installation program contains the following
code fragment:
rid A = ...;
mid midOfAnEntryPoint = ...;
DefineResource (A,
Only (Account(K,0)),
receivedCookie,
midOfAnEntryPoint, nilMid);
In the fragment above, midOfAnEntryPoint is the identifier of application A's
entry point segment, to be loaded into memory from the persistent store and
branched to for execution upon a successful acquisition of A's resource.
The application has a user interface (e.g., part of its GUI) that provides the
application administrator the means to:
- generate customer cookies to request additional floating licenses,
- add new (paid for) licenses, using vendor cookies, communicated either by
telephone (voice), or mechanically via some form of connection between the
application site and the vendor's site (e.g., modem connection over regular
phone lines), and
- inquire about the status of licenses and meters, such as how many licenses
are currently installed, etc.).
The application can run either with or without a license for Kala. In the
former case, no further exchange takes place between A and K. In the latter
case, the meter units consumed by application execution will be debited from
A's account and credited to K's account when application execution ceases.
A typical user site scenario is:
a. The application administrator (likely the same person who administers
networks, etc.) clicks on the application's menu item reading "Add another
license".
b. The application presents the administrator with a dialog box. The
application administrator fills out the quantity desired (defaulting to 1) and
the credit card number and expiration date (no default, for privacy reasons).
Then he clicks on the OK button.
c. The application silently sends electronic mail to the vendor, containing
the above information and a locally generated client cookie.
d. The vendor silently responds with a vendor cookie.
e. The application receives the electronic mail from the vendor and issues
a call to
DefineLicense (A, installation, 1,
forever, vendorCookieA);
to install the license to A.
f. If the agreement between A's vendor and Kala's vendor specified that
each sale of a license for A will also include a sale of a license for Kala
(one of the many possible arrangements), then a license to Kala is also
installed:
DefineLicense (K, A, 1, forever,
vendorCookieK);
Note that a perfectly valid alternative is to assume that licenses for Kala are
obtained through a completely separate channel. For example, Kala may already
be installed on that network computer in support of other applications, and
blanket licenses (that is, licenses to Kala for anyone who needs them) may
already exist.
g. The application sends e-mail to the application administrator, notifying
him that the license(s) have been successfully installed.
There are many variations and extensions of the perpetual floating license
scheme, both with respect to what is being licensed and to how the licenses are
administered. The example above suggests a more mechanized, transparent and
easy-to-use approach, involving a minimum amount of effort on the customer's
side and a minimum amount of labor on the vendor's side. Indeed, a win-win
situation.
Flat Annual Royalty Arrangements
Another commonly practiced licensing scheme is that of a flat annual royalty.
In this scheme, if an application A uses a component B, A's vendor obtains the
permission to dispense an unlimited number of licenses to B in return for a
flat annual fee. Other legal limitations may occur, and some may be enforceable
through software. However, we will ignore them here for simplicity. We also
assume that A's vendor sells its application under a perpetual license
agreement.
When A's vendor pays B's vendor the agreed-upon annual fee, B's vendor gives
A's vendor a NewCookie module that generates cookies for 1-year licenses from B
to A. A's vendor delivers the B upgrade module to its own customers as part of
an annual upgrade of the A application. The B upgrade module silently installs
up-to-date licenses to B, so A's customers can continue to use the embedded B
without charge (they may actually not be even aware of the existence of B!).
This scheme assumes an explicit module upgrade. While these upgrades of B-to-A
licenses are not relevant to A's customers, they can be hidden inside other
kinds of upgrades of A, such as annual A software releases, etc.
If the customer does not install the upgrade, A will continue to run even
though the local (sub)license from B to A has expired, so long as the B
component was written to fall back to pay-per-use. Absent a license, B will run
off a meter so long as the end-user's resource accepts the provisional and
actual charges. This inconvenience can be avoided by providing the customer
with strong enough incentives to upgrade.
If A's vendor (who has sold perpetual licenses to its customers) fails to buy
and deliver to its customer the necessary B module upgrade (so that the
customer can use B as part of A without charge), then the customer has the same
legal complaint against A as for any other failure to deliver contracted
upgrades. This presents an incentive to A's vendor to provide the necessary
upgrades.
As in the example in Section on "Perpetual Floating Licensing", the process can
be made quite smooth by employing silent transfer mechanisms such as electronic
mail or direct connect via modems over phone lines. Since most sites
(organizational and residential) are now equipped with such devices, and since
the amount of data to be transferred is fairly modest, these options are now
more practical than ever.
Metered Use of Kala as a Repository
Another simple application occurs where passive objects are provided under a
metered arrangement. For example, a vendor of clip art may place an entire clip
art collection on a Kala-managed CD-ROM (see [7],[8] for more information on
Kala's persistent store functionality).
The vendor distributes the collection for no or low cost (perhaps enough to
cover manufacturing costs in part). The arrangement is that each clip is paid
for on a usage basis: a small amount is charged every time a drawing program
loads a clip and inserts it into a drawing.
The drawing program is implemented so that it cannot be used to make any
further copies of the clip. Kala's Resource Manager doesn't really enforce this
if the clip is to be truly passive, i.e. usable by a lot of applications. The
application must have an internal (memory) representation for the art clip, and
Kala has no means to prevent the application from writing out the internal
representation and reusing it. Here, the actual protection comes from the fact
that commercial drawing package developers will have no incentive to allow such
loopholes -- it is in their best interest to protect the economic interest of
clip artists, so that they can continue to supply them with high quality clip
art.
An individual programmer may find ways to break this protection; however, if
the cost of clips is low enough, it would be too much trouble for what it was
worth. Pricing strategy plays an important role here. The vendor of a clip art
library should price the product such that if every clip was referenced once,
the total meter credit would be more than what he would sell an unlimited
license for anyway.
In the implementation, Kala holds clips as persistent data. Access to these
clips is securely controlled using Kala's data visibility functionality.
Drawings using these clips can also be held as Kala data.
Each clip has a resource object associated with it. Each "handle" to a clip is
set up to acquire the clip's associated resource. The model supports embedded
clips as well.
The end-user (or the site, if accounting is on a site basis) periodically fills
up his account with some quantity of meter currency. The end-user resource
accepts charges as long as its account balance is positive.[6]
When a clip needs to be loaded into a drawing, if the proposed charge is
accepted by the end-user resource, the actual charge is credited to the clip's
resource account. Periodically (for example, on a quarterly basis or when the
customer purchases more meter currency), the accumulated accounting information
is sent to the vendor.
Clip art may be supplied by many artists. The clip art vendor can, using the
detailed accounting data received from the customer, distribute the
proportional revenues to the clip artists. Thus, the small but highly skilled
contributor can get actual revenue from his or her work, without placing an
excessive burden on the revenue collection system -- a simple accounting
computation. The underlying mechanism is very similar to the one ASCAP uses to
convey a portion of each coin in a jukebox to the author of the song
played.
Free (Unlicensed) Use
A degenerated use of the model occurs when a component is offered for free use
to anyone who needs it. In this case, the code fragment that installs such a
"nil license" for a resource X is:
DefineLicense (X, anyone, maxInt,
forever, aCookie);
Here, a virtually unlimited number of users can use component X
indefinitely.
SUMMARY OF THE API
This section summarizes Kala's resource management interface. The interface
(API) is shown as C function declarations, although other language interfaces
will be supported.
Resources, Relationships and Accounts
DefineResource defines a resource and its "use" relationship to a suite of
other resources, expressed as a row of resource. It associates a resource with
a component.
void
DefineResource (rid resource,
rowRid subResource,
cookie magicNumber,
mid component,
mid state);
InstallLicense defines one or more pay-per-user (license) relationships
between a grantor resource and a grantee resource, based on a cash payment. The
license is for a given number of seats, and has a given time validity, measured
in days.
void
InstallLicense (rid grantor,
rid grantee,
span seats,
duration validity,
cookie magicNumber);
RefillAccount credits a resource's account with a given number of meter
units, based on a cash payment.
void
RefillAccount (rid resource,
span units,
cookie magicNumber);
Provisional and Actual Charges
DefineProvisionalCharge states that a resource can allow access to its
associated component (see DefineResource in the Section on "Resources,
Relationships and Accounts") in return for an expected charge. A provisional
charge is defined to be a range, indicating a minimum and a maximum (see the
Section on "Resources and Sub-resources").
void
DefineProvisionalCharge
(rid grantor,
rid grantee,
urange charge,
cookie magicNumber);
DefineAcceptableProvisionalCharge states that a grantee resource is willing
to accept an indicated provisional charge.
void
DefineAcceptableProvisionalCharge
(rid grantor,
rid grantee,
urange charge,
cookie magicNumber);
Charge allows a grantor resource to present a grantee resource with a given
actual charge, measured in meter units.
void
Charge (rid grantor,
rid grantee,
span units);
AcceptCharge allows a grantee resource to accept an actual charge from a
grantor resource. The accepted actual charge is given as a min/max urange
(range of unsigned integers), so that the match does not have to be exact.
void
AcceptCharge (rid grantor,
rid grantee,
urange charge);
Acquiring Resources
AcquireResource acquires a resource for a potential grantee resource (the
caller of this function). If successful, it secures access to the resource's
component for the grantee's component. It can acquire the resource a quantity
number of times. If successful, it returns a pointer to the grantor component,
now in memory.
pointer
AcquireResource (rid resource,
rid grantee,
span quantity);
ResourceOfClient returns a client's associated resource, expressed by its
identifier (rid). The client is identified by its client unique identifier
(cid).
rid
ResourceOfClient (cid client);
Cookies
Cookie generates a new local installation cookie, to be passed to the
vendor, along with some request and cash payment.
cookie
Cookie (void);
Accounting
CreateAccountingSummary computes the summary of accounts in an internal
format and uses Kala facilities to create a new Kala persistent datum to hold
the summary. The newly created datum is pointed to by a Kala handle located at
<kin, basket>, using usual Kala addressing [7]. The resulting datum can
thereafter be copied to a file, sent to the vendor site via electronic mail, or
moved between Kala installations using regular Kala facilities.
mid
CreateAccountingSummary(kid kin,
bid basket);
CONCLUSIONS
In the Section on "Revenue Collection" we outlined a few requirements for a
practical revenue collection mechanism independent of the software distribution
mechanism. To conclude this brief overview of Kala's resource management
functionality, we are reviewing how Kala meets these requirements.
a. Be safe. Kala meets this requirement by a combination of several
factors: (i) the resource model requires components to be accessible
only via their resource objects; (ii) Kala provides a secure storage of
data, whereby applications have full control over who can see what and when,
via the data visibility primitives (see [7] for a complete discussion of Kala's
main data visibility mechanism, the Kala Basket); and (iii) the dual cookie
device permits rights to be communicated between vendors and customers without
the need for expensive or cumbersome communication safety provisions.
b. Be recursive. Kala's resource management model meets this requirement by
recognizing that, with respect to licensing or metering, arbitrary components
are no different from applications which are no different from passive data.
The model explicitly calls for resource graphs.
c. Be flexible. Kala's model does not impose any policies. It imposes no
practical restrictions on how the business deal is structured, how the licenses
or the meters are administered, what mechanism is used to communicate between
vendors and customers, etc. As long as a policy does not violate the other
requirements discussed here (for example, the safety requirement), it is
implementable using Kala's resource management primitives. This feature sharply
distinguishes Kala from all other license managers (commercial or research).
The immediate effect is simplicity and interface economy.
d. Be efficient. Kala's model was designed to minimize the number of
communications between the application/component code and the resource manager.
The result is an implementation that brings very little overhead, unnoticeable
in practice.
e. Be invisible. Kala's toolkit approach makes it possible to fully
integrate all license and meter management with the application (and under some
schemes even hide them inside).
f. Provide Dual Techniques. Kala provides support for both the
"pay-per-user" and "pay-per-use" approaches, and does so by linking them
together, so that "pay-per-use" becomes the default in the absence of available
licenses.
A restricted version of this model has been part of the Kala persistent data
server product since its 2.2a version. This model is part of Kala's 3.x
version. Extensions to it are also expected.
NOTES
1. Kala is a Trademark of Penobscot Development Corporation. Portions of the
technology described herein are covered by pending US and international
patents.
2. Many have pointed out that there is more software and information being used
without payment than there is legitimate use.
3. We are, however, encouraging everyone to explore these topics and devise
ways to overcome these serious barriers.
4. Application definition with respect to the component repository, i.e., at
application installation.
5. This restriction can be relaxed in the case of a dynamic resource graph.
6. It is possible to allow account balances to become negative. This
corresponds to extending some amount of credit to a customer, much as a charge
account bank would do.
BIBLIOGRAPHY
[1] Cox, Brad, What if There Is A Silver Bullet, Journal of Object
Oriented Programming, June 1992.
[2] Hemnes, Thomas M.S., Esq., Software Revenue Generation in Network
Environments, Ropes and Gray, Massachusetts Computer Software Council
Annual Legal Update Program, November 1992.
[3] Miller, Mark, On Software Pay-Per-Use, private conversations, June
1992 and January 1993.
[4] Mori, Ryoichi and Maraji Kawahara, Superdistribution: An Overview and
The Current Status, Technical Reports of the Institute of Electronics,
Information, and Communication Engineers, Volume 89, Number 44.
[5] Penobscot Development Corporation, The Kala Archives, available via
anonymous ftp from world.std.com at ~ftp/pub/kala. Send mail to
kala-request@world.std.com for more information.
[6] Penobscot Development Corporation, The Kala Forum, by free on-line
subscription only. Send requests to kala-request@world.std.com.
[7] Simmel, Sergiu S. and Ivan Godard, The Kala Basket -- A Semantic
Primitive Unifying Object Transactions, Access Control, Versions, and
Configurations, Proceedings of OOPSLA'91, October 1991, pp. 240-261.
[8] Simmel, Sergiu S. and Ivan Godard, Objects of Substance, BYTE,
December 1992, Volume 14, Number 17, pp. 167-170.
[9] Simmel, Sergiu, Software Licensing and Metering with Kala --
Infrastructure for a New Economics of Software, Hotline on Object-Oriented
Technology, Volume 3, Number 4, pp. 3-7.
GLOSSARY OF TERMS
account -- constituent of a resource, holding a balance of meter units
actual charge -- the amount of meter units a grantor resource asks a
grantee resource to pay for its actual use of the grantor's services during an
execution
actual acceptable charge -- he amount of meter units a grantee resource
expects or is willing to be charged by a grantor resource for its actual use of
the grantor's services during an execution
component -- small-grain constituent of a software system
customer cookie -- magic number generated by the customer on the customer
computer, and transmitted (either manually or mechanically) to the vendor
definition -- activity by which resources are defined, licenses are
installed, and meters (resource accounts) are filled with meter currency
distribution -- mechanism by which a component is made available to another
component or final consumer (end-user)
end-user -- real person (based on whatever the local system uses for user
identifier), budget pseudo-people, or an installation as a whole if finer grain
accounting is not required
license -- deal between a grantee resource M and a grantor resource N
whereby N grants to M's component access to N's component for a certain period
of time, in return for a pre-negotiated license fee
license fee -- monetary exchange between the vendors that own the two
resources M and N, or between an end-user represented by resource M and the
vendor that owns resource N
license duration -- time for which a license exists
licensing -- see pay-per-user
meter units -- currency in which all transactions between resources take
place
metering -- see pay-per-use
pay-per-use -- arrangement whereby the consumer pays the producer for as
much of the producer's software as the consumer's software actually uses
pay-per-user -- arrangement whereby the consumer's software is permitted to
use the producer's software for a fixed period of time in return for a fixed
fee, independent of whether or how much the consumer's software actually uses
the producer's software
provisional charge -- a formulation of the amount of meter units a grantor
resource may charge if the resource is used
provisional acceptable charge -- a formulation of the amount of meter units
a resource M would accept to be charged for the use of another resource N
resource -- abstraction representing access to a software component
resource accounts conversion -- activity of summarizing the balances of all
resources in a Resource Manager installation, communicating the summary to the
agency that does the conversion (the equivalent of the bank), paying the
corresponding vendors the equivalent amounts of cash, and finally resetting the
paid accounts to zero, ready for the next cycle
revenue collection -- mechanism by which payment for a component is made to
reach the producing vendor, regardless of the context in which the component is
actually used
resource graph -- the graph of resources related by the user relationship,
with the application's resource as the entry node (root)
rid -- resource identifier
subassembly -- medium-grain constituent of a software system
vendor -- manufacturer of a component, an agent for the manufacturer, or
anyone who has acquired the legal right to sell access to a component
vendor cookie -- magic number generated by the vendor in response to a
customer cookie and to information the vendor has about the associated cash
transaction (such as whether the customer's check cleared or the credit card
transaction went through)
BIOGRAPHY
Sergiu S. Simmel, President and Co-Founder of Penobscot Development
Corporation, has been involved in the KALA project since 1987. He holds a
Master's Degree in Computer and Information Sciences from University of
Minnesota. He has been working in the computer industry as a software engineer
and technical manager since 1981. His areas of expertise include CASE systems,
hypermedia document management, and object oriented databases.
Ivan Godard, Chief Technologist, is Kala's main designer and implementor, being
the main force of the KALA project throughout. Mr. Godard has been involved in
the computing industry since 1968 as a scientist, engineer, consultant, and
entrepreneur. He contributed to the Aldo168 Revised Report and the design of
the Ada Language (the "green" version). His areas of expertise include language
design, translation technologies, and object oriented databases. Mr. Godard has
taught computer science at graduate and post-graduate level at several
universities including Carnegie-Mellon University and University of Maine.
The authors can be reached at:
Penobscot Development Corporation
One Kendall Square, Building 200, Suite 2200
Cambridge, MA 02139-1564
voice: (617) 267-KALA
fax: (617) 859-9597
Internet: infor@Kala.com
Copyright (c) 1993, Penobscot Development Corporation
