Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

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.

Posted in Java at Nov 12 2007, 10:36:41 AM MST 15 Comments

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 13, 2007 at 02:35 AM MST #

I think this message-driven, event-based service has already been achieved in Flex. Flex's actionScript with aid of mxml is doing what SOFEA is trying. For example, if there is a change in db and a service in midder tier has been implemented to retrieve it, this change will be automatically updated in UI without refreshing from UI since there is a message contract between UI and midder tier.

Posted by kkus on November 13, 2007 at 03:59 PM 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 06: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.


Posted by Ganesh Prasad on November 13, 2007 at 11:30 PM MST #

In discussion over my JavaLobby article that you link to, defenders of server-side web frameworks (where MVC is implemented on the server-side) said that these were in no way dead or showing signs that they were becoming dead technologies.

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 10:59 PM MST #

Hello! I've started a thread on the Ext forum...because I think that we need a js framework which goes in the SOFEA direction

Posted by Claudio on November 19, 2007 at 02:10 PM MST #

and also on jQuery ml:

Posted by claudio on November 20, 2007 at 08:26 AM MST #

no one seems to care....150 views, no replies... :-|

Posted by claudio on November 21, 2007 at 12:04 PM MST #

interesting reply by Chris

Posted by claudio on November 27, 2007 at 03:43 PM MST #

check this out:

Posted by claudio on December 06, 2007 at 03:14 PM MST #

a javascript soap client:

Posted by on December 09, 2007 at 03:09 PM MST #

Instead of a better acronym for SOFEA/SOUI, what about a better name: Client Server 2.0? We're basically moving from server generated user interfaces to browser (javascript or flex) generated user interfaces. We're back to the client server model, the client running completely in the browser, and the application server just hosting data and business logic services. The main purpose of an application server will be to act as SOA/WOA container.

Posted by Andrej on September 05, 2008 at 02:31 PM MDT #

This explains how to do CRUD on the Java Content Repository using Sling & jQuery. Cool stuff:

Posted by Michael on October 15, 2008 at 03:39 PM 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!

Posted by Fabio Bozzo on December 02, 2009 at 08:20 AM MST #

Ajax uses HTTP to communicate with a rest service, this means you can use http security.

Posted by andrej on December 02, 2009 at 08:31 AM MST #

Post a Comment:
  • HTML Syntax: Allowed