Life above the Service Tier

Home

News: Life above the Service Tier

  1. Life above the Service Tier (39 messages)

    How do we design and build the Presentation Tier of an application in an increasingly service-oriented world? We (Ganesh Prasad, Rajat Taneja and Vikrant Todankar) believe there is a definite answer, although it is not a particular technology but rather an Architectural Style. We call this style SOFEA, for Service-Oriented Front-End Architecture. The principles of SOFEA are: 0.Decouple the three orthogonal Presentation Tier processes of Application Download, Presentation Flow and Data Interchange. This is the foundational principle of SOFEA. (Interestingly, the most common Presentation Tier technology, i.e., traditional web technology or “Web 1.0”, fails this principle.) 1.Explore various Application Download options to exploit usefully contrary trade-offs around client footprint, startup time, offline capability and a number of security-related parameters. (The key differences between “thin” and “rich” clients lie in these trade-offs, and therefore SOFEA is a metamodel for both types of applications.) 2.Presentation Flow must be driven by a client-side component and never by a server-side component. Client state must be managed within the client. (We show that the Front Controller “pattern” represented by all server-side web frameworks is in fact an anti-pattern, which is why there are so many variants of it and why none of them satisfies.) 3.Data Interchange between the Presentation Tier and the Service Tier must not become the weakest link in the end-to-end application chain of data integrity. The Presentation Tier must support equally rich data structures, data types and data constraints. (In this regard, the inherent weakness of “Web 1.0” makes it hard to integrate with the Service Tier. We recommend the use of XML as the common data denominator for the two tiers). Ideally also, the Data Interchange pattern between the two tiers should follow the peer-to-peer model rather than the client/server model to enable more natural event notification. 4.Model-View-Controller (MVC) is a good pattern to use to build the Presentation Tier. (This is not to be confused with Front Controller, which is an anti-pattern.) The MVC Controller is the key front-end component which manages client state and drives both Presentation Flow and Data Interchange processes. There are many Presentation Tier technologies available to developers today, including some that were very recently announced. While all of them inherently allow wide latitude in the way they are used, we believe that adherence to SOFEA principles will ease their integration into an increasingly SOA-oriented enterprise infrastructure. Our paper can be found here, and a brief presentation on it can be downloaded from here. My blog entry on this is here. We would be very interested in community feedback. Ganesh Prasad

    Threaded Messages (39)

  2. Front Controller anti-pattern?[ Go to top ]

    "This is not to be confused with Front Controller, which is an anti-pattern." When did Front Controller become an anti-pattern?
  3. I guess you took time to comment, but not the time to read the article: "Web frameworks are based on the Front Controller anti­pattern (which looks like a pattern only when compared with raw HTML­-over-HTTP). Front Controller does not help in decoupling Presentation Flow from Data Interchange, and is therefore part of the problem. If we keep developing newer and “better” variants of an anti­pattern, is there any wonder none of them will satisfy? The correct approach is to repudiate this anti­pattern altogether. The historical reason for its invention no longer exists to justify its continued use."
  4. your blog entry is the single most important article i have read this year. thank you for formalizing it. this is *great* !!!!!
  5. thought provocative[ Go to top ]

    very interesting thoughts are brought up during this read.. but in general for JEE is it possible that adding more layers and over architecture of the presentation tier, is what holds java back from being a great web development language. Look at rails framework, and PHP. Convention over configuration is a great thing. I can imagine, if implemented correctly the ideas brought up would be excellent, but still heavyweight.
  6. Re: Life above the Service Tier[ Go to top ]

    Great article. Very thoughtful. I need read one more time to digest. Thank you for posting this. Chester
  7. We stipulate that a SOFEA-conforming application will support both SOAP and REST-based Data Interchange through XML documents.
    Application container specific RPC styles such as JSON RPC is a reality today due to performance reasons and can be directly used as client model. Why restrict to XML?
  8. We stipulate that a SOFEA-conforming application will support both SOAP and REST-based Data Interchange through XML documents.
    Application container specific RPC styles such as JSON RPC is a reality today due to performance reasons and can be directly used as client model. Why restrict to XML?
  9. It is only XML that can comprehensively enforce data integrity. Besides, the Service Tier already uses XML as its data format of choice. The Presentation Tier must choose a compatible data format that does not weaken the chain of data integrity of the application as a whole. Regrettably, we cannot endorse JSON as a suitable data format for Data Interchange.
    Looks like justification for not endorsing JSON RPC is already in the paper. Sorry for commenting by reading only the blog. However the points against JSON are debatable: 1) Why would you validate xml data against schema for "every" request from a "known" source such as business/service tier? 2) Even if you need validation in JSON you could always validate against a serialized javascript class/prototype. So the point about lack of data integrity in JSON is questionable. 3) JSON RPC is one of the application container specific RPC styles. What about Java webstart which has implicitly strict datatyped RPC?
  10. Great paper[ Go to top ]

    It's good to be reminded about the impact of the competitive wars on architecture over the last few years. One could view the advent of the "traditional" web application as a leap backwards in productivity for both users of these applications and developers building and maintaining business applications - I think this is largely true for "in-house" focused applications. Looking forward to your next paper comparing the various "AJAX" products/libraries/frameworks. To me the only really compelling thing about AJAX is the opportunity to build "SOFEA" based applications with a rich UI that can be both public and internal facing without having to build and maintain two separate presentation tiers.
  11. What I find most interesting is the proposed list of modern technologies one could use to apply the SOFEA model. I am reproducing it here, with a personal note for each (after the "=>"): I DHTML/AJAX frameworks for Current Browsers 1. Handcoded with third party JavaScript libraries => not very practical, requires Javascript coding/debugging 2. Google Web Toolkit (GWT, GWT-Ext) => this works great, I use it currently in a large project 3. TIBCO General Interface Builder => I know nothing about, but not an option (for me) if it's commercial II XML Dialects for Advanced Browsers 4. XForms and XHTML 2.0 => not supported by current browsers, therefore not an option 5. Mozilla XUL => only supported by Mozilla browsers, therefore not an option 6. Microsoft SilverLight/XAML => controlled by a single commercial vendor and only supported by IE, therefore not an option III Java frameworks 7. Java WebStart (with/without Spring Rich Client) => never got much traction in the market, probably never will 8. JavaFX => still only mostly vaporware, and not likely to be widely accepted IV Adobe Flash-based frameworks 9. Adobe Flex => not a Java-based tech, controlled by single commercial vendor, and not very compelling 10. OpenLaszlo => not a Java-based tech, not very compelling, with small market penetration Please keep in mind the above comments are purelly from my personal opinion. I only have significant real world experience with GWT. So far, I am very pleased with the "Web 2.0" architecture which naturally evolved in my current project (which used and still uses JSP and Struts) from the introduction of GWT. And this architecture happens to follow most of the SOFEA principles (all but principle 1, I think), even though the application doesn't use SOA. Rogério Liesenfeld
  12. ...3. TIBCO General Interface Builder
    => I know nothing about, but not an option (for me)
    if it's commercial...
    http://www.tibco.com/software/rich_internet_application/general_interface/gi_licenses_pricing.jsp
  13. Re: Life above the Service Tier[ Go to top ]

    The architecture described by this paper is the way I've been building webapps for the last 6-7 years... just like AJAX, had I thought it was anything special all this time and not just the way everyone must be doing things, *I* could have been the one to get rich and famous! Story of my life! But I digress... this is all about mindset, something I've said in numerous places on numerous occasions... so many people are still burdened by what I like to call the "classic" model of webapp architecture, largely perpetuated by many of the most popular frameworks in use today. That model is outdated and doesn't allow development of modern RIAs (not without a lot of headache anyway). The thing people need to realize is that doing this isn't hard, it's actually very easy. It doesn't require any sort of tooling, doesn't require any sort of technology that hasn't been around for many, many years. All it requires is a different way of thinking, a different approach. Once you get your mind in the right gear, indeed, it seems silly to do things any other way. I say this having been successful developing applications in this way for a long time on a good number of large projects. I've prided myself on building a reputation of creating webapps that look, feel and function like fat-client apps, and the architecture described here, more or less anyway, is what has allowed me to do so.
  14. A correction[ Go to top ]

    The table mapping CRUD verbs to HTTP verbs on page 8 of the main document has a typo. "Find/Search" is a Retrieve, not a Create, and it maps to GET, not to POST. We'll upload a corrected version of the document shortly. Apologies. Ganesh
  15. Wicket and Eclipse-RAP[ Go to top ]

    Nice article, It would be very interesting to see what is the SOFEA compliance of the following Presentation technologies: - Apache Wicket: http://wicket.apache.org/ - Eclipse-RAP: http://www.eclipse.org/rap/ Perhaps you can add them to the list of technologies being evaluated?
  16. About remoting protocol[ Go to top ]

    First of all thank you for formalizing this. I definitely think that this is going in the right direction. But I feel like as it has been stated in previous comments, you should not restrict remoting to the use of XML. For me this is plumbing and we just need a remoting protocol that conforms to some requirements. The main advantages of XML are interoperability and validation (by schema). But sometimes you just don't care about interoperability but you are more concerned about performance. For instance if you're doing Java to Java remoting, Spring remoting using HTTPInvoker is a great choice. As you transport Java objects on the wire, a lot of validation is unnecessary and if you need more advanced validation rules you can intercept method calls both on client and server using validators. I like the idea of P2P messaging that you are advocating, but you should elaborate a little bit more on that. This is really convenient in situations where you need push (back to front updates...). Calling service methods asynchronously is good, but I think too that to be complete, services would need to provide hooks during the time span of their execution. Those hooks could be used for instance to notify the progress to the client for long running jobs, to provide stop or cancel functionality (the later triggering a transaction rollback), or to return partial results (think of service method aggregating remote service calls). Regarding the implementations for the web I like GWT. I think that this technology can enable a good coverage of the principles SOFEA. It lacks a MVC framework but I think it will come because it is not that hard to implement. But I think that the P2P messaging is missing (maybe I'm wrong). I started to look at Flex too and I liked what I've seen. It has a good MVC framework (Cairngorm), validation and seems to have all the required plumbing for P2P messaging. For desktop application as I stated above if you're using a Java client technology like for instance Eclipse RCP, I like Spring Remoting for synchronous method calls, and JMS for P2P messaging (with temporary queues). But I would like to have a unified way to call services with hooks.
  17. My opinion... 'Presentation Flow' is a legacy artifact of the page-based, HTML dominated world of application development that we current ly live in. A 'rich' UI does not limit users to a predefined 'flow', they manipulate objects in any way that suits their purposes at the moment, there is no 'presentation flow'. For instance, they might choose to lookup an address while right in the middle of completing the 'create invoice' flow.
  18. I fully agree. In my experience, which started in the old pre-Java times dominated by RAD tools such as Visual Basic, this idea of having a statically defined (usually in XML) "presentation flow" never seemed to make much sense. I mean, nobody never did seem to miss the lack of such a feature when using VB, Visual C++, Delphi, PowerBuilder, or Swing. So why must we separatelly and declaratively define page/screen flow for web applications? GWT has no support for declarative screen flow, but nobody in my current project team misses it either. And we are implementing complex use cases, even some where the "next screen" depends on some interactive UI selection in the current screen. I wish developers would just dump this concept. IMO, it is not worth the effort. Rogério
  19. The need for presentation flow is purely determined by end user requirement/usability/page real estate. Most cases it is not even our choice. If that need exists, you have to build it irrespective of AJAX, VB etc (programmatically of course)
  20. Ted, Our definition of Presentation Flow simply refers to the (visual) changes to the interface as the application is executed. It does not imply that the system determines that flow, nor that Presentation Flow has to be tied to a predetermined "business workflow" specific to the function the user is attempting to complete. What you have described is the user directly controlling Presentation Flow, which is what we are recommending as well. In your example, if the user chooses an Address Lookup tab while in the middle of the Create Invoice form, the MVC Controller will respond to that user event and display the Address Lookup form. The MVC Model corresponding to Create Invoice will meanwhile continue to hold the partially entered invoice data, and the user can return to it once Address Lookup is done. Depending on the application's requirements, the Address Lookup function may end up populating the same Model, so that when the user returns to Create Invoice, the address just selected has been added to that form. So, to address your point, there is a Presentation Flow that occurs even in a rich client, but it is much more flexible and more responsive to user requirements. Regards, Ganesh
  21. Half object pattern[ Go to top ]

    Hi, I like your article. Especially the critics of the direct mapping of the request/ response- character of http to the page flow-/ front controller anti pattern. I share your opinion, that this is the reason "why there are so many variants of it and why none of them satisfies". But I think, you are missing a whole category of alternative frameworks, that are based on the half object pattern like Echo2, WiSer and wingS. The pattern does not adhere to the SOFEA principles but it has none of the short comings of the "front controller anti pattern". It is mvc based, highly efficient and it gains a very good responsiveness and usability. Regards, Holger
  22. Thanks for the feedback[ Go to top ]

    Thanks for the continuing feedback, guys. Keep it coming. It's both encouraging and educational for us to hear these different viewpoints, and we can assure you we are/will be investigating the different areas that have been suggested. Thanks once again on behalf of all three of us. Regards, Ganesh
  23. The Web and Java[ Go to top ]

    "Dedication To innovators like Tim BernersLee and the Oak (Green project) team at Sun Microsystems who created the core foundations upon which so much of our digital civilisation depends (The Web and Java);"
    LoL! I stopped reading after reading this dedication. Our "digital civilisation depends" on Java. Heaven forbid!
  24. Client-side control[ Go to top ]

    I agree with many of the other comments here. This is a well-written and welcome paper. I have a quibble about the demand for having client state and presentation flow managed on the client side only. I think this rules out a large number of possible user agents. You mention voice applications yourself. Flow would presumably have to be server-side then. Also, ultra-thin HTML clients cannot be expected to manage their own state. By all means model presentation flow and data interchange orthogonally. I fully welcome that. But at implementation time, where the behaviour sits should not be dictated purely by dogmatic architectural principle. Kit
  25. First of, I think this is well written. But, I dont know if one can efficiently fit thin-client web apps on to this concept. This article will be suitable for RCPs, no doubt. But with webapps, the download time for (AD portion of) a real-world (not sample) application would be so huge that it wont even be worth it. "The second flaw is that the thin-client model tightly couples the mutually orthogonal processes of Presentation Flow and Data Interchange." I dont see anyting wrong with Presentation Flow being on server. It does not necessarily have to be tightly coupled with Data Interchange, always. Then again, presentation Flow does not have to be completely either on client or the server. It can stay on both. For example where you have a list of 5000 names that you want on your drop-down list, you dont want to download all of them as part of your AD. But AJAX will come in your rescue to may be get a filtered list every time as a response to user's keystroke.
  26. Looking at the BPM solutions, we can see tools that just participate on SOA, but they don't build it! In example, Savvion, that is a BPM Suite, uses all the SOA beneficts to build user applications (of course, based on designed processes). We also have some good BPM free tools on the web, for smaller projects and evaluation. It can be an answer for part of these problems, don't you think?
  27. BPM/Workflow follows a document-style (stateless) communication across user/session context. What we are talking here is a conversation-style (stateful) communication within a user/session context. Only place i could think of using BPM is in page/presentation flow. but that's like using a cannon to kill a mosquito.
  28. No, no... I am not telling you that it is "the solution". What I am trying to expose is the availability of a solution that can be used in some cases - that's why I wrote it could be a solution for "a part" of these problems. In SOA, BPM participates, integrated to Portals, Identity Models and sw, LDAP authorization, creating and controlling user tasks, accessing several numbers of services, etc. So, if you need more than just a presentation, it should be considered. And yes, you can get a stateful communication! So, what I was trying to tell is the opposit you understood: sometimes you have to think big, dealing a solution as a process.
  29. I gave a good read of this paper and it seems to correctly describe the web-versus-fat-client debate. Unfortunately it doesn't address major issues in that debate because it makes too many usage assumptions in favor of fat clients. 1) Non-ajax clients are _not_ in the browser. For non-ajax apps, the browser is simply the display screen and the actual client resides in the server. In this case the "Front Controller" pattern is _not_ an antipattern, because the webserver is where the client resides and that is where the control should be. Claiming that the browser is the client is like saying that one's monitor and mouse is the client for GUI applications. 2) Part of the power of the web platform is that URLs often represent readdressable parts of the applications' presentation flow. URLs (obtained with GET) actually represent directly-addressable state. This is lost or severely hacked around in Ajax applications. This has never been a requirement with Rich Clients because they aren't expected to be available 24x7, aren't inherently multi-user, and generally cannot refer to each other. This is a very powerful concept that enabled the entire internet and is given no weight in the article. 3) By ignoring points #1 and #2, SOFEA seems limited to SOA architectures that are only valid within the scope of a completely controlled environment (like a single company). Many webapps don't have this easy-going requirement. Indeed they may be _more_ service oriented since their loose coupling open them up to easier interoperability. Although I think there are a lot of interesting ideas in the article, I also think that the problems it addresses have been simplified to satisfy the conclusions. There are valid reasons for having flow and state outside of the individual's browser -- even some that apply to Service Oriented design. I would love to see a new revision that takes these concerns into account -- I think the work so far is interesting but would benefit from a more complete treatment.
  30. Keith, I have to disagree with your assessment.
    ...the "Front Controller" pattern is _not_ an antipattern, because the webserver is where the client resides and that is where the control should be.
    Our paper is devoted to challenging this very concept. The web server is _not_ a client. It's a server-side entity that does a number of things, including assisting the client (the thing that runs inside the application container/browser). And no, the monitor and mouse are not the client either. I would request you to read our paper again without preconceptions.
    Part of the power of the web platform is that URLs often represent readdressable parts of the applications' presentation flow.
    Again, I beg to differ. If you study the REST model, URLs represent resources, and hyperlinks can be used to traverse resources. This is _not_ Presentation Flow. It is Data Interchange. We need to get out of the traditional web application mindset and look at the problem domain afresh. It's not fair to say that our paper gives no weight to the web concept of hyperlinking. We do, but we see hyperlinks as linking data (like in the REST model). Presentation Flow is something else altogether.
    SOFEA seems limited to SOA architectures that are only valid within the scope of a completely controlled environment (like a single company).
    No, we intend SOFEA to be a universal architecture for the Presentation Tier. Regards, Ganesh
  31. I really like this article. I like it because it goes along with my thinking. More then a year back I proposed a architecture based on the same concept. You can check it at http://searchwarp.com/swa47205.htm Thanks, Shabbir
  32. First of all, congratulations on thoroughly researched and thought-through article! A deserved challenge to MVC and a needed attempt to tie SOA to front-end issues. I'm somewhat puzzled by how thin vs fat client argument played out, though. In the end, you effectively advocate model convergence by making all clients fat. If only life was that simple! First, there is a problem of different presentation formats for different clients, some of which are not capable of being "fat enough", e.g. cell phones and voice access. For such "very thin" clients, Web server is a client and it plays important role of maintaining uniform cleanly layered architecture. If you can not support pervasive clients, you end up having very different models for regular Web (now fat client, containing PF and requiring AD) and cell phone (thin client driven by Web server). Another challenge I do not see addressed is that in real life you will not be able to split up Application Download and Presentation Flow. If we are talking about pushing presentation flow to the client and having client issue data calls to the server, much of the code that currently runs inside the server will migrate to the client (browser). Realistic applications would weigh in at 10 MB+ of download. We do not want to make client wait for entire application to download before she is able to start working (and 80/20 rule tells us they do not need all this code most of the time anyway). Consider an internal brokerage application. Would you download all Reports and Trading presentation flows on first hit, before user even logs in? This particular user may not even have access to these functions based on her role. So some sort of download on demand driven by presentation flow will be required. And there goes clean separation of AD and PF.
  33. Ivan, The client does not have to be that fat. If you read the paper again carefully, you will see that we have actually proposed *two* SOFEA-conforming designs. The first is a Single Page Application (SPA), which will have the constraints you described. We have also proposed a second solution conforming to SOFEA principles, but which does not require the entire application to be downloaded up front. I think we mentioned at least 3 or 4 times in the paper that we can use a web server that serves up *page templates* on demand (but does not drive Presentation Flow). This is the equivalent of traditional thin clients where pages are served up on demand, but with PF being driven by the client, not the server. Your other point about constrained devices holds. Let's see what can be done about that... Regards, Ganesh
  34. True, you mentioned page templates. This takes care of huge one-lump initial download, but establishes a tie between PF and AD. It is not as problematic as tying in Data Interchange, but still muddies the water. And even if client is not "that fat" in terms of megabytes, architectural model is. Look, your application would resemble a J2EE client with a Swing GUI making EJB calls to "business logic" server. We just have a different standard/protocol for remote access. This is what makes me think fat client. Also, if you imagine a busy portal-like Web(?) page with multiple widgets on it, you will see that you have pushed integration from Portal server to client. Now your client becomes even heavier because it tracks all the things different widgets/portlets do. Looks like I will be able to save a bundle on server hardware (if clients can even run my portal on their desktops, of course).
  35. Ivan, Let me be a bit cheeky and selectively highlight parts of your comment. I believe this preserves the facts while tuning out the cynicism :-).
    [...] page templates [...] take[s] care of huge one-lump initial download [...] establishes a tie between PF and AD. [...] client is not "that fat" in terms of megabytes [...] application would resemble a J2EE client with a Swing GUI making EJB calls to "business logic" server [with] a different standard/protocol for remote access. [...] a busy portal-like Web(?) page with multiple widgets on it [...] have pushed integration from Portal server to client. Now your client [...] tracks all the things different widgets/portlets do. [...]
    My response is, you have accurately described the architecture, and I fail to see the problem! This is exactly what we want :-). Ganesh
  36. Re: Life above the Service Tier[ Go to top ]

    I've posted my feedback on my blog. http://raibledesigns.com/rd/entry/re_life_above_the_service I think this is a very well-written paper. Nicely done gentlemen. Matt
  37. Re: Life above the Service Tier[ Go to top ]

    I just came across this article and was happy to see GWT-Ext mentioned. For those interested, the GWT-Ext page is http://code.google.com/p/gwt-ext/ and you can have a look at the Showcase demo here : http://gwt-ext.googlecode.com/svn/trunk/site/samples/Showcase/Showcase.html#formWithGrid Sanjiv
  38. First of all, thank you for a very well written and thought-provoking article. I must admit though, I can't help but think you are minimizing some of the benefits of the current common practice of spreading MVC across client and server. First, by having my model and domain logic located on the server, I am free to choose the development environment of my preference to build that logic. I can take advantage of the productivity tools, community support, and deep labor pool that comes with JEE. The more I move the model to the client, the more I am confined by whatever execution platform happens to be in vogue across clients. Do I now regress 10 years in development environment to build my non-trivial domain model in JavaScript? Second, the more code I have on my server, the more control I have of its quality. I am in control of execution platform upgrades and can run regression tests accordingly. The more I depend on the client platform, the more I am at mercy of subtle bugs introduced by unique permutations of client environment. I remember the nightmare of quality assurance and browser JVM dependencies when applications were being crammed into Java Applets in the mid to late 90's. Third, by limiting my client dependencies to rendering and some AJAX enhancements, and my Controller and Model safely isolated on my server, I am free to support multiple rendering implementations across different client devices more cheaply than I can support the entire application stack on different client devices. I can focus on desktop browser rendering via HTML/JavaScript first, and then add custom rendering support for my application logic on a Blackberry via Blackberry JDE. Yes, I open myself up to all the problems mentioned above that come with dependence on the client environment, but my point is that I minimize that dependence by having the bulk of my application stack (the domain logic) reside under my control on the server. It would seem to me that the choice of locating your Model and Controller on the client or server would depend on the characteristics of your application and your client base. I would love to hear your reply, because if I'm still just not getting my head around a new way of thinking, I'd like to change that. :) Anthony
  39. Anthony,
    I [...] think you are minimizing some of the benefits of the current common practice of spreading MVC across client and server.

    First, by having my model and domain logic located on the server, I am free to choose the development environment of my preference to build that logic. I can take advantage of the productivity tools, community support, and deep labor pool that comes with JEE. The more I move the model to the client, the more I am confined by whatever execution platform happens to be in vogue across clients. Do I now regress 10 years in development environment to build my non-trivial domain model in JavaScript?
    Domain logic remains on the server and is accessible as services (SOAP or REST). Only Presentation logic moves to the client. Besides, moving to JavaScript is not regressing. Some of the libraries available with JavaScript (e.g., E4X for XML manipulation) beat any that are available for Java.
    Second, the more code I have on my server, the more control I have of its quality. I am in control of execution platform upgrades and can run regression tests accordingly. The more I depend on the client platform, the more I am at mercy of subtle bugs introduced by unique permutations of client environment. I remember the nightmare of quality assurance and browser JVM dependencies when applications were being crammed into Java Applets in the mid to late 90's.
    That's true, but (1) it's only presentation logic that moves to the client, not business logic, so the possible disruption from such situations is lower than it may seem, and (2) client environments have been improving in quality and can provide more stability as platforms.
    Third, by limiting my client dependencies to rendering and some AJAX enhancements, and my Controller and Model safely isolated on my server, I am free to support multiple rendering implementations across different client devices more cheaply than I can support the entire application stack on different client devices. I can focus on desktop browser rendering via HTML/JavaScript first, and then add custom rendering support for my application logic on a Blackberry via Blackberry JDE. Yes, I open myself up to all the problems mentioned above that come with dependence on the client environment, but my point is that I minimize that dependence by having the bulk of my application stack (the domain logic) reside under my control on the server.
    Precisely, and this is what you get when you leave (common) business or domain logic on the server and build various presentation-aware clients to consume that logic in the form of services.
    It would seem to me that the choice of locating your Model and Controller on the client or server would depend on the characteristics of your application and your client base.
    Yes, but there's considerable wiggle room for the designer to use the SOFEA model in almost all contexts (except perhaps where a browser _must_ be used, and JavaScript _must_ be turned off - rarer these days). Regards, Ganesh
  40. Life above the Service Tier[ Go to top ]

    I would like to say that this is an excellence Web 2.0 design pattern. I like it so much that I had implemented a reusable GUI framework to provide SOFEA, that web GUI applications can build on. This framework is built purely in JavaScript and JQuery. It is intended for single page application (of course you can use more that one page). The lowest level of the framework composes of COMM/AJAX Manager, Schedule Manager , Event Manager, Command Manager and Widget Manager just to named a few. At the mid-level, The framework added MVC base Widget to provide further decoupling in the front-end logic. The top level provides implementation of various Widgets (extends MVC base) like Screen, Grid, Form ... the common GUI constructs in the HTML world. All data exchanges are in JSON through AJAX/REST protocol. We developed a Widget Definition language in XML, that dictates the widgets assembly, look and feel and parent-child relationships. These XML definition live on the server, be converted to Java Objects at Server startup time, and serve the corresponding JSON when demanded by the  SOFEA framework client on behave of specific widget. The client reacts on the JSON data to render corresponding widgets on the screen by using their built-in HTML. The widgets on the Screen work independently but interact through events.  We have two applications deployed to production and 5-6 applications based on this framework are in the pipeline. Thanks again.