Component based Software Engineering v/s SOA Based Software EngineeringProposed by:Maulik ParikhRiddhi Vyas

ScenarioA 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 componentsPromotes software reuseImproved quality softwareReduced development costsReduces 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 MODELSOMG’s CORBA Component Model (CCM)Microsoft’s COM ,DCOM ,COM+ familyUML2.0PECOSADLs, Pin, Fractal, KobrA, SOFA

Basic Concepts:i)Components: Components are considered to be a higher level of abstraction than objectsii) Interface:Exported Interface Imported Interfaceiii)Contract:Specifies two things

Benefits with CBSEReduce or Contain development costsIncreasing industry competition for similar productsDecreased time to marketImproved software qualityDemand for more complex software solutionsComplex software solutions cost reduced through CBSEIncreased availability of COTS componentsIn Short:Maintainability FunctionalityUsabilityEfficiencyReliabilityPortability

Challenges of CBSEExternal Components May contain serious bugsDo not meet all functional requirementsUnable to obtain timely component supportPoor API documentationTechnical risks involved with integrating multiple components with different architecturesToo much time spent analyzing and searching for existing componentsNo universally accepted terminologyNo commonly accepted criteria/classification/taxonomyConfiguration Management

No universally accepted terminology

No commonly accepted criteria/classification/taxonomy

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 solutionSOA is NOT a product to be purchased

SOA Services:Loose coupling Formal contract Abstraction Reusability Principles that service must adhered toPromote software reusabilityFlexibility and able to respond faster to change Self-describing and self-containing

SOA Architecture:

SOA TechnologiesXML:Specification to create customized markup languagesSupports communication of different systemsCommunication is platform neutral, language neutral and self-describing syntax SOAP:Protocol specification used to exchange information via Web ServicesFlexible enough to use multiple transport protocols (HTTP or SMTP)Platform & language independentRelies on XML

SOA TechnologiesWSDL(Web Service Definition Language):Defines services as collections of network endpoints or portsMultiple ports define a serviceClients read WSDL to determine Services available How to make SOAP calls to the serviceUDDI(Universal Description Discovery and Integration):Registry where businesses can list available services and discover servicesComposed of 3 items:White Pages - Stores contact information (address and other identifiers)Yellow Pages - Service categorizationsGreen Pages - Technical information regarding services

SOA ToolsComposing 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.

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

SOA BenefitsSOA 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 investmentProvide higher level of interoperability and increased business and technology domain alignmentComplex software system can be build more rapidly from existing servicesTechnology NeutralRemove technology and platform boundariesLocation transparencyFacilitates reusabilitySelf-containing, self-describing, dynamic bindingLoosely coupledMore open to change

Remove technology and platform boundaries

Self-containing,

self-describing,

dynamic binding

More open to change

SOA ChallengesManaging Service capability dataCollecting and presenting data on how all components interact and their discoverable capabilitiesTestingLack of comprehensive testing tools for SOAWith “real-time” application composition and service deployment, testing is easily forgottenSecurityAll independent services must handle security independently

CBSE v/s SOA

Service ComponentsService 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.

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

Designed to be reused.

It must have a name, properties and an implementation.

Properties--- Operational constraints,

Service ComponentsInterface– 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 ComponentsConnector: 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 ComponentsModern 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??

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 SolutionWe 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.

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 ComponentsIn 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:Services are public not models of development. Can be accessed through registries as done in Yellow Pages.Services have to be largely independent from implementation specific attributes. E.g. Java, .Net or Perl. (Communication –XML and SOAP)

Discussions and JustificationsPerformance Issues of Web Services:Long chain of web services relianceNon-public services cause transport security and transaction issues. E.g. JMS-Web Services bridgeWhich 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.

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 JustificationsQuality 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 SOAPSOAP is a de-facto wire protocol for web services.SOAP performance is degraded due to the following:SOAP envelop extraction from SOAP packet is very time-expensive.SOAP encoding rules makes it mandatory to include typing information in all the SOAP messages sent and received.

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:

Discussions and JustificationsData 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.

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 OfferingsSOA 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 WorkComponent 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.

ConclusionSOA 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).

ReferencesHanson, J: Coarse-grained interfaces enable service composition in SOA. URL: http://builder.com/5100-63865064520.htmlSiddiqui, 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-61Enterprise Service Bus. URL: http://en.wikipedia.org/wiki/enterprise service busElrad, T., Aksit, M. , Kiczales, G., Lieberherr, K., Ossher, H. : Discussing aspects of Component Communication. ACM 44(10) (2001) 33-38

Q & A?