Hi all,
In our system, we have a Remote API layer (e.g. SOAP, XML-RPC, REST, etc.) to handle the domain logic and data access for web application and any client applications that're developed on top of it. Unlike in the past, I do not have business logic code and DB connectivity at the web application, all user actions are translated to be invoking the methods of the layer.
My concerns are, say for the rendering of a page, it requires making quite a number of calls to grab the data, e.g. a user dashboard with reports, recent history, some portlets, etc. With my current design (of delegating logic and DA to the Remote layer), what're the disadvantages that you are seeing? I see that establishing and transmitting text-based data via HTTP are heavier and more expensive than DB access. Besides, optimization has to be done at the Remote layer instead (given business logic & DA code at the web app, you have more flexibility in optimizing).
I am now thinking if I shall create a remote "Helper" service that allows me to squeeze all calls into one, i.e. instead of making multiple calls, I send one single call with a collection of method names and arguments. It looks a bit ugly and that's why I'm still skeptical of doing it now.
I would like to know your opinions about this architecture and if you had developed a web appplication using the similar way, what're the approaches you had taken in the past to guarantee good performance? If there're any other concerns that I should really be worried about, please share it with me as well.
Thanks!
yc