Transcript Model-Driven Engineering Of Component Systems Krishnakumar Balasubramanian James Hill

Model-Driven Engineering Of
Component Systems
Krishnakumar Balasubramanian
James Hill
Dr. Douglas C. Schmidt
{kitty, hillj,jules,schmidt}@dre.vanderbilt.edu
Institute for Software Integrated Systems
Vanderbilt University
Nashville, Tennessee
Presentation Roadmap
• Research Challenges
• Software System Analysis
• Component System Integration
• Component System Optimization
• Demonstration Section
• Scenario
• Question
• Capability Demo
• Enabling Technology
• Concluding Remarks
• December Demo
• Benefits & Roadmap
2
Model-Driven Engineering Technologies
Component Package
Component
Component
Component
Assembly
Component
Assembly
re
s
)c
s
on
ge
fig
u
cka
Component
packager
Component
p
(2) assembles
k
ac
assembly
Component
Assembly
Component
sp
Component
configurator
ag
ing
co
nfi
gu
CoSMIC
ific
ati
on
de
ve
lop
s
ec
Component
Developer
fe
Assembly
ra t
ion
b
ed
Deployment
Application
(5) deployment planning
Assembly
k
ac
o
kt
ac &
db ion
ee at g
) f ur
(7 nfig nnin
co p l a
Component
Assembler
(1)
Component
pa
Component
Component
(3)
System
Optimization
Technologies
Component
Component
(4
Component
System
Integration
Technologies
Component
planning
Component
Component
deployer Assembly
(6) analysis &
benchmarking
Component
Imp
Imp
Imp
l
l
l
Resource
Requirements
system
analyzer
Properties
Analysis & Benchmarking
System
Analysis
Technologies
3
SLICE System Scenario (1/2)
sensor 1
(main)
planner 1
sensor 2
error recovery
effector 1
(main)
configuration
effector 2
planner 2
SLICE application string consists of:
 2 sensors
 2 planners that process data from the
sensors
 Configuration component responsible
for converting planner output into
configuration input for effectors
 Effectors that perform action based on
configuration parameters
4
SLICE System Scenario (2/2)
sensor 1
(main)
planner 1
error recovery
effector 1
(main)
configuration
effector 2
planner 2
sensor 2
• Three hosts
• One database is shared between
all hosts
Deployment & Performance
Requirements
• Critical path deadline is 350 ms
• main sensor to main effector
through configuration
• Components in the critical path must
be deployed across multiple hosts
• Main sensor & effector must be
deployed on separate hosts
5
Software System Analysis Challenge: Serialized Phasing
System
infrastructure
components
developed first
Level of Abstraction
Application components
developed after
infrastructure is mature
Development Timeline
6
Software System Analysis Challenge: Serialized Phasing
Finished development
Level of Abstraction
System integration
& testing
Integration
Surprises!!!
Development Timeline
7
Software System Analysis Challenge: Serialized Phasing
Level of Abstraction
Still in development
Ready for testing
Complexities
• System infrastructure cannot be
tested adequately until applications
are done
Development Timeline
8
Software System Analysis Challenge: Serialized Phasing
Level of Abstraction
Overall performance?
Complexities
• System infrastructure cannot be
tested adequately until applications
are done
• Entire system must be deployed &
configured properly to meet QoS
requirements
• Existing evaluation tools do not
support “what if” evaluation
Development Timeline
9
Software System Analysis Challenge: Serialized Phasing
Level of Abstraction
Meet QoS
requirements?
Key QoS concerns
• Which deployment configurations
meet the QoS requirements?
Development Timeline
10
Software System Analysis Challenge: Serialized Phasing
Level of Abstraction
Performance
metrics?
Key QoS concerns
• Which deployment configurations
meet the QoS requirements?
• What is the worse/average/best
time for various workloads?
Development Timeline
11
Software System Analysis Challenge: Serialized Phasing
Level of Abstraction
System
overload?
Key QoS concerns
• Which deployment configurations
meet the QoS requirements?
• What is the worst/average/best time
for various workloads?
• How much workload can the system
handle until its QoS requirements
are compromised?
Development Timeline
12
It is hard to address these concerns in processes that use serialized phasing
Software System Analysis in 10 Years
Validate Design Rules
• System will adhere to system
design specifications
• “Correct-by-construction”
Ensure
Design
Conformance
Ensure Design Conformance
• System will be deployed &
configured to conform to
system design rules
Conduct “What If” Analysis
• QoS concerns can be analyzed
prior to completing the entire
system
Validate
Design
Rules
Conduct
“What If”
Analysis
• e.g., before system
integration phase
13
The cycle is repeated when developing application & infrastructure components
Software System Analysis in 3 Years
Component Workload Emulator (CoWorker)
Utilization Test Suite Workflow (CUTS):
• Develop MDE tools which allow
emulation of real components on
target infrastructure
• Develop analysis tools to evaluate &
verify QoS performance
• Develop framework to allow
Validate
instrumentation of “real” components
Design
• Develop framework for intermixing
Rules
of emulation components with “real”
component
Validate
Design
Conformance
Conduct
“What If”
Analysis
14
Enable testing on target infrastructure early in development lifecycle
Software System Analysis 2006 Demos
• August
• Model-Driven Software System Analysis Tools
• Automated generation of emulation components
• December
• Develop CoWorkEr emulation framework in multiple SOA
technologies
• Microsoft .NET web services
• J2EE web service
• Integration of CBML & WML into other MDD tools
• GEMS
15
Software System Analysis Motivating Question?
How can system engineers analyze the performance
of an application on the actual deployment
environment before the development of application
components is complete?
16
Enabling Technology: Model-Driven Software System Analysis
• The Component Behavior Modeling
Language (CBML) & Workload
Modeling Language (WML) is used to
define the behavior of CoWorkEr
components in a PICML model
• CoWorkEr implementation is generated
on top of a component framework that
contains a benchmarking aspect
Emulation Framework
17
Component System 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)
• Integration can be done at multiple levels
• Process Integration
• Functional Integration
• Data integration
• Presentation Integration
• Portal Integration
• System Integration refers to functional
integration done via
• Distributed Object Integration
• Service-Oriented Integration
DLL
DLL
Implementation
QoS
Properties
Version
Checksum
Dependencies
DLL
DLL
Implementation
QoS
Properties
Version
QoS Specs
List of Files
Checksum
Dependencies
Component
Interconnections
18
Component System Integration: Unresolved Challenges
• Component middleware is getting a lot
more declarative
• Management of diverse metadata
& configuration of middleware is
proving to be error-prone
• Current practice attempts integration in
a manual fashion
• Inappropriate level of abstraction
• Integrators need to learn enough of
every technology
• Lack of automated tools limits
scalability of integration
• Total system performance determined
by “Quality-of-Integration” (QoI)
• QoI refers to the effect of the
integration on the functional & QoS
properties of the integrated system
• Along with “Quality-ofImplementation”
XML
XML
<assemblyImpl>
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
<name>ScaleQosket</name>
<package href="ScaleQosket.cpd"/>
XML
<package href="ScaleQosket.cpd"/>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<name>LocalResourceManagerComponent</name>
</instance>
...
<connection>
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<internalEndpoint>
<package href="ScaleQosket.cpd"/>
<portName>outgoing_image_Evt</portName>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<instance xmi:idref="LocalReceiver"/>
<name>LocalResourceManagerComponent</name>
</internalEndpoint>
<package href="LocalResourceManagerComponent.cpd"/>
<internalEndpoint>
</instance>
...
<connection>
<name>incoming_image_outgoing_image_Evt</name>
<name>LocalResourceManagerComponent</name>
<package href="LocalResourceManagerComponent.cpd"/>
<name>incoming_image_outgoing_image_Evt</name>
<name>ScaleQosket</name>
</instance>
<instance xmi:id="LocalResourceManagerComponent">
<package href="LocalResourceManagerComponent.cpd"/>
</instance>
...
<connection>
<name>incoming_image_outgoing_image_Evt</name>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
<instance xmi:idref="LocalReceiver"/>
<portName>incoming_image_Evt</portName>
</internalEndpoint>
<instance xmi:idref="MultiReceiver"/>
<internalEndpoint>
</internalEndpoint>
<portName>incoming_image_Evt</portName>
</connection>
<internalEndpoint>
<portName>outgoing_image_Evt</portName>
</assemblyImpl>
<instance xmi:idref="LocalReceiver"/>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</internalEndpoint>
</assemblyImpl>
<internalEndpoint>
<portName>incoming_image_Evt</portName>
<instance xmi:idref="MultiReceiver"/>
</internalEndpoint>
</connection>
</assemblyImpl>
XML
<assemblyImpl>
<instance xmi:id="ScaleQosket">
<name>ScaleQosket</name>
Component
Component
<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>
MIDDLEWARE
OS KERNEL
OS KERNEL
OS I/O Subsystem
OS I/O Subsystem
Network Interfaces
Network Interfaces
19
Component System Integration: Unresolved Challenges
• Lack of tool support for key integration
activities
• Needed to scale up the integration &
deployment process
• Relieve the system integrator from
ever-changing platform-specific
details aka “accidental complexities”
• Unable to define constraints at the
whole system level
• Needed to evaluate service-level
agreements before integration
• Check system consistency before &
after integration
• Lack of infrastructure to apply system
level optimizations
• Needed to automate and optimize
the generated glue-code
• (Re-)Target emerging & new
middleware technologies
DLL
DLL
Implementation
QoS
Properties
Version
Checksum
Dependencies
DLL
DLL
Implementation
QoS
Properties
Version
QoS Specs
List of Files
Checksum
Dependencies
Component
Interconnections
20
Component System Integration in 10 Years
• Provide abstractions for expressing
system level design intent
• Automation of key system
integration activities
• Generation of integration gluecode
• Generation of middleware &
deployment metadata
• Integrated system satisfies Service
Level Agreements (SLAs)
• De-emphasize programming-in-thesmall
• No more whack-a-mole
approach to system integration
• No more violation of Don’t
Repeat Yourself (DRY) principle
Tools to integrate “systems-in-the-large”
21
Component System Integration in 3 Years
•Develop tools to allow functional integration
of two sample COTS technologies
• CCM
CCM Deployment
descriptors
• Web Services
•Express & evaluate service level
agreements between applications built
using
• CCM
• Web Services
•Enable integrators to evaluate QoI using
different
• Integration topologies, e.g., Message
Bus, Point-to-Point, Broker
(Indirect/Direct), Publish/Subscribe
• Integration architectures, e.g., Java
Business Integration (JBI), Service
Component Architecture (SCA),
Windows Communication Foundation
(WCF)
System Integration Modeling Language (SIML)
Web Service
Deployment
descriptors
PICML
(CCM DSML)
WSML
(WS DSML)
22
Component System Integration 2006 Demos
• August
• Use CCM & Web Service as sample technologies to be
integrated
• Show automatic generation of Web Service implementation
from model
• December
• To be defined in discussion with LMCO STI personnel
23
Component System Integration Motivating Questions?
1. How do you integrate systems that were not
designed to work together?
2. How do you predict the effects of system
integration before the actual integration?
3. How do you automate key system integration
activities?
24
Demonstration Scenario
CCM Client
Web Service
Client
Benchmark_Data_Collector Web Service
CCMC TypeSpecific SOAP
lient IIOP ó SOAP Server
25
Enabling Technology: Model-Driven System Integration
• Model-based approach to system
integration
• Develop System Integration
Modeling Language (SIML), a
DSML for system integration
• Hierarchical composition of DSMLs
• Composed from multiple sub-DSMLs
CCM Deployment
descriptors
• PICML  CCM
• WSML  Web Services
• Each sub-DSML is used as a
model library
• Built in a re-usable & extensible
fashion
• “Open-Closed” principle
• New languages can be added;
existing ones reused
• Preserve existing investment
• Tools for sub-DSMLs work
seamlessly in composite DSML
System Integration Modeling Language (SIML)
Web Service
Deployment
descriptors
PICML
(CCM DSML)
WSML
(WS DSML)
26
Enabling Technology: Usage Scenarios
• SIML consists of DSMLs for each
technology being integrated
• Targets system developers &
integrators
• System Developers
• Use DSML of corresponding
CCM Deployment
technology
descriptors
• Assists in automating key
deployment activities
• Used during development of
individual sub-systems
• System Integrators
• Use the integration DSML
• Assists in combining subsystems together
• Used during integration testing
of the whole system
System Integration Modeling Language (SIML)
Web Service
Deployment
descriptors
PICML
(CCM DSML)
WSML
(WS DSML)
27
Component System Optimization
• 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
Control
Center
SystemResource
Manager
Image Feeds
(.NET Web
Service)
• Reducing communication costs
• Moving data closer to the
consumers by replication
• Reflection-based approaches
Local
Resource
Manager
Scaling QoS
Predictor
Scale
Qosket
Cropping QoS
Predictor
Crop
Qosket
Compress
Qosket
Compression QoS
Predictor
• Choosing appropriate
alternate implementations
28
Component System Optimizations: Unresolved Challenges
Stream 1
1.Lack of application
context
• Missed middleware
optimization
Node Application
opportunities
• E.g., every
invocation
performs check
for locality
• Optimization
decisions relegated
to run-time
• Impossible for
middleware (alone)
Container
to predict application
Remote Invocation
Receptacle
Component
usage
Collocated Invocation
Facet
Component Assembly
Creates
• Settle for nearEvent Source
Component Home
Event Sink
optimal solutions
Cannot be solved efficiently at middleware level alone! 29
Stream 2
SystemResource
Manager
Control Center
Display
Stream 3
Stream 4
Sender
CH
Local
Resource
Manager
Crop
Qosket
Scale
Qosket
CH
Compress
Qosket
Receiver
CH
CH
Compression
QoS Predictor
Scaling QoS
Predictor
Cropping QoS
Predictor
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
Component System Optimizations: Unresolved Challenges
Stream 1
2.Overhead of platform
mappings
Stream 2
SystemResource
Manager
Control Center
Display
Stream 3
• Blind adherence to
platform semantics
• Inefficient middleware
glue code generation
per component
• Example: Every
component is created
using a Factory
Object
• Overhead of
external
components similar
to internal ones
3.Standard component
models define only
virtual assemblies
Stream 4
Node Application
Sender
CH
Local
Resource
Manager
Scale
Qosket
Crop
Qosket
CH
Compress
Qosket
CH
CH
Receiver
Compression
QoS Predictor
Scaling QoS
Predictor
Cropping QoS
Predictor
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
Container
Component
Component Assembly
CH
Component Home
Receptacle
Facet
Event Source
Remote Invocation
Collocated Invocation
Creates
Event Sink
30
Component System Optimization in 10 Years
• Generate application
specific components for a
product-line architecture
CH
CH
• Optimize middleware in an
application-specific fashion
CH
CH
• Improve performance
CH
CH
CH
CH
CH
CH
CH
• Reduce static & dynamic
footprint
• Eliminate misoptimizations
• No changes to individual
component
implementations
CH
CH
CH
CH
CH
Assembly
Optimizer
CH
CH
CH
CH
• Customizable & completely
application transparent
Factory
CH
CH
CH
CH
31
Component System Optimization in 3 Years
• Identify sources of overhead in
large-scale component-based
system of systems
Stream 1
Stream 2
SystemResource
Manager
Control Center
Display
• Develop component assembly
optimizer which eliminates these
sources of overhead
Stream 3
Stream 4
Node Application
Sender
• Use CORBA Component Model
as a test bed
• Apply optimization technology
to a variety of scenarios
Local
Resource
Manager
Crop
Qosket
Scale
Qosket
Compress
Qosket
• Scenarios with & without
inherent hierarchy
CH
CH
Compression
QoS Predictor
Scaling QoS
Predictor
Cropping QoS
Predictor
CH
Factory
• PCES Emergency
Response System (30+
components)
• ARMS GateTest scenarios
(100+ components)
Receiver
CH
CH
CH
CH
CH
Container
Receptacle
Component
CH
Facet
Component Assembly
Event Source
Component Home
Event Sink
Remote Invocation
Optimized Invocation
Creates
32
Component System Optimization Motivating Question?
How do you custom optimize individual
component implementations based on the
global system composition properties & usage
scenario without requiring any changes to the
component implementation?
33
Component System Optimization: December Demo
• Baseline for comparison
CH
• Performance & footprint (with vanilla
CIAO)
CH
• Emergency Response System
(30+ components)
CH
CH
• ARMS GateTest scenarios (100+
components)
CH
CH
CH
CH
CH
CH
CH
CH
• Scenario with & without inherent
hierarchy
CH
CH
CH
CH
Assembly
Optimizer
• Reduce static & dynamic footprint
• n = no. of internal components, x =
total no. of components in the
assembly
CH
CH
CH
CH
• Reduce from n factories to 1 factory
Factory
CH
CH
CH
CH
34
Component System Optimization: December Demo
• 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
• Customizable & application transparent
implementations
• Investigate feasibility of applying
• Eliminate need for a local
optimizations to Web Services (in addition
vs. remote version
35
to CCM)
Concluding Remarks
• Our research focuses on Model-driven Engineering (MDE) solutions
• Software System Analysis Tools (CUTS/PICML/WSML)
• Benefits
• Reduces complexities with serialized phasing in large-scale systems
• Automates generation of distributed emulation infrastructure
• Component System Integration Tools (SIML)
• Benefits
• Provides infrastructure to evaluate service level agreements
• Automates generation of integration glue-code
• Component System Optimization Tools (PICML/WSML)
• Benefits
• Perform optimizations on a “system-of-systems” scale
36
Tools can be downloaded from www.dre.vanderbilt.edu/CoSMIC/
Enabling Technology: Component Assembly Optimizer
• Component Assembly Optimizer
• Uses system models as input
• Combines
• Information about the system-asa-whole as well as individual
components from the model
• Catalog of (feature, perf.
overhead),(feature,dependent
features) & (feature, incompatible
features) tuples of the underlying
middleware technology
• To optimize globally, i.e., across the
whole “system-of-systems”, the
• Generated middleware glue code
• Configuration of underlying
middleware
• Generated deployment metadata
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
CH
Assembly
Optimizer
CH
CH
CH
CH
Factory
CH
CH
CH
CH
37
Target Scenarios
• “System of Systems” with
portions exhibiting
• Hierarchy
• No hierarchy
• Built using COTS
component/SOA technologies
• Web Services
• CCM
• EJB
• Specific deployment scenario
• Information about
• Composition structure
of systems/component
assemblies
• Desired QoS policies
• Target deployment
domain
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
38
Solution Approach: Physical Assembly Mapping
3.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
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
• Too deep – Single giant
blob
• Too shallow –
Potentially lower
benefits
C
H
C
H
C
H
Assembly
Optimizer
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
C
H
39
Component System Optimization: What’s missing?
• Lack of high-level notation to
guide optimization frameworks
• Missing AST of application
Application Abstract
Syntax Tree
N
N
N
N
N
N
N
N
N
N
40
Component System Optimization: What’s missing?
• Lack of high-level notation to
guide optimization frameworks
• Missing AST of application
• Emphasis on detection at runtime (reflection)
• Additional overhead in the
fast path
• Not suitable for all systems
Control
Center
SystemResource
Manager
Image Feeds
(.NET Web
Service)
• Not completely application
transparent
• Requires providing multiple
implementations
• Optimization performed either
Local
Resource
Manager
Scaling QoS
Predictor
Scale
Qosket
Cropping QoS
Predictor
Crop
Qosket
Compress
Qosket
Compression QoS
Predictor
• Too early, or too late
41
Steps Involved in Integration Using SIML
1.Generate a CCM DSML model
from the IDL definition of
application components
2.Generate a WSDL file from the
IDL of the component(s) to be
exposed as Web Service(s)
3.Import the CCM model into
integration DSML; define
connections between CCM
components to assemble
application
4.Generate a WSDL DSML model
from generated WSDL
5.Import the Web Service model
into integration DSML
CORBA Component
Application
1
2
IDL 2 PICML
Generator
IDL 2 WSDL
Generator
4
3
WSDL Importer
5
Integration DSML
CCM Deployment
descriptors
CORBA
Component
Model DSML
6
Web Service
Deployment
descriptors
Web Services
DSML
9
7
8
Web Service
Client
CCM Component
CCM TypeSpecific SOAP
Client IIOP ó SOAP Server
Web Service
Client
Web Service
Client
42
Steps Involved in Integration Using SIML
6.Annotate the WSDL model to
specify deployment information
like WSDL port bindings (host
name, host port number, URI
including namespace of service
et al.
7.Generate CCM deployment
descriptors
8.Generate the type-specific
proxies, i.e., integration gluecode
9.Generate Web Service
deployment descriptors
including updated WSDL, web
container hosting artifacts
CORBA Component
Application
1
2
IDL 2 PICML
Generator
IDL 2 WSDL
Generator
4
3
WSDL Importer
5
Integration DSML
CCM Deployment
descriptors
CORBA
Component
Model DSML
6
Web Service
Deployment
descriptors
Web Services
DSML
9
7
8
Web Service
Client
CCM Component
CCM TypeSpecific SOAP
Client IIOP ó SOAP Server
Web Service
Client
Web Service
Client
43
SIML Benefits
• Develop integration DSML in a
modular & extensible fashion
• Model-library based approach
• Allows re-use of existing
platform DSMLs
• New platforms can be added
easily
Integration DSML
CCM Deployment
descriptors
CORBA
Component
Model DSML
Web Services
DSML
Web Service
Deployment
descriptors
Web Service
Client
CCM Component
Generic
CCM
SOAP
Client IIOP ó SOAP Server
Web Service
Client
Web Service
Client
Web Service
Client
CCM Component
CCM TypeSpecific SOAP
Client IIOP ó SOAP Server
Web Service
Client
Web Service
Client
44