1. Composition Filter – Part 2 איתי בן אליעזר נובמבר 2004

2. What’s next ? Examples of the composition filter. ComposeJ. Conclusions about the composition filter. Composition filter vs. aspectJ and HyperJ.

3. An example Suppose we have an agency that deals with disablement insurance laws.

4. An example There are five tasks here: RequestHandler create a document for clients. RequestDispatcher implements the evaluation and distribution of the documents to the necessary tasks. MedicalCheck is responsible for evaluating the client’s disablement. Payment is responsible for issuing bank orders. OutputHandler is responsible for communicating with the clients.

5. Model Client’s request (Document) For each client’s request,a document is created. Depending on the document type and client's data, the document is edited and sent to the appropriate tasks using a standard email system. Class Document is the root class of all document types. There are several classes which inherit from the class Document. For example, ClaimDocument is used to represent the claims of clients.

6. Document hierarchy

7. Model

8. How does the model work ? A client wants to issue a claim. RequestHandler creates a ClaimDocument. It retrieves the client’s data and open the document’s editor. The clerk enters the data to the RequestHandler. The operation forwardDocument prepares the document and passes it as an argument to the operation processDocument on the next task. The next task receives the document and goes on with the process.

9. Model’s improvement (1) Protecting Documents In the initial position, a clerk could edit any field in a document. A request dispatcher clerk could, for instance, accidentally edit the medical data field. To avoid this, the implementation of methods should be extended with some source code that verifies the identity of the caller.

10. Protecting Documents Inheritance-based solution ProtectedClaimDocument inherits from ClaimDocument. Declares a new operation called activeTask that returns the identity of the active task. 15 operations should be redefines in the new model. In the next page we can see the changes in the code.

11. Protecting Documents

12. Protecting Documents: CF-based solution the operation ~> get every message except the ones that are specified on right-hand side. A CF class aggregates zero or more internal classes. Implementation of the class.

13. Protecting Documents: CF-based solution concern ProtectedClaimDocument begin filterinterface documentWithViews begin internals document: ClaimDocument; externals // no externals defined by this class conditions activeRH; activeRD; activeMC; activeP; activeOH; methods activeTask(); Inputfilters protection: Error = { activeP => {putApprovedClaim, approvedClaim}, activeMC => {putMedicalCheckData, medicalCheckData}, … // etc. for the other views}; inh:Dispatch = { inner.*, document.* }; end filterinterface DocumentWithViews; Implementation // introduced in the next page End implementation end concern ProtectedClaimDocument; Internal objects are encapsulated within the CF object External objects are references to objects outside the CF object, such as global objects Condition and Methods are defined in the implementation => inner is a pseudo variable that refers to the implementation object document was declared as internal object

14. Protecting Documents: CF-based solution implementation in Java // for example class ProtectedClaimDocument { boolean activeRH() { return this.activeTask().class()!=RequestHandler }; boolean activeRD() { … }; boolean activeMC() { … }; boolean activeP() { … }; boolean activeOH() { … }; String activeTask() { … }; } end implementation

15. Model’s improvement (2) Adding workflow In the previous implementation, the clerks had to decide which task to be executed next. To enforce a process, class WorkFlowEngine is introduced. The operation selectTask accepts a document as an argument and based on the workflow specification and the state of the document, returns the identity of the next task.

16. Adding workflow Inheritance-based solution Adding a workflow to the system requires redefinition of forwardDocument for all task classes. The forwardDocument first calls on selectTask of WorkFlowEngine, which returns the next task.

17. superimposition So far, we have shown only examples of behavior that crosscuts a number of methods within a single object. Now,We need to deal with concerns crosscut multiple objects.

18. superimposition The declaration of a filterinterfacehas been separated from its instantiation and multiple declarations are allowed. Multiple instantiations of filterinterfaces are possible. Incoming and outgoing messages have to pass through all the instantiated filterinterfaces. superimposition element specifies where filterinterfaces are superimposed: on the concern itself, or on other concerns.

19. Adding workflow: CF-based solution concern WorkFlowEngine begin // introduces centralized workflow control filterinterface useWorkFlowEngine begin // this part declares the crosscutting code externals wfEngine : WorkFlowEngine; inputfilters redirect : Meta = { [forwardDocument]wfEngine.selectTask } end filterinterface useWorkFlowEngine; filterinterface engine begin //defines the interface of the workflow engine object methods selectTask(Message); setWorkFlow(WorkFlow); inputfilters disp : Dispatch = { inner.* }; // accept all methods implemented by myself end filterinterface engine; … Declare a shared instance for the concern Catch forwardDocument message, send it to wfEngine, as an argument to selectTask message. selectTask determines the next task that should handle the document

20. Adding workflow : CF-based solution … superimposition begin selectors allTasks = { *=RequestHandler, *=RequestDispatcher, *=OutputHandler, *=MedicalCheck, *=Payment}; filterinterfaces self <- self::engine; allTasks <- self::useWorkFlowEngine; end superimposition; implementation in Java; class WorkFlowEngineClass { WorkFlow workFlowRepr; void selectTask(mess Message) { … }; void setWorkFlow(WorkFlow wf) { … }; } end implementation; end concern WorkFlowEngine; Define allTasks as all the objects that are instances of this classes Instances of WorkFlow Engine have engine filterinterface The allTask instances have useWorkFlowEngine

21. How does it works? There is a useWorkFlowEngine filter on every task. When a task get a forwardDocumennt message, the Meta filter send the message to wfEngine as an argument to the selectTask message. wfEngine gets the message through the engine filter, manipulate it and fire it to the task.

22. Model’s improvement (3) Adding Document Queues Each document in the process may require a different processing time. To improve the average throughput, a document queue is defined for every task. There is a buffer for every task class. The operation processDocument has to be mutual exclusive.

23. Adding Document Queues Inheritance-based solution The synchronization code must apply to every task processor class. It is repeated within the implementation of several methods of the “task processor” class. This is a typical example of crosscutting behavior.

24. Adding Document Queues : CF-based solution concern MutEx begin // implements the mutual exclusion synchronization concern filterinterface mutExSync begin conditions NoActiveThreads; inputfilters buffer : Wait = { NoActiveThreads=>* }; end filterinterface mutExSync; superimposition begin // not imposed anywhere; abstract concern end superimposition; implementation in Java; class MutExSupport { Boolean NoActiveThreads() { … }; } end implementation; end concern MutEx ; If (NoActiveThreads == false) than it wait

25. Adding Document Queues : CF-based solution concern ConcurrentDocumentProcessing begin // allows concurrency without interference superimposition begin conditions WorkFlowEngine::allTasks <- MutEx::NoActiveThreads; filterinterfaces WorkFlowEngine:: allTasks <- MutEx::mutExSync; end superimposition superimposition; end concern ConcurrentDocumentProcessing; Every task calls the mutExSync filter if the NoActiveThreads is false

26. Model’s improvement (4) Adding logging One of the important concerns of the workflow system is to monitor the process. All the interactions among objects are registered. Class Logger is introduced to register the interactions in the system.

27. Adding logging Inheritance-based solution Adding a logging facility also requires redefinition of all methods of task and document classes. This is because before executing any call, the operation log of Logger must be called.

28. Adding logging: CF-based solution concern Logging begin // introduces centralized logger filterinterface notifyLogger begin externals logger : Logging; internals logOn : boolean; methods loggingOn(); logginOff(); log(Message); conditions LoggingEnabled; inputfilters logMessages : Meta = { LoggingEnabled=>[*]logger.log }; dispLogMethods : Dispatch = { loggingOn, loggingOff }; end filterinterface notifyLogger; Declare a global object logger Used to enable and disable the logging of messages Turn on and turn off the logOn field This interface will be on all the instances except of logging Get information from message and store it When logOn is turned On,pass it to logger as an argument Pass the loggingOn and loggingOff methods

29. Adding logging: CF-based solution filterinterface logger begin //defines the interface of the logger object itself methods log(Message); inputfilters disp : Dispatch = { inner.* }; end filterinterface logger; superimposition begin selectors allConcerns = { *!=Logging }; conditions allConcerns <- LoggingEnabled; filterinterfaces allConcerns <- notifyLogger; self <- logger; end superimposition superimposition; accept all methods implemented by myself Every instances except instances of Logging will get notifylogger filter The filter logger is on the logging instance

30. Adding logging: CF-based solution implementation in Java; class LoggerClass { boolean LoggingEnabled() { return logOn }; void loggingOn() { logOn:=true; }; void loggingOff() { logOn:=false; }; void log(Message mess) { … }; } end implementation; end concern Logging; get information from message and store

31. Model’s improvement (5) Adding locking It was found necessary to temporarily lock a task or document, for instance, for reallocating resources, debugging or for obtaining a snapshot of the system. For every class in the system, the operations lock and unlock are introduced. The operation lock queues all the requests unless unlock is invoked.

32. Adding locking Inheritance-based solution If a the semaphore-like mechanism is used to implement locking, every operation of a class has to be redefined.

33. Adding locking: CF-based solution concern Locking begin // implements the locking synchronization concern filterinterface lockBehavior begin internals lockState : boolean; methods lock(); unlock(); conditions unLocked; inputfilters lockAll : Wait = { unlock, unLocked=>* }; disp : Dispatch = { lock, unlock }; end filterinterface lockBehavior; superimposition begin // this is an abstract concern end superimposition; state is true when locked Wait filter that blocks all messages except the unlock message when the concern is in the locked state or messages when it isn’t locked.

34. Adding locking: CF-based solution implementation in Java; { class LockingSupport{ void lock() { lockstate:=true }; void unlock() { lockstate:=false }; boolean UnLocked() { return !lockstate; }; boolean Locked() { return lockstate; }; } end implementation; end concern Locking;

35. Adding locking: CF-based solution concern WorkflowLocking begin // applies the locking concern to the workflow appl. superimposition begin selectors applObjects = {*:Document, *:TaskProcessor}; methods applObjects <- {Locking::lock, Locking::unlock}; conditions applObjects <- Locking::UnLocked; filterinterfaces applObjects <- Locking::lockBehavior; end superimposition ; end concern WorkflowLocking; selector includes all instances of TaskProcessor and Document If (lockState==false) It use the lockBehavior

36. ComposeJ ComposeJ implements an extension of the java language that adds Composition Filters to Java classes through inlining. The first prototype was created in 1999, as part of Hans Wichman's MSc. ComposeJ implements the Error and dispatch filters. The ComposeJ system is an add-on to a standard Java compiler. The ComposeJ system is built for Java 1.1. However, the way it is designed and implemented, it can easily migrate to Java 1.2 or even Java 1.0.

37. ComposeJ ComposeJ is a compile time tool. The main reason for this approach is the performance loss in a run-time approach. ComposeJ translate the filters to an implementation where code is inlined in Java sources.

38. ComposeJ The composition filter grammar was adapted to the Java grammar.

39. Processing a ComposeJ file A ComposeJ file is processed by choosing the ‘Process Java with filters’ option from the Build menu. Extensive information about the current state of the process is printed to the debug window. When the processing finishes successfully, a new Java file is present in the same directory as the ComposeJ file.

40. The future of ComposeJ A future work is necessary to extend the system with other filter types and functionality. But the system requirements and the goal of the assignment have largely been met.

41. Composition filter - conclusions The CF approach can decrease the amount of source code. In more complicated problems it can be even more crucial. Declarative concerns are specified declaratively in a simple pattern matching language allowing various implementation strategies. For example, ComposeJ is a compiler,which adds inline filter code. The Sina language compiler implements filters as metaObjects.

42. Composition filter - conclusions Open ended new kind of concern semantics can be introduced as new filter types. High level semantics The semantics of filter types are well defined and highly expressive. We can see from the examples that the filters can express effectively the different tasks.

43. Composition filter - conclusions Strong encapsulation Superimpositions, objects,methods,and conditions are restricted to the interface level. Therefore superimposed concerns do not relay on the details of the implementation. Modular Unifies OOP with AOP.

44. Composition filter vs. aspectJ and HyperJ What are the common principle of aspectJ, hyperJ, and CF ? Crosscutting. aspectJ use pointcuts. hyperJ use HyperModule and HyperSlice. Composition filter use the filterinterface and superImposition.

45. Differences between CF and the other approaches. But, they see the aspects in a different way. CF partitions ‘aspect’ specifications per object, expressed in terms of message AspectJ uses a central aspect specification, that is integrated with the class hierarchies by using a so-called aspectweaver (preprocessor). In HyperJ, there are sets of Hyperslices that create a HyperMoudles.

46. Differences between CF and the other approaches. Encapsulation In CF,the implementation part is strongly encapsulated object. CF deals only with the interface level. AspectJ and HyperJ allow the crosscutting concerns (aspects) to 'break encapsulation', which makes the aspects less reusable and more vulnerable to implementation changes. They have structural and behavioral crosscutting.

47. Differences between CF and the other approaches. Semantics The semantics of the filter types are well defined and highly expressive. But there are only few filters. AspectJ and HyperJ are more general-purpose approaches than Composition filter. The concerns are less semantics.

48. Reference ”Composition Multiple Concerns Using Composition Filters” by Lodewijk Bergmans & Mehmet Aksit, University of Twente. ComposeJ – master of science thesis by Johannes Cornelis Wichman.

49. Questions ?