HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
Interview with Paul Chambers, Part 2, by Jason Westra

JDJ: Paul, what do you think about wireless and the state of the industry in five years?

Chambers: There's certainly going to be a lot of change. The telecommunications industry is really going to go through a revolution over the next five years. Two markets we really need to look at are the North American market and the rest of the world, which really complies with another set of standards. Ultimately they're going to converge in about four years.

The sort of standards we've got in Europe – it's packet switched so it can just do data, but not fantastically. It's got a limited bandwidth, currently about 14 kilobits per second, if you've got good reception, etc. Where that's going is, by the end of the year there'll be several networks up and several devices. There's actually several devices available now through a technology called GPRS [General Packet Radio Service]. GPRS gets a bandwidth up to 115 kilobits per second. Now that's pretty nice for applications, and you can start doing real stuff. The other aspect of it, though, is that it's packet switched rather than circuit switched. This is the first step into real TCP/IP packet-switched information so that we're running voice over IP and gateway and back end, too. For all these things the existing networks are based on PSTN [Public Switched Telephone Network], the existing circuit-switched networking protocols. The big change is that, as well as the bandwidth – it's always on, like any TCP/IP, LAN-based networking packet switch.

This introduces the concept of being able to have push models as well as pull models in the mix. Another thing that bandwidth will introduce, though, is that J2ME is going to become very important. So the idea of having smarter applications running on mobile devices, based on Java and messaging back the services and technologies like JMS. JMS is being rolled out there in terms of lightweight JMS, just as J2ME is a lightweight Java form of platform. So you're going to start to see smarter applications as well as the wireless application protocol (WAP), which is essentially a markup language, albeit a binary one, which is more efficient for the narrow bandwidth.

You'll get around some current limitations of the applications. I've used them back in Europe – I've sat on the train trying to send e-mail and what happens? A coffee man comes along and interrupts you. You put your device down and go through a tunnel. You lose the signal and when you come back to your application – lo and behold, it's gone! All that you did...

In an ideal world what you want is an asynchronous model – you want a smart Java application. Possibly you want an embedded database – and nice caching locally – and asynchronous messaging back to the server so you can have asynchronous tasks, asynchronous messaging, which will get you over the problem of interruption. You know, it's not a continuous service when you're mobile. So there's going to be some nice, interesting applications once you've got this GPRS. That's happening this year. It'll really start making an impact next year in terms of the mobile Internet.

In the U.S., what you've got currently is Code Division Multiple Access (CDMA). I talked recently with Sprint. They're running out of a lot of WAP applications in America. So you guys aren't too far behind. I know the U.S. predictions have been a bit behind, but not that far behind. There's a lot of work going on. There's not a lot of clients throwing out WAP applications, but Sprint got to the point where they've got national coverage now with their network, which means they've got huge coverage and it's based on CDMA. They're going to take out CDMA next year and put in CDMA 2000. Now CDMA 2000 is like GPRS; many of the technologies are the same. Qualcomm actually owns a lot of the technologies that GPSR and CDMA 2000 are based on. Again, I guess the bandwidth is packet switched. It's going to be really nice for mobile applications and data, etc. That's what's happening over the next 18 months.

JDJ: With the way chips are coming out with Java embedded in them, a number of companies have had some great announcements of their products. How do you see that coinciding with J2ME? Are they complementary? Or do the actual embedded Java chips in the hardware replace J2ME? Does J2ME's role decrease?

Chambers: I think that remains to be seen. There are three sort-of solutions I've seen out there, which may compete, or may coexist. So you're going to see chips that are designed to run bi-code instructions on these mobile devices. You're also going to see that some companies are trying to take the standard JDK – the standard J2SE platform – and not reduce functionality but squeeze it into small enough footprints so the device is just above the very small things like smart phones. They're all competing for their own space, along with J2ME, but J2ME does have some limitations, and ideally you wouldn't want to do that. You don't want to reduce the functionality of the application, etc. The only reason you're doing it is because of the limitations of the devices. The other thing is the capabilities – the bang for the buck. Obviously, it goes up. All these things are going to converge, and we'll just have to see how over the next few years.

JDJ: It sounds like JMS is making headway into both wireless and the J2EE platform. How do you see that evolving into this lightweight form that's going to be supported in the devices?

Chambers: Obviously, devices need to communicate, applications need to communicate, and there's going to be a number of mechanisms to do that. JMS is an interesting mechanism for doing that because it has a more loosely coupled messaging capability.

Take a mobile application talking to a J2EE application server. As I said before, you get interrupted, you lose your signal, and so on. JMS is really good – guaranteed delivery, batched queues. It sits there when the connection comes back up, and your application will reconnect and synchronize the messaging, get the message back to the application. Of course, you've got the smart application back there in terms of the J2EE application, so it's going to play a key role. I think you're going to see things like CORBA running over the air, so it's going to be there as well. You're going to see I/O type communications as well. As the bandwidth goes up, downloading servlets, running these different object protocols and so on over the bigger bandwidth is going to be possible – it's going to happen.

JDJ: Are these some of the things you're seeing GemStone's partners doing with JMS and integrating GemStone as well?

Chambers: Two companies we're working with are working within this space (probably more, but these are two I can say). SoftWired, JMS vendors from Switzerland and Zurich, has mobile, lightweight JMS for mobile devices, so that's currently available. They're starting to do wireless applications with them. Similarly, SpiritSoft, based in London, is a JMS vendor. They're working on lightweight JMS as well, and doing mobile applications in the financial industry. This is the real thing. It's really happening.

JDJ: You mentioned your partners. How exactly are you using the wireless? How are you building wireless applications with GemStone/J?

Chambers: It's this mutual architecture, this aggregator. It's an EAI engine – it aggregates information at the back end and now it's aggregating at the front end as well. What you want to do is write your application once, protect that investment from technology change and from all the different channels you have to deliver front-end technology to. What we're seeing is that people are relying on GemStone behind these sorts of applications – these wireless applications – for robustness 24/7, for smartness in terms of caching. When you lose a connection it comes back. GemStone's got all that. The user state is currently cached – we make sure you don't lose the work, so really, it's just a robust, scalable thing at the back end. Do it once, distribute it to any channels. It's a channel-neutral platform so it's doing no more than you'd expect from a J2EE server, eh? Scalable, robust, lots of transactions, lots of uses. [email protected]


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.