Common Understanding Wiki

Common Understanding Wiki

A Common Knowledge Source of Terms and Definitions

FrontPage

Adapter Framework

Wiki: Tools

Adapter Framework

Goal: Unified Adapter Framework for SaaS for syntactical integration

Overview

Challenges

Cloud Service and Component Interoperability.

Flexible definition of BPaaS requires plug-and-play of identified Cloud services or Cloud application components. Hence, it must overcome vendor lock and consider interaction frameworks and implement adapters enabling the data exchange during an orchestration.

The Challenge is in developing interfaces and adapters to existing Cloud services for interoperability.

Execution Phase. First, common adapters and interfaces need to be established, second common data streams need to be applied, before the process Orchestrator can run workflows within a multi-Cloud environment, performing self-adaptive deployment and managing the BPaaS quality

Ambition

Heterogeneous Cloud capable BPaaS Execution Environment

Current SaaS Adapter frameworks only deal with service provisioning and single-sign on and do not aim to expose the specific behaviour of each such solution (e.g. managing customers in CRM, uploading documents in ECM, exporting Excel data in Office365). Furthermore financial management (e.g. metering, chargeback) and service-level agreements are concerns not typically approached in a unified and generic manner.

The CAMP (Cloud Application Management for Platforms) (CAMP 2012) Technical Committee aims at defining models, mechanisms and protocols for the management of applications in, and their use of, a PaaS environment. The focus of the TC is to develop an interoperable protocol for PaaS (self-service) management interfaces for cloud users to use in developing, deploying and the administration of their applications. The TC aims at defining interfaces for self-service provisioning, monitoring and control. CAMP is only a protocol specification; therefore it needs to be implemented by parties adopting the protocol.

The OASIS TOSCA (“Topology and Orchestration Specification for Cloud Applications”) (TOSCA 2012) Technical Committee aims at enhancing the portability of cloud applications and services. The main aim of TOSCA is to enable the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behaviour of these services, independently from the supplier creating the service, and any particular cloud provider or hosting technology. By increasing service and application portability in a vendor-neutral ecosystem, TOSCA aims at enabling portable deployment to any compliant cloud, smoother migration of existing applications to the cloud, as well as dynamic, multi-cloud provider applications.

Our proposal: A generic framework to adapt Cloud service solutions and provide a unified approach for service integration, delivery and composition. This framework will cover the entire lifecycle of such a product, from provisioning of tenants, users and applications, going through management of such entities and enriching these with product specific behaviours and operations abstracted in a generic way, all the while proving information about monitoring and metering events.\\

It will consist of a set of generic programming contracts and set of APIs, based on REST and JSON, easily extensible with metadata specific to each provider. These APIs will deal with use cases like: Single Sign On, Provisioning of Tenant, Users and Subscription, Metering, Monitoring and can be extended to implement SaaS provider specific use cases.

Three sets of APIs to be implemented:

  1. Provisioning and Management APIs: deals with Tenant, User, Application provisioning/deprovisioning and management.\\
  2. Monitoring and Metering APIs: in order to receive events, either correlated to the outbound request or uncorrelated related to metering and monitoring.
  3. Generic Functional APIs: will deal with abstracting the solution specific behaviours: create, read, update delete operations specific for each SaaS product.

Implementation

RESTFul Web Services

Functional

  1. Service Definition
  2. Service Discovery
  3. Service Security
  4. Service Policy (QoS)
  5. Service Management

Plugins

Standards

OData

http://www.odata.org/

An open protocol to allow the creation and consumption of queryable and interoperable RESTful APIs in a simple and standard way. OData (Open Data Protocol) is an OASIS standard that defines the best practice for building and consuming RESTful APIs.

OData RESTful APIs are easy to consume. The OData metadata, a machine-readable description of the data model of the APIs, enables the creation of powerful generic client proxies and tools. Some of them can help you interact with OData even without knowing anything about the protocol.

OData CSDL - Common Schema Definition Language

http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part3-csdl.html

OData services are described by an Entity Data Model (EDM). Common Schema Definition Language (CSDL) defines an XML-based representation of the entity model exposed by an OData service. An OData service SHOULD provide a CSDL description of its entity model when a client requests a description of the entity model by sending a GET request to /$metadata.

RESTdesc

http://restdesc.org/about/descriptions

Semantic descriptions for hypermedia APIs. Simply describe functionality. Functionality captures the essentials of APIs, and RESTdesc aims to describe this. Resources and their hyperlinks make up the cornerstones of descriptions.

Hydra - Hypermedia-Driven Web APIs

http://www.markus-lanthaler.com/hydra/

Hydra is an effort to simplify the development of interoperable, hypermedia-driven Web APIs. The two fundamental building blocks of Hydra are JSON‑LD and the Hydra Core Vocabulary.

JSON‑LD is the serialization format used in the communication between the server and its clients.

The Hydra Core Vocabulary represents the shared vocabulary between them. By specifying a number of concepts which are commonly used in Web APIs it can be used as the foundation to build Web services that share REST's benefits in terms of loose coupling, maintainability, evolvability, and scalability.

Furthermore it enables the creation of generic API clients instead of requiring specialized clients for every single API.

JSON-LD

http://json-ld.org/

JSON for Linking Data. JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale. Linked Data empowers people that publish and use information on the Web. It is a way to create a network of standards-based, machine-readable data across Web sites. Describes a method of publishing structured data so that it can be interlinked and become more useful through semantic queries.

LDP - Linked Data Platform

http://www.w3.org/TR/ldp/

Linked Data Platform (LDP) defines a set of rules for HTTP operations on web resources, some based on RDF, to provide an architecture for read-write Linked Data on the web.

RDF - Resource Description Framework

http://www.w3.org/RDF/

The Resource Description Framework (RDF) is a specifications originally designed as a metadata data model. It has come to be used as a general method for conceptual description or modeling of information that is implemented in web resources, using a variety of syntax notations and data serialization formats.

RDF is a standard model for data interchange on the Web. RDF has features that facilitate data merging even if the underlying schemas differ, and it specifically supports the evolution of schemas over time without requiring all the data consumers to be changed.

OWL - Web Ontology Language

http://www.w3.org/TR/owl2-overview/

Knowledge representation languages for authoring ontologies.

OWL 2 ontologies provide classes, properties, individuals, and data values and are stored as Semantic Web documents. OWL 2 ontologies can be used along with information written in RDF, and OWL 2 ontologies themselves are primarily exchanged as RDF documents.

RIF - Rule Interchange Format

http://www.w3.org/TR/2010/NOTE-rif-overview-20100622/

RIF focused on exchange rather than trying to develop a single one-fits-all rule language because, in contrast to other Semantic Web standards.

SPARQL - SPARQL Protocol and RDF Query Language

http://www.w3.org/TR/sparql11-overview/

A RDF query language, that is, a semantic query language for databases, able to retrieve and manipulate data stored in Resource Description Framework (RDF) format.

WADL - Web Application Description Language

https://wadl.java.net/

Machine-readable XML description of HTTP-based web applications (typically REST web services)


\\

0 附件
9102 查看
平均 (0 票)
评论
还没有评论。 发表第一个留言。