Cloud Zone
Cloud Zone is brought to you in partnership with:

Java Champion / JavaOne Rockstar Adam Bien (adam-bien.com) is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector. He is also the author of several books and articles on Java and Java EE technology, as well as distributed Java programming. adam has posted 59 posts at DZone. View Full User Profile

Java EE: The Perfect Platform For Cloud Computing

02.26.2009
| 26959 views |
  • submit to reddit

The term "Cloud Computing" is even cloudier than SOA or Web 2.0 definitions. My understanding of clouds is:

  1. Elasticity: you can fire up new instances on demand.

  2. Management and Monitoring: especially applications in the "cloud" have higher requirements regarding management and monitoring. You should be able to pro-actively monitor the current state of your application.

  3. Vendor neutrality: you wouldn't like to be dependent on one vendor in the current economic situation.

  4. Standardized packaging and installation: you will have to package your application to install it to a "cloud". Standards are always good, otherwise you will end up in many negotiations and meetings. 

  5. Failover capabilities: clouds do not have necessarily to be HA-aware. It is nice to have a clustering option.

  6. Easy administration: you will need remote administration tools. Using vi to edit files would probably not satisfy your customers.

  7. Low resource consumption: computing time and resources cost a lot. It is important to build as lean applications as possible to save money.

In case my cloud-understanding is correct Java EE 6 and even Java EE 5 would be perfectly suitable for cloud standardization:

  1. JMX is just built-in and standardized (J2EE management and monitoring). ...and you can nothing do against it :-). Every deployed Java EE component has to be published on every J2EE 1.4+ conform application server. You have only to leverage the information with JConsole, through Java 5 SE API, or tools like Hyperic or openNMS.

  2. You can start, stop and manage application servers on demand. e.g. GF v2 can do it through a centralized domain. If it is not sufficient, you can easily extend such capabilities with e.g. EHCache, JBoss Cache, RESTFul interface and leasing concepts.

  3. The portability of Java EE 5 applications is really good - and it will be even better in Java EE 6. I actually switch back and forth between WLS 10 and GF v2 in my current projects. Java EE 5 is already supported by JBoss, Geronimo, Glassfish, Weblogic, Websphere, SAP and even Spring (look at pitchfork).

  4. EARs, EJB-JARs, WARs and RARs are standardized. You don't even have to touch this archives migrating them from one server to another (reason: XML is no more necessary - server-dependent deployment descriptors are gone)

  5. Failover is supported by every application server I know.

  6. Easy administration: it cannot be easier than in Glassfish v2+. The webconsole is lean, fast and intuitive. Command line interface is available as well. Geronimo also comes with own console. The admin console for JBoss is available in the commercial package too.

  7. Low resource consumption: the EJB 3.1 container in GF v3 is exactly 420kB.... It can be loaded and unloaded on demand.

From http://www.adam-bien.com/roller/abien/entry/java_ee_the_perfect_platform
Published at DZone with permission of its author, adam bien.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Geertjan Wielenga replied on Thu, 2009/02/26 - 8:44am

What I've been trying to understand is: "What will applications/software look like on the cloud?" Are they all web applications? Web services? Or what?

Ulf Gohde replied on Thu, 2009/02/26 - 11:24am in response to: Geertjan Wielenga

Cloud Computing itself doesn't say anything about this. You could just store the data in the cloud and use thick clients to access the data, e.g. like Apple's MobileMe. That would still count as cloud computing.

However, it is probably fair to assume that RIA will play a big part in Cloud Computing in general.

 

Andreas Siebert replied on Thu, 2009/02/26 - 11:57am

sounds like an advertisement for j2ee technologies ;)

 

1. j2ee is not so elastic like it can be. you have to manage something and not only fireup and run. in the best case a new instance should startup on demand.

2. if you have many many many requests  (and clouds are developed for many many many requests on demand:) then distribution is better as clustering.

2. java persistence is at this moment practicaly strong "database-oriented". database is a bottleneck. in my understanding is a cloud horizontaly scalable. but distributed databases are not so popular. 

 

 but j2ee-servers can be used in a cloud. that's right ...

Robert Buffone replied on Thu, 2009/02/26 - 12:12pm in response to: Geertjan Wielenga

I just went to a Amazon Meetup last night in Boston and the applications people are talking about are all over the map.

  • Enterprise and Consumer
  • Websites / Web Applications / Web Services
  • Desktop / Mobile.
  • Production / Development / Testing / Building

But they all had a couple things they were looking to achieve:

  • Elastic computing power that makes it easy to scale up as well as down when resources aren't needed.
  • Looking for afordable computing power that can let applications reach "Web-scale".
  • Computing power as an utility.
As part of my work on rockstarapps.com and our eclipse tools for Amazon WebServices, I found Amazon has really made it possible for people to create a large applications in a very afordable manner. 

 

William Louth replied on Thu, 2009/02/26 - 2:25pm

"especially applications in the "cloud" have higher requirements regarding management and monitoring" Higher requirements! Then how can anyone even consider JMX and the tooling listed. No one is trying to do something "against it" [jmx] that it has not already done to itself by its design and implementation. The world (at least in the cloud) has moved on from the time this API was initially conceived. We now need concrete, standardized and unified cost, performance, metric models that offer (inherently) aggregation and merging capabilities across the containers of execution flow (which by the way is practically impossible to model with JMX). JMX might have been useable in some form when things when monitored soley at the system level but now and certainly in the future it is all about fine grain activity metering in terms of (multi) resource usage and costing models. Java should have a very bright future in the cloud if Sun chooses appropriately the technologies that should be migrated and designs more appropriate programming models that blur process, memory and storage boundaries. William

Bryan Taylor replied on Thu, 2009/02/26 - 2:42pm

8. Hot Deployment - in a cloud environment, the deployment and undeployment of apps to containers cannot require the bouncing of the container, as the container may be shared among many apps, including those that are not produced by the same organization.

Traditional java utterly fails at this, and it's one reason why cloud vendors like Rackspace/Mosso and Google App Engine are not featuring java. OSGi and Spring DM might improve this, but traditional app servers with their massive Perm Gen memory leaks on app reloads simply are completely unacceptable for many core forms of cloud computing.

William Louth replied on Thu, 2009/02/26 - 5:13pm in response to: Bryan Taylor

Hot deployment in the cloud does not necessarily mean that that a process itself has to stay up and running. In the context of an ideal cloud computing environment no one would even care about such as OS legacy construct. If we continue to think in terms of a processes then we will simply never scale because of the obvious management scalability issues (even with auto-agent discovery solutions). The only way to truly scale if for us to just see the code as being deployed to just one container - the cloud. Why bother moving to the clouds if you are still going to bring some legacy baggage. Hot deployment is a developers solution to a symptom of software and not the actual problem itself. The ideal environment today (while we wait for the computing computing programming model) is for the runtimes to start-up/shutdown as cheap as possible. This is the only way one can be reasonably sure that such issues are minimized sufficiently. Spring dm and OSGi does not address this either as only yesterday after downloading the latest and greatest and after two failed app deployments of the tutorial apps the dm server was broken (state infection) and I was forced to do a complete restart. Nothing has changed the same bugs exist just at another layer on the card deck.

Bryan Taylor replied on Fri, 2009/02/27 - 1:56am in response to: William Louth

William - what you are describing is an illusion. At the end of the day, the physical reality is that there are boxes that run processes that respond to requests. Cloud computing does not change this. Instead it creates an abstraction layer that hides the physical architecture behind a logical one. Yes, the app deployer want to see one logical container that is the cloud, but any attempt to virtualize the physical deployment architecture this way succeeds only by transfering the management to the hosting provider. The hosting provider will see appXYZ as being deployed to some set of container processes scattered across physical nodes. Container per app doesn't scale to 1000 apps, let alone 10000 or 100000. 

I can have one instance of apache httpd running a crap load of mod_python, mod_php, mod_perl apps that deploy and undeploy all day. You simply cannot do this with JEE app servers. Mosso and app engine aren't restarting an httpd process every time I deploy a new version of my app.

BTW... there's other hard issues besides deployment. I can sandbox a JVM in terms of memory consumption, but I can't really do that for apps within a JEE container. Nor can I prevent thread proliferation easily. 

 

 

William Louth replied on Fri, 2009/02/27 - 3:36am in response to: Bryan Taylor

Illusion? I did state this will be the end game for computing in the cloud. Virtualization of a server and a set of processes is just an intermediary poor mans step while the innovative research and development goes on in the companies that have a glimpse of the future. If you spent a little more time on the cloud computing forums you would have noted that there are basically two camps - those that want to remove process/storage/memory boundaries and those that want to see the cloud as some large scale server provisioning system (which does not scale at the human side). I do not understand why you bring up apache httpd when today most application servers that are fronted by such a processes are routinely restarted with the mods dealing with rebinding to instances within the cluster. Maybe you I did not get my point across but a deployment to the cloud (container) could implement this in whatever way that seems fit to the platform itself. What is important (for scaling) is that the user is not concerned with managing physical or virtual servers and processes. It is the cloud vendor that will deal with the complexity reducing IT management costs across all customers using the platform. Naturally they would probably manage this at the process level themselves as this is a surest way to guarantee some degree of isolation and to speed up problem resolution which is a nightmare with current OS/runtime technologies hosting multiple applications. This does require that the cloud vendor has some standard way to intercept and manage execution flow which is why there will eventually be a cloud computing programming model that addresses such needs in the same way Java EE did for internal enterprise application deployments.

Alex(JAlexoid) ... replied on Sun, 2009/03/01 - 8:49am

Java has one thing missing at the moment - standardized resource and thread management.
Without that Java EE on the cloud is basically a proprietary element. You can see how GigaSpaces handles additional processing power on Sun Grid.
Currently you have to "roll your own resource manager" and you can only manage threads, not memory.

Next, since "the cloud" is identified with IaaS, PaaS and SaaS, Java EE is has limited space on SaaS.
And on IaaS Java EE is a good option and is actually and actively used. On the other Java spectrum, you can setup and start a Hadoop installation on Amazon EC2 in a amtter of minutes.
It is not ideal for only one reason - thread and process management and provisioning.

 

Finally, I will add a bit of criticism to the article itlsef, minor , but still.
2. Pro-active monitoring is not possible. Monitoring in it's essence is a reactive activity.

3. Vendor neutrality has nothing to do with the clouds. In this economic situation, economies of scale win, so we will have Amazon, Google, Force.com and a few more. Meaning, that only organizations with existing BIG data centers can compete.

7. Clouds have nothing to do with "Low resource consumption". Clouds were created due to resource under-usage. The applications themselves may be very resource hungry. And not much has changed in the prices, that means computing resources are still cheap. Clouds are better, because you don't need to support those computing resources and no need for capital investment.

The other point 7: GlasshFish may be only 420KB, but it still cannot compete with the likes of Python. 

 

I can't stress enough that Java is lacking resource management capabilities, and that is a real PITA in a hosted environment. OSGi does not help in any way on that front.

Liezel Jane Jandayan replied on Thu, 2011/08/11 - 5:58am

Developers will benefit from productivity improvements with more annotations, more POJOs, simplified packaging, and less XML configuration.

Senior Healthcare Consultants

Sirikant Noori replied on Fri, 2012/03/30 - 12:48pm

 

Sir I dont agree. Java EE is standard based which is one of the greatest draw of Java EE. oNE MIGHT be taking app of cloud infrastructure to be deployed to other which is not done easily in Microsoft or Amazon etc. Thank you so much for the post

Java Exam

Chris Haddad replied on Sun, 2012/04/29 - 1:49pm

Adam,   even the JCP leads have publicly stated JEE must be modified to appropriately deliver cloud characteristcs.   To review 'what is cloud', please read the latest NIST Draft - Cloud Computing Synopsis and Recommendations at http://csrc.nist.gov/publications/drafts/800-146/Draft-NIST-SP800-146.pdf

 

Based on the proprietary work WSO2, CloudBees, and RedHat have been forced to perform when creating a Cloud application platform.  I would assert today,  JEE fails to reach the Cloud  

John Smith replied on Mon, 2013/02/18 - 8:58am

 I like this post,And I guess that they having fun to read this post,they shall take a good site to make a information,thanks for sharing it to me.      spongebob game

 

Joay Sim replied on Thu, 2013/02/21 - 8:57am in response to: Geertjan Wielenga

 Superbly written article, if only all bloggers offered the same content as you, the internet would be a far better place..

         manually backlinks service

Ron Sim replied on Mon, 2013/02/25 - 10:01am in response to: Geertjan Wielenga

 
Thank you for helping people get the information they need. Great stuff as usual. Keep up the great work!!!

       http://hotlivedealer.com

Ron Sim replied on Wed, 2013/02/27 - 4:38am in response to: Geertjan Wielenga

I have read your article, it is very informative and helpful for me.I admire the valuable information you offer in your articles. Thanks for posting it..
       teeth implants uk

John Smith replied on Sat, 2013/04/27 - 4:02am in response to: Ulf Gohde

 
I found that site very usefull and this survey is very cirious, I ' ve never seen a blog that demand a survey for this actions, very curious...

            my latest blog post

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
"Starting from scratch" is seductive but disease ridden
-Pithy Advice for Programmers