Information Technology Reference
In-Depth Information
behavior RSSBehavior()
{
//Instance variable declarations...
octet[] examples::bette::SlideShow.:read (in long gifNumber)
{
return_value octet[] result;
local instr::Trace_rec rec;
Method
Join Point
after METHODENTRY {
methodlD = "read";
rec = rssQosket.createTraceRec(methodlD);
}
inplaceof METHODCALL {
region slow {
java_code #{
iServer =
(com.bbn.quo.examples.bette.SlideShowlnstrumented)
rssQosket.getlnstrumentedServer();
}#;
instrumented_result = iServer.read(gifNumber,rec);
result = instrumented_result.getBytes();
rec = instrnmented_result.getRecord();
}
}
};
Advice
Region
Advice
Figure 3.6.
QuO ASL example.
This approach presents the possibility of operating systems being able to be
modularised to a far greater extent than that which is currently possible and, as
described above, provides the possibly to add autonomic computing functionality.
3.7.2
The QuO Toolkit
Middleware technologies, such as CORBA [77], allow the development of dis-
tributed applications without the developer needing to be aware of details of the
distribution technology involved. As these applications may be distributed across
a number of different physical machines connected via one or more networks, the
applications concerned may need to adapt to the changing network and system
conditions to maintain an acceptable quality of of service (QoS).
Duzan et al. [30] have developed the QuO toolkit which builds QoS as an
aspect and weaves the aspect into the boundary between the application and the
middleware. QoU defines an aspect model, which includes join points specific
to distribution and adaption, and an adaption model which defines the adaption
strategy to be used. The QuO toolkit consists of four main entities [30]:
1. Contracts, which are used to define an adaption policy in QuO. Contracts
are defined using QUO's Contract Definition Language (CDL).
2. System Condition Objects, which are used to monitor the environment.
Search WWH ::




Custom Search