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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

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


Subject: Re: [soa-rm-ra] Service visibility


I've embedded my comments below:

<comment>
When do we need visibility between the consumer and
the service vs. the consumer and the service provider?
 For example, if I've used the service before and
saved the specifics of the execution context, I just
interact with the service to realize the real world
effects.  If I am having difficulties with automated
means for resolving policy differences, I probably
need to interact with the service provider.   Frank
and I had a brief interchange on this during the RM. 
Do we need more resolution of the endpoint?
</comment>

<danny comment>
Based on the comment, it is not synonomous to say
consumer interacts with service and consumer interacts
with service provider.  This is a useful distinction,
but I think it is a subtle distinction for most people
in the IT industry.  I think it might be worthwhile to
clearly make this distinction in the Participants
section of the RA.  From an IT perspective,
interacting with the service is the invocation of the
service actions. Interacting with the service provider
includes invocation of service action and things like
contract negotiations, resolution of a breach of
contract, etc.

In terms of visibility, there are places where service
provider may be used instead of just service but it is
not always clear which one is a better fit.
</danny comment>

<original>
Willingness is an intentional stance held by the
participating entities that predisposes them to
interact in a service interaction.
</original>
<suggestion>
Willingness is an intentional stance held by the
participating entities that predisposes them to take
actions necessary to realize the real world effects of
a service.
</suggestion>

<danny comment>
updated wiki
</danny comment>


<original>

Management of group discovery information can quickly
become complex if the service consumers and service
providers refer to each other directly. Discovery
mediation can alleviate direct references between the
consumer's and provider's discovery information.

</original>

<danny comment>
This sentence should be discussed in the mediation
section.  I removed it from the Group section.
</danny comment>

<comment>

The issue isn't one of consumers and providers
referring to each other directly but rather how they
refer to each other.  For example, if I want to
evaluate the risk in driving a certain route, I
certainly want to refer to the same service (and
possibly the same version of the service) each time I
reevaluate the risk, because if the risk changes, I
want to know why it changed, i.e. I can't have
different services arbitrarily swapped in.  On the
other hand, this does not mean I need to interact
through the same service interface each time as long
as I can be assured that the differences aren't
important to me.  So if Danny provides the risk
evaluation services for my group, I can get the same
flexibility from a Web page with links that Danny
provides as I can from a formal registry, and can
probably do it more directly.  Additionally, a
registry may have a mechanism to read Danny's Web page
and pull the descriptions into its catalog.

</comment>

<suggestion>

A group is a collection of individuals and the level
and complexity of the formalisms through which the
group operates will vary. In a SOA context, if the
domain expertise of the group can be organized into a
dozen services, a Web page listing summary
descriptions and a link to the full service
description (including the address of the service
interface) may be sufficient to accomplish awareness. 
If the group maintains several hundred services, a
formal cataloguing mechanism, such as a service
registry, is likely needed.  This points to the
transition when group resources exhibit aspects of
global discovery, but that transition is likely to
occur in stages over time and not be characterized by
any hard criteria.

</suggestion>


<danny comment>
There's a conflict in the use of personal, group, and
global and I'm not sure how to resolve it at this
point in time.  It's perfectly valid to describe
personal, group, and global in the way it has been
described.  From an SOA IT perspective, the
implementation of visibility for personal, group, or
global will likely be the same.  For example, no
matter what category I fall into I am likely to
interact with a service registry product to achieve
service visibility.     
</danny comment>

<comment>

When I start reading about Mediated Discovery, I feel
we need to step back and include (somewhere) a
definition of Mediation.

</comment>

<suggestion>

Mediation is the process by which interaction is
enabled between two entities where there is initially
a difference between the abilities, protocols,
formats, vocabularies, or other interaction or
exchange requirements for the two entities to have a
successful interaction.  Mediation may be automated or
require human intervention.  For SOA, information in
the service and consumer descriptions serve as an
indicator of where mediation is needed.  Establishing
an execution context is often the process of
identifying and assembling the mediation capabilities
needed for continued interaction or collecting the
results of mediation that has already resolved some
subset of the initial differences.

</suggestion>

<comment> The dictionary definition of mediation
implies a 3rd party to help resolve disputes.  I think
the suggested definition is consistent with this.  So,
how does this definition (or some variant) apply to
the term "mediated discovery"?  Should we modify the
suggested definition to include mitigating complexity
or does that over-stretch the term?

</comment>

<danny comment>
Now we have a clash of two paradigms. The first
paradigm was simple, complex, and mediated discovery
and the second paradigm is personal, group, and global
discovery.  The first paradigm took a more IT centric
approach and the second took more of a humanistic
approach.  We need to bridge the humanistic approach
to the IT approach for the enterprise architects.
</danny comment>


<original>

Mediation promotes loose coupling by keeping the
consumers and services from explicitly referring to
each other and the descriptions.

</original>

<comment>

Loose coupling isn't necessarily that you don't point
directly to something explicit but how easy it is to
point to something else.  The idea of the UDDI tModel
is one can easily point to another service that uses
the same tModel.

</comment>

<danny comment>
It's easiest for me to point my service directly to
another service without going through a mediation
process, but by doing so I am more tightly coupling
myself with the service I am referring to. The tModel
example is going down another level in describing
loose coupling, do we need to go down to that level
for the RA?
</danny comment>


<original>

The potential service consumers perform queries or are
notified ...

...

 2. A single point of control. If the central
discovery service is owned by, or controlled by,
someone other than the service consumers and/or
providers then the latter may be put at a competitive
disadvantage based on policies of the discovery
provider.

</original>

<comment>

Good capture here.  Do we need more thought on who
sets up a registry and why?  Also, how do you search
across registries?  For example, if every ESB that
proxies services has a local registry, it appears each
ESB licensee has a separate registry.  Is there a way
across these?

</comment>

<danny comment>
The question of who sets up a registry and why goes
back to the human element.  Expanding on DNS could
provide one model for searching across registries.  I
don't think this is a problem we should try to solve
at the level of the RA.
</danny coment>


<original>

While there can be several mechanisms for service
discovery in a SOA, a prevalent mechanism for
mediation in the industry is a registry.

</original>

<comment>

One might say a registry is the canonical mechanism
but I'm not sure I'd say the prevalent one.

</comment>

<danny comment>
chagned prevalent to common
</danny comment>


<original>

Illustration 4 label: Register service description

</original>

<comment>

As stated, register would be a push mechanism.  Should
also allow for pull, such as crawl?

</comment>

<danny comment>
The sentence above the diagram allows for pull:
Service descriptions can be pushed (publish/subscribe
for example) or pulled from the register-repository
mediator.
<danny comment>

<suggestion>

Service Provider <arrowLabel> creates/maintains
</arrowLabel> Service Description (new box) and arrow
from Service Description to Mediation Facility is
"Populate with service description".

</suggestion>

<danny comment>
Added a box for Service Description.  Changed the
Service Provider to Mediation Facility arrow label to
Populate/Maintain Service Description.
</danny comment>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


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