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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

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


Subject: Proposal for [Disc03], [Disc08] and [Disco11] (was RE: [wsdm] Discovery Scenarios [fred])



I agree with Thierry's proposal. Using the issue names from the
"discovery recap" email, this proposal says that issues [Disc03] and
[Disc08] should be merged and the mechanism to ask someone for the
resources it knows about is to ask that someone for the relationships
they have.

Practically, one way to do this is to create a MUWS-defined resource
property called "muws:Relationship" of cardinality 0 to infinite. The
exact type of this will come from our group's work on relationships.
Resources will use this property to expose relationships they are
engaged in (and know about).

There is only one correction I want to make on Thierry's proposal.

In the wording for [Disc03] I purposely wrote: It is the issue of
providing a way to retrieve a list of EPRs from "someone". I didn't call
this "someone" manageability provider because currently what we define
as the manageability provider is not an entity to which you address
messages, it is an entity that allows WS-Resources to receive messages.
It does not have interactions of its own. I think it should stay this
way. The resource that exposes its relationships is different from the
conceptual "manageability provider" even though it might in practice be
the same code. So I would slightly modify Thierry's proposal to not say
that the relationship is between the resource and the "manageability
provider". It is between the resource and some WS-Resource that we
happen to know about.

Here is an example:

The resources I am discovering are Web services. I am also managing
their container, as a WSEE resource. In practice, the code behind the
WSEE (say BEA WebLogic) is also the manageability provider for the Web
services. But my interactions are with the WSEE as a Web Service
Execution Environment, not as a "manageability provider". I retrieve the
"relationship" resource property for the WSEE and it gives me a bunch of
"containment" relationships with each of the Web services deployed in
the WSEE. These give me the EPRs of the manageable resources
corresponding to these services. Note that the WSEE might also have, for
example, a "dependency" relationship with the server on which it runs or
with a database it uses. As the requestor, it is my choice to decide
what relationships I care about. For example, if I am a simple topology
tool who just wants to draw a map of all the resources present, I will
consider all the relationships exposed by the WSEE. If I am a Web
service-centric tool that only care about Web services, then I will only
care about resources that have a "contained" relationship with the WSEE.

How does this map to our "WSDL to EPR" discovery discussion? Simple. If
I discover a WSDL and this WSDL happens to have, among its resource
properties, the muws:Relationship resource property, I might try to
retrieve these relationships. Now this invocation might fail if some
reference properties are needed, but this is a matter for issue [Disc02]
which I don't want to discuss here. Assume that the interaction
succeeds, either because the resolution of [Disc02] allows this or
because the implementer just decides to make a WS-Resource available at
this address which has an empty ReferenceProperties element in this EPR.
Then we retrieve a bunch of relationships that give us a bunch of EPRs.
We have in effect provided one way to retrieve EPRs from a WSDL: send a
<wsrp:GetResourceProperty>muws:Relationship</wsrp:GetResourceProperty>
request to the address in the WSDL and see what you get back. Whether to
make this pattern a best practice or not is for us to decide.

As Thierry also notes, this also covers us with regards to [Disco11],
brought up by Mike Ellison. These "someone" whom we ask for their
relationship, we can also register with them for notification on
creation/deletion of relationships. So, using my example above, I would
register with the WSEE for notification on creation/deletion of
relationships. This way whenever a service gets deployed/undeployed I
will be notified. Same thing for the "WSDL to EPR" example. That
WS-Resource that I asked for its relationships (whether this WS-Resource
is a manageable resource of its own with a muws:ResourceId and other
management capabilities or not) might also be willing to act as a
notification producer and I can register with it for notification on
destruction/creation of relationships.

If people are comfortable with this approach, we can close [Disco03],
[Disco08] and Disco[11] (or rather hibernate them until we get to the
work on relationships). The discussion would still go as to what to do
with [Disco02] and whether to submit a requirement on it to WSRF, but
the [Disco03] part of the discussion would be off the table and not need
to go to WSRF.

Regards,

William


-----Original Message-----
From: Thierry Schang [mailto:tschang@tibco.com] 
Sent: Friday, May 21, 2004 3:12 PM
To: Wsdm (E-mail)
Cc: Thierry Schang
Subject: RE: [wsdm] Discovery Scenarios [fred]


I think we do need to have a "ListResources" functionality for each
manageability provider.  This model is used by multiple agent based
management systems, JMX and HP's WSMF are good examples of it.

The functionality itself can actually be handled like a relationship
named "manages" and/or "isManagedBy" which can exist between the
manageability provider and each EPR. 

Discovering new EPRs or changes in the EPR list can be done through
relationship change notifications.  We haven't talked much about
relationships yet in this group but it will probably provide a mechanism
to notify the manager of any relationship change, hence we get the
functionality for free in this context.

thanks

Thierry Schang
TIBCO Software Inc. - voice: 650 846 5781



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