The "trendy" answer is Web 2.0 for the skin, SOA for the body. Mentally that is how I work on it. In my SOA book I talked about "virtual services" that do not do work directly but which present a different view on the services and capabilities that exist. This comes from a project I did in 1999 where we had a big backend (C++) and then created a set of services in Java which represented how the users wished to interact with that capability. The user (virtual) services did things like caching and page-flow (incremental building of information) and was done based on the user interaction model and the data as they saw it, rather than as the backend (not service oriented) wanted things to be done.
Its easy to imagine several lightweight virtual services re-purposing the "true" SOA pieces for different audiences and interaction models. http://www.capgemini.com/ctoblog/2007/01/diamonds_are_forever_1.php is a picture representation of the difference between interaction and function and how the two interact. Steve On 27/06/07, JP Morgenthal <[EMAIL PROTECTED]> wrote:
You're premise is correct. I am constantly having to remind my development team that we do not change the service to fit the needs of the UI. In these cases we have to develop a server-side processor to provide information aggregation and transformation. Some might do this with an ESB today, but I'm using a Microsoft stack. You might also use a BPM tool to help in this layer since the UI is probably connected to a business process. __________________________________ JP Morgenthal President & CEO Avorcor, Inc. 46440 Benedict Drive Suite 103 Sterling, VA 20164 (703) 649-0829 x 101: Office (703) 554-5301 : Cell [EMAIL PROTECTED] __________________________________ ** *Confidential:* The information in this e-mail message (including any attachments) is intended only for the use of the recipient(s) named above and as such is privileged and confidential. If you are not an intended recipient of this message or an agent responsible for delivering it to the intended recipient(s), be hereby notified that you have received this message in error. Any review, dissemination, distribution, printing or copying of this message is strictly prohibited. If you believe you have received this message in error, please notify the sender immediately by return e-mail and delete this message from your system(s). On Jun 26, 2007, at 5:42 PM, Suhayl Masud wrote: I am curious to find out how fellow SOA practitioners are handling the GUI in the SOA world. The GUI is an interesting beast in SOA (and so is "reporting" for that matter). GUIs require customized information, tailored to particular screens. Now you can format information for the screen on the presentation layer in the GUI, but what if the UI needs more/different information than the service provides? To offer a crude hypothetical: consider a service that requires 10 items in an order to process that order in a specific domain, but the user interface requires 15 information items from the same domain. Now, one hates to modify the perfectly good business service specifically to satisfy the needs of one UI. I have seen the solutions of "presentation services", and have built a few myself....frankly; they don't really look much like services [they resemble pure old application APIs over SOAP http). So, fellow practitioners, how have you handled the requirements of an information rich user interface in your environments? -Regards Suhayl Masud http://www.linkedin.com/in/smasud
