Modeling for cloud
Semantic Modeling
Cloud computing has lately become the
attention grabber in both academia and
industry. The promise of seemingly unlimited, readily available utility-type computing
has opened many doors previously considered
difficult, if not impossible, to open. The cloud-
computing landscape, however, is still evolving,
and we must overcome many challenges to foster widespread adoption of clouds.
The main challenge is interoperability.
Numerous vendors have introduced paradigms
and services, making the cloud landscape
diverse and heterogeneous. Just as in the computer hardware industry’s early days, when each
vendor made and marketed its own version of
(incompatible) computer equipment, clouds are
diverse and vendor-locked. Although many
efforts are under way to standardize clouds’
important technical aspects, notably from the
US National Institute of Standards and Technology (NIST), consolidation and standardization
are still far from reality. In this two-part article,
we discuss how a little bit of semantics can help
address clouds’ key interoperability and porta-
bility issues. erations, the consumer must select a cloud to
use. Each cloud vendor exposes these details in
different formats and at different granularity
levels.
Second, the consumer must learn about the
vendor’s technical aspects (service interface,
scaling configuration, and so on) and workflow.
Third, the consumer must then develop an
application or customize the vendor-provided
multitenant application to fulfill his or her
requirements. When doing this, the consumer
must take into account various technical details
such as the choice of programming language
and limitations in the application runtime,
which will all be vendor-specific.
Finally, after deploying the application, if
the consumer must change the service provider
(which happens surprisingly often), at least two
major considerations arise. First, the consumer
might need to rewrite or modify the application
code to suit the new provider’s environment. For
some clouds (such as IaaS), this is minimal, but
porting the code in PaaS and SaaS clouds will
likely require more effort.
The second consideration is that data col-
lected for the application might need transfor-
mation. Data is the most important asset the
application generates over time and is essential
for continued functioning. The transformation
might even need to carry across different data
models. The industry practice is to address such
transformations case-by-case.
To overcome these challenges and provide
better insight into the aspects requiring attention, proper modeling in this space is essential.
Semantic modeling can help with this. | ||
landscape in Figure 1 arise owing to two types of heterogeneities. The first is vertical heterogeneity — that is, within a single silo. We can address this by using middleware to homogenize the API and sometimes by enforcing standardization. For example, the Open Virtualization Format (OVF; www.dmtf.org/ vman) is an emerging standard that allows migration of virtual-machine snapshots across IaaS clouds. The second type is horizontal heterogeneity—that is, across silos. Overcoming this is fundamentally more difficult. Each silo provides different abstraction levels and services. High-level modeling pays off, especially when you must move an application and code horizontally across these silos. Surprisingly, many small and medium businesses make horizontal transitions. PaaS clouds offer faster setup for applications, and many exploit the free hosting opportunities of some platform cloud providers (for example, Google’s App Engine). When the application grows in scope and criticality, however, an IaaS cloud might prove cheaper, more flexible, and more reliable, prompting a transition. The following discussion on semantic models applies to both ver- tical and horizontal interoperability. The key in addressing both types is that many of the core data and services causing them follow the same semantic concepts. For example, almost all IaaS clouds follow conceptually similar workflows when allocating resources, although the actual service implementations and tools differ significantly. Similarly, the PaaS modeling space is a subset of that for IaaS, from a semantic perspective. These observations prompt us to argue for semantic models’ applicability, especially to supplement interoperability in the cloud space. Some parts of the scientific and engineering community weren’t
|
||
use Web Services Description Lan- guage (WSDL) descriptions in their Web services, these descriptions are syntactic and can’t provide useful semantic details. To overcome this deficiency, SAWSDL (Semantic Annotations for WSDL and XML Schema; www.w3.org/TR/sawsdl) attaches semantic-model details to WSDL documents. The software lifecycle stage is important in determining the modeling requirements. For example, some nonfunctional and system require- ments might not be modeled during development but will be taken into account only during deployment. A different team handles each of these lifecycle stages; this separation is important so that one team doesn’t step on another’s toes. This separation aims to focus the modeling effort on the correct time and people. Some cloud models fall under the nonfunctional/system/ ontology space in Figure 2. Such models include the Elastic Computing Modeling Language (ECML), Elastic Deployment Modeling Language (EDML),
and Elastic Management Modeling
Language (EMML), all based on OWL
and published by Elastra (Elastra Languages).
However, some aspects of cloud
modeling have received little or no
attention. For example, there’s no
comprehensive higher-level modeling in the data and functional spaces.
Lessons learned during large-scale
ontological modeling in the Semantic Web and Semantic Web services,
biology, and many other domains are
readily applicable here and would
help address some of the challenges
in the cloud space. Proc. 2008 Int’l Conf. Web Intelligence and Intelligent Agent Technology (WI- IAT 08), vol. 1, IEEE CS Press, 2008, pp. 496–502. 2. K. Sivashanmugam et al., “Adding Semantics to Web Services Standards,” Proc.Int’lConf.WebServices (ICWS 03), CSREA Press, 2003, pp. 395–401. Amit Sheth is the director of Kno.e.sis—the Center of Excellence on Knowledge- Enabled Human-Centered Computing at Wright State University. He’s also the university’s LexisNexis Ohio Eminent Scholar and an IEEE Fellow. He’s on the Web at http://knoesis.org/amit. Ajith Ranabahu is pursuing a PhD in cloud- computing interoperability at Wright State University. He worked with IBM on Sharable Code and its Altocumulus project, and he coordinates the Cirrocumulus project. Contact him at ajith.ranabahu@gmail.com. |
||
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. semantics, 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 (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. 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-REST(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.
|