Peter,
Sorry, didn't see the mail from you until after I added the members. I went back to see how I missed it. The first few words were in Swedish so I must have assumed it was spam and didn't look too closely until your latest mail.
I really don't mind going with either Group. Or do you think we need a Group with a more neutral name?
Ganesh2008/7/23 Peter Svensson <psve...@gmail.com>:
LOL :) Looking right back at you!
Cheers,
PS
Well, never mind, we can go with the SOFEA group, NP.On Tue, Jul 22, 2008 at 10:49 PM, Ganesh and Sashi Prasad <g.c.p...@gmail.com> wrote:
Now where would we go for a Google Group? :-)
Hang on a minute, I'll send you all an invite.
Regards,
Ganesh2008/7/23 Justin Meyer <jus...@jupiterit.com>:Maybe we should move this to a google group?
----- Original Message ----- From: "Mario Valente" <mval...@ruido-visual.pt>
To: "Ganesh and Sashi Prasad" <g.c.p...@gmail.com>
Cc: "Peter Svensson" <psve...@gmail.com>; "Justin Meyer" <jus...@jupiterit.com>; "Mic Cvilic" <michael...@beebole.com>; "Yves Hiernaux" <yves.h...@beebole.com>
Sent: Tuesday, July 22, 2008 10:06 AM
Subject: Re: [The Wisdom of Ganesh] New comment on New Home for SOFEA, Thin Server Architecture.
Mic/Yves, I'm CC:ing you the most relevant/summarized message
on the chat that we've been having on the TSA/SOFEA free for all :-)
I think that you guys might be interested in the discussion and
available for contributions...
-- MV
Ganesh and Sashi Prasad wrote:
Let me refine this slightly with "MUST" and "SHOULD" keywords like they do in standards specifications:
1. Refactoring: Presentation Logic MUST be confined to the client. Business Logic MUST be confined to the server.
=> The client MUST NOT contain any logic other than rendering and (screen)flow logic. The client MUST call services for all business logic.
=> The server side MUST be capable of supporting both visual and non-visual clients.
2. Services: The server SHOULD conform to SOA principles and any of the popular approaches to SOA (SOAP or REST)
3. Clients: The client SHOULD conform to an MVC architecture
4. Client/Server Interface: The interface between the client and the server SHOULD support:
=> rigorously defined data formats
=> rich message exchange patterns (not just request/response)
=> additional qualities of service (security, etc.)
5. Client Deployment: The deployment of the client MUST be through an independent mechanism, i.e., not dependent on the same server that is used to host business logic. (The two capabilities may be co-hosted on the same physical infrastructure but there MUST NOT be any logical dependencies between them.)
I see SOFEA as treating some of the SHOULDs as MUSTs (2 and 4).
Do any of you guys see some of the MUSTs requiring to be diluted to SHOULDs?
Regards,
Ganesh
2008/7/19 Ganesh and Sashi Prasad <g.c.p...@gmail.com <mailto:g.c.p...@gmail.com>>:
Great, then on to the next step!
Naming Architecture X is a parallel activity to defining exactly
what it is.
Here's my initial suggestion on its features:
1. Refactoring: Clean refactoring of business logic out of the
client and into server-side "services" (no need to specify here what
these services should be - SOAP, REST, native, etc. The emphasis is
on refactoring.)
Implications:
=> No business logic will be encoded in the client. The client will
only contain rendering and (screen)flow logic and will call services
for all business logic.
=> The server side will not contain any presentation logic at all.
It will support both visual and non-visual clients.
2. Services: The server should ideally conform to SOA principles and
any of the popular approaches to SOA (SOAP or REST)
3. Clients: The client should ideally conform to an MVC architecture
4. Client/Server Interface: The interface between the client and the
server should ideally support:
=> rigorously defined data formats
=> rich message exchange patterns (not just request/response)
=> additional qualities of service (security, etc.)
5. Client Deployment: The deployment of the client should be through
an independent mechanism, i.e., not dependent on the same server
that is used to host business logic.
Is this generic enough? And does it capture the core principles that
we talked about?
Regards,
Ganesh
2008/7/19 Peter Svensson <psve...@gmail.com
<mailto:psve...@gmail.com>>:
Yes!! Thanks, Ganesh.
Cheers,
PS
On Sat, Jul 19, 2008 at 12:18 PM, Ganesh and Sashi Prasad
<g.c.p...@gmail.com <mailto:g.c.p...@gmail.com>> wrote:
Yes, that makes perfect sense.
So are we talking about something like this?
Architecture X (which we're now looking to name)
|
|------ SOFEA (the rigorous variant, not browser-dependent)
|
|------ A lightweight variant (using JSON, maybe
browser-specific)
|
|------ Other variant
I'd be comfortable with this, personally.
Regards,
Ganesh
2008/7/19 Peter Svensson <psve...@gmail.com
<mailto:psve...@gmail.com>>:
I hear you, Ganesh. I was more thinking of describing
things without having to actually define data formats.
Then we can have specific subsets or variants. Does that
make sense?
Also, I think plain SOFEA (or SOFIA as well) still
sounds OK.
Cheers,
PS
On Sat, Jul 19, 2008 at 12:02 PM, Ganesh and Sashi
Prasad <g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>> wrote:
Peter,
I understand your point and can even empathise with
your CTO's viewpoint :-). I know there's quite a bit
of pressure to just use JSON instead of XML because
it's far simpler. Even within our (SOFEA authors)
group, there was a fair amount of debate about the
JSON-or-XML issue. Ultimately, we saw it as a
strength of the architecture to make the
Presentation and Business Logic tiers uniform in
terms of data integrity (the same XML document
payload can pass through unchanged if the designer
wants it that way), and we felt that JSON would
dilute that integrity at the front-end. We even put
in a table of features to explain why we weren't
recommending JSON.
If we're now going to propose an architecture that
includes JSON, then I suggest we maintain a
distinction similar to "High REST" (GET, PUT, POST,
DELETE) and "Low REST" (only GET and POST). The
"High" version of the architecture will involve more
effort but will also be more rigorous in terms of
data integrity and seamless in its integration with
services. The "Low" version will be easier to get
started with but offer lower guarantees in the above
areas. I would go so far as to warn that it will be
no more "service -oriented" than any other MVC-based
client architecture used today. It would probably be
similar to a Swing/Java Web Start app. You can
cleanly refactor the Presentation and Business Logic
tiers only if they have a common interface, and I
don't see any escape from XML there because nothing
else can enforce a contract as rigorously.
So are we looking at SOFEA/LFEA (Service-Oriented
vs. Lightweight) or something similar?
BTW, I don't think we had ever restricted ourselves
to supporting browsers. We were always open to both
thin and rich clients, is that correct? I know SOFEA
certainly doesn't impose that restriction.
Regards,
Ganesh
2008/7/19 Peter Svensson <psve...@gmail.com
<mailto:psve...@gmail.com>>:
That could work as well. Nice to get a
geographical parallel as well.
My only remaining gripe with SOFEA as it is
(Sorry Ganesh :) is that it is a bit too
specific. When I presented the paper to our
acting CTO as what I'd like to do, he
immediately said that he wanted to use JSON
instead of XML.
I think that SOFEA is perfect to describe
enterprise solutions with lots of existing
services, but for a startup with a clear
web-based front-end with no prior code or
service, the choice of encoding as actually
quite arbitrary.
So one thing we might toy with (if possible) is
to try to generalize the ideas a little bit so
to not be dependent on browser as front end or
XML as data format.
How does that sound??
Cheers,
PS
On Sat, Jul 19, 2008 at 1:06 AM, Mario Valente
<mval...@ruido-visual.pt
<mailto:mval...@ruido-visual.pt>> wrote:
I really like the SOFEA acronym, except for
the fact that its
too frontend-oriented/loaded. I really
believe that the separation
of concerns issue goes beyond the MV in MVC
(which is the focus of
SOFEA) and that the separation at the VC
level is also quite
important.
SOFIA? As in "Service Oriented F* Interface
Architecture"? Feel
free to choose your F word :-). For example
"Service Oriented
Framework for Interfacing Architecture"....
Sofia is of course a city at the interface
between East and
West. Its also a portuguese (and others)
girls name. And its
greek roots stand for knowledge and wisdom.
-- MV
Ganesh and Sashi Prasad wrote:
It should also sound glamorous. As Bruno
Vernay pointed out, AJAX has that
certain something. There's a zip in the
name. To catch on as a term, people need
to be proud of saying, "We've used the
<?> architecture."
Now I'm not saying this because I made
it up, but SOFEA has a bit of that. It
gives a tech concept some exotic
glamorous mystique similar to aircraft
nose art
<http://images.google.com/images?aq=f&um=1&complete=1&hl=en&safe=off&q=aircraft+nose+art&btnG=Search+Images
<http://images.google.com/images?aq=f&um=1&complete=1&hl=en&safe=off&q=aircraft+nose+art&btnG=Search+Images>>,
just not as sexist. I thought of
calling it SOPTA (Service-Oriented
Presentation Tier Architecture), which
is precisely what it is, but the name
sounded awful to me. I has also toyed
with SOFA (where I treated Front-end as
a single word rather than Front-End),
but thought SOFEA sounded better in the end.
I think we should treat SOFEA as the
baseline, and try to think of something
better, both in terms of descriptiveness
and in punch. We're in the realm of
marketing, after all. That's why we
included a logo
<http://groups.google.com/group/sofea/web/sofea-logo-256x256.png>
and explained its significance at the
end of our paper. I know we're geeks and
we don't do that sort of thing very
well, but maybe our SOs could help here ;-)?
As another thought, it doesn't have to
be an acronym. By way of example,
"Portal" and "Mashup" are pretty popular
terms for certain types of UIs. "Portal"
was a pretty loose term until 2003, when
JSR 168 defined the Portlet API
formally. "Mashup" is still a loose term
and every vendor and developer uses it
to mean what they want. We're providing
both the term and its definition. I know
these sound awful, but a non-acronymic
term like "Tight Client", "Compact
Client", "Servee", etc., may be equally
valid.
And finally, the semi-acronyms: e.g.,
ViSCo (Visual Service Consumer) - ugh!
REST has legitimised this (It should
have been RST).
Get those creative juices flowing!
Regards,
Ganesh
2008/7/19 Peter Svensson
<psve...@gmail.com
<mailto:psve...@gmail.com>
<mailto:psve...@gmail.com
<mailto:psve...@gmail.com>>>:
I like the Soya beans :) Maybe beans
are too Java centric, fo
course, but why not?
Cheers,
PS
On Fri, Jul 18, 2008 at 5:06 PM,
Mario Valente
<mval...@ruido-visual.pt
<mailto:mval...@ruido-visual.pt>
<mailto:mval...@ruido-visual.pt
<mailto:mval...@ruido-visual.pt>>> wrote:
SOIA? Service Oriented
Interface Architecture.
With a double double entendre:
1) the I in Interface relates
(or can relate) to both the
frontend/businesslogic interface and
to the businesslogic/datalayer
interface; 2) the SOIA acronym is
a play on SOA and on soya/soja
beans as opposed to coffee/java
beans (as in EJB) ;-)
-- MV
Peter Svensson wrote:
Hmm. I agree. TSA focus on
the server (but talks about the
client all the time) and
SOFEA focus on the client :) The
problem is, I think that many
generic terms (like SOA) are
already abducted. I often use
the term "Separation of
Concerns", which is used in
various other contexts but also
very generic.
People would probably blow a
fuse if we try to use the term
SOA as well :) But who knows.
Maybe Service Oriented Web
Application Architecture? SOWAA ?
That's related to SOFEA, but
tells almost nothing about what
it's about, which could be
good or bad. Or permutations
along those lines.
We can bounce it back and
forth a bit and see what we can
come up with.
I CC the rest of the guys to
see if anyone can weigh in.
Cheers,
PS
On Fri, Jul 18, 2008 at 4:23
PM, Ganesh and Sashi Prasad
<g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>
<mailto:g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>>
<mailto:g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>
<mailto:g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>>>>
wrote:
Peter,
Good to hear that you're
applying these principles in
real-life.
Vikrant is doing the same
at his new employer. Fortunately or
unfortunately, being an
architect at a large bank means I
don't get
to be hands-on at all :-(.
I just play with code samples
on my home
computer in my spare time,
not real applications.
Do you have any ideas for
a good name? I think what we're
doing has
significance beyond making
the server thin, so maybe TSA
doesn't do
justice to the
architecture. I'm not saying SOFEA or
SOUI is
necessarily the best name
either. We should find a term
that is
broad enough, yet
describes it perfectly. If SOA (the
term) turns
out to be a fad, then
hitching the name of this
architecture to that
term may affect it
negatively. Yet the overall impact of the
architecture is about
making the presentation tier a
cleaner client
by factoring out business
logic into services. Tradeoffs,
tradeoffs.
Regards,
Ganesh
2008/7/16 Peter Svensson
<psve...@gmail.com
<mailto:psve...@gmail.com>
<mailto:psve...@gmail.com
<mailto:psve...@gmail.com>>
<mailto:psve...@gmail.com
<mailto:psve...@gmail.com>
<mailto:psve...@gmail.com
<mailto:psve...@gmail.com>>>>:
That's so true!
I've felt so bad
slapping together the site like
that, and not
updating it propely. I
am glad, though that we
managed to get
the article up and
that it got seen. However, we
should consider
a good name, absolutely.
On the up site, I have
managed to be selected
front-end lead on
a new 'stealth'
start-up, where I've managed to separate
concerns and refered a
lot to your articles and my
ramblings :) It has
been well accepted, even though
we're using JSON instead
of XML, butotherwise OK.
Hope you are well. I'm
in the middle of a Swedish
'long-lunch'
and a acouple of
schnapses, so I hope I'm readable.
Thansk fo reverything
in any case, and now we move
forward.
Cheers!
PS
On Wed, Jul 16, 2008
at 1:25 PM, Ganesh and Sashi Prasad
<g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>
<mailto:g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>>
<mailto:g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>
<mailto:g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>>>>
wrote:
A friendly
suggestion from a well-wisher (below) :-)
----------
Forwarded message ----------
From: *Bruno
Vernay* <noreply...@blogger.com
<mailto:noreply...@blogger.com>
<mailto:noreply...@blogger.com
<mailto:noreply...@blogger.com>>
<mailto:noreply...@blogger.com
<mailto:noreply...@blogger.com>
<mailto:noreply...@blogger.com
<mailto:noreply...@blogger.com>>>>
Date: 2008/7/16
Subject: [The
Wisdom of Ganesh] New comment on
New Home for
SOFEA, Thin Server
Architecture.
To:
g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>
<mailto:g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>>
<mailto:g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>
<mailto:g.c.p...@gmail.com
<mailto:g.c.p...@gmail.com>>>
Bruno Vernay
<http://www.blogger.com/profile/14452464782395869356>
has
left a new comment
on your post "New Home for
SOFEA, Thin
Server Architecture
<http://wisdomofganesh.blogspot.com/2008/03/new-home-for-sofea-thin-server.html>":
Should put your blog :
http://wisdomofganesh.blogspot.com/search/label/SOFEA
and the infoQ article
(http://www.infoq.com/articles/rationalizing-presentation-tier)
in the article
section, no ?
And most important
: choose a name : either
SOFEA, SOUI or
TSA. Remember what
happened with "AJAX".
Posted by Bruno
Vernay to The Wisdom of Ganesh
<http://wisdomofganesh.blogspot.com/> at
16/7/08
03:43