Brief Introduction to CosMIC:
The Component Synthesis
using Model Integrated Computing (CoSMIC) project is a MDA toolset being
developed by the Institute for Software Integrated Systems (ISIS) at
1. Model and analyze distributed real-time and embedded application functionality and QoS requirements.
2. Synthesize CCM-specific deployment metadata required to deliver end-to-end QoS to DRE applications.
The CoSMIC toolsuite provides modeling of DRE systems, their QoS requirements, and QoS adaptation policies used for DRE application QoS management. The component behavior, their interactions, and QoS requirements are modeled using a domain specific modeling language that adheres to the OMG Deployment & Configuration (D&C) specification (ptc/2003-07-08). CoSMIC enables modeling the standards-based CCM components.
Hand-writing the required XML descriptors to configure our components is tedious and error prone. We therefore utilize CosMIC (we specifically use a subset of CosMIC called PICML, which stands for Platform-Independent Component Modeling Language) to generate the bulk of descriptors for us.
For more information on CosMIC, please refer to the following article:
CoSMIC:
An MDA Generative Tool for Distributed Real-time and Embedded Applications.
Importing IDL to PICML
To quick start our Stock Quoter modeling process in GME, CoSMIC
introduces idl_to_picml , which is an executable program that imports
the IDL files you just created into PICML.
%COSMIC_ROOT%\bin
is included in
the PATH variable, e.g., c:\Program Files\ISIS\CoSMIC\bin.
MyQuoter\
, and type the
following command:
MyQuoter.xme
file in the
MyQuoter
directory. Note that if
-x option is not used, the default xme file name will be
PICML_default_xme_file.xme.
Figure 2
In the Browser of the generated model, the PredefinedTypes
folder contains a bunch of atomic datatype elements that will be referenced by
other modeling parts later. You don't have to worry about them for now. The
models in InterfaceDefinitions folder are the PICML representations
ofthe IDL files you just imported. Double-click to open Broker, it
will show you a white, document-like entity which represents a
<<FileRef>> instance and a yellow box-shaped entity representing a
<<Package>> instance. Their equivalent representations in IDL files
are "#include" and "module" respectively. Figure 3 gives
you a clear view of GME representation of all the 3 idl files created. We will
cover the other folders in the next section.
Figure 3
Now
we are ready to model the rest of the Stock Quoter systems.
This section describes modeling the Quoter
application using PICML. If you have trouble producing a functioning model from
this tutorial, please see the, pre-built Quoter model which is provided for your reference. This model contains all
elements created as part of this tutorial.
Note: To import an XML file in GME, select File->Import
XML.. from GME and choose your XML model
The PICML paradigm is designed for the OMG
Deployment & Configuration (D&C) specification (ptc/2003-07-08), so the modeling process
is straightforward if you are familiar with the specification. Please see the DAnCE
project for more
information. For those who hate specification (including me, :-)), an overview
of D&C
and as well as a tutorial of D&C
and CCM can help to reduce the learning curve. In addition, it is
also helpful to read through Chapter 32 of TAO's Developer's Guide 1.4a (CIAO
and CCM) which thoroughly describes the various descriptors required for a
component (*.iad, *.ccd, *.cid, etc).
The complete PICML Quoter model consists of
modeling elements distributed across various folders. If you used idl_to_picml
to generate the initial model, you will see that it has created all these
folders and some of the tedious boilerplate modeling for us. The rest of the
section will explain the purpose of each folder as well as the modeling
entities contained in these folders. We will also show how to model some of the
folders that have to be done by hand.
Important: The interpreters that generate deployment
artifacts expect very strict constraints in the model. When you finish your
model, and any time you wish to generate anything, it is a good idea to check
constraints by clicking on File->Check->Check All in GME. This
will help you find many logic errors in your model.
This folder contains implementation artifacts
associated with components. idl_to_picml has created these artifacts
for us, with their dependency relationships correctly captured. Figure 4 shows
the Implementation Artifacts for Broker.
Figure 4.
This folder contains models that describe the implementations
of component interfaces. In the Quoter example, we will have two monolithic
component implementations - named StockDistributorImplementation and StockBrokerImplementation
- and an assembly component implementation named StockQuoter, which is
an assembly of StockDistributorImplementation and StockBrokerImplementaion.
idl_to_picml has created the monolithic component implementations for
us, as shown in figure 5 for example, but we have to specify the connections
between them in order to construct a Quoter system.
Figure 5
Assembly components provide a boundary for the composition
of monolithic components and even other assemblies. Assembly components do not
provide actual implementations for their interface, it is a virtual component
that delegates its ports and attributes to one or more of the entities it
contains. There are slight differences between modeling an assembly and
modeling a monolithic component. Since the assembly is a virtual component, it
is not necessary to model a MonolithicImplementation
.
Instead, instances of other components are placed within the assembly
and connected. Let's try to assemble the StockQuoter.
MyQuoter/InterfaceDefinitions/Broker/Stock/StockBroker
in the browser to the "StockQuoter" <<ComponentAssembly>> window
while pressing ALT key. Repeat the same steps for
MyQuoter/InterfaceDefinitions/Distributor/Stock/StockDistributor
,
and you will see two instances of component interfaces have been created as
shown in Figure 6 (the black line in the figure only indicates .mapping)
Figure 6
>
Figure 7
This folder contains deployable
component packages. Every instance in an assembly should have a corresponding
monolithic implementation and packaged in a ComponentPackagebe To create a
package for StockBroker.instance
MyQuoter/ComponentImplementations/StockBroker
Implementation/StockBrokerMonolithicImpl.
Refer the <<ComponentRef>> Broker to
MyQuoter/InterfaceDefinitions/Broker/Stock/StockBroker
.
To create a reference in GME, simply drag the tree node in the Browser "into"
the reference model. For example, you should drag the tree node
MyQuoter/ComponentImplementations/StockBroker
Implementation/StockBrokerMonolithicImpl
into <<ComponentImplementationReference>> Broker. Check
GME manual(tutorials) for more information.
The model you built should resemble Figure 8.
>
Figure 8
Now create a
ComponentPackage/StockDistributor following the same steps.
1.
Insert a <<ComponentPackage>> named
"StockQuoter"
2.
Add a <<ComponentImplementationReference>>
named "StockQuoter", refer it to MyQuoter/ComponentImplementations/StockQuoter/StockQuoter
3.
Switch to connect mode and connect
<<ComponentImplementationReference>> StockQuoter with
<<ComponentPackage>> StockQuoter, as in Figure 9.
>
Figure 9
This folder contains just one
model capturing specific configuration of Component packages.
MyQuoter/ComponentPackage/StockQuoter/StockQuoter
(Not <<ComponentImplementationReference>>
MyQuoter/ComponentPackage/StockQuoter/StockQuoter!)
This folder contains one model
capturing information about the top-level element that will be fed to the
application.
Quoter/PackageConfiguration/Default/Default
This folder contains
domain-specific models capturing information about the target environment in
which component-based application will be deployed. In this Quoter example, we
can either deploy the two components into ONE host, or into TWO different host.
We will deploy the Quoter into two different host.
Now we are ready to deploy our Components to the actual physical environment.
This folder contains a plan model
that captures information about the assignment of component to nodes.
MyQuoter/Targets/Domain/Broker
and
MyQuoter/Targets/Domain/Distributor
respectively
MyQuoter/ComponentImplementations/StockQuoterImplementation/StockQuoter/StockBroker
and
MyQuoter/ComponentImplementations/StockQuoterImplementation/StockQuoter/StockDistributor
respectively. Note that the <<ComponentRef>> in DeploymentPlan is
not referring to the interface, but rather the actual instance of the
implementation.
Figure 10.
>
Figure 11
Now move your cursor to
<<ComponentRef>> StockDistributor, and left-click it, so that
it looks like Figure 12.
Figure 12
This operation
associates StockDistributor component to the
<<CollocationGroup>> running on Distributor node. To do
the same with Broker, just right-click on another
<<CollocationGroup>>, and left-click on StockBroker
<<CollocationGroup>> which is highlighted.
Up to this point, we are basically
done with the modeling part. Before we generate anything from this model
though, please DO remember to check the constraints of the model as we
mentioned earlier.
After we are done with the modeling, the
Deploymentplan interpreter that comes along with PICML will help us
to generate a Plan.cdp file. Please make sure you generate
this file to MyQuoter/descriptors. Note that to get the example working,a
Node
Map file should be created to map logical nodes to NodeManager object
references,e.g:
DistributorNode corbaloc:iiop:localhost:30000/NodeManager
BrokerNode corbaloc:iiop:localhost:40000/NodeManager