[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]