As far as I am concerned, there is utility
to generic method signatures and generic meta-models (the data model
equivalent) at a certain layer of the stack.
These then need to layered with more
specific operation names and more specific data models to get more semantics in
and hence more immediate use but allowing the cost of making them more and more
domain specific.
It all boils down to being a continuum and
not a black or white thing. Where to draw the line, of course, is
application/goal specific (at a point in time).
Mukund Balasubramanian
From: Gregg Wonderly
[mailto:[EMAIL PROTECTED]
Sent: Monday, February 27, 2006
8:50 PM
To: [email protected]
Subject: Re:
[service-orientated-architecture] Re: What is a "well defined
interface"?
Mark Baker wrote:
> Anne,
>
> On 2/27/06, Anne Thomas Manes
<[EMAIL PROTECTED]> wrote:
>
>>A generic protocol provides only generic
semantics.
>>
>>
>
> Right. You can get both real time and
delayed stock quotes via a
> getStockQuote interface, which is better than
requiring separate interfaces
> for each type of quote
(getRealtimeStockQuote(), getDelayedStockQuote).
>
> Generic semantics just take this practice -
which improves reusability and
> reduces coupling - to an extreme. Seems
like a good idea to me! And think
> how popular and widespread a protocol with
these kinds of generic semantics
> would be! 8-)
We've had IP and TCP for years. Why is there
any other protocol in existance?
They provide everything needed to get the data
from one end to the other. If we
just used TCP for reliable streams, then everyone
would have to know how every
port's protocol worked, and there would be wide
variations. The semantic
standardization that created HTTP running over a
reliable stream, is the
enabler. Further semanatic standardization
on top of HTTP include HTML
presentation. However that is outbound
semantics, not inbound semantics. So,
for every operation performed over http, we
technically can only provide
something like
Object getStockQuote( String symbol, int maxWait
);
The returned value will require infinite
(litteraly) inspection scenarios to
completely understand what is there. The
reason? Because there are no semantic
limitations of the interpretation.
HTML presented to a human is consumable.
But, what would an application do with
the following pieces of HTML if its intent was to
find the titles of all
sections of a set of pages? Both of these
produce reasonably similar renderings.
<font size="+3"><b>The Title
String</b></font><br>
vs
<h1>The Title String</h1>
The first example has no semantic meaning, only
presentation. The second
example, is one of the few HTML shortcut
presentation directives that actually
has a semantic meaning that "might"
allow me to use it appropriately in software.
But, the documents creator has the option to use
the former or the latter, and I
can't control that as the consumer.
The more choices there are, the harder it is to
know which choice has been made
and which choices you should be prepared to deal
with.
There are, of course, reasons to use something
completely generic. I have a
least one interface in production code that has the
above signature. It's a
convienent placeholder that allows me to plug in
new API calls that I want to
try out, without having to change the API for the
other users who don't use
downloaded code. But, I regularly move such
methods up to fully declared
methods in the API on new releases.
Gregg Wonderly
SPONSORED LINKS
YAHOO! GROUPS LINKS
