Architecting Composite Component Systems for Heterogeneous Environments with Open Standards. Derek Dominish
March 5, 2016 | Author: Norah Charles | Category: N/A
Short Description
Download Architecting Composite Component Systems for Heterogeneous Environments with Open Standards. Derek Dominish...
Description
Architecting Composite Component Systems for Heterogeneous Environments with Open Standards Derek Dominish Aerospace Division Future Information Architectures MilCIS - Canberra 14th November 2013
© Commonwealth of Australia
The NCW Integration Complexity Problem Problem Space • Network-centric, dynamic, very large-scale “systems of systems” • Stringent simultaneous quality of service (QoS) demands • Highly diverse & complex problem domains
CHAOTIC Solution Space • Enormous accidental & inherent complexities • Continuous evolution & change • Highly heterogeneous environments
Mapping & integrating problem artifacts to solution artifacts is extremely difficult Adapted from: “Overview of the OMG Data Distribution Service”, Schmidt/Parsons (DDS.ppt; pp 7)
1
Open Architecture through Open Standards Surface System
Aircraft System
Common Computing Environment Land System
Common Computing Environment
‘POSIX’, CORBA, DDS, etc.
Service Orientated - Open Architecture
Common Computing Environment
Sub-Surface System
Standards Based Computing Environment ‘POSIX’, CORBA, DDS, etc.
Standards Based Computing Environment ‘POSIX’, CORBA, DDS, etc.
Standards Based Computing Environment ‘POSIX’, CORBA, DDS, etc.
Standards Based Computing Environment Common Computing Environment
TM, NAV, ID, etc.
Common Functions
Surface Combatant Unique Functions
SCS System Unique & Common Applications & Interfaces
Aircraft Unique Functions
Aircraft System Unique & Common Applications & Interfaces
Land Unique Functions
Soldier System Unique & Common Applications & Interfaces
Sub-Surface Unique Functions
Submarine System Unique & Common Applications & Interfaces
TM, NAV, ID, etc.
Common Functions TM, NAV, ID, etc.
Common Functions TM, NAV, ID, etc.
Common Functions Common Platform Functions
Platform Unique Functions
Interoperable System-of-Systems
Common Middleware Bus Architecture Adapted from: “Open Architecture” , Strei; 2/2/2004 (NOAbrf.ppt; slide 4)
Net Centric Mission Environment
Levels Of Information Systems Interoperability (LISI) Reference Model Adapted from: “Overview of the OMG Data Distribution Service”, Schmidt/Parsons (DDS.ppt; slide 8)
2
Layered Reference Architecture Tactical SOA (OA) The Strategic Architecture Reference Model (SARM)
The SARM is; •
an open communications and information architecture framework supported by NCOIC,
•
based upon commercial and government interfacing standards (IDL),
•
organized to address system-wide network design issues,
•
an enabling technology framework to allow platforms and tactical systems to interface to the Global Information Grid,
•
allows for interoperable nodes on the network.
Adapted from: Technical Reference Model for Network-Centric Operations Bradley C. Logan. The Boeing Company (Crosstalk Aug 2003; Vol16, No8)
The Strategic Architecture Reference Model (SARM)
Tactical SOA Reference Architecture Business Services
Business Services are; •
a unit of autonomous behaviour that meets a particular business need,
•
constructed / assembled from one or more components that support a business ontology,
•
conform to an infrastructure plug and play deployment policy,
•
orchestrated through an application,
•
collaborate with other peer services within a network,
•
location and machine architecture independent,
•
built upon standardised infrastructure services and mechanisms,
•
often needed to adapt to legacy environments,
•
expressed through formal and interoperable service interface definitions (IDL [PIM]) to the network.
•
not necessarily reliant on any particular networking protocol or communications infrastructure.
3
Net-Centric Reference Architecture (SOA)
COP Generator
Adaptor
Configuration
API
Correlation
Application
Fusion
Application
Interface Control
Security Boundary
Interface Control
Domain Environment
COP Adaptor
Ontology / Schema
Device/System
Database Tables
Schema Information Assurance Filter
COP Generator
Search / Query
COP Adaptor
Database Tables
Domain Environment (CCM/EJB/Web-Services)
Information Infrastructure Core - Middleware Environment (CORBA/DDS/RMI) Communications Environment – Transports / Protocols (TCP/UDP/IIOP) Platform Environment – Posix Compliant Operating System / Services (Solaris/Windows)
System-of-Systems Integration Infrastructure Architecture A Standardised Middleware Approach
System Integration Through Service Composition
Service Infrastructure – Middleware Fabric (L0)
Information Assurance Communication: QoS, encryption, bandwidth Security: boundaries, classification, communication routes Authentication: information ownership, need to know
4
System-of-Systems Integration Infrastructure Architecture A Standardised Middleware Approach
B1 Architecture layers (partial applications)
B2
Interoperating across vendors and systems Ontological Conformity Integrate “services” through layering Standardisation Interfaces Protocols Hooking into appropriate layer Easier, cheaper to change and upgrade Open business practices Indeterminate liability Certification
B3
B3
B4
B5
L3
L2.5
L3
L2
L2
L1
L1
L1
L0
Application Server ‘Application Store’ Application Servers; Application Server (process) Managed Infrastructure Services Infrastructure Services
Control - Status
Gestalt
Service Configurator
loads
Application Server Interface
Business Services
• • • • • •
Thread Management Transaction Management Communications control DDS Domain / Participant / Topic / Type Instrumentation Visualisation
manage component service complexity,
•
dynamically and statically load and configure service components,
•
provide infrastructure capabilities and services to hosted components; • logging, • aids to debugging, • instrumentation, • capabilities dynamically configurable and extensible.
•
manage coupled middleware environment; • security and access policy enforcement, • Communications, protocols and bearers, • … many other environmental aspects.
•
manage lifecycle of hosted components (initialisation, shutdown, suspend, resume),
•
facilitate the navigability to individual component interface implementations,
•
manage the optimisation of peer component interactions through collocation,
•
location and machine architecture independent,
•
built upon standardised infrastructure services mechanisms and patterns,
•
supports a network accessible service control and status interface.
Application Components (services)
implements
controls
Service Configuration
•
Gestalt
5
Technical Architecture ‘putting it all together’
Application Server Service Gestalt realises
Component Configurator Service Configurator Domain/Middleware Communications/Platform
Net Warrior D10 Process Domain MSRC (AEW&C - AOD) WIRE
MSRC (ASCEL - AOD) Data-Link Gateway
Recorded Feed
Wedgetail Scenario
Wedgetail (SOA)
(IWARS)
Network Management System
TADIL Network (L16) IDL/WSDL/SOAP
Middleware
IP/TCP/UDP/IIOP/HTTP
Network / Physical
OMG – DDS/CORBA
Solaris/Linux/Windows
ISRAIL (ISRD)
External Feeds
FOCAL (C3ID)
Correlation and Tracking
Full Motion Video
ROC
Command Centre ISR Integration (ADIIB)
Legend of Technology
Visualisation
GIS
Operational Information Portal
Legend of Adapter Transform
Tactical Data Links (Link-16)
DDS – CORBA
OMG – Data Distribution Service (DDS)
DDS – XML
OMG – Common Object Request Broker Architecture (CORBA)
DDS – Web-Services
IBM – Web-Services (SOAP)
Proprietary – Web-Services
Extensible Mark-Up Language (XML) Proprietary Technology / Interface
6
Net Warrior (D10 Event) Bus Architecture A Standardised Middleware Approach – Demonstration Event
Visualisation Surveillance Network Management
Stimulation (truth)
Tracking
Mission Systems Bridge
Gateway
Enterprise
DDS
Real Time Publish/Subscribe & Synchronous Control Bus – (CORBA/DDS) CORBA
CORBA
SOAP
SOAP
SOAP
Enterprise Information Service Bus – (Web-Services) XML
TDL
SOAP
XML
TDL TacticalTDL Data Link Network – (Link16/Link11/VMF)
Demonstration Artefacts -This really works! The Build Process.
The Development Process. • Define an interface (IDL)
• Create a service project MakeProjectCreator descriptor for MPC toolset project(CORBAService) : taflib, taolib_with_idl { sharedname = * idlflags += -Wb,export_macro=CORBAService_Export \ -Wb,export_include=CORBAService_export.h libout = $(DAF_ROOT)/lib libpaths += $(DAF_ROOT)/lib macros += CORBASERVICE_BUILD_DLL prebuild = perl $(ACE_ROOT)/bin/generate_export_file.pl CORBAService > CORBAService_export.h IDL_Files { CORBAService.idl } Header_Files { CORBAService.h CORBAService_export.h } Inline_Files { } Source_Files { CORBAService.cpp } }
• Use MakeProjectCreator (MPC) to build solution files for platform toolsets (Windows/Linux …). perl %ACE_ROOT%/bin/mwc.pl -type vc10 -name_modifier *_vc10 -apply_project TAF_DAF.mwc
• Load project into toolset environment (i.e. Windows - VC10)
• Implement interface providing service descriptors for application server deployment control (CORBAService.cpp).
• Deploy with configuration (DSTO.conf) • Build binaries with toolset applicable to platform environment.
7
Questions?
The Age – Australian Newspaper
8
View more...
Comments