Ed: (01)
First I am glad the OSI stack exists but I am not too young to remember it
(45). Thanks for working on it - it did provide an abstract shared
understanding of layered communications and computer network protocol design
for those who were smart enough to grok it. Even today, companies like
Novell draw two talking to each other:
http://www.novell.com/info/primer/art/prim03.gif (02)
I think that I would agree that what I said below is a bit muddy. From the
perspective of ³all SOA², yes what is behind the interface counts and is
very relevant. The perspective I understood however from the previous
statement was that the consumer should be able to know. Managed
transparency is correct in both cases. A service designer can decide how
much they wish to expose behind the interface. (03)
I had issues with some of the concepts from WS-RX in the fact the visibility
of what happened to the message was supposed to be reported to the service
consumer. This does not in fact break the concept of ³Managed transparency²
but it does introduce some tighter coupling and in general, unless there is
a *really* good reason to do so, most architects I know would not reveal
such detail. (04)
I have no disagreement with acknowledgement or reliable messaging in general
and support WS-RX, but am wary of the fact that people can now use Web
Services standards in a way that is not SOA, using the OASIS Reference Model
as the definition of SOA. This of course confuses people who still think
SOA = WS. (05)
More inline: (06)
>
> 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.
>
> 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)
DN: Sadly, the same reason SOA has not delivered all it can is that these
ontology pieces are missing. I gave a talk last week that almost quoted
your paragraphs above to the word. (08)
>
> 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?).
> (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)
DN: On the W3C note, if a virus, it now appears to have spread to OASIS.
One other thing I am grappling with is the standard WS-TX which now appears
to mix business (application) semantics in the transport layer. Why would
SOAP messages start carrying application logic such as 2 phased commits etc.
I an curious to know what others on this list think of this development. (011)
Thoughts? (012)
_________________________________________________________________
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 (013)
|
