I2SD Reverse Engineering Sequence Diagrams from Enterprise JavaBeans with Interceptors
An Enterprise JavaBeans (EJB) interceptor is a software mechanism that provides for introducing behavior implemented as separate code into the execution of a Java application. In this way EJB interceptors provide a clear separation of the core functionality of the bean and other concerns, such as logging or performance analysis. Despite the beauty of the idea behind the interceptors, developing, testing and managing dependencies introduced by the interceptors are considered to be daunting tasks. For example, the developers can specify interceptors at multiple locations and by multiple means. However, different locations and specification means influence the order of the interceptor invocation, which is governed by more than fifteen different intertwined rules according to the EJB standard. To facilitate development of EJB applications we have designed I2SD, Interceptors to Sequence Diagrams, a tool for reverse engineering EJB applications with interceptors to UML sequence diagrams. I2SD provides the developer with a visual feedback and can be used by quality managers to get a broader understanding of the way interceptors are used in their project.
![PAGE 1 Interceptors ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (19)
Mais de Alexander Serebrenik
Mais de Alexander Serebrenik (20)
Último
Último (20)
I2SD Reverse Engineering Sequence Diagrams from Enterprise JavaBeans with Interceptors
- 1. I2SD: Reverse engineering sequence diagrams from Enterprise JavaBeans with interceptors SergueiRoubtsov Alexander Serebrenik AurélienMazoyer (Polytech’Nice-Sophia) Mark van den Brand
- 3. when a method is called
- 6. XML file
- 7. Annotation
- 9. Bean class
- 10. Method (BMI)
- 11. Where?
- 12. Bean class
- 13. Superclass
- 14. Separate class
- 15. Injected beanpublic classimportantClass { public StringimportantMethod() { … } … } Order of invocation
- 16. Order of invocation Influenced by how, where and at what level. Governed by complex and interwined laws 9 for the business method interceptors 7 for the life cycle callback interceptors Comprehension of the invocation order is complex! Visualization: sequence diagrams Beneficial for comprehension [Tiley Huang 2003] Suited for the task as interceptor invocation Sequential Data independent (more or less) PAGE 2
- 17. I2SD Co-evolution concern separation of the parsers Visualization + analysis SVG (XML-based) Suited for post-processing Integrated in NetBeans Uses the internal on-the-fly NetBeans compiler / name of department PAGE 3 7-10-2011
- 18. User scenarios (paper) Developer Alice tries to understand a performance problem Measurements of the explicit calls do not help I2SD exposes “hidden” interceptor calls Alice measures performance of these calls Alice-like demo Quality assessor Bob evaluates maintainability Metrics: number of calls in a scenario [J. Muskens, M. R. Chaudron, and R. WestgeestPROGRESS 2002] Bob runs I2SD as a batch job Compares results against the benchmarks / name of department PAGE 4 7-10-2011
- 19. Conclusions Interceptors are flexible and beneficial Order of invocation is challenging Reason for slow adoption? I2SD reconstructs sequence diagrams Helps both developers and quality assessors More information and availability Serguei Roubtsov s.roubtsov@tue.nl / name of department PAGE 5 7-10-2011
Notas do Editor
- Incosistencies:First, the specification states that <interceptor-order> can specify total orderingof interceptors on a bean at the class level and/or method level. The implementation, however, allows only one such an element: either on the class or on the method level of any particular bean. Second, the specification states: “If the interceptor-order element is used, the ordering specified at the given level must be a total order over all interceptor classes that have been defined at that level and above (unless they have been explicitly excluded by means of one of the exclude- elements)”. However, in the GlassFish implementation, the <interceptor-order> element has the absolute priority and the exclude- elements cannot override it. Third, the specification defines that a <method-name> element should be used to specify an interceptor method. GlassFish, however, requires the <method-name> element to be enclosed in the <method> element. This discrepancy stems from an inconsistency in [21]: while the discussion omits <method>, the XML schema found in the same document includes this element. In all these situations, the algorithms presented in the next section follow the implementation rather than the specification.
- The plugin uses an internal on-the-fly compiler of NetBeans (what element is selected – name, signature, class/method/…)