HTTP의 의존도를 낮춰라!
http://www.zdnet.co.kr의 기사내용 일부입니다. 전체 내용은 관련 링크를 참조하십시오.
----
HTTP의 문제점 중 하나는 이것이 RPC(Remote Procedure Call)에 기반해 브라우저와 같은 프로그램이 네트워크로 연결된 다른 컴퓨터에 존재하는 프로그램에 네트워크에 대한 자세한 사항을 몰라도 서비스를 요청할 수 있다는 점이다.
이는 웹페이지를 요청하는 작은 트랜잭션(transaction)에서는 무리없이 작동하지만, 웹서비스가 이 프로토콜을 이용해 시간이 많이 걸리는 트랜잭션을 수행하면 문제가 발생한다.
"요청에 대한 응답 시간이 3분 정도라면 이는 진정한 HTTP라 할 수 없다"고 박스가 말했다. 박스는 중개자(클라이언트와 서버 사이에 위치하는 라우터나 케이블을 소유한 업체들)가 트랜잭션 수행 시간이 이렇게 오래 걸리는 것을 절대 용납하지 않는다는 것이 문제라고 말했다.
박스는 "HTTP에 대한 의존도를 낮출 필요가 있다. 계속해서 HTTP에만 전적으로 의존하면 인터넷은 혼돈에 빠지게 될 것이다. 그렇다고 망연자실할 수도 없는 노릇이다. 최소한 산업 전반에 걸쳐 서버에 요청한 후 5일 동안 결과를 받지 않아도 될 정도의 장시간 요청을 수행할 수 있는 방법을 모색해야 한다"고 말했다.
HTTP의 또 다른 문제는 비대칭성이라고 박스는 말했다. "단일 개체만 HTTP를 이용해 교환할 수 있으며, 상대편 개체는 전적으로 수동적으로 응답만 할 수 있다. P2P 애플리케이션에 있어 이는 정말 부적절한 것"이라고....
----
SI에서 웹서비스를 선택할 경우 요구사항을 웹서비스만으로 충족하기가 쉽지 않습니다. 자바를 쓸 경우 애플릿의 보안 문제를 해결해야 하고, 업로드도 신경 써서 손봐줘야 하고 기타 등등 할 수는 있더라도 상당히 소모적이라고 느껴지는 일들이 많습니다. 그래서 아예 다른 프로토콜에 기반한 새로운 브라우저가 나오고 간단한 설정만으로 웹의 한계를 극복할 수 있는 그런 게 있으면 좋겠다는 생각을 하게 되었는데 여러분들의 생각은 어떠신가요?
HTTP 는 검색용에 접합한 프로토콜 같은데요.이러한 HTTP 를
HTTP 는 검색용에 접합한 프로토콜 같은데요.
이러한 HTTP 를 검색용이 아닌 데이타 전용이나, 온라인 거래같은 다른용도로 쓰이는건 , 더좋은 프로토콜이 있는데도 불구하고 HTTP만을 고집한다는건 문제가 있다고 봅니다.
이와같은 경우에 HTTP 는 단지 서비스 차원으로 개발을 해야 하는것이고 결코 주는 상황에 맟는 적합한 프로토콜로 개발해야 한다고 생각합니다.
네. 맞는 말씀입니다.ActiveX로 파일 전송 서비스를 만드는 동안
네. 맞는 말씀입니다.
ActiveX로 파일 전송 서비스를 만드는 동안 FTP를 개량하는 데 노력을 기울였다면 훨씬 좋았을 텐데 말예요.
from [ke'izi] : where is [r]?
간단하다.. 그건 브라우져와 웹서버에서 비접속유지와 접속유지형 둘
간단하다.. 그건 브라우져와 웹서버에서
비접속유지와 접속유지형 둘다를 지원하면 된다..
난 왜 첨부터 접속유지가 지원되지 않는지가 의문이
다.
군인에게 총이랑 수류탄도 한두개 줘서 보낼만도
한데.. 딸랑 총한자루만 줘서 보내는거나 마찬가지다.
참나.. 말두 안대는 걸 가지고 HTTP의존도를 낮추라니http를
참나.. 말두 안대는 걸 가지고 HTTP의존도를 낮추라니
http를 접속해서 3분이상 되는 것에 대해서 잘못되었다구
하는데..
30분이 걸리건 한시간이 걸리건..
결과값을 받으면 된다.. 꼭 그자리에 없을려면.
이메일로 결과값을 받던가 하면 된다.
그리고 http로 접속해 있을 필요가 없다.
fork등을 통해서 프로세서를 독립시킨 후에..
http로 실행한 프로그램을 종료해버리면.
독립성은 보장받게 되는 것이다.
다른 걸루 의존성 내리라면 말이 대는데..
기획이나 프로세서의 아이디어가 문제인 것을
http의 약점으로 알면 안된다는 말이다..
그 얘기가 아닌 것 같은데요? -.-;HTTP 의 단점을 지적하는 것
그 얘기가 아닌 것 같은데요? -.-;
HTTP 의 단점을 지적하는 것이 아니라, HTTP 만으로 모든 것을 해결하려는 것을 지적하는 것 같습니다.
님의 말처럼 이메일이나 다른 프로토콜을 활용하라는 얘기인 것 같습니다.
http가 태그로 이루어져 있어서 확장성이 넓고 여러곳에 사용될 수 있습
http가 태그로 이루어져 있어서 확장성이 넓고 여러곳에 사용될 수 있습니다.
하지만 기능이나 속도면에서 전용프로토콜을 사용하는 경우보다 느릴수밖에 없습니다.
http에서 한 페이지를 보려면 우선 요청한 html 문서를 다운받은 후,,
그 html문서를 모두 파싱해야하며
이미지 등의 추가적인 다운로드를 위해서
서버에 리퀘스트를 보내는 시간과 다운로드에 드는 시간을 기다려야하며,,
이는 다운로드의 횟수와 크기에 따라 시간이 달라지게됩니다.
하지만 이를 FTP 처럼 전용 프로그램으로 서버에 접속하게 한다면,,
형식화된(html보다 훨씬 간단한) 프로토콜을 파싱한 후
추가적인 다운로드가 있는지 판단해서 없다면 하지않을 수 있죠..
유저가 기다리는 시간 역시 줄어들겠지만,,
서버측면에서도 리퀘스트가 줄어 처리량이 줄게 되며,
필요한 대역폭 역시 줄어들게 됩니다.
물론 이러한 방식은 추가적인 프로그램의 다운로드가 필요하게됩니다.
하지만 목적이 http를 완전히 대체한 프로토콜이 아니라,,
http를 사용하기 적합하지 않은 곳이나,,
속도나 기능면에서 http보다 낳은 성능을 낼 수 있는 곳 과 같이
특정목적에서 http를 대체할 프로토콜이라면
충분히 개발할 가치가 있다고 생각합니다.
zdnet의 글에서도 지적했듯이HTTP 는 httpd/브라우저 의
zdnet의 글에서도 지적했듯이
HTTP 는 httpd/브라우저 의 CS 라고 할 수 있지만,,
http 자체만으로는 절대로 서버쪽에서 클라이언트를 제어할 수없습니다.
서버에서의 정보가 변하더라도,,
브라우저를 리프레쉬하지 않는 이상 유저는 그 사실을 알 수 없습니다.
이는 엄청난 단점이라고 생각합니다.
쉬운 예로 http만으로는 깔끔하게 웹채팅을 만들어낼 수 없죠..
그리고 또한 http는 TCP/IP 위에 얹혀있긴 하지만,,
TCP/IP가 connection-orinted 인반면
http는 connectionless 이라고 볼 수 있습니다.
http 에서 로그인/로그아웃 등을 구별하려면
브라우저가 보낸 쿠키를 보고
지난번 리퀘스트와의 시간차(서버설정에 따라..)를 계산해야 합니다.
뭐 가능하기는 하지만 어쨌든 깔끔한 방법은 아니라고 봅니다.
또 온라인 뱅킹을 하기 위해서도 보안을 위해서
추가적인 프로그램이 필요하며
현재는 이러한 프로그램들이 거의 대부분 activeX이죠..
하지만 온라인 뱅킹만을 위한 서버가 존재하고
그 서버에 접근하는 전용 프로그램이 있는 것이
보안및 속도(latency)면에서 더 뛰어납니다.
하지만 현재는 http 로 저것들을 모두 구현하고 있습니다.
웹채팅만 보더라도 activeX, 애플릿 등을 이용하게 되며,,
모든 플랫폼에서 같은 동작을 보여야할 표준으로서의
http의 장점은 떨어질 수 밖에 없죠..
즉 문제는 http가 잡다하게 많은 것을 표현할 수 있다고해서,,
그리고 점점 더 많이 쓰이는 추세라고 해서,,
적합하지 않은 곳에서까지 http가 사용되고 있고,,
그렇게 하기 위해서 온갖 잡다한 꽁수들이 동원되고 있습니다.
확실한건 현재 우리나라에서 http이 차지하는 비중이 너무 많다는겁니다.
확실한건 현재 우리나라에서 http이 차지하는 비중이 너무 많다는겁니다.
너무나도 매력적인 irc, newsgroup, p2p 등이 있는데
인터넷 하면 대부분 웹브라우저를 생각하니까요...
컴퓨터에 관심이 없는 사람은 어차피 지금 있는거만 잘 사용해도 사회생활하는데는 지장 없으니까 심각하게 생각하지 않지요
근데 왜 자꾸 스타크래프트가 생각나는걸까요?
우리나라사람 스타 진짜 좋아하잖아요...몇년이 지났는데도 계속 하는거 보면은... 마치 우리나라에서 게임은 스타만 있는것 처럼.
그다지 좋아보이지는 않네요
스타크레프트처럼 잘만들어진 겜은 극히 드뭅니다.아니 아예 없다고도
스타크레프트처럼 잘만들어진 겜은 극히 드뭅니다.
아니 아예 없다고도 생각됩니다. 그러니까 스타를 많이하고 벌써
5년이넘게 흘러도 아직도 스타를 많이 하지요..
스타를 대체할만한 겜이 나오지 않는이상 스타는 계속할겁니다.
그런데 스타크레프트를 대체할겜은 바로 스타크레프트II가 될겁니다.
갑자기 웬 스타크 얘기입니까?ㅡㅡ;;
갑자기 웬 스타크 얘기입니까?
ㅡㅡ;;
잼나니까 하지요 :)
잼나니까 하지요 :)
서버에 요청한 후 5일 동안 결과를 받지 않아도 될 정도의 장시간 요청을
서버에 요청한 후 5일 동안 결과를 받지 않아도 될 정도의 장시간 요청을 수행할 수 있는 방법을 모색해야 한다"고 말했다. -> 프로토콜이 이러한 것을 고려한다면 현재의 http보다 얼마나 무거워져야 할 지에 대해서는 고려치 않는 것 같네요.
최초에 문제로 언급되어진 웹서비스란 부분은 요즘 많이들 얘기되어지는 soap/wsdl/uddi부분을 말하죠.. 서비스는 soap으로 http위를 타고 다니는데 "트랜잭션이 이루어지는 부분일 경우 3분이 넘어간다면 중개자가 허락을 않하지 않겠느냐"~ 라는 말은 틀린 말이 아닙니다.
하지만 잘못 된 것 중의 하나는 웹서비스에 대한 개념을 이 글을 쓰셨던 분이 잘못잡고 문제를 제기한 것인데, 웹서비스란 것으로 억지로 rpc레벨까지 내려가도 가능은 하지만, 본래의 의미는 서비스란 것이죠..
서비스란 기능의 단위에는 적합하지만 억지로 트랜잭션이 견고하게 결합되어 있는 하나의 3개의 페이지로 구성된 하나의 서비스를 굳이 3개의 웹서비스로 볼 필요가 없다는 것이죠..
웹서비스란 것은 rpc라기 보다는 서비스객체, workflow에 접근해야 하는 것인데 soap의 기능성을 바라보다가 http의 단점에 대해 특화된 프로토콜과 비교하는 식으로 너무 하단에 치중한 것은 아닌가 싶습니다.
너무 프로그래머의 생각에 치중한 게 아닐까요? 생각해야할 것은 비즈니스의
너무 프로그래머의 생각에 치중한 게 아닐까요? 생각해야할 것은 비즈니스의 요구사항을 충족할 수 있느냐 없느냐가 제일 우선 아닌가요?
현재 얘기되어지는 것은 http 프로토콜과 웹서비스에 관한 논의랍니다.^
현재 얘기되어지는 것은 http 프로토콜과 웹서비스에 관한 논의랍니다.^^;;
그러니까 한 말이져. 이런 논의가 발생한 원인은 프로토콜 자체에 어떤 문
그러니까 한 말이져. 이런 논의가 발생한 원인은 프로토콜 자체에 어떤 문제가 있어서가 아니라 비즈니스 요구사항을 http와 현재의 웹서비스가 충족하지 못하고 있다는데서 나온 거니까요. 그러니 http 자체만 가지고 논의하는 것은 무의미한 일이죠. 오히려 요구사항을 어떻게 하면 충족할 수 있는가를 논해야하는 거겠죠.
프로그래머들은 종종 기술을 위한 기술에 치우쳐 그 기술이 목적에 적합한가를 돌보지 않는 일이 많더군요.
논의가 자꾸 비껴나가고 있네요.. 비즈니스의 요구사항을 현재의 http와
논의가 자꾸 비껴나가고 있네요.. 비즈니스의 요구사항을 현재의 http와 현재의 웹서비스가 충족하지 못하고 있다는 의미가 아니라, 비즈니스 요구사항을 충족시킬 수 있는 서비스를 왜 결함있는 http를 꽁수를 써가면서 하느냐라는 얘기죠~ 그리고 웹서비스에 대한 의미를 일반적인 웹서비스로 보시는 듯 싶은데, 여기서 언급되어지는 용어 웹서비스란 soap-rpc, wfdl, wsdl, uddi가 결합된 서비스를 일컫습니다.
글의 내용을 자세히 보면 rpc, 트랜잭션 얘기로 볼 때 비즈니스 요구사항을 웹서비스가 충족시키지 못한다는 내용이 아니라, "웹서비스가 이 프로토콜을 이용해 시간이 많이 걸리는 트랜잭션을 수행하면 문제가 발생한다. "라고 되어 있잖습니까?
말씀하신 것처럼 비즈니스 요구사항을 충족시키지 못하는 http와 웹서비스란 식으로 같은 편에 서 있어서 논의가 되는게 아니라, http프로토콜을 이용한 wsdl/uddi를 이용할때 soap-rpc를 사용함에 있어서 문제가 있는데, 왜 굳이 http를 쓰려 하는 것입니까란 것이 정확한 논의점입니다.
개발자가 아닌 분들은 종종 용어를 크게 혼동해서 잘못이해한 지식으로 종종 동문서답식으로 문제를 야기 시킬 때가 있더군요.
(비개발자 : xp? 유행이죠 window xp!!
(개발자 : extreme programming을 말하고 있음..
(비개발자 : 웹서비스? 비즈니스 요구사항을 충족시키는 웹에서 이루어지는 서비스
(개발자 : wfdl, wsdl, uddi, soap으로 웹에서 이루어지는 서비스를 개발하는데 사용할 http-xml이 결합된 아키텍쳐를 말하고 있음
충족이란 말의 의미를 서로 다르게 쓰고 있는 듯 하군요. 어차피 그 얘기
충족이란 말의 의미를 서로 다르게 쓰고 있는 듯 하군요. 어차피 그 얘기를 한 건데..
어쨋든, 논의의 발생은 비즈니스 요구사항에서 왔다는 것까지 부인하진 않으시겠죠?
그리고, 왜 굳이 http를 쓰려하는 것입니까..하는 게 정확한 논의점인 게 아니라 님의 주장인 거겠죠-_- 정확한 논의점은 요구사항의 충족을 위해 "어떤 해결책"을 강구해야할 것인가..인 듯 하네요. 그 해결책은 http를 개선하는 것이 될 수도 있고 http 대신 다른 프로토콜을 쓰거나 조합하는 방식이 될 수도 있는 거죠. 발제문 자체가 제시하고 있는 문제도 두 가지고 해결책은 제시한 것도 없는데 그런 식으로 맘대로 논의를 제한해놓고 논의를 비껴나가고 있다는 건 좀 그렇네요.
그리고 xp 이야기는 좀 듣기 민망하군요. 프로그래머 이야기에 반발로 하신 말씀이신지?
비즈니스에서 웹서비스가 뭘 말하는 건지는 '전혀' 중요하지 않습니다. 그게 요구사항을 충족하느냐 아니냐가 중요할 뿐이죠. 굳이 웹서비스를 웹과 떼서 생각하려는 시도가 여기서 어떤 의미가 있는지 모르겠네요.
제가 보기엔 위의 글은 HTTP프로토콜에 대한 문제점에 대한 글로 밖
제가 보기엔 위의 글은 HTTP프로토콜에 대한 문제점에
대한 글로 밖에 보이지 않습니다. 실제로 통합툴이라던가
하는 개발자 측면으로 볼때는 보다 상위의 Hyper Text
쪽을 수정해야 하지 않을까 싶군요.
움.. 그에 따른 프로토콜도 바뀌어야 할것 같지만요.
제가 발제자의 글을 잘 못 이해했는지 모르겠지만 ZDNet의글은 말씀
제가 발제자의 글을 잘 못 이해했는지 모르겠지만 ZDNet의
글은 말씀하신 웹서비스(우리가 아는 웹페이지 등을 보여주는
것)가 아니라 분산 컴퓨팅, 차라리 CORBA에 가까운 것입니다.
때문에 처리에 시간이 오래 걸리는 것을 HTTP자체로 해결
하는 것이 힘들다고 보고 문제를 제기한 것이지요. 그런데
인용문과 달리 발제하신 분은 전자의 웹페이지 퍼블리싱에
가까운 문제 제기를 하셨고 답변을 하시는 분들도 그쪽으로
가는 것 같습니다. 일단 인용문의 문제로 돌아가면 HTTP자체
로 일반적인 해결은 힘들 것으로 보이며 서비스 프로바이더
간의 문제로 국한 한다면 Messaging Service를 사용해서
해결이 가능합니다. (리퀘스트 트랜젝션하나, 리스판스
트랜젝션 하나, 레퀘스트를 받는 쪽에서, 보낸쪽에서
양방 모두 Messaging 큐를 사용하고요.)
참 동감하는 바입니다. 결국 돈문제일 것 같은데 역시 이런 비용을 감
참 동감하는 바입니다.
결국 돈문제일 것 같은데 역시 이런 비용을 감수할 수 있는 곳은 점넷의 M$밖에 없는 것일까요?
밑에 두 분이 목적이 다른 프로토콜이 있으니 목적에 맞는 걸 쓰면 된다는
밑에 두 분이 목적이 다른 프로토콜이 있으니 목적에 맞는 걸 쓰면 된다는 말씀을 하시는데 맞는 말이긴 하지만, 기왕이면 두 목적을 다 충족시키는 프로토콜이 있으면 좋지 않겠습니까? 꼭 리눅스는 서버용이니까 GNOME이 발전하든 KDE가 발전하든 상관 없다는 주장과 비슷하게 들리네요.
제 생각은 이렇습니다. 현실적으로 엔터프라이즈 어플리케이션에서 웹서비스란 개념이 아주 좋은데 그 기반 프로토콜의 한계로 비즈니스 요구사항을 충족하기 어려운 단점이 많고 상당한 편법과 꽁수를 동원해야합니다. 그런 반면 과거의 C/S 환경은 그런 단점은 없지만 웹서비스에 비해 개방성과 확장성이 부족하고 많은 사용자가 있는 시스템에 적합치 않죠. 그래서, 웹서비스의 장점과 C/S의 장점을 합해서 개방적이고 확장성이 뛰어나면서도 파워풀한(물론 튼튼한 보안 인증이 필요하겠죠.) 프로토콜이 있으면 좋지 않을까..하는 것입니다.
이를테면, 애플릿으로 모래상자의 한계를 넘으려면 인증서를 발급하고 서명을 하는 과정을 거쳐야합니다. 이 과정에서 프로그래머가 수동으로 해줘야하는 일이 애플릿의 요구사항이 커질수록 늘어나고 소모적인 일이 됩니다. 또 업로드하는 것도 업로드 프로그레스바 같은 걸 표시하고 좀더 안정적으로 업로드하려면 고가의 업로드 유닛을 구입하거나 아니면 상당량의 코딩을 해야하죠. 다운로드 같은 것도 현재는 브라우저의 다운로드는 불안정한 점도 있고 이어받기도 잘 안되고 그래서 플래시겟 같은 걸 쓰는 사람이 많습니다. 만약 이런 클라이언트에서 일어나야하는 작업들을 프로토콜과 브라우저 차원에서 해결할 수 있다면 어떨까요?
J2EE를 예를 들어보면, 과거에는 프로그래머가 직접 사용자의 인증과 세션을 처리했었죠. 하지만 J2EE에서 인증을 컨테이너가 처리할 수 있게 만들어서 프로그래머도 상당히 할 일이 줄고 안정성도 높아졌습니다. 트랜잭션도 프로그래머가 직접 관리하던 것에서 컨테이너에게 책임을 넘김으로써 여러 가지 많은 장점을 가져왔죠. 이런 개념에서 HTTP가 좀더 확장되어 클라이언트에서 일어나는 잡다한 일들을 HTML 태그 등으로 브라우저에 넘겨 처리하게 할 수 있다면 프로그래머는 소모적인 작업이 훨씬 줄고 좀더 비즈니스 로직에 집중할 수 있겠죠.
더불어 이런 브라우저가 표준이 된다면 리눅스도 인터넷 뱅킹의 수혜자가 될 수 있겠죠. 보안 문제도 훨씬 쉽게 해결할 수 있게 될 꺼구요.
머..그런 정도.
저는 통합툴에는 찬성하지만 다목적의 프로토콜에는 반대합니다.말씀하신
저는 통합툴에는 찬성하지만 다목적의 프로토콜에는 반대합니다.
말씀하신 J2EE는 제가 생각할때는 새로운 통합프로토콜을 지향한다기 보다는 작업의 성격에 맞춰 기존의 프로토콜로 매핑해주는 말 그대로 통합 틀이 아닐까 생각하는데요.
브라우저 또한 주어진 url을 분석해서 주어진 프로토콜에 따라 직접 처리를 하거나 해당 plug-in이나 add-on을 불러서 처리할 수 있도록 만들어진 통합툴이고요.
기본적으로 하나의 프로그램(혹은 모듈)은 하나의 기능만을 수행해야 한다는 평소의 소신 때문이기도 하지만 프로토콜은 인터페이스의 문제고 인터페이스가 복잡하면 바람잘날이 없다는 만고불변의 진리를 믿기에 프로토콜은 절대로 가벼워야 한다고 생각합니다.
현재의 프로토콜로 하지 못하는 일이 있다면 예를 들어 P2P, 해당 표준을 만든 다음 그놈을 위한 plug-in이나 add-on을 만들든가 도저히 안되면 애플리케이션을 만들어서 bind 시켜주면 되지 않을까요. 메신저? 표준 프로토콜만 있다면 브라우저에 통합시켜 넣는게 결코 어렵지 않으리라 생각합니다. 지금으로선 MS만이 할 수 있는...-_-;
그리고 제가 생각할때 통합프로토콜의 용서할 수 없는 단점, 폐쇄성의 강화입니다.
개발자 참여의 문턱을 높인다는 점에서 폐쇄적이고 독점의 가능성을 높이다는 점에서도 그렇지요. 표준적인 프로토콜을 사용하는 여러 제품들이 다양한 계층으로 존재하는 시장이 독점적인 대체물의 등장으로 시장전체가 와해되는 시장보다 훨씬 안정적이고 소비자 지향적이라고 생각합니다.
점넷에 대한 설명을 들었는데요,점넷의 1단계 목표는 다른 프로토콜을
점넷에 대한 설명을 들었는데요,
점넷의 1단계 목표는 다른 프로토콜을 다 없애버리고 HTTP 위에 SOAP를 얹어서 통신을 하다가 2단계에서는 HTTP도 없애버리고 TCP/IP 위에 바로 SOAP을 얹어서 네트워크 세상을 통일하는 거랍니다.
개념없는 초딩들은 좋은 말로 할때 DC나 웃대가서 놀아라. 응?
확실히 P2P 프로토콜은 좀 표준화 되면 좋겠습니다. 엇비슷한 메신저 여
확실히 P2P 프로토콜은 좀 표준화 되면 좋겠습니다. 엇비슷한 메신저 여러개 띄우고 있을라면 꼭 이래야 되나 하는 생각도 들고.
하지만 웹의 한계를 극복하는 통합된 브라우저는 별로 보고 싶지가 않네요. 사실 http, telnet, ftp 각자 전문기능을 중심으로 만들어진 놈들인데 굳이 파일전송도 http로 콘솔에서나 할 작업도 http로 해야 한다고 우겨되는 사람들 보면 답답하지요. 물론 그런 요구를 들어줄 수 밖에 없는게 시장의 현실이고 그런 요구를 들어주면 뭔가 기술적으로 대단한 혁신을 한것처럼 떠벌여 댈 수 있는 근거가 생기는게 요즘세태이긴 하지만. 전문화된 간단하고 효율적인 가벼운 프로토콜이 세상을 지배했으면 하는게 재 바램입니다. 그리고 어플리케이션이 작업별로 프로토콜 바꿔가면서 쓰면 굳이 통합프로토콜 안만들어도 되지않을까요...^^; 이게 브라우저 같은데...
좀 새면 브라우저에서 http 생략하는 꼼수가 결국 이런 현실을 낳는데 일조 하지 않았을까요. 표준을 무시한 경쟁이 초래한 역사의 복수...^^;
그리고 이미 언급하신 것처럼 텔넷은 쓰기싫고 작업은 interactive하게 해야겠다면 제가 볼때는 애플릿쓰는게 제일 나을 것 같은데. 클라이언트별로 security policy 세팅하고 certificate import 하는게 좀 귀찮기는 하겠지만 이거야 말로 http로 일괄 배포가 가능한 것들이니 SI에서야 문제 될게 없을 것 같은데요.
애플릿이 요즘은 security policy 세팅을 안해도 되는 것 같더
애플릿이 요즘은 security policy 세팅을 안해도 되는 것 같더군요. 저두 1.2 때 쓰여진 문서와 책들을 보면서 했었는데 1.3에서는 서명만 해주니까 그냥 되네요-_-
제가 알기론1.0 - sand box 모델 : 무슨 수를 쓰던 애
제가 알기론
1.0 - sand box 모델 : 무슨 수를 쓰던 애플릿은 안된다.
http://java.sun.com/docs/books/tutorial/figures/security1.2/scrtymdl.gif
1.1 - signed applet : 사인만 되면 무슨 짓이든 할 수 있다.
http://java.sun.com/docs/books/tutorial/figures/security1.2/scrtmdl2.gif
1.2 - security policy
http://java.sun.com/docs/books/tutorial/figures/security1.2/scrtmdl3.gif
이렇게 알고 있습니다.
제가 1.3의 security 모델을 잘 모르지만 policy file 지정안하시고 하셔서 default policy가 적용됐고 거기서 허용하도록 돼있었던게 아닐까요. 1.1과의 호환성을 유지하기 위해서 그렇게 하지 않을까 싶은데요.
님 말씀이 맞군요. 1.3에서는 1.2에서 디폴트가 아니던 것 중에 디폴
님 말씀이 맞군요. 1.3에서는 1.2에서 디폴트가 아니던 것 중에 디폴트가 된 게 좀 있네요. 1.2에선 File.listRoots() 메쏘드는 정책 설정을 안하면 아무 것도 리턴을 안하는데 1.3에서는 안해도 리턴을 해주네요. 그 외에도 몇 가지가 있는 것 같더군요. 여전히 다른 사이트에 접속한다거나 하는 건 정책 설정이 필요하네요.
http가 대성공을 이루고, 기존에 독립 애플리케이션으로 제작되던 여러
http가 대성공을 이루고, 기존에 독립 애플리케이션으로 제작되던 여러 프로그램들이 웹브라우저를 통한 cgi 및 서버 스크립트 언어 등으로 통합시키면서 슬슬 http자체가 가진 특성과 배치될수밖에 없는 제한사항이 생기는 것은 당연한 일인듯 합니다. 여기서 다른 예는 잘 모르겠고, P2P만 들어 생각해 본다면, P2P는 P2P의 목적에 맞도록 별도로 설계된 프로토콜을 사용할 것이고, 애초에 http와 P2P는 목적부터 틀린 놈들이므로 굳이 http를 P2P에 갖다 붙이려고 하면서 잘 안붙는다고 불평하는 이유를 모르겠네요. 사용자들이나 윗선에서 P2P를 http로 구현해야 한다고 압력이 들어와서 괴로워서 그러나? 하긴 잘 되기만 한다면 굳이 별도로 프로그램 설치할 필요 없이 웹브라우저 하나만 있으면 될테고 기존에 웹기반에서 개발된 여러 기반구조들도 좀더 쉽게 활용할 수 있을테니 폼은 나겠네요. :-)
본문(zdnet에 올려진)의 요지를 보면,"인터넷의 사용용도가 바
본문(zdnet에 올려진)의 요지를 보면,
"인터넷의 사용용도가 바뀌고 있다.(정보의 교환 -> 그이상의 무엇)
따라서, 가장 많이 사용되는 프로토콜에 대한 근본적인 대체안이 필요하다."
이런 내용인 것 같은데...
변화자체는 급속히 이루어지는 것이 아니라 점진적인 성격이 강하고,
따라서, 웹의 트랜드 또한 http의 한계를 극복하기 위해,
융통성있게(다르게 말하면 편법적으로) http를 활용하고 있지만,
어느 순간이 되면, 치명적인 한계에 부디치게 될 것이며,
따라서 이를 대체하기 위해 많은 업체들이 새로운 프로토콜 개발에
노력하고 있으니, 관련자들도 이에 대한 마인드를 가져야 한다는 것 같습니다.