Spring + Hibernate + GWT is a sound choice and should support most all of what you need to do. I would look at JBoss SEAM, but then I like JBoss. All three are tried and tested in the field, so that should tell you scalability is not an issue. With GWT clients, the key thing is being able to move session state from the server (where it lives in e.g. a Struts application), to the client. If it is possible for you to eliminate most session state maintenance from your server cluster you will get a significant boost to performance and scalability since you get less HttpSession synchronization chatter across the cluster.
This of course is in your own hands. Spring, Hibernate, GWT and your application server won't stop you doing this right, but they won't do it for you automatically either. On Jan 16, 10:34 am, Paranoid Android <paranoid.fa...@gmail.com> wrote: > Thank you. I'm convincing myself that this could be the possible best > solution. > I also looked at the architecture of some "white label social > networking platforms" and portals like Elgg, LinkedIn, Liferay etc.. > and it seems that the architecture i've described in the previous post > could be both robust and flexible enought for my solution. > Using GWT I can develop an high quality interface, higher than a JSP > based from my poit of view, also moving some complexity and computing > overhead to the client. > With the Spring framework I've an ascertained and robust backbone for > implementing services and managing data with Hibernate in a simpler > and managed way. > Besides that, I can integrate some messaging system, maybe based on > ActiveMQ and thanks to message driven beans provided by Spring, if > such need will arise in the future or in the more detailed design > phases. > In this way I can concetrate, in the first design phases, to other > concers more related to the "social aspect" of the platform (i.e. > sociability design, data portability etc) than to spend a lot of time > developing some kind of "more advanced message-based architecture" > using ESB like ServiceMix. > I've only one concern: scalability. > How does this solution conciliate with scalability issues. Is this > architecture scalable? Can this architecture support the goals of my > project? What do you think? > > On Jan 15, 5:35 pm, gregor <greg.power...@googlemail.com> wrote: > > > > If, for example, I've an application with a rich client interface > > > (e.g. builded using gwt) that interacts with, let's say, with a > > > Session Facade..(ejb, spring, or whatever). > > > My Model is composed of services and a typical persistence layer... > > > now hypothesize that everything is well done, i.e. services reflects a > > > business decomposition etc..etc... > > > Isn't this a good solution? Is this SOA? Is this MVC? > > > I think what you are describing here is an industrial strength Java EE > > + GWT architecture for a system that is fully capable of > > *participating* in an SOA since all the business services (EJB/Spring > > based, whatever) can be exposed in multiple ways to third party > > systems as required, including an ESB supporting an SOA environment. > > An application server like JBoss, for instance, has a plethora of > > tools to help you do this (including it's own ESB as it happens), and > > I think Spring is the same. > > > MVC is another matter, and IMO it is another buzz term that means all > > sorts of things to different people. MVC was originally invented > > during the Apple Lisa project (the first real WIMP framework) in the > > early 1980's I believe, and I think it was implemented in Smalltalk, > > one of the first "proper" OO languages, which was specifically > > designed to support MVC. Struts is most definitely MVC: > > JSP==View;Action==Controller;Bean==Model etc. But it has to be that > > way to run the cycles of pages in the application. > > > However in GUI programming environments the role of Controller becomes > > moot, or confused. Swing, for example, is often accused of not being > > "true MVC" because there is no real enforcement or even encouragement > > to cleanly separate a View (i.e. a widget) from a Controller, whatever > > that actually means in the context of a client GUI. > > > For a GWT example, suppose you have a Tree, you select an item from it > > and you want to display some details about that item in second panel. > > You might have the widget containing the tree implement > > SourcesChangeEvents, and the display panel implement ChangeListener, > > so the display panel is notified when user selects a Tree item. > > DisplayPanel has its onChange(Widget sender) method called, retrieves > > the item identifier from the sender (the Tree) and calls an > > asynchronous RPC service to get the details. RPC servlet calls, say, a > > Session EJB to fetch the Model object concerned, then returns it to > > DisplayPanel callback onSuccess(object result) method, from whence > > DisplayPanel can populate its fields. > > > As you can see the "Controller" element is split up all over the place > > because what you have here is a distributed n-tier architecture with > > an AJAX UI, and, unlike Struts, it doesn't fit neatly into pure MVC. > > The same sort of thing happens with Swing/SWT. In the Apple Lisa days, > > I think it was assumed an application would either run pretty much all > > on a server to a dumb client or alternatively pretty much all on the > > client just accessing maybe a database sever, so the original MVC > > didn't really cater for all this. > > > This is not to say that you cannot implement pure MVC in a GWT client > > (I think there are projects around that directly support this) but it > > can take extra effort that may not really be worth it. One case where > > true MVC does earn its dinner is where you have a complex model > > (something like a work flow process for example) which supports > > multiple views, all of which might update it and all of which need > > notifying of changes to it. In this case the Views should interact > > with the model via a Controller only or you will end up with > > unmaintainable spaghetti. > > > I have no idea what MVC has got to do with messaging. Perhaps ESB > > vendors would like people to think of their message buses as > > Controllers, and in the multi-system business process scenario > > discussed above they undoubtedly are, but MVC usually refers to how a > > UI interacts with the Domain Model. > > > regards > > gregor > > > > My idea is that, FROM A PRACTICAL (implementation) point of view, SOA > > > can be (also) simply a way to think about the Model, in a reusable and > > > loose-coupled way and can be a very good solution even without going > > > to complex message-based MVC. > > > > On Jan 15, 9:53 am, Paranoid Android <paranoid.fa...@gmail.com> wrote: > > > > > Thank you gregor, I think your advices could be very useful to me. > > > > My biggest concern, anyway, is not to run on multiple clients. Even if > > > > I can't discard this possibility by now, it has not yet been > > > > identified as a requirements of the application. > > > > The biggest concern is to expose a set of features that future > > > > developers that want to add some higher level functionalities can use > > > > with no or minimal changes to the underlying architecture. > > > > As I said, specifically to the domain of the application, something > > > > pretty similar to Google OpenSocial Apis, but using standars like web > > > > services. > > > > This is the biggest concern, than the system should be scalable and > > > > maybe distributed, so the architecture must be > > > > thought in a way that it will not be a problem if users scale from 100 > > > > to 100000. > > > > This is the general picture. So, thinking about it, maybe an ESB is > > > > not really what I need, anyway I must expose feature both locally and > > > > remotely and thus I'm going to look for other technologies to achieve > > > > that, maybe EJB's as you suggested.. > > > > Only a thing make me doubtful: the project manager suggest that a > > > > message/event driven architecture may be a better solution over a > > > > classical MVC architecture, but I can't find another solution for a > > > > good message driven solution other than an ESB.. > > > > > On Jan 14, 7:06 pm, gregor <greg.power...@googlemail.com> wrote: > > > > > > Paranoid, > > > > > > 1) ESB's are good at, and designed for, orchestrating business > > > > > transactions across multiple third party systems that otherwise could > > > > > not talk to each other easily, whilst providing clients with a single > > > > > view of and interface with that process. Other than that, they offer > > > > > nothing really. By now you probably get the impression that I think > > > > > you need an ESB like you need a hole in the head! > > > > > > 2) You should adhere to YAGNI. For each iteration of a project you > > > > > should define precise objectives for each use case you intend to > > > > > implement *for that iteration*, and equally important you should > > > > > define non-objectives (constraints), things you are definitely not > > > > > going to do this time, if ever. Then you do not write a line of code > > > > > nor use any library that does not directly contribute something > > > > > tangible to these stated objectives, and secondly you meet these > > > > > objectives in the simplest and quickest way you possibly can. That's > > > > > so you get feedback from real users as early as possible which will > > > > > almost certainly give you some surprises. > > > > > > For example, it seems to me that one of your biggest concerns is > > > > > running on multiple clients, e.g. mobile devices, as well as standard > > > > > browsers. OK, so you might define an primary objective that the system > > > > > must be fully functional for a given set of use cases in both a > > > > > standard browser and on, say, an iPhone, something running Android, or > > > > > whatever. By doing that you will a) focus your development effort on > > > > > practical application of the technologies you need to use to meet this > > > > > specific objective, and b) your server side architecture will > > > > > automatically evolve to support these two different client interfaces > > > > > as the practical issues become clear to you. Subsequently adding a > > > > > third or fourth will then be straight forward, but you don't have to > > > > > worry about that now. > > > > > > If you don't focus like this, you are in danger of never really > > > > > getting started, never mind finishing. > > > > > > regards > > > > > gregor > > > > > > On Jan 14, 4:30 pm, Paranoid Android <paranoid.fa...@gmail.com> wrote: > > > > > > > Thank you gregor, your post is very interesting and I basically > > > > > > agree > > > > > > with your point of view. > > > > > > Cause I'm a newby in SOA solutions, I'm reading and reading things > > > > > > and > > > > > > asking to more expert people like you. > > > > > > In fact I think I need little of > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
