Apache Camel is my favorite integration framework on the Java platform due to great DSLs, a huge community, and so many different components. Camel is used by many developers from different companies all over the world. However, most guys are not aware that some really cool tooling is available for Camel, too. Many people ask me about Camel tooling when I do talks at conferences. This is the reason for this short blog post about Camel tooling.
The question comes up often. It came up in my new project in November 2011, too. I will use Java EE (JEE, and not J2EE) instead of the Spring framework in this new Enterprise Java project.
I know: Several articles, blogs and forum discussions are available regarding this topic. Why is there a need for one more? Because many blogs talk about older versions of Java EE or because they are not neutral (I hope to be neutral). And because many people still think thank EJBs are heavy! And because the time has changed: It is Java EE 6 time now, J2EE is dead. Finally! Finally, because not only JEE 6 is available, but also several application servers. I do not want to start a flame war (too many exist already), I just want to describe my personal opinion of the JEE vs. Spring „fight“…
I had to answer the following question: Shall we use a Portal and if yes, should it be Liferay Portal or Oracle Portal? Or shall we use just one or more Java web frameworks? This article shows my result. The short answer: A Portal makes sense only in a few use cases, in the majority of cases you should not use one. In my case, we will not use one.
The integration framework Apache Camel already supports several important cloud services. This article describes the combination of Apache Camel and the Amazon Web Services (AWS) interfaces of Simple Storage Service (S3), Simple Queue Service (SQS) and Simple Notification Service (SNS). Thus, The concept of Infrastructure as a Service (IaaS) is used to access messaging systems and data storage without any need for configuration.
Spring Roo is a tool to offer rapid application development on the Java platform. It supports two solutions for Cloud Computing at the moment: Google App Engine (GAE) and VMware Cloud Foundry. Both provide the Platform as a Service (PaaS) concept. This article will discuss the Cloud Foundry support of Spring Roo. GAE was discussed in part 1 of this article series (https://www.kai-waehner.de/blog/2011/07/18/rapid-cloud-development-with-spring-roo-%E2%80%93-part-1-google-app-engine-gae).
Spring Roo is a tool to offer rapid application development on the Java platform. I already explained when to use it: https://www.kai-waehner.de/blog/2011/04/05/when-to-use-spring-roo. Spring Roo supports two solutions for Cloud Computing at the moment: Google App Engine (GAE) and VMware Cloud Foundry. Both provide the Platform as a Service (PaaS) concept. This article will discuss the GAE support of Spring Roo. Cloud Foundry will be analyzed in part 2 of this article series.
I really like the integration framework Apache Camel and I also like Scala a lot. This article shows the basics of this combination. It is NO introduction to Apache Camel or Scala. I created a Git project to use it as simple startup for Camel-Scala-Maven projects using just the basic Camel concepts and only a few complex Scala features (i.e. very „Java-friendly“).
Several solutions are available in the Java / JVM environment for messaging. All have in common that they exist for many years and still do its job in mission critical systems: Sending remote messages fast and reliable. There exist two different concepts which compete against each other for enterprise messaging solutions. This article describes and compares Point-to-Point (e.g. ActiveMQ) and Multicast (e.g. Tibco Rendevous) messaging to answer the question when to use which one. Although both solutions are available for many years now, this question is still very important – also for new software!
A keynote of Dalibor Topic (Oracle) criticizes the Java-Release-Cycles of Sun Microsystems at the Java conference „CONFESS 2011“ in Vienna, Austria. OpenJDK will become more imporant for Oracle than it was for Sun.