in line comments.... On Jan 12, 4:58 pm, Paranoid Android <[email protected]> wrote: > Thank you. > > I'm looking at SOA because the variouse features of the social > application should be implememente as remote services.. > What I've to develop is the core of the social network..this core > needs to support functionalities that will be added as services in the > future. > Not every functionality will be exposed as a web service, anyway. > > I read on many blogs and paper on the Web that SOA and EDA are not > alternatives, but complementary approaches (some refer to this as SOA > 2.0, other as Event Driven SOA, etc..).
IMO they are confusing the issue - the term SOA has been conflated with web services and SOAP to such an extent that people talk about EDA being something different to SOA. This is exacerbated with marketing hype from message oriented middleware vendors talking about SOA 2.0 on the back of web 2.0 and claiming EDA is something new and different. In the messaging world you have two types of message: point- to-point and publish/subscribe. SOAP is point-to-point and EDA is publish/subscribe based, period. MoM/ESB products have been supporting both types of message for years and both are equally valid mechanisms for implementing messaging within an SOA. > The interface should be aware of some events in the community and a > part of the tools, along with their GUI (for example a widget that > displays some kind of information for a friend, when he connects into > the network) must "listen" or at least be updated in response to these > events. > To do that you need to look up "server push" technology. You can do it either by having clients regularly poll the server for new messages, or you can use blocking threads to simulate the server "pushing" messages back to the clients. The second option is more complicated but obviously provides a better user experience for your type of application. It is known usually as comet. There are libraries available that support comet you can use. Either way, it has nothing to do with SOA. > Now I'm a little bit confused, because my past experience of web > application developing was based on MVC model. > JSP interface, Struts as Application Controller and Hibernate as > persistence. > GWT UI runs on client, and it replaces traditional JSP/Struts MVC which runs on the server. In GWT you typically use GWT RPC to communicate with a Java server. You declare methods in GWT RemoteServiceServlets to replace e.g. struts Action classes and the ActionServlet. These RPC servlet methods then communicate with your server architecture (Spring, Hibernate whatever) in exactly the same way as Struts Action classes do - from that point on it is the same. Search the group for Struts etc for info about difference between Struts and GWT, there's plenty of it. > So, I'm wondering if the correct approach is to interact with remote > services in the model, in response of some kind of user interaction > with the GUI, then to update the view with the data etc..(like a > classic MVC approach, with the only difference that some of the > business logic is implemented into remote web services e.g. a Struts > Action that invoke a web service), or there is a more correct > approach, in which the interface itself can speak directly with web > services (something like SOAFaces, remote portlets, etc..). > > I'm asking this beacuse there's a lot about SOA for the business > layer, but nothing about the potential advantages of SOA at the user > interface and I'm a newby in this field. > SOA has nothing to do with user interfaces. From the info you have given, you need to look at server-push technology (e.g. comet), and forget about SOA. > In few words: is the GUI independent from the SOA choice yes > or is it also > exploitable in some ways from the GUI? > no - it's "exploitable" from the GWT RPC layer. A GWT application (i.e. a web UI) might make a call as a result of making an order to a RPC servlet that kicked off a complicated business process that involved several different business systems (e.g. Customer Accounts, Products, Inventory, Shipping etc) that the business might have bought from different vendors. To do that the RPC servlet might invoke a service managed by an Enterprise Service Bus that coordinated the transaction across all these various systems by orchestrating a number of e.g. SOAP calls to them and assembling the "answer" before returning a response to the RPC servlet and thence to the client. That is what SOA is all about. > Thank you! > > On Jan 12, 5:40 pm, gregor <[email protected]> wrote: > > > Service Oriented Architectures are about connecting different systems > > within an organisation together using, typically, SOAP. An SOA usually > > uses a message hub, often called an Enterprise Service Bus, of some > > kind to manage the connections and SOAP calls between systems. Axis is > > the most famous open source ESB. > > > Event Driven Architecture an approach to SOA which is an alternative > > to SOAP whereby instead of making direct SOAP RPC calls, systems > > broadcast events that other systems may listen for (or subscribe to). > > Usually it is derived from existing message hub functionality around > > the publish/subscribe message model so existing message hub products > > already support the basic functionality. The advantage is it reduces > > coupling between systems within the SOA scope in the same way that > > using the Observer/Observable pattern in GUI programming does. > > > If you are building a social networking site, it seems unlikely that > > an SOA is what you are looking for since it is geared around > > orchestrating complex business transactions between multiple systems > > within an organisation, say 10 or 20 of them. If you are looking to > > enable other web sites to access your services then I think the most > > popular and efficient way to do that is to create and publish a JSON > > interface. You could also publish a SOAP interface as well, but it is > > unlikely to be as popular as JSON. But AFAIK this is not classified as > > SOA, more mash-up support. > > > regards > > gregor > > > On Jan 12, 3:37 pm, Paranoid Android <[email protected]> wrote: > > > > Hello. My project is about designing an online social network > > > application. I'm in a first stage of evaluating different > > > architectures and design alternatives. The user interface should be > > > made using GWT and the architecture should be a SOA and/or EDA. > > > Now, I'm new to all these technologies/architectures (i was used to > > > MVC using Struts ecc...) and I'm wondering if GWT is a suitable GUI > > > solution in a > > > architecture.. I find out the SOAFaces project but it's like in the > > > earlier stages of development and I instead I need a standard, adopted > > > and working solution. > > > > Can someone give me some some tips to get started.. What kind of > > > technologies should I study? Is GWT ok for SOA and EDA?If not, is > > > there a set of technolgies which adapt well to an SOA architecture, > > > especially on the client (GUI) side? > > > > Thank you very much!! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
