another great article by Michael Yuan

[serge masse]

http://www.sys-con.com/story/?storyid=38365&rss=1

[serge masse]

Michael makes good points about the need to focus attention to the communication between the mobile device and the corporate back end.
We now have good specs and free development tools and free services (e.g., Handango) for delivering mobile applications to mobile end users, but we don't have free services for hosting interactive applications, i.e., mobile applications that interact with the back end. For this thread, lets call this type of app *m2n* for mobile-to-non-mobile. This means that after a developer completes her mobile m2n application, she is left incapable of demonstrating it without herself developing and hosting a back-end demo.
As far as I could find (actually *not* find), there is no free demo services for the m2n applications that Michael and I are focussing on. If I am wrong please let us know. This is important to me.
So it looks like with the advent of TCP/IP capable devices such as the MIDP2 phones and pdas there is a growing unfulfilled demand for a service hosting m2n apps for the independent mobile software vendors.
Any company offering MIDlets today, or hosting small to medium size web sites, should be considering adding this feature to their web site. It is not a cheap one to setup and manage so I expect some charges for the service. But I for one would be willing to pay for such a service. I have an m2n demo righ now and no one can use it because it is not hosted.
please comment.

[Stephen Pride]

Have you thought about MyCGIServer.com? It allows for free Java web application support.

[serge masse]

Stephen,
thank you very much for the tip. I did not know mycgiserver.com and it looks great. I will give them a try.

[Stephen Pride]

No problem. BTW, I am in agreement with you in Michael regarding mobile J2ME front-end applications to enterprise (J2EE) web applications as being a huge market that is just now in its infancy. Lot of opportunity for the savvy entreprenuer.

[Pavlin Mihalev]

Hello,
The article is extremely interesting but in my humble opinion mobile Wi-Fi terminals will make the communication with the corporate back end and thus the need of j2me will be obsolete.
What do you think ?

[Michael Yuan]

Originally posted by Pavlin Mihalev:
The article is extremely interesting but in my humble opinion mobile Wi-Fi terminals will make the communication with the corporate back end and thus the need of j2me will be obsolete.
What do you think ?

Hmm, WiFi is just a data bearer, right? I can have J2ME applications running on a WiFi PDA. Most people use WiFi with laptop or Tablet though. But, that illustrates a key weakness of WiFi: It mainly covers areas where people are comfortable with laptops. You cannot use WiFi while you are driving, for instance.
Also WiFi's pricing structure is very complex. While I am tarvelling, I am always frustrated by the fact that each airport uses different WiFi providers. A national 3G network would be much better ... I do not believe that WiFi can replace 3G even in wireless 3rd world countries like the US.

[Pavlin Mihalev]

It seems that Wi-Fi is "happening" more quickly than 3G. Very soon there will be enough hotspots even on the road, so all you'll have to do is to drive to the next McDon. or the next gaz station to connect your laptop.
On other hand 3G is a data bearer as well, so why not plug a GPRS/HSCD/WLAN card modem in the laptop and stay connected everywhere.
The main advantage of a j2me device is that it's connected, but with Wi-Fi that's no more the same situation.
[ January 07, 2004: Message edited by: Pavlin Mihalev ]

[serge masse]

J2ME has many advantages for mobility over J2SE. Yes J2SE applications can be more mobile today because they can use Wi-Fi but there are very few J2SE laptop applications today. Non-J2ME Java applications are mostly on the server side.
As the J2ME mobile devices are selling much faster than laptops, the Java world is booming in two areas: J2ME and J2SE/J2EE on the servers. And obviously, the quantity of J2ME devices is now much larger than non-J2ME Java platforms.
So, we can say that J2ME is much more *successful* than other Java environments.
Furthurmore, this will accelerate over the next few years at least, as J2ME has serious advantages for the end-user over the other Java environments. For example, with a MIDP2 device the end user can download and install a new application over-the-air (OTA), something which is harder to do in J2SE even with Wi-Fi.
And on top of that, OTA is part of the specs, so developers of MIDP2 applications don't have to write any code for their application to get that feature.
This is not a complete list of J2ME/MIDP2 advantages but it highlights the current trend.
Anyone sees other major advantages of J2ME over non-J2ME? or vice-versa?

[serge masse]

just to specify that in my opinion, the main advantage of J2ME over other Java environments is that most of the devices are shipped with J2ME-compliant platform included in the box. For the consumer, this is the most important and this is the advantage of J2ME/MIDP over Applets, for example. Applets required a Java plug-in in browsers that had to be downloaded and installed, as a separate and slow process, for most consumers. This was one reason why applets did not really become commonplace, although there are many in use today.
this out-of-the-box advantage of J2ME is implied by my above post but not specified. It is important to see it clearly, specially for consumer applications.
also, Java, i.e., Sun, could easily produce a robust and sophisticated J2ME environment partly because Java was originally designed as a device platform, back in the early 1990's. Microsoft is still having a hard time to deliver a robust sophisticated environment for small devices based on Windows. Their latest platform is being rejected by many device manufacturers these days.

[Michael Yuan]

I am completely agree that the OTA spec and the MIDlet execution model are two major advantages J2ME has over J2SE. True, you can still run managed provisioning solutions such as the OSGi on a laptop. You can also write J2SE applications that can be paused or be multi-modal. But those are much easier in J2ME.
But perhaps more importantly, J2ME enables pervasive data access -- a person can carry many J2ME devices (from medical sensors to barcode scanners to GPS receiver) while walking around. You cannot exactly do that with a laptop or a tabletpc.

[serge masse]

Michael, and everyone else,
how do you compare the security models of MIDP2/J2ME vs. J2SE?
which one is better for the developers?

[Pavlin Mihalev]

Hello again,
I'm afraid we are a little bit loosing the topic ... About the communication between the mobile user and the corporate back end
I think that the user will prefer to use a laptop conected through Wi-Fi or pcmcia card rather than one or more j2me devices. It's a practical question I think - you can do more things quickly on a keyboard.
Cheers

[Michael Yuan]

Originally posted by Pavlin Mihalev:

I think that the user will prefer to use a laptop conected through Wi-Fi or pcmcia card rather than one or more j2me devices. It's a practical question I think - you can do more things quickly on a keyboard.

Well, for composing an email or write a Java program, keyboard is efficient. But for many other tasks, keyboard is just inconvenient (isn't this why they invented TabletPC?)
For example,

When I am vacationing on a Hawaii beach, I would like to have my important messages *pushed* to my smartphone (which I can carry and the battery can last a full day) rather than having to pull a web mail interface from my laptop.

When I am trying to order a drink on the beach, I'd like to bill directly to my cell phone account (with an IR scanner) rather than pulling up the seller's web site.

When a nurse is trying to locate her next home visit patient, she would prefer to read the assignment and driving directions (using GPS) directly on her car phone rather than having to stop and connect ...

[serge masse]

Nice examples, Michael.
I would like to point out that many new J2ME/MIDP devices offer optional keyboards for those that want to type long text. In a few months, some of these keyboards will be virtual, i.e., a projected image on a flat surface.

[serge masse]

I sure would like to get some opinions on the differences for the security features of MIDP2 vs. J2SE.

[Michael Yuan]

Originally posted by serge masse:
I sure would like to get some opinions on the differences for the security features of MIDP2 vs. J2SE.

The basic underlying security technologies for authentication and authorization are pretty much the same, right? But I think MIDP developers tend to be more security concise since the carriers and device vendors tend to enforce more strict security policies. Most J2SE applications I see do not utilize any of the security APIs.

[serge masse]

Does this mean that the security features of MIDP2/CLDC1.1 are mostly built-in the device runtime, in the carrier networks, and in the server application?
In other words, are there recommendations for security features that developers *must* include in their design for applications involving MIDlets communicating with corporate systems? Or is most of the security requirements for such an application pretty much taken care of by runtime designers, carrier network designers and corporate app servers designers?
This subject might have been covered by Michael's book but I did not buy it yet. If it is covered, I sure would like to know as this would give me more incentive to justify the *investment*.
The one feature I see is the encryption of confidential data, as this is a requirement for any data transfer over a public network. That's taken care on on the device side by including SSL in MIDP2 specs: HttpsConnection, SecureConnection.
what about authentification? where is this taken care of? Is there any components of MIDP2 specs defining authentification? I am not familiar with the security features of the specs yet.
any other security features to worry about?
thanks,
serge
[ January 08, 2004: Message edited by: serge masse ]

[serge masse]

I can confirm that Michael's book on J2ME, *Enterprise J2ME: Developing Mobile Java Applications*, does a fantastic coverage of the security issues for J2ME/corporate systems:
I read the table of contents on Amazon.com and it is quite large. As a summary this is what Michael wrote on his web site on *some* of the security issues covered in the book, there are more:

Advanced mobile data security beyond the HTTPS
* The algorithms covered in this chapter include symmetric and public key encryption, digital signature and password based encryption.
* J2ME cryptic libraries discussed in this chapter include solutions from BouncyCastle, Phaos, IAIK, NTRU and B3 Security.
* Detailed source code recipe for each task using each toolkit will be provided.

Now I have to save and buy it.

[serge masse]

Another important issue with corporate J2ME is the need for data synchronization with corporate databases.
This also makes me think that another major problem is the one of data _integrity_ and not *just* _security_. Maybe one could write a book on this point.
And such needs are probably not fulfilled by open source code yet. There are many opportunities here.

[Michael Yuan]

Originally posted by serge masse:
Another important issue with corporate J2ME is the need for data synchronization with corporate databases.

Yes, my books covers various mobile database synchronization products and their J2ME APIs. Most of them have build-in support for encryption for wireless data traffic. All of them are commercial products. I do not see a good Open Source mobile database synchronization solution yet.

This also makes me think that another major problem is the one of data _integrity_ and not *just* _security_. Maybe one could write a book on this point.

Well, part of the security requirements is "integrity". This is why we use secure hashes. Right?
cheers
Michael

[serge masse]

Thanks for the feedback Michael.

Well, part of the security requirements is "integrity". This is why we use secure hashes. Right?

That's fine but what I meant by *integrity* is mostly located at the database model level and at the business objects level. For example, the integrity features of relational databases must be extended to include distributed components, some of which are on individual user devices and not all at some central repository. The concepts of database integrity, already complex for a central corporate database, becomes exponentially more complex when you add distributed (mobile) components. I have been making large robust databases (that will not get corrupted because they are designed with time honored practices to preserve data integrity) and make small robust distributed databases with mobile devices, but I know that large distributed databases are the bleeding edge of current practices. The size of the complexity make such databases very expensive to develop, partly because we don't have time honored practices for distributed databases, and this is so partly because our current practices require a central database.
I have not looked at Oracle's G10 yet and I don't know how *distributed* it is.
If a cowboy or cowgirl has pointers on best practices for robust distributed databases, please let us know here.
thanks,
[ January 10, 2004: Message edited by: serge masse ]

[serge masse]

The buzz is picking up volume:
see *MIDP 2.0 - Fun yes, but not just games*
Sue Spielman (January 15, 2004 4:06PM PT)
http://weblogs.java.net/pub/wlg/911
and
http://www.mobilogics.com/

[Mark Spritzler]

Nice article Michael. I think also a real important advancement needs to be creating and implemented before some really great mobile enterprise applications can be created.
That is the Database, the storage capacity of the mobile devices and the speed at which the data can be transferred between the mobile device and the back-end.
PointBase has a cool little database for mobile devices that can also synchronize with Server style RDBMS like Oracle. However these mobile databases can only be filled with data when it is directly on the actual device. Meaning you cannot load the data from your desktop into their little mobile database, then copy the files to your mobile device. So if you have a catalog of 8000 items, then it will take a little while to install your data onto the mobile application. And if this application is on a consumers mobile device, then the consumer will be the one waiting.
Also Michael, it said that you are turning down all those J2ME contracts. If you want, you can send them to me
Good Luck and thanks for all the advice.
Mark