CBSE VS SOA Presentation
Upcoming SlideShare
Loading in...5
×
 

CBSE VS SOA Presentation

on

  • 715 views

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

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.

Statistics

Views

Total Views
715
Views on SlideShare
701
Embed Views
14

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 14

http://www.linkedin.com 14

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

CBSE VS SOA Presentation CBSE VS SOA Presentation Presentation 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 components
    • 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 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 Technologies
    XML:
    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
  • 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:
    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 Justifications
    Performance Issues of Web Services:
    Long chain of web services reliance
    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:
    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.
  • 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?