[Hawkular-dev] Usage of other apis

[Lukas Krejci]

On Friday, February 20, 2015 08:50:40 Heiko Braun wrote:
> > On 19 Feb 2015, at 22:25, Heiko W.Rupp <hrupp at redhat.com> wrote:
> >> Am 16.02.2015 um 16:07 schrieb Peter Palaga <ppalaga at redhat.com
> >> <mailto:ppalaga at redhat.com>>: Second, the possibility to run in a
> >> non-WF-like container is still somewhere in my consciousness. Importing
> >> wf BoM does not seem to be a step in that direction.
> > 
> > Yes. We need to restrict ourselves to Java EE 6 and EJB 3.1, JMS 1.1 apis.
> > We can use what EAP 6.4 offers - including JAX-RS 2 (this is not in there
> > by default, but can be supplied by the application).
> > This does not imply that we have to develop on EAP 6.4 though.
> 
> These two statements are contradicting each other: running in a “non
> WF-like” container and assuming EE6 API’s on the target platform are two
> worlds apart.
> 
> First of all, if you build on EE6, you don’t “restrict” yourself. At least
> not in the way of “limiting” the API dependencies. But limiting the API
> dependencies is a prerequisite to successfully integrate with other
> platforms (or containers), which is what Peter has in mind, if I am
> correct.
> 
> Hawkular want’s to provide a set of re-usable components. Re-usable in a
> sense, that other software project can integrate them easily. On the other
> hand there is the goal to build a Hawkular application, which itself is a
> consumer of the before mentioned components.
> 
> I think the continuous mistake among the Hawkular contributors is that you
> don’t prioritise these two approaches. To do that, we need to acknowledge
> an intrinsic dependency of the Hawkular application onto the components.
> Furthermore, any decision of API and service dependencies of those
> components impacts the way in which they can be re-used. Dependencies would
> need to be carried over to any platform that want’s to leverage Hawkular
> components. Which, in a way, limits it’s reusability.
> 

I guess the point the Heiko R. wanted to make is that by using jboss-javaee7 
BoM or whatever BoM that defines versions of dependencies that are used in our 
*primary* target container, all we are doing is that we limit ourselves in a 
choice of versions of *potential* dependencies. By importing a BoM you don't 
actually depend on anything - you merely predefine the versions of artifacts 
you might want to depend on. All it does is it makes our lives easier when 
composing the integrated solution together.

Otherwise everything you said resonates with me. The components themselves 
should be first of all embeddable as a library and therefore have only an 
absolutely necessary number of deps.

REST API then becomes a facade on top of that. If we ever want to expose the 
components as EJBs, those EJBs would again be facades using the library. Etc.

That's how I understood the outcome of our design discussions. While it may 
not look like it at the moment when we want to "rush" something (barely) 
consumable out to public, that outcome is definitely what we want to have in 
the "final" picture (or at least I sincerely hope so ;) ).

Of course, embeddable libraries are only a small beginning. The picture gets 
more interesting when you start to think about integrations between the 
components (i.e actually fire an alert when some value flows into metrics). I 
actually am not sure we cracked that architectural nut such that we all are 
satisfied with it. A message bus of sorts lends itself as a solution to 
loosely coupled communication between the components but components themselves 
I think should not depend on the bus by default - if for nothing else than for 
the "baggage" of dependencies any of the message bus solutions carry with it. 


> My suggestion would be to prioritise on the component re-use. Even if that
> results in inconveniences  when building the Hawkular application:
> 
> - Get rid of all EE6 dependencies.

+1

> - Stop thinking in WAR and EAR deployments.

+1 for components, -1 for their REST APIs and the integrated solution

> - Support reusability by strictly limiting the API dependencies.

+100

> - Come to an agreement about the priorities.

I think the prios are clear - rush something "dirty" out now, clean up to our 
hearts' content right after the first version is out.

> - Document and communicate the outcome of this discussion

+1, we (and most of all I) need to get better at this

> - Make sure all contributors understand and respect these constraints.
> 
> Regards, Heiko B.