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.
Data exchanges between companies increase a lot. The number of applications, which must be integrated increases, too. The interfaces use different technologies, protocols and data formats. Nevertheless, the integration of these applications shall be modeled in a standardized way, realized efficiently and supported by automatic tests. Such a standard exists with the Enterprise Integration Patterns (EIP) [1], which have become the industry standard for describing, documenting and implementing integration problems. Apache Camel [2] implements the EIPs and offers a standardized, internal domain-specific language (DSL) [3] to integrate applications. This article gives an introduction to Apache Camel including several code examples.
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“…
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. 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.
Cloud Computing is the future – if you believe market forecasts from companies such as Gartner. I think so, too. But everybody should be aware that there won’t be one single cloud solution, but several clouds. These clouds will be hosted at different providers, use products and APIs from different vendors and use different concepts (IaaS, PaaS, SaaS). Thus, in the future you will have to integrate these clouds as you integrate applications today.
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“).
Apache Camel is one of my favorite open source frameworks in the JVM / Java environment. It enables easy integration of different applications which use several protocols and technologies. This article shows when to use Apache Camel and when to use other alternatives.
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.