You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by helander <le...@gmail.com> on 2012/08/14 22:24:06 UTC
Proof of concept for Camel Web Interface
Hi,
I would like to share with anyone interested a prototype I have made for a
Web interface to Camel.
It is based on Jolokia (http://jolikia.org) which is a JMX agent that
provides access via http. Along with jolokia comes client interface
libraries for Javascript and Java. The Jolokia agent is deployable in
basically any kind of Java container; standard JVM, Web container, OSGi
container, and for example the agent is available as a ready to deploy OSGi
bundle. The solution I have created and tested (tested in Karaf) consists
of:
1) The Jolika OSGi Agent (download it from jolokia.org)
2) A web application, packaged as a WAR (attached to this post)
Just put these two artifacts in Karaf's deploy directory and open a browser
(Firefox works best for me) at http://localhost:8181/camel-webui.
You would of course need some camel routes as well, and if you do not have
that, I have provided a blueprint with a couple of routes (attached as
dummy.xml). This requires camel-blueprint to be installed.
The WAR file only contains static content, one html file with embedded
javascript and some css for layout. The html file is not very large (below
200 lines - 50 html and 150 javascript).
Ok, so what can you do with this application:
1) It lists all available routes and some data about each route.
2) The current state is indicated by a button, typically labeled "Started".
If you press the button, the route will be suspended and the button label
will change to "Suspended".
3) On the right hand side of the route table you have a column called
"Monitor" and it has a checkbox for each route. When you tick a checkbox, a
diagram will appear. The diagram will show the activity (number of completed
exchanges) for all routes that currently have their monitor box ticked. The
data in the table will also be live updated for the monitored routes.
All interactions between the browser and camel is made via the Jolika
javascript library, which interacts with the Jolokia agent on the target
system. The Jolokia agent then interacts with the Camel MBeans.
I am not associated with Jolokia, but I like the possibilities their
components provide, namely building clients to applications and components
by just utilizing what these applications and components exposes via JMX
(their MBeans).
I am not an HTML, CSS or Javascript expert, so there is probably a lot to
say about the code in my prototype, but it works fairly well, and I am
impressed by the kind of functionality you can create with 200 lines of
code.
Thanks
Lars http://camel.465427.n5.nabble.com/file/n5717349/camel-webui-1.0.0.war
camel-webui-1.0.0.war
http://camel.465427.n5.nabble.com/file/n5717349/dummy.xml dummy.xml
--
View this message in context: http://camel.465427.n5.nabble.com/Proof-of-concept-for-Camel-Web-Interface-tp5717349.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Proof of concept for Camel Web Interface
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Thanks for sharing this with the community.
Yes Jolokia is a interesting project. For example it can offer a nice
REST api on top of the JMX API we have in Camel.
We have on the Camel roadmap for 3.x to offer a REST management API,
but Jolokia may just be the glue we decide to use, instead of rolling
out our own. Notice we have some REST api in camel-web, but that is a
IMHO a bit to heavy as its tied to a web console as well using scalate
and jersey.
On Tue, Aug 14, 2012 at 10:24 PM, helander <le...@gmail.com> wrote:
> Hi,
>
> I would like to share with anyone interested a prototype I have made for a
> Web interface to Camel.
> It is based on Jolokia (http://jolikia.org) which is a JMX agent that
> provides access via http. Along with jolokia comes client interface
> libraries for Javascript and Java. The Jolokia agent is deployable in
> basically any kind of Java container; standard JVM, Web container, OSGi
> container, and for example the agent is available as a ready to deploy OSGi
> bundle. The solution I have created and tested (tested in Karaf) consists
> of:
>
> 1) The Jolika OSGi Agent (download it from jolokia.org)
> 2) A web application, packaged as a WAR (attached to this post)
>
> Just put these two artifacts in Karaf's deploy directory and open a browser
> (Firefox works best for me) at http://localhost:8181/camel-webui.
>
> You would of course need some camel routes as well, and if you do not have
> that, I have provided a blueprint with a couple of routes (attached as
> dummy.xml). This requires camel-blueprint to be installed.
>
> The WAR file only contains static content, one html file with embedded
> javascript and some css for layout. The html file is not very large (below
> 200 lines - 50 html and 150 javascript).
>
> Ok, so what can you do with this application:
>
> 1) It lists all available routes and some data about each route.
> 2) The current state is indicated by a button, typically labeled "Started".
> If you press the button, the route will be suspended and the button label
> will change to "Suspended".
> 3) On the right hand side of the route table you have a column called
> "Monitor" and it has a checkbox for each route. When you tick a checkbox, a
> diagram will appear. The diagram will show the activity (number of completed
> exchanges) for all routes that currently have their monitor box ticked. The
> data in the table will also be live updated for the monitored routes.
>
> All interactions between the browser and camel is made via the Jolika
> javascript library, which interacts with the Jolokia agent on the target
> system. The Jolokia agent then interacts with the Camel MBeans.
>
> I am not associated with Jolokia, but I like the possibilities their
> components provide, namely building clients to applications and components
> by just utilizing what these applications and components exposes via JMX
> (their MBeans).
>
> I am not an HTML, CSS or Javascript expert, so there is probably a lot to
> say about the code in my prototype, but it works fairly well, and I am
> impressed by the kind of functionality you can create with 200 lines of
> code.
>
> Thanks
>
> Lars http://camel.465427.n5.nabble.com/file/n5717349/camel-webui-1.0.0.war
> camel-webui-1.0.0.war
> http://camel.465427.n5.nabble.com/file/n5717349/dummy.xml dummy.xml
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Proof-of-concept-for-Camel-Web-Interface-tp5717349.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Proof of concept for Camel Web Interface
Posted by Lars-Erik Helander <le...@gmail.com>.
Hi Claus,
I have attached the WAR to this e-mail. It contains all sources.
/Lasse
2012/8/16 Claus Ibsen <cl...@gmail.com>:
> Hi Lasse
>
> The link for the WAR file gave me a file not found error. Do you have
> the POC hosted somewhere, or maybe you can post maybe a .zip file with
> the source code or something?
>
>
>
> On Tue, Aug 14, 2012 at 10:24 PM, helander <le...@gmail.com> wrote:
>> Hi,
>>
>> I would like to share with anyone interested a prototype I have made for a
>> Web interface to Camel.
>> It is based on Jolokia (http://jolikia.org) which is a JMX agent that
>> provides access via http. Along with jolokia comes client interface
>> libraries for Javascript and Java. The Jolokia agent is deployable in
>> basically any kind of Java container; standard JVM, Web container, OSGi
>> container, and for example the agent is available as a ready to deploy OSGi
>> bundle. The solution I have created and tested (tested in Karaf) consists
>> of:
>>
>> 1) The Jolika OSGi Agent (download it from jolokia.org)
>> 2) A web application, packaged as a WAR (attached to this post)
>>
>> Just put these two artifacts in Karaf's deploy directory and open a browser
>> (Firefox works best for me) at http://localhost:8181/camel-webui.
>>
>> You would of course need some camel routes as well, and if you do not have
>> that, I have provided a blueprint with a couple of routes (attached as
>> dummy.xml). This requires camel-blueprint to be installed.
>>
>> The WAR file only contains static content, one html file with embedded
>> javascript and some css for layout. The html file is not very large (below
>> 200 lines - 50 html and 150 javascript).
>>
>> Ok, so what can you do with this application:
>>
>> 1) It lists all available routes and some data about each route.
>> 2) The current state is indicated by a button, typically labeled "Started".
>> If you press the button, the route will be suspended and the button label
>> will change to "Suspended".
>> 3) On the right hand side of the route table you have a column called
>> "Monitor" and it has a checkbox for each route. When you tick a checkbox, a
>> diagram will appear. The diagram will show the activity (number of completed
>> exchanges) for all routes that currently have their monitor box ticked. The
>> data in the table will also be live updated for the monitored routes.
>>
>> All interactions between the browser and camel is made via the Jolika
>> javascript library, which interacts with the Jolokia agent on the target
>> system. The Jolokia agent then interacts with the Camel MBeans.
>>
>> I am not associated with Jolokia, but I like the possibilities their
>> components provide, namely building clients to applications and components
>> by just utilizing what these applications and components exposes via JMX
>> (their MBeans).
>>
>> I am not an HTML, CSS or Javascript expert, so there is probably a lot to
>> say about the code in my prototype, but it works fairly well, and I am
>> impressed by the kind of functionality you can create with 200 lines of
>> code.
>>
>> Thanks
>>
>> Lars http://camel.465427.n5.nabble.com/file/n5717349/camel-webui-1.0.0.war
>> camel-webui-1.0.0.war
>> http://camel.465427.n5.nabble.com/file/n5717349/dummy.xml dummy.xml
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/Proof-of-concept-for-Camel-Web-Interface-tp5717349.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
Re: Proof of concept for Camel Web Interface
Posted by Claus Ibsen <cl...@gmail.com>.
Hi Lasse
The link for the WAR file gave me a file not found error. Do you have
the POC hosted somewhere, or maybe you can post maybe a .zip file with
the source code or something?
On Tue, Aug 14, 2012 at 10:24 PM, helander <le...@gmail.com> wrote:
> Hi,
>
> I would like to share with anyone interested a prototype I have made for a
> Web interface to Camel.
> It is based on Jolokia (http://jolikia.org) which is a JMX agent that
> provides access via http. Along with jolokia comes client interface
> libraries for Javascript and Java. The Jolokia agent is deployable in
> basically any kind of Java container; standard JVM, Web container, OSGi
> container, and for example the agent is available as a ready to deploy OSGi
> bundle. The solution I have created and tested (tested in Karaf) consists
> of:
>
> 1) The Jolika OSGi Agent (download it from jolokia.org)
> 2) A web application, packaged as a WAR (attached to this post)
>
> Just put these two artifacts in Karaf's deploy directory and open a browser
> (Firefox works best for me) at http://localhost:8181/camel-webui.
>
> You would of course need some camel routes as well, and if you do not have
> that, I have provided a blueprint with a couple of routes (attached as
> dummy.xml). This requires camel-blueprint to be installed.
>
> The WAR file only contains static content, one html file with embedded
> javascript and some css for layout. The html file is not very large (below
> 200 lines - 50 html and 150 javascript).
>
> Ok, so what can you do with this application:
>
> 1) It lists all available routes and some data about each route.
> 2) The current state is indicated by a button, typically labeled "Started".
> If you press the button, the route will be suspended and the button label
> will change to "Suspended".
> 3) On the right hand side of the route table you have a column called
> "Monitor" and it has a checkbox for each route. When you tick a checkbox, a
> diagram will appear. The diagram will show the activity (number of completed
> exchanges) for all routes that currently have their monitor box ticked. The
> data in the table will also be live updated for the monitored routes.
>
> All interactions between the browser and camel is made via the Jolika
> javascript library, which interacts with the Jolokia agent on the target
> system. The Jolokia agent then interacts with the Camel MBeans.
>
> I am not associated with Jolokia, but I like the possibilities their
> components provide, namely building clients to applications and components
> by just utilizing what these applications and components exposes via JMX
> (their MBeans).
>
> I am not an HTML, CSS or Javascript expert, so there is probably a lot to
> say about the code in my prototype, but it works fairly well, and I am
> impressed by the kind of functionality you can create with 200 lines of
> code.
>
> Thanks
>
> Lars http://camel.465427.n5.nabble.com/file/n5717349/camel-webui-1.0.0.war
> camel-webui-1.0.0.war
> http://camel.465427.n5.nabble.com/file/n5717349/dummy.xml dummy.xml
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Proof-of-concept-for-Camel-Web-Interface-tp5717349.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Proof of concept for Camel Web Interface
Posted by "Preben.Asmussen" <pr...@dr.dk>.
Hi all
Had a look at the camel-web component, and I think it addresses the need to
visualize camel jmx in a web app. for ppl. to view/manage camel via a web
gui. Personally I use VisualVM http://visualvm.java.net/ for that kind of
need. This gives me also access to all other management beans available in
the vm.
The solution we needed was a simple system/platform monitoring feature that
could monitor a lot of camel routes deployed on different nodes, and be
plugged in to our existing monitoring system used by operations, and
ourselves of course.
Im not sure if that fits in the camel-web project. It seems to me that it
should be separate since it addresses a different need. What do you think ?
I would like to share the solution if there is any interest, and if time
allows it. (boss sponsors time)
Currently it is somewhat proprietary since it's developed to suite our
needs, but it would be easy to generalize.
Preben
--
View this message in context: http://camel.465427.n5.nabble.com/Proof-of-concept-for-Camel-Web-Interface-tp5717349p5717561.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Proof of concept for Camel Web Interface
Posted by "michal.warecki" <mi...@gmail.com>.
Yes, all are welcome in the development of the camel-web branch.
Link to source:
https://github.com/michalwarecki/camel/tree/trunk/components/camel-web
I've just stared developmpent so some fragments need improvements but using
JMX as a camel-web console looks promising and it is very easy to extend
(creating new REST resource with html page takes about 1 hour).
--
View this message in context: http://camel.465427.n5.nabble.com/Proof-of-concept-for-Camel-Web-Interface-tp5717349p5717516.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Proof of concept for Camel Web Interface
Posted by "Preben.Asmussen" <pr...@dr.dk>.
@Lukasz Good ideer will check the dev list and Michal.
/Preben
--
View this message in context: http://camel.465427.n5.nabble.com/Proof-of-concept-for-Camel-Web-Interface-tp5717349p5717513.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Proof of concept for Camel Web Interface
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hey Preben,
There is another thread on dev list about camel-web improvements. Maybe you can join forces with Michal and work together?
Best regards,
Lukasz
Wiadomość napisana przez Preben.Asmussen w dniu 15 sie 2012, o godz. 18:06:
> Hi Lars
>
> I had a look at Jolokia last year and was impressed by it's usability for
> exposing jmx using http. Basically I wanted to use the Camel stats. for
> monitoring purposes for our custom monitoring system.
>
> At the end I found that the jmx stats wasn't enough to give you a reliable
> picture of the health of a Camel integration. Something is missing eg. the
> ability to check if a given resource being consumed by camel eg. a db, ftp
> or file is working. Camel will only give you statistics (failure, completed
> asf. ) when an exchange is being processed, and not if for example a db is
> down (using the jpa consumer here).
>
> At the end I developed a small monitoring capability for Camel that exposes
> a rest interface for all our routes deployed. This monitor internally uses
> the jmx stats to see if there has been any activity on the route within a
> configurable interval of MS. If any activity it will use the stats to
> determine if the route should report it's health as OK, WARN or ERROR.
> If no activity has been on the route it will run a Secondary target, meaning
> a custom monitoring component that will check the consumer's endpoint. These
> secondary targets are eg. a db, file, ftp resources with the purpose to
> checks if the resource is available and in good state (reporting the same
> stats as above).
> When the integration is deployed as a war each Camel context has it's own
> monitor.xml where monitoring rules are set up for the integration, exposing
> a rest interface for that component.
>
> The only thing needed now is a integration monitor that knows each component
> (Camel context/war) deployed and it's rest endpoint. The integration monitor
> runs in intervals and collects stats from each component, builds a
> correlated view of the hole platform's health and exposes that as a rest
> endpoint.
> This can then be consumed by in our case HP Openview to report on platform
> health. Besides that a gui is available.
>
> Preben
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Proof-of-concept-for-Camel-Web-Interface-tp5717349p5717409.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Proof of concept for Camel Web Interface
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hey Preben,
There is another thread on dev list about camel-web improvements. Maybe you can join forces with Michal and work together?
Best regards,
Lukasz
Wiadomość napisana przez Preben.Asmussen w dniu 15 sie 2012, o godz. 18:06:
> Hi Lars
>
> I had a look at Jolokia last year and was impressed by it's usability for
> exposing jmx using http. Basically I wanted to use the Camel stats. for
> monitoring purposes for our custom monitoring system.
>
> At the end I found that the jmx stats wasn't enough to give you a reliable
> picture of the health of a Camel integration. Something is missing eg. the
> ability to check if a given resource being consumed by camel eg. a db, ftp
> or file is working. Camel will only give you statistics (failure, completed
> asf. ) when an exchange is being processed, and not if for example a db is
> down (using the jpa consumer here).
>
> At the end I developed a small monitoring capability for Camel that exposes
> a rest interface for all our routes deployed. This monitor internally uses
> the jmx stats to see if there has been any activity on the route within a
> configurable interval of MS. If any activity it will use the stats to
> determine if the route should report it's health as OK, WARN or ERROR.
> If no activity has been on the route it will run a Secondary target, meaning
> a custom monitoring component that will check the consumer's endpoint. These
> secondary targets are eg. a db, file, ftp resources with the purpose to
> checks if the resource is available and in good state (reporting the same
> stats as above).
> When the integration is deployed as a war each Camel context has it's own
> monitor.xml where monitoring rules are set up for the integration, exposing
> a rest interface for that component.
>
> The only thing needed now is a integration monitor that knows each component
> (Camel context/war) deployed and it's rest endpoint. The integration monitor
> runs in intervals and collects stats from each component, builds a
> correlated view of the hole platform's health and exposes that as a rest
> endpoint.
> This can then be consumed by in our case HP Openview to report on platform
> health. Besides that a gui is available.
>
> Preben
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Proof-of-concept-for-Camel-Web-Interface-tp5717349p5717409.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Proof of concept for Camel Web Interface
Posted by "Preben.Asmussen" <pr...@dr.dk>.
Hi Lars
I had a look at Jolokia last year and was impressed by it's usability for
exposing jmx using http. Basically I wanted to use the Camel stats. for
monitoring purposes for our custom monitoring system.
At the end I found that the jmx stats wasn't enough to give you a reliable
picture of the health of a Camel integration. Something is missing eg. the
ability to check if a given resource being consumed by camel eg. a db, ftp
or file is working. Camel will only give you statistics (failure, completed
asf. ) when an exchange is being processed, and not if for example a db is
down (using the jpa consumer here).
At the end I developed a small monitoring capability for Camel that exposes
a rest interface for all our routes deployed. This monitor internally uses
the jmx stats to see if there has been any activity on the route within a
configurable interval of MS. If any activity it will use the stats to
determine if the route should report it's health as OK, WARN or ERROR.
If no activity has been on the route it will run a Secondary target, meaning
a custom monitoring component that will check the consumer's endpoint. These
secondary targets are eg. a db, file, ftp resources with the purpose to
checks if the resource is available and in good state (reporting the same
stats as above).
When the integration is deployed as a war each Camel context has it's own
monitor.xml where monitoring rules are set up for the integration, exposing
a rest interface for that component.
The only thing needed now is a integration monitor that knows each component
(Camel context/war) deployed and it's rest endpoint. The integration monitor
runs in intervals and collects stats from each component, builds a
correlated view of the hole platform's health and exposes that as a rest
endpoint.
This can then be consumed by in our case HP Openview to report on platform
health. Besides that a gui is available.
Preben
--
View this message in context: http://camel.465427.n5.nabble.com/Proof-of-concept-for-Camel-Web-Interface-tp5717349p5717409.html
Sent from the Camel - Users mailing list archive at Nabble.com.