W3C home > Mailing lists > Public > www-ws-arch@w3.org > December 2002

[MTF] Conf Call Minutes 12/18/02

From: Heather Kreger <kreger@us.ibm.com>
Date: Thu, 19 Dec 2002 17:40:11 -0500
To: www-ws-arch@w3.org
Message-ID: <OF112AD139.B91AB12D-ON87256C94.007C6DC0@us.ibm.com>






W3c MTF 12/18/02

Attendees:
Igor - CA
Heather - IBM
Mark – Talking Blocks
Yin-Leng - HP
David Booth – W3C

Discussion:


Web Service Management Requirements

Discussion: Service vs Port: are we managing WSDL.Service? or WSDL.Port?
Service Instance or what’s exposed to consumer that we can measure against.
Is defined as Service, or group of portTypes, at least one portType.  Don’t
go to ports because either do related interfaces (portTypes) or one
portTypes with many ports (bindings) associated with it. Should manage what
consumer and provider agree on portTypes… not the implementation that is
exposed in port. Service itself is a single portType or group of portTypes.

      We’ll manage at levels defined in WSDL: by service, then by port and
portType
The following information should be available for each service as defined
by its name in the WSDL:
Information required to be manageable, where it comes from, format of it is
to be decided by the development a detailed specification.

We have discussed the following fields:


Identification

   Identification information:
o     service identifier, required – uri – a unique identifier for the
service instance or is it type?Refer to wsdl for specifics. Could be
different syntax/multiple uri’s to refer to a service. Can deref to exactly
the same description of the service.
o     service name, not required – readable name for the service, Does it
need to match the service name or the port name in the wsdl? Can get name
from WSDL document for service. Not required, but VERY convenient. Do we
need to standardize optional fields? If provided should be the same as the
value in WSDL.
o     service description, not required – readable description of the
purpose of the service, this could be a catcher for taxonomy, Can get from
WSDL, but its not required there either. If is provided should be same as
in WSDL
o     service version, required – the version of the service as defined in
the WSDL document, this information should ALSO be in WSDL, although at
this time there is no standard way to define it. We will need to define a
standard WSDL extension for this.
§     Vote: Mark, Heather, Igor: required; YinLeng: part of absolute
minimum, mandatory
o     WSDL Reference, required – the reference for the wsdl document for
the service, its somehow allows the manager to get a copy or access to the
WSDL document.
§     Vote: Heather, Mark: Required; Igor: optional… not always at a URL,
could be cached or genned on demand by infrastructure.  Resolution, call it
a reference, let followon work decide format.; Igor is now required.
o     Semantics URI, required – WSDL tns of a WSDL, identifies the
semantics. Use identifier to refer to semantics or could use it to get a
document that describes the semantics of the service, what you get depends
on mime type. Could be a human readable doc, or rdf doc. Could be the URL
of a document, but its not required to be a URL.
§     Vote: Igor, Mark, David, Heather?: required; YinLeng: optional;
o     (move to metric)



Configuration

   Configuration information
o     WS Access URLs, optional – this would be the same is the URL in the
location element in the port referring to this service. Can a service have
several of these? For a service, tell all the access URLs. Move discussion
to service instance.
o     Ws WSDL description URLs + service name + port name, already part of
Identification.
o      Configuration files, remove – optional – filename that contains any
configuration for this service. It should be an XML file. If there are
configuration files they should be identified?Config data is really about a
service instance and not for the ‘WSDL.Service’concept. Move to service
instance

This is as far as the discussion progressed. The following is the rest of
the section to be discussed on our next call on Jan 9th.
      Configuration Information
o     Admin URL – (optional) URL to access that supports administering this
service
o     Admin WSDL URL
o     Management URL – URL to access that supports a w3c recommended
management protocol to access the data defined in this specification for
this service
o     Management WSDL URL – the url for the management url’s WSDL. If we
have this, do we need management url since it’s the location in the port
definition and may vary for read/only vs reconfigure ports.
o
o     Security settings – optional This needs more thought and exploration
with ws-security



Metrics

   Metrics to help track usage of the service and execution environment.
   This was intended to be counts for the life of the service.. (since it
   was enabled, not since instantiated) or WSEE. Should we keep timestamps
   for each metric to scope the counts/averages?
·     Availability time – what time the service was enabled.
·     Number of Requests – total  number of web services requests for this
service
·     Number of Success Responses – total number of success responses sent
by this service We need to define ‘successful’
·     Number of Failure Responses – total number of failure responses sent
by this service . We need to define ‘failure’ response
·     Average Response Time of Responses – the average response time for
all responses from this service. The timestamp should be taken as soon as
it enters the service and again just as it responds.  It will be the
aggregate of the time spent in the service itself.
·     Average Response Time of Failure Responses - the average response
time for all failure responses this service. The timestamp should be taken
as soon as it enters the service and again just as it sends the response.
It will be the aggregate of the time spent in the service itself.
·     Average Response Time of Successful Responses - the average response
time for all successful  responses for this service.  The timestamp should
be taken as soon as it enters the service and again just as it sends the
response.  It will be the aggregate of the time spent in the service
itself.
·     Total Elapsed Execution Time – the total ms spent processing in the
web service for all requests (can then calculate average)
·     Success Response Execution Time
·     Failure Response Execution Time  (or is this total-success)
·     Number of Invocations Per Method – the number of requests for each
operation/method supported by the service
·     Number of Successes Per Method
·     Number of Failures Per Method - the number of failures returned by
the service for each operation/method supported by the service (or is this
total-success)
·     Average Response Time of Responses per Method - the average response
time for all responses for each method.  The timestamp should be taken as
soon as it enters the method and again just as it exits the method.  It
will be the aggregate of the time spent in each method.
·     Average Response Time of Failure Responses per Method - the average
response time for all failure responses for each method.  The timestamp
should be taken as soon as it enters the method and again just as it exits
the method.  It will be the aggregate of the time spent in each method.
·     Average Response Time of Successful Responses per Method - the
average response time for all successful responses for each method.  The
timestamp should be taken as soon as it enters the method and again just as
it exits the method.  It will be the aggregate of the time spent in each
method.
·     Success Elapsed Execution Time per Method
·     Failure Elapsed Execution Time per Method (or is this Total-success)
·     Total Elapsed Execution Time per Method – the total ms spent
processing this method in the web service for all invocations
·     Number of Invocations per Attachment (?) – number of times an
attachment is sent to the web service
·     Number of Invocations per Message (?) – number of times a message
element is sent to the web service (for doc styles counting?)
·     High/Low water marks?
·     Rate of invocation?




Operations

   Operations to control service lifecycle, deploy, remove, start, and stop
   are part of the execution environment’s operations. They could be moved
   to the service specific MBeans, but it’s a 50-50 choice so for these
   examples, they are part of the execution environment MBean.
·     Deploy – have service start its deployment
·     Undeploy – have service start its undeployment
·     Enable – allow this service to be invoked to respond to a request
·     Disable – stop this service from being invoked to respond to a
request



Events

   The notifications should be sent by the execution environment for each
   service,  including:
o     service not deployed – tried to enable or request to a service that
is not depoyed in wsee
o     service unavailable – tried to request on a service that is deployed
an dis not enabled
o     service failed – request to the service failed
o     service deployed – lifecycle event that a service has been deployed
   service access denied – security denial
o     service invocation failed – a request to the service has failed
within the service implementation (not via the wsee)
o     service not found –the service is deployed and enabled but not
invocable
o     service timed out – request to the service timed out Where do we get
the timeout value?
o     service deploy failed – deployment of the service failed
o     service enable failed – enabling the service failed


Heather Kreger
Web Services Lead Architect
STSM, SWG Emerging Technology
kreger@us.ibm.com
919-543-3211 (t/l 441)  cell:919-496-9572
Received on Thursday, 19 December 2002 17:40:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:11 GMT