I am thinking about these things (in no particular order):
- consistent configuration & management of the different components
- service model (single vm & distributed)
- scalability in general (at least support for multi node installations)
- difference between user and system code
- API dependencies
- Service dependencies
My hope was that at some point rhq.next evolves into a more integrated and coherent whole,
possibly even using wildfly.core as the baseline. But the recent addition of the Cassandra
EAR make me believe that we get one step further away from that goal with every new
component being added.
It would fine to declare rhq.next as a loose collection of components that can be
integrated and used in different ways, but then the dependencies on certain API’s (namely
EE7) should be reconsidered. These API dependencies limit the way in which the rhq.next
components can be re-used.
On the other hand, if we where about the create a more coherent system, then chosing a
baseline (i.e. wf-core) and integrating with it would mean to abandon the WAR and EAR and
do the integration on a lower level for all the benefits it has (i.e. jboss modules, wf
subsystems and extensions). This would as well require us to revisit the API and service
dependencies introduced to the project (EE7, activeMQ).
Looking at the current codebase it seems that everything is put into a WAR or EAR for the
sake of simplicity without a second thought about any of the above. I believe if the
project proceed in that direction then it will neither become a reusable collection of
components nor an integrated whole.
/Heiko
On 07 Jan 2015, at 21:46, John Sanda <jsanda(a)redhat.com>
wrote:
Is there something in particular to which you are referring? Can you elaborate?
Thanks
- John
On 07 Jan 2015, at 21:05, Heiko Braun
<ike.braun(a)googlemail.com> wrote:
Guys, ay what point do you want to start thinking about a platform for all the bits and
pieces you throw together? Possibly even a platform that supports coordinated multi-node
deployments and operations?
How do you think is a bunch of EAR’s and WAR’s creating a coherent whole at the end?
I can understand that Wildfly might not be your first choice for achieving this. But we
did great length to make sure some your basic requirements are covered. I still believe
wildfly-core would offer a reasonable baseline for RHQ metrics and related projects. But
it seems to me that you cannot or just don’t want to see the value in it.
If you have another proposal for a managed runtime, bring it up, but please don’t tell
me that your idea of a system architecture is limited to a servlet container.
The more developer-centric artefacts you create, the less likely it becomes to integrate
as managed, secure and scalable system at the end. I know integration is the Cinderella of
software development, but if you don’t account for it from the beginning it’s very
unlikely to happen at the end.
RHQ metrics started on good grounds, with several reasonable approaches to things. But
the project’s structure degrades the more things you slam onto it.
I hope this email creates room for another discussion. About the big picture, about the
system architecture for RHQ metrics and integration options for projects like Wildfly that
have been looking forward to it so far.
Regards, Heiko B.