Feeding Content to Keitais
We spent a day at Sun Microsystem’s JavaOne conference and show in Yokohama in September, and were pleasantly surprised to meet up with mobile software vendor Openwave, grand-daddy of the WAP Forum (freshly repainted as the Open Mobile Alliance). Japanese carriers have created killer Java services… and they had to do so from scratch. That included the provisioning system which actually feeds the applis onto the handsets (providers merely have to write the downloadable Java code). Now another major player has launched a Java provisioning system (which also works for other content). Want to launch Java, but you’re not partnered with DoCoMo? You’d better watch this one twice…
Comments from Wireless Watch Japan Editor-in-Chief Daniel Scuka:
Motives aside, they demo’d a very cool content download solution comprising a server-side download manager and a client-side Java. application manger. Together (and combined with a microbrowser), these form a content provisioning system particularly applicable to Java.
We were impressed. Sure, Japanese carriers have already rolled out their own Java services, but remember that back in ’99, no one had yet done so; arguably the real feat in launching i-Appli Java on, say, DoCoMo’s i-mode, was in creating and engineering the provisioning system — the mechanism by which the Java applis actually get loaded onboard the handset via the air interface. And don’t think Sun was any huge help; their Java technology addresses the programming language used for those Java games — as well as the onboard environment that executes them, but says very little about how they get there in the first place.
If an i-Appli doesn’t pass muster (because it violates a security condition by, oh, for example, sending 12 zillion packets per second to ‘whitehouse.gov’) then the Java application manager won’t let it download to the handset.
NTT DoCoMo’s proprietary onboard Java application manager software is notable because it allows for a very robust security framework for the i-Appli Java system. The JAM mediates how i-Applis are accessed, downloaded, managed, stored, and executed by the handset. If an i-Appli created by a third-party developer doesn’t pass muster (because it violates a security condition by, oh, for example, sending 12 zillion packets per second to some domain like ‘whitehouse.gov’), then the JAM won’t let it download to the handset. As a result, DoCoMo can allow third-party developers to create and host independent i-Applis, and therefore i-moders have a huge library of Java i-Applis with which to amuse themselves; their J-Phone- and KDDI-using buddies have a much smaller Java selection to choose from, and all must be vetted (to varying degrees) by those carriers.
If Openwave has created a system that is similarly robust and that would allow carriers elsewhere to open up their Java and mobile content services (like ring tones, images, etc.) to third-party development, then they may just have a winner on their hands. In today’s webcast, WWJ sits down with a couple of knowledgeable folks from Openwave to find out more about their new software and about content services for cell phones, and we hear what consumers are willing to pay for camera phones versus what it costs makers to put those tiny CCD-thingys onboard at the factory (hint: the difference is **real** steep).