One unfortunate consequence to the drag-and-drop design view is the slowness associated with undo; removing a component, component customization, or data binding incurs a noticeable delay. Given all of the underpinnings of code required to support the interface, this is understandable; still, I would hope in subsequent releases that Sun would work to ameliorate some of the delay.

Though JSC2 provides access to data and logic sources, and even though it is built atop NetBeans, Sun doesn't recommend using the IDE to actually build any of those business services. Instead, the concept that they're championing is that a team of Java/J2EE developers would have already created the underlying business logic objects or services to drive the functionality of your application; JSC2 is then employed by an analyst or designer to composite those services into the front end of the Web site. Sun envisions JSC2 existing within a development ecosystem, comprised of their own Sun Java Studio Enterprise for the "actual" Java developers building EJB and WS-based business services, analysts compositing these services into a JSF-based front end with JSC2, with the final work deployed on their own Sun Java System Application Server.

Understanding this helps counter some common criticisms of JSC2 - that it lacks integration with modeling tools, profiling support, etc. JSC2 doesn't exist to replace more powerful, general purpose IDEs like Eclipse, IntelliJ or NetBeans; it seeks to augment them - and therefore shouldn't have to support more powerful features like round-trip model engineering or profiling.

Visual Page Navigation
The visual page navigation editor provides an intuitive way to draw relationships between each page in your Website; this is akin to the Struts config visual editor in IBM's WSAD/RAD or Oracle's JDeveloper, for those of you who are familiar with them. Simply select a page, click and drag outward (this creates the relationship arrow, rather than selecting the arrow from a palette, which I think is more intuitive), and drop the arrow on the desired end page. JSC2 handles all of the innards required to link the pages together. Each relationship can take an optional name, letting the designer keep track of the use case associated with that activity. You can also manually edit the underlying <faces-config/> XML configuration file if necessary (Figure 5).

Versioning
JSC2 supports integration with CVS and Visual Source Safe code repositories; it does not support direct integration with Rational ClearCase, CA's Harvest, or the open source Subversion, though this does not necessarily prevent you from using these products with JSC2.

Deployment
Applications can be run locally from within JSC2 via the bundled Sun Java System Application Server PE. JSC2 includes support for remote deployment to the Sun Java System Application Server or WebServer; you'll have to export your project as an .ear or .war file to deploy to other application servers, such as IBM WebSphere, BEA WebLogic, JBoss, or Apache Geronimo.

Framework Support
Sun takes the Henry Ford approach to framework support in Java Studio Creator - you can use any MVC framework you want, as long as it's JavaServer Faces.

In my conversations with Sun representatives - including luminary Craig McClanahan - about plans to support other MVC or ORM frameworks, their response was noncommittal. Essentially, the viewpoint is that basing the MVC layer on JSF, the presentation tier on JSP, accessing data through RowSets, and using EJBs for business logic all conform to J2EE specifications, even though doing so at the exclusion of alternative frameworks restricts choice. In this sense, JSC2 becomes a showcase for Sun's work in creating J2EE standards as much as a RAD tool for allowing designers to quickly build Web applications. Unfortunately, my experience is that enterprise Java development does not necessarily revolve around Sun's published best practices on the matter - for instance, there is a general disdain in the industry around using EJBs at all, and most J2EE applications I've worked with manage data through an ORM framework, such as Hibernate or JDO, not through JDBC and RowSets.

The other unfortunate consequence of this restriction is that it works to prevent adoption of JSC2 within enterprise development environments - unless by some chance the company you're working with already uses JSF, encapsulates business logic in EJBs, and has no known plans to ever change this architecture.

As a technologist, I don't let the capabilities of an IDE force my hand in determining which underlying frameworks are best suited to any project - technology decisions should be driven by several factors, primarily TCO and functional/non-functional requirements. In the event you're working in an environment where the underlying MVC framework isn't JSF, JSC2 could still be used by your analysts for rapid prototyping; there is still value in leveraging JSC2 as part of an agile process. With expanded support for Struts Classic, Struts Shale, Spring, Hibernate, JDO, Velocity, etc., I think JSC could become a vital, must-have IDE in most J2EE shops. Without expanded framework support, its role must be necessarily relegated for use only by those businesses that have already standardized on JSF, or those that adopt J2SC for rapid prototyping.

Of course, Sun's target market for JSC2 are SMBs, which don't base their purchasing decisions on architectural flexibility; their primary concern is keeping IT costs down. J2EE development has traditionally been an expensive, complex undertaking, preventing many SMBs from using Java at all. By lowering the technical bar of entry, JSC2 brings J2EE into the arena normally ruled by LAMP and .NET applications, making it a real alternative for many SMBs.

Plug It In
For the record, JSC2 does sport a pluggable architecture for UI components; a good example of why you'd want to use this is including AJAX functionality in your site, for which there is a download available on Sun's Java Studio Creator support site. This kind of pluggable architecture is encouraging, as is the existence of a timely library such as one supporting AJAX. It shows both Sun's acknowledgment that the technologies it makes available in its toolset aren't necessarily gospel; it also shows a willingness on Sun's part to respond in a timely manner to new technologies as they appear on the tech landscape. Good show.

Conclusion
Sun has done a successful job of creating an environment that allows J2EE applications to be quickly composited with a visual design approach, using existing business services. Java Studio Creator 2's user interface is well-thought-out, making the tool easy to learn and use, and provides a great selection of user interface components and other tools for rapidly building J2EE Websites. Building JSC2 on top of NetBeans gives users the advantages of a stable, feature-rich platform with a thriving user community. Compared to offerings from Microsoft and Macromedia, Sun's JSC2 pricing model is extremely attractive.

However, in forcing users to build on top of a specific architectural stack, Sun limits the choices available to JSC2 users and limits the kind of customers and markets that will be attracted to the tool. Rather than basing your decisions on the best technology for meeting your company's requirements, deciding whether or not to use Java Studio Creator 2 depends more on your business' budget and developer skill set. Some of the code-generation features would make agile or test-driven development practices hard to sustain. Performance issues surrounding the original JSC release unfortunately remain in the latest edition.

All told, if you're an SMB looking for a cost-effective way to rapidly and visually build your company's Website, Sun's Java Studio Creator 2 is definitely worth considering.