Internet DRAFT - draft-algermissen-software-system-life-cycle-model

draft-algermissen-software-system-life-cycle-model







Network Working Group                                     J. Algermissen
Internet-Draft                     Jan Algermissen Solutions Engineering
Intended status: Informational                         February 20, 2019
Expires: August 24, 2019


                    Software System Life Cycle Model
         draft-algermissen-software-system-life-cycle-model-00

Abstract

   This specification defines an abstract model for software systems and
   their relationships with each other in order to establish a basic
   abstraction on which the lifecycle of software systems and
   collaborations around them can be expressed.  In addition, this
   specification defines a number of message formats and hypermedia
   controls, to enable the creation of tools and application in the
   space of software systems life cycle management.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 24, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Algermissen              Expires August 24, 2019                [Page 1]

Internet-DraftA model for software system life cycle manageFebruary 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Services  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Execution Environment Types . . . . . . . . . . . . . . . . .   4
   4.  Basic System Model  . . . . . . . . . . . . . . . . . . . . .   5
   5.  The System JSON Object  . . . . . . . . . . . . . . . . . . .   7
   6.  Stage Sets  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  The Stage Set JSON Object . . . . . . . . . . . . . . . . . .   8
   8.  Well Defined Execution Environment Variables  . . . . . . . .   9
   9.  Example Implementations . . . . . . . . . . . . . . . . . . .   9
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  12
   Appendix B.  Implementation Notes . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   A wide variety of applications exists that support the journey of
   developers and other collaborators around the lifecycle of software
   systems.

   The aim of this specification is to facilitate integration options
   between such tools and applications by providing a common abstraction
   and coordination protocols.

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Services

   The Software System Life Cycle Model aims to facilitate the
   integration into existing Internet technology and thus uses existing
   specified semantics whenever possible.

   One of such integration points is the notion of _Service_, which
   refers to an abstract capability associated with an interaction
   protocol expectation.  This specification uses the term _Service_ in



Algermissen              Expires August 24, 2019                [Page 2]

Internet-DraftA model for software system life cycle manageFebruary 2019


   the exact same sense as it is used by the various specifications
   available through the IETF.

   Some relevant specifications are [RFC3232].  [RFC2782], [RFC6763].

   On the one hand services are used by capability providing software
   systems to advertise that they meet the contract associated with a
   given service name, or in other words, that the providing system
   meets the expectations of consuming systems of a given service.  On
   the other hand, services are used by consuming systems to express
   that they have certain protocol and capability expectations when
   interacting with a providing system.

   While services in most existing specifications are rather protocol
   focussed, the service notion seamlessly supports referring to
   capabilities that exist in more functional areas.  The following
   examples show services that illustrate the notion of _servciew_ as
   understood by this specification:

   'search', 'suggest', 'basket', 'ftp', 'postgres', 'smtp', 'http',
   'aws-dynamo', 'gcp-pubsub', 'google-maps',...

2.1.  Service Names

   Service names MUST conform to the syntax requirements stated in
   [RFC1034], meaning that service names MUST only consist of ASCII
   letters, digits, and hyphens and that they MUST NOT be longer than 15
   characters.

   Service names are case insensitive.

   TBD: Differentiate between standardized global services and context-
   based services

2.2.  Port Numbers

   Services MAY be assigned a port number, see [RFC3232] and
   https://www.iana.org/assignments/port-numbers

2.3.  Service Catalog

   In order to express dependencies of a system on one or more services,
   the list of services available in a given context must be known.
   Systems that have the ability to manage dependencies SHOULD expose
   service catalogs that list the available services.






Algermissen              Expires August 24, 2019                [Page 3]

Internet-DraftA model for software system life cycle manageFebruary 2019


2.4.  Service List Documents

   The canonical model for a System document is a JSON [RFC8259] object.

   When serialized as a JSON document, that format is identified with
   the "application/vnd.ply.servicelist+json" media type.

2.4.1.  Example

   {
     "services" : [
       {
         "name" : "",
         "description" : "...",
         "docs" : [ "" , "" ]
       },
       {
         "name" : "",
         "description" : "...",
         "docs" : [ "" , "" ]
       }
    ]
   }


2.5.  The service-catalog Link Relation Type

   Links with the link relation type 'service-catalog' indicate that the
   target resource represents a service catalog.

3.  Execution Environment Types

   Common to all software systems is the differentiation between
   something being developed and actually running it in a given context.
   The things being develop are inherently bound to the target type of
   execution environment.  This specification defines the notion of
   _Execution Environment Type_ in order to capture this property of
   developed software items.  An Execution Environment is anyting into
   which a developed software can be deployed to realize its
   capabilities in a given runtime environment.

   Examples of Execution Environment Types are the usual environments
   such as "Linux Operating System", "Docker", "AWS Lambda", "Java
   Application Server", "Oracle PL/SQL", but other possible runnable
   artefacts and Execution Environment Types are "Single Page
   Applications deployed to a CDN", "The configuration of an integration
   proxy", "A native mobile app deployed on a mobile phone".




Algermissen              Expires August 24, 2019                [Page 4]

Internet-DraftA model for software system life cycle manageFebruary 2019


3.1.  Execution Environment Type Definitions

   TBD

3.2.  Execution Environment Variables

   TBD

3.3.  Execution Environment Type Catalog

   Systems that support the deployment of software artifacts SHOULD
   provide an execution evironment type catalog to inform client systems
   about the supported execution environments.

3.4.  The 'execenv-catalog' Link Relation Type

   Links with the link relation type 'execenv-catalog' indicate that the
   target resource represents an execution environment type catalog.

4.  Basic System Model

   A software system is understood to consist of components.  Components
   can have dependencies on services.  Services are either backing
   systems like databases or they are external services, such as a
   search API, a backend IT system, or another system in the sense of
   'system' used here.

   Components can share dependencies that are specific to a system, but
   no two systems may share the same service instances.






















Algermissen              Expires August 24, 2019                [Page 5]

Internet-DraftA model for software system life cycle manageFebruary 2019


       +-----------------------------------+
       |              System               |
       |              ~~~~~~               |
       |              -name                |
       |                                   |
       |  +-----------+     +-----------+  |                +-------+
       |  | Component |     | Component +--+-- implements ->|Service|
       |  | ~~~~~~~~~ |     | ~~~~~~~~~ |  |                +-------+
       |  | -name     |     | -name     |  |
       |  | -type     |     | -type     |  |
       |  +----+-+----+     +-----+-----+  |
       |       | |                |        |
       |       | +----------------+        |
       |       |                  |        |
       |       V                  V        |
       |  +----------+       +----------+  |
       |  |Dependency|       |Dependency|  |
       |  |-name     |       |-name     |  |
       |  +-----+----+       +----+-----+  |
       |        |                 |        |
       +--------+-----------------+--------+
                |                 |
                V                 V
            +-------+         +-------+
            |Service|         |Service|
            +-------+         +-------+


4.1.  System

   TBD

4.1.1.  System Name Attribute

   System objects MUST exhibit a "name" property with a string literal
   value which conforms to the syntax requirements for DNS labels.  The
   labels must follow the rules for ARPANET host names.  They must start
   with a letter, end with a letter or digit, and have as interior
   characters only letters, digits, and hyphen.  There are also some
   restrictions on the length.  Labels must be 63 characters or less
   ([RFC2181]).

4.2.  Component








Algermissen              Expires August 24, 2019                [Page 6]

Internet-DraftA model for software system life cycle manageFebruary 2019


4.2.1.  Component Name Attribute

   Component objects MUST exhibit a "name" property with a string
   literal value which conforms to the syntax requirements for DNS
   labels.  The labels must follow the rules for ARPANET host names.
   They must start with a letter, end with a letter or digit, and have
   as interior characters only letters, digits, and hyphen.  There are
   also some restrictions on the length.  Labels must be 63 characters
   or less ([RFC2181]).

4.2.2.  Component Type Attribute

   Components have an Execution Environment Type indicated by the 'type'
   attribute.

4.3.  Dependency

   TBD

   Dependencies are named to differentiate between them.  This makes it
   possible for a system to exhibit one or more dependencies on the same
   service.

4.4.  Service Implementation

   When systems expose capabilities for use by other systems, they must
   expose them in order for other systems to consume them as
   dependencies.

5.  The System JSON Object

   The canonical model for a System document is a JSON [RFC8259] object.

   When serialized as a JSON document, that format is identified with
   the "application/vnd.ply.system+json" media type.

5.1.  A YAML-formatted example of a system model














Algermissen              Expires August 24, 2019                [Page 7]

Internet-DraftA model for software system life cycle manageFebruary 2019


   name: search
   dependencies:
     - name: index
       service: solr
     - name: config
       service: postgres
   components:
     - name: importer
       dependencies: ["index","config"]
     - name: searcher
       dependencies: ["index"]
       implements: ["opensearch","my-suggest"]



6.  Stage Sets

   TBD

7.  The Stage Set JSON Object

   The canonical model for a Stage Set document is a JSON [RFC8259]
   object.

   When serialized as a JSON document, that format is identified with
   the "application/vnd.ply.stageset+json" media type.

7.1.  A YAML-formatted example of a stage set model

   name: myset
   systemref: http://foo.bar.myssystem.example
   budget: '66474-gghk-88733/00'
   stages:
     - name: dev
       criticality: work
       dependencyInstances:
         - name: mydb
           parameters:
             - name: foo
               value: bar
       componentDeployments:
         - name: searcher
           artifact: myrepo.example.com/images/foo:1
           dns: www.example.org
     - name: prod
     ...





Algermissen              Expires August 24, 2019                [Page 8]

Internet-DraftA model for software system life cycle manageFebruary 2019


8.  Well Defined Execution Environment Variables

   TBD Define the list of common environment variables for execution
   environments

   o  PLY_LOC_STAGE

   o  PLY_LOC_REGION

   o  PLY_LOC_SYSTEM

   o  ...

9.  Example Implementations

   TBD: Consider describing some areas of application of ply, such as
   writing a call center user agent for a an origin server.

10.  Security Considerations

   TBD

11.  IANA Considerations

   This specification defines two new Internet media types [RFC6838].

11.1.  application/vnd.ply.system+json

   o  Type name: application

   o  Subtype name: vnd.ply.system+json

   o  Required parameters: None

   o  Optional parameters: None; unrecognized parameters should be
      ignored

   o  Encoding considerations: Same as [RFC8259]

   o  Security considerations: see Section 5 of this document

   o  Interoperability considerations: None

   o  Published specification: TBD (this document)

   o  Applications that use this media type: HTTP





Algermissen              Expires August 24, 2019                [Page 9]

Internet-DraftA model for software system life cycle manageFebruary 2019


   o  Fragment identifier considerations: Same as for application/json
      ([RFC8259])

   o  Additional information:

   o  Deprecated alias names for this type: n/a

      *  Magic number(s): n/a

      *  File extension(s): n/a

      *  Macintosh file type code(s): n/a

   o  Person and email address to contact for further information: Jan
      Algermissen algermissen@acm.org [1]

   o  Intended usage: COMMON

   o  Restrictions on usage: None.

   o  Author: Jan Algermissen algermissen@acm.org [2]

   o  Change controller: IESG

11.2.  application/vnd.ply.system+yaml

   TBD

12.  References

12.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
              <https://www.rfc-editor.org/info/rfc2181>.

   [RFC3232]  Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
              by an On-line Database", RFC 3232, DOI 10.17487/RFC3232,
              January 2002, <https://www.rfc-editor.org/info/rfc3232>.



Algermissen              Expires August 24, 2019               [Page 10]

Internet-DraftA model for software system life cycle manageFebruary 2019


   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/info/rfc6838>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

12.2.  Informative References

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,
              <https://www.rfc-editor.org/info/rfc2782>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

12.3.  URIs

   [1] mailto:algermissen@acm.org

   [2] mailto:algermissen@acm.org





















Algermissen              Expires August 24, 2019               [Page 11]

Internet-DraftA model for software system life cycle manageFebruary 2019


Appendix A.  Acknowledgements

   Thanks to TBD for their comments.

Appendix B.  Implementation Notes

   TBD

Author's Address

   Jan Algermissen
   Jan Algermissen Solutions Engineering

   EMail: algermissen@acm.org
   URI:   http://algermissen.io




































Algermissen              Expires August 24, 2019               [Page 12]