According to Stephen Maryka, collaborative enterprise mashups and other next-generation Web applications are on the horizon. In particular, the combination of SOA and Web 2.0 realizes significant new efficiencies in the way members of an enterprise community interact amongst themselves and with corporate data that is constantly changing around them. However, speculation in the development community is that there are fundamental gaps between the technologies that are needed to realize these benefits.
In this article posted on SearchWebServices.com, Maryka examines the state of Java presentation technologies in an effort to understand where the standards must go to facilitate the marriage of SOA and Web 2.0 concepts.
Necessary improvements that Maryka lists include:

A more holistic approach to incorporating Ajax interactions within the JSF lifecycle, in particular an improved user interaction model and an incremental presentation update

A mechanism to push dynamic presentation changes to the client (essential for achieving the true dynamic nature that the Web 2.0 model demands)

A conversation scope to facilitate multi-view support and effectively support bookmarking and back-button features in an application

A modified Servlet model to handle long-lived requests in a thread-efficient manner in order to support the push model

What else do you think needs to change in order to support a new generation of collaborative enterprise applications?

The message I get from this article is that the new standards required are completely different from JSF and may not even be J2EE-specific (though this is probably not what the author intended).
Once you acknowledge that there are at least some interactions that exist purely on the client, where a JSF server would have no involvement, the entire architecture flips around: the question becomes, which interactions should the server be involved in and why?
The server needs to be there at least for security and persistance. Modern AJAX frameworks like SmartClient do not require JSF and can easily support full page, multiple screen user interfaces without leaning on the server at all. The server only needs to be contacted when data needs to be loaded or saved, and its purpose is to enforce data integrity and business rules.
So a deployed AJAX based web application can look like:
- an .html file on a webserver
- an authentication mechanism
- some web services
Notice that there is no JSF or even J2EE in the above list. The standards that need to be created in this space are more along the lines of web services that support the standard CRUD operations (create, retrieve, update, delete), similar to SalesForce' AppForce WSDL service. AJAX frameworks that directly understand XML Schema and other metadata formats obviate the need for any JSF-based data access in the creation of enterprise mash-ups. The resulting architecture is simpler, easier to audit from a security or scalability standpoint, and truly server platform agnostic.
Some examples of what I'm talking about:
- Fullscreen application requiring only CRUD web services from the server
- Client-side XML schema import configures an AJAX grid and form, including validators
- Several examples of binding to WSDL and REST services from the client

So a deployed AJAX based web application can look like:
- an .html file on a webserver
- an authentication mechanism
- some web services

Funny: this is the description of Java Web Start deployment as well :)
By the way I think that 'some web services' do not have to be XML based, for example Hessian protocol is really good for accessing Java APIs.
Ideally those services will be CORBA based ;)

So a deployed AJAX-based web application can look like:- an .html file on a webserver- an authentication mechanism- some web services

Funny: this is the description of Java Web Start deployment as well :)

Quite right, and in general, of any client-server application deployed to the web, or even of an installable application that you download. This is a clear indication that this is the right architecture for an AJAX web application: simply put, when you have a powerful GUI framework at your disposal you don't choose to descend into JSP/JSF soup, you use a clean client-server architecture.
I think we will have to agree to disagree on whether it would be ideal for those services to be CORBA-based ;)

Looks cool to me. The server will act more or less as a data repository or service repository to put it in better words.
I think technologies like DWR and DOJO are really showing signs of the things to come. No Need of any JSF only cool AJAX front ends talking to services using DWR...

Looks cool to me. The server will act more or less as a data repository or service repository to put it in better words. I think technologies like DWR and DOJO are really showing signs of the things to come. No Need of any JSF only cool AJAX front ends talking to services using DWR...

Still it is totally beyond me, why these technologies are "cool". A graphical library and an application framework written in just another language for just another execution platform. The quality of which is sub-standard for at least the next three years, when the next server/side client side application framework will emerge based on yet another language and yet another execution framework.
It's not as if Java Web Start, ActiveX and Flash are doing anything different. They are just doing things better, with a better language, a better graphical component library, more mature network access....
The other thing I do not understand is what the discussion has to do with "SOA" to start with. "SOA" as I understand it, is totally agnostic to the interaction paradigms that the various frontend applications use. Any half decent server side application uses a "service layer" internally since at least 2000, so it should be adabtable in any AJAX application paradigm (then known as "Fat Client" paradigm) anyway.

<blockquote The other thing I do not understand is what the discussion has to do with "SOA" to start with.
I agree.
IMHO this article would be more appropriately titled something like "Ajax integration with JSF".

I am wrong..I feel these technologies are hot...Not very sure what do you mean when you say
'A graphical library and an application framework written in just another language for just another execution platform'
This another language is javascript the only language the browser talks..Well I dont think we should be comparin it to Flash or Active X as those are implementations of a falt client..Here we are trying to acheive a thin but rich client.
For me DWR works very fine..We have used it in our application quite a lot.
'The other thing I do not understand is what the discussion has to do with "SOA" to start with. "SOA" as I understand it, is totally agnostic to the interaction paradigms that the various frontend applications use'
I agree that its agnostic to where we consume the services.But the whole idea is to front end the services with an AJAX front end rather then consuming it at the Struts layer using Business delegates or something. This i see as a shift in the way we deal with services..If you use Flex u can consume those services using Action script but again u need to install a flash plugin and for development you need to invest money for purchasing flex..
What I meant by cool is that the technologies like DWR and DOJO are making broswer rich even without those costs involvement.
BTW what is ur say on Ruby on Rails..
Shashank

The message I get from this article is that the new standards required are completely different from JSF and may not even be J2EE-specific (though this is probably not what the author intended).

Indeed - I am certain this is not what the author extended. The message I get from this article is that far from rejecting JSF, it "has proven to be well-suited to incorporation of Ajax techniques at the component level" but can and should be extended to better support AJAX interactions.
I am not entirely sure how a message that what is required is completely different from JSF can be read from an article that discusses in detail how JSF can be extended to enable better Web 2.0 support.

The message I get from this article is that far from rejecting JSF, it "has proven to be well-suited to incorporation of Ajax techniques at the component level" but can and should be extended to better support AJAX interactions.

I am not entirely sure how a message that what is required is completely different from JSF can be read from an article that discusses in detail how JSF can be extended to enable better Web 2.0 support

The author of that article is from a company that sells an AJAX for JSF framework. When I see a proponent of JSF saying that even future editions of JSF do not provide a clean architecture for AJAX, naturally my thoughts go to non-JSF approaches that do provide a clean architecture, right now. You would not expect the author of that article to abandon JSF and hence his product.
Then again, I work on SmartClient, one of the few AJAX frameworks that is actually capable of true client-server architecture, so there's by bias.

The message I get from this article is that far from rejecting JSF, it "has proven to be well-suited to incorporation of Ajax techniques at the component level", but can and should be extended to better support AJAX interactions.

Charles wrote...
The author of that article is from a company that sells an AJAX for JSF framework. When I see a proponent of JSF saying that even future editions of JSF do not provide a clean architecture for AJAX, naturally my thoughts go to non-JSF approaches that do provide a clean architecture, right now.

Steve was correct about my intension for the article. It focuses on what will make JSF better, and did not consider alternatives that "are not JSF", and certainly not alternatives that "are not JEE", although others seem motivated to twist the discussion in that direction.

If you hadn't noticed, there are still a HUGE bunch of JEE developers out there, and even more JEE-based applications that will benefit from Ajax enrichment. Our experience with customers from the JEE World is they don't want to do Ajax, they don't want to learn JavaScript, and they don't want to dismantle their application architecture. They do, however, want richer applications and seem mostly willing to be nudged toward JSF if they haven't already gone there themselves.

As for other alternatives that are "not JSF and not JEE", that's a whole different discussion. There are lots of choices out there in this realm, but I have a fundamental problem with most of them, as they rely entirely on large amounts of JavaScript running client-side. Frankly, we view that as a pretty fragile environment to build sophisticated enterprise applications in. On top of that, the client-centric approach blows a major hole in the web security model, and large enterprises, like financial institutions, aren't going to be very keen about that. The geeks gone wild syndrome in the Ajax World isn't going to fly far in the enterprise, and is doing a disfavor to the industry in general.

In the meanwhile we are working with JSF, and JEE and looking to bring Rich Internet Application features to the JEE community with the least amount of pain. In that World, I can honestly say we have been luckily enough to have never faced a situation where a customer was deciding between ICEfaces and SmartCeint, so I guess I won't start fretting yet.

Despite all this, my original point remains. JSF needs to address Ajax features better in the 2.0 specification. Does anyone disagree with that?

As for other alternatives that are "not JSF and not JEE", that's a whole different discussion. There are lots of choices out there in this realm, but I have a fundamental problem with most of them, as they rely entirely on large amounts of JavaScript running client-side. Frankly, we view that as a pretty fragile environment to build sophisticated enterprise applications in. On top of that, the client-centric approach blows a major hole in the web security model, and large enterprises, like financial institutions, aren't going to be very keen about that. The geeks gone wild syndrome in the Ajax World isn't going to fly far in the enterprise,...

+1
Usability is important, but it is just one parameter, and rarelly the most important one for enterprise applications (and many non-enterprise applications as well).

... I have a fundamental problem with most of them, as they rely entirely on large amounts of JavaScript running client-side. Frankly, we view that as a pretty fragile environment to build sophisticated enterprise applications in. On top of that, the client-centric approach blows a major hole in the web security model, and large enterprises, like financial institutions, aren't going to be very keen about that. The geeks gone wild syndrome in the Ajax World isn't going to fly far in the enterprise, and is doing a disfavor to the industry in general.

Actually, SmartClient is in use at a majority of the Fortune 500, and in aggregate, heavy duty AJAX technologies probably cover 99% of the Fortune 500. This is because our technology is incorporated in products by Informatica and Wily/CA among others. So it's not a question of whether heavy duty AJAX will succeed in the enterprise, it already has.
Could you explain why you think using more AJAX "blows a major hole in the web security model"? As I see it, using AJAX with a client-server architecture produces a simpler application that is more easily audited from a security standpoint than the JSF/JSP soup typical of previous-generation architectures.
Large enterprises seem to agree, and of course, I am not actually proposing a new architecture here, just the tried and true client/server architecture.

Could you explain why you think using more AJAX "blows a major hole in the web security model"? As I see it, using AJAX with a client-server architecture produces a simpler application that is more easily audited from a security standpoint than the JSF/JSP soup typical of previous-generation architectures.

I am not so sure, what the original poster meant, but I am happy to explain why there actually is a problem. In multitier client-server architecture, as would be the case in a true SOA, but generally in any client server architecture, it is a good design principle to "pull state up as far as possible and push transactions down as far as possible" (to quote myself). In general this holds true with AJAX applications as well and in fact is one of its main selling points. Now, since this state in a ROW (Rugged Old Web) was stored on the server, it had several advantages.

Low latency to backend servers

Hard to compromise application state

Fairly easy to handle failures. Patterns exist for major cases

With an AJAX architecture (In fact with any "fat/smart client"), this is no longer true. Latency to Back End Servers is potentially high. Application state can e directly attacked and the recovery patterns are not really understood. There are a lot of applications where that does not matter much. There are a whole class of applications where this actually is a problem.
As for the auditing: LOL! If the architecture is good to start with, an classic web application is just as auditable, because it calls the same services to start with. Actually, because AJAX (potentially) uses less bandwidth, it may be more prone to "architecture blur", since a "little additional service" does not cost as much as transmitting an entire web page.

Ajax-based approaches improve performance by never going to the server at all for many kinds of interactions (eg screen rearrangements, sorting, etc).

Hard to compromise application state

Web applications that predate Ajax were compromised in thousands of ways, so it's not exactly hard :) The question is whether an Ajax client-server architecture introduces new vulnerabilities. These days black hats are using Ajax techniques to compromise non-Ajax applications. I have seen little indication that Ajax-based applications are vulnerable to a new class of exploit.

Fairly easy to handle failures. Patterns exist for major cases

If you don't store temporary presentation state on the server, you don't need failover for it. This is one of the larger benefits of client-server architecture in terms of both scalability and reliability.

If the architecture is good to start with, an classic web application is just as auditable, because it calls the same services to start with.

True, you can construct a clean service layer and have JSPs access it in a way similar to a true client in a client-server architecture. However, in practice, many organizations that adopt a JSP-based presentation layer end up sprinkling data access and business rule enforcement throughout their JSPs. From a security standpoint, it is much easier to design and audit a set of data access services than a complicated mixture of data access and presentation logic.

If you don't store temporary presentation state on the server, you don't need failover for it. This is one of the larger benefits of client-server architecture in terms of both scalability and reliability.

Of course you do. You need to build it in the front end application. You need to start multi threaded programming for one thing (or use a toolkit that does it for you), you need to cater for one-time-only transactions, you need to cater for idempotent transactions. Just because the problems are on a different layer does *not* make them disappear! You will not need stateful failover - but you will use exactly the same paradigms on your fat client that you use in a web application (re-establish application state by re-reading data etc.). And don't get me started about the problems of network topology and timeout issues - this has never been thoroughly investigated for critical wide area C/S systems, because there are none outside of controlled (i.e. you have control of the tcp settings and network routing) environments.
After a close look, nothing is as simple as it seems....

If you don't store temporary presentation state on the server, you don't need failover for it. This is one of the larger benefits of client-server architecture in terms of both scalability and reliability.

Of course you do. You need to build it in the front end application. You need to start multi threaded programming for one thing (or use a toolkit that does it for you), you need to cater for one-time-only transactions, you need to cater for idempotent transactions.

You don't seem to be talking about AJAX architectures any more.. for one thing, in-browser Javascript is not multi-threaded, and involving a browser on a WAN in transactional commit would be kind of silly.
It's really quite simple: in an application where the entire page refreshes for most interactions, the server must hang onto a lot of temporary state, including the current expansion state of navigation menus, current contents of form fields, what screen the user is on, etc.
When you have an AJAX client that handles the entire GUI without page refreshes, that temporary state simply resides in the browser. You don't need server-side storage and failover schemes for it, and so application scalability and reliability are increased.

br>It's really quite simple: in an application where the entire page refreshes for most interactions, the server must hang onto a lot of temporary state, including the current expansion state of navigation menus, current contents of form fields, what screen the user is on, etc.

This is - plain and simple - untrue. If AJAX has an advantage it is that it is more interactive. All the state can also be stored in requests and response - this is not even a lot of overhead, since it can be binary. Temporary state can be stored on a database on the server (sounds kind of silly, but is often more effective than all the failover and synchronizing semantics). But even then: You must still provide failover and the like for certain classes of client applications. It does not matter if "the browser" is in a transaction - the data is!
You still must use one time transaction semantics, cater for idempotency, protect against back button usage and concurrency....these problems do not disappear. That said, there are things that you can do very nicely with AJAX, in particular read mostly operations on medium size data sets (no not on large datasets, because those you want sorted by the database and nothing like the database).
And one more thing that should not be discarded so easily: There *was* a reason, why people moved away from C/S architectures in the mid 90s, and it was not only marketing and web hype. C/S systems are prone to several classes of "architectural blur" in their own right. A lot of that should be better now that we have SOA (don't get me started about what this term is abused for) and should be able to do better - but this has not much do with AJAX.

Hi Karl,
I'm talking about a very specific class of state - temporary presentation state - which does not have to be stored by the server in the SOA or client-server AJAX architecture. eg, "the current expansion state of navigation menus" is not transactional and failover is not required for it. The only reason it is ever stored on the server is that, in most existing web applications, a mainframe-like architecture is required where the server re-renders the entire screen on every click. Client-server AJAX applications remove the need for the server to store this state.
If you are unclear on this, best to take it offline: charles dot kendrick at smartclient dot com.
Re: the back button: modern AJAX frameworks have solved this issue. For an example, go to the SmartClient example browser, navigate through a few examples and use your back button. No page refresh, state preserved.
Re: client side operations on medium data sets: yes, the server needs to sort larger datasets, and client-side sorting can be used for smaller ones. Ideally, when a search returns a medium to small dataset, client-side sorting automatically kicks in. That's what we do, see eg our sample app: pick a category with a large number of items, click a header to see a request to the server for the first page of sorted results. Pick a small category, click a header to see client-side sorting.
But we are now getting into details of how a SOA or client-server AJAX architecture is accomplished. If you'd like to keep discussing this, a more appropriate venue might be the SmartClient forums. We'd welcome your input.

I have seen little indication that Ajax-based applications are vulnerable to a new class of exploit

The more execution privileges you give something downloaded from the web on your desktop, the greater the risk. If you download it multiple times, the risk rises again. If you do not restrict that on some trusted partners, the risk rises. Combine that with an application that is very easy to disassemble and the risk rises. This is of course not a new kind of exploit. It is more a question of scale.

Hi,
I like the look of smart client, and it seems to deliver what a rich client should, namely it's smart! The download time seems acceptable to me, any slower though could be a problem.
Javascript at its core is actually a very sophisticated OO language (based on Self). Just in a browers it seeems to be hobbled. Freeing Javascript to be used as a full strength OO language does create the posibility of making the browser a fully fledged development platform. Downloading Javascript code to your browser should be no diferent then downloading a Java applet IMO, other than the fact that the browser will always have a javascript runtime installed.
I'm not sure that it is fair to characterise this approach as "geeks gone wild" as posted by Steve Maryka. To me it seems like the next logical step forward.
Better support in the browser should help address security issues, and could improve javascript download times too. A Javascript code cache on the browser and a javascript sandbox and security model come to mind as two possible ideas that could help (do these exist today?).
Hopefully the Firefox guys are watching, I see an opportunity for them to steal a jump on Micorosoft and IE here. For sure Microsoft won't want browser based apps of this quality competing with Microsoft Apps on the Desktop.
In terms of quality of the user experience, Smartclient is the best Javascript/AJAX solution I've seen so far. Not sure how easy it is to develop with though!
Who knows what the future holds. Firefox, with Javascript desktop applications running in a browser as the standard enterprise desktop platform is a real possibility for the future!
Paul.

Javascript at its core is actually a very sophisticated OO language (based on Self).

I might have been a long time gone, but from what I remember, JavaScript is not object oriented. It is an object based language. Suggested reading: The language specification (http://www.ecma-international.org/publications/standards/Ecma-262.htm).
Of course JavaScript can be used for OO programming, as can C , as can Pascal, as can FORTRAN. In addition JavaScript is a total nightmare to debug. If one would want a dynamically typed and bound OO language, there are some (Python comes to mind), but JavaScript is not an option.

Of course JavaScript can be used for OO programming, as can C , as can Pascal, as can FORTRAN. In addition JavaScript is a total nightmare to debug. If one would want a dynamically typed and bound OO language, there are some (Python comes to mind), but JavaScript is not an option.

Hi,
Javascript is a prototype based OO language based on Self, a research language from Sun Microsystems. Self in turn was based on Smalltalk, replacing Classes with prototypical instances.
Inside a web page Javascript is very limited, after all any objects and methods created will only have scope for that single page request. Outside a browser it is a fully fledged OO language. I believe there is a Javascript interpreter called Rhino which can be used to run fully fledged Javascript application standalone.
Getting away from new page requests to communicate with the server would allow Javascript to be fully utilised. I think this is what they are doing with Smartclient. In this scenario, using XMLHttpRequest is just like opening a socket back to the server in a standard Client-server application.
Paul.

Hopefully the Firefox guys are watching, I see an opportunity for them to steal a jump on Micorosoft and IE here. For sure Microsoft won't want browser based apps of this quality competing with Microsoft Apps on the Desktop.
...Firefox, with Javascript desktop applications running in a browser as the standard enterprise desktop platform is a real possibility for the future!

I believe that most enterprises has a standard desktop configuration that applies to 99% of corporate users, and I believe that IE is included in this standard configuration, and Firefox is not.
Actually, the more sophisticated features that are necessary from the browser itself, and the less portable applications become between browsers (which follows from proposition one) the less chance Firefox has.

Hi my fiend,
Use a little imagination :^).
We would not have AJAX today if Microsoft didn't introduce XMLHttpRequest to IE. When they did it wasn't standard either (infact I'm not sdure that XMLHttpRequest is a W3C standard today).
If some Google or someone else comes up with a Office compatible Web Application Suite, which performed best on Firefox then I could see several things happening:
1. Corporates looking to purchase the suite to much reduce their desktop support costs. Rememby the "thin clients" that Java was going to usher in?
2. Everyone changing there standard desktop browser from IE to Firefox.
3. Microsoft rushing to provide compatible support in IE, in the same way that Firefox and Safari followed IE with support for XMLHttpRequest.
OK. It could be a long shot, but in this crazy industry anything is possible :^).
Paul.

We would not have AJAX today if Microsoft didn't introduce XMLHttpRequest to IE. When they did it wasn't standard either (infact I'm not sdure that XMLHttpRequest is a W3C standard today).

If some Google or someone else comes up with a Office compatible Web Application Suite, which performed best on Firefox then I could see several things happening:

1. Corporates looking to purchase the suite to much reduce their desktop support costs. Rememby the "thin clients" that Java was going to usher in?2. Everyone changing there standard desktop browser from IE to Firefox.3. Microsoft rushing to provide compatible support in IE, in the same way that Firefox and Safari followed IE with support for XMLHttpRequest.

OK. It could be a long shot, but in this crazy industry anything is possible :^).

Paul.

Hello Paul,
(1) Yeah, I remember. Didnt happen did it? =)
(2) Its not gonna happen. IE is already there. Me and you already have firefox, and people like us might change in larger numbers. The average citizen - no way.
(3) Yeah, that would happen, but I bet they will either beat firefox for it, or implement a better technology before.
But about cheaper office suits - there is already OpenOffice - which is free. How many enterprises use that? Total cost of ownership, user training, support etc - everything is on Office side - because it has such penetration already.
A true leap in technology might change it, but if I knew to what I would be silent.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.