Showing posts with label Java EE. Show all posts
Showing posts with label Java EE. Show all posts

Friday, June 29, 2007

AJAX JSF on Mobile

Long long ago, I had written an article in Computers Today about WAP. It was in November 2000 issue. What I had written then about server side delivery will be preferred way is still true.
Ericsson has released an open source JSF renderer for mobiles! get the presentation here.
You can also download the source from their site.

The advantage of using Java EE to deliver application to mobile is that you don't have to support multiple versions for each vendor and even intra vendor's platform. And unlike Nokia's SDK, which is too fat, Ericson has a small footprint and thus does not lock the developer in.

Recently Sun and Ericsson are collaborating to marry Java technologies with telecommunications. Not that Java was not present in the telecom space, it had JAIN (Java Advanced Intelligent Network) But then there was Parlay led by Microsoft. Now Sun and Ericson have collaborated to produce Parlay interop with Java EE. It too is open source.

To avoid confusion here, I must add that I am talking two different things here. The enterprise applications connect B2C where as AIN (Advanced Intellegent Network) application are more of telecom domain applications like delivering caller tunes of your choice or call divert or voice mail service. Thus you could think it as O2C (Operator to Customer) applications. The only common thread here is the use of Java EE technology.

Sunday, June 24, 2007

Netbeans Does Not Use Grizzly Yet

Its a bit sad to figure out that Netbeans.org does not use Grizzly!
Now if you are wondering what all this is all about? Let me clear the bytes for you. Netbeans is the Sun's flagship IDE. Competing directly with Eclipse. Grizzly is the NIO framework within Glassfish. It has been proven within Sun, that Apache does not scale beyond 4 cores, whereas Glassfish with Grizzly technology scales well beyond.

However I figured out that Netbeans uses the old technology circa 1999. where Apache sat in front and connected to Tomcat or any other Java Server using AJP (Apache Java Protocol)

Don't ask me how I figured out that netbeans.org uses Apache 2.0.50 (as of 24 June 2007) as HTTP server.

I would like to appeal to Netbeans admin to seriously consider using Glassfish.

Jetty 6 , which also uses NIO, run their web site on Jetty itself! That's what I call confidence!

Monday, June 18, 2007

Java ME versus Java EE as a Career Option

Jatin my mentee at techTribe, asked a question :

"can u tell me about the scope that j2me has in the industry?"

This blog entry attempts to answer the above query.
First J2ME has been re-branded as Java ME. So is J2EE as Java EE, and yes you guessed it J2SE is now Java SE.

Now that you have fallen in love with Java, (I fell for it when it was in beta circa 1997, and now happily married to it, though I have a mistress called C# :), after the initial infatuation stage, you will need to evaluate the career options.

First Java ME is heavily fragmented and most of the manufacturers support is as an afterthought. All these manufacturers have an alternate C++ SDK and their own custom options.
Nokia and Moto are two 400 pound gorillas in the mobile arena. Though these two support Java ME, they have their alternative SDK. Any real life application would have to use their SDK and be tied down to their platform. Moreover Sun has launched Java FX recently, which is targeted towards RIA (Rich Internet Application). Though Java FX is a layer over Java SE and ME, it does puts spanner in the Java ME's gears. talking about gears, it reminds me of Google..why? check out Google gears but that's another story and lets not digress.

Java ME has serious competition from RIA see Google API and apps for mobiles. Also Microsoft have been slowly and steadily been chipping away at the mobile OS market.

So Java ME is in its way out to join the Applet club (Going to Caribbean into the Dead Man's Chest, with apologies to the Pirates trilogy)

Lets understand why Java ME is going under. First, Google is leading a gang of RIA developers, the advantage of delivering an XHTML application with AJAX, is that most mobiles have a good Internet connectivity. Also distribution and lifecycle management is much easier. RIA apps can also remain offline and sync when network catches up, this is done by leveraging the cache technology.

The Microsoft's mobile OS initiative is more serious, since they have more at stake than Sun in this space.

That's because after Jonathan Schwartz took over, he buried the hatchet with Microsoft. So, no more mindless Gate's bashing. Also he re-focused Sun's strategy and Sun is now making ALL its software open source! So how does Sun makes money? Good question and answering it will answer your query as well.

Sun makes its money by selling high end servers, and that is not the dual core types but more like 128 cores :) Check out Sun Blackbox as an example. Sun is also very good at making apps runs faster on their Solaris and extreme hardware platforms. For example, I have a patent (owned by Sun), to make Java faster than 'C'. So Sun really does not make money on simple hand-held devices, but by selling high end servers.

Given that Java EE has a mobile extension for RIA (Ajax, xHTML) its more of interest to Sun if applications are delivered from servers than embedded inside mobile devices.

Thus if you are wanting to go for Java, go for Java EE not ME. Sun is more focused on EE.

Now when I read the Nokia's tag line "This has what computers have become", Sun's Blackbox comes to my mind and not Nokia's N series.

I hope I have answered your query.

Saturday, June 02, 2007

Dynamic Configuration Management For Clustered Java EE

I have posted a tech. brief at http://www.ashishbanerjee.com/dyna-config-25may07.pdf
This technical brief, first describes the dynamic application specific configuration, then describes an use-case scenario. Thereafter, design constrains and solution architecture is described. Two
implementations are proposed.

Also a programmer's guideline is provided for using the dynamically configurable application parameters.

It is concluded that a JNDI wrapped LDAP store is the best solution, followed by Entity Beans and
finally by Java Spaces.

However, all the three implementations are transparent to the application programmer, who uses JNDI abstraction to access the parameters.