Difference between revisions of "Modeling for cloud part2"
(Added the details and external reference) |
|||
Line 1: | Line 1: | ||
− | |||
This is the Wiki version of the article published in IEEE Internet Computing July/August 2010 Issue. | This is the Wiki version of the article published in IEEE Internet Computing July/August 2010 Issue. | ||
[http://www.computer.org/portal/web/csdl/doi/10.1109/MIC.2010.98 External Reference] | [http://www.computer.org/portal/web/csdl/doi/10.1109/MIC.2010.98 External Reference] | ||
Line 11: | Line 10: | ||
Part 1 of this two-part article discussed | Part 1 of this two-part article discussed | ||
challenges related to cloud computing, | challenges related to cloud computing, | ||
− | cloud interoperability, and | + | cloud interoperability, and multidimensional analysis of cloud-modeling requirements |
− | + | ||
(see the May/June issue). Here, we look more | (see the May/June issue). Here, we look more | ||
specifically at areas in which semantic models | specifically at areas in which semantic models | ||
Line 24: | Line 22: | ||
functionality and quality-of-service details in | functionality and quality-of-service details in | ||
a platform-agnostic manner can immensely | a platform-agnostic manner can immensely | ||
− | benefit the cloud community. This is | + | benefit the cloud community. This is particularly important for porting application code |
− | + | ||
horizontally—that is, across silos. Lightweight | horizontally—that is, across silos. Lightweight | ||
semantics, which we describe in detail later, are | semantics, which we describe in detail later, are | ||
Line 37: | Line 34: | ||
challenge. For a good overview of this concern, | challenge. For a good overview of this concern, | ||
see the discussion of customer scenarios in the | see the discussion of customer scenarios in the | ||
− | + | [www.scribd.com/doc/18172802/Cloud-Computing-Use-Cases-Whitepaper Cloud Computing User Cases White Paper]. The root of this difficulty is the lack of a platform-agnostic data | |
− | + | ||
model. Semantic modeling of data to provide a | model. Semantic modeling of data to provide a | ||
platform-independent data representation would | platform-independent data representation would | ||
Line 47: | Line 43: | ||
differ between vendors. The operations’ seman-</p> | differ between vendors. The operations’ seman-</p> | ||
<p style="float:right;width:300px">tics, however, are similar. Metadata added | <p style="float:right;width:300px">tics, however, are similar. Metadata added | ||
− | through annotations pointing to generic | + | through annotations pointing to generic operational models would play a key role in consolidating these APIs and enable interoperability |
− | + | ||
− | + | ||
among the heterogeneous cloud environments.<br /><br /> | among the heterogeneous cloud environments.<br /><br /> | ||
<span style="font-size:12pt;color:purple">Functional Portability</span><br /> | <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 | ||
− | of semantics (that is, viewing the cube in | + | of semantics (that is, viewing the cube in Figure 1 from the top), we see that opportunities |
− | + | exist to use semantic models to define applications’ functional aspects in a platform-agnostic | |
− | exist to use semantic models to define | + | |
− | + | ||
manner. In most cases, however, converting a | manner. In most cases, however, converting a | ||
− | high-level model directly to executable | + | high-level model directly to executable artifacts pollutes both representations. Intermediate representations are important to provide a |
− | + | ||
− | + | ||
convenient conversion. | convenient conversion. | ||
Applying high-level modeling to describe an | Applying high-level modeling to describe an | ||
Line 73: | Line 63: | ||
derive fine-grain artifacts. UML models usually | derive fine-grain artifacts. UML models usually | ||
don’t include code, so you can use them only | don’t include code, so you can use them only | ||
− | to generate a skeletal application. That is, low- | + | to generate a skeletal application. That is, low-level details are deliberately kept away from the |
− | level details are deliberately kept away from the | + | |
high-level models. | high-level models. | ||
UML models, however, are inherently bound | UML models, however, are inherently bound | ||
with object-oriented languages, and UML- | with object-oriented languages, and UML- | ||
driven development processes depend heavily | driven development processes depend heavily | ||
− | on advanced tools (for example, IBM’s | + | on advanced tools (for example, IBM’s Rational Rose; www-01.ibm.com/software/awdtools/ |
− | + | ||
developer/rose). This limits UML’s applicability. | developer/rose). This limits UML’s applicability. | ||
A popular alternative to such tool-dependent | A popular alternative to such tool-dependent | ||
− | heavy upfront models is domain-specific | + | heavy upfront models is domain-specific languages (DSLs). Their popularity is due partly </p> |
− | + | ||
</td></tr> | </td></tr> | ||
<tr><td> | <tr><td> | ||
Line 91: | Line 78: | ||
such as Ruby and Python. Unlike | such as Ruby and Python. Unlike | ||
UML, a DSL is applicable only in a | UML, a DSL is applicable only in a | ||
− | given domain but enables a light- | + | given domain but enables a light-weight model in that domain, often |
− | weight model in that domain, often | + | |
without requiring proprietary tools. | without requiring proprietary tools. | ||
For example, you can use IBM’s | For example, you can use IBM’s | ||
Line 101: | Line 87: | ||
would be more convenient for users.) | would be more convenient for users.) | ||
“Lightweight” signifies that these | “Lightweight” signifies that these | ||
− | models don’t use rich knowledge | + | models don’t use rich knowledge representation languages and so have |
− | + | ||
limited reasoning capabilities. | limited reasoning capabilities. | ||
Our Cirrocumulus project for | Our Cirrocumulus project for | ||
− | cloud interoperability (http://knoesis.org/research/srl/projects/cirrocumulus) uses DSLs to bridge the | + | cloud interoperability ([http://knoesis.org/research/srl/projects/cirrocumulus Cirrocumulus]) uses DSLs to bridge the |
gap between executable artifacts | gap between executable artifacts | ||
and high-level semantic models. A | and high-level semantic models. A | ||
DSL, although domain specific, can | DSL, although domain specific, can | ||
provide a more programmer-oriented | provide a more programmer-oriented | ||
− | representation of functional, non- | + | representation of functional, non-functional, or even data descriptions. |
− | functional, or even data descriptions. | + | |
A best-of-both-worlds approach | A best-of-both-worlds approach | ||
− | is to use annotations to link | + | is to use annotations to link models, which provides the convenience |
− | + | of lightweight models while supporting high-level operations when | |
− | of lightweight models while | + | required. Figure 2 shows an annotation referring to an ontology from |
− | + | a fictitious DSL script for configuration. The script is more program- | |
− | required. Figure 2 shows an | + | |
− | + | ||
− | a fictitious DSL script for | + | |
− | + | ||
mer-oriented (in fact, it’s derived | mer-oriented (in fact, it’s derived | ||
from Ruby) but lacks an ontology’s | from Ruby) but lacks an ontology’s | ||
− | richness. However, the | + | richness. However, the annotation links the relevant components |
− | + | between the different levels, providing a way to facilitate high-level | |
− | between the different levels, | + | |
− | + | ||
operations while maintaining a | operations while maintaining a | ||
simpler representation. | simpler representation. | ||
Line 132: | Line 110: | ||
the type of semantics and software | the type of semantics and software | ||
lifecycle stage—that is, looking at the | lifecycle stage—that is, looking at the | ||
− | cube in Figure 1 from the | + | cube in Figure 1 from the front — you |
can see the modeling coverage for | can see the modeling coverage for | ||
− | software deployment and | + | software deployment and management. Elastra’s Elastic Computing |
− | + | Modeling Language (ECML), </p> | |
− | Modeling Language (ECML), | + | |
<p style="float:right;width:350px">[[File:Chart1.png|350px]]<br /><br />[[File:Chart2.png|350px]]<br /><br /> | <p style="float:right;width:350px">[[File:Chart1.png|350px]]<br /><br />[[File:Chart2.png|350px]]<br /><br /> | ||
<table width="350" border="0" cellpadding="5"> | <table width="350" border="0" cellpadding="5"> | ||
<tr> | <tr> | ||
− | <td width="175"><p style="float:left"> | + | <td width="175"><p style="float:left">Elastic Deployment Modeling Language |
(EDML), and Elastic Management | (EDML), and Elastic Management | ||
Modeling Language (EMML) ontolo- | Modeling Language (EMML) ontolo- | ||
Line 171: | Line 148: | ||
[[File:Chart3.png|600px]] | [[File:Chart3.png|600px]] | ||
<p style="float:left;width:200px">exploiting these data stores requires | <p style="float:left;width:200px">exploiting these data stores requires | ||
− | substantial redesign of many data- | + | substantial redesign of many data-driven applications and often makes |
− | driven applications and often makes | + | porting data to a traditional relational database extremely difficult. |
− | porting data to a traditional | + | |
− | + | ||
The current practice is to address | The current practice is to address | ||
such transitions case-by-case. | such transitions case-by-case. | ||
Line 180: | Line 155: | ||
data in RDF and generate the specific | data in RDF and generate the specific | ||
target representations, and in some | target representations, and in some | ||
− | cases even the code for the | + | cases even the code for the application’s data access layer. This method |
− | + | ||
can formulate transformations from | can formulate transformations from | ||
one representation to another using | one representation to another using | ||
the lifting-lowering mechanism. | the lifting-lowering mechanism. | ||
Semantic Annotations for WSDL | Semantic Annotations for WSDL | ||
− | and XML Schema ( | + | and XML Schema ([http://www.w3.org/TR/sawsdl SAWSDL]) demonstrated this |
− | w3.org/TR/sawsdl) demonstrated this | + | |
mechanism’s use for data mediation. | mechanism’s use for data mediation. | ||
2 | 2 | ||
Line 201: | Line 174: | ||
of semantics and software lifecycle | of semantics and software lifecycle | ||
stage, most of this data modeling | stage, most of this data modeling | ||
− | applies during application | + | applies during application development. Concrete artifacts generated |
− | + | ||
from these high-level models would | from these high-level models would | ||
be used mostly during subsequent | be used mostly during subsequent | ||
Line 213: | Line 185: | ||
from other distributed environments | from other distributed environments | ||
is the availability of Web services | is the availability of Web services | ||
− | to manipulate resources. | + | to manipulate resources. Availability of the service APIs lets you |
− | + | ||
programmatically manage the cloud | programmatically manage the cloud | ||
resources, even from within the | resources, even from within the | ||
same cloud. These capabilities have | same cloud. These capabilities have | ||
− | revolutionized application | + | revolutionized application deployment and management. For example, |
− | + | you can compose or mash up well-defined services to facilitate elaborate workflows. | |
− | you can compose or mash up well- | + | |
− | defined services to facilitate | + | |
− | + | ||
Service definitions are usually | Service definitions are usually | ||
syntactic, and many researchers | syntactic, and many researchers | ||
have focused on embedding rich | have focused on embedding rich | ||
− | metadata in formal service | + | metadata in formal service descriptions. One result of this research |
− | + | ||
is SAWSDL. A growing trend is | is SAWSDL. A growing trend is | ||
to annotate HTML descriptions to | to annotate HTML descriptions to | ||
Line 233: | Line 200: | ||
semantic metadata. One reason for | semantic metadata. One reason for | ||
this method’s popularity is search | this method’s popularity is search | ||
− | engines’ use of metadata to | + | engines’ use of metadata to display results in customized formats. |
− | + | ||
Yahoo’s SearchMonkey and Google | Yahoo’s SearchMonkey and Google | ||
− | Rich Snippets are two such | + | Rich Snippets are two such microformat-driven schemes. These anno- |
− | + | ||
tations, unlike the DSL annotations | tations, unlike the DSL annotations | ||
in Figure 3, might not always point | in Figure 3, might not always point | ||
Line 251: | Line 216: | ||
three main benefits that go beyond | three main benefits that go beyond | ||
customized search capabilities. | customized search capabilities. | ||
− | The first benefit deals with | + | The first benefit deals with Representational State Transfer (REST) |
− | + | ||
style services. Many cloud service | style services. Many cloud service | ||
− | providers adopt REST-style Web | + | providers adopt REST-style Web services that don’t advocate a formal |
− | + | ||
service description. These services | service description. These services | ||
are described using HTML pages. | are described using HTML pages. | ||
WSDL 2.0, the latest specification, | WSDL 2.0, the latest specification, | ||
− | explicitly supports formal | + | explicitly supports formal description of “RESTful” services but hasn’t |
− | + | ||
seen quick adoption. Alternative | seen quick adoption. Alternative | ||
approaches such as SA-REST3 (SA | approaches such as SA-REST3 (SA | ||
stands for semantic annotation), a | stands for semantic annotation), a | ||
− | generic annotation scheme that | + | generic annotation scheme that follows microformat design principles, |
− | + | ||
are becoming more applicable in | are becoming more applicable in | ||
this space. These annotations enable | this space. These annotations enable | ||
Line 277: | Line 238: | ||
The second benefit deals with | The second benefit deals with | ||
handling change. The cloud space is | handling change. The cloud space is | ||
− | still evolving. If the history of | + | still evolving. If the history of software or component interoperability </p> |
− | + | ||
</td> | </td> | ||
</tr> | </tr> | ||
Line 286: | Line 246: | ||
the cloud space will be difficult and | the cloud space will be difficult and | ||
won’t likely happen soon. Attaching | won’t likely happen soon. Attaching | ||
− | formalizations via annotations, | + | formalizations via annotations, however, is flexible enough to accommodate an evolving model. This is |
− | + | ||
− | + | ||
especially attractive to vendors who | especially attractive to vendors who | ||
aren’t willing to invest heavily in | aren’t willing to invest heavily in | ||
interim standards. | interim standards. | ||
− | The third benefit is that the | + | The third benefit is that the formalizations apply not only to service descriptions but also to many |
− | + | ||
− | + | ||
other aspects such as service-level | other aspects such as service-level | ||
agreements (SLAs) and software | agreements (SLAs) and software | ||
Line 301: | Line 257: | ||
these documents, facilitating more | these documents, facilitating more | ||
automation in the cloud space. For | automation in the cloud space. For | ||
− | example, Web Service- Level | + | example, Web Service- Level Agreement ([http://www.research.ibm.com/wsla WSLA]) specification provides a |
− | + | ||
− | com/wsla) specification provides a | + | |
way to formalize SLAs, but creating | way to formalize SLAs, but creating | ||
− | and maintaining these | + | and maintaining these formalizations is time-consuming. |
− | + | Figure 3 illustrates using SA-REST annotations on the Amazon | |
− | Figure 3 illustrates using SA- | + | |
− | REST annotations on the Amazon | + | |
Elastic Compute Cloud (EC2) SLA | Elastic Compute Cloud (EC2) SLA | ||
document. It shows how a capable | document. It shows how a capable | ||
− | processor could use these | + | processor could use these annotations to extract a WSLA equivalent |
− | + | ||
of the human-readable SLA. | of the human-readable SLA. | ||
These benefits’ importance comes | These benefits’ importance comes | ||
into perspective when you consider | into perspective when you consider | ||
the enormous body of research on | the enormous body of research on | ||
− | standard-driven service | + | standard-driven service compositions and agreement matching. |
− | + | ||
The informal, non-standard-driven | The informal, non-standard-driven | ||
nature of many cloud services made | nature of many cloud services made | ||
− | most of the previous research | + | most of the previous research inapplicable. However, being able to |
− | + | ||
glean formalizations from existing | glean formalizations from existing | ||
documents opens the doors to apply | documents opens the doors to apply | ||
Line 338: | Line 287: | ||
However, learning from the past, | However, learning from the past, | ||
we advocate a multilevel modeling | we advocate a multilevel modeling | ||
− | strategy to provide smooth | + | strategy to provide smooth transitions into different granularity |
− | + | ||
levels. We also think that DSLs can | levels. We also think that DSLs can | ||
play an important role in the cloud | play an important role in the cloud | ||
− | space to provide lightweight | + | space to provide lightweight modeling in an appealing manner to the |
− | + | ||
software engineering community. | software engineering community. | ||
<br /><br /><span style="font-size:12pt;color:purple">References</span><br /> | <br /><br /><span style="font-size:12pt;color:purple">References</span><br /> | ||
Line 359: | Line 306: | ||
3. A.P. Sheth, K. Gomadam, and J. Lathem,<br /> | 3. A.P. Sheth, K. Gomadam, and J. Lathem,<br /> | ||
“SA-REST: Semantically Interoperable<br /> | “SA-REST: Semantically Interoperable<br /> | ||
− | and Easier-to-Use Services and | + | and Easier-to-Use Services and Mashups,” IEEE Internet Computing, vol. 11,<br /> |
− | + | no. 6, 2007, pp. 91–94.</span><br /><br /> | |
− | no. 6, 2007, pp. 91–94.</span><br / | + | Amit Sheth is the director of the Ohio Center of Excellence on Knowledge-Enabled<br /> |
− | Amit Sheth is the director of the Ohio | + | |
− | + | ||
Computing (Kno.e.sis) at Wright State<br /> | Computing (Kno.e.sis) at Wright State<br /> | ||
University. He’s also the university’s<br /> | University. He’s also the university’s<br /> | ||
Line 373: | Line 318: | ||
on Sharable Code and its Altocumulus<br /> | on Sharable Code and its Altocumulus<br /> | ||
project, and he coordinates the Cirrocu-<br /> | project, and he coordinates the Cirrocu-<br /> | ||
− | mulus project (http://knoesis. | + | mulus project ([http://knoesis.org/research/srl/projects/cirrocumulus Cirrocumulus]). Contact him at ajith@knoesis.org |
− | + | /</p> | |
− | + | ||
</td> | </td> | ||
</tr> | </tr> | ||
</table> | </table> |
Revision as of 15:53, 30 July 2010
This is the Wiki version of the article published in IEEE Internet Computing July/August 2010 Issue. External Reference
Semantic Modeling
Part 1 of this two-part article discussed
challenges related to cloud computing,
cloud interoperability, and multidimensional 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 operational models would play a key role in consolidating 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 representation languages and so have limited reasoning capabilities. Our Cirrocumulus project for cloud interoperability (Cirrocumulus) 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 models, which provides the convenience of lightweight models while supporting high-level operations when required. Figure 2 shows an annotation referring to an ontology from a fictitious DSL script for configuration. The script is more program- mer-oriented (in fact, it’s derived from Ruby) but lacks an ontology’s richness. However, the annotation links the relevant components between the different levels, providing 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 management. Elastra’s Elastic Computing Modeling Language (ECML),
|
||
exploiting these data stores requires substantial redesign of many data-driven applications and often makes porting data to a traditional relational database extremely difficult. The current practice is to address such transitions case-by-case. A better approach is to model the data in RDF and generate the specific target representations, and in some cases even the code for the application’s data access layer. This method can formulate transformations from one representation to another using the lifting-lowering mechanism. Semantic Annotations for WSDL and XML Schema (SAWSDL) demonstrated this mechanism’s use for data mediation. 2 Lightweight modeling in terms of DSLs also applies here. For example, the Web services community has long used XML Schema definitions as platform-agnostic data definitions. Schema definitions serve as inputs to code generation tools that generate platform-specific data definitions. From the perspective of the type of semantics and software lifecycle stage, most of this data modeling applies during application development. Concrete artifacts generated from these high-level models would be used mostly during subsequent lifecycle stages.
Service Enrichment microformat is part of the “lowercase semantic web” movement, which emphasizes lightweight models. Embedding rich semantic meta- data in cloud service descriptions has three main benefits that go beyond customized search capabilities. The first benefit deals with Representational State Transfer (REST) style services. Many cloud service providers adopt REST-style Web services that don’t advocate a formal service description. These services are described using HTML pages. WSDL 2.0, the latest specification, explicitly supports formal description of “RESTful” services but hasn’t seen quick adoption. Alternative approaches such as SA-REST3 (SA stands for semantic annotation), a generic annotation scheme that follows microformat design principles, are becoming more applicable in this space. These annotations enable the seamless, flexible integration of formalizations into RESTful service descriptions. This opens the door to many exciting avenues such as faceted search to identify relevant reusable services and semiautomated service compositions. The second benefit deals with handling change. The cloud space is still evolving. If the history of software or component interoperability |
||
is any guide, achieving consensus in
the cloud space will be difficult and
won’t likely happen soon. Attaching
formalizations via annotations, however, is flexible enough to accommodate an evolving model. This is
especially attractive to vendors who
aren’t willing to invest heavily in
interim standards.
The third benefit is that the formalizations apply not only to service descriptions but also to many
other aspects such as service-level
agreements (SLAs) and software
licenses. You can use annotations
to embed formalizations even for
these documents, facilitating more
automation in the cloud space. For
example, Web Service- Level Agreement (WSLA) specification provides a
way to formalize SLAs, but creating
and maintaining these formalizations is time-consuming.
Figure 3 illustrates using SA-REST annotations on the Amazon
Elastic Compute Cloud (EC2) SLA
document. It shows how a capable
processor could use these annotations to extract a WSLA equivalent
of the human-readable SLA.
These benefits’ importance comes
into perspective when you consider
the enormous body of research on
standard-driven service compositions and agreement matching.
The informal, non-standard-driven
nature of many cloud services made
most of the previous research inapplicable. However, being able to
glean formalizations from existing
documents opens the doors to apply
many well-researched techniques.
models excel in providing solutions.
However, learning from the past,
we advocate a multilevel modeling
strategy to provide smooth transitions into different granularity
levels. We also think that DSLs can
play an important role in the cloud
space to provide lightweight modeling in an appealing manner to the
software engineering community.
|