Some people have talked about Ajax as an impeding death blow to web
application frameworks. Sites like Microsoft's http://www.start.com and
the Atlas samples on http://www.asp.net show the potential of this
technique for building client-side UIs with DOM and JS, coupled to
back-end data providers.
It's not clear to me that this will signal a death of web frameworks,
but maybe it will signal a change in approach. Currently, the benefit
we enjoy from the web frameworks are the strong-typing, debugging and
tracing, the rich class library support, choice of languages, etc. This
has come at the expense of a more user-friendly and unobtrusive UI
experience. The postback is annoying, maintaining state is still not
easy with viewstate or other solutions.
While some of this gets a little easier, ostensibly, with Ajax, it
opens up different problems. First, JavaScript is not strongly-typed.
It is object-based, and you can do a lot with object prototypes,
including what boils down to extending classes at runtime by adding
properties to the .prototype of a constructor function. While this
flexibility can make for a nicer looking UI, it doesn't address other
areas like accessibility, both in terms of 508 compliance and for a
wide variety of devices.
Perhaps what may happen is that the frameworks can evolve to include an
adapter for rendering UIs as "Ajax" capable. They could still render
controls in "standard", server dependent ways for accessibility. I'm
not sure how it would really look, but I don't see Ajax as a solution
to all problems, especially when getting information out there is more
important than usability or wow-factor.
Another aspect to consider though is the continued importance of the
"REST" style of web services as opposed to the SOAP style. A lot of
applications have been "restian" for years, but the style is just now
reaching mainstream awareness. The basic idea is that all resources are
reachable by unique URI. So, you could have an entire database exposed
by URIs. Requests are issued with standard HTTP actions like GET, PUT,
HEAD, and POST. This lowers the barriers to entry for application
developers who might not need sophisticated features of WS-*
initiatives.
All of Yahoo's web services feature REST based API's, as do Google and
Microsoft now with their mapping APIs.
The more important thing about REST is that it avoids tight-coupling by
implying a document-centered approach. SOAP's nature implies, but does
not require, an RPC based approach. The focus is on method calls,
method names. WIth REST, the focus is on packages of information, like
Customer, Order, etc. The contract between the consumer and the
provider is at the level of the schema. Of course, the same is true in
SOAP, but the semantics of the content differ.
There is nothing that prevents you from implementing a document-centric
approach over SOAP, but it would be wrapped in a method call with the
document as the argument.
So, the solution for any given situation will depend on needs of the
application, but it's nice to have more options available in the
toolbox.
More more information about Ajax, REST, and SOAP, check these links out:
SOAP: http://en.wikipedia.org/wiki/SOAP
REST: http://en.wikipedia.org/wiki/REST
Ajax: http://en.wikipedia.org/wiki/Ajax_%28programming%29
Happy Thanksgiving!