SOFEA: Also known as SOUI
InfoQ asks Does the rise of Service Oriented UI (SOUI) means the death of server-assisted MVC? A similar thread was started on JavaLobby last week: Web frameworks peaking toward obsolescence. A month ago, TSS posted a whitepaper titled Life above the Service Tier.
As far as I can tell, Nolan Wright and Jeff Haynie haven't read the Life above the Service Tier article - where the very same architecture is called SOFEA. Nolan and Jeff are calling it SOUI. Is there a difference that you can see? I don't think there is. However, I do think there's a better acronym out there that could spark more interest in this type of architecture. After all, isn't the tipping point often triggered by good timing and clever marketing?
As I mentioned previously, I really like the ideas behind SOFEA/SOUI. However, I don't think it will replace the existing frameworks we use to develop web applications. Those have been very successful and will continue to be. The internet is growing - there's lots of room for new applications developed with new architectures. As long as this new architecture is scalable and maintainable, I can't think of a good reason why it won't succeed.
You're right. I had not read the TSS post - just did. I think we are promoting similar ideas. We have built a client/server, message-oriented platform. It enables HTML elements to generate and receive messages and to take action based on these messages. These same messages can be used to make service requests to services written in Java, Ruby, or PHP.
Our goal was to greatly simplify the use of Ajax and DHTML in clients and to break the standard coupling of the client and the server found in MVC-based web frameworks.
For us, an Ajax request is as simple as adding the following to an HTML button:
on="click then r:login.request".
This simple expression results in a remote service request via Ajax.
You can use the same simple expression language to control the user interface. For example, if I wanted to hide/show a DIV based on two different messages, I could add the following to the DIV:
on="r:login.request then show or r:login.response then hide"
These are just some trivial examples, but they do demostrate how we enable you to leverage Ajax and DHTML without having to write Javascript. They also demonstrate the ideas behind SOUI - i.e., HTML elements that can consume services and are only coupled to these services by a message-based contract.
The latter is very powerful because it has enabled us to build a services platform that supports services written in multiple programming languages. Since the only thing that binds the client to a service is a message contract, the underlying programming language no longer matters. This also greatly simplifies service development since you no longer need presentation logic in your service code. The service only needs to implement the message contract.
Anyway, I just wanted to shed some light on some of the specifics behind our thinking and our writing.
BTW, I completely agree with your comment on good timing and clever marketing.
Posted by Nolan Wright on November 12, 2007 at 08:35 PM MST #
Posted by kkus on November 13, 2007 at 09:59 AM MST #
Flex is event driven but it does require a fair amount of code to implement event logic. It also requires Flash and it requires you to learn MXML and Action Script. The other problem with Flex is that it does not have a fully integrated services platform. They have some stuff for Java but that's about it.
Our approach is different in that we message-enable standard HTML elements. It's also far less verbose than Flex. We can accomplish the same things as Flex using far less code plus we do have a fully integrated services platform for doing service development in Ruby, Java, PHP and soon .NET and Python. In all fairness, we do require that you learn an expression language to implement messaging but it's certainly as easy if not easier than learning Aciton Script. For example: on="r:login.response[success=true] then hide else show". This expression can be added to any HTML element. It basically says "when I receive a message named "r:login.response" with the data value "success=true" then hide the element, otherwise show it. Overall, I think Flex is a good solution but I think it does fall short in the areas I mentioned above.Posted by Nolan Wright on November 13, 2007 at 12:12 PM MST #
Thanks for bringing SOUI to our notice. We hadn't heard of Appcelerator either (which seems to be a pretty solid piece of work, by the way).
You asked if there were any differences between SOFEA and SOUI. I can see one, and it is in the choice of Data Interchange format. SOFEA strongly recommends XML. SOUI doesn't seem particular (indeed, since the SOUI authors' creation Appcelerator uses JSON, one would think SOUI prefers JSON to XML).
SOFEA emphasises the use of XML for Data Interchange because one of its guiding principles is to mesh seamlessly with the service tier. Services may be built using either the REST paradigm or the SOAP messaging paradigm, but XML plays a big role in either one. SOAP requires, and REST recommends, the use of XML for Data Interchange. XML's characteristic of being able to enforce data integrity (i.e., conformance to specified data structures, data types and data constraints) is essential to many applications, which is why we make a big deal about XML support in SOFEA. We considered but rejected JSON because it's only slightly better than raw HTML-over-HTTP in these respects.
I guess Nolan and Jeff have made a valid architectural choice favouring ease-of-use over data integrity, but better XML tooling may blunt that advantage in future.
I've also blogged about this.
Regards,
Ganesh
Posted by Ganesh Prasad on November 13, 2007 at 05:30 PM MST #
Well, of course they're not as the title of my article used the phrase peaking toward.
I don't expect server-side web frameworks to become dead. Instead I prefer the term "zombie". For instance, COBOL is not a dead language, but it is pretty much a zombie language.
Perhaps Lotus123 or VisaCalc are truly dead as I have not heard of anyone in recent times that still use these.
A zombie IT technology, though, remains very much in use - being propelled by legacy circumstances.
A technology is in zombie status when no green field project would consider using the technology in question.
So in a few years I think server-side web frameworks, where the MVC pattern is implemented on the server-side, will reach zombie status.
RIA web app clients + SOA middle-tiers are that much better in terms of over-all architectural approach that they will gain more and more traction.
I don't have to prod my developer staff into that belief, they come to that conclusion on their own once they've spent some time doing Flex app development - in the RIA + SOA manner that my shop does it.
Posted by Roger Voss on November 15, 2007 at 04:59 PM MST #
Posted by Claudio on November 19, 2007 at 08:10 AM MST #
Posted by claudio on November 20, 2007 at 02:26 AM MST #
Posted by claudio on November 21, 2007 at 06:04 AM MST #
Posted by claudio on November 27, 2007 at 09:43 AM MST #
Posted by claudio on December 06, 2007 at 09:14 AM MST #
Posted by 82.48.126.132 on December 09, 2007 at 09:09 AM MST #
Posted by Andrej on September 05, 2008 at 08:31 AM MDT #
Posted by Michael on October 15, 2008 at 09:39 AM MDT #
My question: what about security in SOFEA?
I mean, XML/JSON Restful services are exposed via-network, maybe Internet.
When something, like an Ajax Dojo UI, makes a request to them, how can I be sure of its identity?
I mean, if I was always in a WebApplication, I would manage security in the right way but what if I will develop another app, e.g. mobile =), which use those services directly? What's the right way to embed authentication informations in a request made by ajax to rest services?
Thanks for your help and ideas!
FB
Posted by Fabio Bozzo on December 02, 2009 at 02:20 AM MST #
Posted by andrej on December 02, 2009 at 02:31 AM MST #