Docstoc

Large Scale AOSD for Middleware

Document Sample
Large Scale AOSD for Middleware Powered By Docstoc
					Aspects in Middleware

      1: Adrian Coyler, Andrew Clement
   2: Charles Zhang, Hans-Arno Jacobsen


            Presented by: Itay Maman




                                          1
        Scope (1/2)

   Middleware platforms offer great aspect
    opportunities
       Many policies
       Many applications from different vendors
       Must be highly customizable


   On the other hand, there are many obstacles
       Customers are reluctant to switch to a new platform
       Complexity of the code/System
            => New bugs due to aspectization


                                                              2
        Scope (2/2)
   Our focus: lessons learnt while refactoring existing
    middleware products
       Original language: Java
       Aspect technology: AspectJ
       What makes middleware good AOP candidates?
       Refactoring process
       Discussion of benefits

   We will NOT talk about developing an AOP-based
    middleware from scratch

   Complex terminology
       Middleware, Three-tier application, Components, ...
                                                              3
         Three-tier application
           Three-tier application:
             An application that is organized into three
                      major distributed parts:
                    User interface (client program),
                Functional processing (business rules),
                     and Data storage (Database)

   A Common architecture for Enterprise applications
       E.g.: Banks, Hospitals, Phone companies, …

   May get complex
       More than one database
       A Data storage may be a separate three-tier application itself
       Multiple types of clients
       Redundancy


                                                                         4
   Example: A Three-tier application
First Tier          Second Tier      Third Tier




  Browser
             HTTP




                                         Database
                                  JDBC


                        Server



                                                    5
        The middle tier

   The middle tier is the heart of the system
       The design of the other tiers is complex but
        almost mechanical
   Includes most of the domain-specific
    programming:
       Algorithms & calculations
       Decisions
       Behavior
   Usually: Encapsulation using components
       (See next slide)
                                                       6
        Components

             Components:
             A reusable program building block that can
             be combined with other components in the
                same or other computers to form an
                            application


   Examples: Enterprise Java Beans, DCOM
   EJBs
       Managed by a J2EE server
       Two classifications:
            Session Bean/Entity Bean
            Stateless/Stateful
                                                          7
   Welcome to the world of J2EE
First Tier          Second Tier           Third Tier



                    JSP
Browser
          HTTP    Servlet

                  RMI       RMI

                    Accounts EJB   JDBC
                                            Database

                 Employees EJB     JDBC

                    J2EE Server

                                                       8
        Middleware, Application Server (1/2)
         Middleware:
            Software that mediates between two
             separate and often already existing
                         programs

   Categories of middleware:
       Infrastructure middleware
       Distribution middleware
       Common middleware services
            AKA: Application Server
       Domain Specific middleware

                                                   9
         Middleware, Application Server (2/2)

         Application Server:
          A server program (typically running on a
          dedicated computer) that is dedicated for
            running certain software applications



   The two terms describe different levels of the same
    concept
       An application server is just a sophisticated type of
        middleware
       We will use both terms interchangeably

                                                                10
         Inspection of middleware needs

    Two approaches
    1) Analytic: What is so unique in middleware
       platforms?
    2) Programmatic: What is needed in a typical
       component code?




                                                   11
      Analytic approach (1/3)

   Let’s compare Application Servers (AS) with
    Operating Systems (OS).

    It turns out that both are platforms, which:
    a) Launch applications
    b) Supply core services to these applications
    c) Let programmers focus on domain specific
        tasks


On the other hand, there are some key differences…
                                                    12
        Analytic approach (2/3)

   Application Server (AS) vs. Operating System (OS):
      Variability of applications

            A single AS invokes a specific set of applications
            A desktop computer launches all sorts of programs
       Interconnectivity
            Usually, components in an AS communicate with each
             other
            In an OS most applications are stand-alone
       Money invested
            A customer is willing to pay to customize his AS

                                                                  13
        Analytic approach (3/3)

   Summary of differences
       An AS is more coherent
       An AS must be highly customizable
            “stop-install-reboot” is usually not an option




   The solution: Aspects



                                                              14
        Programmatic approach (1/3)

   Forces in Enterprise applications
       Availability/Fail Safety/Recoverability
       Multiplicity
       Transaction Management
       Scalability
       Concurrency
       Security
       Simplicity of the algorithms
       Backwards compatibility
       Heterogeneity
            Of platforms (HW, OS), languages, tools

    Non functional requirements (?!?)
                                                       15
        Programmatic approach (2/3)

   Standard J2EE services
       Dynamic web pages: JSPs, Servlets
       Components: EJBs
       Naming: JNDI
       Messaging: JMS
       E-Mailing
       Transactions: JTA
       Authentication
       Imported from J2SE:
            Remoting: RMI
            DB connectivity: JDBC
            XML
       Other services may be provided by a specific implementations
            Not part of the J2EE standard

     Functional requirements (?!?)

                                                                       16
        Programmatic approach (3/3)

   What is left for the programmer to do?
    1) Invoke J2EE services
         Lookup,iterate,put,get,remove,send,receive

    2) Write domain specific algorithms/behavior
         Which are typically not complicated

    3) Address various concerns
         concerns which correspond to the non functional requirements
         - or - “classical” aspects: Logging, error handling, …

   The 3rd task (“Address various concerns”) is the most
    complex one
       Due to its cross cutting nature
       Due to lack of support from the J2EE platform

   The solution (again): Aspects
                                                                         17
        Classification of concerns in middleware

   Conformance to a policy (homogenous)
       “When to log?”, “When to release a resource?”, …
       Homogenous: Same treatment in all locations

   Scattered behavior (heterogeneous)
       User authentication,Database connectivity, …
       Heterogenous: Treatment varies

   Tier cutting concerns
       Compression, Encryption, …
       Very interesting, but out of this lecture’s scope

Relevant to: middleware code, components code
                                                            18
        “Large scale AOSD for Middleware”

   Work of Coyler, Clement (IBM)

   Used the “Websphere” application server
       An IBM product
       J2EE complaint

   The idea:
       Identify cross cutting concerns
       Refactor them into aspects
       Compare the aspectized system with the original
                                                      19
        Homogenous concerns (1/2)

   The WebSphere source code should conform to
    several predefined standards (policies)

   Each policy is defined by a specification document

   Three such policies were investigated
       Tracing and logging
       First Failure Data Capture (FFDC)
       Monitoring and statistics

   Each policy creates a homogenous concern
                                                         20
        Homogenous concerns (2/2)

   The investigation process
       Encapsulate each policy in an abstract aspect
            Defines how the policy is to be applied
       Write a concrete sub-aspect for each component
            Provides concrete specification of pointcuts
       Weave the advices into the program
       Compare the augmented program with the original
            (No details were given about the comparison process)


   Results
       No numerical data is reported
       The authors claim that many locations were found where
        the policy was not followed by the original program
                                                                    21
        Heterogeneous concerns (1/6)

   The motivation: Decompose a certain service
    (feature) off the middleware
       Find the code which is part of the service
       Place the code in dedicated classes/aspects
       Use AspectJ to build two different flavors of the
        system:
            Feature turned on
            Feature turned off


   The problem: How to find all pieces of code
    which implement a feature?
       (see next slide)

                                                            22
      Heterogeneous concerns (2/6)

   (The problem: How to find all pieces of code which
    implement a feature?)
   The solution: An iterative semi-manual algorithm

    [1] Choose an initial set of classes: S
        (These classes are known to be part of the feature)

    [2] for each code site that calls methods of classes in S:

    [3]   If the site takes part in the implementation
          of the feature, add its class to S
          (Move the site to a new class if needed)

    [4] Go back to [2] if S has changed in the last pass


   The challenge: Automation of step [2]                     23
        Heterogeneous concerns (3/6)
       Q: What’s the easiest way to implement step [2]?
public aspect EJBSeparation {
  pointcut inEjb() {
    within(T1) ||
    within(T2) ||
    ...;
  }

    pointcut ejbCall() {
      call(* T1.*(..)) ||
      call(* T2.*(..)) ||
      ...; }

    declare warning :
      ejbCall() && !inEjb() :
        "Link to EJB Support found";
}


        A: AspectJ!
                                                                         24
             This aspect finds all location which use the EJB service
             Heterogeneous concerns (4/6)
   The process:
           Run Query (Aspect)                                           Analyze

           Inspect results (warnings)               Run Query            Query
                                                                         Report

           Refactor
           Add classes to pointcut definitions

    public aspect EJBSeparation {
      pointcut inEjb() {
        within(T1) ||                             Alter EJB Support      Refactor
                                                  pointcut definition   Component
        within(T2) || ...; }

        pointcut ejbCall() {
          call(* T1.*(..)) ||
          call(* T2.*(..)) || ...; }

        declare warning :
          ejbCall() && !inEjb() :
            "Link to EJB Support found";
    }
                                                                                    25
         Refactoring (of EJB support)
                                public class A extends B {

                                    public void init() {
                                       one();
public class A extends B {             add();
   private EJBContainer ejbc;          two();
                                    }
    public void init() {
       one();                       void add() { }
       ejbc = newContainer();   }
       if(ejbc != null)
          register(ejbc)        public aspect EJBAspect1 {
       two();                      EJBContainer ejbc;
    }
}                                   pointcut registration(A ci) :
                                       execution(* add()) && this(ci);


   Original code                   before(A ci) : registration(ci) {
                                       ejbc = newContainer();
                                       if(ejbc != null)
                                          register(ejbc)
                                    }
                                }


                                           Refactored code              26
        Heterogeneous concerns (5/6)

   The concern which was factored out:
       EJB support
   Results
       The two flavors passed all J2EE conformance tests
            Except for EJB related tests in the “off” flavor
       Slight improvements when EJB support is off
            Performance
            Footprint
            Startup time




                                                                27
        Heterogeneous concerns (6/6)

   Why was EJB support chosen?
       This is one of the “heaviest” services offered by
        WebSphere.
       As such, we would expect one to choose a simpler
        feature for this type of research
   A speculation:
       EJB support is one of the primary functional
        requirements of a J2EE server
       => The system was designed “around” this service
       => The System’s primary decomposition does not cut
        the EJB service
       => It is relatively easy to refactor it

                                                             28
        “Quantifying Aspects…” (1/3)
   Work of Zhang, Jacobsen (University of Toronto)
       Full name: “Quantifying Aspects in Middleware Platforms”


   Used the “CORBA” middleware
       A Distribution Middleware
       Less sophisticated than an application server (WebSphere)


   Methodology: Similar to the previous work
       But, OO metrics were used to evaluate the benefits of AOP




                                                                    29
        “Quantifying Aspects…” (2/3)
   Investigated aspects
       Homogenous: Logging, Error handling, Synchronization, pre/post
        conditions
       Heterogeneous: Dynamic programming model, Portable
        interceptors


   OO Metrics
       Size: Total number of executable lines
       Weight: Number of methods per class
       CCN: Number of unique execution paths per method
       Coupling: Average number of other classes “known” by a class




                                                                         30
        “Quantifying Aspects…” (3/3)
   Results:
                 CCN             Size         Weight        Coupling
Original         4.2             5893         16.5          21.13
Refactored 4.04                  4899         16            18.33



   Analysis:
      All metrics decreased in the refactored program

      This indicates that the primary code became simpler

              Though the complete program code is just as complex
       It is difficult to evaluate the significance of the
        improvement

                                                                       31
        Summary

   Various concerns in middleware
       Homogenous
       Heterogenous
       Tier-cutting

   AOP refactoring
       Using aspects (!) to find concerns
       Changing the original code to make it aspect-friendly

   Numerical indications to the benefits of the
    refactroring process
                                                                32
-The End-




            33
   Welcome to the world of Middleware
First Tier          Second Tier            Third Tier



                        JSP
  Browser
             HTTP     Servlet

                          RMI


                        EJB         JDBC     Database


                      J2EE Server



                                                        34
Welcome to the world of Middleware



                               Analyze
           Run Query            Query
                               Report




        Alter EJB Support      Refactor
        pointcut definition   Component




                                          35

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:1/9/2012
language:
pages:35