Great Article: “What is the TCO difference between WebSphere and JBoss?”

I have spotted a really great article about comparing prices of open source and proprietary products: “What is the TCO difference between WebSphere and JBoss?“. The interesting aspect is, that this article is written by an IBM-biased company (Prolifics). Usually, only open source vendors write such comparisons. I really like this article, seriously! It is good to see comparisons not only by open source vendors, but also by vendors such as IBM (in this case, Prolifics cannot be considered unbiased, it is an IBM consulting company – but that is fine). I just want to give my two cents to this article in the following…

Features, Performance, Availability?

I definitely agree that proprietary vendors have more features, best performance, and highest availability. So, if I have got a 100 million dollar project, where I need all of these features, and where I have to deploy to 1000s of servers, then IBM (or Oracle or SAG or XYZ) might be a good choice! However, in probably 95 percent of use cases, you do not need ALL features, BEST performance, and HIGHEST availability. You just need to solve your problem! Think about this before deciding for a whole stack of proprietary products.

Regarding some other aspects: I disagree that proprietary products have got better manageability and ease of use.

Manageability?

Production-ready installations for open source products can be done within one day – without a lot of expensive consulting efforts. You cannot install the production-ready Websphere stack in one or two days! It is much more complex. Maybe you can make it to install the development edition in one or two days on your laptop. Maybe…

And what about manageability if there is a missing feature. In an open source product, you are very flexible. You can add or change features as you want. Just change the code. That’s it. As these products usually base on open source projects (e.g. Eclipse or Apache), you find all information you need, including documentation and a large community (which helps for free). If you do not want to change it by yourself, the commercial support will help you quickly and just charge the “consulting days” of implementing the new feature. You will get a new feature in a few days or weeks (depending on its size). Try to get a new feature or a change request from proprietary vendors. Good luck. You have to pay a lot of money and / or wait a very long time!

Ease of Use?

As a developer, you can just download an open source product, use an one-click-installer, and use it. Usually, the product is an unified platform, i.e. you can do everything within the development environment intuitively. You are learning by doing. If you want to use the IBM Websphere stack, you have to install several different products. Yes, they are all “Websphere”, but nevertheless, they are different products with different tooling, based on different technologies and code bases (as many of the products come from acquisitions).

Conclusion?

So again, I really like this comparison from an IBM perspective. Every decision maker should consider both views (in the case of this article JBoss and IBM), and then decide by himself. Both solutions are good, but they differ a lot – not just in pricing! Look at all products deeply, do a proof of concept, then make a decision!

What’s your opinion? Feel free to give a comment…

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post What is the TCO difference between IBM WebSphere and Open Source JBoss? – Just my two cents… 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.

What is a Portal?

It is important to know that we are talking about an Enterprise Portal. Wikipedia has a good definition:

„An enterprise portal […] is a framework for integrating information, people and processes across organizational boundaries. It provides a secure unified access point, often in the form of a web-based user interface, and is designed to aggregate and personalize information through application-specific portlets.“

Several Portal server are available in the Java / JVM environment. Liferay Portal and GateIn Portal (former JBoss Portal) are examples for open source products while Oracle Portal or IBM WebSphere Portal are proprietary products.

You develop Portlets („simple“ web applications) and deploy them in your portal. If you need to know more about a Portal or the Portlet JSR standards, ask Wikipedia: http://en.wikipedia.org/wiki/Portlet.

Should we use a Portal or not?

I found several pros and cons for using a Portal instead of just web applications.

Disadvantages of using a Portal:

• Higher complexity
  • Additional configuration (e.g. portlet.xml, Portal server)
  • Communication  between Portlets using Events is not trivial (it is also not trivial if two applications communicate without portlets, of course)
  • Several restrictions when developing a web application within a Portlet
• Additional testing efforts (test your web applications and test it within a Portal and all its Portal features)
• Additional costs
  • Open source usually offers enterprise editions which include support (e.g. Liferay)
  • Proprietary products have very high initial costs. Besides, you need support, too (e.g. Oracle)
• You still have to customize the portal and integrate applications. A portal product does not give you corporate identity or systems integration for free. Software licensing often is only ten percent of the total price.
• Developers need additional skills besides using a web framework
• Several restrictions must be considered choosing a web-framework and implement the web application
  • Rethinking about web application design is necessary
  • Portlets use other concepts such as events or an action and render phase instead of only one phase
  • Frameworks (also called bridges) help to solve this problem (but these are standardized for JSF only, a few other plugins are available, e.g. for GWT or Grails)
  • Actually, IMO you have to use JSF if you want to realize Portlets in a stable, relatively „easy“ and future-proof way. There is no standard bridge for other frameworks. There are no books, best practices, articles or conference sessions about Portlets without JSF, right?

Advantages of using a Portal

Important: Many of the pros can be realized by oneself with relatively low efforts (see red font).

• Single Sign On (SSO)

Several Java frameworks are available, e.g OpenSSO (powerful, but complicated) or JOSSO (not so powerful, but easy to use).

Good products are available, e.g. Atlassian Crowd (I love Atlassian products such as Crowd, Jira or Confluence, because they are very intuitive and easy to use).

• Integration of several applications within one GUI
  • A portal gives you layout and sequence of the applications for free (including stuff such as drag & drop, minimizing windows, and so on)
• Communication between Portlets (i.e. between different applications)

This is required without a portal, too.

Several solutions can be used, such as a database, messaging, web services, events, and so on.

Even „push“ is possible for some time now (using specific web framework features or HTML 5 websockets).

• Uniform appearence

CSS can solve this problem (the keyword „corporate identity“ exists in almost every company).

Create a HTML template and include your applications within this template. Done.

• Personalization
  • Regarding content, structure or graphical presentation
  • Based on individual preferences or metadata

Some of these features can be realized very easily by oneself (e.g. a simple role concept).

Nevertheless, GUI features such as drag & drop are more effort (although component libraries can help you a lot).

• Many addons are included
  • Search
  • Content management
  • Document management
  • Web 2.0 tools (e.g. blogs or wikis)
  • Collaboration suites (e.g. team pages)
  • Analytics and reporting
  • Development platforms

But:

A) Do you really need these Features?

B) Is the offered functionality sufficent? Portals only offer „basic“ versions of stand-alone products. For instance, the content management system or search engine of a Portal is less powerful than other „real“ products offering this functionality.

Thus, you have to think about the following central question: Do we really need all those features offered by a portal?

Conclusion:

The total cost of ownership (TCO) is much higher when using a portal. You have to be sure, that you really need the offered features.

In some situations, you can defer your decision. Create your web applications as before. You can still integrate them in a Portal later, if you really need one. For instance, the following Oracle blog describes how you can use iFrames to do this: http://blogs.oracle.com/jheadstart/entry/integrating_a_jsf_application

If you decide to use a Portal, you have to choose a Portal product.

Should we use an Open Source or Proprietary Portal Product?

Both, open source and proprietary Portal products have pros and cons. I especially looked at Oracle Portal and Liferay Portal, but probably most aspects can be considered when evaluating other products, too.

Advantages  of Oracle Portal

• Oracle offers a full-stack suite for development (including JSF and Portlets): Oracle Application Development Framework (ADF)
• Oracle JDeveloper offers good support for ADF.
• Everything from one product line increases efficiency (database, application server, ESB, IDE, Portal, …) – at least in theory J

Disadvantages of Oracle Portal:

• High initial costs (I heard something about 200K in our company)
• Complex, heavyweight product (compared to Liferay Portal)
• Proprietary
• Communication between Portlets is not implemented using the standard JSR-286, but a custom proprietary solution (Source: http://www.contribute.be/web/contribute/news/-/journal_content/56_INSTANCE_pdF5/10234/21893)

Advantages  of Liferay Portal:

• Open source
• Drastically lower initial costs
• Lightwight product (1-Click-Install, etc.)

Disadvantages of Liferay Portal:

• Not everything is from one product line (this cannot be considered as disadvantage always, but in our case the customer preferred very few different vendors (keyword “IT consolidation”)
• Portlets are still Portlets. Although Liferay is lightweight, realizing Portlets still sucks as it does with a proprietary product

When to use a Portal?

Well, the conclusion is difficult. In my opinion, it does make sense only in a few use cases. If you really need many or all of those Portal features, and they are also sufficient, then use a Portal product. Though, usually it is much easier to create a simple web application which integrates your applications. Use a SSO framework, create a template, and you are done. Your developers will appreciate not to work with Portlets and its increased complexity and restrictions.

Did I miss any pros or cons? Do you have another opinion (probably, many people do???), then please write a comment and let’s discuss…

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post Pros and Cons – When to use a Portal and Portlets instead of just Java Web-Frameworks appeared first on Kai Waehner.

Deployment of a Cloud Foundry Application to the Cloud

The reference guide of Spring Roo gives an introduction at http://www.springsource.org/roo/guide?w=base-cloud-foundry, which describes the combination of Spring Roo and Cloud Foundry. In a nutshell, there is not much to do to deploy your (CRUD-) application in the Cloud Foundry cloud.

You have to login to your Cloud Foundry account, create a WAR file and deploy it. Three Roo commands execute these tasks. If you use any Cloud Foundry services (such as MySQL, Redis or RabbitMQ), then you have to create and bind these services using other Roo commands. The deployment is very easy. You can choose to deploy your application to a private cloud (your own servers) or to the public cloud (VMware servers).

I got a strange non-speaking exception (that’s a major problem of Spring Roo often): „Operation could not be completed: 400 Bad Request“, but no further details or exceptions. Forum support was necessary. The problem was that the name of my cloud app was already used by another developer, it was not unique (I tried to use the name „SimpleCloudFoundry“). A more speaking error message would be nice! Using another (unique) name solved the problem.

Cloud Foundry is just a traditional Web Application –  Contrary to GAE

So, after reading the previous paragragh, the conlusion is the following: Spring Roo supports deploying  its applications to the Cloud Foundry cloud. Thus, everything is fine? Yes, more or less surprisingly, that is true! The statement of the Cloud Foundry documentation is also true: „You won’t need to architect your applications in a special way or make do with a restricted subset of language or framework features, nor will you need to call Cloud Foundry specific APIs. You just develop your application as you do without Cloud Foundry, then you deploy it.“

So, why should you think about using another PaaS solution instead of Cloud Foundry? Cloud Foundry applications are traditional Java web applications which are using Spring and being deployed to a Tomcat web container. You do not have many limitations (remember the Java classes white list of GAE) or database restrictions (remember the BigTable concepts of GAE). Be aware that due to this advantage, you have to use the services offered by Cloud Foundry! At the moment, you can use MySQL, Redis, Mongo DB and RabbitMQ. No other databases or messaging solutions can be used. If the offered services meet your demands, everything is fine.

Almost all Cloud Foundry Commands are available in the Roo Shell

Usually, you develop a Cloud Foundry application in an IDE such as Eclipse. Besides, you use the VMware CLI (which is a command line tool) to login to Cloud Foundry, create and bind services, deploy, start and stop your application, and so on.

Spring Roo offers more than 30 unique Cloud Foundry commands. With Roo’s Cloud Foundry integration, you can now manage the entire life cycle of your application from the Roo shell. That is great! Of course, VMware wants to push both, Cloud Foundry and Spring Roo, so the connection between both products is really good. But …

There is no Reason to use Spring Roo for Cloud Foundry Development

Spring Roo’s goal is to help the developer to realize applications easier and faster. It is awesome for creating prototypes or CRUD web applications. Nevertheless, it does not help to create Cloud Foundry applications. Sure, you can use all VMC commands directly within the Roo shell, but that’s it. I wonder if this is an advantage? I found it annoying to always type „cloud foundry“ in the Roo shell before entering the real command which I wanted to use.  Thus, I switched back to the VMC command line tool quickly. The SpringSource Tool Suite also offers a Cloud Foundry plugin to bind services and deploy applications via „drag and drop“. Very nice!

In my opinion, there is no benefit to use Spring Roo for developing Cloud Foundry applications. There is one exception, of course: If you develop a Spring Roo application (let’s say a CRUD app), then you can do everything within the same shell, that is cool.

By the way: Though I do think that the combination with Spring Roo brings no benefits, I really like Cloud Foundry. It is one of the first PaaS solutions (besides Amazon Elastic Beanstalk) which offers relational database support. Besides, it is possible to deploy to public AND private clouds. It is open source, thus much more support and services will be available in the future. But be aware: Contrary to GAE, Cloud Foundry is still BETA at the moment.

The current conclusion of this article series is that Spring Roo does not really help to develop applications for the cloud. Nevertheless, I like Spring Roo and I like PaaS solutions such as GAE and Cloud Foundry – but not combined. I will write further articles if this situation changes or if further PaaS products are supported by Spring Roo.

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post Rapid Cloud Development with Spring Roo – Part 2: VMware Cloud Foundry 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.

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.

What is Spring Roo?

“Spring Roo is a lightweight developer tool that makes it fast and easy to deliver instant results. Best of all, you code 100% in Java and get to reuse all your existing Java knowledge, skills and experience. You’ll like it – and have plenty of fun too!” (http://www.springsource.org/roo)
Many introductory articles exist already, just use Google if you do not know Spring Roo yet. In a nutshell: Spring Roo is a Java-based tool (using the SpringSource Tool Suite which is based on Eclipse). It uses AspectJ to simulate many features of Grails and other frameworks with dynamic languages to improve the developer experience.

Spring Roo is awesome for CRUD-Clients!

You can create a CRUD application within minutes to create, read, update and delete data. I recommend Spring Roo for CRUD applications because of a good community and a powerful vendor (compared to other CRUD frameworks such as Roma Meta Framework or OpenXava).
Personally, I would prefer Grails, but if you want to create CRUD applications with Java, then Spring Roo is the best alternative.

Spring Roo is good for learning Technologies!

Spring Roo is also good for learning technologies because you get a working example in seconds, and you can create more complex stuff within minutes using the Roo Shell. Then you can learn and understand how Spring Roo uses these technologies.
Of course, Spring-based technologies such as Spring MVC or Spring Security are supported very well. Also JEE standards such as Bean Validation or JPA are supported. Besides, many further technologies are supported, e.g. GWT, JSF, Vaadin, Flex or Google App Engine. Actually, many of these addons are not production-ready yet – but Spring Roo is young and I am sure that many improvements will happen because of the large community.

Spring Roo is NOT good for complex Projects (yet)…

Please be aware, that this is my personal opinion due to my experience with Spring Roo: If you want to build something really complex, then you should use technologies such as JPA, GWT or Google App Engine without Spring Roo, because Spring Roo is not ready yet for this kind of project, and thus will probably create more questions than answers…
One exceptional case: If you want to realize an application which uses especially or better just Spring frameworks, then you might start your project with Spring Roo. It can be a huge help in the beginning of a project.

Conclusion: Spring Roo is a nice Tool => Become a Part of the Community!

My final conclusion: You should know Spring Roo, because it is nice, but you should also know when to use it and when to use something else. Use it to create CRUD applications or to learn technologies. Do not use it (yet) for complex, large projects.
Spring Roo is young and has a large community plus a powerful vendor. You should participate and become a part of the Roo community to make it better and production-ready (this does not mean you have to commit code – I do not commit code as well – but even if you only read the JIRA issues and vote for your favorites helps the community).
So, if you never used Spring Roo yet, try it out now!

Best regards,

Kai Wähner (Twitter: @KaiWaehner)

The post When to use Spring Roo? appeared first on Kai Waehner.

The final track included a live demo of Adam Bien, a well-known JEE expert, author and speaker (also involved in the JEE specs). A very nice “live show” of the JEE 6 features!
The participants (including me) asked a lot of questions crititcally, Adam Bien always had very good answers and explanations because of his excessive experiences with Java technologies for several years.

While answering our questions, Adam Bien claimed some very interesting statements, which I want do list and discuss in the following (I agree with most of them)…

Statement 1: Tomcat is not as lightweight as it appears first!

Tomcat is a very lightwight web container, that is true. But where is the benefit, if the size of many deployed applications is larger than the container itself? You have to add all required libraries to your lib folder, because Tomcat does not offer them. On the other side, application servers already contain implementations for the JEE specs.

I agree!

Statement 2: Use the full JEE 6 stack instead of the Web Profile for development whenever possible!

The new JEE 6 Profiles (such as the Web Profile) limit the environment because they prohibit some features such as Remote EJBs, MDBs, Timer and so on. But why should you use e.g. the Web Profile for development? The size of the full JEE stack contains only 30 Mb more. Maybe the performance differs slightly, but the developer does not notice this barely measurable difference in practice.

I agree.
We discussed another intention of these profiles earlier that day: The profiles shall help other vendors to build JEE conform containers. They do not have do implement every (rarely used) specification, so it should be a lot easier for smaller companies to build a product.

Statement 3: Use EJBs instead of POJOs!

Why should you still use EJBs instead of POJOs in many projects? You get transactions, threads and JMX-integration for no additional effort.

I agree.

Statement 4: JEE 6 and Spring 3 are very similar!

The current versions of JEE (version 6) and Spring (version 3) are very similiar. The decision is a question of faith: JEE uses conventions over configuration, Spring forces the developer explicitly to add configuration (e.g. for transactions). So choose what you prefer, or if one of it is already used in a project, then continue using it.

I agree. By the way: Personally, I prefer JEE 6.

Statement 5: Two annotations should be enough above one Java class!

Do annotations make the source code more confusing? No. If you use more than two annotations above a class declaration, then the class contains too much functionality.

I slightly disagree. I really like Annotations. But there is a threat, that many people use them everywhere. And probably, many APIs will be created that require much more than two annotations. For instance, JPA 2.0 is very borderline! Sometimes, you (have to) use more annotations than other lines of code.But I still think that Annotations are much better than XML configuration for these tasks.

Statement 6: Use interfaces only if you need them!

Use interfaces only if you need them (e.g. using the strategy pattern)! You also no more need interfaces for mock-tests since two years.

I agree. In our current project, we use a class (without “impl” or other naming conventions). If you need an interface in the future, just make a simple refactoring!

Statement 7: Use REST instead of SOAP!

If possible, use REST instead of SOAP!

I aggree.
Another well-know german IT expert, Stefan Tilkov (innoQ), contributes many reasons, why REST is almost always better than SOAP in a very nice (german) podcast: Podcast about REST and SOAP web services. And here you can find a great introduction to REST.

Statement 8: Flash has no future because iPhone and iPad do not support it!

Adam Bien does not use Flash or Flex in his projects since two years. The reason: No iPhone and no iPad support (these devices do not support the Adobe Flash Player). Many customers do not know this fact, before Adam Bien explains it to them. The decision of Apple “killed” Flash as alternative for future applications.

I agree, that this decision of Apple is very tough for Adobe and that the integration of multimedia (especially videos) in HTML 5 will make the Adobe Flash Player unneccesary in the future. But this will take some more years of course…

Statement 9: Do not mix JEE and Spring in future projects!

Mixing JEE and Spring in future projects is very risky, because you have to buy two different support licenses. Unfortunatelly, Spring and some JEE containers (namely e.g. Glassfish) do not offer updates / patches for an older major version after a newer major version has released. So, companies have a higher risk, when using both technology stacks.

Overall, I agree. But I think that you can use e.g. the Spring Templates (such as JDBC or JMS Templates) in JEE applications with very low risk, nevertheless…
(if you like these Spring Templates – personally, I do not like them. For instance, if I do not want to use plain JDBC, I usually use the very lightweight persistence framework myBatis (former iBatis) instead.

Statement 10: Convention over Configuration is great for developers!

In many cases, a JEE 6 Developer is not required to know many details about the JEE specs to build good applications. For instance, you often do not need to know about the JSF life cylce, but you can nevertheless write web applications.

I agree. Convention over configuration increases ease of development a lot. It is much easier to start with JEE 6 than some time ago where you had to learn JEE 5 or even worse JEE 1.4.

Conclusion

So, some very interesting statements are discussed… I think that JEE 6 is a great improvement. So let’s hope that some more stable certified JEE 6 application servers will release soon!

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

The post 10 interesting Statements of Adam Bien about the Java Enterprise Edition 6 (JEE 6) appeared first on Kai Waehner.

I presented about applicability and limits of Java Server Faces 2.0 (JSF 2.0). You can download my (german) presentation slides:  DOAG SIG Java (Sept2010) – Einsatz und und Grenzen von Java Server Faces 2.0

“DOAG SIG Java” – What’s that?

The DOAG is a very large, german, independent Oracle-Usergroup. After the acqisition of Sun, the SIG Java was established to demarcate the Java technology from other business units (database, administration, …). Conferences are organized several times a year, the number of participants varies from 50 to 2000.

The conference was very interesting. Besides me, speaker from Oracle, Msg Systems and IMIXS were on site. Also Adam Bien, a well-known JEE expert, author and speaker (also involved in the JEE specs) was present.

The following talks were presented:

1) Overview about JEE 6

Summary:
– More and more specifications
– Ease of Development is the main priority
– Decoupling the specs from each other is an important goal
– Profiles (such as the Web Profile) will be avaiable – maybe thus more vendors will build   JEE-certified container

2) Usage of Components in JEE + Discussion: Why is there no JEE Marketplace (just like the Apple App Store)?

Summary: Too many questions, which nobody can answer:
– Is the business logic too specific  for a company / for a project?
– Who wants to build components for Oracle, IBM and so on?
– Who guarantees for the quality and who gives support?
– Probably developers would use available components, but who should build them?

3) News from the Java Persistence API (JPA) 2.0

Code examples showed the new features of the API, meta model, Queries (such as the new Criteria API).
Not much more to tell here…

4) Applicability and Limits of Java Server Faces (JSF) 2.0

My talk

The talk contained three parts:
– Introduction to JSF: architecture, life cycle, design concepts (multi-page, server-centric, component-based)
– Addons for JSF: Component Libraries (such as ICEFaces, RichFaces, MyFaces and so on), JBoss Seam, CaptainCasa, Portal-Integration)
– Limits of JSF: When should you use another web-framework? First a categorization of web frameworks was presented to show why developers sometimes should think about using web frameworks such as Grails (CRUD), GWT (Rich Client) or JavaFX (Rich Internet Application) instead of JSF in some use cases.

5) Live-Demo with Adam Bien

This was really nice: Adam Bien developed a little application and showed many new JEE 6 features in practice. The audience asked questions critically all the time, Adam Bien always had a good answer…
I wrote down a lot of very interessting statements of Adam Bien’s excessive experiences with Java technologies. You can read them discussed in my other blog entry including my comments: 10 interesting Statements of Adam Bien about the Java Enterprise Edition (JEE) 6.

Conclusion

A nice one-day conference about JEE 6. The participants got an overview about JEE 6, its new features, practical experiences and interesting discussions….

Best regards,
Kai Wähner

The post Report: One-Day Conference “DOAG SIG Java 2010” about Java Enterprise Edition 6 (JEE 6) appeared first on Kai Waehner.

I want to share my experiences with JRebel (http://www.zeroturnaround.com/jrebel/). If you need some neutral information about this product to ease development with J2EE / JEE applications and application servers, this blog entry is for you!

Problems with JEE Application Servers

If you develop with WAS, no matter if it is version 5 / 6 / 6.1 / 7, deployment takes a very long time. Even changing a single line of code (e.g. to add a System.out.println) takes about 15 minutes in our project for publishing the changes, because you always have to do a build and redeployment. So, sometimes you have to wait 50 percent of your working time until WebSphere is ready again.

Other application servers have the same problem, although they are probably not as lame as WebSphere.

What is JRebel?

JRebel is a product which promises to solve this problem.  You do not need to build and redeploy. You save your class, the IDE compiles the class, and you can see the changes within one second!
If you want to understand how it works technically (you do not need this knowledge to use the product), you can read a detailed explanation here: http://www.zeroturnaround.com/jrebel/faq/#How_does_jrebel_work

Features of JRebel

JRebel supports all important application servers such as WebSphere, Weblogic, Tomcat, Glassfish and so on. Besides allowing simple changes  such as adding methods, fields, classes or annotations, you can also change EJB interfaces, JSPs, JSF and JPA code, XML config files and so on. Spring, Hibernate, JBoss Seam and some further Web-Frameworks are also supported. So, JRebel is very powerful.

IDE-Plugins are available for all major Java IDEs: Eclipse, NetBeans and IntelliJ IDEA.

All features of JRebel are described and compared to other solutions at http://www.zeroturnaround.com/jrebel/comparison/

Does JRebel work?

I can confirm you: JRebel works as promised! You can save plenty of developtment time. I would never ever think about developing a J2EE / JEE project without JRebel (especially if WebSphere is the used application server).

I was very sceptical before trying out JRebel by myself. My colleagues also did not trust the promises at the product’s website, so I had to give them a live demo

You even can debug using JRebel. So you can start the application server in debugging mode, make some changes, set a breakpoint, and see the changes immediately.

License Costs

The standard edition costs 189 USD for one year per developer. Support costs additional 50 USD. The support is fantastic! You get very quick responses with detailed explanations.
Open source and Scala projects do not have to pay any license costs.

It is excellent value for money! You can save a lot of time by investing this little amount of money.

Installation

The installation is very easy. JRebel is installed (and also removed) within 10 minutes. You just have to add a JAR file and add one line of code to the configuration of the application server.

Bad Documentation

My main criticism: The documentation is bad. Someone of the JRebel guys should extend and improve the documentation!

There are some pitfalls which I had to resolve:

– The application server runtimes do not use the same JVM version of the IBM compiler as RAD, although it is one installation! You get very strange error messages, so it is tough to deduce this problem.

– Some important information about JRebel is logged to the file “native_stderr.log” at /RAD/SDP70/runtimes/base_v61/profiles/Application/logs/server1/
e.g. this file informs you if JRebel is activated succesfully or what problems occur. I did not find this information anywhere within the FAQ. The JRebel support gave me this hint.

– I had some problems while debugging with JRebel and WebSpehre / RAD. Sometimes, the IDE did not show the line where the debugger is at the moment. This problem happened sometimes, but not too frequently. I restarted the application server, then the debugger worked correctly again.

Conclusion

Besides the bad documentation, JRebel is a very good  product. You can save a lot of money using it, The licences costs are very low. So, if you develop a J2EE / JEE application, you should always use this great product. So I recommend: Try it out by yourself, a 30 day trial is available to test JRebel. It will only takes some minutes to see the potential…

If you have made other experiences with JRebel, let me know and post a comment.

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

The post JEE Development using JRebel with IBM WebSphere (WAS) 6.1 and RAD 7.0 appeared first on Kai Waehner.