Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Spec
    • Labels:
      None
    • Proposal:
      Hide

      Paul recommended to start a new issue that is focussed on environment dependencies. This new issue is the result of Paul's request.

      Show
      Paul recommended to start a new issue that is focussed on environment dependencies. This new issue is the result of Paul's request.
    • Resolution:
      Hide

      This issue provides the context and scope of the discussion of environment dependencies of plans. I extend the scope of this issue to include the impact of environment on operations.

      Show
      This issue provides the context and scope of the discussion of environment dependencies of plans. I extend the scope of this issue to include the impact of environment on operations.

      Description

      We started a discussion on dependencies of plans on the target environment of cloud services. This discussion was held in the context of TOSCA Issue 4. But TOSCA Issue 4 is more focused on fixing a problem with interface definitions.

      The main purpose of this issue is to discuss conceptual and architectural aspects on environment dependencies of plans and operations, as well as the relation of plans and operations.

        Attachments

          Activity

          Hide
          lippa02 Paul Lipton (Inactive) added a comment -
          Show
          lippa02 Paul Lipton (Inactive) added a comment - TC approves closing this issue without further action on 9/6 (see https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/46841/TOSCA%20TC%20Minutes%202012-09-06.docx ).
          Hide
          lippa02 Paul Lipton (Inactive) added a comment -

          As you know, specifications in standards are about improving interoperability. That will often involve constraining choice, rather than expanding it or listing it, as long as you can find consensus in the TC. Will you be proposing specific text changes to the spec or text/images for a primer, e.g., BPMN as a SHOULD or a MUST?

          If this discussion is also evolving towards a "base set" of operations, properties, and maybe a small number of nodes, should this discussion not be informed by one or more use cases? See TOSCA-8, which suggests but does not yet provide some use cases. I have also uploaded a use case template, which folks could use to get things rolling.

          Show
          lippa02 Paul Lipton (Inactive) added a comment - As you know, specifications in standards are about improving interoperability. That will often involve constraining choice, rather than expanding it or listing it, as long as you can find consensus in the TC. Will you be proposing specific text changes to the spec or text/images for a primer, e.g., BPMN as a SHOULD or a MUST? If this discussion is also evolving towards a "base set" of operations, properties, and maybe a small number of nodes, should this discussion not be informed by one or more use cases? See TOSCA-8 , which suggests but does not yet provide some use cases. I have also uploaded a use case template, which folks could use to get things rolling.
          Hide
          leymann Frank Leymann (Inactive) added a comment -

          I am absolutely fine with specifying in TOSCA that BPMN 2.0 is the default language for defining plans.

          Wrt "artifacts", we need be more specific.

          We define "implementation artifacts" as the "executables" realizing operations. The spec lists potential types of operations, i.e. WSDL port type operations, REST interfaces, and scripts. WSDL port types are often implemented as servlets but also as EJBs (in addition to corresponding Windows components). Thus, we should add EARs to Derek's list. REST interfaces are often realized as servlets, i.e. from a Java perspective JAR files or WAR files should be fine. The list of script languages is fine with me, but I need to delegate the list of scripts to others (this is not my skill area).

          We define "deployment artifacts" as the "executables" realizing node types/templates. When a node type/template represents infrastructure, i.e. OS or middleware (DBMS, App Server,...) assuming images is fine. The list of VM image formats to be supported needs to be discussed. Also, we need to include AMIs (or references to them) because of their frequent use. But if we move from infrastructure up towards the implementation, we need to support artifacts that represent service- and process-oriented applications. Thus, the artifact types include WSDL files, BPEL- and BPMN files, EAR/JAR files (implementing the WSDL port types) and so on.

          Summary: The list is an excellent base, but we should consider to extend it in order to reflect applications that are often (expected to be) run in a cloud environment.

          Show
          leymann Frank Leymann (Inactive) added a comment - I am absolutely fine with specifying in TOSCA that BPMN 2.0 is the default language for defining plans. Wrt "artifacts", we need be more specific. We define "implementation artifacts" as the "executables" realizing operations. The spec lists potential types of operations, i.e. WSDL port type operations, REST interfaces, and scripts. WSDL port types are often implemented as servlets but also as EJBs (in addition to corresponding Windows components). Thus, we should add EARs to Derek's list. REST interfaces are often realized as servlets, i.e. from a Java perspective JAR files or WAR files should be fine. The list of script languages is fine with me, but I need to delegate the list of scripts to others (this is not my skill area). We define "deployment artifacts" as the "executables" realizing node types/templates. When a node type/template represents infrastructure, i.e. OS or middleware (DBMS, App Server,...) assuming images is fine. The list of VM image formats to be supported needs to be discussed. Also, we need to include AMIs (or references to them) because of their frequent use. But if we move from infrastructure up towards the implementation, we need to support artifacts that represent service- and process-oriented applications. Thus, the artifact types include WSDL files, BPEL- and BPMN files, EAR/JAR files (implementing the WSDL port types) and so on. Summary: The list is an excellent base, but we should consider to extend it in order to reflect applications that are often (expected to be) run in a cloud environment.
          Hide
          dpalma Derek Palma (Inactive) added a comment -

          Can we address Frank's Ad 2 and select the process model and smallest set of implementation artifacts that MUST be supported by a compliant implementation so we can generate real TOSCA compliant plans? This will support additional concrete questions.

          Here is a proposal to keep it representative but simple:

          Process Model:
          BPMN

          Implementation Artifacts:
          WAR (simpler than EAR)
          VMImage (OVF, RAW (versus all possible))
          Scripts (SH, PowerScript, Perl, Python)

          Show
          dpalma Derek Palma (Inactive) added a comment - Can we address Frank's Ad 2 and select the process model and smallest set of implementation artifacts that MUST be supported by a compliant implementation so we can generate real TOSCA compliant plans? This will support additional concrete questions. Here is a proposal to keep it representative but simple: Process Model: BPMN Implementation Artifacts: WAR (simpler than EAR) VMImage (OVF, RAW (versus all possible)) Scripts (SH, PowerScript, Perl, Python)
          Hide
          lippa02 Paul Lipton (Inactive) added a comment -

          Does this discussion need text in the spec or in a primer? If so, please provide text for review. Otherwise, we should close this issue.

          Show
          lippa02 Paul Lipton (Inactive) added a comment - Does this discussion need text in the spec or in a primer? If so, please provide text for review. Otherwise, we should close this issue.

            People

            • Assignee:
              leymann Frank Leymann (Inactive)
              Reporter:
              leymann Frank Leymann (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: