[Top] [All Lists]

Re: [ontolog-forum] The DIKW Hierarchy issue(s)

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
Cc: "Toby.Considine@xxxxxxxxx" <Toby.Considine@xxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Fri, 19 Jun 2009 13:16:56 -0400
Message-id: <4A3BC808.3070408@xxxxxxxx>
OK.  I have to disagree with Duane on two counts.    (01)

Duane Nickull wrote:
> I always disgreed with "& will do something with it" as this
> potentially is an anti-pattern of SOA.  The managed transparency
> aspect means that you  should not necessarily know what is
> behind the service interface, only have a well defined interface
> (aka REST style SOA) and the shared state is the only important
> thing.    (02)

This is a bit muddy.    (03)

I agree that "will do something <not clearly specified> with it" is an 
anti-pattern of SOA.  It treats the message as purely informative.  (But 
in Toby's defense, he was distinguishing the different concepts of 
acknowledgement, not different concepts of service and action.)    (04)

OTOH, SOA is very much about what is behind the interface, rather than 
what the interface is.  Working solely from the interfaces it precisely 
what the existing stupid SOA tools do because they have no intelligent 
representation of what is behind it.    (05)

What characterizes a Service is WHAT it does -- what function is 
performed -- as distinct from HOW it performs that function.  What is 
encapsulated is the HOW, but what needs to be exposed, e.g., for service 
composition or selection is the WHAT.  And that means that the function 
should be defined as a change of state in terms of entities in some 
reference ontology.  The interface is only the explicit language in 
which you ask the agent to perform that function, and many agents may 
provide multiple interfaces to the same function.  (In the Amsterdam 
airport, the lady in the information kiosk responds to queries in 5 or 6 
languages, but the service is the same.)  And conversely, the same 
interface (verbatim) might be used by different agents to perform 
significantly different functions.  ("Fire that pot" means something 
very different in ceramics and fireworks.)  So, contrary to the major 
vendor hype, the interface is a poor way to identify the service.    (06)

Duane is right when he speaks of the "shared state".  The "shared state" 
is the consistent understanding of the initial and intended final states 
of the world in terms of the reference ontology.  And that is what makes 
the topic relevant to this forum.    (07)

On another topic, Duane wrote:
> The OSI 7 layer model was perhaps the most confusing thing introduced
> to the tech world.  I used to burst out laughing when someone
> presented on it and had two talking to each other (what does
> "abstract" mean again?).    (08)

Duane is too young to be familiar with the confusion that preceded it. 
ISO 7498:1978 was an effort to sort out the confusion of communication 
concerns that abounded in the 1970s.  In that same time frame, the 
ARPAnet protocol stack was restructured to give rise to the 
not-quite-as-broken protocol stack that underlies the Internet.  The 
problem with ISO 7498, the Open Systems Interconnection (OSI) Model, was 
  - failure of everyone in the 1970s to understand the concept 
"application protocol" and its relationship to human-computer interfaces.
  - failure of software engineers to understand the difference between 
viewpoints and software modules.
  - the politics of getting major vendors' products to be competitive 
and somehow consistent with the OSI concepts.    (09)

While Duane was laughing at the people who didn't understand 
abstraction, the original architects of OSI were crying.  (To this day, 
W3C refers to XML as a "transport layer", even though it is clearly an 
example of a "presentation" specification in OSI terms.  And it is 
pretty hard to reconcile the W3C usage with the term "Transport Control 
Protocol" (TCP), which IS an OSI "transport layer" specification (and 
parts of another used as a third!).)    (010)

We have long since thrown out the OSI baby with the OSI bathwater, 
partly because what they got only half right, and the ARPAnet ignored, 
were the application and presentation concerns, and partly because the 
ARPAnet religion of 1980 was "streams" instead of "messages".  (Message 
boundaries were an application-specific concern to the ARPAnet folk; so 
everyone invented his own.)  So we have spent 30 years floundering in 
the area of presentation and application standards, while various groups 
jockey for advantage.    (011)

The last bullet above, however, was what doomed OSI.  The major vendors 
did not understand that there was no way to make money building 
communications services to compete with the essentially open-source 
TCP/IP-based services being built by universities with DARPA and JANET 
and EARN funding.  They designed competing services that were better 
designed and would have been more powerful, if there had been a joint 
will to discard their private technologies, and if the software 
implementors had been up to the task.  But the more general designs were 
harder to build, and they had to somehow work with existing products 
with exactly the confused designs that led to the OSI effort.  The adage 
of information technology is "Technical excellence is unrelated to 
market share."  During the 1980s, the major computer firms continued to 
"pursue last year's winners", and lost their market.    (012)

-Ed    (013)

P.S. Yes, I was one of the people who taught and built OSI for 
industrial automation networks in the 1980s.  Duane might be surprised 
at how effective the OSI concepts were, when newly applied over all 
kinds of lower-layer physical networks.  But we had the luxury of virgin 
territory that was not, for the most part, dominated by the major 
computer vendors' higher-level architectures.    (014)

Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694    (015)

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."    (016)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (017)

<Prev in Thread] Current Thread [Next in Thread>