Comments on SOFEA
Subbu Allamaraju
At a session on "RESTful Web Apps - Facts vs Fiction" [1] at the
Colorado Software Summit, I briefly discussed about SOFEA
misinterpreting the web architecture, in particular, the uniform
interface and hypermedia as representing application state and not
just data. Some one in the audience pointed me to this group, and so I
am posting my comments here.
The text in quotes below is from the SOFEA paper.
"Thus, the REST approach accomplishes loose coupling between systems
using the standard vocabulary of the web – HTTP verbs and URL nouns, a
“contract” that hides actual implementations behind a common façade –
the REST Service Interface. "
It is more than that. Loose-coupling in REST can be achieved via the
following:
a. Media types to describe representations
b. Uniform interface to allow visible interactions, so that clients
and intermediary infrastructure can follow the interpret all
interactions
c. Link relations to describe URIs [2,3]
d. Hypermedia as the engine of the application state, viz.,
representations contain not only data, but also contain the state of
the application in the form of contextual links.
Secondly, please don't coin terms like "REST Service Interface". REST
is not an interface. The interface that exists in REST or HTTP is a
"uniform interface", viz., a generic interface with a fixed set of
operations.
"Whenever we use a client device to run an application (and this
client device could be a workstation or any of the newer handheld
devices we all own and love), three separate and distinct processes
take place, whether we realise it or not:
1. Application Download (AD)
2. Presentation Flow (PF)
3. Data Interchange (DI)"
IMO, this kind of separation works only for "single page"
applications, where you download the entire app (HTML + JS + others)
when a user hits a URI, and subsequently, all interactions happen over
XHR. By focusing on just such applications, the app will not be able
to support browser navigation and book-markability, which by the way,
are not broken unless an app breaks them by poor implementation choices.
Secondly, although you mention the download server being different
from the "business logic" server, due to same origin policy, from the
clients point of view, these are the same. Hence, the suggested SOFEA
architecture has a much narrower scope and relevance on the web.
"This lack of respect for data as data is a fundamental characteristic
of HTML over HTTP. It has been with us since the inception of the web,
but no one seems to mind. "
No one seems to mind because it works. More importantly, this process
is not lossy. If you consider the architecture of the WWW, you will
find that how data is transmitted between clients and servers is
dictated by media types. A media type such as "application/x-www-form-
urlencoded" or "application/xhtml+xml" specify information is encoded.
Just because a media type prescribes stuffing parameters into a single
string (such as "p1=v1&p2=v2") does not mean that it is mistreating
the data. A different media type, such as "application/vnd.myorg.person
+xml" may specify a different encoding of information, say, as an XML
document with an underlying XSD or RNG schema. Concluding that the
current web is not respecting data is gross misinterpretation of the
web architecture. Instead of looking for schemas, look for media type
specifications.
"It is not possible to trigger a Presentation Flow in a web
application without initiating a Data Interchange operation (e.g., a
GET or a POST). More vexingly, every Data Interchange operation willy
nilly results in a Presentation Flow. It's a classic case of tight
coupling between two orthogonal concerns. ... In hindsight, it might
have been better if they had been completely broken, because then
this aspect of the thin client architecture would have been fixed."
IMHO, this argument is a stretch. HTML was designed for navigation,
and navigation involves sending a representation (of a given media
type) or following a URI and then fetching a new representation. This
is what makes a generic client such as a browser work.
"Although ingenious, the POST Redirect GET pattern is mere band aid
over the fractured web architecture. "
Where did the authors get this idea from? IMHO, this paper is
misinterpreting the difference between non-idempotent operations and
idempotent operations.
"Use XML to define data structures, data types and data constraints
for the application end to end. "
I think this approach is ignoring media types and links, and is in
stead focusing on passing data around. The key downside of this
approach is that the code downloaded will be strongly coupled to the
so-called "business logic" server as the code needs to understands how
to construct URIs and guess what URI accepts/returns what kind of
representations.
"4. Not being tied to HTTP, the model is open to peer to peer Data
Interchange."
IMHO, this is a mistake. SOAP/WS made the same mistake of treating
HTTP as a transport protocol. Please don't repeat it. By ignoring
HTTP, you are also ignoring the uniform interface and all the
semantics that go with it such as caching, optimistic concurrency,
idempotency and safety. Consequently, apps built using SOFEA will not
be able to scale and perform the way users expect the web to work.
Apps will also be forced to invent proprietary mechanisms to account
for concurrency. This is a slippery slope.
To summarize, by relying on XHR and such technologies, there are more
opportunities to take advantage of the RESTfulness of the web
architecture. This paper makes some honest attempts for Ajaxy single-
page applications, but claiming that the current web is broken is a
gross misinterpretation. By relying on HTTP's uniform interface, and
by using media types and links, it is possible to build richer and
RESTful applications that take advantage of the web architecture and
not fight against it.
Sincerely,
Subbu
http://www.subbu.org
[1] http://www.subbu.org/blog/2008/10/slides-from-the-colorado-software-summit
[2] http://www.subbu.org/blog/2008/09/on-linking-part-1
[3] http://www.subbu.org/blog/2008/09/on-linking-part-2
Kris Zyp
> To summarize, by relying on XHR and such technologies, there are more
> opportunities to take advantage of the RESTfulness of the web
> architecture. This paper makes some honest attempts for Ajaxy single-
> page applications, but claiming that the current web is broken is a
> gross misinterpretation. By relying on HTTP's uniform interface, and
> by using media types and links, it is possible to build richer and
> RESTful applications that take advantage of the web architecture and
> not fight against it.
>
main points of SOFEA), but I certainly agree with your points, I think
it is critical that we build on HTTP, not against it. It is certainly my
ambition that we can leverage the RESTful architecture that HTTP
provides, thanks for your comments.
> IMO, this kind of separation works only for "single page"
> applications, where you download the entire app (HTML + JS + others)
> when a user hits a URI, and subsequently, all interactions happen over
> XHR. By focusing on just such applications, the app will not be able
> to support browser navigation and book-markability, which by the way,
> are not broken unless an app breaks them by poor implementation choices.
>
>
book-markability using hash/URL fragments, and HTML5 is providing
further standardization of the hash/JS interaction (partly due to some
bugs in IE's handling of hash changes and the difficulty in track them
from JS side of the user agent). There is nothing anti-RESTful about
"single page" apps, it just makes the JavaScript part of the user agent
in HTTP interaction (and hence it is so important that the JavaScript
actually understands and leverages HTTP properly, as I think you are
advocating).
Thanks,
Kris
Subbu Allamaraju
>> IMO, this kind of separation works only for "single page"
>> applications, where you download the entire app (HTML + JS + others)
>> when a user hits a URI, and subsequently, all interactions happen
>> over
>> XHR. By focusing on just such applications, the app will not be able
>> to support browser navigation and book-markability, which by the way,
>> are not broken unless an app breaks them by poor implementation
>> choices.
>>
>>
> This isn't true, "single page" apps have long-supported navigation and
> book-markability using hash/URL fragments, and HTML5 is providing
> further standardization of the hash/JS interaction (partly due to some
> bugs in IE's handling of hash changes and the difficulty in track them
> from JS side of the user agent). There is nothing anti-RESTful about
> "single page" apps, it just makes the JavaScript part of the user
> agent
> in HTTP interaction (and hence it is so important that the JavaScript
> actually understands and leverages HTTP properly, as I think you are
> advocating).
Note that history solutions that rely on changing the URI with those
fragment identifiers and require the app to "re"create the previous
view are confusing to the end user. As I discussed in [1] below, the
correct behavior is to let the browser present "its" view of the
previous page without the app reconstituting it programmatically.
You are right about HTML5.
Subbu
[1] http://www.subbu.org/blog/2006/06/ajax-and-history-management-alternatives
Justin Meyer
Is this forum for both TSA and SOFEA? Is the main goal promoting and
discussing Thin Server Architectures? Is SOFEA an offshoot?
In my opinion, I think we are burning rubber with SOFEA (generating a
lot of smoke without going anywhere). If the core message of this
group is TSA, SOFEA's constraints are distractions to that core
message. SOFEA gives too much fodder for the elite programmers to
tear apart.
As a related aside ...
I cringe when I hear statements like:
Secondly, please don't coin terms like "REST Service Interface".
REST
is not an interface. The interface that exists in REST or HTTP is a
"uniform interface", viz., a generic interface with a fixed set of
operations.
like the group gets too caught up in semantics and word games. No one
cares. We sound like a bunch of Grad students.
These ideas are going to be a success not based on formal
descriptions, but by clearly communicating the advantages of TSA. I
know about 4 different companies that are just trying this 'java'
thing after programming for AS/400 for the last 10 years.
At the end of the day, 90% of developers don't really care if they are
following the standards of the web or following what was originally
intended. They care about doing whatever makes their clients happy
the easiest. When they think of that, they should think of TSA.
In my opinion, TSA is easier to build more engaging applications.
That is all that matters.
Justin Meyer
Subbu Allamaraju
On Oct 28, 2008, at 11:42 AM, Justin Meyer wrote:
>
> Is Gmail or Facebook, which uses history, confusing for its users?
I don't know what happens behind the scenes, but the key point I am
making is that, when a user clicks on the back button, what the user
expects is the browser's view of the previous page. Some of the apps I
have seen try to recreate the view based on the state as known to the
app. In some cases, these two views could be different, and that is
what can confuse users. The difference may be subtle in some cases,
but not always. Apps should not have to recreate views when the user
is navigating browser history.
Subbu
http://www.subbu.org
Peter Svensson
Much of my own argumentation and research (if one can call it that) have been in justifying the general ideas without being too specific about the implementation. OK, I _have_ been specific about what I prefer, but also that it is just my cup of tea (JSON, love and let live :).
The SOFEA specification as it stands is very much geared towards large, multifaceted intranets, where SOA is the common factor binding systems together. Even if Ganesh and his team may have some detail wrong, or have been misinterpreted, this does not take away the central message of it.
I am not a scholar myself, and like Justin I'm a very pramgatic person, but that also mean that I'm blind on those eyes (Not really a Swedish saying, but nevermind). Perhaps the discussion over the detailed implementation can and will be important to future technologies, or perhaps even the current ones.
And I still feel that there is so much common ground between TSA and SOFEa that I don't feel any immediate need for this to turn into a splintering of any sort. TSA is very coffee-discussion simple and open - OSFEA is very specific and detailed for a specific (and very common) enviroment. No problem there.
Also, I get the feeling that Subbu agrees on the general ideas of TSA and SOFEA at heart and only have issues with certail details of SOFEA. Isn't that so?
Cheers,
PS
claudiobosticco
I'm developing my first TSA web app, so I'm here to learn and to share
my experience.
Btw, I'm using smartclient LGPL for the UI (6.5.1 but waiting for the
7.0 release...)
Claudio
Peter Svensson
I haven't used Smartclient, but I saw it demoed at AjaxWorld recently. How do you find it in terms of usability, features, ease of development, et.c.?
Cheers,
PS
Subbu Allamaraju
> I cringe when I hear statements like:
>
> Secondly, please don't coin terms like "REST Service Interface".
> REST
> is not an interface. The interface that exists in REST or HTTP is a
> "uniform interface", viz., a generic interface with a fixed set of
> operations.
>
> My sincere apology to Subbu for picking on this statement. I feel
> like the group gets too caught up in semantics and word games. No one
> cares. We sound like a bunch of Grad students.
>
No apologies needed, but not sure why you had to "cringe". This
discussion is about some fundamental concepts and not word games.
Don't mean to pick on your remarks, but it is good to get the concepts
right.
Subbu
claudiobosticco
> I haven't used Smartclient, but I saw it demoed at AjaxWorld recently. How
> do you find it in terms of usability, features, ease of development, et.c.?
features that I absolutely need (i.e. grids), and also rejected ExtJs
due to the licensing policy...
Beware: I don't want to start a smartclient vs extjs flame!
but I think that in terms of usability extjs is better than
smartclient. Maybe also a bit more responsive. I'm waiting for the 7.0
release because there will be new skins, and I hope in a positive
impact on usability. Forgive me if I'm plain wrong :-)
Features: very rich! I'm very impressed, I still haven't discovered
all features...their demos page can take a while to load (better to
disable firebug) but I think it's impressive.
I like the databinding and the validation. In my project I will load
dinamically the description of forms, layout and validation, in json
format...and I'm planning to interpret the validation rules written in
json format to do the server-side validation, also (I think their
commercial server side components do this).
ease of development: maybe a bit hard to start, but the docs are good
to me, and the developer console is great.
The commercial version has also a "visual builder":
http://www.smartclient.com/releases/vb_video.htm
Claudio
Peter Svensson
claudiobosticco
> Dojo has this, and so has JavaScriptMVC and ExtJS. And of course
> Smartclient. I don't think that jQuery have any common standard around data
> management, but I'm not really the one to ask.
developing it.
> I did get a comment today on my blog, where Andrej Koelewin said that he had
> made almsot the same kind of presentation that I had at my Google tech talk,
> but using jQuery instead :)
>
good, I'll take a look at it together with yours :-)
> Which proves that it works anyway. But concerning that, one of the things I
> like to see coming out of the OpenAjax alliances work is an open standard
> data API between various layers in a client-side app, so that we can reuse
> each others components and data sources.
Claudio
claudiobosticco
> think that the central theme for most of the toolkits used in building TSA /
> SOFEA applications is that they have an official data model which cleanly
> separates the widgets that consume or use data from the service or place
> that provides it.
used by the RAP Eclipse project.
Claudio