Advanced Separation of Concerns and Component Technology

1
Advanced Separation of Concerns and Component
Technology

• Stephan Herrmann, Technical University Berlin
• Mira Mezini, Darmstadt University of Technology
• Klaus Ostermann, Siemens AG Corporate Technology

2
What we want to do

• Create software by assembling independently
  developed components

However...

• Most software still written from scratch
• Few components on the market, only in very
  specific domains (e.g., GUI)

3
Why the LEGO metaphor fails

• Multiple reasons
• Platform / Language incompatibilities
• Missing interface standards
• ...
• We believe the main reason is the crosscutting
  phenomenon

4
What is crosscutting?

• A crosscutting concern in a specific source code
  is a concern that is not well modularized
• Cross-application concerns (transaction,
  persistence, logging) are generally difficult to
  modularize
• Frequently application-specific concerns behave
  like a magic cube It is difficult to modularize
  all of them simultaneously

5
The Magic Cube Metaphor
6
How crosscutting affects components

• If a crosscutting concern has not already been
  built in by the component vendor, the component
  is useless for the customer
• Component vendors cannot foresee all concerns
  that may apply to a component

• Components cannot be realized without coping with
  crosscutting concerns.

7
Two rather independent trends to accomplish
crosscutting

• Component-based application servers for
  server-side components (EJB, CORBA, COM)
• Mechanisms for so-called Advanced Separation of
  Concerns (AOP, AspectJ, MDSOC, Hyper/J, PCA etc.)

8
Solution 1Component-Based Application Servers

• Typical cross-application concerns (transaction,
  persistence etc.) are provided as services
• Components are basically freed from these
  concerns and therefore clean
• Underlying technique All calls are dispatched
  via the container, the container calls
  appropriate services transparently.

9
Component-Based Application ServersDrawbacks

• Set of provided services useful (based on
  experience) but arbitrary
• Difficult to add new services
• Difficult to modify existing services
• Excessive coding conventions necessary
• Object Creation
• Calls to other components
• Not integrated in programming language
• No enforcement of coding conventions
• Loss of static type checking
• No help regarding separation of
  application-specific concerns

10
Solution 2ASOC Mechanisms

• Cope with crosscutting concerns at the language
  level
• Concerns can be added and removed freely (in
  contrast to a predefined set of services)
• Full programming language integration

11
ASOC Mechanisms violate important component
prerequisites

• Black Box Reuse
• Often precise knowledge of the source required
• Independent Extensibility
• Difficult to resolve inter-concern dependencies
• Closed World Assumption / Separate Compilation
• Often global compilation required
• Binary Components
• Often source code required

12
Summary

• Component-based app-servers and ASOC models have
  a common goal effective separation of concerns
• Scope is different
• App-Servers focus on large-scale distributed
  components
• ASOC models enable fine-grained separation on the
  language level
• Both have different strengths and weaknesses

We should strive for a combination of both
technologies!
13
Goal Every concern can be a component
MyApplication
Customer
Persistence
Transaction
Order Processing
14
Final Question
How the hell can all this be achieved?

• We do not have the final answer yet but
• Part of our solution will be presented at OOPSLA
  01
• We are working on the rest