My tech talk at Google

14 views
Skip to first unread message

Peter Svensson

unread,
Oct 28, 2008, 10:44:10 AM10/28/08
to so...@googlegroups.com
Here's the resulting TSA tech talk. I was as general as possible, trying to nail down my favorite points, of course. This time I managed to mention Justin and JSMVC as well as SOFEA. Phew!

http://unclescript.blogspot.com/2008/10/tech-talk-on-thin-server-architecture.html

Cheers,
PS

Justin Meyer

unread,
Nov 25, 2008, 12:31:17 AM11/25/08
to SOFEA
I don't how I forgot to say this, but this looked great. Very good
arguments for TSA. Added a quick link to our blog: http://javascriptmvc.com/blog/.
I'm going to use about 60% of your talk.
> http://unclescript.blogspot.com/2008/10/tech-talk-on-thin-server-arch...
>
> Cheers,
> PS

Peter Svensson

unread,
Nov 25, 2008, 3:16:51 AM11/25/08
to so...@googlegroups.com
Thanks,
Please use watever parts of my slides you want (that goes for everyone, of course). I have stolen all nice-looking images and major parts of the layout from Kirs Zyp.

I just did another talk last week in Stockholm for nearly 50 people, and got some very interesting feedback from that. Almsot to a man, everyone was positive, but even so most people (very tech-savvy in all) just didn't make the connection when it came to practical discussions.

I had a coffee-break discussion with one developer who had been to one of my earlier talks and seemed to have understood the concepts well, but who asked a lot of questions of integrating these ideas with an existing Struts2 application he had, and we continued to talk past each other for quite a while.

So it seems that TSA/SOFEA is actually really *hard* to understand, people are not just being obnoxious :) I thinkthe major culprit here is that the only available vocabulary and mental models come from server-centric web frameworks, and even though people agree to and understand the abstract discussions about separation of concerns, when they try to apply it, they lack the mental building blocks to do so.

I tried to be very explicit this time, and had an extra slide that described what TSA implied; single-page apps, SEO borkedness, bookmarking issues, et.c. And that actually lead to an interesting discussion; Is web 1.0 hyperlinking really relevant _inside_ an application? Et.c.

Cheers,
PS

Kris Zyp

unread,
Nov 25, 2008, 9:55:54 AM11/25/08
to so...@googlegroups.com
I was wondering if those in this group might be worth considering moving
towards more of a REST focus as an aim of this group. It is certainly an
uphill battle to attempt to evangelize a new acronym (SOFEA or TSA),
when in fact REST (if it is understood properly, IMO) actually embodies
the same concepts that you are pursuing. I think I mentioned this
before, but section 5.1.2 [1] actually states: By separating the user
interface concerns from the data storage concerns, we improve the
portability of the user interface across multiple platforms and improve
scalability by simplifying the server components. This sounds very close
to the goals of SOFEA. While many people seem to think REST simply means
using GET requests with a certain style of URLs, the REST architecture
as a described by Fielding is actually principals to apply to facilitate
minimizing the processing requirements of the server (TSA) and enabling
clients (SOFEA):
Statelessness - Application state remains on the client (hypertext
as engine of application state), servers can remain stateless, reducing
their complexity
Uniform Interface - Data is discovered and interacting with through
a uniform standard interface, allowing the data to drive applications.
This further reduces server complexity because custom interfaces and
APIs do not need to be designed, generic infrastructure and interface
can be utilized.
Code-On-Demand - REST is designed for code to be delivered to the
client to enrich the user experience
Of course REST is based on extensive academic and empirical research,
there is a solid foundation there. By preaching REST (rather than
something new), you can leverage the existing popularity and buzz around
REST, while focusing on some of the lesser understood concepts (seems
very few people actually understand REST) that are synonymous with
service oriented front end architecture with thin servers. Anyway, just
a suggestion, an idea to consider, obviously that is where my focus is...
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Kris

Peter Svensson

unread,
Nov 25, 2008, 11:25:41 AM11/25/08
to so...@googlegroups.com
Hi Kris,

I think that this is a good move in general, but I don't think that REST covers everything. I'm not trying to be a wet blanket here :) but  we are trying to define more than just data interaction. For example, a lot of things get very weird if you try to map then onto REST operations, like a login. Also, getting the schema out of a RESTive table is also something I would recommend using RPC for, since it's meta-data, which kind of muddles the domains if you use the same table to manage that, as well. 

So to define separation of concerns in terms of protocol (instead of client or server-perspective) we need at least RPC also.  But then it doesn't get as clear-cut (or maybe it does, and it's just me).

But I think that REST is definitely in there in the core. 

Cheers,
PS

Craig McClanahan

unread,
Nov 25, 2008, 2:32:00 PM11/25/08
to so...@googlegroups.com
On Tue, Nov 25, 2008 at 8:25 AM, Peter Svensson <psve...@gmail.com> wrote:
> Hi Kris,
> I think that this is a good move in general, but I don't think that REST
> covers everything. I'm not trying to be a wet blanket here :) but we are
> trying to define more than just data interaction. For example, a lot of
> things get very weird if you try to map then onto REST operations, like a
> login. Also, getting the schema out of a RESTive table is also something I
> would recommend using RPC for, since it's meta-data, which kind of muddles
> the domains if you use the same table to manage that, as well.
> So to define separation of concerns in terms of protocol (instead of client
> or server-perspective) we need at least RPC also. But then it doesn't get
> as clear-cut (or maybe it does, and it's just me).
> But I think that REST is definitely in there in the core.
> Cheers,
> PS

While it's clear that SOFEA intends to encompass more than data
transfer, and I like the way you have been thinking there, I would
echo Kris's recommendation in slightly stronger terms: if you claim
that REST is not *sufficient* for the data transport layer, the
RESTafarian community that does exist will reject *all* your ideas.
All they need point at is "we need at least RPC also" to do that. And
that would be too bad.

Examples of RESTafarian responses you are going to get:

* Why do you need login at all? (Of course, this will quickly
morph into a stateless versus stateful interaction discussion,
so the real question is "are you claiming you need stateful
interactions with the server? if so, why?"

* Why would retrieving mundane things like a database schema
be better suited to RPC than REST? To me, that's pretty much
a perfect use case for a REST approach, because the metadata
is just a resource that can be queried (in whole or in part).

I'd hate to see all your other good ideas about TSA get ignored on this basis.

Craig McClanahan

Peter Svensson

unread,
Nov 25, 2008, 2:45:04 PM11/25/08
to so...@googlegroups.com
Hi Craig,

Thanks for your good riposte :)

Actually, I'm not absolutely certain that REST cannot be the be-all, end-all of data communication betweena client and a server, I'll just see if I can come up with something that is not sensitive.

Let's say that you need to access a resource on the server that is calculated on the fly, like the result of a grid calculation, or the current GPS position of a car. Of course, these things could also be mapped onto a REST object property that is read.

As for metadata, I've always felt that it is unclear where metadata for a REST 'table' should be accessed. Under /table/schema, under /schemas/table or something else? Since this (IMO) feels undefined, I would fel more comfortable moving it out of the domain entirely. OTOH, if people can just agree on a standard for this, it owud make things easier.

Does anyone know there's some kind of prejudicing discussion about this, so as not to reinvent the wheel? I'm fine in general with using REST only for everything, but I have a nagging feeling that it doesn't suffice. I'm happily proven, or implied, wrong, however.

Cheers,
PS

Kris Zyp

unread,
Nov 25, 2008, 3:18:42 PM11/25/08
to so...@googlegroups.com
My point was more that evangelism efforts might be easier if rather than
proclaiming "you should follow this architecture that I thought of or
named, etc", it might be easier to say "there is significant benefits in
following these principles of the REST architecture which Roy Fielding
described and are the proven, tested foundations of web and it's
scalability". You can disseminate the ideas of TSA/SOFEA as principles
of REST rather than new concepts, and I think you can do so without even
taking sides how strictly one needs to follow REST or whether or not one
needs to avoid any REST constraint violations (certainly many people
claim to use REST, and perhaps even benefit from REST architecture, but
still have REST violations (like authenticated sessions)). Many people
understand that REST is a powerful architectural pattern to follow, but
are unclear on what is involved. Discussing the benefits of the REST's
statelessness, uniform interface, and code-on-demand principles as
arguments for TSA may be easier for people to accept and you don't even
need to get into the other principles or try to convince people of the
entirety of REST for such benefits to be realized. I didn't really
intend to argue whether or not REST can and should be used to solve all
problems, just that it is highly regarded architecture (and rightly so)
and thus preaching principles with REST as the reference source is more
likely to be well-received (and rightly so).
Kris

Craig McClanahan

unread,
Nov 25, 2008, 3:19:23 PM11/25/08
to so...@googlegroups.com
On Tue, Nov 25, 2008 at 11:45 AM, Peter Svensson <psve...@gmail.com> wrote:
> Hi Craig,
> Thanks for your good riposte :)
> Actually, I'm not absolutely certain that REST cannot be the be-all, end-all
> of data communication betweena client and a server, I'll just see if I can
> come up with something that is not sensitive.
> Let's say that you need to access a resource on the server that is
> calculated on the fly, like the result of a grid calculation, or the current
> GPS position of a car. Of course, these things could also be mapped onto a
> REST object property that is read.

It sure can. Only your server knows for sure what's static and what's
dynamic :-).

> As for metadata, I've always felt that it is unclear where metadata for a
> REST 'table' should be accessed. Under /table/schema, under /schemas/table
> or something else? Since this (IMO) feels undefined, I would fel more
> comfortable moving it out of the domain entirely. OTOH, if people can just
> agree on a standard for this, it owud make things easier.

Well, there are a lot of hierarchical relationships in our data models
one could reason about. Examples:

* Customers -> Orders -> Line Items

* Databases -> Tables -> Columns

So it seems like the same decomposition principles (and URI
determinations) could be done in both domains. Just one possible
approach:

* Get a customer: GET /customers/{accountId}

* Get a database description: GET /databases/{databaseName}

* Get orders for a customer: GET /customers/{accountId}/orders

* Get tables metadata for a database: GET /databases/{databaseName}/tables

and so on. There's lots of ways to skin this cat, but hierarchical
data models map pretty naturally to hierarchical URIs. (It gets fun
when you have many-to-many relationships, though :-).

In the scenario above, you'd probably support create (POST), update
(PUT), and delete (DELETE) interactions to the customers, orders, and
line numbers data models, but probably only support GET on the
database metadata. That's perfectly fine.

All of that being said, a word of caution is in order. Pretty URIs
are *not* a primary goal of REST -- that's really for human
consumption. The key principle in REST that lots of people miss is
that your data representations (the XML or JSON or whatever you send
back and forth) should include hyperlinks for all the related data you
might want. The general way I would state this principle: a client
application should *not* need to understand how the server's URIs are
composed -- it should be able to contact a canonical "service
discovery" URI and be able to follow links from there." This is a
little overly ambitious when applied universally, but it's a good
measuring stick for your data model design.

Just as one example, let's say you have a "get customers" call that
includes filtering and pagination options (for this, I like "count"
and "offset"). It's real typical for a front end UI to want to
present results in a paginated way, so lets make that easy:

GET /customers?offset=30&count=10

Now, lets include some useful links in the response (I'm using XML by
habit ... same principle applies with JSON):

<customers>
<link rel="previous"
href="http://server.example.com/customers?offset=20&count=10"/>
<link rel="next"
href="http://server.example.com/customers?offset=40&count=10"/>
<customer>...</customer>
<customer>...</customer>
...
</customers>

Now, when the UI wants to respond to a "Previous Page" or "Next Page"
button click, it doesn't have to "know" how to manually compose the
correct URI ... it just uses the right href from a <link>.

> Does anyone know there's some kind of prejudicing discussion about this, so
> as not to reinvent the wheel? I'm fine in general with using REST only for
> everything, but I have a nagging feeling that it doesn't suffice. I'm
> happily proven, or implied, wrong, however.

I get a lot of my RESTful inspiration from seeing how the Atom
Syndication Format[1] and Atom Publishing Protocol[2] were put
together. While the initial problem domain for Atom was blogs and
posts, the principles can be applied to *any* problem domain, by using
custom content data elements, or a custom namespace, in addition to
the standard elements. In addition, using the standard CRUD
interaction patterns from AtomPub makes your application both easy
understand, and easy to develop. It is instructive to see lots of
publicly available APIs (consider GData) that are taking this path.

In the big picture, figuring out the right URI structures, and
including the right hyperlinks, are "medium sized" steps along the
path to REST. In my experience, REST newcomers tend to have more
problems with the stateless constraint than anything else :-). But
that also turns out to be where some of the biggest benefits
(particularly in scalability) can come from.

> Cheers,
> PS

Craig

[1] http://tools.ietf.org/html/rfc4287
[2] http://tools.ietf.org/html/rfc5023

Peter Svensson

unread,
Nov 25, 2008, 3:23:43 PM11/25/08
to so...@googlegroups.com
You're right, Kris. I think I was working myself up to that conclusion as well, eagerly trying to miss the main point as always.
Havine 'yet another' acronym is a big target in itself, and the main thing is to get the basic ideas across. Using a moderately well accepted acronym as 'attractor' instead would defuse a lot of initial confusion. Agreed.

Cheers,
PS

Peter Svensson

unread,
Nov 25, 2008, 3:31:34 PM11/25/08
to so...@googlegroups.com
Craig, thanks for the very good discussion on urls, et.c. I guess I can manage to use REST principles for everything, in principle. 
In practice, though, I think I'll use rpc for some stuff anyway, but I do agree that it seems that REST would suffice.

I also agree to the hyperlinkedness of resources, and to abstract the same away from the users of the data. Dojo has stores that can manage references in items, both internal, external and circular. A component reading the data, only ask to get the value of property x, and the rest is managed.

I also thought the same when reading the GData spec; It felt like nothing much more was needed, especially the 'checking out' of resources for editing, et.c. Really neat.

Cheers,
PS

Craig McClanahan

unread,
Nov 25, 2008, 10:36:38 PM11/25/08
to so...@googlegroups.com
On Tue, Nov 25, 2008 at 12:31 PM, Peter Svensson <psve...@gmail.com> wrote:
> Craig, thanks for the very good discussion on urls, et.c. I guess I can
> manage to use REST principles for everything, in principle.
> In practice, though, I think I'll use rpc for some stuff anyway, but I do
> agree that it seems that REST would suffice.

You can certainly do that if you choose ... but you'll be back to
skipping the opportunity for RESTafarians to support SOFEA. At best
they'll ignore it. At worst, they'll bash it ... *especially* if you
were to claim to be RESTful but still have non-RESTful
characteristics. You're expected to "walk the walk, not just talk the
talk" if you say you're RESTful :-).

> I also agree to the hyperlinkedness of resources, and to abstract the same
> away from the users of the data. Dojo has stores that can manage references
> in items, both internal, external and circular. A component reading the
> data, only ask to get the value of property x, and the rest is managed.
> I also thought the same when reading the GData spec; It felt like nothing
> much more was needed, especially the 'checking out' of resources for
> editing, et.c. Really neat.

If you run into something where you're puzzled about how to implement
it RESTfully, feel free to send it to this list -- I'll hang around.
But I've got to admit (although I suspect this is no surprise) ...
I've become a RESTafarian myself (hopefully considered a nice one :-),
so my personal interest in SOFEA will remain "oh, cool ideas, too bad
it's useless to me" if its not really RESTful.

BTW, my "day job" at Sun is building the server side of some
"interesting" web services that will become public later, and
designing the RESTful APIs for them. Our team doing the UI work is in
fact using these RESTful interfaces already, achieving the kind of
separation goals you talk about even though the UI implementation
technology still has server side elements to it. But we're going to
get the same sorts of benefits from this separation.

> Cheers,
> PS

Craig

Justin Meyer

unread,
Nov 25, 2008, 11:02:43 PM11/25/08
to SOFEA
I agree that using rest to argue some of points for us is a wise idea.

Correct me if I am wrong, but by 'in practice', I think Peter means in
his actual use, not necessarily how he describes it when presenting
it.

Personally, I think TSA is easy to understand at its core -> client =
UI, server = data.

I have a much harder time describing how to implement it.


On Nov 25, 9:36 pm, "Craig McClanahan" <craig...@gmail.com> wrote:

Peter Svensson

unread,
Nov 26, 2008, 4:39:03 AM11/26/08
to so...@googlegroups.com
Well, yes. Thanks for getting me back to my main point, Justin.

REST might be the only thing needed for C/S communication, but the problem I'm trying to solve is how to describe to people that the most efficient architecture to use when building web apps is one where you separate concerns between client and server, so that the server does not have any client state (and most probably, no state at all).

What Kris say is that by adopting REST as a description of what we're doing (which might be or might become true) we can hitch a ride on an existing movement without paving the road brick by brick all the way.

This is all well and good, but I feel that by reducing the discussion to focus on the protocol, instead of the architectural issues, what might happen is that people think that we're just speaking about REST and don't have time for the small print.

I'm trying to talk about a better way of planting forests, not whether the Birch is the greatest tree. Focus on Birches (great trees!) might lead to great forests, as this is implied in how the Birch works as a tree, but it is still one step removed from the central discussion.

Cheers,
PS

Ganesh and Sashi Prasad

unread,
Nov 26, 2008, 6:32:54 AM11/26/08
to so...@googlegroups.com
Hi,

I've been following this discussion with interest.

One way to approach this would be to first ask the question, "How can
a *rich* client interact with server-side resources?"

We risk muddying the waters if we straightaway begin to talk about
clients built using web technology, because that's the space in which
REST also plays. The line between our view of REST (as a provider of
business logic services to the UI) and the REST folks' view of REST
(as a capable driver of the UI itself) becomes confusing.

So first consider (say) a Win32 VB app built on Windows and managing
all UI components. All data resides on a server-side database. We
would like to interface between this VB client and the server-side
data using a higher-level protocol than ODBC.

If REST is proposed as that protocol, then we in turn position the
SOFEA Data Interchange mechanism as the way the client talks REST.
Application Download and Presentation Flow have already been factored
out of the equation because the application is manually installed on
the client (through MSI) and VB components handle all Presentation
aspects in their native way.

Once we establish this interaction model (and we can show a parallel
model to interface the Win32 app with SOAP services), we can extend
this to an application that is installed onto a virtual platform like
a Java Virtual Machine, i.e., a Java application. Application Download
could be in real-time through Java WebStart. Presentation Flow is
managed natively in Java Swing, analogous to the Win32 case. The
interface with REST and SOAP then remains similar to the Win32 case.

Finally, extend the model to one built using AJAX/Web technology.
First consider a Single Page Application (SPA) that gets downloaded in
real-time (like a Java WebStart app) to a virtual machine (the browser
platform rather than a JVM). Presentation Flow is still managed
internally using JavaScript rather than Java. The interaction model
with REST and SOAP then remains the same as in the previous two cases.

The non-SPA case where plain templates are served up from a Download
Server is a mere extension of this last model.

I think that step-by-step development of the SOFEA model covering
three different technologies is the best way to avoid confusion with
REST's own UI management model.

I don't see the two as contradictory. I just don't see the REST UI
model as being exclusionary to other UI approaches. We need to point
that out by starting with a case where REST clearly doesn't apply
(e.g., a Win32 client app).

Regards,
Ganesh
Reply all
Reply to author
Forward
0 new messages