1. Implementation of the INFOD System using AOP
The Thesis Defense for M.Eng. (Software Engineering)
Author: Flannan Lo
Date: August 28, 2007

2. Abstract Objectives Background Design and Implementation Evaluation
Future Work
Conclusion

3. Objectives
Experiment with AOP throughout the entire software development cycle.
Identify the crosscutting concerns, i.e., the aspects, as many as possible.
Draw some lessons learned by applying AOP to a large-scale system.

4. Background

5. What is the INFOD System?
Web
Service
Web
Service
Publisher
Consumer
Subscriber
Subscription
Registry
Registration
Notification
Flow of Data
INFOD stands for Information Dissemination, is a system uses notification mechanism to make data source available to consumers.
Publisher is an entity registered in the INFOD system, which is responsible to generate and send messages to consumers.
Consumer is an entity registered in the INFOD system, which can receive messages from publishers.
Subscriber is an entity registered in the INFOD system. It is the only entity that can create subscriptions in the system.
Subscription is an entity that is internal to the system. It specifies the message flow from publishers to consumers and also the data interested to the consumers.
Registry is the data centre of the INFOD system. It is a resource manager that manages entities and data in the system.

6. What is Aspect-Oriented Programming?
Without AOP:
A new programming technique to use to separate concerns that cut across a software system.
Examples of crosscutting concerns:
Security
Exceptions Handling
Logging and Tracing
Programming languages for implementing AOP
AspectJ
AspectC
With AOP:
Offers a new paradigm to software development to modularize concerns that cross cut in a software system.
These concerns are usually scattered across the system and cannot be cleanly decomposed from the rest of the system.

7. What is AspectC?
An extension to C language to allow implementation of AOP in C.
Contains two types of files:
Core
Aspects
Join points
Advices
A core contains a limited number of essential functionalities of a software system that serve as the base of the system to allow further customization.
An aspect address a crosscutting concern. It contains join points and advices that can alter the behaviour of the base code by applying the advices before, after or in place of the program execution when a join point is reached.
A join point is a point in the control flow of a program. It is where the main program and the aspect meet.
An advice describes a certain function that can be applied at a given join point of a program.

8. Design and Implementation

9. How do we design the INFOD System?
Identify the core program.
Identify the aspects.

10. Identify the Core Program
According to the INFOD specifications, the APIs are divided into 7 categories:
Managing Publishers  Publisher Manager
Managing Subscribers  Subscriber Manager
Managing Consumers  Consumer Manager
Managing Subscriptions  Subscription Manager
Managing Vocabularies  Vocabulary Manager
Managing Associations  Association Manager
Managing Registry  Registry Manager
The INFOD specifications is an open, public specifications is designed by a number of people from IBM and Oracle in the Grid community.
Since these APIs do not cross cut the INFOD system and they are the entry points to the INFOD system, they are identified as the core of the system.

11. The Core Program
Utilities class provides utility methods that can be shared by all managers in the core system.

12. The Next Step: Identify Aspects
We apply two approaches to identify the crosscutting concerns, i.e., aspects, in this project.
Use Case Scenarios
Horizontal Decomposition Principles

13. Identify Aspects using Use Case Scenarios
Define use cases for the INFOD system from the requirements.
Each use case is described in details by categorizing its message flow in:
Base Flow
Alternate Flow
Sub-flow
An aspect must satisfy two criteria:
The requirement is described in either an alternate flow or a sub-flow.
The requirement is crosscutting.
The use case scenario approach is described in the book, Aspect-oriented Software Development with Use Cases by Ivar Jacobson and Pan-Wei Ng.
A base flow describes the activities that are normally done from the starting point to the ending point.
An alternate flow describes the activities that branches out from the base flow when certain conditions are met.
A subflow describes the activity that overrides another activity in the base flow. E.g., book a room and book a hotel room.

14. An Example Use Case 1: Create a Publisher Base Flow: Alternate Flow:
The use case begins with the arrival of a request message to create a publisher.
The message is passed into an XML Parser.
The manager validates the request.
The manager Insert Registry for the new entity.
The manager creates a response message.
The manager returns the message to the requesting service.
The use case terminates.
Alternate Flow:
No Authorization on Creation
No Authorization occurs at step 3 of the base flow.
The manager checks if the user is authorized to add a new entity.
If not, the manager creates a fault message. (CreateEntityAuthorizationFailure).
The base flow terminates.

15. An Example (cont.) Use Case 2: Create a Property Vocabulary Base Flow:
The use case begins with the arrival of a request message.
The message is passed into an XML Parser.
The manager validates the request.
The manager Insert Registry the new vocabulary.
The manager creates a response message.
The manager returns the message to the requesting service.
The use case terminates.
Alternate Flows
No Authorization on Creation
No Authorization occurs at step 3 of the base flow.
The manager checks if the user is authorized to add a new vocabulary.
If not, the manager creates a fault message. (RegisterVocabularyAuthorizationFailure).
The base flow terminates.

16. An Example (cont.)
By analyzing these two use cases, the feature for No Authorization on Creation is an aspect.
It is crosscutting because both use cases use it.
It is an alternate flow in both use cases.

17. Identify Aspects by applying Horizontal Decomposition Principles
These principles are discussed in the paper, “Resolving Feature Convolution in Middleware Systems” in OOPSLA04.
From these principles, we derive a set of criteria to identify aspects:
The feature must address a crosscutting concern.
The feature will likely be updated or replaced in the future.
The feature is optional.

18. An Example
We want to see if attaching SOAP header to a message can be implemented as an aspect.
Supporting soap can be aspect?

19. An Example (cont.)
This feature is crosscutting.
Change… animation

20. An Example (cont.)
This feature will likely be upgraded or replaced in the future.
Different environment may have a different protocol to exchange messages.
We may want to update the SOAP version, e.g. from 1.1 to 1.2.
IIOP (Internet Inter-ORB protocol) instead of CORBA … application message protocol

21. An Example (cont.) This feature is optional.
In a local environment, the SOAP header may not be necessary since we can directly do a procedural call.
Because it satisfies the criteria derived from the horizontal decomposition principles, attaching SOAP header can be implemented as an aspect.

22. INFOD System Aspects
By using the two approaches, we successfully identify a list of aspects.
Aspects identified by the use case scenario approach:
Message Filtering
Drop Unused INFOD elements
Disable New INFOD elements
Error Handling
Aspects identified by the horizontal decomposition principles approach:
Attach SOAP Header
Remove SOAP Header
Remove INFOD References
Authorization Failure
Logging and Tracing
Remove Namespaces
Remote Access
High Performance

23. Evaluation

24. System Product Family

25. System Product Family Member
Core Modules
Aspect Modules
INFOD base system with no aspects
Publisher Service
Consumer Service
Subscriber Service
Subscription Service
Vocabulary Service
Registry Service
Association Service
None
INFOD base system with exception handling
Authorization
Error Handling
INFOD base system with SOAP support and exception handling
Attach SOAP Header
Remove SOAP Header
Provide a name for the member

26. Implementation Summary
Number of INFOD system aspects identified 12
Number of INFOD system configurations
1024
Number of lines of code in the core system
2512
Number of lines of code in all aspects
2905
Average time to build a configuration
1.92 min
Average time to test a configuration
3.95 min
I found one thing is that as we have fewer aspects woven in, the time required to build the system becomes shorter.
Describe this table
Show number of aspects, size of the code, how many aspects in design/implementation, executable size

27. Performance Number of Requests
Average Time Required to Handle the Requests (in seconds)
System with Features Built-in
System with Aspects
500 29
29.6
2000
368.6
369.4
C implementation of features vs aspect implementation of features
In these 2 slides, show the average time of the run instead of showing all individual runs.

28. Comparison on the two Approaches
Both approaches, use case scenario and horizontal decomposition principles, are very similar in identifying aspects.
The approach derived from horizontal decomposition principles may identify more aspects in the base flow in a use case scenario.
Both approaches are very similar. Most of the aspects identified in this project can be identified using either approach.
In the use case approach, the aspects can be identified in the subflow or alternate flows, but the second approach may allow you to identify aspects in the main flow in a use case scenario.
This is lesson learned
Give number of aspects identified by each approach

29. Evaluation on AOP
Realizing crosscutting concerns is done in the entire software development cycle.
Aspects identified in design phase
Aspects identified in implementation phase
Attach SOAP Header
Remove SOAP Header
Message Filtering
Drop Unused INFOD Elements
Disable New INFOD Elements
Authorization Failure
Error Handling
Logging and Tracing
Remote Access
High Performance
Remove INFOD References
Remove Namespaces
Identifying aspects is difficult.
For example, manipulating the INFOD registry is identified to be an aspect candidate in the design phase. But since it is so mandatory to the INFOD system, I find that it is impossible for the core system to live without it, and so I need to implement it as part of the core instead.
Give example

30. Evaluation on AOP Logging and tracing is a typical aspect.
Problem: Due to the limitations of the aspect programming language, it cannot support a thorough tracing of a system.
Solution: Break down the core functions in smaller pieces.
Solution: Insert trace statements in the middle of the core functions.
Problem of the solution 2: the logging and tracing facility is scattered around the system.

31. Guidelines to Implement System using AOP
Isolate the aspects and the core.
Ensure that the core system can work properly without the aspects.
Isolate the implementation of the core and the aspects.
Make debugging easier.
We should isolate the aspects and the core as much as possible because:
We want to ensure the core system can live without any aspects.
We also want to isolate the implementation of the core and aspects. We should fully implement and test the core system before starting to implement and test the aspects. This makes debugging easier because if a problem occurs after an aspect is woven into the core, we can assume that the problem occurs at the aspect and so it can save us time to locate the problem.

32. Future Work
Deploy the INFOD system in a real client-server environment.
Implement security support as aspect in the INFOD system.
The INFOD system is originally designed to deploy on a web service environment.
Due to the time limitation, I am only able to implement the INFOD system to use C sockets.
It will become interesting to see how it behaves in a web server-client environment.
Since the system is deployed on a web service environment, web security becomes an important issue.

33. Conclusion
We successfully develop a system using AOP during the entire software development cycle.
By applying AOP in the entire software cycle, we are able to identify many aspects in the system.
12 aspects in total.
46% core vs. 54% aspects (in lines of code).
We successfully use two approaches to identify aspects in the INFOD system.
Use case approach
Horizontal decomposition principles approach
We provide some guidelines on how to implement a system using AOP.
Isolate the core and aspects as much as possible.
Implement and test the core and the aspects in order and separately.

34. Questions?

35. Test Strategy
We produce 1024 different configurations of the INFOD system.
Problem: Takes too long to test the system in conventional way of testing.
Solution: Apply AOP to do the testing too.

36. Comparison on Testing Methods
Test Strategy using AOP approach
Test Strategy using non-AOP approach
Requires fewer test cases to cover all the implemented features.
Requires more test cases to cover all the implemented features.
Requires more time to compile the test cases because the test case aspects need to be woven into the core test cases.
Requires less time to compile the test cases because the system can be built into a library.
Requires more thoughts when designing the test case aspects to make sure they do not contradict to each other.
All test cases are independent from each other.
Test data sets are managed in the core test cases and the test case aspects. The test case aspects generate test data sets from those in the core test cases.
Test data sets are finite and managed solely by each individual test case.