Thoughts on Day 2

Overall, the quality of the presentations wasn't quite as high the second day. However, the keynote made the whole day worthwhile.

I wish I had more to say in conclusion for today. Tomorrow is the last day of the symposium, and I am hopeful that I can come up with a more eloquent way to tie everything together tomorrow night. But for now, all I can come up with is goodnight.

Migrating to EJB 3.0

Mike Keith and Debu Panda gave this talk. Both are from Oracle; Mike is the Chief Architect for TopLink, and Debu is in charge of the EJB 3.0 container.

Most of their talk was addressed to clients with pre-existing EJB 2.x logic deployed. Fortunately for NI, this number is almost 0. For new developers, he encouraged developers to just start building against EJB 3.0 as it would be available "soon" (who knows when that is).

Session Bean migration is essentially removing the callback methods and turning them back into POJI business interfaces.

Entity Bean migration is more difficult, and since we don't do Entity Beans at all at NI, I will skip this. However, this is where the new Persistence API comes into play. The new EJB 3 based persistence API is going to be a very close approximation of several current frameworks, including TopLink, Hibernate, and JDO. This persistence will be available outside the J2EE container.

The presentation wasn't rocket science, but I'm glad I got to hear Oracle's two top minds on this subject discuss their opinions.

Advanced Spring Framework

Never attend a session with "advanced" in the title if you're new to the subject matter. =]

I had read a little about Spring when I first started researching some of these J2EE technologies and frameworks back in November. It seemed like good technology that just didn't have quite enough mainstream acceptance or adoption. I'm not sure if the audience is a representative sample, but the TSS crowd seems to embrace it heartily. Rod Johnson was one of the people I have been most impressed with here, so maybe it's worth taking a closer look at his technology.

In any case, this was not the time and place to try to pick up some basics about Spring. I was lost throughout most of the presentation. However, I did pick up a couple of interesting things. First, org.springframework.test is their test framework, and apparently it's pretty darn good. I'd be curious to know if Spring Test is a competitor to or an ally of TestNG.

Another new specific Spring extension was introduced, Spring WebFlow. The concept of web flows seems very valuable. I found it interesting that the architect behind the tool said it had been originally implemented with Struts. I would have figured Spring MVC. It was developed originally for a client, so we have the comfort of knowing that the code is production-proven. WebFlow allows you to chain view presentations together into a kind of work flow. Imagine a web application that tells the users they are at step 3 of 6 for some business process. With WebFlow, you can actually model those 6 steps and define the different navigation paths around each screen. It can also reuse flows as nested within larger flows. It sounds a lot like a presentation tier VI to me.

The benefit of Spring is that it leverages auto-wiring through inversion of control. This reduces the amount of necessary configuration, however it also makes it less easy to troubleshoot. It is also less self-documenting. Overall, I think Spring is a fine platform for pure developers, but I'm not sure what the value proposition would be for J2EE development at NI. We may be better off sticking to simple, tool-supported frameworks like Struts.

Oracle Releases EJB 3.0 Preview!

Oracle sponsored our lunch today, and they announed the release of a Tech Preview edition of their EJB 3.0 container. This is HUGE news!!!!!!!!! I'm really impressed that they timed the launch with TSS symposium. Oracle's chief architect for developer tools was the lunch keynote speaker, and he gave a good (but fast!) demo of the EJB 3.0 and JSF ADF Faces components in this new Tech Preview.

I'm psyched that we finally have an Oracle container for EJB 3.0. Now we can really start poking around with this and figure out the value of this new technology. If you want to download it, go to http://otn.oracle.com/ejb3

JUnit and TestNG

Cedric Beust from Google was here to talk about a personal project of his, a JUnit alternative testing framework called TestNG. The session was useful as a critique of JUnit, and also as an eye-opener to how our ideas of what unit tests should be have been shaped (and limited) by JUnit.

He jumped pretty quickly into an overview of the limitations of JUnit. JUnit re-instantiates test classes before testing each method call, which can be inefficient if you're doing a lot of setUp() or tearDown() work each time. You can work around the problem with static methods, but as Beust put it, then you're just trading one limitation for another one. Another problem with JUnit is that you can't easily test individual methods, at least outside of an IDE. Also, you can't enable or disable test suites without recompiling code. And, if nothing else, JUnit hasn't been updated in years, so it's not necessarily up-to-date with changes in JDK 1.4, 5, etc.

Mostly, Beust's complaints seemed to center around the fact that JUnit is a very static programming model, and that it imposes strict naming conventions around its configuration extensions. His product, TestNG separates business logic of the actual test from the run-time model of the test execution.

TestNG supports test groups which can categorize and aggregate common test types (database, front-end, etc). TestNG supports parameters into test methods, and method dependencies. Dependent methods report failure differently if it results from a missing dependency; it reports SKIP instead of FAIL. He refers to this feature as "partial failure." These business logic features of TestNG are all annotation-based. The run-time model is driven from a configuration file called testng.xml.

A lot of the features of TestNG could be viewed as requirements for a new revision of JUnit. Fundamentally, they are very different tools, but I'm not sure how much credibility and longevity this TestNG tool will have. Instead, I see its value more for NI as a way to identify gaps in JUnit so we can do our best to mitigate them.

One thing I did really like about TestNG was that its annotations include support for timeout and invocation count aspects. Wouldn't it be nice to be able to set timeout rules on our tests to enforce performance requirements? Or invocation counts to load test within the unit test framework?

Overall, honestly, TestNG seems like a far superior tool. My hesitation for now is based on the lack of confidence I have in the longevity of TestNG. JUnit has been around a while, and I am not sure what the value proposition is for migrating to TestNG. It sounds like JUnit has lots of room for improvement, but I just don't know that this is enough to warrant breaking apart from such a de facto standard. I would be very curious to see how TestNG adoption increases over this year. If it starts being seen as a viable, stable alternative to JUnit, it may be worth looking at.

Pragmatic SOA

I snuck into this session midway through after walking out on the Pluggable J2EE Web Applications session.

We are really nowhere near even the tip of the iceberg on Web Services at NI. As such, Eda and I both were pretty out of our element in this session. The content was great, and if I could have understood much of it, I'm sure I would have been very impresesed. =]

It wasn't quite that bad, but I did find it instructive that the one session where I struggled to follow the alphabet soup of technologies and the basic principles was the one on web services. I guess that's ok, given that we have no immediate plans to delve into a more open architecture for SOAP-exposed services on ni.com. But it is definitely a decifiency as far as our expertise level at NI.

Having said that, here's what I was able to glean from the discussion. Apparently identity management is a huge issue with web services, and one of the reasons that wider adoption has not yet been seen in the B2B arena. Federated identity in particular is problematic for systems where user authentication happens on the other side of the cloud instead of within a common SSO layer in the same corporate environment.

The speaker (can't remember his name) also talked about the three basic standards that are going to be relevant for the evolution of web services. WSDL will describe the data, BPEL will orchestrate the assembly of services, and JBI will provide the integration platform. He did mention that Oracle seemed to be alone in the externalization of BPEL as a client-view API. I think he sees it more commonly as a background technology. Again, I can fit what I know about BPEL on the head of a pin, so I'm just going off what I heard.

JBI is a new JSR spec that is receiving a fair amount of coverage at this symposium. The idea is that the integration container can be reinforced with standards for integration that will eliminate some of the vendor-specific configuration that goes on today to make all the magic of web services work. Again this fits into the notion of application servers becoming best-of-breed integration platforms rather than original service providers.

Pluggable J2EE Web Applications

This session started promisingly enough. The speaker was a guy from Atlassian, the company that originally made Orion (aka. OracleAS). His topic was on a framework Atlassian had developed for creating a plugin architecture for your J2EE web applications.

The idea sounded good, until I learned there wasn't really going to be much of a demo. Oh, and by the way, the technology doesn't work with JSPs. Can you say next presentation?

TSSJS Day 2 Keynote (Trends in J2EE)

Rod Johnson is by far my favorite speaker of the conference. After giving a phenomenal lecture Thursday on why J2EE projects fail, Johnson returned this morning for a keynote address on trends in J2EE.

One of the things I found interesting being a newcomer to the event was the sense of renewed confidence in the platform. Rod in particular talked about being skeptical when he presented at the first TSS symposium that J2EE would survive the threat mounted by .NET. The biggest difference between then and now is that J2EE projects are succeeding more than in the past, thanks largely to the slow but eventual development of best practices around how (and how not) to use EJBs. Keep in mind, when people (including Rod) bash EJB, they're mostly talking about Entity Beans or Session Beans that use too much RMI and don't follow the prescribed Session Facade pattern. In other words, EJB done correctly is a good thing, but EJB done poorly is catastrophic.

In any case, he also talked about the perception of Java as a "chaotic" platform with so many competing frameworks as a falsely negative attitude. In fact, the diversity is a strength and fuels innovation thanks largely to the open source community. That being said, he dove into some specific buckets of thought around why J2EE is now more poised for enduring success and supremacy over .NET than ever before.

J2EE and OOP

Much of the old J2EE (i.e. EJB 2.x) architecture isn't truly OO. "Fake objects" like Data Transfer Objects (DTO) were simply state, no behavior - so not really objects at all. Plus, more obviously, EJBs themselves were glaringly non-OO: you can't even subclass them. Today, this is changing. The J2EE platform is moving back toward solid OO principles, with no better evidence for this than the EJB 3.0 spec's reliance on concrete POJO classes.

His bottom line argument here was that the domain model should dictate the object model, the platform should not. However, with EJB 2.x, developers had to deal with a cumbersome object model simply because of platform constraints, not because the complexity was suggested or even necessary to the object model. This notion, that the platform should not dictate object model design, is a major reason for the growing emphasis on Dependency Injection (facilitated by AOP) in the J2EE platform.

Agile J2EE

This is an area where I see the most potential friction between what we hear in industry best practices and the way things work at NI. NI has always seemed very wedded to a waterfall SDLC approach, but the conventional wisdom (at least at this event) seems to be that agile development works a little better for J2EE. A good compromise for NI would be to follow agile development practices by creating more fully scoped proof-of-concept applications that validate architectural assumptions and illuminate key risks.

In any case, Rod talked about agile J2EE development as an idea that started off as an academic theory that has started to gain acceptance in industry. He cited some examples of large clients of his that now view agile methodologies as less risky than waterfall approaches. A large part of the explanation for this may be found in the acknowledgement that waterfall approaches seek to freeze requirements and code design, whereas in reality, business needs change often and code needs to be continually refactored to reach optimal quality.

Still, the waterfall seems to be part of how NI IT develops software. So at some point, we need to address this, if only to start evangelizing the role of proof-of-concept development in the project lifecycle. There may be Sarbanes/Oxley implications for this as well given controls around Project Tracking. Anyway, I don't want to beat a dead horse... It's something we need to look into.

During this part of the session, Rod also introduced the concept of Test Driven Development, a variation on XP style development where unit, integration, and functional tests are used for more iterative development.

Framework-Oriented Development

Not surprisingly, a guy famous for having invented a popular framework for J2EE development is really really fond of frameworks for J2EE development. He did have some good things to say about this. He credited Struts for being one of the first tools to come along and take a relatively academic discussion of the "front controller" pattern and create a product around the pattern, making it much easier to discuss and leverage. More and more frameworks have sprung up, many of them open-source, and this has led to what he refers to as "the death of the in-house framework."

Apparently, 1-2 years ago, third-party frameworks did not receive the same prestige and acceptance they do today. It was more common for companies to have created their own proprietary in-house frameworks. He said that the move away from in-house frameworks toward third-party frameworks was probably the most significant trend in the J2EE industry he had observed over the past 18 months.

Developers need to add value, and to do that, they need to be focusing on the problems at hand. This seems simple enough, but without the leverage provided by frameworks, developers have to write (and maintain) many, many more lines of code. Most of that code has nothing to do with business logic and just configures services on the application server. This is the trap I believe we have fallen into at NI with things like the connection pool in NiJavaLib. We should be letting the application server handle connection pooling, and we should just leverage the built-in support for connection pooling through data sources.

What is open-source about?

This area of discussion was a little off topic from the state of the platform itself, but he had some interesting thoughts. He encouraged a more TCO-oriented evaluation of open-source software. Just because the license is free doesn't mean the technology is going to be cheaper or better to adopt. Focus should include quality of performance, quality and price of services provided, and the requisite training and path to adoption (in other words, the organizational impact). So in his words, he encourages us to "evaluate on merit first, then worry about the license."

He had a lot to say about where specifications belonged and where innovation should be left unchecked. Essentially, his argument was that core services that make up the underlying platform should be standardized and little else. Specifically, it doesn't make sense to standardize around an application programming model (like Struts vs. Spring MVC). We have to standardize around things like the servlet interface, distributed transaction management, etc to make sure that the J2EE spec is portable across vendor implementations.

He argued that the EJB Entity Bean specification around persistence was premature and derailed the platform for years. His comment was, "If Entity Beans hadn't been part of the J2EE specification, would that have survived on their own?" The answer to this is of course a resounding NO. So I found this argument to be relatively compelling. Overall, I like the mix of options out there that allow developers and organizations to choose for themselves.

AOP

We did an audience poll right after breakfast that showed that barely 1/3 of developers had touched AOP or even planned to in the near future. His comment on this was that he was surprised that AOP hadn't taken off faster. Nevertheless, he cited experience with his clients where incremental adoption of AOP (mostly for infrastructure services like security) almost always led to increased adoption based on the positive results from initial AOP efforts.

According to Rod, the recent merger (which I didn't even know about) between AspectJ and AspectWerkz creates a de facto standard for AOP with AspectJ 5.0. It was unclear to me exactly why, but he made a comment that he saw AspectJ becoming far more prevalent than JBoss AOP, of which he was candid in his criticism.

AOP is not ready for standardization, largely because according to Rod, there is no need and no value from standardizing. The market will bear out the best uses for AOP, and standardizing now may just stifle innovation.

Implications for the App Server

The emergence of third party frameworks and specifically the role of the open-source community converge on the application server vendors in a way that may change their role in the platform. If developers can pick and choose and assemble "best of breed" interoperable J2EE frameworks and technologies, then they don't need the umbrella support of proprietary technology in a particular vendor's application server. Instead of becoming the service provider, the application server can become a simple service integrator.

Technologies to watch

For the purposes of professional development, he encouraged all of us to establish (or sharpen) our understanding of certain technologies. These inculde:

• IoC (inversion of control) and DI (dependency injection)
• Unit testing and TDD (test driven development)
• O/R Mapping (TopLink, Hibernate, JDO, etc)
  
• Web application frameworks (Struts, JSF, Spring, Tapestry, etc)
  
• Rich Internet Applications (GMail)
  

He concluded his talk by warning developers that by not building expertise in frameworks that bring leverage to J2EE development, we risk obsolescence. Get beyond J2EE, learn other technologies and become a domain expert - learn your business's domain model. Solve business problems. Good advice, no?