As I said, I won't be attending the W3C enterprise computing
workshop. too busy with other things, including writing up the
interop results for the WSRF-based deployment API, my review of the
first Alpine prototype, and the final editing stages of Ant in Action.
If I were going, this is what my position would be
Position paper on the W3c Workshop
Let's recognise that the SOAP dream of dynamic service binding,
interop and global services is dead. The only place SOAP survives
is in the enterprise, because if you can control both ends of the
conversation, you can use the same toolkit and eliminate interop.
The key selling point of most SOAP stacks -reverse generation of
WSDL from your classes- is actually viable in this context, rather
than the source of interop problems discussed in [Loughran and
Smith, 2005]. The handholding the tools provide is something
developers expect and appreciate, especially once they get the SOAP
debugging tools they also need.
The other thing that is doomed, apart from the odd special case,
is the fat client application. The cost of developing, testing and
maintaining client apps is too high compared to web sites, the
functionality of which is improving every day. If you must do a
rich client application, XUL is the most compelling framework, as
it has many of the features of a web application.
At the same time, Web2.0 != REST. There are some very RESTy
parts of the ecosystem: RSS and Atom feeds; the Atom Publishing
Protocol. But AJAX is not REST, merely something else that uses
HTTP to exchange content, be it XML or JSON. And so there is no
clear cut model for writing REST applications, other than the
''mashup'', web sites that integrate the published front ends of
other applications.
The W3C can and should embrace the web-centric architecture,
rather than try and fix legacy protocols to work through proxy
servers by helping them tunnel over HTTP. What then are the
problems?
- How to provide a client programming model that accesses REST
endpoints with the same ease of use as
same-stack-SOAP-development?
- How to integrate Atom feeds and APP into the enterprise as an
alternate communications pattern; polling over posting?
- What is the best programming paradigm for this. Ruby on Rails
shows how a dynamic language with continuations and the
ActiveRecord database binding makes server-side web development
easy. What can we do with clients?
- How to keep Web 2.0 style applications providing a back end
'service' architecture that meets the needs and business models of
providers and consumers.
- How best to transition legacy middleware -including SOAP
systems- to the new world
On an personal note, having implemented a SOAP stack with
WS-Addressing and WS-RF support, can I observe that the
near-perfect lack of tests makes any chance of compliance very
unlikely. The W3C should not only embrace and adopt the Web 2.0
technologies, it should adopt their test-centric, iterative-design
processes for the development of future standards.
