Interface annotator:
Abstraction is one of the pillars of Object Oriented programming. When applied to behavioral representation, it is demonstrated with the use of interfaces in language. An interface enables any class to implement a certain abstraction of behavior via the contract described. Unit tests are often written using the mocking of these interfaces. This facilitates tests to be written even before the classes are implemented. This notion is often referred as the Liskov Substitution Principle. The purpose of this writeup is to describe a user library that gather statistics on the call usages automatically.
Description: API monitoring and mechanics are well understood because we often leverage it in production support of critical API implementations. These monitoring services are configured to read the number of calls made, the failures associated and record metrics of availability and latency. Rules and alerts may also be written to take actions on the associated records. The purpose and pervasiveness of API monitoring is never questioned. However the work involved is significant and therefore applied to external facing services.
Developers generally do not have such instrumentation and call statistics other than profiling which comes at a very high cost. Something simpler in terms of just success failure and invocation counts cannot easily be determined from the runtime without some kind of instrumentation. Some do write annotations that can be added to methods to capture this information, however decorating each and every method is generally tiresome.
On the other hand, if every interface could gather such statistics and the results could be persisted from a run of the application, then such data could become valuable to query. Collecting information automatically on interfaces could be supported with the help of a library. In other words, monitoring as opposed to profiling could be helpful even pushed down to methods on the interfaces within a service and not just the methods that are externally facing and invoked via APIs.
Interfaces are used for several techniques one of which is the inversion of control principle. This lets implementations to be invoked from the interfaces so that they are automatically available within the service. Consequently unlike classes, they are heavily shared and statistics more appealing because the usage is not limited or scoped.
Conclusion: Simple statistics on interfaces if collected automatically could provide significant insight without the encumberance of profiling.
Courtesy : http://users.ics.aalto.fi/kepa/publications/KahLamHelNie-RV2009.pdf
https://ideone.com/saidLd
Abstraction is one of the pillars of Object Oriented programming. When applied to behavioral representation, it is demonstrated with the use of interfaces in language. An interface enables any class to implement a certain abstraction of behavior via the contract described. Unit tests are often written using the mocking of these interfaces. This facilitates tests to be written even before the classes are implemented. This notion is often referred as the Liskov Substitution Principle. The purpose of this writeup is to describe a user library that gather statistics on the call usages automatically.
Description: API monitoring and mechanics are well understood because we often leverage it in production support of critical API implementations. These monitoring services are configured to read the number of calls made, the failures associated and record metrics of availability and latency. Rules and alerts may also be written to take actions on the associated records. The purpose and pervasiveness of API monitoring is never questioned. However the work involved is significant and therefore applied to external facing services.
Developers generally do not have such instrumentation and call statistics other than profiling which comes at a very high cost. Something simpler in terms of just success failure and invocation counts cannot easily be determined from the runtime without some kind of instrumentation. Some do write annotations that can be added to methods to capture this information, however decorating each and every method is generally tiresome.
On the other hand, if every interface could gather such statistics and the results could be persisted from a run of the application, then such data could become valuable to query. Collecting information automatically on interfaces could be supported with the help of a library. In other words, monitoring as opposed to profiling could be helpful even pushed down to methods on the interfaces within a service and not just the methods that are externally facing and invoked via APIs.
Interfaces are used for several techniques one of which is the inversion of control principle. This lets implementations to be invoked from the interfaces so that they are automatically available within the service. Consequently unlike classes, they are heavily shared and statistics more appealing because the usage is not limited or scoped.
Conclusion: Simple statistics on interfaces if collected automatically could provide significant insight without the encumberance of profiling.
Courtesy : http://users.ics.aalto.fi/kepa/publications/KahLamHelNie-RV2009.pdf
https://ideone.com/saidLd
No comments:
Post a Comment