Jason Delport Home

Blog Feed Blog Feed

Paxmodept Website Paxmodept Website

Contact Information


Jason Delport

+44(0)7931445721

jason@paxmodept.com

Download vCard


Mobile Portal


~mobile.paxmodept.com~
QR Code

Blog Archive & Stats


MonthPosts
November 2009(3)
October 2009(3)
September 2009(7)
August 2009(1)
July 2009(2)
June 2009(4)
May 2009(7)
April 2009(5)
March 2009(10)
February 2009(10)
January 2009(19)
December 2008(11)
November 2008(16)
October 2008(28)
September 2008(7)
August 2008(19)
July 2008(17)
June 2008(13)
May 2008(11)
April 2008(11)
March 2008(18)
February 2008(17)
January 2008(19)
December 2007(8)
November 2007(29)
October 2007(38)
September 2007(30)
August 2007(50)
July 2007(46)
June 2007(38)
May 2007(20)
April 2007(16)
March 2007(35)
February 2007(28)
January 2007(36)
December 2006(26)
November 2006(42)
October 2006(39)
September 2006(26)
August 2006(16)
July 2006(4)
Total785


© 2008 Jason Delport

Full Ecosystems beat Autonomous Execution Environments?

Sprint have recently announced that they will be implementing Qualcomm's BREW on some of their mobile devices. Sprint were one of the few CDMA based network operators to choose Java ME over BREW and even went so far as to invest heavily in their own Java application execution platform so this is a surprise move. In my eyes this is another nail in the coffin of Java ME in its current configuration.

While BREW has many shortcomings compared to Java ME there is one factor which really distinguishes it and that is the fact that it provides an entire end-to-end architecture with a built in application distribution mechanism (aka "application store"). At the moment it seems that solitary application execution environments just can't complete with an full end-to-end infrastructure. These ecosystems whose features include an SDK, application execution environment, search and discovery mechanism, robust deployment and provisioning solution, payment mechanisms, fragmentation management and administration are far more appealing to network operators than investing in relatively autonomous 3rd party application execution environments like Flash Lite, Java ME, .net CF, Python etc.

Basically if I was a JVM vendor I would be working hard to extend the on device Java Application Manager to become a sophisticated application distribution environment which includes the requisite backend infrastructure necessary to offer a full ecosystem. This would also provide large software vendors like Aromasoft, Aplix and Esmertec with new revenue streams beyond simply selling JVMs. Thoughts?

Update: I wrote something similar to this at the start of the year.




~Comments~

C. Enrique ortiz declares...

What got J2ME in trouble was its "silo" approach. This approach was due to Sun's philosophy of creating specs and APIs and JVM and let the ecosystem/vendors define the rest. In theory it sounds like a good "open" philosophy, but without E2E strategy it results and resulted in fragmentation. Isn't that ironic? Sun's idea was to be open, and openness meant way too many people involved and slowing the process down and also meant no unified E2E solution, hell, no E2E at all. I saw this happening in front of my eyes. I remember time ago going to some Sun folks about the importance of application discovery (and security) as the 2 top issues to address, but they didn't get it and were stuck on "letting others define that". That is when I had the idea to do YouApp. In any case, sometimes even having all the E2E pieces is not sufficient - this must be done at the right time with the right attitude or it will be ignored.


Date Mon, 14 Sep 2009 at 20:56:17

~Add Comment~

Name
Email
Website
Website
Website
Comment (No HTML)
Human? Human?