동접이 지극히 높은 상황에서 EJB와 스프링을 고민하고 있습니다.

[자유]

예를 들면 현금인출기와 같을 정도의 많은 동시접속자를 처리해야하는 WAS에 아키텍쳐를 설계하고 있습니다.

와스는 WebLogic이구요. WAS 앞 단은 웹서버가 아닌 TCP소켓서버(java)입니다. 물론 클라이언트도 TCP소켓클라이언
트이구요.

이경우 TCP소켓서버가 WAS에 있는 비지니스로직을 호출하기 위해 원격호출을 해야하는데 이부분에서 의견이 분분합니다.
EJB3.0, SpringMVC, 순수Servlet, SOAP...

가장중요한건 쓰루풋 그리고 그 다음이 확장성

제가 생각하는 성능상의 팩터는 다음과 같은것들이 있습니다.

1.위 각 방식의 통신프로토콜은 : rmi, http, soap 으로 구별할수 있을것 같은데요... 이들의 차이가 한 팩터가 될
듯하구요.

2.EJB의 대량동시접속자의 처리가 좋다고 알고 있는데 스프링이 그러한 특성을 다 구현하고 있는지 예를 들면 인스턴스 풀링과 같
은... 하여간 이런게 또하나의 팩터가 될듯하구요.

3.EJB는 마샬링을 하기때문에 부가적인 로드가 들어갈것같구요.

4.SOAP은 역시 XML파싱 등의 작업에 로드가 들어갈것 같구요.

참고로 해당서비스는 세션을 유지할필요없으므로 EJB로 한다면 당연히 SLSB을 쓸거구요. 스프링이라면 싱글턴으로 갈예정입니다.
퍼시스턴스쪽은 iBatis등을 고려하고 있습니다.(사실 이쪽도 고민입니다)

해당 서비스는 별도의 특이한 로직은 없고 대부분 DB조회나 DB트랜잭션이 주요 역할인 서비스입니다.

고수님들의 좋은 의견 많이 부탁드립니다.

[HONG SUNG DONG]

비슷한 경우로 모 증권사가 구현한 적이 있는데..

TCP 서버 + WAS

tcp 서버와 WAS는 http로 servlet으로 통신하구요
WAS Core는 EJB 기반으로 처리됩니다.

초기 http 프로토콜에 대한 성능 이슈가 많았는데 실제로 해보니 예상보단 빠른 응답 구현했습니다.

http connection은 pooling으로 서버당 2000개 정도 유지 한걸로 알고 있습니다.

rmi는 속도 저하문제로 포기...

참고가 되시면 좋겠군요...

EJB,Spring에 대한 자세한건 저도 잘 몰라서...

2010년 8월 19일 오전 9:08, 자유 <kiki...@gmail.com>님의 말:

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

--
눈에 보이는게 전부는 아니며 눈에 안보인다고 없는게 아니다.by 洪
HP:010-4717-6896

[Sewon Ann]

저도 통신 프로토콜은 http가 되어야지 않나 생각합니다. rmi는 홍성동님 말씀대로 부하가 너무 걸리고, soap는 자유님이 직접 말씀하신 것 처럼 xml 파싱하고 생성하는데 힘이 많이 들고, 또 빈번하게 통신이 일어날 경우 traffic만 늘어나지 않나 생각합니다.

2010/8/19 HONG SUNG DONG <sdm...@gmail.com>

[Kuwon Kang]

TCP서버가 데이터는 받을 때는 일반적인 스트링의 메시지 구조인가요?

그렇다면 WAS로 호출시 Spring MVC는 굳이 사용할 필요가 없어 보입니다. 실제 아키텍처 구조상 TCP서버와 WAS간에 통신이라면 View개념은 없는 거고 사실 Model도 없어 보입니다.

정리를 하면 다음과 같을 것 같습니다.

1. EJB 3.0

  가장 좋은 퍼포먼스가 날 것으로 보입니다. 정확한것은 Bench mark를 해보셔야 겠지만 경험상으로 그렇습니다.

   EJB Client를 Cache하면 HTTP보다 성능이 좋을 것입니다. 한가지 또 다른 장점은 API설계를 OOP로 할 수 있다는 거겠죠? 단점은 TCP 서버가 EJB 3.0에 의존적이 된다는 거죠. 또한 WAS가 무조건 EJB를 지원해야 한다는 의존성과 비용문제등이 생기는 거구요. 이런 부분들들 고려하셔서(Total Cost of Ownership)   결정하시면 좋을 것 같습니다.

트랜젝션은 자연스럽게 CMT또는 BMT를 통해서 관리할 수 있는데 XA를 사용하시면 무척 퍼포먼스가 느리기 때문에 2PC가 아니면 무조건 NonXA를 사용하셔야 합니다. 

2. SOAP

  SOA나 외부 시스템 연계가 아니면 사용하지 않는게 좋겠죠. 퍼포먼스가 다른 것보다 비교가 안될 것입니다.

3. RMI

  RMI도 비용이 만만치는 않습니다. 실제 객체 지향적인 API다지안이 가능해서 개발적인 측면에서는 편리할 수 도 있지만 TCP서버에서 어차피 전문을 객체로 변환해야 한다면 이를 그냥 WAS에서 하는 것도 상관 없어 보입니다.

4. Servlet

  기본적으로 확장성이나 성능도 그렇게 떨어 질 것 같지는 않습니다. 다만 EJB 3.0보다는 조금 성능이 저하될 것 으로 보입니다. 님께서 구축하는 시스템의 요건이 0.00x를 중요시하는 시스템이라면 EJB 3.0과 Servlet중에 의사결정을 하셔야 할 것으로 보입니다. 장점은 당연 WAS가 아니어도 되는 거겠죠? Tomcat으로 시스템을 구축해도 된다는 말씀이구요 이부분은 물론 유지보수나 기술지원 적인 측면에서 고려될 부분이기도 합니다.

WAS에서 Servlet Receiver에서는 Local EJB를 호출하시면 Tx관리는 굳이 JTA를 사용하지 않아도 SpringTransactionManager만 사용해서 가능합니다.

감사합니다.

2010/8/19 자유 <kiki...@gmail.com>

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

--
Blessings.
Kuwon Kang
............................................................
IT specialist and architect.
Java technology engineer.
JavaEE architect/developer.
Spring Framework specialist.
Solution developer.

- Model Driven Architecture.
- Test Driven Development.
- Test Driven Software Design.
- Refactoring Oriented Development.
- Practical design and modeling.
- Robust  Software Design and Engineering.
............................................................
Prever,Inc.
 http://www.prever.co.kr/
Blog:
 http://josh.prever.co.kr/
............................................................

God's love is eternal and leads us to live for heaven and His glory

[Kuwon Kang]

2.EJB의 대량동시접속자의 처리가 좋다고 알고 있는데 스프링이 그러한 특성을 다 구현하고 있는지 예를 들면 인스턴스 풀링과 같
은... 하여간 이런게 또하나의 팩터가 될듯하구요.

위의 질문은 좀 애매한데요.

대용량 접속시 인스턴스 풀링의 개념은 Statefull을 의미하시는 건가요? SLSB의 측면에서 보면 Client마다 Cache가 되면 사실 WAS입장에서는 하나의 Instance를 가지게 됩니다.

다만 Cache화된 Client가 많다면 SLSB도 여러개의 Bean이 풀에 존재하는 개념이 될텐데 그렇다 해도 그렇게 많이 생기지는 않겠죠?

스프링측면에서는 모든 Bean Instance들이 BeanFactory에 있으므로 이를 Singleton으로 사용하게되면 해당 Bean을 꺼내서 메서드를 호출하는 방식이 되므로 이게 EJB의 인스턴스 풀과 비교할 수 있는 부분은 아니어 보입니다.

따라서 EJB의 대용량 처리가 더 좋다 좋지 않다는 의미는 사실 좀 애매한 부분이 있어 보입니다.

예를 들어 다음과 같이 되겠죠?

TCP Server->Send message->WAS Servlet Recevier-->전문을 VO로 생성->Spring Bean Factory->getBean->Method call with VO->return->전문 생성->send back to TCP Server.

따라서 스프링이 모든 빈을 관리하고 이 빈을 꺼내서 요청된 서비스를 호출하는 Facade Pattern의 구조가 될 것 같아 보입니다.

도움이 되시길~~~

2010/8/19 자유 <kiki...@gmail.com>

[Sanghyuk Jung]

EJB규약없이 Servlet만 고려하신다면, Spring MVC로도 이번에 추가된 HttpMessageConverter같은 것을 응용해볼수도 있어보입니다.

 

MVC showcase를 보시면 사용자가 보는 View를 직접 호출할 때와 아닐 때의 권장하는 방식이 따로 나와있습니다.

 

http://blog.springsource.com/2010/07/22/spring-mvc-3-showcase/

 

EJB를 쓴다면 개발자가 Client 쪽에서 좀 더 편한점이 있을 듯합니다. 그러나 Stateless로 간다면 EJB의 인스턴스 풀링은 큰 실효성이 없다는 것이 일반적인 이야기구요 (로드존슨이 쓴 책에도 그렇게 나와있었는데, EJB3이후에는 어떤지는 모르겠네요)

 

아마 성능의 핵심은 DTO(VO라고 쓰면 Domain Driven Design에서 이야기하는 Value Object 개념과 혼동이 될까봐 저는 DTO라는 용어를 더 선호합니다.)를 어떻게 bytestream으로 변환하는냐의 정책이 될 것 같네요.

 

Hessian정도면 가볍지 않을까 생각했는데 아래 벤치마크 자료를 보니 더 빨라보이는 것이 많네요

 

http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

 

EJB쓰면 Java의 원래 Serialize 규약을 쓸테니 그것을 뛰어넘는 성능을 원하신다면 위에 나와있는 라이브러리를 참고하시면 될 듯합니다.

 

참고로 protobuf라는 것등 이중 몇가지는 DTO마다 따로 전송될 필드에 대한 규약을 따로 적어줘야 된다고 하더군요.

2010년 8월 19일 오전 10:18, Kuwon Kang <preve...@gmail.com>님의 말:

정정해야 할 부분이 있습니다.

EJB 3.0과 Servlet의 차이중에 한가지 좀 언급해야할 부분이 있네요.

클라이언트의 측면에서 EJB와 Servlet의 성능은 거의 비슷할 것으로 보입니다. 다만 제가 말씀드린 것처럼 Remote를 호출 할때의 API구조가 좀더 EJB가 OOP적이라고 말씀드릴 수 있을 것 같습니다.

다만 Container의 처리적인 측면에서 보면 EJB보다는 Servlet Container가 가볍습니다.

또한 EJB종속적인 구조가 되기 때문에 그런 부분도 확장성 면에서는 떨어진다고 할 수 있죠.

2PC요건이 아니라면 Servlet베이스로 SpringTransactionManager를 통해 트렌젝션 관리를 하는 방법을 사용하면 되구요.

따라서 Container자체는 Servlet베이스로 가고 프로토컬도 스트림 베이스로 Http방식하에서 받아서 VO로 Receiver에서 매핑하는 방식이 좋아 보입니다.

2010/8/19 Kuwon Kang <preve...@gmail.com>

[Kuwon Kang]

정정해야 할 부분이 있습니다.

EJB 3.0과 Servlet의 차이중에 한가지 좀 언급해야할 부분이 있네요.

클라이언트의 측면에서 EJB와 Servlet의 성능은 거의 비슷할 것으로 보입니다. 다만 제가 말씀드린 것처럼 Remote를 호출 할때의 API구조가 좀더 EJB가 OOP적이라고 말씀드릴 수 있을 것 같습니다.

다만 Container의 처리적인 측면에서 보면 EJB보다는 Servlet Container가 가볍습니다.

또한 EJB종속적인 구조가 되기 때문에 그런 부분도 확장성 면에서는 떨어진다고 할 수 있죠.

2PC요건이 아니라면 Servlet베이스로 SpringTransactionManager를 통해 트렌젝션 관리를 하는 방법을 사용하면 되구요.

따라서 Container자체는 Servlet베이스로 가고 프로토컬도 스트림 베이스로 Http방식하에서 받아서 VO로 Receiver에서 매핑하는 방식이 좋아 보입니다.

2010/8/19 Kuwon Kang <preve...@gmail.com>

TCP서버가 데이터는 받을 때는 일반적인 스트링의 메시지 구조인가요?

[Sungchul Park]

> 아마 성능의 핵심은 DTO(VO라고 쓰면 Domain Driven Design에서 이야기하는
> Value Object 개념과 혼동이 될까봐 저는 DTO라는 용어를 더 선호합니다.)
> 를 어떻게 bytestream으로 변환하는냐의 정책이 될 것 같네요.

이 부분도 중요하지만 전 다른 부분도 점검해보면 좋을 같습니다. 동시성 처
리를 얼마나 자원 낭비 없이 할 수 있는지도 신경써야하고 동시에 갑자기 사
용자가 몰렸을 때 문제도 생각해야 하고요.

결국 메세지 큐와 비동기 처리에 관심이 가는데요. 클라이언트가 서버에 직접
접속해서 동기화된(네트워크 커넥션과 Thread를 계속 물고 있는) 처리를 하게
하지 말고 중간에 메세지 큐(ActiveMQ, JbossMQ, RabbitMQ 같은)를 두어서 버
퍼와 부하 분산 역할을 하게하면 좋겠습니다. 그리고 서버쪽에서도 자원을 효
율적으로 사용할 수 있게 되죠. 결과적으로 쓰루풋과 확장성이 모두 개선되리
라 봅니다.

아니면 Netty 같은 비동기 네트워크 프레임워크를 사용해보셔도...

> Hessian정도면 가볍지 않을까 생각했는데 아래 벤치마크 자료를 보니 더 빨
> 라보이는 것이 많네요
> http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

Hessian이 의외로 느리다고 나오네요. 그리고, scala가 참 안습... 이런;;;

[자유]

정말 도움이 되는 정보입니다. 감사합니다.

TCP서버가 http로 WAS의 서블릿을 호출하고 그 서블릿이 다시 같은 WAS내의 EJB를 호출했다는 말씀이죠? 이 경우
EJB는 원격호출이 아닌 로컬인터페이스(맞나?) 방식으로 호출된거겠구요...

즉 통신 프로토콜은 http GET이나 POST로 그리고 WAS측에서 요청처리는 서블릿이 담당하며 비지니스로직은 EJB가 처리하
게 했다는 말로 정리할수 있는걸까요?

On 8월19일, 오전9시27분, HONG SUNG DONG <sdm...@gmail.com> wrote:
> 비슷한 경우로 모 증권사가 구현한 적이 있는데..
>
> TCP 서버 + WAS
>
> tcp 서버와 WAS는 http로 servlet으로 통신하구요
> WAS Core는 EJB 기반으로 처리됩니다.
>
> 초기 http 프로토콜에 대한 성능 이슈가 많았는데 실제로 해보니 예상보단 빠른 응답 구현했습니다.
>
> http connection은 pooling으로 서버당 2000개 정도 유지 한걸로 알고 있습니다.
>
> rmi는 속도 저하문제로 포기...
>
> 참고가 되시면 좋겠군요...
>
> EJB,Spring에 대한 자세한건 저도 잘 몰라서...
>

> 2010년 8월 19일 오전 9:08, 자유 <kikist...@gmail.com>님의 말:

>
>
>
> > 예를 들면 현금인출기와 같을 정도의 많은 동시접속자를 처리해야하는 WAS에 아키텍쳐를 설계하고 있습니다.
>
> > 와스는 WebLogic이구요. WAS 앞 단은 웹서버가 아닌 TCP소켓서버(java)입니다. 물론 클라이언트도 TCP소켓클라이언
> > 트이구요.
>
> > 이경우 TCP소켓서버가 WAS에 있는 비지니스로직을 호출하기 위해 원격호출을 해야하는데 이부분에서 의견이 분분합니다.
> > EJB3.0, SpringMVC, 순수Servlet, SOAP...
>
> > 가장중요한건 쓰루풋 그리고 그 다음이 확장성
>
> > 제가 생각하는 성능상의 팩터는 다음과 같은것들이 있습니다.
>
> > 1.위 각 방식의 통신프로토콜은 : rmi, http, soap 으로 구별할수 있을것 같은데요... 이들의 차이가 한 팩터가 될
> > 듯하구요.
>
> > 2.EJB의 대량동시접속자의 처리가 좋다고 알고 있는데 스프링이 그러한 특성을 다 구현하고 있는지 예를 들면 인스턴스 풀링과 같
> > 은... 하여간 이런게 또하나의 팩터가 될듯하구요.
>
> > 3.EJB는 마샬링을 하기때문에 부가적인 로드가 들어갈것같구요.
>
> > 4.SOAP은 역시 XML파싱 등의 작업에 로드가 들어갈것 같구요.
>
> > 참고로 해당서비스는 세션을 유지할필요없으므로 EJB로 한다면 당연히 SLSB을 쓸거구요. 스프링이라면 싱글턴으로 갈예정입니다.
> > 퍼시스턴스쪽은 iBatis등을 고려하고 있습니다.(사실 이쪽도 고민입니다)
>
> > 해당 서비스는 별도의 특이한 로직은 없고 대부분 DB조회나 DB트랜잭션이 주요 역할인 서비스입니다.
>
> > 고수님들의 좋은 의견 많이 부탁드립니다.
>
> > --
> > Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> > 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.

> > 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com<ksug%2Bunsu...@googlegroups.com>로
> > 이메일을 보내주세요.
> > 더 많은 옵션을 보려면http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.
>
> --
> 눈에 보이는게 전부는 아니며 눈에 안보인다고 없는게 아니다.by <http://xn--9i1b3b869e.by> 洪
> HP:010-4717-6896

[자유]

의견 감사합니다. rmi는 스펙을 대충봐도 HTTP보다는 부하가 있을것 같긴하더군요. 그렇담 원격요청에 대한 디스패쳐는 서블릿으
로 하는게 좋다는 말씀이겠군요.

그 말은 spring mvc 를 사용하여 구현하는 방식도 해당되는거지요? 순수 서블릿과 스프링에서의 디스패쳐(맞는지 모르겠네
요. 스트러츠만써봐서...)간에 성능차이가 있을까요?

On 8월19일, 오전9시54분, Sewon Ann <king...@gmail.com> wrote:
> 저도 통신 프로토콜은 http가 되어야지 않나 생각합니다. rmi는 홍성동님 말씀대로 부하가 너무 걸리고, soap는 자유님이 직접
> 말씀하신 것 처럼 xml 파싱하고 생성하는데 힘이 많이 들고, 또 빈번하게 통신이 일어날 경우 traffic만 늘어나지 않나 생각합니다.
>
> 2010/8/19 HONG SUNG DONG <sdm...@gmail.com>
>
> > 비슷한 경우로 모 증권사가 구현한 적이 있는데..
>
> > TCP 서버 + WAS
>
> > tcp 서버와 WAS는 http로 servlet으로 통신하구요
> > WAS Core는 EJB 기반으로 처리됩니다.
>
> > 초기 http 프로토콜에 대한 성능 이슈가 많았는데 실제로 해보니 예상보단 빠른 응답 구현했습니다.
>
> > http connection은 pooling으로 서버당 2000개 정도 유지 한걸로 알고 있습니다.
>
> > rmi는 속도 저하문제로 포기...
>
> > 참고가 되시면 좋겠군요...
>
> > EJB,Spring에 대한 자세한건 저도 잘 몰라서...
>

> > 2010년 8월 19일 오전 9:08, 자유 <kikist...@gmail.com>님의 말:

>
> > 예를 들면 현금인출기와 같을 정도의 많은 동시접속자를 처리해야하는 WAS에 아키텍쳐를 설계하고 있습니다.
>
> >> 와스는 WebLogic이구요. WAS 앞 단은 웹서버가 아닌 TCP소켓서버(java)입니다. 물론 클라이언트도 TCP소켓클라이언
> >> 트이구요.
>
> >> 이경우 TCP소켓서버가 WAS에 있는 비지니스로직을 호출하기 위해 원격호출을 해야하는데 이부분에서 의견이 분분합니다.
> >> EJB3.0, SpringMVC, 순수Servlet, SOAP...
>
> >> 가장중요한건 쓰루풋 그리고 그 다음이 확장성
>
> >> 제가 생각하는 성능상의 팩터는 다음과 같은것들이 있습니다.
>
> >> 1.위 각 방식의 통신프로토콜은 : rmi, http, soap 으로 구별할수 있을것 같은데요... 이들의 차이가 한 팩터가 될
> >> 듯하구요.
>
> >> 2.EJB의 대량동시접속자의 처리가 좋다고 알고 있는데 스프링이 그러한 특성을 다 구현하고 있는지 예를 들면 인스턴스 풀링과 같
> >> 은... 하여간 이런게 또하나의 팩터가 될듯하구요.
>
> >> 3.EJB는 마샬링을 하기때문에 부가적인 로드가 들어갈것같구요.
>
> >> 4.SOAP은 역시 XML파싱 등의 작업에 로드가 들어갈것 같구요.
>
> >> 참고로 해당서비스는 세션을 유지할필요없으므로 EJB로 한다면 당연히 SLSB을 쓸거구요. 스프링이라면 싱글턴으로 갈예정입니다.
> >> 퍼시스턴스쪽은 iBatis등을 고려하고 있습니다.(사실 이쪽도 고민입니다)
>
> >> 해당 서비스는 별도의 특이한 로직은 없고 대부분 DB조회나 DB트랜잭션이 주요 역할인 서비스입니다.
>
> >> 고수님들의 좋은 의견 많이 부탁드립니다.
>
> >> --
> >> Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> >> 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.

> >> 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com<ksug%2Bunsu...@googlegroups.com>로
> >> 이메일을 보내주세요.
> >> 더 많은 옵션을 보려면http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.
>
> > --
> > 눈에 보이는게 전부는 아니며 눈에 안보인다고 없는게 아니다.by <http://xn--9i1b3b869e.by> 洪

> > HP:010-4717-6896
>
> > --
> > Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> > 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.

> > 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com<ksug%2Bunsu...@googlegroups.com>로

[자유]

위의 분들과는 또 다른 의견이군요.
옛날 EJB 밖에 안써봐서 잘모르지만...

EJB가 rmi통신을 하는거 아닌가요?

참 먼저, 데이터는 소켓통신을하다보니 스트링으로 전달되어 옵니다. 길이나 구분자로 잘라서 DB에 인서트되거나 하구요. 어떤방식을
쓰던 was는 WebLogic으로 정해져있구요.

EJB3.0보다는 서블릿이 좀더 범용적이겠죠? 생각하지 못했던 부분이네요. 앞으로 만약 다른 시스템에서 이 WAS에 해당 서비스
를 이용하려한다면... 아무래도 확장성은 서블릿이 좀더 좋긴하겠네요. HTTP프로토콜만 만족하면되니... 원격의 EJB를 호출하
려면 RMI를 구현해야되는거죠?

> 2010/8/19 자유 <kikist...@gmail.com>

>
>
>
> > 예를 들면 현금인출기와 같을 정도의 많은 동시접속자를 처리해야하는 WAS에 아키텍쳐를 설계하고 있습니다.
>
> > 와스는 WebLogic이구요. WAS 앞 단은 웹서버가 아닌 TCP소켓서버(java)입니다. 물론 클라이언트도 TCP소켓클라이언
> > 트이구요.
>
> > 이경우 TCP소켓서버가 WAS에 있는 비지니스로직을 호출하기 위해 원격호출을 해야하는데 이부분에서 의견이 분분합니다.
> > EJB3.0, SpringMVC, 순수Servlet, SOAP...
>
> > 가장중요한건 쓰루풋 그리고 그 다음이 확장성
>
> > 제가 생각하는 성능상의 팩터는 다음과 같은것들이 있습니다.
>
> > 1.위 각 방식의 통신프로토콜은 : rmi, http, soap 으로 구별할수 있을것 같은데요... 이들의 차이가 한 팩터가 될
> > 듯하구요.
>
> > 2.EJB의 대량동시접속자의 처리가 좋다고 알고 있는데 스프링이 그러한 특성을 다 구현하고 있는지 예를 들면 인스턴스 풀링과 같
> > 은... 하여간 이런게 또하나의 팩터가 될듯하구요.
>
> > 3.EJB는 마샬링을 하기때문에 부가적인 로드가 들어갈것같구요.
>
> > 4.SOAP은 역시 XML파싱 등의 작업에 로드가 들어갈것 같구요.
>
> > 참고로 해당서비스는 세션을 유지할필요없으므로 EJB로 한다면 당연히 SLSB을 쓸거구요. 스프링이라면 싱글턴으로 갈예정입니다.
> > 퍼시스턴스쪽은 iBatis등을 고려하고 있습니다.(사실 이쪽도 고민입니다)
>
> > 해당 서비스는 별도의 특이한 로직은 없고 대부분 DB조회나 DB트랜잭션이 주요 역할인 서비스입니다.
>
> > 고수님들의 좋은 의견 많이 부탁드립니다.
>
> > --
> > Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> > 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.

> > 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com<ksug%2Bunsu...@googlegroups.com>로
> > 이메일을 보내주세요.
> > 더 많은 옵션을 보려면http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[자유]

네 제가 좀 헷갈리고 있습니다. 상태가 없는 경우 ejb든 싱글톤 서블릿이든 인스턴스는 하나이고 와스가 담당하는 쓰레드풀링의 성
능이 더 영향을 미치게 되는건가요? 혹 스프링자체에서도 이러한 부분에 대해 관여하는게 있나요?

참 그리고 Cache화된 클라이언트란 어떤걸 말씀하시는건지요?

On 8월19일, 오전10시44분, Kuwon Kang <prever.k...@gmail.com> wrote:
> 2.EJB의 대량동시접속자의 처리가 좋다고 알고 있는데 스프링이 그러한 특성을 다 구현하고 있는지 예를 들면 인스턴스 풀링과 같
> 은... 하여간 이런게 또하나의 팩터가 될듯하구요.
>
> 위의 질문은 좀 애매한데요.
>
> 대용량 접속시 인스턴스 풀링의 개념은 Statefull을 의미하시는 건가요? SLSB의 측면에서 보면 Client마다 Cache가 되면
> 사실 WAS입장에서는 하나의 Instance를 가지게 됩니다.
>
> 다만 Cache화된 Client가 많다면 SLSB도 여러개의 Bean이 풀에 존재하는 개념이 될텐데 그렇다 해도 그렇게 많이 생기지는
> 않겠죠?
>
> 스프링측면에서는 모든 Bean Instance들이 BeanFactory에 있으므로 이를 Singleton으로 사용하게되면 해당 Bean을
> 꺼내서 메서드를 호출하는 방식이 되므로 이게 EJB의 인스턴스 풀과 비교할 수 있는 부분은 아니어 보입니다.
>
> 따라서 EJB의 대용량 처리가 더 좋다 좋지 않다는 의미는 사실 좀 애매한 부분이 있어 보입니다.
>
> 예를 들어 다음과 같이 되겠죠?
>
> TCP Server->Send message->WAS Servlet Recevier-->전문을 VO로 생성->Spring Bean
> Factory->getBean->Method call with VO->return->전문 생성->send back to TCP
> Server.
>
> 따라서 스프링이 모든 빈을 관리하고 이 빈을 꺼내서 요청된 서비스를 호출하는 Facade Pattern의 구조가 될 것 같아 보입니다.
>
> 도움이 되시길~~~
>

> 2010/8/19 자유 <kikist...@gmail.com>

>
>
>
> > 예를 들면 현금인출기와 같을 정도의 많은 동시접속자를 처리해야하는 WAS에 아키텍쳐를 설계하고 있습니다.
>
> > 와스는 WebLogic이구요. WAS 앞 단은 웹서버가 아닌 TCP소켓서버(java)입니다. 물론 클라이언트도 TCP소켓클라이언
> > 트이구요.
>
> > 이경우 TCP소켓서버가 WAS에 있는 비지니스로직을 호출하기 위해 원격호출을 해야하는데 이부분에서 의견이 분분합니다.
> > EJB3.0, SpringMVC, 순수Servlet, SOAP...
>
> > 가장중요한건 쓰루풋 그리고 그 다음이 확장성
>
> > 제가 생각하는 성능상의 팩터는 다음과 같은것들이 있습니다.
>
> > 1.위 각 방식의 통신프로토콜은 : rmi, http, soap 으로 구별할수 있을것 같은데요... 이들의 차이가 한 팩터가 될
> > 듯하구요.
>
> > 2.EJB의 대량동시접속자의 처리가 좋다고 알고 있는데 스프링이 그러한 특성을 다 구현하고 있는지 예를 들면 인스턴스 풀링과 같
> > 은... 하여간 이런게 또하나의 팩터가 될듯하구요.
>
> > 3.EJB는 마샬링을 하기때문에 부가적인 로드가 들어갈것같구요.
>
> > 4.SOAP은 역시 XML파싱 등의 작업에 로드가 들어갈것 같구요.
>
> > 참고로 해당서비스는 세션을 유지할필요없으므로 EJB로 한다면 당연히 SLSB을 쓸거구요. 스프링이라면 싱글턴으로 갈예정입니다.
> > 퍼시스턴스쪽은 iBatis등을 고려하고 있습니다.(사실 이쪽도 고민입니다)
>
> > 해당 서비스는 별도의 특이한 로직은 없고 대부분 DB조회나 DB트랜잭션이 주요 역할인 서비스입니다.
>
> > 고수님들의 좋은 의견 많이 부탁드립니다.
>
> > --
> > Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> > 이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.

> > 그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com<ksug%2Bunsu...@googlegroups.com>로
> > 이메일을 보내주세요.
> > 더 많은 옵션을 보려면http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[Kuwon Kang]

EJB의 instance pool과 서블릿의 쓰레드 pool은 거의 같은 목적이라고 보셔도 되죠.

리소스 관리 및 성능측면에서 고려된 개념이므로 비교하는 것은 무리가 있어 보입니다.

스프링 빈들의 인스턴스를 pool이라는 방식으로 관리하는 개념은 없습니다.

예를 들어 쓰레드 풀이던 ejb의 instance풀이던 스프링 BeanFactory에서 해당 싱글톤 빈을 꺼내서 쓸 뿐이죠(만약 서비스 호출 방식을 Ejb던, 싱글톤 서블릿이던 Facade Pattern방식으로 구성하 경우에...).

EJB를 해보셔서 아시겠지만 Cache된 클라이언트란 매번 요청시마다 stub을 생성하지 않고 한번 생성한 후에 싱글톤 패턴으로 사용하는 것을 의미합니다.

2010/8/20 자유 <kiki...@gmail.com>

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[Kuwon Kang]

^^ 네 물론이죠.

EJB도 RMI프로토콜을 기반으로 구성된 통신이닌깐요.

다만 RMI를 직접 개발하고 코딩하고 디플로이하는 이런 개발/유지보수 관점에서 비용이 있다는 말씀이구요 EJB는 그냥 개발 및 설정후 디플로이 하면 WAS가 알아서 해주기 때문에 이런 측면에서 말씀드린 것입니다.

여러가지 많은 Factor들을 고려 하고 계신 것 같은데 제 개인적으로는 다음같은 의사결정 Factor를 기준으로 두고 결정하시면 좋을 것 같습니다.

1. 고성능 아키텍처를 지향해야 하는가?

    가령 EJB vs Servlet Container. EJB는 서블릿 컨데이너보다 무겁습니다.

    0.00x의 차이가 중요한 비즈니스 요건인가?

2. Business요건이 반드시 EJB가 있어야 하는가? 2Phase Commit을 지원해야 하는가?

   그렇지 않다면 결코 EJB를 사용할 필요가 없죠.

3. Client와 서버가 네트워크 최적화가 필요한가?

    가령 HTTP기반의 Stream통신 처리와 예를 들어 Hessian등과 같은 방식중 어떤 것을 선택할 것인가? 개발적인 측면에서는 Hessian일 쉬울 것이고 퍼포먼스 측면에서는 조금은 Law level에 HTTP Stream방식이 전문 처리를 위해서는 좋을 것 같아 보입니다.

4. 개발 및 유지 보수의 편리성?

    여러가지 측면의 고려가 있겠죠?

5. 특정 플랫폼 의존적인?

    Client의 입장에서 의존성(EJB, Hessian, RMI).

    서버 입장에서 의존성(EJB, XA Driver).

6. 유지보수자의 관점에서 많은 기술적 장벽은 없는지?

    EJB, 2pc, XA, etc.

만약 비즈니스 요건이 EJB가 아니면 결코 EJB를 사용할 필요가 없고 예를 들어 0.00x의 성능 차이를 고려하지 않아도 된다면 law level로 개발하기 보다는 hessian, Bulap등 과 같은 Third party라이브러리를 사용하는 것도 좋겠죠.

저 개인적으로 EJB의 요건이 반드시 필요하지 않다면 사용하지 않을 것을 권장하구요 0.00x의 차이정도는 Acceptable하다면 hessian과 같은 라이브러리 사용을 권장합니다.

2010/8/20 자유 <kiki...@gmail.com>

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[One Bread]

깔끔하게 잘 정리해주셔서 이해하기가 좋네요.

그런데 Law level은 혹시 raw level이나 low level을 말씀하시려던게 아니에요?

2010/8/22 Kuwon Kang <preve...@gmail.com>

[Kuwon Kang]

ㅎㅎ ^^ 네 맞습니다.

감사해요^^

2010/8/22 One Bread <onebre...@gmail.com>

[HONG SUNG DONG]

우선 고객이 접속하는 서버는 TCP 접속서버이구요. http 프로토콜로 WAS 서블릿을 호출합니다.

제가 웹개발자이면서도 EJB는 써보지 않아서 WAS 내부에서 어떤 방식으로 처리되는지는 정확히 모르겠습니다.

IBM 프레임워크를 사용했다고 했는데 EJB는 맞는듯 합니다.

관련 개발자, TCP 서버 개발자, 프레임워크 담당자 정보 공유 가능합니다.

서로 좋은 기술 경험을 공유한다면 원하시는 시스템 구축이 가능하리라 생각합니다.

2010년 8월 20일 오전 1:08, 자유 <kiki...@gmail.com>님의 말:

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

--
눈에 보이는게 전부는 아니며 눈에 안보인다고 없는게 아니다.by 洪
HP:010-4717-6896