Jakarta component model programming discussion(The future of jakarta ejb )

Hi All,

taking inspiration from this paper https://sigops.org/s/conferences/hotos/2023/papers/ghemawat.pdf
" Towards Modern Development of Cloud Applications" (from Google) it's interesting beacause, they mention the limitations of microservices and their solution to solve them.

In the proposed solution paragraph they mention remote and local call management execution components and runtimes and their optimization and distribution, and it seems to me that they are remaking what ejbs and application servers are...
Aside from reading, it makes me think that this could be further food for thought in the Jakarta community and in removing the distributed programming model of EJBs in future releases, What do you think in relation to EJb deprecation/removal, RMI-IIOP deprecation/removal?
The @Service is the new way for jakarta enterprise for build a component model programming in distributed environment(features like, location, trasparency, rmi invocation, trasparency local or rmi invocation, concurrency, transaction,security)?

Start by reading the linked “Towards Modern Development of Cloud Applications” paper, then review the issue’s questions about EJB, RMI-IIOP, and the proposed @Service component model. The issue does not identify files, tests, an implementation entry point, or a concrete completion criterion; it requires community and specification design discussion first.

Written by the indexing model from the issue text.