RE: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc) uploaded

[David E Cox <decox@us.ibm.com>]

Hi Kirk,

  I agree that if the service is
Unavailable, quite likely all of the operations are unavailable.  The
reverse, however, may not be true.  The operations in a service may
vary widely in what they require in order to accomplish their function.
 For example, reading a record may work whereas writing a record may
not (due to locking issues, etc).  Another example is that some operations
may be simple, self-contained operations that always work, but other operations
may call out to other web services or non-web services dependencies (such
as a database) that may or may not be up.  Operations that access
one table in a databsae that has performance problems or poor tuning may
show a degraded or unacceptable response time, while other operations work
fine.

  From that perspective, I would
have to get out a great big can opener and open a can of worms.  Just
about (but not quite) everything in the MOWS spec can be different from
one operation to the next within a web service.  The metrics, state,
and status, plus the relationships can certainly be different.  Message
processing state can be different.  Would it make sense to model operations
as resources, rather than trying to qualify most but not everything in
MOWS with operation qualifiers?  This would be in addition to the
model of a Web service as a whole, not a replacement for it.  Let's
discuss first whether it might or might not make sense academically, before
we reject it out of hand because it seems "hard" or too much
trouble.


Regards,
David E Cox

"Wilson, Kirk D" <Kirk.Wilson@ca.com>

10/24/2005 03:02 PM

To	David E Cox/Raleigh/IBM@IBMUS, <fred.carter@amberpoint.com>
cc	<wsdm@lists.oasis-open.org>
Subject	RE: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc) uploaded

On second thought:  I’m
not sure what value per-operation status and state will have.  If
the service is Available or Unavailable, that would apply generally to
the operations within the service.  Perhaps if the service is Partially
Aavailable we might what to drill down to see what operations are available
or not—does anyone have any opinions on this??  I believe that state
model used for operational state is pretty much defined for the service-level
state.
 
On the other hand, I think
we should include the operationName/portTypeName attributes that are part
of the OperationMetric capability as part of the RequestProcessingStateType
so that notification consumer can know what process is being talked about.
 (I assume what is meant by “operation” in the OperationMetric is
the same thing that is being talked about as a “request” in the RequestProcessingState.
 If so, then we should probably use of consistent vocabulary and talk
about a RequestMetric and Request metric properties.  Opinions on
this??)
 
Kirk Wilson
Architect, Development
Office of the CTO
802 765-4337
 
-----Original Message-----
From: Wilson, Kirk D 
Sent: Friday, October 21, 2005 4:59 PM
To: 'David E Cox'; fred.carter@amberpoint.com
Cc: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc)
uploaded
 
Dave, yes I agree.  I
already brought up about an operation processing state (and, correspondingly)
notifications.  I think the general consensus was that it would be
more difficult.  I agree that this issue should be revisited.
 
Kirk Wilson
Architect, Development
Office of the CTO
802 765-4337
 
-----Original Message-----
From: David E Cox [mailto:decox@us.ibm.com] 
Sent: Friday, October 21, 2005 8:05 AM
To: fred.carter@amberpoint.com
Cc: wsdm@lists.oasis-open.org
Subject: Re: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc)
uploaded
 

I think this will be very useful, and thanks for the Proposal, Fred.  But
metrics is only part of the story.  Are we going to do per-operation
state and status?  Are we going to do per-operation message processing
state and notifications?  (The last item may be possible already,
if you specify the operation in your xpath).  I know those weren't
explicitely in the action item, so I am asking if we can add them to the
action item, or write a new action item.

Regards,
David E Cox

Fred Carter <fred.carter@amberpoint.com>

10/17/2005 01:21 PM

Please respond to
fred.carter

To	wsdm@lists.oasis-open.org
cc
Subject	Re: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc) uploaded

 

Good catch.  Operation + ${metric} it is

Thus quoth Wilson, Kirk D (~ 10/15/2005 11:24 AM ~)...
I think there might be a processing problem in the proposal as it current stands.  When encountering a <NumberOfRequests> element, the client parser would have to check the attributes to determine whether the data is at the service level or the operation level.  That might produce a backwards compatibility problem for current implementations.
 
I would recommend that the OperationMetrics properties also be prefaced with “Operation”, i.e. <OperationNumberOfRequests>, etc.
 
Kirk Wilson
Architect, Development
Office of the CTO
802 765-4337
 
-----Original Message-----
From: Fred Carter [mailto:fred.carter@amberpoint.com]
Sent: Friday, October 14, 2005 2:27 PM
To: wsdm@lists.oasis-open.org
Subject: Re: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc) uploaded
 
Thus quoth Wilson, Kirk D (~ 10/14/2005 11:16 AM ~)...
I haven’t had time to read Fred’s proposal yet (weekend reading), but isn’t another alternative just to handle OperationMetrics as an “empty” capability (extension of MOWS metrics) and allow the designer to specify GEDs as part of an service specific extension for each metric property for each operation of interest within that service (a bit ugly and tedious)?
indeed it is.  That's effectively, albeit with even fewer restrictions, the alternative mentioned below  the query resource properties.  It would require each new manageable endpoint to specify their own schema, I think, or run entirely within the extensibility rules.  Then, though, I think you need to figure out how to link them back to this capability...  By type?  By some other, still-to-be-named attribute?

I thought about this.  We could do it using, say, the operationName attribute as a key meaning that this is an operation metric.  Or use the mows:operation{integer,duration}  type, I suppose.  That would work as well.  Difference is that they caller will have to examine the schema to 1) figure out if there are op metrics, and 2) to figure out what their names are.  In this case, the names are known, the operation's names come from the wsdl, but you either have to get the whole prop doc and mung or rely on the server to do it (its having implemented queryResourceProps).  Unclear to me which is preferred...

 
Any thoughts on this?  (Just as a conceptual possibility if not a practical one.)
 
Kirk Wilson
Architect, Development
Office of the CTO
802 765-4337
 
-----Original Message-----
From: Tony Gullotta [mailto:tony.gullotta@soa.com]
Sent: Friday, October 14, 2005 1:59 PM
To: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc) uploaded
 
I see. So we have to use QueryResourceProperties because GetResourceProperty won't be able to distinguish between operations.
 

 

---

From: Fred Carter [mailto:fred.carter@amberpoint.com]
Sent: Friday, October 14, 2005 10:52 AM
To: Tony Gullotta
Cc: wsdm@lists.oasis-open.org
Subject: Re: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc)
uploaded 
Well, it's just a properties document.  So whatever query mechanism
for that would have to do -- that's a WSDM limit, I think.  So this
would use the QueryResourceProperties optional call with a query expression
(dialect XPath) of
   *[namespace-uri()="this capability's namespace" and ./@operationName="desiredOperation"]
(or something like that)

An alternative, where the query function isn't required, would be to name
the operation metrics with the operation name.  However, I think we'd
have a hard time coming up with a schema then (we'd need a meta schema
:-) ), since we wouldn't have the metric names at spec time (since the
operations vary quite a bit, obviously).

At a higher level, the choice at some level, was either individual
metrics or a more general property document element for the operation --
that would contain all the stuff  about an operation.  This seemed
counter to how we've done capabilities, so I separated it this way.

The other choice involves a capability (or some combination thereof) that
instituted a subdocument for operation properties.  I wasn't quite
sure if that was easily representable, so...

Thus quoth Tony Gullotta (~ 10/14/2005 10:34 AM ~)... 
How would I request the NumberOfRequests metric for just one operation?
  
-----Original Message----- 
From: fred.carter@amberpoint.com
[mailto:fred.carter@amberpoint.com]
Sent: Friday, October 14, 2005 10:22 AM
To: wsdm@lists.oasis-open.org
Subject: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc)
uploaded 
  
This document proposes to extend the MUWS metrics capability, adding an
operation name &, optionally, portType, attributes to the current set
of 
MOWS metrics.  As an example, we could report number of requests for
the 
sample operation as 
    <NumberOfRequests operationName="sample" ...>34</NumberOfRequests>
    <NumberOfRequests operationName="anotherSample"
...>3</NumberOfRequests>
  
In this environment, any number of numberOfRequests is permitted, though
they must have different operationNames, or, if the same, different
portTypes, as these are the distinguishing characteristics.
  
Document current shows changes based on the MOWS Metrics capability
since it's pretty analogous.
  
It occurred to me that this is not all that hard, so we may be able to
fit it in (as was some folks recollection of the plan).  My apologies
to 
Bryan as I think we were supposed to collaborate, but he's out of town
now, and I'll be out much of next week.
  
Feel free to shoot away on the list!
  
/fred 
  
 -- fred carter 
  
The document named OperationMetricsProposal (MowsOpMetrics.doc) has been
submitted by fred carter to the OASIS Web Services Distributed
Management 
(WSDM) TC document repository.
  
Document Description: 
Operation Metrics Proposed Text
  
View Document Details: 
http://www.oasis-open.org/apps/org/workgroup/wsdm/document.php?document_
id=14904 
  
Download Document:   
http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php/14904/Mow
sOpMetrics.doc 
  
  
PLEASE NOTE:  If the above links do not work for you, your email
application may be breaking the link into two pieces.  You may be
able 
to copy and paste the entire link address into the address field of your
web browser. 
  
-OASIS Open Administration 
  
  


-- 
Fred Carter / AmberPoint, Inc.
  
mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301



-- 
Fred Carter / AmberPoint, Inc.
  
mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301


-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301