Enrique Castro-Leon is an enterprise architect and technology strategist with Intel Corporation working on technology integration for highly efficient virtualized cloud data centers to emerging usage models for cloud computing.
He is the lead author of two books, The Business Value of Virtual Service Grids: Strategic Insights for Enterprise Decision Makers and Creating the Infrastructure for Cloud Computing: An Essential Handbook for IT Professionals.
He holds a BSEE degree from the University of Costa Rica, and M.S. degrees in Electrical Engineering and Computer Science, and a Ph.D. in Electrical Engineering from Purdue University.
Robert R. Harmon is Professor of Marketing and Technology Management and Cameron Research Fellow in the School of Business at Portland State University. His research is focused on service innovation, sustainable IT services, and the strategic migration of manufacturing companies to service enterprise business models. His research has been funded by the National Science Foundation, Intel Corporation, IBM, Tata Consultancy Services, the Semiconductor Industry Association (SIA), and Semiconductor Equipment and Materials International (SEMI), among others. He has a Ph.D. in marketing and information systems from Arizona State University.
John Kennedy is a senior researcher in the Cloud and Services Lab of Intel Labs Europe. He is focusing on open standards and open source enablers to facilitate more dependable cloud computing. John is particularly active in Intel's European research initiatives, engaging in collaborative research at local, national, and international levels. He has a B. Eng (hons) in Electronic Engineering and M. Sc. in Computing. John joined Intel in 1997 and has held roles of systems analyst, developer, solution architect, and applied researcher in Intel's Manufacturing, IT, and Intel Labs organizations.
Mrigank Shekhar is an enterprise architect with Intel Corporation working on platform solution architecture for highly efficient cloud data centers for cloud computing. He has also worked for Siemens and Biotronik where he led the research and design team responsible for implantable defibrillator products.
He holds several patents in medical electronics and server architecture. He also successfully founded a point-of-sale company. He holds a Master’s degree in Computer Engineering from the University of Southern California, Los Angeles.
On the Concept of Metadata Exchange in Cloud Services - Part I Published: April 10, 2013 • Service Technology Magazine Issue LXXI PDF
The concept of metadata is essential in a number of disciplines, including Database Architecture and Library Science. In a cloud environment, service introspection is a must have requirement to establish meaningful relationships between cloud service consumers and providers. Metadata exchange refers to the automated exchange of information about a service offering during service setup and operations. Automated, standardized metadata exchange will become an essential ingredient in a functioning, scalable cloud service ecosystem. Under the current state of the art, when an application is implemented using outsourced cloud components there is inherently less transparency about the service components when services cross organizational boundaries as in private clouds, or even more so company boundaries. This circumstance makes it difficult to implement manageability policies for a composite application made of outsourced service components. This paper reports an initial exploration of geolocation and power management examples for service metadata elements.
The notion of metadata is central to many disciplines such as the Dewey Decimal System for cataloguing books in library and information science, the EXIF data recorded with every frame by many digital cameras. The notion of metadata is also essential to the business model of the leading social media companies like Facebook, Google, and Twitter. It can be said that the revenue from metadata is so valuable to these companies that it allows them to deliver the actual content to their user community essentially for free or at nominal cost. Reflecting this value, metadata is also at the core of intellectual property ownership and privacy controversies in the industry today. Cloud metadata constitutes an emerging field. The cloud metadata literature typically refers to metadata management for information stored in the cloud, about performance issues, replication policies and the optimal configurations for specific applications.
In the context of databases, the notion of metadata is commonly associated with information about stored data to organize the data and make it easier to search and retrieve. Metadata access and replication policies are important factors in the information retrieval performance and, when improperly architected, can become a bottleneck. Metadata is an important consideration in a company's data strategy. Metadata is essential in defining the structure of warehouse repositories aggregating information from
Needed in this environment are mechanisms for service metadata exchange, information about the service itself. Not much has been reported on metadata for cloud services proper. This article captures an initial exploration on the subject.
Defining Cloud Service Metadata
David Linthicum introduces the notion of metaservices as being data about services. The analogy here is that metaservices are descriptive of services in the same sense that metadata is descriptive of data stores. For the purposes of this work we need to take this initial definition one step beyond, more in alignment with the business process management (BPM) conceptual view described by R. Schmidt and applicable specifically to the description of cloud-based services, as illustrated in Figure 1.
Figure 1 - The three dimensions of service value (Source: Intel Corporation 2012)
Schmidt observed that services are usually defined in terms of functional properties, such as the service's API and access methods. Yet this description is incomplete for practical implementations. There are two more necessary dimensions beyond the obvious functional capabilities that a service offers: nonfunctional properties and metaservices, and a service's value or goodness is determined by the aggregate of the three dimensions, that is, the volume along the three vectors shown in Figure 1.
For instance, for most applications a cloud service would be of limited value if it does not come with a description about its reliability and security aspects. Qualitative assertions about a service's reliability and security and vague promises are not likely to satisfy service consumers. Unintended deviations from the stated reliability and security aspects are possible and because of this, from the consumer perspective the service is not fully described without the presence of enforcement provisions, preferably in real time and in an automated manner. In other words any exceptions or deviations are to be handled programmatically instead of relying on manual intervention, including the legal system. Manual processes would be too onerous, again negating the value of the cloud. Enforcement is provided as set of actions under a metaservice. The implementation of these enforcement actions can be automatic in the form of machine-to-machine interactions, such as rebates if certain conditions are not met or manual, in the case, for example, of complaint, arbitration, or lawsuit processes. Because of the expense involved, manual processes should be reserved for truly exceptional occasions. Other actions, such as billing or even search and discovery actions can be construed as metaservice functions.
A quintessential example of metadata is pricing, namely the pricing of a service itself. For composite services, the service provider can determine the cost of providing the service through the application of a formula combining the cost of the subsidiary services with the provider's direct costs. These calculations can be made in real time without the need to do offline accruals at the end of each billing period.
For the purposes of this discussion, we will use the term service metadata to refer to the nonfunctional aspects of a cloud service (Schmidt's axis 2). Metadata consists of nouns or declarations, essentially a set of property sheets describing the service. Metadata needs to be accompanied with a set of verbs or actions to make metadata actionable or enforceable (axis 3.) Schmidt claims the three axes cover the service space completely, but it is entirely possible that new aspects may appear and become relevant with practice evolution and increasing process maturity.
The meta-aspects are both relative and recursive. The aspects are relative in the sense that the meta- designation depends on the particular context. A service provider may decide to outsource all or portions of the meta-functions, for instance relying on a third party service provider for issuing certificates. Such certificate authority provider would be a service provider on its own right, beholden in turn to its particular metadata and metaservices. Hence someone's metadata may be someone else's main product. Metadata is recursive in the sense that a metaservice, in addition to possibly being a service on its own right, can also carry its own metadata and metaservice attributes. The manageability aspects of a service map directly to a cloud service's metadata and metaservice where manageability monitoring is captured under metadata, and the manageability control aspects are enforced under a metaservice.
A number of high-level service metadata concepts, albeit under a different name, are covered in the Open Data Center Alliance Usage: Service Catalog usage model prescription. This represents a vast, yet to be explored area. The main challenges are not technical, but in achieving a common agreement and mechanisms to automate cloud service setup. These challenges will be eventually addressed through a number of commonly agreed standards. The next section covers examples of efforts in this area.
Motivation for Developing Metadata Concepts
Under the current state of the art the main factor limiting the applicability of cloud services is the lack of maturity of the nonfunctional aspects of the cloud. Solution architects do not have the means and tools to estimate the security and service level implications of a cloud based composite application. From a solution integration perspective, the transactions involved in integrating a service component are as relevant as the services rendered. By their nature, services are subject to service level agreements, whether implicit or explicit. The World Wide Web as initially conceived was an open framework for humans to access applications over the Internet. The human-to-machine interactions eventually evolved into Web services with machine-to-machine interactions over the Internet. We expect a similar evolution for services, with labor-intensive negotiations for service setup today giving way to automated processes not too far into the future. The force driving this change is lower transaction costs.
Service level agreements (SLAs) are considered to be the complete definition of the service offered by the provider and consumed by the customer, including all functional and nonfunctional parameters of the service. Without machine-readable SLAs, service consumers are forced to manually investigate and negotiate offerings from multiple service providers, and for scalability and manageability reasons service providers cannot offer personalized SLAs. Opportunities for offering better value services to customers are lost, as are opportunities to consolidate infrastructure.
This problem of metadata has been subject to extensive research past and present. SLA@SOI, for example, is a European Commission funded research project dedicated to developing and proving the concept of machine-readable service level agreements. SLA@SOI has provided a solution for comprehensive SLA management supporting arbitrary service types and covering the complete service lifecycle. The project has developed a holistic reference architecture, a harmonized set of models for SLA-related management activities, and a complete reference implementation of the architecture published as open-source. The project has delivered a complete implementation of SLA management at the infrastructure layer.
Of particular interest to this discussion is perhaps the SLA model that SLA@SOI has developed. The SLA* model in particular is a generic service level agreement model that is rich, comprehensive, extensible, and format-independent. Arbitrary SLAs can be defined using domain-specific vocabularies. Developed by the SLA Management and Foundations focus area of the project, the most recent version of the model is described in that focus area's latest project deliverable. Software to support the SLA model has been published open source and is documented on the SLA@SOI SourceForge project wiki. The SLA* model is focused on syntax. The FI-Ware project, a European Commission funded public-private partnership project, is building on SLA* to develop a model that also comprehends semantics. The intent is that the resulting model can be contributed to W3C's Unified Service Description Language (USDL) Incubator Group for publication as a standard.
SLA@SOI has also played a key role in the creation of OGF's Open Cloud Computing Interface (OCCI) standard. Version 1.1, published in 2011, is a RESTful API designed to allow cloud resources to be managed: provisioned, reprovisioned, queried, and torn down. An extension has recently been proposed to support SLAs. As mentioned above, if we look at previous patterns of technology evolution, the role of metadata goes beyond service introspection and transparency. Today, even when a specific IT application is outsourced to a service provider, applications such as payroll, expense reports, or CRM, there is a lengthy and manual negotiation process upfront.
Machine-readable SLAs and standardized APIs will provide a means to automate much, if not all, of
These applications are treated as unbreakable monoliths precisely because it is very difficult to infer the behaviors of the whole based on the characteristics of the individual components. The availability of metadata will allow making predictable QoS assessments for a whole application based on the analysis of the metadata of the service components. The transparency brought about by metadata will make it easier to build IT applications with best-of-breed service components, likely smaller and more fungible than the fully fledged services of today. In particular, cloud services functioning as building blocks to other services are instances of servicelets. It will be possible to fine tune the delivered QoS through the manipulation of the individual servicelets. The assumption is that the means will exist to estimate the delivered QoS in a provable way, that is, through the application of mathematical formulas using servicelet metadata.
For instance a solution architect for a provider may determine that in order to reach the advertised QoS the backend storage availability needs to be increased from 98 percent to 99 percent. An in-house solution might require reengineering the storage subsystem in the company-owned data center. A more agile, service-oriented solution might involve leasing additional storage capacity, perhaps from another storage provider and deploying a mirror copy of the data, or perhaps switching to another provider altogether with a different and more stringent QoS profile. All these assessments would be done on the basis of available metadata. If the consumer is unsure about the validity of the provider metadata, it could sign up the services of a third-party provider in the business of monitoring storage QoS. This is an example of a metaservice.
In principle this process is not much different than building a portfolio of investments in finance with a target set of behaviors by integrating a set of instruments with desired characteristics and aided by the services of ratings companies. This capability is a function of technology maturity. We can expect machine-to-machine negotiations to become more prevalent. Negotiations that used to require human-to-human interactions between service providers and consumers with lengthy and protracted negotiations taking months to close will morph to humans interacting with portals, with time constants shrinking to days, and eventually machine-to-machine, with transactions closed in a matter of minutes.
This new environment will foster the creation of new classes of service providers, more horizontally focused in a rich and agile application environment. One aspect that can't be emphasized enough is that metadata is money, with significant strategic implications to suppliers and consumers alike. It enables Google, Amazon, Facebook, Netflix, and Apple services. The economic benefit of getting a hold on metadata explains the viability and success of these companies to the extent that they can offer a number of products for free or at much lower prices than would otherwise be possible.
The Dynamic Enterprise Perimeter for Cloud-Based Applications
The boundary of a set of IT resources under which a common metadata and metaservice applies is said to define an enterprise perimeter. This concept was introduced by Dournaee for security analysis, but it is actually applicable to any aspect of manageability. Within the enterprise perimeter a set of assertions (meta-assertions) holds true. One example assertion would be: "the servers inside this perimeter support Intel® Node Manager server platform power management technology." The presence of this capability would enable the carrying out of common power management policies within the perimeter for the precise optimization of power and energy consumption.
Now assume that the initial set of IT resources is augmented with outsourced resources through a cloud bursting arrangement. If principles of software engineering were to be applied to this situation toward the goal of limitless scalability, the augmented resources would be transparent to the original set so the same methods and operational procedures apply uniformly. If this condition is met, the net effect of cloud bursting would be that of expanding the initial enterprise perimeter into a virtual enterprise perimeter (dynamic enterprise perimeter in Dournaee's definition) encompassing the original and the
For this scenario to take place, this would require that the metafeatures of a service, namely the metadata and metaservices, be a compatible superset of the metafeatures in the internal resources. Under this scenario a framework is required that allows exposing and passing on the platform power management feature all the way to the service consumer through the service supply chain regardless of the number of intermediaries. This capability allows service consumer to implement global power management policies regardless of who "owns" the equipment. The metadata passed through the supply chain includes not only platform data, but also APIs. The nature of the APIs is part of the pre-negotiation and metadata exchange itself, and can be in the form of low level APIs, such as the IPMI standard, or the high-level RESTful API provided by the Intel® Data Center Manager (DCM) middleware.
In this article we explored the concept of cloud service metadata and metadata exchange. Service metadata is information about a service itself, allowing service introspection. Metadata is essential for service consumer building a composite application to evaluate whether a given service offering from a provider matches the application's requirements. In the next article we'll see how metadata features for artifacts inside a service can be exposed across service boundaries.
 Ganesan Shankaranarayanan, Adir Even, "The Metadata Enigma," Comm. ACM, Vol. 49-2,
 J. Wang, P. Varman, C. Xie, "Middleware Enabled Data Sharing on Cloud Storage Services," Proc. ACM MW4SOC'10, Bangalore, November 29, 2010.
 Wikipedia, Metadata, Retrieved February 5, 2012 from http://en.wikipedia.org/wiki/Metadata.
 Dournaee, B., "Taking Control of the Cloud for your Enterprise," Intel Corporation white paper, 2010. Retrieved from http://info.intel.com/rs/ intel/images/Taking_Control_of_the_Cloud.pdf.
 Open Data Center Alliance Usage: Service Catalog, Open Data Center Alliance (2011)
 Kearney, K.T.; Torelli, F.; Kotsokalis, C.; "SLA: An abstract syntax for Service Level Agreements, Grid Computing (GRID)," 2010 11th IEEE/ ACM International Conference, pp. 217–224, 2010, http://www.sla4d- grid.de/sites/default/files/SLAWS_Grid-2010_SLAatSOI_Model.pdf
 Kennedy, J; Edmonds, A., Bayon, V., Cheevers, P. Lu, K., Stopar, M., Murn, D., "SLA-Enabled Infrastructure Management," Chapter 7 in Service Level Agreements for Cloud Computing, Springer, 2011.
 E. Castro-Leon, E., He, J., Chang, M., Peiravi, P., The Business Value of Virtual Service Oriented Grids, Chapter 2, Intel Press, 2008.
 Open Cloud Computing Interface, Retrieved February 20, 2012 from http://occi-wg.org/.
 Linthicum, D.S., Cloud Computing and SOA Convergence in Your Enterprise, A Step-by-Step Guide, Addison-Wesley, 2010.
 Schmidt, R., "Perspectives for Moving Business Processes into the Cloud," I. Bider et al. (Eds.), BPMDS 2010 and EMMSAD 2010, pp. 49–61, Springer-Verlag Berlin Heidelberg 2010.
 Schmidt, R., "A Service-System Based Identification of Meta-services for the Service-Oriented Enterprise Architecture," Proc. 15th IEEE Int. Enterprise Distributed Object Computing Conference,
 The W3C Incubator Activity. Retrieved February 20, 2012 from http://www.w3.org/2005/Incubator/usdl/.
 Wolf, C., "Security and Compliance in the Cloud," 2009.
 Wolf, C., "The Cloud Mystery Machine: Metadata Standards," 2010.
 "The Future Internet Core Platform." Retrieved February 20, 2012
 Verma, A., Venkataraman, S., Caesar, Campbell, R., "Efficient Metadata Management for Cloud Computing Applications," Technical Report, University of Illinois, 2010. Retrieved from https://www.ideals.illinois.edu/handle/2142/14820
 SLA@SOI Project Web Site in the European Union. Retrieved February 20, 2012 from http://www.sla-at-soi.eu.
 Foundations for SLA Management – Evaluated Framework, SCLA@ SOI Deliverable D.A5a, Retrieved February 20, 2012 from http://sla-at-soi.eu/wp-content/uploads/2011/08/D.A5a-M38-SLA-Foundations-and-Management.pdf.
 A Collection of Resources Relating to the SLA Model, SLA@SOI SourceForge Project Wiki. Retrieved February 20, 2012 from http://sourceforge.net/apps/trac/sla-at-soi/wiki/SlaModel.
 Coase, R. H., "The Nature of the Firm," Economica, Vol. 4 No. 16. (Nov. 1937), pp. 386-405.