Content
The books introduces many important Java EE 7 specifications: CDI, EJB, JPA, Servlets, JMS, Bean Validation, JAX-RS and some other stuff such as WebSockets, HTML5 support and Java Transaction API. Each chapter contains an introduction, source code examples and explanations of most important features and configurations. Source code examples can be downloaded, too.

Cool side note
Introduces and uses Gradle as build system and Arquillian for writing integration tests.

Summary
Even though the book starts with a short introduction to Java EE in general, this book is not suited for beginners. If you have no experience with Java EE yet, the information of this book will be too much for you. Get another book which offers step-by-step introduction examples for getting started with Java EE.
The book is perfect for getting an overview about many new Java EE 7 features. If you already have experience with Java EE, then this book is for you! The book does not go into all detail, of course. Java EE is too extensive for one book. You can write a single book about each specification. So, this book is a very good introduction to Java EE 7 and can also be used as reference book. If you need more details, you have to buy additional books for specific topics such as EJB or JSF.
A disappointing aspect is that, unfortunately, some new Java EE 7 features are not mentioned with more than just one or two sentences. IMO, this is fine for minor updates (e.g. JSF or JCA). Though, important new specifications (especially Batch) are missing, too.

Have fun with Java EE 7…

Best regards,
Kai Wähner (@KaiWaehner)

The post Book Review: “Java EE 7 Developer Handbook” by PACKT / Pilgrim appeared first on Kai Waehner.

[FYI: I work for Talend (one of the vendors). Please also read the comments from my Red Hat friends at the bottom!]

IDE Support

Camel consists of a set of normal Java libraries and is therefore usable with any Java IDE (such as Eclipse, NetBeans or IntelliJ IDEA) or even a classic text editor. Programming DSLs are available for Java, Groovy, and Scala. Even a Kotlin DSL is in the works, thanks to Camel’s founder James Strachan. All familiar IDE features such as code completion or Javadoc view are available for these DSLs. In the Spring XML DSL, the Eclipse-based SpringSource Tool Suite (STS) should be emphasized, which provides the best support for the Spring Framework and XML configurations.

Camel-specific Tooling

Besides classical IDE support, further products are available to provide additional functionality. Integration problems can be modeled with the help of Enterprise Integration Patterns (EIP, http://www.eaipatterns.com/). EIPs are implemented by Camel. Visual designers are available to help modeling integration problems with these EIPs. These tools even generate the corresponding source code automatically. Ideally, developers do not have to write any source code by hand.

Camel tooling is offered by Talend with Talend ESB (http://de.talend.com/products/esb) and JBoss, formerly FuseSource, with Fuse IDE (http://fusesource.com/products/fuse-ide). Both companies also provide full-time committers for the Apache Camel project. Let’s take a short look at these two products in the following.

Open Studio for Talend ESB

Talend ESB is an Eclipse-based integration platform within the Talend Unified Platform. The familiar “look and feel” and the intuitive use of Eclipse remain. The ESB is open source and freely available. The paid Enterprise version offers additional features and support. The ESB can be used independently or in combination with other parts of the Talend Unified Platform, such as BPM, Big Data, or Master Data Management. The great benefit is that everything can be done within one suite using the same GUI and concepts, based on Eclipse.

The entire Talend Unified Platform is based on the “zero-coding” approach. This way, a very efficient implementation of integration problems is possible using the EIPs and components. Routes are modeled and configured with intuitive tool support, all source code is generated. Of course, custom integration logic can still be written and included, for example, POJOs, Spring beans, scripts in different languages, or own Camel components. Plenty of other components besides Camel’s ones are available for Talend ESB – for example connectors to Alfresco, Jasper, SAP, Salesforce, or host systems.

Figure 1: Visual Designer of Talend’s ESB

Fuse IDE

The Fuse IDE is an Eclipse plugin, which is installed from the Eclipse update site. The Visual Designer (see Figure 2) generates Camel routes as XML code using the Spring XML DSL. The generated code is editable vice-versa, i.e. the developer can change the source code. The graphical model applies changes automatically. Fuse IDE is intuitive to use for creating Camel routes. FuseSource offers some other products, which can be used in combination with Fuse IDE – such as management console or Fuse MQ for messaging.

Under FuseSource, Fuse IDE was a proprietary product. However, FuseSource was recently taken over by RedHat (http://www.redhat.com/about/news/press-archive/2012/6/red-hat-to-acquire-fusesource) and now belongs to the JBoss division.  In the new roadmap, the Fuse IDE is still included. It will probably be integrated into the JBoss Enterprise SOA Platform and become “open sourced”. The integration of FuseSource will take at least a few more months time to complete (http://www.redhat.com/promo/jboss_integration_week/).

JBoss now “owns” three ESB products (JBoss ESB, Switchyard and Fuse ESB). Probably, these will be merged into one product in the end (SwitchYard is also based on Camel). Nevertheless, the FuseSource products will also be supported for some time – primarily in order to satisfy existing customers (my guess).

Figure 2:  Visual Designer of Fuse IDE (JBoss, former FuseSource)

Enterprise-ready Tooling is already available for Apache Camel!

The bottom line is that enterprise-ready tooling is already available for Apache Camel. It is great to see different companies working on tooling for Apache Camel. The winner definitely is Apache Camel… And there is no loser! Talend ESB and Fuse IDE are two different approaches for different kinds of projects.

If you like the „zero-coding“ approach, then take a closer look at Talend’s ESB. It is really easy and efficient to realize integration projects without writing source code – nevertheless, there is enough flexibility for customization and adding own source code. The combination with BPM, MDM or Big Data (based on Hadoop) is also supported within the unified platform using the same open source and „zero-coding“ concepts. If you „insist“ on writing and refactoring all source code by yourself within the text editor of an IDE, then take a look at Fuse IDE.

Your best would be to try out both and see which one fits best into your next enterprise integration project. If you know any other cool Camel tooling (no matter if it is enterprise-ready or not), or if you have any other feedback, please write a comment. Thank you.

Best regards,
Kai Wähner (Twitter: @KaiWaehner)

The post Enterprise-ready Tool Support for Apache Camel appeared first on Kai Waehner.

Enterprise Integration Patterns

EIPs can be used to split integration problems into smaller pieces and model them using standardized graphics. Everybody can understand these models easily. Besides, there is no need to reinvent the wheel every time for each integration problem.

Using EIPs, Apache Camel closes a gap between modeling and implementation. There is almost a one-to-one relation between EIP models and the DSL of Apache Camel. This article explains the relation of EIPs and Apache Camel using an online shop example.

Use Case: Handling Orders in an Online Shop

The main concepts of Apache Camel are introduced by implementing a small use case. Starting your own project should be really easy after reading this article. The easiest way to get started is using a Maven archetype [4]. This way, you can rebuild the following example within minutes. Of course, you can also download the whole example at once[5].

Figure 1 shows the example from EIP perspective. The task is to process orders of an online shop. Orders arrive in csv format. At first, the orders have to be transformed to the internal format. Order items of each order must be split because the shop only sells dvds and cds. Other order items are forwarded to a partner.

Figure 1: EIP Perspective of the Integration Problem

This example shows the advantages of EIPs:  The integration problem is split into several small, perseverative subproblems. These subproblems are easy to understand and solved the same way each time. After describing the use case, we will now look at the basic concepts of Apache Camel.

Basic Concepts

Apache Camel runs on the Java Virtual Machine (JVM). Most components are realized in Java. Though, this is no requirement for new components. For instance, the camel-scala component is written in Scala. The Spring framework is used in some parts, e.g. for transaction support. However, Spring dependencies were reduced to a minimum in release 2.9 [6]. The core of Apache Camel is very small and just contains commonly used components (i.e. connectors to several technologies and APIs) such as Log, File, Mock or Timer.

Further components can be added easily due to the modular structure of Apache Camel., Maven is recommended for dependency management, because most technologies require additional libraries. Though, libraries can also be downloaded manually and added to the classpath, of course.

The core functionality of Apache Camel is its routing engine. It allocates messages based on the related routes. A route contains flow and integration logic. It is implemented using EIPs and a specific DSL. Each message contains a body, several headers and optional attachments. The messages are sent from a provider to a consumer. In between, the messages may be processed, e.g. filtered or transformed. Figure 1 shows how the messages can change within a route.

Messages between a provider and a consumer are managed by a message exchange container, which contains an unique message id, exception information, incoming and outgoing messages (i.e. request and response), and the used message exchange pattern (MEP). „In Only“ MEP is used for one-way messages such as JMS whereas „In Out“ MEP executes request-response communication such as a client side HTTP based request and its response from the server side.

After shortly explaining the basic concepts of Apache Camel, the following sections will give more details and code examples. Let’s begin with the architecture of Apache Camel.

Architecture

Figure 2 shows the architecture of Apache Camel. A CamelContext provides the runtime system. Inside, processors handle things in between endpoints like routing or transformation. Endpoints connect several technologies to be integrated. Apache Camel offers different DSLs to realize the integration problems.

Figure 2: Architecture of Apache Camel

CamelContext

The CamelContext is the runtime system of Apache Camel and connects its different concepts such as routes, components or endpoints. The following code snipped shows a Java main method, which starts the CamelContext and stops it after 30 seconds. Usually, the CamelContext is started when loading the application and stopped at shutdown.

public class CamelStarter {

public static void main(String[] args) throws Exception {

CamelContext context = new DefaultCamelContext();

context.addRoutes(new IntegrationRoute());

context.start();

Thread.sleep(30000);

context.stop();

}

}

The runtime system can be included anywhere in the JVM environment, including web container (e.g. Tomcat), JEE application server (e.g. IBM WebSphere AS), OSGi container, or even in the cloud.

Domain Specific Languages

DSLs facilitate the realization of complex projects by using a higher abstraction level. Apache Camel offers several different DSLs. Java, Groovy and Scala use object-oriented concepts and offer a specific method for most EIPs. On the other side, Spring XML DSL is based on the Spring framework and uses XML configuration. Besides, OSGi blueprint XML is available for OSGi integration.

Java DSL has best IDE support. Groovy and Scala DSL are similar to Java DSL, in addition they offer typical features of modern JVM languages such as concise code or closures. Contrary to these programming languages, Spring XML DSL requires a lot of XML. Besides, it offers very powerful Spring-based dependency injection mechanism and nice abstractions to simplify configurations (such as JDBC or JMS connections). The choice is purely a matter of taste in most use cases. Even a combination is possible. Many developer use Spring XML for configuration whilst routes are realized in Java, Groovy or Scala.

Routes

Routes are a crucial part of Apache Camel. The flow and logic of an integration is specified here. The following example shows a route using Java DSL:

public class IntegrationRoute extends RouteBuilder {

@Override

public void configure() throws Exception {

from(“file:target/inbox”)

                      .process(new LoggingProcessor())

                      .bean(new TransformationBean(),

                                  “makeUpperCase”)                                                  

.to(“file:target/outbox/dvd”);

}

}

The DSL is easy to use. Everybody should be able to understand the above example without even knowing Apache Camel. The route realizes a part of the described use case. Orders are put in a file directory from an external source. The orders are processed and finally moved to the target directory.

Routes have to extend the „RouteBuilder“ class and override the „configure“ method. The route itself begins with a „from“ endpoint and finishes at one or more „to“ endpoints. In between, all necessary process logic is implemented. Any number of routes can be implemented within one „configure“ method.

The following snippet shows the same route realized via Spring XML DSL:

<beans … >

<bean class=”mwea.TransformationBean” id=”transformationBean”/>

<bean class=”mwea.LoggingProcessor” id=”loggingProcessor”/>

<camelContext xmlns=”http://camel.apache.org/schema/spring”>

<package>mwea</package>

<route>

        <from uri=”file:target/inbox”/>

                    <process ref=”loggingProcessor”/>

                    <bean ref=”transformationBean”/>

        <to uri=”file:target/outbox”/>

    </route>

</camelContext>

</beans>

Besides routes, another important concept of Apache Camel is its components. They offer integration points for almost every technology.

Components

In the meantime, over 100 components are available. Besides widespread technologies such as HTTP, FTP, JMS or JDBC, many more technologies are supported, including cloud services from Amazon, Google, GoGrid, and others. New components are added in each release. Often, also the community builds new custom components because it is very easy.

The most amazing feature of Apache Camel is its uniformity. All components use the same syntax and concepts. Every integration and even its automatic unit tests look the same. Thus, complexity is reduced a lot. Consider changing the above example: If orders should be sent to a JMS queue instead of a file directory, just change the „to“ endpoint from „file:target/outbox“ to „jms:queue:orders“. That’s it! (JMS must be configured once within the application before, of course)

While components offer the interface to technologies, Processors and Beans can be used to add custom integration logic to a route.

Processors and Beans

Besides using EIPs, you have to add individual integration logic, often. This is very easy and again uses the same concepts always: Processors or Beans. Both were used in the route example above.

Processor is a simple Java interface with one single method: „process“. Inside this method, you can do whatever you need to solve your integration problem, e.g. transform the incoming message, call other services, and so on.

public class LoggingProcessor implements Processor {

@Override

public void process(Exchange exchange) throws Exception {

System.out.println(“Received Order: ” +

exchange.getIn().getBody(String.class));

}

}

The „exchange“ parameter contains the Messsage Exchange with the incoming message, the outgoing message, and other information. Due to implementing the Processor interface, you have got a dependency to the Camel API. This might be a problem sometimes. Maybe you already have got existing integration code which cannot be changed (i.e. you cannot implement the Processor interface)? In this case, you can use Beans, also called POJOs (Plain Old Java Object). You get the incoming message (which is the parameter of the method) and return an outgoing message, as shown in the following snipped:

public class TransformationBean {

public String makeUpperCase(String body) {

String transformedBody = body.toUpperCase();

return transformedBody;

}

}

The above bean receives a String, transforms it, and finally sends it to the next endpoint. Look at the route above again. The incoming message is a File. You may wonder why this works? Apache Camel offers another powerful feature: More than 150 automatic type converters are included from scratch, e.g. FileToString, CollectionToObject[] or URLtoInputStream. By the way: Further type converters can be created and added to the CamelContext easily [7].

If a Bean only contains one single method, it even can be omitted in the route. The above call therefore could also be .bean(new TransformationBean()) instead of .bean(new TransformationBean(), “makeUpperCase”).

Adding some more Enterprise Integration Patterns

The above route transforms incoming orders using the Translator EIP before processing them. Besides this transformation, some more work is required to realize the whole use case. Therefore, some more EIPs are used in the following example:

public class IntegrationRoute extends RouteBuilder {

@Override

public void configure() throws Exception {

from(“file:target/inbox”)

.process(new LoggingProcessor())

.bean(new TransformationBean())

.unmarshal().csv()

.split(body().tokenize(“,”))

.choice()

.when(body().contains(“DVD”))

.to(“file:target/outbox/dvd”)

.when(body().contains(“CD”))

.to(“activemq:CD_Orders”)

.otherwise()

.to(“mock:others”);

}

}

Each csv file illustrates one single order containing one or more order items. The camel-csv component is used to convert the csv message. Afterwards, the Splitter EIP separates each order item of the message body. In this case, the default separator (a comma) is used. Though, complex regular expressions or scripting languages such as XPath, XQuery or SQL can also be used as splitter.

Each order item has to be sent to a specific processing unit (remember: there are dvd orders, cd orders, and other orders which are sent to a partner). The content-based router EIP solves this problem without any individual coding efforts. Dvd orders are processed via a file directory whilst cd orders are sent to a JMS queue.

ActiveMQ is used as JMS implementation in this example. To add ActiveMQ support to a Camel application, you only have to add the related maven dependency for the camel-activemq component or add the JARs to the classpath manually. That’s it. Some other components need a little bit more configuration, once. For instance, if you want to use WebSphere MQ or another JMS implementation instead of ActiveMQ, you have to configure the JMS provider.

All other order items besides dvds and cds are sent to a partner. Unfortunately, this interface is not available, yet. The Mock component is used instead to simulate this interface momentarily.

The above example shows impressively how different interfaces (in this case File, JMS, and Mock) can be used within one route. You always apply the same syntax and concepts despite very different technologies.

Automatic Unit and Integration Tests

Automatic tests are crucial. Nevertheless, it usually is neglected in integration projects. The reason is too much efforts and very high complexity due to several different technologies.

Apache Camel solves this problem: It offers test support via JUnit extensions. The test class must extend CamelTestSupport to use Camel’s powerful testing capabilities. Besides additional assertions, mocks are supported implicitly. No other mock framework such as EasyMock or Mockito is required. You can even simulate sending messages to a route or receiving messages from it via a producer respectively consumer template. All routes can be tested automatically using this test kit. It is noteworthy to mention that the syntax and concepts are the same for every technology, again.

The following code snipped shows a unit test for our example route:

public class IntegrationTest extends CamelTestSupport {

@Before

public void setup() throws Exception {

super.setUp();

context.addRoutes(new IntegrationRoute());

}

@Test

public void testIntegrationRoute() throws Exception {

// Body of test message containing several order items

String bodyOfMessage = “Harry Potter / dvd, Metallica / cd, Claus Ibsen –

Camel in Action / book “;

// Initialize the mock and set expected results

MockEndpoint mock = context.getEndpoint(“mock:others”,

MockEndpoint.class);

mock.expectedMessageCount(1);

mock.setResultWaitTime(1000);

// Only the book order item is sent to the mock

// (because it is not a cd or dvd)

String bookBody = “Claus Ibsen – Camel in Action / book”.toUpperCase();

mock.expectedBodiesReceived(bookBody);

// ProducerTemplate sends a message (i.e. a File) to the inbox directory

template.sendBodyAndHeader(“file://target/inbox”, bodyOfMessage, Exchange.FILE_NAME, “order.csv”);

Thread.sleep(3000);

// Was the file moved to the outbox directory?

File target = new File(“target/outbox/dvd/order.csv”);

assertTrue(“File not moved!”, target.exists());

// Was the file transformed correctly (i.e. to uppercase)?

String content = context.getTypeConverter().convertTo(String.class, target);

String dvdbody = “Harry Potter / dvd”.toUpperCase();

assertEquals(dvdbody, content);

// Was the book order (i.e. „Camel in action“ which is not a cd or dvd) sent to the mock?

mock.assertIsSatisfied();

}

}

The setup method creates an instance of CamelContext (and does some additional stuff). Afterwards, the route is added such that it can be tested. The test itself creates a mock and sets its expectations. Then, the producer template sends a message to the „from“ endpoint of the route. Finally, some assertions validate the results. The test can be run the same way as each other JUnit test: directly within the IDE or inside a build script. Even agile Test-driven Development (TDD) is possible. At first, the Camel test has to be written, before implementing the corresponding route.

If you want to learn more about Apache Camel, the first address should be the book „Camel in Action“ [8], which describes all basics and many advanced features in detail including working code examples for each chapter. After whetting your appetite, let’s now discuss when to use Apache Camel…

Alternatives for Systems Integration

Figure 3 shows three alternatives for integrating applications:

• Own custom Solution: Implement an individual solution that works for your problem without separating problems into little pieces. This works and is probably the fastest alternative for small use cases. You have to code all by yourself.

• Integration Framework: Use a framework, which helps to integrate applications in a standardized way using several integration patterns. It reduces efforts a lot. Every developer will easily understand what you did. You do not have to reinvent the wheel each time.

• Enterprise Service Bus (ESB): Use an ESB to integrate your applications. Under the hood, the ESB often also uses an integration framework. But there is much more functionality, such as business process management, a registry or business activity monitoring. You can usually configure routing and such stuff within a graphical user interface (you have to decide at your own if that reduces complexity and efforts). Usually, an ESB is a complex product. The learning curve is much higher than using a lightweight integration framework. Though, therefore you get a very powerful tool, which should fulfill all your requirements in large integration projects.

Figure 3: Alternatives for Systems Integration

If you decide to use an integration framework, you still have three good alternatives in the JVM environment: Spring Integration [9], Mule [10], and Apache Camel. They are all lightweight, easy to use and implement the EIPs.  Therefore, they offer a standardized way to integrate applications and can be used even in very complex integration projects. A more detailed comparison of these three integration frameworks can be found at [11].

My personal favorite is Apache Camel due to its awesome Java, Groovy and Scala DSLs, combined with many supported technologies. Spring Integration and Mule only offer XML configuration. I would only use Mule if I need some of its awesome unique connectors to proprietary products (such as SAP, Tibco Rendevous, Oracle Siebel CRM, Paypal or IBM’s CICS Transaction Gateway). I would only use Spring Integration in an existing Spring project and if I only need to integrate widespread technologies such as FTP, HTTP or JMS. In all other cases, I would use Apache Camel.

Nevertheless: No matter which of these lightweight integration frameworks you choose, you will have much fun realizing complex integration projects easily with low efforts. Remember: Often, a fat ESB has too much functionality, and therefore too much, unnecessary complexity and efforts. Use the right tool for the right job!

Apache Camel is ready for Enterprise Integration Projects

Apache Camel already celebrated its fourth birthday in July 2011 [12] and represents a very mature and stable open source project. It supports all requirements to be used in enterprise projects, such as error handing, transactions, scalability, and monitoring. Commercial support is also available.

The most important gains is its available DSLs, many components for almost every thinkable technology, and the fact, that the same syntax and concepts can be used always – even for automatic tests – no matter which technologies have to be integrated. Therefore, Apache Camel should always be evaluated as lightweight alternative to heavyweight ESBs. Get started by downloading the example of this article. If you need any help or further information, there is a great community and a well-written book available.

About the author

Kai Wähner works as an IT-Consultant at MaibornWolff et al in Munich, Germany. His main area of expertise lies within the fields of Java EE, SOA and Cloud Computing.

He is speaker at international IT conferences such as Jazoon or Confess, writes articles for professional journals, and shares his experiences with new technologies on his blog (www.kai-waehner.de/blog). Contact: kontakt@kai-waehner.de or Twitter: @KaiWaehner.

Sources:

• [1] „Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions“, ISBN: 0321200683, Gregor Hohpe, Bobby Woolf
• [2] Apache Camel http://camel.apache.org
• [3] Internal DSL http://martinfowler.com/bliki/DomainSpecificLanguage.html
• [4] Camel Archetypes http://camel.apache.org/camel-maven-archetypes.html
• [5] Example Code for this Article at github https://github.com/megachucky/camel-infoq
• [6] Reduced Dependency on Spring JARs http://davsclaus.blogspot.com/2011/08/apache-camel-29-reduced-dependency-on.html
• [7] Camel Type Converter http://camel.apache.org/type-converter.html
• [8] “Camel in Action”, ISBN: 1935182366, Claus Ibsen, Jonathan Anstey, Hadrian Zbarcea
• [9] Spring Integration www.springsource.org/spring-integration
• [10] Mule ESB http://www.mulesoft.org
• [11] Comparison of Apache Camel, Mule ESB and Spring Integration http://www.kai-waehner.de/blog/2012/01/10/spoilt-for-choice-which-integration-framework-to-use-spring-integration-mule-esb-or-apache-camel
• [12] Fourth Birthday of Apache Camel http://camel.apache.org/2011/07/07/happy-birthday-camel.html

The post Apache Camel Tutorial – Introduction to EIP, Routes, Components, Testing, and other Concepts appeared first on Kai Waehner.

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 (not just Glassfish as reference implementation). 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“…

Therefore, I think it is very important to start with a short overview and history of both alternatives. Afterwards, I will list the differences of both and explain why these differences lead me to JEE instead of Spring for most new Java projects. I am explicitly talking about new applications. If you have to extend an existing application, continue using the existing framework!

One more disclaimer: I am talking about mission-critical Enterprise Java applications. I am not talking about a little internal application or other uncritical stuff. I also would prefer using a combination of Scala, Groovy and Clojure persisting to a NoSQL database while being deployed at a PaaS cloud service such as JBoss OpenShift or VMware CloudFoundry…

General Information about JEE and Spring

First, I want to summarize some general information about JEE and Spring:

• In the end, both alternatives consist of several libraries which can be used by developers to create enterprise applications.
• Both can be used in most use cases, they have very similar functionality (business logic, transactions, web-frameworks, whatever…) – they only differ in realization (e.g. declarative transactions in Spring vs. conventions in JEE).
• You also can use only one or some of the available libraries. You can even combine JEE and Spring stuff.
• Usually, the crucial question is: „Should I use JEE (i.e. especially EJB, JPA, CDI, etc.) or the Spring core framework (i.e. especially Spring Application Context, Spring beans, etc.) for realizing my new application? Mostly, you can choose both, it does not matter from the point of view of the end user. But you should not merge both, this only creates higher complexity.
• There always was a debate about which alternative to choose. It is very difficult to discuss this question in a neutral way. That’s why almost all discussions end up in praising one framework and bashing the other one (I hope to be neutral in this blog post).

History: J2EE was horrible, so Spring helped!

J2EE was horrible. So much XML configuration, so many interfaces, and so lame application servers. This is why the Spring framework was created. It solved many problems of J2EE. It was lightweight, easy to use, and applications could be deployed in a  web container (such as Tomcat) instead of a heavy J2EE application server. Deployment took seconds instead of 15 minutes. Unfortunately, JRebel did not exist at that time. The Spring framework is no standard as J2EE, nevertheless it became very widespread and an large community arose.

Today: J2EE is dead. JEE „stole“ the lightweight Spring ideas!

Everything started with a little shortcut change. J2EE was dead. The new shortcut was JEE. JEE 5 was born in 2006. It „stole“ many good, lightweight ideas such as „convention over configuration“ or „dependency injection“ from Spring and other frameworks. Yes, JEE application servers still were heavy, and testing was almost impossible. Nevertheless, developing JEE applications was fun with JEE 5. You did not have to write 20 interfaces when creating an EJB. Wow, amazing!

Then, in 2009, JEE 6 was released. Development is so easy. Finally! For example, you have to add only one annotation and your EJB is ready! Of course, the developers of the Spring framework did not sleep. Much new stuff was added. Today, you can create a Spring application without any one XML file as I have read in a „No Fluff Just Stuff“ article some weeks ago. Besides, several really cool frameworks were added to the Spring stack, e.g. Spring Integration, Spring Batch or Spring Roo.

Today (November, 2011), both JEE and Spring are very widespread and have a large community. Much information is available for both, e.g. books, blogs, tutorials, etc.

So, after I have described the evolution of JEE and Spring, why will I use JEE in most new Java projects?

Pros and Cons of JEE and Spring

A decision must be made. Which alternative to use in new projects? Let’s look at the pros and cons of both. I will add a „BUT“ to the Spring advantages – these „BUTs“ are the reason why I prefer JEE to Spring.

Advantages of JEE

• JEE is a set of standard specifications, thus it is vendor-independent. Usually, several implementations exist of a specification.
• Sustainability: Well, this is the advantage of a standard which is supported by several big players.
• Yes, believe it or not, testing is possible! Lightweight application servers and frameworks such as Arquillian arrived in the JEE world!
• Convention over Configuration is everywhere instead of explicit (I know that some people will disagree that this is an advantage).

Advantages of Spring

• You do not need a heavy JEE application server, you can deploy your application in a web container such as Tomcat.

BUT: JEE application servers are not as heavy as they were some years ago. Besides, the JEE web profile can be used, too. You do not have to use a Tomcat or Jetty to be lightweight!

• Spring offers features which are not available as JEE standards, such as Spring Batch.

BUT: You can add such a library to a JEE project without problems. You can also add other Spring libraries such as JDBCTemplate or JMSTemplate (which help reducing some boilerplate code) if you want.

• Spring offers much more flexiblity and power, e.g. aspect-oriented programming is more powerful than JEE interceptors.

BUT: In most projects you do not need this flexibility or power. If you do need it, then use Spring, not JEE – of course!

• Faster Releases (because it is no standard and only one vendor). The reaction to market requirements is much faster. Some current examples: cloud, mobile, social computing.

BUT: All enterprise projects – of many different clients – which I have seen, are not that flexible. Enterprise applications do not change every month or year. If there is a project, where you can change your version very easily, Spring might be better than JEE under some circumstances. But in most enterprise projects, you cannot simply upgrade from Spring 2.5 to Spring 3.x or from JEE 5 to JEE 6. I wish this would be possible, but low flexibility and politics rule in large companies with thousands of employees.

Conclusion: I will use JEE in most new Enterprise Java Projects

Due to the reasons I explained against Spring in the „BUT“ parts, I will choose JEE in most new Enterprise Java projects. Nevertheless, I will sometimes use a Spring libraries, too (such as Spring Batch). Sometimes, I will even have to use Spring (if I need its flexibility or power), but only then I will choose it. Of course, for existing projects, I will continue using the framework that is used already. I would probably not migrate a Spring 2.5 application to JEE, but I would migrate it to Spring 3.x instead!

So, I have described my reasons why I will use JEE in most new Enterprise Java projects. If I have missed something, or if you have got another opinion (probably many guys have), you can bash me in the comments. I appreciate all „non-flame-war“ discussions…

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post Why I will use Java EE (JEE, and not J2EE) instead of Spring in new Enterprise Java Projects in 2012 appeared first on Kai Waehner.

Registration to AWS and Setup of Camel

First, you have to register to the Amazon Web Services (for free). Most AWS services include a free monthly quota, which is absolutely sufficient to play around and develop some simple applications. As its name states, AWS uses technology-independent web services. Besides, APIs for several different programming languages are available to ease development. By the way, Camel uses the AWS SDK for Java (http://aws.amazon.com/sdkforjava), of course. The documentation is detailed and easy to understand, including tutorials, screenshots and code examples .

Hint 1:

You should read the introductions to S3, SQS and SNS (go to http://aws.amazon.com and click on „products“) and play around with the AWS Management Console (http://aws.amazon.com/console) before you continue. This step is very easy and takes less than one hour. Then, you will have a much better understanding about AWS and where Camel can help you!

Hint 2:

It really helps to look at the source code of the camel-aws component, It helps you to understand how Camel uses the AWS Java API internally. If you want to write tests, you can do it the same way. In the past, I was afraid of looking at „complex“ source code of open source frameworks. But there is no need to be scared! The camel-aws component (and most other camel components) contain only of a few classes. Everything is easy to understand. It helps you to understand Camel internals, the AWS API, and to spot and solve errors due to exceptions in your code.

In the meanwhile, the current Camel version 2.8 supports three AWS services: S3, SQS and SNS. All of them use similar concepts. Therefore, they are included in one single camel component: „camel-aws“. You have to add the libraries to your existing Camel project. As always, the simplest way is to use Maven and add the following dependency to the pom.xml:

<dependency>

<groupId>org.apache.camel</groupId>

<artifactId>camel-aws</artifactId>

<version>${camel-version}</version>

</dependency>

Configuration of the Camel Endpoint

The implementation and configuration of all three services is very similar. The URI looks like this (the code shows the SQS service):

aws-sqs://queue-name[?options]

There are two alternatives to configure your endpoint.

Using Parameters

The easy way is to use two paramters in the URI of your endpoint: „accessKey“ and „secretKey“ (you receive both after your AWS registration).

“aws-sqs://unique-queue-name?accessKey=“INSERT_ME“&secretKey=INSERT_ME”

Be aware of the following problem, which can result in a strange, non-speaking exception (thanks to Brendan Long):

You’ll need to URL encode any +’s in your secret key (otherwise, they’ll
be treated as spaces). + = %2B, so if your secretkey was
“my+secret\key”, your Camel URL should have “secretKey=my%2Bsecret\key”.

“Within the query string, the plus sign is reserved as shorthand
notation for a space. Therefore, real plus signs must be encoded. This
method was used to make query URIs easier to pass in systems which did
not allow spaces.”

Source: WC3 URI Recommendations
<http://www.w3.org/Addressing/URL/4_URI_Recommentations.html#z5>

Adding a configured AmazonClient to the Registry

If you need to do more configuration (e.g. because your system is behind a firewall), you have to add an AmazonClient object to your registry. The following code shows an example using SQS, but SNS and S3 use exactly the same concept.

@Override

protected JndiRegistry createRegistry() throws Exception {

JndiRegistry registry = super.createRegistry();

AWSCredentials awsCredentials = new BasicAWSCredentials(“INSERT_ME”, “INSERT_ME”);

ClientConfiguration clientConfiguration = new ClientConfiguration();

clientConfiguration.setProxyHost(“http://myProxyHost”);

clientConfiguration.setProxyPort(8080);

AmazonSQSClient client = new AmazonSQSClient(awsCredentials, clientConfiguration);

registry.bind(“amazonSQSClient”, client);

return registry;

}

This example overwrites the createRegistry() method of a JUnit test (extending CamelTestSupport). You can also add this information to your runtime Camel application, of course.

Apache Camel and the Simple Storage Service (S3)

Simple Storage Service (S3) is a key-value-store. You can store small to very large data. The usage is very easy. You create buckets and put key-value data into these buckets. You can also create folders within buckets to organize your data. That’s it. You can monitor your buckets using the AWS Management Console – an intuitive GUI supporting most AWS services.

The following example shows both alternatives for accessing the Amazon services (as described above): Paramenters and the AmazonClient.

// Transfer data from your file inbox to the AWS S3 service

from(“file:files/inbox”)

// This is the key of your key-value data

.setHeader(S3Constants.KEY, simple(“This is a static key”))

// Using parameters for accessing the AWS service

.to(“aws-s3://camel-integration-bucket-mwea-kw?accessKey=INSERT_ME&secretKey=INSERT_ME&region=eu-west-1”);

// Transfer data from the AWS S3 service to your file outbox

from(“aws-s3://camel-integration-bucket-mwea-kw?amazonS3Client=#amazonS3Client&region=eu-wes”)

.to(“file:files/outbox”);

There are some additional parameters, for instance you can submit the desired AWS region or delete data after receiving it (see http://camel.apache.org/aws-s3.html and the corresponding SQS and SNS sites for more details about parameters and message headers).

As you see in the code, you can use the AWS-S3 endpoint for producing and for consuming messages. Each bucket must be unique, thus you have to add some specific information such as your company to its name.

Hint:

If a bucket does not exist, Camel is creating it automatically (as the AWS API does). This concept is also used for SQS queues and SNS topics.

Apache Camel and the Simple Queue Service (SQS)

The Simple Queue Service (SQS) is similar to a JMS provider such as WebSphere MQ or ActiveMQ (but with some differences). You create queues and send messages to them. Consumers receive the messages. Contrary to most other AWS services, you cannot monitor queues by using the AWS management console directly. You have to use the service „Cloudwatch“ (http://aws.amazon.com/cloudwatch) and start an EC2 instance to monitor queues and its content.

As you can see in the following code example, the syntax and concepts are almost the same as for the S3 service:

from(“file:inbox”)

.to(“aws-sqs://camel-integration-queue-mwea-kw?accessKey=INSERT_ME&secretKey=INSERT_ME”);

from(“aws-sqs://camel-integration-queue-mwea-kw?amazonSQSClient=#amazonSQSClient”)

.to(“file:outbox?fileName=sqs-${date:now:yyyy.MM.dd-hh:mm:ss:SS}”);

Again, you can use the AWS-SQS endpoint for producing and for consuming messages. Each queue name must be unique.

There exist two important differences to JMS (copy & paste from the AWS documentation):

Q: How many times will I receive each message?

Amazon SQS is engineered to provide “at least once” delivery of all messages in its queues. Although most of the time each message will be delivered to your application exactly once, you should design your system so that processing a message more than once does not create any errors or inconsistencies.

Q: Why are there separate ReceiveMessage and DeleteMessage operations?

When Amazon SQS returns a message to you, that message stays in the queue, whether or not you actually received the message. You are responsible for deleting the message; the delete request acknowledges that you’re done processing the message. If you don’t delete the message, Amazon SQS will deliver it again on another receive request.

Apache Camel and the Simple Notification Service (SNS)

The Simple Notification Service (SNS) acts like JMS topics. You create a topic, consumers subscribe to the topic and then receive notifications. Several transport protocols are supported: HTTP(S), Email and SQS. Further interfaces will be added in the future, e.g. the Short Message Service (SMS) for mobile phones.

Contrary to S3 and SQS, Camel only offers a producer endpoint for this AWS service. You can only create topics and send messages via Camel. The reason is simple: Camel already offers endpoints for consuming these messages: HTTP, Email and SQS are already available.

There is one tradeoff: A consumer cannot subscribe to topics using Camel – at the moment. The AWS Management Console has to be used. A very interesting discussion can be read on the Camel JIRA issue regarding the following questions: Should Camel be able to subscribe to topics? Should the producer contain this feature or should there be a consumer? In my opinion, there should be a consumer which is able to subscribe to topics, otherwise Camel is missing a key part of the AWS SNS service! Please read the discussion and contribute your opinion: https://issues.apache.org/jira/browse/CAMEL-3476.

Apache Camel is already ready for the Cloud Computing Era

AWS offers many more services for the cloud. Probably, it does not make sense to integrate everyone into Camel, but more AWS services will be supported in the future. For instance, SimpleDB and the Relational Database Service (RDS) are already planned and make sende, too: http://camel.apache.org/aws.html.

The conclusion is easy: Apache Camel is already ready for the cloud computing era. Several important cloud services are already supported. Cloud integration will become very important in the future. Thus, Camel is on a very good way. Hopefully, we will see more cloud components, soon.

I will continue to write articles about other Camel cloud components (and new AWS addons, ouf course). For instance, a component for the  Platform as a Service (PaaS) product Google App Engine (GAE) is already available.

If you have any additional important information, questions or other feedback, please write a comment. Thank you in advance…

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post Cloud Integration with Apache Camel and Amazon Web Services (AWS): S3, SQS and SNS appeared first on Kai Waehner.

Deployment of a GAE Application to the Cloud

A very good introductory article, which describes the combination of Spring Roo and GAE, already exists here: http://java.dzone.com/articles/creating-application-using. In a nutshell, there is not much to do to deploy your (CRUD-) application in the GAE cloud. You have to choose another database provider, enter your GAE application id in a configuration file and deploy the application using one single Maven command (mvn gae:deploy). That is the difference to „traditional“ Roo applications. Thus, no rocket science! Nevertheless, there are several restrictions for developing GAE applications, for instance you cannot use @OneToMany annotations to specify relations due to NoSQL concepts. Deployment will fail respectively the application will not work as expected if you do not follow the rules.

GAE is much more than just deploying a traditional Web Application to the Cloud

So, after reading the previous paragragh, the conlusion is the following: Spring Roo supports deploying  its applications to the GAE cloud. Thus, everything is fine? No, not at all!

Yes, you can deploy your CRUD application to the GAE cloud (if you do not use relations), but GAE is much more. You can or rather should use Task Queues to segment your long-running work, the BigTable datastore and blobstore to store your data, use the URL fetch service to communicate to other applications using HTTP(S), and several other GAE services such as XMPP, Memcache, Mail, and so on. The number of available services further increases with new GAE releases.

These GAE services exist for some reasons: You should be able to create a cloud application which scales automatically without any manual server configuration and such stuff. That is the reason why you have to use NoSQL database concepts and Fetch URL instead of a SQL database, Threads, socket programming, and the other techniques which you used in the past when not developing an application for the cloud. Google developers are NOT too dumb to support SQL databases, but it is not the appropriate technology for highly scaling cloud applications. A nice article about „SQL versus NoSQL“ can be found here: http://java.dzone.com/news/sql-vs-nosql-cloud-which

Several Spring Roo Commands are missing for developing GAE Applications

Spring Roo has no special GAE command. You use the persistence command to create support for BigTable, and you use a Maven goal to deploy the GAE application. Besides, there are no GAE commands although you would need them to create your Task Queues, BigTable datastore access (including relations), URL fetches, and so on. You have to code everything by yourself, as you have to do without Spring Roo. Thus, there is no real support for GAE, yet – contrary to Cloud Foundry (as we will see in part 2 of this article series). Of course, VMware wants to push its own PaaS solution, I understand that. Nevertheless, Spring Roo should also offer good support for other solutions as it does for web frameworks (in the meantime, there is offical support for Spring MVC and GWT, besides plugins for Vaadin, Flex and JSF are available respectively in work).

GAE is the only stable, production-ready PaaS Solution in the Java environment

Be aware that GAE is the only stable and production-ready PaaS solution in the Java environment at the moment. Other offerings such as Cloud Foundry or Red Hat OpenShift are still in BETA status. Also be aware that there exist reasons why Google is not offering SQL database support yet. They will probably add this feature in the future, because public criticism is huge. Nevertheless, NoSQL databases will be required in many use cases where you want to deploy your application in the cloud. Thus, I hope that Spring Roo will offer better GAE support in future versions.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post Rapid Cloud Development with Spring Roo – Part 1: Google App Engine (GAE) appeared first on Kai Waehner.

Apache Camel already offers Components for several Cloud Interfaces

Probably, it will take some months (or years) until enterprise projects need to integrate different clouds. Nevertheless, Apache Camel already offers several components for these tasks. You can integrate clouds using the same concepts as you use for integration of HTTP, FTP, JMS, JDBC, and all other Camel components. That is the biggest advantage of this integration framework, in my opinion.

IaaS Integration

Infrastructure as a Service (IaaS) offers a broad range of use cases. You can rent whole servers where you install whatever operating system and applications you want. You can integrate everything as you do it today with your common servers. IaaS also offers computing services (e.g. Amazon Elastic Compute Cloud – EC2) and storage services (e.g. Amazon Relational Database Service – RDS, SimpleDB or Simple Storage Service – S3). Camel already offers components to communicate directly with some of these IaaS services.

PaaS Integration

Platform as a Service (PaaS) offers a development container where you can deploy your application. Several restrictions exist, e.g. Google App Engine (GAE) has a white list of Java classes which are allowed. Further, no SQL database can be used at the moment. VMware Cloud Foundry is an open source example which offers MySQL support besides NoSQL databases. Camel already offers components to connect to GAE applications. The benefit of PaaS is that once you know the programming model, you can develop and deploy cloud applications very easily with automatic, elastic high availablity.

SaaS Integration

Software as a Service (PaaS) means using web applications in your web browser. Gmail is a very well-known, simple example. Salesforce is a better example for business applications. In fact, it is easy to use these SaaS applications. But if you want to integrate them, you still need a programming interface to each SaaS application which you want to integrate. For instance, Camel offers a component to send emails via Gmail. Some products already offer documentation how to integrate their SaaS application to Camel (here you can see an example from Hippo CMS: http://hst-salesforce.forge.onehippo.org/usingtasks.html).

The Number of Cloud Computing Solutions will increase a lot in the Future

Above, I mentioned some examples of IaaS, PaaS and SaaS alternatives.  Of course, the number of products and solutions will increase a lot within the next months and years. Let’s list some more brands which are already available: Rackspace Cloud, CloudBees, Windows Azure, Elastic Bean Stalk, vCloud, AppForce, Hyper-V Cloud.

Apache Camel is future-proof for the Cloud Computing Era

As you can see, Apache Camel already offers several components for cloud computing offerings. Hopefully, many more components will be created for other coming cloud interfaces (BTW: I am sure this will happen). Different clouds will need to be integrated. Apache Camel has great potential to use the same concepts (routes, processors, test support, and so on) to integrate all these different cloud concepts and technologies. Nevertheless, you can still choose between „old style“ DSLs (using Java or Spring XML) and  new modern JVM programming languages (using Groovy or Scala). In the next months, I will show more blogs which will show code examples to describe how to integrate the different cloud interfaces, starting with Amazon services (IaaS), Google App Engine (PaaS) and Salesforce (SaaS), as these components are already available…

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post Cloud Computing Heterogeneity will require Cloud Integration – Apache Camel is already prepared! appeared first on Kai Waehner.

Problems when Starting with this Combination

I had several problems finding good resources for starting when I first tried to combine them. I have a lot of Camel experience, but only basic Scala knowledge. I tried to start with some projects which where already available in the web (e.g. from the „Camel in Action“ book or other Git examples).

I could not get them ready to run in IntelliJ IDEA (and Eclipse Scala plugin is still not really stable, at least on my Mac). The examples either used way too many Scala features (and thus contained very complex source code for a Scala beginner), were too basic (here I mean the camel-scala archetype) or did not work because of problems with IDE support or version problems with Maven, Scala, and so on.

Nevertheless, it is also tough to create a Camel project (and even more a Camel Scala project) from scratch without Maven because of so many dependencies. Thus, I created my own „getting started“ project with current versions of Camel (2.7.1) and Scala (2.9). Of course, you can change the version in the maven configuration.

You can download the whole project from Github at https://github.com/megachucky/MavenCamelScala. If you wanna use my project you have to either use Intellij IDEA or uncomment some configuration stuff in the pom.xml file to use it within Eclipse.

Camel and Scala Concepts shown in this Example

This example just shows the most important Camel features for getting started (all in very simple forms) – this includes Routes, Processors, Beans, CamelContext, ErrorHandling and Testing. Besides, only some advanced Scala features are used. This project is easy to understand and extendable to play around with this combination. In the following, only some code snippets will be shown, please download the project at Git if you want to see everything.

CamelContext

You use the CamelContext as you do in Java.

Routes

Scala Routes extend the Java class „RouteBuilder“ as Java Routes do, but they also use several features of Scala. Shorter Scala syntax is implicitly used (no semicolons, dots and parantheses, no constructor). Implicit conversions are another advanced Scala feature. For example, you do not have to use a „from“-method as you have to in Java. Overwriting operators such as „+“ or creating new operators such as „–>“ is another Scala feature shown here.

Processors and Beans

Here you can reduce the lines of code a lot by just using Scala source code instead of Java source code. Nevertheless, you can still call other Java libraries as you did until now.

By the way: You could also use a closure to implement the „process“-method and then assign it to a variable.

Testing

You simply use the CamelTestSupport API from the Java DSL. Besides, you can mix in further traits. In this example, traits are used to include the testing framework ScalaTest. Traits are very powerful for adding more functionality!

In the Git source code, there is one more example, where traits are used to add default error handling to a route (therefore the route extends the „ErrorLog“ trait).

Advantages of using Camel combined with Scala

There are two main advantages. You can reduce the lines of code a lot. This reduces efforts in time to write code, but also in maintenance (code analysis and refactoring of code). You also have several powerful features which are offered by the Scala language, e.g. mixing in more than one trait.

Nevertheless, you can still use all of your Java libraries (as you have seen with the Camel classes which are used within the Scala code).

Conclusion

This article showed the basic Camel concepts realized with Scala. Be aware that not all Enterprise Integration Patterns (EIP) are implemented in Scala DSL yet, but this will happen soon, hopefully. The available documentation and code examples is also still not very comprehensive, maybe this article will help some people for getting started.  Despite of these concerns, you should really try out this combination, because both Apache Camel and Scala have a promising future in the JVM environment! My final conclusion: Apache Camel combined with Scala is a very powerful combination.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post Apache Camel and Scala: A Powerful Combination appeared first on Kai Waehner.

The Problem: Enterprise Application Integration (EAI)

Enterprise application integration is necessary in almost every company due to new products and applications. Integrating these applications creates several problems. New paradigms come up every decade, for example client / server communication, Service-oriented Architecture (SOA) or Cloud Computing.

Besides, different interfaces, protocols and technologies emerge. Instead of storing data in files in the past (many years ago), SQL databases are used often today. Sometimes, even NoSQL databases are required in some usecases. Synchronous remote procedure calls or asynchronous messaging is used to communicate via several technologies such as RMI, SOAP Web Services, REST or JMS. A lot of software silos exists. Nevertheless, all applications and products of these decades have to communicate with each other to work together perfectly.

Enterprise Integration Patterns (EIP)

Of course, you could reinvent the wheel for each problem, write some spaghetti code and let the applications work together. Unfortunately, your management will not like the long-term perspective of this solution.

Enterprise Integration Patterns (www.eaipatterns.com) help to fragment problems and use standardized ways to integrate applications. Using these, you always use the same concepts to transform and route messages. Thus, it is a good idea to forget about reinventing the wheel each time you have a problem.

Alternatives for integrating Systems

Three alternatives exist for integrating applications. EIPs can be used in each solution.

Solution 1: Own custom Solution

Implement a individual solution that works for your problem without separating problems into little pieces. This works and is probably the fastest alternative for small use cases. You have to code all by yourself. Maintenance will probably be high if team members change.

Solution 2: Integration Framework

Use a framework which helps to integrate applications in a standardized way using several integration patterns. It reduces efforts a lot. Every developer will easily understand what you did (if he knows the used framework).

Solution 3: Enterprise Service Bus (ESB)

Use an enterprise service bus to integrate your applications. Under the hood, the ESB also uses an integration framework. But there is much more functionality, such as business process management, a registry or business activity monitoring. You can usually configure routing and such stuff within a graphical user interface – you have to decide at your own if that reduces complexity and efforts. Usually, an ESB is a complex product. The learning curve is much higher. But therefore you get a very powerful tool which should offer all your needs.

What is Apache Camel?

Apache Camel is a lightweight integration framework which implements all EIPs. Thus, you can easily integrate different applications using the required patterns. You can use Java, Spring XML, Scala or Groovy. Almost every technology you can imagine is available, for example HTTP, FTP, JMS, EJB, JPA, RMI, JMS, JMX, LDAP, Netty, and many, many more (of course most ESBs also offer support for them). Besides, own custom components can be created very easily.

You can deploy Apache Camel as standalone application, in a web container (e.g. Tomcat or Jetty), in a JEE application Server (e.g. JBoss AS or WebSphere AS), in an OSGi environment or in combination with a Spring container.

If you need more information about Apache Camel, please go to its web site as starting point: http://camel.apache.org. This article is no technical introduction J

When to use Apache Camel?

Apache Camel is awesome if you want to integrate several applications with different protocols and technologies. Why? There is one feature (besides supporting so many technologies and besides supporting different programming languages) which I really appreciate a lot: Every integration uses the same concepts! No matter which protocol you use. No matter which technology you use. No matter which domain specific language (DSL)  you use – it can be Java, Scala, Groovy or Spring XML. You do it the same way. Always! There is a producer, there is a consumer, there are endpoints, there are EIPs, there are custom processors  / beans (e.g. for custom transformation) and there are parameters (e.g. for credentials).

Here is one example which contains all of these concepts using the Java DSL:

from(„activeMQ:orderQueue“)..transaction().log(„processing order“).to(mock:“notYetExistingInterface“)

Now let’s look at another example using the Scala DSL:

„file:incomingOrders?noop=true“ process(new TransformationProcessor) to „jdbc:orderDatastore“

If you are a developer, you should be able to recognize what these routes do, don’t you?

Two other very important features are the support for error-handling (e.g. using a dead letter queue) and automatic testing. You can test EVERYTHING very easily using a Camel-extension of JUnit! And again, you always use the same concepts, no matter which technology you have to support.

Apache Camel is mature and production ready. It offers scalability, transaction support, concurrency and monitoring. Commercial support is available by FuseSource: http://fusesource.com/products/enterprise-camel

When NOT to use Apache Camel?

Well, yes, there exist some use cases where I would not use Apache Camel. I have illustrated this in the following graphic (remember the three alternatives I mentioned above: own custom integration, integration framework, enterprise service bus).

If you have to integrate just one or two technologies, e.g. reading a file or sending a JMS message, it is probably much easier and faster to use some well known libraries such as Apache Commons IO or Spring JmsTemplate. But please do always use these helper classes, pure File or JMS integration with try-catch-error is soooo ugly!

Although FuseSource offers commercial support, I would not use Apache Camel for very large integration projects. An ESB is the right tool for this job in most cases. It offers many additional features such as BPM or BAM. Of course, you could also use several single frameworks or products and „create“ your own ESB, but this is a waste of time and money (in my opinion).

Several production-ready ESBs are already available. Usually, open source solutions are more lightweight than commercial products such as WebSphere Message Broker (you probably need a day or two just to install the evaluation version of this product)! Well-known open source ESBs are Apache ServiceMix, Mule ESB and WSO2 ESB. By the way: Did you know that some ESB base on the Apache Camel framework (e.g. Apache Service Mix and the Talend ESB). Thus, if you like Apache Camel, you could also use Apache ServiceMix or the commercial Fuse ESB which is based on ServiceMix.

Conclusion

Apache Camel is an awesome framework to integrate applications with different technologies. The best thing is that you always use the same concepts. Besides, support for many many technologies, good error handling and easy automatic testing make it ready for integration projects.

Because the number of applications and technologies in each company will increase further, Apache Camel has a great future. Today we have application silos, in ten years we will probably have cloud silos which are deployed in Goggle App Engine, CloudFoundry, Amazon EC3, or any other cloud service. So I hope that Apache Camel will not oversleep to be ready for the cloud era, too (e.g. by offering components to connect to cloud frameworks easily). But that’s future… At the moment you really should try this framework out, if you have to integrate applications in the JVM / Java environment.

By the way: I know that I praise Camel in this article, but I am neither a Camel committer nor working for FuseSource. I just really like this framework.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post When to use Apache Camel? appeared first on Kai Waehner.

A keynote of Dalibor Topic (Oracle) criticizes the Java-Release-Cycles of Sun Microsystems at the Java conference „CONFESS 2011“ in Vienna, Austria. After showing the past of Java SE from version 1 to 6, he showed a SWOT analysis (Strengths, Weaknesses, Opportunities, and Threats) named „SWOT – Sun days“ (Picture from my Tweet). One weakness stated the slow release cycle of Java SE. Oracle will do a better job in the future, beginning with Java 7 in 2011 and Java 8 in 2012. Further releases (Java 9 and so on) also seem to be in planning stage already. Java shall remain the most used language!

OpenJDK will become more important  for Oracle than it was for Sun

However, a strength of Sun was the large Java community. Oracle recognized its bad name in the Java community as it was stated in the „Java SWOT – Oracle“, which followed Sun’s SWOT analysis. Oracle will re-connect to the community in the future. An important statement of the talk is related to the OpenJDK: „ I think, Open JDK will become more important for Oracle than it was for Sun.“ Therefore, JRockit content will be merged to OpenJDK. The JDK / JRE will still be free in the future, and contain the same license as before. Of course, Oracle will offer premium services such as JFR, JRMC, JFB or support.

Trends for Oracle: Multi Core, Dynamic Languages, DSLs, Cloud and Mobiles

At the end, Dalibor Topic showed which trends will be important in the Java / JVM environment for Oracle in the next years: Multi core processors, dynamic langugages, domain specific languages, cloud computing, smart phones and tablets. No surprise after all

My conclusion: The critique about the slow Java-Release-Cycles is true. The plan of Oracle for the future of Java sounds good! What do you think?

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post Oracle complains about Sun’s Java-Release-Cycles – OpenJDK will become more important appeared first on Kai Waehner.