Tag Archives: Java/Java EE

Live from TSSJS – Lightweight J2EE with Adam

Posted on by
2

For my final TheServerSide Java Symposium breakout session for the day, I am attending “Lightweight Application Development with Java EE 6” presented by Adam Bien.  Adam’s talk is in part an attempt to bring former J2EE developers (myself included) back to the table who may have been driven off by previous, heavy-weight J2EE implementations, such as J2EE 1.4.

Adam spends most of his presentation actually building a simple Java EE 6 application on the fly, using Casino/Police/Mafia metaphor (since this conference is in Las Vegas).  I’ll try to capture the highlights in this blog, but the code itself says volumes about how simple to use Java EE 6 has become.  He develops in NetBeans IDe 6.9.1 with Glassfish as a web server, deploying everything as a WAR.

1.  Simplifying Code with Annotations
Java EE 6, like Java EE 5 before it, solves a lot of complexity and deployment issues through Java 1.5’s creation of annotations.  Adam shows a code example of a Stateless session bean is essentially just a POJO with the @Stateless annotation.  The only required import is “javax.ejb.Stateless” for the annotation to reference.

2.  Interceptors
Java EE 6 supports @Interceptors that redirect business methods for a better separation of POJOs and business logic.  Serves as a filter for business methods.

3.  Dependency Injection
The @Inject tag allows you create instances of related objects that live as long as the parent module.  Easy to create events and inject them into classes.

4.  Qualifiers
Adapted from Spring, helps control event ordering as far as which observer gets the message.  The annotation @Qualifier is used on the class level with a @Retention and @Target parameters.  The listener can then be updated to only listen to events of particular types or values.  Furthermore, they can be use for filtering on events which is useful for batch processing.

5.  Messaging
Java EE 6 supports @Asynchronous annotation for creating messaging handlers.

6.  Interfaces
Similar to previous versions of J2EE, you can define an interface for a session bean and use references to the interface instead of the concrete class.  Compiler throws an error if you try to inject an interface with no concrete implementation.

7.  J2EE and Spring
Adam recommends not mixing the two, and building entirely in Spring xor J2EE 5 or 6.  The features are very similar between the two and mixing them can be complicated.  One of the major new features of Java EE 6 is REST integration.

Conclusion
Adam did not present any slides, but built a quite impressive Java EE 6 application on the fly with very little code.  Everything he built deployed instanteously on his MacBook, and was accessible from the web browser right away.  Adam pointed out not all computers or operating systems build as quickly.

I asked Adam if he would be posting his code online since it was quite educational.  He said he will once he is back in Germany.

Lightweight application development – the server side java symposium

Posted on by
1

This session is a live demo of developing an app quickly. Kind of like the Ruby on Rails “see i can develop an app in 15 minutes so long as it fits my extremely fitting scenario”. It was an informative and humorous/domain specific (casino) example. And I was pleasantly surprised that it didn’t trivialize the amount of work required. It was obviously a hello world type example and not intended you have a complete application in an hour. And the humor made it a great way to end the day.

The demo uses NetBeans because the speaker doesn’t want to install plugins, jab at Eclipse.

Since this was largely demo, comments are light, but here are some points:

  • Recommends using CDI instead of managed beans
  • Noted larger projects take a few seconds to rebuild/redeploy via maven
  • The interceptors and beans look so much like Spring and just as easy. I[ don’t see why you would switch back to ejb and know oracle plans to stay behind the curve]
  • Have a bean.xml even if empty so server doesn’t need to scan the whole project, just the cdi jars
  • I like that he included a custom annotation
  • In jee, an ejb can be a restful service

    • Avoids interfaces, only uses when really variation [what about testing?]

The speaker feels you should use Spring with an older JEE technology, but not JEE 6 because redundant. [you would still be deploying to jee 6 even if you aren’t using it though]

Live from TSSJS – Testing in the Cloud with Andrew

Posted on by
1

This afternoon I’m live blogging from TheServerSide Symposium, attending “Breaking all the Rules:  The Myth of Testing and Deployment in the Cloud” presented by fellow CodeRanch Andrew Monkhouse.

1.  CodeRanch History
Andrew opens his talk with a discussion of CodeRanch performance, traffic, and memory usage.  He mentions there have been serious issues in the past that haven’t temporarily brought the performance of the website down to a crawl.  CodeRanch uses a fork of JForum (2008) and staffs around 20 developers among 150 moderators, all volunteer participants, to build a custom community-based forum.

CodeRanch developers use a number of test strategies including smoke tests, load tests, and stress test.

2. Redeploying in the Cloud
The focus of Andrew’s presentation will be to demonstrate how CodeRanch would function in the cloud.  He has allocated a “small EC2 instance” (1.7GB memory, 1 compute unit, moderate I/O performance) within Amazon’s cloud that is useful for quick set up, but extremely small for practical use and reliable testing.

3. Benefits of the Cloud
The cloud provides a relatively clean environment in which it is ‘cheap’ to add extra servers, at least compared to running a local test server which may be allocated for additional processes.  Also, tests can run by anyone, anywhere, which is great for a distributed developer team, since Amazon allows you to assign rights to additional users.

You can easily create, set up, and desotry Amazon Machine Images (AMI), so you do not need to get it right the first time.  Lots of backup storage options, depending on your needs.

4.  Dangers of the Cloud
Testing in the Cloud can be difficult.  First off, it is hard to get absolute numbers because of the nature of the underlying change in hardware happening within the cloud.  Second, calibrating results is difficult.  Also, developers have to remember to shut down servers after they are down with them else other developers will run out of resources.  Finally, network traffic does cost money so testing can be expensive, although hardware is cheaper in cloud.

5.  Test Setup
The performance tests were set up into 3 servers, in part because it turned out to be cost effective to set it up this way based on the individual server options.

  • Application Server running CodeRanch
  • Database Server
  • JMeter Test Server

JMeter was used at the testing suite software given its large variety of features, options, and plugins.

6.  Test Analysis
Andrew discussed some items to keep in mind when testing the server and understanding the results:

  • It is quite possible for the Test Server to have greater load than the Application server, so be sure to monitor all your servers!
  • Try different graphs, they may tell you different things
  • JMeter plugins are your friend, they will help you identify problems with your application server and/or test set up.
  • Don’t forget about ramp up times

7.  Where do we go from here?
Automated weekly performance tests using the latest code base.  Add more stress tests.  Andrew comments there are no plans to move the CodeRanch to the cloud at this time given that we require full-time administrators since we don’t have a dedicated, paid team of administrators.

Conclusion
Andrew presents a compelling argument why you should be testing your applications within the cloud.  It provides a sanitary environment in which to perform a large variety of tests across multiuple servers.  I’ve heard arguments of moving application servers to the cloud, but this is the first time I’ve heard it suggested to migrate all automated testing to the cloud.