[Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0

[Stefan Negrea]

----- Original Message -----
> From: "Anton Hughes" <ah at tradeworks.io>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Tuesday, November 10, 2015 2:00:23 PM
> Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0
> 
> Hi all
> 
> Firstly, apologies if this thread is intended for Redhat staff only.

Thanks for replying. This is not an RH only discussion. This is a public mailing list and feedback like yours is really important to us.

> 
> My development background is primarily in .net - and so I am writing here to
> suggest using this instead - joking! chez.
> But, while working with .net, microsoft release the Windows Communication
> Foundation framework - basically a framework for abstracting the different
> messaging systems - how messages are sent over the wire, or in proc - from
> the implementation.
> 
> For the past 5 years I have been almost exclusively working in Java and was
> delighted to see similar concepts in Jboss Switchyard and Apache Camel. In
> particular, Switchyard allows for a service to be exposed to the world via
> multiple bindings easily. Camel is also an excellent choice.
> 
> Personally I would love to see communication to Hawkular using Apache Kafka!
> Adding a kafak binding in either Switchyard or Camel is a breeze!
> 
> When it comes to choosing a messaging implementation, I have good success in
> choosing frameworks that focus on integration and abstracting the specific
> messaging type. In my company, when we have discussions of should we use
> rest or jms - we tend to say yes - the answer is in the question. We need a
> system that easily supports both, and more.

My proposal is to have a single public API. I am advocating that if we decide to also support component level communication over JMS at this time, then the structure (functionality exposed, request requirements, and response) of that exchange should be identical with what we currently published for REST over HTTP. And if I understand correctly what you are saying, the concept is <<one API, multiple transports/bindings>>.

> 
> If this discussion arises now, it will surely arise again - therefore make
> the choice of easy integration. Abstract away how the message is sent to
> being simply a configuration.


That is one of the reasons why I keep pushing for a single public API. The hot transport right now is REST over HTTP. If we are committed to a single public API, not only that API will get better and better over time (because it is the only one used and published) but we can also find ways to leverage it over other channels.


> 
> Kind regards
> 
> On 10 November 2015 at 20:19, Lucas Ponce < lponce at redhat.com > wrote:
> 
> 
> > > 
> > > So, communication via Java API should be feasible.
> > 
> > That is an option as long as it works in a distributed environment (think
> > containers and different JVMs; would Java API work there? and how?) and the
> > same interface that is currently exposed on the public REST API is
> > available.
> > 
> 
> I'm not thinking as a general option.
> 
> But I have a wildfly server with metrics.war and alerts.war and
> mycomponent.war as client under same deployment, why I can't use Java API
> and I need to use REST between them ?
> 
> EJB clients are also possible but this was not introduced before and I don't
> want to do it.
> 
> But in the first scenario, looking for a user that wants to add its code
> colocated, the Java API should be the easy one.
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
> 
> 
> --
> Anton Hughes
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>