search

arrowhead-f / arrowhead-kalix

The Arrowhead Kalix Libraries
https://arkalix.se
Eclipse Public License 2.0
2 stars 5 forks source link

Make transport layers configurable #4

Open emanuelpalm opened 4 years ago

emanuelpalm commented 4 years ago

This will likely require creating some kind of configurator object that be used to provide Netty AbstractBootstraps with ChannelOption instances.

emanuelpalm commented 4 years ago

Not just the network-layer transport needs configuration possibilities, but also the application-level transports (currently only HTTP). Things such as compression/decompression, limits on the sizes of message heads, bodies, chunks, and so on, all could be made configurable.

I'm changing the name of the issue.

awoSYS commented 2 years ago

Not sure, if this is the right issue for this. But I'd like to add, that service interfaces other than HTTP-(IN)SECURE-JSON (such as MQTT) should be supported - not (only) for communicating with the core services, but in a service registration / orchestration request interface(Requirement)s field.

emanuelpalm commented 2 years ago

@awoSYS If you would like to see MQTT, or any other protocol, being supported by the core systems, you need to open an issue in the eclipse-arrowhead/core-java-spring repository. I don't think such an effort would be within the scope of what is targeted for Arrowhead 4.5+, but perhaps it could become relevant for a later Arrowhead 5 release.

awoSYS commented 2 years ago

@emanuelpalm I understand that you wait fore the core services to support communication via other protocols, before you implement that in the Kalix lib.

However, I'm referring to the communication between provider and consumer. The transport layer they use can imho differ from the way the provider and consumer communicate with the core services. We're doing this in our own demo and I think, I've seen that in another demo in Lübeck as well: towards the core services, producer and consumer use HTTP transport, data transfer between the two happens via MQTT afterwards.

The core services already support interface names, like MQTT-SECURE-JSON, if the use_strict_service_intf_name_verifier flag is set to false.

So do you think it's reasonable and feasible to allow other transports than HTTP in service registration or orchestration requests? (This probably means to implement providers and consumers other than for HTTP) Or do you still think this pattern is something that should be discussed with the community before considering it in Kalix?

emanuelpalm commented 2 years ago

Are you talking about the interface identifiers themselves, or are you wanting more direct support (such as a MqttService class)?

The interface identifier you mention already exists. In version 0.6 you can find it in the ServiceInterface class. In version 0.5, the same class is called InterfaceDescriptor. Both of those classes are defined such that you can add your own identifiers.

awoSYS commented 2 years ago

Yeah, the former. I'd think of classes like (Default)MqttConsumer, MqttService and maybe even MqttServer (or something with better naming).

emanuelpalm commented 2 years ago

@awoSYS That is certainly something I would be interested in adding later on. There are some things that need to happen first, however.

First and foremost, the future of the Kalix library is still a bit uncertain. While I don't think the library is going to disappear, there are some questions regarding how it will be managed. What I believe is likely is that some kind of effort will be initiated between LTU, Pinterop (myself) and AITIA for a more official Java Arrowhead-library. The reason I believe this is that there are voices being raised about that there should only be a single Arrowhead Java library. The name "Kalix" is probably going to disappear in the process. Before this can happen, however, I have to complete some other Arrowhead-related work for LTU. I'm currently writing a reference model, after which I will write a documentation reference and two new Arrowhead systems (the Device Agent and the Device Supervisor (names may change)). Work on the library may commence after that, which would be something like before summer next year.

Secondly, there are still quite a few things that need to be settled regarding the shape of the library. For example, after experimenting a bit with reactive programming, I believe it is a better fit for the deeply asynchronous nature of many Arrowhead applications than the current model based on Futures. It would, for example, have made the core service integration a lot easier to program and make bug-free.

When we have a stable-ish official Arrowhead Java library that supports HTTP(S) and JSON, the time could be right to start on more official support for MQTT, CoAP and/or CBOR.

awoSYS commented 2 years ago

@emanuelpalm Yes, I think I've heard of the effort to try to unite the multiple Java libs into one. I think that's very reasonable. Makes sense to wait for that (and other fundamental changes) to be completed, before adding functionality.

Btw. I like the effort towards better AHFW documentation!