Difference between revisions of "Modeling for cloud part1"
Line 1: | Line 1: | ||
+ | <table border="1" width="650"> | ||
+ | <tr> | ||
+ | <td width="650"> | ||
<span style="font-size:28pt;color:purple">Semantic Modeling<br /><br />for Cloud Computing, Part 2</span><br /><br /> | <span style="font-size:28pt;color:purple">Semantic Modeling<br /><br />for Cloud Computing, Part 2</span><br /><br /> | ||
Amit Sheth and Ajith Ranabahu • <i>Wright State University</i><br /><br /> | Amit Sheth and Ajith Ranabahu • <i>Wright State University</i><br /><br /> | ||
Line 41: | Line 44: | ||
via Web services, but these service interfaces | via Web services, but these service interfaces | ||
differ between vendors. The operations’ seman-</p> | differ between vendors. The operations’ seman-</p> | ||
− | <p style="float: | + | <p style="float:right;width:300px">tics, however, are similar. Metadata added |
through annotations pointing to generic opera- | through annotations pointing to generic opera- | ||
tional models would play a key role in consoli- | tional models would play a key role in consoli- | ||
dating these APIs and enable interoperability | dating these APIs and enable interoperability | ||
− | among the heterogeneous cloud environments. | + | among the heterogeneous cloud environments.<br /><br /> |
− | Functional Portability | + | <span style="font-size:12pt;color:purple">Functional Portability</span><br /> |
From a perspective of the cloud landscape | From a perspective of the cloud landscape | ||
based on the language abstraction and type | based on the language abstraction and type | ||
Line 80: | Line 83: | ||
heavy upfront models is domain-specific lan- | heavy upfront models is domain-specific lan- | ||
guages (DSLs). Their popularity is due partly </p> | guages (DSLs). Their popularity is due partly </p> | ||
− | <p style=";width:300px">to the availability of extensible | + | </td></tr> |
+ | <tr><td> | ||
+ | <p style="float:left;width:300px">to the availability of extensible | ||
interpreted programming languages | interpreted programming languages | ||
such as Ruby and Python. Unlike | such as Ruby and Python. Unlike | ||
Line 133: | Line 138: | ||
ment. Elastra’s Elastic Computing | ment. Elastra’s Elastic Computing | ||
Modeling Language (ECML), Elas- </p> | Modeling Language (ECML), Elas- </p> | ||
+ | </td></tr></table> |
Revision as of 16:53, 13 July 2010
Semantic Modeling
Part 1 of this two-part article discussed
challenges related to cloud computing,
cloud interoperability, and multidimen-
sional analysis of cloud-modeling requirements
(see the May/June issue). Here, we look more
specifically at areas in which semantic models
can support cloud computing. tics, however, are similar. Metadata added
through annotations pointing to generic opera-
tional models would play a key role in consoli-
dating these APIs and enable interoperability
among the heterogeneous cloud environments. |
to the availability of extensible interpreted programming languages such as Ruby and Python. Unlike UML, a DSL is applicable only in a given domain but enables a light- weight model in that domain, often without requiring proprietary tools. For example, you can use IBM’s Sharable Code DSL (http://services. alphaworks.ibm.com/isc), which is a mashup generator, with a basic text editor. (However, providing graphical abstractions and specialized tooling would be more convenient for users.) “Lightweight” signifies that these models don’t use rich knowledge rep- resentation languages and so have limited reasoning capabilities. Our Cirrocumulus project for cloud interoperability (http://kno- esis.org/research/srl/projects/cir- rocumulus) uses DSLs to bridge the gap between executable artifacts and high-level semantic models. A DSL, although domain specific, can provide a more programmer-oriented representation of functional, non- functional, or even data descriptions. A best-of-both-worlds approach is to use annotations to link mod- els, which provides the convenience of lightweight models while sup- porting high-level operations when required. Figure 2 shows an annota- tion referring to an ontology from a fictitious DSL script for configu- ration. The script is more program- mer-oriented (in fact, it’s derived from Ruby) but lacks an ontology’s richness. However, the annota- tion links the relevant components between the different levels, pro- viding a way to facilitate high-level operations while maintaining a simpler representation. From the perspective based on the type of semantics and software lifecycle stage—that is, looking at the cube in Figure 1 from the front—you can see the modeling coverage for software deployment and manage- ment. Elastra’s Elastic Computing Modeling Language (ECML), Elas- |