model-driven engineering of component middleware-based systems vanderbilt university nashville,...
TRANSCRIPT
Model-Driven Engineering of Component Middleware-based
Systems
Vanderbilt University Nashville, Tennessee
Institute for Software Integrated Systems
CS WithIT Seminar, April 26th, 2007
Krishnakumar [email protected]
www.dre.vanderbilt.edu/~kitty
2
Model-Driven Engineering Approach
• System Composition Technologies – A Domain-Specific Modeling Language (DSML) to allow component specification & composition
• System Optimization Technologies – System optimization infrastructure• Generation Technologies – Metadata generation infrastructure• System Integration Technologies – System Integration using model
composition
Generation Technologies
System Composition Technologie
s
System Optimization Technologie
s
System Integration
Technologies
3
Presentation Road Map
• Technology Context• Overview of Research Challenges• Research Area 1: Component System
Integration • Research Area 2: Application-Specific
Optimizations• Summary of Research Contributions• Concluding Remarks
4
Component Middleware
• Components encapsulate “business” logic
• Components interact via ports• Provided interfaces• Required interfaces• Event sinks & sources• Attributes
• Allow navigation between ports• Containers provide execution
environment for components• Components/containers can also
• Communicate via a middleware bus & reuse common middleware services
SecurityReplication NotificationPersistence
SchedulingA/V Streaming Load Balancing
Middleware Bus
…
Container
… …
…
Container
Components allow reasoning about systems at higher level of abstraction
e.g., CORBA Component Model (CCM), Microsoft .NET Web Services, Enterprise Java Beans (EJB)
5
Presentation Road Map
• Technology Context• Overview of Research Challenges• Research Area 1: Component System
Integration • Research Area 2: Application-Specific
Optimizations• Summary of Research Contributions• Concluding Remarks
6
Component System Development Challenges• Lack of system composition tools
Component
ResourceRequirements
Impl Impl Impl
Properties
Component Assembly
ComponentComponent
ComponentComponent
7
Component System Development Challenges• Lack of system composition tools
• Complexity of declarative platform API & notations
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
OS KERNEL
OS I/O Subsystem
Network Interfaces
OS KERNEL
OS I/O Subsystem
Network Interfaces
MIDDLEWARE
ComponentComponent
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
XML
XMLXML
XML
8
Component System Development Challenges• Lack of system composition tools
• Complexity of declarative platform API & notations
• Composition overhead in large-scale systems
Node Application
Container
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CH
Receptacle
Facet
Event Sink
Event SourceComponent Home
Component Assembly
Component Remote Invocation
Collocated Invocation
Creates
9
Component System Development Challenges• Lack of system composition tools
• Complexity of declarative platform API & notations
• Composition overhead in large-scale systems
• Need to integrate with systems built using heterogeneous middleware
10
Component System Development Challenges
My research provides tools to design, optimize & integrate “systems-in-the-large”
• Lack of system composition tools
• Complexity of declarative platform API & notations
• Composition overhead in large-scale systems
• Need to integrate with systems built using heterogeneous middleware
• Emphasis still on programming-in-the-small
• Whack-a-mole approach to system development
• Violation of Don’t Repeat Yourself (DRY) principle
• Need abstractions for expressing system level design intent
11
Solution Approach: PICML & SIML
• System Composition Technologies – A Domain-Specific Modeling Language (DSML) to allow component specification & composition
• System Optimization Technologies – System optimization infrastructure• Generation Technologies – Metadata generation infrastructure• System Integration Technologies – System Integration using model
composition
Generation Technologies
System Composition Technologie
s
System Optimization Technologie
s
System Integration
Technologies
12
Presentation Road Map
• Technology Context• Overview of Research Challenges• Research Area 1: Component System
Integration • Research Area 2: Application-Specific
Optimizations• Summary of Research Contributions• Concluding Remarks
Research Area 1: Component System Integration• Integration can be done at multiple levels
• Process Integration• Functional Integration• Data integration• Presentation Integration• Portal Integration
• System refers to software systems built using
• Service-Oriented Architecture (SOA) technologies like Web Services
• Component middleware technologies like Enterprise Java Beans (EJB), CORBA Component Model (CCM)
• System Integration refers to functional integration done via
• Distributed Object Integration• Service-Oriented Integration
13
Related Research
14
Category Related Research
Integration Evaluation Tools
IBM’s WebSphere
Smith, C., & Williams, L. (2001). Performance Solutions
Integration Design Tools
Object Management Group. UML Profile for Enterprise Application
Integration (EAI), omg document formal/04-03-26 edition, March 2004.
Integration Patterns
G. Hohpe and B. Woolf. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, October 2003.
Resource Adapters
Java Messaging Specification & J2EE Connector Architecture
IBM’s MQSeries (IBM, 1999), Microsoft BizTalk Server
Integration frameworks
Web Ontology Language. www.w3.org/2004/OWL/, Feb 2004.
Ian Foster, C. Kesselman, J. M. Nick, and S. Tuecke. Grid Services for Distributed System Integration. Computer, 35(6):37–46, 2002
L. Zeng, B. Benatallah, A. H. Ngu, M. Dumas, J. Kalagnanam, and H. Chang. QoS-Aware Middleware for Web Services Composition. IEEE Trans. Softw. Eng., 30(5):311–327, 2004
Integration Quality Analysis
H. Ludwig, A. Keller, A. Dan, R. P. King, and R. Franck. Web Service Level Agreement Language Specification. http://researchweb.watson.ibm.com/wsla/documents.html, January 2003.
Related Research: What’s missing?• Integration Evaluation Tools
• Serve only the preliminary stage
• Integration Design tools• Not integrated with
deployment• Integration Patterns
• Offer best practices (only)• Resource Adapters
• Still require manual “integration programming”
• Integration frameworks • Rely on unambiguous, formal
representations of capabilities
• Not always feasible with legacy systems
15
GatewayComponent
GatewayComponent
NamingServiceNamingService
LoggingComponent
LoggingComponent
CoordinatorComponentCoordinatorComponent
DatabaseComponentDatabase
ComponentIdentity
ManagerIdentity
ManagerBusiness
LogicBusiness
Logic
Client A
Client B
component Logging_Service{provides Logger handle;consumes LogEvent log_event;
};
component Logging_Service{provides Logger handle;consumes LogEvent log_event;
};
WS-Log Analyzer
Log Analyzer
Logging Web Service
SOAP Server
CCM Client
TypeSpecific IIOP ó SOAP
Motivating Application• Enterprise Distributed System
• Different client applications• Differentiated services to
clients• System Domain
• Shipboard Computing • On-demand situation
awareness• Integration with human
operators• Logging Component
• Originally built using CORBA Component Model (CCM)
• Needed to be exposed as a Web Service
• Integrate with Log Analyzer built as Web Service Clients
16
Component System Integration: Unresolved Challenges(1/5)1. Choosing an appropriate level
of integration• Need to select elements from
the different technologies• Selection Challenges
• Number of normalizations• To/from native types
• Flexibility of deployment• In-process/Out-of-
process• Evolving the integration
architecture• Increasing the number
of peers integrated• Availability of platform-
specific infrastructure • OS, languages
17
System Integration
CORBA Component
Model Subsystem
Web Services Subsystem
Required Interface
Provided Interface
Event Source
Event Sink
Component
2. Reconciling differences in interface specifications
• Datatype Mapping• e.g., CORBA IDL to Web
Services WSDL• Exception Mapping
• e.g., SOAP faults to CORBA Exceptions
• Language Mapping• Different source/target
implementation languages• Limited scope at level of
functional integration • Restricted to out-of-
process IPC
18
component Benchmark_Data_Collector { provides Testing_Service testing_service;
provides BDC_Control_Handle controls;
attribute long timeout;
attribute string service; };
<wsdl:service name="CUTS.Benchmark_Data_Collector"> <wsdl:port name="CUTS.Benchmark_Data_Collector.online_measurements" binding="tns:CUTS.Benchmark_Data_Collector._SE_online_measurements"> <soap:address location="http://localhost:8080/" wsdl:required="false"/> </wsdl:port> <wsdl:port name="CUTS.Benchmark_Data_Collector.controls" binding="tns:CUTS.Benchmark_Data_Collector._SE_controls"> <soap:address location="http://localhost:8080/" wsdl:required="false"/> </wsdl:port> </wsdl:service>
Component System Integration: Unresolved Challenges(2/5)
Component System Integration: Unresolved Challenges(3/5)
Java Web Service Client
C# Web Service Client
TypeSpecific IIOP ó SOAP
SOAP Server
CCMClient
CCM Component
3. Managing differences in implementation technologies• How to map low-level technology details such as networking,
discovery?• Protocol differences
• e.g., Internet Inter-ORB Protocol (IIOP) in CCM vs. SOAP in Web Services
• Discovery services differences• e.g., CORBA Naming Service vs. UDDI repositories
• Quality of Service (QoS)• Ensure service-level agreements are met
19
Component System Integration: Unresolved Challenges(4/5)4. Managing deployment of
subsystems• Declarative notations used to
capture various configuration options
• e.g., CCM deployment descriptors, .NET assembly manifests
• Functionality of system depends on correct configuration of metadata
• Development-time default values different from production values
• e.g., configuration of Web Servers hosting Web Services
20
CCM Subsystem
QoS Properties
Checksum
Version Dependencies
List of FilesQoS Specs Component Interconnections
CCM ImplementationDLL DLL
Web Services Subsystem
QoS Properties
Checksum
Version Dependencies
Web Services ImplementationDLL DLL
Component System Integration: Unresolved Challenges(5/5)
5. Interoperability issues• Multiple implementations of same middleware technology• Differences between implementations
• e.g., Java Web Services stack vs. .NET Web Services stack• Problems show up only during system integration
• e.g., existence of standards like Web Services-Interoperability (WS-I)
• Need to deal with interoperability issues in a less than ideal world21
Component DSML A
Component DSML B
DSML A Models
DSML B Models
Composite DSML
Model Composition
Imported Entity
22
Solution Approach: (Meta-) Model Composition• System Integration using (Meta-)
Model composition• Hierarchical composition of multiple
domain-specific modeling languages(DSMLs)
• Each corresponding to the different middleware technologies (domains)
• Built in a reusable & extensible fashion
• “Open-Closed” principle• New languages can be added;
existing ones reused• Semantics of existing DSMLs
preserved in composition• Refinement of semantics
allowed
System Integration Modeling Language (SIML)• Prototype implementation of
(Meta-) model composition• Composed from two domain-
specific Modeling Languages (DSMLs)
• CCM Platform-Independent Component Modeling Language (PICML)
• Web Services Web Services Modeling Language (WSML)
• Supports integration of applications built using CCM and Web Services
23
System Integration Modeling Language (SIML)
PICML (CCM DSML)
WSML (WS DSML)
CCM Deployment descriptors
Web Service Deployment descriptors
Required Interface
Provided Interface
Event Source
Event Sink
CCM DSML
Web Services DSML
CCM Models
Web Service Models
System Integration
DSML
Model Composition
CCM Deployment descriptors
Web Service Deployment descriptors
CCM Deployment descriptors
Web Service Deployment descriptors
Integration Glue code
Imported Entity
Exported Entity
24
System Integration Evaluation Criteria1. Seamless support for existing
tools• Existing investment in tools
should be preserved2. Integration architecture should
evolve with changes to the applications
• Changes to applications shouldn’t require a lot of rework
3. Preserve application encapsulation
• Individual applications should be shielded from changes in other applications
4. Existing semantics should be preserved
• Semantics of stand-alone applications should be preserved
25
Evaluating System Integration using SIML1. Representation of independent
concepts• PICML & WSML model
interpreters work seamlessly in SIML
• Allows Import/Export of both PICML and WSML models
2. Supporting model evolution• PICML & WSML packaged as
read-only model libraries• Changes to either propagated
through library refresh3. Partitioning model namespaces
• PICML & WSML assigned separate namespaces
4. Handling constraints• Namespaces provide
appropriate context for constraint evaluation
System Integration Modeling Language
PICML WSML
Component
Port
Service
BindingPort
HttpsBinding
Service
BindingPort
1
2
3
4
SIML satisfies the evaluation criteria for system integration
Resolving Challenge 1 : Choosing Integration Level• Combination of pre-defined
& customizable integration levels
• Pre-defined interactions• CCM Ports Web
Service Ports• User-defined interactions
• Component level• Assembly level
• SIML defines new interactions between CCM ports and Web Services ports
• Allows integration of other middleware technologies
• e.g., Enterprise Java Beans
26
System Integration Modeling Language
Web Services Modeling Language
Platform-Independent Component Modeling Language
CCM Component
Gateway
Identity Manager
Business Logic
Naming Service
Coordinator
Database
Logging Logging
Java Log Analyzer
C# Log Analyzer
Log Analyzer
Web ServiceWeb Service Client
SIML allows representing integration architecture at the model level
Resolving Challenge 2: Reconciling Differences in Interfaces• SIML provides a set of tools
idl_to_wsdl, idl_to_picml, WSDLImporter
• Both IDL and WSDL can be directly imported into models
• Performs datatype mapping• Maps CORBA datatypes
to WSDL datatypes• Performs exception mapping
• Maps CORBA exceptions to WSDL faults
• Limited language mapping • Maps ISO/ANSI C++ to
Microsoft C++/CLI
27
System Integration Modeling Language
Web Services Modeling Language
Platform-Independent Component Modeling Language
CCM Component
Gateway
Identity Manager
Business Logic
Naming Service
Coordinator
Database
Logging Logging
Java Log Analyzer
C# Log Analyzer
Log Analyzer
component Benchmark_Data_Collector { provides Testing_Service testing_service;
provides BDC_Control_Handle controls;
attribute long timeout;
attribute string service; };
<wsdl:service name="CUTS.Benchmark_Data_Collector"> <wsdl:port name="CUTS.Benchmark_Data_Collector.online_measurements" binding="tns:CUTS.Benchmark_Data_Collector._SE_online_measurements"> <soap:address location="http://localhost:8080/" wsdl:required="false"/> </wsdl:port> <wsdl:port name="CUTS.Benchmark_Data_Collector.controls" binding="tns:CUTS.Benchmark_Data_Collector._SE_controls"> <soap:address location="http://localhost:8080/" wsdl:required="false"/> </wsdl:port> </wsdl:service>
idl_to_picml.exe
idl_to_wsdl.exe
WSDLImporter.exe
Web ServiceWeb Service Client
SIML’s interface mapping automatically handles differences in interfaces
Resolving Challenge 3: Handling Implementation Differences• Resource Adapters are
typically used to bridge implementation differences
• SIML implements resource adapters via Gateways
• Automatically generates gateways from models
• Perform protocol mapping• IIOP SOAP mapping
• Perform discovery mapping• Connects to CORBA
Naming Service• Configurable Gateway
generation from models• GSOAP, Microsoft .NET
Web Services
28
System Integration Modeling Language
Web Services Modeling Language
Platform-Independent Component Modeling Language
CCM Component
Gateway
Identity Manager
Business Logic
Naming Service
Coordinator
Database
Logging Logging
Java Log Analyzer
C# Log Analyzer
Log Analyzer
TypeSpecific Gateway IIOP ó SOAP
GatewayGenerator.exe
Web ServiceWeb Service Client
SIML generates integration glue-code directly from the application models
Resolving Challenge 4: Managing Heterogeneous Deployment• Deployment of sub-systems
requires different mechanisms
• SIML can use existing tools for individual sub-system deployment
• Possible because of model composition
• Deployment metadata configuration & generation
• Directly from within SIML
• CCM• DeploymentPlan.exe
• Web Services• WSDLExporter.exe
29
System Integration Modeling Language
Web Services Modeling Language
Platform-Independent Component Modeling Language
Web Service Deployment descriptors
CCM Component
Gateway
Identity Manager
Business Logic
Naming Service
Coordinator
Database
Logging Logging
Java Log Analyzer
C# Log Analyzer
Log Analyzer
CCM Deployment descriptors
WSDLExporter.exe
DeploymentPlan.exe
Web ServiceWeb Service Client
SIML provides an integrated view of heterogeneous deployment
Resolving Challenge 5: Handling Interoperability Differences• Knowledge of sub-DSML
technologies built into SIML• Allows compensating for
interoperability differences• idl_to_wsdl.exe
• Maps IDL to WS-I defined subset of WSDL
• GatewayGenerator.exe• Inter-operable subset of
RPC encoding• WSDLExporter.exe
• Interoperable XML namespaces in WSDL
• Newly discovered incompatibilities can be worked around
30
System Integration Modeling Language
Web Services Modeling Language
Platform-Independent Component Modeling Language
Web Service Deployment descriptors
CCM Component
Gateway
Identity Manager
Business Logic
Naming Service
Coordinator
Database
Logging Logging
Java Log Analyzer
C# Log Analyzer
Log Analyzer
CCM Deployment descriptors
component Benchmark_Data_Collector { provides Testing_Service testing_service;
provides BDC_Control_Handle controls;
attribute long timeout;
attribute string service; };
<wsdl:service name="CUTS.Benchmark_Data_Collector"> <wsdl:port name="CUTS.Benchmark_Data_Collector.online_measurements" binding="tns:CUTS.Benchmark_Data_Collector._SE_online_measurements"> <soap:address location="http://localhost:8080/" wsdl:required="false"/> </wsdl:port> <wsdl:port name="CUTS.Benchmark_Data_Collector.controls" binding="tns:CUTS.Benchmark_Data_Collector._SE_controls"> <soap:address location="http://localhost:8080/" wsdl:required="false"/> </wsdl:port> </wsdl:service>
TypeSpecific Gateway IIOP ó SOAP
idl_to_picml.exe
idl_to_wsdl.exe
WSDLImporter.exe
WSDLExporter.exe
DeploymentPlan.exe
GatewayGenerator.exe
Web ServiceWeb Service Client
SIML codifies inter-operability workarounds
31
Summary of Research ContributionsCategory Benefits Publications
System Integration Technologies
• System integration from the high-level abstraction of models
• Model-composition allows preserving investment in existing domain-specific languages
• Relieves system integrators from dealing with intricacies of heterogeneous middleware technologies by automatically generating integration glue code
1. IEEE Engineering of Computer-Based Systems, 2007
2. Designing Software-Intensive Systems: Methods and Principles, Bookchapter Edited by Dr. Pierre F. Tiako, Langston University, OK. (Accepted for publication)
32
Presentation Road Map
• Technology Context• Overview of Research Challenges• Research Area 1: Component System
Integration • Research Area 2: Application-Specific
Optimizations• Summary of Research Contributions• Concluding Remarks
33
Control Center SystemResource
Manager
ScaleQosket
CropQosket
Compress Qosket
LocalResourceManager
Cropping QoSPredictorScaling QoS
Predictor
Compression QoSPredictor
Image Feeds (.NET Web
Service)
Research Area 2: Application Specific Optimizations • Middleware tries to optimize
execution for every application
• Collocated method invocations
• Optimize the (de-)marshaling costs by exploiting locality
• Specialization of request path by exploiting protocol properties
• Caching, Compression, various encoding schemes
• Reducing communication costs
• Moving data closer to the consumers by replication
• Reflection-based approaches
• Choosing appropriate alternate implementations
34
Related ResearchCategory Related Research
Component Middleware
Wang, N. et al, Applying Reflective Techniques to Optimize a QoS-enabled CORBA Component Model Implementation, 24th Annual International Computer Software & Applications Conference Taipai, Taiwan, October 2000.
Teiniker, E. et al, Local Components & Reuse of Legacy Code in the CORBA Component Model, EUROMICRO 2002, Dortmund, Germany (2002)
Diaconescu, A. & Murphy, J., Automating the Performance Management of Component-based Enterprise Systems through the Use of Redundancy, Proceedings of the 20th IEEE/ACM international Conference on Automated Software Engineering (Long Beach, CA, USA, November 07 - 11, 2005).
Gurdip Singh & Sanghamitra Das, Customizing Event Ordering Middleware for Component-Based Systems, pp. 359-362, Eighth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC'05), 2005.
Web Services Gao, L et al, 2003, Application specific Data Replication for Edge Services, In Proceedings of the 12th International Conference on World Wide Web (Budapest, Hungary, May 20 - 24, 2003). WWW '03. ACM Press, New York, NY, 449-460.
Mukhi, N. K., 2004, Cooperative Middleware Specialization for Service Oriented Architectures, Proceedings of the 13th International World Wide Web Conference on Alternate Track Papers & Posters (New York, NY, USA, May 19 - 21, 2004).
35
Related Research: What’s missing?• Lack of high-level notation to
guide optimization frameworks
• Missing AST of application
N N N N
N
N
N
N
NN
Application Abstract Syntax Tree
36
Related Research: What’s missing?• Lack of high-level notation to
guide optimization frameworks
• Missing AST of application
• Emphasis on detection at run-time (reflection)
• Additional overhead in the fast path
• Not suitable for all systems
• Not completely application transparent
• Requires providing multiple implementations
• Optimization performed either
• Too early, or too late
Control Center SystemResource
Manager
ScaleQosket
CropQosket
Compress Qosket
LocalResourceManager
Cropping QoSPredictorScaling QoS
Predictor
Compression QoSPredictor
Image Feeds (.NET Web
Service)
37
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
Node Application
Container
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CHCH
CH
Receptacle
Facet
Event Sink
Event SourceComponent Home
Component Assembly
Component Remote Invocation
Collocated Invocation
Creates
1. Overhead of platform mappings
• Blind adherence to platform semantics
• Inefficient middleware glue code generation per component
• Example:
• Creation of a factory object per component
• Servant glue-code generation for every component
Need optimization techniques to build large-scale component systems!
Application Specific Optimizations: Unresolved Challenges
Solution Approach: Component Assembly Optimizer
38
PICMLmodel
CH CH
CHCH
OS KERNEL
OS I/O Subsystem
Network Interfaces
MIDDLEWARE
Component Assembly Optimizer
Deployment Plan
Configuration Files
CH
Required Interface
Provided Interface
Event Sink
Event SourceComponent Home
Component Assembly
Component Invocation
Creates
CH
CH
CH
CH
CH
CH
CH
CH
CH CH
CHCH
• Component Assembly Optimizer
• Uses the application model as the input
• Exploits knowledge about platform semantics to rewrite the input model to a functionally equivalent output model
• Generates middleware glue-code
• Generates deployment configuration files
• Operates just before deployment
• Can be viewed as a “deployment compiler”
Component Assembly Optimizer Inputs• Set of 3 input graphs
• G1: (V1, E1) where V1 is the set of components in the application & E1 is the set of connections between them
• G2: (V2, E2), where V2 is the union of vertices in V1 with the set of QoS configuration options on components & E2 is the set of associations between the components and the QoS options
• G3: (V3, E3), where V3 is the union of vertices in V1 with the set of nodes in the target deployment domain of the application & E3 is the set of associations between the components and the nodes of the domain
39
Component Assembly Optimizer Output
40
• Produces an output graph
• Go: (Vo, Eo), where Vo is the set of composites (physical assemblies) created on a single node, & Eo is the set of connections between the composites
• Creation of physical assemblies subject to a number of constraints
• Average case
• |Vo| < |V1|
• Worst case
• |Vo| = |V1|, i.e., the optimizer couldn’t create any physical assemblies
• Equivalent to deployment of original application
Physical Assembly
41
• Physical Assembly
• Created from the set of components that are deployed within a single process of a target node
• Subject to various constraints
• Example constraints include
• No two ports of the set of components should have the same name
• No two components should have incompatible RT-CORBA policies
• No change to individual component implementations
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
Physical Assembly Generation
42
• Given set of components deployed on a single process of a target node
• Compute pair-wise intersections of component port name sets
• If intersection is null, merge the two components into a physical assembly
• Supported interfaces of constituent components are supported by physical assembly
• Additional RT-CCM constraint
• If intersection is null & RT-CORBA policies of the components are compatible
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
Middleware Concepts Exploited by Physical Assemblies
43
• Opacity of object references
• Components don’t rely on specific details of object references, e.g., location of type information
• Allows replacing references transparent to component implementations
Middleware Concepts Exploited by Physical Assemblies
44
• Opacity of object references
• Components don’t rely on specific details of object references, e.g., location of type information
• Allows replacing references transparent to component implementations
• Presence of a component context
• Components access ports of other components using a context object
• Allows replacing context transparent to component implementations
Container
Servant
ComponentSpecificContext
CCMContext
MainComponent
Executor
ExecutorsExecutorsExecutors
POA
EnterpriseComponent
CCMContext
Container
Servant
ComponentSpecificContext
CCMContext
MainComponent
Executor
ExecutorsExecutorsExecutors
POA
EnterpriseComponent
CCMContext
user implemented
code
Container
CORBAComponen
t
POA
Ext
erna
lI n
t erf
ac e
s
InternalInterface
s
Middleware Concepts Exploited by Physical Assemblies
45
• Opacity of object references
• Components don’t rely on specific details of object references, e.g., location of type information
• Allows replacing references transparent to component implementations
• Presence of a component context
• Components access ports of other components using a context object
• Allows replacing context transparent to component implementations
• Clean separation between glue-code & component implementation
• Allows modifications transparent to component implementations
Technique can be applied to other middleware with these properties
Stub
Executors
Skel
IDL Compiler
IDL
CIDL
CIDL Compiler
Executor IDL
Servants
ExecutorStubs
IDL Compiler
XMLComponentDescriptors
46
Physical Assembly Evaluation Criteria • Footprint of physical assembly
components
• Compared to vanilla Component-Integrated ACE ORB (CIAO)
• Different scenarios
• Simple scenarios (<= 10 components)
• ARMS GateTest scenarios (150+ components)
• Reduce static & dynamic footprint
• Reduce no. of homes by (n – 1) / n
• Reduce no. of objects registered with POA by (n – 1) / n
• Reduce no. of context objects created by (n – 1) / n
n = no. of components deployed in a single process
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
Assembly Optimizer
Factory
CHCH
CH
CH
CH
CH CHCH
Evaluating Physical Assemblies
• Boeing’s BoldStroke Basic Single Processor Scenario• Consists of 4 components
• Timer – Periodically sends refresh signal to the GPS• GPS – Calculates new co-ordinates of the aircraft in response
to Timer signal• Airframe – Processes new location inputs from GPS• Display – Updates the new location of the aircraft in the
navigation display47
Applying Physical Assemblies to BasicSP Scenario
• Assumption: GPS, Airframe and Display components are deployed on a single processor board
• Applying physical assemblies • Combines GPS, Airframe and Display components into a
single physical assembly (BasicSPAsm)• Maintains the same number of connections• Timer component not combined (due to clash in port names)
48
Experimental Results: BasicSP Scenario• Testbed
• Linux 2.6.20 FC6
• Dual 2.4Mhz processor
• 1.5GB RAM
• Evaluation for larger applications (~150 components) is in progress
49Physical assembly mapping reduces the footprint significantly
Static footprint reduction of ~45%
Dynamic footprint reduction of ~10%
50
Application Specific Optimizations: Unresolved Challenges2.Lack of application context
• Optimization decisions relegated to run-time
• e.g., every invocation performs check for locality
• Settle for near-optimal solutions
• Missed middleware optimization opportunities
51
Application Specific Optimizations: Unresolved Challenges2.Lack of application context
• Optimization decisions relegated to run-time
• e.g., every invocation performs check for locality
• Settle for near-optimal solutions
• Missed middleware optimization opportunities
• e.g., allocation of RT-CORBA thread pools and lanes
• Large overhead compared to collocated calls
Cannot be solved efficiently at middleware level alone!
Invocation within the same pool/lane (12µs)
Invocation to a different pool/lane (150µs)
Solution Approach: Use Application Context from Models• Use application structure &
context available in models• Create fast path within
middleware for physical assemblies
• Cross-pool/lane proxy• Create platform mappings to use
fast path• E.g., Use matching real-time
policies as additional constraint when creating physical assemblies
• Configure middleware resources efficiently
• E.g., place physical assemblies with matching policies in the same thread pool or thread pool with lanes
52
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
Assembly Optimizer
Factory
CHCH
CH
CH
CH
CH CHCH
53
Context-driven Optimization Evaluation Criteria • Improve performance
• t = no. of cross-pool/lane interactions between components within an assembly
• Transform t remote calls to t cross-pool/lane calls
• Eliminate mis-optimizations• Check incompatible POA
policies• Incompatible invocation
semantics (oneway or twoway)
• No changes to individual component implementations• Eliminate need for a local
vs. remote version
• Customizable & application transparent
Experimental Results: Cross pool/lane proxy
54
Standard deviation <= 3µs
Max latency improved by ~50%
99% latency improved by 60-66%
Average latency improved by 60 – 66%
Significant performance benefits with cross pool/lane proxy!
55
Presentation Road Map
• Technology Context• Overview of Research Challenges• Research Area 1: Component System
Integration • Research Area 2: Application-Specific
Optimizations• Summary of Research Contributions• Concluding Remarks
56
Summary of Research ContributionsTopic Benefits
System Composition Technologies
Support static composition of systems by ensuring that the components get built correctly
Support dynamic composition of systems by ensuring that the connections between components are correct
Address composition scalability concerns by employing model-weaving technologies
Generation Technologies
Expressing domain constraints in the form of a platform-independent MDE tool
Manage & automate the generation of syntactically valid metadata in various required declarative notations
System Integration Technologies
Novel approach to system integration based on model composition
Supports functional integration of heterogeneous middleware
Generation of integration glue-code directly from models
System Optimization Technologies
Automatic discovery & realization of optimizations from models using application context; such optimizations are impossible to perform if operating at the middleware layer alone.
A novel mechanism for mapping an assembly as a component to both reduce application footprint and increase performance
57
Summary of PublicationsCategory Publications
System Composition Technologies
1. Towards Composable Distributed Real-time & Embedded Software, Proceedings of the 8th IEEE Workshop on Object-oriented Real-time Dependable Systems (WORDS), Guadalajara, Mexico, January 2003.
2. Applying Model-Driven Development to Distributed Real-time & Embedded Avionics Systems, the International Journal of Embedded Systems, special issue on Design & Verification of Real-Time Embedded Software, April 2005.
3. A Platform-Independent Component Modeling Language for Distributed Real-time & Embedded Systems, Elsevier J. of Computer & System Sciences, 2006.
4. Weaving Deployment Aspects into Domain-Specific Models, International J. on Software Engineering & Knowledge Engineering, Summer 2006 (Accepted).
Generation Technologies
1. A Platform-Independent Component Modeling Language for Distributed Real-time & Embedded Systems, 11th IEEE Real-Time & Embedded Technology & Applications Symposium, San Francisco, CA, March 2005.
2. Developing Applications Using Model-Driven Design Environments, Computer, vol. 39, no. 2, pp. 33-40, Feb., 2006.
3. Model-driven Development of Component-based Distributed Real-time & Embedded Systems, Model Driven Engineering for Distributed Real-time & Embedded Systems, Hermes, 2005.
4. Model Driven Middleware: A New Paradigm for Deploying & Provisioning Distributed Real-time & Embedded Applications, Elsevier J. of Science of Computer Programming: Special Issue on Model Driven Architecture, 2006.
System Integration Technologies
1. Component-based System Integration via (Meta)Model Composition, 14th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS), Tucson, AZ, March 2007
2. System Integration via Model Composition, Designing Software-Intensive Systems: Methods and Principles, Edited by Dr. Pierre F. Tiako, Langston University, OK. (Submitted)
First Author Second Author
58
Concluding Remarks
• Component middleware is an emerging paradigm
• Problems with component middleware
• Significant gaps in the development & integration toolchain
• Potential to negate benefits of using component middleware
• Direct application to DRE systems not possible
• Might not meet the stringent QoS requirements of DRE systems
• My research
• Resulted in improved tool-support for component middleware
• Model-Driven Engineering toolchain
• Performs optimizations on component middleware that were previously infeasible
• Exploit application context made available by MDE tool-chain
• Successful transition to DD(X) program for TSCEI deployment & configuration services
Tools can be downloaded from www.dre.vanderbilt.edu/CoSMIC/
Questions?
59
60
Presentation Road Map
• Motivation• Technology Context• Overview of Research Challenges• Research Area 1: Component System
Integration • Research Area 2: Application-Specific
Optimizations• Summary of Research Contributions• Concluding Remarks
61
Where We Started: Object-Oriented Programming
• Object-oriented (OO) programming simplified software development through higher level abstractions & patterns, e.g.,
Well-written OO programs exhibit recurring structures that promote abstraction, flexibility, modularity, & elegance
• Decoupling interfaces & implementations
• Associating related data & operations
operation1()operation2()operation3()operationn()
data
class X
62
Distributed Object Computing (DOC) Middleware
• Applies the Broker pattern to abstract away lower-level OS & protocol-specific details for network programming
• Creates distributed systems that are easier to model & build using OO techniques
• Result: robust distributed systems built with distributed object computing (DOC) middleware
• e.g., CORBA, Java RMI, etc.
1 1Proxy
service
Service
service
AbstractService
service
Client
We now have more robust software & more powerful distributed systems
operation()Object :
Interface X: Client
Middleware
63
Traditional DOC Middleware Limitations• Unable to provide multiple, alternate
views per client
Component
Client C
Client A
64
Traditional DOC Middleware Limitations• Unable to provide multiple, alternate
views per client
• Unable to navigate between interfaces in a standardized fashion
Component
Client C
Client A
65
Traditional DOC Middleware Limitations• Unable to provide multiple,
alternate views per client
• Unable to navigate between interfaces in a standardized fashion
• Specification & enforcement of policy
• Done via low-level mechanisms, i.e., by writing code // Get the correct bands from the <server_declared_obj>.
policies[0] = server_declared_obj->_get_policy (RTCORBA::PRIORITY_BANDED_CONNECTION_POLICY_TYPE); RTCORBA::PriorityBandedConnectionPolicy_var
bands_policy = RTCORBA::PriorityBandedConnectionPolicy ::_narrow (policies[0]); RTCORBA::PriorityBands_var bands = bands_policy->priority_bands ();
// Set the proper bands at the object level. Note that a new // object is returned. object = client_propagated_obj->_set_policy_overrides(policies,
CORBA::SET_OVERRIDE);
66
Traditional DOC Middleware Limitations• Unable to provide multiple, alternate
views per client
• Unable to navigate between interfaces in a standardized fashion
• Specification & enforcement of policy
• Done via low-level mechanisms, i.e., by writing code
• Accidental complexities
• Middleware configuration is complex, tedious & error-prone
• Ad hoc deployment mechanisms
• Tedious, error-prone
• Not reusable
Significant challenges for system developers!
QoSProperties
Checksum
Version Dependencies
List of FilesQoS Specs ComponentInterconnections
ImplementationDLL DLL
QoSProperties
Checksum
Version Dependencies
ImplementationDLL DLL
67
Traditional DOC Middleware Limitations• Unable to provide multiple, alternate
views per client
• Unable to navigate between interfaces in a standardized fashion
• Extensibility restricted to language (Java, C++) and/or platform (CORBA) C++ Component
Java Component C++ Component C# Component
68
Interface Design
Component Design
Component Implementation
Component Packaging
ApplicationAssembly
SystemDeployment
Interface IDL Definitions
Stubs&
Skeletons
Object Implementations
RunningApplications
Component IDL
Definitions
IDL Compiler
CIDL Compiler
Component CIDL
Definitions
Servants,Executors,Contexts
Language Tools
Component DLLs
Component & Home Properties
Component Interface
Descriptors (.ccd)
Packaging Tools
Component & Home Properties
Component Implementation
Descriptors (.cid)
DeploymentTools
Implementation Artifact
Descriptors (.iad)
Deployment Plan
Descriptor (.cdp)
AssemblyTools
Component Implementation
Descriptor(*.cid)
Component Package
Descriptors (.cpd)
MonolithicComponentDescription
Component Package
Descriptors (.cpd)
Component Assembly
Descriptors
realizes
realizes
uses
DeploymentPlanning
DeploymentPlanning
Tools
ComponentDomain
Descriptor(.cdd)
Component & Home Properties
realizes
Component System Development Lifecycle
Specification of supported interfaces
69
Interface Design
Component Design
Component Implementation
Component Packaging
ApplicationAssembly
SystemDeployment
Interface IDL Definitions
Stubs&
Skeletons
Object Implementations
RunningApplications
Component IDL
Definitions
IDL Compiler
CIDL Compiler
Component CIDL
Definitions
Servants,Executors,Contexts
Language Tools
Component DLLs
Component & Home Properties
Component Interface
Descriptors (.ccd)
Packaging Tools
Component & Home Properties
Component Implementation
Descriptors (.cid)
DeploymentTools
Implementation Artifact
Descriptors (.iad)
Deployment Plan
Descriptor (.cdp)
AssemblyTools
Component Implementation
Descriptor(*.cid)
Component Package
Descriptors (.cpd)
MonolithicComponentDescription
Component Package
Descriptors (.cpd)
Component Assembly
Descriptors
realizes
realizes
uses
DeploymentPlanning
DeploymentPlanning
Tools
ComponentDomain
Descriptor(.cdd)
Component & Home Properties
realizes
Component System Development Lifecycle
Specification of component types, e.g.,
provided & required interfaces
70
Interface Design
Component Design
Component Implementation
Component Packaging
ApplicationAssembly
SystemDeployment
Interface IDL Definitions
Stubs&
Skeletons
Object Implementations
RunningApplications
Component IDL
Definitions
IDL Compiler
CIDL Compiler
Component CIDL
Definitions
Servants,Executors,Contexts
Language Tools
Component DLLs
Component & Home Properties
Component Interface
Descriptors (.ccd)
Packaging Tools
Component & Home Properties
Component Implementation
Descriptors (.cid)
DeploymentTools
Implementation Artifact
Descriptors (.iad)
Deployment Plan
Descriptor (.cdp)
AssemblyTools
Component Implementation
Descriptor(*.cid)
Component Package
Descriptors (.cpd)
MonolithicComponentDescription
Component Package
Descriptors (.cpd)
Component Assembly
Descriptors
realizes
realizes
uses
DeploymentPlanning
DeploymentPlanning
Tools
ComponentDomain
Descriptor(.cdd)
Component & Home Properties
realizes
Component System Development Lifecycle
Component Implementation
71
Interface Design
Component Design
Component Implementation
Component Packaging
ApplicationAssembly
SystemDeployment
Interface IDL Definitions
Stubs&
Skeletons
Object Implementations
RunningApplications
Component IDL
Definitions
IDL Compiler
CIDL Compiler
Component CIDL
Definitions
Servants,Executors,Contexts
Language Tools
Component DLLs
Component & Home Properties
Component Interface
Descriptors (.ccd)
Packaging Tools
Component & Home Properties
Component Implementation
Descriptors (.cid)
DeploymentTools
Implementation Artifact
Descriptors (.iad)
Deployment Plan
Descriptor (.cdp)
AssemblyTools
Component Implementation
Descriptor(*.cid)
Component Package
Descriptors (.cpd)
MonolithicComponentDescription
Component Package
Descriptors (.cpd)
Component Assembly
Descriptors
realizes
realizes
uses
DeploymentPlanning
DeploymentPlanning
Tools
ComponentDomain
Descriptor(.cdd)
Component & Home Properties
realizes
Component System Development Lifecycle
Grouping of component implementation artifacts
& metadata into component packages
72
Interface Design
Component Design
Component Implementation
Component Packaging
ApplicationAssembly
SystemDeployment
Interface IDL Definitions
Stubs&
Skeletons
Object Implementations
RunningApplications
Component IDL
Definitions
IDL Compiler
CIDL Compiler
Component CIDL
Definitions
Servants,Executors,Contexts
Language Tools
Component DLLs
Component & Home Properties
Component Interface
Descriptors (.ccd)
Packaging Tools
Component & Home Properties
Component Implementation
Descriptors (.cid)
DeploymentTools
Implementation Artifact
Descriptors (.iad)
Deployment Plan
Descriptor (.cdp)
AssemblyTools
Component Implementation
Descriptor(*.cid)
Component Package
Descriptors (.cpd)
MonolithicComponentDescription
Component Package
Descriptors (.cpd)
Component Assembly
Descriptors
realizes
realizes
uses
DeploymentPlanning
DeploymentPlanning
Tools
ComponentDomain
Descriptor(.cdd)
Component & Home Properties
realizes
Component System Development Lifecycle
Specification of component interconnections &
composition of component assembly packages
73
Interface Design
Component Design
Component Implementation
Component Packaging
ApplicationAssembly
SystemDeployment
Interface IDL Definitions
Stubs&
Skeletons
Object Implementations
RunningApplications
Component IDL
Definitions
IDL Compiler
CIDL Compiler
Component CIDL
Definitions
Servants,Executors,Contexts
Language Tools
Component DLLs
Component & Home Properties
Component Interface
Descriptors (.ccd)
Packaging Tools
Component & Home Properties
Component Implementation
Descriptors (.cid)
DeploymentTools
Implementation Artifact
Descriptors (.iad)
Deployment Plan
Descriptor (.cdp)
AssemblyTools
Component Implementation
Descriptor(*.cid)
Component Package
Descriptors (.cpd)
MonolithicComponentDescription
Component Package
Descriptors (.cpd)
Component Assembly
Descriptors
realizes
realizes
uses
DeploymentPlanning
DeploymentPlanning
Tools
ComponentDomain
Descriptor(.cdd)
Component & Home Properties
realizes
Component System Development Lifecycle
Specification of deployment target domain & configuration
of component assembly
74
Interface Design
Component Design
Component Implementation
Component Packaging
ApplicationAssembly
SystemDeployment
Interface IDL Definitions
Stubs&
Skeletons
Object Implementations
RunningApplications
Component IDL
Definitions
IDL Compiler
CIDL Compiler
Component CIDL
Definitions
Servants,Executors,Contexts
Language Tools
Component DLLs
Component & Home Properties
Component Interface
Descriptors (.ccd)
Packaging Tools
Component & Home Properties
Component Implementation
Descriptors (.cid)
DeploymentTools
Implementation Artifact
Descriptors (.iad)
Deployment Plan
Descriptor (.cdp)
AssemblyTools
Component Implementation
Descriptor(*.cid)
Component Package
Descriptors (.cpd)
MonolithicComponentDescription
Component Package
Descriptors (.cpd)
Component Assembly
Descriptors
realizes
realizes
uses
DeploymentPlanning
DeploymentPlanning
Tools
ComponentDomain
Descriptor(.cdd)
Component & Home Properties
realizes
Component System Development Lifecycle
Deploy component assembly packages onto target nodes
according to a deployment plan
75
Control Center SystemResource
Manager
ScaleQosket
CropQosket
Compress Qosket
LocalResourceManager
Cropping QoSPredictorScaling QoS
Predictor
Compression QoSPredictor
Image Feeds (.NET Web
Service)
• System Resource Manager
• Global QoS manager• Control Center
• User interaction• .NET Web Services
• Image Stream(s)• Local Resource
Manager• Local QoS
manager• Qoskets
• QoS enforcer• QoS predictors
• QoS estimators• Built using the
Component-Integrated ACE ORB (CIAO)
Example Scenario: Emergency Response System
Developed for DARPA PCES program (dist-systems.bbn.com/papers/)
76
Presentation Road Map
• Motivation• Technology Context• Overview of Research Challenges• Research Area 1: Composition of Component
Systems• Research Area 2: Expression of Design Intent• Research Area 3: Component System
Integration • Research Area 4: Application-Specific
Optimizations• Summary of Research Contributions• Concluding Remarks
77
• Component middleware allows composition across multiple dimensions
• Temporal – Static vs. dynamic
Research Area 1: Composition of Component Systems
Static Dynamic
Time
Hierarchical
Flat
Str
uct
ura
lComponent Assembly
Component Component
Component ComponentComponent Component
Component Component
Deployment Time
Build Time
Component Assembly
78
• Component middleware allows composition across multiple dimensions
• Temporal – Static vs. dynamic• Structural – Flat vs. hierarchical
• Systems are no longer built from scratch
• Composed from COTS components & frameworks using design patterns
Research Area 1: Composition of Component Systems
Static Dynamic
Time
Hierarchical
Flat
Str
uct
ura
lComponent Assembly
Component Component
Component ComponentComponent Component
Component Component
Deployment Time
Build Time
Component Assembly
79
Related ResearchCategory Related Research
Component Environments
G. Karsai et al, A Modeling Language & Its Supporting Tools for Avionics Systems, In Proceedings of 21st Digital Avionics Systems Conf., Aug. 2002.
Lüer, C. & Rosenblum, D. S. 2001, WREN---an environment for component-based development, SIGSOFT Soft. Eng. Notes 26, 5 (Sep. 2001), 207-217.
Jack Greenfield et al, Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, Wiley, 2004
Programming Models
G. T. Heineman & W. T. Councill, editors, Component-Based Software Engineering: Putting the Pieces Together, Addison-Wesley, 2001.
Czarnecki, K. & Eisenecker, U. W. Generative Programming: Methods, Tools, & Applications, ACM Press/Addison-Wesley Publishing Co., 2000
Batory, D. et al, Scaling step-wise refinement, in Proceedings of the 25th International Conference on Software Engineering (Portland, Oregon, May 03 - 10, 2003).
Functional Verification
J. Hatcliff et. al., Cadena: An Integrated Development, Analysis, & Verification Environment for Component-based Systems, in Proceedings of the 25th International Conference on Software Engineering, (Portland, OR), May 2003.
J. A. Stankovic et al, VEST: An Aspect-based Composition Tool for Real-time Systems, in Proceedings of the IEEE Real-time Applications Symposium, (Washington,DC), IEEE, May 2003.
80
Related Research: What’s Missing?• Tool-specific component
technologies• As opposed to component-
technology agnostic tools!• Emphasis on component
programming models /languages• How to write better
components?• Lack of deployment-time tool
support• No support for deployment
artifacts!• Lack of tool support for system
level development
It’s not just the functionality, it’s the packaging!
Component
ResourceRequirements
Impl Impl Impl
Properties
Component Assembly
ComponentComponent
ComponentComponent
81
1.Lack of tool support for defining consistent component interactions• Primitive interface definition
tools: EditCompileRun Fix cycle
component SystemResourceManager {attribute double available_cpu;
attribute double available_bw; attribute double needed_cpu; attribute double needed_bw; attribute UAV_List uavs_from_lrm; uses multiple LRMInterface my_lrms;provides SRMInterface srm_interface;
publishes ResourceAllocationEvt resourceEvt; publishes PolicyChangeEvt policy_evt; };
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
System Composition: Unresolved Challenges
82
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
1.Lack of tool support for defining consistent component interactions• Primitive interface definition
tools: EditCompileRun Fix cycle
• No inter-connection information
2.Lack of integrated system view• Design view, e.g., UML models• Development view, e.g., Visual
Studio
component MultiReceiver
: ImageProcessingQosket
{
consumes ResourceAllocationEvt
resourceEvt;
consumes PolicyChangeEvt
policyEevt;
};
Integrated view of the system is essential!
System Composition: Unresolved Challenges
83
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
3.Lack of tool support for multi-level composition
• Change propagation done in an ad-hoc fashion
• Redundant & error-prone
• Violates “Don’t Repeat Yourself” (DRY) principle
• Need support for different composition granularities
4.Lack of context-aware policy specification mechanisms
• No one size fits all!
5.Lack of scalable techniques for composition
• Manual techniques don’t scale well
Lack of tool support negates benefits of components!
System Composition: Unresolved ChallengesPolicy A
Policy A’
84
Solution Approach: DSML Infrastructure• Platform-Independent
Component Modeling Language (PICML)• Developed using GME• Core of Component
Synthesis using Model-Integrated Computing (CoSMIC) toolchain
• Capture elements & dependencies visually
85
Solution Approach: DSML Infrastructure• Platform-Independent
Component Modeling Language (PICML)• Developed using GME• Core of Component
Synthesis using Model-Integrated Computing (CoSMIC) toolchain
• Capture elements & dependencies visually
• Define “static semantics” using Object Constraint Language (OCL)
86
Solution Approach: DSML Infrastructure• Platform-Independent
Component Modeling Language (PICML)• Developed using GME• Core of Component
Synthesis using Model-Integrated Computing (CoSMIC) toolchain
• Capture elements & dependencies visually
• Define “static semantics” using Object Constraint Language (OCL)
• Define “dynamic semantics” via model interpreters
• Employ generative technologies
Component Developer
IDL Files
Domain Expert
Define domain elemets
Import/Export IDL
Define interfaces
Associate components with domain elements
PICML
Model Application
Application Model
Application Developer
Refine application during life-time
Target Domain Model
Model interfaces
Deployment Descriptors
87
Solution Approach: System Composition Tools• Disallow inconsistent
component interactions
• Provide integrated view of system
• Support system composition across multiple levels
• Support context-dependent policy specifications
• Support scalable composition techniques
• Support integration with component build tools & component repositories
Pol
ResIma
Stream1
Pol
ResIma
Stream2
Pol
ResIma
Stream3
Pol
ResIma
Stream4
pol
res
inc
out
MultiReceiver[ MultiReceiver ]
blupol
res
SystemResourceManager[ SystemResourceManager ]
c3
c1
c2
c4
c5
c6
publish
deliverTo
deliverTo
deliverTo
deliverTo
publish
deliverTo
deliverTo
deliverTo
deliverTo
publish
deliverTodeliverTo
deliverTo
publish
deliverTo
deliverTo
deliverTo
publish
publish
qos
ScaleQosPredictor[ ScaleQosPredictor ]
imainccur
out
CompressQosket[ CompressQosket ]
imainccur
out
DiffServQosket[ Dif fServQosket ]
cpu
CPUBrokerComponent[ CPUBrokerComponent ]
imainccur
out
ScaleQosket[ ScaleQosket ]
qos
CroppingQosPredictor[ CroppingQosPredictor ]
inc out
LocalReceiver[ LocalReceiver ]
PolicyChangeEvt
ResourceAllocationEvt
ImageGenerationEvt
qos
CompressionQosPredictor[ CompressionQosPredictor ]
imasen
out
Sender[ Sender ]
polresinccomscacrodifcpu
imaoutcrosca
com
LocalResourceManagerComponent[ LocalResourceManagerComponent ]
imainccur
out
CropQosket[ CropQosket ]
invoke
emit
emit
delegatesTo
delegatesTo
emit
delegatesTo
invoke
invoke
invoke
invoke
emit
invoke
emit
invokeinvoke
Policy A
Policy A’
88
Challenges 1 & 2 Resolved: Visual Interaction Definition
ima
inc
cur
out
CropQosket[ CropQosket ]
qos
CroppingQosPredictor[ CroppingQosPredictor ]
pol
res
inc
com
sca
cro
ima
out
cro
sca
com
dif
cpu
LocalResourceManagerComponent[ LocalResourceManagerComponent ]
ima
inc
cur
out
CompressQosket[ CompressQosket ]
ima
senout
Sender[ Sender ]
qos
CompressionQosPredictor[ CompressionQosPredictor ]
qos
ScaleQosPredictor[ ScaleQosPredictor ]
ima
inc
cur
out
ScaleQosket[ ScaleQosket ]
cpu
CPUBrokerComponent[ CPUBrokerComponent ]
inc out
LocalReceiver[ LocalReceiver ]
PolicyChangeEvt
ResourceAllocationEvt
ImageGenerationEvt
ima
inc
cur
out
DiffServQosket[ Dif fServQosket ]
delegatesTo
delegatesTo
emit
invoke
invoke
invokeinvoke
invoke
emit emit emit
invoke
invokeinvoke
emit
delegatesTo
1.Syntactically compatible component interaction definition• Enforce platform semantics using OCL
constraints
Disallow inconsistent component interactions
89
Challenges 1 & 2 Resolved: Visual Interaction Definition
ima
inc
cur
out
CropQosket[ CropQosket ]
qos
CroppingQosPredictor[ CroppingQosPredictor ]
pol
res
inc
com
sca
cro
ima
out
cro
sca
com
dif
cpu
LocalResourceManagerComponent[ LocalResourceManagerComponent ]
ima
inc
cur
out
CompressQosket[ CompressQosket ]
ima
senout
Sender[ Sender ]
qos
CompressionQosPredictor[ CompressionQosPredictor ]
qos
ScaleQosPredictor[ ScaleQosPredictor ]
ima
inc
cur
out
ScaleQosket[ ScaleQosket ]
cpu
CPUBrokerComponent[ CPUBrokerComponent ]
inc out
LocalReceiver[ LocalReceiver ]
PolicyChangeEvt
ResourceAllocationEvt
ImageGenerationEvt
ima
inc
cur
out
DiffServQosket[ Dif fServQosket ]
delegatesTo
delegatesTo
emit
invoke
invoke
invokeinvoke
invoke
emit emit emit
invoke
invokeinvoke
emit
delegatesTo
1.Syntactically compatible component interaction definition• Enforce platform semantics using OCL
constraints2.High-level integrated view of system
• In addition to multiple task-specific views of the same system
K Balasubramanian et al, “Applying Model-Driven Development to Distributed Real-time & Embedded Avionics Systems,” the International Journal of Embedded Systems,
special issue on Design & Verification of Real-Time Embedded Software, April 2005
Provide integrated view of system
90
Challenges 3 & 4 Resolved: Hierarchical Composition3.Allow composition across multiple levels
• Components, assemblies of components & assemblies of assemblies
• Propagate changes automatically• Define assemblies as types• Instantiate multiple times
Support system composition across multiple levels
91
Challenges 3 & 4 Resolved: Hierarchical Composition3.Allow composition across multiple levels
• Components, assemblies of components & assemblies of assemblies
• Propagate changes automatically• Define assemblies as types• Instantiate multiple times
4.Policy/Configuration can be specified
• At component level• Overridden at assembly
level(s)
K Balasubramanian et al, “A Platform-Independent Component Modeling Language for Dist-ributed Real-time & Embedded Systems,” Journal of Computer & System Sciences, 2006
Support context-dependent policy specifications
92
Challenge 5 Resolved: Scalable System Composition 5.Integrate support for scalable
composition techniques
• Aspect-Oriented Modeling
• Addresses scalability of modeling effort
• C-SAW tool
• Developed by SOFTCOM (UAB)
• C-SAW with PICML
• Provides template configurations (using ECL) that are weaved into a model
• User can customize the templates depending on application requirements
K. Balasubramanian et al, “Weaving Deployment Aspects into Domain-Specific Models,” the International Journal on Software Engineering & Knowledge Engineering, 2006 (Accepted)
Support scalable composition techniques
93
Research Contributions
Category Benefits Publications
System Composition Technologies
• Support static composition of systems by ensuring that the components get built correctly
• Support dynamic composition of systems by ensuring that the connections between components are correct
• Provide integrated view of system
• Address composition scalability concerns by employing model-weaving technologies
1. IEEE Workshop on Object-oriented Real-time Dependable Systems (WORDS), 2003.
2. International Journal of Embedded Systems, Special issue on Design & Verification of Real-Time Embedded Software, 2005.
3. Elsevier Journal of Computer & System Sciences, 2006.
4. International Journal on Software Engineering & Knowledge Engineering, 2006. (Accepted)
94
Presentation Road Map
• Motivation• Technology Context• Overview of Research Challenges• Research Area 1: Composition of Component
Systems• Research Area 2: Expression of Design Intent• Research Area 3: Component System
Integration • Research Area 4: Application-Specific
Optimizations• Summary of Research Contributions• Concluding Remarks
95
Research Area 2: Expression of Design Intent• Traditional middleware had a
significant gap between design intent & its expression using 3rd generation languages
• Component middleware helps bridge this gap by replacing imperative techniques with declarative techniques
• Examples:
• Describing connection between components
• Describing constituents of component packages
• Configuration of components
• Configuration of middleware infrastructure
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
OS KERNEL
OS I/O Subsystem
Network Interfaces
OS KERNEL
OS I/O Subsystem
Network Interfaces
MIDDLEWARE
ComponentComponent
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
XML
XMLXML
XML
96
Related ResearchCategory Related Research
Operating System
John DeTreville, Making System Configuration More Declarative, Proceedings of the 10th Work. on Hot Topics in Operating Systems, June 2005, USENIX.
Bryan Cantrill et al, Dynamic Instrumentation of Production Systems, USENIX Annual Technical Conference, 2004
Lionel Cons & Piotr Poznanski, Pan: A High-Level Configuration Language, LISA, Proceedings of the 16th Conference on Systems Administration (LISA 2002), 2002, pp.83-98
Software Description
R. Chinnici et al, Web Services Description Language (WSDL) 2.0 part 1: Core language, August 2004, http://www.w3.org/TR/2004/WD-wsdl20-20040803.
Dashofy, E. M. et al, An infrastructure for the rapid development of XML-based architecture description languages, Proceedings of the 24th international Conference on Software Engineering (Orlando, Florida, May 19 - 25, 2002)
Middleware Packaging
Richter, J., Applied Microsoft .NET Framework Programming, Microsoft Press, 2002.
Sun Microsystems, Enterprise Java Beans Specification, Version 2.1, 2002
Middleware Communication
M Rose, The Blocks Extensible Exchange Protocol Core (BEEP), RFC 3080, March 2001
Don Box et al, Simple Object Access Protocol (SOAP) 1.1, http://www.w3.org/TR/2000/NOTE-SOAP-20000508
97
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
</instance>...<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
</internalEndpoint>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
Related Research: What’s Missing?• Declarative techniques use
tool-friendly technologies to express design intent
• Example: XML
• XML is non-intuitive
• Error-prone to write manually
• Changes to system require changes to generated XML
• Redundant effort
• Problems with imperative techniques not solved
• Declarative techniques shifted the problem into a different space
• “Whack-a-mole” approach
Support for declarative notations of component middleware is critical!
Is id unique?
Does portName refer to a valid port?
Is idref a valid reference?
98
Expression of Design Intent: Unresolved Challenges
1.Complexity of Declarative Notations
• Example 1: CORBA Interface Definition Language (IDL)
• Differences between CORBA 2.x & CORBA 3.x (CCM)
• New keywords in the language
• Subtle differences in syntax & semantics of similar elements
–CORBA 2.x interfaces
–CORBA 3.x components
// CORBA 3.xcomponent ImageProvider {};component ImageViewer {};component LRM : ImageProvider, ImageViewer
{ // Operations on LRM
};
// CORBA 2.xinterface ImageProvider {};interface ImageViewer {};interface LRM : ImageProvider,
ImageViewer{ // Operations on LRM
};
Accidental complexities are present in every technology!
99
Expression of Design Intent: Unresolved Challenges• Example 2: .NET manifests
• Each assembly in .NET can be associated with manifests
• Policy specifications for assembly, user, domain
• Configuration of assembly• Manifest names are closely
associated with assembly names• Foo.dll Foo.dll.manifest• Foo.dll Foo.dll.config
• OS loader ignores configurations in files with other names
2.Lack of support for system evolution• Interfaces & metadata of
individual components needs to evolve with the system
Need flexible abstractions to express design intent!
Policy
`
Group
Application Assembly Manifest
User
Component
ResourceRequirements
Implementation
Properties
ImplementationImplementation
Component Assembly Configuration
Component Assembly Manifest
Application Assembly Configuration
100
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
Solution Approach: Model-Driven Generation• Provide high-level
abstractions for specification of design intent
• Automate generation of platform-specific metadata from these abstractions
• Provide support for system interface & metadata evolution
• Provide support for developing heterogeneous systems
101
Challenge 1 Resolved: Automate Generation of Metadata
1.High-level, user-friendly visual abstractions for declarative notations
• Define a type system that captures the platform semantics
• e.g., CCM, .NET
ModelInterpreters
Application Model
<connection> <name>compressionQosPredictor_qosLevels</name> <internalEndpoint> <portName>qosLevels</portName> <instance xmi:idref="CompressionQosPredictor"/> </internalEndpoint> <internalEndpoint> <portName>compressionQosPredictor</portName> <instance xmi:idref="LocalResourceManagerComponent"/> </internalEndpoint></connection>
Generated Descriptors
N N N N
N
N
N
N
NN
Application Model Abstract Syntax Tree
Provide high-level abstractions for specification of design intent
102
Challenge 1 Resolved: Automate Generation of Metadata
1.High-level, user-friendly visual abstractions for declarative notations
• Define a type system that captures the platform semantics
• e.g., CCM, .NET
ModelInterpreters
Application Model
<connection> <name>compressionQosPredictor_qosLevels</name> <internalEndpoint> <portName>qosLevels</portName> <instance xmi:idref="CompressionQosPredictor"/> </internalEndpoint> <internalEndpoint> <portName>compressionQosPredictor</portName> <instance xmi:idref="LocalResourceManagerComponent"/> </internalEndpoint></connection>
Generated Descriptors
N N N N
N
N
N
N
NN
Application Model Abstract Syntax Tree
• Build model interpreters
• Generate descriptors in required (potentially different) declarative notation(s) for multiple platforms
• Ensure generated artifacts are:
• Syntactically valid
K. Balasubramanian et al, “Developing Applications Using Model-Driven Design Environments,” Computer, vol. 39, no. 2, pp. 33-40, Feb., 2006
Automate generation of platform-specific metadata from these abstractions
103
Challenge 2 Resolved: System Interface Evolution
2.Provide support for system interface evolution
• (Re-)Import/(Re-)Export IDL• Provides migration for
legacy systems• Eliminate accidental
complexities• Define platform interface
semantics using MetaGME & OCL constraints• e.g., a receptacle should
be connected to a facet of the same type or a type derived from the receptacle
K. Balasubramanian et al, “A Platform-Independent Component Modeling Language for Distributed Real-time & Embedded Systems,” Proceedings of the 11th IEEE Real-Time &
Embedded Technology & Applications Symposium, San Francisco, CA, March 2005
Provide automated support system interface & metadata evolution
104
Research ContributionsCategory Benefits Publications
Generative System Technologies
• Expressing domain constraints in the form of a platform-independent MDE tool
• Manage & automate the generation of syntactically valid metadata in various (potentially different) required declarative notations
1. Model Driven Engineering for Distributed Real-time & Embedded Systems, edited by Sebastien Gerard, Joel Champea, & Jean-Philippe Babau, Hermes, 2005
2. IEEE Real-Time & Embedded Technology & Applications Symposium, 2005
3. Elsevier Journal of Science of Computer Programming: Special Issue on Model Driven Architecture, 2006
4. IEEE Computer, 2006
105
System Composition: Proposed Enhancements• Integrate with portable infrastructure
build tools like MakeProjectCreator• Exploit application context
information to take advantage of native platform build tool capabilities, e.g.:• Alter the visibility of symbols
• Elevate implementation artifact abstraction• Allows managing components in
terms of packages• Push metadata into Repository
Manager to allow execution of meta-queries, e.g.:• “Do you have a sensor with
latency specification < 6 µs?”• “Give me a database capable of
handling 2,000 transactions/sec”
Component
ResourceRequirements
Impl Impl Impl
Properties
Component Assembly
ComponentComponent
ComponentComponent
106
Proposed Enhancements: Evaluation Criteria• Baseline for comparison
• Deployment of a system with existing tools (vanilla CIAO & DAnCE)
• Eliminate the need to manually write build scripts
• Reduce static footprint per component type by 20%
• Simple changes already yield 10%
• Total savings accrue based on number of unique types per assembly
• Automate the creation of component packages
• Ability to automatically deploy a package into the Repository Manager
PICML
COMPONENT REPOSITORY
QoS Specs
Configurations
Dependencies
107
Expression of Design Intent: Proposed Enhancements
• Extend generative capabilities of PICML to .NET Web Services to generate:• Assembly manifests (.dll.manifest) –
Describes contents of a .NET component• Application manifests (.exe.manifest) –
Describes metadata associated with an application
• Application Configuration Files (app.config) – Describes application behavior configuration elements
• Web Service Configuration File (web.config) – Equivalent to app.config for external subsystems of a web Service
• Policy files ({enterprisesec, machine, security}.config) – Describes code access security policy elements
Policy
`
Group
Application Assembly Manifest
User
Component
ResourceRequirements
Implementation
Properties
ImplementationImplementation
Component Assembly Configuration
Component Assembly Manifest
Application Assembly Configuration
Support development of heterogeneous systems
108
Proposed Enhancements: Evaluation Criteria• Baseline for comparison
• Deployment of a system having both CCM components & .NET Web Services with existing tools (vanilla CIAO, Visual Studio)
• Automate three-staged deployment of typical .NET Web services • Syntactically valid manifests for
the 3 stages: Development, Testing, & Production
• Eliminate errors in deployment due to inconsistent policies
• Eliminate need for user to write glue code to integrate a CCM component with a .NET Web Service
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
109
Proposed Approach: Physical Assembly Mapping3.Devise mapping for physical
component assembly
• Exploit hierarchy of application structure to fuse (make a component internal) at multiple levels in hierarchy
• Experimentally validate right depth of hierarchy to stop fusion
• Too deep – Single giant blob
• Too shallow – Potentially lower benefits
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
110
Proposed Approach: Evaluation Criteria • Baseline for comparison
• Performance & footprint (with vanilla CIAO)
• Emergency Response System (30+ components)
• ARMS GateTest scenarios (1,800+ components)
• Scenario with & without inherent hierarchy
• Reduce static & dynamic footprint
• n = no. of internal components, x = total no. of components in the assembly
• Reduce no. of homes by (n-1)/x
• Reduce no. of objects registered with POA by (n-1)/x
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
CH CH
CHCH
Assembly Optimizer
Factory
CHCH
CH
CH
CH
CH CHCH
111
Proposed Approach: Evaluation Criteria • Improve performance
• t = no. of interactions between components within an assembly
• Transform t collocation checked calls to t unchecked calls
• Eliminate mis-optimizations• Check incompatible POA
policies• Incompatible invocation
semantics (oneway or twoway)
• No changes to individual component implementations• Eliminate need for a local
vs. remote version
• Customizable & application transparent• Investigate feasibility of applying
optimizations to .NET Web Services (in addition to CCM)
112
Doctoral Research & Dissertation Timeline
Non-generated artifact
To be implemented
Implementation complete
Collaboration with Jeff Parsons
9 Jan, 2003 15 Dec, 2006
3/03 6/03 9/03 12/03 3/04 6/04 9/04 12/04 3/05 6/05 9/05 12/05 3/06 6/06 9/06
1/03WORDS 03 Paper
7/03Work on PICML started
4/04Inital version of PICML
10/03Elsevier Journal 06 Paper
6/04Support for generation of metadata
8/04Support for hierarchical composition
9/04RTAS 05 Paper
5/05Elsevier Journal 06 Paper
12/04IJES 05 Paper 3/05
IJSEKE 06 Paper
1/05MDE Book Chapter 05
10/05IEEE Computer 06
2/05Support for scalable composition
10/04OOPSLA 04 Poster
10/06Support for .NET Web Services
4/06 - 9/06Submissions to MoDELS, Middleware,
OOPSLA/GPCE, DOA, RTSS, ICSE
3/06Qualifying Exam
7/06Support for assembly optimization