From Project Relator to an internal program called JavaFirst, Sun Microsystems believes it's time developers started treating mobile devices like real computers. Mark Jones spoke with Sun's Rich Green, vice president of developer tools, and Jeff Anders, group marketing manager, at June's JavaOne show.

Q: Applications built around services-oriented architectures are typically done in J2EE environments. In that context, how will J2ME applications evolve on mobile devices?

Green: There are two issues here: Services-oriented architectures in general, and then how does it talk to clients, for example a mobile device. (Sun is) trying to move up more and more to services-based technologies. There are some issues, (such as) what is the state of the art in terms of standards for creating services-based systems? With the Web services definitions that are out there today, it’s really quite straightforward. But when you get into something like an enterprise-class application that has to do secure transactions with high availability and failover that use many Web services, the flow of information has to be choreographed, and that’s not all there yet. So what we’re trying to do is two things: Keep the platforms -- the Sun ONE platform and the soon-to-be Orion platform -- state of the art in terms of adhering to the latest standards for services-based technology. We’re also doing things ourselves in the area of integration and other services while we await these standards that will allow this to occur.

Q: What opportunity does this situation represent to the Java community?

Green: I think massive steps are being taken between the Java community, WSI, and others. All the JAX-RPC (Java API for XML-Based Remote Procedure Calls) stuff, all the J2EE 1.4 functionality, (and) Web services are probably the single most powerful bit of glue and protocol capability to build services-based systems. The WSI components, the WSI basic profile -- which is also going to be part of 1.4 -- add a lot more in terms of XML standardization and protocols for that. What we’re going to do is keep evolving the Java platform and the interface model to deal with that. And in some respects, Java is further ahead because Java knows about transactions. Java really knows about security. Now it’s possible through the EJB container model to build highly available applications just by enabling that at the container model. The question is, are there standards to express those between services? They’re not all there yet. That’s a Web services thing and not a Java thing. So you can build services-based architectures extremely effectively now with pure Java, not even using SOAP and XML, because of the fundamental capabilities of the platform and the protocols that it supports. But as the world converges on Web services, Web services has to be evolved to be able to express all of these notions that are there in the Java platform between Web services, regardless of the implementation technique.

Q: Part of this discussion is the argument that Java could become fragmented. Is that a motivator behind what appears to be Sun's attempt to control and more visibly own the Java brand?

Green: It's (about) motivating compatibility, I’d like not to say it’s (about) control. It’s not like we have anybody in a headlock or tearing their (hair) out. But certainly in my speech (at JavaOne), I really tried to highlight the value of compatibility. Not from a control perspective but from the virtues it brings in terms of the Java ecosystem and building a bigger business and a bigger world model.

Q: Tell me about Sun's internal J2ME program, JavaFirst.

Green: The whole point of JavaFirst is taking all these Web services systems and if you want to sort of squint and look into the future, it’s (about) full services-based architectures. (We want to) make them available to mobile devices. What we showed on stage was essentially expressing the services-based architecture in such a way that you can automatically generate the client interfaces. What that system essentially does is it looks at the interfaces of your services-based architecture and it generates a proxy for it in a protocol that is readily expressed to the client, and then generates a set of client subs that allows these systems to talk. So you have a big Web services system, you run the tool against it, and what you get is essentially a port that supports all these services. And you get a client that you download onto your mobile device that can talk to it. And then you just attach the interface to it and you’re done. And it’s really cool.

Q: We're moving to a world where cell phones and converged devices are not hard-coded anymore.

Green: Yes, they used to be phones, now they’re -- albeit lightly -- a general-purpose computer. But the first app that it runs is telephony.

Q: When can we expect to see real-world instantiations of JavaFirst?

Anders: We have what we call the Sun ONE Studio Mobile Edition, which is a development environment for developers who want to build (MID-P midlets), and that’s really just a collection of plug-ins or modules that go into our Sun ONE Studio product. That’s there today. What we’re doing in addition to that is some of the things that Rich alluded to, which was the Project Relator. That’s the ability to take something like a rich client and pick any of your favorite design tools to create sort of a graphic: Adobe, Macromedia, Illustrator. It allows you to take that (tool) and essentially create hot spots. Say you designed a game, for instance, and you created an image map of a game that you wanted to create hot spots on that would relate to an action. What Relator allows you to do is create the hot spots and then tie that to pieces of Java code on the back end that, when you mouse over it or you click on it, then invokes an EJB or does whatever action you’ve specified on the back end. So that’s one thing that we’re doing to bring together the front-end client to something on the back end.

The other thing that we’re doing -- which wasn’t part of the announcements -- we’re actually showing on the show floor something called Javon. The whole goal there is to tie together the front-end client with the back end, to a J2EE type of server. It has two pieces: There’s a run-time component, which is the APIs, and the thing that does the messaging, which is very thin, very lightweight, which is exactly what you want. Then there’s also a set of wizards and design sheets that are part of Studio. The idea is to create a thin-client piece and then push a lot of the business logic and applications back to the server.

Q: You are trying to change the way developers build and deploy enterprise apps for mobile devices, but do you think traditional enterprise app vendors have got it yet?

Green: Well, I don’t want to sound negative, but mostly no. I think they have it in their heads. They see what’s coming. But most of their products are still very coarse-grained services-based stuff: a big J2EE app talking to a big J2EE app.