Interoperable Open Architecture through a Common Component Model
2 likes1,139 views
The document outlines the concept of an Interoperable Open Architecture (IOA) through a Common Component Model (CCM), emphasizing information exchange patterns such as request/response and publish/subscribe for real-time embedded systems. It promotes component-based development for its modularity, reusability, interoperability, and reduced complexity, enabling independent updates and faster deployment. The solution leverages open standards and an open-source approach, facilitating integration across various platforms and ensuring a standardized environment for software development.
Interoperable Open Architecture through a Common Component Model
- 1. Interoperable Open Architecture (IOA) through Common Component Model (CCM) Johnny Willemsen Copyright © 2011 Page 1
- 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 systems Copyright © 2011 Page 2
- 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 available Copyright © 2011 Page 3
- 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 ports Copyright © 2011 Page 4
- 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 functionality Copyright © 2011 Page 5
- 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 level Copyright © 2011 Page 6
- 7. Separate middleware logic from business logic Components shouldn't be cluttered with middleware related logic – Components shouldn't be tied to a specific middleware – Which middleware to be used is a deployment decision, not an implementation decision Copyright © 2011 Page 7
- 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 footprint Copyright © 2011 Page 8
- 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 implementations Copyright © 2011 Page 9
- 10. System Development Lifecycle Copyright © 2011 Page 10
- 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 packages Copyright © 2011 Page 11
- 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-configuration Copyright © 2011 Page 12
- 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. Open standards Open standards are required to ensure interoperability between tools and middleware All parts of the solution are based on open standards Copyright © 2011 Page 14
- 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 process Copyright © 2011 Page 15
- 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 – http://www.orbzone.org/node/182 Copyright © 2011 Page 16
- 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 solution Copyright © 2011 Page 17
- 18. Johnny Willemsen jwillemsen@remedy.nl Copyright © 2011 Page 18
- 19. For more information OMG – www.omg.org Remedy IT hosted websites – www.theaceorb.nl – www.remedy.nl – www.orbzone.org – osportal.remedy.nl Vanderbilt/Douglas Schmidt – www.dre.vanderbilt.edu – www.cs.wustl.edu/~schmidt Copyright © 2011 Page 19