Difference between revisions of "Modeling for cloud part2"

Semantic Modeling

for Cloud Computing, Part 2

Amit Sheth and Ajith Ranabahu • Wright State University

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.

Opportunities for Semantic Models in Cloud Computing
Semantic models are helpful in three aspects of cloud computing. The first is functional and nonfunctional definitions. The ability to define application functionality and quality-of-service details in a platform-agnostic manner can immensely benefit the cloud community. This is particularly important for porting application code horizontally—that is, across silos. Lightweight semantics, which we describe in detail later, are particularly applicable. The second aspect is data modeling. A crucial difficulty developers face is porting data hori- zontally across clouds. For example, moving data from a schema-less data store (such as Google Bigtable1) to a schema-driven data store such as a relational database presents a significant challenge. For a good overview of this concern, 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 platform-independent data representation would be a major advantage in the cloud space. The third aspect is service description enhancement. Clouds expose their operations via Web services, but these service interfaces differ between vendors. The operations’ seman-

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.

Functional Portability
From a perspective of the cloud landscape based on the language abstraction and type 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 manner. In most cases, however, converting a high-level model directly to executable artifacts pollutes both representations. Intermediate representations are important to provide a convenient conversion. Applying high-level modeling to describe an application’s functional aspects isn’t new. Many software development companies have been using UML to model application functionality at a high level and use artifacts derived from these models to drive development. This process is commonly called model-driven development. This is an example of using high-level models to derive fine-grain artifacts. UML models usually don’t include code, so you can use them only to generate a skeletal application. That is, low-level details are deliberately kept away from the high-level models. UML models, however, are inherently bound with object-oriented languages, and UML- driven development processes depend heavily on advanced tools (for example, IBM’s Rational Rose; www-01.ibm.com/software/awdtools/ developer/rose). This limits UML’s applicability. A popular alternative to such tool-dependent heavy upfront models is domain-specific languages (DSLs). Their popularity is due partly

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
One feature differentiating the cloud from other distributed environments is the availability of Web services to manipulate resources. Availability of the service APIs lets you programmatically manage the cloud resources, even from within the same cloud. These capabilities have revolutionized application deployment and management. For example, you can compose or mash up well-defined services to facilitate elaborate workflows. Service definitions are usually syntactic, and many researchers have focused on embedding rich metadata in formal service descriptions. One result of this research is SAWSDL. A growing trend is to annotate HTML descriptions to embed richer, machine-readable semantic metadata. One reason for this method’s popularity is search engines’ use of metadata to display results in customized formats. Yahoo’s SearchMonkey and Google Rich Snippets are two such microformat-driven schemes. These anno- tations, unlike the DSL annotations in Figure 3, might not always point to ontologies. Their structure can be based on a vocabulary or taxonomy— a lower-grade nonsemantic model. For example, the popular hCalendar

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.

The cloud space presents many opportunities for researchers, and we see a plethora of applica- tions that use semantic modeling. Issues such as interoperability and data portability, which the cloud community is facing right now, are the very issues for which semantic

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.

References
1. F. Chang et al., “Bigtable: A Distributed
Storage System for Structured Data,” in
Proc. Usenix Symp. Operating Systems
Design and Implementation, Usenix
Assoc., 2006, p. 15.
2. M. Nagarajan et al., “Semantic Interoper-
ability of Web Services—Challenges and
Experiences,” Proc. 2006 IEEE Int’l Conf.
Web Services (ICWS 06), IEEE CS Press,
2006, p. 373–382.
3. A.P. Sheth, K. Gomadam, and J. Lathem,
“SA-REST: Semantically Interoperable
and Easier-to-Use Services and Mashups,” IEEE Internet Computing, vol. 11,
no. 6, 2007, pp. 91–94.

Amit Sheth is the director of the Ohio Center of Excellence on Knowledge-Enabled
Computing (Kno.e.sis) at Wright State
University. He’s also the university’s
LexisNexis Ohio Eminent Scholar. 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 Cirrocu-
mulus project (Cirrocumulus). Contact him at ajith@knoesis.org /