ServiceRegistry vs SystemRegistry #21
Comments
|
This is the current DB model: |
|
@borditamas I agree about the overlap between the registries being a concern. They are too interrelated for it to make sense to have them be different systems. I would like to see a single system take on responsibility for device, system and service registrations. Furthermore, I would either like to see all on-boarding functionality be taken away from this registry and be moved to the Onboarding Controller (as @borditamas suggested), or I would like the Onboarding Controller to be merged with this new system. If we want our registry system to only hold registrations (i.e. be a plain database), then it should have nothing to with on-boarding. If we see on-boarding as an essential concern, then it should be built-in (I don't really see why it would be, so I guess this is the less desirable alternative). |
|
Exactly my thoughts on this topic, one system should be responsible for all registrations. |
|
@mzsilak What do you think about this? |
|
The naming convention by Cristina and me gave us a way of relating LocalClouds, Devices, Systems, and Services. Having separate systems for Device, System and Service registration supports the idea of micro-systems and micro-services. |
|
For your reference, this is the convention of Cristina. @jerkerdelsing If we would have used her naming convention and built the service registry on top of BIND (or some other DNS database), there would be one database/system keeping track of all registries anyway. The difference would have been that the database is hierarchical and eventually consistent, which is something we could emulate for our own registry implementations if we want. @jerkerdelsing How do we know a system or service is "micro" enough . As far as I know, there is no precise definition we can rely on. What I believe we are suggesting here is that the definition of a "micro" system or service is such that provides a smaller set of functionality that can be provided with some degree of independence (i.e. the classical "separation of concerns"). As @borditamas pointed out, the service registry is almost embarrassingly dependent on the system registry. Unless the service registry maintains its own copy of the system registry entries, it is going to cease to function as soon as the system registry goes offline. Furthermore, we are going introduce more system-of-systems latency by having to send more messages than would have been the case if the two registries were maintained by the same system, which, among other things, makes maintaining registry integrity more challenging. Rather than ensuring that the registry system remains minimal by keeping data out, we suggest that we instead should keep on-boarding out. I other words, the new "registry system" should store data and do nothing else. It is a plain database. |
emanuelpalm
added
Core System: Device Registry
|
@borditamas We discussed this during the Roadmap WG call today. Were you on it? This question is being lead by @vanDeventer, which is responsible for a Roadmap WG subgroup on the issue. The gist of our discussion is that most members favor the device, system and service registries being distinct systems. That being said, whether or not they share database behind the scenes is up to whoever is implementing the systems. @vanDeventer is tasked with making proposals for new device, system and service registry system specifications. |
|
@emanuelpalm Yes I was there. Personally I'm not convinced but primariIy I think arrowhead should cover the widest range of needs as much as possible. Why I'm still on the side of having these as one system is rather coming from the application developer perspective than to avoid the data management difficulties within the FW. For example (based on the current implementation): Why should an application system implement different interfaces to register first the system than the service and optionally the device, when there is no service without system at least? We should strive for impose the less requirement towards to the application systems. Of course when there is only one entry point for "registry" than it is irrelevant that how many core system will share on the input, but if the community would prefer one entry point against three, then I still see safer and more efficient to process the whole input in place. |
|
@borditamas I agree that many, if not most, use cases would benefit most from having a given system register itself, and all of its service, with only one message. In fact, I believe that in many cases would benefit from registering some devices with all of their systems and all of their services with a single message. A separation of these systems does not have to make that impossible, however. We could simply define a fourth system that exposes a service that only receives that message. The implementation of that fourth system could either send messages to the conventional registries, or store the data to the same database as the other systems are using, which would make all of the data available immediately in all registries. That poses the question, however, why that register-everything service would have to be hosted by a dedicated system? Couldn't a single system host all of the services, both the old and the one I proposed here? You are not forced to have a given system actually provide all of its services, just as you are not forced to host any particular system. To be honest, I don't know the answer. Is that something you have thought about, @vanDeventer? |
|
Oh, wait. I just realized that having them hosted by separate systems gives you the option of actually running them on different devices, which is something you cannot do with only services. |
|
Correct me if I'm wrong, but currently the services we are talking about are nothing else than writing into and reading from a database. Really don't understand what is the advatage of running a complete webserver per database entity. (Unless we still want SytemRegistry to dealing with the Onboarding stuffs what I also see as not the best approach). Furthermore, these entities are in unavoidable relation with each other. |
|
Yes, that is all they do, after performing some certificate checks and so on. You don't have to use a conventional database, however. You could store things in RAM, write them to disk, and so on. The point of the system services being so simple is that it becomes very straightforward to implement them. In the end, we want to have many different implementations of these systems that cater to different kinds of needs and scenarios. You don't have to run a complete webserver per system. You could have a single webserver provide all of the systems from the same Java process. As long as each system has its own certificate it does not matter how it is implemented (given that it satisfies whatever non-functional requirements are relevant, such as performance or security). I understand that changing the AITIA implementations to work like this would not be easy, but my understanding is that this discussion is not being made with any particular implementation in mind (at least by us not part of AITIA). I completely agree about that the registries should not be directly involved in the on-boarding procedure. As far as I know, the only information that should be shared between these systems are the details about the device interface (IP address or DNS name) and system interface (port and public key). Device information such as make, brand, manufacturing year, and so on, are not known by the other registries. System information such as what java version is used (if at all), what dynamic libraries are linked, and so on, are not known by the other registries. |
I think the same.
I thought, that when we are talking about core systems (or providers), than the networking capability and its functionalities (services) together makes them being a standalone system. Because without the networking capability the services are not working. But according to your description only the functionalities (services) makes a system being an arrowhead system by defintiton. It makes sense for me, however I see it a bit confusing from practicular aspects. |
The ability to send messages over a network is an essential attribute of a system, just as you are saying. I'm not claiming otherwise. Clumping them together into a single application does not remove this attrbute, however. From the perspective of all systems not baked into this monolith, nothing changed. Each system still has an IP address, their services can still be consumed, and so on.
The OASIS SOA standard (which is the definition of SOA we are loosely basing Arrowhead on) [1] [2] is not concerned with how messages are exchanged or how networks are facilitated. From the perspective of the standard, message exchanges can happen from inside the same binary, by classes calling each other's methods, just as well as they can happen over conventional networks. We may be going against how many interpret SOA in the context of microservices, but that is not what we are targeting. As far as I can tell, that view is too focused on the problem domain and technologies of the Web. However, I do think it would be sensible to have goals or restrictions set up for the AITIA implementations of the core systems, aimed at making them tilt as little as possible towards narrow use cases. Requring the AITIA Java systems to run in their own JVMs could very well be a suitable delimitation. |
I was referring rather to the ability of listening on a network.
I don't argue with this approach just saying that so far this has not been stated so. Or at least it wasn't realized by me :) |
|
The device registry only registers a device. The system registry links a system to a device. At the time the system registry was written, there was no correct way to register a system (consumer) only.
The onboarding features which were added later into device and system registry basically perform two things: (1) "create" a new certificate for device/system, and (2) register said device/system. In both cases, the onboarding core system is not involved (anymore). The registries either create a certificate signing request (CSR), or use a provided CSR and forward that to the certificate authority. It is true that the mentioned endpoints do not require AH certificates especially to allow the usage of temporary certificates which got created during the onboarding procedure. At the end of the procedure, the onboarding and registration on the system registry, the client receives a final and valid AH certificate and can finally contact all other core systems (including the "normal" registry method).
In my opinion the use of microservices enables rapid development if we have the needed supporting frameworks and it supports mixing (core) services written in different languages. Our current core services might to be big already to support this. I would not mind creating core services which are not publicly available for arrowhead clients but can be only used by other core services. I also would not mind creating "meta" services which forward calls to the relevant core services to make the "frontend" more easy to use. |
|
Greetings, I should have been active in this Git issue conversation earlier, but I have been overwhelmed with work. The Service Registry is of interest to me since it has been giving us trouble. My interest are constrained devices and our development work uses the B-L475E-IOT01A Discovery kit. One neat feature it has is a STSAFE-A100 chip, which is relevant with authentication (hardware and software), onboarding and encryption. The problem the Service Registry gave was that when coming back online, we would get an error when attempting to register our services, since they were already registered. That is the services were not deleted from the registry although they were not available. (They should be deregistered when leaving a local cloud, yet the system of systems should tolerate system failure). @tsvetlin informed me in Lübeck that the "time to live" registration feature is implemented and by default turned off. I do not see any such information in the payload (Returns a ServiceRegistryEntry). The current Git issue is about ServiceRegistry vs SystemRegistry #21 and could include the DeviceRegistry. Should there be one system or three? If we look at the above reply to the registration or the ServiceQueryList, all the information is there for the available services. There is no need for the service registry to know more about systems (providers and consumers) as long as they are authenticated within the local cloud and the metadata of the devices and systems are associated with those of the services. Even an Authentication system, which relies on policies, would need to know about the systems themselves if the metadata information is complete. A service registry that only takes care of services allows for alternative service registry, such as HashiCorp Consul. Alternative solution to the service registry have been requested by customers. To my understanding, the device and system registry are used with the onboarding procedure to assist with automatic generation of certificates in collaboration with the Certificate Authority system. Therefore there is no need to know about the system registry or the device registry once the systems have their authenticating certificate. What we agreed in our last roadmap workgroup meeting is that the descriptions of the device, system and service registry are separated, yet flexible or vague enough to allow a separated or combined implementation of the registries. |
|
@vanDeventer As far as I can tell, you are raising two concerns. Concern 1: The first is the problem of reregistering an already registered service. This is a concern I raised in Mars last year [1]. I then proposed a way of letting systems replace existing service registry entries, but @tsvetlin decided it was redundant as the "time to live"-mechanism takes care of pruning old entries. In essence, my proposal was to associate every registered entry with the hash of the x.509-certificate of the system owning the entry, and permitting every system to replace its own entries. The proposal is not complete, however. It should also handle certificates expiring and being replaced, as well handling systems running in insecure mode (which means that they do not have any certificates). A more robust approach would be to have the service registry keep track of its own internal identifiers to each system, and then allow for mulitple kinds of identifiers to map to the same internal system identifiers. Then different hash algorithms, multiple simeoultaneous certificates, and so on, can be supported at once. While the "time to live"-mechanism indeed does prune old entries, it is rather slow and can be turned off. Allowing for systems to replace entries would always work, for which reason I still think it should be implemented. HashiCorp Consul refers to the mitigation of this problem as anti-entropy, and have written quite a bit about how they tackle it and why. I think we would do well to take inspiration from them. By the way, the Concern 2: The second concern is whether or not there is an overlap between the service and system registries. As far as I can tell, the only information owned by the device or system of a service that must be known to consume a given service is an IP address, a port and, optionally, some form of certificate identifier (just as you are saying @vanDeventer). I don't see that as enough reason to merge the systems into one. |
|
First I like to state that we should add the SystemRegistry and the DeviceRegistry to the mandatory core systems. Next that each of these systems should have their own database which is a cornerstone to the architecture. The Roadmap WG meeting 211028 came to the conclusion that having a ServiceRegistry, a SystemRegistry and a DeviceRegistry is appropriate from an architecture view and makes sense to complex application solutions. |
|
This discussion also holds the following topics:
A third topic is how should the data structures look like. We know that the DNS-SD structure is defined and standardised. We could use this or we could define our own way of doing it. The naming convention by Cristina provides a structured way of linking the three registries regardless if we use DNS-SD or any other structure. A related topic is which meta data we should mandate to be registered and how additional meta data can be application system defined. |
|
see v5.0.0 isse #44 |
ServiceRegistry and SystemRegistry are both directly writing the
system_table and have overlapping featuers, which I think is not the best approach. Personally I think that only one core-system should offer such a core service like system registration and cover the responsbility of preprocessing, verifying (etc...) the records to be saved, in order to have a crystal clear and easily maintainable process.As far as I see, the purpose of SystemRegistry is
I suggest to have a conversation about the below alterantives (and more if any):
A) SystemRegistry to consume "register-system" service instead of directly writing the system table.
This way we could keep the current way of working related to SystemRegistry, but also we would ensure, that the system registration will always be the same process. On the other hand it means more resource usage (because of http(s) calls), than it would necesarry.
B) Move SystemRegistry features into the most related core-systems.
As an example:
Linking a system to a device
Move this into DeviceRegistry or move this into ServiceRegistry as a switchable extension.
Allowing of system registration without publishing a service
This has been implemented by ServiceRegistry since v4.3.0
Triggering onboarding procedure
If I understand the code well, currently the SystemRegistry creates the CertificateCreationRequestDTO on behalf of the application system and sends it to the Onboarding core system. I think this should be covered fully by the Onboarding core system which could also create the request on behalf of the application system and registrate it after the successful certificate creation (by consuming the "register-system" service). Actually based on the SystemRegistryAccessControlFilter the SystemRegistry gives access to clients without valid AH certificate when calling
/systemregistry/echo,/systemregistry/onboardingand/systemregistry/unregister, which I think shouldn't be allowed in case of a core system which is not on the edge.The text was updated successfully, but these errors were encountered: