Esri Java State of the Union

So in my small brain, I see Esri Java Server solutions as the only way to effectively and economically deploy and scale ArcGIS for Server in any hosted environment[ref]I refuse to use the “c” word that rhymes with loud[/ref].  The idea that I’d scale any ArcGIS for Server on Windows in AWS is simply crazy talk.  Because of this line of thinking, I’ve been watching for the “new” Esri Java Server products that hopefully are right around the corner.  Well Esri has posted a “Java State of the Union” for everyone to read:

Esri’s ArcGIS and Java strategy is pervasive, in and through all of the key computing environments that Java is found in, from Mobility to the desktop and to the Enterprise. This makes Esri’s GIS and Java a perfect match for any Java-based implementation that requires the delivery of geospatial or location services and capabilities.

So it looks like Esri is continuing to invest in ArcGIS for Server Java and hopefully we’ll see it available on platforms other than RHE and SUSE[ref]*cough* Fedora *cough*[/ref].  Java still feels like an afterthought for much of Esri’s push, but at least we’ve got a dedicated team trying to get Server where it belongs.

OK, everyone together…. “Java…… in the Server…… Make me happy……. Make me feel fine. Java….. Make me warm all over…”

The ESRI Web ADF 9.3

Remember this post?  Count that as the most popular post ever on my blog (so much for a positive post being my watermark).  Anyway Doron Yaacoby has followed up almost a year and a half later with another look at where ESRI has taken the Web ADF since then.

Almost none of the issues I addressed in my original post were fixed. The API is still overly complex. Resources, functionalities and all these so-called abstractions remain in place, emphasizing the strength of the JavaScript API’s simplicity. And yes, there are still about a billion classes that are named “Converter” in the API. It seems like ESRI insists that you write the entire namespace before every class you use.

Yea that was probably predictable, but I don’t think any of it matters.  We’ve all moved beyond the Web ADFs and on to the REST APIs (Flex, JavaScript and Silverlight).  Really though I’m amazed at how much our web development platform has changed in that time, we all can agree developing with ESRI is much more enjoyable than it was and I’m wagering most of us forget there is a Web ADF out there anymore.  I can’t wait until the ESRI UC to see what the future holds in store.

The killing of .NET and Java on the web continues unabated

The killing of .NET and Java on the web continues unabated.

HTML 5 SHOULD Kill Flash and Silverlight

A great article has appeared about how HTML 5 really should finally kill off the proprietary Flash and Silverlight browser add-ons.

HTML 5, a groundbreaking upgrade to the prominent Web presentation specification, could become a game-changer in Web application development, one that might even make obsolete such plug-in-based rich Internet application (RIA) technologies as Adobe Flash, Microsoft Silverlight, and Sun JavaFX

All this focus on Flex/Flash and Silverlight is really beside the point in my opinion.  Sure maybe today, we have to rely on these proprietary browser plugins to deliver content to users, but the real innovative developers and companies are going to standard on HTML 5 and in turn revolutionize how users interact with data.  We all want faster web applications and the only way to deliver this is to use HTML 5.  Of course some companies can’t get their act together to support it (I’m looking at you Microsoft), but given how positive people have been toward the Google Chrome browser and how it works with their web applications, I think we are really very close to a revolution here.  The question we need to ask ourselves is to you want to be in the front, or the rear of change?

MechaHTML5 pushes proprietary browser add-ons to the side.

MechaHTML5 pushes proprietary browser add-ons to the side.

HT: DF

ESRI DevSummit – The Gift that Keeps Giving

ArcGIS Code Challenge Winners Announced

Looks like Alper Dincer and Matthew Petre are the big winners.  The mobile code challenge results are posted as well.  I suppose they announce this after the DevSummit so the winners don’t have to buy everyone beer.

VBA and VB6 with ArcGIS: What’s the Story?

First off I bet you didn’t even know there was an ArcObjects blog.  Second, please move off of VBA or VB6.  Last year I said the writing was on the wall, this year the wall is falling down upon you.  Python, Java or .NET;  take your pick and enjoy.  There is nothing you can’t do with those choices and in fact gives you much more freedom.

Silverlight API

Vish is taking it for a spin and he’s reporting back on its use.  Bookmark or subscribe to Vish.

Virtual Earth and ESRI ArcGIS

This seems to be getting a ton of play.  One thing to remember folks, yes VE is free with ArcGIS Desktop and ArcGIS Explorer 900, but you need a valid license.  If you download AGX 900 and don’t have a valid ArcGIS Desktop license, you won’t be seeing VE imagery.  Yea that sucks for the world, but every ESRI user should buy Jack a drink at the UC in San Diego for paying for this.

Picking a web front end

Dave Bouwman has a great blog post on all the different choices available to ESRI centric developers for a web mapping front end.  Not a bad primer for folks still trying to figure out all the new options we have available for visualization.

 

Ill take a side of RESTful with my mapping front end please.

I'll take a side of RESTful with my mapping front end please.

I come to praise the Web ADF, not to bury it

I was just talking to someone today about web applications for ArcGIS Server 9.3 and they were surprised that I was using the Web ADF to create an application after my post earlier this week on the JavaScript API.  I feel like I need to clarify some things about that post.  It wasn’t so much a desertion of the Web ADF, but point that one should be looking toward the JavaScript API (and I suppose the Flex API) for most mapping situation and use the Web ADF (Java and .NET) when it best makes sense.  I’m using the Web ADF on this project because the requirements of the end user is best met with the Web ADF.  The great thing about the JavaScript API, the Flex API, the .NET Web ADF, the Java Web ADF and even the JavaScript extenders for the JavaScript API is that they all can be called on if needed.  Of course the Web ADF does have licensing issues that ESRI needs to address that limit its appeal even when it is the best choice for the solution. 

ESRI has given their developers choices that we aren’t accustom to and in turn ESRI developers should be looking at the choices when making a decision of what SDK to use.  Also just because you use the JavaScript API or the Flex API doesn’t mean you’ll end up with a great application.  So much more goes into it and there isn’t any reason why the Java Web ADF can’t give you a great application anymore than the Flex API can. 

Et tu, James?

Et tu, James?

The ESRI WebADF and the ArcGIS JavaScript API

I find it interesting that most work I’m seeing these days is with the JavaScript API that ESRI released at ArcGIS 9.3. I assumed a couple months ago that people would really be looking at moving off of the WebADF (.NET or Java) for the JavaScript API and it appears that this trend is beginning to happen. Now before you think that I’m really sticking a fork in the WebADF, think again. The WebADF will continue to grow and be used where it makes sense, but probably not as the “default” mapping front end for ESRI web servers. The simplicity of the JavaScript API and the way it works, makes the classic WebADF and HTML viewers obsolete for most users (I’m still waiting to see what ESRI does with Silverlight, but that discussion is for another day).

Also, coupled with the JavaScript Extenders for Google Maps and Virtual Earth, there is probably very good reasons to be looking this way instead of deploying the WebADF. I’ve also seen people abandoning third party “helpers” for the WebADF such as Geocortex Essentials (I guess we’ll see JavaScript API tools from these companies soon, eh?) to move back to simpler JavaScript front ends. There are times and places for .NET or Java server solutions, but what the JavaScript API has done is allow ESRI customers and implementors to go with a more lightweight solution and in turn brings them to more cutting edge RESTful and JavaScript technologies that can be leveraged outside of the ESRI silo.

I’ve really started to try and point my clients (and anyone else who asks) away from the Java and .NET WebADF and toward the lightweight ESRI JavaScript API. Everyone who has moved in that direction has really been satisfied and given the 9.2 release of ArcGIS Server, that is really turning things around.

James seems to be pushing ArcGIS Server again

James seems to be pushing ArcGIS Server again

deCarta looks to LBS for a future?

So deCarta has a new product called deCarta Mobile. Everyone has their own mobile development platform, so why not offer your own? I’m sure they have some developers lined up to showcase their Java LBS platform so there will probably be some interesting apps coming forward. I can understand that deCarta brings much expertise to the LBS arena, but I’m just not sure that will matter much given the huge developer bases for Android and the iPhone (I await Glenn‘s comment below about Nokia mattering).

In the end I suspect this is a niche platform for users who need a very specific application and not meant for consumer applications (not saying that it isn’t possible, just there are other SDKs that developers might choose before this one). deCarta did a good job of explaining why they think they are important in the hosted service world in the comments of this post on the Virtual Earth /Live Maps Blog.  Ignore all the porn links and go to the last comment (note to Microsoft, Live Spaces is a horrible blogging platform and using it just proves to everyone what a poorly thought out concept “Live” is).

The deCarta model might be just what some companies are looking for (being able to pick and chose providers or hosting your own data) and I suppose we’ll see how if deCarta Mobile takes off. For me Java is irrelevant on the mobile platform (iPhone) and on my desktop (I think only my Oracle management tools are Java) so I’m definitely not its market.