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: Re: [wsdm] Discovery of manageability endpoint


Thus quoth Sedukhin, Igor S (~ 11-Dec-03 10:00 AM ~)...

> +1 to Fred :) 

Thanx. 8-)

Another interesting point about the 'pedestrian' approach is that it 
punts the "what do we manage question".  We manage that which refered to 
us. ;-)

Implementations will, in turn, be able to complain that they can't 
figure out details.  But that's an implementation issue.
> 
> 
> -- 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, December 11, 2003 12:56 PM
> To: WSDM TC
> Subject: Re: [wsdm] Discovery of manageability endpoint
> 
> Thus quoth Sedukhin, Igor S (~ 11-Dec-03 9:23 AM ~)...
> 
> 
>>The next obvious problem that we need to solve for the interop 
>>scenario discussed at the F2F is: given the functional endpoint 
>>(service) WSDL find the manageability endpoint(s). I propose that we 
>>discuss and allow ALL of the following possible solutions, however 
>>pick one for the interop event show run.
>>
>>Possible ways to discover manageability endpoint
>>
>>1. description of the manageability service (possibly with a set of 
>>manageability endpoints) is embedded in the same WSDL along with 
>>functional service with its endpoint(s). The manager detects 
>>manageability service/endpoints by verifying the operation signatures 
>>(WSDL 1.1) or interface extension tree (WSDL 2.0).
>>
>>2. The functional endpoint is ALSO a manageability endpoint (i.e. 
>>implements functional and WSDM operations). In this case manager has 
>>no confusion and issues management related requests to the same 
>>endpoint that functional requests are issued to. The precise 
>>implementation of such could be in the same code; the container that 
>>adds management operations at the deployment time automatically; an 
>>intermediary that appends manageability operations, sits in the 
>>message path and takes care of management requests on behalf of the functional endpoint; etc.
>>
>>3. Both functional and manageability endpoints are published into the 
>>same UDDI. For every service binding (UDDI) an instance info contains 
>>a set of tModels each with a pointer to an overview document (WSDL). 
>>There could be (and usually are) multiple tModels for a given UDDI binding.
>>First instance info tModels has to be describing a functional endpoint 
>>(UDDI requirement). Other tModels could be describing things like 
>>security token service, etc. Therefore, description of the 
>>manageability endpoint could also appear as yet another tModel in the 
>>instance info list of a given UDDI binding. Manager merely 
>>investigates all tModels in an instance info list looking for those 
>>that implement WSDM manageability interfaces (WSDL 2.0) or 
>>manageability operations (checking signatures in case of WSDL 1.1).
>>
>>4. Manager could use relationships: query at runtime or read from 
>>descriptive metadata. This is yet to be discussed.
>>
>>Possible ways to establish which manageability endpoint manages which 
>>functional endpoint, given WSDL descriptions of both endpoints.
>>
>>A. The manager establishes associations between functional and 
>>manageability endpoints by exercising identification manageability 
>>capability on the manageability endpoint (requests at runtime) and 
>>compares the returned reference to the given WSDL information.
>>
>>B. The manager establishes associations between functional and 
>>manageability endpoint by comparing a WSDM-specific tag on the 
>>wsdl:endpoint elements. For example <wsdl:endpoint name="Functional"
>>wsdm:target="urn:abc">, <wsdl:endpoint name="Manageability" 
>>wsdm:target="urn:abc">
>>
>>C. Manager could use descriptive metadata e.g. relationships or 
>>otherwise. For example <wsdl:endpoint name="Manageability"
>>wsdm:target="urn:abc"> … <wsdm:target uri="urn:abc" 
>>service="s:MyService" endpoint="Functional">. Or similar 
>>metadata-based approaches are possible.
> 
> Or even the more pedestrian "name it" approach:
>      <wsdl:endpoint name="foo" wsdm:MgmtEP="http://..."/> or, better yet (arguably),
>      <wsdl:endpoint name="foo1"
>         wsdm:MgmtEp=".../M-ilityEndPoint.wsdl#port(mgmtsvc/mgmtport)"/>
> (where that last thing is the xPointer way of naming a port in a wsdl file, the WSDL file being that of the management endpoint in question.)
> 
>>--* **Igor Sedukhin* .. (igor.sedukhin@ca.com)
>>--* (631) 342-4325* .. 1 CA Plaza, Islandia, NY 11788
>>
> 
> 
> 
> --
> 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.
> 
> 
> 


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