Component based Software Engineering

v/s

SOA Based Software Engineering

Proposed by:

Maulik Parikh

Riddhi Vyas

Scenario

A Mid tier/ Mid level company which wants to

develop a product.

Asked software architects for suggesting them a

solution methodology.

As software architects we are comparing two

methodologies: Component Based Software

Engineering and SOA based Software Engineering

and proposing a solution to the stack holders.

What is CBSE?

Emphasis on decomposition of the engineered systems

Functional or logical components with well-defined interfaces used communication across the components

Development methodology that utilizes separate software entities using:

◦ Commercially off-the-shelf products (COTS)

◦ Internally developed components

Promotes software reuse

◦ Improved quality software

◦ Reduced development costs

Reduces time to market for large system implementation

Why CBSE?

Goal: Represent the system as assembly of parts(Components)

The ‘buy, don’t build’ philosophy.

The development of parts as reusable entities, and the maintenance and upgrading of systems by customizing and replacing such parts

What is Required for that: established methodologies and tool support covering the entire component and system lifecycle including technological, organizational, marketing, legal, and other aspects

What is New?

OOD v/s CBD

What is Needed?

CBSE COMPONENT MODELS

OMG‟s CORBA Component Model (CCM)

Microsoft‟s COM ,DCOM ,COM+ family

UML2.0

PECOS

ADLs, Pin, Fractal, KobrA, SOFA

Basic Concepts:

i)Components: Components are considered to be a higher level of abstraction than objects

ii) Interface:

Exported Interface

Imported Interface

iii)Contract:

Specifies two things

Benefits with CBSE Reduce or Contain development costs

Increasing industry competition for similar products

◦ Decreased time to market

◦ Improved software quality

Demand for more complex software solutions

◦ Complex software solutions cost reduced through CBSE

◦ Increased availability of COTS components

In Short:

Maintainability

Functionality

Usability

Efficiency

Reliability

Portability

Challenges of CBSE External Components

◦ May contain serious bugs

◦ Do not meet all functional requirements

◦ Unable to obtain timely component support

◦ Poor API documentation

Technical risks involved with integrating multiple components with different architectures

Too much time spent analyzing and searching for existing componentso No universally accepted terminologyo No commonly accepted criteria/classification/taxonomyo Configuration Management

What is SOA?

Utilizes services as fundamental elements for

developing applications and solutions.

Also called group of services that communicate with

each other which involves either data passing or co-

coordinating activity between two or more services.

Web Services is used as a methodology to implement a

SOA solution

SOA is NOT a product to be purchased

SOA Services:

Loose coupling

Formal contract

Abstraction

Reusability

Principles that service must adhered to

Promote software reusability

Flexibility and able to respond faster to

change

Self-describing and self-containing

SOA Architecture:

SOA TechnologiesXML:

Specification to create customized markup languages

Supports communication of different systems

Communication is platform neutral, language neutral

and self-describing syntax

SOAP:

Protocol specification used to exchange information via

Web Services

Flexible enough to use multiple transport protocols

(HTTP or SMTP)

Platform & language independent

Relies on XML

SOA Technologies

WSDL(Web Service Definition Language):

Defines services as collections of network endpoints or

ports

Multiple ports define a service

Clients read WSDL to determine

◦ Services available

◦ How to make SOAP calls to the service

UDDI(Universal Description Discovery and Integration):

Registry where businesses can list available services and

discover services

Composed of 3 items:

◦ White Pages - Stores contact information (address and other

identifiers)

◦ Yellow Pages - Service categorizations

◦ Green Pages - Technical information regarding services

SOA Tools

Composing Services:

• For composing services one has to filter some no-required functions of „provider „ services. For this, Pipes and Filters are used.

Orchestration:

Orchestration is about maintaining a flow of sequence of composed services in a system. For this, BPEL4WS (Business Process Execution Language for Web Services)and Web Service Conversation Interface are used.

Choreography:

Choreography deals with interaction between the service providers. For this ,WS-CDL(Web Services-Choreography Description Language) is used.

SOA Benefits SOA can help business respond more quickly to changing market

conditions in a cost-effective manner to stay competitive

Ease the management of IT resources in the organization and allow company to leverage off from existing IT investment

Provide higher level of interoperability and increased business and technology domain alignment

Complex software system can be build more rapidly from existing services

Technology Neutral

• Remove technology and platform boundaries

Location transparency

Facilitates reusability

• Self-containing,

• self-describing,

• dynamic binding

Loosely coupled

• More open to change

SOA Challenges

Managing Service capability data

◦ Collecting and presenting data on how all components interact and their discoverable capabilities

Testing

◦ Lack of comprehensive testing tools for SOA

◦ With “real-time” application composition and service deployment, testing is easily forgotten

Security

◦ All independent services must handle security independently

CBSE v/s SOA

CBSE SOA

Loose Coupling and Tight

Coupling

Loose Coupling

Composing components of

different models limited

Implement in diverse

technologies, different applications

on different platforms

Variety of encapsulation types:

black-box and white-box

Only black-box encapsulation

Supports early binding and late

binding

Supports only dynamic binding

Components are composed at

design time or run time

Services composed at runtime

Service Components

Service Component:

It is a self-contained body of the code with a well-defined

interface, attributes and behavior.

• Works as ‘Service Provider’ and/or ‘Service Consumer’.

• Designed to be reused.

• It must have a name, properties and an implementation.

• Properties--- Operational constraints,

its dependencies (if any) on other components, list of

operation that can be reused, list of known relationships etc.

Service Components Interface– can be described with a programming

language.

Service Provider

{

provide output;

pubReq input;

spec serviceSpecification;

}

Interface may be described directly in the specification

or indirectly discovered through reflection and

introspection.

Network addressable interfaces.

Communicate via standard protocols and data formats.

Service Components Connector: It connects service components.

Define the connector type and specify it by declaring its

interfaces and the connection protocols.

Connector Interface: It‟s a set of interaction points

between the connector and the service components

and the connectors attached to it.

Connector PubLink

{

publisher output;

pubRequestor input;

spec publishProtocol;

}

The connector interface “input” defines interconnection

protocol between the provider and that connector.

Modern Components Modern components are the ones which are

manufactured by a vendor using some

standardized models and used by a third party

who uses it as COTS-components.

Modern components are accessed by vendor

defined standardized architecture based

interfaces.

They are tightly coupled inside a container.

This puts an extra processing

overhead…..How??

Modern Components

Component Distribution….A

problem?• Fine Grained objects are tightly coupled inside a

container and it is not possible to distribute fine-

grained objects without causing a measurable

impact to at least some of the non-functional

requirements.

• Only coarse-grained objects should be exposed to

the network.

• Hard to reuse coarse-grained objects.

• Reusable business logic should remain fine

grained.

• So Component Distribution is a problem!!!......

• What‟s the Solution??

Façade Pattern-A Solution

•We don‟t want to publish the fine grained entities to the client, so we have to

provide a coarse view of them.

•We do not want to change the interface too..

•Façade provides such a view which satisfies different system specific

demands like web services.

Demarcated SOA v/s

Components In principal, SOA is the enhancement of

components.

Individual services are single components which can be linked to gain new business logic, new services or a new components.

The big difference is the connection between the possibilities of offering single service for third parties.

EJB(especially Session Beans) can be designed to offer its business methods like services in a context free way.

Compare it with a department in a company offering a service to other department.

IS SOA a miracle cure?

SOA is a step forward from component technology but not a miracle-cure.

It gives loose coupling, higher reusability, faster development and a complete new style of software development.

Two points of differentiation:

1. Services are public not models of development. Can be accessed through registries as done in Yellow Pages.

2. Services have to be largely independent from implementation specific attributes. E.g. Java, .Net or Perl. (Communication –XML and SOAP)

Discussions and Justifications

Performance Issues of Web Services:

1. Long chain of web services reliance

2. Non-public services cause transport security and

transaction issues. E.g. JMS-Web Services bridge

Which Web Services are right for me?

Technologies like UDDI does help in doing this job

but it is not an efficient and competitive way.

Write undiscoverable web services

oneself…That‟s against the idea of SOA!! Than

there‟s no real advantage of SOA over CBD.

Discussions and Justifications

Quality of Service of foreign applications:

Non-functional attributes like performance,

reliability, security and manageability have to be

detected.

There should be a metrics to decide for a fit of

service.

• Performance with SOAP

SOAP is a de-facto wire protocol for web services.

SOAP performance is degraded due to the

following:

1. SOAP envelop extraction from SOAP packet is very

time-expensive.

2. SOAP encoding rules makes it mandatory to include

typing information in all the SOAP messages sent and

Discussions and Justifications

Data Overhead: XML is a language independent, platform independent,

easy to recognize and normal textual format.

SOA uses XML for data exchange and interchange.

A coin has two sides….

Higher need of data transfer lower performance and

higher usage of network and internet traffic.

Parsing the XML information contained in an envelop is

time-consuming.

Very less time is consumed in serializing and de-

serializing sent in a binary format over the network.

Very less data optimization is possible with XML.

More Offerings

SOA services can be built on CBD principles, it adds a

new layer for reuse.

SOA services can be reused via standard

communication over ESB and discoverability offered by

repositories.

Using XML and web services SOA applications have

become distributed but there are still questions about

security, transactions, fault tolerance, change

management.

Technical SOA principles like data ownership are object

oriented so technically it is not a novelty.

Business functionality which raises the level of

abstraction separates SOA services from common

components.

Future Work

Component based paradigm has a

long history relatively behind them.

Solid methodology for developing

component based applications.

As SOA paradigm matures, it requires

careful consideration of the role of

different software artifacts in the

system.

e.g. clearly distinguish between

reusability on different levels, for

instance.

Conclusion

SOA gives a new type of service based architecture to be

used in a context free way , it does not differ significantly from

existing component based frameworks like EJB.

Developers can use foreign external components as Web

Services.

But one has to take into consideration factors like finding

services, providing acceptable performance, security,

transactions, maintainability in own services even to handle

changeability of integrated external services or components.

There are a lot of problems but there are a lot of possibilities

too.

In our opinion future is about Component based SOA(CSOA).

References

Hanson, J: Coarse-grained interfaces enable service

composition in SOA. URL: http://builder.com/5100-

63865064520.html

Siddiqui, F: Component based software engineering, a

look at reusable software components (August 2003)

Stal, M. : Using architectural patterns and blueprints for

service-oriented architecture. Software, IEEE 23(2)

(2006) 54-61

Enterprise Service Bus. URL:

http://en.wikipedia.org/wiki/enterprise service bus

Elrad, T., Aksit, M. , Kiczales, G., Lieberherr, K., Ossher,

H. : Discussing aspects of Component Communication.

ACM 44(10) (2001) 33-38

Q & A?