Update When i wrote this post i was pretty skeptical about SOFEA/SOUI, but having build some apps using jquery and grails rest services, i am now convinced that this is a very useful and productive architecture for a lot of applications. Implementing the complete client side using javascript in the browser, communicating with services in SOA containers turns out to be very simple and productive. But i think we need a more appealing name for this architecture. Client Server 2.0 seems to be the most appropriate, although it might not be the most sexy name. Read my follow-up post Client Server 2.0 why i think this name best describes the next step in UI design.
Original post
Last week at the OSCON matt raible did a presentation on Web Frameworks of the Future: Flex, GWT, Grails and Rails. One of the topics in his presentation is service based user interfaces, also known as SOFEA (Service oriented frontend architecture) or SOUI (service oriented user interface).
Core to these architectures is a separation between service layer, and the UI layer. You can run your service layer on a (java) application server, and the UI layer completely in the browser, either using a AJAX or some sort of plugin (FLEX, etc). Communication between the layers can be based on SOAP, XML, JSON, or something similar.
We’ve used a similar architecture on a couple of projects in the past: all services were implemented using webservices, and these webservices were called from the user interface layer. The only difference is that we implemented the user interface using JSF technology. But the goal was the same as with SOFEA/SOUI: create a layer of generic, reusable services, not tied to a particular application.
This goal is good if you achieve it, but it’s not easy to achieve. We ran into some problems:
- lousy productivity – when there’s nothing to reuse, and you have to implement all the services required, productivity is pretty bad. Mostly because there’s just more technology between user interface and database then when you just use jsf+spring+hibernate.
- hard to change – we found the applications hard to change: when you want to add some fields to a form there’s more layers to modify, with less tool support to do it. If you’re just working with java, refactoring is easy, but when you have to deal with soap, xml, xml-schema and even esb and bpel, making one simple change has a lot more impact.
- complex, hard to learn – you have more layers, more technology, so it’s harder to understand and work with. It takes more time to get new developers up to speed, and it’s harder to find cross-functional developers who can implements your requirements from user interface to database, so you need more developers, and more communication.
- hard to design generic services – designing reusable generic services is hard. You have to try to anticipate future use. But often this goes against performance. To achieve good performance we’ve had to put less information into the xml files returned by the services. In the end, often this meant application specific web services, only returning the data required by the user interface. Not very generic, not reusable, so mainly a waste of time and performance to use web services.
- bad performance – lots of unnecessary data translations, from database to java to xml to java to xml to java to html, or even worse depending on the number of esb and bpel processes used.
The funny thing is that recently we did a project the old, conservative, way, using spring framework, hibernate, and jsf, and a lot of the developers like it a lot better. Development is fun again: you can implement user requirements very fast, developers can work on their own features from top to bottom. This also makes project management a lot easier, a simpler critical path. And productivity is a lot better too.
July 28th, 2008 at 19:38:09
I was thinking about the same today. And I too agree that this kind of architecture cannot go long way, except adding “unnecessary comlexity” to the entire application. The company that i work in has the same kind of framework. A Java based MVC framework, purely to build UI, which calls the the backend RFC to get the data. Believe me with all the tools, I feel it’s just unwanted complexity.
But it would be interesting if there could be some use case for such kind of architecture !
July 29th, 2008 at 08:32:18
Looks nice, but i’m not aware of any tooling that would allow me to visually create such a ui, all the way from top to bottom, ie., from single page web app to services, to database.
July 30th, 2008 at 07:34:04
In my experience there are a lot of companies that prefer average applications, build (mostly generated) by average developers. Or maybe it’s better to say: the reality is that most developers are quite average, and can only manage to push some buttons in a case or 4gl tool. These are the developers companies have to work with, so they need tools that can generate everything from ui to db.
July 30th, 2008 at 07:35:52
Regarding soui tooling: i find the combination of grails and the gwt plugin quite interesting, but i haven’t tried it yet.
July 31st, 2008 at 07:02:47
Hi Priya & Andrej, I worked on a full SOFEA commercial app.
The “unnecessary complexity” you mentioned is hidden by the development tools.
(There was a post here previously that provided a link to a website that describes the SOFEA development we use.)
In terms of the complexity/ development tools:
For us, the requirements are first specified in UML, which is then used to auto-generate approx 90% of the code and plumbing including 100% of the WebServices/ Hibernate or EJB/ Spring layer/ Server side validation/ Client side Javascript validation/ Client side Javascript business libraries/ ACEGI security.
Then its Just a matter of filling in the business logic and using our preferred HTML tools for the “Stateful” HTML/ JavaScript front end. Changes to the requirements/ UML are then automatically propagated through to the various back end and front end layers, without overwriting any hand written code, thus providing an Agile development process.
Our SOFEA framework is true SOFEA in that it uses server side web-services (or REST XML) and a rich “Statefull” HTML client. Aside from delivering the initial HTML pages, the server doesn’t know about any presentation or use any JSPs and doesn’t know about/ care about/ or maintain any client state.
From my experience with traditional MVC J2EE web development compared to my experience with SOFEA development, SOFEA apps deliver reduced time/ cost to market, more easily prototyped/ developed and reduced ongoing maintenance cost.
However, for us, the real value SOFEA delivers is the increased front end richness.
So perhaps dont give up just yet on SOFEA, I’ve been pleasantly suprised at how much more I enjoy working on a SOFEA /MDA architecture.
July 31st, 2008 at 08:56:46
Sounds like an interesting development tool, what are you using?
July 31st, 2008 at 09:22:06
Believe me, I’m not against such kind of architechture, but I needed a use case, where this sort of architechture would be more useful than traditional MVC. There are several tools coming up in this direction, Tibco GI is one of them. And this is one of the fundamental benefits of SOA, you can plug services in your app at the highest level.
But still I’m not fully convinced that for large, complex application, this architechture will not become too cumbersome and complex. To change something on UI, you will have to find and figure out where it’s coming from in the backend and all the way down. Until and unless I have tools like Daz
August 4th, 2008 at 10:01:43
“To change something on UI, you will have to find and figure out where it’s coming from in the backend and all the way down.”
Not sure how you arrive at that conclusion. When using e.g. a JSON/REST backend with templates that are rendered in the browser by Javascript, the only thing you need to change is the template and perhaps the JS handler. Mostly no need in the backend/server code, compared to the traditional way, where you need to adapt the server (e.g. one or more of JSP, Servlets, Actions, Validation, JSF, Templates)
Peace
-stephan
August 4th, 2008 at 10:39:26
Yes, if the backend has the data you need, but if you want to add a complete new field/column it’s quite a lot of work: Change db, change orm, change service, change client proxy, change ui… And maybe some messaging, esb, bpel stuff…
And if the service needed is used by multiple users, and owned by someone else you have a lot more problems: testing all the other programs using the service, getting the owner to extend the service, aligning all the deadlines, discussing who will pay for what, etc, etc.
August 5th, 2008 at 14:39:43
That’s exactly my point. Thanks Andrej. When you have added a SOUI layer and you want to add an additional field in the UI, change a business logic ( and later on find out to your frustration ) that developer coded half of business logic in client side framework ( SOUI or SOFEA ) and some on the server side, things just become difficult. Testing will become a nightmare, because your UI and Business logic is so de-coupled. I think we should always go for simplicity, rather than some fancy architechture…
August 8th, 2008 at 16:44:23
But still I’m not fully convinced that for large, complex application, this architechture will not become too cumbersome and complex.
In my experience, “large, complex applications” are an inefficient way to develop applications. All of the large code-bases I know are trying to split themselves into smaller projects that interoperate with each other.
August 17th, 2008 at 17:22:59
Priya Ranjan said:
> When you have added a SOUI layer and you want to add an additional field in the UI, change a business logic ( and later on find out to your frustration ) that developer coded half of business logic in client side framework ( SOUI or SOFEA ) and some on the server side, things just become difficult.
You’re describing a design that violates SOFEA principles. Business logic should not be coded into the client-side framework. Business logic should be exposed as _services_ (SOAP or REST). Only presentation logic (screen flow) should be in the presentation tier. Certainly, if your application is built in the manner that you describe, testing and maintenance become harder. But it’s hardly fair to blame SOFEA for that.
Regards,
Ganesh