Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.
RetroTech 팟캐스트 44BITS 팟캐스트

SUN Tech Days 2008 Seoul 2일차 후기

썬테크데이 2008 2일차이다. 이렇게 세미나때문에 회사출근을 안한 적은 처음이라 왠지 어색했다. 서류 결재 다 받고 온 것이기는 한데 왠지 연락올 것 같은 불안감. ㅋ 썬테크데이는 회사에서 공식적인 휴가라고 이벤트 1등은 말이 크게 공감이 갔다. 쉬니까(?) 좀 편하긴 하네....  썬의 큰 행사답게 사람들은 엄청 많았다. 큰 행사치고는 제법 깔끔하게 진행하기는 했지만 특정 트랙으로 사람들이 몰려서 어떤 트랙쪽은 자리가 텅텅비고 어떤 트랙은 너무 사람많아서 들어가기도 힘들정도이고 외부에서도 볼수 있게 TV랑 스피커를 배치한 건 좋았지만 동시통역기는 전파가 약해서 제대로 들리지 못했던 점은 아쉽다. 특히 점심때 잘 줄서서 먹었는데 너무 많다보니 줄이 미친듯이 길게 서고 관리안되서 이리보냈다 저리보냈다 하고 정상적으로 먹고 왔더니만 이미 세션은 시작되어 있고 그런건 많이 아쉬웠다.

사용자 삽입 이미지






REST를 통한 네트워킹 - Michael Li


OpenAPI 때문에 관심은 많지만 아직 경험해보지는 못했던 REST... REST는 유니크한 URI를 이용하고 CRUD기능을 모두 제공하고 있는제 제한적으로 보이기는 하지만 실제로 생각해 보면 이 이상의 기능을 그리 필요하지 않다.

REST의 5가지 조건
  1. 모든 것은 ID를 가지고 있다.
    아이디는 POJO를 사용하고 @Path어노테이션을 준다.(리소스에 아이디를 줄 수 있다.)
  2. 모든 것은 Link 되어 있다.
    메서드의 이름은 중요하지 않고 어노테이션이 중요하다.
  3. 표준적인 방법으로 접근한다.( Get(Select), Put(Update), Post(Insert), Delete)
    @produceMine을 이용하고 XML, JSON을 만든다.
    @consumeMine은 Put, Post를 받기 위해 사용한다.
  4. Multiple Representation
  5. Stateless Communication : state는 클라이언트에 따르기 때문에 서버는 Request만 받고 state가 없다.

서버측 장점
기존 웹인프라와 잘 맞는다. (CS간의 커플링이 줄어든다. 세션이 서버에 없어서 서버부담이 적다.)
서버세션이라는 것 자체가 없어서 failover가 쉽다.(별다른 셋팅없이 다른 서버로 넘기면 된다.)

클라이언트측 장점
캐쉬나 북마킹이 가능하다.
테스트가 쉽다.
모든 언어가 가능하다.
Data-Format이 다양하다.

REST는 아키텍쳐 스타일이다.








Simplicifying Persistence using JAP - Sridhar Reddy

원래는 AMD의 세션이었는데 세션이 취소되고 퍼시스턴트자바에 대한 세션으로 대체되었다.

EJB 에서는(난 아직 EJB 못해봤지만.. ㅠ..ㅠ) 엔티티빈을 만들때의 여러가지 이슈들이 있었다. 아무리 적게 만들어도 최소한 3개는 만들어야 하고 복잡하고 무겁다. 때문에 어떻게 EJB를 간소화 가능한가를 고민하게 되었고 EJB 3.0에서 간소화 하였다. 그리고 이 세션에서도 어노테이션에 대해서 언급을 했다. (어노테이션에 대해서 좀 공부를 해야겠구만...)








Comet 및 Ajax를 이용한 웹애플리케이션개발 - Michael Li

2일간의 컨퍼런스중에 나한테는 가장 쇼킹했던 세션.... Comet이 먼지도 몰랐지만 웹애플리케이션 개발이라길래 들어갔는데 이거 장난아니다. 웹이라는 거의 방식상 절대 불가능하다고 생각되는 것이 이 기술로 가능하다.

Comet은 기술이름인데 Ajax Push라고도 하고 Reverse Ajax라고도 한다. 개인적으로는 Comet이라는 이름이 잘 맘에 안 와닿아서 Ajax Push라는 이름이 더 맘에 든다. Comet이 뭐의 약자인가 했는데 어디서 유래됐는지는 모르겠지만 달리 유래가 나온 정보는 찾아볼 수가 없었다.

이 Comet이라는 기술은 마치 소켓통신같은걸 가능하게 한다. 일반적인 Ajax로는 서버로부터 무언가를 받으려면 반드시 요청을 날려주어야 한다. 그래서 수시로 업데이트가 되어야 하는 사이트(채팅등등)은 셋타임아웃으로 일정 기간 간격으로 요청을 계속 날려주는 것이 보통이다. 싸이월드 같은거 봐라 로긴하고 계속 보고 있으면 몇분마다 한번씩 요청해서 페이지가 갱신이 된다. 이게 당연한거고 이렇게 밖에 할 수 없었다. 하지만 Comet은 다르다. Comet 은 서버가 클라이언트에게 이벤트가 발생할 때마다 데이터를 보내고 클라이언트는 데이터가 돌아오면 처리하면 된다. 클라이언트가 데이터가 바뀌었는지 일일이 요청할 필요가 없어서 서버의 부하가 줄어들고 Latency나 트래픽도 줄어든다.

Ajax Push는 2가지가 있는데 Long Poll과 Streaming이다. Long Poll은 클라이언트가 Request를 보내면 서버가 응답해야 할 내용이 없으면 Request를 가지고 있다가 이벤트가 발생하면  Response를 보내고 클라이언트는 Response를 받고 다시 Request를 보낸다. Streaming방식은 Request를 서버가 받으면 그 Request를 이용해서 Event가 발생할 때마다 계속 Response를 보낸다.

이런 Ajax Push방식과 비교해서 기존의 Ajax방식은 Ajax Poll이라고 표현했다. Ajax Poll은 특성상 데이터가 없는 것과 서버와의 통신이 느린 것을 구별해 낼수가 없는데 Ajax Push는 이런 점을 해결 할 수가 있다.

물론 Ajax에도 문제가 있는데 특성상 Connection이 항상 열려 있는데 이런 쓰레드가 대기상태로 Block 되면 메모리를 잡아먹기 때문에 전통적인 서버기술로는 Commet을 효율적으로 쓰기가 쉽지 않다. JVM의 쓰레드 갯수를 늘려야 하기 때문에 서버 확장성에 문제가 있다. 이를 해결하는 방법이 JAVA NIO를 사용하여서 블럭킹이 되지 않게 하고 한 쓰레드가 여러 커넥션을 공유할 수 있도록 하며 여러 커넥션을 열어놓고도 블럭킹이 일어나지 않도록 해야 한다. 이렇게 하면 오직 오픈된 소켓수에만 제약을 받고 메모리 이슈가 없기 때문에 확장성을 가질 수 있다.

이에 필요한 기술로는 비동기 IO(비동기 Read/Write)와 서스펜스가 가능한 리퀘스트/레스폰스, 그리고 유요한 데이터 딜리버리를 보장하는 기술이다.

서버쪽 기술이 필요하긴 하지만 이거 완젼 흥미로와.. 이런게 되다니.. ㅠ..ㅠ







OpenSSO 및 OpenID를 비롯한 웹보안 강화방안 - Sang Shin

오픈아이디에 관심도 많고 아이덴티티 2.0에서 관심이 집중되고 있는 기술인데 크게 얻을만한 건 많이 없었다.

SSO의 이슈는 조직내에서의 SSO와 조직외에서의 SSO라고 할 수 있는데 OpenSSO가 이에 대한 대안이 될수 있다. 코딩이 필요없고 Aject가 인터셉트를 하고 SAML을 이용해서 권한을 교환한다.

자세한 기술얘기는 많이 논하지 않아서 이렇다하게 정의하기가 쉽지 않네.. ㅎ


2008/10/24 02:29 2008/10/24 02:29