------- Forwarded Message
Return-Path: XoTGhiway-request@xopen.xopen.co.uk
Return-Path: <XoTGhiway-request@xopen.xopen.co.uk>
Received: from www10.w3.org ([18.23.0.20]) by beach.w3.org
with smtp id <m0tulN0-0002U5C@beach.w3.org>
(Debian /\oo/\ Smail3.1.29.1 #29.33); Thu, 7 Mar 96 14:29 EST
Received: from xopen.xopen.co.uk by www10.w3.org (5.0/NSCS-1.0S)
id AA23664; Thu, 7 Mar 1996 14:28:52 +0500
Received: by xopen.xopen.co.uk; id AA08463; Thu, 7 Mar 1996 19:24:28 GMT
Message-Id: <9603071924.AA08463@xopen.xopen.co.uk>
Received: from WINVMD by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4666;
Thu, 07 Mar 96 14:22:09 EST
Date: Thu, 7 Mar 96 19:23:40 GMT
From: jmcarter@vnet.ibm.com
To: XOTGHIWAY@xopen.co.uk
Subject: (XoTGhiway 48) Transactionality and the Web
Sender: XoTGhiway-request@xopen.co.uk
Comments: (XoTGhiway 48)
content-length: 36936
Transactionality and the World Wide Web
=======================================
Copyright Notice
- ----------------
Please note that some of the material in this paper appeared recently in
an article written by myself and published in MIDDLEWARESpectra (Volume
10 Report 1 - February 1996). Accordingly those parts are subject to
copyright. However there is no problem with using this as a discussion
document or using it as a basis for presentations.
.* Overview of this paper
.* ----------------------
.*
.* 1. Introduction
.*
.* 2. The Model for a World Wide Web Application
.* Browsers (Clients, plus Agents) and Servers
.* Services (e.g. Directory, Security, Data Conversion, Management)
.* The Top Plane and the Lower Plane(s)
.*
.* 3. What are the Features of Transactionality
.* ACID Properties
.* Synchronism (co-ordination and tightly coupled processes)
.* Examples (in outline description only):
.* a. Funds transfer (a case of data base coherency)
.* b. Calendar commitment (another case of data base coherency)
.* c. Travel agent (service co-ordination)
.*
.* 4. Influences on Transactionality
.* Spasmodic Network and Process Operation by Choice
.* Mobile Devices (including Smart Cards)
.* Availability of Multiple Equivalent Servers
.* The Internet and the World Wide Web
.* Object Oriented Technology
.* Network Performance (Bandwidth) and Reliability
.* Business value
.* Low value and/or low complexity (negotiated commitment)
.*
.* 5. "Tightly Coupled" (Synchronous) and "Loosely Coupled"
.* (Asynchronous) Transaction Processing
.* Achieving Transactionality with Loosely Coupled Processes
.* Example:
.* a. Funds transfer
.* b. Calendar (with a twist)
.* Compensation
.* The ACID properties using the Asynchronous Approach
.* Summary of the asynchronous approach
.* Dependency on the local co-ordinator
.*
.* 6. Co-existence with today's methods (migration considerations)
.*
.* 7. Applicability of Transactioanlity to the World Wide Web
.* Electronic Commerce
.* New Applications
.* Extending and Coalescing Existing Applications
.* a. Calendar plus travel agent service
.*
.* 8. Establishing the Requirements for Transactionality in the World
.* Wide Web
.*
.* 9. Conclusion
Introduction
- ------------
The World Wide Web is, or rather has become, a phenomenon. Many are
asking how should it be used in their business and have realised that
they cannot, or dare not, ignore it as a result of the possibilities for
new business opportunities that it offers.
At the very least, it is known very widely and is accessible to a vast,
and rapidly growing, section of the world's population. In this respect
alone it necessitates the attention of anyone wanting to heighten the
awareness of the consumer to the products or services he or she can
supply. This does not just apply to sales and service businesses; even
individuals are advertising their skills to obtain positions in the job
market through placing their Curriculum Vitae into pages on the Web.
In the beginning the Web has been used mainly for the display of
information. This has now evolved, and will continue to evolve, into
more sophisticated use, such as placing orders, and later, the secure
exchange of contracts backed by the full weight of (international) law.
Naturally, if this is to be conducted electronically, it will imply an
infrastructure of software facilities in order to support the
requirements of the software components which comprise the capabilities
offered to the end users (the clients). Just possibly a Transactional
Service is a component of the required infrastructure.
The Model for a World Wide Web Application
- ------------------------------------------
In order to understand the potential role of a Transactional Service
within the software infrastructure of the World Wide Web, it is
necessary first to describe the model, in high-level terms, that enables
an application to be constructed and to operate.
Basically, from a software only point of view, there are three types of
component, namely Browsers, Servers and Services.
Browsers: represent the "real" clients, namely the human users.
Essentially they are the presentation interface between that
human and the application. However, these are not simple
input and output procedures, but very sophisticated programs
with many features, for example, the ability to remember
previous pages which have been viewed. Browsers interpret the
data from its specification form, namely, the HTML (HyperText
Mark-up Language), which has been standardised primarily under
the auspices of the W3C (World Wide Web Consortium). Also
Browsers capture the input from the user for the information
of a server, not necessarily the one which supplied the
presentation on which the human has just acted.
Browsers will retain that role and probably not be extended
themselves to provide facilities not directly related to the
task of handling the user interaction. However, they do
provide a specialised execution environment (JAVA), which
permits the server to provide its own programmability within
the browser. In this way, the browser functionality will be
extended. Alternatively, browsers will be integrated with
specialised agents which will provide additional facilities to
the user.
Servers: are the providers of the information to the users. They are
the applications with which those users interact. In general
the interactions are "stateless", that is, a server does not
maintain a "session" with the client in which it remembers the
previous interactions of its user. However, by appropriate
programming in the server, related interactions with a user
can be associated.
Services: are specialised servers, which provide particular services,
either directly to the users (by way of the browser) or to the
other servers. For example, they may offer Directory services
or Security services or Data Conversion services or System
Management services.
Accordingly, the Web can be considered to be a network of servers and
services, with the browsers at its boundary. The browsers, servers and
services are distributed through the network and these components
communicate by use of the HyperText Transfer Protocol (HTTP).
Diagrammatically:
-- --
/---------/B/-----------------/B/--------/
/ -- ---- -- /
/ ---- /Svc/ --/
/ /Svc/ ---- ---- /B/
/ ---- /Svr/ /--
--/ ---- ---- /
/B/ /Svr/ ---- --/ --
/-- ---- /Svr/ /B/ /B/ = Browser
/ -- -- ---- /-- --
/----/B/--------------------/B/----------/ ----
-- -- /Svr/ = Server
----
----
/Svc/ = Service
----
This can be considered to be a Surface or Top Plane when representing
application programming in the World Wide Web. However because servers
do communicate with one another privately (and using other transfer
protocols) outside the domain of the Web, the above (intended to be
three dimensional) diagram should contain Lower Planes of communication:
-- --
/---------/B/-----------------/B/--------/
/ -- ---- -- /
/ ---- /Svc/ --/
/ /Svc/ ---- ---- /B/
/ ---- /Svr/ /--
--/ ---- ---- /----------/
/B/ /Svr/ ---- --/ /
/-- --V- /Svr/ /B/ /
/ -- V -- --V- /-- /
/----/B/-------------V------/B/----V-----/ /
-- / -V-- -- V /
/ /Svr/<========>-V-- /
/ ---- /Svr/ /
/ ---- /
/----------------------------------------/
What are the Features of Transactionality
- -----------------------------------------
The ACID properties which characterise a classical transaction are:
* Atomicity: the results of the transaction are either all
committed or are all rolled back
* Consistency: a transaction transforms a shared resource from one
valid state to another valid state
* Isolation: any change to a shared resource by one transaction is
not visible outside that transaction until the
transaction commits
* Durability: the changes that result from the commitment of a
transaction survive subsequent system or media
failures
Honouring these properties enables reliable business processes to be
implemented by software applications. However, it does imply the
simultaneous availability of all the parties involved in making the
commitment. Such synchronism entails a very "tight coupling" between
the co-operating partners. Applied to an environment of distributed
processing, it entails that the necessary part of the network and the
participating processes are all operational at the same time.
Probably the most well known example of transactionality is the transfer
of money from one bank account (actually just a data base) to another
bank account (similarly just another data base). A variant of this is
when two individuals "commit" a meeting to their separate diaries.
These two are cases of ensuring the coherence of independent data
bases, and is one aspect of the atomicity property of transactionality
(that is, both data bases are updated or neither data base is updated).
A third less well, but now often quoted, example is the travel agent
scenario, in which an individual is endeavouring to make reservations
for an airline flight, a hotel, and a car. Clearly these are related
activities, since the customer probably does want the hotel or the car
at a location near to the destination of the flight. This is another
aspect of the atomicity property of transactionality, namely service
co-ordination (that is, it all must occur or none of it must occur).
These examples will re-occur throughout this paper, in order to
illustrate how the atomicity property of transactionality, in its guises
of service co-ordination and coherence of autonomous data bases, is
applicable to application programming in the World Wide Web.
Influences on Transactionality
- ------------------------------
There are trends which are likely to influence the classical view of
transactionality. These include:
* Spasmodic Network and Process Operation by Choice
* Mobile Devices (including "smart cards")
* Availability of Multiple Equivalent Servers
* The Internet and the World Wide Web
* Object Oriented Technology
* Network Performance (Bandwidth) and Reliability
The above are described in the Appendix. In addition to the above,
there is another significant influence, namely the business value of the
transaction. Clearly, if the transaction involves the transfer of a
large sum of money (for which even the instantaneous accrual of interest
is sufficiently significant), then that sum of money must be
attributable to a known party at all times, which is equivalent to a
synchronisation of the debit and the credit operations. Alternatively,
consider the interaction of two individuals endeavouring to establish a
mutually convenient time for a meeting. This is logically equivalent to
updating their individual data bases (their diaries), and therefore is a
case of a normal transaction. However, this is not likely to be of
significant business value, so the mutually agreed meeting time is
achieved by the initiator sending a note to the other party, who
subsequently notes it in his or her diary if convenient, or, if it is
not convenient, replies to the initiator with alternatives times. This
procedure is repeated by each party in turn until some mutually
acceptable arrangement is agreed (including the possibility of
cancelling the proposed appointment). In this way a "negotiated
commitment" is achieved, and surely is appropriate for business
exchanges which are low in value or which are sufficiently simple that
the recovery of the inevitable failure will not be excrutiatingly
complicated.
In summary, the above influences on transactionality are leading to a
design style for the overall application by utilising a number of
"loosely coupled" components, which have a considerable degree of
independence from one another, and indeed the components may well be
operated asynchronously. This seems an approach which is particularly
appropriate for applications within the World Wide Web.
"Tightly Coupled" (Synchronous) and "Loosely Coupled" (Asynchronous)
- --------------------------------------------------------------------
Transaction Processing
- ----------------------
Models for "Tightly Coupled" Distributed Transaction Processing have
been widely debated and documented. Can transactionality, or rather
the appropriate features of it, be achieved by way of "Loosely
Coupled" processes, which are operating in a asynchronous manner?
Consider the example of the transfer of money from one bank account to
another, where the two accounts are maintained on different systems.
Assuming that the cheque is presented at the bank where the account to
be credited is located, and that the processes of the two banks are
asynchronous and are honourable (by design) to one another, the simplest
error free case of the separate processes would be:
-----------------------------
ICrediting Bank (Credit)I
I---------------------------I
I I
IBegin Transaction I
Deposit I I
- ------->IReceive credit payment I
I I
IIncrement local account I -----------------------------
I I IDebiting Bank (Debit)I
ISend debit request to I I---------------------------I
Iremote bank I--- I I
I I I IBegin Transaction I
IEnd Transaction I I I I
I I -->IReceive debit request I
----------------------------- I I
IFunds available in account?I
I I
IYes (Commit) I
I Decrement local account I
----------------------------- I I
ICrediting Bank (Correct)I INo (Rollback) I
I---------------------------I I Send rejection note to I
I I ---I crediting bank I
IBegin Transaction I I I I
I I I IEnd Transcation I
IReceive rejection note I<-- I I
I I -----------------------------
IDecrement local account I
I I
IAccount overdrawn? I
I I
IYes I
I Initiate local bank I
I overdrawn procedure I
I I
IEnd Transaction I
I I
-----------------------------
This is a simplified example, but it enables one to observe that what
would have been a single distributed transaction with a "commit" and a
"rollback" branch has now become two time independent non-distributed
transactions in the case of the "commit", and three non-distributed
transactions in the "rollback" case, the last process being the
"compensating" transaction for the business logic failure in the
debiting transaction.
Observe also that each process requires transactional capability, but
only within its local system. This ensures that the data in the
request that initiates each process is not lost, if the process itself
does not complete; and also enables the data "sending" actions to be
co-ordinated atomically with other updating activity in that process,
for example, the "crediting" action of the first process.
By extension of the above and with analysis of the overall application,
it is possible to design and build very elaborate structures of
co-operating processes. Since these processes can be arranged to
operate in parallel as well as serially, it is possible to envisage
many topologies for the structure of the participating components.
In the asynchronous approach, each process assumes that the next process
will be available eventually and that it can be trusted to discharge its
responsibility with respect to the overall application. However, there
will be situations in which one process needs some feedback regarding
the status of the related work undertaken by subsequent processes, not
necessarily just that of the next one.
For example, and extending the financial scenario above, suppose that
the credit was for a large amount (above some bank defined limit), then
the crediting bank might choose to inhibit any debits for large amounts
against that account until it was certain the funds were cleared from
the debited account. The crediting bank is "in-doubt" regarding the
financial status of that account, so it would send a "debit with
acknowledgement" request to the debiting bank and mark the account as
"in-doubt" until it can act on the acknowledgement. Note that these
processes are still asynchronous with respect to one another, the
initiating credit process can still complete, the debiting (with
acknowledgement) process still operates subsequently and independently,
and there will be some further process in the crediting bank to remove
the "in-doubt" status against that account (this may require application
defined mechanisms such as use counts and transaction identities, if it
is necessary to allow for multiple occurrences of this situation).
This illustrates the principle of "signalling" between the asynchronous
portions of the application. Obviously, such signals can be generated
at any appropriate stage of the structure of processes and targetted to
any particular previous process so as to allow it to resolve any
"in-doubt" condition. In general, there will be natural co-ordination
points in any structure of processes and it is likely that these can be
used as the "checkpoints" to enable the processes which comprise the
application to achieve a universally accepted state. Such co-ordination
points within the structure of processes allow an application to be
viewed as a sequence of stages; each stage containing some group of
processes co-operating by acting in series and/or parallel. To some
extent, each stage represents a sort of unit-of-work.
The calendar scenario can be programmed in the same asynchronous style.
Suppose that someone wants a meeting with me (yes, it does actually
happen!). The requester selects a time convenient for him or her (for
the purpose of this example without reference to my diary) and sends me
a note containing the meeting request. I look in my diary to see if I
can accommodate the request. If so, I can commit my time (for the
purpose of this example without sending an acknowledgement). In this
way the requester and I have both committed the update to our diaries
with only one communication flow. However, if it had been inconvenient
for me, I would have to send a note to the requester to initiate some
rearrangement. This negotiation would continue until a satisfactory
agreement was achieved; this would be the compensating activity as a
result of my inability to commit the initial request.
-------------------------------- --------------------------------
I Diary:Requester 11 Mar 96 I I Diary:John Carter 11 Mar 96 I
I------------------------------I I------------------------------I
I I I I
I 09:00-09:30 See manager I I 09:00-10:00 Meeting I
I 11:00-12:00 Presentation I I 11:00-12:30 Attend lecture I
I 12:00-13:00 Lunch I I 12:30-13:30 Lunch I
I 13:00-18:00 Vacation (Golf) I I 13:30-18:00 Discussion groupI
I I I I
-------------------------------- --------------------------------
So the meeting request for 10:00 (for 60 mins) looks quite achievable.
But what was I doing on the previous day?
--------------------------------
I Diary:John Carter 10 Mar 96 I
I------------------------------I
I I
I 09:00-18:00 Travel to San I
I Francisco I
I I
I I
I I
--------------------------------
So, it is not quite as straightforward as it first seemed, because the
requester and I are probably not in the same country, let alone in the
same time zone!
The point of this example is that reference simply to my data base for
the chosen day would not have led to committing the meeting time. I
have kept my diary relative to my time for my convenience; more context
is necessary in order to achieve the result. Obviously, I would have
to provide that to the requester, as part of the compensating
negotiation.
This example illustrates that compensation should not be seen simply as
a recovery procedure. Really it has a more forward looking and
progressive role. It is the mechanism by which a new decision on how to
proceed is being formed as a consequence of new information. In very
complex or business significant situations, compensation will probably
ultimately require some authoritative human involvement; when this will
occur is a matter of the level of sophistication that is justifiable in
the programming of the compensation procedure.
How are the ACID properties affected when the transactions are
programmed in the asynchronous style?
In the asynchronous model, the application is composed of many
inter-related transactions, which must be programmed to provide the
adherence to the conventions required by the business. Provided the
implications of using an asynchronous approach is understood and the
processes are programmed to allow for it, much of the capability
associated with "classical" transaction processing can still be
achieved.
* Consistency and Durability are unaffected.
* Atomicity is delivered locally (although the processes themselves
must play their part to achieve any greater global level of this
property).
* Isolation is also achieved locally, but is not achieved between
time independent processes, because the data can be viewed in an
incoherent state. However this is the same situation as when a
heuristic decision has been taken in the "classical" model.
This has been a deliberately long digression on the topic of achieving
transactionality by the use of loosely coupled processes. The pertinent
points are that:
* the properties of "classical" transactionality can still be
satisfactorily achieved,
* the asynchronous approach depends on a local co-ordinator to ensure
the atomicity of local action, and in particular the atomic
co-ordination of the transmission of data (both input and output)
with the other local activity,
* atomicity is just as much about such co-ordination of multiple
actions as it is about "two-phase commitment", and
* compensating activity is not simply about recovery from failure.
It is worth noting that the asynchronous approach might represent a
reduction in network load, since it is possible that the communication
between two co-operating components might be limited to a single round
(or better still a single uni-directional) flow. With higher network
reliability, it becomes statistically probable that there is benefit (at
least from the viewpoint of the network) to assume that any transmitted
data will be delivered and what is more will be satisfactorily processed
by the recipient.
The loosely coupled style offers benefits to the operation of the
network and the processes located in it, because each process makes no
assumption about when the next process will perform its part of the
activity, and therefore not all the network or its processes need be
operational.
Co-existence with today's methods
- ---------------------------------
The business methods in existence today represent a substantial
investment, both in development resource of that business and in the
embodiment of its procedures (probably gained from experience).
Accordingly, it is not likely to be prudent for any business to alter
its computing procedures in any revolutionary manner. A business is
likely to continue to operate its existing applications, and only change
them incrementally.
Any association with the World Wide Web will probably be achieved by
use of a bridge or an adapter between the methods appropriate in the
domain of the World Wide Web to those that the business currently has in
place.
Applicability of Transactionality to the World Wide Web
- -------------------------------------------------------
If applications in the World Wide Web are achieved by suites of
co-operating loosely coupled processes, then the discussion of
asynchronous transaction processing will be pertinent.
Electronic commerce is becoming (has become) a widespread application,
essentially in a "mail order by way of a credit card" style, so that
the financial aspects are conducted as a background operation, just as
might happen with a telephone call to order a product. This does not
involve transactionality in the World Wide Web based portion of the
application; although arguably there might be cases for some level of
guaranteed commitment between the purchaser and the supplier, as would
be embodied in a transaction. Note that the security of the data
transfered between the purchaser and the supplier is an important, but
orthogonal requirement to the guarantee implied by the transaction
conducted by the business exchange.
It is difficult to predict what facilities will be needed by completely
new applications, developed to operate in the World Wide Web. Some may
demand a service to co-ordinate activity activity across their
distributed parts. However, these may well be a minority.
New applications may well be developed by coalescing, in some way,
existing applications. For example, it may be worthwhile to offer an
application which combines a calendar and a travel agent service, so
that a meeting can be arranged at a mutually convenient time and place
and that the participants can ensure being able to arrive at the chosen
venue. Such conglomerates will probably need a transactional service.
Establishing the Requirements for Transactionality in the World Wide Web
- ------------------------------------------------------------------------
Obviously the businesses will determine the most appropriate use of the
World Wide Web for their purpose. From that will emerge the needs for
services. One might well envisage a requirement for a transactional
service, to provide the tight coupling between distributed World Wide
Web based applications. One might also envisage a need for a more local
level of transactionality, to enable the atomic co-ordination of actions
within a single component of a World Wide Web based application. This
latter will almost certainly require some involvement of the HTTP
communication, because it will be necessary for the transfer of data
to be committed to the network if some other update to a resource is
also committed.
There may well be other needs for transactional services in the World
Wide Web, which will emerge from discussions and realisations at these
meetings.
Conclusion
- ----------
Necessity is the mother of invention, and in the context of the World
Wide Web if there is a need someone will soon provide it. Therefore. if
the Open Group wants to be an influence with regard to the provision of
a transactional service for the World Wide Web, it must realise that
time is of the essence.
It is likely that applications in the World Wide Web will be composed
of loosely coupled processes, with a high degree of independence, and
probably operating asynchronously to one another. These components will
need a transactional service to provide local atomic co-ordination of
their activity, including that with the data transfer protocol. Some of
them may need a distributed transaction service. Some portions of an
application will have tightly coupled relationships with other portions
of that application or with other applications, but this will probably
be outside the domain of the World Wide Web and such relationships will
be supported by today's existing mechanisms, including those offered by
current distributed transaction processing products.
Existing applications, not currently associated with the World Wide Web,
are likely to be extended, where appropriate, to interface with it by
use of bridges and adapters. This, in itself, is not likely to lead to
a requirement for a transactional service in the World Wide Web.
New applications will be developed to exploit the availability,
accessibility and other facilities of the World Wide Web. Some of these
may mandate the use of a distributed transactional service.
New applications may be derived by coalescing existing applications.
Since these would probably follow a loosely coupled style, then their
requirements would be similar to those needed by any application
constructed of loosely coupled processes.
Appendix. Influences on Transactionality
- -----------------------------------------
* Spasmodic Network and Process Operation by Choice
In this context, a link of the network or a process in the network is
termed spasmodic, if it is deliberately unavailable as a normal
aspect of its operation, as opposed to being unavailable as a result
of some unscheduled problem condition.
As the network gets larger, it takes more effort to ensure that all,
or at least the necessary part, of it is operational continuously.
Also, it can be sensible to operate certain parts of the network only
for special periods of time, for example, to take advantage of
particular telecommunication tariffs or because the level of traffic
on some communications link does not warrant its continuous
operation. Similarly, it is appropriate to operate certain processes
only for special periods of time.
* Mobile Devices
These are already part of the computing environment, and whose usage
will certainly become more and more pervasive as technology drives
down their cost and enhances their capability. Such devices have
significant processing power and adequate permanent storage media.
Accordingly they are already, and will become more, involved in
distributed transactional processes. However their availability to
participate in some distributed application is very much controlled
by the whim of their operators, that is, the operation of their
processes and their connection to the network are spasmodic.
The mobile evolution will continue to advance. "Smart Cards" are a
case of a mobile device, in that they contain some deeply embedded
chip and memory. Currently, they are involved in "small change"
transactions and typically have to be inserted in (or at least be in
the vicinity of) other specialised and larger equipment to
participate in some business exchange. It seems likely that their
involvement will grow both in volume and value; the latter presumably
requiring some guarantee that both parts of the business exchange
will be honoured.
* Availability of Multiple Equivalent Processes (Servers)
This is another aspect of the increase in complexity of software, in
that deliberately in the network, there may exist several servers
which can offer equivalent function to a client.
It is unlikely that such a server will always require a
transactional relationship with its client, but it does illustrate a
change in the style of programming of the client, since the client
has some choice in which server to use. Resolving this choice is
very much a matter for the client, but one algorithm will surely be
to choose that server which is likely to achieve a response to the
client the soonest. Producing a result to this algorithm is outside
the sensible scope of computation for the client, since it involves
knowledge of, amongst other things, the topology of the network, the
capability of both the network and the processes within it, and the
amount and distribution of the current workload. Such determination
is best left to the system management of the network and its
processes.
What this example does demonstrate is that there will be a much
looser binding between the processes which comprise the application.
* The Internet and the World Wide Web
The Internet and the World Wide Web are encouraging the growth of
electronic commerce. Much of the current commercial activity relates
to business exchanges (transactions) which are of low risk (because
they are of low value).
* Object Oriented Technology
This is a style of programming that is becoming widespread.
One of its underlying principles, namely, the encapsulation of data,
entails an isolation between the data (and its manipulative methods)
and those co-operating parties that wish to access (and amend) that
data. This further shows that in programming technologies there is a
growing trend to have a looser coupling between the processes which
comprise the application.
* Network Performance and Reliability
Another aspects of the changing software environment are that
network bandwidth is increasing and network reliability is improving.
The former is enabling more sophisticated applications to be
created, involving both larger amounts and also different types of
data to be transferred between distributed systems. Some of these
transfers may require co-ordination across different types of
communication link. This latter is encouraging applications to be
developed for the world of distributed systems, since it is now
practical to locate parts of the overall application in different
systems. This enables more processing power to be applied to that
application or to achieve a better balance of workload across all the
applications. It also gives rise to the possibility of having some
processing redundancy to enhance an application's reliability.
Obviously higher network bandwidth and availability facilitate the
co-ordination of a distributed application. However, it is worth
noting that they also reduce the likelihood of needing to deploy some
application error recovery procedure.
End of paper "Transactionality and the World Wide Web"
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
------- End of Forwarded Message