[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsdm] Groups - OperationMetricsProposal (MowsOpMetrics.doc) uploaded
Kirk,
On 25 Oct 2005, at 7:57, Wilson, Kirk D wrote:
> 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?
I'm not comfortable with operations as resources, particularly in terms
on the creating WS-Resources out of them by combining them with a Web
service, i.e. defining a whole WS to manage a single operation on
another WS starts to sound like deep recursion in the model with no way
out. So I would answer this as operations are not resources. They may
be controllable, as in the discussion on this thread, but they are not
manageable resources. The relationship between an operation and it
containing service should simply be the WSDL and nothing more
complicated than that.
> Is Service Group sufficient to this job? (Would Service Group do
> the job of representing services that are aggregations of services?)
I think the answer here is yes. If I want to construct a SuperService
composition of to other services I could create a ServiceGroup with the
extended semantics that it supported all the operations of both member
services and implemented these operations by simply forwarding the
requests to the members. There are other way to do this, but this might
have other uses, such as load balancing. A SuperService is a collection
of a number of identical services and the SS routes requests to lightly
loaded members.
There are of course other ways to address these use cases.
>
> 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
>
--
Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
Fujitsu Laboratories of Europe
Hayes Park Central
Hayes End Road
Hayes, Middlesex UB4 8FE
+44-208-606-4649 (Office)
+44-208-606-4539 (Fax)
+44-7768-807526 (Mobile)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]