SOFEA definitions and principles

[Peter Svensson]

Hi Ganesh, All.

Preparing for my talk I've started to go over my old slides and the original SOFEA specification to get organized.
And I felt still that I had to separate my own generic thins server architecture a bit from SOFEA, as stated in the paper, since I don't really want to emphasize choice of data encoding (hint: XML :) at that level of abstraction.

But then I (which I should have done the first time, I suppose) checked all of our old emails on the subjects, and it seems that we're pretty agreed on that the basic principle of SOFEA should be that presentation logic be kept outside the server, and that further specializations might specify further constraints for various reasons or contexts. Is that OK?

In that case, I'll just call everything SOFEA :) And the list gets vary manageable.

Cheers,
PS

[Ganesh and Sashi Prasad]

> In that case, I'll just call everything SOFEA :)

Uh, actually Peter, I'd rather we didn't dilute the SOFEA concept by using it as the abstract superclass. One of the core principles we were trying to ensure with the original SOFEA concept was data integrity. If we dilute the data integrity principle, we lose something pretty major.

By all means, retain the thin server architecture as distinct from SOFEA. I wouldn't want to force XML on all similar models. JSON is definitely a valid approach for certain types of systems. But we should retain both models as distinct variants of a more generic one.

Why don't we seriously look at this earlier idea?

Architecture X (the generic model)
  |
  |------ SOFEA (the rigorous variant, not browser-dependent)
  |
  |------ A lightweight variant (using JSON, maybe browser-specific)
  |
  |------ Other variant


Since we need some names, the superclass (Architecture X) could be called Uniform Resource-Based Interface Architecture (URBIA), based on the Latin "urbis" for city. That's the abstract superclass. (We could consider other backronyms as well, if you don't like this one :-).

The rigorous subclass of URBIS would be SOFEA.
The not-so-rigorous subclass could be called LiMA (Lightweight MVC-based Architecture).

In other words, specific examples of Urbia (generic city) are actual cities Sofia and Lima.

No?

Ganesh

2008/10/3 Peter Svensson <psve...@gmail.com>

[Ganesh and Sashi Prasad]

BTW, I blogged about the latest diagram we discussed yesterday.

Ganesh

[Peter Svensson]

Yes I saw, and I think it's good to put SOFEA in a workflow context like that. The pircutre is still too big for me to include in a presentation, though.

I had kind of hoped to just call the supertype 'thin server architecture' :) But actually it would be better with a name / acronym that declares the separation of concerns between view/client and the rest of the system.  Maybe

Properly Separated View (PSV)
Separation Of Concerns (SOC)
No UI on Server (NUIOS)
 or what have you.

As an aside, since Kris et, al. has done excellent work with the JSON-Schema, the approaches are getting nearer each other in usability

Cheers,
PS

[Justin Meyer]

Warning: as the author doesn't really know anything, ignore this email completely ....

I have a very strong opinion that we are wasting our time with all this Phd style bather.  We aren't trying to fill up a dissertation paper, we are trying to change how people develop applications.  Though important to provide specifics, I don't think we are giving the right kind of specifics. 

We should be driving home a single core concept.  To me this concept is ONLY services on the back end.  Everything else falls from that.  If you ONLY have services on the back end, you have to create views and manage how the user coordinates those services on the client.  We are essentially SOA, but making sure that there are JUST services on the server.

Narrowing the spec down further is an exercise in pointlessness.  This is because it hurts the message and hurts the developer.

The best example of this problem is the XML vs JSON debate.  Here's why it is pointless:

• Superfluous specifications take away from the impact of the most important point.  If someone has to learn about XML, it simply takes away from the core message.
  
• Superfluous specifications provide diminishing returns.  For example, is only XML going to really provide more utility than the core idea, especially since every language can deal with both?  If you are TSA and that adds 100 value points, what does XML only?  Maybe 5?  If we aren't making things significantly better for the developer, drop them.
  
• Developers do not care about this level of detail.  They want to get their job done and move on.
• Specifics can change.  It's how people perceive a name that eventually matters.  The best and extremely relevant point is AJAX used to mean XML but now means interactive websites.
  

Therefore, I recommend we forgo all this naming business for the time being.  We should standardize on Thin Server Architecture.  And instead of refining specifics of the specification, we should be giving specifics on how to develop these applications. 

--
Justin Meyer

Jupiter IT Solutions
847-924-6039
justin...@gmail.com
AOL: jusbarmey

[Peter Svensson]

Justin, I hear you. I'm all for simplicity as well.
I think that we're essentially agreed on the basics. The core issue is just what you described, and I also agree with that fragmentation in sub-issues can make the central point getting lost in noise.

This is about communication, and as long as we are united in our core message, we can continue to refine more detailed specifications and see which are msot usable to which scenarios.

My problem is that I have to finish my slides in a couple of days, and I have to decide how to present the core issue (and what to call it) to people who might not be up to speed on the issue (Palinesque?). The title of my talk is "Practical thin server architecture with Dojo", so I'll probably use that term.

However, since Ganesh (and collaborators) have done so much in defining the issue from a particular constraint, and very well done too, I felt obliged to have that in my talk as well. The reason I began mailing today was to get an idea of whether to separate the ideas or present them as separate. :) Also, perhaps it's simpler for the case of the talk to stick to the basics only, and leave delineations and classifications for a later talk when people are up to speed.

Cheers,
PS

[Ganesh and Sashi Prasad]

Justin,

If Peter and you are comfortable with the name TSA, please go ahead and call it that. I'm very uncomfortable with the idea of diluting the term SOFEA to include JSON. There are very good reasons why we specified XML in the SOFEA paper, and I don't believe it's a pointless debate. But I recognise that you have stuff to deliver, so don't let me hold you back.

Ganesh

2008/10/4 Justin Meyer <justin...@gmail.com>

[Justin Meyer]

Ha ... ok.  I hope that I was coming off as being bold for impact.  Maybe I went to too many Douglas Crockford sessions at the Ajaxian Conference. 

I think in the context of why you were debating XML, it was not pointless at all.  I'm just absolutely focused on getting the main idea out to as many people as possible.

After talking with a local IT department for a large construction company last week, we have our work cut out for us.  They were just trying this 'Java' thing after being on AS400's for years.  They looked at me like I was an alien when I brought up Ajax. 

I'm trying to figure out how I can have those departments skip a few of the ugly steps between web 1.0 development to TSA development.

Justin

[Peter Svensson]

Thanks for all input. I think I will use TSA, but I will also mark that it is not an original idea and make sure to refer to SOFEA.

Cheers,
PS

[Kris Zyp]

I don't know if it is of any help or interest, but here is my presentation from the TAE and the rich web experience:

http://www.slideshare.net/kriszyp/jsonbased-service-oriented-architecture-for-the-web-presentation

Kris