April’s Contributions on Bright Hub

In April, I contributed two articles to the Web Development channel over on Bright Hub:

• Introducing The Aptana Cloud
• HTML vs. XHTML: The Five Key Takeaways

Book Review: Google Web Toolkit

Automagically convert Java to JavaScript. 

Thus begins the seemingly curious proposition of the Google Web Toolkit (GWT). 

Of course, it’s about a lot more than that. 

For one thing, GWT addresses a key gap in the rapid delivery of the Asynchronous JavaScript and XML (AJAX) based applications that are driving eyeballs and mindshare to Google’s Web site.

By the time you’ve read Prabhakar Chaganti’s book on the GWT, you’ll be significantly wiser on at least two fronts. You’ll know that:

1. There’s a broad-and-deep software engineering ecosystem around the GWT that is fueling progress and delivering highly significant results. 
2. Chaganti is an excellent guide with the ability to negotiate this ecosystem and drive you towards tangible outcomes.

Using a task-oriented approach, the book proceeds as follows:

• Chapter 1 rapidly places the GWT in context, and gets you started by downloading, installing and working with the samples provided. Available for Apple Mac OS X, Linux and Microsoft Windows, the GWT only requires the Java SDK as an installation prerequisite. The GWT is made available via the Apache Open Source license; this allows for the development of commercial and Open Source applications. 
• With the Java SDK, the GWT and the Eclipse IDE, the developer has a well-integrated and powerful platform on which to develop applications. After illustrating the development of the obligatory “Hello World!” application at the outset of Chapter 2, attention shifts rapidly to use of Eclipse. Google’s Web-wired DNA is evident in everything they do, and the GWT is no exception. The GWT leverages the Java SDK and Eclipse to the fullest, while closing the gaps in developing AJAX-based applications in a very organized way. By the end of this Chapter, the reader knows how to develop a simple application with both client and server-side components and execute the same in both hosted (i.e., non-deployed) and Web hosted (i.e., executing within a Web-hosted Tomcat servlet container). Made explicit in this latter deployment is GWT’s ability to support a variety of Web browsers – i.e., Apple Safari, Microsoft Internet Explorer, Mozilla Firefox and Opera.
• The creation of services is the focus of Chapter 3. To quote from this Chapter, and in the GWT context, service “… refers to the code that the client invokes on the server side in order to access the functionality provided by the server.” The author is quick to point out that this is a separate and distinct notion from that used in the context of Web services. True to its billing, this Chapter works the reader through the creation of a service definition interface (a client/server contract that defines the service’s functionality and establishes rules of usage) and service implementation. Particularly important in this Chapter is the creation of an asynchronous service definition interface, as this facilitates remote calls in the background to the server, and capitalizes on the AJAX support in the GWT. With definition and implementation taken care of, the remainder of the chapter focuses on use (i.e., consumption of the service by a client). Conceptual illustrations compliment screenshots to effectively convey this content. 
• Whereas the previous chapter delivered a prime number service, Chapter 4 introduces no less than six services that really showcase the capabilities of this application paradigm. With ample explanation and illustration live searches, password strength checks, auto form fills, sorting tables, dynamically generated lists and Flickr-style editable labels are each considered. Not only does one recognize these as design patterns that are already in everyday use (e.g., Flickr, Google Docs, Maps and Search, etc.), one also realizes their potential for re-use in one’s own projects. 
• Chapter 5 introduces five interfaces that are more complex than those presented in the previous chapter. These interfaces are pageable tables, editable tree nodes, log spy (the GWT spin on the UNIX tail utility), sticky notes and jigsaw puzzle. To reiterate, one recognizes these as design patterns already in everyday use, and the potential for re-usability.
• Browser effects are the subject of Chapter 6. Here the author introduces the JavaScript Native Interface (JSNI) as a vehicle that allows JavaScript libraries (e.g., Moo.Fx and Rico) to be accessed directly from Java classes. A wrapper-based approach, independent of JSNI, is also introduced to leverage the Script.aculo.us effects. Although compelling effects can be achieved, cautionary words are included in this Chapter, as the impact may be diminished by browser-level incompatibilities.
• By the end of Chapter 7, impressive calendar and weather widgets have been created, and readied for re-use. 
• In Chapter 8, JUnit is introduced in the context of unit testing. Standalone tests plus test suites are given consideration; this includes tests involving asynchronous services.  
• Although this is only the second book I’ve ever seen from Packt Publishing (the first I’ve reviewed elsewhere), I’ve become accustomed to expecting bonus content towards the end of the book. Chapter 9, which addresses internationalization and XML support, falls into this bonus category. Of course, it’s no surprise that Google expertise on internationalizations ranks high, and this is evident in GWT support for the same. The author provides an hors d’oeuvre of the possibilities. XML support is of particular personal interest, so I was delighted by the degree of support for creating and parsing XML documents. I share the author’s sentiments with respect to XML support wholeheartedly: I too hope that future releases of the GWT will provide broader and deeper support for XML.  
• In the final chapter (Chapter 10), attention is given to increasingly automated methods for deploying GWT-based applications. Starting with a manual deployment in Tomcat, then an automated deployment with Ant, and finally an Ant-based deployment from within Eclipse. 
• A single appendix details how to access and execute the examples provided throughout the book.

With the possible exception of a concluding chapter, page, paragraph or even sentence(!), to provide some sense of closure to the book, I am at a loss to report any omissions, oversights or errors of any consequence. And although it will have to wait for a follow-on contribution of some kind, additional discussion might be given to topics such as Google Gears or even Google Android.

Even though the book I reviewed was a complimentary copy provided by the publisher, I would happily pay for my own copy, and heartily recommend this book to others having interests in the GWT. 

By the way, Packt has an articulated scheme when it comes to Open Source projects:

Packt Open Source Project Royalty Scheme Packt believes in Open Source. When we sell a book written on an Open Source project, we pay a royalty directly to that project. As a result of purchasing one of our Open Source books, Packt will have given some of the money received to the Open Source project.In the long term, we see ourselves and yourselves, as customers and readers of our books, as part of the Open Source ecosystem, providing sustainable revenue for the projects we publish on. Our aim at Packt is to establish publishing royalties as an essential part of the service and support business model that sustains Open Source. 

I cannot suggest that Packt is unique in this approach. Regardless, their approach is certainly welcome.

BlackBerry Rules the Back Office – For Now …

I’ve had a BlackBerry 8830 for a few months now. And I must admit, I’m getting over my iPhone envy. (iPhone’s still aren’t officially available in Canada!) The 8830 has the tactile keypad I’ve grown to love, a (two-dimensional) trackball in place of a (one-dimensional) thumbwheel, GPS-based mapping, etc. This means that built-in WiFi is about the only capability for which I find myself wanting.

But enough about the client-side device (CSD).

So much of the value delivered to the CSD is because of what’s in the back office – behind the scenes, as it were.

In writing a book review on BlackBerry Enterprise Server (BES) installation and administration, I was reminded of this aspect on the ongoing BlackBerry vs. iPhone battle.

What’s in the BlackBerry back office?

Allow me to itemize:

• Integration – The BES integrates the CSD with the enterprise messaging platform (e.g., Microsoft Exchange, IBM Lotus Notes, etc.) and the rest of RIM’s BlackBerry universe. In addition to email and calendaring, this has the potential to include instant messaging (e.g., MSN, IBM Lotus Sametime, etc.) and more.
• Security – Because the BES provides a single locus of control (the BlackBerry domain), it can and has been leveraged extensively to deliver an industry leading environment for end-to-end security. Encryption, authentication, plus six levels for administrative roles, are all present.
• Policies  - To quote from my review:

The BES ships with over 200 policies that can be applied variously to users, groups and devices … The ability to administer users, groups and devices with respect to policies (including software), from a single point of control (i.e., the BES server), speaks volumes to the appeal and value that this offering can deliver to corporate enterprise environments. 

• Provisioning – The BES facilitates provisioning of users, groups, devices as well as associated software. Software can even be bundled and targeted to specific CSDs.

The back office supporting the iPhone has a long, long way to go to catch up with all of this – if that’s even a plan that Apple has.

In fact, a far greater threat to the back-office portion of RIM’s BlackBerry universe is the ecosystem developing around Google Android.

Book Review: BlackBerry Enterprise Server for Microsoft Exchange

Packt Publishing claims its

… unique business model allows [them] to bring [us] more focused information, giving [us] more of what [we] need to know, and less of what [we] don’t.  

If Desai & Renfroe’s BlackBerry Enterprise Server for Microsoft Exchange: Installation and Administration is any indication, Packt actually lives up to its claim. In just 172 pages, Desai & Renfroe achieve an enviable balance between being concise and being comprehensive. This statement applies as much to what the authors have written, as to their choice of what to illustrate. Specifically:

• Chapter 1 places the BlackBerry Enterprise Server (BES) in the broader context of Research In Motion’s (RIM) BlackBerry universe. In addition to itemizing relevant components, an introduction to the BlackBerry’s push model, security and Internet connectivity is provided. 
• Though brief, Chapter 2 runs deep in addressing BES architecture and implementation planning. For example, we learn that the BES employs a modular architecture comprising over a dozen components. After succinctly enumerating the components and their function, BES requirements and prerequisites are identified. In addition to hardware and software requirements, recommendations are made with respect to networking your BES (e.g., firewall and/or proxy considerations) and providing it with a database. Easy to gloss over on first read are thoughtful recommendations on sizing the BES (including pointers to resources from RIM) and the database for the anticipated user load. 
• Before BES components can be installed and enabled, the messaging environment and database server need to be configured. This is the subject of Chapter 3. Both local and remote database instances receive attention. Because each step is well illustrated, the book delivers on its intended purpose of serving as a solution guide.
• The installation of the BES is a multistep process enabled via a wizard. As in the previous chapter, in Chapter 4 the authors guide the reader through this process making appropriate use of illustrations. They interject appropriate commentary, and are clear on out-of-scope topics. The early emphasis on delineating BES architecture (Chapter 1) is realized as the authors transition the reader through the BES installation. 
• Of course, installing the BES is just the beginning, and therefore the next few chapters focus on the additional tasks required to operationally deliver this service to its users. After introducing the six permissible levels of administrative role on the BES, attention shifts in Chapter 5 to the matter of provisioning users, groups and devices. And with respect to devices, wireline and wireless options for provisioning are given consideration. 
• The BES ships with over 200 policies that can be applied variously to users, groups and devices. Also covered in Chapter 6 is the topic of provisioning software from RIM and third parties. Of particular value is the authors’ example of a software bundle targeted to a particular BlackBerry model. The ability to administer users, groups and devices with respect to policies (including software), from a single point of control (i.e., the BES server), speaks volumes to the appeal and value that this offering can deliver to corporate enterprise environments. This Chapter’s treatment of policies and software provisioning serves as an excellent introduction to topics BES administrators will return to repeatedly, and likely with increasing degrees of sophistication. 
• Unlike many of the other chapters, Chapter 7 provides only an overview of multitiered administration – i.e., properties and tasks relating to users, groups, (BlackBerry) domains and servers. This enumeration of possibilities, presented in context, works effectively. 
• A deeper discussion on security is the focus of the first part of the final chapter (Chapter 8). Encryption and authorization, both of which receive detailed consideration, amplify the value of the BES and its context in the overall BlackBerry universe for corporate enterprises. An unanticipated treatment of disaster recovery closes Chapter 8. In sufficient detail to enable a solution, the authors discuss in turn the measures needed to ensure that both the server (the BES) and its data (housed by the BES’s local or remote database) are readied for a disaster situation. 

 

Although Desai and Renfroe’s BES book unapologetically targets the Microsoft Exchange environment, its value is not limited here. Those working in other environments, and those interested in learning more about BES’s place in the BlackBerry universe, will almost certainly derive value from this book. Because the book is clear and concise, yet surprisingly complete and well-organized, it is likely to be well-thumbed by BES administrators of varying expertise.  

With the possible exception of a concluding chapter, page, paragraph or even sentence(!), to provide some sense of closure to the book, I am at a loss to report any omissions, oversights or errors. And although they might be better suited for a follow-on contribution of some kind, additional discussion might be given to topics such as performance and scalability (e.g., of local versus remote databases), the mapping of BlackBerry domains to organizational units, and/or improved degrees of DR.

Even though the book I reviewed was a complimentary copy provided by the publisher, I would happily pay for my own copy, and heartily recommend this book to others having interest in BES installation and administration. 

Parsing XML: Commercial Interest

Over the past few months, a topic I’ve become quite interested in is parsing XML. And more specifically, parsing XML in parallel.

Although I won’t take this opportunity to expound in any detail on what I’ve been up to, I did want to state that this topic is receiving interest from significant industry players. For example, here are two data points:

• Cisco is funding research into parsing XML in parallel on multicore architectures

Parsing of XML documents has been recognized as a performance bottleneck when processing XML. One cost-effective way to improve parsing performance is to use parallel algorithms and leverage the use of multi-core processors. Parallel parsing for XML Document Object Model (DOM) has been proposed, but the existing schemes do not scale up well with the number of processors. Further, there is little discussion of parallel parsing methods for other parsing models. The question is: how can we improve parallel parsing for DOM and other XML parsing models, when multi-core processors are available?

• Intel has recently released performance-enhancing software

Intel Corp. released a new software product suite that is designed to enhance the performance of XML in service-oriented architecture (SOA) environments, or other environments where XML handling needs optimization. Intel XML Software Suite 1.0, which was announced earlier this month, provides libraries to help accelerate XSLT, XPath, XML schemas and XML parsing. XML performance was found to be twice that of open source solutions when Intel tested its product …

As someone with a vested interest in XML, I regard data points such as these as very positive overall.

AGU Poster: Relationship-Centric Ontology Integration

Later today in San Francisco, at the 2007 Fall Meeting of the American Geophysical Union (AGU), one of my co-authors will be presenting our poster entitled “Relationship-Centric Ontology Integration” (abstract).

This poster will be in a session for which I was a co-convenor and described elsewhere.

A PDF-version of the poster is available elsewhere (agu07_the_poster_v2.pdf).

Book Reviews: Coming Soon!

Packt Publishing has kindly sent me the following books to review:

• Google Web Toolkit GWT Java AJAX Programming

• BlackBerry Enterprise Server for Microsoft® Exchange

Please stay tuned as I expect to share my feedback here on my blog over the next few weeks …

Will I be trading in my Blackberry for an iPhone?

I love my BlackBerry. It does exactly what I expect it to do. After years of disappointment with technology, this is as strong an endorsement as I can think of.

I have the same feeling every time I use my Apple MacBook Pro. I can see my daughters having the same experience every time they use their Apple iPods.

Coming from this perspective, the anticipation I have for the Apple iPhone is nothing short of spine-tingling. It’s all anticipation at this point because all I know about the iPhone is what I can read online.

Of course, that won’t stop me from compiling a list of considerations on whether or not I will trade in my BlackBerry for an iPhone:

• Physicality – RIM nailed the physical aspects of the Blackberry. Apple nailed the physical aspects of the MacBook and iPod, but what about the iPhone? For example, I’m concerned about trading in the highly tactile experience of my BlackBerry 7290′s real keypad for a touchscreen-based, soft keypad. I’ve had the soft-keypad experience via various Palm devices, and that’s precisely why I know I prefer the real keypad on the BlackBerry.
• Footprint – RIM nailed device footprint. So did Palm. So did Apple with the iPod. In my estimation no handheld representation of a PC, based on some pared-down version of Windows (WindowsCE, aka. “WINCE”), even comes close. Device footprint is the cumulative effect of the operating system, applications, data, etc. In the case of the BlackBerry, Palm, or iPod, there is minimal bloat. The iPhone has to deliver a low-bloat device footprint. Although I like Apple’s chances here, the challenge will be significant as the iPhone is based on Apple OS X. It’s not clear whose CPU will be inside.
• Propriety – According to one source:
  

  Apple has long preferred to develop products built on closed, proprietary technologies rather than open standards. Its proprietary iTunes music software, which will not work with devices other than Apple’s iPod, is one example of such a system.

  To some extent, of course, this is true. To a greater extent, however, it is a red herring.

As RIM has demonstrated with the BlackBerry, integration is the real issue. The BlackBerry is proprietary hardware. Because the operating system and applications are all J2ME-based, third parties can and do develop for the Blackberry platform, and RIM facilitates this. This is only the handheld portion of the picture, as integration with enterprise-scale messaging platforms (Microsoft Outlook, IBM Lotus Notes, etc.) is also key to the BlackBerry’s overall delivered value. Given that the iPhone is based on Apple Mac OS X, there are clearly prospects for integration.

• Software
  • Office software – Like the Blackberry, office-productivity software is absent on the iPhone. Although this doesn’t mean you won’t be able to find such software for your iPhone, it does underscore the fact that office apps are not a focal point. From one perspective, this is an omission. From another, it is highly consistent with closing the expectation/experience gap I raised at the outset.
  • Chat software – RIM provides its own chat software (BlackBerry Messenger); it works well between BlackBerry’s. However, it’s the third-party chat applications that amplify the integration of the BlackBerry with enterprise-messaging systems (via the RIM BlackBerry Enterprise Messenger, IBM Sametime, etc.) or with Internet messaging systems (Yahoo! Messenger, GoogleTalk, etc.). Frankly, I’m surprised that some variant of iChat wasn’t included with the iPhone. Even from the non-business perspective, iChat would be a phenomenal way of further capturing the mindshare of the iPod generation that is currently umbilically tethered to MSN Messenger. I predict Apple will address this oversight before product release.
• Legalities – The impending legal battle between Cisco and Apple is generating almost as much attention as the iPhone itself. As someone who lived through the RIM vs. NTP situation, while traveling extensively in the US, settlement of this legal matter will be a precondition of purchase.
• Connectivity – I’ve used BlackBerry’s on CDMA and GSM-based cellular networks. With today’s expectation of IP everywhere, one wonders when an IP-ready version of the BlackBerry will become available. (Today, I only care when I run a Web browser on my BlackBerry.) The iPhone will grok both cellular and IP-based wireless networks on release. Even more, the iPhone is ready for next-generation wireless networks based on the emerging IEEE 802.11n standard. From the connectivity perspective then, the iPhone presents a phenomenal convergence play. RIM has less than six months to ensure it retains mindshare on this increasingly important front.

So, will I be trading in my BlackBerry for an iPhone?

It’s too early to say, but I’m definitely keen to learn more.

Google Office for the Blackberry: Coming Soon?

In a recent post, I blogged:

Now picture this: A J2ME client application for Google Docs & Spreadsheets.

This is interesting on a number of levels:

• It’s feasible! Google Docs & Spreadsheets is likely written in
  some variant of Java (J2*E) already, so paring it down to J2ME is (in
  principle) possible.

Alas, Google Docs & Spreadsheets (GD&S) isn’t based on some variant of J2*E.

It’s based on JavaScript. To see this, open a document or spreadsheet in GD&S and then look at the document source (“View \ Page Source” in Firefox) and/or the DOM (“Tools DOM Inspector” in Firefox). Or, try to open a document or spreadsheet in GD&S on your Blackberry. You’ll soon find out about the dependence on JavaScript.

More precisely, GD&S is based on AJAX (Asynchronous JavaScript + XML). AJAX is behind the wonderful user experience afforded by most of Google’s offerings. (There’s an outstanding explanation of how AJAX achieves this experience available from Adaptive Path president and founder J. J. Garrett .) AJAX is a multi-tier platform or framework for developing and delivering Web-centric applications. (And many refer to it in the same breath as Web Services.)

In striking contrast, the GMail client for the Blackberry is a stand-alone Java application that executes within a J2ME container under the Blackberry operating environment.

Clearly AJAX and J2ME are completely different environments/platforms.

Thus it would seem that Google has the options summarized by a two-dimensional platform versus motivity grid.

On the vertical axis, platform ranges from self-contained to service-oriented.

Motivity is a bona fide word that is synonymous with locomotion (the power or ability to move). I intend here to coin a slightly different meaning, a juxtaposition of mobility and connectivity. More precisely, I propose to use motivity as a semi-quantitative measure of the degree of mobility relative to the degree of connectivity. As mobility increases, connectivity decreases, and motivity therefore increases. This is illustrated by the horizontal axis of the two-dimensional grid. It is also important to note that connectivity is itself a proxy for bandwidth and latency. More precisely, high connectivity is taken to imply high bandwidth, low latency connectivity.

Thus the options in taking GD&S to the Blackberry are:

• Port GD&S to the Blackberry operating environment (i.e., develop a native J2ME client version of GD&S) – the lower-right quadrant of the 2D-grid

or

• Port the client-side aspects of AJAX to the Blackberry operating environment (JavaScript and the AJAX engine) and interface this in real time with the server-side components – the upper-right quadrant of the 2D-grid

There is one other possibility that originates in the lower-left quadrant. GD&S could be written as a Java application. A pared down version could be relatively easily be made available for the J2ME-based Blackberry operating environment. (This was my naive suggestion that’s been revisited in this post.) In parallel, through use of the Google Web Toolkit (GWT), the same Java version of GD&S could be converted to AJAX as “… the GWT compiler converts your Java classes to browser-compliant JavaScript and HTML.”

Thus a revised two-dimensional grid of the possibilities is shown below.

Either way, it may be some time before Google Docs & Spreadsheets makes it to the Blackberry.