[Oslc-pm] PmAppMonitoring scenario questions

Julianne Bielski bielsk at us.ibm.com
Wed Jun 13 16:55:26 EDT 2012


From:   John Arwe/Poughkeepsie/IBM at IBMUS
To:     oslc-pm at open-services.net, 
Date:   06/13/2012 07:50 AM
Subject:        [Oslc-pm] PmAppMonitoring scenario questions
Sent by:        oslc-pm-bounces at open-services.net



[1] http://open-services.net/bin/view/Main/PmAppMonitoring 

Q1.1: mentions a central registry ... is that implementation detail or 
something within the intended scope of the Perf Mon specs? Implementation 
detail.

Q1.2: mentions "reconciled" a few times ... is that implementation detail 
or something within the intended scope of the Perf Mon specs?  Any 
intended relationship to the reconciliation working group that Core 
approved two weeks ago at my request? I see it mentioned in the technical 
goals as a way of alluding to the fact that there won't be multiple 
representations of the same resource from different perfmon providers. I 
wasn't actually awae of a reconciliation working group.

Q1.3: "OSLC client will dynamically determine the current providers" ... 
is that implementation detail or something within the intended scope of 
the Perf Mon specs?   Implementation detail

Q1.4: "An application health consumer queries for monitoring information" 
... is "health" some other domain?  Perf Mon? Same domain, different name. 
A resource's performance give a particular load is an aspect of its 
health, but so are a lot of other things. This scenario describes how the 
PerfMon domain will contribute to the determination of application health.

Q1.5: What is the relationship between Steps and Detailed Steps?  There 
are 5 steps in each, but they do not appear to directly correspond. 
Detailed steps describes what's going on in steps 2-4 of Steps

Q1.6: detailed steps mentions "resource registry"  ... is that 
implementation detail or something within the intended scope of the Perf 
Mon specs?   Implementation detail

Q1.7: detailed steps 2 and children seem to be switching URLs.  At first 
it's a monitoring SP URL (so it probably links to a oslc:ServiceProvider 
resource) that you want a UI preview for, then in 2.2 it's a "target 
resource" that appears to be separate from the SP. I think when I wrote 
that I thought they were separate URLs, but now I know they're one and the 
same

Q1.8: detailed steps 3 talks about HTML inside a compact XML document, 
which is not how OSLC Core's UI preview handshake works. Okay, what should 
I update to fix it?

Q1.9: detailed steps 3.1 maps to an internal resource name ... I'm 
guessing this is implementation detail, not something Perf Mon intends to 
spec? Implementation detail

Q1.10 Are there any specific data/metrics that need to be in the domain 
spec in order to meet this scenario (e.g. all/some of those in the UI 
preview table...which)?  Or is the intent to leave the particular 
metrics/definitions to the implementation, and limit the spec to defining 
how the implementation's metrics are introspected at run time?   Or a bit 
of both? A bit of both. I think consumers want to know what we think Best 
Practice metrics are to determine performance-related health, but I also 
want to allow other providers to be able to add additional metrics if them 
deem it necessary.

Best Regards, John 

Voice US 845-435-9470  BluePages 
Tivoli OSLC Lead - Show me the Scenario 
_______________________________________________
Oslc-Pm mailing list
Oslc-Pm at open-services.net
http://open-services.net/mailman/listinfo/oslc-pm_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-pm_open-services.net/attachments/20120613/e6a2a994/attachment-0003.html>


More information about the Oslc-Pm mailing list