EJB와 스프링 선택의 기준에 대한 질문
Lee SeongUk
최근에는 보험사 차세대 프로젝트만 돌아서 그런지 스프링을 실무로 접한지 오래됐습니다.
한데 이런 대형 프로젝트에서 스프링을 사용하지 않는거 같더군요
어떤 곳은 자체 프레임워크를 사용하는데 스프링의 개념이 섞이긴 했으나 기본은 EJB를 사용합니다.
다른 X보험사 같은 경우는 EJB에 스트러츠의 액션 기능을 붙여서 쓰고있습니다.
어떤 분은 복잡한 트랜잭션 처리를 EJB 컨테이너에 맡기기 위해서 EJB를 사용한다고 하며,
어떤 이는 대형 프로젝트에서는 관리차원에서 스프링을 쓰기가 어렵다고 합니다.
물론 스프링과 EJB가 어느 한쪽만 선택하는 문제는 아니겠지만,
굳이 선택해서 진행해야 한다면 각각이 비교될 수 있는 장단이 뭐가 되며 그 기준은 어떤 것들이 있을까요?
저도 솔직히 몇백명이상의 인원이 참여하는 대형 프로젝트에서 스프링으로 프로젝트를 하는 케이스를 못본거 같은데
그 이유가 정확히 뭔지 궁금합니다.
많은 고수분들의 조언 부탁드립니다.
Sanghyuk Jung
옛날 EJB이야기이기는하지만, 로드존슨이 처음에 J2EE development without EJB 책을 썼을 때의 상황은 아래의 링크에 있는 글들을 참고하실 수 있을 듯 합니다.
http://benelog.springnote.com/pages/420130
EJB도 요즘은 Local session bean이나 POJO스러운 방식으로 쓸 수 있기 때문에 Spring의 programming model과 많이 비슷해진 느낌입니다. 특히 EJB 3.1 light라는 것은 거의 Spring과 유사한 모델을 수용한 것이라고도 볼 수 있습니다.
EJB를 포함한 전체 JavaEE 스펙과 Spring과의 관계에 대해서 SpringSource쪽의 입장은 아래의 링크를 참고하시면 도움이 되실지도 모르겠습니다.
http://benelog.egloos.com/2703581
그리고 Spring의 PlatformTransactionManager는 EJB container에서 제공하는 JTA (Java Transaction API)를 쓸 수 있기 때문에 Spring을 쓰면서도 EJB의 트랜잭션 방식을 쓸 수 있고, 그런 선택과 선택을 변경할 때 수정을 적게하는 유연성을 제공하는 것이 Spring의 의도라고 할 수 있습니다..
관리차원에서 Spring을 쓰기 힘들다는 점은 전체 아키텍처의 통일성 측면의 이야기인지, 설정파일 관리 측면인지는 알 수 없지만, Spring을 쓴다는 것은 다양한 선택이 가능하고, 하다못해 JdbcTemplate만 쓰는 경우도 Spring을 쓴다고 할 수 있으니 상황에 맞게 쓰는 것은 어디에서나 가능할 것 같습니다. production code에서 Spring을 안 쓰는 경우라도 JdbcTemplate를 테스트 코드나 테스트 데이터 구축을 할 때 활용하면 편할 때가 많습니다.
그리고 세계10대 은행 중에 9개가 스프링을 쓰고 있다고 하는 기사도 아래에 있네요.
http://www.bloter.net/archives/15878
대형프로젝트에서는 기술지원을 튼튼하게 보증해주는 벤더의 제품을 쓰는 것이 안전하다고 생각하는 의사결정자가 많을 것이기 때문에 미들웨어 벤더사에서 안정성을 강조해서 홍보하는 EJB의 스펙을 많이 활용하지 않나하는 예상이 듭니다. 그런데 상용WAS에서 제공하는Transaction관리나 connection pooling같은 것도 Spring을 통해서도 연결해서도 쓸 수 있고, Spring을 통해서 사용할 때 미들웨어 의존성이 적어지는 유연성이 있으니 벤더사가 제공하는 안정된 인프라기술 아래에서 스프링을 쓰는 것도 좋은 선택이라고 생각합니다.
아마도 국내 금융권에서는 그럴 일은 없겠지만, 꼭 그런 상용WAS의 기능이 필요하지 않은 곳에서는 나중에 Tomcat 같은 것으로 갈아타서 라이센스비 아껴보자는 상황이 생길지 언제 어떻게 알 수 없으니까요..
아래 사이트보면 외국에서는 그런 일을 벌리고자 하는 사람들이 있어보이네요
--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.
Lee SeongUk
와~ 상세한 정보 감사드립니다.
가끔씩 드는 생각이지만, 우리나라 환경에서 프로젝트를 진행하며 소프트웨어를 선택하는 기준은
든든한 벤더사가 있느냐 없느냐가 크게 좌우한다고 생각합니다.
WAS뿐만 아니라 DB만 봐도 비싼 오라클을 고집하는 이유가 다른 DB의 장단을 비교하고 상황에 맞게 선택하기보다는
그만한 기술지원을 받을 수 있기 때문에 선택하는 것으로 보이거든요.
솔직히 굳이 스프링 얘기만 아니더라도,
개발방법론만 봐도 몇백억의 대형프로젝트인데도 여전히 폭포수 모델을 가지고 프로젝트를 진행합니다.
수십명이 1년이 넘는 기간동안 분석설계 다 끝나고 구현단계에 들어가는데,
설계문서는 어디갔는지 모르겠고 그나마 쓸만한 문서들은 나중에 폐기처분되는 현실입니다.
심지어 분석설계 끝나고 설계자가 나가시면 후임자는 설계문서 휴지통에 버리는 일이 다반사이거든요.
애자일이 만능은 아니지만, 관련된 이런저런 얘기들을 하면 관리자들은 귀담아 듣지 않습니다.
솔직히 따라가는 제 입장에서 답답한 느낌을 받는게 한두번이 아니거든요.
때로는 제가 아직 경험이 미천하고 이론적으로만 알고 있어 현실은 다른가 하고 받아들일때도 많습니다.
정상혁님이 링크걸어주신 예만봐도 세계 10대은행중 9개가 스프링으로 개발했다고 하는데,,
정말 먼나라 얘기처럼만 느껴집니다.
그나저나 상혁님 말씀을 저는 아래와 같이 이해했는데 맞나요?
1. EJB만 가능한 환경은 있지 않으며, EJB 내세우고 있는 여러 장점들은 이미 스프링에서 개념적으로 포함하고 있다.
2. EJB와 스프링을 한쪽만 선택하는 개념이 아닌 환경에 맞추어 스프링을 기능을 선택해서 사용하면 된다.
그럼 항상 좋은일만 가득하세요.
감사합니다.
> *http://www.tomcatexpert.com/*<http://www.tomcatexpert.com/>
>
> 2010년 12월 5일 오전 12:53, Lee SeongUk <passion1...@gmail.com>님의 말:
>
>
>
>
>
>
>
> > 안녕하세요.
>
> > 최근에는 보험사 차세대 프로젝트만 돌아서 그런지 스프링을 실무로 접한지 오래됐습니다.
>
> > 한데 이런 대형 프로젝트에서 스프링을 사용하지 않는거 같더군요
> > 어떤 곳은 자체 프레임워크를 사용하는데 스프링의 개념이 섞이긴 했으나 기본은 EJB를 사용합니다.
> > 다른 X보험사 같은 경우는 EJB에 스트러츠의 액션 기능을 붙여서 쓰고있습니다.
>
> > 어떤 분은 복잡한 트랜잭션 처리를 EJB 컨테이너에 맡기기 위해서 EJB를 사용한다고 하며,
> > 어떤 이는 대형 프로젝트에서는 관리차원에서 스프링을 쓰기가 어렵다고 합니다.
>
> > 물론 스프링과 EJB가 어느 한쪽만 선택하는 문제는 아니겠지만,
> > 굳이 선택해서 진행해야 한다면 각각이 비교될 수 있는 장단이 뭐가 되며 그 기준은 어떤 것들이 있을까요?
>
> > 저도 솔직히 몇백명이상의 인원이 참여하는 대형 프로젝트에서 스프링으로 프로젝트를 하는 케이스를 못본거 같은데
> > 그 이유가 정확히 뭔지 궁금합니다.
>
> > 많은 고수분들의 조언 부탁드립니다.
>
> > --
> > Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> > 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
> > 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com<ksug%2Bunsu...@googlegroups.com>로
밤바
가까운 곳에 모 생명사에서도 동일 프레임워크를 사용중입니다.
각종 레퍼런스나 자료는 이미 충분히 언급을 해주셔서 번외로 제 주관적인 의견을 적어볼까 합니다.
최근 Spring의 강세에도 불구하고 만약 여전히 EJB가 선호되는 사이트가 있다면
결국 의사결정권자의 '관리적'인 이유,
특히 트러블 발생 시의 대응, 문제 해결 능력에 대한 불신 때문이라고 봅니다.
이러한 불신은 상당히 주관적이고 정확하지 않은 이유로 인해 발생하는 일이 종종 있는데
예를 들어 이곳 프로젝트에서는 W WAS 위에 Spring 기반 Web Application을 얹었을 때, 트러블이 발생하면
W WAS의 기술지원 엔지니어가 제대로 대응을 하지 못하는 일이 종종 있었습니다.
그들의 트러블슈팅 결과가 트러블의 원인을 Spring으로 몰고가는 일이 몇 번 있다보니
(EJB에서는 되는데 Spring을 써서 그런 것이 아니냐는 식의 대응)
기술에 대해 이해가 깊지 못한 의사결정권자가
이러한 잘못된 정보를 듣고 위기 회피 차원에서 EJB를 생각하는 것 같습니다.
국내의 알아준다는 베테랑 JEE 관련 기술 지원 엔지니어들의 연령층이 30대 후반에서 40대 중반이라고 볼 때,
그들이 쌓은 개발 경험은 대부분이 EJB 기반이었고 이후 개발 기회는 줄어들고 기술지원, 혹은 관리를 주력으로 하다보니
자연히 새로 부각된 Spring에 대한 경험이 EJB에 비해 상대적으로 약해서 그럴 수 있다고 보여집니다.
제공되는 기술, 스펙 상의 커버리지로 제품 선택, 구현 기술 선택이 결정되면 다행입니다만
아무래도 국내 현실은
문제가 생기면 누가와서 시스템 앞에 죽치고 앉아서 해결하는 모습을 보여줄 수 있느냐가 판단 기준인 것 같습니다.
(그래서 저도 주말에 출근해 있나봅니다. ㅎ)
참.. 그리고
제 주변에서는 사이트에서는 복잡한 트랜잭션이 필요할 때는
EJB3 보다는 차라리 C 기반 Framework으로 가는 경향이 강하군요.
이것도 역시 C 기반 Framework에 대한 오랜 경험과 믿음 때문인 것 같습니다.
On 12월5일, 오전4시36분, Sanghyuk Jung <bene...@gmail.com> wrote:
> *http://www.tomcatexpert.com/*<http://www.tomcatexpert.com/>
>
> 2010년 12월 5일 오전 12:53, Lee SeongUk <passion1...@gmail.com>님의 말:
>
>
>
> > 안녕하세요.
>
> > 최근에는 보험사 차세대 프로젝트만 돌아서 그런지 스프링을 실무로 접한지 오래됐습니다.
>
> > 한데 이런 대형 프로젝트에서 스프링을 사용하지 않는거 같더군요
> > 어떤 곳은 자체 프레임워크를 사용하는데 스프링의 개념이 섞이긴 했으나 기본은 EJB를 사용합니다.
> > 다른 X보험사 같은 경우는 EJB에 스트러츠의 액션 기능을 붙여서 쓰고있습니다.
>
> > 어떤 분은 복잡한 트랜잭션 처리를 EJB 컨테이너에 맡기기 위해서 EJB를 사용한다고 하며,
> > 어떤 이는 대형 프로젝트에서는 관리차원에서 스프링을 쓰기가 어렵다고 합니다.
>
> > 물론 스프링과 EJB가 어느 한쪽만 선택하는 문제는 아니겠지만,
> > 굳이 선택해서 진행해야 한다면 각각이 비교될 수 있는 장단이 뭐가 되며 그 기준은 어떤 것들이 있을까요?
>
> > 저도 솔직히 몇백명이상의 인원이 참여하는 대형 프로젝트에서 스프링으로 프로젝트를 하는 케이스를 못본거 같은데
> > 그 이유가 정확히 뭔지 궁금합니다.
>
> > 많은 고수분들의 조언 부탁드립니다.
>
> > --
> > Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> > 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
> > 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com<ksug%2Bunsu...@googlegroups.com>로
> > 이메일을 보내주세요.
> > 더 많은 옵션을 보려면http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.- 원본 텍스트 숨기기 -
>
> - 원본 텍스트 보기 -
Lee SeongUk
네 밤바님 좋은 의견 감사합니다.
저도 밤바님 의견에 동의 합니다.
그리고 그러한 현실이 문제라기 보다는 요즘들어서는 당연한게 아닌가라는 생각도 듭니다.
요즘 자주 드는 생각은 결국 IT라는게 공학이라기보다 인문학에 더 가까운게 아닌가라는 생각이 점점 더 크게 들거든요.
그나저나 C기반 프레임워크는 처음듣습니다. :)
혹시 웹에서도 C기반 프레임워크를 사용하나요?
그럼 항상 행복하세요~^^
이성욱 드림.
밤바
모 증권 관련사의 차세대 프로젝트의 경우,
크리티컬한 서비스 레이어부터 그 아래까지 C기반 프레임워크 (T모 사의 C/S 프레임워크)를 사용하고
프리젠테이션 레이어부터 브라우저 UI 컴포넌트까지 Java 기반 MVC 프레임워크 + X-Internet 제품을 채택,
그 사이의 연결을 MCA(MCI)/EAI로 연결하는 방식이 사용되었습니다. (T모 사의 A**** 제품)
증권 관련 사이트에 계신 주변 SA 분들이 대체로 이 형태를 경험하신 것으로 보아
증권 관련 사이트에서의 C/S 프레임워크에 대한 신뢰가 두텁거나
혹은 프레임워크 납품사의 영업력, 기술력이 강한 것을 알 수 있습니다.
방카 및 카드 계열의 프로젝트의 경우
S모 사의 C/S 프레임워크를 볼 수 있는데 이 역시 C/S 프레임워크에 대한 신뢰,
혹은 납품사에 대한 영업력, 기술력에 대한 기대인 것 같습니다.
요컨데 Client 단은 배포가 용이한 Web 기반을 사용하되,
C/S 스타일의 UI를 위해 RIA 나 X-Internet을 사용하고
MVC는 Struts/Spring 기반의 MVC를,
DB 접근 및 서비스 로직은 C 기반의 프레임워크를 사용하는 유형입니다.
아이러니한 이야기지만
Java 기반 Framework이 개방적이고 유연하며 확장 가능한 형태를 추구하고 있다면
C기반 Framework은 폐쇄적이고 벤더 의존적이며 강한 제약을 통한 표준화를 추구하고 있는데
고객은 오히려 '강한 제약을 통한 표준화'를 선호하는 것 같습니다.
보통 그런 분들에게 듣는 얘기는
'Java는 왜 이렇게 어려워? C나 Cobol로 할 때는 이렇게까지 힘들진 않았어'
와 같은 것인데 이것 역시 입장에 따라 달라지는 시각차와 경험치의 차이,
기술의 가치를 판단하는 가치관의 차이에서 온다고 생각합니다.
(저는 개방적이고 자유도가 높은 쪽에 가중치를 둡니다.)
한편으론 개발하지 않는 고객이나 프로젝트 측 관리 영역의 의사결정권자 외에도
개발자들 조차 어느 정도의 배경 지식을 필요로하는 Java 기반 프레임워크 보다는
모조건 따라하기 식의 C 기반 프레임워크를 선호하기도 합니다.
이는 위의 경우와는 조금 달라서
Java 기반 기술이 변천 과정과 패턴, 아키텍처, 전략에 대한 이해가 있으면 접근이 쉬운 반면
대부분의 프로젝트에 투입되는 개발자가 Java 언어만 익히고 투입되는 경우가 많다보니
자유도가 높으면 오히려 혼란스럽고
배경이 약해 진입 장벽이 높아 익히기 어렵고, 생산성이 나지 않기 때문이라고 보여집니다.
C기반 프레임워크는 이런 부분을 적절히(제가 볼 때는 심하게) 숨겨둔 덕에
개발자가 손 댈 부분이 제한적이라 프레임워크 엔지니어에게
문제를 던져버릴 수 있기 때문에 개발자 입장에서는 심적 부담이 줄어들 수 있습니다.
무엇보다 그들이 보는 Framework은 우리가 말하는 Framework이 아니라
그보다 범위가 좁고 구체적인 Template을 생각하기 때문에 그런 시각 차가 생기는 것 같습니다.
..
쓰고 보니 딴 길로 많이 새었네요. -ㅁ-;
결론은 웹 기반 MVC + C 기반 서비스 형태도
많이 사용되는 아키텍처랍니다.
포데브
하지만 트랜잭션은 JTA구현체가 많아서(JOTM 등) 굳이 WAS 가 아니어도 됩니다.
분산처리는 rpc 또는 rmi 로 처리하거나 CORBA로 처리합니다. 최근엔 웹서비스나 REST 로 처리하기도 하지만요.
하지만 전통적 분산처리의 기준은 역시 rpc나 rmi 입니다. rmi 에 기반한 EJB는 트랜잭션의 목적보단 분산처리때문에 사용
한다고 볼수 있는것이죠.
그럼 분산처리의 목적은? 역시 비즈니스로직의 재사용입니다. 그런데 최근의 IT 상황은 굳이 분산처리를 요구하지 않습니다. 하드웨
어가 저렴해짐으로써 소프트웨어보단 하드웨어를 늘리는게 비용이적게 들기때문에 그리드 컴퓨팅을 구축해버립니다. 이런 상황이 아니라
면 분산처리를 고려해야합니다. 스프링이 분산처리하는 방법은 3가지 인데 1. HTTP 호출, 2. HTTP Object
Stream, 3. HTTP 터널링 입니다. 제가 잘못이해 했을지몰라도 이런 통신방식은 XA라 하더라도 트랜잭션을 보장하기 어려
울겁니다. 이런관점에서 EJB는 가치가 있습니다. EJB 는 이런 분산처리에 최적화가 되어 있기땨문입니다. 서버를 구성할때 꼭
동일할필요가 없으며 JNDI 서버만 잘운용하면 이런문제를 쉽게 해결할수있습니다.
이렇게 분산처리할 필요가 없다면 스프링이 최고입니다. 가볍고 트랜젝션 훌륭하고~~~
요약하면 분산처리 해야하는가 아닌가를 따져서 선택해하는것이라고 봅니다
Lee SeongUk
오늘도 행복하세요.^^
Lee SeongUk
트랜잭션이니 관리차원이니 하는 말은 굳이 EJB를 선택해야 하는 근거로 부족하다 느꼈거든요.
갑자기 생각나는게...
CBD가 불같이 일어나던 시기에 같이 덩달아 EJB 컴포넌트 개발이 유행했던 것이 기억납니다.
제가 있는 시스템의 요구사항이 내부호출뿐만이 아닌
여러 케이스의 외부 채널로 부터 서비스 호출이 요구되는 환경입니다.
이런 다양한 상황에서 분산처리를 통해 서비스 가능하게 만드려면 EJB가 적합한 이유가 되겠네요.
좋은 의견 감사드립니다.
Sanghyuk Jung
Spring Remote에서는 EJB뿐만이 아니라 Hessian, Burlap, Http invocation, RMI, JAX-RPC등의 다양한 방식을 유사하게 사용할 수 있고, 그런 방식이 바뀌었을 때 적은 수정으로 대처할 수 있습니다
그러나 EJB에서 제공하는 롤기반 인증이라던지, 원격 트랜잭션 전파가 필요할 때는 당연히 EJB를 쓰는 것이 좋겠죠~
그런데 EJB를 쓸 때도 스프링에서 제공하는 클래스를 사용하면 JNDI lookup을 역할을 분리한 Service Locator Pattern이라던가, EJB호출부분을 감싸주는 Business Delegate 같은 패턴을 보다 편하게 쓸 수 있습니다.
( 레퍼런스 메뉴얼에 따로 나와있죠 http://static.springsource.org/spring/docs/2.5.x/reference/ejb.html )
메뉴얼에 있는 아래 문장이 인상적이였습니다
"However, it is important to note that using Spring does not prevent you from using EJBs. In fact, Spring makes it much easier to access EJBs and implement EJBs and functionality within them."
즉, 원격호출이 필요한 경우에도 Spring을 쓴다면, 그 서비스를 사용하는 쪽에서는 똑같이 dependency injection으로 interface를 참조하게 되므로, 원격호출 방식의 변화나 Local 호출로 바꿔야 하는 일이 생겨도 수정할 곳이 적어지는 장점이 있습니다. 그래서 원격호출 방식에 대해서 향후 변경에 대비하고자 한다면 Spring의 Remote와 EJB 지원 기능을 활용하는 것이 유용할 수 있습니다.
만약 어플리케이션의 business layer를 100% 원격호출을 하는 아키텍처를 정했고, EJB가 제공하는 기능들이 꼭 필요하고, 앞으로 그런 스펙이 변경될 가능성도 없다고 하면 EJB만 쓰는 것이 개발자가 알아야할 기술스펙을 줄이기 때문에 선호될수도 있습니다. 그리고 EJB내에서도 local, remote를 왔다갔다 할 수 있고, Spring이 지원하는 Hessian 같은 경량 프로토콜은 고려의 대상이 아니라서, 그런 유연성이 필요없을 수도 있습니다.EJB 3.0이상에서 제공되는 POJO 스타일로 프로그래밍을 해서 Testablility같은 spring의 장점도 얻을 수도 있겠죠. 다만 Spring을 사용한다면 EJB를 지원하지 않는 WAS에서 어플리케이션을 돌리고자 할 때도 수정할 곳이 적어진다는 유연성은 또 있습니다.
그리고, EJB 1,2에서 유행했던 그렇게 business layer를 처음부터 100% 원격호출을 하는 스타일보다는 필요한 부분만 원격으로 노출하고, 호출하는 쪽에서도 부분적으로 소모하는 방식이 실용적인 때가 많습니다. 우리가 클래스 설계를 할 때 public 메소드 노출에 대해서 고민하듯이 원격으로 노출할 부분도 숙고하는 것이 향후 유지보수에 도움이 된다고 생각합니다. 뭔가 하나로 통일을 하는 것이 파워포인트로 그리면 깔끔해서 윗분들한테도 잘 먹혀서 100% 원격호출 layer를 두는 방향으로 의사결정이 많이 되는데, 어떤 기술을 쓰더라도 원격호출은 개발,디버깅, 유지보수, 자원소모가 Call by value에 비해서는 비싼 작업이고, 원격호출로 노출된 인터페이스가 다른 외부 어플리케이션에서 쓰이지 않는다면, 그런 추가 개발 비용이 회수되지 못하는 것이기 때문에, 원격호출을 할 부분은 최대한 보수적으로 결정하는 것이 좋다고 생각합니다. 그래서 일단은 Local 호출로 해 놓고, 다른 Applicatoin에서 호출이 필요한 시점에 최소한의 수정으로 원격으로 노출하는 구조가 적합할 때가 많습니다.
사실 원격호출과 재활용을 강조하는 것은 IT역사에서 꾸준히 강조되는 떡밥이고, DCOM, CORBA, CBD+EJB, SOA 등도 마찬가지의 역사의 반복이였던 것 같습니다. 원격호출이 유용한 부분이 있지만, 그것의 효과가 과장되어 온 이유는, 그런 구조가 미들웨어의 역할을 강조해서 새로운 시장을 만들어낼 수 있었기 때문인 것 같습니다. EJB에서도 처음에는 원격호출이 획기적인 재활용성을 낳고, 더 나은 Scability를 보장할 것이라고 했는데, 사실 원격호출의 부하 때문에 더 많은 장비가 필요할 때도 많았고, 원격호출은 Component 재활용이라고 표현되기보다는 데이터 저장소까지 포함한 Application, Service간의 연결을 위한 integration을 위한 것이라고 표현하는 것이 더 적합해 보였습니다. 사실 Business component의 재활용은 극히 예외적인 경우에만 가능하다고 하는 말이 수십년전부터 있었고, 그게 반복적으로 증명되는 것 같습니다. 그나마 사전에 100% 원격호출로 개발하는 것이 유행이였던 EJB초기 시대에 비해서는 SOA시대에는 원격으로 노출될 인터페이스를 어떻게 선별하고 추상화 정도를 높여져 제공하느냐가 강조되기는 했었습니다..
(기술 스펙인 EJB와 아키텍처인 SOA를 비교하는 것은 아니고, 그것이 유행했던 시대에 강조했던 점을 이야기하고자 하는 것입니다 ^^; SOAP을 써야지 SOA가 아니고 EJB를 써서 SOA를 하는 사례도 있습니다.)
암튼 쓰다보니 길어졌는데, 말씀드리고자 하는 요점은, 전체 시스템의 아키텍처에 따라서 상황은 다 다르지만, 하나의 어플리케이션 내에서도 선택적으로 원격호출과 노출을 하는 것이 실용적인 때가 많고,그런 상황에서는 EJB도 Spring을 통해서 쓰면 편리할 수 있다~ 그정도입니다. 그리고 EJB안에서 Remote session Bean, Local sesion Bean을 왔다갔다 하는 유연성을 발휘할 수도 있지만, Spring에서는 호출방식과 실행환경의 유연성의 폭이 더 넓은 장점이 있고, 그런 유연성이 필요 없어서 EJB만 쓸 때도 스프링이 유행시킨 POJO바탕의 프로그래밍 스타일과 그로 인한 Testablility의 장점은 EJB3로 누려보는 것이 좋겠다.. 입니다.
--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
Lee SeongUk
풍부한 내용에 먼저 감사를 드리고요.
제가 아직 스프링에 대해서 모르는게 많아 전부 이해는 못하지만,
앞으로 어떤것을 봐야 할지는 감이 잡힙니다.
앞으로 EJB와 스프링의 조합을 좀더 생각해보고 케이스별로 좋은 아키텍처를 선택할 수 있도록 노력해봐야겠어요.
오늘도 행복하세요.
Sewon Ann
Lee SeongUk
아 그리고 여기 있는 전체내용이 참고 할게 많아서 제 블로그에 포스팅했습니다.
여러 많은 지식(?)들을 공유해주셔서 감사합니다.
On 12월7일, 오후1시23분, Sewon Ann <king...@gmail.com> wrote:
> 상혁님은 잘 생기기까지 하셨습니다. 욕심쟁이 우후훗~
>
> 2010/12/7 Lee SeongUk <passion1...@gmail.com>
>
>
>
>
>
>
>
> > 정상혁님 글은 정말 제가 배울게 너무 많네요.
> > 풍부한 내용에 먼저 감사를 드리고요.
>
> > 제가 아직 스프링에 대해서 모르는게 많아 전부 이해는 못하지만,
> > 앞으로 어떤것을 봐야 할지는 감이 잡힙니다.
>
> > 앞으로 EJB와 스프링의 조합을 좀더 생각해보고 케이스별로 좋은 아키텍처를 선택할 수 있도록 노력해봐야겠어요.
>
> > 오늘도 행복하세요.
>
> > On 12월7일, 오전8시08분, Sanghyuk Jung <bene...@gmail.com> wrote:
> > > 안녕하세요~ 위의 논의에 덧붙여, 원격 호출이 필요할 때도 스프링을 사용하면 유용한 상황이 있다고 생각하는데요,
>
> > --
> > Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> > 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
> > 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com<ksug%2Bunsu...@googlegroups.com>로