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
