Thank you gregor!. You' ve been very clear.
On Jan 12, 7:05 pm, gregor <greg.power...@googlemail.com> wrote:
> in line comments....
>
> On Jan 12, 4:58 pm, Paranoid Android <paranoid.fa...@gmail.com> 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 <greg.power...@googlemail.com> 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 <paranoid.fa...@gmail.com> 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 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
-~----------~----~----~----~------~----~------~--~---
