"하지만 RMI를 사용하는 것에서 오는 모든 장점보다 네트워크와 마샬링의 부하에서 오는 단점들이 훨씬 더 크다는데 문제가 있다... 프리젠테이션 계층과 비즈니스 로직 계층이 공존하는 구조도 얼마든지 확장이 가능하다." 왜 EJB 시절의 시행착오를 한번 더 겪어야 할까? 10.07.22 11:07
4 개의 댓글이 있습니다.
문맥을 잘 모르겠어요. 상혁님은 저 글에서 RMI 옹호론자 쪽이신거에요, 반대론자 쪽이신거에용?
오리대마왕 오래전에 대부분의 상황에서 RMI류의 이득이 없다는 것이 업계에서 다 밝혀졌음에도 불구하고 아직 그것을 과도하게 쓰려는 움직임이 있어서 인용해본거에요. 뭔가 주변에서 EJB시절의 시행착오가 한번 더 일어나는 것 같은 느낌이라서..
오리대마왕 당연히 전 EJB를 포함한 RMI비슷한 것들에 대해 아직도 사람들이 지나치게 환상을 가지고 있다고 생각하는, 반대론자죠
benelog 네. 근데 원격 method call 까진 아니더라도 객체 주고받는 부분에 대해선 많이 나아지지 않았나 생각해요. JSON 같은 기술은 참 유용하구요. flex에서 쓰이는 자료 전달방법(이름이 잘..) 도 그렇구요. 이건 논점 이탈인가 ^^a
문맥을 잘 모르겠어요. 상혁님은 저 글에서 RMI 옹호론자 쪽이신거에요, 반대론자 쪽이신거에용?
10.07.22 13:27오리대마왕 오래전에 대부분의 상황에서 RMI류의 이득이 없다는 것이 업계에서 다 밝혀졌음에도 불구하고 아직 그것을 과도하게 쓰려는 움직임이 있어서 인용해본거에요. 뭔가 주변에서 EJB시절의 시행착오가 한번 더 일어나는 것 같은 느낌이라서..
10.07.23 08:12오리대마왕 당연히 전 EJB를 포함한 RMI비슷한 것들에 대해 아직도 사람들이 지나치게 환상을 가지고 있다고 생각하는, 반대론자죠
10.07.23 08:13benelog 네. 근데 원격 method call 까진 아니더라도 객체 주고받는 부분에 대해선 많이 나아지지 않았나 생각해요. JSON 같은 기술은 참 유용하구요. flex에서 쓰이는 자료 전달방법(이름이 잘..) 도 그렇구요. 이건 논점 이탈인가 ^^a
10.07.23 10:00