What you are demonstrating is the problem of having SOA and SODA
interpreted as the same thing, or more succinctly, SOA being tied to
a way to design software versus the way to design a system.
To paraphrase Einstein, "Something should be made as simple as
possible and no simpler." A service should have distinct
boundaries. There's a commercial on the radio here in Virginia now
that is an auto-attendant for a phone system and it says, "Press 1
for insurance, Press 2 for dog grooming, etc." Granularity is a key
to a good SOA design. So all the operations of the service should
have a logical relationship that the consumer can understand. If
you're providing a service for managing consumer banking that also
offers to provide car service, you will break the consumer's model of
comprehension.
NOTE: I had to re-write that last anecdote three times because the
first two are now actually offered by banks (life insurance and
mortgage), finally I just left the financial services domain to
complete the example. However, it pointed out something I wanted to
share, which is if business sets the model and it's understandable by
the consumer, then the consumer will not deem the service confusing.
So a consumer banking service that has operations for assigning life
insurance policy and re-financing a mortgage will not break the
consumer's model of comprehension today, but it would have in 1980.
So, I figure by 2020, we can just write the Great Mother Of All
Services and screw all the arguments since Microsoft and Citibank
will just offer everything anyway.
To speak of things like "facade services" confuses SODA with general
SOA in my opinion. This is just helper code to make a software
system work, it has nothing to do with actually providing the service
you wish to provide.
__________________________________
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 27, 2007, at 1:29 PM, Suhayl Masud wrote:
Thanks for the responses so far.
However facade / aggregate services are not going to solve the
problem posed : "your user wants to see more information then is
required to conduct your business process".
Here is my premise: a service should not offer a simple raw data
dump. Why? Because then you are tightly coupling on the data. The
more raw data you expose, the more people will manipulate it
different ways and be tied to it. Furthermore, once again, the logic
will start getting built over and over to do similar things all over
the place.
In my humble opinion, one should be able to ask a question of a
service and receive an intelligent response. So instead of
extracting data and manipulating it oneself, the consumer could ask
a meaningful question and recieve an intelligent response. This way,
the service is responsible for the "logic" as well as the data.
Business processes and the services within, work well with this
approach. The UI on the other hand, wants to show a lot of
information. Rollups, drill downs, and all sorts of stuff that helps
the user *decide* to take action in that business process.
It would be ideal if one could promote the simplification of the
user interface. E.g. Library search interfaces were far more
complicated then the google search interface, but google offers
richer results even though the control "choices" of the user are
limited. I have found however, that for human intelligence rich
processes, it is imperative to provide the user a tonne of
information so they are comfortable with the process, and can make a
meaningful decision.
It is tough to explain this without detailed examples, but it has
been my experience that UIs pose a specific challenge to building
services. Especially when you get right down to the nitty gritty of
the details needed (often outside of the business service
interface), and performance issues (consider a list pane with a
scroll bar...ouch!).
--cheers
Suhayl
http://www.linkedin.com/in/smasud
--- In [email protected], "Rob Eamon"
<[EMAIL PROTECTED]> wrote:
>
> In their book "Enterprise SOA: Service-Oriented Architecture Best
> Practices", Krafzig, Banke and Slama define a "facade service"
much
> like what the other posts describe. Such services "encapsulate
some of
> the complexity of underlying basic services by providing an
aggregated
> API that enables clients to more easily utilize the functionality
of
> the basic layer."
>
> I know you were just providing an example with the 10 fields vs.
15
> fields scenario but we should be careful about thinking in those
terms.
> Rather, we should be thinking in terms of services.
>
> For example, from the Enterprise SOA book, they use an example of
> separate booking and billing services that must record a
reservation in
> a coordinated manner--e.g. you don't want to book without billing
and
> vice versa. An intermediate service would be one way to address
this.
> This focuses on the need for coordinating the services, rather
than
> focusing on the data elements.
>
> -Rob
>
