Emerging Trends

The price of computers have dropped

drastically in this period .At the same time ,
they have become more powerful. Now they
can perform computations much faster and
store much larger volumes of data .The sizes
of computer have shrunk and laptops and
palmtops are becoming popular.

The internet has become extremely

popular .Internet connects millions of
computers worldwide and makes enormous
available to the user.
Networking technique have made rapid
progress .the speed of data transfer has
increased unbelievably and at the same time ,
the cost of the networking has dropped
dramatically .

Mobile phones have dramatically captured

imaginations of all.
Mobile phones are rapidly transforming
themselves into handheld computing devices .In
addition to high-speed line connection .GPRS
and wireless LANs have become common place.
CHALLENGES IN SOFTWARE
DEVELOPMENT
Software is still taking unacceptably long time
to develop and is turning out to a bottleneck in
implementing rapid business process changes .
To reduce the software delivery times, software
is being developed by teams working from
globally distributed locations .
Business houses are getting tired of
astronomical software costs , late deliveries,
and poor quality products .
Hardware and software cost differential are
becoming more and more glaring
Software sizes are further increasing
After Internet have become vastly popular, many
software products are now required to interface
with the Internet .
Many products are even expected to work across
the Internet .Also, with the availability of fast
network, distributed applications are becoming
common place
However, it is not clear that how software is to be
effectively developed in the context of the
distributed platform and the Internet.

In response to the challenges faced, the
following software engineering trends are
becoming noticeable

Client-server software
Service –oriented
Architecture(SOA)
Software as a service (SaaS)
In a client –server software, both clients and
server are essentially software components .

A client is a consumer of services and a

server is a provider of services

For example, a teacher may be a client to a

doctor , and a doctor may be a client of a
barber, who in turn may be a client of the
lawyer
ADVANTAGES OF CLIENT –SERVER SOFTWARE
Concurrency: A client-server software
divides the computing work among many
different client and server components that
could be residing on different machines .Thus
, client-server solutions are inherently
concurrent,

Loose Coupling : Client and server

components are inherently loosely-couples ,
making these easy to understand and develop
. Flexibility: Client-server software is
flexible in the sense that clients and server
can be attached and removed as and when
required. Also, clients can access the server
from anywhere.

. Cost-effectiveness: The client-server

paradigm usually leads to cost-effective
solutions. Clients usually run on cheap
desktop computers, whereas server may run
on sophisticated and expensive computers.
Even to use sophisticated
. Heterogeneous hardware: In a client-server
solution, it is easy to have specialized severs that
can efficiently solve specific problem. It is possible
to efficiently integrate heterogeneous computing
platforms to support the requirements of different
types of server software.

 Fault-tolerance: Client-server solutions are

usually fault tolerant. It is possible to have many
servers providing the same service. If one server
becomes unavailable, then client requests can be
directed to any other working server.
Mobile computing: Mobile computing
implicitly requires uses of client-server
technique. Cell phones are of late, evolving as
handheld computing and communication
devices and are being provided with small
processor power, keyboard, small memory,
and LCD display

Application service provisioning: There

are many application software products that
are extremely expensive to own. A client-
server based approach can be used to make
these software products affordable for use
Component-based development: Client-
server paradigm fits well with the component
based software development. Component-
based software development holds out the
promise of achieving substantial reduction to
cost and delivery time and at the same time
achieve increased product reliability.
 Disadvantages of client-server software

Security:
In a monolithic application addressing the
security concerns is much easier as compared
to client-server implementation. In a client-
server based software provides much
flexibility.

For example, a client can connect to a

server from anywhere. This makes it easy for
hackers to break into the system. Therefore,
ensuring security of a client-server system is
a very challenging task.
Server can be bottlenecked: Server can
turn out to be a bottleneck because many
clients might try to connect to a server at the
same time. This problem arises due to the
flexibility given that any client can connect
anytime required.

 Compatibility: Clients and server may not

be compatible to each other. Since the client
and server components may be manufactured
by different vendors, they may not be
compatible with respect to data types,
languages, number representation, etc.
Inconsistency: Replication of server can be
potentially create problem as whenever there
is replication of data, there is a danger of the
data becoming inconsistent.

Client-server Architecture

The simplest way to connect clients and

server is by using a two tier architecture
shown in figure 15.1 (a). In two tier
architecture, any client can get service from
any server by sending a request over the
network.

TWO Tier Architecture
Limitations of two-tier client-server architectures.

Two-tier architecture for client-server

application though is an intuitively obvious
solution, but it turns out to be not practically
usable.
The main problem is that client and server
components are usually manufactured by
different vendors, who may not adopt their
own interfacing and implementation
solutions, As a result, the different
components may not interface with each
other easily.
Three-tier client-server architecture

Three-tier client-server architecture

The three-tier architecture overcomes the
main limitations of the two-tier architecture.
In the three-tier architecture, a middleware
is added between client and the server
components as shown in figure 15.1 (b) .
The middleware keeps track of all servers. It
also translates client request into server
understandable form
Three Tier Architecture
Functions of middleware
The important activities of the middleware
include the following:
The middleware keeps track of the addresses
of server. Based on a client request, it can
therefore easily locate the required server.
It can translate between client and server
formats of data and vice versa.
Two popular middleware standards are
COBRA (Common Object request Broker
Architecture) and
SERVICE-ORIENTED ARCHITECTURE (SOA)
Service-orientation principles have their
roots in the object-oriented designing.

Many claim that service-orientation will

replace object-orientation; others think that
two are complementary paradigms

SOA views s/w as providing a set of services.

Each service composed of smaller services
The main idea behind SOA is to build applications
by composing s/w services.
There are several similarities between services
and components are:
1. Reuse: Both a component and a service are
reused across multiple applications.
2. Generic: The components and services are
usually generic enough to be useful to a wide
range of applications.
3. Composable: Both services and components
are integrated together to develop an application.
4 Encapsulated: Both services and
components are non-investigable through
their interfaces.
5. Independently development and
versioning: Both components and services are
developed independently by different vendors
and also continue to evolve independently.
6. Loose Coupling: Both applications
developed using the component paradigm
and the SOA paradigm have loose coupling
inherent to them
Software as a service
Software as a service (SaaS) involves hosting the
software remotely and providing access to it over
the Internet.
Software is deployed on a server (or more commonly
a number of servers) and is accessed through a web
browser. It is not deployed on a local PC.
The software is owned and managed by a software
provider, rather than the organizations using the
software.
Users may pay for the software according to the
amount of use they make of it or through an annual
or monthly subscription.
Chapter 18 Distributed software engineering 25
Key elements of SaaS
Software is deployed on a server (or more commonly
a number of servers) and is accessed through a web
browser. It is not deployed on a local PC.
The software is owned and managed by a software
provider, rather than the organizations using the
software.
Users may pay for the software according to the
amount of use they make of it or through an annual
or monthly subscription. Sometimes, the software is
free for anyone to use but users must then agree to
accept advertisements, which fund the software
service.
Chapter 18 Distributed software engineering 26
SaaS and SOA
Software as a service is a way of providing
functionality on a remote server with client access
through a web browser. The server maintains the
user’s data and state during an interaction session.
Transactions are usually long transactions e.g.
editing a document.
Service-oriented architecture is an approach to
structuring a software system as a set of separate,
stateless services. These may be provided by
multiple providers and may be distributed. Typically,
transactions are short transactions where a service
is called, does something then returns a result.
Chapter 18 Distributed software engineering 27
Implementation factors for SaaS
Configurability How do you configure the
software for the specific requirements of each
organization?
Multi-tenancy How do you present each user
of the software with the impression that they
are working with their own copy of the
system while, at the same time, making
efficient use of system resources?
Scalability How do you design the system so
that it can be scaled to accommodate an
unpredictably large number of users?
Chapter 18 Distributed software engineering 28
Configuration of a software system offered
as a service

Chapter 18 Distributed software engineering 29

Service configuration
 Branding, where users from each organization, are
presented with an interface that reflects their own
organization.
 Business rules and workflows, where each
organization defines its own rules that govern the use
of the service and its data.
 Database extensions, where each organization defines
how the generic service data model is extended to
meet its specific needs.
 Access control, where service customers create
individual accounts for their staff and define the
resources and functions that are accessible to each of
their users.
Chapter 18 Distributed software engineering 30
Multi-tenancy
Multi-tenancy is a situation in which many
different users access the same system and
the system architecture is defined to allow
the efficient sharing of system resources.
It must appear to each user that they have
the sole use of the system.
Multi-tenancy involves designing the system
so that there is an absolute separation
between the system functionality and the
system data.

Chapter 18 Distributed software engineering 31

A multitenant database

Chapter 18 Distributed software engineering 32

Scaleability
 Develop applications where each component is
implemented as a simple stateless service that may be
run on any server.
 Design the system using asynchronous interaction so
that the application does not have to wait for the
result of an interaction (such as a read request).
 Manage resources, such as network and database
connections, as a pool so that no single server is likely
to run out of resources.
 Design your database to allow fine-grain locking. That
is, do not lock out whole records in the database when
only part of a record is in use.

Chapter 18 Distributed software engineering 33