2:54 p.m.
----- Original Message -----
From: "Anton Hughes" <ah(a)tradeworks.io>
To: "Discussions around Hawkular development"
<hawkular-dev(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
--
Anton Hughes
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev