[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Created: (TOSCA-13) Clarify value of TOSCA "portability" and "interoperability"
Clarify value of TOSCA "portability" and "interoperability" ------------------------------------------------------------ Key: TOSCA-13 URL: http://tools.oasis-open.org/issues/browse/TOSCA-13 Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC Issue Type: Improvement Reporter: Dale Moberg Priority: Minor WD-4 says "The advent of cloud computing suggests the utility of standards that enable the (semi-) automatic creation and management of services (a.k.a. service automation). These standards describe a service and how to manage it independent of the supplier creating the service and independent of any particular cloud provider and the technology hosting the service. Making service topologies (i.e. the individual components of a service and their relations) and their orchestration plans (i.e. the management procedures to create and modify a service) interoperable artifacts, enables their exchange between different environments. This specification explains how to define services in a portable and interoperable manner in a Service Template document." Is the reader to think that by making topologies and orchestration plans "interoperable artifacts" that can be exchanged that portability and interoperability are thereby achieved? Why would that "serialization" necessarily lead to services that are portable and interoperable? Is service interoperability equivalent to saying that any service consumer can interchangeably use the ported services? How is service automation thought to be enabled, and how is service automation important for portability, interoperability (or both) of the created and managed services? The current introduction is too dense to convey an unambiguous conception of how all the elements are asserted to cohere and achieve their supposed advantages. Managed and managing services need to be distinguished. Portability and interoperability for each of these types of service (if TOSCA yields advantages for both kinds of service) need to be explicitly defined and related to TOSCA model components, and to the sub-artifacts (WSDL, packaging, BPMN 2, BPEL, etc). What does TOSCA do and how is value over and above the imported/referenced sub-artifacts generated? If this is too long for an introduction, a clear list of the advantages should be made at the outset (enumeration of the points to be made) and later explicit indications that show how these points have been established. Ideally these points should connect with a set of conformance clauses asserting what an application must do to make use of TOSCA to achieve the enumerated advantages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira