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 integration of different systems (no > legacy systems to integrate etc....). > But the key in my project is that I must provide interfaces for the > future development of functionalities, in a similar way as OpenSocial > by Google does, but using other standards. > So my project is not "completely SOA", in the sense that not > everything in my system must be distributed, orchestred, exposed etc, > but a portion of it does. > I though that ESB's like, for example, Apache ServiceMix can be useful > because they provide a way to implements services as POJO's and take > care to expose remote interfaces (bindings) for different types of > consumer that will be developed in the future and because they provide > a way to route messages through services etc.. > But I'm wondering if they provide a way to interact with services that > are local through a local interface (i.e. the model inside my app will > interact with such services through a local interface exposed by the > ESD, while other remote consumers that will eventually be developed in > the future can access these services through, for example, REST or > SOAP without the need to wrap these functionalities). > For these reasons I'm thinking about a SOA solution, even if not > everything will be a service etc... > The general, high level architecture I'm thinking about is something > like this: > > GWT Interface that, through RPC, communicates with a client layer, > such as servlets. > This layer interacts with an ESB (if needed) to invoke services in a > easier way , these services can be remote or local to the server, but > mostly they will be local. > Under this layer of services, there will be, obviously, a persistence > layer with an optional ORM layer (like Hibernate) in beetwen. > > From this point of view, one can argue that I don't need web services > at all.. > But the key here is that I've to expose features (for example, access > to users profiles in the virtual communities) to applications that > will be developed and intergrated in the solution in the future, or > maybe to a mobile interface... > Something similar, as i've stated before, to OpenSocial. > Than I need flexibility. Even if the system is not highly distributed > now, I can't say that it will not be more distributed in the future! > > What do you think? > > On Jan 14, 5:10 pm, gregor <greg.power...@googlemail.com> wrote: > > > @Pananoid > > > You may be interested in this post from The Server Side about SOA. > > >http://www.theserverside.com/tt/articles/article.tss?track=NL-461&ad=... > > > In it the author states: > > > "SOA has thus come to be associated primarily with integration of > > systems. But what if I am building a new application that has little > > to do with integration? Say I'm building a Business Intelligence (BI) > > tool for analyzing and reporting on data from a data warehouse and > > have no requirement to integrate any legacy systems, expose any Web > > Services, or provide any BPEL processes. Is SOA relevant in the design > > of such a system? Would I apply any SOA principles in architecting > > this application? Would it make sense to say that my new system's > > architecture is SOA-based? The answer to all of these questions is > > "Yes" > > > Well, I completely disagree with that. IMO it is an example of the > > sort of hype and nonsense you tend to get around SOA. Examples: > > > 1) Using SOAP interfaces and employing a SOA framework (e.g. an ESB) > > where none is needed imposes a large processing overhead that will > > reduce performance, possibly by orders of magnitude. > > > 2) SOAP interfaces are much more difficult to change than Java > > interfaces. Say I want to change a GWT RPC method by adding an > > additional parameter. I simply select the method in the RPC interface > > in my Java IDE, select "refactor" which updates the asynch interface > > and the implementation automatically, and edit the code in the RPC > > service implementation to use the new parameter. Job done. Try doing > > that sort of thing with a SOAP interface. > > > Against this the author puts up the (IMO extremely weak) argument that > > a SOAP interface + SOA infrastructure "is keeping the mode of > > provisioning of a service separate and independent". What on earth > > does he mean by that? He cannot mean the SOAP service itself because a > > SOAP service is a SOAP service is a SOAP service. I think what he > > means is simply that "SOA infrastructure" takes care of tracking which > > physical server the service runs on which boils down to its IP address > > or DNS name plus the SOAP service call details. Big deal. Remember, > > the service client still has to call the "SOA infrastructure", so it > > will need its address, the call protocol details etc to do so > > anyway..... > > > SOA/SOAP does shine where you need to integrate different back end > > systems that can't talk to each other any other way, but if you are > > writing your own application in your own chosen language like Java it > > is usually better, both from a system performance/scalability and from > > a development agility point of view, to collocate all your component > > modules within the same application server cluster (the exception > > often being a database server). This is because your components will > > talk to each other using local references and you can edit and debug > > the whole stack in your favourite Java IDE. And in this type of > > situation GWT RPC shines as well - economical to code and fast. > > > Just my 2c, Paranoid, but I fear that if you listen too much to this > > sort of thing you will be buying yourself a whole heap of unnecessary > > pain. > > > regards > > gregor > > > On Jan 14, 2:58 pm, Paranoid Android <paranoid.fa...@gmail.com> wrote: > > > > Some questions: > > > > 1) Using GWT-RPC model, can servlets (business logic) distributed like > > > standard web services are? e.g. can I invoke some business that > > > resides on another machine from a GWT client using RPC? > > > > 2) What about Restlets+GWT > > > > 3) Do I need to expose JSON or SOAP interfaces for web services only > > > if I've to expose functionalities to third party web sites, as you > > > said, or they can be useful anyway? > > > > 4) What about SOAFaces for GWT-ESB integration? > > > > Thank you > > > > On Jan 14, 3:39 pm, gregor <greg.power...@googlemail.com> wrote: > > > > > Hi Gabor, > > > > > Personally, I never use the term "web services" anymore. It can mean > > > > anything to anybody. I prefer to be specific, so I speak of SOAP, > > > > REST, JSON, XmlHttprequest, GWT RPC etc. as appropriate. > > > > > I'm a GWT RPC person myself, but if I needed to expose services to > > > > third party web sites for instance, I would choose JSON to do it. I > > > > agree JSON (and REST) is a "web service" if a manager needs soothing > > > > on the point. > > > > > regards > > > > gregor > > > > > On Jan 14, 8:50 am, Gabor Szokoli <szoc...@gmail.com> wrote: > > > > > > Hi! > > > > > > I completely agree with your comparison between GWT-RPC and SOAP XML, > > > > > but it is just too convenient for me to reply to your post with the > > > > > non-conflicting argument for JSON web services as a viable middle > > > > > ground: > > > > > > On Tue, Jan 13, 2009 at 2:42 PM, gregor > > > > > <greg.power...@googlemail.com> wrote: > > > > > > In practice this is almost certainly an unfavourable option because > > > > > > SOAP is a bloated over complicated XML based data exchange mechanism > > > > > > by comparison to REST, JSON, > > > > > > That's still a web service in my book. That's what we use in fact > > > > > (REST with JSON), with SSL and basic authentication. > > > > > The project is still in the pilot phase, but we are getting there. > > > > > Client side performance does not seem to be an issue so far with our > > > > > expected dataset sizes: modern cell phones seem to handle it fine. > > > > > > > and particularly to GWT RPC. > > > > > > GWT-RPC is probably the most efficient on the wire and in the client, > > > > > true. > > > > > On the upside we expose (develop, secure and load test) one interface > > > > > for both human and machine consumption, and can use the server-side > > > > > platform of our choice (currently Jersey) independently from client > > > > > development (currently GWT). > > > > > > > In other words your application will run many times slower, > > > > > > Let them use Chrome ;-) > > > > > Seriously, I very much like the idea of off-loading application state, > > > > > data manipulation and GUI rendering all to the clients, leaving me > > > > > with a stateless, cacheable, data-only server (plus the static > > > > > download of the GWT client). > > > > > Client hardware specifications are often within the order of magnitude > > > > > of server nodes anyway (they may even exceed them in our case...) > > > > > > > and you will have > > > > > > to write hundreds of lines of code to create, serialize and > > > > > > deserialize large XML strings. > > > > > > Not as nice as GWT-RPC sure, but JSON and third party stuff like > > > > > Restlet-GWT can help with that. > > > > > (For the pilot we just roll our own to better understand what is > > > > > going on.) > > > > > > I keep bragging about this approach here to invoke constructive > > > > > criticism, so please discuss. > > > > > I know some of our cornerstone design conditions differ from the > > > > > general case, so I'll list them here: > > > > > - We need to publish web services functionally equivalent to the web > > > > > GUIs anyway > > > > > - Single-page, desktop-like applications > > > > > - No need for SEO, no need to spy on users^W^W^Wcollect usage > > > > > statistics > > > > > - Applications may need to scale (both up to millions of users, and > > > > > down to a few on restricted hardware.) > > > > > > I think enough of these conditions hold for Marvin's case for him to > > ... > > 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 -~----------~----~----~----~------~----~------~--~---
