rajib mall lecture notes part 22

7/30/2019 Rajib Mall Lecture Notes part 22

1/56

1

Emerging Trends inSoftware Engineering

Prof. R. Mall

Dept. of CSE, IIT, Kharagpur


2/56

2

Introduction

Technology developments occur: To adapt to new environments To respond to new challenges

Few important developments that haveoccurred over the last decade or so: Desktops have become more powerful andat the same time more affordable.

Internet has become widely accepted. Mobile computing. Outsourcing has become prevalent.


3/56

3

Background Software market has two parts:

Products (General purpose

software)Services (custom software)

Total business appx. $1 Trillion

Half in products and half servicesServices segment is growing fast


4/56

4

Backgroundcont

SE goal is to develop softwareto satisfy user needs.

Either generic or one-off. Customer needs are consideredsacrosanct and fixed:

Vendor has to find the solution.


5/56

5

Background: A Constraint onSoftware Engineering Process

Business Process

Implementation in IT

Time required = T1

Change in Business Process

Change in the IT solutionsupporting

the business process

Time required = T2


6/56

6

Background: Desired Goals A. Reduce T1 (and improve quality) B. Reduce T2 A requires:

Process should efficiently capturerequirements of the business and thenefficiently convert it to code.

B requires: Implementation should be such thatbusiness process changes can be easilyaccommodated in the software solution.


7/56

7

ChallengesBeing Faced Delivery time requirements areshortening: High business velocity requires this.

Software is becoming a bottleneck inimplementing business process changes.

Businesses are getting tired of software

cost, late deliveries, poor quality, risk, Hardware and software cost differentialsare becoming more and more glaring.


8/56

8

Challenges Being Facedcont

Software sizes are furtherincreasing. How software is to be effectively

developed in following contexts isnot clear: Distributed platforms

Working with Internet Distributed development teams


9/56

9

Noticeable SoftwareEngineering Technology Trends

Following software engineeringtrends are easily noticeable:

Client-server (or Component-based)development

Service-Oriented Architecture(SOA)

Software as a Service (SaaS)


10/56

10

Client-Server Technology

Both clients and servers are pieces ofsoftware. Concepts of Clients and Servers are

nothing new --- have existed forages: Clients are consumers of service. Servers are providers of service.

Why is then a sudden interest seen inclient-server software architecture?


11/56

11

Advantages of Client-ServerCompared to Traditional Software Flexibility:

Clients and servers can be easily attached andremoved.

Modularity Concurrency Fault-tolerance Clients are cheap computers:

Servers are expensive computers tucked away insome AC rooms.

To use a software you not need not buyexpensive server hardware and software.


12/56

12

Client-Server versusTraditional Software

The following two factors are possibly themost relevant:

Component-based software development: To develop a hardware solution an electronicengineer does not solder transistors andresistors on a PCB --- uses off-the-shelf ICs.

Why not do the same for software.

Current trend of mobile computing: Handhelds can only be clients due to lowprocessing and memory capabilities.


13/56

13

Component Architectures

Two tier architecture: Most obvious

But does not work.

Server 1 Server m

Client 1

Client n

Internet

Wh h P bl i h


14/56

14

What are the Problems withthe 2-tier Architecture?

Servers can be bottleneck. How to locate servers? Client-Server incompatibility:

Analogy: House hunting in

Bangalore.

S l ti 3 ti


15/56

15

Middleware

Solution: 3-tierArchitecture

Server 1 Server m

Client 1 Client n

InternetMiddleware


16/56

16

Middleware Standards CORBA versus COM/DCOM CORBA (common object request

broker architecture) Being advocated by OMG

COM/DCOM:

Being advocated by Microsoft


17/56

17

CORBA Architecture

ORB

Server 1 Server mSkeleton Skeleton

Client 1 Client n

Stub Stub

Object Adapter

DSI DSI


18/56

18

CORBA Architecture Skeleton:

Marshalls client requests

The servers register themselves with

the object-adapter. The ORB delivers the client request tothe server.

The Skeleton marshalls the serverresponse.

DII/DSI for dynamic service invocation.

IDL: Interface


19/56

19

IDL: InterfaceDevelopment Language

Interfaces between clients andservers can be specified.

Similar to C++ or Java: But no executable statements.Interface clock{

set-time(int hh, int mm, int ss);get-time(int hh, int mm, int ss);

}

H t D v l p C mp n nt


20/56

20

How to Develop Component-Based Applications?

Divide application into components. Determine component interfaces:

Define using IDL. Get available components:

Build the ones not available

Integrate the components and test


21/56

21

CORBA Implementations

VisigenicIonaOrbixJava IDL


22/56

22

COM/DCOM

COM used when application runs on asingle machine: DCOM for distributed machine.

Concepts are similar to CORBA: Though terminologies are different. Proxy on client side. More usable than CORBA.

What is a component in COM/DCOM? A .exe or .dll component Created using VB or VC++


23/56

23

COM/DCOM versus CORBA

COM/DCOM strong on client side: CORBA on server side. Java Beans an attempt to bridge thisgap.

COM/DCOM more usable: If your application is to run only onMicrosoft operating systems, better use

COM/DCOM. If your application needs to run onheterogeneous platforms, better useCORBA.


24/56

24

Service-Oriented

Architecture (SOA)

SOA I d i


25/56

25

SOA: Introduction Service-orientation principles havetheir roots in the object-orienteddesigning.

Many claim that service-orientationwill replace object-orientation:

Others think the two arecomplementary paradigms.

Wh i OA?


26/56

26

What is SOA?

Build applications by composing softwareservices. What is a software service?

Essentially software components. Typically implement functionality mosthumans would recognize as a service.

Examples of services:

Filling out an online application Viewing an online bank-statement Placing an online booking

F ll


27/56

27

Service: More Formally

A service is a contractuallydefined behavior:

Implemented and provided by acomponent for use by anapplication developer.

d l


28/56

28

SOA vs. Component Model

Several things common betweenservices and components: Multiple-use

Non-context-specific Composable Encapsulated i.e., non-investigablethrough its interfaces

A unit of independent deploymentand versioning

Loose coupling

SOA vs Component Model


29/56

29

SOA vs. Component Modelcont

Several things different. Compared to components:

SOA's atomic-level objects areoften 100 to 1,000 times larger.

Services may be developed and

hosted separately.Possibly pay per use.



30/56

30


Instead of services embedding calls toeach other in their source code: They use defined protocols whichdescribe how services can talk to eachother.

This architecture relies on a businessprocess expert:

Links and sequences services, in a processknown as orchestration, to meet a newbusiness requirement.



31/56

31


SOA targets fairly large chunks offunctionality to be strung together toform new services:

Built almost entirely from existingsoftware services.

The larger the chunks: The fewer the interfacings required; Faster development; However, very large chunks may notprove easy to reuse.

SOA Nitt G itt


32/56

32

SOA: Nitty Gritty SOA is a collection of services:

That communicate with each other.

The services are self-contained: Do not depend on the context or stateof the other service.

Each service works within adistributed-system architecture.

SOA : Nitty Gritty


33/56

33

SOA : Nitty Grittycont

A paradigm for utilizing distributedcapabilities: May be under the control of

different ownership domains. Provides a uniform means:

To offer, discover, interact with anduse capabilities to achieve desiredresults.

SOA: Nitty Gritty


34/56

34

SOA: Nitty Grittycont

SOA would fundamentally change theway we construct software systems.

SOA involves statically and dynamicallyplugging-in services to build software.

SOA players:

BEA Aqua logic, Oracle Web services

manager, HP Systinet Registry, MS .Net,IBM Web Sphere, Iona Artrix, Javacomposite application suite.

SOA: Nitty Gritty


35/56

35

SOA: Nitty Grittycont

Views software as providing a set of services: Each service composed of smaller services.

Leverages the Internet and emergingstandardization on it for interoperability

Hopes that a market place for differentpredefined services can emerge: Not tied to any specific vendor

An app can be built using these services: And building the missing ones.

Principles of Service-


36/56

36

Principles of ServiceOrientation: Services

Services: Abstract the underlying data andlogic

Composable Autonomous Share a formal contract

Loosely coupled Stateless Discoverable

SOA Entiti s


37/56

37

ServiceConsumer

ServiceProvider

Contract Registry

SOA Entities

SOA Implementation


38/56

38

SOA Implementation

Web services can implement aservice-oriented architecture.

Web services make functional

building blocks Accessible over standard Internetprotocols

Independent of platforms andprogramming languages.

Service Orchestration


39/56

39

Service Orchestration

Requires metadata in sufficient detailto describe: The characteristics of the services, Also the data that drives them.

The services are typically described byWSDL.

Communications protocols by SOAP. Data and meta data by XML

SOA Vision


40/56

40

SOA Vision

Have a marketplace for services: It will automatically improve qualityand reduce prices.

To build an application: Use off-the-shelf services andpossibly build some.

Cost of building reduces; Also cost of ownership (which is quitelarge for regular software) reduces.

Great Promise of SOA


41/56

41

Great Promise of SOA The cost of creating the n-thapplication is near-zero,

As all of the software servicesrequired already exists.

Only orchestration required to

produce a new application.

SOA Challenges


42/56

42

SOA Challenges

Building services and infrastructure Composing services formal theoryand algebra, languages, semantics

Testing and verification Trust Non Functional properties Changes Business level modeling and translation Developing the marketplace


43/56

43

Software as a

Service (SaaS)

Challenge Faced


44/56

44

Challenge Faced Owning software is very expensive:

An Rs. 50 Lakh software running on an Rs.1 Lakh computer is common place.

As with hardware, owning software isthe business tradition: Both products and services bought and

used. Most of IT budget now goes in supportingthe software assets.

Background


45/56

45

Background To have water supply at home:

Do you install system to pump water fromriver directly to your home?

To get electricity supply: Do you install a thermal or hydro electricgenerator?

It would lead to wastage:You do not need to have all the water pipesopen all the time.

Unnecessarily expensive proposition.

Background


46/56

46

Backgroundcont

Should you own Rational Suitepaying Rs. 50 Lakhs: If you use it only 10 hours every

month One hour of usage costs Rs. 100/- Also frees use from maintenance and

data storage costs --- Given thatmaintenance is usually a severeoverhead.

SaaS


47/56

47

SaaS Lets customers pay for whatthey need and when:With price reflecting market

place supply and demand. SaaS includes:

Elements of outsourcing andApplication service provisioning

SaaS


48/56

48

SaaS

SaaS is a model of softwaredelivery:Software owner provides

maintenance, daily technicaloperation, and support for thesoftware.

Services are provided to theclients on amount of usage basis.

SaaS vs SOA


49/56

49

SaaS vs. SOA

SaaS is a software delivery model: SOA is a software constructionmodel.

SaaS counters the concept of auser as the owner: Owner is a vendor who hosts the

software and lets the users executeon-demand charges per usage units.

SaaS versus SOA


50/56

50

SaaS versus SOA Despite significant differences:

Espouse closely related architecturemodels.

SaaS and SOA complement each other: SaaS helps to offer components for SOAto use.

SOA helps to help quickly realize SaaS.

Main enabler of SaaS and SOA: Internet and web services technologies.

Key Characteristics


51/56

51

Key Characteristics

Network-based access and management ofcommercially available (not custom) software.

Activities managed from central location andnot at customer site, Enabling customers to access applicationsremotely via the Web.

Application delivery follows a one-to-many

model (single instance, multi-tenantarchitecture): In contrast to a one-to-one model.

Business Model


52/56

52

Business Model Shift "ownership" of the software:

From the customer to a service provider.

Shift responsibility for hardware and

software management: From the customer to the provider

Reduce the cost of providing software

services: Through specialization and economy ofscale.

Target the "long tail" of small customers

Current Business Model


53/56

53

Current Business Model

SaaS Business Model


54/56

54

SaaS Business Model

SaaS Architecture


55/56

55

SaaS Architecture

Meta-Model

Data

Player

Designer

ApplicationInstance

Play/Edit

Edit

Client 1

Client 2

Client n

Summary


56/56

56

Summary Some of the basic assumptions of software

are changing This is leading to some different paradigmsfor software delivery.

Component-based development: Expected to reduce development time, cost andat the same time improve quality.

SaaS is changing the way software isdelivered.

SOA conceives a component based assemblymodel with independent component vendors.

rajib mall lecture notes part 22

Documents