4 DESIGN 

4.1 Introduction 

The previous chapter highlighted the requirements for monitoring Web delivered services 

and identified parameters to capture and the options that exist to capture them. This chapter 

will first examine the possible architectures to support such service monitoring and then 

discuss the design of the components that enable such monitoring to take place. 

4.2 Architectures for Service Monitoring 

Having determined the type of information that should be captured for a service, the use of 

that information can be varied. In most cases, information captured on a service will be used 

by: 

The Customer to determine if a Service is performing as specified in a SLA 

The ASP provider to determine if the service it's providing is meeting the SLA  

with it's customer and possible to be alerted to service faults 

A number of architectures to monitor Web delivered services will now be examined. The 

strengths and weaknesses will be highlighted for each one. Some architectures result in a 

more efficient and flexible Service monitoring and reporting. For example, if a proxy is used 

to monitor a service and has access to a SLA for that service, a certain amount of data 

analysis can be done by the proxy and then appropriate action taken depending on the result 

of that analysis. If the proxy does not have the SLA it may have to return the information 

logged for all HTTP requests to the party monitoring the service performance before 

performance and availability issues can be highlighted to the ASP and customer. This also 

results in a greater amount of data being transferred and analysed remotely, which may not 

be a very scalable solution. This just highlights some of the choices that must be made when 

deciding on how information is exchanged between a Customer, Service provider and a third 

party 

$