The application delivery scenarios focus around software as
a service. Software as a service applications fall into three varieties: pure
service, and software + service, hosted application.
The hosted application scenario is similar to hosted
application delivery. Examples are SalesForce, or Hosted Microsoft Exchange.
People provide or buy an application that runs in the cloud. At the other
extreme is the pure service play. Providers create web services (SOAP or REST
based) that provide services used by other applications. Examples are credit
card approvals, or certain loan applications. Applications written by third
parties use this software to compose their applications in conjunction with
their own software. Then there is the mixed play. Providers create both web applications
and web services to be used by third parties. These applications consume the
same web services that are available to others to build their own applications.
This is often done to allow the provider to share the web services among
various offerings, or because they need to boot strap the application
marketplace. The need for rich clients does not necessarily disappear here. If
applications (such as emergency services) have to run with loss of internet
connectivity, stand alone apps may be necessary with synchronization software
used when connectivity is re-established. Transactional queuing is not enough
here because substantive work has to be done by the rich client app when
connectivity is absent.
Internet scale is the last class of application. The first
scaling factor is number of users. In order to achieve such scale you may to
use cloud features such as tables (Google Big Table, Azure Tables, Amazon
Simple DB) instead of or in addition to relational databases. Note that
transactional guarantees are often impossible to make here. The second scaling
factor is geographic distance. If your clients are geographically separated by
enough distance, the latency caused by the speed of light in fiber optic cable actually matters. You
may have to use the cloud features mentioned previously to achieve the responsiveness
for writeable data because transactions, especially distributed transactions
are not feasible to achieve scalability.
The next post in the series will start to discuss the architectural implications of these different types of applications.