REST를 통한 네트워킹 - Michael Li
OpenAPI 때문에 관심은 많지만 아직 경험해보지는 못했던 REST... REST는 유니크한 URI를 이용하고 CRUD기능을 모두 제공하고 있는제 제한적으로 보이기는 하지만 실제로 생각해 보면 이 이상의 기능을 그리 필요하지 않다.
REST의 5가지 조건
- 모든 것은 ID를 가지고 있다.
아이디는 POJO를 사용하고 @Path어노테이션을 준다.(리소스에 아이디를 줄 수 있다.) - 모든 것은 Link 되어 있다.
메서드의 이름은 중요하지 않고 어노테이션이 중요하다. - 표준적인 방법으로 접근한다.( Get(Select), Put(Update), Post(Insert), Delete)
@produceMine을 이용하고 XML, JSON을 만든다.
@consumeMine은 Put, Post를 받기 위해 사용한다. - Multiple Representation
- Stateless Communication : state는 클라이언트에 따르기 때문에 서버는 Request만 받고 state가 없다.
서버측 장점
기존 웹인프라와 잘 맞는다. (CS간의 커플링이 줄어든다. 세션이 서버에 없어서 서버부담이 적다.)
서버세션이라는 것 자체가 없어서 failover가 쉽다.(별다른 셋팅없이 다른 서버로 넘기면 된다.)
서버세션이라는 것 자체가 없어서 failover가 쉽다.(별다른 셋팅없이 다른 서버로 넘기면 된다.)
클라이언트측 장점
캐쉬나 북마킹이 가능하다.
테스트가 쉽다.
모든 언어가 가능하다.
Data-Format이 다양하다.
테스트가 쉽다.
모든 언어가 가능하다.
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을 이용해서 권한을 교환한다.
자세한 기술얘기는 많이 논하지 않아서 이렇다하게 정의하기가 쉽지 않네.. ㅎ
오오 좋은 세미나를 가셨군요.
작년인가 제가 웹채팅을 만들었는데 소켓통신처럼 보인다는게
쓰레드를 돌려서 wait시킨다음 타임걸어서 그 지정한 시간안에
몬가 데이터가 들어오면 가동시키고 완료되는 방식이더군요.
한마디로 웹은 끝나면 연결된 상태가 아니기때문에 주소 요청하면
계속 지정된 시간까지 돌고 있는상태라는거거든요.ㅋㅋ
과연 성능은 어떨지 몰라도 ㅡㅡ; 신기하더군요. ㅋㅋ
소켓을 이용하지 않은 웹채팅은 대부분 이런방식이고.
구굴톨크도 역시 xmpp 프로토콜 사용하니 대부분의 저런방식을 사용하더군요
결론적으로 웹채팅은 구현만해놓고 서비스는 아직 쓸곳이 없어서 안했답니다. ㅋ
오픈 ID 역시 지금 기획서 기다리는중인데..
여기서 정보를 얻었었는데 ㅎㅎ...
좋은정보 많이 얻고가네여 ㅎㅎ
채팅은 한번 해봐야지 했는데 아직 못해보고 있었는데....
그런 방식으로 하는 것도 있군요. 내부 소스는 보지 않고는 제대로 이해가지는 않지만 방식은 상당히 신기하군요. 소스쪽 부하가 클것 같기는 하지만요.. 원리만으로는 Comet도 비슷한 방식같네요. 암튼 전 처음보는거라서 많이 신기했습니다. ㅎ
세미나 정보는 들은거 정리만 해서 올린건데요 머.. ㅎㅎ 도움되셨다니 다행이네요....
오픈아이디는 한번해보니까 개념은 대충 이해가 되더군요. 소스상으로는 다 처리 못한 부분도 있지만요. 저희가 만들때는 기획서도 없이 그냥 만들어 버려서요. 일정때문에 깊히는 못보고 너무 급하게 만들어서 지금와서는 아쉬움이 남네요. 나름 애착이 가서 정리해서 올리긴 했지만요... ㅎㅎ 결국 그 프로젝트는 다른 일때문에 통째로 드랍이 되버렸네요.. ㅠ..ㅠ