Review the GSoSD Arrowhead Core Systems 5.0 Draft

[emanuelpalm]

The Arrowhead community is admonished to read and review the latest GSoSD Arrowhead Core Systems 5.0 draft, available here:
https://github.com/eclipse-arrowhead/roadmap/tree/main/5.0%20Draft/GSoSD.

Please read the document and then create Issues with any comments you may have in this repository. Please start the titles of your issues with GSoSD Arrowhead Core Systems 5.0:. Alternatively, you may elect to post your comments in this issue.

[rbocsi]

• Core Systems and Support Systems: I agree with this notation. The old one, Mandatory Core Systems and Support Core Systems was sometimes confusing.
• With or Without Micro: I prefer the system/service alternative because it is shorter and we used them before. Maybe in the overview, we can emphasize that these system and service should have a narrow scope. But if we choose to go back the original usage, you have to remake the diagrams, because they are using the microsystems and microservices.

OK

• Authorisation: I prefer the old name Authorization. It is both valid, so why change?

Usage of policies is appreciated - do we have resources to implement in v5?

• 2.1.2: The description of authorization here is the old one. In Arrowhead 5.0, we prefer something much more flexible, based on policies, not the current peer-to-peer rules, because these are very inconvenient. (We talked about NGAC before). Who can create/update these policies is a good question. Administrator (sysop), of course. Some 'higher-level' support systems (Plant Description Engine, Workflow Choreographer)? I also think we should allow providers to create authorization policies about their services.

OK

• move the authorisation from the authorisation data base ID's

• 2.1.3: Here you just write about fix (peer-to-peer) store orchestration. We shouldn't discard the features that we already introduced: dynamic orchestration, flexible store orchestration (this can replace the fix store orchestration), matchmaking, provider reservation, etc. I agree with Emanuel that the current orchestration usage is confusing and complicated. But I think we can fix this, maybe with separating the orchestration to multiple operations, using better defaults, etc.

• 2.1.3 tokens: I don't think orchestration should store tokens, that is the job of the Authorization.

• 2.2: I do not really like these 'If only the Service Registry is used...', 'If also the Authorisation System is used...', etc. sentences. These suggests that the Authorization and Orchestration are NOT really mandatory systems (so NOT Core systems in the new notation). They are just recommended, at best. I think, every Arrowhead local cloud should contain these systems.

• 3.4: In this use-case, Orchestration should consult with Authorization about the results it got from the Service Registry. It makes no sense to return a provider to the requester that the requester can't use because of permissions.

• 4: 'Furthermore, once the system-of-systems have been established and no need for change is imminent, the control plane could even be removed or shut down.' I don't really understand this sentence. The previous use-cases can't work if we shut down the core systems (those are part of the control plane, right?). The providers wants to authorize all the time (by contacting Authorization), checking tokens (by contacting Authorization). The consumers may want reorchestrating because of changed circumstances or expired tokens (by contacting Orchestration).

• 7.1: 'As of Arrowhead version 4, security is managed by the Authorisation system'. It is not true. Authorization only works with permissions, authentication is using X.509 certificates.

• 7.1 Identity Provider (IP): If we want this system, it is definitely a core service. For X.509, the Cert authority can be this system. The problem with this that now every system has to know somehow where is the IP. Alternatively, system should ask Service Registry about the IP's service, but in this case we have to make an exception here: we need to allow that everybody (without identifying itself) can ask Service Registry about this specific service (and has permission to use it), because for using the service discovery the system needs to identify itself.

• 7.1. Tokens: Identity tokens and auth tokens are two separate things. The first one tells the provider who we are, the second tells provider that this consumer can use this service for a specified time.

• 7.2: I prefer the subscription approach. It makes possible for the consumer to express explicitly that it wants orchestration results continuously (when rules change) until further notice. Orchestration should store these requests to avoid problems if the system goes down and restart.

• 7.3: 'Systems/services or systems/services' This is about the micro- (see above) prefix. I suspect somebody use find all and replace operation to any microsystem to system and any microservice to service, which make this section very absurd.

[MatsBJohansson]

Page 1:

The title:
“Generic System-of-Systems Description (GSoSD) - The Arrowhead Core Systems” could perhaps be elaborated to better reflect the intension to be a “template” for specific SoSD’s at a basic Arrowhead level. Perhaps something like: “Generic System-of-Systems Description (GSoSD) – A template for design of basic Arrowhead System-of-Systems.”

Abstract:
Clarify that the purpose with the document includes to be a guide on how to design specific System of Systems based on the Arrowhead architecture. Including how application systems that need to exchange information via application services are intended to behave.

Section 1:

1. loose coupling, which means that services have narrow, well-defined application areas and depend internally on as few other services as possible to fulfil their functions,

• My view it that "loose coupling" includes that systems can easily be decoupled and a service consumer can change to consume a service from an other service provider that replaces the former, i.e. make a new "coupling". A bit unclear in the description.

2. late binding, which entails providing as much functionality as possible given what needed services, configuration data and other details are currently available, as well as

• My view is that "late binding" means that a service consumer can estabish a service consumption during runtime, as well as end it and establish a new.
• ", as well as" .... refers to point 3 ?? Propose to remove or clearify.

3. lookup, which means that systems, when possible, look up needed data by consuming services instead of relying on the data being in given configuration files.

• I miss "Publish". A system that provides a service should normally (mandatory?) make its service(s) known, to make it possible to "lookup".

Section 2.3, System-Service Matrix.
Gives a good overview and summary of section 2.1. And it clarifies the requirement to be able to implement and use separate systems that provide the services Service Discovery, Authorization and Orchestration Pull and Push independently.
Propose to remove columns for different implementation technologies and just have one column for each system.
Also propose to add example application systems and services aligned with the picture in section 1 and with section 3.
Don’t think we need the System-Service Matrix as an appendix, if the picture is made clearer with better contrast.

Section 8, References.
Propose to add referenses to SyS’s and SD’s for for systems and services addresses in the document.

[jerkerdelsing]

My comments to the Eclipse arrowhead Generic SoSD v5.0 document.
In general this GSoSD deviates too much from the v4.6 assumptions about the default properties provided by the architecture. This is not a good way forward. The default properties of 4.6 need to be kept. Degrading should be doable but not recommended. We should foster a more moderna, secure and future oriented thinking in the community!

I realise that many of my below comments are related to the above comment. Thus I limit Amy current review to a few sections of the current GSoSD v5.0 draft.

Sec 1

Terminology: SOA -> microservice architecture. An introductory explanation of the similarities between SOA and microservice architecture is necessary.

The local cloud definition should be more description and precise. Providing the objective and a conceptual description. The necessity for inter-local cloud service exchanges need to described.

Sec 2.
We should use microsystem and microservice instead of system and service this to distinguish us from all other "system" terminology.

A more precise definition of a microsystem is needed. The self contained capability need to be defined. See definition in the Arrowhead book.

Sec 2.1.1
A mechanism for finding the ServiceRegistry should be defined, e.g. periodically broadcast within the local cloud of ServiceRegistry address.
Individual should be mandated to register it's service with the local cloud ServiceRegistry (keep naming as before ServiceRegistry as one word with capital S and R).

Information about a microservice address, understood protocols, encodings, data models etc. need to be mandated.
A set of metadata should be recommended.

Registration time to live need to be defined.

Re-registration of services by the producing microsystem before x% of the end registration life need to be mandated.

Thus automated cleaning end of life microservice in the ServiceRegistry is a needed property.

Monitoring of registered microservice responsiveness: Can be mandated to the the ServiceRegistry or a separate Monitoring syport microsystem,

Sec 2.1.2
The usage of microservice consumer authentication and access control should be the default.
If relaxed security is preferred this is allow but not recommended.

Cashing strategies for security policies/rules should be more precisely described e.g. X number of usage, usage for a defined time period, but not limited to.

Sec 2.1.3

The description seams more like a v2 or maybe a v3 of Eclipse Arrowhead. Again the thinking of v4 need to reflected and any down grading should be allowed bu t not recommended!

Sec 2.2

We should continue to have the core microsystem as the basic starting point. Using one or two of the core microsystem need to be treated as special cases and can be described in e.g. appendix.

The booth-strapping description should reflect that v4 approach with the capabilities of the on-boarding procedure and associated support systems. Down grading should be allowed.

Sec 2.3

The service - system matrix should be replaced by SysML models of the core Microsystems showing actual implemented services and protocols and indicating potential protocols.

Sec 3 not considered so far.

Sec 4.
Need to be much more precise regarding the default control plane capability capability and the thereby reflected data plane execution. Extensions to the default capability with on-boarding, and other control plane functionality should be described to the ambition of v5.

[emanuelpalm]

@jerkerdelsing

My comments to the Eclipse arrowhead Generic SoSD v5.0 document.
In general this GSoSD deviates too much from the v4.6 assumptions about the default properties provided by the architecture. This is not a good way forward. The default properties of 4.6 need to be kept. Degrading should be doable but not recommended. We should foster a more moderna, secure and future oriented thinking in the community!

What do you mean by default properties and degrading? Are you saying that Arrowhead 5.0 must be backwards-compatible, or do you mean that we should not provide fewer features than Arrowhead 4.x? If it is the latter, I don't really see a significant risk of that. My own impression is that the features of Arrowhead 4.x are good. It is the way they are realized that can be improved upon quite a lot, in terms of how services are designed, how messages are sent, and so on. I thought that increasing the major version to 5 was meant to signal how backwards-compatibility with 4.x is not going to be a requirement.

I realise that many of my below comments are related to the above comment. Thus I limit Amy current review to a few sections of the current GSoSD v5.0 draft.

Sec 1

Terminology: SOA -> microservice architecture. An introductory explanation of the similarities between SOA and microservice architecture is necessary.

Yes, this has been voiced several times already. My impression is that most of us believe this should go into a separate document, however.

The local cloud definition should be more description and precise. Providing the objective and a conceptual description. The necessity for inter-local cloud service exchanges need to described.

We need to settle on an architectural definition of Arrowhead Local Cloud. I believe we can use the Arrowhead 4.x definition more or less as-is. There may be some less major details that need be discussed, such as what to call a local cloud that cannot connect to the Internet at all, and so on.

Sec 2.
We should use microsystem and microservice instead of system and service this to distinguish us from all other "system" terminology.

We have already discussed this quite a lot. I'm not commenting on it here.

A more precise definition of a microsystem is needed. The self contained capability need to be defined. See definition in the Arrowhead book.

This is a good point. We may need some kind of architectural definition of system in this document.

Sec 2.1.1
A mechanism for finding the ServiceRegistry should be defined, e.g. periodically broadcast within the local cloud of ServiceRegistry address.

If we decide to include this (which I would fully support), I would likely be apt to mention already in this document.

Individual should be mandated to register its service with the local cloud ServiceRegistry (keep naming as before ServiceRegistry as one word with capital S and R).

I agree that this is important, but should it go into the GSoSD? Should there be a Generic SysD for each of the Core/Support systems? (I've made a note about system naming in my summary.)

Information about a microservice address, understood protocols, encodings, data models etc. need to be mandated.
A set of metadata should be recommended.

Same as above.

Registration time to live need to be defined.

Same as above.

Re-registration of services by the producing microsystem before x% of the end registration life need to be mandated.

Same as above.

Thus automated cleaning end of life microservice in the ServiceRegistry is a needed property.

Same as above.

Monitoring of registered microservice responsiveness: Can be mandated to the the ServiceRegistry or a separate Monitoring syport microsystem,

I believe that monitoring should be handled, at least architecturally, as a separate system concern.

Sec 2.1.2
The usage of microservice consumer authentication and access control should be the default.
If relaxed security is preferred this is allow but not recommended.

Yes.

Cashing strategies for security policies/rules should be more precisely described e.g. X number of usage, usage for a defined time period, but not limited to.

Noted.

Sec 2.1.3

The description seams more like a v2 or maybe a v3 of Eclipse Arrowhead. Again the thinking of v4 need to reflected and any down grading should be allowed bu t not recommended!

The GSoSD is not complete and there is no plan, as far as I'm aware, to remove any features. That being said, the Orchestrator does many things today, and I believe we need to make it much more apparent why and when its different modes of operation are useful. My gut feeling is that we may have to separate it into two systems to land at a desirable level of separation of concerns.

Sec 2.2

We should continue to have the core microsystem as the basic starting point. Using one or two of the core microsystem need to be treated as special cases and can be described in e.g. appendix.

From a pedagogical standpoint it is convenient to consider them without each other. We could make it into an architectural requirement for all three of them to be present. We could even talk about things such as "Core Compliance" (all core systems used), "Partial Core Compliance" (at least on core systems used) and so on, in this document.

The booth-strapping description should reflect that v4 approach with the capabilities of the on-boarding procedure and associated support systems. Down grading should be allowed.

When writing this, we decided that bootstrapping and on-boarding are two different things, and that the latter should be addressed in the "Support Systems" document together with the On-Boarding Controller et al. Bootstrapping is the process through which a local cloud forms after a cold start, while on-boarding is the process through which an individual system joins a local cloud.

What do you mean by "downgrading"?

Sec 2.3

The service - system matrix should be replaced by SysML models of the core Microsystems showing actual implemented services and protocols and indicating potential protocols.

This is an interesting proposal. Could you be more specific regarding what details you think should be in the model?

Sec 3 not considered so far.

Sec 4.
Need to be much more precise regarding the default control plane capability capability and the thereby reflected data plane execution. Extensions to the default capability with on-boarding, and other control plane functionality should be described to the ambition of v5.

I agree that there is room for improvements to this section. I'm not sure it should be in this document at all. Perhaps we can resume this discussion when we know where the section goes?

[emanuelpalm]

This is my summary of all review comments I've found for this document. Some of them come from our internal discussions at Sinetiq and the rest of them are gathered from this GitHub project's issues. @jerkerdelsing @jenseliasson @palvarga @PerOlofsson-Sinetiq @henrikbylund @MatsBJohansson

Review Summary

General

1. "Microsystem" and "microservice" or "system" and "service"?
   • The illustrations contain the micro prefix before service and system, while the rest of the document has been updated to not use those prefixes.
   • The latter pair of terms are shorter, which is generally preferrable.
   • Adding the micro prefix means that plenty of old documents and illustrations would have to be changed.
2. Should the document bring up important engineering qualities, such as "operational independence" or "resilience"?
3. Authentication (as opposed to authorization) is currently not addressed by this document. It should, by most conceivable standards, be considered an important enough concern to be addressed together with the current Core Systems/Services of Arrowhead.
4. Can we assume that systems are either (1) "active" or (2) "passive", by which we mean that they either (1) actively make assumptions about what they should do and try to execute them or (2) wait until they receive instructions?
   • Depending on whether systems are active or passive, different design choices become relevant for the services of the core systems.
   • Should we have a document of "reference scenarios" where "active" and "passive" architectures are presented? Such a document could help us reason about the suitability of design choices for individual systems and services.
5. System and service identities and identifiers are never explained in detail.
6. What is, more exactly, the scope of this document?
   • Is the GSoSD a "SoSD Template", a generic description of what Arrowhead is, a guide to writing documentation, or an architectural reference?
     • Should these topics be addressed in separate documents? Which of them belongs in the GSoSD?
7. The new naming "Core Systems" and "Support Systems" is less confusing than the old "Mandatory Core System" and "Support Core System".
8. The document is to be written in American English, and this should be explicitly stated in the document.
9. Up until now, the convention have been to write System and Service names in PascalCase (each word starts with a capital letter and all words part of the name are written without spaces between them). Why detract from it?
   • [Emanuel Palm] Other than that having spaces between words make them slightly easier to read, there is no real reason. We can just as well stick with PascalCase. We should, however, write somewhere that this is the convention. Also, we need to clarify whether the words System and Service, respectively, should be part of the pascalization. Should it be "Authorization System" or "AuthorizationSystem", or perhaps even "Authorization system"?
10. There are no architectural definitions for "local cloud" or "system" in the document.
11. The idea of a service type identifier, or just service type, should be explained in this document.

Section 1. Overview

1. Service consumption and provision are not explained in enough detail.
   • Perhaps trying to motivate SOA is beyond the scope of the document? Should it be part of a separate "Assumptions Reference"?
2. Should being able to operate without Internet access be a requirement for a System-of-Systems to be a Local Cloud?
3. Can a given System be a member of more than one Local Cloud at the same time?
4. Loose coupling significantly entails being able to easily decouple and recouple systems. This should be mentioned explicitly.
5. Late binding is about being able to establish consumption patterns at runtime. What is mentioned are sensible behaviors that are enabled by that.
6. Looked up data needs to be published. This should be mentioned explicitly.
7. A separate document should exist that addresses the differences between Arrowhead and other concept domains, such as microservices architecture or old-style SOA (ESB, SOAP, etc.).
8. The Local Cloud description/definition needs to be more precise.

Section 2. Systems

1. Replace "are meant to address concerns expected to be typical to most settings where SOA is applied" with "are used to enable SOA characteristics such as Loosely coupled, Late binding and Lookup".
2. The term System needs to be defined more precisely, as well as be based on the definition in the book IoT Automation: Arrowahead Framework.

Section 2.1. System Descriptions

1. Replace "We now proceed to informally state the purposes and services of the Core systems" with "This chapter describes the purposes, concepts and capabilities of the Core systems."

Section 2.1.1. Service Registry

1. The phrase "The Service Registry holds a table that maps the identifiers of [...]" may make it seem as if a hash table must be used to hold the service registrations. Remove "holds a table that".
2. Make the purpose of the Service Registry appear earlier in the text and with more clarity. As in:
   • "The primary purpose of the Service Registry is to provide possibilities to register and lookup where to reach an endpoint for connectivity and enable information exchange. System can register their service producers, ie. the endpoint for other systems to reach for their producing information. Systems can discover producers that provides known (needed) information to enable interaction to feed its consumers. The System Registry relates endpoint with information sources of know and well-defined services/service contracts/interfaces by use of an identifier, called service-type."
3. There should be a conventional and automatic way for systems to find a service registry when they boot up or find themselves on a new network.
   • UDP/IP Multicasting is one approach.
   • Another is to assume that a certain IP address position from the beginning or end of the current subnet space will always hold the service registry (such as the second highest, like in 192.168.253/32).

Section 2.1.2 Authorization System

1. The phrase "The Authorisation System holds a table that maps the identifier of each system [...]" may make it seem as if a hash table must be used to hold the orchestration rules. Remove "holds a table that".
2. Could this system of consumer-to-provider rules, which is rather cumbersome to manage, be made more flexible through the use of NGAC or some other policy-based access control schema?
   • While it may be true that consumer-to-provider rules are hard to setup, and especially so when the numbers of consumers and providers are high, they are simple to handle from an implementation standpoint. Perhaps the dynamicity you seek through these policies could be realized through some kind of coordination or "authorization choreography" system?
3. Using authorization and other security mechanisms should be considered practically mandatory, or strongly recommended for Arrowhead local clouds.
4. Caching of authorization rules should be considered in more detail.
   • It is practically a requirement to use caching, so we may just as well consider it more thoroughly.

Section 2.1.3 Orchestration System

1. The phrase "The Orchestration System holds a table that maps each relevant system to [...]" may make it seem as if a hash table must be used to hold the orchestration rules. Remove "holds a table that".
2. Why would the Orchestration System hold access control tokens?
   • The Arrowhead 4.* implementation of the Orchestration system distributed access control tokens as part of its orchestration rules. After acquiring the tokens from the Authorization system, an implementation may or it may not store them, as a measure to improve performance by reducing message exchanges, before providing them its consumers. Perhaps a different strategy should be employed for distributing access tokens from the Authorization System?
3. Make the purpose of the Orchestration System appear earlier in the text and with more clarity. As in:
   • "The primarily purpose of the Orchestration System is to dynamically handle how to combine the services within the local cloud, ie. how to combine the Systems and their information exchange for the current purpose and need. The Orchestration System with its services enable late binding and seamless re-configuration of the system-of-system composition."
4. The new description is a rather dramatic reduction in scope of the version 4.* Orchestrator System, which also supports dynamic orchestration, flexible store orchestration, matchmaking, provider reservation, etc.
   • While the way in which those things are currently realized may be confusing, it does not necessarily have to mean that we need to remove them entirely. Refactoring the service or services of the Orchestration System may be enough.
5. Should the Orchestration System allow queries where service types are stated and service instance identifiers are returned?

Section 2 Local Cloud Bootstrapping

1. Are the core systems mandatory or recommended?
   • My current impression is that most contributors and stakeholders of the Arrowhead project are leaning towards them being recommended only. If this is in doubt we should have a discussion about it.

Section 2.3 The System-Service Matrix

1. Should this matrix be in this document? It can be a good way of mapping out what systems could communicate with each other, but this document is dedicated to too few systems for this to really become a benefit.
   • Arguments for having it is for example (A) the design-time availability to see existing possibilities of interactions. Another argument (B) is the ability to plan coming interactions and set the scene for new generations of s system-of-system.
   • Arguments against it is for example that it (a) fills no purpose in a run-time situation and that (b) it might get too large to give the visibility of the service landscape in a system-of-system. It would also (c) state current implementation details that should not be present in an architecture document.
2. Remove strictly technical (non-abstract/IDD) information?
3. Reduce scope and remove Appendix 1?

Section 3. Use-cases

1. Should this Section be presented as describing behavior that must be conformed to for a consumer or provider to be considered Arrowhead-compliant? The current phrasing is vague on the matter.

Section 3.2. Authorization

1. The diagram makes it seem as if the Authorization System must be consulted every time a service is consumed, which could produce a major performance bottleneck.
   • We wanted to make it clear that the Authorization System is responsible for holding all authorization rules. We figured that Section 6.1, which is about caching, would help people understand that there are ways of avoiding having to send the messages all the time. We could, of course, clarify that caching may be used in various ways to improve performance in this scenario.
2. Should the Authorization System be consulted when consuming the services of the Arrowhead Core Systems?
   • If the Service Registry depends on the Authorization System, it cannot be used independently of it.
   • One solution could be to make it configurable.

Section 3.3 Orchestration

1. The Orchestration System should not respond with addresses, but with service identifiers.
   • While this leads to services having to consult the Service Registry a lot more, it also means that the Orchestration System does not have to consult the Service Registry. In either case, systems must cache mappings between service identifiers and addresses. Not having the Orchestration System distribute addresses means that there is one less place where address lookup can go wrong.

Section 3.4 Authorization and Orchestration

1. In step 1.b.i, the Service Registry checks if the Orchestration System is authorized to request addresses. Those addresses are requested on behalf of an application system, which may not be permitted to have them.
   • This could be solved by:
     1. Making also the Orchestration System consult the Authorization System about the addresses, but this time to check if the application system is permitted to get them.
     2. Making the Orchestration System not look up addresses at all, but instead provide service instance identifiers to its consumers. Those consumers then have to look up the associated addresses in the Service Registry themselves.
        • This would simplify the Orchestration system and facilitate a clearer separation of concerns between it and the Service Registry. It would also avoid the extra message exchange introduced by alternative 1.

Section 4. Control and Data Planes

1. Does this section belong in this document? It is about how to diagram or model systems, not about architectural requirements.
2. "Furthermore, once the system-of-systems have been established and no need for change is imminent, the control plane could even be removed or shut down."
   • This needs to be clarified. None of the example scenarios in the document hint at the control plane systems being necessary only in some establishment phase. Under what conditions can the control plane systems be removed?

Section 6. Non-Functional Requirements

1. Does this section belong in this document? What is the scope of this document?

Section 7. Unresolved Issues

1. Is issues 1 and 2 outside the scope of this document?
2. The sentence in issue 1 "As of Arrowhead version 4, security is managed by the Authorisation system", is untrue, as also X.509-certificates, the Certificate Authority, the Gatekeeper/Gateway and the Onboarding Controller also provide security.
3. The Certificate Authority could be modified to act as an "Identity Provider System" when identifies are issued in the form of X.509-certificates.
4. Issuing identities and issuing tokens are two distinct activities, as identities and tokens are used for different things.
   • The former proves who you are, while the latter proves that you are permitted to do something.
   • Having both an Identity Provider and a Token Provider system could, as a consequence, be relevant.
5. How independent do we want systems to be? (see also General, Point 4)
   • An independent system should be responsible for it getting orchestration/choreography data, via polling, subscriptions or otherwise. My impression is currently that most contributors and stakeholders lean towards this option.
   • A dependent system should, on the other hand, wait for some other system to take initiative with regards to it receiving orchestration/choreography data.
6. Issue 3 has been rendered obsolete by the removal of the "micro"-prefixes from the document. It should be removed.

Section 8. References

1. Where are the references? Even though the documents are not finished yet, there is still value in being able to think about what this section should look like.
   • References to SysDs, SoSDs, SDs?

[emanuelpalm]

@jerkerdelsing @jenseliasson @palvarga @PerOlofsson-Sinetiq @henrikbylund @MatsBJohansson

As you all can see, this document sparked quite a lot of discussion. I'm of the opinion that before we continue addressing the concerns that have been raised about it, we first agree on a plan for what reference documents this GSoSD should be split up into and complemented with.

We could chose to follow ISO 42010. It would require that someone more familiar with the standard guides us through it. @henrikbylund? Another thought is to follow the reasoning on the roadmap meeting where we discussed the Concepts Reference and create the "Assumptions", "Values" and "Practices" documents mentioned there.

[emanuelpalm]

Review Reaction Plan

It is my opinion that most points in the review summary above can be fixed without further discussion within the Arrowhead community. I believe @PerOlofsson-Sinetiq and myself can see to that those points until the next release of the GSoSD.

Which are the points that cannot be trivially fixed withou further discussion? I believe they are as follows:

The following plan has been ratified by the project:

1. Should Eclipse Arrowhead Core and Support systems be designed to be proactive (actively try to fulfill their intended functions) or reactive (passively wait for instructions to be received)? Do we need to choose?
   • Lead: Per Olofsson, Sinetiq
2. What "specification documents" should exist apart from the GSoSD, the Concepts Reference and the Foundational Principles documents? What is the scope of each document?
   • Lead: Pal Varga, BME
3. How do we name clouds, systems, services, operations, devices and other components? Should there be both human-readable names and machine-readable names, or can one type of name be used for both?
   • Lead: Cristina Paniagua, LTU
4. How do we name the Orchestration System (Core) and the Choreography System (Support) such that we avoid unneccessary confusion from the Microservices communities? [1] [2] Is renaming them necessary?
   • Lead: Felix Laringa, University of Mondragon
5. Should all current kinds of orchestration be supported by the same one orchestration system?
   • Lead: Jerker Delsing, LTU
6. Should an "Authentication System" be part of the Core or Support systems of Eclipse Arrowhead? What should its name be? Should it support OpenID? SAML 2.0? LDAP? Does it have its own self-managed database of users/systems?
   • Lead: Per Olofsson, Sinetiq
7. What authorization mechanisms should be supported by the Authorization System? OAuth 2.0? OpenID Connect (together with the "Authentication System")?
   • Lead: Olof Schelén, LTU
8. What terms to use for Services and Systems? Microservices and microsystems?
   • Lead: Jerker Delsing, LTU
9. Does each individual Core system have to be useful on its own, or can they depend on each other directly?
   • Lead: Rajmund Bocsi, AITIA
10. What kind of backwards compatibility should Arrowhead version 5.0 offer with regards to version 4.*? Interface compatibility? Documentation format compatibility?
    • Lead: Jan van Deventer, LTU

I consider the following to be ratified and to need no further discussion:

1. We will use the terms Service and System, and not Microservice or Microsystem.
2. American English will be used in all documents produced by the Eclipse Arrowhead project.
3. Using all the Core systems is highly recommended for the vast majority of deployments where Arrowhead systems are used, and is mandatory if wanting to refer to a deployment as an Arrowhead Local Cloud or Arrowhead Cloud. As a consequence, each individual Core system must be useful on its own.

[rbocsi]

As a consequence, each individual Core system must be useful on its own.

I disagree with this. The orchestrator can't do any useful things without an existing Service Registry.

[emanuelpalm]

As a consequence, each individual Core system must be useful on its own.

I disagree with this. The orchestrator can't do any useful things without an existing Service Registry.

By "be[ing] useful on its own", I'm not saying that the orchestrator has to work without a service registry, just that it should not depend on there being any particular type of service registry. This means that you should be able to use a regular DNS server as service registry, if you wanted to.

[rbocsi]

The orchestrator can work with any SR as long as that SR implements the ServiceDiscovery SD and provide that on an interface (which is documented in an IDD) that the orchestrator understands.

[emanuelpalm]

The outcome of this discussion is continuing in #63. I'm closing this issue.