scripting languages과 web application의 미래는?

atie의 이미지

여기에 있는 이것을 보고난 후, 며칠 전 슬쩍 읽고 지나갔던 OSNews의 Ruby on Railsdynamic language 에 대한 글을 다시 한번 읽어 보았습니다.

아무래도 프로그래머에게는 언어에 대한 이야기가 가장 재미(?)있을텐데, 주제를 약간 좁혀서 웹 어플리케이션을 염두에 두고 Ajax 같은 새 기술등도 곁들여서 이야기 해 보았으면 합니다.

Java는 이제 10년을 맞아 정점에 섰고, 웹 어플리케이션을 위한 셀 수도 없는 Framework들이 나오고 있습니다. 그런데, 요즘 저는 개발 생산성을 놓고 보았을 때, 과연 계속 이 추세가 유지될까 하는 의문을 가지고 있습니다. 개인 용도로 가끔씩 php를 써서 코딩을 해보는 제게도 "이렇게 편한 길이 있는데..."하는 생각이 들 때가 많거든요.

규모가 있는 어플리케이션에서는 "아직도 자바가..."하는 생각을 이제는 버려야 할 때인가요? 회사의 새 웹 어플리케이션 프로젝트를 C#+ASP.Net으로 진행하면서 "웬지 다른 돌파구가 있나" 하는 고민에 여러분의 고견을 묻습니다.

ps. 위에 링크한 video 데모 보시고, 신공에 대한 정보도 팍팍 주시길 기대합니다.

익명 사용자의 이미지

twisted 도 흥미롭더군요.

http://zope.openlook.org/blog/894

nohmad의 이미지

저는 지금 RubyOnRails 프레임웍으로 개인 프로젝트를 진행하고 있습니다. 0.7 버전 때부터 가장 최근의 0.11 버전까지 계속 숨가쁘게 쫓아가고 있는데, API도 휙휙 바뀌고, 0.1 올라갈 때마다 엄청난 선물보따리들이 마구 쏟아져서, 제대로 돌아가게 고치는 것은 고사하고 이번 선물(업그레이드)에는 또 뭐 새로운 게 들었나 풀어보는 데만도 한 세월입니다. -_-; 신생 프레임웍을 일찍 채용하는 자의 비애랄까요?

개발 프레임웍으로써의 품질은 최고입니다. 기본이 되는 MVC 프레임웍이 필요한 것을 중심으로 매우 심플하게 갖추어져 있고, 테스팅 프레임웍도 훌륭합니다. Unix 친화적인 루비의 특징이라고 할 수 있을텐데, 웹어플리케이션의 동작을 커맨드라인에서 인터랙티브하게 에뮬레이션할 수 있다는 것이 큰 장점입니다. 루비 인터랙티브 환경에 한 번 익숙해지면 DB 접속창 따로 열 필요도 없어집니다. 디버깅도 코드 중간 어디서나 breakpoint만 삽입하면 그 순간의 스택을 덤프해서 원격으로 서빙해주니 매우 편리하게 진행할 수 있습니다.

현재 주요 도입현황을 보면, 미국에서는 43things.com, tadalist.com 같은 소셜네트워크가 이 프레임웍으로 구축되어 인기를 얻고 있고, Rails의 개발자인 David Hansson이 만든 프로젝트 관리 싸이트 Basecamp 싸이트도 상당히 좋은 평가를 받고 있습니다. 포드캐스팅 전문 싸이트인 odeo.com이나 cdbaby.com 등이 Rails를 이용하여 싸이트 리뉴얼을 준비하고 있습니다. 데비안 사회적 계약의 작성자인 Bruce Perens씨는 현재 slashcode로 제작된 technocrat.net을 Rails로 재작성하고 있다고 합니다. 그외에도 메일링리스트에는 하루가 다르게 프레임웍 채용 소식이 올라옵니다.

RubyOnRails가 웹프레임웍 시장에 이제 갓 선을 보인 신생 프레임웍으로써, 현재 웹어플리케이션 시장을 주름잡고 있는 J2EE와 PHP 사이에서 어중간한 위치에 있다고도 할 수 있습니다. 현재 PHP 진영쪽은 더 이상 PHP로는 유지/관리되는 코드를 만들기 힘들다는 생각이 널리 퍼져 있는지, Rails가 돌아가는 것을 본 사람들은 다시 PHP로 돌아가기 싫어하고, Rails에 대한 특별한 경쟁의식 같은 것도 가지고 있지 않은 것처럼 보입니다. 그러나 J2EE 진영에서는 Rails측에서 광고하는 J2EE 대비 10배의 개발자 생산성이란 문구에 대해 강한 거부감을 가지고 있고, 게시판 상에서 험한 말도 마구 오가고 있어 분위기가 살벌합니다.

제 생각에도 사실 10배는 좀 심하다고 생각하는데, 일반적인 J2EE 개발이 개인이 감당하기 힘들 정도로 거대한 프레임웍들과 복잡한 설정파일들로 이루어져 있다는 것은 매우 분명해보입니다. 자바하는 사람들 중 자바만 알고 자바만이 최고라고 생각하는 일부 사람들을 자바리안(java + barbarian)이라고 경멸하는 것도, 통상의 자바 프로그래머들이 워낙 거대한 프레임웍들에 치여 살기 때문에 시야가 좁아질 수밖에 없는 현상을 비꼰 것이라고 생각합니다.

논란이 된 서버사이드쪽의 논쟁을 보면, 자바 진영에서는 스크립트 언어를 매우 비하하고, scalability 문제를 집중 공격하고 있음을 알 수 있는데, Rails는 캐싱 프레임웍도 잘 갖추어져 있고, fastcgi dispatcher로 돌리면 확장성 문제도 쉽게 해결됩니다. 게다가 요즘 뜨고 있는 가벼운 웹서버인 lighttpd 위에서 돌리면, 일반적인 J2EE 지원 WAS 못지 않은 성능을 낼 것이라고 확신합니다. 게다가 오픈소스 아닙니까. RubyOnRails는 MIT 라이센스로 개발되고 있습니다.

Java Server Face의 저자 David Geary, Java Performance에 관한 저술로 유명한 Bruce Tate 등이 RubyOnRails에 관한 책을 내기로 했고, J2EE쪽에서의 이탈은 분명히 있을 것으로 생각됩니다. 이런 이탈이 기존 J2EE 스타일의 개발방식에 대해 뭔가 충격을 주었으면 하는 생각입니다.

한때 C++처럼 강력한 정적 타입 시스템을 가진 언어만이 프로그래머의 실수를 줄이고 프로그램을 좀더 견고하게 만들 수 있다고 생각했던 때가 있었습니다. 그러나 정적 타입에 의존하는 것보다는 테스트 중심적인 개발이 보다 견고한 프로그램을 만들 수 있다는 것이 실전에서 증명되기 시작하면서 프로그래머를 제약하는 정적 타입 언어들의 한계가 노출되고, 루비, 파이썬처럼 동적이지만 강력한 타입을 가진 언어들이 주목을 받고 있습니다. 이제 이러한 흐름이 웹개발에도 적용될 수 있을지 더 지켜봐야 할 것 같습니다.

죠커의 이미지

C#은 좋지만 ASP.net 환경은 매우 싫어합니다. 웹 콘트롤이란 것은 사실 정형화된 작업에 적합한데 웹 콘트롤을 써서 정형화된 작업을 하는 생산성은 오히려 JSP보다도 떨어진다고 생각합니다.

RubyOnRails가 괜찮나요? Ruby를 먼저 익혀봐야 하겠죠?

offree의 이미지

잘 모르고 이야기하는 것이라 양해바랍니다. ^^

Ruby 는 자체 웹서버(?) 가 따로 있는지요?

Python 같은 경우 Zope (웹서버라고만 하기는 그렇지만.) 라는 것이 있는 것 같은데 말이죠.

또한 apache 위에서도 작동하는지요?

Python 이냐 Ruby 냐..

사용자가 바꾸어 나가자!!

= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com

nohmad의 이미지

offree wrote:
잘 모르고 이야기하는 것이라 양해바랍니다. ^^

Ruby 는 자체 웹서버(?) 가 따로 있는지요?

Python 같은 경우 Zope (웹서버라고만 하기는 그렇지만.) 라는 것이 있는 것 같은데 말이죠.

또한 apache 위에서도 작동하는지요?

Python 이냐 Ruby 냐..

Zope 같은 경우는 애플리케이션 서버(WAS)이면서 또한 프레임웍으로써의 성격도 가지고 있어서, 이와 비슷한 경우를 다른 언어에서 찾는다는 것은 매우 힘들 것입니다. J2EE이면서 WAS라고 할 수 있을까요?

웹서버라는 한정된 용도에서 봤을 때, 루비 표준 라이브러리에 포함된 webrick이라는 순수 루비로 구현된 웹서버는 그럭저럭 쓸만 합니다. 파이썬의 경우도 표준 라이브러리에 여러 종류(?)의 웹서버가 포함되어 있습니다만, 실제 애플리케이션에서 그것들을 사용하는 경우는 거의 보지 못했습니다. 그러나 루비의 webrick은 프로그래밍 인터페이스도 훌륭하고, 웹서버로부터 CGI를 통해 호출되는 것보다는 webrick 자체 서버를 이용하여 서블릿으로 동작하는 것이 보다 나은 성능을 내기에 CGI 방식보다는 많이 선호되고 있습니다.

RubyOnRails의 경우를 예로 들면, 자동 리플렉션이나 관계 모델링 등 서비스 초기화에 상당한 오버헤드가 있는데, CGI 방식의 경우는 매번 이 불필요한 초기화를 해야 해서 성능이 극도로 나빠집니다. RubyOnRails의 개발자가 그전에 만들어 공개한 instiki라는 위키 프로그램은 쉬운 설치과정(no 3 step, only 2 step)을 표방하며 나온 것으로 자체 웹서버로 돌아가는데, 이런 경우 여느 CGI 방식의 위키 프로그램들보다는 훨씬 나은 성능을 내고 있습니다.

그래도 역시 아파치 모듈로 동작하는 mod_ruby나 fastcgi 방식보다는 느립니다. 아파치 모듈 방식은 모듈로 결합하는 순간 아파치 프로세스 자체가 커져서 메모리를 많이 소모한다는 단점 때문에, 예를 들어 아파치 서버에서 mod_php, mod_perl, mod_python, mod_ruby를 모두 돌릴 때의 성능 저하는 엄청날 것이라고 생각합니다. fastcgi의 경우는 프로세스 생성 부담없이 웹서버와 소켓을 통해 통신하기 때문에 확장성도 좋고, 성능 또한 우수합니다.

RubyOnRails의 경우는 dispatcher를 추상화함으로, cgi, mod_ruby, fastcgi, webrick 서버에서 모두 돌아갈 수 있습니다. webrick의 장점은 개발과정에서 미리 서버 설정 때문에 골치아파하고 시간낭비하지 않아도 된다는 점입니다. 통상의 J2EE 프로그래밍이 톰캣 설정 때문에 한 세월 보내는 것에 비하면, webrick dispatcher가 주는 장점이 크게 부각될 수 있을 것으로 보입니다.

tasy의 이미지

많은 사람들이 생각하고 있는 이유와 같이(생산성, 유지보수 등) 스크립트 랭귀지(인터프리터를 사용하는 프로그램이라 하는게 더 좋을지도 모르겠네요)들은 점점 더 많이 사용될 것 같습니다. 물론 제 개인적인 생각이지만요.

하지만, 실제로 서비스 개발에서 이들 언어들이 차지하고 있는 비중이 점점 높아진 다는 것을 생각했을 때 무시할 만한 수준은 아니라 생각되는군요.

http://www.sauria.com/~twl/conferences/pycon2005/20050325/Python%20at%20Google.notes

위는 PyCon2005의 강연노트중 하나인데요. 구글에서 python의 사용에 대한 이야기입니다. 그들은 Python을 사용함으로써 얻는 생산성이나 유지보수의 이점들을 잘 알고 있으며 그 이점들을 여러부분에서 이용하고 있습니다. 우리나라처럼 그래도 자바자... 라는 식의 작업분야를 무시하고 한 언어만을 사용하는게 아니라 최대한의 효율성을 얻기 위해 취사선택하는 문화가 있어서 그런지는 모르겠지만, 외국의 기업들에서 Python과 같은 고생산성을 가진 언어의 채택이 늘어나는 듯 합니다.

국내기업들에서도 채용하는 기업들이 있긴 하지만, 아직 그렇게 많은 수준은 아닌 것 같네요. 그래도 점점 그 변화가 눈에 보일정도로 생길 거라 생각합니다.

저도 이번에 회사에서 Python으로 프로젝트를 해볼려다가 제가 막내라 못했습니다. ㅜㅜ.. 시간이 지나면 점점 바뀔 수 있겠죠.

그리고 원래 주제로 좁혀들어가서 웹 어플리케이션 쪽에서 보면 Ajax같은 기술은

http://www.adaptivepath.com/publications/essays/archives/000385.php

위 글의 말미에서도 밝히고 있는 것처럼 개발하기 용이한 기술이 아닙니다. 복잡한 자바스크립트로 이루어지는 기술이죠. 결국 필요한 분야에 적당히 사용하는 것이 상책이 아닐까 합니다. 뭐, 이런 기술을 쉽게 쓰기 위해서 프레임워크가 나올지도 모르겠습니다만, 아직도 웹에는 html과 form을 받아 처리하는 부분만으로도 작동시킬 수 있는 부분이 절반 이상은 된다고 생각합니다.

당분간 framework가 이곳 저곳에서 사용되는 모습은 있겠지만, 그렇게 폭발적으로 늘어날거라는 생각은 하기 힘드네요. J2EE같은 종류들은 그 분야에서 활발하게 사용이 되겠죠. 다만, 중간급 규모 혹은 조금 더 작은 규모의 작업에서 잘 적용될지는 모르겠습니다.

---------
Byeongweon Moon
http://tasy.jaram.org/blog
사랑하면 알게 되고 알면 보이나니 그때에 보이는 것은 전과 같지 않으리라.

익명 사용자의 이미지

tasy wrote:
위는 PyCon2005의 강연노트중 하나인데요. 구글에서 python의 사용에 대한 이야기입니다. 그들은 Python을 사용함으로써 얻는 생산성이나 유지보수의 이점들을 잘 알고 있으며 그 이점들을 여러부분에서 이용하고 있습니다.

파이선은 펄보다도 속도가 느린 편이라거 알고 있는데 이제는 아닌가요..

익명 사용자의 이미지

손님22 wrote:
tasy wrote:
위는 PyCon2005의 강연노트중 하나인데요. 구글에서 python의 사용에 대한 이야기입니다. 그들은 Python을 사용함으로써 얻는 생산성이나 유지보수의 이점들을 잘 알고 있으며 그 이점들을 여러부분에서 이용하고 있습니다.

파이선은 펄보다도 속도가 느린 편이라거 알고 있는데 이제는 아닌가요..

현재 있는 파이선 구현은 느립니다. 구글에서 사용한다는 것은 속도가 그리 크게 요구되지 않지만 빨리빨이 변경해야 하는 부분에 국한하여 사용하는 것으로 알고 있습니다. 제대로된 사용법이죠.

익명 사용자의 이미지

손님22 wrote:
tasy wrote:
위는 PyCon2005의 강연노트중 하나인데요. 구글에서 python의 사용에 대한 이야기입니다. 그들은 Python을 사용함으로써 얻는 생산성이나 유지보수의 이점들을 잘 알고 있으며 그 이점들을 여러부분에서 이용하고 있습니다.

파이선은 펄보다도 속도가 느린 편이라거 알고 있는데 이제는 아닌가요..

http://dada.perl.it/shootout/craps.html

http://scutigena.sourceforge.net/

atie의 이미지

Tomcat을 설정하기 위해서 한 세월을 보내는 경우는 없습니다. 물론, websphere 같은 WAS를 설정하기 위해서 시간을 소모해야 하는 경우는 있습니다. 요즘은 모르겠지만, IBM의 경우는 path를 잡는 방법이나 사용되는 외부 api들이 철 지난 방식으로 되었던 것이 많았기에 그랬었죠.
그리고, 통상 J2EE 어플리케이션이라고 하면 WAS에서 돌아가는 경우를 뜻하고 (O/R mapping 또는 JMS를 사용하는), Tomcat에서 돌아가는 JSP/Servlet 어플과는 구분지어 언급이 되었으면 합니다.

주제로 돌아와서, 여기에 언급되는 ruby나 python 기반의 framework들도 MVC (Model-View-Controller) 구현은 기초로 하는 것 같은데, 어느 정도로 유연하게 비지니스 모델을 구현하고 확장을 해 나갈 수가 있나요? 질문을 던져놓고 보니, ruby나 python으로 java로 구현하는 만큼의 비지니스 클래스를 만들 수 있느냐 하는 것과 같은 뜻이 되었는데, 잘 아시는 분이 한 번쯤 짚어 주시면 고맙겠습니다. php5 쓰시는 분도 동일 종의 framework가 있다면 답변을 부탁 드립니다.

Ajax 관련해서는, 꼭 이 기술이 아니라고 하더라도, 추세는 현재 서버에서는 html을 생성을 하고 클라이언트(웹 브라우저)에서는 이것을 렌더링하는 방식이, 서버에서는 xml을 생성/이용하고 클라이언트의 역할을 좀 더 고급하게 발전시켜 xml도 html과 함께 처리하는 쪽으로 바뀌고 있다고 생각을 합니다. 제 생각으로, 이러한 방식은 html로 구현할 수 있는 UI의 한계 때문에 기인한다고 보고, 서버는 xml을 생산하는데 중점을 두고 표준화 시키고, UI의 렌더링은 브라우저가 맡아서 처리하는 방식으로 역할 분담이 이루어지리라 봅니다. 나중에, 클라이언트의 기능이 바뀌더라도 서버의 기능은 재사용할 수 있다는 것을 감안하면 올바른 쪽으로 추세가 바뀌는 것이 아닌가 하는 감을 가지고 있습니다.

ps1. 현재 진행하는 그 asp.net 프로젝트에는 UI는 최대한 html 표준을 준수하고, Java Script에 달력 정도만 콘트롤을 사용하고 있습니다. 계획 단계에서 자바와 비교해서 30% 정도 비용 절감을 기대했었고 인도 업체에 턴키로 아웃소싱해서 개발중입니다. Linux 서버에 Servlet을 쓰는 것과 해서 4개 안 정도를 기안했었는데 역시 비용이 문제가 되는 경우라 거래 중인 업체가 최소 금액을 제안하는 것을 높은 분들이 선호하더군요. 일단은 C#으로 비지니스 클래스는 구현해야 한다는 단서를 달아놓고 한가지라도 하는 마음에 반은 실망, 반은 기대를 하고 결과물이 나오기를 기다리는 중입니다.

ps2. Linux를 기업용으로 보급하는 가장 빠른 길은 "인도 개발자들이 리눅스로 개발해야 하는 것이 아닌가" 하는 딴 생각을 ps1.이 결정될 무렵 가졌던 적이 있습니다.

ps3. 미국의 한 증권 업체가 700여대의 pc급 기계에 리눅스와 탐캣을 탑재해서 주식 거래에 걸리는 시간이 9초 였던 업계 기록을 갱신했다는 기사를 몇달 전에 본 적이 있습니다. 700대 pc를 사용하는 이유는 구글과 마찬가지로 고장나는 장비는 갖다 버리는 정책 때문이고, 요청을 지능적으로 분산처리하는 미들웨어를 써서 위의 기록을 갱신할 수 있었다는 기사 내용이었습니다. "탐캣을 사용하면"이 문제가 아니라 "전체 시스템 구성"을 어떻게 하느냐가 문제라는 것을 말하려고 사족으로 답니다.

----
I paint objects as I think them, not as I see them.
atie's minipage

atie의 이미지

Hibernate vs. Rails: The Persistence Showdown

OR mapping에 대한 비교글이 서버사이드에 올랐습니다.

----
I paint objects as I think them, not as I see them.
atie's minipage

익명 사용자의 이미지

특정 industry domain의 knowledge가 담겨있는 샌프란시스코 같은 류의 것을 말씀하심인지, 그저 design pattern의 유기적 결합체 ( framework정도 )를 말씀하시는 것인지 알고 싶습니다.

전자라 하면, 아직 ruby나 python, php에는 그러한 것이 없습니다. 다만 후자의 것들은 다수 있지요. ( 전자의 것을 구현하는 것 자체는 별 문제가 없다고
봅니다. 다만 그럴 의지를 가지는 주체가 없다는 것지요. )

atie의 이미지

전자의 의미로, IBM San Francisco이면 Class Library 쯤이 되겠고, 어플리케이션의 논리상 설계에서는 Business Components와 Business Entities를 의미했습니다. 그렇지만, IBM San Francisco를 염두에 두고 글을 썼던 것은 아닙니다.

이 부분과 개발자 생산성을 관련해서 몇가지 의문점이 있기에 위의 질문을 하였지만, 제 자신이 위에 언급된 스크립트 기반의 Framework들에 대한 경험이 없기에 조목 조목 짚지는 못하겠군요. 답변 주신 글로 "아직 기업 업무에 적용된 경험이 일천해서 구현된 양이 적다, 그렇지만 언어 때문에 생기는 기술적인 문제는 없을 것이다"라는 정도로 이해를 하겠습니다.

다른 관점에서 보면 개발자에게는 새로운 기회일 수도 있겠군요.

----
I paint objects as I think them, not as I see them.
atie's minipage

익명 사용자의 이미지

ruby는 ruby on rails, python은 twisted같은 것이 있습니다.

비지니스 컴포넌트의 구현이 기술적부분이라기 보다는, 비지니스 knowledge의 이해에 포인트가 주어져있는 것이고, 어느정도 유저들에게 이름이 알려질 정도의 ( 이정도가 되면 기본은 되야 하고, 어느 정도 범용성을 획득하는 것이 일반적이기 때문에 ) 수준이 되면 비지니스 컴포넌트 구현에는 별로 문제가 없다고 봅니다.

예를 들어 난마같이 얽혀있는 금융권 시스템 인터페이스의 핵심기술은
아직까지도 FTP입니다. (--;) 기술자체는 별게 아니지만, 프로세스의 복잡함으로 구현에 아주 골머리를 썩죠...

그리고 개발자에게 기회가 될 수 있는건 사실이긴 한데,
제가 보는 견지에서는 이쪽의 개발자들이 이런 비지니스 컴포넌트류에는 별로 의지가 없는 것 같습니다. 더 정확히 말하면 의지를 가질 정도의 경험이 부족하지 않은가 합니다. ( 그 자체를 만든 사람들도 대부분 비지니스 필요가
아니라 개인적인-대부분 학술적인, 아님 취미생활...- 이유로 만들었기 때문에
비지니스적 용도로는 별로 관심이 없습니다. )

creativeidler의 이미지

요즘 자바에서도 비즈니스 컴포넌트가 POJO로 가고 있는 걸 생각해본다면 python이나 ruby는 오히려 자바보다 비즈니스 컴포넌트를 구현하긴 더 쉽겠죠.

익명 사용자의 이미지

ruby나 python을 이용한 개발 Framework에 비지니스 컴퍼넌트 셋까지 포함해서 제공하면, 리눅스 시장에 많은 비지니스 유저들을 편입시킬 수 있지 않을까 하는 생각이... ( 이것들을 이용하면 정말 개발하기 쉽거든여... )

atie의 이미지

Sun BluePrints program에서 AJAX를 J2EE에서 적용해서 할 수 있는 다음의 solution을 자세히 sequence diagram을 곁들여서 설명을 했습니다.

Quote:
some solutions for using AJAX when developing Web applications with the J2EE platform:

* Auto-Complete: Provide a simplifed means of data navigation as the user enters a request in an HTML form.
* Progress Bar: Track the progress on the client of a server-side operation without refreshing the HTML page.
* Realtime Form Validation: Perform server-side validation of form data in an HTML page without refreshes.
* Refreshing Data: Provide up to date data to the an HTML page.

http://theserverside.com/news/thread.tss?thread_id=33319

----
I paint objects as I think them, not as I see them.
atie's minipage

익명 사용자의 이미지

Java와 script language의 비교는 아마 StrongTypeLanguage와 DynamicTypeLanguage의 비교가 아닐까 합니다. Python에서는 부분적인 StrongType을 지원 할까 하는 생각이 있는거 같고. (PEP을 보면 함수의 리턴값을 강하게!ㅎㅎ; 하는거 같더군요.-_-)
또 자바쪽은 유닛테스트를 쓰면 타입 체크가 그리 효용성이 적어진다고 하더군요
(제가 자바를 해보지를 못해서. T_T)

J2EE와 OnRails등의 Framework을 비교해 보자면,
WebFront에서는 PHP/Ruby/Python등이 더 좋은 개발속도가 나올거 같습니다..
(물론 PHP은 Thread을 지원하지 않으니까. 서블릿과 비교는 좀 다를수가 있겠군요.)

아직 다른 프레임워크에서 없는건 EJB같은 (물론 복잡함의 대표주자이지만) 같은
분산 객체/트랜ㅤㅈㅕㄱ션 부분이 없는거 같습니다.. 쉽게 OnRails은 투티어 아닐까요?-_-

트위스트는 비동기 IO을 가진 서버 프레임워크이니까. 정확히는 웹 애플리케이션 레이어에서는 안 맞는게 아니까 싶네요. (물론 Twisted.Web 이나 다른 부분도 있지만요.) 자바의 NBServer와 비슷한걸까요?@_@

자바 머스탱에서는 groovy가 포함될지도 모른다고 (JSR이 등록되었다고 하더군요..) 하더군요.
제 생각에는 프레임워크나 라이브러리 같은 설계중심의 코드는 자바가 구현단계(비지니스 로직,웹 프론트)는 Groovy같은 동적언어가 좋지 않을까 합니다.

스크립트 포 자바 플랫폼이라는 스택에서도 자바 서블릿상에 다른 스크립트 언어를 지원하도록 할려고 하나 봅니다.

OnRails이 매력적인 부분이 있다면 full-stack이라는 점.이더군요..
자바에서 stack을 정할때 투티어일지라도
hibernate+spring+webwork2+jsf+sitemash 등... 3~4개 프레임워크를 함께 써야 해서 학습 곡선이 팍팍 올라가는 듯한...우울함이..=.= (거기다가 EJB까지라면.흑흑.)

익명 사용자의 이미지

자바의 하이버네이트나 온레일의 액티브 레코드 같은 o-r mapping이 Python에서는
있나요? 제가 본것은 sqlobject 하나 밖에 없군요...(아.. 조프의 zodb가 있긴 하군요.)
온레일에 영향을 받은 파이썬의 subway라는 프레임워크가 있더군요.. 내부적으로
sqlobject와 cherrypy을 쓰는거 같습니다.
또 애플의 webobject에 영향을 받은 webwork라는 프레임워크도 있습니다만..
자바는 서블릿 컨테이너가 따로 있는데 다른 프레임워크도 아파치의 cgi/fastcgi/scgi에 물려 있는것 보다 따로 컨테이너로 구성되는 프레임워크를 찾아 봐야겠군요..
요즘 관심이 가는 분야이라서 자꾸 쓸데 없는 글을 올리게 되는 군요..
죄송합니다.꾸벅~ -_- _-_