Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Floyd Marinescu on Jul 04, 2006 11:13 AM
After a heated discussion on the Struts-Dev list about the future of Struts and Shale, it has been announced late last week that Shale will become it's own top level Apache project, instead of a sub-project of Struts.I want to focus on attracting a much larger audience of developers who are *not* O-O professionals, whose idea of "code reuse" is cut-n-paste, and who might actually prefer to use tools (SAF2's fundamental architecture is pretty much untoolable, even if someone were motivated to spend the effort to build tooling around it).
Velociti Partners Customer Survey
The Role of Open Source in Data Integration
Adobe® Flash® Platform Overview PDF
http://weblogs.java.net/blog/jhook/archive/2006/07/saf2_and_shale.html
Hi Jacob, We are all for driving traffic to peoples blogs (yes InfoQ has actually gotten big enough in the month since it's launched that it can do that), but it would be more polite (and possibly more effective for you) to also comment in this thread to express your point as well as link off to your blog. Thanks for participating. Respectfully, Floyd
...to also comment in this thread to express your point as well as link off to your blog.
I'll take note of that in the future :-) Respectfully, the blog does point back to and mentions InfoQ.com.
I like Jacobs's suggestions on collaboration. He says that both SAF2 and JSF should:
I think that WW2 has nailed the action framework stuff, and I'm very happy implementing my actions with it. However, it is taking a lot of awkward missteps into the AJAX component space, and I get jealous of JSF's ability to pick and choose third party components to drop into the UI.
I would consider "sprinkling" JSF into my WW2 stuff per Don's suggestion. But as Jacob notes, there are still enough unnecessary incompatibilities between the frameworks that it is too much of a pain in the ass to do so.
JSF seems to be going through an identity crisis that is reminiscent of JINI. First, JSF was presented as a tooling platform, then its proponents got very defensive and claimed that JSF worked best without tooling. Now we've come full circle, where even Craig admits that JSF is only superior in a tooling context.
In the end, it looks like JSF's primary selling point will be its vendor support, which will exist purely by virtue of being forced into the JEE spec. That's probably not going to be enough to win me over.
JSF seems to be going through an identity crisis that is reminiscent of JINI. First, JSF was presented as a tooling platform, then its proponents got very defensive and claimed that JSF worked best without tooling. Now we've come full circle, where even Craig admits that JSF is only superior in a tooling context.
The problem is people absolutly want to put a label on JSF. After having worked with it, I can say JSF is a nice platform to work with without using any tools. But some people aren't comfortable with OO and prefer to use RAD tools. Those 2 facts aren't exclusive. From what I understand, Craig didn't say JSF was only superior in a tooling context but that he is looking to attract people coming from VB or Delphi. It doesn't mean JSF is a dirty solution. Not at all. To work with JSF, tools support isn't essential but available if you want it.
We designed JSF first as a solid, component-centric framework, and second as a framework for tools. Whatever the marketing folks did with that (or what Craig is quoted as saying) is not so much my concern. I'm still baffled that the fact that we actually thought about tooling in the first version is somehow a negative thing in anyone's mind - but no one ever suggested on the expert group that JSF was or should be a tooling platform. (I'm also amazed that anyone would claim that any framework - JSF, Hibernate, WebWorks, etc., is somehow best without tooling.) I agree entirely with Jacob's suggestions for collaboration among the frameworks - and JSR 299 looks like a fine place to work through many of these issues. Splitting up and going our separate ways, and leaving it at that, seems like a poor route for all of our users.
When I started the thread on Struts dev, my goal was to unify the two groups, not provoke a "divorce". My point was JSF is a solid component framework, and Struts 2 is a proven controller, and the two can and should work together seamlessly. In a perfect world, there would be an action-based controller JSR that could optionally be used with JSF components, and both JSR's would use the same EL, annotations, validations, localization, etc. The Struts 2-style controller is much more powerful than the JSF servlet, and supports other types of views and workflows. On the other hand, JSF, in my opinion, has the better component framework and can handle complex, event-based components, encouraging a component marketplace. It was said that JSF was a view technology that had to define some controller capabilities to get by, so why not replace that controller with a Struts 2-style MVC controller, and let JSF get back to what it is best at?
Sigh ... that is an incorrect misconception of what I am actually saying, which can be summarized very succinctly:JSF seems to be going through an identity crisis that is reminiscent of JINI. First, JSF was presented as a tooling platform, then its proponents got very defensive and claimed that JSF worked best without tooling. Now we've come full circle, where even Craig admits that JSF is only superior in a tooling context.
Craig
In the end, it looks like JSF's primary selling point will be its vendor support, which will exist purely by virtue of being forced into the JEE spec. That's probably not going to be enough to win me over.
You might want to think about whether the kind of vendor support you see for JSF today is even technically feasbile for your favorite action oriented framework. Supporting graphical help in updating configuration files is pretty easy (and commonly available for frameworks like Struts 1 today). Supporting development with visual components, on the other hand, is not particularly easy when there is no visual component model, let alone libraries of components that correspond to that model.
NOTE - it may well be that you are not won over by this ... and that's fine. In particular, if you like action oriented frameworks, you can't go wrong with Struts 2 ... it is a very elegant evolution of this paradigm. But, I'm thinking that the number of people who can appreciate that elegance is a heck of a lot smaller than the potential number of developers whose lives could be made better by a framework that doesn't require them to understand that elegance in order to benefit from it.
Craig
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
9 comments
Watch Thread Reply