|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 38
Messages: 38
Messages: 38
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Life above the Service Tier
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
|
|
|
Message #241116
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Front Controller anti-pattern?
"This is not to be confused with Front Controller, which is an anti-pattern."
When did Front Controller become an anti-pattern?
|
|
|
Message #241118
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
At last, sane ideas for the presentation tier.
your blog entry is the single most important article i have read this year.
thank you for formalizing it. this is *great* !!!!!
|
|
|
Message #241122
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
thought provocative
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.
|
|
|
Message #241125
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Life above the Service Tier
Great article. Very thoughtful. I need read one more time to digest. Thank you for posting this.
Chester
|
|
|
Message #241132
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Front Controller anti-pattern?
I guess you took time to comment, but not the time to read the article:
"Web frameworks are based on the Front Controller antipattern
(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 antipattern, is there any wonder none of them
will satisfy? The correct approach is to repudiate this
antipattern altogether. The historical reason for its
invention no longer exists to justify its continued use."
|
|
|
Message #241135
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Application container specific RPC styles
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?
|
|
|
Message #241136
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Application container specific RPC styles
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?
|
|
|
Message #241137
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Great paper
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.
|
|
|
Message #241141
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Life above the Service Tier
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
|
|
|
Message #241144
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Life above the Service Tier
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.
|
|
|
Message #241145
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A correction
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
|
|
|
Message #241149
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Application container specific RPC styles
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?
|
|
|
Message #241151
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
About remoting protocol
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.
|
|
|
Message #241157
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rich UIs do not have 'Presentation Flow'
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.
|
|
|
Message #241166
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Half object pattern
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
|
|
|
Message #241167
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rich UIs do not have 'Presentation Flow'
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
|
|
|
Message #241168
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rich UIs do not have 'Presentation Flow'
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)
|
|
|
Message #241171
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thanks for the feedback
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
|
|
|
Message #241173
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The Web and Java
"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!
|
|
|
Message #241180
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Rich UIs do not have 'Presentation Flow'
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
|
|
|
Message #241200
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Client-side control
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
|
|
|
Message #241206
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Maybe a BPM Solution can be an answer for part of these problems
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?
|
|
|
Message #241215
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Maybe a BPM Solution can be an answer for part of these problems
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.
|
|
|
Message #241216
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This concept will effectively rule out thin-client apps
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.
|
|
|
Message #241224
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This paper doesn't the unique concerns of webapps
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.
|
|
|
Message #241231
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Maybe a BPM Solution can be an answer for part of these problems
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.
|
|
|
Message #241246
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: This paper doesn't the unique concerns of webapps
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
|
|
|
Message #241547
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Back to Fat Clients and unhappy AD/PF marriage
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.
|
|
|
Message #241550
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back to Fat Clients and unhappy AD/PF marriage
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
|
|
|
Message #241653
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back to Fat Clients and unhappy AD/PF marriage
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).
|
|
|
Message #241663
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Back to Fat Clients and unhappy AD/PF marriage
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
|
|
|
Message #243076
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Does MVC on the client introduce new problems?
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
|
|
|
Message #245910
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does MVC on the client introduce new problems?
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
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
