![D. Agrawal et al. (Eds.): Information and Software as Services, LNBIP 74, pp. 1–30, 2011.
© Springer-Verlag Berlin Heidelberg 2011
Study of Software as a Service Support Platform
for Small and Medium Businesses
Chang-Jie Guo, Wei Sun, Zhong-Bo Jiang, Ying Huang,
Bo Gao, and Zhi-Hu Wang
IBM China Research Lab, ZGC Software Park No. 19, Beijing, China
{guocj,weisun,jiangzb,yinghy,bocrlgao,zhwang}@cn.ibm.com
Abstract. Software as a Serivce (SaaS) provides software application vendors a
Web based delivery model to serve big amount of clients with multi-tenancy
based infrastructure and application sharing architecture so as to get great benefit
from the economy of scale. In this paper, we describe the evolution of the small
and medium businesses (SMB) oriented SaaS ecosystem and its key challenges.
On particular problem we focus on is how to leverage massive multi-tenancy to
balance the cost-effectiveness achieved via high shared efficiency, and the con-
sequent security, performance and availability isolation issues among tenants.
Base on this foundation, we further study the concepts, competency model and
enablement framework of customization and configuration in SaaS context to
satisfy as may tenants’ requirements as possible. We also explore the topics on
service lifecycle and the subscription management design of SaaS.
Keywords: Software as a Service, Multi-tenancy, Customization, Service
Lifecycle Management, Subscription, Small and Medium Businesses (SMB).
1 Introduction
Software as a Service (SaaS) is gaining momentum with the significant increased
number of vendors moving into this space and the recent success of a bunch of lead-
ing players on the market [1]. Designed to leverage the benefits brought by economy
of scale, SaaS is about delivering software functionalities to a big group of clients
over Web with one single instance of software application running on top of a multi-
tenancy platform [2]. Clients usually don’t need to purchase the software license and
install the software package in their local computing environment. They use the
credentials issued by the SaaS vendor to log onto and consume the SaaS service
over Web through an Internet browser at any time and from any where with Internet
connections.
Today’s economic crisis makes it imperative that organizations of all sizes find new
ways to perform their operations in a more cost-effective fashion. This is particularly
true for small and medium size businesses (SMBs) which often operate with thinner
margins than their larger enterprise counterparts [3]. From this point of view, SaaS is a
delivery model that has everything to lure SMBs -- easy installation, low cost. As a
consequence, SMBs can afford those more powerful enterprise applications, such as
Customer Relationship Management (CRM), Enterprise Resource Planning (ERP) and](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-17-320.jpg)
![2 C.-J. Guo et al.
Supply Chain Management (SCM), via SaaS alternatives to the traditional, on-premise
software packages of the past. It thus has achieved a prosperous development and
covered most of the well-known application areas during the past several years. Ac-
cording to a recent survey [4], 86% of the 600+ SMBs that participated in the survey
said they expected to deploy SaaS in their organization over the next year. Further,
55% of the survey participants indicated that they were planning to spend the same or
even more on IT over the next year.
As more people are diving deep into the market, the SMBs oriented SaaS evolves
gradually into a complex ecosystem. In the ecosystem, the service provider hosts
many applications recruiting from different software vendors in the centrally-
managed data centers, and operates them as the web delivered services for a huge
number of SMBs simultaneously. Furthermore, some value-added service resellers
(VARs), also appeared to help distribute, customize and compose the services to end
customers more efficiently. All of these roles collaborate together to create a healthy
and scalable SaaS value chain for the SMB market. The SMBs greatly reduce their
operating costs and improve the effectiveness of their operations. Other stakeholders
of the ecosystem share the revenues by providing support in the different stages of the
service lifecycle, such as service creation, delivery, operation, composition and distri-
bution. To enable the ecosystem and value chain, several technical challenges are
inevitable introduced, especially compared with the traditional license software based
business model.
Š Massive multi-tenancy [2] refers to the principle of cost saving by effectively
sharing infrastructure and application resources among tenants and offerings
to achieve economy of scale. However, the tenant would naturally desire to
access the service as if there is a dedicated one, which inevitably results to the
security, performance and availability isolation issues among tenants with di-
verse SLA (service level agreement) and customization requirements.
Š Self-serve customization [14] Many clients, although sharing the highly stan-
dardized software functionalities, still ask for function variants according to
their unique business needs. Due to the subscription based model, SaaS
vendors need take a well designed strategy to enable the self-serve and con-
figuration based customization by their customers without changing the SaaS
application source code for any individual customer.
Š Low-cost application migration may help service providers recruit more of-
ferings in a short time, since the service vendors needn’t pay too much efforts
in transformation. However, one issue is most of existing applications are on-
premise or with very initial multi-tenancy features enabled. Another challenge
is the extremely heterogenous programming models.
Š Streamlined service lifecycle [15] refers to the management processes of
services and tenants in many aspects like promotion, subscription, on-
boarding, billing and operation etc. It focuses on optimizing the delivery
efficiency and improving the process flexibility to satisfy the dynamically
changing requirements.
Š On-demand scalability refers to effectively deliver the application and computa-
tional resources to exactly match the real demands of clients. Today, this study is
mostly located in cloud computing [5]. One key challenge is the on-demand allo-
cation/de-allocation of resources in a dynamic, optimized and transparent way.](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-18-320.jpg)
![Study of Software as a Service Support Platform for Small and Medium Businesses 5
Fig. 2 shows a more complex ecosystem, in which a new role, e.g. the service pro-
vider instead of the service vendor, will take full responsibility for hosting and operat-
ing the SaaS applications, and focus on providing better service quality to customers.
In general, service providers may not develop applications by themselves, but tend to
recruit from the service vendors and share the revenue with them in a certain way. In
this case, service vendor becomes the pure SaaS content provider, while the value
propositions of service provider in the ecosystem are as follows.
First, service provider sets up a cost-effective, secure and scalable runtime envi-
ronment to deliver the applications of service vendors as services. It includes the
hosted infrastructure, middleware and common services for SaaS enablement as well
as the management and operation support, such as subscription, metering, billing,
monitoring etc. To be noted, all of these features are provided in a standard “platform
as service” way, independent of the applications running above. It’s somehow similar
to the BSS/OSS (Business/Operation Support System) platform of a telecom carrier,
but targets to the SaaS domain.
Secondly, service provider also provides a suite of programming packages, sand-
box, migration and offering lifecycle management tools for service vendors to
quickly develop, test, transform and on-board their SaaS applications. In this case,
service vendors need only focus on the user interfaces, business logics and data
access models of their applications, without concerning with the detailed implemen-
tation of the SaaS enablement features. Those applications following the given
programming specifications can easily run as services inside the hosted environ-
ment of service provider. Obviously, it can greatly reduce the development or
migration costs of SaaS applications, and has potential to attracting more service
vendors for a short time.
According to the definition of Wikipedia [6], a value-added reseller (VAR) is a
company that adds some feature(s) to an existing product(s), and then resells it (usu-
ally to end-users) as an integrated product or complete "turn-key" solution. In the
SaaS ecosystem, the value proposition of VAR mainly comes from two aspects:
Š Service Distribution: The economics of scales demands the service provider to
recruit a large volume of subscribed customers. In general, the VARs are geo-
graphically closer to end customers, and more familiar with the businesses and
requirements of SMBs. By building a well-designed distribution network with
resellers, service provider may recruit more SMB customers with least costs of
go-to-market. In practice, service resellers may have pre-negotiated pricing that
enables them to discount more than a customer would see going direct, or share
the revenue with service provider.
Š Service Engagement: The value propositions of VARs can also be added by
providing some specific features for the customer's needs which don’t exist in
the standard service offerings, such as services customization, composition and
integration with the on-premise applications or processes. Customers would
purchase these value added services from the resellers if they lack the time or
experiences to satisfy these requierments by themselves.](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-21-320.jpg)
![Study of Software as a Service Support Platform for Small and Medium Businesses 7
Fig. 4. Multi-tenancy Patterns: Multiple Instances Vs. Native (Massive) Multi-tenancy
scalability level increases. By using native multi-tenancy to support more tenants, we
should put more efforts to prevent the QoS of one tenant from being affected by other
tenants in the same sharing multi-tenancy environment.
The selection of multi-tenancy technology depends on the specific application sce-
narios and the target clients’ requirements. For example, a large enterprise may prefer
to pay a premium for multiple instances to prevent the potential risks associated with
resource sharing. While most SMB companies would prefer services with a reason-
able quality at lower costs, and care less about particular kinds of multi-tenancy pat-
terns that the service providers use. Therefore, in this paper, we will focus on the
native multi-tenancy pattern to explore how to achieve cost-effectiveness with accept-
able isolation level for the SMB oriented SaaS ecosystem.
3.2 Cost-Effectiveness
Typically, most SaaS offerings target to SMB clients with very limited IT budgets.
It’s well known that low price is one of the most important reasons that SaaS can
attract the attention of SMB customers. Therefore, the success of SMB oriented SaaS
extremely depends on cost effectiveness and scalability, e.g. economics of scale. This
trend is quite obvious, especially in the emerging markets.
For example, in China, one SMB with 3 concurrent users need only pay about $300
per year to subscribe the online accounting and SCM applications [7]. Meanwhile, the
service provider, which is the biggest ERP software vendor of China SMB market,
wishes to recruit several hundred thousands or even one million subscribed SMB
customers in future several years. The scale of tenant number is predictable since
China owns over 40 million SMBs in 2009. The key challenge is that how to make it
profitable within such low pricing model.
First, from the view of service provider, it should extremely reduce the expense of
service delivery infrastructure including the hardware, software and utility of hosting
center, e.g. bandwidth, power, space etc., and save the costs of human resources to
maintain the service operation lifecycle.
In this case, the multiple instances pattern in Fig. 4 is not practical as the small
revenue generated from each tenant won’t justify the allocation of dedicated hard-
ware/software resources for the tenant. Actually, many resource types can be shared](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-23-320.jpg)
![8 C.-J. Guo et al.
among tenants in a more fine-granular and cost effective way if we take some kind of
suitable resource management mechanism. These resources are located in different
tiers and artifacts of SaaS applications, like user interface, business logic and data
model. Table 1 gives some of these resources in a J2EE based SaaS application.
Table 1. Sharable multi-tenant resources in the J2EE based SaaS application
Layer Components Sharable Resources
Database Access (JDBC, SDO,
Hibernate, JPA etc.)
— Data Source & Connection Pool
— DB Account
— Database/Schema/Table/Buffer Pool etc.
File / IO — Directory
— File
Persistent Data
Model
Directory Server (LDAP) — Directory Tree
— Schema
Authentication & Authorization — Organization Structure / Privileges Repository
— Login / authorization modules
Global Java Object — Static variable
— Variable of Singleton Class
Remote Access (Socket/Http,
RMI, CORABA, JNDI, Web
Service etc.)
— Remote Services
— Connection Parameters like URI, port,
username, password etc.
EJB — Stateful EJB instance
— Data source connection, table of Entity Bean
— Queue, sender's identity of MDB
Logs — Log file location, content, format and
configuration
Business Logic
Cache — Cache Container
BPEL Process Template — Template Level Attribute, Activity, Link
Condition etc.
Human Task — Verb, Task UI etc
Process/Workflow
Business Rule — Rules
JSP — Application Scope Variable (tag, usebean,
applicationContext etc.)
— Declaration variable
— Logo,Style,Layout etc.
User Interface
Servlet — Single-thread servlet
— servletContext
For each kind of sharable resource type, we start from identifying all the potential
sharing and isolation mechanisms, and evaluate them according to the estimation of
the degree of cost saving. The additional management costs introduced by different
level of resources sharing should be considered carefully. Since current administration
tools for application, middleware and database are totally unaware of the concept of
tenants, service providers have to pay more efforts and human resources to execute
those multi-tenancy related operations manually because of lacking tenant-aware
toolkits and automation processes.
For people to understand better, we take the database access as an example [8], and
identified at least three kinds of resources sharing patterns in Fig. 5.
Š E1: Totally isolated: each tenant owns a separate database
Š E2: Partially shared: multiple tenants share a database, but each tenant
owns a separate set of tables and schema](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-24-320.jpg)
![10 C.-J. Guo et al.
To keep consistency, we still take the database as the example. It’s well known in a
standard J2EE application, people generally access database via the standard JDBC
interface or some frameworks above it, such as the iBatis, Hibernate and JPA. To
support pattern E3 in Fig. 5, the layer provides a specific multi-tenant JDBC wrapper
(or driver), which can intercept the database access requests of the application and
retrieve the data of the tenant of the current logon user in an implicit way. Since the
multi-tenant wrapper takes the same programming interfaces of standard JDBC, the
developers are almost multi-tenancy non-awareness and like writing a single tenant
application. Similarly, to transform those existing on-premise applications, the devel-
opers can simply re-compile the application by replacing the JDBC libraries, without
needing change any source codes.
3.3 Security Isolation
In the multi-tenant scenarios, besides those traditional security mechanisms (i.e.,
authentication, authorization, audit etc.), one also needs to consider additional poten-
tial security risk introduced by other tenants who share the same application instance
and resources. This section focus on the security technologies in the massive multi-
tenant system to safeguard the security of each tenant at similar security levels as
those of the traditional single-tenant applications.
Access Control Isolation. It refers to the mechanism to prevent a user from getting
the privileges to access resources belonging to other tenants. There are generally two
kinds of access control isolation patterns: implicit filter and explicit permission. Paper
[9] introduced how to apply these two patterns into a multi-tenant data model.
Actually, we can further generalize the two patterns to realize the access control
isolation of other resources through proper designs of the filter and permission
mechanisms.
Multi-tenant Resource Pool
Tenant A Tenant B
R1 R2 R1 R2
Access tenant
resource implicitly
Insert the tenant
oriented filter into
resource request
Access resource via a
common delegated
account
Tenant Users
Delegated
Account
Fig. 6. Process of Implicit Filter Based Access Control Isolation Pattern
Š Implicit Filter Based Access Control Isolation: In this pattern as illustrated in
Fig. 6, when one tenant requests to access shared resources, a common platform
level account is delegated to handle this request. The delegated account is
shared by all tenants and has the privileges to access resources of all tenants.
However, the key of this mechanism is to implicitly compose a tenant-oriented
filter that will be used to prevent one user from tapping into resources of other
tenants. There are some typical and practical filters for different kinds of re-
sources, such as the SQL sub-statement like “Where TenantID=xxx”, tenant
specific XML context/scope in the configuration file, and one additional tenant](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-26-320.jpg)
![Study of Software as a Service Support Platform for Small and Medium Businesses 11
aware parameter or dimension of the if/then ruleset or decision table in business
rule etc.
Š Explicit Permission Based Access Control Isolation: In this pattern, access
privileges for the resources have been explicitly pre-assigned to the correspond-
ing tenant accounts by using the Access Control List (ACL) mechanism. There-
fore, there is no need to leverage an additional common delegated account
across tenants.
Let’s take the database resource sharing pattern E3 in Fig. 5 as an example too. Ac-
cording to the approaches described above, we may leverage either the application-
level or DBMS-level database access control isolation mechanisms.
In the former, all tenants share a common database account to access their own
data records. A sub-clause needs to be inserted into the SQL statement, to filter out
data records not belonging to the current tenant. For example, for an application
query such as Select name, address, phone From CustomerData, the query would
need to be re-written as Select name, address, phone From CustomerData Where
TenantID=’xyz’.
Although easy to implement, application-level access control isolation has some
potential security risks. For example, SQL injection [10], which is a technique that
exploits a security vulnerability occurring in the database layer of an application, may
occur when user input is either incorrectly filtered for string literal escape characters
embedded in SQL statements or user input is not strongly typed and thereby unex-
pectedly executed. In the multi-tenant context, a well-designed user input may bypass
the sub-clause used to filter out other tenants' data. A typical example of cross tenant
SQL injection is as follows:
Suppose the original SQL statement is Select * From Sales_Order Where Tenan-
tID = 'xyz' And SOID = '" + Order_Id + "'. If the Order_Id variable is crafted in a
specific way by a malicious user, the SQL statement may do more than the code au-
thor intended. For example, setting the Order_Id variable as: '123' or '0'='0'. Then, the
new SQL statement becomes: Select * From Sales_Order Where TenantID = 'xyz'
And SOID = '123' or '0'='0'. Obviously, in this case, all tenants' orders residing in the
shared table will be accessed illegally.
In the DBMS-level access control isolation, each tenant is assigned a dedicated da-
tabase access account and connection which only has privileges to access its own
resources. It should depend on some kind of access control mechanism support by
DBMS in native. For example, Label-Based Access Control (LBAC) [11] is a new
security feature provided by DB2 v9, which allows you decide exactly who has read
and write access to individual rows and individual columns, and thus greatly increases
the control you have over who can access your data. In this way, it can completely
prevent potential SQL injection attack.
Information Protection Isolation. This topic is intended to protect the integrity and
confidentiality of each tenant’s critical information. In other word, one should prevent
the critical information of one tenant from being read or modified by other
unauthorized tenants and users via hacking attempts.](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-27-320.jpg)
![12 C.-J. Guo et al.
Typically, the information may be accessed by unauthorized requesters when data is
stored in database or in memory, exchanged among different application components,
and transferred through networks. A traditional way to protect the information content is
through data encryption and digital signature. However, in a multi-tenant system, the
mechanism of sharing the same set of keys among all tenants is obviously meaningless
since it can only prevent external attackers, but not other tenants who also have the
access to the keys. Therefore, in this case, each tenant should own a unique set of keys,
without disclosing to other tenants, to encrypt its critical and private information.
Theoretically, we may encrypt all the information with the strongest encryption al-
gorithm in any situation. However, the security is about trade-offs of information secu-
rity and performance. We should strive for good-enough security, not for more security
than necessary. From a practical point of view, we suggest the following principles
when making the tradeoffs with respect to the security in multi-tenant systems:
Š Encrypt or digitally sign the most critical information only: Generally, the
criticality of data can be measured by application specific domain knowledge
(i.e. financial data may have higher priority) and the SLA requirements of the
tenants.
Š Select a suitable encryption algorithm: Generally, encryption algorithms with
stronger security may result in poorer performance. In some cases, we may take
mixed encryption algorithms for the tradeoffs. For example, use the public and
private key cryptography algorithm to protect symmetric keys which are finally
used to encrypt data [9].
Š Consider the information access frequency: The performance will suffer more if
the data with higher access frequency is encrypted.
3.4 Performance Isolation
The objective of performance isolation mainly includes two aspects. First, prevent the
(potentially bad) behaviors of one tenant from adversely affecting the usage perform-
ance of other tenants in an unpredictable manner. Secondly, avoid the unfairness
among tenants in terms of usage performance. One should prevent the unbalanced
situations where some tenants achieve very high performance at the cost of others
while all of them sign the same SLA. However, the fairness doesn’t mean absolute
equality: the performance of one tenant is related to its corresponding SLA. It’s rea-
sonable to provide higher performance for the tenant who pays more for a better SLA.
As we all know, the resource allocation mechanisms have major impact on the sys-
tem performance. [12] In this section, we explore the merits and shortcomings of
several resource management mechanisms, and provide guidelines on how to effec-
tively leverage them in the complex multi-tenant environments.
Š By Tenant Resource Reservation: Enforce fixed quotas per tenant for different
resources. This approach can guarantee to meet the minimal SLA requirements
of a tenant. However, it does not have the flexibility to share the idle resources,
and may significantly reduce the throughput and scalability of the hosting ser-
vice platform, especially in the high-load situations.](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-28-320.jpg)
![Study of Software as a Service Support Platform for Small and Medium Businesses 13
Š By Tenant Resource Admission Control: Enforce the admission control policies
or limitations per tenant for different resources to prevent potentially bad behav-
iors. The admission policies may be static or even dynamic ones dependent on
the states of the system during the runtime. For example, “if the system load is
less than a certain degree, then the maximal number of concurrent users per ten-
ant should be fifteen, else be ten.”
Š Tenant Oriented Resource Partition: It refers to the capability of distributing
different kinds of available resources among a number of partitions. Each tenant
will be assigned to a certain resource partition. Tenants sharing the same parti-
tion should follow the same resource management policies, and be separated
from those tenants outside the partition. Obviously, this separation improves the
isolation capabilities among tenants who don't belong to the same partition. The
challenge is how to improve the resources efficiency among partitions. One po-
tential approach is a well-designed placement algorithm to distribute tenants
with different loads and SLAs among multiple partitions to balance the loads of
all partitions.
In practice, we suggest to take a hybrid performance isolation pattern. First, the ten-
ants are categorized into different groups according to their specific SLA require-
ments and behavior patterns studied by statistical data collected during the runtime.
Then, the approaches mentioned above, including resources reservation, admission
control and partition, etc., would be applied selectively to achieve the best balance
between the resource utilization efficiency and the performance isolation.
3.5 Availability (Fault) Isolation
The service availability is one of the most important SLA metrics of a hosted applica-
tion. Study [13] in this area have concerned with how to design a high availability
system. However, the native multi-tenant system presents a new challenge: how to
prevent the propagation of faults among tenants sharing the same application instance,
or the so-called tenant oriented fault or availability isolation.
In traditional single tenant system, the availability is usually measured by follow-
ing formula:
- /( )
ST Availability MTTF MTTF MTTR
= + (1)
Where, MTTF is Mean Time To Failure, MTTR is Mean Time To Repair. Therefore,
the availability is expressed as a ratio of the average service available time to the total
system cycle time.
While in a multi-tenant system, the formula should be revised by taking the tenants
into consideration. Suppose the total number of tenants is N, and the average number
of infected tenants is X when a fault occurs. We can define the availability of the
multi-tenant system as following:
- 1 /( )* /
MT Availability MTTR MTTF MTTR X N
= − + (2)
Obviously, consider the MTTF, MTTR and N as the constants, the average infected
tenant number X should be the key factor of the availability of the hosted service.](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-29-320.jpg)
![Study of Software as a Service Support Platform for Small and Medium Businesses 15
software, the more potential tailoring efforts need be involved to serve a specific
client. Web e-Mail is one SaaS service with relatively simple functions, that is why
clients usually just need to tailor the service with parameters based setting, e.g. e-mail
box storage size; account number. Industry generic CRM is one service with medium
level of function complexity that is why you see many CRM SaaS vendors offer much
stronger tailoring capabilities through configuration and customization tools. As SaaS
leverages economy of scale of clients’ number through a long tail play, therefore the
more complex of the software, it becomes more non-appropriate to explore SaaS
model as client may ask very complex tailoring requirements which can not be han-
dled effectively with Web based delivery model in multi-tenancy environment. That
is why the most successful SaaS services stay at CRM, Human Resource Management
(HRM), Finance & Administration (F&A) and Collaboration (email, web-conference,
etc) spaces [16].
Fig. 7. Configuration and Customization Demands vs. Functional Complexity of a SaaS
Tailoring a SaaS service can leverage two major approaches: Configuration and
Customization. These two terms usually get people confused about their differences.
Actually different SaaS vendors use different terms in different contexts. We try to
clarify the difference between them. As depicted in Fig.8, In order to make a stan-
dardized SaaS offering to serve a specific client, we need to tailor it into a tenantized
offering by satisfying this client’s unique requirements. Both Configuration and Cus-
tomization can support this tailoring effort into certain level. The crux of the differ-
ence is complexity. Configuration does not involve source code change of the SaaS
application. It usually support variance through setting pre-defined parameters, or
Fig. 8. Configuration and Customization](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-31-320.jpg)
![16 C.-J. Guo et al.
leveraging tools to change application functions within pre-defined scope, e.g. adding
data fields, changing field names, modifying drop-down lists, adding buttons, and
changing business rules, etc. Configuration can support tailoring requirements within
pre-defined configurable limit. Customization involves SaaS application source code
changes to create functionality that is beyond the configurable limit.
Comparing with Configuration, Customization is a much more costy approach for
both SaaS vendors and clients. As Customization involves SaaS software source code
changes, that produces many issues which involve significant cost, for example: Re-
quiring people with higher skills with higher wage to work on Customization; Allo-
cating resources and infrastructure to manage software code versions; involving much
longer lifecycle brought by code development/debugging/testing and deployment; and
losing business opportunity from those clients who can not accept the Customization
complexity and cost [17]. The Customization is becoming much more complex in
SaaS context, as SasS vendors need to maintain every piece of Customization code
tenant by tenant. Upgrading the SaaS application should not lead into losing of any
single tenant’s customization code. Therefore wherever possible, SaaS should avoid
Customization by using Configuration to meet clients’ tailoring requirements and
enlarge configurable limit as far as possible toward client’s unique requirements.
4.2 Configuration and Customization Competency Model
To facilitate strategy definition and execution discussion around SaaS configuration and
customization, we introduce the Configuration and Customization Competency Model
described in Fig. 9. There are 5 levels of competencies have been defined from “Entry”,
“Aware”, “Capable” levels to “Mature” and “World Class” levels. This model can be
used in the assessment of SaaS application to identify improvement goals around con-
figuration and customization through necessary benchmarking with market leader’s
competency level. Different level of competency can enable different level of variance
requirements through different technical approaches supported by ranges of SaaS ser-
vices from completely standardized offering across all the tenants to fully tenantized
offering for any individual tenant. In theory, the higher of the competency level, the
more customers and the more complex variance requirements the SaaS service can
Fig. 9. SaaS Configuration Competency Model](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-32-320.jpg)
![Study of Software as a Service Support Platform for Small and Medium Businesses 17
support. However different SaaS vendors may have different strategies in terms of tar-
geted customer segments, supported scope of variance, etc. If the SaaS strategy is well
defined, the SaaS service can succeed on the market even its configuration and customi-
zation competency only stays at “Entry” level or “Aware” level.
The configuration and customization to a SaaS application can happen in many dif-
ferent perspectives. Summit Strategies Inc analyzed the configuration and customiza-
tion capabilities of SaaS in different implementation layers of the software, which
include: Presentation Logic, Application Logic, and Database Logic [18]. Here we try
to analyze this issue from clients’ requirements point of view as follows.
As illustrated by the Fig. 10, SaaS tenants can potentially have configuration and
customization requirements from many different perspectives. Each tenant may raise
the following challenges to the SaaS vendor: “I need more fields to describe my busi-
ness documents”; “Our manager wants a new report/dashboard to analyze sales data”;
“Our organization has no role of procurement manager”; “The workflow of our busi-
ness is different with what you can support”. Any of these challenges can be divided
into implications to different perspectives of the SaaS application, e.g., Data, User
Interface, Organization Structure, Processing Logic, Workflow, Business Rules, For
example: When tenant wants to change the default data structures provided by the SaaS
vendor, the configuration and customization tools should support.
“Add Custom Field”, “Change Field Name”, “Change Field Type”; When tenant
wants to change workflow pre-built by SaaS vendor, the configuration and customiza-
tion tools should support “Switch on/off Tasks”, “Add New Tasks”, “Reorder the
Tasks”, “Change Roles for a Task”. If you analyze those change impact relationship”
lines on the figure, you will notice “Data Configuration and Customization” and “Or-
ganization Structure Configuration and Customization” are the two most important
perspectives, any change of these two perspectives will potentially bring major impact
to many other perspectives including User Interface, Workflow, Business Rules, etc.
Fig. 10. Perspectives of Configuration and Customization Requirements](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-33-320.jpg)
![22 C.-J. Guo et al.
It is critical to have well designed principals and approach to tackle all the actions in a
unified and consistent way.
As we discussed in table 2, there are different approaches which can enable differ-
ent competency level requirements. Parameterized Configuration can enable “Aware”
level variance through setting pre-defined parameters and options by end user in the
runtime environment. Self Serve Configuration tool leverages an application variance
metadata framework and a series of simple point-and-click wizards, users can design
custom user interfaces and modify the structure of the data model and the applica-
tion’s business logic (workflow, business rules, etc). But the scope of configuration is
constrained by the metadata framework. Scripting based programming, a version of
end-user programming, allow for larger scope customization by the end user by ex-
tending the features of the tool using a constraint scripting language to guarantee
security and avoid script generated damage to the core application. World Class SaaS
service make their application coupled with a development environment and a formal
programming model that can be used by user to build new application code or modify
compiled code to match their requirements. Different SaaS vendors take different
approach and develop their own implementations. [19] There is not a generic and
platform independent approach for SaaS vendors to use today. There is a strong op-
portunity for research activities.
5 Service Lifecycle Management
5.1 SaaS Service Lifecycle Overview
Generally speaking, SaaS has a different lifecycle compared to a traditional software
product. The stages like requirements analysis, development and testing are still very
fundamental; however, new activities are required in addition. The following figure
shows an overall SaaS lifecycle.
Fig. 15. An Overall SaaS Lifecycle
After a software application has been developed and deployed, it needs to be pack-
aged by defining business terms, applying billing policies, and so on before it’s ready
to be subscribed to as a service offering by a customer. There are multiple ways to
subscribe, including self-service or subscription via service reseller or operator. If a
customer successfully subscribes to a service offering, then users can be authorized to
access it. Based on metered usage information the customer will be billed periodically.
Usually, feedback and analysis are essential steps to further improve a software appli-
cation or customer service.
In real practice, the lifecycle may be different from the complete one showed above
(e.g., there’s a certain kind of SaaS, which is developed and consumed via the Web](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-38-320.jpg)
![Study of Software as a Service Support Platform for Small and Medium Businesses 27
Fig. 20. Service Structure for Retail B2B Service
6 Related Work
In the hosted applications of the early 90s [20][21], companies only moved their
hardware and applications from their premises to the data centers, and paid a premium
to have their applications hosted. This was a typical single-tenancy scenario without
any hardware or software sharing. To reduce the operation cost, some hosting service
providers [22] started to run multiple application instances with the same code base
on a shared hardware or software infrastructure. In fact, many such technologies [23]
are applicable to support the multi-tenant pattern including partition, virtual OS, re-
sources partitions, and virtual middleware server.
To achieve more benefits from the concept and practice of the shared efficiency,
pioneers in this domain started building their solutions of hosted applications around
the multi-tenancy rather than simply leveraging the on-premise application hosting
model. [21] In recent years, the native multi-tenancy model, as exemplified in SaaS
[24][25][26][27][28], achieves great successes. However, most of them are specific
applications or application types such as CRM. [25][28]
Fred & Gianpaolo studied the similar topics [9][29]. They provided a high-level
description of the architecture of a SaaS application, and discussed the challenges and
benefits of developing and offering SaaS. Their work mainly focused on the multi-
tenant data model from the security and scalability perspectives. There are already
some studies [23] on the tradeoffs of resources utilization and isolation. The authors
of [30][ 31] introduced the OS level performance isolation mechanisms, by leveraging
the reservation or partition technologies on system resources. White and Miles [13]
presented four principles on fault tolerance and availability to deal with the fault
isolation issues.
As for the customization and configuration, there are many academic research and
industrial best practices available already. For example: Software Configuration Man-
agement theory was developed by Roger Pressman through software engineering
research[32]; SAP software applications have strong configuration and customization
capabilities through Graphic User Interface(GUI) based tool and script based pro-
gramming tool(ABAP)[33]. The leading SaaS vendors have developed profound
configuration and customization capabilities as well, for example, Salesfoce.com
provides Apex to facilitate the extensive application configuration and customization
on the Web based on the multi-tenancy architecture. [34]
In the telecommunications industry, subscription information is the basis for service
life cycle management. For example, to handle the relationships and interactions among
a service user, subscriber and retailer, the Telecommunication Information Networking
Architecture (TINA) specifies a subscription management information model [35], and
also related service components [36]. Lee et al. provide a three-tier CORBA based
framework to implement a service subscription information management system in a
TINA environment [37]. Compared with a general publish/subscription system, research](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-43-320.jpg)
![28 C.-J. Guo et al.
and practice in this area are more concerned with the service subscription process and
data model in the telecommunication industry context. Subscription management for
Web services is mainly concerned with issuing event notifications and handling the
communication between two parties, the subscriber and the registry. For example, Uni-
versal Description Discovery and Integration (UDDI) introduces a type of entity called
subscription in its information model for a service requestor to keep track of changes of
other UDDI entities like businessEntity, businessService, and so on [38]. UDDI defines
corresponding application protocol interface (API) sets to handle the interaction be-
tween a subscriber and a registry in both synchronous and asynchronous models. Liu et
al. introduces a “consumer centric” service discovery and subscription approach based
on the concept of Community-of-Interest (CoI) [39][40]. CoI is a collection of several
services with similar functionalities and different qualities of service (QoS). In a CoI
model, the subscriber does not communicate with any individual service directly, in-
stead, it interacts with CoI which is responsible for scheduling the subscription to real
target service providers dynamically to achieve the best choice for either QoS or another
objective. Mietzner et al. propose multi-tenancy patterns and variability descriptors to
package multi-tenancy aware configurable composite SaaS applications, based on Ser-
vice Component Architecture (SCA) [41]. They study service structure from a con-
figurability perspective, and subscription is not explicitly covered.
7 Summary
As more people are diving deep into the market, the SMBs oriented SaaS evolves
gradually into a complex ecosystem. It involves many stakeholders with different
requirements and value propositions, such as customer (tenant), service provider,
service (software) vendor and value-added service reseller and so on. This paper tar-
gets to explore the technologies to set up a healthy and profitable SaaS ecosystem to
operate many SaaS applications recruiting from service vendors for a huge number of
SMB customers. According to the customer requirements and experiences we accu-
mulated via real customer engagement, this paper focuses on exploring three most
important challenges of the ecosystem, e.g. massive multi-tenancy, flexibility and
service lifecycle management, and the corresponding technical solutions.
First, this paper introduces how to leverage the massive multi-tenancy technologies
to achieve the cost effectiveness by effectively sharing resources of the infrastructure,
middleware and application instance among tenants. Due to the essential tradeoff
between the high shared efficiency and isolation among tenants, we also explore
many approaches to support better security, performance and availability isolation in
the multi-tenant environments.
Configuration and customization are the critical perspectives for SaaS vendors to
design their offerings to satisfy as many customers’ requirements as possible in the
targeted customer segment and application domain In this paper, we clarified the
concepts of configuration and customization in SaaS context, and introduced compe-
tency model and a framework to help SaaS vendors to plan their offerings from con-
figuration and customization enablement point of view.
This paper also explores the topics on service lifecycle and the subscription manage-
ment design of SaaS. We present a method which can guide a SaaS provider in designing
subscription management according to its application’s characteristics and targeted busi-
ness model. Structure pattern and interaction pattern are the key components of this](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-44-320.jpg)
![D. Agrawal et al. (Eds.): Information and Software as Services, LNBIP 74, pp. 31–56, 2011.
© Springer-Verlag Berlin Heidelberg 2011
Design Patterns for Cloud Services
Jinquan Dai and Bo Huang
Intel China Software Center
No. 880 Zi Xing Road, Shanghai, P.R. China, 200241
{jason.dai,bo.huang}@intel.com
Abstract. The transition to cloud computing is a disruptive trend that poses
huge challenges to the software and service architecture. There are dramatic dif-
ferences between delivering software as services in the cloud for millions to use
through their occasionally disconnected clients, versus distributing software as
bits for millions to run on their PCs. In particular, cloud services need new de-
sign patterns and programming models for their partitioned data set with many
copies that are independently changed. This is a huge software challenge and a
major barrier to the adoption of cloud computing. For instance, big websites
spend 70% of their efforts on the undifferentiated heavy lifting (e.g., partition-
ing, replication and scaling) versus 30% on the differentiated value (feature)
creation. This chapter will review the challenges for cloud services and some of
the emerging solutions to address those challenges, based on our experience in
building cloud service platforms as well as the industry best practices.
Keywords: cloud computing, cloud service, scalability, availability, reliability,
design patterns, service architecture.
1 Introduction
The transition to cloud computing is a disruptive trend that poses huge challenges to
the software and service architecture. There are dramatic differences between deliver-
ing software as services in the cloud for millions to use through their occasionally
disconnected clients, versus distributing software as bits for millions to run on their
PCs. First, services must be highly scalable, supporting millions of concurrent users at
peak. Second, services must have low latency, minimizing the wait time of users.
Third, services must be always available, even in times of server or network failures.
Fourth, services can evolve much more quickly (with, say, weekly or bi-weekly re-
leases) than packaged products, because they only run inside the cloud. Those re-
quirements have two important implications on the underlying software as follows.
• The data center is the computer
In order to meet the requirements of high scalability, high availability and low la-
tency, services are developed to run on mega data centers [1], as opposed to
shrink-wrapped software running on individual PCs. The data centers have a scale-
out shared-nothing architecture (made up of tens of thousands of independent,
commodity servers) and are geographically distributed. And there is also a move to](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-47-320.jpg)
![32 J. Dai and B. Huang
many small, cheap, independent and less reliable data centers (e.g., containerized
data centers [2] [3]) that are geo-distributed, for the sake of cost and energy
effectiveness [4].
In this model, cloud services can achieve high scalability only through partition-
ing, and achieve high availability only through redundancy. Therefore, services
need to be architected to have their data and computing partitioned among inde-
pendent servers, and to have their data (asynchronously) replicated across inde-
pendent servers and data centers.
• The application is always offline
Despite the increasingly ubiquitous wireless connectivity, clients will be occasion-
ally disconnected. In addition, due to ubiquitous service compositions (e.g., SOA
and service APIs), data integrations (e.g., mashup and widget), as well as data rep-
lications across multiple servers and data centers, remote services and data will be
occasionally unavailable to the applications (either in the cloud or on the clients).
If those applications have to wait for the remote services and data when discon-
nected, cloud services will be extremely slow and have low availability. Therefore,
the application needs to work with an assumption that it is always offline, by mak-
ing progress based on its local states as much as possible (e.g., using Google Gears
[5] that provides an environment for web applications to run offline or Microsoft
Sync framework [6] that automatically synchronizes data between clients and ser-
vices), and by interacting with remote partners asynchronously to reconcile their
states.
In summary, cloud service platforms are drastically different from traditional distrib-
uted systems. The classic definition of a distributed system is a “collection of inde-
pendent computers that appear to the users of the system as a single computer” [7].
Traditionally, efforts in this area (such as distributed transactions, quorum protocols,
atomic broadcast, RPC, synchronous request-response, and tightly coupled schema)
all attempt to mask the existence of independence from the applications. On the other
hand, cloud computing is composed of, and more importantly, acknowledges the
existence of many small, independent, and unreliable components (e.g., clients, serv-
ers, data centers and services) that may be occasionally disconnected.
Consequently, cloud services need new design patterns and programming models
for the partitioned data set with many copies that are changed independently [8]. This
is a huge software development challenge and a major barrier to the adoption of cloud
computing. For instance, developers of big websites usually spend 70% of their ef-
forts on the undifferentiated heavy lifting (e.g., partitioning, replication and scaling)
versus 30% on the differentiated value (feature) creation [9]. This chapter will review
the challenges for cloud services and some of the emerging directions for solutions to
address those challenges, based on our experience in building cloud service platforms
as well as the industry best practices.
The rest of the chapter is organized as follows. Section 2 describes how the cloud
services manage their partitioned data set using the new data model. Section 3 re-
views the computing models adopted by cloud services to distribute their computa-
tions across many independent servers. Section 4 discusses the challenges for cloud](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-48-320.jpg)
![Design Patterns for Cloud Services 33
service to manage distributed agreement across many independent components and
how those challenges can be addressed. Section 5 describes how to cope with the
inconsistency across multiple data replicas in cloud services using relaxed consistency
models. Finally, section 6 concludes the chapter with possible future works for both
the industry and the academic community.
2 Data Model
Traditionally, enterprise systems store their data in relational databases. However, the
complex management, general querying and transaction support offered by an
RDBMS is overkill for most of the service applications. This excess functionality
results in high performance penalty, expensive hardware and highly skilled personnel
for operations, making it a very inefficient solution. In addition, traditional distributed
relational database systems focus on providing a complete relational model with
transactional (ACID) consistency to the partitioned and/or replicated data, and are
therefore limited in scalability and availability [10].
Although many advances have been made, it is still difficult to scale-out databases
or use smart partitioning and replication schemes. Many big websites have to build
their own (semi-) structured data storage systems from scratch (e.g., Google’s Big-
table [11] system, Amzon’s Dynamo [10] system and Yahoo’s PNUTS [12] system);
and others just use the traditional RDBMS as dumb row stores and build their own
access and management logics above the databases (e.g., the eBay architecture [13],
sharding in MySpace [14] and Flickr [15], and Microsoft SQL data service [16]), as
illustrated in Fig. 1.
Web/App Server
Global lookup
DB cluster
db#0
25% of users
(1) where is user#168?
(2) db#2
(3) get user#168
(4) return user#168
db#1
25% of users
db#2
25% of users
db#3
25% of users
Fig. 1. In this simple example of data access layer (above traditional databases), each of the
servers (db#0 – db#3) contains a subset of the user profiles. When the web server needs to
access the profile of user#168, it first looks up the profile location, which is stored at the global
lookup DB cluster. After the location (server db#2 in this example) is determined, the web
server can directly go to server db#2 for the profile.](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-49-320.jpg)
![34 J. Dai and B. Huang
2.1 Requirements of Cloud Services
Cloud services need a new data model to deal with their unique requirements and
challenges as follows.
• Data partitioning
In cloud services, data are usually horizontally partitioned along primary access
paths [19] [20] (e.g., by individual users), and spread around independent servers.
For instance, Fig. 2 illustrates the horizontal partitioning of databases in the eBay
architecture [13]. Therefore, the new data model should allow the programmers to
express the data partitioning as a program abstraction, and to design the applica-
tions around collections of partitioned data.
Fig. 2. eBay horizontally splits its databases (e.g., user and category tables) into individual
shards, which are standalone database servers containing a slice of the main database
• Dynamic schema
Cloud services need to both evolve quickly and provide high availability; conse-
quently changes to the data schema need to be handled seamlessly in a system run-
ning 24 by 7, 365 days a year. Therefore, the new data model should allow the
schema of objects to be flexibly defined and dynamically changed.
For instance, in Amazon SimpleDB [21], data are organized into domains that
are collection of items described by attribute-value pairs; conceptually, a domain is
analogous to a relational table with each item corresponding to a row and each at-
tribute corresponding to a column. However, unlike traditional databases, Amazon
SimpleDB has a much more flexible data schema, as illustrated in Fig. 3.](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-50-320.jpg)
![Design Patterns for Cloud Services 35
Name
(1) createDomain (“product”);
- An “product” domain is
create
- The domain is initially
empty
- Only the “Name” attribute
is required
Name
item1
Category
sweater
Color
blue,
red
(2) putAttribute (domain=>“product”,
Name=>”item1”,
Category=>”sweater”,
Color=>”blue”,
Color=>”red”,
Size=>”small”);
- An new item “item1” is added
- New attributes “Category”, “Color” and
“Size” are added
- Multiple values are associated with the
“Color” attribute
Name
item1
Category
sweater
Color
blue,
red
(3) putAttribute (domain=>“product”,
Name=>”item2”,
Category=>”shoes”,
Color=>”black”,
Size=>”9”,
Material=>”leather”);
- An new item “item2” is added
- Values of different types are associated with the “Size” attribute of
“item1” and “item2”
- New attributes “Material” is added to “item2” only
Size
small
Size
small
item2 shoes black 9 leather
Material
Fig. 3. Amazon SimpleDB has a very flexible schema. New attributes can be dynamically
added on the fly and only associated with specific items, multiple values can be associated with
an attribute of an item, and two items in the same domain can have different types of values for
the same attribute.
• Local transaction (only)
In cloud services, distributed transactions (including techniques such as two-phase
commit, Paxos, and quorum protocols) are not used, due to their performance cost
and fragility [20] [22]. Therefore, the new data model should enforce that only lo-
cal transactions (within a node) can be used and that distributed transactions are
not allowed.
For instance, in Google Megastore [23] [24] each data object is known as an en-
tity and each entity have a parent entity. Consequently entities forms a forest of
trees through their parent-relationship, and all entities in the same tree (i.e., with](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-51-320.jpg)
![36 J. Dai and B. Huang
the same root entity) belong to the same entity group. All entities in a group are
stored in the same Megastore node, and a single transaction can only operate enti-
ties in the same entity group.
• Incremental scaling
In cloud services, the size of the data manipulated by the applications grows sig-
nificantly large over time. What previously fits in one machine may need to be re-
partitioned to multiple machines later. Therefore, the new data model should allow
the applications to scale incrementally (i.e., one machine at a time), by dynami-
cally spreading the data in a small set of machines to a larger set as the load grows
and new machines become available.
2.2 New Data Model: Uniquely Keyed Elements
Typically the new data model for cloud services comprises a collection of uniquely
keyed elements [22], as described in detail below and illustrated in Fig. 4.
1) Each element represents a disjoint set of data (which are typically described as
property-value pairs and whose properties may be dynamically changed). An
application comprises many elements; for instance, a web application usually
supports many users, and each user can be represented as an element identified
by the unique user ID.
2) All the data within a single element is guaranteed to reside on a single machine
(ignoring replication); different elements may be located in different machines.
That is, the data set of the application is partitioned around those uniquely keyed
elements.
3) The application locates a specific element through its unique key. The physical
location of the element is determined by the lower layer (e.g., the data store),
and is likely to change as the requirement for scaling changes and the deploy-
ment evolves. Therefore, the application cannot make assumptions about the lo-
cations of elements, except that a single element is guaranteed to reside on a
single machine.
4) The application can only perform atomic transactions within a single element.
Transactions cannot span multiple elements, because there is no guarantee that
they will reside on the single machine all the time
In summary, the data model for cloud services requires that the service has the notion
of element as a programming abstraction, designs its business logic and data set
around the collection of elements, uses the unique key to locate a specific element,
and assumes lack of atomicity across different elements. This data model is implicitly
adopted by many Internet-scale services in the industry today (such as Amazon Sim-
pleDB [21], Google MegaStore [23] [24], Microsoft Windows Azure table storage
[25] and Microsoft SQL data service [16]).](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-52-320.jpg)
![38 J. Dai and B. Huang
• Primary-key based access
Primary-key based access to records is not only predominant for cloud services, but
also the most efficient and preferred way in the new data model, as long as the
primary key includes the unique identifier of the element that contains the record
(e.g., the primary key of every record that belongs to a user element may contain
the unique user ID).
• Simple queries
It is also straightforward to efficiently support some simple forms of queries in the
new data model, especially those against a specific element (and preferably over
some indexed fields).
• Arbitrary, ad-hoc queries
On the other hand, it is very challenging, if not impossible, to support arbitrary, ad-
hoc queries in the new data model, especially those that can potentially access an
arbitrary number of elements (e.g., finding all the users whose birthdays are today
where each user is an individual element).
In general, it is unclear what the most efficient way is to support this type of
queries. One possible implementation of such queries is through distributed query;
that is, (partial) queries are sent to all the nodes which then return partial results to
a central place to assemble the final result. Unfortunately, distributed query is lim-
ited in performance and scalability as the data set grows in size.
An alternative implementation is two-level lookup through alternative indices;
that is, identifiers of the elements containing the records are first determined by
looking up an alternative index and only those elements are then queried. Since all
elements or servers are not queried, two-level lookup usually has better perform-
ance and scalability; however, the service needs to deal with the potential inconsis-
tency as the alternative index can get out-of-sync with the element data [22].
In practice, only a predefined, business critical subset of those ad-hoc queries
will be supported for the service. For instance, social network services usually need
to solve the hairball problem [26]. That is, those services need to organize the per-
user information (e.g., groups that a user belongs to) as an individual element so
that they can efficiently access such information by the user ID; on the other hand,
they also need to access the per-user information by searching for the data to find
the users (e.g., all the users belonging to a given group). Those predefined queries
are typically supported through extensive use of prepared statements and bind vari-
ables [13], and through data demornalization [15] (that is, storing data redundantly
along all primary access paths, usually in an asynchronous manner).
For instance, in FriendFeed [27] data are stored as JSON objects with unique
IDs in the primary database tables, which are then horizontally partitioned based on
the primary keys. In order to efficiently access these data by searching on a secon-
dary property, a separate “index” database table is created and asynchronous up-
dated to contain the mapping between the secondary property and the unique ID](https://image.slidesharecdn.com/834721-250529232848-4a551da3/85/New-Frontiers-In-Information-And-Software-As-Services-Service-And-Application-Design-Challenges-In-The-Cloud-1st-Edition-Changjie-Guo-54-320.jpg)
New Frontiers In Information And Software As Services Service And Application Design Challenges In The Cloud 1st Edition Changjie Guo
- 1. New Frontiers In Information And Software As Services Service And Application Design Challenges In The Cloud 1st Edition Changjie Guo download https://ebookbell.com/product/new-frontiers-in-information-and- software-as-services-service-and-application-design-challenges- in-the-cloud-1st-edition-changjie-guo-1669442 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. New Frontiers In Information And Production Systems Modelling And Analysis Incentive Mechanisms Competence Management Knowledgebased Production 1st Edition Przemysaw Rewski https://ebookbell.com/product/new-frontiers-in-information-and- production-systems-modelling-and-analysis-incentive-mechanisms- competence-management-knowledgebased-production-1st-edition-przemysaw- rewski-5236260 Information Fusion And Intelligent Geographic Information Systems Ifigis17 New Frontiers In Information Fusion And Intelligent Gis From Maritime To Landbased Research Claramunt https://ebookbell.com/product/information-fusion-and-intelligent- geographic-information-systems-ifigis17-new-frontiers-in-information- fusion-and-intelligent-gis-from-maritime-to-landbased-research- claramunt-6752184 The Value Of Information Methodological Frontiers And New Applications In Environment And Health 1st Edition Daniel Osgood https://ebookbell.com/product/the-value-of-information-methodological- frontiers-and-new-applications-in-environment-and-health-1st-edition- daniel-osgood-4269190 Governing New Frontiers In The Information Age Toward Cyber Peace 1st Edition Scott J Shackelford https://ebookbell.com/product/governing-new-frontiers-in-the- information-age-toward-cyber-peace-1st-edition-scott-j- shackelford-33933910
- 3. New Frontiers In Quantitative Methods In Informatics 1st Ed Simonetta Balsamo https://ebookbell.com/product/new-frontiers-in-quantitative-methods- in-informatics-1st-ed-simonetta-balsamo-7151378 New Frontiers In Cloud Computing And Internet Of Things Rajkumar Buyya https://ebookbell.com/product/new-frontiers-in-cloud-computing-and- internet-of-things-rajkumar-buyya-46274040 New Frontiers In Bayesian Statistics Baysm 2021 Online September 13 Raffaele Argiento https://ebookbell.com/product/new-frontiers-in-bayesian-statistics- baysm-2021-online-september-13-raffaele-argiento-48680636 New Frontiers In Artificial Intelligence Jsaiisai 2022 Workshop Jurisin 2022 And Jsai 2022 International Session Kyoto Japan June 1217 2022 Revised Selected Papers Yasufumi Takama https://ebookbell.com/product/new-frontiers-in-artificial- intelligence-jsaiisai-2022-workshop-jurisin-2022-and- jsai-2022-international-session-kyoto-japan-june-1217-2022-revised- selected-papers-yasufumi-takama-49463290 New Frontiers In Empirical Labour Law Research Amy Ludlow Alysia Blackham Editors https://ebookbell.com/product/new-frontiers-in-empirical-labour-law- research-amy-ludlow-alysia-blackham-editors-50617338
- 6. Lecture Notes in Business Information Processing 74 Series Editors Wil van der Aalst Eindhoven Technical University, The Netherlands John Mylopoulos University of Trento, Italy Michael Rosemann Queensland University of Technology, Brisbane, Qld, Australia Michael J. Shaw University of Illinois, Urbana-Champaign, IL, USA Clemens Szyperski Microsoft Research, Redmond, WA, USA
- 7. Divyakant Agrawal K. Selçuk Candan Wen-Syan Li (Eds.) New Frontiers in Information and Software as Services Service and Application Design Challenges in the Cloud 1 3
- 8. Volume Editors Divyakant Agrawal University of California at Santa Barbara Department of Computer Science, Santa Barbara, CA 93106, USA E-mail: agrawal@cs.ucsb.edu K. Selçuk Candan Arizona State University School of Computing, Informatics and Decision Systems Engineering Tempe, AZ 85287-8809, USA E-mail: candan@asu.edu Wen-Syan Li SAP China Shanghai, 201203, China E-mail: wen-syan.li@sap.com ISSN 1865-1348 e-ISSN 1865-1356 ISBN 978-3-642-19293-7 e-ISBN 978-3-642-19294-4 DOI 10.1007/978-3-642-19294-4 Springer Heidelberg Dordrecht London New York Library of Congress Control Number: 2011920956 ACM Computing Classification (1998): H.3.5, J.1, H.4.1, K.4.4, C.4 © Springer-Verlag Berlin Heidelberg 2011 This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper Springer is part of Springer Science+Business Media (www.springer.com)
- 10. Preface The need for a book focusing on the challenges associated with the design, de- ployment, and management of information and software as services materialized in our minds after the success of the two consecutive workshops (WISS 2009 and WISS 2010) we organized on this topic in conjunction with the IEEE Interna- tional Conference on Data Engineering (ICDE). Over the recent years, the increasing costs of creating and maintaining in- frastructures for delivering services to consumers have led to the emergence of cloud-based third-party service providers that rent out network presence, com- putation power, storage, as well as entire software suites, including database and application server capabilities. These service providers reduce the overall infras- tructure burden of small and medium (and increasingly even large) businesses by enabling rapid Web-native deployment, lower hardware/software manage- ment costs, virtualization and automation, and instant scalability. The emer- gence in the last decade of various enabling technologies, such as J2EE, .Net, XML, virtual machines, Web services, new data management techniques (includ- ing column databases and MapReduce), and large data centers contributed to this trend. Today grid computing, on-line e-commerce and business (including CRM, accounting, collaboration, and workforce management) services, large- scale data integration and analytics, IT virtualization, and private and public data and application clouds are typical examples exploiting this database and software as service paradigm. While the financial incentives for the database and software as service de- ployments are obvious, convincing potential customers that outsourcing their data is a viable alternative is still challenging. Today, major customer demands from these third-party services include competitive pricing (including pay-per- use), performance-level and service-level assurances, and the flexibility to move services across third-party infrastructures or maybe to in-house private clouds maintained on-premise. Behind these demands lie serious concerns, including the security, availability, and (semantic and performance) isolation provided by the third-party infrastructures, whether these will work in accordance with in-house components, whether they will provide sufficiently complete solutions that elim- inate the need of having to create complex hybrids, whether they will work with other clouds if needed, and whether they will be sufficiently configurable but still cost less. Note that, while tackling these demands and concerns, the service provider also needs to find ways to optimize the utilization of its internal resources so as to ensure the viability of its own operations. Therefore, the immediate technical challenges faced by providers of information and software as service infrastruc- tures are manifold and include, among others, security and information assur- ance, service level agreements and service class guarantees, workflow modeling,
- 11. VI Preface design patterns, and dynamic service composition, resource optimization and multi-tenancy, and compressed domain processing, replication, and high-degree parallelization. The chapters in this book, contributed by leaders in academia and industry, and reviewed and supervised by an expert editorial board, describe approaches for tackling these cutting-edge challenges. We hope that you will find the chapters included here as indicative and informative about the nature of the coming age of information and software as services as we do. November 2010 Divyakant Agrawal K. Selçuk Candan Wen-Syan Li
- 12. Editorial Advisory Board Elisa Bertino Purdue University, USA Bin Cui Peking University, China Takeshi Fukuda IBM Yamato Software Laboratory, Japan Yoshinori Hara Kyoto University, Graduate School of Management, Japan Howard Ho IBM Almaden Research Center, USA Masaru Kitsuregawa University of Tokyo, Japan Ling Liu Georgia Tech, USA Qiong Luo HKUST, China Mukesh Mohania IBM India Research Laboratory, India Tamer Ozsu University of Waterloo, Canada Cesare Pautasso ETH Zurich, Switzerland Thomas Phan Microsoft, USA Honesty Young Intel Asia-Pacific R&D, China Aoying Zhou East China Normal University, China
- 14. Table of Contents Service Design Study of Software as a Service Support Platform for Small and Medium Businesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chang-Jie Guo, Wei Sun, Zhong-Bo Jiang, Ying Huang, Bo Gao, and Zhi-Hu Wang Design Patterns for Cloud Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Jinquan Dai and Bo Huang Service Security Secure Data Management Service on Cloud Computing Infrastructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Divyakant Agrawal, Amr El Abbadi, Fatih Emekci, Ahmed Metwally, and Shiyuan Wang Security Plans for SaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Marco D. Aime, Antonio Lioy, Paolo C. Pomi, and Marco Vallini Service Optimization Runtime Web-Service Workflow Optimization . . . . . . . . . . . . . . . . . . . . . . . 112 Radu Sion and Junichi Tatemura Adaptive Parallelization of Queries Calling Dependent Data Providing Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Manivasakan Sabesan and Tore Risch Data-Utility Sensitive Query Processing on Server Clusters to Support Scalable Data Analysis Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Renwei Yu, Mithila Nagendra, Parth Nagarkar, K. Selçuk Candan, and Jong Wook Kim Multi-query Evaluation over Compressed XML Data in DaaS . . . . . . . . . . 185 Xiaoling Wang, Aoying Zhou, Juzhen He, Wilfred Ng, and Patrick Hung The HiBench Benchmark Suite: Characterization of the MapReduce- Based Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Shengsheng Huang, Jie Huang, Jinquan Dai, Tao Xie, and Bo Huang
- 15. X Table of Contents Multi-tenancy and Service Migration Enabling Migration of Enterprise Applications in SaaS via Progressive Schema Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Jianfeng Yan and Bo Zhang Towards Analytics-as-a-Service Using an In-Memory Column Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Jan Schaffner, Benjamin Eckart, Christian Schwarz, Jan Brunnert, Dean Jacobs, and Alexander Zeier What Next? At the Frontiers of Information and Software as Services . . . . . . . . . . . . . . 283 K. Selçuk Candan, Wen-Syan Li, Thomas Phan, and Minqi Zhou Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
- 17. D. Agrawal et al. (Eds.): Information and Software as Services, LNBIP 74, pp. 1–30, 2011. © Springer-Verlag Berlin Heidelberg 2011 Study of Software as a Service Support Platform for Small and Medium Businesses Chang-Jie Guo, Wei Sun, Zhong-Bo Jiang, Ying Huang, Bo Gao, and Zhi-Hu Wang IBM China Research Lab, ZGC Software Park No. 19, Beijing, China {guocj,weisun,jiangzb,yinghy,bocrlgao,zhwang}@cn.ibm.com Abstract. Software as a Serivce (SaaS) provides software application vendors a Web based delivery model to serve big amount of clients with multi-tenancy based infrastructure and application sharing architecture so as to get great benefit from the economy of scale. In this paper, we describe the evolution of the small and medium businesses (SMB) oriented SaaS ecosystem and its key challenges. On particular problem we focus on is how to leverage massive multi-tenancy to balance the cost-effectiveness achieved via high shared efficiency, and the con- sequent security, performance and availability isolation issues among tenants. Base on this foundation, we further study the concepts, competency model and enablement framework of customization and configuration in SaaS context to satisfy as may tenants’ requirements as possible. We also explore the topics on service lifecycle and the subscription management design of SaaS. Keywords: Software as a Service, Multi-tenancy, Customization, Service Lifecycle Management, Subscription, Small and Medium Businesses (SMB). 1 Introduction Software as a Service (SaaS) is gaining momentum with the significant increased number of vendors moving into this space and the recent success of a bunch of lead- ing players on the market [1]. Designed to leverage the benefits brought by economy of scale, SaaS is about delivering software functionalities to a big group of clients over Web with one single instance of software application running on top of a multi- tenancy platform [2]. Clients usually don’t need to purchase the software license and install the software package in their local computing environment. They use the credentials issued by the SaaS vendor to log onto and consume the SaaS service over Web through an Internet browser at any time and from any where with Internet connections. Today’s economic crisis makes it imperative that organizations of all sizes find new ways to perform their operations in a more cost-effective fashion. This is particularly true for small and medium size businesses (SMBs) which often operate with thinner margins than their larger enterprise counterparts [3]. From this point of view, SaaS is a delivery model that has everything to lure SMBs -- easy installation, low cost. As a consequence, SMBs can afford those more powerful enterprise applications, such as Customer Relationship Management (CRM), Enterprise Resource Planning (ERP) and
- 18. 2 C.-J. Guo et al. Supply Chain Management (SCM), via SaaS alternatives to the traditional, on-premise software packages of the past. It thus has achieved a prosperous development and covered most of the well-known application areas during the past several years. Ac- cording to a recent survey [4], 86% of the 600+ SMBs that participated in the survey said they expected to deploy SaaS in their organization over the next year. Further, 55% of the survey participants indicated that they were planning to spend the same or even more on IT over the next year. As more people are diving deep into the market, the SMBs oriented SaaS evolves gradually into a complex ecosystem. In the ecosystem, the service provider hosts many applications recruiting from different software vendors in the centrally- managed data centers, and operates them as the web delivered services for a huge number of SMBs simultaneously. Furthermore, some value-added service resellers (VARs), also appeared to help distribute, customize and compose the services to end customers more efficiently. All of these roles collaborate together to create a healthy and scalable SaaS value chain for the SMB market. The SMBs greatly reduce their operating costs and improve the effectiveness of their operations. Other stakeholders of the ecosystem share the revenues by providing support in the different stages of the service lifecycle, such as service creation, delivery, operation, composition and distri- bution. To enable the ecosystem and value chain, several technical challenges are inevitable introduced, especially compared with the traditional license software based business model. Š Massive multi-tenancy [2] refers to the principle of cost saving by effectively sharing infrastructure and application resources among tenants and offerings to achieve economy of scale. However, the tenant would naturally desire to access the service as if there is a dedicated one, which inevitably results to the security, performance and availability isolation issues among tenants with di- verse SLA (service level agreement) and customization requirements. Š Self-serve customization [14] Many clients, although sharing the highly stan- dardized software functionalities, still ask for function variants according to their unique business needs. Due to the subscription based model, SaaS vendors need take a well designed strategy to enable the self-serve and con- figuration based customization by their customers without changing the SaaS application source code for any individual customer. Š Low-cost application migration may help service providers recruit more of- ferings in a short time, since the service vendors needn’t pay too much efforts in transformation. However, one issue is most of existing applications are on- premise or with very initial multi-tenancy features enabled. Another challenge is the extremely heterogenous programming models. Š Streamlined service lifecycle [15] refers to the management processes of services and tenants in many aspects like promotion, subscription, on- boarding, billing and operation etc. It focuses on optimizing the delivery efficiency and improving the process flexibility to satisfy the dynamically changing requirements. Š On-demand scalability refers to effectively deliver the application and computa- tional resources to exactly match the real demands of clients. Today, this study is mostly located in cloud computing [5]. One key challenge is the on-demand allo- cation/de-allocation of resources in a dynamic, optimized and transparent way.
- 19. Study of Software as a Service Support Platform for Small and Medium Businesses 3 The existing IT infrastructure, middleware and programming models are difficult to satisfy the requirements and challenges described above, which show in many aspects. For example, software vendors should pay significant development efforts to enable their applications with the capabilities to be run as SaaS services. Meanwhile, the service providers are assailed by seeking a secure, flexible and cost-effective in- frastructure and platform to effectively deliver and operate the SaaS services in the massive multi-tenancy scenarios. Furthermore, they also need well-designed man- agement processes and programming toolkits to attract more software vendors, value added service builders and resellers to join the ecosystem, and recruit, promote and refine the services in a more efficient way. This paper will introduce our experiences and insights accumulated in the real in- dustry practices, to set up an effective and profitable SaaS ecosystem for the large- scale service provider to deliver internet-based services to a huge amount of SMB clients by working with plenty of service vendors. This paper focuses on exploring the key customer requirements and challenges of the ecosystem from three important aspects, e.g. massive multi-tenancy, flexibility and service lifecycle management, and the corresponding technologies having the potential to resolve them in practice. The rest of this paper is organized as follows: Section 2 illustrates the evolution of SaaS ecosystem for SMB market. The next three sections are the main body of this paper. Section 3 focuses on massive multi-tenancy, which is the most important char- acteristic of SaaS. It explores how to achieve the cost effectiveness via effective re- source sharing mechanisms, and the consequent security, performance and availability isolation issues among tenants. Section 4 will explore the configuration and customi- zation issues and challenges to SaaS vendors, clarify the difference between configu- ration and customization. A competency model and a methodology framework have been developed to help SaaS vendors to plan and evaluate their capabilities and strategies for service configuration and customization. Section 5 targets to the service lifecycle and the subscription management design of SaaS. A subscription model is introduced first to capture the different entities and their relationships involved in SaaS subscription. Then a method supported with service structure patterns and busi- ness interaction patterns analysis is presented to empower a SaaS provider to design an appropriate subscription model for its service offering. A case study is also made to demonstrate the effectiveness of the method at the end of this paper. Section 6 introduces related works, and finally Section 7 concludes this paper and discusses future works. 2 SMBs Oriented SaaS Ecosystem In the primary SaaS model, service (software) vendors are responsible for all stages of the complete service lifecycle. As illustrated in Fig. 1, they have to develop and host the SaaS applications by themselves. To promote the businesses, they should define a suitable go-to-market strategy to connect the potential SMB customers to persuade them to subscribe the services. Furthermore, service vendors need also pay significant efforts in the daily operations of the services, like charging the monthly “hosting” or “subscription” fees from customers directly.
- 20. 4 C.-J. Guo et al. Fig. 1. The Primary SaaS Eco-system SaaS customers, e.g. tenants, wish to get cost-effective services that address their critical business needs via a continuous expense rather than a single expense at time of purchase to reduce the Total Cost of Ownership (TCO). Meanwhile, the quality of the services, such as the security, performance, availability and flexibility, should be ensured at an acceptable level, considering the web based multi-tenant environments. Furthermore, the capability of highly on-demand scalability is also strongly required to adapt the dynamic and diverse requirements of their rapid business developments. In this case, service vendors should accumulate enough knowledge in SaaS domain and have an insight into the architecture design of the SaaS applications. They need pay great efforts to enable those SaaS specific features, such as multi-tenant resources sharing patterns, isolation mechanisms, SLA management, service subscription and billing etc. This demands that developers own more strong technical skills, and inevi- tably increases the development cost and cycle. Things could be a lot worse if the service vendors want to build more than one SaaS applications. They have to repeat the effort one by one since the implementation of the SaaS specific features have already been closely tangled with the business lo- gics of each application. It may produce multiple independent and silo SaaS applica- tions, which is not scalable to both development and management. Fig. 2. The Advanced SaaS Ecosystem
- 21. Study of Software as a Service Support Platform for Small and Medium Businesses 5 Fig. 2 shows a more complex ecosystem, in which a new role, e.g. the service pro- vider instead of the service vendor, will take full responsibility for hosting and operat- ing the SaaS applications, and focus on providing better service quality to customers. In general, service providers may not develop applications by themselves, but tend to recruit from the service vendors and share the revenue with them in a certain way. In this case, service vendor becomes the pure SaaS content provider, while the value propositions of service provider in the ecosystem are as follows. First, service provider sets up a cost-effective, secure and scalable runtime envi- ronment to deliver the applications of service vendors as services. It includes the hosted infrastructure, middleware and common services for SaaS enablement as well as the management and operation support, such as subscription, metering, billing, monitoring etc. To be noted, all of these features are provided in a standard “platform as service” way, independent of the applications running above. It’s somehow similar to the BSS/OSS (Business/Operation Support System) platform of a telecom carrier, but targets to the SaaS domain. Secondly, service provider also provides a suite of programming packages, sand- box, migration and offering lifecycle management tools for service vendors to quickly develop, test, transform and on-board their SaaS applications. In this case, service vendors need only focus on the user interfaces, business logics and data access models of their applications, without concerning with the detailed implemen- tation of the SaaS enablement features. Those applications following the given programming specifications can easily run as services inside the hosted environ- ment of service provider. Obviously, it can greatly reduce the development or migration costs of SaaS applications, and has potential to attracting more service vendors for a short time. According to the definition of Wikipedia [6], a value-added reseller (VAR) is a company that adds some feature(s) to an existing product(s), and then resells it (usu- ally to end-users) as an integrated product or complete "turn-key" solution. In the SaaS ecosystem, the value proposition of VAR mainly comes from two aspects: Š Service Distribution: The economics of scales demands the service provider to recruit a large volume of subscribed customers. In general, the VARs are geo- graphically closer to end customers, and more familiar with the businesses and requirements of SMBs. By building a well-designed distribution network with resellers, service provider may recruit more SMB customers with least costs of go-to-market. In practice, service resellers may have pre-negotiated pricing that enables them to discount more than a customer would see going direct, or share the revenue with service provider. Š Service Engagement: The value propositions of VARs can also be added by providing some specific features for the customer's needs which don’t exist in the standard service offerings, such as services customization, composition and integration with the on-premise applications or processes. Customers would purchase these value added services from the resellers if they lack the time or experiences to satisfy these requierments by themselves.
- 22. 6 C.-J. Guo et al. 3 Massive Multi-tenancy 3.1 Overview of Multi-tenancy Patterns Multi-tenancy is one of the key characteristics of SaaS. As illustrated in Fig. 3, in a multi-tenant enabled service environment, the user requests from different organiza- tions and companies (referred as tenants) are served concurrently by one or more hosted application instances and databases based on a scalable, shared hardware and software infrastructure. The multi-tenancy approach can bring in a number of benefits including the improved profit margin for service providers through reduced delivery costs and decreased service subscription costs for clients. It makes the service offer- ings attractive to their potential clients, especially the SMB clients within very limited IT investment budget. App Instance Database Tenants Fig. 3. A Multi-Tenant Enabled Service Environment To achieve the economies of scale, the multi-tenant approach wishes to increase revenues by recruiting large number of clients and reduce the average service delivery costs per client by serving these clients with highly sharing infrastructure and applica- tion resources. Although higher resources sharing level can effectively drive down the total costs for both service consumers and providers, there are essential conflicts be- tween cost-effectiveness and isolation among tenants. From the user experience, QoS (Quality of Service) and administration perspectives, the tenants would naturally desire to access and use the services as if there were dedicated ones. Therefore, isola- tion should be carefully considered in almost all parts of architecture design, from both non-functional and functional level, such as security, performance, availability, administration etc. Generally, there are two kinds of multi-tenancy patterns: multiple instances and na- tive (or massive) multi-tenancy, as illustrated in Fig. 4. The former supports each tenant with its dedicated application instance over a shared hardware, Operating System (OS) or a middleware server in a hosting environment whereas the latter can support all ten- ants by a single shared application instance over various hosting resources. The two kinds of multi-tenancy patterns scale quite differently in terms of the number of tenants that they can support. The multi-instances pattern is adopted to sup- port several up to dozens of tenants. While the native multi-tenancy pattern is used to support a much larger number of tenants, usually in the hundreds or even thou- sands. It is interesting to note that the isolation level among tenants decreases as the
- 23. Study of Software as a Service Support Platform for Small and Medium Businesses 7 Fig. 4. Multi-tenancy Patterns: Multiple Instances Vs. Native (Massive) Multi-tenancy scalability level increases. By using native multi-tenancy to support more tenants, we should put more efforts to prevent the QoS of one tenant from being affected by other tenants in the same sharing multi-tenancy environment. The selection of multi-tenancy technology depends on the specific application sce- narios and the target clients’ requirements. For example, a large enterprise may prefer to pay a premium for multiple instances to prevent the potential risks associated with resource sharing. While most SMB companies would prefer services with a reason- able quality at lower costs, and care less about particular kinds of multi-tenancy pat- terns that the service providers use. Therefore, in this paper, we will focus on the native multi-tenancy pattern to explore how to achieve cost-effectiveness with accept- able isolation level for the SMB oriented SaaS ecosystem. 3.2 Cost-Effectiveness Typically, most SaaS offerings target to SMB clients with very limited IT budgets. It’s well known that low price is one of the most important reasons that SaaS can attract the attention of SMB customers. Therefore, the success of SMB oriented SaaS extremely depends on cost effectiveness and scalability, e.g. economics of scale. This trend is quite obvious, especially in the emerging markets. For example, in China, one SMB with 3 concurrent users need only pay about $300 per year to subscribe the online accounting and SCM applications [7]. Meanwhile, the service provider, which is the biggest ERP software vendor of China SMB market, wishes to recruit several hundred thousands or even one million subscribed SMB customers in future several years. The scale of tenant number is predictable since China owns over 40 million SMBs in 2009. The key challenge is that how to make it profitable within such low pricing model. First, from the view of service provider, it should extremely reduce the expense of service delivery infrastructure including the hardware, software and utility of hosting center, e.g. bandwidth, power, space etc., and save the costs of human resources to maintain the service operation lifecycle. In this case, the multiple instances pattern in Fig. 4 is not practical as the small revenue generated from each tenant won’t justify the allocation of dedicated hard- ware/software resources for the tenant. Actually, many resource types can be shared
- 24. 8 C.-J. Guo et al. among tenants in a more fine-granular and cost effective way if we take some kind of suitable resource management mechanism. These resources are located in different tiers and artifacts of SaaS applications, like user interface, business logic and data model. Table 1 gives some of these resources in a J2EE based SaaS application. Table 1. Sharable multi-tenant resources in the J2EE based SaaS application Layer Components Sharable Resources Database Access (JDBC, SDO, Hibernate, JPA etc.) — Data Source & Connection Pool — DB Account — Database/Schema/Table/Buffer Pool etc. File / IO — Directory — File Persistent Data Model Directory Server (LDAP) — Directory Tree — Schema Authentication & Authorization — Organization Structure / Privileges Repository — Login / authorization modules Global Java Object — Static variable — Variable of Singleton Class Remote Access (Socket/Http, RMI, CORABA, JNDI, Web Service etc.) — Remote Services — Connection Parameters like URI, port, username, password etc. EJB — Stateful EJB instance — Data source connection, table of Entity Bean — Queue, sender's identity of MDB Logs — Log file location, content, format and configuration Business Logic Cache — Cache Container BPEL Process Template — Template Level Attribute, Activity, Link Condition etc. Human Task — Verb, Task UI etc Process/Workflow Business Rule — Rules JSP — Application Scope Variable (tag, usebean, applicationContext etc.) — Declaration variable — Logo,Style,Layout etc. User Interface Servlet — Single-thread servlet — servletContext For each kind of sharable resource type, we start from identifying all the potential sharing and isolation mechanisms, and evaluate them according to the estimation of the degree of cost saving. The additional management costs introduced by different level of resources sharing should be considered carefully. Since current administration tools for application, middleware and database are totally unaware of the concept of tenants, service providers have to pay more efforts and human resources to execute those multi-tenancy related operations manually because of lacking tenant-aware toolkits and automation processes. For people to understand better, we take the database access as an example [8], and identified at least three kinds of resources sharing patterns in Fig. 5. Š E1: Totally isolated: each tenant owns a separate database Š E2: Partially shared: multiple tenants share a database, but each tenant owns a separate set of tables and schema
- 25. Study of Software as a Service Support Platform for Small and Medium Businesses 9 Š E3: Totally shared: multiple tenants share the same database, tables and schema. In this pattern, records of all tenants are stored in a single shared table sets mixed in any order, in which a tenant ID column is inserted in each table to associate the data records with the corresponding tenants Fig. 5. Data tier resource sharing patterns in the multi-tenant context Obviously, E3 is more cost effective than another two patterns in the infrastructure level resources consumption. However beside the isolation issues that we will further discuss later, it also introduces additional costs in data management and maintenance. For example, per-tenant data backup and restore is a very typical feature that should be provided in a multi-tenant environment. Existing DBMS only supports database and table-space level backup and restore mechanism, which can work well in pattern E1 since the smallest operation unit of a tenant is also the database. While in E3, the records of all tenants are stored inside a same set of tables, which makes the existing backup and restore mechanism hardly identify and separate data from the dimension of tenant. In this case, the administrator has to execute the work manually and results to significant effort. Therefore, to automate the operation proc- ess and cut the maintenance cost, current DBMS management toolkits should be en- hanced and transformed as tenant awareness. Secondly, as for service vendors, the development and upgrading costs of SaaS ap- plications should be as small as possible. There are also many software vendors who have already accumulated a lot of on-premise applications in different industries. Most of these applications are very mature and verified in the markets. If they can be quickly transformed into multi-tenant applications with least effort, the SaaS ecosys- tem will become more attractable to both end customers and service vendors. One practical approach is to provide a multi-tenancy enablement layer to hide the complexities of enabling the multi-tenancy capability by encapsulating the detailed implementation of multi-tenant resources sharing and isolation mechanisms. By lev- eraging the (nearly) transparent programming interfaces, build-time libraries and runtime components (or plug-ins of middleware), the enablement layer relieves most of developers from those complicated multi-tenant issues by simulating a virtualized single-tenant application development environment.
- 26. 10 C.-J. Guo et al. To keep consistency, we still take the database as the example. It’s well known in a standard J2EE application, people generally access database via the standard JDBC interface or some frameworks above it, such as the iBatis, Hibernate and JPA. To support pattern E3 in Fig. 5, the layer provides a specific multi-tenant JDBC wrapper (or driver), which can intercept the database access requests of the application and retrieve the data of the tenant of the current logon user in an implicit way. Since the multi-tenant wrapper takes the same programming interfaces of standard JDBC, the developers are almost multi-tenancy non-awareness and like writing a single tenant application. Similarly, to transform those existing on-premise applications, the devel- opers can simply re-compile the application by replacing the JDBC libraries, without needing change any source codes. 3.3 Security Isolation In the multi-tenant scenarios, besides those traditional security mechanisms (i.e., authentication, authorization, audit etc.), one also needs to consider additional poten- tial security risk introduced by other tenants who share the same application instance and resources. This section focus on the security technologies in the massive multi- tenant system to safeguard the security of each tenant at similar security levels as those of the traditional single-tenant applications. Access Control Isolation. It refers to the mechanism to prevent a user from getting the privileges to access resources belonging to other tenants. There are generally two kinds of access control isolation patterns: implicit filter and explicit permission. Paper [9] introduced how to apply these two patterns into a multi-tenant data model. Actually, we can further generalize the two patterns to realize the access control isolation of other resources through proper designs of the filter and permission mechanisms. Multi-tenant Resource Pool Tenant A Tenant B R1 R2 R1 R2 Access tenant resource implicitly Insert the tenant oriented filter into resource request Access resource via a common delegated account Tenant Users Delegated Account Fig. 6. Process of Implicit Filter Based Access Control Isolation Pattern Š Implicit Filter Based Access Control Isolation: In this pattern as illustrated in Fig. 6, when one tenant requests to access shared resources, a common platform level account is delegated to handle this request. The delegated account is shared by all tenants and has the privileges to access resources of all tenants. However, the key of this mechanism is to implicitly compose a tenant-oriented filter that will be used to prevent one user from tapping into resources of other tenants. There are some typical and practical filters for different kinds of re- sources, such as the SQL sub-statement like “Where TenantID=xxx”, tenant specific XML context/scope in the configuration file, and one additional tenant
- 27. Study of Software as a Service Support Platform for Small and Medium Businesses 11 aware parameter or dimension of the if/then ruleset or decision table in business rule etc. Š Explicit Permission Based Access Control Isolation: In this pattern, access privileges for the resources have been explicitly pre-assigned to the correspond- ing tenant accounts by using the Access Control List (ACL) mechanism. There- fore, there is no need to leverage an additional common delegated account across tenants. Let’s take the database resource sharing pattern E3 in Fig. 5 as an example too. Ac- cording to the approaches described above, we may leverage either the application- level or DBMS-level database access control isolation mechanisms. In the former, all tenants share a common database account to access their own data records. A sub-clause needs to be inserted into the SQL statement, to filter out data records not belonging to the current tenant. For example, for an application query such as Select name, address, phone From CustomerData, the query would need to be re-written as Select name, address, phone From CustomerData Where TenantID=’xyz’. Although easy to implement, application-level access control isolation has some potential security risks. For example, SQL injection [10], which is a technique that exploits a security vulnerability occurring in the database layer of an application, may occur when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unex- pectedly executed. In the multi-tenant context, a well-designed user input may bypass the sub-clause used to filter out other tenants' data. A typical example of cross tenant SQL injection is as follows: Suppose the original SQL statement is Select * From Sales_Order Where Tenan- tID = 'xyz' And SOID = '" + Order_Id + "'. If the Order_Id variable is crafted in a specific way by a malicious user, the SQL statement may do more than the code au- thor intended. For example, setting the Order_Id variable as: '123' or '0'='0'. Then, the new SQL statement becomes: Select * From Sales_Order Where TenantID = 'xyz' And SOID = '123' or '0'='0'. Obviously, in this case, all tenants' orders residing in the shared table will be accessed illegally. In the DBMS-level access control isolation, each tenant is assigned a dedicated da- tabase access account and connection which only has privileges to access its own resources. It should depend on some kind of access control mechanism support by DBMS in native. For example, Label-Based Access Control (LBAC) [11] is a new security feature provided by DB2 v9, which allows you decide exactly who has read and write access to individual rows and individual columns, and thus greatly increases the control you have over who can access your data. In this way, it can completely prevent potential SQL injection attack. Information Protection Isolation. This topic is intended to protect the integrity and confidentiality of each tenant’s critical information. In other word, one should prevent the critical information of one tenant from being read or modified by other unauthorized tenants and users via hacking attempts.
- 28. 12 C.-J. Guo et al. Typically, the information may be accessed by unauthorized requesters when data is stored in database or in memory, exchanged among different application components, and transferred through networks. A traditional way to protect the information content is through data encryption and digital signature. However, in a multi-tenant system, the mechanism of sharing the same set of keys among all tenants is obviously meaningless since it can only prevent external attackers, but not other tenants who also have the access to the keys. Therefore, in this case, each tenant should own a unique set of keys, without disclosing to other tenants, to encrypt its critical and private information. Theoretically, we may encrypt all the information with the strongest encryption al- gorithm in any situation. However, the security is about trade-offs of information secu- rity and performance. We should strive for good-enough security, not for more security than necessary. From a practical point of view, we suggest the following principles when making the tradeoffs with respect to the security in multi-tenant systems: Š Encrypt or digitally sign the most critical information only: Generally, the criticality of data can be measured by application specific domain knowledge (i.e. financial data may have higher priority) and the SLA requirements of the tenants. Š Select a suitable encryption algorithm: Generally, encryption algorithms with stronger security may result in poorer performance. In some cases, we may take mixed encryption algorithms for the tradeoffs. For example, use the public and private key cryptography algorithm to protect symmetric keys which are finally used to encrypt data [9]. Š Consider the information access frequency: The performance will suffer more if the data with higher access frequency is encrypted. 3.4 Performance Isolation The objective of performance isolation mainly includes two aspects. First, prevent the (potentially bad) behaviors of one tenant from adversely affecting the usage perform- ance of other tenants in an unpredictable manner. Secondly, avoid the unfairness among tenants in terms of usage performance. One should prevent the unbalanced situations where some tenants achieve very high performance at the cost of others while all of them sign the same SLA. However, the fairness doesn’t mean absolute equality: the performance of one tenant is related to its corresponding SLA. It’s rea- sonable to provide higher performance for the tenant who pays more for a better SLA. As we all know, the resource allocation mechanisms have major impact on the sys- tem performance. [12] In this section, we explore the merits and shortcomings of several resource management mechanisms, and provide guidelines on how to effec- tively leverage them in the complex multi-tenant environments. Š By Tenant Resource Reservation: Enforce fixed quotas per tenant for different resources. This approach can guarantee to meet the minimal SLA requirements of a tenant. However, it does not have the flexibility to share the idle resources, and may significantly reduce the throughput and scalability of the hosting ser- vice platform, especially in the high-load situations.
- 29. Study of Software as a Service Support Platform for Small and Medium Businesses 13 Š By Tenant Resource Admission Control: Enforce the admission control policies or limitations per tenant for different resources to prevent potentially bad behav- iors. The admission policies may be static or even dynamic ones dependent on the states of the system during the runtime. For example, “if the system load is less than a certain degree, then the maximal number of concurrent users per ten- ant should be fifteen, else be ten.” Š Tenant Oriented Resource Partition: It refers to the capability of distributing different kinds of available resources among a number of partitions. Each tenant will be assigned to a certain resource partition. Tenants sharing the same parti- tion should follow the same resource management policies, and be separated from those tenants outside the partition. Obviously, this separation improves the isolation capabilities among tenants who don't belong to the same partition. The challenge is how to improve the resources efficiency among partitions. One po- tential approach is a well-designed placement algorithm to distribute tenants with different loads and SLAs among multiple partitions to balance the loads of all partitions. In practice, we suggest to take a hybrid performance isolation pattern. First, the ten- ants are categorized into different groups according to their specific SLA require- ments and behavior patterns studied by statistical data collected during the runtime. Then, the approaches mentioned above, including resources reservation, admission control and partition, etc., would be applied selectively to achieve the best balance between the resource utilization efficiency and the performance isolation. 3.5 Availability (Fault) Isolation The service availability is one of the most important SLA metrics of a hosted applica- tion. Study [13] in this area have concerned with how to design a high availability system. However, the native multi-tenant system presents a new challenge: how to prevent the propagation of faults among tenants sharing the same application instance, or the so-called tenant oriented fault or availability isolation. In traditional single tenant system, the availability is usually measured by follow- ing formula: - /( ) ST Availability MTTF MTTF MTTR = + (1) Where, MTTF is Mean Time To Failure, MTTR is Mean Time To Repair. Therefore, the availability is expressed as a ratio of the average service available time to the total system cycle time. While in a multi-tenant system, the formula should be revised by taking the tenants into consideration. Suppose the total number of tenants is N, and the average number of infected tenants is X when a fault occurs. We can define the availability of the multi-tenant system as following: - 1 /( )* / MT Availability MTTR MTTF MTTR X N = − + (2) Obviously, consider the MTTF, MTTR and N as the constants, the average infected tenant number X should be the key factor of the availability of the hosted service.
- 30. 14 C.-J. Guo et al. In other words, the goal of tenant oriented fault isolation is to reduce X/N, the ratio of fault propagation among tenants, as much as possible. Based on the analysis above, we give out several principles to handle the challenge of preventing fault propagation in a multi-tenant system: Š Fault Detection & Diagnosis: It’s the first stage to detect that something unex- pected has occurred and quickly identify the currently infected tenant(s). This implies that each tenant should have the ability to monitor the states of its own running instance, and report to the service platform in a timely manner via the mechanisms like heart-beating and periodical simulations. Š Fault Propagation Prevention: Once having detected the faults occurred to cer- tain tenants, we need to take immediate actions to prevent them from propagat- ing to other tenants so as to reduce the infection ratio X/N. Although the specific approaches to reach this goal depend very much on particular kinds of the fault (category), one basic principle is to force the faster release of the critical shared resources to avoid the possible fault propagation. Furthermore, certain isolation technologies discussed in the previous sections (e.g., the partitioning) can also help prevent fault propagation among tenants. Š On-Line Repair: In the native multi-tenant system, the faults of those ill tenants should be repaired while the application instance is still running. Two possible approaches are: (1) Tenant oriented service restart: First suspend or kick out all active users and instances of the ill tenant, release resources it currently owns, and try to correct the error via modifying (potentially) wrong data or informa- tion, then “restart” the service of the tenant (activate users or instances). (2) Tenant oriented service restore: In this approach, we clear all data of the ill ten- ant, and restore to one of its previous backup versions. Beside the fault isolation, the data redundancy is another very important approach to provide fault tolerance. While in the native multi-tenant system, one particular problem is to balance the cost and the tenants’ specific requirements on SLA. Generally, the cost associated with providing this feature is a reduction of storage capacity available, since the implementations require one or more duplications of the tenant’s data set. For each tenant, more copies of data mean better SLA but higher cost. Therefore, the design of data redundancy mechanism should be fine granular and tenant awared to flexibly allocate suitable copies of data for each tenant, which can save the operation cost by the greatest degree while not violating the commitment on availability. 4 Flexibility: Configuration and Customization 4.1 Configuration and Customization in Multi-tenancy Environment The fundamental design point of SaaS is to serve hundreds and thousands of clients through one instance of software application. SaaS vendors don’t develop and keep different software versions for any individual client. The most ideal case for SaaS vendors is that every client feel comfortable using a completely standardize offering. However this ideal case usually doesn’t happen in enterprise software application area. As illustrated in Fig.7, In general with the functional complexity increase of the
- 31. Study of Software as a Service Support Platform for Small and Medium Businesses 15 software, the more potential tailoring efforts need be involved to serve a specific client. Web e-Mail is one SaaS service with relatively simple functions, that is why clients usually just need to tailor the service with parameters based setting, e.g. e-mail box storage size; account number. Industry generic CRM is one service with medium level of function complexity that is why you see many CRM SaaS vendors offer much stronger tailoring capabilities through configuration and customization tools. As SaaS leverages economy of scale of clients’ number through a long tail play, therefore the more complex of the software, it becomes more non-appropriate to explore SaaS model as client may ask very complex tailoring requirements which can not be han- dled effectively with Web based delivery model in multi-tenancy environment. That is why the most successful SaaS services stay at CRM, Human Resource Management (HRM), Finance & Administration (F&A) and Collaboration (email, web-conference, etc) spaces [16]. Fig. 7. Configuration and Customization Demands vs. Functional Complexity of a SaaS Tailoring a SaaS service can leverage two major approaches: Configuration and Customization. These two terms usually get people confused about their differences. Actually different SaaS vendors use different terms in different contexts. We try to clarify the difference between them. As depicted in Fig.8, In order to make a stan- dardized SaaS offering to serve a specific client, we need to tailor it into a tenantized offering by satisfying this client’s unique requirements. Both Configuration and Cus- tomization can support this tailoring effort into certain level. The crux of the differ- ence is complexity. Configuration does not involve source code change of the SaaS application. It usually support variance through setting pre-defined parameters, or Fig. 8. Configuration and Customization
- 32. 16 C.-J. Guo et al. leveraging tools to change application functions within pre-defined scope, e.g. adding data fields, changing field names, modifying drop-down lists, adding buttons, and changing business rules, etc. Configuration can support tailoring requirements within pre-defined configurable limit. Customization involves SaaS application source code changes to create functionality that is beyond the configurable limit. Comparing with Configuration, Customization is a much more costy approach for both SaaS vendors and clients. As Customization involves SaaS software source code changes, that produces many issues which involve significant cost, for example: Re- quiring people with higher skills with higher wage to work on Customization; Allo- cating resources and infrastructure to manage software code versions; involving much longer lifecycle brought by code development/debugging/testing and deployment; and losing business opportunity from those clients who can not accept the Customization complexity and cost [17]. The Customization is becoming much more complex in SaaS context, as SasS vendors need to maintain every piece of Customization code tenant by tenant. Upgrading the SaaS application should not lead into losing of any single tenant’s customization code. Therefore wherever possible, SaaS should avoid Customization by using Configuration to meet clients’ tailoring requirements and enlarge configurable limit as far as possible toward client’s unique requirements. 4.2 Configuration and Customization Competency Model To facilitate strategy definition and execution discussion around SaaS configuration and customization, we introduce the Configuration and Customization Competency Model described in Fig. 9. There are 5 levels of competencies have been defined from “Entry”, “Aware”, “Capable” levels to “Mature” and “World Class” levels. This model can be used in the assessment of SaaS application to identify improvement goals around con- figuration and customization through necessary benchmarking with market leader’s competency level. Different level of competency can enable different level of variance requirements through different technical approaches supported by ranges of SaaS ser- vices from completely standardized offering across all the tenants to fully tenantized offering for any individual tenant. In theory, the higher of the competency level, the more customers and the more complex variance requirements the SaaS service can Fig. 9. SaaS Configuration Competency Model
- 33. Study of Software as a Service Support Platform for Small and Medium Businesses 17 support. However different SaaS vendors may have different strategies in terms of tar- geted customer segments, supported scope of variance, etc. If the SaaS strategy is well defined, the SaaS service can succeed on the market even its configuration and customi- zation competency only stays at “Entry” level or “Aware” level. The configuration and customization to a SaaS application can happen in many dif- ferent perspectives. Summit Strategies Inc analyzed the configuration and customiza- tion capabilities of SaaS in different implementation layers of the software, which include: Presentation Logic, Application Logic, and Database Logic [18]. Here we try to analyze this issue from clients’ requirements point of view as follows. As illustrated by the Fig. 10, SaaS tenants can potentially have configuration and customization requirements from many different perspectives. Each tenant may raise the following challenges to the SaaS vendor: “I need more fields to describe my busi- ness documents”; “Our manager wants a new report/dashboard to analyze sales data”; “Our organization has no role of procurement manager”; “The workflow of our busi- ness is different with what you can support”. Any of these challenges can be divided into implications to different perspectives of the SaaS application, e.g., Data, User Interface, Organization Structure, Processing Logic, Workflow, Business Rules, For example: When tenant wants to change the default data structures provided by the SaaS vendor, the configuration and customization tools should support. “Add Custom Field”, “Change Field Name”, “Change Field Type”; When tenant wants to change workflow pre-built by SaaS vendor, the configuration and customiza- tion tools should support “Switch on/off Tasks”, “Add New Tasks”, “Reorder the Tasks”, “Change Roles for a Task”. If you analyze those change impact relationship” lines on the figure, you will notice “Data Configuration and Customization” and “Or- ganization Structure Configuration and Customization” are the two most important perspectives, any change of these two perspectives will potentially bring major impact to many other perspectives including User Interface, Workflow, Business Rules, etc. Fig. 10. Perspectives of Configuration and Customization Requirements
- 34. 18 C.-J. Guo et al. For example: If tenant changes a data structure, then the user interface to support the input and view of the data should be changed as well; If tenant changes the roles’ definition, then the workflow need to be changed accordingly for those tasks handled by those roles. Therefore SaaS vendors should put much more effort to well design Data and Organization Structure layers to support easy configuration and customiza- tion. It is also very important to consider the impacts and establish the linkages be- tween the other software artifacts and the changes of Data and Organization structure. 4.3 A Framework to Plan and Execute Configuration and Customization Strategy It is very important to define the appropriate software functional scope to be offered as SaaS. It is extremely critical for SaaS vendors to have the right strategy and soft- ware architecture to support Configuration and Customization. This is the foundation to support a SaaS service to pursue economical scale. Fig. 11. A Framework to Plan and Execute Configuration and Customization Strategy As illustrated in the above figure, we introduce a framework to guide the plan and execution of SaaS configuration and customization strategy. This framework consists of a methodology and supporting analysis tools. Understand Environment. The first step of the methodology is to make necessary investigation to understand the environment related with the configuration and customization of the SaaS service. There are two main areas need to be investigated: client requirements and market leader competency level. The objective of analyzing customer requirements is to identify the targeted customer segment and the required variance scope. As illustrated in Fig. 12, a customer segmentation analysis can be conducted by segmenting the whole market into 4 quadrants divided by two major dimensions: uniqueness of requirements and capability to acquire alternative solution. In general, the customers in quadrant III should be the primary targeted customer segment of SaaS service as these customers have relatively low level of variance requirements and has relatively weak capability to acquire alternative solution (e.g. invest on a custom developed application) other than the SaaS service. Quadrant I is Fig. 12. Customer Segment Analysis
- 35. Study of Software as a Service Support Platform for Small and Medium Businesses 19 usually a difficult segment for SaaS service to win as each of the customers in this segment has very unique requirements and they have the capability to explore other alternatives. Customers in quadrant II and IV are the segments where customers are usually in marginal position. If the SaaS vendors could offer strong, easy and low cost configu- ration and customization capabilities, they can win more customers in these two seg- ments. The SaaS vendor can leverage survey and interview with selected potential customers to develop such a customer segment analysis. There are two important elements of this analysis. The first one is to well define the SaaS application function scope and complexity level so as to make clients fall into quadrant III as many as possible; the second one is to determine the addressed market segment and targeted segment through enhanced configuration and customization according to the investi- gated variance requirements. Market leader’s competency level investigation can help SaaS vendor to well posi- tion itself in the competition environment from configuration and customization per- spective, which is an important exercise to support target competency level definition discussed later in this paper. Define Strategy. SaaS vendor should determine how they plan to support the required configuration and customization requirements in the targeted customer segment. To facilitate the discussion, we abstract the potential strategies around Configuration and Customization into four Models illustrated in the table below. Table 2. Different Configuration and Customization Approaches Model A: Native Design Model B: Smooth Evolvement Model C: Pulse Evolvement Model D: Failure Management Description Thoroughly analyze the common configuration and customization requirements before building the SaaS appli- cation; Design the application for extensive configuration and cus- tomization; provide powerful web based tools for tenants to configure and customize the SaaS service by themselves or other system integrator vendor. SaaS vendors need to spend effort to support every single tenant’s configuration and customization re- quirements. But SaaS vendors have a way to manage the cost by leveraging tools & assets, and gradually reduce the cost spend on configuration and customization per tenant. SaaS vendors collect configuration and customization requirements from a group of tenants. Upgrade application to satisfy the re- quirements de- manded by a big group of tenants when the return on investment can be justified by potential benefits brought by the effort. SaaS vendors support configura- tion and customiza- tion for individual tenant. They fail to manage the cost within a scope required by a profit- able business. Approach Provide programming model, web based tools and API for tenants to conduct configuration and customization in self-service mode. SaaS vendors won’t change application code for any individual tenant. SaaS vendors change application codes according to tenants’ requirements. They deploy management tool and process to manage the cost spent on each tenant. SaaS vendors change application codes when the configuration and customization requirements are defined and justified by a big group of tenants’ demand. SaaS vendors change application codes according to each tenant’s re- quirements. They don’t have effective tools and process to manage the cost spent on each tenant. Possible Scalability Very High Medium-to-Low Medium-to-High Very Low Application Complexity Medium-to-Low Medium Medium High
- 36. 20 C.-J. Guo et al. As shown in Fig. 13, the four approaches, “Native Design” (Model A), “Smooth Evolvement” (Model B), “Pulse Evolvement” (Model C), “Failure Management” (Model D), have different level of impact on the SaaS service delivery cost spent on each tenant from configuration and customization. As shown on the following figure, Model D is obviously a bad one which every SaaS vendors should avoid to get into. The other three models can all support sustainable SaaS service business with different profit margins. They can be good choice according to specific SaaS business context in terms of: application complexity, scalability target, the vendor’s understanding of the market, the budget situation, etc. In general, Model B is more appropriate for SaaS targeting very limited number of clients as supporting each individual tenant’s unique require- ments is a very expensive strategy. If a SaaS vendors want to explore very high scalabil- ity to leverage very big economical scale (Long tail play), then Model A would be the best approach. The easiest approach for a SaaS vendor starts from is Model C, they learn the market along the process and eventually can be evolved into Model A when they clearly define and build configuration and customization capabilities needed by the large amount of tenants they want to acquire and serve. Model A can only be built out through deep understanding of the potential configura- tion and customization requirements associated with the SaaS service. It takes specially designed software architecture and provides web based tools for easy and extensive configuration and customization without changing the SaaS application source code. Fig. 13. The Impact on Configuration and Customization Cost of Different Approaches Access Competency. This step is extremely important for those traditional software application vendors who plan to explore SaaS as a new delivery model. The configura- tion and customization might not be a big challenge for applications vendors who have been successfully addressing consumer market and SMB market. These vendors usually take volume play model and do not support individual customer’s variance requirements. They can jump start to explore SaaS by transforming their applications into multi- tenancy enabled with Web interface. However the configuration and customization issue is a big challenge for those application vendors who have been addressing medium to large enterprise market. Though they have well packaged application as a base, these vendors are usually paid by their customers to take custom development approach to satisfy each individual customer’s unique variance requirements.
- 37. Study of Software as a Service Support Platform for Small and Medium Businesses 21 In many cases, source code level customizations are involved if the application has no well defined configuration framework. But in the traditional application delivery model, the vendor can afford that because they are paid by the end customer to do so. This approach can not be replicated in SaaS delivery model. SaaS has subscription based usage pattern. The very small amount upfront investment made by the tenant and monthly based subscription fee can not support the total cost spent on source code level customization. Therefore these application vendors should be very careful and make necessary assessment about their competency around configuration and cus- tomization before they decide to move their application to the SaaS delivery model. We introduced the configuration and customization competency model with sev- eral major perspectives to be studied for a SaaS application in section 4.2. These perspectives can be categorized into 6 groups: data structure and processing, organi- zation structure, user interface, workflow, business rule and reporting. This model can be used to assess the competency of the existing software application from configura- tion and customization aspect. As illustrated by an example in Fig. 14, a benchmark study can also be conducted to compare with market leader’s competency so as to clearly identify competency improvement goals. This study does not mean that every SaaS vendor should improve the competency to the higher level from every perspec- tive. If a vendor’s application is pretty similar with other existing SaaS services on the market from function aspect, then higher level configuration and customization com- petency can help the vendor to get stronger competitive advantages. Fig. 14. Competency Assessment and Gap Analysis Identify Gaps and Actions. Through the competency benchmark study, the compe- tency gaps can be identified to guide the actions’ definition. The example in Fig. 14 shows the gaps and improvement goals especially in user interface and reporting perspectives. With the analysis in section 3, the competency improvement goal could be further developed into specific actions. For example, to improve the configuration and customization capability for reporting function of the application, the actions need to be identified to support “Add/Change dataset”, “Add/Change query rules” and “Add/Change report style (chart, table, graph)”. If we go through every configu- ration and customization perspectives according to figure 3, we can generate a long list of actions which implies very complex design challenges for the SaaS application.
- 38. 22 C.-J. Guo et al. It is critical to have well designed principals and approach to tackle all the actions in a unified and consistent way. As we discussed in table 2, there are different approaches which can enable differ- ent competency level requirements. Parameterized Configuration can enable “Aware” level variance through setting pre-defined parameters and options by end user in the runtime environment. Self Serve Configuration tool leverages an application variance metadata framework and a series of simple point-and-click wizards, users can design custom user interfaces and modify the structure of the data model and the applica- tion’s business logic (workflow, business rules, etc). But the scope of configuration is constrained by the metadata framework. Scripting based programming, a version of end-user programming, allow for larger scope customization by the end user by ex- tending the features of the tool using a constraint scripting language to guarantee security and avoid script generated damage to the core application. World Class SaaS service make their application coupled with a development environment and a formal programming model that can be used by user to build new application code or modify compiled code to match their requirements. Different SaaS vendors take different approach and develop their own implementations. [19] There is not a generic and platform independent approach for SaaS vendors to use today. There is a strong op- portunity for research activities. 5 Service Lifecycle Management 5.1 SaaS Service Lifecycle Overview Generally speaking, SaaS has a different lifecycle compared to a traditional software product. The stages like requirements analysis, development and testing are still very fundamental; however, new activities are required in addition. The following figure shows an overall SaaS lifecycle. Fig. 15. An Overall SaaS Lifecycle After a software application has been developed and deployed, it needs to be pack- aged by defining business terms, applying billing policies, and so on before it’s ready to be subscribed to as a service offering by a customer. There are multiple ways to subscribe, including self-service or subscription via service reseller or operator. If a customer successfully subscribes to a service offering, then users can be authorized to access it. Based on metered usage information the customer will be billed periodically. Usually, feedback and analysis are essential steps to further improve a software appli- cation or customer service. In real practice, the lifecycle may be different from the complete one showed above (e.g., there’s a certain kind of SaaS, which is developed and consumed via the Web
- 39. Study of Software as a Service Support Platform for Small and Medium Businesses 23 where no explicit deployment step is required). Another example is customer triggered provisioning, which occurs when one service is very popular and being subscribed to by a large number of customers. Additional deployments may be required to ensure a reasonable response time and satisfied customers. 5.2 Service Subscription Model Subscription instantiates a service offering by providing customer-specific billing policy parameters and service level configurations. A service authorization is given based upon the subscription result and governing constraints or rules. For example, the maximum number of users is specified at subscription time and becomes a constraint for authorization. To separate the concerns and build a flexible connection between software imple- mentation and business operation, we refine the concept of service into a service ele- ment and a service offering in a general SaaS context. Fig. 16 shows the subscription model, and the key entities are described as follows. Š Software application is the deployment unit, and one application contains one or more service elements. Š Service element is the access and metering unit. There may be dependencies be- tween service elements, and optionally, a service element has targeted customer types. Š Service offering is the subscription unit packaged from a service element, and business terms and billing policies are defined for a service offering. Subscription enables a tenant to register for a service offering, while authorization gives a user to access a service instance. Here the service instance is generated from the subscription, and it is actually the instance of a service element. The subscription model congregates different types of considerations around the entities of software application, service element and service offering, thus building a solid foundation for SaaS subscription management. But in real practice, the relation- ships among these entities and the ecosystem roles can be very complex, especially as the SaaS area evolves. Based on our in-market practice and study, we summarize the relationships into two groups of patterns, service structure and business interaction, which focus on connections among key entities and interactions among ecosystem roles, respectively. Fig. 16. SaaS Subscription Model
- 40. 24 C.-J. Guo et al. Subscription requirements provide input for pattern selection, as shown in Fig. 17. After both groups of patterns have been decided, they will be composed to get the final subscription design. More than one pattern can be selected for each group. If a conflict arises upon composing service structure patterns and business interaction patterns, either business- or technical-oriented requirements/pre-conditions should be adjusted. As an example, the application and service element may need to be re- engineered to support certain business interaction patterns. Fig. 17. Pattern-based Approach Service Structure Patterns. Service structure patterns are described as following several categories: Š Single Service: Service offering contain only one service element, which must be selected when subscribing Š Independent Multiple Services: Service offering contains more than one service elements. One or more of them can be selected when subscribing. There’s no de- pendency between any two of them. Š Dependent Multiple Services: Service offering contains more than one service elements. There are dependencies between service elements. And if one service element has been selected when subscribing, then the service elements it depends on must be selected. Š Composed Service: Service offering is composed of more than one service offer- ings. And the service elements of each offering are implemented respectively. Š Proxy Service: Service offering O1 has more than one service elements. One (or more) of them is from another service offering O2. And O1 and O2 are owned by different providers. This pattern becomes even more complex when there are de- pendencies between service elements of O1. For space reasons, we purposely have not included the problem and example sections for each pattern. To give one example, consider the case of the Dependent Multiple Services structure pattern. In a transaction based application like order management, reporting is a useful function built on top of the transaction history. When delivered as a SaaS, the Dependent Multiple Services pattern accurately describes this structure, and puts constraints for subscription in a systematic way.
- 41. Study of Software as a Service Support Platform for Small and Medium Businesses 25 The process of selecting a service structure pattern is shown in Fig. 18 as a non- exclusive decision tree. It can be visited more than once to decide related patterns. To illustrate, when packaging service offerings from another provider, both Proxy Service and Composed Service patterns can be selected. Fig. 18. Service Structure Pattern Selection Business Interaction Patterns. Typical business interaction patterns are described as followings: Š Self-Service: Customers directly subscribe to service offering from service provider. Š Hub-Spoke:The hub customer subscribes to service offering from provider and the spoke customers subscribe to service offering from the hub customer. (Or the hub customer subscribes to service offering on behalf of spoke customers.) Š Distribution: The reseller subscribes to service offering from provider and the customers to service offering from the reseller. (Or the reseller subscribes to ser- vice on behalf of the customers.) Š Delegated: The provider subscribes to service offering from another provider on behalf on its customers. (This usually happens together with the proxy structure pattern.) After subscription, the provider is authorized to sell the corresponding service offering. The runtime results for subscription actions are included. E.g. in the Distribution pat- tern, a reseller subscribes to a service offering from a provider, and in turn, customers subscribe to the service offering from the reseller. The permanent result at runtime is
- 42. 26 C.-J. Guo et al. both the reseller and the customers will obtain related privileges of the corresponding service offering. We also describe the selection of business interaction patterns in Fig. 19. This is a degenerate decision tree and all the patterns can be selected as long as the proposed conditions can be satisfied. Fig. 19. Business Interaction Pattern Selection 5.3 Case Study: Service Subscription of the Retail B2B Case We apply the pattern-based design approach for subscription management in a real case in this section. A retail Business to Business (B2B) service is an industrial appli- cation to facilitate the interaction between a retailer and its suppliers via web. There are three main functional modules: retailer’s portal (RP), supplier’s portal (SP) and Trans- action Notification (TN). RP and SP depend on each other with two-way data ex- change, and TN depends on either RP or SP as a data source. When delivered as a SaaS, SP and RP can be charged by service period while TN is more suitable to adopt quantity-based charging model. The provider in this context has a strong sales channel network and provides very limited direct customer service support. With pre-conditions stated above, we can first decide the service structure. RP and SP serve specific customers respectively, and although user of TN is not restricted by customer type, TN fits a different metering method from RP and SP. Thus, we can get the following structure by selecting Dependent Multiple Services pattern, and the graphic representation is shown in Fig. 20. In the retail industry, usually, one retailer has hundreds or thousands of suppliers, and it’s the anchor customer for the retail B2B service. But since a provider has limited customer service capability, we can only select the Distribution pattern for business interaction, which means the provider depends on resellers to get customers. If the provider offers (or wants to build) direct customer service, then, the Hub-Spoke pattern can also be adopted, and accordingly. Both patterns are workable, and the retailer and its suppliers finally get their required services. But the business relationship and the follow-up service operation are totally different. In the Hub-Spoke model, a total billing report will be issued from the provider to the retailer. And the retailer collects a service fee from the suppliers. While in the Distribution model, a third party customer service company (reseller) is introduced, who will deal with retailer and suppliers for billing and other customer interactions. The provider no longer directly touches either the retailer or the suppliers anymore. Based on different business considerations, dissimilar decisions will be made.
- 43. Study of Software as a Service Support Platform for Small and Medium Businesses 27 Fig. 20. Service Structure for Retail B2B Service 6 Related Work In the hosted applications of the early 90s [20][21], companies only moved their hardware and applications from their premises to the data centers, and paid a premium to have their applications hosted. This was a typical single-tenancy scenario without any hardware or software sharing. To reduce the operation cost, some hosting service providers [22] started to run multiple application instances with the same code base on a shared hardware or software infrastructure. In fact, many such technologies [23] are applicable to support the multi-tenant pattern including partition, virtual OS, re- sources partitions, and virtual middleware server. To achieve more benefits from the concept and practice of the shared efficiency, pioneers in this domain started building their solutions of hosted applications around the multi-tenancy rather than simply leveraging the on-premise application hosting model. [21] In recent years, the native multi-tenancy model, as exemplified in SaaS [24][25][26][27][28], achieves great successes. However, most of them are specific applications or application types such as CRM. [25][28] Fred & Gianpaolo studied the similar topics [9][29]. They provided a high-level description of the architecture of a SaaS application, and discussed the challenges and benefits of developing and offering SaaS. Their work mainly focused on the multi- tenant data model from the security and scalability perspectives. There are already some studies [23] on the tradeoffs of resources utilization and isolation. The authors of [30][ 31] introduced the OS level performance isolation mechanisms, by leveraging the reservation or partition technologies on system resources. White and Miles [13] presented four principles on fault tolerance and availability to deal with the fault isolation issues. As for the customization and configuration, there are many academic research and industrial best practices available already. For example: Software Configuration Man- agement theory was developed by Roger Pressman through software engineering research[32]; SAP software applications have strong configuration and customization capabilities through Graphic User Interface(GUI) based tool and script based pro- gramming tool(ABAP)[33]. The leading SaaS vendors have developed profound configuration and customization capabilities as well, for example, Salesfoce.com provides Apex to facilitate the extensive application configuration and customization on the Web based on the multi-tenancy architecture. [34] In the telecommunications industry, subscription information is the basis for service life cycle management. For example, to handle the relationships and interactions among a service user, subscriber and retailer, the Telecommunication Information Networking Architecture (TINA) specifies a subscription management information model [35], and also related service components [36]. Lee et al. provide a three-tier CORBA based framework to implement a service subscription information management system in a TINA environment [37]. Compared with a general publish/subscription system, research
- 44. 28 C.-J. Guo et al. and practice in this area are more concerned with the service subscription process and data model in the telecommunication industry context. Subscription management for Web services is mainly concerned with issuing event notifications and handling the communication between two parties, the subscriber and the registry. For example, Uni- versal Description Discovery and Integration (UDDI) introduces a type of entity called subscription in its information model for a service requestor to keep track of changes of other UDDI entities like businessEntity, businessService, and so on [38]. UDDI defines corresponding application protocol interface (API) sets to handle the interaction be- tween a subscriber and a registry in both synchronous and asynchronous models. Liu et al. introduces a “consumer centric” service discovery and subscription approach based on the concept of Community-of-Interest (CoI) [39][40]. CoI is a collection of several services with similar functionalities and different qualities of service (QoS). In a CoI model, the subscriber does not communicate with any individual service directly, in- stead, it interacts with CoI which is responsible for scheduling the subscription to real target service providers dynamically to achieve the best choice for either QoS or another objective. Mietzner et al. propose multi-tenancy patterns and variability descriptors to package multi-tenancy aware configurable composite SaaS applications, based on Ser- vice Component Architecture (SCA) [41]. They study service structure from a con- figurability perspective, and subscription is not explicitly covered. 7 Summary As more people are diving deep into the market, the SMBs oriented SaaS evolves gradually into a complex ecosystem. It involves many stakeholders with different requirements and value propositions, such as customer (tenant), service provider, service (software) vendor and value-added service reseller and so on. This paper tar- gets to explore the technologies to set up a healthy and profitable SaaS ecosystem to operate many SaaS applications recruiting from service vendors for a huge number of SMB customers. According to the customer requirements and experiences we accu- mulated via real customer engagement, this paper focuses on exploring three most important challenges of the ecosystem, e.g. massive multi-tenancy, flexibility and service lifecycle management, and the corresponding technical solutions. First, this paper introduces how to leverage the massive multi-tenancy technologies to achieve the cost effectiveness by effectively sharing resources of the infrastructure, middleware and application instance among tenants. Due to the essential tradeoff between the high shared efficiency and isolation among tenants, we also explore many approaches to support better security, performance and availability isolation in the multi-tenant environments. Configuration and customization are the critical perspectives for SaaS vendors to design their offerings to satisfy as many customers’ requirements as possible in the targeted customer segment and application domain In this paper, we clarified the concepts of configuration and customization in SaaS context, and introduced compe- tency model and a framework to help SaaS vendors to plan their offerings from con- figuration and customization enablement point of view. This paper also explores the topics on service lifecycle and the subscription manage- ment design of SaaS. We present a method which can guide a SaaS provider in designing subscription management according to its application’s characteristics and targeted busi- ness model. Structure pattern and interaction pattern are the key components of this
- 45. Study of Software as a Service Support Platform for Small and Medium Businesses 29 method which are summarized from various types of SaaS businesses. Finally, we also leverage a case study to demonstrate the effectiveness of the method. References 1. Sun, W., Zhang, K., Chen, S.-K., Zhang, X., Liang, H.: Software as a service: An integra- tion perspective. In: Krämer, B.J., Lin, K.-J., Narasimhan, P. (eds.) ICSOC 2007. LNCS, vol. 4749, pp. 558–569. Springer, Heidelberg (2007) 2. Guo, C.J., Sun, W., Huang, Y., Wang, Z.H., Gao, B.: A Framework for Native Multi- Tenancy Application Development and Management. In: The 9th IEEE International Confer- ence on E-Commerce Technology and the 4th IEEE International Conference on Enterprise Computing, E-Commerce, and E-Services, pp. 551–558. IEEE Press, Tokyo (2007) 3. How SMBs Can Save Money Using SaaS, http://itmanagement.earthweb.com/features/article.php/ 3803136/How-SMBs-Can-Save-Money-Using-SaaS.htm 4. Microsoft Sees Growing SaaS Opportunity Among SMBs, http://www.pcworld.com/businesscenter/article/161925/ microsoft_sees_growing_saas_opportunity_among_smbs.html 5. The Cloud Wars: $100 billion at stake. Technical Report, Merrill Lynch (2008) 6. WikiPedia, http://en.wikipedia.org/wiki/Value-added_reseller 7. Youshang.com, http://www.youshang.com/en/compare.html 8. Build A Multi-tenant Data Tier With Access Control and Security, http://www.ibm.com/developerworks/db2/library/techarticle/ dm-0712taylor/ 9. Multi-Tenant Data Architecture, http://msdn.microsoft.com/en-us/library/aa479086.aspx 10. WikiPedia, http://en.wikipedia.org/wiki/SQL_injection 11. DB2 Label-Based Access Control, a practical guide, Part 1: Understand the basics of LBAC in DB2, http://www.ibm.com/developerworks/edu/ dm-dw-dm-0605wong-i.html 12. Urgaonkar, B.: Dynamic Resource Management in Internet Hosting Platforms. Doctoral Thesis, University of Massachusetts Amherst (2005) 13. White, R.V., Miles, F.M.: Principles of Fault Tolerance. In: Applied Power Electronics Conference and Exposition, pp. 18–25. IEEE Press, San Jose (1996) 14. Sun, W., Zhang, X., Guo, C.J., Sun, P., Su, H.: Software as a Service: Configuration and Customization Perspectives. In: Congress on Services Part II, 2008. SERVICES-2, pp. 18–25. IEEE Press, Beijing (2008) 15. Jiang, Z., Sun, W., Tang, K., Snowdon, J.L., Zhang, X.: A Pattern-based Design Approach for Subscription Management of Software as a Service. Technical Report, IBM China Re- search Lab (2009) 16. Summit Strategy Inc., Software-Powered Services Net-Native Software-as-Services Transforms the ISV Business Model. Technical Report 17. Rohleder, C., Davis, S., Günther, H.: Software Customization With XML. Issues in Infor- mation Systems VI(2) (2005) 18. Summit Strategy Inc., Software Powered Services Net Native SaS Transforms The Enter- prise Application. Technical Report 19. Datamonitor ComputerWire, SaaS Customization. Technical Report
- 46. 30 C.-J. Guo et al. 20. Gray, T.: Application Service Provider - A new way of software application delivery. Melbourne (2002) 21. Gianforte, G.: Multiple-Tenancy Hosted Applications: The Death and Rebirth of the Soft- ware Industry. RightNow Technologies Inc (2005) 22. Kobilsky, N.: SAP CRM On-demand. SAP Forum (2006) 23. BEA Weblogic Application Consolidation Strategies, http://dev2dev.bea.com/pub/a/2003/10/Heublein.html 24. Software as a Service (SaaS): An Enterprise Perspective, http://msdn.microsoft.com/en-us/library/aa905332.aspx 25. Salesforce.com Corporation, http://salesforce.com 26. Waters, B.: Software as a service: A look at the customer benefits. Journal of Digital Asset Management 1(1), 1 (2005) 27. Software as a Service (SaaS) Resource Center, http://www.deitel.com/softwareasaservice/ SoftwareAsAService_ResourceCenter_Articles.html 28. Rightnow Technologies Inc., http://www.rightnow.com/products/ 29. Architecture Strategies for Catching the Long Tail, http://blogs.msdn.com/gianpaolo 30. Verghese, B., Gupta, A., Rosenblum, M.: Performance isolation: sharing and isolation in shared-memory multiprocessors. In: Proceedings of the 8th Conference on Architectural Support for Programming Language and Operating Systems, San Jose, pp. 181–192 (1998) 31. Pérez, C.O., Rutten, M., Steffens, L., van Eijndhoven, J., Paul Stravers, S.: Resource Res- ervations in Shared-memory Multiprocessor SOCS. Philips Research Laboratories, Tech- nical Report, Eindhoven, The Netherlands 32. Pressman, R.: Software Engineering: A Practitioner’s Approach. McGraw-Hill Science, New York 33. Getting Started: ABAP, SAP Community Network, https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/ webcontent/uuid/90e7556d-ed76-2910-1592-b6af816225cc 34. Introduction to the Apex Platform, http://salesforce.com 35. TINA 1.0 Specification, Service Component Specification Computational Model and Dy- namics Version 1.0b (1998), http://www.tinac.com/specifications/documents/comp.pdf 36. TINA 1.0 Specification, Overall Concepts and Principles of TINA Version 1.0 (1995), http://www.tinac.com/specifications/documents/overall.pdf 37. Lee, J.C.-K., Mohapi, S., Hanrahan, H.E.: Service Subscription Information Management in a TINA Environment using Object-Oriented Middleware. In: Intelligent Network Work- shop, pp. 121–125. IEEE Press, Los Alamitos (2001) 38. UDDI V3.0.2, http://www.oasis-open.org/committees/uddi-spec/doc/ spec/v3/uddi-v3.0.2-20041019.htm 39. Liu, X.Z., Zhou, L., Huang, G., Mei, H.: Consumer-Centric Web Services Discovery and Subscription. In: IEEE International Conference on e-Business Engineering, pp. 543–550. IEEE Press, Hong Kong (2007) 40. Liu, X.Z., Huang, G., Mei, H.: Towards Service Discovery and Subscription based on Community-of-Interest. In: Proceedings of the Second IEEE International Symposium on Service-Oriented System Engineering, pp. 167–174. IEEE Press, Washington (2006) 41. Mietzner, R., Leymann, F., Papazoglou, M.: Defining Composite Configurable SaaS Ap- plication Packages Using SCA, Variability Descriptors and Multi-Tenancy Patterns. In: Third International Conference on Internet and Web Applications and Services, pp. 156– 161. IEEE Press, Los Alamitos (2008)
- 47. D. Agrawal et al. (Eds.): Information and Software as Services, LNBIP 74, pp. 31–56, 2011. © Springer-Verlag Berlin Heidelberg 2011 Design Patterns for Cloud Services Jinquan Dai and Bo Huang Intel China Software Center No. 880 Zi Xing Road, Shanghai, P.R. China, 200241 {jason.dai,bo.huang}@intel.com Abstract. The transition to cloud computing is a disruptive trend that poses huge challenges to the software and service architecture. There are dramatic dif- ferences between delivering software as services in the cloud for millions to use through their occasionally disconnected clients, versus distributing software as bits for millions to run on their PCs. In particular, cloud services need new de- sign patterns and programming models for their partitioned data set with many copies that are independently changed. This is a huge software challenge and a major barrier to the adoption of cloud computing. For instance, big websites spend 70% of their efforts on the undifferentiated heavy lifting (e.g., partition- ing, replication and scaling) versus 30% on the differentiated value (feature) creation. This chapter will review the challenges for cloud services and some of the emerging solutions to address those challenges, based on our experience in building cloud service platforms as well as the industry best practices. Keywords: cloud computing, cloud service, scalability, availability, reliability, design patterns, service architecture. 1 Introduction The transition to cloud computing is a disruptive trend that poses huge challenges to the software and service architecture. There are dramatic differences between deliver- ing software as services in the cloud for millions to use through their occasionally disconnected clients, versus distributing software as bits for millions to run on their PCs. First, services must be highly scalable, supporting millions of concurrent users at peak. Second, services must have low latency, minimizing the wait time of users. Third, services must be always available, even in times of server or network failures. Fourth, services can evolve much more quickly (with, say, weekly or bi-weekly re- leases) than packaged products, because they only run inside the cloud. Those re- quirements have two important implications on the underlying software as follows. • The data center is the computer In order to meet the requirements of high scalability, high availability and low la- tency, services are developed to run on mega data centers [1], as opposed to shrink-wrapped software running on individual PCs. The data centers have a scale- out shared-nothing architecture (made up of tens of thousands of independent, commodity servers) and are geographically distributed. And there is also a move to
- 48. 32 J. Dai and B. Huang many small, cheap, independent and less reliable data centers (e.g., containerized data centers [2] [3]) that are geo-distributed, for the sake of cost and energy effectiveness [4]. In this model, cloud services can achieve high scalability only through partition- ing, and achieve high availability only through redundancy. Therefore, services need to be architected to have their data and computing partitioned among inde- pendent servers, and to have their data (asynchronously) replicated across inde- pendent servers and data centers. • The application is always offline Despite the increasingly ubiquitous wireless connectivity, clients will be occasion- ally disconnected. In addition, due to ubiquitous service compositions (e.g., SOA and service APIs), data integrations (e.g., mashup and widget), as well as data rep- lications across multiple servers and data centers, remote services and data will be occasionally unavailable to the applications (either in the cloud or on the clients). If those applications have to wait for the remote services and data when discon- nected, cloud services will be extremely slow and have low availability. Therefore, the application needs to work with an assumption that it is always offline, by mak- ing progress based on its local states as much as possible (e.g., using Google Gears [5] that provides an environment for web applications to run offline or Microsoft Sync framework [6] that automatically synchronizes data between clients and ser- vices), and by interacting with remote partners asynchronously to reconcile their states. In summary, cloud service platforms are drastically different from traditional distrib- uted systems. The classic definition of a distributed system is a “collection of inde- pendent computers that appear to the users of the system as a single computer” [7]. Traditionally, efforts in this area (such as distributed transactions, quorum protocols, atomic broadcast, RPC, synchronous request-response, and tightly coupled schema) all attempt to mask the existence of independence from the applications. On the other hand, cloud computing is composed of, and more importantly, acknowledges the existence of many small, independent, and unreliable components (e.g., clients, serv- ers, data centers and services) that may be occasionally disconnected. Consequently, cloud services need new design patterns and programming models for the partitioned data set with many copies that are changed independently [8]. This is a huge software development challenge and a major barrier to the adoption of cloud computing. For instance, developers of big websites usually spend 70% of their ef- forts on the undifferentiated heavy lifting (e.g., partitioning, replication and scaling) versus 30% on the differentiated value (feature) creation [9]. This chapter will review the challenges for cloud services and some of the emerging directions for solutions to address those challenges, based on our experience in building cloud service platforms as well as the industry best practices. The rest of the chapter is organized as follows. Section 2 describes how the cloud services manage their partitioned data set using the new data model. Section 3 re- views the computing models adopted by cloud services to distribute their computa- tions across many independent servers. Section 4 discusses the challenges for cloud
- 49. Design Patterns for Cloud Services 33 service to manage distributed agreement across many independent components and how those challenges can be addressed. Section 5 describes how to cope with the inconsistency across multiple data replicas in cloud services using relaxed consistency models. Finally, section 6 concludes the chapter with possible future works for both the industry and the academic community. 2 Data Model Traditionally, enterprise systems store their data in relational databases. However, the complex management, general querying and transaction support offered by an RDBMS is overkill for most of the service applications. This excess functionality results in high performance penalty, expensive hardware and highly skilled personnel for operations, making it a very inefficient solution. In addition, traditional distributed relational database systems focus on providing a complete relational model with transactional (ACID) consistency to the partitioned and/or replicated data, and are therefore limited in scalability and availability [10]. Although many advances have been made, it is still difficult to scale-out databases or use smart partitioning and replication schemes. Many big websites have to build their own (semi-) structured data storage systems from scratch (e.g., Google’s Big- table [11] system, Amzon’s Dynamo [10] system and Yahoo’s PNUTS [12] system); and others just use the traditional RDBMS as dumb row stores and build their own access and management logics above the databases (e.g., the eBay architecture [13], sharding in MySpace [14] and Flickr [15], and Microsoft SQL data service [16]), as illustrated in Fig. 1. Web/App Server Global lookup DB cluster db#0 25% of users (1) where is user#168? (2) db#2 (3) get user#168 (4) return user#168 db#1 25% of users db#2 25% of users db#3 25% of users Fig. 1. In this simple example of data access layer (above traditional databases), each of the servers (db#0 – db#3) contains a subset of the user profiles. When the web server needs to access the profile of user#168, it first looks up the profile location, which is stored at the global lookup DB cluster. After the location (server db#2 in this example) is determined, the web server can directly go to server db#2 for the profile.
- 50. 34 J. Dai and B. Huang 2.1 Requirements of Cloud Services Cloud services need a new data model to deal with their unique requirements and challenges as follows. • Data partitioning In cloud services, data are usually horizontally partitioned along primary access paths [19] [20] (e.g., by individual users), and spread around independent servers. For instance, Fig. 2 illustrates the horizontal partitioning of databases in the eBay architecture [13]. Therefore, the new data model should allow the programmers to express the data partitioning as a program abstraction, and to design the applica- tions around collections of partitioned data. Fig. 2. eBay horizontally splits its databases (e.g., user and category tables) into individual shards, which are standalone database servers containing a slice of the main database • Dynamic schema Cloud services need to both evolve quickly and provide high availability; conse- quently changes to the data schema need to be handled seamlessly in a system run- ning 24 by 7, 365 days a year. Therefore, the new data model should allow the schema of objects to be flexibly defined and dynamically changed. For instance, in Amazon SimpleDB [21], data are organized into domains that are collection of items described by attribute-value pairs; conceptually, a domain is analogous to a relational table with each item corresponding to a row and each at- tribute corresponding to a column. However, unlike traditional databases, Amazon SimpleDB has a much more flexible data schema, as illustrated in Fig. 3.
- 51. Design Patterns for Cloud Services 35 Name (1) createDomain (“product”); - An “product” domain is create - The domain is initially empty - Only the “Name” attribute is required Name item1 Category sweater Color blue, red (2) putAttribute (domain=>“product”, Name=>”item1”, Category=>”sweater”, Color=>”blue”, Color=>”red”, Size=>”small”); - An new item “item1” is added - New attributes “Category”, “Color” and “Size” are added - Multiple values are associated with the “Color” attribute Name item1 Category sweater Color blue, red (3) putAttribute (domain=>“product”, Name=>”item2”, Category=>”shoes”, Color=>”black”, Size=>”9”, Material=>”leather”); - An new item “item2” is added - Values of different types are associated with the “Size” attribute of “item1” and “item2” - New attributes “Material” is added to “item2” only Size small Size small item2 shoes black 9 leather Material Fig. 3. Amazon SimpleDB has a very flexible schema. New attributes can be dynamically added on the fly and only associated with specific items, multiple values can be associated with an attribute of an item, and two items in the same domain can have different types of values for the same attribute. • Local transaction (only) In cloud services, distributed transactions (including techniques such as two-phase commit, Paxos, and quorum protocols) are not used, due to their performance cost and fragility [20] [22]. Therefore, the new data model should enforce that only lo- cal transactions (within a node) can be used and that distributed transactions are not allowed. For instance, in Google Megastore [23] [24] each data object is known as an en- tity and each entity have a parent entity. Consequently entities forms a forest of trees through their parent-relationship, and all entities in the same tree (i.e., with
- 52. 36 J. Dai and B. Huang the same root entity) belong to the same entity group. All entities in a group are stored in the same Megastore node, and a single transaction can only operate enti- ties in the same entity group. • Incremental scaling In cloud services, the size of the data manipulated by the applications grows sig- nificantly large over time. What previously fits in one machine may need to be re- partitioned to multiple machines later. Therefore, the new data model should allow the applications to scale incrementally (i.e., one machine at a time), by dynami- cally spreading the data in a small set of machines to a larger set as the load grows and new machines become available. 2.2 New Data Model: Uniquely Keyed Elements Typically the new data model for cloud services comprises a collection of uniquely keyed elements [22], as described in detail below and illustrated in Fig. 4. 1) Each element represents a disjoint set of data (which are typically described as property-value pairs and whose properties may be dynamically changed). An application comprises many elements; for instance, a web application usually supports many users, and each user can be represented as an element identified by the unique user ID. 2) All the data within a single element is guaranteed to reside on a single machine (ignoring replication); different elements may be located in different machines. That is, the data set of the application is partitioned around those uniquely keyed elements. 3) The application locates a specific element through its unique key. The physical location of the element is determined by the lower layer (e.g., the data store), and is likely to change as the requirement for scaling changes and the deploy- ment evolves. Therefore, the application cannot make assumptions about the lo- cations of elements, except that a single element is guaranteed to reside on a single machine. 4) The application can only perform atomic transactions within a single element. Transactions cannot span multiple elements, because there is no guarantee that they will reside on the single machine all the time In summary, the data model for cloud services requires that the service has the notion of element as a programming abstraction, designs its business logic and data set around the collection of elements, uses the unique key to locate a specific element, and assumes lack of atomicity across different elements. This data model is implicitly adopted by many Internet-scale services in the industry today (such as Amazon Sim- pleDB [21], Google MegaStore [23] [24], Microsoft Windows Azure table storage [25] and Microsoft SQL data service [16]).
- 53. Design Patterns for Cloud Services 37 Each element resides on a single machine, and its specific location is determined by lower layer db2 db1 user1 ... user2 ... item1 ... user3 ... item3 ... item2 ... db2 db1 user1 ... user2 ... user3 ... item3 ... db3 item2 ... item1 ... user1 ... user2 ... user3 ... item1 ... item2 ... item3 ... Application data comprise many elements key = “user1” key = “item2” Application logics manipulate a collection of elements through the unique keys Lower layer may re- partition elements Physical storages of elements today Physical storages of elements tomorrow Keys are mapped to physical locations of elements Fig. 4. The application’s data are factored into elements, each of which has a unique key. The lower layer guarantees each element always resides on a single machine; however, it may re- partition the elements as requirements for scaling change. 2.3 Data Access in the New Data Model An element is just a logical concept that represents a disjoint set of data; those data can be stored in any form that is appropriate for the service, such as SQL records (possibly across many tables). The partitioning should be as fine-grained as possible because the underlying data store will never split an element. On the other hand, data querying patterns should also be taken into considerations during the data par- titioning, as some data accesses are very challenging to support in the new data model.
- 54. 38 J. Dai and B. Huang • Primary-key based access Primary-key based access to records is not only predominant for cloud services, but also the most efficient and preferred way in the new data model, as long as the primary key includes the unique identifier of the element that contains the record (e.g., the primary key of every record that belongs to a user element may contain the unique user ID). • Simple queries It is also straightforward to efficiently support some simple forms of queries in the new data model, especially those against a specific element (and preferably over some indexed fields). • Arbitrary, ad-hoc queries On the other hand, it is very challenging, if not impossible, to support arbitrary, ad- hoc queries in the new data model, especially those that can potentially access an arbitrary number of elements (e.g., finding all the users whose birthdays are today where each user is an individual element). In general, it is unclear what the most efficient way is to support this type of queries. One possible implementation of such queries is through distributed query; that is, (partial) queries are sent to all the nodes which then return partial results to a central place to assemble the final result. Unfortunately, distributed query is lim- ited in performance and scalability as the data set grows in size. An alternative implementation is two-level lookup through alternative indices; that is, identifiers of the elements containing the records are first determined by looking up an alternative index and only those elements are then queried. Since all elements or servers are not queried, two-level lookup usually has better perform- ance and scalability; however, the service needs to deal with the potential inconsis- tency as the alternative index can get out-of-sync with the element data [22]. In practice, only a predefined, business critical subset of those ad-hoc queries will be supported for the service. For instance, social network services usually need to solve the hairball problem [26]. That is, those services need to organize the per- user information (e.g., groups that a user belongs to) as an individual element so that they can efficiently access such information by the user ID; on the other hand, they also need to access the per-user information by searching for the data to find the users (e.g., all the users belonging to a given group). Those predefined queries are typically supported through extensive use of prepared statements and bind vari- ables [13], and through data demornalization [15] (that is, storing data redundantly along all primary access paths, usually in an asynchronous manner). For instance, in FriendFeed [27] data are stored as JSON objects with unique IDs in the primary database tables, which are then horizontally partitioned based on the primary keys. In order to efficiently access these data by searching on a secon- dary property, a separate “index” database table is created and asynchronous up- dated to contain the mapping between the secondary property and the unique ID
- 55. Random documents with unrelated content Scribd suggests to you:
- 56. Grapsidæ, 241, 281. Grass sponge, 104. Grateloupia, 78, 94. G. Cutleria, 78, 94. Grateloupieæ, 78, 94. Green glands, 246. Griffithsia, 15, 29, 78, 91. G. Bornetiana, 78, 91. G. corallina, 29. Grinnellia, 29, 77, 86. G. Americana, 29, 77, 86. Gymnogongrus, 76, 82. G. Norvegicus, 76, 82. Gymnolæmata, 188, 193. H Halcyonoida, 141, 150. Halcyonoids, 142. Halichondria, 100, 107. H. panicea, 100, 107. Halidrys, 63, 73. H. osmunda, 63, 73. Halimeda, 51, 58. H. opuntia, 51, 59. H. tridens, 51, 59. H. tuna, 51, 58. Haliotidæ, 324, 358. Haliotis, 9, 312, 324, 358. H. cracherodii, 324, 359. H. rufescens, 324, 359. H. splendens, 324, 359. Haliseris, 63, 71. H. polypodioides, 63, 71. Halosaccion, 78, 95. H. ramentaceum, 78, 95. Halymenia, 78, 94. H. ligulata, 78, 94. Haminea solitaria, 324, 351. Harmothoë, 161, 174. H. imbricata, 161, 174.
- 57. Heart, 416. Heart and vascular system, 341. Heart-urchins, 218, 226. Heliaster, 204, 205, 212. H. multiradiata, 204, 212. Heliasteridæ, 204, 212. Helipora, 147. Helmet-shells, 380. Helminthocladieæ, 76, 79. Hemigrapsus, 241, 281. H. nudus, 241, 281. H. oregonensis, 241, 281. Hemimyaria, 472. Herbarium, 17. Hermit-crabs, 12, 258, 259, 264, 362. Heterocœla, 100. Heterograpsus nudus, 281. H. oregonensis, 281. Heterorrhaphidæ, 100. Hildenbrandtia, 78, 95. H. rosea, 40, 78, 95. Himanthalia, 63, 71. H. lorea, 63, 71. Hippa, 10, 240, 268. H. analoga, 240, 269. H. talpoida, 10, 11, 240, 268. Hippasteria, 204, 209. H. phrygiana, 204, 209. Hippidæ, 240, 268. Hippoconcha, 240, 264. H. arcuata, 240, 264. Hippospongia, 100, 108. H. canaliculata, 100, 108. H. canaliculata, var. flabellum 100, 109. H. canaliculata, var. gossypina, 100, 108. H. equina, 100, 108. H. equina, var. agaricina, 108. H. equina, var. cerebriformis, 100, 108. H. equina, var. dura, 108. H. equina, var. elastica, 100, 108. H. equina, var. meandriformis, 100, 108.
- 58. Hircinia, 100, 109. H. campana, 100, 109. Histology, 20. Holdfasts, 26. Holocampa, 141, 145. H. producta, 141, 145. Holothuria edulis, 232. Holothurians, 202, 203. Holothuroidea, 200, 228, 229. Homarus, 240, 261. H. americanus, 240, 262. H. capensis, 261. H. vulgaris, 261. Homorrhaphidæ, 100. How to arrange a herbarium, 17. Hyas, 241, 284, 285. H. araneus, 241, 285. H. coarctatus, 241, 285. H. lyratus, 241, 285. Hybocodon, 124. H. prolifer, 116, 124. Hydractinia, 116, 122. H. polyclina, 116, 122, 266. Hydrallmania falcata, 127. Hydranth, 118, 119. Hydrocorallina, 117, 129. Hydroids, 22, 114, 119. Hydrorhiza, 118. Hydrosoma, 118. Hydrotheca, 118. Hydrozoa, 112, 114, 116, 119, 120. Hypnea, 77, 84. H. musciformis, 77, 84. I Ideal mollusk, 317. Idotea, 242, 293. I. irrorata, 293. I. marina, 242, 293. I. metallica, 242, 294. I. ochotensis, 242, 294. I. wosnesenskii, 242, 294.
- 59. Idyia, 154, 157. I. cyanthina, 154, 158. I. roseola, 154, 157. Inarticulata, 188. Infusoria, 21, 101. Interambulacral areas, 201, 202, 218. Introvert, 186. Iridæa, 76, 82. Isopoda, 242, 291. Isopods, 12. J Janthina, 325, 364. J. fragilis, 325, 365. Janthinidæ, 325, 364. Jellyfishes, 7, 44, 112, 115, 119, 134. Jonah crab, 277. K Kelp, 38. Kingdom, 19. Kitchen-middens, 432. L Labial palps, 416. Labiosa canaliculata, 447. Lacuna, 309, 326, 373. L. vincta, 12, 44, 326, 373. Lady-crab, 276. Lambrus, 241, 286. L. pourtalesii, 241, 286. Lamellibranchiata, 409. Lamelliform, 303. Laminaria, 43, 63, 70. L. digitata, 44, 63, 70. L. longicruris, 63, 70. L. saccharina, 63, 70. Laminariaceæ, 31, 35, 38, 63, 64, 68. Laminarian zone, 30,31.
- 60. Larva, 201. Larvacea, 472. Laurencia, 77, 89. L. pinnatifida, 77, 89. Laver, 38. Leathesia, 62, 68. L. difformis, 41, 68. L. tuberiformis, 68. Leda, 309, 405, 422. L. tenuisulcata, 405, 422. Lepas, 239, 250, 252. L. anatifera, 239, 253. L. pectinata, 239, 253. L. striata, 239, 253. Leptodora, 238. Leptogorgia Agassizii, Plate XLVII. L. rigida, Plate XLVII. Leptoliniæ, 116, 121. Leptomedusæ, 116. Leptoplana, 160, 166. L. folium, 160, 166. Lessonia, 36, 63. Leucosolenia, 100, 106. L. botryoides, 100, 106. Liagora, 76. Libinia, 241, 284. L. dubia, 241, 284. L. emarginata, 241, 284. Ligament, 417. Limnoria, 242, 292. L. lignorum, 13, 242, 290, 292. Limpets, 9. Limulus, 242, 294. L. moluccanus, 295. L. polyphemus, 242, 294. Linerges, 133, 139. L. mercurius, 133, 139. Lines of growth, 344, 347. Lineus marinus, 167.
- 61. L. sanguineus, 168. Lingual ribbon, 303, 340. Lip, inner, 344. Outer, 344. Lithocysts, 135. Lithodes, 240, 270. L. maia, 240, 270. Lithodidæ, 240, 270. Littoral, 23. Species, 308. Zone, 30. Littorina, 9, 309, 311, 325, 338, 370. L. angulifera, 325, 372. L. irrorata, 325, 372. L. litorea, 8, 41, 42, 325, 371. L. palliata, 42, 325, 372. L. planaxis, 325, 373. L. rudis, 41, 42, 325, 371. L. scutulata, 325, 373. Littorinella minuta, 12. Littorinidæ, 325, 338, 370. Livona, 325, 362. L. pica, 268, 325, 362. Lizzia, 120. Lobata, 154, 156. Lobsters, 240, 247, 250, 258, 259, 261. Loligo, 464, 467, 469. L. brevis, 464, 469. L. Pealei, 464, 469. Lomentaria, 77, 85. L. Baileyana, 77, 85. Lophophore, 190, 193. Lophothuria, 228. L. fabricii, 228, 232. Loripes, 406, 443. L. edentula, 406, 443. Lottia, 324, 357. L. gigantea, 324, 357. Lovenia, 217, 227. L. cordiformis, 217, 227. Loxorhynchus, 241, 285. L. crispatus, 241, 285.
- 62. Lucapina, 324, 358. L. crenulata, 324, 358. Lucernaria, 133, 136. L. auricula, 133, 136. Lucina, 311, 406, 442. L. californica, 406, 443. L. dentata, 406, 443. L. floridana, 406, 442. L. nuttallii, 406, 443. L. pennsylvanica, 406, 442. L. tigrina, 406, 442. Lucinidæ, 406, 442. Luidia, 204, 209. L. alternata, 204, 209. L. clathrata, 204, 209. L. senegalensis, 204, 209. Lumbriconereis, 161, 179. L. tenuis, 161, 179. Lunatia, 12, 309, 314, 325, 367. L. heros, 10, 12, 44, 325, 367. L. lewisii, 325, 368. L. triseriata, 325, 367. Lunules, 224, 303, 418. Lyngbya, 48. L. æstuarii, 50. L. ferruginea, 50. L. majuscula, 50. M Macoma, 406, 444. M. baltica, 406, 445. M. nasuta, 406, 444. M. proxima, 406, 445. M. secta, 406, 444. M. tenta, 406, 445. Macrocystis, 35, 63. M. pyrifera, 36, 70. Macrura, 240, 258, 259, 272. Mactra, 310, 406, 410, 446. M. lateralis, 406, 447. M. ovalis, 406, 447. M. similis, 406, 447. M. solidissima, 406, 446. Mactridæ, 406, 446. Madreporic plate, 201, 203, 206, 218. Maiidæ, 241, 284. Malacostraca, 239, 257. Mandibles, 246, 258. Mantle, 303, 316, 319, 328, 331, 410.
- 63. Mantle cavity, 303, 319, 336. Mantle fusion, 412. Margarita, 309, 325, 360. M. cinerea, 325, 360. M. helicina, 12, 44, 325, 360. M. undulata, 325, 360. Margin, 417. Anterior, 417. Dorsal, 417. Posterior, 417. Ventral, 417. Marginella, 311, 327, 399. M. apicina, 327, 399. Marginellidæ, 327, 399. Marine invertebrates, 97. Maxillæ, 243, 246, 258. Maxillipeds, 243, 246, 258. Meckelia, 160, 169. M. ingens, 160, 169. M. rosea, 160, 169. Mediaster, 204, 209. M. æqualis, 204, 209. Megalops, 248, 273. Meleagrina margaritifera, 313, 430, 431. Melita nitida, 290. Mellita, 217, 225. M. testudinata, 217, 225. Melobesia, 78, 96. Melongena, 311, 327, 396. M. corona, 327, 396. Membranaceous, 27. Membranipora, 188, 192, 196. M. lineata, 188, 196. M. pilosa, 43, 188, 196. M. tenuis, 188, 197. Menippe, 241, 280. M. mercenaria, 241, 280. Meristomes, 242, 294. Mesoderm, 101, 118. Mesoglœa, 62, 68. M. divaricata, 62, 68. M. virescens, 62, 68.
- 64. Metalia, 217, 227. M. pectoralis, 217, 227. Metameres, 243. Metapodium, 376. Metazoa, 101. Metridium marginatum, 42. Microciona, 100, 107. M. prolifera, 100, 107. Microcladia, 78, 93. M. borealis, 78, 93. M. Coulteri, 78, 93. Millepora, 129. M. alcicornis, 117, 129. Mitra, 313. Mnemiopsis, 154, 157. M. Leidyii, 154, 157. Modiola, 309, 405, 426. M. modiolus, 405, 428. M. nigra, 429. M. plicatula, 405, 429. M. recta, 405, 429. M. tulipa, 405, 429. Mœra levis, 290. Moina, 238. Moira, 217, 226. M. atropos, 217, 226. Molgula, 473, 475. M. arenata, 473, 476. M. manhattensis, 473, 475. M. pellucida, 473, 476. Mollia, 188, 197. M. hyalina, 188, 197. Mollusca, 300, 305, 328. Monoceras, 312, 326, 387. M. engonatum, 326, 388. M. lapilloides, 326, 388. Monomyarian, 303, 430. Monostroma, 26, 51, 55. Monotocardia, 300, 325, 364. Morphology, 20. Moss-animals, 191.
- 65. Mother-of-pearl, 431. Moulting, 248, 259, 263. Mounting seaweeds, 16. Mouth, 329, 333. Mud-crabs, 12. Muddy shores, 12. Multivalve, 307. Murex, 326, 331, 382. M. fulvescens, 383. M. pomum, 326, 383. M. rufus, 326, 382. M. tenuispina, 343, 347. Muricea specifera, Plate XLVI. Muricidæ, 326, 381. Muricinæ, 326, 381, 385. Muscles, 248. Musical sands, 2. Mussel, great horse-, 428. Mussels, 43, 321, 426. Mya, 309, 407, 456. M. arenaria, 3, 42, 44, 311, 407, 456. Mycedium fragile, Plate XLV. Myidæ, 407, 456. Myrionema, 62, 68. Mysis, 239, 257. M. sternolepsis, 239, 257. Mytilidæ, 406, 426. Mytilus, 41, 309, 406, 426. M. californicus, 405, 428. M. edulis, 42, 43, 287, 405, 427, 428. M. hamatus, 405, 428. N Naming of plants, 28. Nanomia, 130. N. cara, 117, 130. Narcomedusæ, 117. Nassa, 3, 10, 12, 327, 335, 390.
- 66. N. fossata, 327, 391. N. mendica, 327, 391. N. obsoleta, 10, 12, 327, 390. N. perpinguis, 327, 391. N. tegula, 327, 391. N. trivittata, 10, 11, 327, 390. N. vibex, 327, 391. Nassidæ, 327, 390. Natica, 311, 325, 334, 367. N. canrena, 325, 368. N. clausa, 325, 368. N. heros, 367. Naticidæ, 325, 366. Nauplius, 248, 251. Nautilus, 328, 467. Navicula ostrearia, 435. Nekton, 23. Nemalion, 76, 79. N. multifidum, 76, 79. Nemalionaceæ, 76, 79. Nemathelminthes, 159, 161, 170. Nematoda, 161, 170. Nematophore, 118. Nemerteans, 167. Nemertes, 160, 169. N. socialis, 160, 169. N. viridis, 160, 169. Nemertinea, 160, 167. Neopanopeus, 241. N. texana, 241, 281. Nephridia, 319. Nephridium, 303. Nephthydidæ, 161, 177. Nephthys, 161, 178. N. ingens, 161, 178. N. picta, 161, 178. Nereidæ, 161, 176. Nereis, 161, 176. N. limbata, 161, 177. N. pelagica, 161, 177. N. virens, 161, 177. Nereocystis, 63, 70. N. Lütkeana, 35. Nerine, 161, 181.
- 67. N. agilis, 161, 181. N. coniocephala, 161, 181. Nerita, 325, 363. N. peleronta, 325, 363. N. tessellata, 325, 363. N. versicolor, 325. Neritidæ, 325, 363. Neritina, 311, 325, 363. N. reclivata, 325, 364. N. viridis, 325, 364. Nervous system, 247, 320. Neverita, 309, 325, 368. N. duplicata, 11, 325, 367. N. recluziana, 325, 368. Nicothoë, 239, 250. Nidorella, 204, 210. N. armata, 204, 210. Nitophyllum, 77, 85. N. laceratum, 77, 85. N. punctatum, 77, 86. N. Ruprechteanum, 77, 86. Noah's-ark shell, 426. Node, 303. Nodules, 344. Non-Calcarea, 100, 104, 106. Norrisia, 312. Nostocaceæ, 48. Nucula, 309, 405, 422. N. proxima, 405, 422. Nuculidæ, 405, 421. Nudibranch, 328, 349, 353. Nudibranchiata, 300, 324, 352. Nullipores, 31, 147. Nummulites, 22. O Obelia, 125. O. commissuralis, 116, 125. Oceania, 125. O. languida, 116, 125. Ocinebra, 326, 384.
- 68. O. circumtexta, 385. O. interfossa, 326, 385. O. lurida, 326, 384. O. poulsoni, 326, 384. Octopi, 315. Octopoda, 301, 464, 468. Octopus, 464, 468. Oculina, 141, 148. Ocypoda, 11, 241, 282. O. arenaria, 241, 274, 282. Ocypodidæ, 241, 282. Odontophore, 303. Oliva, 10, 311, 313, 327, 334, 400. O. literata, 327, 400. Olivella, 10, 312, 327, 400. O. biplicata, 327, 400. O. boetica, 327, 401. O. mutica, 327, 400. Olividæ, 327, 400. Ommastrephes, 464, 468, 469. O. illecebrosus, 464, 469. Opercula, 193. Operculum, 254, 303, 331, 355. Ophiocoma, 213, 216. O. æthiops, 213, 216. O. Alexandri, 213, 216. O. riisei, 213, 216. Ophiopholis, 213, 215. O. aculeata, 43, 213, 215. Ophiothrix, 213, 216. O. angulata, 213, 216. Ophiurida, 213, 215. Ophiuroidea, 200, 213, 214. Opisthobranchiata, 300, 324, 349, 350. Oral, 202. Surface, 201. Orbits, 243. Orchestia, 11, 43, 242, 289. O. agilis, 242, 289.
- 69. Organ-pipe coral, 151. Organs of feeling, 249. Orifice, 190, 412. Oscillaria, 48, 49. Osphradium, 303, 339. Ossicles, 201, 203, 218. Ostracoda, 238. Ostrea, 405, 410, 435. O. edulis, 435. O. frons, 405, 435. O. lurida, 405, 435. O. virginica, 310, 405, 435. Ostreidæ, 405, 432. Otocysts, 165, 303. Otter Cliffs, 43. Ovalipes, 241, 276. O. ocellatus, 241, 276. Ovicell, 190, 193. Oyster-crab, 287. Oyster-culture, 432. Oysters, 321, 432. Pearl-, 430, 431, 432. P Pacific faunal divisions 311. Pacygrapsus, 241, 282. P. crassipes, 241, 282. Padina, 63, 71. P. pavonia, 63, 71. Paguridæ, 240, 264. Pagurus, 240, 267. P. bernhardus, 240, 267. P. longicarpus, 240, 267. P. pollicaris, 240, 267. Palæmonetes, 240, 260. P. vulgaris, 240, 260. Palæmon vulgaris, 260. Pallial line, 303, 418. Sinus, 303, 419.
- 70. Palps, 176, 416. Palpus, 258. Panamic province, 312. Pandora, 407, 463. P. trilineata, 407, 463. Pandoridæ, 407, 463. Panopeus, 12, 281. Pantopoda, 242, 296. Panulirus, 240. 263. P. americanus, 263. P. argus, 240, 263. P. interruptus, 240, 263. Papillaceous, 303. Paraphyses, 72. Parapodia, 171. Parenchyma, 26. Parypha, 123. P. crocea, 116, 123. Peachia, 144. Pearls, 430, 431. Pecten, 309, 405, 435. P. æquisulcatus, 405, 438. P. dislocatus, 405, 437. P. hastatus, 405, 438. P. irradians, 405, 437. P. islandicus, 405, 436. P. jacobius, 436. P. magellanicus, 287, 405, 436. P. tenuiscostatus, 436. Pectinidæ, 405, 435. Pedal opening, 412. Pedata, 228, 231. Pedicellariæ, 201, 205, 219. Pedicellina, 189, 198. P. americana, 189, 198. Pelagia, 133, 139. P. cyanella, 133, 139. Pelagic, 23. Flora, 38. Pelecypoda, 301, 320, 321, 405, 409, 420.
- 71. Classification of, 419. Peltogaster, 239, 256. Pen, 467. Penæus, 240, 260. P. brasiliensis, 240, 260. P. setiferus, 240, 260. Penicillus, 51, 58. P. capitatus, 51, 58. P. dumentosus, 51, 58. P. Phœnix, 51, 58. Pennaria, 124. P. gibbosa, 116, 124. P. tiarella, 116, 124. Pennatula, 141. P. aculeata, Plate XLVII. P. borealis, Plate XLVII. Pennatulacea, 141, 153. Pentaceros, 204, 210. P. occidentalis, 204, 210. P. reticularis, 204, 210. Pentacerotidæ, 204, 210. Pentacrinus, 234, 235. Pentacta, 228, 232. P. frondosa, 43, 228, 232. Pentagonasteridæ, 204, 209. Pericardium, 341, 416. Pericolpa, 133, 136. P. quadrigata, 133, 136. Peridinieæ, 38. Periostracum, 303, 425. Perisaltic, 172. Perisarc, 118, 119. Peristome, 190, 194, 218, 303. Peristomium, 176. Periwinkles, 371. Perna, 405, 432. P. ephippium, 405, 432. Peromedusæ, 133, 136. Petricola, 407, 452. P. carditoides, 407, 452. P. pholadiformis, 407, 452.
- 72. Petricolidæ, 407, 452. Petrocelis, 78, 95. P. cruenta, 40, 78, 95. Petrolisthes, 240, 270. P. armatus, 240, 270. P. sexspinosus, 240, 270. Peyssonnelia, 78, 95. P. Dubyi, 78, 95. Phæophyceæ, 28, 61, 62. Phanerogams, 25. Phanerozonia, 204, 208. Phascolosoma, 162, 186. P. Gouldii, 162, 186. Pholadidæ, 407, 460. Pholas, 407, 460. P. californica, 407, 461. P. costata, 407, 461. P. truncata, 407, 461. Phoxichilidium, 242, 297. P. maxillare, 242, 297. Phyla, 19. Phyllitis, 62, 66. P. fascia, 62, 66. Phyllodoce, 161, 175. P. gracilis, 161, 175. Phyllodocidæ, 161, 175. Phyllolithodes, 240, 271. P. papillosus, 240, 271. Phyllonotus pomum, 382. Phyllophora, 76, 81. P. Brodiæi, 76, 82. P. membranifolia, 76, 82. Phyllopoda, 238. Phyllospora, 63, 73. P. Menziesii, 63, 73. Phylum, 19. Phyncopodia helianthoides, 207. Physalia, 131.
- 73. P. arethusa, 117, 131. Pikea, 78, 94. P. californica, 78, 94. Pill-bugs, 291. Pinna, 405, 431. P. muricata, 405, 431. P. seminuda, 405, 431. Pinnotheres, 241, 287. P. maculatum, 287. P. ostreum, 241, 287. Pinnotheriidæ, 241, 287. Pitho, 241, 286. P. aculeata, 241, 286. Placunanomia, 405, 425. P. macrochisma, 405, 425. Planaria, 160, 167. P. grisea, 160, 167. Planarians, 166. Planarian worms, 12. Plankton, 21, 23. Planocera, 160, 166. P. nebulosa, 160, 166. Planula, 120, 135. Platyhelminthes, 159, 160, 164. Platyonichus ocellatus, 276. Pleurobrachia, 154, 156. P. rhododactyla, 154, 156. Pleurococcus, 26. P. vulgaris, 25. Plocamium, 77, 85. P. coccineum, 77, 85. Plumularia, 127. P. falcata, 116, 127. Plumularians, 116, 127. Pluteus, 201, 220. Polian vessels, 201. Polina, 160, 170.
- 74. P. glutinosa, 160, 170. Polychæta, 161, 172. Polycirrus, 161, 182. P. eximius, 161, 182. Polycladida, 160, 165. Polyides, 78, 95. P. rotundus, 78, 95. Polymastia, 100, 106. P. robusta, 100, 106. Polynices, 12, 310, 314, 325, 335, 367. P. duplicata, 11, 325, 344, 367. P. heros, 8, 10, 44, 325, 343, 367. P. lewisii, 325, 368. P. recluziana, 325, 368. P. triseriata, 325, 367. Polynoë, 161, 174. P. squamata, 161, 174. P. sublevis, 161, 174. Polyphemus, 238. Polypide, 190, 192. Polyplacophora, 300, 321. Polyps, 111, 114, 119. Polysiphonia, 77, 87. P. Baileyi, 77, 88. P. dendroidea, 77, 87. P. fastigiata, 43, 77, 87. P. fibrillosa, 77, 88. P. Harveyi, 77, 88. P. nigrescens, 77, 87. P. Olneyi, 77, 88. P. parasitica, 77, 87. P. urceolata, 77, 88. P. urceolata, var. formosa, 77, 88. P. variegata, 77, 88. P. violacea, 44, 77, 88. P. Woodii, 77, 89. Polyzoa, 8, 188, 191. Polyzoans, 8, 12, 22. Pontonema, 161, 170. P. marinum, 161, 170. Porcelanous, 304, 345. Porcellana, 240, 269. P. sayana, 240, 269. Porcellanasteridæ, 204, 208. Porcellanidæ, 240, 269. Porcupine Island, 42. Porifera, 100, 101.
- 75. Porites, 147. P. astræaoides, Plate XLV. P. furcata, Plate XLV. Porocidaris, 217, 222. P. sharreri, 217, 222. Porphyra, 43, 78, 96. P. laciniata, 78, 96. P. vulgaris, 38, 78, 96. Porpita, 132. Portunidæ, 241, 274. Prawns, 258, 259. Preserving invertebrates, 14. Prionitis, 78, 94. P. Andersonii, 78, 94. P. lanceolata, 78, 94. Proboscis, 333. Procerodes, 160, 167. P. frequens, 160, 167. Propodium, 335. Prosobranchiata, 300, 324, 349, 355. Prostomium, 176, 243. Protista, 22. Protobranchiata, 301, 405, 420, 421. Protococcaceæ, 38. Protococcus nivalis, 25, 33. Protophyta, 21. Protozoa, 21, 101. Pseudolamellibranchiata, 301, 405, 420, 429. Psilaster, 204, 209. P. floræ, 204, 209. Psolus ephippiger, 231. P. fabricii, 232. Pterogorgia acerosa, Plate XLVI. Pteronotus, 326, 384. P. festivus, 326, 384. Ptilota, 78, 92. P. densa, 78, 92. P. elegans, 78, 92. P. hypnoides, 78, 92. P. serrata, 78, 92.
- 76. Pugettia, 241, 285. P. gracilis, 241, 285. Pulmonata, 300, 331, 338, 349. Punctaria, 62, 65. P. latifolia, 62, 65. P. plantaginea, 62, 66. P. tenuissima, 62, 66. Purpura, 8, 9, 309, 312, 326, 386, 387. P. crispata, 326, 387. P. hæmastoma, 326, 387. P. lapillus, 41, 42, 314, 326, 386. P. lima, 326, 387. P. patula, 326, 386. P. saxicola, 326, 387. Purpurinæ, 326, 385. Pycnogonida, 242, 296. Pycnogonidæ, 9. Pylopagurus, 268. Pyloric cæca, 208. Pyrocystis noctiluca, 33. Pyrosoma, 472. Pyrosomata, 472. Pyrula, 10, 326, 379. P. papyratia, 326, 379. R Radiata, 113. Radiates, 20. Radula, 304, 317, 340. Ræta, 406, 447. R. canaliculata, 406, 447. Ralfsia, 62, 65. Ralfsiaceæ, 62, 65. Rataria, 132. Receptacles, 72. Red crab, 278. Red seaweeds, 76, 79. Red snow, 33. Reef-builders, 147.
- 77. Reef-corals, 142, 146. Regularia, 217. Reticulated, 304. Rhabdocœlida, 160, 167. Rhabdonia. 77, 83. R. Coulteri, 77, 84. R. tenera, 77, 83. Rhithropanopeus, 241. R. harrisii, 241, 281. Rhizocephala, 239, 256. Rhizophyllideæ, 78, 95. Rhizostomæ, 133, 139. Rhodactinia, 141, 145. R. davidsii, 141, 145. Rhodomela, 77, 89. R. floccosa, 77, 90. R. larix, 77, 90. R. Rochei, 77, 89. R. subfusca, 77, 89. Rhodomeleæ, 77, 86. Rhodophyceæ, 28, 76, 79. Rhodophyllideæ, 77, 83. Rhodophyllis, 77, 83. R. veprecula, 77, 83. Rhodospermeæ, 79. Rhodymenia, 77, 85. R. palmata, 38, 42, 43, 77, 85. Rhodymeniaceæ, 77, 84. Rhodymenieæ, 77, 85. Ring-canal, 201, 203. Rock-crab, 277, 280. Rockweeds, 8. Rocky shores, 7. Rodicks Weir, 44. Root-mouth jellyfishes, 139. Rostrum, 243. Roundworms, 170.
- 78. S Sabella, 162, 184. S. microphthalma, 162, 184. Sabellidæ, 162, 184. Sacculina, 239, 256. Sagartia, 141, 145. S. leucolena, 141, 145. Salpa, 472, 474, 475. Sand-crab, 282. Sand-dollar, 11, 44, 225. Sandpiper, 5. Sandy shores, 10. Sapphirina, 239, 250. Sargasso Sea, 33. Sargassum, 26, 63, 64, 73. S. bacciferum, 34, 35, 63, 74. S. Montagnei, 63, 74. S. vulgare, 63, 74. Sarsia, 116, 123. S. mirabilis, 123. Saxicava, 41. Saxidomus, 406, 452. S. nuttallii, 406, 452. Scala, 325, 365. S. angulata, 325, 366. S. groenlandica, 325, 366. S. lineata, 325, 366. S. multistriata, 325, 366. Scalidæ, 325, 365. Scallops, 12. Scaphopoda, 320, 321, 327, 402. Schizaster, 217, 227. S. fragilis, 217, 227. Schizopoda, 239, 257. Scinaia, 76, 80. S. furcellata, 76, 80. Scrobicularia, 413. Sculpture, 304.
- 79. Scurria, 312. Scuta, 254. Scutellidæ, 217, 225. Scyllarus, 258, 263. Scyphozoa, 112, 115, 133, 134. Sea-acorns, 254. Sea-anemones, 112, 142. Sea-blubbers, 134. Sea-colanders, 42, 69. Sea-cucumbers, 43, 200, 202, 229. Sea-eggs, 221. Sea-fans, 114, 115, 142, 147, 152. Sea-feathers, 152. Sea-hares, 351. Sea-lilies, 200, 234. Sea-mats, 192. Sea-otters' cabbage, 35. Sea-peach, 476. Sea-pens, 142, 153. Sea-slugs, 349. Sea-spiders, 9, 296. Sea-squirts, 474. Sea-urchins, 43, 114, 200, 203, 218, 220. Sea-whips, 142, 152. Sedentaria, 161, 180. Segment, 243. Segmented worms, 170. Semostomæ, 133, 137. Sense-organs, 135. Sepia, 464, 467, 468. Septibranchiata, 420. Serpula, 162, 185.
- 80. S. dianthus, 162, 185. Serpulidæ, 162, 184. Sertularia, 126. S. argentea, 43, 116, 127. S. cupressina, 116, 127. S. pumila, 43, 116, 126. Sertularians, 8, 116, 120, 121, 126. Sessile, 121, 126. Sheep-crab, 285. Sheepswool sponge, 104, 108. Shell— Butterfly-, 323. Coffee-, 379. Conch-, 377. Cowry-, 377. Gasteropod, 342. Growth of gasteropod, 346. Mounds, 432. Noah's-ark, 426. Peach-, 454. Pelecypod, 416, 417. Razor-, 457. Setting-sun, 444. Shipworm, 462. Shrimps, 240, 245, 258, 259. Sigaretus, 311, 325, 334, 369. S. perspectivus, 325, 369. Signs on the beach, 1. Singing Beach, 2. Sinistral, 304, 345. Sinuate, 304. Sipho, 309, 313, 327, 393. S. islandicus, 393. S. pygmæus, 327, 394. S. Stimpsoni, 327, 393. Siphon, 304, 330, 334, 411. Anal, 412. Branchial, 412. Excurrent, 412. Functional, 411. Incurrent, 412. Siphonalia, 327, 394. S. kellettii, 327, 394. Siphoneæ, 51, 56. Siphonoglyphs, 143. Siphonophora, 117, 120, 121, 130. Siphonozoöids, 150. Siphuncle, 468.
- 81. Sipunculoidea, 162, 185. Sipunculus, 162, 185. S. nudus, 162, 185. Skates, 12, 44. Solaster, 204, 205, 211. S. decemradiata, 204, 211. S. endeca, 204, 211. Solasteridæ, 204, 211. Solen, 407, 458. S. ensis, 3, 458. S. rosaceus, 407, 458. S. sicarius, 407, 458. S. viridis, 407, 458. Solenidæ, 407, 457. Solenogastres, 321. Solenomya, 405, 423. S. borealis, 405, 423. S. velum 405, 423. Solenomyidæ, 405, 423. Somite, 243. Sow-bugs, 291. Spatangoidæ, 217, 226. Spatangoidea, 217, 226. Species, 20. Specific name, 28. Sphacelaria, 62, 65. S. cirrhosa, 62, 65. S. radicans, 62, 65. Sphacelariaceæ, 62, 65. Sphæoplea annulina, 37. Sphæridia, 219. Sphærococceæ, 77, 84. Sphæroma, 242, 293. S. destructor, 293. S. quadridentatum, 242, 293. Spicules, 102. Spider-crabs, 241, 284. Spines, 201, 205, 221. Spionidæ, 161, 181. Spire, 304.
- 82. Spirorbis, 8, 12, 162, 185. S. borealis, 162, 185. Spirula, 464, 467, 468. Spirulina, 48, 49. Sponges, 100, 101. Spongia, 104. S. graminea, 109. Spongidæ, 100. Spongillidæ, 104. Spongin, 102. Spring-tides, 13, 15. Spyridia, 78, 92. S. filamentosa, 78, 92. Squamarieæ, 78, 95. Squame, 243. Squids, 464. Squilla, 241, 288. S. empusa, 241, 288. Starfishes, 43, 114, 200, 203, 204, 205, 434. Station and habits of the Mollusca, 313. Stauromedusæ, 133, 136. Stelosponginæ, 100. Sternogramme, 76, 82. S. interrupta, 76, 82. Sternorhynchus, 241, 286. S. sagittarius, 241, 286. Stomatopoda, 241, 288. Stone-canal, 201, 203. Stone-crab, 280. Stony corals, 112, 115, 146. Striæ, 344. Strobila, 135, 138. Strombidæ, 326, 375. Strombus, 10, 311, 326, 376.
- 83. S. alatus, 376. S. gigas, 326, 376, 431. S. pugilis, 326, 376. Strongylocentrotus, 217, 223. S. drobachiensis, 41, 43, 217, 223. S. franciscanus, 217, 223. S. purpuratus, 217, 221, 223. Structure of mollusks, 315. Stylochopsis, 160, 166. S. littoralis, 160, 166. Suberites, 100, 106. S. compacta, 100, 106. Suberitidæ, 100. Suborders, 29. Subumbrella, 120. Suckers, 201, 203. Sun-jellies, 134, 138. Suture, 304, 344. Swimming-bell, 120. Swimming crabs, 241. Syconidæ, 100. Syllidæ, 161, 173. Symmetry, 328. Synapta, 228, 229, 233. S. roseola, 228, 233. S. rotifera, 228, 233. S. tenuis, 228, 233. S. viviparia, 231. T Table: Classification of algæ— Blue-green, 48. Brown, 62. Grass-green, 51. Red, 76. Classification of— Actinozoa, 141. Arthropoda, 238. Asteroidea, 204. Cephalopoda, 464. Chordata, 472. Ctenophora, 154. Echinoidea, 217. Holothuroidea, 228. Hydrozoa, 116. Mollusca, 300. Molluscoida, 188. Ophiuroidea, 213. Pelecypoda, 409. Porifera, 100. Scyphozoa, 133. Tagelus, 310, 407, 459. T. gibbus, 407, 459. Talitrus longicornis, 289. Talorchestia, 242, 289. T. longicornis, 242, 289. T. megalophthalma, 290.
- 84. Taonia, 63, 71. T. atomaria, 63, 71. Tapes, 406, 451. T. laciniata, 406, 451. T. staminea, 406, 451. Tealia crassiformis, 145. Tectarius, 311, 326, 373. T. muricatus, 326. T. nodulosus, 326, 373. Tectibranchiata, 300, 324, 350. Tedania, 100, 107. Teeth, 304, 417, 418. Cardinal, 418. Lateral, 418. Tellina, 311, 406, 443. T. alternata, 406, 444. T. bodegensis, 406, 444. T. radiata, 406, 443, 444. T. tenera, 406, 444. Tellinidæ, 406, 443. Telson, 243, 247. Tentaculocysts, 135. Terebellidæ, 161, 182. Teredinidæ, 407, 462. Teredo, 407, 462. T. navalis, 13, 407, 462. Terga, 254. Terms used in describing Crustacea, 243. Echinoderms, 201. Hydroids, 118. Mollusks, 302. Polyzoa, 190. Testaceous, 304. Tetrabranchiata, 301, 464, 467. Tetrastemma, 160, 169. T. arenicola, 160, 169. Thalassiophyllum, 36, 63, 70. Thaliacea, 472. Thallophytes, 25. Thallus, 26. Thelepsus, 161, 182. T. cincinnatus, 161, 182.
- 85. Thorax, 243, 246. Thracia, 309. Thyone, 228, 231. T. briareus, 228, 231. Tima, 128. T. formosa, 116, 128. Tivela, 406, 410, 450. T. crassatelloides, 406, 450. Toad-crab, 285. Toxopneustes, 217, 224. T. variegatus, 217, 234. Trachylinæ, 117, 120, 128. Trachymedusæ, 117, 128. Trachynema, 128. T. digitale, 117, 128. Transatlantic province, 309. Trematoda, 160. Trichodesmium, 33. Trichotropis, 309. Tricladida, 160, 166. Triclads, 166. Tridacna gigas, 313, 419. Triforis, 374. Tritonidea, 327, 394. T. tincta, 327, 394. Trivia, 326, 378. T. californica, 326, 379. T. pediculus, 326, 378. T. quadripunctata, 326, 379. T. solandri, 326, 379. T. spadacea, 379. Trochidae, 325, 359. Trochiscus, 325, 362. T. norrisi, 325, 362. Trophon, 309, 326, 383. T. clathratus, 326, 383. Tube-feet, 203.
- 86. Tubicola, 161, 172. Tubicolous worms, 180. Tubipora, 141, 147, 151. Tubularia, 116. T. Couthouyi, 116, 123. T. indivisa, 116. Tubularians, 116, 121, 122. Tubulipora, 188, 194. T. flabellaris, 188, 194. Tunicata, 472. 474. Tunicates, 474. Turbellaria, 160, 165. Turbinate, 304. Turbinellidæ, 327, 394. Turbinidæ, 325, 362. Turbo, 325, 363. T. castaneus, 325, 363. T. castaneus, var. crenulatus, 325, 363. Tyrian purple, 386. U Uca, 241, 282. U. minax, 241, 282. U. pugilator, 241, 282. U. pugnax, 241, 282. Udotea, 51, 58. U. conglutinata, 51, 58. U. flabellata, 51, 58. Udoteaceæ, 51, 58. Ulothrix, 51, 53. Ulva, 26, 28, 29, 51, 55. U. lactuca, 51, 55. U. latissima, 51, 55. U. Linza, 56. U. rigida, 55. Ulvaceæ, 28, 51, 52, 53, 54. Umbilicus, 304, 344. Umbo, 304, 417. Uncini, 180. Univalves, 306, 307, 314.
- 87. Urochorda, 472, 474. Urosalpinx, 11, 326, 383, 434. U. cinerea, 314, 326, 383. Uses of algæ, 37. V Valoniaceæ, 51, 56. Valve, 409, 416. Varices, 304, 344, 347. Vegetative reproduction, 27. Vellela, 131. V. limbosa, 117, 131. Velum, 134. Velutina, 309. Velvet sponge, 104. Veneridæ, 406, 447. Venons sinuses, 247. Ventral surface, 201. Ventricose, 304. Venus, 406, 410, 448. V. cancellata, 406, 449. V. mercenaria, 406, 448. V. mercenaria, var. mortoni, 406, 449. Venus's flower-basket, 102. Girdle, 157. Vermes, 163. Vermetidæ, 326, 375. Vermicularia, 326, 375. V. spirata, 326, 375. Vertebrates, 19. Vesicularia, 189, 198. V. custata, 189, 198. V. dichotoma, 189, 198. Vibracula, 190, 193. Visceral mass, 415. Voluta, 313, 327, 398. V. junonia, 327, 398, 399.
- 88. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com