And again: death of the application server announced

January 21st, 2015

What better way to start the new year than with a glimpse of what the future will bring for Java?

In this interview, Eberhard Wolff discusses why he thinks the application server is dead.

Some highlights:

  • Today, most app servers only deploy one application on them (mainly for isolation)
  • He envisions a Jar deployment model instead
  • Monitoring can be provided by external tools rather than the app server

It’s good to see that after more than 8 years after we introduced it, our jee without application server paradigm shift is more relevant than ever! And as usual, we’re here to give you the transactions you need without the application server.

UPDATE: Eberhard also has an article on this here

End of the app server and the ESB

December 8th, 2014

Another great independent article on how the app server is disappearing, with the ESB going along:

Micro services on light weight containers like Docker or maybe Dropwizard or Spring Boot are the end of the application server that served us so well last decade. If you can scale your application by starting a new process on a fresh VM you don’t need complex software to share resources. That means you don’t really need a lot of infrastructure. You can deploy small components with negligible overhead. Key-value data stores allow you to relax constraints on data that where imposed by relational databases. A service might support two versions of an interface at the same time. Combined with REST, a DNS and a load balancer this is the end of ESBs.

Interested in going one step further and moving into implementation? Download our JEE without application server vision to see some concrete tips on how this can work in Java…

Poll results: what should we (not) do?

November 17th, 2014

A few weeks back we’ve been sending around this poll via our newsletter subscriber base. We got a lot of answers so I will not go into every single one of them (and we can’t send individual replies, BTW, because the survey was anonymous). However, here is a distillation of the results, and our comments / questions to each:


  • Neglecting our users: we got at least some remarks about neglecting our non-commercial user base. We are very sorry if that seems to be the case, and we actually feel quite the contrary. We chose an open source model and have never regretted it to date. Our community users are most definitely every bit as important to us as our customers, because we would not get customers if it weren’t for our community (thanks for that, BTW!). However, fact of life is that we only have 24 hours every day and sometimes we need to make money besides the stuff we can offer for free. So in a way, we’ve been the victim of our own success because we had to serve a lot of new customers lately (especially since we’ve redefined our business model and the pricing that goes with it). Our sincerest apologies if this caused us to appear a bit negligent.
  • More open tools: this includes things like our source code repository, forums, issue tracker and documentation / examples. Granted, we could do a better job on those, but first and foremost we want to use the tools that support our business model (support that is). So that’s what has been guiding our choices so far. We haven’t found a better ’stack’ yet that serves that purpose and is worth the overhead of switching… We’re always on the lookout for opportunities though.

Business model: some respondents suggested we look into a new business model like JBoss, for instance. We don’t really understand why, because what we are doing is about the same thing as what Red Hat is doing? We’re curious to learn though, if anybody wants to clarify…

Integrations: a lot of people requested more built-in integration with third-party platforms. We’re certainly doing that: we’ve recently added Tomcat and are working on more things to come… Thanks for that!

Documentation: We always need more documentation. Somebody also suggested that we restructure our existing docs and offered to help. If you are that person, please email us (plenty of contact addresses on our website). Thanks!

Performance: We should do more benchmarking and publish / compare the results. That is certainly true, but we found that it depends so much on your configuration (not ours) that it is hard to come to a general conclusion. It just depends…

Again, we were not able to contact individual respondents so our interpretation and conclusion could be wrong. If that is the case, and you feel misunderstood (or just want to help) then please get in touch via our website.


TCC for transaction management across microservices

September 30th, 2014

Microservices are all about splitting up responsibilities of your domain’s bounded context into several HTTP-like services, deployed independently. So essentially it means splitting up process boundaries across different services - away from the monolith…

What is the consequence for your business transactions? In some (though not all) cases you may need some notion of transaction management but you can’t resort to XA or classical distributed transactions in the REST world…

So what are your options? Our newest API, TCC for REST, allows light-weight BPM and transaction management across independent REST services. Interested in learning all about it? Find out for yourself here (requires registration).

Web scale and cloud scale JEE without application server

September 30th, 2014

Scaling applications to the web and the cloud - combined with continuous deployment automation practices - is not easy. The current rigid and oversized infrastructure platforms don’t help here.

So it’s time for something different: discover our increasingly popular “no-appserver-paradigm”, enabling you to use all of the enterprise features without the heavy platform burden…

Download the full article here! (requires registration)

Light-weight BPM for REST

September 28th, 2014

Some people will claim that REST does not need BPM because it provides all the semantics you need.

However, if you look beneath the hood then it turns out that this is not exactly true: in particular, if multiple (independent) REST services need to come to the same outcome then you want something more…

Wondering what that is? Good! It’s all explained in one of our latest publications - to learn the details: just fill out this form.


Transaction management API for REST: TCC

September 28th, 2014

So you’re into REST and you are wondering how to define some kind of transaction guarantee with it…

Look no further, because we have exactly what you need:

  • A design pattern
  • A simple, vendor-independent REST API
  • Backed by a reusable coordinator service if you need one (that is up to you, really)

Find out for yourself here! (requires registration)

TCC context

If you have any questions or remarks, we’d love to hear about it…

Distributed transactions with multiple databases, Spring Boot, Spring Data JPA and Atomikos

August 19th, 2014

Another interesting blog post showing off Atomikos with Spring Boot and JPA.

As soon as we get some spare time (sigh) we’re hoping to look a bit more into Spring Boot, BTW.

Spring JTA multiple resource transactions in Tomcat with Atomikos example

August 19th, 2014

We found this nice tutorial by Gonçalo Marques covering basic two-phase commit with Spring, Tomcat and Atomikos.


PS with our latest Tomcat integration - available to commercial subscribers - things are even easier :-)

The further decline of the app server

July 5th, 2014

Interesting independent survey: 68% uses a web container like Tomcat or Jetty.

Appserver stats

Credit for the survey is due to Zero Turnaround