1. 문제점Local and Remote Interface Simultaneously 안티 패턴은 빈을 위해 로컬과 리모트 인터페이스를 제공함으로써 발생하는 문제점에 대해 지적하고 있는 패턴으로, 이 패턴이 지적하고 있는 문제점을 살펴보면 다음과 같음.
EJB 2.0에서는 콤포넌트 작성시 로컬 인터페이스를 제공할 것인지, 리모트 인터페이스를 제공할 것인지, 아니면 둘 다 제공할 것인지를 선택할 수 있음.
로컬과 리모트 인터페이스 둘 다 제공할 경우, 타입 케스팅을 할 때 인터페이스 이름이 필요로하므로 클라이언트 프로그래머는 어떤 인터페이스를 사용해야 할지 선택해야 함. 그러나, 로컬과 리모트 인터페이스 모두 동일한 인터페이스를 상속 받고 있다면, 어떤 인터페이스를 사용해야 하는지 결정할 필요가 없음. 디플로이 디스크립터에 JNDI 네임 바인딩을 조정함으로써, 로컬 인터페이스를 사용하든 리모트 인터페이스를 사용하든 상관없이 클라이언트 코드를 같게 작성할 수 있으나 아래와 같은 단점을 가짐.
- 동일한 인터페이스 상속
동일한 인터페이스를 상속 받을 경우, 로컬 인터페이스에 선언되는 메소드들은 RemoteException을 throws 하도록 선언해야 함. 따라서, 클라이언트가 로컬 인터페이스를 사용할 지라도 RemoteException을 catch 해야 함.
- 리모트 환경과 로컬 환경의 데이터 패스 방식
리모트 환경과 로컬 환경에서 메소드 파라메터를 통해 데이터를 패스하는 방식이 다름. 리모트 환경에서는 메소느 파라메터를 Pass-By-Value 방식으로 전달하고, 로컬 환경에서는 메소드 파라메터를 Pass-By-Reference 방식으로 전달함.
메소드 파라메터를 전달할 때 Pass-By-Reference 방식으로 전달할 경우 부작용 현상이 발생할 수 있음. 이와 같은 부작용을 피하기 위해, 모든 메소드 파라메터는 Pass-By-Value로 전달되도록 할 수 있음. 그러나, 이와 같은 작업은 리모트 환경에서는 노력과 시간이 낭비됨. - 리모트 인터페이스와 로컬 인터페이스의 설계
리모트 인터페이스는 로컬 인터페이스와 다르게 설계되어야 함. 특히, 리모트 인터페이스는 Coarse-Grained하게 설계되어야 하는 반면, 로컬 인터페이스는 Fine-Grained하게 설계되어햐 함. - 콤포넌트 결정
콤포넌트를 로컬 콤포넌트로 할 것인지, 리모트 콤포넌트를 할 것인지에 대한 결정은 퍼포먼스에 많은 영향을 주는 부분이기 때문에
중요한 디자인 결정 중 하나임. 따라서, 리모트 인터페이스를 사용할 것인지, 로컬 인터페이스를 사용할 것인지에 대해서는 신중하게
결정함으로써, 한번 결정된 사항을 왔다 갔다 바꾸지 않도록 해야 함.
2. 징후 및 결과 (Symptoms and Consequences)- 로컬 억세스와 리모트 억세스에 대한 잘못된 선택으로 인해 시스템의 퍼포먼스가 늦음.
- 로컬 억세스와 리모트 억세스 코드가 적절하게 설계되지 않음으로써 예상치 못한 부작용이 발생함.
3. 리팩토링된 해결방안 (Refactored Solutions)리모트 영역을 신중하게 결정하고 나서, 이 결정사항에 따라 로컬 또는 리모트 인터페이스를 사용. 일반적으로, 리모트 영역의 수가 많을 경우 퍼포먼스는 떨어짐. 따러서, 콤포넌트 레이어의 어디를 정말 물리적으로 분리시킬 필요가 있는 지를 결정해야 함.
happyness
Programming/J2EE Patterns
Local and Remote Interface Simultaneously,
비즈니스티어 안티패턴
2007/05/27 18:00
2007/05/27 18:00