Re: [soa-rm] Diagram

An entity may be directly discoverable or indirectly discoverable. For the discussion I was doing at the time, indirect discovery would be accomplished through search of a registry where the description of the entity has been catalogued and discovery is accomplished by matching the user's criteria to the catalogued entity description. However, it should be noted that there are other discovery mechanisms such as direct discovery by browsing for an entity at known locations. For example, an NCES discovery service could be accessible from a link on the home page of a DISA portal. You go to the portal because you expect to find a link prominently displayed; this is as much based on expectations for the functions of the portal as it does anything about the discovery service. As another recent example, many corporations have been responding to natural disasters by having prominent links on their home pages pointing to relief organizations or ways to make immediate contributions that would be passed to such organizations. This has created an implicit expectation that a certain set of home pages will enable direct discovery of pertinent links, and no other searching is required. One can also imagine a business model where certain portals specialize in advertising specific types of services. Note that discovery could make use of both direct and indirect methods, such as browsing a taxonomy to identify a class of entity and then searching a registry for entities catalogued as belonging to that class.

In both of these cases, the entity must have sufficient visibility (no matter what the visibility mechanism) so that it can be discovered when someone looks for it.

Hope this moves things forward.

Ken

On Dec 7, 2005, at 9:33 PM, Francis McCabe wrote:

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...

Frank

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

---

Ken Laskey

MITRE Corporation, M/S H305 phone: 703-983-7934

7515 Colshire Drive fax: 703-983-1379

McLean VA 22102-7508

soa-rm message