cbse vs soa presentation
DESCRIPTION
This is a presentation of a research paper on comparative study of Component based Software Engineering and Service Oriented Architecture. It covers technologies of both paradigms as well as technical discussions and justifications on SOA. It also covers modern components.TRANSCRIPT
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?