Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CBSE VS SOA Presentation


Published on

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.

  • Be the first to comment

  • Be the first to like this

CBSE VS SOA Presentation

  1. 1. Component based Software Engineering v/s SOA Based Software Engineering<br />Proposed by:<br />Maulik Parikh<br />Riddhi Vyas<br />
  2. 2. Scenario<br />A Mid tier/ Mid level company which wants to develop a product.<br />Asked software architects for suggesting them a solution methodology.<br />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.<br />
  3. 3. What is CBSE?<br />Emphasis on decomposition of the engineered systems <br />Functional or logical components with well-defined interfaces used communication across the components <br />Development methodology that utilizes separate software entities using: <br />Commercially off-the-shelf products (COTS)<br />Internally developed components<br />Promotes software reuse<br />Improved quality software<br />Reduced development costs<br />Reduces time to market for large system implementation<br />
  4. 4. Why CBSE?<br />Goal: Represent the system as assembly of parts(Components)<br />The ‘buy, don’t build’ philosophy.<br />The development of parts as reusable entities, and the maintenance and upgrading of systems by customizing and replacing such parts <br />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<br />
  5. 5. What is New?<br />OOD v/s CBD<br />
  6. 6. What is Needed?<br />CBSE COMPONENT MODELS<br />OMG’s CORBA Component Model (CCM)<br />Microsoft’s COM ,DCOM ,COM+ family<br />UML2.0<br />PECOS<br />ADLs, Pin, Fractal, KobrA, SOFA <br />
  7. 7. Basic Concepts:<br />i)Components: Components are considered to be a higher level of abstraction than objects<br />ii) Interface:<br />Exported Interface <br />Imported Interface<br />iii)Contract:<br />Specifies two things<br />
  8. 8. Benefits with CBSE<br />Reduce or Contain development costs<br />Increasing industry competition for similar products<br />Decreased time to market<br />Improved software quality<br />Demand for more complex software solutions<br />Complex software solutions cost reduced through CBSE<br />Increased availability of COTS components<br />In Short:<br />Maintainability <br />Functionality<br />Usability<br />Efficiency<br />Reliability<br />Portability<br />
  9. 9. Challenges of CBSE<br />External Components <br />May contain serious bugs<br />Do not meet all functional requirements<br />Unable to obtain timely component support<br />Poor API documentation<br />Technical risks involved with integrating multiple components with different architectures<br />Too much time spent analyzing and searching for existing components<br /><ul><li>No universally accepted terminology
  10. 10. No commonly accepted criteria/classification/taxonomy
  11. 11. Configuration Management</li></li></ul><li>What is SOA?<br />Utilizes services as fundamental elements for developing applications and solutions.<br />Also called group of services that communicate with each other which involves either data passing or co-coordinating activity between two or more services.<br />Web Services is used as a methodology to implement a SOA solution<br />SOA is NOT a product to be purchased<br />
  12. 12. SOA Services:<br />Loose coupling <br />Formal contract <br />Abstraction <br />Reusability <br />Principles that service must adhered to<br />Promote software reusability<br />Flexibility and able to respond faster to change <br />Self-describing and self-containing<br />
  13. 13. SOA Architecture:<br />
  14. 14. SOA Technologies<br />XML:<br />Specification to create customized markup languages<br />Supports communication of different systems<br />Communication is platform neutral, language neutral and self-describing syntax <br />SOAP:<br />Protocol specification used to exchange information via Web Services<br />Flexible enough to use multiple transport protocols (HTTP or SMTP)<br />Platform & language independent<br />Relies on XML <br />
  15. 15. SOA Technologies<br />WSDL(Web Service Definition Language):<br />Defines services as collections of network endpoints or ports<br />Multiple ports define a service<br />Clients read WSDL to determine <br />Services available <br />How to make SOAP calls to the service<br />UDDI(Universal Description Discovery and Integration):<br />Registry where businesses can list available services and discover services<br />Composed of 3 items:<br />White Pages - Stores contact information (address and other identifiers)<br />Yellow Pages - Service categorizations<br />Green Pages - Technical information regarding services<br />
  16. 16. SOA Tools<br />Composing Services:<br /><ul><li>For composing services one has to filter some no-required functions of ‘provider ‘ services. For this, Pipes and Filters are used.</li></ul>Orchestration:<br />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.<br />Choreography:<br />Choreography deals with interaction between the service providers. For this ,WS-CDL(Web Services-Choreography Description Language) is used.<br />
  17. 17. SOA Benefits<br />SOA can help business respond more quickly to changing market conditions in a cost-effective manner to stay competitive <br />Ease the management of IT resources in the organization and allow company to leverage off from existing IT investment<br />Provide higher level of interoperability and increased business and technology domain alignment<br />Complex software system can be build more rapidly from existing services<br />Technology Neutral<br /><ul><li>Remove technology and platform boundaries</li></ul>Location transparency<br />Facilitates reusability<br /><ul><li>Self-containing,
  18. 18. self-describing,
  19. 19. dynamic binding</li></ul>Loosely coupled<br /><ul><li>More open to change</li></li></ul><li>SOA Challenges<br />Managing Service capability data<br />Collecting and presenting data on how all components interact and their discoverable capabilities<br />Testing<br />Lack of comprehensive testing tools for SOA<br />With “real-time” application composition and service deployment, testing is easily forgotten<br />Security<br />All independent services must handle security independently<br />
  20. 20. CBSE v/s SOA<br />
  21. 21. Service Components<br />Service Component: <br />It is a self-contained body of the code with a well-defined interface, attributes and behavior.<br /><ul><li>Works as ‘Service Provider’ and/or ‘Service Consumer’.
  22. 22. Designed to be reused.
  23. 23. It must have a name, properties and an implementation.
  24. 24. Properties--- Operational constraints, </li></ul> its dependencies (if any) on other components, list of operation that can be reused, list of known relationships etc. <br />
  25. 25. Service Components<br />Interface– can be described with a programming language.<br />Service Provider<br /> {<br /> provide output;<br /> pubReq input;<br /> spec serviceSpecification;<br />}<br />Interface may be described directly in the specification or indirectly discovered through reflection and introspection.<br />Network addressable interfaces.<br />Communicate via standard protocols and data formats.<br />
  26. 26. Service Components<br />Connector: It connects service components.<br />Define the connector type and specify it by declaring its interfaces and the connection protocols.<br />Connector Interface: It’s a set of interaction points between the connector and the service components and the connectors attached to it.<br /> Connector PubLink<br /> {<br /> publisher output;<br /> pubRequestor input;<br /> spec publishProtocol;<br /> }<br />The connector interface“input” defines interconnection protocol between the provider and that connector.<br />
  27. 27. Modern Components<br />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.<br />Modern components are accessed by vendor defined standardized architecture based interfaces.<br />They are tightly coupled inside a container.<br />This puts an extra processing overhead…..How??<br />
  28. 28. Modern Components<br />
  29. 29. Component Distribution….A problem?<br /><ul><li>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.
  30. 30. Only coarse-grained objects should be exposed to the network.
  31. 31. Hard to reuse coarse-grained objects.
  32. 32. Reusable business logic should remain fine grained.
  33. 33. So Component Distribution is a problem!!!......
  34. 34. What’s the Solution??</li></li></ul><li>Façade Pattern-A Solution<br /><ul><li>We don’t want to publish the fine grained entities to the client, so we have to provide a coarse view of them.
  35. 35. We do not want to change the interface too..
  36. 36. Façade provides such a view which satisfies different system specific demands like web services. </li></li></ul><li>Demarcated SOA v/s Components<br />In principal, SOA is the enhancement of components.<br />Individual services are single components which can be linked to gain new business logic, new services or a new components.<br />The big difference is the connection between the possibilities of offering single service for third parties.<br />EJB(especially Session Beans) can be designed to offer its business methods like services in a context free way.<br />Compare it with a department in a company offering a service to other department.<br />
  37. 37. IS SOA a miracle cure?<br />SOA is a step forward from component technology but not a miracle-cure.<br />It gives loose coupling, higher reusability, faster development and a complete new style of software development.<br />Two points of differentiation:<br />Services are public not models of development. Can be accessed through registries as done in Yellow Pages.<br />Services have to be largely independent from implementation specific attributes. E.g. Java, .Net or Perl. (Communication –XML and SOAP)<br />
  38. 38. Discussions and Justifications<br />Performance Issues of Web Services:<br />Long chain of web services reliance<br />Non-public services cause transport security and transaction issues. E.g. JMS-Web Services bridge<br />Which Web Services are right for me?<br /><ul><li>Technologies like UDDI does help in doing this job but it is not an efficient and competitive way.
  39. 39. Write undiscoverable web services oneself…That’s against the idea of SOA!! Than there’s no real advantage of SOA over CBD. </li></li></ul><li>Discussions and Justifications<br />Quality of Service of foreign applications:<br /><ul><li>Non-functional attributes like performance, reliability, security and manageability have to be detected.
  40. 40. There should be a metrics to decide for a fit of service.
  41. 41. Performance with SOAP
  42. 42. SOAP is a de-facto wire protocol for web services.
  43. 43. SOAP performance is degraded due to the following:</li></ul>SOAP envelop extraction from SOAP packet is very time-expensive.<br />SOAP encoding rules makes it mandatory to include typing information in all the SOAP messages sent and received.<br />
  44. 44. Discussions and Justifications<br />Data Overhead:<br /><ul><li>XML is a language independent, platform independent, easy to recognize and normal textual format.
  45. 45. SOA uses XML for data exchange and interchange.
  46. 46. A coin has two sides….
  47. 47. Higher need of data transfer  lower performance and higher usage of network and internet traffic.
  48. 48. Parsing the XML information contained in an envelop is time-consuming.
  49. 49. Very less time is consumed in serializing and de-serializing sent in a binary format over the network.
  50. 50. Very less data optimization is possible with XML.</li></li></ul><li>More Offerings<br />SOA services can be built on CBD principles, it adds a new layer for reuse.<br />SOA services can be reused via standard communication over ESB and discoverability offered by repositories.<br />Using XML and web services SOA applications have become distributed but there are still questions about security, transactions, fault tolerance, change management.<br />Technical SOA principles like data ownership are object oriented so technically it is not a novelty.<br />Business functionality which raises the level of abstraction separates SOA services from common components.<br />
  51. 51. Future Work<br />Component based paradigm has a long history relatively behind them.<br />Solid methodology for developing component based applications.<br />As SOA paradigm matures, it requires careful consideration of the role of different software artifacts in the system.<br /> e.g. clearly distinguish between reusability on different levels, for instance.<br />
  52. 52. Conclusion<br />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.<br />Developers can use foreign external components as Web Services.<br />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.<br />There are a lot of problems but there are a lot of possibilities too.<br />In our opinion future is about Component based SOA(CSOA).<br />
  53. 53. References<br />Hanson, J: Coarse-grained interfaces enable service composition in SOA. URL:<br />Siddiqui, F: Component based software engineering, a look at reusable software components (August 2003)<br />Stal, M. : Using architectural patterns and blueprints for service-oriented architecture. Software, IEEE 23(2) (2006) 54-61<br />Enterprise Service Bus. URL: service bus<br />Elrad, T., Aksit, M. , Kiczales, G., Lieberherr, K., Ossher, H. : Discussing aspects of Component Communication. ACM 44(10) (2001) 33-38<br />
  54. 54. Q & A?<br />