TEMÁTICA DE LOS LIBROS ADQUIRIDOS

We have developed experimental toolkit in C + + language, which enables static instrumentation of C + + source code with high-level of encapsulation. To accomplish this goal, the key idea of the toolkit is based on the technique from object oriented programming known as decoration. In this particular case, the decoration effect is achieved using template classes and operator overloading. Operator overloading is often considered to be quite dangerous technique, which affects the clarity of the source code and leads to errors due to unclear seman- tics of the overloaded operators. However, a variant of substitution principle defined in [2] may be used to demonstrate, that the mitigating factors of the described problems are minimised. Example source demonstrating the usage of the provided classes is shown in Fig. 2.2. The instrumentation is data-driven, the toolkit provides objects which encapsulate accesses to data (by variable as- signment statements) and data checks on such occasions by defining constraints.

The toolkit defines three basic constructs, which are used to implement in- strumentation: checked values (CheckedValue class), constraints ( C o n s t r a i n t class) and handlers (Handler class). Checked values are values which the pro- grammer considers to be significant, which would be ideally turned into metrics and made available to monitoring tools. Turning a value into a checked value is done by decorating it with the instance of the CheckedValue class. This also automatically registers the value as a metric, so the resulting executable is able to produce the list of available metrics automatically.

Checked values provide automated monitoring capability. A custom action is taken every time the value is modified (by assignment statement). This cus-

int m a i n ( i n t arge , char** argv)

{

/ / Monitoring—related code.

// Checked values must be less than SO.

C o n s t r a i n t < i n t , l e s s < i n t » t h r e a d L i m i t =

new C o n s t r a i n t <int , less < i n t > > ( " t h r e a d L i m i t " , 20);

/ / We are going to define the threadCount metric. CheckedValue<int> t h r e a d C o u n t =

new CheckedValue<" t h r e a d C o u n t " , i n t > ( ) ;

i . a d d C o n s t r a i n t ( " t h r e a d L i m i t E x c e e d e d " , t h r e a d L i m i t ) ; / / Our trivial code.

while (1)

{

w a i t F o r R e q u e s t () ; c r e a t e T h r e a d ( ) ;

threadCountH—h; / / changes are reported automatically

Fig. 2: Simple Example in C + +

torn action is called a notification and is specified by registering instance of the

Handler class with the checked value. Also, it is possible to define constraints on

the checked value to associate different actions with different conditions. Con- straint is defined by registering one or more instances of the C o n s t r a i n t class with the checked value.

Consider a simple example. In your custom service, a pool of threads exists to handle requests from users. The number of threads in the pool depends on the number of requests received per hour and increases with increasing amount of requests. We want to monitor the load of the service and react when the service becomes overloaded - the number of threads in the pool exceeds some predefined value. If your code contains a thread count value, it is simple to implement the described functionality. The value is turned into checked value and a constraint which checks the value is defined. The source code of the service is not affected. Only a simple initialisation code is added.

2.2.1 Performance Overhead Evaluation

We have evaluated overhead of the created toolkit on a set of sequential programs which implement vector and matrix multiplication. Vector and matrix elements are checked values. Our test suite contains three classes of tests, which implement the same functionality only differ in terms of monitoring support. The test classes follows:

test class lines of code memory usage runtime sees. plain classic encapsulated 245 315 250 77 MB 77 MB 78 MB 1.95 + / - 0.02 2.54 + / - 0.04 2.61 + / - 0.07

Tab. 1: Measured Overhead (avg. from 100 iterations)

Runtime in s e c o n d s (100 iterations)

13 16 13 22 25 31 34 37 43 43 46 43 52 55 67 73 73 76 73 31 34 37

Fig. 3: Runtime in seconds (100 iterations)

• classic tests, which contain monitoring code, but the instrumentation is implemented manually

• encapsulated tests, which contain monitoring code, implemented using the described toolkit

Overhead has been measured in terms of required memory usage, running time in seconds and lines of source code required to implement the test. The smaller the better rule applies to all three measured characteristics.The measured results are summarised in the table 2.2.1. Running time of the tests is shown in Fig. 2.2.1 in detail.

It is obvious from the results and also expected fact, the introducing mon- itoring support imposes some memory and processing time overhead. Memory overhead can be observed between the plain version and encapsulated version. Object oriented code is naturally more memory consuming that the straightfor- ward sequential code (classic test suite) with instrumentation hooks. However, important observation is that the overhead difference between classic and encap- sulated test suite is minimal. The cost of encapsulation in terms of processing time is relatively small. The difference is caused mainly by using virtual meth- ods in the toolkit classes to allow greater flexibility and better encapsulation. This however indicates, that the chosen approach may be viable.

2.2.2 N o t e on Implementation Techniques

The chosen implementation techniques are not available in general - many programming languages restrain from supporting generic programming (tem- plates) and/or operator overloading to the required extent. When we would like to develop a useful toolkit endorsing the monitoring support for different programming language, we may need to leverage different mechanism.

One of the promising approaches is using aspects from Aspect Oriented Pro- gramming [4] paradigm. Aspects can be seen as a duality of objects from ob- ject oriented programming. Roughly speaking, objects correspond to problem domain entities, which together comprise the application logic. This may be seen as a vertical crosscutting of the problem domain. Aspects, on the other hand, are the horizontal crosscutting concept. They allow to consolidate vari- ous mechanisms which are present in all objects, such as persistence, security, logging and monitoring, into a single entity. By leveraging this functionality, a function-driven monitoring toolkit may be built which, again, will deliver con- venient encapsulation of the monitoring internals and their separation from the programmer. We currently work on a working prototype of this approach in Java using Aspect J toolkit[3]. Aspect Oriented Programming toolkits are also available for other programming languages, such as C + + or C # so the resulting prototype would be portable into other languages as well.

2 . 3 C o n t r a c t - b a s e d M o n i t o r i n g

From the point of view of software engineering, middleware implementation is a complex task. We have demonstrated relatively straightforward techniques, which lead to simplification of the implementation of instrumentation based monitoring techniques and clarification of the source code. These qualities have important impact on the maintainability of the software product, grid middle- ware services in our particular case.

However, the discussed approaches offer only fairly limited set of functional- ity. When requirements for more complex monitoring schemes arise, the com- plexity of the required solution grows significantly. Thus, we have observed that a more sophisticated approach could be taken to minimise this complexity grow- ing effect. We introduce a technique, called Contract-based Monitoring which has evolved from the ideas described in this paper. Contract-based monitoring is based on extending the source code of a monitored service or resource with constructs similar to those known from the Design by Contract [5]. Design by contract allows the programmer to specify pre- and postconditions and invari- ants related to various source code constructs (functions, object methods, loops, etc). These constructs are specified in a declarative manner, i.e. the programmer does not specify when and how the conditions and invariant checks are carried out. Only what conditions must be met is to be specified. This approach is an extension of the Design by Contract to allow declarative specification of execu-

tion conditions of the respective source code and definition of monitoring policy

t u s . T h i s policy is governed by t h e decision of t h e p r o g r a m m e r , b u t t h e policy m a y also b e e x t e n d e d by t h e technical p e r s o n responsible for t h e d e p l o y m e n t a n d m a n a g e m e n t of a p a r t i c u l a r instances of our m o n i t o r e d services.

However, t h e downside of this a p p r o a c h is t h a t it requires e n h a n c e m e n t s t o

t h e compiler of our chosen p r o g r a m m i n g l a n g u a g e or development of a source- ^ ^ code processing tool which would t r a n s l a t e our e n h a n c e d source code into a H compiler-accepted form. B o t h a p p r o a c h e s have a d v a n t a g e s a n d d i s a d v a n t a g e s

on their own, however t h e significant difference is t h a t c r e a t i n g a new compiler for a specifically tailored l a n g u a g e is a complex t a s k a n d would require effort of m a n y p r o g r a m m e r s w i t h t h e b u r d e n of m a i n t e n a n c e of such compiler. T h e l a t t e r a p p r o a c h is m u c h simpler, b u t would only provide functionality on t h e level of "syntactic sugar", w i t h o u t t h e chance of changing s e m a n t i c s of t h e chosen l a n g u a g e at all. However, it is n o t obvious w h e t h e r this is really required for t h e service m o n i t o r i n g p r o b l e m we have defined.

3 Conclusions

B a s e d on t h e identified p r o b l e m of i n s t r u m e n t a t i o n i m p l e m e n t a t i o n , we have d e m o n s t r a t e d t h e C + + m o n i t o r i n g toolkit which provides good results in t e r m s of e n c a p s u l a t i o n of t h e m o n i t o r i n g code a n d imposed performance overhead. However, we observe t h a t t h e functionality provided by t h e toolkit is n o t suf- ficient. T h e p r o b l e m is t h a t t h e used c o n s t r u c t s are n o t s u p p o r t e d in m a n y m a i n s t r e a m p r o g r a m m i n g languages a n d also we would like t o have m o r e pow- erful tools t o i m p l e m e n t i n s t r u m e n t a t i o n . We have identified two promising a p p r o a c h e s , using A s p e c t O r i e n t e d P r o g r a m m i n g a n d i m p l e m e n t i n g a novel tech- nique, called C o n t r a c t - b a s e d M o n i t o r i n g .

References

1. I. Foster, C. Kesselman. "The Grid 2: Blueprint for a New Computing Infras- tructure." Morgan Kauffman Publishers Inc. San Francisco, USA. 2003. 2. B. Liskov and J. Wing. "Family Values: A Behavioral Notion of Subtyping."

ACM Technical Report TR-562b. 1993.

3. Aspect J Project Website, h t t p : / / w w w . a s p e c t j .org

4. Aspect Oriented Software Development Portal, h t t p : / / w w w . a o s d . n e t

5. "Building bug-free O-O software: Introduction t o Design-by-Contract(TM)". h t t p : / / a r c h i v e . e i f f e l . c o m / d o c / m a n u a l s / t e c h n o l o g y / c o n t r a c t /