[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] Discovery of manageability endpoint
From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
Sent: Thursday, December 11, 2003 9:24 AM
To: WSDM TC
Subject: [wsdm] Discovery of manageability endpoint
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.
-- Igor Sedukhin .. (email@example.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788