RE: [wsdm] Discovery Scenarios [fred]

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

+1 to Fred. Here is my scenario. I had a MOWS situation in mind to which MUWS must be applicable to make any near term sense for WSDM.

<Schenario>
A map search Web service is discovered and used by a client. The client locates and reads a WSDL document. The client sends map query messages to the map search Web service. The same client or a management part of the client wants to display a warning if the map search Web service is not available and possibly notify the user when the service comes back online. The client wants to go about this using the same tools and techniques that were used to discover and use the map serach Web service. The client has an integral application or a business process that uses map search Web services and their manageability together.
</Schenario>

In general, the way things move i.e. "WSDL or EPR first", in particular, may result in us engineering MUWS to be such a heavy weight "solve-it-all" base that engineering MOWS with it is similar to mounting a rocket jet engine on your everyday Toyota.

Again, I want to emphasize the following additional scenario.

<AnotherScenario>
If a resource is exposed as a regular Web service, e.g. an HDD with an XML API, then it is expected that the way the resource's service is being discovered and used would be applicable to managing such resource as well. In other words, if to read or write some data from/to HDD, one discovers a WSDL document, discovers an HDD service, picks an endpoint and sends SOAP messages with HDD read/write specific payload, then to manage this HDD [and its service for that matter] using WSDM one may naturally choose to do exactly the same except the payload of the messages may be management specific.
</AnotherScenario>

Now, note that either scenario starts with an assumption that it must work today. Let's get the basics sorted out, we can add complexity and flexibility to this as we go. We must start from some workable assumptions.

<IMO>
I think that using EPRs to refer to multiple entities behind a Web service endpoint is just fine, but I don't believe that world starts from an EPR just yet. I believe that given a URL to a WSDL document + WSDM set of specs the scenarios should work. Now, it does not mean that we cannot use some common patterns e.g. WS-RP or WS-N in which EPRs are instrumental. There should be a way to derive those from the above mentioned equation.
</IMO>

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: Fred Carter [mailto:fred.carter@amberpoint.com] 
Sent: Thursday, May 20, 2004 6:38 PM
To: Wsdm (E-mail)
Subject: [wsdm] Discovery Scenarios [fred]

<ScenarioPart>

My scenario, unless I mentioned another to which I wasn't paying attention during the call, is as follows.

    Manager is started.  It is given either a WSDL file (which corresponds to an endpoint for a manageability endpoint) or a URL (which corresponds to said endpoint -- assumed to have some known capabilities).

    Manager wants to use said endpoint to do its manager application thing.  To do so, it needs to find the resources available.

    Now what?

that's it.  I think this is the fundamental part of the so-called "WSDL->EPR" requirements.

</ScenarioPart>

<FredsCommentary>

Responses to anticipated issues:

    Well, why not start with EPR's.
        1) Cause we didn't.
        2) Cause many web service applications follow the above pattern

    Use [insert name] registry here.
        1) Small site, I don't have one.
        2) My first implementation will be the simplest one.  Later, I will add complexity with more moving parts, etc.

    Why should we do this?  Why isn't this left unspecified?
        1) Our intent, insofar as I can tell, is to provide a specification which is usable as is.  We have made a number of decisions and taken directions based on the capability of extant tools and software stacks, to ensure that the specification is adoptable.  If the we rely on a implementation specific stuff to start up, especially for the simplest case (a small number of resources, one container, no uddi, etc.), I think we have an adoption problem.
        2) We can certainly argue that there are should be some other [heretofore nonexistent] specification in which the belongs.  And that may even be true.  But we want folks to adopt & implement now, so basing our work on more things that might come real soon now seems fraught with peril.
        3) One /could/ make whatever a solution might be (say, the ListEPRs operation, for purposes of argument) optional so that "tiny manageability provider endpoints" (or dynamic ones) could function without fear, but I think we should provide the definition nonetheless.


At a higher level, I think that any system wherein access to said resources is provided by other access providers (e.g. WSRF-based things
:-) ) must have a means by which one can determine which resources are accessed via what access provider (modulo permissions, etc.).  This is a bootstrap issue.  It may be that there are options (e.g. use some registry), but then one must be able to find said registry. (Perhaps we define some appropriate fault or property that directs the caller to said registry when necessary.)  Consequently, I tend to think that this is a general problem for WSRF.

[It may be appropriate higher up in the chain (it may be some of the defined mechanism behind ...Addressing), but since WS-Addressing is agnostic on what the properties are used for, it may not be appropriate there.]

</FredsCommentary>


--
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php.