adsense(728_90)


J2EE에서 웹서비스 개발 Enterprise

다들 알고 있는 내용이지만 다시 정리하자면, 결국 J2EE에서 웹서비스를 개발하는 게 특별히 J2SE와 다를 것은 없다. 하지만 단순히 서비스 로직뿐만 아니라 보안과 트랜잭션,로드밸런싱 등 다양한 기술적인 비용들을 J2EE환경을 통해 해결할 수 있다면 굳이 웹서비스를 어렵게 시작할 이유는 없다. 그 중에서도 특별히 SLSB(Stateless Session Bean)을 주목할 필요가 있다.
SLSB는 도메인 로직에 접근하여 비즈니스 로직을 수행하는 컴포넌트이며 J2EE즉 WAS의 컨테이너 내에서 우리가 원하는 보안과 로드 밸런싱, 트랜잭션등을 처리할 수 있다. 또한 이를 웹서비스로 연결하는 데 있어 프로토콜에 대한 유연성도 함께 부여할 수 있는데, HTTP프로토콜을 이용한 동기적인 프로토콜 사용시 이를 호출하는 서블릿이 있고 비동기 프로토콜을 사용할 시에는 MDB를 앞단에 두어 로직과 프로토콜과 연관된 부분에 대한 완벽한 분리가 가능한 것이다. 따라서 J2EE 1.4에서는 SLSB에 대한 JAX-RPC를 통한 웹서비스 구현이 표준으로 되어있다. 만약 해당 EJB가 refactoring이 필요한 시점이 올 경우 POJO가 사용될 수 있고 보다 fine-grained한 웹서비스를 위한 아키텍처가 만들어질 수 있겠으나 어쨌거나 J2EE에서 SLSB는 웹서비스의 로직을 구현하는 데 있어 가장 멋진 공간일 수 있다.
위에서 말한 내용은 J2EE 기반 웹서비스 구현에서 아주 평범한 이야기 이고 이에 대하여 다시 확인하는 차원에서 IBM의 Bobby Woolf가 자신의 블로그에 쓴 내용Bea의 Eugene Kuleshove가 딴지를 걸고 나왔다. SLSB에 서비스 로직을 담아버릴 경우 POJO기반의 설계가 가지는 유연성에 비교해볼 때 매우 치명적인 단점을 지니게 된다는 주장이다. 즉 SLSB는 그림에서 보는 바와 같이 그저 Facade로 사용하고 POJO 클래스가 실제 로직을 담당함으로써 테스트와 디버깅에 들어가는 시간을 줄일 수 있다는 것이다.

Bea의 이 열렬한 IoC의 추종자는 웹서비스에 대한 로직마저도 POJO를 통해서 최대한 fine-grained한 디자인이어야 한다고 주장하고 있고, 이에 대한 답변으로서 Bobby woolf는 그의 블로그에서 자신이 이전에 쓴 블로그에서 강조한 것은 J2EE에서 웹서비스를 구현하기 위한 가장 적절한 곳은 SLSB이며 만약 Refactoring이 필요한 경우 충분히 로직에 대한 분리를 통해 POJO를 사용하는 것은 필요할 수 있다고 언급하면서 결국 자신이 강조한 것은 SLSB라고 한다.
그럼에도 불구하고 Eugene의 블로깅은 다분히 걸고 넘어지기 식이라고 밖에 안보이는 것이, 내가 일단 IoC방식을 극단적으로 싫어하며, 굳이 웹서비스를 구현하는 구현 로직이 위의 그림처럼 복잡한 설계방식이 필요할만큼의 복잡성을 가져야하는 지에 대해서 조차 의구심이 들기 때문이다.
아무튼 갑작스런 친구의 술자리 호출로 이만 총총...

덧글

  • 2005/11/29 00:38 # 답글 비공개

    비공개 덧글입니다.
댓글 입력 영역


Google Analytics