Interoperable Open Architecture through a Common Component Model


Published on

This presentation goes into some of the concepts that are in a Common Component Model that could lead to a real Interoperable Open Architecture

Published in: Technology, Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Interoperable Open Architecture through a Common Component Model

  1. 1. Interoperable Open Architecture (IOA) through Common Component Model (CCM) Johnny WillemsenCopyright © 2011 Page 1
  2. 2. Information Exchange Patterns All systems are using the following information exchange patterns – Request/response (SOA) ▪ Mostly one to one behavior like command and control – Publish/subscribe ▪ Many to Many We want to model and implement these information exchange patterns without requiring a specific middleware The solution must be usable for real-time embedded systemsCopyright © 2011 Page 2
  3. 3. IDL as part of the solution Define the information exchange patterns in a manner that is independent of programming language or particular middleware Formal OMG/ISO standard IDL (Interface Definition Language) is used for example by CCM, CORBA, and DDS Language mappings for various programming languages are availableCopyright © 2011 Page 3
  4. 4. What is a component Independently revisable unit of software with a well defined interface Well defined interfaces are called “ports” Able to be packaged into an independently installable set of hierarchically defined files Smallest decomposable unit that defines standard ports is called a “monolithic component” A “component assembly” is a higher level aggregation of monolithic components or other component assemblies A component/assembly defines an aggregation of multiple portsCopyright © 2011 Page 4
  5. 5. Why Component Based Development (1/2) Modularity – Components can be independently updated or replaced without impacting the rest of a system Reuse – Software is reusable at the component level instead of a full system level Interoperability – Well-defined ports and container-based development ensures interoperability between application components Extensibility – A Component Based Architecture (CBA) is inherently loosely-coupled, supporting easier extensibility of component and system functionalityCopyright © 2011 Page 5
  6. 6. Why Component Based Development (2/2) Reduced Complexity – Encapsulation, modularity, separation of concerns and the establishment of hierarchical component dependencies, or “layers”, all contribute to reduced design & system complexity Reduced Design Time – Faster time-to-market, shortened program/software development schedules – Focus changed to composition of a software-intensive system vs. all new design Lower Design & Maintenance Costs – Result of shorter design times, reuse and less complexity Quality & Reliability – Reuse and test/maintenance at the component level vs. at a monolithic system levelCopyright © 2011 Page 6
  7. 7. Separate middleware logic from business logic Components shouldnt be cluttered with middleware related logic – Components shouldnt be tied to a specific middleware – Which middleware to be used is a deployment decision, not an implementation decisionCopyright © 2011 Page 7
  8. 8. Connectors Connectors implement an information exchange pattern on top of a specific middleware standard/product Can be configured at deployment time to support various QoS properties Connector implementations exist outside of the container and are loaded at deployment time – Component containers need not be aware of any particular distribution middleware – Simplifies container implementation and reduces run-time footprintCopyright © 2011 Page 8
  9. 9. Component Based DDS Makes DDS available to CCM through a connector Based on the OMG DDS4CCM specification Configuration of all DDS QoS at deployment time through XML instead of hardcoded in the component Encapsulates all vendor specific extensions Configuration decisions are moved from the implementation phase to the deployment phase Provides simplified interface that is consistent across all DDS implementationsCopyright © 2011 Page 9
  10. 10. System Development LifecycleCopyright © 2011 Page 10
  11. 11. Component/Connector Repository Should support all steps in the system development cycle, from specification through implementation, assembly, and deployment Contains meta-data necessary for component re-use – Resource requirements – Capabilities – Configuration information Supports both monolithic components and component assemblies Delivers design, implementation, and packagesCopyright © 2011 Page 11
  12. 12. CCM is supported by Deployment & Configuration Standardized set of interchange formats for the whole lifecycle of an application – Component specification – Component implementation – Component assembly – Component packaging – Component application planning – Component application deployment – Component application re-configurationCopyright © 2011 Page 12
  13. 13. Model Driven Architecture - MDA Full system development cycle supported by MDA/MDE tooling Multiple tool vendors support CCM/D&C/DDS4CCM – Atego – Zeligsoft – Vanderbilt University (CoSMIC) – Remedy IT (CMDL)Copyright © 2011 Page 13
  14. 14. Open standards Open standards are required to ensure interoperability between tools and middleware All parts of the solution are based on open standardsCopyright © 2011 Page 14
  15. 15. Open source Our CCM/D&C solution is open source No development and no runtime license costs Open Source is still a business model, funding is needed for adding features – Improved support for component packaging – Integrated tools for whole-lifecycle management of the component design, implementation, and deployment processCopyright © 2011 Page 15
  16. 16. Northrop Grumman Teton Project OA & MOSA are the charter tenet Developed a Component Based SDK for High Performance Computing Applications All APIs are based on open standards and preferably open source A public NGC presentation has been posted to ORBzone – © 2011 Page 16
  17. 17. Conclusion A Common Component Model approach leads to: – Reduced development time – More reuse of developed artifacts – More flexible systems – A standards based component/application store – Integrates DDS and CORBA out of the boxDelivers a Real Time SOA solutionCopyright © 2011 Page 17
  18. 18. Johnny Willemsen jwillemsen@remedy.nlCopyright © 2011 Page 18
  19. 19. For more information OMG – Remedy IT hosted websites – – – – Vanderbilt/Douglas Schmidt – – © 2011 Page 19