https://sundaland.tistory.com/74
AOP Alliance 프로젝트는 목표, 철학, 제공해야 할 답변, 제공하지 말아야 할 것들에 대해 다룬다. AOP Alliance의 다른 구성원들과 논의를 통해 우리가 여기서 무엇을 하고 있는지에 대한 공통된 견해를 도출하기 위해 추가 논의가 필요한 초안 제안서이다. 또한 목록에서 논의 중에 흥미로운 점이 나오면 이 문서에 추가되어야 한다.
[ ▶ AOP Alliance goals ]
[ ▷ AOP Advantages: The J2EE Case ]
애스펙트 지향 프로그래밍 (AOP)은 애플리케이션을 셀계하고 프로그랭하는데 있어 훌륭한 방법이다. AOP는 기존 기술 (EJB 등)이 제공하는 것보다 더 나은 해결책을 제시한다.
J2EE는 AOP Alliance의 해택을 받을 수 있는 전형적인 대상 환경이지만, 유일한 대상은 아니다. 실제로 J2EE 환경은 영속성이나 트랙잭션 같은 기술적 문제를 처리할 수단을 제공함으로써 일부 문제를 부분적으로 해결한다. 그러나 J2EE 아키텍처는 특정 요구와 관련된 새로운 기술적 관심사를 쉽게 추가할 만큼 유연하지 않다. 또한 필요하지 않거나 더 가벼운 솔루션이 선호되는 경우 하나의 솔루션을 제거할 수 있는 기능이 있으면 유용할 것이다.
AOP는 새로운 기술적 관심사 (crosscutting concerns)를 구축하고 이를 애플리케이션 내에 유연하고 모듈화된 방식으로 연결할 수 있는 일반적인 수단을 제공한다. J2EE에 일부 AOP 개념을 적용하면 J2EE 사용이 훨씬 간단해질 수 있다. 예를 들어, 일반 자바 객체 (POJO)를 EJB 대신 사용할 수 있다. 따라서 J2EE에 완전한 AOP를 쉽게 적용할 수 있다면 J2EE의 사용성을 크게 향상시킬 것이다. 또한 J2EE 준수 애플리케이션 서버에 훨씬 많은 기능을 제공할 것이다.
[ ▷ The Current Brakes To AOP ]
AOP는 인기를 얻고 있다. 그러나 대부분의 AOP 도구들은 특정 환경에서만 사용되도록 설계되지 않았다. (주로 대부분의 도구가 실험 목적에서 설계되었기 때문이다.) 따라서 특정 환경에서 AOP를 사용하려고 할 때, 예를 들어, 그 환경이 이미 AOP 도구 구현과 호환되지 않는 ㅐ장된 액스팩트를 지원하는 경우, 몇 가지 문제에 직면할 수 있다.
이 문제는 AOP가 제대로 작동하기 위해 애플리케이션의 객체나 클래스를 수정해야 하기 때문에 발생한다. 이러한 객체 수정 로직은 AOP 도구의 특정 부분인 위버 (weaver)에 의해 구현된다. 위버는 특정 환경에 잘 맞을 수 있지만, 다른 환경에서는 중요한 시스템 속성을 손상시킬 수 있다.
예를 들어, Gregor와 Rickard 사이의 AOP Alliance 목록에서 흥미로운 논의는 AspectJ의 위버 구현이 일부 환경에서 분산 및 영속성 기능을 갖춘 환경에는 잘 맞닌 않는다는 것을 보여준다.
[ ▷ The AOP Alliance Claim ]
대부분의 사람들은 완벽한 시스템을 믿지 않는다. 시스템이 항상 특정 문제와 환경에 적합하다고 생각하며, 다른 문제나 환경에는 반드시 적합하지 않을 수도 있다. 이것이 바로 J2EE와 같은 복잡한 환경에서 사용할 수 있는 AOP 도구의 경우에 해당한다. 직면한 문제에 따라 AOP 특정 구현이 유용할 수 있다.
- AspetJ : AO 소스 수둔 (및 바이트코드 수준) 위버. 새로운 언어
- AspectWerkz : AO 프레임워크 (바이트코드 수준의 동적 위버 + XML에서의 구성)
- BCEL : 바이트코드 변환기
- JAC : AO 미들웨어 (바이트코드 수준의 동적 위버 + 구성 + 애스팩트). 프레임워크
- Javassitst : 고수준 API를 가진 바이트코드 변환기.
- JBoss-AOP : 인터셉션 및 메타데이터 기반 AO 프레임워크 (JBoss 애플리케이션 서버에서 실행 + 독립 실행형 버전)
- Nanning : AO 위버 (프레임워크)
- Prose : AO 바이트코드 수준의 동적 위버 (프레임워크)
이러한 구현들이 좋은 구현이나 나쁜 구현이 있는 것이 아니라, 특정 문제/환경에 적합한 구현이 있을 뿐임을 반영한다.
따라서 AOP Alliance의 목표는 새로운 AOP 모델을 제시하거나, 모든 경우에 작동하거나 특정 J2EE 애플리케이션 서버에서 작동할 훌룡한 AOP 구현을 제공하는 것이 아니다. 오히려 AOP Alliance의 목표는 모든 기존 구현들이 동일한 핵심 언어를 사용하도록 하여 아래의 기능을 가능하도록 한다.
- 기존 AOP 구성 요소를 재사용함으로써 재구축을 피한다.
- 특정 대상 환경 (일반적으로 J2EE 환경)에 맞게 기존 AOP 구성 요소의 적응을 간소화한다.
- 공통의 루트 AOP API를 통해 애스택 재사용을 간소화한다.
- AOP 기능을 통합하려는 개발 도구의 구현을 간소화한다.
[ ▶ Aspect-Oriented Architectures ]
[ ▷ A Common Architectural Vision ]
공통된 AOP 모델과 구현 방식에 합의하는 것은 어렵다. 그 이우는 사용 맥략과 환경에 너무 밀접하게 연결되어 있기 때문이다. 예를 들어, 순수 자바 접근 방식과 J2EE 준수 접근 방식에서는 구현이 다를 수 있다. 하지만 AOE (Aspect-Oriented Environments)에 대해 공통된 아키텍처적 비전에 합의하는 것이 가능하다.
AOE를 구축할 때 설계자들은 아키텍처를 정의해야 한다. 대부분의 기존 AOE에서 아키텍처는 시스템의 기본 기능을 구현하는 몇가지 기본 모듈/구성 요소/API를 정의하고 결합한다. 기존 도구들을 살펴보면, 공통 구성 요소들을 식별할 수 있다. (해당 아키텍처에서 유사한 기능을 제공하지만, 반드시 동일한 구현 기술을 사용하는 것은 아님). 예를 들어 JBoss의 위버는 Javassist를 사용하여 클라이언트 축에서 인터셉션 메커니즘을 구현하는 반면, JAC의 위버는 BCEL를 사용하여 서버 측에서 인터셉션 메커니즘을 구현한다. 동일한 효과를 내기 위해 JIT 컴파일러를 간섭하는 다른 기술도 사용할 수 있다. 이들 모두 환경에 크게 의존한다.
AOE 라는 용어는 AOP를 어떤 방식으로든 지원하는 모든 환경을 의미한다. 예를 들어 JBoss의 AOP는 AOE에 해당하지만, 내장된 애스텍트 (관심사)를 가진 J2EE 애플리케이션 서버도 축소된 형태의 AOE로 간주될 수 있다.
[ ▷ A 3-Layer Typical Architecture ]
보통 아키텍쳐는 세 가지 계층으로 나눌 수 있다.
- 대상 플랫폼에서 위빙 (AOP의 주요 과정)을 구한하기 위한 기본 구성 요소를 제공하는 저수준 계층
- AOP의 원래 의미에 따라 기본 구성 요소와 AO 의미론을 구현하는 로직을 제공하는 고수준 계층 (대상 플랫폼에 따라 다름)
- UI를 광범위한 의미로 포함하는 개발 수준의 계층 (언어로 지원될 수 있으며, 모델링 도구일 수 있음)과 AO 프로그램을 신뢰할 수 있도록 돕기 위한 기타 도구 (타입 검사, 시각화 도구, 디버거 등)
[ ▷ What Shall AOP Alliance Specify Here? ]
AOP Alliance의 목표는 새로운 모델을 제공하거나 기존 도구의 더 나은 구현을 제공하는 것이 아니다. AOP Alliance의 목표는 공통적인 애스펙트 (관심자) 지향 환경 (AOE) 구현에서 식별된 구성 요소에 대해 표준화된 API를 명시하는 것이다.
AOP Alliance의 역할은 식별된 구성 요소의 API를 정의하는 것이어야 한다. 가장 중요한 것은 저수준의 것들인데, 그 두현 방식이 AOE를 사용할 수 있는 환경에 영향을 미치기 때문이다. 일부 기술적 특성은 결과 시스템의 속성에 깊은 영향을 미칠 수 있다. (애스팩트 (관심사)가 동적의 위빙/언위빙될 수 있는지 여부, 시스템이 배포에 대해 확장 가능한지 여부, 시스템이 영속성 또는 트랜잭션과 같은 내장 애스팩트 (관심사)와 공존할 수 있는 지 여부 등). 그러나 고수준 구성 요소들도 IDE, 디버거, 모델링 도구아 같은 도구들에 매우 흥미로울 수 있다. 공통적인 AOP 개념 조작 API를 갖추면, 도구들이 서로 다른 환경에서 여러 AOP 구현을 더 잘 지원할 수 있게 될 것이다.
AOP Alliance는 일부 구성 요소에 대해 기존의 두구를 사용하여 참조 구현을 제공할 수 있다. 그러나 정의된 APi의 구현은 기존 도구들이 직접 젝ㅇ하는 것이 더 나을 것이다. 이러한 구현은 API의 정확성을 검증할 것이다.
AOP Alliance는 위빙 로직과 구성 로직을 다루지 않는다. 이는 AOE 구현에 따라 크게 달라지기 때문이다. 그러나 우리는 API를 사용하여 AOE를 구축하는 방법을 보여주기 위해 몇 가지 참조 구현을 제공해야 한다.
AOP 도구가 우리의 API를 구현할 때, 개발 도구 구현자들이 우리의 API를 사용할 수 있도록 해야한다.
[ ▶ AOP Alliance Components ]
이 구성 요소들은 AOP Alliance가 명시해야 할 API에 대한 첫 번째 제안 초안이다. 이들 중 일부는 제거될 수 있으며, 일부는 추가될 수 있다. 이들 중 일부는 이미 자바 인터페이스로 명시되기 시작했다는 점에 유의해야 한다.
[ ▷ Low-Level Components ]
저수준 구성 요소는 매우 중요하다. 왜냐하면 전체 AOE가 이들에 의존하여 구현되기 때문이다. 이러한 구성 요소들이 어떻게 구현되는지는 매우 중요하며, 성능, 확장성, 통합 능력 또는 보안과 같은 시스템의 속성에 큰 영향을 미칠 수 있다.
[ ▷ Reflection ]
리플렉션 API는 모든 AOE에 매우 중요하다. 사실 위버 (weaver)는 어드바이스나 인트로덕션을 적용하기 위해 기본 프로그램의 클래스를 조사 (introspect)해야 한다. 예를 들어 어떤 포인트 컷이 클래스의 모든 메서드에 어드바이스를 적용해야 한다고 지정한 경우 (정규 표현식이나 ALL 키워드를 사용하여), 위버는 실제로 어드바이스가 필요한 메서드 목록을 명시적으로 알기 위해 리플렉션 API를 사용해야 한다.
위방 과정이 런타임에 수행될 떄는 SUN의 java.lang.relfect 구현이 AOE를 구축하는데 충분할 수 있다. 그러나 대부분의 기존 시스템에서 위빙 과종아 컴파일 타임 또는 클래스 로드 타입이 발생한다. 이러한 경우, 특정 리플렉션 API 구현이 필요하다. AOP Alliance에 따르면, AOE의 실행 컨텍스트에 따라 기본 구현을 변경할 수 있도록 이 API를 표준화하는 것이 매우 중요하다.
[ ▷ Program Instrumentation ]
위버의 관점에서 리플렉션이 위빙된 프로그램에 대한 일기 접근이라면, 인스트루멘테이션은 쓰기 접근이다. 그러나 AOP에서 허용되는 프로그램 수정은 제한된 수정 집합이다. 허용되는 수정은 초기 프로그램의 기존 구조에 대해 점진적인 수정이므로, 애스펙트 (관심사)들이 올바르게 함께 구성될 수 있다. 이러한 종류의 점진적인 수정을 인스트루멘테이션이라고 부른다.
인스트루멘테이션에 대한 표준 API는 없다. 하지만 리플렉션과 마찬가지로, 인스트루멘테이션은 런타임, 컴파일 타임, 또는 로드 타임에 발생할 수 있다. 게다가 각 범부마다 컨텍스트와 AOE 환경에 따라 다른 구현이 수행될 수 있다. (에를 들어 인스트루멘테이션은 소스 코드나 바이트 코드에서 직접 수행될 수 있다.) 따라서 AOE 요구 사항에 따라 기본 구현을 변경할 수 있도록 인스트루멘테이션 API를 표준화하는 것이 중요하다.
[ ▷ Interception Frameworks ]
AOE (Aspect-Oriented Enviroments)를 구축하는데 매유 우용할 수 있는 또 다른 유형의 기본 구성 요소는 인터셉션 프레임워크이다. 자바는 동적 프록시를 통해 인터셉션을 위한 표준 API/프레임워크를 제공한다. 그러나 투명성, 성능 등에서 여러가지 개선이 다른 구현을 통해 이루어질 수 있다. (대부분의 인스트루멘테이션 API를 사용한다.) 따라서 명확한 의미를 가진 표준 인터셉션 API/프레임워크를 정의한다.
인터셉션 프레임워크는 AOP 모델의 around 어드바이스를 매우 쉽게 구현할 수 있게 해주는 많은 장점이 있다. 또한, 이 프레임워크들은 독립적으로 사용할 수 있으며, 대부분의 경우 순수 자바로 작성되었음에도 불구하고 상당히 명확한 AOP 스탈의 코드를 제공한다. 이러한 이유로 여러 프로젝트와 환경 (J2EE 애플리케이션 서버, JBoss 참고)에서 여러 인터셉션 프레임워크가 구현되었다. 따라서 AOP Alliance는 이 중요한 AOP 도구 모음을 표준화하기 위해 추상적인 인터셉션 프레임워크를 제공해야 한다.
[ ▷ Metadata Handling ]
메타데이터 처리는 AOE (Aspect-Oriented Enviroments) 를 구현할 때 특히 인터셉션 프레임워크와 결합될 경우 유용하다.
메타데이터 처리를 통해 위버는 클래스의 시맨틱을 비침투적 방식으로 확장할 수 있다.대부분의 메타데이터 구현은 동적성을 허용하기 떄문에, 동적 구성/재구성에도 사용할 수 있다.
비록 JDK 1.5가 메타데이터에 대한 표준 구현을 제공할 것이지만, 여러 구현을 허용하는 표준 API를 제공하는 것이 유용할 것이다. 이러한 API는 배포, 직렬화와 같은 환경 특수성을 고려할 수 있으며, 기본 구현에서 제대로 처리되지 않을 수 있는 부분도 다룰 수 있다.
[ ▷ Class Loading Frameworks ]
많은 AOE (Aspect-Oriented Enviroments)에서 바이트코드 수준의 조작이 필요하다. 이는 인터셉션 프레임워크를 구현하거나, 프로그램에 대한 위버의 인스트루멘테이션을 직접 구현하는데 사용할 수 있다. 일부 경우에는 AOP 인스트루멘테이션이 상당히 간단하기 때문에 클래스 로드 시점에서 이러한 바이트코드 수준의 조작이 수행될 수 있다. 따라서 대부분의 AOE는 자바의 유연한 클래스 로딩 아키텍처를 사용한다.
그러나 여러 환경에서도 클래스 로더를 사용하여 고유의 기능을 구현한다. 예를 들어 분산 환경에서 특정 클래스 로더를 사용하여 스텁을 생성할 수 있다. 이러한 환경에서는 AOE의 클래스 로딩 메커니즘이 클래스 로더의 비호환성으로 인해 시스템 충돌을 일으킬 수 있다. 따라서 우리는 서로 다른 환경에서 오는 다양한 클래스 로더가 안전한 방식으로 협력할 수 있도록 충분히 유연한 클래스 로딩 프레임워크를 표준화하는 것이 중요할 수 있다로 생각된다.
[ ▷ High-Level Components ]
고수준 구성 요소를 표준화하는 것은, 세 번째 계층 (개발 계층)에서 정의된 도구들이 AOP에 대해 전반적으로 더 나은 자원을 제공할 수 있도록 하기 위해 중요하다.
[ ▷ Configuration API ]
많은 애스펙트 (관심사)는 범용적인 방식으로 구현될 수 있다. 이는 애스펙트의 기능을 적용하고자 하는 모든 프로그램에서 잠재적으로 재사용 가능한 로직을 구현한다는 것을 의미한다. 대부분의 경우, 이러한 애스펙트 재사용 과정은 범용 애스펙트의 파라미터화를 포함한다. (범용적인 영속성 애스펙트에 어떤 클래스가 영속성을 가져야 하는지, 어떻게 처리해야 하는지를 지정하는 것). AspectJ에서 추상 애스펙트를 서브클래싱하여 이를 수행할 수 있다. 하지만 외부 도구 (전처리기 등)를 사용하여 이를 수행할 수도 있다. J2EE 환경에서는 내장된 애스펙트 (EJB 컨테이너의 기술적 관심사)의 구성 프로세스가 XML 배포 파일로 파라미터화된다.
JBoss/AOP 및 기타 프레임워크에서는 XML 파일을 사용하여 구성을 할 수 있다. JAC에서는 자바 프로그램에서 애스펙트 구성 API를 사용하거나 특정 스크립트 언어와 같은 언어를 사용하여 구성을 할 수 있다.
구성 API를 표준화할 수 있다면 매우 유용하다. 이는 개발 도구에 대한 AOE 통합을 더 쉽게 만들어준다. 또한 AOE 간에 특정 구성을 재사용하는 것을 촉진한다. (AspectJ와 JBoss/AOP).
애스펙트를 AOE 간에 이식 가능하게 만드는 것은 잠재걱으로 중요한 차이점들 때문에 비현실적일 수 있음을 유의해야 한다. 하지만 애스펙트 구성을 이식 가능하게 만드는 것은 덜 비현실적이며, 이는 AOE 상호운용성을 나아가는 첫걸음이 될 수 있다.
