CXF & Heroku, one more time…

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:

Create the project from the archetype and its associated git repository

• mvn archetype:generate -DarchetypeCatalog=http://petalslink.github.com/maven/
• cd FOLDER
• git init
• git add *
• git commit -m « Yeah! »

Push it to heroku

• heroku login
• heroku create
• git push heroku master

view raw

howto.md

hosted with ❤ by GitHub

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?

Running JAXRS services in the Cloud in 5 minutes… or less!

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:

	/**
	*
	*/
	package org.chamerling.heroku.service.rest;
	import javax.ws.rs.GET;
	import javax.ws.rs.Path;
	import javax.ws.rs.PathParam;
	import javax.ws.rs.Produces;
	import javax.ws.rs.QueryParam;
	import javax.ws.rs.core.MediaType;
	import javax.ws.rs.core.Response;
	/**
	* @author chamerling
	*
	*/
	@Path("/sample/")
	public interface SampleService {
	/**
	* Simple response
	*
	* @return
	*/
	@GET
	@Path("ping")
	String ping();
	/**
	* Response from JAXB beans
	*
	* @return
	*/
	@GET
	@Path("list")
	@Produces(MediaType.APPLICATION_JSON)
	Response list();
	/**
	* Get query parameters. ie call to /rest/query?foo=bar
	*
	* @return
	*/
	@GET
	@Path("query")
	@Produces(MediaType.APPLICATION_JSON)
	Response query(@QueryParam("foo") String parameter);
	/**
	* Call me at /rest/path/XXX
	*
	* @param id
	* @return
	*/
	@GET
	@Path("path/{id}")
	@Produces(MediaType.APPLICATION_JSON)
	Response path(@PathParam("id") String id);
	}

view raw

SampleService.java

hosted with ❤ by GitHub

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

BPEL support in Petals DSB

As promised in the last article about my talk at OW2Con 2011 last week, here is a video on something I was not able to show due to some low resolution problems. The video is a bit long but shows several things (in the right order):

1. The DSB Manager Web application is used to manage the Distributed Service Bus. It uses the DSB Web service API to interact with node instances running somewhere…
2. The DSB Manager is used to bind business services to the DSB (let’s forget JBI, the user does not care about it…). DSB services are also exposed. Every DSB node provides the same business API with the help of the distributed endpoint registry it uses.
3. The DSB Manager uses the DSB BPEL API to deploy BPEL processes to the DSB. Up to the DSB to use the right internal endpoint when the process is executed. Services can be hosted on any node, it is the role of the DSB to route messages to the right endpoint on the right node. The BPEL process is exposed as Web service and can be invoked by any Web service client. Here I just use SOAPUI client.
4. We can monitor what happens when invoking a service! For now the DSB Manager uses Web service notification to subscribe to some monitoring topic hosted on the DSB node. When a message is exchanged between the client and the services involved in the process execution, notification are automatically published to the DSB Manager which has just subscribed. The monitoring uses Web sockets for live display in the browser…
5. Last thing is just a test to show more monitoring data when many calls are exchanged between consumers and providers.

Let’s go one step further… The BPEL engine we use in the DSB is our own (PetalsLink) BPEL engine we developed from scratch. This allows us to have a complete control on it and to be able to extend it and embed it as we want without any constraint. In the current case, the BPEL Engine is hosted on a dedicated DSB component. It means that we do not have an external thing which talk with services through some exposed services. This is really important to notice that by doing such thing we can really base process execution on a Service Oriented Architecture. When developing the BPEL process with the Petals Studio, or when creating a BPM process (more details in a future post), you do not have to care about service endpoints. You just have to say to the process that you want to call operation X of service Y or interface Z. It is up to the DSB hosting the BPEL engine to resolve endpoints at runtime. By using this approach we can really do interesting things, just because the DSB is Distributed: services can be hosted on any nodes, can be replicated, can move, can be updated without any impact on the process itself: Oh wait this is SOA!

Related articles

• Back From OW2Con 2011 (chamerling.org)
• Some Play Framework, Service Bus, WS Notification and Web Sockets… (chamerling.org)
• Let’s talk at OW2Con 2011 (chamerling.org)

Pushing your Web services in the Cloud in 5 minutes…

… or less! Heroku is defined as a « Cloud application platform ». I just want to redefine it to « Awesome Cloud application Platform ». So, this awesome platform provides a way to host and scale your application in the Cloud really easily with 3 or 4 commands…

Since I am currently working on my talk at #OW2Con 2011 (coming later this week) dealing with BPM, Services and the Cloud, I wanted to host some Web services on several places. I never had time to test Heroku but I just took this precious time today. After looking some examples, I created a Maven project template (no I do not have time to create an archetype, maybe there is one somewhere) which uses Jetty and Apache CXF to expose JAXWS annotated classes as Web services. So now, using heroku to freely expose your services is easy as:

1.  Sign up to heroku
2. Download the heroku client for your platform
3. Clone/Fork the repository at https://github.com/chamerling/heroku-cxf-jaxws
4. Add your own services
5. Login to heroku ‘heroku auth:login‘
6. Create the app on heroku ‘heroku create -s cedar‘
7. Push your services to heroku ‘git push heroku master‘. There is a git hook somewhere which just automatically compile and start your application after you pushed it.
8. Open your CXF services summary page ‘heroku open’

The default application name is some random one, you can rename it by using the ‘heroku rename yournewname‘ but in the current case I had an issue on the generated Web service endpoint name. So I suggest restarting your app after renaming (have a look to the ‘heroku ps‘ command).

That’s all, that’s quick!

Playing in Brussels

Last week was the first annual review meeting of the Play project I work on since one year. I am involved at several levels in this project: from the architecture point of view, to the software integration and quality ones. On my side, my goal is to provide the efficient software infrastructure for events actors, or how to build an Event Driven Architecture based on Petals Distributed Service Bus. There are others points which have to be developed, especially all the platform governance stuff and Service Level Agreement for events, what we call Event Level Agreement.

We showed several things to the European Commission reviewers and we were also able to show an early prototype (this one was originally planned to be show at mid project ie in 6 months…). I made a video capture of the demo, which really needs to be explained…

• There is the idea of a market place for events : The event marketplace. From there users are able to subscribe to things they are interested in. For now it is just a simple Web application which subscribe on behalf of the user to events through topics. This subscription is sent to the Play paltform using Web standards. Here we use OASIS Web service Notification to create this communication link.
• Events are collected from several sources by events adapters. In the video above, we can see the user setting this FB status which is collected by the Play system and transformed into a notification which is published to the platform. There are also some Twitter adapters and Pachube ones which collects data in real time and publish them to the platform. This time again, we use Web standards for adapters communication.
• Now, what happens in the video? The user logs in to event marketplace and subscribes to FB events. The user then publishes something to its FB wall (note that it is not mandatory to have the same user in the event marketplace and in FB. A user can subscribe to FB events and receive events from all the FB statuses collected from the FB application users). After the event propagation delay, the event marketplace display the event to the user.

So do we need such machinery to do things like that? No, if you want to do some other simple mashup portal. There are several components which are under active development: Storage and processing. Yes we store all events in the Play platform. This storage will be huge, but it is one of the project goal: Providing efficient and elastic storage in some P2P way. The need for this storage comes with the other important aspect of the project: Complex Event Processing. We will soon be able to create complex rules on top of events and be able to generate notifications based on past and real time notifications because we have efficient storage and real time stuff inside the platform. I am not an expert of this domain, so I can not give more details about that point but capabilities are huge! For example, we can express something like « Hey Play, can you send me a SMS me when there is my favorite punk rock band playing just around and I am not on a business trip and X and !Y or Z ». All of this intelligence coming from the processing of various sources I push since months in the platform coming from Twitter, FB, last.fm and other data providers.

Now let’s take some time to work on my OW2Con talk. The session name is pretty cool : Open Cloud Summit Session.