News »Browse Articles » Java Champion Adam Bien on Java EE and Cloud Computing

EE n CC

Java Champion Adam Bien is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector in Germany who implements Java technology on a large scale. He is also the author of several books and articles on Java and Java EE technology, as well as distributed Java programming. His latest book, Real World Java EE Patterns - - Rethinking Best Practices, explores the challenges of cloud computing.

In addition, he has been named a Java Rock Star for his popular session at the 2009 JavaOne conference.

We met up with him to get his latest thoughts on Java EE and cloud computing.

java.sun.com (JSC): What is your basic understanding of how cloud computing works?

Bien: I see two unrelated concepts called cloud computing. The first one is related to grid computing, where parallelizable tasks are distributed to independent computing nodes and then aggregated to a consistent result. Frameworks like Hadoop, map-reduce algorithms, are an example of this approach.

The other paradigm is a virtual, private or public, data-computing center with an accessible API. You can model the environment in drag-and-drop-like fashion or, even more importantly, control it directly through a programmable API. You can, of course, run the grids in public or private clouds.

These paradigms also differ in their usage models. Grid computing is intended to be used by a few power users who need a considerable amount of computing power. On the other hand, in cloud computing, significantly more users access the machines with relatively low resource utilization.

While these two models are conceptually opposite, the underlying technology could be very similar. The first is often called platform as a service, and the latter, infrastructure as a service.

The Advantages and Disadvantages of Java EE

JSC: What are the advantages and disadvantages of Java EE for the cloud?

Bien: Java EE was designed to be deployed to a distributed environment. Cluster management and extensive monitoring and management capabilities are supported by major application servers.

The EJB 3 programming model encourages stateless, idempotent, and atomic or transactional design. It is interesting to note that the programming restrictions are very similar to the Google App Engine. In both cases, thread management, file access, changes to the underlying JVM* -- especially class loading, system properties, and security managers -- are not allowed.

Furthermore, both Java EE 5 and Java EE 6 come with standardized packaging -- the Enterprise Archive (EAR), which makes the provisioning of cloud apps relatively easy. And EAR solves some cloud-interoperability issues: It`s a lot easier to move an app from one cloud to another. Java EE 5 and 6 are portable, so applications can be easily moved from one application server to another, regardless of whether they run in a cloud or not. They both will run on JDK 5 or higher.

The JVM itself comes with fantastic remote debugging, profiling, and monitoring capabilities. This already greatly simplifies the development of distributed apps and should also simplify cloud-enabled apps.

Java EE, however, was not designed to be operated in highly dynamic environments. Clouds tend to be elastic, and most of the current computing centers are not. There is some work to be done with respect to dynamic discovery, self-healing, and dynamic load balancing. It isn`t hard with the current application server -- we did it in projects with GlassFish v2 and several years ago with JBoss.

Ironically, Jini and JXTA were always capable of behaving this way. You can simply borrow the concepts like leasing or dynamic discovery from these frameworks and apply them to a rather static Java EE environment.

JSC: Sun`s Geertjan Wielenga asks in a DZone discussion: "What will applications/software look like on the cloud? Are they all web applications? Web services? Or what?" How would you answer him?

Bien: Actually, some cloud providers are not that different from on-premise software. The application just runs elsewhere.

The difference starts with the implementation of persistence services. Some cloud providers, like Google or Amazon, don`t offer support for relational databases. So you either have to live with the map-like structure or try to install a relational database in the cloud. This necessitates some rethinking about how the persistence should be designed and can even impact the design of the user interface.

The obvious use case for clouds are load generators. It is very hard to simulate thousands of users on premise. Clouds are perfect for that: You can leverage the power of the cloud for your load tests and pay only for the spent CPU cycles. Without a cloud, many underutilized machines must be maintained to cover a few peaks a year.

Batch processing is another use case -- perfectly suitable for grids and clouds. The workload can be distributed across the working nodes or images -- it can scale very well.

Source:
http://java.sun.com/developer/technicalArticles/Interviews/community/bien_qa_200

No Comments For This News

Post a link to something interesting from another site, or submit your own original writing for the Java community to read.