OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [soa-rm] Diagram

You can think of visibility as being supported by discoverability (in  
all its various forms).
But, in fact, it hints at a very interesting and deep concept that  
underlies many aspects of CS. An extreme example: a function call in  
a bit of code that invokes a library function. For this function call  
to 'work', the caller has to be able to 'see' the callee. In many  
languages this is accomplished by setting special flags that tell the  
compiler (and link-loader) where to find the library. Similarly, the  
library function often has to be specially marked (exported) and  
placed in a special library file in a special location (putting a lib  
file in /usr/lib amounts to advertising the library).

Thus for the function call to work, there has to be awareness -- a  
combination of the programmer specifying the function call and the  
compiler knowing where to look. There has to 'willingness' -- the  
function has to be ready to accept a call. And there has to be  
reachability - the compiled function has to be in a place where the  
link-loader and/or OS can access it (and has to be link-compatible  
with the caller).

This is an extreme case, but exceptions prove the rule! (The old  
meaning of prove as in testing).

Visibility also speaks more to the result of discovery than the  
process. Which is initially why I pounced on the term when Ken  
introduced it.

I had a lot of nodding of heads at the OMG when I talked about  
visibility. People seem to glom on to the idea very naturally.

As far as errors and RWE is concerned, I am aware that there is a  
gradation of responses possible when a service consumer interacts  
with a service. If you think about withdrawing more cash from one's  
bank account than is present in it, the bank will report an error. It  
may well also flag the account for possible fraud checking. This  
feature is an aspect of the RWE of using the bank that all parties  
may be relying on...


On Dec 7, 2005, at 5:44 PM, Duane Nickull wrote:

> Actually, I think that an error/fault report is a legitimate RWE!
> Perhaps it is not the desired effect... Otherwise if you try to
> distinguish successful interactions from unsuccessful ones you are
> going to get into an awful tangle.
> DN: This may slightly clash with your earlier thoughts on this thread
> WRT "It is not the interaction that results in a real world effect. It
> is the use of the capability that does."  I am not weighed either way
> since it requires more thought than my mind is currently capable  
> of ;-)
> Again, it is not a question of what needs to be visible. But rather
> that visibility is an inherent aspect of SOA.
> Visibility may be enhanced by discovery/descriptions etc. but is a
> separate concept. For one thing, it is inherently consumer/provider
> neutral.
> DN: yeah - that is the one concept I had the most trouble with and am
> stil not happy.  It is kind of like "semantics" - irgundwo and  
> nirgundwo
> (everywhere and nowhere in German).
> D

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]