Interop Planning This is a brainstorm session, add as you wish Review Planning Logistics

Interop review Existing document covers MOWS interop w/ a Weather Station service example Provides input for a Primer Lessons learned –...

Interop goals Test ONLY WSDM spec –Make sure that spec is implementable by two independent parties Test what matters Depend on other specs, but not focus on them –Test ONLY parts that make WSDM work Provide implementation experience Results internal to participants –NDA ahead of the event –Rules agreed upfront –Data sanitization Possibility of PR Basis for a cool demo (public event, possibly) Still the input for Primer

Interop Interop “Playbook” –Web service –Arbitrary manageable resource –Example scenarios Interop “Acts” –Capabilties included –Actual interop can be done on these

Interop Sets Focused on a task –E.g. “Subscribing to MOWS Request Processing Notifications” Text explanation of the task Constraints SOAP message exchange examples –Mandatory/optional parts –WSDM parts –Dependent standards parts –Identify volatile parts Separate Interop Sets for Discovery/Introspection (WSDL)

Interop Bootstrap Starts with EPRs for manageability endpoints of –Web Services –Blackberry –Server –... MUST provide –Identity & List of capabilities MAY provide URL to a WSDL (?BP 1.1 compliance) –In which case EPR MUST include service/port If WSDL is not provided, all operations MUST be HTTP/SOAP bound w/o any extensions except WSA Soap:mustUnderstand allowed only on WSA headers WS-I compliant Rely on WSRF-RP implemented at the endpoint (try and fail is ok)

Interop Playbooks Web services management –Weather Station Service example MUWS Identity/Characteristics (Mandatory) MOWS Identification (Mandatory) MOWS Metrics (Optional) MOWS Status/State (Optional) MOWS Request Processing Notification (Optional) MUWS Relationships (Optional) Weather Station Correlateable Properties Act Small device management –Blackberry example MUWS Identity/Characteristics (Mandatory) Blackberry Metrics “Act” (Optional)... Blackberry Configuration (Optional) MUWS Status (Optional) MUWS Metric Change Event (Optional) MUWS Status Change Event (Optional) Server management –IPMI example MUWS Identity/Characteristics (Mandatory) Server Configuration Act (Optional) Server Metrics Act (Optional) Reset “Act” (Optional) Server Alert Notification Act (Optional) MUWS Status (Optional) MUWS Metric Change Event (Optional) MUWS Status Change Event (Optional) WSDL verification “Acts” to be added for each act above (Heather/Zhili) as optional acts.

MUWS Metric Change Event Act To subscribe to a MUWS Metric event topic and get notifications delivered. Step1: using WSDM manageable resource EPR retrieve wsdm:ManageabilityCharacteristics property and verify URI is included (possibly among others) Step2: Using an EPR to a manageable resource retrieve available topics: Get(Topics) -> check for wsdm:MetricsCapability Step3: Using the same EPR subscribe to wsdm:MetricsCapability events. Include receiver EPR. Step4: Receive wsdm:ManagementEvent wrapped wsrp:ResourcePropertyChangeNotification message. Manageable resource uses reeceeiver EPR to send this.

MUWS Identity/Characteristics Act To retrieve resource identification and characteristics provided an EPR of a WSDM manageable resource. Step1: Using an EPR to the WSDM manageable resource retrieve wsdm:ResouceId property. Step2: Retrieve wsdm:ManageabilityCharacteristics property an verify that URI is included (possibly among others)

Server Reset Act To use WSDM manageable resource EPR to reset the server resource. Step1: using WSDM manageable resource EPR retrieve wsdm:ManageabilityCharacteristics property and verify and URIs are included (possibly among others) Step2: using manageable resource EPR invoke ServerReset operation.

Blackberry Metrics Act To retrieve metrics values specific to the Blackberry device. Step1: using WSDM manageable resource EPR retrieve wsdm:ManageabilityCharacteristics property and verify and URIs are included (possibly among others) Step2: Using EPR to a manageable resource retrieve the following metrics properties –wsdm:CurrentTime –bbry:CodeModuleSize, bbry:AllocatedStorage, bbry:FreeStorage –Do it using wsrp:GetProperty for each –Verify that metrics attributes are set correctly according to the type of the metrics (types TBD by IBM) Step3: Do the same using wsrp:GetMultipleProperties

MUWS Relationships Act To navigate a link between two WSDM manageable resources. Step1: using WSDM manageable resource EPR retrieve wsdm:ManageabilityCharacteristics property and verify URI is included (possibly among others) Step2: Using an EPR to the manageable resource retrieve wsdm:ResourceId property Step3: Using an EPR to the manageable resource retrieve wsdm:Relationship* property. Step4: For each wsdm:Relationship with wsdm:Participant/wsdm:ManageabilityEndpointReference AND wsdm:Participant/wsdm:ResourceId != Step2.wsdm:ResourceId DO THIS –Using an EPR contained in wsdm:Participant/wsdm:ManageabilityEndpointReference retrieve wsdm:ResourceId property. This is to make sure that the EPR points to a live WSDM manageable resource.

Weather Station Correlateable Properties Act To establish sameness of two manageable resources using correlateable properties capability. Step1: using WSDM manageable resource #1 EPR retrieve wsdm:ManageabilityCharacteristics property and verify URI is included (possibly among others) Step2: using EPR to the manageable resource #1 retrieve wsdm:CorrelateableProperties property. The dialect MUST be.../pbm. And it MUST contain only one weatherstation:FCCID assertion. Step3: using EPR to the manageable resource #2 retrieve weatherstation:FCCID property. Property MUST be of the xs:positiveInteger type. Step4: Do the same for the manageable resource #1. Step5: Compare values of Step3.weatherstation:FCCID and Step4.weatherstation:FCCID to establish sameness

Interop Participation Manageable Resource –Which profile –Which sets Manageability Consumer –Which profile –Which sets

Interop results Not tested/Not offered Worked Failed –Details WSDM problems Other problems

Plan Interop document –1 week for the first draft Feb 1 st –2 weeks for input Feb 14 th –2 weeks to agree Feb 28 th Signup From Feb 14 th through March 1 st Interop date: Week of April 11 th Interop location: TBD Possible PR by OASIS Symposium (April 24 th )