웹프로그래밍 언어 비교하기

이영진의 이미지

현재 중급 프로그래머로서 공사의 대형 웹 프로젝트를 진행중입니다. php를 jsp로 교체하는 작업인데 규모가 방대합니다. 이곳의 관계자의 말에 의하면 속도면에서는 개선이 안될 지언정 유지보수성, 이식성, 확장성, 다양한 기능 구현등 여러면에서 자바 기술이 좋을 것으로 판단해 돈을 엄청 투자해 리노베이션 프로젝트를 추진하게 되었다고 합니다. 자바의 뛰어난 객체지향적 패러다임의 기반 위에서 만들어지는 웹 서비스(통칭)는 제 개인적인 생각에도 무한한 발전 가능성이 있고, 그러한 발전의 방향으로 나아가게끔 하는 자바의 힘이 있는것 같습니다. 그리고 그런 것만 봐서 그런지 중대형 웹 사이트에서 JSP를 포함한 자바 기반으로의 전환 또는 개발이 두드러지고 있는듯 합니다. 그러나 다른 언어 기반의 웹 애플리케이션에 대해선 다소 문외한이기에 어쩌면 나 자신이 눈먼 장님이 될 수도 있다는 생각이 듭니다. 자바 개발자가 되어 웹쪽으로 먹고 사는 처지인데 과연 웹 애플리케이션 분야에서 쉽고 빠르고 유지보수성이 뛰어나며 확장성이 좋은 언어는 무엇이며 어떤 기준을 적용해야 할까? 다른 웹 개발 언어를 절대 무시하는건 아닙니다. asp로 개발된 사이트 또한 훌륭한 장점을 많이 가지고 있는듯하며 기능또한 jsp에 비해 뒤질것이 없는듯하며 php도 빠르고 쉬우며 간결하고 많은 기능적 우수성을 포함하고 있는듯 합니다. 제가 이 질문을 하게 된 동기는 한쪽으로만 치우쳐서 다른 곳을 보지 못하는 자의 잠깐의 상황파악 정도 라고 생각하시면 될 것입니다.

자바의 핵심 기술, MS c++/vb의 핵심 기술, php의 핵심기술 이렇게 세가지 기술에 대해 어느정도 감을 잡고 계신 분의 의견을 듣고 싶습니다.

* 관리자 코멘트(권순선):
야후!가 php로 전환하고 있다는 소식이 방금 /.에 올라왔네요. 아래 관련 링크를 참고하세요. java, asp, php이외의 perl(mod_perl 등)이나 python(mod_python, zope 등) 및 기타 가능한 웹 프로그래밍 솔루션들에 대해서도 각자의 경험과 의견을 나눌 수 있는 계기가 되었으면 합니다. :-)

dawnsea의 이미지

음... PHP 가 쉽고.. 또 초급개발자들도 많다 보니 (저야 뭐 취미나 알바나 하고 본업은 딴 일이라서 저도 초급이죠) 자꾸 PHP가 쉽고 효율만 좋은 언어로만 매도당하는게 아쉽네요.. 뭐 여기서 그렇다는 건 아니지만...

한 번씩 짚고 넘어가고 싶은 것은..

PHP 는 초급 개발자들에게는 초급개발자 만큼의 최대의 PHP가, 고급 개발자들에게는 고급 개발자만큼의 최대의 PHP 가 있다는 생각입니다...

안 그런가요? 씨익~~ ^____^;;;

익명 사용자의 이미지

읽어보니 이해도가 부족한 사람들이 많아 보이네요. 저도 마찬가지이지만..

제 생각에는 기능을 구현하는 것이 문제가 되지는 않을 거라 생각합니다. 설령 지금 불가능하다고 하더라도 계속되어서 버전업되므로 시간이 문제지요. 그렇다면 비용과 관리의 수월성이 선택에 중요하지 않을까요?

그런면에서 아주 경험이 많으신 분의 글이 실렸으면 합니다. 아니면 외국유명사이트에서 비교자료를 아시는 분은 주소를 가르켜 주시던지...

LikeJAzz_의 이미지

가장쉽고 직관적으로 비교를 해보죠 .

비슷한 실력의 JSP 개발자, ASP 개발자, PHP 개발자가 있다고 할때 ..

JSP 개발자의 연봉이 가장 높고 ASP 개발자가 두번째, PHP 개발자의 연봉이 가장 낮습니다 .

물론 특수한 경우를 제외한 일반적인 경우이며 이는 각각의 서버군들의 가격과 연관됩니다 .

즉, 비싼 프로그램을 다룰줄 아는 개발자는 연봉이 높다고 해야할까요 ?

아이러니하지만 무시할수없는 현실입니다 .

익명 사용자의 이미지

글쎄요... 제가볼 때는 지금 시점에서 자바 개발자에 대한 요구가 많기 때문이라는게 더 적절한 설명 같습니다. 실제로 JSP와 서블릿만 사용하는 프로젝트의 경우 가장 많은 선택은 - 제가 아는 한 탐캣과 레진입니다. 탐캣은 아시다시피 무료이고 레진도 상대적으로 매우 저렴한 편입니다. 물론 웹로직 사서 웹서버로 돌리는 황당한 경우도 봤지만 대부분의 경우 서버 가격 보다는 개발자 수요에 따라 변동하는 듯 합니다.

그럼~

Suhoi의 이미지

흠냐...로그인 한다는 것을 깜박...-.-

겁쟁이란 말인가.....휴...-.-

"PHP 장점: 출력 버퍼링 어쩌구리.."제가 쓴글 임다..

php 클래스 약하다! 라는 분들은
www.phpclass.com 가보세요 !!

www.php.net PEAR 문서를 보셔도 되구요..

익명 사용자의 이미지

http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm

야후에서 ASP,coldfusion,PERL,JSP 를 지원 하지 않는 이유가 나와 있슴당..

함 보세엽...

PHP 장점: 출력 버퍼링 지원..함수 1000개 이상.. 대부분 OS 지원..
함수 찾기 열라 쉬움..메뉴얼 좋고..
알고리즘 생각하면서 함수 만들 필요가 없음...-.-

mysql 장점: 쿼리 캐시
트랜잭션 지원 됨. 이노디비로..대부분 OS지원..

스토어드 프로시져 지원 예정..(4.1)

익명 사용자의 이미지

제가 회사다닐때 UNIX기반에 웹로직,
올라클 이런걸로 개발을 했는데요.
회사를 때려치고 돈이 없어서 혼자서
apache+tomcat+mysql로 쇼핑몰을 만들
었는데요...

tomcat이나 mysql이 좋다고들
하길래 썼는데, 돌아버리는 줄
알았습니다, tomcat은 class file
compile후에 reload가 안되고,
mysql은 sql날리고 rollback이 안되더
군요. 제가 내린 결론은 공짜중에서
그런대로 쓸만하니까 쓰는 거지 mysql
이 오라클만큼 좋아서 쓰는것은 아니
더군요.
단지, 돈없이 하는 저의 경우에는
tomcat, mysql이 최선이라는 겁니다.
하고픈 이야기가 뭐나면, 사람들이
뭐가 좋다고 한다면, 그게 나에게도
항상 좋을수는 없다는 것입니다.
그러니까...
자바, MS c++/vb, php 중 어느 것이
좋다고 이야기 할 수 없는 것이겠지요.
그것은 환경에 따라 얼마든지 달라
지겠지요.
야후에서 php를 쓰기로 했다고,
아마존에서 php를 쓰면 사이트가
돌아 갈까요. 위의 두 사이트는 성격이
완전히 틀리죠.
야후는 긁어다 모은것 보여주는 사이트
이지만 아마존은 transaction이 많이
일어나지요.
그리고 야후도 모든 시스템을 php로
바꾸지는 않을 것입니다. front end
를 그렇게 하지 back end를 그렇게
바꾸지는 않을 겁니다.
저의 결론은 3가지의 우열은 없다는
것입니다. 어느 것이나 경우에 따라
서 최선이 될 수 있다는 것입니다.

익명 사용자의 이미지

이전 버전까지 웹어플리케이션의 hot deploy가 안되었던 것은 사실이지만 탐캣 자체가 full J2EE stack인 웹로직 등과 비교하면 훨씬 가볍기 때문에 개발시 문제가 된다고 생각한 적은 없습니다. 더구나 요즘에는 대다수의 IDE들이 탐캣과 연동하는 플러그인을 지원해서 디버깅과 배포가 개발툴 안에서 일어나기 때문에 별문제 안될 것 같습니다. 제가 아는 한 웹로직은 개발자에 친숙한 어플리케이션 서버는 아닙니다. 오히려 잘못된 개발환경으로 인해 일일히 클래스를 손으로 컴파일 한다던지 에러처리를 잘못해서 디버깅이 안된다던지 하는 문제는 많이 본 것 같습니다.

MySQL이 트랜잭션 지원한지도 꽤 오래된 것으로 기억합니다. 경험상 자바지원은 오라클이 앞서지만 어디까지나 오라클 제품을 썼을 때 이야기고, JDBC만 놓고 보면 MySQL이 개발하기가 훨씬 수월합니다. 오라클의 경우 OCI드라이버가 아닌 경우 특히 BLOB/CLOB등의 처리에서 표준적인 JDBC의 방식을 지원하지 않습니다. 이 때문에 어플리케이션 서버에 따라 문제가 되기도 합니다.

MySQL이외에 테스트 단계, 혹은 소규모 자바 개발에서 쓸만한 DB로는 HypersonicSQL도 있습니다. JBoss등에 번들되서 나오기 때문에 설정이 전혀 필요없고 메모리 기반이기 때문에 엄청나게 빠릅니다. 전국 우편번호 DB같은 걸 입력해도 성능 저하가 눈에 띄지 않더군요. 어쨌든 개발 단계에선 상당히 편리한 경우가 많습니다.

참고하세요...

익명 사용자의 이미지

님의 글에 2가지로 답변을 드립니다
(님이 답변하신글의 윗글을 쓴사람입니다)

1.
웹로직등 enterprise환경에서 사용되는 제품들은 tomcat등과 비교해볼때
초기접근이 그리 쉬운것은 아닙니다. 그만큼 많이 알고 있어야 제대로
쓸기 있기 때문이기도 하고, enterprise환경을 지원하려면 tomcat등과는
복잡도에서 비교가 좀 힘든것도 이유가 되겠지요.

제가 이야기하고자 하는 바는 tomcat이 나쁘다는 것이 아니라,
상황에 따라서 좋을 수도, 나쁠수도 있다는 것입니다.
소규모 웹사이트에서 비싼 웹로직을 쓰면서, 머리아파할 이유는 없겠지요.
대신 tomcat을 쓰는 것이 비용적인 측면이나 개발의 효율성측면에서는
훨씬유리하겠지요.
대신 대규모사이트에서 tomcat을 쓰기에는 tomcat의 많은 장점을 상쇄시키는
현실적인 문제점이 존재합니다. 제가 만약 PM이라면 tomcat은 사용하지 않겠
습니다. 아주 중요한 시점에 tomcat의 버그가 발견되면 누가 책임을 지죠?
바로 PM이 책임을 져야 합니다. 차라리 이때는 비용이 들더라도 상용제품을
사용하는 것이 프로젝트 관리에서는 훨씬유리할것이라고 판단이 됩니다.

2.
mysql도 꽤 쓸만한 DBMS라고 생각이 됩니다.
몇가지 기능적인 제약이 있지만서도...
님께서 말씀하신 우편번호 DB같은 경우, 저도 경험해 보았는데
DATA를 import하는데 몇초 안걸리더군요. 너무 빨라 놀랬습니다.
query도 무척 빠르구요.
저의 생각에는 소규모사이트 또는, query performence가 중요하고
transaction이 그리 중요하지 않는 사이트에는 적합하다는 생각이 듭니다.

그리고, 저같은 경우 mysql이 불편하다고 느낀 이유는 몇가지가 있는데요
크게 아래 2가지만 적습니다. 참고로 하십시오.
1)view가 안되더군요. 이전에 view를 사용한 사람들은
이부분에서 상당히 갑갑해 하더군요.
2)완벽한 outer join이 안되더군요. sql을 몇개 더 만들어야 하는
어려움이 있더군요.

이상입니다. 좋은 하루 되시길...

익명 사용자의 이미지

동감합니다. 1번의 경우 제가 말하고자 했던 뜻과 동일합니다. 단 서블릿 컨테이너 레벨에서는 그렇게 벤더에서 버그에 대한 책임을 질 수 있는 경우는 별로 없는 것 같습니다. 그렇다고 JSP 개발에 웹로직이나 웹스피어를 쓰는 건 - 물론 실제 본적도 있지만 ㅡ.ㅡ;; - 엄청난 낭비라고 생각합니다. 2번의 경우 MySQL의 트랜잭션 처리에 대한 부분은 정말 궁금합니다. 저는 단순히 얼마전 버전에서 부터 지원된다는 정도만 알고 있었는데 타 DB에 비해 문제되는 부분이 있는지 알고 싶습니다. 뷰를 사용할 수 없다는 부분은 실제 불편한 경우가 많더군요. JOIN은 개인적으로 거의 사용하지 않지만 SQL을 많이 써서 개발하시는 분들은 제약이라고 느낄 수 있을 것 같습니다.

그럼...

익명 사용자의 이미지

톰캣이 reload 가 안되요? 그것또 첨듣는 이야기군요.

mysql 이 롤백이 안되요? 최신버전에서 지원되지 않나요? 흠.. 혹자는 어플리케이션 레벨에서 해결을 한다고 하더군요...

익명 사용자의 이미지

안녕하세요.
님의 질문에 대해 아래와 같이 답변을 드립니다.
1. tomcat reload문제 :
설절화일에 reloadable = true 로 하면 된다고 하는데
실제로 해보면 안되는 경우가 많습니다. 이 문제는 java hosting을
하는 업체들의 큰 고민거리인것으로 알고 있습니다.

2. mysql rollback문제 :
이 부분은 제가 이야기를 잘못한것 같군요. 일반적으로 많이 쓰는
MyISAM type에서 안된다는 이야기 였습니다.
BDB table table type일 경우에는 되지요.

익명 사용자의 이미지

저도 resin 으로 개발을 했던 사람이라 말씀드리지만,

weblosic 이나 IBM 의 웹스피어 같은 중형 웹서버들은 CLASS RELOAD 가

완벽히 지원 하나요?

참고로 RESIN 은 저희가 개발할당시 2.1 대 버전에서 실시간으로 class reload 가 안됩니다.

resin 을 restart 해야 변경된 class file 들이 적용되죠.

이럴경우 문제는 java 계열로 웹호스팅을 할때 문제가 생깁니다.

톰캣도 마찬가지 인가요?

익명 사용자의 이미지

Weblogic 안됩니다.

Weblogic vendor 하는 회사에서 컨설턴트 팀이랑 같이 플젝 했는데

EJB는 물론, BEAN 컴파일할때마다 리스타트 하시더군요.

되야 되는데 안되는것(?) 중 하나라고 합니다.

Weblogic 한글처리도 약간 좀 골치인거 같더군요

bookworm_의 이미지

InnoDB 에서도 됩니다. InnoDB 에서는 row-level locking도 된다는 소식입니다. BDB에서는 page-level locking까지 가능하죠.
--
Bookworm

Bookworm

익명 사용자의 이미지

php 에서도 오라클 사용가능합니다.
좀 비교가 잘못 된 거 같네요

익명 사용자의 이미지

주제와 좀 벗어난 이야기지만 확실히 확장성(scalability)과 성능은 전혀 다른 문제 같습니다. 전자는 분산처리가 전제되야겠지만 후자의 경우 가장 크게 좌우되는 건 병목점이 있는지 여부, 캐쉬의 적절한 활용, 그리고 쓰레드 타입의 선택 등인 것 같습니다.

병목점은, 자바의 경우 JProbe 등으로 분석해 보면 어느 정도 잡아낼 수 있더군요. 캐쉬는 최근에 oscache를 몇 번 적용해봤는데 태그 하나 추가해서 거의 수십배의 성능향상을 얻을 수 있다는게 매력적이더군요. 데이터 캐쉬의 경우는 아래 PetStore의 경우에서도 논란이 됐지만 CMP2의 경우 오히려 순수하게 JDBC만을 쓰는 것보다 성능을 향상시킬 수 있습니다.

마지막으로 쓰레드 타입이나 JVM 옵션 설정 등인데, 글쎄요... 솔직히 인터넷 등에서 읽은대로 적용은 하지만 아직 결과를 눈으로 확인한 적이 없어서 모르겠군요. 어쨌든 가비지 컬렉터를 병렬로 돌려주고 OS의 프로세스 대신 thin-thread를 쓴다던지 하는 방식으로 성능향상을 얻을 수 있다고 합니다.

어쨌든 중요한 건 웹어플리케이션에서 성능은 단순히 어떤 언어를 선택하는지 보다는 어떻게 구현하는지에 훨씬 크게 영향을 받는 것 같습니다.

아쉬운 건 주위에서 제대로된 로드테스트도 없이 브라우저로 몇번 리프레쉬 해보고 성능이 좋다던지 나쁘다던지 하는 사람들이 꽤 된다는 사실이더군요 ㅡ.ㅡ;; 지금 고객의 경우도 jsp 컴파일 시간을 가지고 성능에 문제가 있다느니 딴지를 걸어 머리가 아프네요 :)

그럼~

익명 사용자의 이미지

저는 초대규모 웹서버 부하를 해소하기 위해서 아파치 모듈 프로그램을 좀 한적이 있습니다.

자주 불리는 로직들은 아파치 모듈 프로그래밍을 하셔서 해당 로직을 아파치 프로세스 자체게 내장시키면 속도 문제를 엄청나게 해결할수 있습니다.

cgi 처리들은 프로세스 포킹후 처리 결과를 아파치 프로세스에게 파이프등으로 돌려주는데
아파치 모듈로 같은 역활을 하는 프로그램을 짜게 되면 이러한 과정이 없죠... 아파치 프로세스 자체가 로직을 물고 뜨기 때문에...

단점은 프로그래밍 하기 까다롭고 (c 기반과 아파치 api를 잘알아야 됩니다.) 재 사용성이 떨어지고 소스 수정후 모듈을 재 컴파일 해야 되는 단점이 있습니다.

그렇지만 속도 문제는 지구상에 나온 어떤 cgi 언어보다 더 빠르게 해결할수 있을 것입니다.

시간이 되면 아파치 모듈로 된 웹 게시판을 만들고 싶습니다.

익명 사용자의 이미지

음.. 절대적인 수치는 아니지만... mod_perl,Apache::Registry,perl 로 cgi 형태로 hello world 프로그램을 만들어서 테스트 해보니... php 보다 2배정도 빠릅니다...

따로 프로세서가 생성되지도 않구요...

요즘 펄로 멀 만들어야 하는 운명이라 어쩔수 없이 쓰고 있긴합니다만, 나름대로 상당히 재미도 있고.. 놀랍게도 성능을 향상시키는 방법또한 있네요...

디비 커넥트 하는 문제도 Apache::DBI 를 쓰면 영속적인 커넥트도 가능합니다.. mysql 을 기본형식으로 깔고 테스트 해보니.. 3초내에 다시 커넥트를 하게되면 기존 디비풀에서 커넥션을 넘겨줍니다..

음.. 사실 FastTemplate 류의 템플릿보다, HTML::Template 모듈이 훨씬 직관적이고, 유용하기도 하구요...

펄이 우리나라에서 거의 안쓰는건 사실이지만(특히 웹프로그래밍 분야에서..), 성능이 떨어져서 그런건 아니라는걸 새삼 깨달았습니다..

조아요 펄~~~

임택균의 이미지

Apache의 경우 Proxy기능을 사용하면, 스크립트와 CGI에서
발생하는 속도 문제는 어느정도 해결할 수 있을 것 같은데요
--
임택균.

임택균.

익명 사용자의 이미지

현재 참여하시는 개발자분들이 모두 올바르게 객체지향을 이해하였는가를 일단 체크해보는 것이 선행되어야 하지 않을까 생각합니다.

제 알기로 아직까지 우리 나라 많은 업체들에서 일하는 개발자분들이 객체지향 마인드가 부족한 것으로 알고 있습니다.

어쨌거나...
객체지향 언어로의 전향은 언어의 장점을 논하는 것 이전에 개발자들의 이해도가 더 중요하리라고 봅니다.

익명 사용자의 이미지

음.. 웹 프로래밍을 위한 language 라는 점을 봤을때, 정말 궁극적으로는 확장성과 process forking 을 최소화 하는것이 좋다고 봅니다.

아무리 c 라 하더라고 컴파일된 바이너리라고 해도 process forking 을 하기 때문에 php 보다 성능이 더 떨어질수도 있는것입니다.

고로 나온것이 fastcgi 라는것도 있으며, 여러가지 방법으로 forking 을 안하고 daemonlize 시키고 있는데, 이러한 방법으로 c fastcgi 를 구현했을시 성능은 정말 극대화 됩니다. ( db 연결도 한번으로 끝납니다 )

그러나, 개발 기간이나 디버깅 기간이 너무 오래 걸리는 단점이 있습니다.

php 나 asp 처럼 아파치 혹은 iis 에서 바로 이용 가능한 프로그램이 그리 크지 않은 규모에서는 훨씬 좋을수가 있다는 생각입니다. 그러나, db 에 connect 하는 부하도 만만치 않을것이며, 이에 대한 튜닝도 필요할것입니다.

perl , python , jsp 등도 쓰는 사람의 역량에 따라서, 정말 틀려질수 있을거 같습니다. 그냥 단순 무식한 process forking 방식의 스크립트 랭귀지 .cgi 는.. 정말 개인용으로만 쓸수 있는것이라 생각합니다. -.-;

위즐의 이미지

> 그러나, 개발 기간이나 디버깅 기간이 너무 오래 걸리는 단점이 있습니다.

어떤 언어를 사용해서 개발하든 말씀하신 문제는 다 가지고 있다고 봅니다.
오히려 C 언어나 Perl을 사용해서 개발했기 때문에 전체적인 일정이 예상보다
줄어드는 경우도 있고 비용절감으로까지 이어지는 경우가 있다고 봅니다.
예를들어 지금 제가 하고 있는 프로젝트의 경우 JAVA로 제대로 구현하려면
애플리케이션 서버따위가 있어야 되고 설계도 엄청 복잡해집니다.(객체지향적으로
설계가 되었는지 안되었는지를 검증하기 위해 문서화를 거쳐야 되고 또 그래야만
되는줄 아니까) 또한 이놈은 오라클이랑 가까워서 거의 대부분 DB를 오라클을
사용합니다. 그리고 말이 run 작업인원은 늘어나고 파트별로 세분화되어 전체일정을 잡는데도, 회의를
한번 진행하는데도 하루가 지나갑니다. 돈 따위가 중요치 않은 기업이고 시간이
남아도는 기업이라면 상관없겠지만 제 경험으론 대기업에서도 돈 따지고 시간
다 따지더군요. 현재 프로젝트에서 사용되는 OS는 리눅스이고 DB는 PostgreSQL
개발언어는 C(서버측, 라이브러리에 사용)이고 일부 MFC로 구현해야 될 부분때문에
C++을 사용합니다. 당근 CGI방식으로 개발하지요. 개발비용에 대해서는 자세히는
모르겠지만 예전에 자바 프로젝트의 경우보다 훨씬 적은 줄 압니다. 인원도 많지도
않고 자바프로젝트의 경우보다 개발일정도 길지 않습니다.

CGI가 구시대적인 웹 개발방식으로
한때는 저도 사람들이 말하는 자바 프로그래머였습니다. (자바만 할 줄아는)
고수는 아니지만 설계자가 작성한 문서를 보고 구현 할 정도의 수준은 되고
이쪽에선 경력 3년차입니다. 제 경험상 개발기간과 디버깅의 문제는 CGI방식을
채택했기 때문이 아니라 다른 요건에 의해 결정되어진다고 봅니다.

익명 사용자의 이미지

개발 기간이나 디버깅 기간이 오래 걸린다는것은 php , asp , python 등과 비교했을때 입니다.

우선 cgi 만을 짜더라도 qdecoder 가 나오기 이전에는 cgi library (get , post) 등을 만들어 썼었죠.. 기타 urlencode 같은거 하나하나 포인터로 지정해서 만들어 쓰고.. -.-; 뿐 아니라 memory leak 발생하면 이거 디버깅 하는것 역시 장난이 아니지요.

그리고 아주 예외적인 상태에서의 segementaion fault 에러. 그리고 같은 코딩이라도 라인수가 틀리고.. 컴파일 일일히 해줘야 하고. -.-;

이런점들을 말한것입니다.

익명 사용자의 이미지

어.. 전 perl 로 사이트를 만들고 있는데요.. 머 별로 걱정은 하지 않습니다.. 프로세서를 양산하기는 해도.. 속도도 빠르고.. (mod_perl 의 Apache::Registry 를 씁니다) .. 기존 모듈들도 엄청나구... 먼가 시스템적인 냄새도 나구요..

외국에서는 아직도 perl 로 사이트를 많이 만들지 않나요?

그리고 우리나라도 큰 포털사이트도 .cgi 방식으로 커뮤니티부분을 구축해놓은것을 많이 봤습니다..

머.. 전 만족하면서 쓰고 있습니다.

지금은 바꼈는지 모르겠습니다만 amazon 도 mod_perl , perl 로 되어있었습니다..흠..

익명 사용자의 이미지

네 개인적으로 쓰기에는 그만인 language 라고 역시 말씀 드렸었습니다. mod_perl 까지 쓴다면 더 좋지요. :)

그리고 우리나라 큰 포털사이트도 .cgi 방식으로 커뮤니티 부분을 구축해놓은 것을 많이 보셨다고 했는데 외형적으로 보이는 .cgi 만으로 내부적인 동작 원리를 알수는 없습니다. .cgi 확장자로 fastcgi 를 쓰는 경우도 많고, yahoo! korea 의 경우는 아이에 apache 에 module 형식으로 프로그램을 httpd 에 내장시켜서 써버리는 경우도 있으니요.

익명 사용자의 이미지

흐흐흐....펄은 어디로 갔느뇨.....펄은 이제 죽었는가? 흑흑

익명 사용자의 이미지

그래도.. 역시나 어디가서 폼(?)나게 이야기 하려면.. J2EE나 .NET이 아닐까 생각을 해봅니다. 제가 엔터프라이즈 쪽에서 일하다 보니 좀 편협한 시각 일 수도 있겠지만.. 솔직히 대형 프로젝트 제안서 쓸때 개발 언어로 Perl, Python, PHP를 쓰는 경우를 잘 보기 힘들더라구요.(제가 잘 모르는 것일 수도 있구요. 지적 바랍니다.) 이건.. 특정 언어가 뛰어나다기 보다는... 그냥.. 암것도 모르는 윗대가리들이 그저 혹해서.. J2EE나 .NET아니면 쳐다 보지도 않기 때문인 경우가 대부분인거 같구요... 덤으로... 전 지금 J2EE에서 개발을 합니다. 그리고 그들이 내놓은 청사진들과 Best Pratice들을 따르려고 하고는 있는데.. 에휴.. 정말 재미 없답니다.. 개인적으로 J2EE는 너무 재미가 없더라구요. PetStore와 Struts를 흉내낸 프레임워크를 하나 만들어서 개발을 하는데... 에휴.. 그 많은 설정 파일들과. 그 많은 스펙들.. 그 많은 테그들하며..... --; 그렇다고 M$가 만든 .NET은 단지 M$가 만들었다는 이유로 왠지 싫고.. (에휴 빨리 편견을 버려야 하는데..--;)
며칠전 J2EE vs .NET 성능 측정이라고 해서 자바 전문가들이 기존의 성능 비교 결과를 인정할 수 없다고 해서 다시 한번 맞 붙었더군요..
결과는 처참하더군요... 에휴.. 그리고선 하는 변명이 더더욱 가관 입니다.. 지네들이 이렇게 이렇게 개발하는 것이 Best~야~ 라고 주장해온던 때는 언제고... 암튼 전 J2EE가 너무 맘에 안듬.. ㅠ.ㅜ 그래두 먹구 살려면..

익명 사용자의 이미지

(1) 혹시 Struts나 EJB를 쓰신다면 xdoclet을 적극 추천합니다.
재미있고 없는 문제야 개인 취향이지만 최소한 설정파일 삽질은
획기적으로 줄일 수 있습니다.

(2) PetStore 성능 테스트에 대한 논란은 '변명'이 아닙니다.
MS의 마케팅 전략이 뛰어났을 뿐이지요... PetStore 소스나 소개
글을 보시면 아시겠지만 이는 J2EE로 할 수 있는 모든 것을 한
프로그램에 뭉쳐서 만든 샘플입니다. 이벤트 기반의 MVC 프레임
워크까지 직접 만들어쓸 뿐만아니라 가능한 모든 부분에 추상화
계층이 포함되어 있습니다. 즉, PetStore의 Best Practice란 J2EE
레벨의 패턴의 사용법을 보여주는 예제일뿐 실무에 사용될 수 있
는 프로그램이 아니라는 뜻입니다.

실제로 국내든 외국이든 PetStore 처럼 실무에서 개발하는 경우는
전혀 없습니다.

그런 샘플을 2-tier로 저장 프로시저까지 써서 재구성해 놓고 28
배가 빠르다고 선전하는 건 좋은 마케팅전략인지는 몰라도 올바른
비교는 아닙니다.

익명 사용자의 이미지

언제적 이야기를 하시는 건지요? TheServerSide dot Com에서 다시 한번 보시기 바랍니다. 이번에 새로 다시 한 결과를 말하는 겁니다. xDoclet는 쓰고 있습니다.. ㅠ.ㅜ 아직 잘 못써서 그런지.. ㅠ.ㅜ 아웅... ㅠ.ㅜ

익명 사용자의 이미지

그렇군요. 28일에 새로운 리포트가 올라와있는 것은
몰랐습니다. 일단 MS 쪽이 아니라 오히려 자바 쪽에 가까운
진영에서 작성된 리포트라면 최소한 공정성에서는 믿을만한
것 같습니다.

하지만 쓰레드를 보니 '변명' 비슷한 건 안보이는 군요.
어쨌든 저로서도 흥미로운 주제이고, 조만간 다른 쪽에서도
반응이 나올 것 같으니 주시해봐야 겠습니다.

관련링크입니다 :
http://www2.theserverside.com/home/thread.jsp?thread_id=16149&article_count=386

익명 사용자의 이미지

flutia_의 이미지

기본적으로 웹이란 환경은 로컬 컴퓨터와는 많이 다릅니다. 데스크탑, 서버 환경이 발전하면서 로컬 애플리케이션을 구현하는 방법도 많이 발전해왔지만, 아직 웹이란 환경은 많은 제약 사항이 있습니다. 로컬 애플리케이션을 구현하는 방법들이 웹에 일부 적용된 것들이 현재의 ASP,Java,PHP 등이겠죠.

단순히 이들 세 언어만 놓고 비교를 했을 때, 현대적인 프로그래밍에 가장 근접한 건 Java이고 그 다음으로 ASP, PHP의 순이 될 겁니다.

지금은 ASP, Java, PHP... 모두 웹에 대한 일반적인 요구 사항을 거의 만족시켜 주고 있는 것 같습니다. 사이트를 만들 때 ASP로 만들든 PHP로 만들든 그렇게 차이는 없다는 거죠.

그러나 앞으로 웹환경은 어떻게 바뀔지 모릅니다. 단순하게, 시스템이 발달하고 회선의 대역폭이 넓어지고 안정적이 되면 분명히 On-Connection 모드의 웹환경도 마련이 될거라고 생각해볼 수 있습니다.

분명히 현재 Java는 앞으로 다가올 발전된 웹환경에 무리가 없는 언어라고 생각합니다. 거대한 웹프로젝트에 있어서 이미 자바는 최선의 선택이라고 거의 단정지을 수 있습니다.

하지만 다른 언어도 언제까지나 현재의 모습에 머물러 있진 않을 겁니다. ASP는 ASP.NET이라는 모습으로 탈바꿈하는데 어느 정도 성공한 것 같고, PHP도 4.x대에만 머물러 있진 않겠죠.
각 언어들은 변화하는 환경에 맞춰 성장해 나갈 겁니다. (개인적으로는 PHP가 그 변화를 맞춰나가기에 가장 진통을 겪을 거라고 생각합니다만... PHP가 Java의 복사모델이 되지 않고 빠른 속도, 간결함, 생산성 등의 장점을 그대로 살려 나간다면 앞날에도 자기의 영역을 확실히 차지할 겁니다.)

그때가 되면 각 언어의 개성과 장단점은 더욱 부각될 거라고 봅니다. 특히 ASP/PHP쪽은 웹의 요구가 많이 반영되며 발전하고 있는 언어라 어떤 특징을 가질지는 딱히 짐작이 가질 않는군요.
자기가 필요한 용도에 맞춰 언어와 플랫폼을 선택할 겁니다.이미 지금도 그러고 있구요.

익명 사용자의 이미지

답글을 보며,역시 뜨거운 화두임에 틀림없음을 실감하겠습니다.
저의 주관적인 의견과 경험임을 미리 밝히면서 몇자 적고 싶은데요.
pc라고 이름붙여진 컴에서의 모든 언어는 한번쯔음 경험은 해 봤는데요,
web 이라는 문화와 접목되며 관련언어구조는 크게 한걸음 뒤로 밀려 갔음을
저는 피부 깊숙이 느끼고 있는건 왜 인지 모르겠습니다.
그 이유를 들자면, 개발환경의 직관성의 결여 때문이 아닌가 싶습니다.
그리고 그 책임은 전적으로 덜성숙된 인터넷의 한계 때문이지요.
적어도 5년전쯔음 IDE 자체는 백지위에 콤포넌트를 떨어뜨리는 기분으로
Enduser의 시각과 작업흐름을 받쳐주도록 되었지만,그런 직관성이 현재 개발툴은
해당되지 않지요.원격의 불특정다수와의 컨넥션이 항상 전제 되어야만 하기때문이지요.
perl ,php,java 등을 처음 접하며 웹을 다루다가 저는 금방 질리고 말았습니다.
어쩌면 이렇게까지 계층이 분리되어 있지 않을까 하는 당혹감에.. 그만 뚜껑을 닫고
싶은 생각뿐이었습니다. 웹개발을 하며 html 을 꼭 알아야만 한다는 사실만으로
저는 충분히 좌절하지 않을수 없었습니다.이게 도대체 무슨 노가다냐하는 느낌...
예를들어,10년전에 터보씨로 popup 윈도우를 만들거나 램상주 프로그램으로
rs232c 통신을 하다가 window가 나오니까 그동안 했던 작업들은 한낱 개폼잡던것밖에
안되더라구요.마찬가지로 어느 훌륭한 제2의 빌게이츠 같은 인물이 internet window
를 만들면 그때는 현재 코드는 아마도 전부 개업휴점 상태로 들어 가겠죠.
그래서 한가지 제안을 하고 싶습니다.
지금 현재 꼭 돈 벌어도 되지 않는 분이라면,그리고 한번쯔음 이세상을 엎어버리겠다고
생각하시는 분이 있다면 지금 현재 인터넷 환경과 개발 툴은 무시하시구요,
aaaa.bbbb.cccc.dddd.eeee 가 가능한 ip 와 100giga 의 bandwidth를 가정하고서
온세상이 localResource 인 상태인것처럼 툴을 하나 만드십시오.
그런다음, 더이상 웹브라우져가 필요없고 pull/push 가 필요 없고 RMI 가 필요 없는
쾌적한 사용환경이 올때 남들은 컨버젼 하고 있을때,그때 뒤집으시기 바랍니다.
이글을 쓴뒤, 저는 현재 돈을 벌어야 하니까 드림위버 공부하고 있을께요.
그럼 이만.

익명 사용자의 이미지

글쓴이 : Lamp

예전에 차라리 C@을 만들자고 주장했다가 자바진영에서 말도 못할 비난을 듣고 있습니다.

익명 사용자의 이미지

반걸음 앞서가면 떼돈을 벌지만 한걸음 앞서가면 남좋은일만 시키는거고, 두걸음 앞서가면 베비지처럼 비운의 천재 소리나 듣는거고 세걸음 앞서나가면 삽질밖에 안됩니다.

Paladin의 이미지

이 말씀 들으니 생각나는게 하나 있는데,
찰스 배비지보다 한 200년 먼저 태어나서 수학사의 길이 남을 여러 업적을 남긴 수학 천재 가우스가 어릴적에 아버지를 위해 계산기를 만들었다는데, 대체 그 계산기를 어떻게 만들었을까요?

물론 이것도 톱니바퀴를 이용한건 분명할텐데, 제 머리로는 구현을 못하겠더군요. 기계공학 전공자는 톱니 바퀴를 아무래도 많이 다뤄 봤을테니 왠지 잘 알 것 같습니다. 혹시 누구중에서 알면 좀 알려주세요.

그리고 베비지가 만든건 일종의 저장 개념(아마 Stack일 것임)이 있는 계산기인데, 과연 그 저장하는 부분은 톱니로 뭘 어떻게 했길래 그것이 가능한 것일까요? 좀체 감이 안잡힘.

9th Paladin

익명 사용자의 이미지

옳소

익명 사용자의 이미지

웹 구현 관련 언어는 웹의 특징을 반영해야 하는 것이 좋다고 생각합니다.

웹은 다른 c/s 와는 달리 커낵션리스라는 방식의 연결을 사용합니다.
즉 request에 대해서 response를 주고 연결을 끊기 때문에
어떻게 보면 하나의 리퀘스트(한 화면)에 대해서 하나의 페이지가 있는 것이
이상적이라고 생각됩니다.

유지보수의 측면에서 이 하나의 페이지들이 수백개로 이뤄질 때 많은 경우
일일이 기억할 수 없을 정도의 페이지들이 존재해서 개발자들이 어려움이 있을 거 같네요.
특히나 asp, php, java 등 거의 모든 언어들에서 비즈니스 로직과 화면을 구성하는 코드가
혼재되어서 스파게티 코드가 나오는 것이 유지 보수의 어려움이지,
특히 어떤 언어이기 때문에 유지보수가 어렵다는 것은 정확한 표현은 아닌 거 같네요.

그리고 또 하나의 유지보수 측면은 바로 db와의 커넥션을 어떻게 커넥션 풀이나 미들웨어로
관리할 수 있는냐는 거죠.
asp는 MTS를 이용할 수 있고, java는 어플리케이션 서버라는 개념을 통해서
WAS가 시동하면서 가볍게 db 커낵션 풀을 올릴 수 있지만,
php 같은 경우는 apache의 모듈로는 올라가지만 정확히 커낵션 풀을 이용하지 못하는 단점이 있죠.
아마도 가볍고 유연한 구조로 가기 위해서는 계속적으로
이런 구조를 유지하지 않겠냐는 추측을 해봅니다.

여기서 한가지 다른 관점으로는 컴포넌트를 개발해서 적용할 수 있는 기준입니다.
asp, java는 이런 컴포넌트를 개발해서 적용할 수 있지만,
php는 그런 방법론이 존재하지 않습니다. 물론 class 를 언어적으로 지원하지만요.
보통 웹 사이트 개발을 할 때 8282 하자고 하는데,
컴포넌트 설계부터 개발까지 할 시간적인 여유가 있을런지 궁금하군요.
컴포넌트 자체의 설계뿐 아니라 사이트의 전체적인 설계까지 잘 되어 있지 않으면
다시 처음부터 개발을 해야 한느데 컴포넌트 기반의 웹 개발이 그렇게 가치 있다고
생각되지 않는군요.

그리고 웹 언어적인 측면은 에러 핸들링이 매우 힘든게 사실이죠.
그런 측면에서 php 에러 핸들링이 우수하지 않나 싶네요.
물론 다른 언어들도 에러가 났을 때 막는 수준은 다들 가능하지만,
예상할 수 없는 에러가 났을 때 핸들링 할 수 있는 구조에서는 php가 우수하다고 생각합니다.

두서없이 이야기를 한거 같은데요 8282 개발해서 8282 결과를 보고 싶으면 asp, jsp, php 등을
그냥 이용하는 겁니다. 그리고 유지보수나 확장성등을 고려해서 개발을 한다면 컴포넌트를
먼저 개발하고 이를 이용하는 개발을 해야겠지요.

* 추신 : 컴포넌트를 이용한 개발을 해본적 없는 사람이기 때문에, 그게 뭐냐고 물어보지 마시길.
끝으로 가장 좋은 웹 개발 언어는 델파이 처럼 화면(디자인)과 비즈니스로직을 분리시킬 수 있는
언어가 아닐런지요. 아직까지 보지 못해지만..

익명 사용자의 이미지

^^; php도 컴포넌트 제작을 할수 있습니다.
class가 아닌 dll 형태로 제작이 가능합니다.
단지 C로 만들어야 하고 PHP에 addon할수 있게 만들어야 한다는 단점과
아직 메뉴얼이 적다는 단점이 있죠
그리고 OS마다 다시 컴파일 해줘야 하는 문제점도 있겠지만요 ^^;
생각보다 만들어 쓰면 재미가 솔솔 합니다 ^^;

그럼

익명 사용자의 이미지

또 한가지, DB 핸들링에 대한 부분은 CMP나 JDO 같은
추상화 계층을 사용할 경우 직접 쿼리를 수행하거나 테이블
단위로 생각하지 않고 순수하게 OOP적 관점에서 접근 가능
합니다. (물론 엔티티빈의 활용과 성능에 대한 부분은 설계
하는 사람에 따라 상당한 이견이 있을 수 있습니다) 단점은
역시 익숙하지 않을 경우 오히려 생산성이 떨어지거나 버그
나 성능등의 문제가 발생할 수 있다는 점입니다.

직접 JDBC를 사용하는 경우 DataSource를 사용해 커넥션을
얻고 풀링은 어플리케이션 서버에서 처리해주는 경우가 일
반적입니다만 이상하게 허접하게 만들어 쓰는 분들이 많더
군요 :)
~

익명 사용자의 이미지

자바에서 MVC 패턴의 적용은 매우 일반화되어 있고 지원하는 프레임워크도 다양합니다
. 특히 Struts에 대해 알아보시면 도움이 될 것 같습니다. MVC 자체도 '스파게티 코드
'를 방지하지만 Struts의 경우 커스텀 태그를 지원해서 아예 JSP 안에 단 한줄의 스크
립팅도 필요 없을 정도로 완벽한 계층 분리를 구현합니다.

이제까지 Struts를 적용한 프로젝트들에서 JSP에 직접 코딩을 할필요가 있었던 경우는
거의 없었습니다.

컴포넌트 설계의 경우, 기본적으로 MVC 기반 프레임워크를 채택하면 대부분의 로직이 서버측에서 커맨드 패턴의 형태로 돌기 때문에 다양한 클래스를 만들어 작업할 수밖에
없습니다. 최소한 jsp 하나가 프로그램 하나라는 식의 사고 방식 자체가 불가능해 집
니다.

참고하세요...

익명 사용자의 이미지

.NET vs Java 2 Enterprise Edition (J2EE) 비교
eBusiness를 향한 두 개의 비전

Roger Sessions
ObjectWatch, Inc.

소개
수익 계획이 없는 전자상거래 사이트는 기름없는 차와 값다. 전자상거래는 멋있게 보이며, 사람들의 많은 관심을 끌고 있지만, 여러분의 모든 것을 빼앗아 갈 수도 있다. 결국에는 원점으로 돌아올 수도 있다.
우리는 2000년에 이 교훈을 배웠다. eBusiness 기업들은 하나씩 차례로 도산했는데, 이것은 고객이 없어서가 아니라, 그 고객들에게서 수익을 창출한 모델이 없었기 때문이다.
2001년에는, 수익의 중요성이 어느 때보다도 커질 것이다. 그러나 수익 모델은 경쟁에 의한 모델에서 협력에 의한 모델로 진화하게 된다. 역설적으로, 경쟁력 높은 기업들은 경쟁에 대하여 전혀 걱정할 필요가 없으며, 협력을 어떻게 잘 할 것인지에 대해서만 집중하게 될 것이다.
“경쟁자를 부숴버려라!”라는 미식축구의 구호는 21세기 기업에 적합한 말이 아니다. 미래기업의 구호는 심포니 오케스트라다. 전반적인 협력이 가능해야 각 기업의 성공도 가능해진다.
전자상거래에서, 협력은 협력업체와의 파트너관계를 통해 판매하는 것을 의미한다. 이것은 수익을 공유하는 것을 의미한다. 수익를 공유하려면, 각 협력단계에서 수익모델을 정밀하게 조사해야 한다. 우리는 가능한한 최저의 비용으로 협력하는 모델로 전자상거래를 구현할 수 있어야 한다.
현재, eBusiness와 eCollaboration을 위한 두 개의 기술적 비전이 존재한다. 한 가지는 .NET이라는 Microsoft의 비전이며, 다른 하나는 Java 2 Enterprise Edition (J2EE)이라는 Sun의 비전이다.
이 기술백서에서, .NET과 J2EE를 비교하게 될 것이다. 여기에서는 향후 5년 동안 eBusiness의 원동력이 될 주요 이슈에 대하여 초점을 맞출 것이다. 또한 두 개의 플랫폼에 대하여 기술적인 설명도 하겠지만, 그 설명은 협력 또는 수익성에 영향을 미치는 부분에 한정할 것이다.
J2EE는 기술명세(specification)이며 제품이 아니라는 것을 지적해야 한다. 많은 벤더들은 자신의 제품 안에 이 명세를 구현하고 있다. 가장 중요한 J2EE 벤더/제품은 IBM의 WebSphere와 BEA의 WebLogic이다. Cutter Consulting 의 최근 조사에 따르면, 이 두 벤더들은 J2EE 시장의 59%를 점유하고 있다. Sun은 비교적 미약한 위치이지만 J2EE 명세를 통제한다는 면에서 중요한 벤더다.
J2EE와 Microsoft의 .NET의 모든 요소를 비교하는 것은 이 기술백서의 범위를 벗어나는 것이다. 그러므로, 여기에서는 Microsoft가 정의한 전반적인 .NET 비전과 Sun이 정의한 전반적인 J2EE 비전을 비교한다. 좀더 가시적인 비교를 하기 위하여, 가상의 비즈니스인 MoneyBroker를 예로 들겠지만, 실제로는 다른 모든 eBusiness에 확대 적용되어야 하는 내용이다.
MoneyBroker에 대하여
MoneyBroker는 두 비전을 비교분석하기 위하여 가상으로 구성한 비즈니스다. MoneyBroker의 목적은 청구서에 온라인으로 지불하는 것이다. 고객들은 MoneyBroker 계정에 돈을 입금하고, 필요한 경우에 온라인 청구서에 지불할 수 있다. 더 많은 고객을 유도하기 위하여, MoneyBroker는 잔액에 대하여 이자를 지불한다.
고객은 청구서에 대하여 직간접적으로 지불할 수 있다. 고객은 MoneyBroker 웹 사이트에 로그온한 후에 청구서 지불을 결정하면 직불을 하게 된다. 간접지불은 MoneyBroker의 협력업체를 통해 일어난다. MoneyBroker 협력업체들은 주문하는 고객에게서 MoneyBroker 돈을 받을 수 있는 소매업자들이다. 한 고객이 AustinKayaks.com을 방문하여 500달러상당의 장난감을 주문하면, AustinKayaks.com이 제시할 수 있는 옵션 중 하나인 MoneyBroker 계정을 통해 지불하게 된다.
MoneyBroker는 고객의 계정에 있는 잔액을 다른 곳에 투자하여 수익을 창출한다. 이 사이트의 수익은 고객에게 지불하는 이자율과 투자수익률의 차이가 되는 것이다.
eBusiness의 필요조건
MoneyBroker가 eCollaboration 또는 전자협력을 지원하려면, MoneyBroker을 가동시키는 컴퓨터 시스템은 특정 필요조건을 충족시켜야 한다. 필자의 경험에 따르면, 가장 중요한 필요조건은 다음과 같다:
• 연동성(Interoperability) – 시스템은 협력업체의 시스템과 정보를 공유할 수 있어야 한다.
• 가용성(Availability) – 시스템은 높은 가용성을 가져야 한다. MoneyBroker의 시스템이 다운되면, AustinKayaks는 영업기회를 잃게되며, 협력관계는 위협을 받게 된다. 다운이 또 다시 발생한다면, 더 이상의 협력관계는 없을 것이다.
• 성능(Throughput) – 시스템은 높은 트랜잭션 성능을 제공할 수 있어야 한다. 지불요청은 MoneyBroker의 자체 웹 사이트에서 뿐만 아니라 협력업체의 웹 사이트에서도 간접적으로 발생하기 때문이다.
수익을 발생시키기 위하여, 전반적인 시스템 비용은 가능한한 낮게 유지해야 한다. 필자의 경험으로는, 시스템 비용 중 가장 중요한 결정요인은 다음과 같다:
• 개발비용(Development Cost) - MoneyBroker 시스템의 아키텍처를 결정하고 구현하는 비용.
• 시스템 관리비용(System Management Cost) - MoneyBroker 시스템을 관리하는 비용.
• 작업단위별 비용(Unit of Work Cost) - MoneyBroker 지불을 처리하는 비용.
• 확장성 비용(Scalability Cost) – 고객층이 확대되는 경우에, 전반적인 MoneyBroker 시스템의 성능을 확장시키는 비용.
이제, 3개의 협력 필요조건(연동성, 가용성과 성능)과 4개의 주요 시스템 (개발비용, 시스템관리 비용, 작업단위별 비용과 확장비용)요소들이 이 기술백서에서 비교분석할 주요 요소들이 될 것이다.
전형적인 전자상거래의 아키텍처
현재의 전자상거래 아키텍처는 그림 1에서와 같이, 일반적으로 3개 계층과 2개의 방화벽으로 구성되어 있다. 이 아키텍처는 eCollaboration을 지원하지 않는다. 우리는 뒷부분에서 이 아키텍처가 전자협력을 지원할 수 있도록 변경을 시킬 것이다..
그림 1. 3계층의 전자상거래 아키텍처

그림 1의 각 계층들은 나름대로의 목적, 아키텍처, API를 가지고 있다. 여기에서는, 일반적인 아키텍처부터 설명한다. 뒷 부분에서는, .NET과 J2EE 간의 차이를 살펴볼 것이다.
프리젠테이션 계층은 클라이언트와 동작하기 위한 것이다. MoneyBroker 애플리케이션에서, 이 계층은 씬 브라우저를 사용하는 청구서 지불 클라이언트와 동작하게 된다.
프리젠테이션 계층은 웹 브라우저에서 HTTP 요청을 받고, 브라우저가 디스플레이할 수 있는 HTML 페이지를 반환한다. 다양한 브라우저가 다양한 디스플레이 능력을 가지고 있기 때문에, 프리젠테이션 계층은 특정 브라우저(또는 다른 씬 클라이언트 장비) 능력에 따라 HTML을 조정해야 한다.
비즈니스 계층은 비즈니스 로직 중 상당부분이 구현되는 곳이다. MoneyBroker의 경우, 여기에는 고객계정을 유지하는 로직과 청구서가 지불될 때 돈을 전송하는 로직이 포함되어 있다. 비즈니스 계층은 프리젠테이션 계층과 데이터베이스 계층 사이에 존재하기 때문에, 중간계층(middle tier)이라고 불리는 경우가 많다.
프리젠테이션 계층은 메서드 전송 프로토콜을 통해 비즈니스 계층과 통신한다. .NET에서, 이 프로토콜은 일반적으로 DCOM 또는 SOAP이며, J2EE에서는 RMI/IIOP가 된다.
.NET과 J2EE 모두에서, 비즈니스 로직은 일반적으로 컴포넌트로 포장된다. 컴포넌트는 잘 정의된 인터페이스를 통해 상호작용하는 비즈니스 로직이다.
컴포넌트는 계층구조식 관계를 가지는 기술인 객체와 종종 혼동되지만, 비슷한 점은 거의 없다. 특히, 객체지향 프로그래밍 법칙과 컴포넌트 패키징 법칙은 크게 다르다. 필자는 최근에 두 기술의 차이를 설명했었기 때문에 , 여기에서는 설명하지 않겠다.
비즈니스 로직은 데이터베이스 연결, 쓰레드, TCP/IP 연결과 메시지 큐 연결과 같은 값비싼 자원들을 요구하는 경우가 많다. 이처럼 과도한 자원을 요구하기 때문에, 한 번에 대규모의 클라이언트를 지원하기 곤란하다. 문제는 전자상거래 애플리케이션은 대규모 클라이언트를 지원해야 한다는 것이다.
이 문제를 해결하기 위하여, J2EE와 .NET의 비즈니스 계층에는 클라이언트 간의 자원공유를 지원하는 정교한 중간계층 하부구조가 포함되어 있다. 이 하부구조는 대규모의 클라이언트를 지원하여 고성능의 시스템을 운영하는데 중요한 역할을 한다. .NET에서는 이와 같은 중간계층 하부구조를 COM+라고 부르며 J2EE에서는, Enterprise JavaBeans (EJB)이라고 부른다.
세번 째 계층은 데이터베이스 계층으로, 실제 데이터가 저장되는 곳이다. MoneyBroker 시스템의 경우, 이 계층은 고객계정 정보와 청구서 지불의 내용을 저장하는 곳이다.
비즈니스 계층은 데이터 계층을 주로 사용하는 클라이언트다. 물론, 대부분의 기업들은 데이터 계층에 존재하는 데이터베이스를 활용하는 내부 시스템을 동시에 운용하기도 한다. 비즈니스 계층과 데이터 계층 간의 통신은 특정 API를 사용하는데, .NET의 경우는 ADO.NET이며, J2EE는 JDBC다.
이제 두 기술에 대하여 더 자세하게 알아보자.
.NET 아키텍처
전반적인 .NET 아키텍처는 6개의 주요 부분으로 나뉘어진다:
• .NET Framework
• VisualStudio.NET
• .NET Enterprise Server
• .NET 클라이언트 시스템
• UDDI eCollaboration 하부구조
• .NET 빌딩 블록(Building Block) 서비스
.NET Framework와 VisualStudio.NET
.NET에 있어서 가장 중요한 부분은 .NET Framework일 것이다. 이것은 운영체제와 밀접하게 관련된 일반적인 런타임 환경이다. 여기에는 컴포넌트 기반의 중간계층 하부구조인 COM+, 개발언어에 독립적인 런타임 환경, JIT(just-in-time) 컴파일러 그리고 .NET 컴포넌트 모델을 사용하여 패키지로 만들어진 운영체제 라이브러리들이 포함되어 있다. .NET 시스템에 있는 각각의 서버 측 계층들은 .NET framework을 지원하는 운영체제를 실행시키게 될 것이다.
.NET Framework와 가장 밀접하게 관련되어 있는 것은 VisualStudio.NET이다. 프리젠테이션 계층의 프로그래머들은 VisualStudio.NET을 사용하여 씬 클라이언트 시스템에 HTML 페이지를 전달하는 로직을 정의할 수 있다. 비즈니스 계층의 프로그래머들은 VisualStudio.NET의 매우 다양한 개발언어로 비즈니스 로직을 구현하고, 이 비즈니스 로직을 COM+ 컴포넌트로 만들 수 있다.
VisualStudio.NET은 개발언어에 독립적이다. 이것은 매우 다양한 개발언어가 플러그 인 될 수 있는 개방형 프로그래밍 플랫폼으로 생각할 수도 있다. VisualStudio.NET과 함께 제공되는 표준 개발언어는 Visual Basic, Visual C++와 Visual C#이다. 다른 언어들은 다른 개발언어 벤더를 통해 제공된다. 예를 들면, Fujitsu의 COBOL, Interactive Software Engineering의 Eiffel 등을 Visual Studio.NET에서 사용할 수 있다. Visual Studio.NET에서 사용할 수 있는 언어로는 Haskell, Mercury, Oberon과 Perl 등이 있으며, 앞으로 더 많은 개발언어가 지원될 예정이다.
VisualStudio.NET의 개발언어 독립성은 .NET 전략에 중요한 역할을 한다. Visual Studio.NET을 지원하는 모든 개발언어는 Microsoft Intermediary Language (MSIL)로 번역된다. 사실, 개발언어 벤더들은 MSIL 번역기를 만들어 자신의 개발언어를 Visual Studio.NET과 호환되도록 만드는 것이다. 이와 같이 호환되는 언어는 .NET 기능을 지원한다고 판단된다.
MSIL 파일은 일반적으로 어셈블리(assembly)라고 불리며 전개할 수 있는 단위로 함께 포장된다. 어셈블리들은 common language runtime (.NET Framework의 한 부분)으로 로딩되고 just-in-time MSIL 컴파일러가 이것을 컴파일한다. common language runtime에는 특정 언어와 연결하는 많은 개발기능들이 포함되어 있다. 예를 들면, 메모리 회수(garbage collection), 형 정의, 메서드 호출의 가상화(virtualization of method call), 에러처리와 전개모델 등이 포함되어 있다.
이러한 개발기능을 특정언어가 아닌 common language runtime에 통합시켰기 때문에, 개발언어들은 전체적인 .NET 플랫폼 내에서 자유롭게 연동된다. 아마도 개발언어 독립성에 대해 가장 인상적인 예는, C#에서 기본 클래스를 정의하고 COBOL과 같이 전혀 관련이 없는 언어에서 메서드를 오버라이딩하는 것이다. 필자는 최근의 한 자료에서 이 예를 설명했었다.
프리젠테이션 계층에서 .NET framework을 사용한다는 것은 프리젠테이션 로직에 .NET을 지원하는 모든 개발언어를 사용할 수 있다는 것을 의미한다. 그리고 .NET framework에는 just-in-time 컴파일러가 포함되어 있기 때문에, 프리젠테이션 계층의 스크립트는 컴파일되어 이전의 인터프리터 방식보다 훨씬 빠른 성능을 제공하게 된다.
최근의 씬 클라이언트(브라우저, 휴대폰, 테이블릿 PC 등)의 종류가 매우 다양해지고 있으며, 자신만의 마크업 언어를 제공하고 있다. 현재의 프리젠테이션 계층 스크립트는 먼저 클라이언트의 종류를 파악한 후에, 그 클라이언트에 적합한 HTML을 만들어야 한다. 이것은 많은 시간이 걸리고, 에러가 발생할 여지가 많으며, 새롭게 등장한 클라이언트 시스템은 지원하지 못하게 된다.
.NET framework에는 ASP.NET이라는 새로운 프리젠테이션 계층의 프로그래밍 모델이 포함되어 있다. ASP.NET은 프리젠테이션 계층이 클라이언트에 대하여 독립적일 수 있게 한다. ASP.NET 프로그래밍 모델은 현재의 Visual Basic 패러다임과 동일한 디자인 패러다임을 가지고 있다. 개발자들은 자신이 잘 알고 있는 IDE를 사용하여 ASP.NET 솔루션을 개발할 수 있다.
Visual Studio.NET을 사용하면, 컴포넌트 팔레트에서 (edit box 또는 pull down box와 같은) GUI 컨트롤들을 작업공간 위에 드랙 앤 드롭하는 것만으로도 ASP.NET 애플리케이션을 개발할 수 있다. 그 후에, 프로그래머는 자신이 원하는 언어를 사용하여 컨트롤 이벤트 코드를 작성하면 되는 것이다. 컨트롤은 클라이언트가 어떤 장비인가에 따라 자신을 렌더링하게 된다. ASP.NET framework는 클라이언트가 특정 행위(버튼 클릭과 같은)를 했는 지를 파악하는 책임을 진다. 이 모든 기능이 서버 위에서 실행되기 때문에, 서비스를 요청한 클라이언트 장비가 .NET 기술을 지원하던 안하던, 하나의 코드로 이 모든 장비를 지원할 수 있게 된다.
이처럼 드랙 앤 드롭만으로 컨트롤/이벤트 프로그래밍을 하고, 장비를 인식하는 기능이 프리젠테이션 로직이 아닌 서버측의 프리젠테이션 컴포넌트에 있기 때문에, 개발과 유지보수 면에서 모든 작업이 간편해졌다. 어떠한 클라이언트 장비가 요청하는 마크업 언어라도 간단한 하나의 코드 블록만으로 처리할 수 있기 때문에 개발 작업이 훨씬 간편해졌다. 새로운 클라이언트 장비가 추가되면 사용하고 있던 컨트롤의 최신 버전을 다운로드받기만 하면 되기 때문에 유지보수 작업도 간편해진다.
.NET Enterprise Server
.NET Enterprise Server는 엔터프라이즈 차원의 전문 서비스를 제공하도록 설계된 서버 제품군들이다. Enterprise Server 중 가장 잘 알려진 것은 SQL Server 2000이다. 이 서버는 너무나도 다양한 기능을 가지고 있기 때문에, 여기에서는 고성능, 고가용성 그리고 높은 확장성을 가진 관계형 데이터베이스로만 소개하겠다.
.NET Framework에 SQL Server를 꼭 사용해야 하는 것은 아니다. 많은 기업들은 기존에 보유하고 있던 Oracle 또는 DB2와 같은 데이터베이스를 .NET framework에 적용하여 전자상거래 시스템을 구축할 것이다. .NET데이터 계층에는 대부분의 데이터베이스가 적용될 수 있다. 예를 들면, 데이터베이스에 독립적인 ADO.NET 인터페이스를 통해 Oracle에 접속할 수 있다. CICS와 IMS같은 메인프레임 데이터베이스는 Host Integration Server(HIS)를 통해 접속할 수 있다.
.NET Enterprise Server 중에서 가장 새로운 서버는 Application Center Server다. 이 제품은 365일 가동되어야 하고 낮은 비용으로 확장성을 유지해야 하는 기업들을 위한 제품이다. Application Center Server는 클러스터를 조율하는 동시에 관리하는 제품이다.
Internet Security and Acceleration Server (ISA)는 프리젠테이션 계층의 요구사항을 해결한다. ISA는 두 가지 중요한 기능을 제공한다. 많은 사이트들의 성능을 크게 향상시킬 수 있는 HTML 페이지 캐싱과 방화벽 기능을 제공한다. 물론, 방화벽 기능은 모든 전자상거래 사이트에 필수적인 기능이다. ISA는 하드웨어 기반의 방화벽 제품에 비해 상당히 낮은 비용으로 방화벽을 구축할 수 있게 한다. ISA는 .NET의 다른 부분과 통합될 수 있지만, 반드시 있어야 하는 것은 아니다.
BizTalk Server는 기업의 다양한 업무를 연결하고, 그 기업이 XML을 사용하여 협력사의 업무와 연동될 수 있게 하는 통합(orchestration) 제품이다.
Commerce Server는 전자상거래 사이트를 구축할 수 있는 프렘임웍이다. 이 제품은 주로 B2C 사이트의 요구사항에 대한 기능을 가지고 있다. B2C 사이트들은 Commerce Server의 한 부분으로 제공되는 컴포넌트를 사용하여 자신의 전자상거래 기능을 신속하게 구축할 수 있다.
UDDI 협업 하부구조
협업은 eBusiness의 미래상이다. eCollaboration을 가능하게 만드는 산업표준들이 Universal Description, Discovery, and Integration (UDDI)라는 단어에 결집되고 있다.
이론상으로, UDDI는 .NET에 독립적이다. 그러나, Microsoft는 .NET 협업의 기초가 UDDI라는 것을 명확히 밝히고 있는 반면에, Sun은 지금 당장은 UDDI가 J2EE 협업의 기초가 아니라고 밝히고 있기 때문에, .NET과 관련하여 UDDI를 설명하는 것이 더 적절하다.
UDDI 표준은 uddi.org(www.uddi.org)라는 컨소시엄이 관장하고 있다. 이 컨소시엄은 Microsoft, Ariba, IBM이 이끌고 있으며, Accenture , Boeing, Compaq, Dell, Ford, HP, Loudcloud, Merrill Lynch, Rational, SAP AG, Sterling과 Sun 등의 160개 기업이 합류하고 있다.
UDDI는 산업전체에서 전폭적으로 수용되고 있는 표준들을 사용하고 있다. UDDI가 사용하는 산업표준은 다음과 같다:
• HTTP – 인터넷 통신의 표준 프로토콜
• XML – 데이터를 잘 구성된 문자열로 포장할 수 있는 산업표준
• SOAP – Microsoft와 IBM에 의해 급속하게 보급되고 있는 표준으로, 클라이언트의 작업요청과 시스템의 반응을 XML 문자열로 포장한다. SOAP는 Simple Object Access Protocol의 약자다.
HTTP와 SOAP은 서로 결합하여, 미래의 eCollaboration의 기초가 된다. 이 기술백서에서 SOAP를 말하면, 전송 프로토콜로 HTTP를 사용하는 것으로 생각하면 된다. 메시지 큐를 이용하는 다른 프로토콜을 통해 SOAP 요청을 처리할 수도 있지만, eCollaboration 아키텍처에서는 적합하지 않을 것이다.
SAOP 기반의 가장 일반적인 eCollaboration는 그림 2와 같다. MoneyBroker가 SOAP을 사용하여 AustinKayaks와 어떻게 전자협업을 하는지를 살펴보자. AustinKayaks는 고객들의 MoneyBroker 계정을 통해 지불을 받을 수 있다.
그림 2에 있는 AustinKayaks와 MoneyBroker 간의 전자협업에 대하여 살펴보자. 브라우저를 사용하고 있는 한 고객(1)이 AustinKayaks URL을 입력하고 장난감을 구매하겠다고 하면, 그 때부터 전자협업이 시작된다. 구매요청은 HTTP 요청으로 인터넷을 통해 전송된다(2). AustinKayaks 프리젠테이션 계층(3)은 이 요청을 받아들이고, 내부에서 사용하는 로칼 프로토콜(4)을 통해 비즈니스 계층으로 전송된다. AustinKayaks가 마이크로소프트 사이트라면, 로칼 프로토콜은 아마도 DCOM이 될 것이다.
AustinKayaks 비즈니스 로직은 이제 MoneyBroker 비즈니스 로직에게 지불을 요청해야 한다는 것을 알고 있다. 로칼의 SOAP surrogate(5)에서 이 요청이 이루어진다. SOAP surrogate는 지불요청을 SOAP 요청으로 다시 포장한 후에 HTTP를 사용하여 MoneyBroker 사이트로 전송한다. MoneyBroker 사이트는 MoneyBroker 프리젠테이션 계층에 있는 SAOP receiver(7)가 이 요청을 받는다.
그림 2. 일반적인 SOAP기반의 eCollaboration

SOAP receiver의 유일한 목적은 SOAP 요청을 로칼 프로토콜(8)을 통해 MoneyBroker 비즈니스 계층(9)에 전달될 수 있는 요청으로 변환하는 것이다. 비즈니스 계층에서는 AustinKayaks 비즈니스 계층이 요청한 지불요청을 처리한다. MoneyBroker 비즈니스 계층이 처리한 결과는 AustinKayaks 프리젠테이션 계층으로 반환되고, 프리젠테이션 계층을 이 결과를 고객의 브라우저에서 볼 수 있는 적절한 형식으로 변환한다.
SOAP은 어떤 기술에 종속된 것이 아니다. AustinKayaks와 MoneyBroker는 양쪽의 기술이 SOAP를 지원하는 한, 사이트에서 어떤 기술이라도 자유롭게 사용할 수 있으며, 서로의 환경을 맞출 필요가 없다.
AustinKayaks는 ‘MoneyBroker가 존재한다는 것’, ‘MoneyBroker의 URL’, ‘MoneyBroker가 제공하는 서비스’, ‘MoneyBroker가 수용할 수 있는 정확한 SOAP 형식’에 대한 4가지 사항만 알고 있다면, MoneyBroker의 웹 서비스를 사용할 수 있다. AustinKayaks가 이것들 중 하나라도 알지 못하는 경우에는 어떻게 할 것인가? AustinKayaks가 어떤 지불 서비스가 있는지, 그리고 어떤 사이트인지 또는 어떻게 그 서비스를 이용할 수 있는지를 모른다면 어떻게 할 것인가?
바로 이와 같은 문제를 해결하는 것이 UDDI다. UDDI는 협업가능성이 있는 업체들이 서로에 대하여 알 수 있게 하는 표준을 정의한다. UDDI 표준에 대해 다음과 같은 정보가 웹 에서 제공되고 있기 때문에, 여기에서는 자세한 설명은 피하도록 하겠다:
• 청구서 지불 서비스와 같이, 산업표준 인터페이스에 대한 정보를 가지고 있는 등록기관의 URL.
• MoneyBroker와 같이, 산업표준 인터페이스를 지원하기로 결정한 기업들.
• 등록기관에 대한 SOAP 인터페이스. 협력업체들은 이 인터페이스를 프로그래밍하여 서로를 발견할 수 있다.
• SOAP 인터페이스를 설명하기 위한 독립적인 표준 언어.
UDDI의 기초 표준(HTTP, XML, SOAP)과 UDDI eCollaboration 표준 사이에, 각 기업들이 서로 협력할 수 있는 독립적인 프레임웍이 있다.
.NET platform은 이미 XML과 SOAP 기술을 채택하였다. 마이크로소프트는 Ariba, IBM과 함께 UDDI 전략을 이끌고 있기 때문에, 이 표준들이 성숙하게 되면, .NET platform으로 통합될 것은 분명한 사실이다.
SOAP이 호출할 수 있는 비즈니스 로직을 웹 서비스라고 부른다.
.NET: 이 세상의 모든 것을 연결
그림 3은 .NET의 모든 부분들과 그 역할을 보여주고 있다. 이 그림은 그림 1이 더 발전한 것이다.
그림 1. .NET 전자상거래 아키텍처

J2EE 아키텍처
Sun 표준이 정의한 J2EE 아키텍처는 .NET에 비해 간단하게 설명할 수 있다. IBM의 WebSphere와 같은 특정 벤더의 제품군을 살펴보면, 대부분의 기술이 WebSphere에 한정되는 것을 알게 될 것이다. 벤더들이 J2EE를 변형한 것을 모두 비교하는 것은 무리이며, 필자의 경험으로는, 대부분의 기업들이 이식표준으로 J2EE를 채택하고 있다. 이식성에 관심이 있는 사람들은 Sun이 정의한 것에 스스로를 구속시키게 될 것이다.
J2EE 아키텍처는 5개 부분으로 나뉘어질 수 있다:
• Java language system
• Client programming model
• Middle tier infrastructure
• Programmer enterprise API
• Non programmer visible API
마지막의 Non programmer visible API에는 다른 제품들이 어떻게 J2EE에 끼워질 수 있는 지를 정의하는 API(Connector API등)와 J2EE 모델에서 이후에 개선되어 효과적으로 대체된 API(JTA-Java Transaction API)가 포함되어 있다. Non programmer visible API는 J2EE와 .NET을 비교한다는 점에서 중요하지 않기 때문에, 여기에서는 설명하지 않을 것이다..
Java Language System
고차원에서, Java language system은 .NET Common Language Runtime과 유사하게 보인다. 두 가지 모두, 소스코드가 저차원 언어로 번역된다. .NET 플랫폼에서는 저차원 언어가 MSIL인 반면에, Java system에서는 Java Byte Code가 된다. 두 가지 모두, 저차원 언어가 런타임 환경으로 불려들여진다. .NET 환경에서 이 환경은 Common Language Runtime인 반면에, Java는 Java Virtual Machine 머신이 된다. 전체적으로, Common Language Runtime과 Java Virtual Machine은 유사한 기능을 가지고 있으며, 두 가지 모두 나름대로의 장점을 가지고 있다.
두 시스템 간의 가장 큰 차이점은 소스코드를 저차원 언어로 번역하는 과정이다. .NET에서, 저차원 언어는 모든 개발언어를 수용하도록 설계되었지만, Java의 저차원 언어는 Java만을 수용한다. 이론적으로는, Java이외의 다른 언어에서도 Java Byte Code를 생성시킬 수 있지만, 실제로 구현된 상용제품은 아직 나타나지 않았다.
클라이언트 프로그래밍 모델
J2EE 클라이언트 프로그래밍 모델은 브라우저와 상호작용하는 것과 관련된 부분이다. 클라이언트 프로그래밍 모델은 Java Applet, Java Servlet과 Java Server Page로 구성되어 있다.
Java Applet은 브라우저 내에서 실행되는 Java 코드를 패키지하는데 사용된다. .NET 영역에서는 브라우저가 실행하는 풍부한 컨트롤을 통해 이 기능을 제공하여 풍부한 클라이언트 UI와 낮은 TCO를 가능하게 한다. 필자의 경험으로는, 전자상거래에서 applet 또는 ActiveX 컴포넌트가 거의 사용되지 않는다. 전자상거래 아키텍처는 일반적으로 프리젠테이션 계층에 대하여 브라우저가 HTTP 요청을 하고, 프리젠테이션 계층은 HTML 페이지로 응답하도록 구성되어 있다. 이런 종류의 시스템은 ActiveX 컴포넌트 또는 Java Applet을 사용하지 않는다.
HTTP 요청과 HTML 응답을 처리하는 중요한 기술은 바로 Java Servlet 과 Java Server Page다 . 이 두 기술은 기능 면에서 .NET의 프리젠테이션 계층 모델인 ASP.NET과 같은 역할을 한다.
.NET 프리젠테이션 계층과 Java 프리젠테이션 계층 간의 차이는 서로 다른 클라이언트 기능을 처리하는 방법이다. Java 프리젠테이션 계층은 이전의 Microsoft ASP 모델을 따라, 어떤 브라우저(또는 다른 씬 클라이언트 시스템)를 대상으로 하는지, 그 클라이언트가 어떤 기능을 할 것인지, 그리고 클라이언트 시스템을 가장 잘 활용할 수 있도록 HTML을 어떻게 생성할 것인지를 모두 프리젠테이션 계층의 프로그래머가 결정한다.
중간계층의 하부구조
J2EE에서는, Enterprise Java Beans (EJB)가 중간계층의 하부구조가 된다. EJB는 현재 2.0 버전이며 온라인을 통해 제공된다. EJB는 .NET Framework의 COM+와 대응되는 기술이다.
EJB와 COM+ 간에는 아키텍처 면에서 다른 점이 거의 없다. 둘 다, MTS (Microsoft Transaction Server)에서 파생된 아키텍처다. 다음과 같은 아이디어가 MTS에서 출발하여 EJB와 COM+로 통합되었다:
• 컴포넌트 인스턴스를 공유하여 높은 확장성을 보장
• 중앙계층에서의 보안 관리
• 트랜잭션 경계를 자동으로 관리
EJB는 컴포넌트 상태를 자동으로 관리하는 한 가지 아이디어를 아키텍처에 추가하였다. 이 기술은 entity beans라고 불린다. entity beans의 사상은 매력적이지만, 실제 구현은 데이터베이스 캐시와 별개인 중간계층의 데이터 캐시에 종속되어 있다. 불행하게도, 데이터베이스 캐시와 중간계층의 캐시 간에 일관성을 유지할 메커니즘이 존재하지 않는다. 이것은 entity beans를 사용하면, 데이터베이스 오류를 발생시킬 가능성이 높다는 것을 의미한다. 간단한 방법으로 캐시 일관성 문제를 해결하기 전에는, entity beans는 실험적인 기술 정도로만 받아들여야 한다.
EJB와 COM+에 대한 더 자세한 내용은, COM+ and the Battle for the Middle Tier 를 참조하기 바란다.
Programmer Enterprise API
우리가 Java Enterprise API라고 부르는 것 중에서 가장 중요한 부분은 다음과 같다:
• Java Database Connection (JDBC) 2.0 – Java에서 관계형 데이터베이스에 접속하기 위한 API . 이것은 .NET의 ADO.NET에 해당되는 것이다.
• Java Naming and Directory Interface (JNDI) – 엔터프라이즈 이름의 정보와 Java의 디렉토리 서비스에 접속하기 위한 API . 이것은 .NET의 Active Directory Services Interface (ADSI)와 비슷하다.
• Java Message Service (JMS) 1.0 – 비동기식 워크플로우를 위한 Java API . 이것은 Message Queue API와 같은 기능을 한다. 마이크로소프트는 queued component로 향상시킨 반면에, J2EE는 JMS를 그대로 사용하고 있다.
J2EE: 모든 것을 연결
그림 4는 J2EE의 각 부분의 역할을 보여주고 있다.
그림 4. J2EE 전자상거래 아키텍처

.

NET와 J2EE의 유사점
.NET와 J2EE 간의 유사점은 아래의 표와 같다. 여러분이 확인할 수 있듯이, J2EE는 .NET 기능 중 상당부분을 제공하지 못한다.
유사한 기술
가술 .NET J2EE
지원되는 기술
분산 프로토콜 DCOM, SOAP RMI/IIOP
방화벽 ISA*
HTML 페이지 캐싱 ISA*, ASP.NET

프리젠테이션 계층 기술
하부구조 IIS
프로그래밍 모델 ASP.NET Servlet, JSP
고 가용성 NLBS*, ASP.NET
로드 밸런싱 NLBS*
관리 Application Center Server*

중간계층 기술 .NET J2EE
하부구조 COM+ EJB
프로그래밍 툴 VisualStudio.NET
고 가용성 ACS*
로드 밸런싱 ACS*
보안 API COM+ Security Call Context JAAS
메시지 큐 API MSMQ JMS 1.0
비동기식 컴포넌트 Queued (COM+) Message driven beans (EJB 2.0)
Naming and Directory Service ADSI JNDI

데이터 계층 기술
분산 트랜잭션 MS-DTC JTS
관계형 DB API ADO.NET JDBC 2.0
계층형 DB API ADO.NET -
데이터베이스 저장소 SQLServer** -
메인프레임 DB 연결 HIS* Java Connectors

프레임웍 기술
전자상거래 프레임웍 Commerce Server* -
B2B 통합 BizTalk Server* -
.NET과 J2EE의 차이
.NET과 J2EE는 서로 상당히 유사한 점이 많다는 것을 앞에서 확인했다. 그렇다면, 둘 중에 어떤 것을 선택해야 할까? 이제부터는 두 아키텍처 간의 차이에 대하여 설명하도록 하겠다.
벤더 중립성
많은 기업들은 J2EE가 특정 벤더에게서 독립적이라고 생각하고 있다. 사실, 이것은 Sun의 비전에서도 공언하고 있다:
명세를 준부하는 많은 J2EE 제품 구성과 구현이 제공될 수 있다. 이식가능한 J2EE 애플리케이션은 이 제품들 내에 성공적으로 전개되었을 경우에 제대로 동작할 것이다.
사실, Sun을 제외한 거의 모든 J2EE 지지자들은 이것이 가능하다고 믿지 않는다. Cutter Consortium의 수석 컨설턴트이자 Architecture/e-Business E-Mail Advisory의 필자인 Paul Harmon은 J2EE를 열렬히 지지하고 있는 사람인데, 그는 최근에 J2EE 벤더의 이식성에 대하여 의외로 솔직한 평가를 내린 적이 있다.
EJB 모델은 한 EJB 애플리케이션 서버에서 다른 서버로 이동할 수 있을 까? 대부분의 경우는 이동시킬 수 없다. EJB 명세는 완벽한 것이 아니다. EJB 애플리케이션 서버 벤더들은 EJB 모델을 보완하고, 자신의 클라이언트들이 운용 시스템을 구축할 수 있도록 전용 솔루션을 제공하고 있다.
Harmon은 현재의 벤더 중립성을 다음과 같이 정리하고 있다:
지금의 현실은, 여러분이 EJB 애플리케이션을 개발하고 싶다면, 한 벤더만 선택해야 한것이다.
현실은, 벤더 중립성과 같은 것은 존재하지 않는다는 것이다. 물론, .NET도 벤더 중립적이지 않으며, Microsoft 운영체계에 집중하고 있다. 그러나 J2EE 구현도 전혀 중립적이지 않다. 필자가 할 수 있는 최선의 조언은, 한 벤더를 선택하고 그 벤더가 제공하는 플랫폼을 최대한 활용하라는 것이다.
전반적인 성숙도
J2EE의 첫번째 명세인 EJB 명세는 1998년에 발표되었고 1999년에 첫번 째 베타가 발표되었다. 이것은.NET 기술에서 MTS(지금은 COM+)라는 것이 발표된지 3년 만의 일이다. 필자는 최근의 한 자료에서 MTS에서 .NET으로의 진화를 설명한 적이 있다.
.NET이 J2EE에 비해 3년 앞서고 있는 점을 감안하면, .NET 플랫폼이 J2EE 플랫폼보다 훨씬 성숙되어 있다는 것은 놀라운 일이 아니다. NASDAQ, Dell과 같이 .NET 기술을 사용하고 있는 대용량의 웹 사이트가 이미 안정적으로 가동되고 있는 반면에, J2EE 플랫폼을 사용하여 있는 대형 사이트는 아직 들어보지 못했다. 다시 한 번, Paul Harmon은:
J2EE 기반으로 회사 전체의 시스템을 구축하려고 시도하고 있는 모든 기업들은 선구자 역할을 하고 있으며 난관을 극복하려면 정말 뛰어난 개발자들과 팀을 구성하는 것이 좋다. 더 중요한 것은, 아마도 종합적인 프로젝트를 다시 고려하고 초기 기대치를 조정해야 할 것이다.
연동성과 웹 서비스
.NET eCollaboration 모델은, 앞에서 설명한 바와 같이, UDDI 표준을 따르고 있다. 이 표준은 100개 이상의 기업이 전폭적으로 지원하고 있다. Microsoft는 IBM, Ariba와 함께 UDDI를 선도하고 있다. Sun은 UDDI 컨소시엄의 구성원이며 UDDI 표준의 중요성을 인식하고 있다. 최근의 기자배포 자료에서, Sun의 Java Community Development 부사장인 George Paolini는 다음과 같이 말했다:
"Sun은 네트워크 기반의 애플리케이션이 원활하게 성장할 수 있는 개방형의 표준 기술을 확립하고 지원해왔다. 그리고 우리는 UDDI를 B2B 전자상거래의 등록 프레임워크를 확립하는 중요한 프로젝트로 보고 있다. ”
그러나 Sun은 공식적으로는 UDDI 표준에 확신을 가지고 있다고 말하지만, 실제로는 UDDI 표준을 J2EE에 통합시키기 위한 어떠한 일도 하지 않고 있다. UDDI 표준의 가장 기본인 되는 SOAP가 1년 이상 존재해왔지만 지원하지 않고 있다. IBM의 Emerging Technologies 부사장인 Rod Smith는 최근에 다음과 같이 말했다:
현재까지, Sun은 UDDI 웹 서비스에 대하여 말을 삼가고 있다. 이것은 여러가지 이유때문이라고 생각한다. 그들은 Java를 중요하게 생각하고 있다. 웹 서비스에서는, 고객의 목소리가 중요하며 그들의 요구사항이 해결되어야 하지만, 실제로는 고객들은 Java 이외의 시스템과 애플리케이션을 가지고 있다. 그렇기 때문에, Sun은 여전히 Java를 홍보해오고 있는 동시에 웹 서비스에 대하여 입을 다물고 있는 것이다.
실제로, Sun의 연동전략에 대한 Smith의 분석은 상당히 정확하다. Sun은 1차적으로 J2EE 벤더 간의 연동성에 집중해왔으며, 제한된 범위 내에서 CORBA 벤더와의 연동을 추진해왔다. 연동성에 대한 Sun의 생각은, IIOP라는 통신 프로토콜을 이용하여 연동되어야 한다는 것이다.
IIOP를 이용한 연동에는 3가지 큰 단점이 존재한다.
먼저, 이것은 모든 것이 J2EE 또는 CORBA로 실행되어야 한다. 이러한 전제조건은 Sun의 J2EE 협력업체조차도 거부하고 있는 것이다. IBM의 Rod Smith는 IBM이 연동표준으로 IIOP가 아닌 SOAP를 지원하고 있는 이유를 다음과 같이 설명하고 있다:
IBM이 개방형 표준으로 SOAP를 지원한다는 발표를 했을 때, 반응은 매우 놀라울 정도로 긍정적이었다. 사람들은 이런 종류의 통합을 원했기 때문이다. 그들은 Microsoft 기반의 솔루션을 가지고 있다. 또한 그들은 Java 기반의 솔루션을 가지고 있다. 그들은 Windows NT 기반의 솔루션과 Linux 기반의 솔루션을 모두 가지고 있다.
두 번째 단점은 모든 전용 통신 프로토콜과 마찬가지로 IIOP는 인터넷을 통해 전송하기 쉽지 않다는 것이다. 이 때문에, eCollaboration을 위한 광범위한 메커니즘의 역할을 할 수 없다.
세 번째 단점은, 전세계 모든 기업이 IIOP와 J2EE를 사용하기로 결정한다고 해도, 현재의 IIOP 명세는 J2EE 벤더들간의 연동을 보장하기에도 불충분하다는 것이다. Paul Harmon은 다음과 같이 말하고 있다:
서로 다른 벤더의 EJB 애플리케이션 서버들이 대형 시스템에서 통합될 수 있을 정도로 표준화되어 있을까? Internet InterORB Protocol (IIOP)을 통해 EJB 애플리케이션 간에 통신을 한다고 해도, 한 네트워크 내에서 여러 개의 EJB 제품들을 연결하는 것은 쉬운 일이 아니다. 여러 개의 비표준 유틸리티를 사용하는 두 개의 EJB 애플리케이션 서버의 통신을 원활하게 하는 것은 상당히 많은 프로그래밍을 해야 한다.
현실은 .NET이 J2EE에 비해 훨씬 중립적인 eCollaboration 전략을 가지고 있다. IBM이 IIOP보다 UDDI가 올바른 연동방법이라고 확신하고 있는 것도 이 때문이다. 지금으로서는, UDDI에 앞서 나온 IIOP는 완벽한 실패라는 것이 분명하다.
확장성
확장성은 더 많은 부하를 추가할 수 있는 능력을 말한다. 일반적으로, 더 많은 사용자가 추가될 경우에 추가적인 부하가 발생된다. 확장성은 상당히 복잡한 내용으로 필자도 많은 자료에서 자세히 설명했었다. 여기에서는 MoneyBroker가 향후 3년 동안 직면하게 될 문제를 예로 들면서 설명하겠다. 이해를 돕기 위하여, 여기에서는 프리젠테이션 계층을 제외한 비즈니스와 데이터베이스 계층만을 실행하는 비용을 감안한다. 프리젠테이션 계층을 포함한다고 하여도 비슷한 결과가 나올 것이다.
MoneyBroker의 비즈니스 모델은 올해에 매일 10만 건의 지불요청을 처리해야 하지만, 내년에는 100만 건, 2년 후에는 1,000만 건을 처리해야 한다고 가정하자. .NET/Windows 솔루션을 선택하는 것과 J2EE/Unix 솔루션을 선택하는 것의 상대적인 비용은 어떻게 될까?
향후 3년 동안 MoneyBroker가 필요로 하는 시스템 규모를 측정하려면, 트랜잭션 성능을 측정할 수 있는 표준 벤치마크가 필요하다. 트랜잭션 결과에 대한 산업표준의 벤치마크는 Transaction Performance Council (TPC)이 관장하고 있으며, 이 벤치마크는 TPC-C 벤치마크로 불린다. TPC 구성원 중에는 Sun, IBM, Oracle, BEA, Microsoft외에 대부분의 중간계층/데이터 계층 벤더들이 포함되어 있다.
TPC-C 벤치마크는 시스템이 기록할 수 잇는 최고의 부하를 측정한다. 측정 단위는 tpmC로, 이것은 TPC-C 벤치마크에서 정의하는 분당 트랜잭션 양이다. 벤치마크에 대한 명세는 TPC 웹 사이트에서 참조할 수 있다.
MoneyBroker에 TPC-C 수치를 적용하는 데에는 두 가지 문제가 있다.
첫 번째 문제는 TPC-C에서 정의한 트랜잭션은 MoneyBroker 트랜잭션과 상당히 다르다는 것이다. TPC-C 명세를 정확하게 이해하고 MoneyBroker에서의 트랜잭션 한 개가 몇 개의 TPC-C 트랜잭션에 해당하는 지를 생각해야 한다. 어느 정도의 편차가 존재하겠지만 MoneyBroker의 트랜잭션은 TPC-C의 10과 맞먹는다고 계산한다.
두 번째 문제는 어떤 J2EE 벤더도 TPC-C 수치를 공식적으로 발표하지 않았다는 것이다. 이 때문에, MoneyBroker를 특정 J2EE 구현과 비교하는 것이 힘들다. 재미있는 것은, 주요 J2EE 벤더들이 TPC-C 벤치마크의 테스트를 거쳤지만, 어느 누구도 J2EE 기술을 사용하지 않았다는 것이다.
예를 들어, IBM의 WebSphere 기술에는 6개의 벤치마크가 있지만, WebSphere 결과를 살펴보면, 벤치마크의 어느 코드도 Java로 작성되지 않았으며, WebSphere J2EE 기능을 사용하지 않았다는 것을 발견하게 된다. 대신에, 이 벤치마크들은 IBM의 전통적인 Encina TP 기술을 사용했다. 이 기술은 WebSphere 브랜드에 속하지만, Java를 사용하는 것은 아니다. 이와 비슷하게, BEA도 전통적인 Tuxedo 기술을 사용하여 벤치마크를 실시하고 있지만, 어디에도 J2EE는 포함되지 않고 있다.
필자는 J2EE 성능 수치를 이용할 수 없기 때문에, J2EE의 상대적인 성능을 감안해야 한다. J2EE는 전통적인 TP 모니터 위에 존재하겠지만, 이 경우에는 Java 프로그래밍 언어, Java 가상머신과 EJB(중간계층)의 부담이 가중되기 때문에, J2EE는 J2EE를 사용하지 않은 아키텍처보다 50% 정도 낮은 성능을 기록한다는 전제가 합리적일 것이다. 그렇기 때문에, 필자는 J2EE의 성능을 측정하는데 있어서 50%의 성능조정 요인을 적용시킬 것이다.
TPC-C 정보를 사용하여 MoneyBroker를 계속 분석해보자. MoneyBroker는 어떤 종류의 시스템을 구매할 것인지 결정하려고 한다. 가능한한 적은 예산을 지출하고 싶지만, 사용자가 집중되는 피크타임에 대하여 좋은 성능을 보여야 한다. 그리고 시스템은 향후 3년 동안 증가하는 수요를 충족시킬 수 있도록 확장될 수 있어야 한다.
올해 MoneyBroker는 매일 10만건의 트랜잭션을 처리해야 한다. 이것은 평균 분당 70건의 트랜잭션, 피크타임에 분당 700건의 트랜잭션을 처리해야 하는 것이다. MoneyBroker 트랜잭션 하나는 10개의 tpmC 트랜잭션에 해당되기 때문에, 이것은 최고 7,000 tpmC와 맞먹는 것이다. 내년에는, 7만 건으로 10배 증가하고 2년 후에는 70만건으로 다시 10배 성장한다.
그렇다면, 향후 3년 동안 시스템에 대하여 지불해야 하는 항목은 무엇인가? 우선 J2EE/Unix 대안부터 검토해보자. 모든 대안을 검토할 수 없기 때문에, IBM의 AIX 운영체계, WebSphere와 Oracle 8i 데이터베이스라는 가장 대표적인 J2EE/Unix 구성으로 비교하도록 한다. 이 구성은 이미 6개의 벤치마크가 존재하며, 이것은 50%의 성능조정 요인이 적용된 수치다:

벤더 시스템 tpmC 총 시스템 비용
Bull Escala T610 c/s 16,785 $1,980,179
IBM RS/6000 Enterprise Server F80 16,785 $2,026,681
Bull Escala EPC810 c/s 33,375 $3,037,499
IBM RS/6000 Enterprise Server M80 33,375 $3,097,055
Bull Escala EPC2450 110,403 $9,563,263
IBM IBM eServer pSeries 680 Model 7017-S85 110,403 $9,560,594
마찬가지로, 너무 많은 시스템구성이 있지만, 앞에서와 같이 대표적인 .NET 시스템만을 조사하면 다음과 같은 수치가 나온다:

벤더 시스템 tpmC 총 시스템 비용
Dell PowerEdge 4400 16,263 $273,487
Compaq ProLiant ML-570-6/700-3P 20,207 $201,717
Dell PowerEdge 6400 30,231 $334,626
IBM Netfinity 7600 c/s 32,377 $443,463
Compaq ProLiant 8500-X550-64P 161,720 $3,534,272
Compaq ProLiant 8500-X700-64P 179,658 $3,546,582
Compaq ProLiant 8500-X550-96P 229,914 $5,305,571
Compaq ProLiant 8500-X700-96P 262,244 $5,305,571
Compaq ProLiant 8500-700-192P 505,303 $10,003,826
여러분은 MoneyBroker가 선택할 수 있는 대안을 확인할 수 있다. 올해에는, 7,000 tpmC 시스템만이 필요하다. 이 시스템은 Unix의 경우 26억원정도이지만, .NET 환경에서는 3억6천만원 정도에 불과하다. 내년에는 7만 tpmC 시스템이 필요하게 될 것이며, J2EE/Unix 환경으로는 123억원의 비용이 드는 반면에, .NET 환경에서는 46억원의 비용이 든다. 3년 째에는, 7십만 tpmC의 성능이 필요하지만, 어떤 시스템도 이 정도의 성능을 제공하지 못한다. .NET 환경에서는 최고의 성능을 제공하는 시스템 비용이 130억원인 반면에, J2EE/Unix 환경에서는 무려 618억원을 지불해야 할 것으로 예상된다.
분명히 시스템 비용이 중요한 고려사항 중 하나라면, .NET 플랫폼은 J2EE에 비해 훨등한 비교우위를 가지고 있다. 위에서 확인한 바와 같이, J2EE/Unix 환경은 .NET 환경에 비해 5~10배의 비용을 지불해야 한다.
앞에서의 .NET 벤치마크는 실제 환경에서 이루어진 실제 벤치마크인 반면에, 어떠한 J2EE 벤치마크도 시행되지 않았다는 점을 다시 한 번 강조하고 싶다. 앞에서의 J2EE 수치는 실제 환경에서 기록하지 못할 수도 있는 가상의 벤치마크 결과다. J2EE 벤더들이 자신의 벤치마크를 발표하기 전에는, 비용은 제쳐두고라도 아직까지는 어떤 J2EE 플랫폼도 신뢰성을 입증하지 못했다는 것을 기억해야 한다.
프레임워크 지원
대규모의 전자상거래 솔루션을 구축하는 경우에, 모든 것을 자체적으로 개발하는 기업은 없을 것이다. 기업들은 잘 정의되고 테스트된 eCommerce 프레임워크를 활용하고 싶어 한다. 이런 프레임워크를 사용하게 되면, 개발비용을 크게 줄일 수 있다.
.NET 플랫폼에는 Commerce Server라는 전자상거래 프레임워크가 포함되어 있다. J2EE 환경에서는 벤더 중립적인 프레임워크가 존재하지 않는다. J2EE에서는 전자상거래 솔루션을 기본부터 개발해야 한다고 생각해도 무방하다. Paul Harmon은 다음과 같이 동의하고 있다:
더욱이, 어떤 J2EE 벤더를 선택하던지, 완벽한 eBusiness 애플리케이션을 신속하게 전개할 수 있는 컴포넌트 프레임워크를 기대한다면, 여러분은 상당히 당황하게 될 것이다.
MS Commerce Server가 여러분의 전자상거래의 기초역할을 할 수 있다면, 전자상거래 시스템을 개발하는 비용은 크게 낮아질 것이다. Commerce Server는 특히 B2C에 적합하다.
개발언어
개발언어 부분에서는, 선택이 상당히 간단한 편이다. J2EE는 Java만을 지원한다. Java를 제외한 다른 개발언어는 지원하지 않을 것으로 보인다. .NET은 Java를 제외한 모든 개발언어를 지원한다. 사실, 개발언어 독립적인 .NET 플랫폼의 중요성을 감안하면, 이제부터 발표되는 모든 개발언어는 .NET을 지원하게 될 것이다. 그리고, Java User Migration Path to .NET (JUMP to .NET)을 통해, Java로 코드를 작성하고 싶은 개발자들고 .NET을 이용할 수 있게 된다.
일부 기업은 J2EE가 다른 언어도 지원한다는 생각을 하고 있다. IBM의 WebSphere와 BEA의 WebLogic은 모두 다른 개발언어를 지원하지만, 자신의 J2EE 기술에서는 전혀 구현하고 있지 않다. J2EE 플랫폼에서 다른 개발언어를 이용할 수 있는 공식적인 방법은 두 가지뿐이다. 하나는 Java Native Interface를 통하는 것이며, 다른 하나는 CORBA를 통하는 것이다. Sun은 후자의 방법을 추천하고 있다. Sun의 Java Architect인 Rick Cattell은 최근의 인터뷰에서 다음과 같이 말하고 있다:
Java Native Interface 또는 CORBA를 통해 C++ 코드를 호출할 수 있다. CORBA는 더 유연하며, J2EE가 CORBA와 잘 동작하도록 디자인되었기 때문에, CORBA가 더 바람직한 방법이 될 것이다.
CORBA 아키텍처로 새로운 코드를 작성하는 것은 다시 생각해야 할 문제다. CORBA은 이제 거의 고사상태나 다름이 없다. IONA를 제외한 모든 CORBA 벤더들이 수익을 올리지 못했으며, IONA까지도 이제는 더 이상 CORBA에 투자를 하고 있지 않다. 만약, 개발자가 Java 이외의 다른 개발언어로 개발하고 싶다면, J2EE는 올바른 선택이 아니다.
현재 Java를 사용하고 있지 않은 기업들이 Java 표준을 검토하는 경우가 있다. 이런 기업들은 다음과 같은 3가지 방식을 취하게 되 것이다:
• 기존의 인력을 재교육
• 신규직원을 고용하고 기존의 인력을 대체
• 아웃소싱
재교육은 아마도 가장 값비싼 대안일 것이다. 전통적인 프로그래머들을 객체지향의 Java 프로그래머로 재교육하는 것은 상당히 많은 부담을 발생시킨다. Gartner 그룹의 최근 조사에 따르면, COBOL 프로그래머를 Java 프로그래머로 재교육시키는 것은 약 8천만원의 비용이 든다. 그렇다고 생산성이 향상되는 것은 아니다. 8천만원의 비용으로 재교육시킨다고 해도 달라지는 것은 Java로 코드를 작성한다는 것뿐이다. 많은 기업들이 객체지향 기술을 도입하는 과정에서 생산성이 크게 저하되는 경우가 대부분이다. 개발자들은 올바른 객체지향 디자인과 분석에 대하여 탁상공론으로 시간을 허비하기 때문이다.
신규직원을 고용하고 대체하는 것도 많은 비용이 든다. 현재, Java 프로그래머는 Visual Basic/COBOL 프로그래머에 비해 30% 높은 임금을 받고 있다. 더욱이, 그들은 더 높은 이직율을 보이고 있는 반면에, 생산성이 더 향상되었다는 증거는 아직 없다.
아웃소싱은 Java로 전환하려는 기업이 선택할 수 있는 유일한 방법일 것이다. 그러나, 아웃소싱이 위에서 언급한 모든 문제를 완벽하게 해결할 수 있다고 가정하는 것은 곤란하다. 특히, 추가적인 프로그래머 관련 비용은 여러분에게 그대로 전가되기 때문이다.
어떤 개발언어를 사용해야 하는 것일까? 결론은, Java로 교육된 직원이 있고 프로그래밍 과정을 효과적으로 관리할 수 있는 좋은 정책이 시행되고 있다면, 그대로 Java를 사용하면 된다. 반면에, 여러분의 기업이 이미 Visual Basic 또는 COBOL에 익숙하다면, Java로 변환하는 것은 극히 어려운 결정이 될 것이다.
개발언어에 대한 선택이 .NET과 J2EE 간의 선택을 결정하지는 않겠지만, 여러분이 Java 이외의 다른 것을 원한다면, J2EE는 더 이상 고려대상이 아니다. 그러나, 여러분이 Java 언어를 선택한다면, JUMP 툴세트를 활용하여 .NET을 사용할 수도 있다. 또 다른 대안은 Java와 매우 유사한 개발언어를 선택하는 것이다. 현재, Java와 가장 비슷한 개발언어는 C#이다. C#은 Java와 너무나도 비슷하기 때문에, 대부분의 사람들은 코드만 보고는 구분하지 못할 정도이다.
그러나, 여러분이 개발언어가 아닌 J2EE 플랫폼의 이식성 때문에 Java를 선택했다면, C# 또는 다른 것들은 적합하지 않을 것이다. 이 경우에는 J2EE가 여러분의 대안이 된다. 그렇지만, 결정을 하기 전에, 필자가 설명한 이식성 부분을 잘 확인하기 바란다.
이식성
J2EE에 매력을 느끼는 것은 이식성때문이다. 이식성에는 두 가지 의미가 있다. 하나는 벤더의 이식성이다. 이것은 앞에서 벤더의 중립성으로 이미 설명했었다. 두 번째 의미는 운영체계의 이식성이다. 이것은 코드를 수정하지 않고도 한 운영체계에서 다른 운영체계로 이동시킬 수 있는 능력을 말한다. 벤더의 이식성과는 달리, 운영체계의 이식성은 J2EE에서 구현이 가능하다.
J2EE에서 운영체계의 이식성이 가능한 것은, J2EE의 본질적인 이식성보다는 대부분의 J2EE 벤더들이 다양한 운영체계를 지원하기 때문이라는 것이 맞다. 그러므로, 특정 J2EE 벤더 또는 데이터베이스 벤더에만 집중한다면, 운영체계 간의 전환이 가능해진다.
벤더의 이식성/중립성이 바람직하다는 것은 분명하지만, 운영체계의 이식성은 어떤 장점이 있는 것일까? 운영체계의 이식성이 필요하다고 생각하는 기업들은 ISV(independent software vendor)와 확장성 솔루션을 모색하고 있는 기업들이다.
ISV는 Windows 이외의 플랫폼을 가지고 있는 고객들이 많은 경우에 운영체계 이식성이 필요하다. Unix 고객에게 .NET 전용 제품을 판매할 수는 없다. 이 경우에는 .NET이 J2EE보다 더 우수하다는 것은 중요하지 않다.
J2EE는 Windows 이외의 고객을 가진 ISV들에게 좋은 솔루션을 제공한다. ISV의 주요 고객들이 Windows를 사용한다면, .NET이 선택되어야 한다. .NET은 훨씬 저렴한 비용으로 훨씬 높은 성능을 제공할 것이다.
운영체계 이식성을 원하는 많은 기업들은 이식성이 확장성을 보장한다고 생각하고 있다. 이 기업들은 애플리케이션을 더 큰 하드웨어 플랫폼으로 전환하여 확장성을 보장할 수 있다고 믿고 있다.
만약, 운영체계의 이식성이 확장성을 보장할 수 있다고 믿는다면 이것은 큰 실수를 하는 것이다. 확장성은 하드웨어의 문제가 아니며, 소프트웨어에 관한 문제다. 최고의 확장성은 높은 확장성을 가진 플랫폼을 개발하고, 가능한한 이 플랫폼을 활용하여 보장받을 수 있는 것이다. 다양한 플랫폼에서 J2EE 제품이 실행되는 것과 확장성과는 거리가 멀다. 현재까지 가장 높은 확장성을 보장하는 것으로 입증된 플랫폼은 .NET 플랫폼이다.
앞에서 설명한 확장성 부분을 다시 인용하면, .NET/Windows 플랫폼은 분당 16,000건의 트랜잭션 처리에서 분당 500,000건으로 확장될 수 있다. IBM WebSphere J2EE/Unix 기술은 분당 17,000건에서 고작 110,000건으로 확장될 수 있을 뿐이다.
그리고 이식성은 그렇게 쉬운 문제가 아니다. 확장성을 원한다면, .NET은 J2EE에 비해 분명한 장점을 가지고 있다.
여러분이 특정 벤더에게 의존하지 않는 이식성을 원한다면, 잊어버리기 바란다. 그런 종류의 이식성은 존재하지 않는다. 그렇기 때문에, 벤더를 신중하게 선택해야 한다. 벤더의 기술과 비전을 이해하고 이것을 이용할 수 있어야 한다. 그리고 그 벤더는 자신의 플랫폼에 장기적인 전략을 가지고 있어야 한다. 마지막으로, 여러분이 선택한 벤더는 극심한 기술경쟁에서 비전을 실현할 수 있는 충분한 자원을 가지고 있어야 한다.
클라이언트 장비의 독립성
앞에서, .NET과 Java의 프리젠테이션 계층의 프로그래밍 모델을 설명했었다. Java와 .NET의 차이는, Java는 클라이언트에 전달될 HTML을 프리젠테이션 계층의 프로그래머가 판단하지만, NET에서는 Visual Studio.NET 컨트롤이 이것을 자동으로 판단한다.
Java의 클라이언트 방식에는 3가지 문제점이 있다. 먼저, 모든 씬 클라이언트 시스템이 서로 다른 코드를 요구하기 때문에, 프리젠테이션 계층에 상당히 많은 코드가 존재해야 한다. 두 번째 문제는, 존재하는 모든 씬 클라이언트 시스템에 대하여 코드를 테스트하는 것이 매우 힘들다. 세번 째 문제는, 기존 애플리케이션에 새로운 씬 클라이언트를 추가하는 것이 너무나도 힘들다는 것이다. 새로운 클라이언트를 추가하려면, 철저한 검사 후에 막대한 양의 프리젠테이션 로직을 수정해야만 한다.
.NET의 방식은 비주얼 컨트롤로 상호작용하는 독립코드를 작성하는 것이다. 클라이언트 장비의 능력에 따라, 어떤 HTML을 전송할 것인지를 판단하는 것은 프로그래머가 아닌 컨트롤의 책임이다. .NET 모델에서는, HTML과 같은 것이 존재한다는 것을 몰라도 상관이 없다.
.NET의 방식은 Java와 ASP 방식의 모든 문제를 해결하고 있다. 한 코드로 모든 씬 클라이언트에서 실행시킬 수 있기 때문에, 개발자들은 훨씬 적은 코드로 효과적인 프리젠테이션 애플리케이션을 작성할 수 있다. 테스트하는 것도 매우 쉬워졌다. 모든 클라이언트 장비에 대하여 테스트하는 것이 아니라, .NET에서는 컨트롤과의 상호작용에 대해서만 테스트하면 된다. 그리고, 마지막으로 단순히 최신버전의 컨트롤을 다운로드받기만 하면, 새로운 클라이언트 장비를 추가할 수 있게 된다.
비용 면에서, .NET의 방식이 훨씬 더 효과적이다. 프리젠테이션 계층을 개발하는 사람들은 클라이언트 장비가 아닌 자신의 코드에 집중할 수 있기 때문에 개발, 디버깅과 유지보수가 훨씬 더 쉬우며 더 저렴하다.
결론
우리는 전자상거래에 대하여 두 개의 서로 상충되는 비전을 가지고 있다.
Sun의 J2EE 비전은 많은 벤더들이 구현할 수 있는 멩서들로 구성되어 있다. 모든 기업이 이 기술을 라이센스하여 구현할 수 있다는 점에서 개방적이지만, Sun에 의해 통제된되며, Java 이외의 다른 기술과 연동될 수 있는 가능성이 매우 적다는 면에서는 폐쇄적인 기술이다.
J2EE의 단점중 하나는 플랫폼의 선택이 한 개발언어의 선택으로 이어지며, Java는 대부분의 기업에 적합하지 않다는 것이다. J2EE의 장점 중 하나는 J2EE 벤더들이 운영체계 이식성을 지원한다는 것이다.
Microsoft의 .NET 비전은 단순한 명세가 아닌 제품으로 구현된 실체이며, 명세는 연동부분을 정의하는 역할을 한다. .NET의 단점은 Windows 플랫폼에 한정되어 있기 때문에, .NET으로 개발된 애플리케이션들은 .NET 플랫폼 위에서 실행된다는 것이다. .NET 플랫폼의 주된 장점은 다음과 같다:
• 표준 개발언어가 사용되며 장비에 독립적인 프리젠테이션 계층이 작성될 수 있기 때문에, 애플리케이션을 개발하는 비용이 훨씬 낮다.
• Unix 하드웨어의 20%에 불과한 비용으로 더 높은 성능을 제공하기 때문에, 애플리케이션을 운용하는 비용이 훨씬 저렴하다.
• 모든 J2EE 플랫폼이 지원할 수 있는 클라이언트 수보다 최소 10배를 지원할 수 있기 때문에, 확장성이 훨씬 뛰어나다.
• 산업표준 eCollaboration이 플랫폼 내에 구축되어 있기 때문에, 연동성이 훨씬 뛰어나다.
더욱이, .NET에는 Unix 기반의 솔루션에 비해 극히 낮은 비용으로 전자상거래를 구축할 수 있는 제품이 포함되어 있다.
Roger Sessions에 대하여
ObjectWatch의 CEO인 Roger Sessions는 세계적인 전자상거래 아키텍처 전문가이며, Microsoft.NET, OMG의 CORBA, Sun의 J2EE에 대해 풍부한 경험을 가지고 있다. 그는 5권의 책과 수십 편의 기사를 저술했으며 각종 세미나의 강사로도 활동하고 있다. 현재 Software Magazine에 정규 칼럼을 기고하고 있으며, ObjectWatch Newletter의 편집을 맡고 있다.
1990년부터 1995년까지, IBM의 CORBA 구현을 위한 수석 아키텍트로 근무했으며, 그의 Object Persistence, Beyond Object-Oriented Databases는 CORBA Persistence Service 부분에 가장 뛰어난 서적으로 알려져 있다.

익명 사용자의 이미지

헉~~테러다...

익명 사용자의 이미지

원글의 출처로 내용을 수정하고 원본은 리플에 올리고 점수를 -1로 해서 숨겨두는게 어떨까요?

익명 사용자의 이미지

위의 내용은 'Roger Session'으로 알려진, .NET으로
상당히 편향된 시각에서 J2EE와 .NET을 비교한 글입니다.
여기에 대한 논란도 꽤나 많았던 것으로 기억합니다.

대표적인 내용은
http://www2.theserverside.com/home/thread.jsp?thread_id=8627
에서 확인하실 수 있으며, 상대적으로 J2EE 편에서
비교한 내용으로는

http://www2.theserverside.com/resources/article.jsp?l=J2EE-vs-DOTNET
이 있습니다.

한 때 두 사람이 한 자리에서 토론을 한적이 있었던 것으로 기억하는데
상당히 흥미롭더군요 :)

어쨌든 객관적 견지에서 쓴 글이 아니라는 사실은 지적하고 싶습니다.

박명준의 이미지

ASP/JSP/PHP
사실 기본 기능만 쓴다면, 거의 다 비슷하죠. 차이나는 부분은 특정기능의 객체화(ASP는 MTS컴포넌트를 지원했었고, JSP는 빈즈 컴포넌트, PHP는 음~ ^^;; 컴포넌트처럼 지원하는 건 없고, 다만 함수 라이브러리가 UNIX스타일로 왕창 많이 제공된다는 거...)
ASP의 경우는 설치가 쉽고, 독학이 쉬운 반면(ASP 한글 강좌 사이트 좋은게 많은 편이죠) VB나 VC++로 서버 컴포넌트 만들어서 연동한다고 하는데, 부가적으로 읽어야 할 것들이 많아서, 그냥 코딩했던 기억이 나네요. ^^;; JSP는(resin+oracle의 경우) 설치에 좀 애를 먹었죠. ^^;; DB커넥션 연결맺고, 안끊어주면, DB가 멎어버리기두 하구요. -_-;; PHP는 더군다나 리눅스 지식이 좀 있어야 하고... 아파치 웹 서버는 IIS처럼 UI달린 제어도구를 제공하지 않잖아요. 그래서 더 힘들었던 듯... -_-;;
개인적으로 맘에드는 언어는 PHP이구요. 물론 중소규모 사이트 제작용으로 맘에 들죠. PHP를 쓴다면, 그냥 컴포넌트니 객체니 UI재사용이니 그런 생각 안하고, 편하게 page랑 DB붙일 때~ 갖가지 제공되는 함수 끼워맞춰서 작업하는 편...
대형사이트라면, 아무래도 컴포넌트로 구성하기 쉬운 JSP가 맘에 드는데, 책을 보면, UI와
비즈니스 로직의 완벽한 분리가 가능하다고 하는데(커스텀 태그 같은걸 자체제작할 수 있다고 문서에는 쓰여 있죠), 막상 해볼려면, 많은 문서를 읽어보아야 했습니다. -_-;; 자바에 익숙하지 않으면, 쉽지두 않구요. 하지만 대겹 사이트들 보믄 대개 JSP를 쓰는 거 같던데요. (S전자, L전자 등~) 그리고 자바를 이용한다면, 기존 JDK에서 제공되는 무지 많은 클래스들을 가져다가 쓸 수 있으니 그게 좋겠죠. (물론 빈으로 감싼 담에... ASP에서 컴포넌트 만드는 것보다는 빈 컴포넌트 만드는게 더 쉬웠던 듯... 그냥 자바로 클래스 만들어 옮겨주면 끝나서, ASP처럼 MTS에 등록하니 어쩌니 그런일 안해도 되죠~)
PHP는 클래스를 지원하지만, 클래스 스타일을 지원하는 코드를 얼마 볼수는 없었습니다.(MySQL/Oracle DB연동 PHP클래스를 써봤는데, 클래스를 구성할 수 있다면, PHP코드가 많이 간결해 질거라 생각이 듭니다. 하지만 PHPNuke는 절차 지향 스타일로 프로그램되어있더군요. 읽어보기 무지 힘들더라구요. ^^;;)
PHP의 장점중의 하나가 오픈소스들이 많다는 거... Apache, PHP, MySQL조합으로 괜찮은 소스들이 웹서핑하다보면 널려 있죠. (특히 외국쪽)
ASP는 별루 모르겠구요.(아마 kldp도 PHPNuke사용한거 같은데... 맞죠? ^^;;)

쉽게 코딩/쉽게 설치 -> ASP
DB 풀링 쉽게 넣을려면 -> JSP
파일업로드 쉽게 넣을려면 -> PHP
자바랑 연동 OOP스타일 코딩 -> JSP
인터페이스 재사용하기 -> 흠... -_-;;
오픈소스? -> PHP (개인적인 생각 ^^;;)

권순선의 이미지

이 사이트(http://geekforum.kldp.org)에서 사용하고 있는 것은 phpnuke가 아니라 korweblog 입니다. http://weblog.kldp.org를 참고하세요...
--
WTFM :-)

익명 사용자의 이미지

하~ 관계없는 말이지만..
j2ee의 확장성과 php의 강점인 간결함이 있는
엔터프라이즈 php 가 나왔으면 합니다.

익명 사용자의 이미지

(1) ASP
장점으로는 순수하게 ASP만으로 개발할 경우 상대적으로 배우기 쉽고 디버그가 용이하다는 장점이 있습니다. 컴파일이 없기 때문에 수정결과가 즉시 반영된다는 장점도 있습니다(물론 런타임에는 약점이 됩니다). ASP.NET에서 부터는 개발툴과의 완벽한 통합도 강점이라고 할 수 있습니다.

써드 파티 컴포넌트도 꽤 있지만 오픈소스 기반이나 무료 제품은 그렇게 많지 않습니다.

반면, MTS/COM등을 사용할 경우 개발 및 디버그가 어렵다는 약점이 있습니다. AST.NET이전에는 인터프리크 방식이었기 때문에 속도 면에서도 JSP에 크게 뒤집니다. 또한 MS환경에 종속된다는 약점도 가지고 있습니다.

(2) PHP
이 부분은 ASP/JSP에 비해 상대적으로 경험이 적어 많은 이야기를 하기 어렵습니다. 하지만 외국의 토론사이트 등에서 비교되는 것으로 볼 때 PHP의 가장 큰 강점은 생산성인 것 같습니다. 간단한 웹메일을 PHP와 J2EE기반으로 구현한 적이 있었는데 PHP의 경우 방대한 함수 라이브러리(?)가 상당히 인상적이었습니다. 또한 아파치 서버가 윈도우즈와 유닉스 머신을 동시에 지원한다는 장점도 있습니다.

속도 측면에서는 아는바 없고, EJB/자바빈즈나 MTS/COM에 대응하는 컴포넌트 모델이 약하기 때문에 확장성이 가장 큰 약점으로 지적되는 것으로 알고 있습니다.

(3) J2EE
장점으로는 스크립팅에 사용하는 언어와 서버측에 사용하는 언어환경이 동일하다는 점입니다. 즉, 좋은 방식은 아니지만 원한다면 JSP에서 AWT/SWING을 포함한 모든 자바 라이브러리를 동일한 문법으로 사용 가능합니다.

또한 개발 프레임워크가 다양하다는 장점이 있습니다. 특히 Struts, Expresso, WebWork등의 오픈소스 MVC기반 프레임워크를 이용하면 표현계층과 비즈니스 계층을 완벽히 분리할 수 있습니다. 같은 코드 베이스로 여러 플랫폼과 어플리케이션 서버를 지원한다는 것도 큰 장점입니다.

단점은 무엇보다 learning curve가 급하다는 점입니다. JSP와 PHP, ASP의 차이가 별로 없다고 생각하는 사람들은 대부분 JSP/J2EE의 사상을 제대로 이해하지 못하는 경우가 많습니다. 이제까지 본 바로는 거의 90% 이상의 JSP프로그래머들이 ASP나 PHP를 자바로 문법만 옮긴 수준에서 코딩을 하더군요. 그런 경우 오히려 생산성이 떨어지고 디버그나 유지보수가 극도로 어려워지는 단점이 있습니다.

결론적으로 J2EE의 경우 적은 규모에서 큰 생산성을 기대할 수 있는 PHP와 반대로 큰규모에 유지보수와 안정성이 중시되는 환경으로 갈수록 장점을 보입니다.

그럼~

익명 사용자의 이미지

소프트웨어 공학에 의한 개발방법론으로 따지자 치면 참으로 할 말 많은 사람 많겠지만서도 결과적으로는 말장난에 불과한 경우가 많은 현실...

어차피 특정 방법론의 기초위에 튼튼하게 설계된 모델도 나중에는 또다시 신기술 제안서가 취미인 사람들에 의하여 훼손되기 십상... 어이없는 제안서들때문에 하청업체는 죽어나는데 이렇게 신기술 나올때마다 프레임웍을 뒤집어 제껴야 또 먹고 산다 하는 것이고... 정말 유지 보수가 잘 되서 추가 개발이 별로 안 나온다는 것은 해당 기업측에서는 좋은 일일지도 모르지만 업계에서는 차라리 악몽이다. 뭐 그 쪽도 공공이라면 남는
연구비도 써제껴야 되는데 서로 좋잖아?

결과적으로 남는 것은 신기술에 의한 잉여 개발비 떡칠. 그리고 남는것은 DB이기에 또 DB 마이그레이션 삽질...

요약하여. 내가 아는 수준이라면.

비스무리 방대한 업무의 지속적인 발생에 의한 노가다 : 자바

즉각적인 스태틱 페이지 뷰의 요청량이 많은 곳 : PHP

돈 없는 자 : PHP, 파이썬

뭐 MS 는 또 거론될테니. 일단 접고.

PHP 에 대해서 이런 말을 할 수 있죠.

소프트웨어 방법론에 의한 뽀대나는 설계의 프로젝도 멋지지만.

PHP 의 고효율 노가다로 그들의 뽀대 나는 결과물을

쫓아갈 수 있다. (쉽고 편안하게!)

munggo_의 이미지

python을 웹프로그램과 비교하는건 맞지 않다고 생각이 드는군요...

펄 또는 헤스킬등과 비교되어야 하지 않을까...하는...

임택균의 이미지

파이썬이 무엇인지 모르는 분 아닌가요?

일반 sh를 CGI인터페이스로 하여 웹프로그램도 가능합니다.
아직 한번도 Python을 이용하여 웹 프로그래밍을 하는 것에 관한
정보를 접하지 않았다면, 이 기회에 웹과 파이썬이 만나면
어떠한 효과가 나타나는지 당장 검색 엔진에서 한번 입력해 보는
것은 어떨까요? :-)
--
임택균.

임택균.

익명 사용자의 이미지

항상 맞는 말은 아닙니다. 특히 J2EE기반 프로젝트의 경우 단 한 줄의 SQL도 쓰지 않고 개발을 끝낼 수 있습니다. DB튜닝과 프로그래머의 역할을 분리하는게 대세 아닌가요?

최소한 자바 진영에서는 RDBMS와 객체지향적인 언어의 간극을 해소하는게 가장 큰 과제였습니다. JDO(ADO와는 완전히 성격이 다릅니다), CMP, O-R mapping등이 모두 그런 목표를 위해 발전되어왔지요...

강혜원의 이미지

저도 Making the Case for PHP at Yahoo!를 읽어보았는데요.
야후! 에서 JSP를 사용하지 않는것은
freebsd를 운영체제로 사용하고 있기 때문이라는군요.
(you can’t really use Java w/o threads.
Threads support on FreeBSD is not great. )

야후에서는 PHP를 최적화한 YSP라는것을 사용한다고 합니다.
Y! paradigm룰을 적용해서 PHP문법을 간단하고 명료하게
개발할수 있게 자기네들만의 가이드라인같은게 있는가 봅니다.

임택균의 이미지

Python이나, Zope는전혀 고려의 대상이 아닌가 보군요.
최근 apache에서도 mod_python을이용할 수 있는데, php와 같은 방식으로 웹 어플리케이션을
파이썬으로 작성할 수 있고, 파이썬이 갖고 있는 결합 특성으로 이런 저런 많은 라이브러리를
통합할 수 있는 특징이 있습니다.

자세한 검토는 하지 않더라도, Python이나 Zope를 위에 열거하신 것들에 추가해 주세요 :-)
--
임택균.

임택균.

익명 사용자의 이미지

제가 보기에는
자바에 밀리지 않으면서 훨씬 쉬운 Python!
웹서버라 하기에는 너무 많은 기능이 깔끔하고 훌륭하게 만들어져 있는 Zope!
가장 비전 있는 부분이라고 생각합니다.
한때는 이것을 열심히 공부해서 창업을 생각해 보았습니다.
실천은 안하고 있지만 이 생각은 여전히 유효합니다.

조프를 배워보세요!
(난 언제 배우나...)

siabard의 이미지

Python + Zope조합은 정말 강력합니다. 당연히 추가되어야할 것 같구..
전통의 Perl(^.^)과 객체지향언어중 하나인 Ruby도 들어갈 수 있을 것 같군요. 전형적인 CGI형태나 mod_ 류의 개발로 쓰이지만 방대한 라이브러리나 효용성은 Perl역시 훌륭한 편이고, eruby등으로 embedding script로 사용되는 Ruby역시 꽤나 강력한 모습을 보이니 말입니다.
다만 아직까지 만족할만한 어플리케이션 서버 레벨의 솔루션이 없다는 면에서 중대형 규모에서 밀리지않나하는 생각이 듭니다만 그러기에는 Perl이 뿌려놓은 씨앗이 너무 많고, 아직 걸음마이지만 Ruby의 참신함도 재미있습니다.
--
새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..

새로움을 느끼기에 삶은 즐겁다..
모험가 아돌 크리스틴을 꿈꾸며..
Sia..

cjh의 이미지

mod_perl용으로도 많은 웹 기반 라이브러리가 나와 있습니다.
perl을 쓰는것만으로도 기존 CPAN의 방대한 라이브러리를 모두
활용할 수 있다는 장점도 있고요. HTML::Mason 이나 Apache::ASP
등등의 mod_perl 기반 라이브러리는 단순히 perl을 쓴다는 것
이외에 템플리트나 추상화 계층을 위한 각종 기능을 제공하고
있는데 -

결정적으로 국내에서는 관심이 없는것 같군요. :P perl을 항상
cgi나 작성하는 구시대 유물 정도로만 취급하니...

http://perl.apache.org

--
익스펙토 페트로눔

임택균의 이미지

저도 답장을 올리면서 mod_perl에 대한 생각을 했습니다. 하지만,
제가 결정적으로 perl을 몰라요. :-(

요즘 Programming Perl을 구입해서 읽고 있는데,
재미가 없더군요. 결정적으로.

그래도 필요다는 생각을 몇년동안 해오고 있던 터라 틈틈히 시간
나는데로 책을 읽는데.......

그래서 Cookbook계열로 책을 바꾸고 읽어볼까 생각하고 있습니다.
--
임택균.

임택균.

cjh의 이미지

개인적인 경험으로는 perl을 단순 prodecural language에서
oo-style lanaguage로 바꾸어 쓰게 되는데까지 걸리는 노력이
상당합니다. 하지만 일단 이해하고 나니까 그 다음부터는 큰
무리가 없게 되더군요.

아마 perl을 배우는 대다수의 사람들이 간단한 프로그램 작성
이상으로 나아가지 못하는 이유가 그것이 아닐까 합니다.
python이나 ruby는 처음부터 oo-style programming을 많이
강제하면서 가르치는데 perl은 꼭 그럴 필요가 없으니까
쉬운 쪽부터 먼저 배우면 예전에 BASIC배우던 사람들은
C에 적응하기 힘든 것과 비슷한 사태가 벌어지는것 같습니다.

저도 perl이 "재밌다"고 깨달을때까지 몇년은 걸린것 같네요. :P

--
익스펙토 페트로눔

강혜원의 이미지

저도 Python과 Zope를 심각하게 고려해보았지만,
선택종류가 다양해서 어떤것을 선택해야 할지 모르겠습니다.
일단 그냥 CGI를 사용하는것은 고려 대상에서 제외하구요.
pyapache나 mod_python, zope, pmz, asp on python등등등... 같은 파이썬으로 개발해도
어플리케이션간 호환이 되지 않으니 저같은 초보 개발자는 혼란만 가중됩니다.

또한가지는 DB연동 프로그램같은것을 배포할때 문제가 생기는데요.
사용자가 일일이 db커넥션을 설치해주어야 하니 무척이나 불편합니다.
뭐, 좋은 선택이 없을까요?

김충길_의 이미지

고려대상에서 제외된 이유중에 하나가 Apache를 고려하지 않은게 아닐까요?

임택균의 이미지

추가로 :-)

제가 Java는 잘 모르지만, 확장성에서는 Python이 자바와 비교하여
전혀 밀리지 않는 강력한 개발 툴이라 생각합니다.
--
임택균.

임택균.

김충길_의 이미지

야후는 C/C++에서 옮기는거 같더이다..