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