wsdm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc) uploaded
- From: "Tony Gullotta" <tony.gullotta@soa.com>
- To: <wsdm@lists.oasis-open.org>
- Date: Mon, 24 Oct 2005 14:10:01 -0700
I don't know about starting and stopping operations but
I do believe it is reasonable to report whether a particular operation is
available or not. Let's say one web service is really an aggregation of many
other web services. If one of those back-end services is down, only some of the
operations of the front end web service will be unavailable. Even with Bryan's
analogy of a service being a resource and operations being actions to take on
that resource, its possible that same actions may not be performed at any given
time.
Tony
I do not agree that Start and Stop
don't make sense on an operation by operation basis. In most app servers,
Start and Stop aren't going to be directly implementable at the service level.
Web services in j2ee containers (for example) are probably stateless
session beans that are not "running" but are rather driven when a request comes
in. Therefore Start and Stop are probably implemented not by stopping some
long-running process (because there is none), but rather by blocking the
messages. Therefore it is perfectly possible and reasonable to allow
blocking messages at the operation granularity.
Similarly, as my examples below illustrated, a Web
service is not a monolithic resource. There can and will be cases where
one operation is available and another is not. One operation may have a
dependency is that is unavailable, and other operations may not have that
dependency. In that case, you can state that the entire Web service is
unavailable, which is incorrect because maybe every operation except one is
available. Otherwise, you state that if any operation is Available, then
the Web service is Available. In that case, you may have Service Level
Agreements that are failing due to a particular operation not working, because
your management tool doesn't have granular visibility to the state of the
operations. You may even have the case where some operations are processed
in a completely different container than other operations (probably on a
port-type boundary).
Another
example is that one business process might use one operation on a service,
and a different business process might use another operation on the same
service. Without status granularity to the operation, in the case where
one operation is unavailable and the other is available, the management tool
will have to conclude that both business processes are impacted or not without
being able to tell that one is impacted and the other is not.
In summary, I think that start, stop,
state, status, and relationships do have meaning for operations within a Web
service. I also believe that providing this level of manageability will be
critical to actually isolating and diagnosing problems in Web services.
Regards,
David E Cox
"Murray, Bryan P."
<bryan.murray@hp.com>
10/24/2005 03:58 PM
|
To
| David E
Cox/Raleigh/IBM@IBMUS, <wsdm@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsdm] Groups -
OperationMetricsProposal (MowsOpMetrics.doc)
uploaded |
|
I do not know what it means to have a Start resource, or a
Stop or Reset resource. To me, operations are the actions that can be done to a
resource, not resources in themselves. I do not know of other models that define
resources for the actions to be taken on a resource - CIM does not.
To get
back to the original subject, I agree with Kirk about State and Status not
really making sense on a per operation basis. A resource is in a particular
state. Some operations are designed to change that state. Sometimes the state
changes for some resource-specific reason. I don't see State as inherently being
different just because a certain operation is being processed (except for those
operations designed to change a state).
We are defining metrics on a per
operation basis, not because metrics are inherently different for different
operations, but to report more detailed data than the resource-wide metrics are
able to do. The resource-wide metric incorporates all of the data that the
individual per operation metrics do as a summary, but sometimes a management
application wants to have more detailed information about some critical
operation than is available with the original set of metrics.
Bryan
From: David E Cox [mailto:decox@us.ibm.com]
Sent: Monday, October 24, 2005 12:38 PM
To:
wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Groups -
OperationMetricsProposal (MowsOpMetrics.doc) uploaded
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]