Welcome!

Java Authors: Maureen O'Gara, Miko Matsumura, John Ryan, Loraine Antrim, Walter H. Pinson, III

Related Topics: Java, Wireless

Java: Article

"Mobility is More than J2ME," Says Michael Yuan

The Keyword for Mobility Has Always Been "End-to-End," Asserts the Wireless Developer of the Year in 2002
By Michael Juntao Yuan
Article Rating:
December 28, 2003 12:00 AM EST
Reads:
 20,077
I was reading Glen Cordrey's last J2ME column in this month's issue of JDJ. Glen mentions that, as the J2ME market has not matured with enough jobs, he is going back to J2EE and try to work on mobility integration issues in enterprise projects.

I complete agree with him and in fact, this is the point I have always advocated in my writings. My keyword for mobility has always been "end-to-end."

Although my experience with the J2ME job market is somewhat different from Glen's (I have to turn down new J2ME contracts to keep myself sane at this point), I understand that not everyone in J2ME had the same luck. Most of the "real" employment opportunities are still on the enterprise server side.

But when we look at the future, I see three trends:

  1. The move to mobility is inevitable in the enterprise. The IT revolution has to reach hundreds of millions of mobile workers in order to realize its promise. There is no other way. However, the real question is how and when this will happen. With the IT over-investment in the last decade, it might take several more years.
  2. When enterprises move to mobility, a key consideration is to preserve existing investment. Fancy flashy J2ME games will not do it. The task is often to develop specialized gateway servers and J2ME integration software to incorporate smart mobile frontends into the system. That requires the developers to have deep understanding of both J2EE and J2ME. I think that the "end-to-end" sector is where the real opportunities are in the next several years. That is also what "Enterprise J2ME" is all about.
  3. Coding is a dying profession in the long run. If the jobs have not been outsourced to developing countries, the new generation of model-focused automatic code generation tools will eliminate the need for basic coders anyway. The jobs that have a future are system designing and architecting (the real engineering jobs). I think the ability to design end-to-end systems using whatever tools available is an important skill for the future.

Anyway, those are my observations for the mobility market in 2004.

Published December 28, 2003 – Reads 20,077
Copyright © 2003 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

About Michael Juntao Yuan

Michael Juntao Yuan is a member of JDJ's editorial board. He is the author of three books. His latest book, "Nokia Smartphone Hacks" from O'Reilly, teaches you how to make the most out of your mobile phone. He is also the author of "Enterprise J2ME" - a best-selling book on mobile enterprise application development. Michael has a PhD from the University of Texas at Austin. He currently works for JBoss Inc. You can visit his Web site and blogs at www.MichaelYuan.com/.

Comments (5) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Himansu Kandwal 02/17/05 01:14:00 AM EST

I am agreeing with Michael, yes J2ME and J2EE should be closely coupled. Yes processing of the complete application on the limited device is not a good idea, it will make the application slow and also not attractive.

I worked on J2EE and I found that it is best suited for server application in an enterprise environment, and when ever we want to connect with our server, using mobile devices, back end should be J2EE.

Now the technology is improving and several applications required connecting the user remotely.

Its my believe future is of using different technologies, according their performance constrains, to serve the request
Himansu Kandwal 02/17/05 01:13:30 AM EST

I am agreeing with Michael, yes J2ME and J2EE should be closely coupled. Yes processing of the complete application on the limited device is not a good idea, it will make the application slow and also not attractive.

I worked on J2EE and I found that it is best suited for server application in an enterprise environment, and when ever we want to connect with our server, using mobile devices, back end should be J2EE.

Now the technology is improving and several applications required connecting the user remotely.

Its my believe future is of using different technologies, according their performance constrains, to serve the request
Michael Yuan 12/30/03 03:08:42 PM EST

The reasons that I tie J2EE closely with J2ME are based on both technical and business realities of today''s mobile world. I assume that this "loosely coupled" mobile and enterprise components idea comes from web services. First off, let''s be clear that I am pro-web services. 3 chapters in my book talks about nothing but mobile web services. :) However, in today''s world:

1. Web services are not yet truely platform independent. The fact is that J2ME SOAP libraries work best with Axis and J2EE web services backends. Plus, web services in the mobile world are more likely to be asynchronous rather than the simple RPC format. J2EE messaging services (SAMS and JMS) are important in those efforts.

2. In the wireless world, bandwidth is precious. SOAP is often considerred too "heavy". If the end-to-end integration is based on compressed binary streams, to use the Java I/O on both ends would work better.

3. For a company that builds end-to-end solutions, it is far cheaper to assemble a team with people with similiar skill sets (Java, in this case) rather than hiring inhouse experts on all development platforms.

So, today, J2EE backends are still the best to drive occassionally connected J2ME frontends.

Also, Re: Serge: Yes, I completely agree that m2m is important. It fits into the whole end-to-end integration idea we discuss here. Thanks for the input.
serge masse 12/29/03 05:18:09 PM EST

Michael is probably right again, for the most part. So I consider his opinion with great care. It also helps that I share most of what he just wrote and I have observed this a while back, specially with some B2B work involving JPMorganChase and some of their clients. Games are not enough for the mobile enterprise, this should be obvious. And what the enterprise has difficulty today is with M2M, machine-to-machine interaction (grid, web services, etc) with and without mobile devices. This m2m stuff will be the main focus of technical improvements over the next 10 years at least. The trend was triggered by the Internet years ago and it is still going on and accelerating technologically and increasing in complexity. These new interoperability standards are a sign of this.

Mobile devices are now a new requirement for the m2m needs of the enterprise, so a J2ME developer must be able to fulfill the m2m needs.

m2m is very difficult.

I must nevertheless point out that the replacement of programmers by code-writing software is a long way off. Sure there will be a larger portion of programming jobs going offshore but offshore locations have their own serious business problems, such as insecurity and higher project management costs. So eventually there will be an equilibrium.
Dan Moore 12/28/03 05:53:08 PM EST

I don''t see why Michael ties J2ME and J2EE so tightly. The whole point of web services is to decouple the server and the client. I dont'' see any reason why you couldn''t have J2ME talk to a .NET server, or a BREW client talk to a J2EE server. To me, the larger issue with the mobile revolution is the architecture of the J2ME applications, since I think that such small, non networked, memory constrained applications (with either extremely limited portability or extremely limited user interfaces, take your pick) are going to be a world apart from the standard java developer''s experience (which is HTML generation, not swing).