OK I am late for the ‘traditional’ past-year summary. So let’s do it short with 4 pictures…
I gave several talks at OW2Con 2012 and had fun like every year. I am also proud to be the new OW2 technology council chairman. There is just one thing to say: There are nice things to come this year!
I launched several OS X apps, just for fun and to get feedback from new communities. Check them out on the Apps menu. The end of the year has been busy but some updates are almost ready to be published, especially for my favorite app : QuickHub.
Linagora, Open Source, Geek life
The most important thing of the year. Loris now have a sister: Mila.
One more Apache CXF and Heroku article to push Web services to the Java PaaS… In some previous articles I explained how to create JAXWS and JAXRS service by cloning/forking/whatever git repositories. This time it is almost the same but I created a maven archetype to generate tons of maven modules quickly and to integrate them in your maven-based projects (OK cloning a repository is faster, it does not download the entire Internet as Maven does…).
Let’s do it with a screen record to check how fast it is. With my poor Internet connection and some typos, I have something running on Heroku in less than 2 min 30…
Here are the commands used in the sample above:
The archetype source code is located at https://github.com/petalslink/petalscloud-maven-archetypes and deployed on OW2 repository. Once the project is generated from the archetype, one can add his own JAXWS-annotated services and associated Spring configuration (src/main/webapp/WEB-INF/beans.xml). Generated project is also available on github at https://github.com/chamerlingdotorg/maven-heroku-jaxws-sample.
Can it really be more easy?
Here is a really simple post about how to push REST services in the Cloud. Nothing really technical nor advanced, just some notes and sample using amazing tools CXF + Heroku…
Last time I was speaking about putting some SOAP Web services in the Cloud with Heroku, this time it is the same with REST services… The approach is exactly the same but it uses the JAXRS implementation provided by Apache CXF.
The REST service illustrates how to annotate the Java interface to returns JSON-based responses like:
Once implemented and configured (it uses Spring with the famous WEB-INF/beans.xml file), pushing it to Heroku is as simple as last time, nothing new here. Heroku needs a Procfile to start, and the Maven-based project is configured to generate what the Procfile needs: A shell file which launches a Jetty instance running Apache CXF and all the REST stuff.
The code is located at https://github.com/chamerling/heroku-cxf-jaxrs. You can run it locally to test before pushing to heroku:
- mvn install
- sh target/bin/webapp
One more time, one more tiny (and maybe useful in some cases…) application with Play!.
WTF, my server is dead again!?
This app is a simple heartbeat manager looking at remote HTTP services and notifying you by email when something becomes unreachable. It uses the background Job feature of the Play framework and just does HTTP GETs on the specified list. That’s all, that’s simple, but that’s can be useful sometimes…
The code is located at https://github.com/chamerling/heartbeat-manager
Almost true… In fact Petals DSB uses and extends Petals ESB in several ways. When I started to think about extending the Enterprise Service Bus, it was just to avoid all the JBI stuff at the management level i.e. use a real, simple and efficient API. So I added many management stuff exposed as Web services : Bind external services, expose internal services (oh yes bind + expose = proxy), get endpoints, activate things, etc…
One other goal was to avoid to use closed protocols for inter node communication: The ESB uses at least three ports to create inter node communications for JMX, NIO and SOAP. So why not, just using an open protocol like SOAP and just one port? This is what I did, I changed some implementations to use the same port and the same protocol for all services.
All this stuff has been developed focusing on extensibility and easier development. This is mainly because the ESB can be hard to extend for newbies, there are so many things inside… Today the DSB is not only a Distributed Service Bus, it is also a framework so that developers can easily extend the DSB without the need to know how it works inside. Some examples? Want to expose a kernel service : Add the JAXWS @WebService annotation. Want to subscribe to Web service notifications : Annotate you Java method with @Notify. Want to be notified about new endpoints : Add the @RegistryListener annotation. That’s all, you do not have to search for the Web service server to expose your service, nor read all the WSN documentation to receive notifications, … Simple, efficient.
There are other things you can do, mostly all is detailed in the DSB page.