Steve and JP both make great points. Given that many projects that
will result in service creation are still driven solely from user
interface requirements, the temptation is very great to tailor you
service interfaces toward that particular UI. Whether you create a
separate presentation services tier performing functions as Steve
describes, or embed some of the logic within the presentation itself,
is dependent on whether there are elements of the presentation that
may be reusable across multiple user interfaces.
The one thing about your example that I found interesting is that you
gave an example of requiring 15 information items in the presentation
layer, but dealing with a business service that only needed 10. I
would be very surprised to find a query service that didn't return
everything that a potential consumer might need. I often recommend a
Small, Medium, and Large approach when dealing with pure information
services. One returns a minimal set of information, potentially as
small as a reference id. One returns the set of information to cover
80% of the consumers, and the last returns everything, ensuring that
all consumers are covered. In reality, however, discussions around
this are usually an indication that the service team really doesn't
understanding how the information is going to be used and is simply
making a best guess. You also don't want to reinvent SQL. If the
information service team is finding no consistency in terms of the
information sets they need to provide and starts down a path of
developing a query language via their service interface, it's time to
rethink your whole approach to information access.
One scenario that could match your example is where the information
comes from multiple information domains, and some aggregation needs
to happen. In this case, you would make use of a presentation
services tier that talks to the domain-specific information services
to aggregate the data. This, of course, presumes that this
particular aggregation is only of value for this particular UI. If
it's a common aggregation, then an argument could be made that it
should be moved down into the information services area anyway.
Also, keep in mind your performance requirements. The other thing to
watch out for is a re-invention of SQL
If the backend business service is performing some form of update
(e.g. the UI is for placing an order), it really doesn't matter that
the UI has more information elements than the business service
requires. If the business service was properly designed, it should
be receiving all the information it needs. If there was ancillary
information that a user needed to do their tasks, but is not needed
for order processing, there's no problems.
-tb
On Jun 27, 2007, at 7:13 AM, Steve Jones wrote:
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
