Sun Tech Days Sydney - Day 1 (4 March 2008)

Today I attended the first day of Sun Tech Days in Sydney, and here are a few of my impressions.

Some major takeaways for me:

1. The Java and Open Source ecosystem has expanded so much in the last decade that Sun can no longer organise a conference to talk about just its own technology. This year, for example, topics included Ruby, JRuby, Rails, the Spring framework, JBoss Seam, MySQL and PostgreSQL, Grails, AJAX, REST, etc.

2. Sun is now irrevocably committed to Open Source. Open Source has become too powerful a force for any company to withstand. It gave me deliciously wicked pleasure to see James Gosling, the "father of Java" and a traditional Open Source skeptic, take the floor and defend Sun's pro-Open Source direction. I know from reading past interviews of Gosling's that he is no admirer of Richard Stallman or the GNU GPL. It must have hurt for him to see his brainchild released under the GPL! ;-D

3. There seems to be some competition hotting up between three players in the Java/Open Source world - SpringSource, Red Hat/JBoss and Sun. I got the feeling Sun was actually aligning with their old enemy Red Hat, because they seem to view SpringSource as their common enemy. SpringSource have taken over Covalent, the Apache services company, so there's a perception that they're pushing Tomcat over all other app servers, GlassFish included. That seems to irk Sun. Later, watching the JBoss Seam demo and learning that it is going to form the basis of a new JavaEE technology called Web Beans, I got the distinct impression that JBoss is proposing a rival to the Spring framework. However, both Sun and SpringSource favour Toplink over Hibernate as the persistence engine for their products, perhaps since Hibernate belongs to JBoss. This whole area bears watching in the near future. It has implications for organisations looking to deploy Open Source Java stacks, because sourcing pieces of the stack from mutually antagonistic parties may create integration problems, even if all the components are nominally Open Source.

4. There is a lot of "low-level" knowledge in the industry about how to use tools, but not enough "high-level" knowledge about why things are the way they are or even what is wrong with the way things are. This is as true of the presenters as of the audience (if audience questions at the end of each talk are any indication). Many presentations focused on syntax and mechanics of how to do stuff ("If you use this annotation, the system will automatically take care of such-and-such for you"), but did not provide more insights into architecture and design rationale. Worse, presenters did not do a good job of answering audience questions at an appropriately high conceptual level. [I felt I could have answered some of those questions better. E.g., "If REST makes the client manage its own state, then how do you secure a service against unauthorised access? Anyone can access the service." Answer: "Consider a simple system in which the userid and password have to be sent with each request. That solves the problem you have described. Now consider more sophisticated authentication tokens that can be sent (and checked) with each request." E.g., "Doesn't the service need to authenticate the client by looking up LDAP?" Answer: "A trusted identity provider has already looked up LDAP or a similar store to authenticate the client, and has provided a token to vouch for the client's identity, which the service now trusts."]

Mind you, the above critique takes nothing away from the fact that I learnt a fair bit at this conference.

1. For example, I had never before heard of the wireless device called a Sun SPOT, one of which was demo-ed at the conference. This tiny device fits in the palm of your hand, and has various kinds of sensors (e.g., light sensor, temperature sensor, 3-axis accelerometer, etc.) The devices can detect each other and a gateway wirelessly and the whole system can be used to collect and collate various kinds of real-world data very simply and display it graphically using a JavaFX Rich Internet client. Very cool. One of the Sun managers said the company is selling these below cost to encourage take-up, so if someone is interested in this sort of device, the Sun SPOT may be worth looking at.

2. I hadn't heard of Mercurial before either. This is a revision control system. Sun has changed their preferred revision control system twice, once from CVS to Subversion, and again from Subversion to Mercurial. From the Wikipedia description and its favourable rating in this comparison of revision control systems, Mercurial seems to be pretty good.

3. I was only vaguely aware that JDK 6 bundled a client-side HTTP server. I must try out this example they showed today:

import javax.jws.*;
...
// Define a web service
@WebService
public class SayHello
{
@WebMethod
public String sayHello()
{
return "Hello, World";
}
}
...
import javax.xml.ws.*;
...
// Publish the service using the bundled HTTP server in the JDK.
// This is a "transient" service hosted temporarily by the client workstation.
SayHello sayHello = new SayHello();
Endpoint endpoint = Endpoint.create( sayHello );
endpoint.publish( "http://localhost:8080/hello" );

I made a quick attempt to run this example but it didn't work. I'll need to do more research.

4. NetBeans 6.0 is not bad. It may be worth waiting for 6.1, though, because there's at least one issue with 6.0 that will be fixed in the next release. That's the ability to generate a simple CRUDish web interface to exercise JPA persistence logic, which was apparently working in version 5.5 but has mysteriously stopped working in 6.0.

5. Carol McDonald's two sessions (one on WSIT, JAX-WS and REST and one on Application development using plain JavaEE, Spring and JBoss Seam) were packed with technical content, but alas, I felt she couldn't add much in the way of design rationale or insight. Her blog entries here and here have more details of her presentation and should be of interest to many.

6. Apparently, SOAP's transport-independence is not just theory. Sun's Metro Web Services stack can use any of these transports - HTTP, JMS, SMTP or TCP. The TCP bit is the most interesting, as I don't think SOAP requires a more heavyweight transport. All of the qualities of service required by SOAP messaging are provided by the WS-* headers anyway, so it's best for SOAP to choose the lightest transport protocol that can possibly work. What about IP itself?

7. OpenSolaris makes for a pretty cool desktop. It boasts all the Compiz magic that Linux offers, so Unix in general is now no desktop slouch.

Some of my pet peeves:

1. A statement was made by one of the presenters that DTOs are an anti-pattern, and that detached entities are the way to go. I have railed against detached entities from the time I first heard about them. Mind you, I have nothing against detached entities as long as they stay within the application tier. It's when they are proposed as a means to export data to other tiers that I object. That immediately exposes the domain model to external parties, resulting in tight coupling. Change your domain model and your clients break. [Incidentally, if you consider the web tier to be part of "your" application and not an external party, you are guilty of "web application thinking" and not "SOA thinking". The web tier of your application is an external consumer of your application's services, as much as any external client.] One may hate DTOs and criticise them as an "anaemic domain model", but DTOs were never meant to model anything. They are mere structures that act as an envelope for a bunch of data items that are exported to other tiers. To the extent that they hide the actual domain model from external parties and decouple them, DTOs are your friend. [If you find it a pain to marshal and unmarshal DTOs, you perhaps haven't been using Dozer. Also, if you consider the XML documents within SOAP requests/responses to be DTOs in XML format, then you may similarly benefit from using TopLink's meet-in-the-middle mapping approach or JiBX's mapped data binding to marshal/unmarshal them. You certainly shouldn't be using JAXB to generate one from the other.]

2. Speaking of which, there was a lot of code generation demonstrated today of the sort I simply hate. I have explained before why, if we want to implement SOA, we cannot simply generate service implementations from domain models. I have also tried to mitigate the evils of code generation by proposing a set of explicit "service" classes that act to decouple the domain model from external parties. Annotating these intermediate service classes and automatically generating web services interfaces and WSDL files does no harm, because the required decoupling has already taken place. But as I complained before, this kind of architectural insight did not accompany the demonstrations. They were training technicians out there today.

Nevertheless, on the whole, I thought it was an entirely rewarding day (and the food was great!) I'll be there again tomorrow and will report on my impressions.