Thursday Dec 07, 2006
Wednesday Jan 25, 2006
By craigmcc on Jan 25, 2006
Well, it's finally out. The final release of Sun Java Studio Creator 2 has hit the web site, and it's free (just sign up for the Sun Developer Network, which is also free, and you'll be able to download a copy). Thare are lots of cool features that you can read about at the site, and in other blogs about Creator today. I'd like to spend a couple of minutes talking a bit about what it is like to be the architect for a product like this.
As you might now already, Creator is based on the NetBeans Platform. In the particular case of Creator 2, we're based on NetBeans version 4.1. But ... that's not quite completely true. Creator development started, a couple of years ago, as a skunkworks project to build a tool focused on visual development of web applications. My colleague Bob Brewin, who was architect at the time (he's now architect for all of Sun's tools) describes some of the vision at the time, and the background of the original code name ("Project Rave") that we used.
What Bob doesn't tell you, though, is what we had to do to get there :-). For expediency we started from the NetBeans code at the time (version 3.6) but hacked many modules of it fairly radically. That is not a sustainable engineering practice over the long term, so we've spent the time ever since coming closer and closer to binary compatibility with the NetBeans platform. In the Creator 2 release, we've made substantial progress towards closing the gap. This, of course, requires interesting "negotations" with the NetBeans platform team -- all going on while NetBeans has their own product delivery schedules, and associated requirements, which don't always line up.
One thing I will say for the NetBeans folks, though ... they know how to build a great platform. And they've been really great to work with, throughout the process. Indeed, you'll see the results of us working together even more in the future. I got to visit the Prague office (where most of the NetBeans developers live and work) last fall -- along with some other travels that leads to my "get a life" comment in the title of this entry. Prague is an incredibly beautiful city, and the team is well organized and passionate about what they do.
Part of what an architect does at Sun is to go out and talk to lots of people, both showing off what we already have but also listening for feedback on where we should go in the future. For me, this kind of thing is often centered around speaking at developer events -- coupled with customer visits and press briefings scattered around as well. This last fall, though, I crammed more travel into less time than I ever thought was possible. Over the course of ten weeks, I went to conferences in Tokyo, Buenos Aires, and Beijing ... followed immediately by the trip to Prague. (Hint -- if you ride a crowded subway in Prague, be SURE to hold tightly to your wallet). And, just for good measure, I travelled down to the Bay Area for a couple of quick trips as well (I normally telecommute from my home in Portland). Sheesh ... I've got enough miles stocked up I'll probably never buy an airline ticket again. But, to my wife's chagrin, I am not all that enthusiastic about flying anywhere fun with them :-).
We had released two Early Access versions of Creator 2 over the last six months, and the amount of feedback we received was both enormous and very useful in improving the quality and performance of the tool. I'd like to extend my personal thanks to everyone who downloaded and try out Creator 2 EA, and especially those who took the time to give us input. As well, thanks to everyone who listened to me present about Creator, or my open source passion of the moment (Shale).
I'd also like to thank the entire team at Sun that brought Creator to life. That's not just the developers. It's the QE folks that made sure we were meeting the quality criteria, the technical writers that produce the wonderful tutorials and articles, the release engineering and website teams that actually produce the bits that were shipped. The list goes on.
In the mean time, I'm going to take a deep breath, and look for someplace we can drive to for vacation this year :-). But, of course, my travel calendar for this year is starting to fill up already (February in Korea, March in Las Vegas, May in San Francisco, and who knows how many additional things that will get added). Isn't being an architect fun?
Friday Aug 12, 2005
By craigmcc on Aug 12, 2005
Hey ... remember me? The guy who promised to start blogging, did a couple of times, and then disappeared last fall? I'm ... um ... back :-)
Although I've had the opportunity to speak at more than a few conferences in the last ten months, I've been spending most of my time on two primary activities:
- My day job -- architect for Sun Java Studio Creator, where we recently introducted Creator 2 Early Access. There is lots of interesting stuff going on here, but I couldn't talk about it until we went public.
- My open source efforts -- where the beginnings of a new web application framework called Shale are starting to take shape. Shale is innovative in the web framework space because it presumes the existence of JavaServer Faces, and adds capability on top instead of redundantly implementing the same features.
Now that life is (relative to my normal madhouse) at point that isn't quite so frantic, it's time to get back into the blogging habit, and talk about these topics, plus other interesting things going on in the world of Java, and especially in the web tier. Things might get a little interesting in September, when I'm slated to go to both China and Argentina; but both of those occasions will have me talking with developers. That's always a useful endeavor.
To start things off, I'll shortly post a blog on a hidden gem in the Creator 2 EA release that hasn't gotten as much attention as some of the other features.
Saturday Oct 02, 2004
By craigmcc on Oct 02, 2004
In a TheServerSide thread responding to the fact that I've started blogging, an interesting question came up from a reader with the alias
While the first part of this statement can lead to its own set of interesting design discussions (on "one big component" versus "assemble complex things out of simple things"), let's focus here on the second part. I believe that, in the case of JSF components, there will be more than one answer to this question over time. Let's look at some of the possibilities, using the term widget as a generic reference to some sort of reusable user interface component that is written against some sort of API supporting component development.
- First, consider a complicated widget from your favorite UI technology (say, Struts Layout;
Table, or whatever). Did a page author create the implementation of these widgets? Probably not; it was likely a Java developer either working on the framework itself, or intimately familiar with the APIs of that framework, who created something reusable. The Java developer undoubtedly used their own favorite editor or IDE (insert gratuitous "Emacs rules, Vi drools" discussion here :-).
- A second traditional source of widgets has been the providers of IDE tools themselves. In order to enhance the design time experience of the page author, the tool will often provide prebuilt widgets with extra design time support (for example, GUI dialogs to configure the columns in a table, or data binding dialogs to attach to model tier business objects). Traditionally, the components provided by a tool would typically conform only to the component API supported by that tool. One of the ways that JSF encourages more components is making it possible for these same components to be used in other tools as well. See, for example, what Oracle is doing to migrate their traditional (Oracle proprietary) components to JSF with ADF Faces.
- Naturally, the open source community has been a historical source of widget libraries for various component APIs. Previously, such libraries have tended to be closely associated with the underlying component API project (or its development community); the advent of a standard component API makes it much more reasonable to build such libraries that plug in to multiple frameworks or tools.
- Page authors, in my experience, are generally less concerned about creating "fine grained" reusable chunks of markup (although they do like the idea of being able to reuse such chunks created by others). JSP, for example, has evolved ways to reuse fragments (such as static and dynamic includes in JSP 1.0, or tag files in JSP 2.0). My belief is that these technologies will continue to be leveraged for larger chunks of stuff (such as a banner that is common across multiple pages), rather than on individual widgets, and we'll see tools focus on supporting this sort of use case (for example, see Page Fragments in Sun Java Studio Creator). On the other hand, it's certainly feasible to contemplate a specialized tool for building JSF components that starts with a chunk of markup, and creates the component classes for you -- it's just fairly straightforward Java code, after all.
- Finally, there are generally "standard" components provided by whatever component API you are using.
In the case of JSF, this is the set of simple HTML components that are provided out of the box, so
you can at least become familiar with the technology quickly. This is where commonly required
concepts show up to be standardized (analogous to the way that JSTL standardized tags like
<c:if>that every tag library needed, but everyone was doing differently). This is not where you are going to see high speed innovation in fancy new widgets. And that is a Good Thing (tm). The focus is, and continues to be, on a high quality API underlying the components that are, and are becoming, available from the sources listed above.
So, where do reusable components come from? The same places that they always have. The extras that JSF provides (a common basic API for building such widgets, useful infrastructure like managed beans and value bindings, and an architecture designed to be easy to support in tools) encourages the development of component libraries that are not aligned with only one technology or tool -- the focus is as much on reusable as it is on components.
Monday Sep 27, 2004
By craigmcc on Sep 27, 2004
It should come as no surprise that the most frequent questions I get asked center around the issue of which of these two web tier technologies an organization or individual developer should consider using. It makes sense to ask me, because I was the original creator of the Struts Framework, and was the co-specification lead for JavaServer Faces 1.0 (JSF).
Usually, the question is framed as an or issue, based on an understanding that the two technologies are mutually exclusive. That turns out not to be the case, but it can still be difficult to determine what to do. This blog entry provides my current advice on the subject -- but, to understand it better, it's worth briefly reviewing the development and focus of the two technologies.
The story is a little long compared to typical blog entries; if you want to cut to the chase and see my advice, scroll down to the section entitled The Bottom Line, below.
Struts grew out of a personal need (open source developers often call this scratching your own itch) to support the development of an application that I was responsible for, prior to joining Sun in 2000. My task was to take a US-centric application to Europe, initially in four languages, and make it available (among other delivery channels) on the web. At the time, there was lots of discussion about appropriate architectures for on the JSP-INTEREST mailing list at
java.sun.com, but there were few available implementations. Therefore, I set out to create an application framework for my own use, particularly focused on some key functional areas:
- An architecture based on the Model-View-Controller design patterns commonly seen in rich client applications, focusing on separation of concerns between presentation logic and business logic.
- A request processing lifecycle that is applied to all incomding HTTP requests, allowing the centralized management of common functionality like input form validation, and invoking business logic via a logical alias, rather than embedding knowledge of the business tier into a view tier component.
- Robust support for localizing the user interface of a web application.
- Since I was planning to use JSP for the view tier, a set of JSP custom tags that simplified the creation of user interfaces based on HTML forms.
The resulting framework served my needs quite well. As it became obvious that my needs were not unique, I began the process of open sourcing this idea of a web application framework at the Apache Software Foundation. What happened next was nothing short of extraordinary -- Struts quickly became the de facto standard web application architecture in the J2EE space (the number of significant Internet applications built with it is substantial, but is dwarfed by the number of intranet applications that use it), integrated into nearly all the major app servers and tools, supported by a rich ecosystem of knowledgeable proffesionals and skilled developers, backed by significant documentation in the form of books and articles, and the basis for a large user community centered around the Struts User mailing list (to subscribe, send an empty message to
As Struts became a common starting point for developers new to the Java platform, an interesting phenomenom was occurring -- for many developers, the key perceived value of using Struts was assumed to be the JSP custom tags for HTML forms. While these tags are quite useful, they do not constitute a robust user interface component model, which has led to the need to create or integrate of third party tag libraries for more complex presentation requirements. To me, the core value has always been in the controller tier (the request processing lifecycle, and the features which this lifecycle has enabled, such as the additions of the Tiles framework for reusable look and feel, and the Validator Framework for client side and server side enforcement of form validation business rules). This perception, then, has led to some of the current confusion.
After Struts was released, and was beginning to demonstrate its popularity, an increasing number of other frameworks and component implementations were becoming available. Indeed, at one point during the development of JSF, I had pointers to over 50 such technologies on a spreasheet being used to survey the market. While a large amount of innovation occurred, it was difficult to forsee the development of a common standard API for user interface components -- one that would enable the creation of a component marketplace where tools vendors could support one component API instead of 50, and where component developers could count on interoperation with many tools instead of one or two.
JSR-127 was introduced with the goal of solving this problem -- providing a common base level API for building user interface components for web applications, with the specific goals of being both accessible to developers writing applications by hand, but also easy to integrate into tools. In order to complete this JSR in any reasonable amount of time (and, if you wish to argue that we didn't achieve this goal, I won't disagree :-), we stayed strictly focused on the view tier. Controller tier functionality was considered out of scope, although to be of any practical use we had to provide hooks for basic things like instantiating objects on demand, as well as support for page navigation.
The focus on the view tier was clear from the feature list for JSF 1.0:
- Standard component API for user interface components, ranging from simple input fields to more complex tree controls and menus, to sophisticated scrollable tables which allowed both input and output. Components also support standard JavaBeans style events and event listeners.
- Decoupled rendering model, so that the same component could be rendered in different ways (for example, a command component used to submit a form might be rendered as either a button or a hyperlink).
- Request processing lifecycle focused on the handling of user interface events (such as the node of a tree control being expanded or contracted), coupled with support for data type conversions and component level validation rules.
- Utility technologies supporting the component APIs, including value binding and method binding expressions, managed beans (create on demand), and page navigation support.
JSF 1.0 was released in March 2004, followed by a maintenance release (1.1) in May, and is being rapidly adopted by tools vendors, component writers, and application developers alike. The beginnings of widespread adoption are clearly occurring, and any application which you are about to start should certainly evaluate JSF to see if it meets your needs. Besides the functional APIs described above, you will enjoy the availability of robust tools support from many vendors (shamless plug -- including the product I am currently an architect for, Sun Java Studio Creator).
The Bottom Line
But what about all those existing Struts applications? Are they going to get left out in the cold, or the developers forced to abandon their existing code and rewrite it? Nothing could be further from the truth.
The ideal scenario for existing Struts applications would be that we should be able to migrate, one page at a time (nobody has time to replace their entire UI in one fell swoop) to using JSF component tags -- either the standard ones shipped with JSF, or from any available third party component library -- to improve the richness of the user interface. And, because of the original MVC-based promise of separation of concerns, this migration should require little or no change in the back end functionality of the application (for Struts, that primarily means Action and ActionForm classes). Also, the migration should not eliminate the ability to use key Struts features like Tiles and the Validator Framework.
This scenario is, in fact, achieveable. In the Struts source repository is the Struts-Faces Integration Library, that achieves exactly this goal. It is currently available in nightly builds, but will shortly be released as a stand-alone add on library for Struts 1.1 or 1.2 based environments. The nightly builds include two versions of the canonical Struts example application, one using Tiles and one not, both using the Validator Framework.
If you have an existing Struts based application, then, I encourage you to evaluate a migration towards using JSF components instead of the original Struts HTML tags. Not only are the original tags effectively superceded by JSF, they are also not undergoing active development at the moment. You will find effectively equivalent functionality in JSF components already available, and much more sophisticated user interface components under development by many providers, for use in the future.
For new development, here's the best strategy for determining what to do:
- Evaluate the two technologies individually, to see if they satisfy your requirements.
- If one or the other technology is sufficient, go ahead and use it (it's easier to learn and use one technology rather than two where possible); keeping in mind, however, the caveats about Struts HTML tags mentioned above.
- If your requirements include unique features supported only by Struts (such as Tiles or client side validation support), feel free to use the two frameworks together.
It should be clear by now that there is overlap between Struts and JSF, particularly in the view tier. Over time, JSF will continue to evolve in the view tier area, and I'm going to be encouraging the Struts community to focus on value adds in the controller and model tiers. Thus, it will become more and more clear that there is room in many web application architectures for two frameworks, each focused on their own tiers, cooperating to meet overall architectural requirements. The details of this, however, will be the subject of further discussions on the Struts developer mailing list, and (undoubtedly) future blog entries.
- Why HATEOAS?
- Sun Shining On The Cloud
- At RailsConf 2008
- jMaki on Rails Example App
- jMaki on Rails
- Is Visual Web Pack Based On Shale?
- Creator 2 Is Out ... And I Get To Have A Life
- Web App Framework Innovation Continues -- News At 11
- Data Provider APIs -- A hidden gem in Creator 2 EA
- Back from behind the firewall