Michael Poulin <[EMAIL PROTECTED]> wrote: "...
but you cannot build your service to do pagination instead (not really a
service anymore)" - Suhayl said.
Oups, I wish I would told this a couple months ago when we built such service,
well "not really a service anymore" -:)
Nevertheless, I am interested to know why pagination service is not really a
service. I would agree - it is not a simple Web Service, right, but we are
talking SOA, aren't we?
- Michael
Suhayl Masud <[EMAIL PROTECTED]> wrote:
Michael and Anne,
Thanks for your input as well. Also I agree with most of what
Michael has written. I must agree that the "example" I put up is
vague.
In my crude example, we have a service for a particular domain, it
satisfies the business process needs of that domain perfectly.
However, different GUIs access this service and have valid needs to
show more information than the service should rightfully provide.
What type of information you ask? All types of information that is
not the realm of the business service.
I disagree that we should build 2 or 3 versions of the same service.
Bad idea. Keep in mind that data coupling increases when the
intelligence is shifted away from the service and into the consumer
by pushing out massive amounts of data, instead of information or
intelligence.
I also disagree that another service be built to provide the extra
information needed. There are lots of things the UI needs (I am
generalizing again), for example, it likes to show things in lists.
You cannot send *all* the information that would show in the list
(say a 1000 records), but you cannot build your service to do
pagination instead (not really a service anymore). This is just an
example I pulled of the top of my head, but you get the idea, the UI
is a different beast.
So the question is a general query...how do you handle the GUI?
How have I handled it? I have tightened the business service to do
the business function well, to be cohesive, and not tied to any user
interfaces. You can ask it an intelligent question and gives you an
intelligent response (does not push out raw data). For anything else
the UI needs from that domain, and if it is not related to the
business task, it goes about it the traditional way, getting it from
the database via a middle layer (not a service).
I believe Anne has pointed out a similar situation in her comment.
I like this group so far, there is intelligent interaction on it.
That's why I suggest that we examine the SOA and the GUI, and SOA
and reporting intelligently (I feel that reporting is another non-
SOA thing btw, that the needs of reporting cannot be met with SOA).
Disclosure: well I am an independent consultant and really biased
towards any products. My architectural bias is a bit more towards
standardized partner to partner interactions as I have worked
extensively with RosettaNet and ebXML in the past.
--cheers
Suhayl
--- In [email protected], "Anne Thomas
Manes" <[EMAIL PROTECTED]> wrote:
>
> For the most part I agree with Michael, here, but I wanted to add
one more
> thought to the discussion, and that is the distinction between
application
> and service.
>
> Why is it that Suhayl is working on the assumption that a UI (an
> application) can retrieve data from one and only one service? Or
that all
> information displayed in the UI must in fact come from a service?
A common
> feature of an application is that it pulls information from
multiple
> services or multiple data sources. If a service supports the needs
of a
> number of applications, it seems inappropriate to bloat the
service with
> additional information just to support a single application.
Either build a
> composite service to support the individual application's
requirements, or
> simply implement the appropriate code in the application to
retrieve the
> additional data required.
>
> Here's an important point that many folks often miss in their
exuberance to
> adopt SOA: not everything needs to be a service. Things that are
> application-specific should be implemented in the application.
>
> Anne
>
> On 7/1/07, Michael Poulin <[EMAIL PROTECTED]> wrote:
> >
> > Hey guys!
> > I know I am late to this stream but still would like to add my
1p. to it.
> > I have not read all messages but guessed there are two major
flows in the
> > discussion (based on what I read): 1) how to design a solution
for exact
> > task set by Suhayl Masud; 2) concerns that there is not
everything OK with
> > the task itself (Gregg Wonderly)
> >
> > So, instead of 'how' I usually start with the question 'why'. 1)
Why UI
> > got disconnected from the service in given example? 2) Why
particular UI
> > asks for more data than service provides? 3) Why the service
dare to hate
> > "to modify the perfectly good business service" for this domain?
> >
> > I have several answers:
> > 1) the business analysis of the case is absent. Also, technical
solution
> > design is absent. The task is formulated in silo, w/o business
and
> > executable context. As usual, one tries to set the cart before
the horse -
> > SOA service is client-centric methodology: if the service cannot
meet the
> > requirements, it is fired. Period.
> >
> > 2) I see a possibility of mistaken UI design for given domain.
Since UI
> > must reflect not a user wishes but the business service
interface, the data
> > in the interface has to be adequate to the business service. A
necessity
> > for more data may mean that the UI tries to a) cross the business
> > domain/function/service; b) user experience (embedded into the
UI) extends
> > (but rather narrows) business interface which might not be
acceptable from
> > the overall business model perspective
> >
> > 3) perfect business service, even in the same domain, may not
necessary
> > cover all customer needs. That is, this service is not enough
and new
> > service is needed. Another case, the "perfect business service"
is not that
> > perfect after all: since the case of just data set variation in
the service
> > return, a document/literal service style can accommodate such
change
> > extremly easy. So, the problem here is not in technology but in
the human
> > factor (that One who does not want to modify the service). That
is, you have
> > to look for managerial means to 'convince' that One to do the
job. If the
> > service is perfect RPC style - this is the very case to
demonstrate the
> > service has to be retired right away because it is perfectly bad
service,
> > especially as a business service.
> >
> > I also deal a lot with 'presentational services'. They reflect
business
> > interfaces of the business services and never crosses the
business service
> > boundaries. The 'presentational services' usually represent sub-
sets of the
> > business service data model. If the UI requires extended set of
data (wider
> > than the business service data model defines), it is a clear
signal for a
> > service composition of several services. Otherwise, the service
must handle
> > any data combinations based on its business service data model
with minimal
> > data format (Schema) modifications (represented as service
versions).
> >
> > - Michael
> >
> >
> >
> > *Suhayl Masud <[EMAIL PROTECTED]>* 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
> >
> >
> > ------------------------------
> > Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s
user
> >
panel<http://us.rd.yahoo.com/evt=48516/*http://surveylink.yahoo.com/g
mrs/yahoo_panel_invite.asp?a=7+>and lay it on us.
> >
> >
> >
>
---------------------------------
Pinpoint customers who are looking for what you sell.
---------------------------------
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.
