kenu
2001-10-21 13:59:32
0
3526

제목:자바 이야기[긴글]


제목:자바 이야기[긴글]
올린이:강문희
올린날짜:2001-10-20

--------------------------------------------------------------------------------
간단하게 저의 주관적 지식을 말씀 드리겠습니다.
긴 글입니다. 지루하실수 있으며 저의 궤변일수 있습니다. 말이 이상한
부분들을 시간 관계로 나중에 수정하겠습니다.

1.개요
등장배경
-. 자바는 커피이름이라는 말이 있으며 처음 가전제품에 들어가는
ROM프로그램을 하는 분들이 창안했다고 합니다.
-. ROM프로그램은 칩에 write해서 H/W에 장착되기에 모델 또는 CPU별로
매번 프로그램을 해야 하기에 귀찮고 힘든일이며 또한 어셈블리 언어(요즘은 C)
로 해야 하기에 힘들었나 봅니다. C 언어도 시스템 dependent한 API라서
어셈블리 언어와 다를바가 없을 것입니다.
해결하려는 노력들
-. 이런 문제를 해결하려고 범용언어와 범용 Object code(기계어로 생각해도 됨)를
만들려는 측면에서 창안을 했다고 생각합니다.
-. 즉, 한가지 언어로 계속 프로그램하면 확장성(scability), portability가 좋은
output을 만들려는 노력이었다는 생각입니다.

2.언어적 측면
2.1 OOP언어
OOP(Object Oriented Program) 언어는 여러가지가 있지만 사실상 Pascal이나
smalltalk같은 언어가 OOP에 제일 좋다 하지만 기존에 만들어진 프로그램들을
모두 흡수는 못한다고 개발자들은 생각했을 것입니다.

2.2 C++언어
-. 언어중 OOP언어를 이용해야 하는데 그중 제일 좋은 언어가 무었이며
기존의 프로그램들을 흡수하기 좋은 것은 무었이고 개발자들이 쉽게 next
Language로 이전을 쉽게 할 수 있는 것을 찾게 되었습니다.
-. 여기서 고려된 것이 바로 C 언어에 개체지향 언어를 덥는(확장) 방법이
였습니다.
-. 이것이 C++언어 이였는데요. 개발자에게는 무리였다고 생각됩니다.
기존의 C resource는 흡수 했지만 C언어보다 더 어려운 언어를 만들어
냈다는 생각입니다.
-. 이때문에 system program에서는 C++언어를 포기했습니다.

2.3 java언어
-. C++에서 잘 안된점을 고려하면서 중간형(?)의 언어를 만들어 낸 것이라 생각합니다.
-. 또한 어떤 언어를 했었어도 개발자로 하여금 쉽게 습득 또는 이전할수
있게 언어 자체를 쉽게 만든것으로 보입니다.
-. 여기에 C++제작시 잘못한 것인 모든 기능을 가지고 그 위에 올라가는 개념보다는
언어 표현은 기존 개발자 습관상의 기능은 흡수하면서 많은 제약을 가미했다고
보입니다.
-. 또한 source및 sample들을 전세계로 계속 배포하면서 무료 또는 Open정책에
치중한 결과 2~3년만에 java언어에 익숙한 개발자를 무지많이 양산한 결과가
나온것입니다.
-. 언어라는 것은 주변에 아는 사람이 많으면 쉽게 퍼지기 마련이죠.

3.component적 측면
3.1 Beans
-. 처음 java언어는 GUI에 치중하여 CS(Client Server)의 Applicatoin(Applet과비교)에
치중하였습니다.
-. 이것이 Java Beans라는 개념을 만들고 어떤 window(X windows,Mac window)에서도
쉽게 만들려고 하였죠(지금은 Swing으로 발전). GUI component라고나 할까.
-. 하지만 GUI개발(델파이,Powerbuilder) tool의 기능에는 미치지 못했고
오히려 델파이 같은 tool이 Beans를 만들어주면 좋겠다고 생각했던것 같습니다.
-. 결국 GUI부분에 어떤 묶음이라는 것은 언어측면에서 지원되기 보다는
4GL같은 측면에서 접근되는 것이 더 좋은 것이란 결론을 필자는 느겼습니다.

3.2 EJB
-. 이런 와중에 GUI부분에 Web page가 나왔고 java를 web page에 넣어
해보려는 시도가 있었습니다.(Applet)
-. 결국 java와 WEB은 서로 관계가 없지만 둘을 이용하면 매우 좋은
결과를 가져오게 될수 있다는 것이였습니다.
-. 실제 C언어를 이용한 cgi보다는 php나 perl로 하는 것이 좋고 jsp를 이용하려는
것이 더 좋다는 것은 누구나 아는 사실이죠.
-. 이런 측면에서 Enterprize 프로그램 부분을 beans로 묶는 방식으로 뒤로 빼고
jsp를 이용하여 Web 디자인 변경에 영향을 받지않도록 한 것이 EJP개념이라
보입니다.
-. 하지만 일반 프로그래머들이 프로그램 목적,성격에 맞게 분류 및 설계가 쉽지 않기에
SUN에서는 spec만 제공하고 third vender(sybase:EA server, Websphier,Jrun)이
tool kit을 제공하기를 원했던것 같습니다.
-. 그렇지만 지금 개발자들은 tool제작 업체에 의존적이지 않은(유행 tool의존적)
개발을 하고 싶어하는 측면에서 보면 EJB took kit을 사용해야 하는 의문이 생기였습니다.
-. 이때 tomcat같은 jsp server를 이용하여 java beans로 빼면 쉽게 Enterprise Javabeas
를 만들수 있으며 tomcat대신 어떤 jsp server를 두어도 무리가 없을 것이라
생각되어 지금 EJB는 tomcat으로 구현하는 것이 좋다고 필자는 생각합니다.

3.3 Runtime Load
-. 이렇게 업무프로그램 부분을 javabeans로 빼는 것과 별개로
불필요한 연관성들을 배제한 독립성이 강한 component beans를 만들어서
언제든지 변경 및 대체에 용이한 부분으로 해 두면 확장성 측면에서 매우
좋은 효과가 있다고 생각됩니다.

4.OS 측면
4.1 SUN의 역할
-. SUN에서는 처음 창안한 가전업체에게서 java지적 소유권을 구입해서
WEB과 접목을 시도했습니다.
-. 이후에 partner ship 경영을 매우잘하고 CPU를 잘 만드는 SUN은 아예
JAVA cpu를 개발했죠(Pico java). 하지만 실패였습니다.
속도가 문제였고 java를 잘 모르는 사람이 많은데 CPU를 배포하면 누가
사서 쓸지 필자도 의심이 갔습니다.
-. 이후 SUN은 방향을 바꾸어서 java언어의 사용에 치중했으며 JDK(java development
kit) version up및 apache와의 연계에 치중했습니다.
-. 결과는 성공적이였습니다. java의 대중화로 IT에서는 제일 앞서가는 SUN이
되었고 java가 제일 잘 돌아가는 시스템이라는 평으로 작년에는 시스템도
매우 많이 팔았다고 합니다.

4.2 아파치와 SUN의 밀월관계
-. SUN은 jsp를 창안하여 jswdk(java server web development kit)을 가지고
테스트를 한것으로 보이는데요. 이것이 문제가 없다고 판단되자. 바로
아파치로 기술이전한 것으로 보입니다.(jswdk1.0.1이후 버젼없슴)
-. 이것을 받은 아파치는 자신들이 하던 servlet toolkit인 Jserv를 포기하고
tomcat으로 돌아섰는듯 보입니다.
-. 여기에 한술더 떠서 jboss라는 것을 만들어 EJB까지 하겠다는 전략인데요.
이것은 그리 잘 안되는 듯 보입니다.
-. 서버는 total solution으로 가면 위험한듯 보입니다. 여러 기술이 모여
하나의 기업 Application을 만들어 내는데 그중 잘하는 것들을 모으거나
일부를 교체하기 불가능하여 통째로 들어내야하는 불쌍사가 생길것을
우려하기 때문입니다.

5.효과
5.1 언어적 측면
언어가 매우 쉽기 때문에 개발자가 바뀌거나 다른 사람의
program들을 흡수하기가 매우 좋다는 것입니다.

5.2 Component적 측면
-. SI측면에서 업무는 대개 데이터와 함께 연결적이고 프로그램은 연결성과
독립성이 강한 데이터(Table)들을 고려하여 설계되고 구현되어야 하는데요.
-. 종종 언어가 벽으로 작용하여 연결성도 없고 독립성도 없는 SI output이
나오는 경우가 있는데요.
-. java의 EJB 부분과 jsp부분의 독립성은 위의 문제들을 cover할수 있다고
생각됩니다.
-. 이런 점도 물론 설계자 또는 개발자들이 미리 고려했을 때 이야기 입니다.

5.3 재사용적 측면
-. java Beans의 경우 다른 개발자 또는 업무 부분에서 개발된 것이라도
jsp부분에서 일부를 뽑아 사용가능하기 때문에 library성격을 가진
Application이라는 생각을 해도 될듯 합니다.

5.4 비용적 측면
-. 위의 모든 측면들은 회사입장에서는 모두 비용절감으로 결과가
나타나는 것입니다.


7.결론 및 향후 전개 방향예측
언어적 측면
-. 이제 java는 언어로서는 더 이상 좋아질 부분이 없어도 될것 으로 보입니다.
-. jdk같은데에서 제공되는 component 또는 import package가 강화될것으로
보입니다.
-. 또한 java언어를 이용하여 독립성이 강한 업무용 Component가 계속 나올것에
기대를 합니다.
-. 지금도 진행중이지만 XML,JSP의 연계 또는 합체등도 조심스럽게 생각해 볼수
있습니다.(tag-example). 이것은 spec측면 보다는 구현측면입니다.

기술 동향 및 사용자 측면
-. 향후에는 EJB Vender는 Vender대로 각 언어는 언어대로
다향성이 혼재하는 상황이 나타날 것이라 생각합니다.
-. 회사의 정보환경은 다양화되고 표준화 될것이기에 선행업체들을
좋은 방향으로 나아가겠지만 뒤 떨어지는 업체들은 있는대로
사용하려 할 것입니다.
-. 하지만 개발자나 개발업체들은 2가지 측면 모두 고려해야 살아
남을수 있을 것이라 생각됩니다.

-. 끝.-

from:
http://www.kmoon.net/cgi/language/java/seedetail?InsertTime=20011017-20:40:49&replyNum=3
0
  • 댓글 0

  • 로그인을 하시면 댓글을 등록할 수 있습니다.