Information Technology Reference
In-Depth Information
utes later. The SLA service can infer that
300 CPU.seconds of CPU time have been
used (1*5*60 = 300 CPU.seconds).
response defined by the PullPoint interface in the
WS-BaseNotification specification. The response
to this request contains zero or more notification
messages as defined by WS-BaseNotification, as
shown in Figure 3.
Each NotificationMessage element should
contain a usage report message from a single
activity, and should give the activity's EPR as the
ProducerReference. A single GetMessages re-
sponse can contain several NotificationMessage
elements, which mean the application service can
generate messages from an activity at times of its
choosing, and cache them until a GetMessages
request is received. But the WS-BaseNotification
requires that the producer should only send a
message once to the recipient, so the application
service will need keep track of which messages
have been delivered. The notification message
format is also defined by WS-BaseNotification,
as shown in Figure 3.
If a service reported that it had used 120
units of a resource in a 1 minute period, the
SLA service would infer that the average
instantaneous measurement (rate of usage)
had been 2 units/s.
Service Monitoring
Service monitoring involves providing the SLA
manager with a document containing usage reports
from each activity supported by the service. In
principle, this can be an asynchronous message
from the application service to the SLA manager.
The GRIA middleware (v5.3.1) proposed to use the
WS-BaseNotification specification (http://docs.
oasis-open.org/wsn/wsn-ws_base_notification-
1.3-spec-os.pdf) for implementing the service
monitoring (http://www.gria.org/about-gria/
relationship-to-standards. Access date: 22 Sept.,
2010). It suggested that the full implementation
would involve a lot of software development;
hence we could let the SLA manager poll for usage
information, using one specific WS-BaseNotifi-
cation method. The agile software development
approach can then be employed to extend the
implementation of the support of push and bro-
kered messaging iteratively and incrementally. Ap-
plication services should support this by providing
the message retrieval (GetMessages) request and
QoS-Assured Service
Once the service is monitored, we can analyze
the acquired QoS measurement data to guaran-
tee the quality of the service. This involves the
issue of capacity management, which concerns
with resources being able to adapt themselves to
meet the live requirements of service processes
to ensure that the whole service provisioning will
remain within performance compliance. This
means the execution of trend analysis on historical
Figure 3. WS-Notification Specification Fragment
Search WWH ::




Custom Search