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
threefold:
- 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)
|