I think we’ve got a good discussion
here.
Another question: IF—big “if”—operations
are represented as resources, is there a way of conveniently representing the
relationship between the service and its operations? Is Service Group
sufficient to this job? (Would Service Group do the job of representing
services that are aggregations of services?)
Kirk Wilson
Architect, Development
Office of the CTO
802 765-4337
-----Original Message-----
From: Tony Gullotta
[mailto:tony.gullotta@soa.com]
Sent: Monday, October 24, 2005
5:10 PM
To: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Groups -
OperationMetricsProposal (MowsOpMetrics.doc) uploaded
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
From: David E Cox
[mailto:decox@us.ibm.com]
Sent: Monday, October 24, 2005
1:16 PM
To: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Groups -
OperationMetricsProposal (MowsOpMetrics.doc) uploaded
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