인생은 마라톤!!

Session Facade(이하 SF라 지칭)와 Business Delegate(BD라 지칭)는 서로 비교 대상이
아닌듯 합니다. 이 두가지의 패턴은 같이 사용되어 티어간의 커플링을 줄이는 역할을 하지요.
core J2EE Patterns에 나와있는 Pattern Map을 보시면 BD -> SF의 순서로 연결이 된 것을
보면 더욱 알수 있습니다. SF는 잘 알려져 있으니, SF와는 다른 BD의 고유의 역할에 촛점을
맞추어 대표적인 특징만 적어봅니다.
첫째.. SF와 같은 EJB에 대한 원격 호출을 할때 발생되는 복잡함을 감추는 Proxy역할을
합니다. 예를 들면 JNDI lookup이라든지 또는, EJB와 관련된 여러가지 exception
을 처리를 하지요.
둘째.. 티어간의 단일 연결통로 역할을 담당함으로써 비지니스 티어의 기술적인 특성으로
부터 프리젠테이션 티어의 종속을 제거합니다.

이러한 역할로 인해 얻을 수 있는 대표적인 효과는 다음과 같습니다.
첫째.. 티어간의 커플링을 줄인다.(SF보다는 더 기여하는 바가 크죠..)
둘째.. 개발시 역할을 나누어 진행할 수 있다. 대규모의 프로젝트에서는 대부분 비지니스
컴포넌트(EJB) 개발과 웹 어플리케이션(JSP,Servlet..)의 롤을 분리하는 경우가 많죠.
이때 각 티어의 개발자들은 서로 연관된 다른 티어의 개발에 영향을 받게 되는데 이를
해결하기 위해 BD의 양쪽에 각각 간단한 응답/호출 기능을 가진 테스트 컨텍스트를
제공하면 서로의 개발진행에 따른 종속을 제거할 수 있는거죠.

간단히 SF와 BD에 대해 말씀을 드렸구요.. 얼마전에 나온 EJB Patterns에 보면 이 두가지
패턴의 조합에 대한 또 다른 대안으로 EJB Command 패턴이 소개되어 있습니다. 같이 비교하여
보시면 보다 더 유익하리라 봅니다.