Rod Johnson in the cloud – the server side java symposium

Rod Johnson led off with a Dilbert cartoon about the cloud/platform – the pointy haired boss says “it’s like you are a technologist and philosopher all in one” in response to “blah blah blah cloud”.

Benefits of cloud

  • No reason to operate own data center because does not scale. Also noted the environmental impacts due to overprovisioning on small/medium data centers. Large companies will adopt onsite/internal clouds.
  • Compared computing to a utility and noted factories used to operate their own electricity. Really good analogy!

Perceived weakness for Java in the cloud

  • Perceived to be slow and startups look to Ruby and the like. This is a problem because these are the companies that are tomorrow’s leaders
  • Universal hosting not available like PHP

Strengths of Java in the cloud

  • Write once run anywhere
  • Java already in the enterprise
  • In actuality scales better than Ruby

Other Points

  • We think if the internet as free when we use it. However, there is a cost and the energy use is very high.
  • Rod Johnson considers flexibility to be a more important driver than cost. That way pay when need and not guessing up front if a startup will succeed. Compared to the Zipcar model. It costs more per mile but cheaper if don’t drive a lot. Another great analogy.
  • Simplicity, because large organizations have a lot of bureaucracy and provides a way to subvert that bureaucracy [some of that bureaucracy has a reason, accounting and security teams are not going to be happy with subverting things. However, an internal cloud provides benefits without subverting.]
  • Need architectural trade offs for economies of scale
  • If cloud is about business agility, need to be able apps fast which is why Rails shines. Notes the importance of being perceived as being able to start fast. [sounds like this is more valuable than maintenance]
  • It is more important to have one good option than a lot of medium options. Thinks Java community needs a cultural change to pick a stack. Showed how having two IDES of eclipse and intelij means good products and not a lot of poor choices. Interesting NetBeans was left off the list. rails helps because gives you less choices and saves time by encouraging consistency
  • The line between development and operations is blurring. No common tool chain organizational chaos. More self service in cloud because developers deploy

Spring’s thoughts

  • IaaS (infrastructure as a service) – vmware vcloud
  • PaaS (software as a service) – must abstract away OS, provide self service and be a productive programming model
  • Frameworks are key to portability – gave example that Spring isolates you from the app server [in other words if you deploy your container in your application, you don’t have to worry about the external container as much]. I liked the Ruby example better because Rails is. Framework that doesn’t replace the container.
  • Challenges: a lot more and complex data, adapt to RDBMS + NOSQL. Recognize what datastores need to be transactional. plugged Spring data project. Similarly for asynchronous data patterns
  • Visual builders are usually horrible because build uneditable code. Wavemaker is different because Spring owns it. I think there as another reason he tried to state but i didn’t catch it. Maybe it builds on roo?

Java’s phases

  • -2005 : make java work
  • 2005-2010: RIA, REST, higher productivity
  • 2010-?: beyond RDBMS, mobile/tablet, cloud, even higher productivity required

the end was all blatant advertising of spring’s tools.

Lightweight application development – the server side java symposium

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]

Testing java ee applications – the server side java symposium

This session was also fast moving and information filled, but it didn’t feel as overwhelming as the Spring session. The presenter included demos of some of the technologies.  He did use the term “unit test” for things that test through the web and database. I would rather these be called integration/functional tests. I wish the testing industry would use one set of definitions. I subscribe to the one where a unit test doesn’t involve the database or the server

Servlet layer

  • Junit – need to build on
  • httpunit – higher level api on http level – the demo shows creating requests and responses using the java api. This technology is preferred over htmlunit because you are usually not generating raw html if you are using a servlet.  [you should be using MVC]
  • htmlunit – higher level api on html level
  • Cactus – in container tests, good for functional testing
  • Selenium – can be used for acceptance testing by users, no coding required
  • Servletunit gives you a simulated container or can mock the request/response objects for simple cases

JSF

  • Jsf 2 project stages help for debugging and testing. This helps because you can easily specify different web.xml settings.
  • Selenium – for simple cases
  • jsfunit – uses cactus, junit, httpnit and htmlunit behind the scenes

Tip: define ids in your jsf tags so not randomly generated. That way you can refer to them

CDI/EJB 3.1

  • Arquillian – lets you say you do not want your whole aoo to be deployed. You use @RunAs(Arquillian.class). Then you can createDeployment() with the classes you want deployed. the ShrinkWrap API lets you add specific classes which lets you test one EJB or injected element.  The demo used embedded glassfish as specified by a Maven profile.  Also lets you inject into the unit test
  • Apace myfaces codi testing is a competing choice
  • For simple cases mock objects are sufficient, not testing production environment [that is why you test logic in unit tests and environment in integration tests which are in container]
  • @RunWith(ResinBeanContainerRunner) starts a very light container. Only supports CDI and EJB 3.1 lite

JPA

  • Embedded database – derby, hsql, java db
  • Embedded container like arquillian
  • Dbunit – helps with data consistency [and setup]
  • ejb3junit, mocks or pure junit again works for simple cases

Web Services

  • Soapui – good for complex cases with either SOAP or REST. Same level as Selenium
  • Can use junit and arquillian if want test to be self contained
  • Can use jersey test framework