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]
