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
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
