Open Source Unleashed

Book Review: JasperReports for Java Developers

Last October, Packt Publishing (a UK based publishing company specializing in focused IT books) extended the offer of reviewing titles from their open source selection. I accepted and decided on the following two titles:

• "JasperReports for Java Developers" by David R. Heffelfinger
• "Java EE 5 Development using GlassFish Application Server" by David R. Heffelfinger

After posting a review of the latter last month, I'm following up with that of the former.

As I stated in my first review, my intention was to both read and review the title from a developer's perspective. Especially considering the fact that the book is aimed at Java developers wishing to become proficient with JasperReports. The book's theme centered on steering the reader "...through each point of report setup, to creating, designing, formatting, and exporting reports." Its author, David Heffelfinger, earned a Masters degree in Software Engineering from Southern Methodist University and is currently editor in chief of Ensode.net, a web site about Java, Linux and other technology topics.

"JasperReports for Java Developers" proved to be a well put together title that provided sufficient support for a JasperReports newbie, like me, while also making good as a source of reference content that might be useful for non-beginners. Nonetheless, there were small gaps (mostly version differences and functionality that is currently available) attributable to the fact that the title was first published in 2006 and that JasperReports has continued as a steadily maturing open source framework since that time. This is to be fully expected and the book's coverage didn't directly suffer as a result.

The first chapter provided a good introduction as well as instructions for getting started with JasperReports including a useful breakdown of class library dependencies and the typical workflow associated with creating a report. In comparison to JasperReports documentation, which is high quality itself, there wasn't much missing/different. The second and third chapters covered the embedding reporting capabilities into Java applications and creating your first report. It was important for these to provide sound, comprehensive coverage of adding and using JasperReports' capabilities from a Java developers perspective if only because this is the library's primary use among its target audience. Both succeeded largely in providing a good foundation.   

The second chapter was essentially seguing to the next one which covered the tasks associated with creating your first report. As a result it was brief and to the point: instructions on downloading, environment setup plus a 'scan' of the JasperReports CLASSPATH in the form of a list of required libraries for report compilation. Chapter 3 provided newbie instructions on creating a report fit with insight on report template creation, preview, compilation, generation and display. There was also a section on using ANT to compile a report programmatically. Not to nitpick, but I felt the part detailing the elements of a JRXML report template should have been at the beginning of the chapter instead of the end, especially considering that understanding its importance is paramount to grasping JasperReports.

At this point in the book I began to instinctively look for follow-up exercises at the end of each chapter. However, none were provided. They always help to ensure that important topics weren't missed in  would have been a practical edition to a developer-centric book such as this one but were absent.

Chapters four and five (pages 55 -114) were two of the strongest throughout the entire book. In the first of those two, the concept of dynamic database reports were introduced and covered. This, obviously, is key topic since most reports aren't static and leverage the use of a database. In this light the chapter did a solid job of covering the same bases as its predecessor including ample text from various code examples interspersed with highlights, graphics and guidance. The sections herein provided a nice set of walk-through oriented content that was helpful in getting a grasp of the subject matter. The next chapter extended the topic of using databases by covering working with other datasources (empty, map, java objects, TableModels, XML and custom). Additionally, the guidance on implementing the JRDataSource interface was particularly informative and appropriate at the end of the chapter.

Neither of the next two chapters (six and seven) disappointed. Chapter 6 detailed the layout and design principles of JasperReports including how to create more complex reports by introducing background images/text and subreports. Each of the notable elements of report design and layout were mentioned as well as how to accomplish associated actions like adding multiple columns and grouping report data. This chapter went into great detail to attempt to portray the nature of JasperReports' extensive reporting capabilities while providing a handle on learning to effectively manipulate them. Chapter 7 was structured in the same manner only it focused on charts and graphics.

Through the end of the book other features, exporting to other formats, using iReport and integration with other Java frameworks were covered. Yet after finishing the 11th and final chapter the Index followed immediately which served as an abrupt end to the flow of the previous chapters and the learning experience, in my opinion. Personally, I expected more auxiliary information but maybe that's just my perspective.

Overall, I found "JasperReports for Java Developers" to be well written and informative in the same vein that "Java EE 5 Development using GlassFish Application Server" was. The book was able to maintain a walk-through oriented tone all throughout without sounding like a traditional developer's guide, all in 328 total pages (index included). Despite the fact that I felt there was a need for something along the lines of an appendix to supplement and better connect the high volume of examples with essential learning keys, the sections within each of the chapters were usefully phrased as if they were answers to a set of FAQ's. When coupled with a high degree of precision in content ordering this led to an instructive reading experience that is ideal for those looking to become familiarized with JasperReports. 

Technorati Tags: Java development |  open source software | JasperReports

OpenProj and the office productivity landscape for 2008 and beyond

About three weeks back I had the opportunity to re-connect with Projity's Marc O'Brien about the recent developments surrounding OpenProj. To paraphrase the announcement, the open source project management software had been downloaded 175,000 times in its first three months of availability. I'll steer clear of a technological view of OpenProj since I wrote up a product review last time around following speaking to Marc for the first time, soon after the first beta release. A talk in which he explained why he felt comfortable setting the bar for OpenProj as high as he did from jump street (Marc went on record saying he eventually expected 7-11 million users). While his logic was sound:

• Microsoft notes that 7% of all Office desktops run Project.
• There are over 100 million users of OpenOffice.org alone, according to Sun CEO Jonathan Schwartz. Giving a 7 million user count in the OpenOffice.org community alone.

The projection wasn't taken seriously by everyone despite numerous factors working in the projects favor. Namely, the $1,000 price tag for Microsoft Project and its separation from the Microsoft Office Suite. What I won't do here is attempt to delve into how many users OpenProj will eventually have based on the number of downloads thus far. However, my perspective is that the entire office productivity landscape has reached an inflection point that is ripe for an extended period of disruption. One where OpenProj, among many others, will undoubtedly play a key role.

Below are some of the directions that I expect to play into office productivity software trends for 2008 and beyond:

Enterprises expect innovation leadership from Microsoft. With a vice grip on the desktop productivity market leveraged by control of the dominant operating system, Windows, Microsoft has reached a point where customers and partners have come to expect nothing less than for the company to be an innovation leader. This means that simply churning out new versions of and fixes to entrenched productivity applications is no longer sufficient, the company must remain focused on meeting changing user needs and the expectation to deliver office productivity software innovation.

Open Document Format/OpenXML debate won't drive decision making. While the Open Document Format and Open XML debate has received its fair share of media and press coverage, standards support alone isn't going to spur changes in office productivity decisions alone. Even if enterprises are watching these developments in light of their document longevity concerns.

Google leads a pack of burgeoning long-term threats to Microsoft's Office dominance. There is a growing segment of interest in the adoption curve for Google Docs as a reference point for the readiness of Microsoft Office alternatives. Admittedly, I'll cast my lot there, too, but more importantly it's going to be interesting to see how Projity's role develops here. Obviously, adding OpenProj to a mix that involves OpenOffice.org strengthens the prospect of there being a feature complete set of open source components that further rivals Microsoft Office. However, Projity ’s business model is structured around upselling from OpenProj to its for-pay, Web-based, Project-ON-Demand SaaS product. So assuming Google Docs continues to gain momentum on the consumer front and OpenProj leads to a pick up of Project-ON-Demand purchases, it is very realistic that as early as mid-2009, Microsoft finds itself in an unenviable predicament. One where the company faces mounting pressure on the desktop front from open source players, i.e. OpenOffice.org and OpenProj, as well as from a class of increasingly relevant online office-type offerings from the Googles, Projitys and Zohos of the world.

IBM looks to broaden its reach with Lotus/Domino 8. I thought IBM's move to release Lotus Symphony for free was both timely and a saavy competitive play. Especially since I thought that "legacy" Lotus Notes versions suffered from a lack of relevance within the consumer realm. Until Symphony IBM never gave itself a fair shot at establishing traction with users at home and students before entering he workforce. Ironically, in my mind, the company's narrow focus on the enterprise actually hurt adoption levels since it artificially limited the avenues to stimulating user familiarity with the product suite. Offering free, enterprise grade software is a good start towards convincing more IT organizations to encourage employee experimentation and adoption of unfamiliar tools.

OpenOffice.org benefits from the emergence of Linux on the desktop. This one is pretty self-explanatory, with more consumers than every catching on to Linux there is more opportunity for the best freely available office suite to capture more traction. Yet I still don't see large levels of mainstream growth in its future over the next 12 to 18 months.

Innovation and user productivity emerge as competitive differentiators. The winners in this segment will have to innovate, cost alone won't cut it. The innovative offerings will be those that introduce new wrinkles to improving productivity levels at home, in the office and on the road.

Technorati Tags: OpenProj |  open source software | office productivity |  Google | Microsoft Office | IBM

No entries until after the New Year alert

I will be on vacation and won't be posting any new entries until after the New Year (1/1/2008).

The risks of open source focus

My last post addressed the nature of open source evolution and the [increasing] risks of generic strategies within the context of industry maturation. However, I did not delve into an analysis of the risk of focus simply because I felt that the topic might warrant another blog post to itself. Along those lines now, when there is an unprecedented level of activity in the commercial open source sector, more than ever, it's appropriate to work towards an understanding of:

1. What the risks of open source focus are
2. How they are affecting industry maturation
3. Where they fit into the competitive dynamics of commercial open source

That being said, focus of any variety carries its own set of cost-benefit realities. In the case of open source focus at this stage, of what is turning out to be a disruptive period, in the history of the software industry, there is undoubtedly a slice of profitability for vendors that accept both the risks and rewards of the model. However, as the open source marketplace evolves so do the forces enacted upon its participants. As such, the risks of open source focus haven't necessarily transformed, only the associated implications have shifted.

This shift, from my perspective, will serve to create a new class of truly hybrid vendors that develop software in thoroughly open and transparent communities but also offer other products and/or components that are proprietary. Some might scoff at this assertion since what was described sounds exactly what a number of commercial open source vendors have been/still are doing for a while. However, these hybrid vendors of the future won't only look to monetize across different versions of the same product (i.e. community & enterprise) but over a portfolio of offerings that consists of those offerings that are fully open source and those that are closed source...without losing sight of their commitment to the open source software model. This evolution will be driven by the following risks of open source focus:

• Widening cost differential eliminates the advantage of focusing solely on open source.
• Narrowing differences between desired products and services within the marketplace.
• The economics of a one-sided software portfolio. 

Not that the above risks will bring about the end of commercial open source by 'forcing' vendors to sell proprietary software, only industry maturation will present a number of business opportunities associated with doing so...in much the same way that proprietary vendors are utilizing open source without fully opening up. It will be interesting to see how this affects the definition of what it means to be an open source/proprietary company as well as customer expectation for both.

Technorati Tags: risks |  open source software | generic strategies |  competitve dynamics | industry evolution

Open source evolution and moving past generic strategies

Over the past two weeks or so I've participated in briefings with, but not exclusive to, the following companies: Concursive (formerly Centric CRM), Funambol and Nuxeo. In parallel, I've been preparing my predictions for the open source software marketplace in 2008 which has entailed analyzing industry-wide trends and maturity indicators. Doing so, has led me to the conclusion that there is a decided movement in the shift in the leadership landscape amongst commercial open source business models preparing to move into 2008.

This shift is being driven by maturing business models as well as the dynamics of industry evolution. The outcome is that the generic strategies (along with the associated risks) previously conducive to growth, begin to erode as a defense against competitive forces. As a result, companies move to mitigate these risks through a number of methods. Below is a breakdown of two of the three widely recognized risks of generic strategies (excluded is the risk of focus) as it relates to the open source marketplace:

RISKS OF OVERALL COST LEADERSHIP
Even as open source software continues to be associated with lower costs, the burden of maintaining cost leadership is deceptively difficult...especially as a firm seeks growth and expansion. The risks as they related to open source are:

• The rapid pace of technological change that drives commoditization. What plays the role of disruptor for established vendors can serve also as an inhibitor to market opportunities for newcomers, i.e. price points must start lower and large segments of customers become highly price-sensitive. We're seeing this take place with MySQL as they attempt to continue to grow in the face of the challenges presented by competing in what amounts to a commoditized product category.
• Rising quality of freely available software. As the functional gap between free and commercial open source closes, it becomes increasingly difficult to provide the added value necessary to entice free users into becoming paying customers. Oftentimes this happens naturally as a result of tending a thriving open source community that centers on free versions.
• Becoming too reliant on cost-value proposition. Low costs tend to sell themselves but the nature of open source TCO is multi-varied and the entire value equation shouldn't be brushed aside. Too much attention on lower costs at the expense of being able to identify required product and marketing changes is not a positive.
• A decrease in price differential. Inflation in costs associated with a growing operation can often eat into price differential margins. For open source vendors this does not bode positively for competing against the brand value and/or other evolving approaches to differentiation from far larger vendors. While this is easily offset by maintaining investments in their open source communities, there is no hard guarantee that the cost savings passed to customers will remain proportional to operating expenses.

RISKS OF DIFFERENTIATION

• Cost differential overshadows brand characteristics. Ideally, being open source should never overshadow the value of the software nor the development model. However, oftentimes being openly (see: freely) available turns awareness away from open source brand characteristics and provides a cover for potential customers for whom price is less of an issue to look elsewhere. In this regard, projects like httpd from the Apache Software Foundation (ASF) have walked the thin line between remaining relevant as a leader that just so happens to also be free.
• Buyers no longer need high levels of differentiation. JBoss(Red Hat) has reached a similar point, where it no longer is competing to differentiate itself from other open source application servers.  Buyers and potential customers typically know what to expect from JBoss and aren't necessarily interested in how it does A, B or C better than GlassFish.
  
• Open source narrows perceived differentiation. A perfect example of this is JasperSoft and Pentaho. Mostly these two are grouped side-by-side as open source Business Intelligence (BI) competitors when in actuality there are stark differences between the two platforms starting with business models, pricing and licensing. However, because they're both open source they have to work just that much harder to achieve a comfortable level of differentiation.

Technorati Tags: risks |  open source software | generic strategies |  competitve dynamics | industry evolution

Jumping on the Open Source Census Bandwagon

This post marks me jumping on the Open Source Census (OSC) bandwagon in support of an ambitious but desperately needed effort. Deemed "a global, collaborative project to collect and share quantitative data on the use of open source software in enterprise," at its web address, OpenLogic is sponsoring what amounts to the first, of what should be many more, wide-reaching efforts to quantify the traction of open source software behind enterprise walls. I'll start by commending Kim, Stormy and Co. for stepping forward and taking the initiative on this matter. If executed well, the OSC has the potential to inject data into the conversation about open source penetration. Currently, there are far too few reliable reference points capable of serving as numerical baselines for quantitative analysis, trend forecasting, and the like.

Actually I think the responsibility of collecting the type of data outlined by the OSC should fall on the shoulders of the entire open source community. I applaud OpenLogic's approach to stimulating participation with incentives but it strikes me that they aren't the only ones who will benefit from the data once compiled. Over the long haul, collecting data of this nature will require that open source communities take the initiative to lower the barriers to collecting this information. I've attempted to highlight the value of extracting relevant information about the free user in the past outside the context of the OSC. Ideally, the OSC would entail mostly the collection of usage data from the communities instead of directly from the enterprise. Because in my honest opinion, commercial open source vendors should be collecting this data religiously on their own. If they're not, it leads me to wonder how well the grasp the reality that data about users of open source software is a critical piece of the sales lead picture.

As a result, as the OSC comes into its own I think it will prove beneficial to work with communities to organically integrate better mechanisms and strategies for similar collecting data subsets into communal frameworks. And not simply for the purpose of sharing the load because we're in this together, but also strengthen the overall efficiency of translating downloads into dollars...something that's at the core of successful commercial open source.

Technorati Tags: OpenLogic |  open source software | Open Source Census

On the issue radar for 12/11/2007

The OpenDS situation
Whether this series of events digresses into a full-fledged open source nightmare for Sun remains to be seen. However, it is clear that a lack of communication and commonly agreed upon execution exposed what was initially an internal fudge as a publicly-visible stain on the company's open source friendly title. Before grasping how this reflects on Sun as an open source company, it is critical to separate the term of democratic from that of open source. Unfortunately for a great many 'purists' this proves exceedingly difficult, especially when it comes to a large organization like Sun. However, as long as the expectation that open source implies democracy continues to persist, there is bound to be uproar whenever the dynamics of top-down corporations collide with open source communities.

The bottom line is that, of all the characteristics that an open source effort should exhibit, democratic is not one. If that sounds backwards, consider the benevolent dictator model. Last time I checked, all dictators (benevolent or otherwise) wield a brand of unilateral authority such that democracy (in the true sense of the word) need not apply at all. Yet this can prove OK so long as a strong sense of meritocracy, open discussion/debate and low barriers to participation remain present. What  In the OpenDS scenario, it's also worth noting that Sun has far more to lose than gain by recklessly alienating any of the company's open source community in which it is substantially invested. Did the company handle issues regarding OpenDS efficiently? No. Were the lines between participation as an employee and as a private citizen clearly outlined in advanced? And should they have been? No, and of course, respectively. Yet with that in mind, Sun's purported behavior speaks to inadequate planning and botched execution as opposed to a thoroughly ingrained strong arm tactics.

Another Apache Juggernaut?
For anyone keeping track of the emergence of open source in the enterprise development arena, it's old news that Tomcat has emerged as an epicenter of the trend towards lightweight Java architectures on the server-side. This isn't directly relevant from a dollars and cents perspective since its producer, Apache, is non-profit. However, Tomcat continues to serve as the key component in the penetration into enterprise data centers by an increasing array of open source software players like the SpringSource, Terracotta and Hyperic. Unfortunately, there aren't those handy NetCraft stats to quote in support of the fact that Tomcat has grown into a juggernaut in its own right.

ESTD and open source software
I've commented on Savio's thoughts on integrating free users into the paying customers base. However, my perspective is that his viewpoint is critical to coming to grips with the realities of commercial open source. While I can't speak for him, I take his points on this subject as coming from an objective angle and not an oppositional/critical one. In reality, it is and will continue to prove an extremely tough game for commercial open source companies to grow their revenue figures along the same lines as proprietary counterparts. That's not to say it can't or won't be done, but making it happen will entail far more than continuing with business as usual. In effect, it's going to take a huge dose of innovation at a strategic, business and technological level. Something I expect fully to occur, but a tough task nonetheless.

Forging ahead with open source software support and services
It is worth watching uptake of the SourceForge.net support and services marketplace in light of the steadily expanding pool of qualified providers. Corralling this diverse basin into a single integrated site will prove challenging, indeed. Most importantly, SourceForge.net must find ways to stimulate an actual marketplace such that the service does not devolve into a static directory of old ratings and broken links. In a way, the marketplace must address similar challenges that any of the projects hosted on SourceForge.net does: courting a community of users, encouraging participation and remaining relevant as the open source model continues to undergo successive waves of evolution.

Technorati Tags: OpenDS |  open source software | SourceForge.net |  Sun Microsystems | Apache Tomcat

Google's Android and the governing dynamics of open source success, Part II

In yesterday's post, the first of this two part series, I began by making mention of the Verizon announcement stating that the company is set to support Android-based phones. And I, like many others, am interested to see if a Google Android will mature into a bona-fide open platform for mobile device development. However, I'm also aware that innovation is never a given, even if openness is embraced entirely. Similarly, there are governing dynamics for achieving open source success that will set the tone for Android's trajectory and progression. In this post I will continue with the last five (5) of these nine dynamics.

Representative Decision Making
The term "democratic" is regularly used to refer to brand of decision-making employed within open source communities. This line of thought tends to categorize communities like the Linux kernel (where Linus Torvalds retains the final right of veto) as less democratic. However, that particular expression [literally "rule by the people"] isn't quite reflective of how decisions are made and authority is actually exercised within a healthy open source community. It is closer to governance by consensus where imposed authority and top-down decisions are tempered by thoroughly integrated forms of consensus building that  prizes discourse in the open over autocratic commands.

Self-Reinforcing Participation
Even as the debate over the viability of cash-motivated contributions takes place, the opportunities and value of participation stands pat. Obviously offering cash is the quickest path to generating a buzz across a larger segment of individuals and potentially enticing some to participate. Be that as it may, sustained community development occurs as a result of highly-qualified parties choosing to continually participate over the long haul. Once an individual proves him/herself qualified (through consistent contributions to the community) he/she is rewarded with recognition, the option of assuming a more prominent role (unofficial or official) and/or more opportunities to learn and develop new skills. This creates a self-reinforcing cycle where growth is realized through participation and more growth opens the door to more opportunities to participate.

Continuous Improvement and Low-Cost Maturation
Open source projects have long lived by mantra of "release early and often" as a governing principle for release cycles. Typically, the opportunity to accelerate the rate of improvement for software is a key driver for adopting this approach in earnest. On the other hand, openness ensures that the changes, releases and branches are all transparent to the extent that tracking, managing and referencing them can be done without hassle. As an open source project matures, the lowered cost of building and testing variations (gained through these tasks being distributed across the community) improves the prospect of assuring security and quality control. This is key to enabling a project to embark upon the path of evolving into a solution that meets user needs and requirements.

Selective Barriers to Participation
While the general concept is that open = no barriers to participation, some barriers are necessary to maintain a sense of governance and structure. For instance, a newcomer should be granted full access to relevant information and source code, yet no such blind permissions should be granted for modifying official, or even unofficial, distributions. This might seem intuitive to most, yet on some levels the decision to carefully cultivate or entirely eliminate barriers can prove complex. For example, some community support forums require that users register using a valid email address before posting in the discussion area(s) while others allow anonymous pseudonyms. Whatever the case, any such barriers should do nothing to decrease the willingness to join an open source community.

Communal Ownership and Access
It can't be argued that at the foundation of an open source project is its license that dictates the terms of attribution/usage for the software asset in question. One of the main purposes of licensing is to protect a valuable common resource against misappropriation, both internal and external to the community. Additionally, it is important that licensing appeal to a sense of fairness while also remaining aligned with the core realities of community-driven development. The optimal community-centric outlook prizes participants as co-owners and promotes forms of sharing the rewards and responsibilities of ownership equitably across the board.

This is the second part of a two part series, view the first part here.

Technorati Tags: Android |  open source software | governing dynamics of open source communities | Verizon

Google's Android and the governing dynamics of open source success, Part I

News that Verizon took one more step closer to an "open" network by embracing Android, Google's new software platform for mobile devices and handsets, caught my attention for a number of reasons. First of all, I noted the magnitude of a commitment from Verizon to a platform sponsored by one of its main rivals in the upcoming 700 MHz auction. Especially considering that the company's previous two announcements were being written off, in many circles, as thinly veiled competitive strikes at Google's position in the same auction.

Nonetheless, I thought it was interesting that Verizon even paid lip service to Android, which is still an unproven entity from a number of perspectives. By this I mean, despite the coverage, buzz and sponsorship by Google, Android's outlook will be determined (in my opinion) by how the nine (9) dynamics of open source success, listed below, factor into its growth curve. To most, these might be taken for granted as compulsory, yet their existence remains very much relevant within the context of each and every open source effort.

Standards, Objectives and Solution Evolution
As Roy Schestowitz astutely points out, standards and openness should go hand-in-hand. I might go on to add that while interoperability isn't a replacement for standards it is the next best thing when a standard is not available/widely adhered to. After all, there's something to be said for a CRM system that may not be "standards compliant" but still sports interoperability with various Salesforce.com modules. However, standards do help to reduce divergence across the parties involved, by highlighting what needs to be done. This counts heavily, as even the act of "solving a problem" can become vague as time wears on, whereas implementing a standard instills in-context awareness of exactly what is being done and why. Coherence in execution is the reason that while successful open source projects are often started for any number of reasons, as time passes there is one overriding characteristic: they all take the form of an evolving solution that aligns with a well defined set of objectives.

Modularity Driven Problem Decomposition
Open source has proven to effectively handle complexity by introducing a corresponding level of modularity to the equation. This facet of efficient open source development is particularly useful in that it promotes agility and flexibility of design and implementation. Complex software development can be done in parallel across a geographically distributed community flexibly and independently. The value of modularity can be introduced as reusable libraries, extensions or plug-ins.

Visibility into the Collaborative Process
Regardless of whether a community is governed by a commercial or non-commercial entity, visibility into the collaborative formula for a project is golden. Since software development is primarily a collaborative task so visibility with regards to the source code, application distribution, documentation, issue tracking and community support mechanisms serves as a window into the core of a project. Newcomers are able to ramp-up quickly, the community is granted agility in the even that participants leave and there is a running historical account of the aforementioned components of the software development process.

Contribution-driven Hierarchies
Even within open communities hierarchies are a fact of life. The principal difference between closed gardens and their open-centric cousins is that hierarchal "rank" is typically based on demonstrated contribution to the community. This tends to create more meritocracy-centric structures where:

• Individuals can build a reputation.
• Trust and status are governed in a communal manner.
• New members are better integrated into the overarching community.

I will conclude this list with the final five governing dynamics of open source in my next post tomorrow. Update: View the second part here.

Technorati Tags: Android |  open source software | governing dynamics of open source communities | Verizon

Book review: "Java EE 5 Development using GlassFish Application Server"

Back in October, Packt Publishing (a UK based publishing company specializing in focused IT books) extended the offer of reviewing titles from their open source selection. I accepted and decided on the following two titles:

• "JasperReports for Java Developers" by David R. Heffelfinger
• "Java EE 5 Development using GlassFish Application Server" by David R. Heffelfinger

Today I'm sharing my review of the latter, with additional information, about this and other titles, available on Packt's website.

To be clear, I made every attempt to read the book, having had a background in enterprise software development, from a developer's perspective. Especially considering the fact that the book is aimed at Java developers wishing to become proficient with Java EE 5, who are have some experience with Java. The theme centered on using GlassFish version 2 to develop and deploy applications. Its author, David Heffelfinger, earned a Masters degree in Software Engineering from Southern Methodist University and is currently editor in chief of Ensode.net, a web site about Java, Linux and other technology topics.

Overall I thought "Java EE 5 Development using GlassFish Application Server" was a well constructed publication that can serve as a solid introductory foundation as well as a decent reference for GlassFish powered development. I did think that it could have done a better job of integrating an overarching vision of how GlassFish fits into the concept of a Java EE 5 solution at a higher level. Especially seeing how the book cover contained the text, "From Technologies to Solutions." Nevertheless it contains enough information and examples to provide the type of comprehensive breakdown of the GlassFish architecture that an uninitiated developer needs.

The first chapter spans an overview of, getting, installing and verifying a current version of GlassFish. I thought this could have included a clear delineation of the GlassFish architecture in picture format, to better provide a clear account of its composition. Still, I was able to follow the installation prompts and install GlassFish successfully, quite a testimony considering my experience with other tech books that endeavored to provide installation instructions. The second (Servlet Development and Deployment) and third (JavaServer Pages) chapters were useful even if they probably could have been combined into a unified chapter, if only because GlassFish boasts a number of impressive features that arguably deserve mention/added coverage throughout a book of this nature.

The next two chapters covered Database connectivity and the JSP Standard Tag Library (JSTL). The latter of which I found particularly useful considering how lacking up-to-date, developer-oriented usage-based JSTL documentation is. Interesting enough, Chapter 4 contained a section called Final Notes which contained mention of accepted design patterns related to Data Access Objects (DAOs). I thought that segment should have been longer and duplicated across every chapter in the book. My reasoning is that since application server architectures are implementations of a Java EE specification there is heavy overlap between design patterns and other accepted best practices. It would have been useful to have a couple of paragraphs shed light on that reality.

Chapter 6 (JavaServer Faces) and chapter 7 (Java Messaging Service) were, in my opinion, two of the better written chapters throughout the entire book. The section in chapter 6 about integrating JSF and JPA was a timely cross reference that provided applicable practical insight into pulling the view and model components of an MVC web application together. Chapter 8 (Security) was well-placed but could have used more information about the security behavior of a Java EE container towards providing a clearer picture for developers of what happens in a simple web application. Reading through this chapter was also the point where I realized that it would have been tremendously useful to see a compilation of to the JSR's that are implemented by GlassFish as a reference.

The last three chapters: 9 (Enterprise Java Beans), 10 (Web Services), and 11 (Beyond Java EE) did not disappoint even if Chapter 11 probably could have used additional information about topics, i.e. GlassFish JBI,  beyond the scope of core Java EE. Also, it might not have hurt to make mention of SOA accordant, GlassFish-friendly components like OpenESB in either the last chapter or an Appendix.

If you're considering using GlassFish as the basis of your Java EE 5 development this title is absolutely perfect for scaling that initial learning curve and getting up to speed on GlassFish version 2. For administrators or developers who don't want to reduce the time it takes to get comfortable and productive in the book will be a really big help. It's straight forward and allows readers to really jumpstart their efforts right away.

Next week I plan to post my review of JasperReports for Java Developers.

Technorati Tags: Java EE 5 |  open source software | GlassFish