1
Component Assembly Evaluation
• Simple C++ expressions
• Operators ( +, *, f() )
• Operands ( x, y, a )
• A compiler will optimize the evaluation of the expression
• Well-known optimizations
• Component assembly
• No optimizations performed!
• Can we do better?
• Exploit the metadata available at the asssembly level
• Optimize evaluation of expression
void foo () {
int x = 1;
double y = x + 7;
float a = x * y;
short c = f(a, y);
}
short f (float x1, double y)
{ return x1 * x1 + y * y; }
2
Middleware
MiddlewareServices
DRE Applications
Operating System& Protocols
Hardware & Networks
DRE Systems: The Challenges Ahead
•DRE systems
•extremely sensitive to Limit to how much application functionality can be refactored into reusable COTS middleware
•Middleware itself has become very hard to use & provision statically & dynamically
IntServ + Diffserv
RTOS + RT Java
RT/DP CORBA + DRTSJ
Load BalancerFT CORBA
Network latency & bandwidth
Workload & Replicas
CPU & memory
Connections & priority bands
RT-CORBA
RT-CORBAServices
RT-CORBAApps
J2ME
J2MEServices
J2MEApps
DRTSJ
DRTSJServices
DRTSJApps
•Component-based DRE systems are also very hard to deploy & configure
•There are many middleware platform technologies to choose from
Gigabit Ethernet
Gigabit Ethernet
3
Where is “Platform-Independence”?• Coming soon to an installer near you • Refactor existing metamodel to PICML
(the new one)
• Platform-Independence™
• Write GReAT transformations
• Smooth upgrades
• New capabilities
• Generate .NET artifacts
• Component Interfaces
• Assemblies
• Assembly manifests
• Target .NET CLR
Platform Independent Component Modeling
Language(PICML)
PICML for CCM
PICML for .NET
OMG D+C Descriptors
.NET assembly
descriptors
GReAT Transformations
Interpreters Interpreters
CCM Runtime
.NET CLR
4
What about scalability?
• Scalable modeling requirements• Eliminate redundancy• Fast UI response time• “Less is more”
• Scalable Features in PICML• Hierarchical assemblies
• If you add a feature, people will use it; often in an unexpected fashion
• Attribute mapping• Initialize attributes at
assembly level• Coming soon
• Property mapping• Similar to attribute mapping
• Pre-defined blocks
5
Enforcing Policies on Components
• Allow transparent injection of policies
(add-hook ‘invoke-hook ‘policy)
• Models as vehicles
• Capture policies as metadata
• Single meta-programmable injection framework
• Instantiated by CIDL compiler
• Orthogonal evolution of framework & policy
Executors
Servants
Executor Stubs
Skel
IDL
Stub
CIDL
Executor IDL
MetaProgrammable Injection Framework
QoS Contract Injection
Your Policing code
Fault Injection
PICML
Generated
Hand-Written
Generates
Inherits
Delegates
Injects
6
Component-based UAV system Challenges (5/5)• Automating propagation of
changes• Typical in DRE systems
evolution• Currently changes propagated
in an ad-hoc fashion
• Redundant effort• Cascading effect
• Change to a single UAV stream
• Needs to get propagated to all instances of the stream
– 1 stream per UAV – n streams in total
(n>=50)• Difficult to estimate effect of
changes
Control Center Display
SystemResourceManager
LocalResourceManager
Sender ReceiverCrop
Qosket
Compress Qosket
Scale Qosket
Compression QoS Predictor
Scaling QoS Predictor
Cropping QoS Predictor
Stream 4
Stream 3
Stream 2
Stream 1
7
Middleware
MiddlewareServices
DRE Applications
Operating System& Protocols
Hardware & Networks
RT-CORBA
RT-CORBAServices
RT-CORBAApps
J2ME
J2MEServices
J2MEApps
DRTSJ
DRTSJServices
DRTSJApps
Promising Solution: Model Driven Development (MDD)
• Develop, validate, & standardize generative software technologies that:
1. Model
2. Analyze
3. Synthesize &
4. Provision
multiple layers of middleware & application components that require simultaneous control of multiple QoS properties end-to-end
• Partial specialization is essential for inter-/intra-layer optimization & advanced product-line architectures
Goal is to enhance developer productivity & software quality by providing higher-level languages & tools for middleware/application developers & users
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
Gigabit Ethernet
Gigabit Ethernet
8
Concluding Remarks• Models can be used as vehicles
• To automate non-scalable activities• To identify & eliminate redundancy• To identify & perform optimizations not possible otherwise• To specify policy
• Middleware & associated frameworks (in conjunction with models)• To execute on instructions from models• To enforce policy
9
Challenge 2: Lack of Tools for Component Composition
• Once designed, components are implemented, built and packaged into a single run-time artifact
• Add/remove functionality iteratively• Each component participates in a variety of contexts & roles• Code for each context & role
• Always present, or• Dynamically loaded using strategies
• Add up to the time/space overhead of components• Lack of tools & abstractions
• To build, store, retrieve, version components• Previous generation middleware abstractions insufficient
• Maintain multiple lean & mean implementations of application components
10
Challenge 3: Lack of Tools for System Composition
• Components are developed in isolation• Without application context• Combined into assemblies to realize functionality
• Limited composition granularity• Restricted to interactions via ports, e.g., elements on a
motherboard• Separate implementations• Source of time/space overhead
• Lack of tools for fine-grained composition• Single implementation with all functionality, e.g. System-On-a-
Chip (SOC)
11
Challenge 4: Lack of Optimization Automation Infrastructure
• Variety of optimizations spanning different stages in lifecycle• Application context-driven (Design-time)• Platform-driven (Operating System, language) (Development
time) • Composition-driven (intra-technology, i.e., middleware)
(Development/Integration-time)• Integration-driven (inter-technology, i.e., all of the above)
(Integration-time)• Existing tools
• Can do one or two of the above• Never all of the above
• Perform optimizations on different artifacts• Lack common underlying representation
• Operate at low-level• Lack high-level abstraction
12
Challenge 3 Resolved: Exploit semantics of component models
• Define a meta-language for application composition• Operators (port operations)• Operands (component ports, components, component assemblies)
• An Application is an equation (or sentence) in this language• Optimize inefficient sentences into efficient ones
• Define execution equivalence semantics between sentences• Theoretically, e.g. using I/OAutomata (needs further investigation) • Empirically, e.g. Validate using CUTS • Build catalog of equivalent sentences
• Sentence A is equivalent to sentence B, iff the effect of evaluating A will yield similar externally observable results as evaluating B, in either the same context C, or a context C’ reducible to C
• E.g., Invoking a method over IIOP vs UIOP• Fuse individual component implementations of an assembly
• Opportunistically & auto-magically when semantics allow such fusion• Component Assembly Fusion == System-On-a-Chip
13
Challenge 4 Resolved: Use Models as Integration Carriers
• Use models as carriers (vehicles) to carry optimization information• Similar to request processing in network stacks with zerocopy
semantics• Request invocation/upcall is done via a single thread context
propagated between layers in the networking stack• Different optimizations (layer processing) associated on the
same model (context) • Spans entire life-cycle of component development
• Design time, Development time, Integration time• Share common underlying representation across different
stages of life-cycle• Exchange integration information with other tools
14
Integration of Heterogeneous Systems• Complex Systems are rarely
implemented using a single component middleware platform
• Every system needs some kind of integration
• Integration with legacy systems
• Integration with COTS systems
• Integration with client systems
• Support for integration with systems is critical to success of component middleware
• Also is backward compatibility
15
Related ResearchCategory Related Research
16
Challenge 4: Ineffective Tool Support for System Integration
Unresolved Challenges
• Integration of heterogeneous systems are almost always done at middleware level or lower
• Potential for major disruption at integration time
• Renders enhanced tool support for other stages of system development meaningless
• Integration purely at the middleware level is error-prone
• Need for higher levels of abstraction for integration of systems
CORBA Component
Model (CCM)
Microsoft .NET Web Services
Enterprise Java Beans (EJB)
17
• Presence of models of platforms to be integrated offers a possible solution
• Significant requirements from modeling infrastructure
• Support composition of metamodels
• Support independent evolution of
• Composition
• Things being composed
• Allow load/save of models corresponding to both platforms in the composed metamodel
CORBA Component
Model (CCM)
Microsoft .NET Web Services
Enterprise Java Beans (EJB)
Challenge 4: Ineffective Tool Support for System Integration
18
Proposed Approach: Multi-Platform System Integrator Tool• Enhance modeling infrastructure to
support seamless composition of metamodels
• Work with GME infrastructure team!
• Utilize enhanced infrastructure support to
• Refactor PICML• Allow integration of systems
using both .NET & CCM• Develop a pluggable glue-code
framework for • Bridging/Adapting cross-
platform invocations• Generate code to perform
adaptation utilizing above framework
PICML (CCM)
PICML (.NET)
CCM Models
.NET Web Service Models
PICML (CCM+.NET)
GME Composition
CCM Deployment descriptors
.NET Deployment descriptors
CCM Deployment descriptors
.NET Deployment descriptors
CCM+.NET Web Service
Models
19
Proposed Approach: Criteria for Evaluation
• Demonstrate feasibility of integration by prototyping an application
• Bridges/adapts calls from CCM to .NET Web Services & vice-versa
• Demonstrate feasibility of automation of integration done at modeling level
• Identify & document requirements from modeling infrastructure (if any) for future improvements
PICML (CCM)
PICML (.NET)
CCM Models
.NET Web Service Models
PICML (CCM+.NET)
GME Composition
CCM Deployment descriptors
.NET Deployment descriptors
CCM Deployment descriptors
.NET Deployment descriptors
CCM+.NET Web Service
Models