제가 다니던 회사도 ERP를 만드는 회사였는데, .NET을 어디에 써야 할까에 대해서 그냥 고민 중이고 이렇다할 Project는 하고 있지 않습니다...
뭐... 아직 .NET에 대해서 많이 모르고 있는 것도 한 몫하겠구요...
그래도 공부하고 있는 사람들은 많지 않습니까??? 아닌가???
제 주위에도 기존에 MS tool을 사용하던 사람들은 거의가 다 .NET에 대해서 끄적이고 있는 거 같던데요... 뭐... 아직은 이렇다할 뭔가를 하는 것은 아니지만요...
하지만, .NET도 기존의 MS tool들처럼 널리 사용하게 되겠죠... 시간만 좀 지나면요... 그게 .NET의 우수성 때문이 아니더라도 시간의 힘 때문에 그렇게 되겠죠... 이제 새로 tool을 사는 사람들은 다 .NET tool을 사는 게 되니까요...
그러나 그것은 그냥 tool의 전환이지, .NET이 진정으로 원하는 것으로의 전환은 아니라고 봅니다...
사실, .NET 광고에서 하는 것을 보면 그게 지금 불가능한가??? 아니면, 그게 지금 구현하는 방법으로 그렇게 어려운가??? 라는 생각을 하게 됩니다...
그만큼 참신성은 좀 떨어진다고 봐야죠...(제 생각일 뿐입니다...)
물론, 많은 면에서 개선이 이루어 졌지만, 그것은 세상을 바꿀만한 뭔가는 아니라고 봅니다...
많이 쓰는 표현처럼,
It is a evolution, not a revolution...
이 되겠죠...
올해도 아마 WEB Service가 자리를 잡는데에는 좀 어렵지 않을까요???
개발진에서도 Web Service라는 것의 효용에 대해서 아직도 반신반의 하고 있는데요...
일단 .NET의 장점은 어떤 환경 언어에 제약이 없이 구현이 될 수가 있다는게 아주 큰 장점이 아닌가 생각을 합니다.
아직은 이러한게 전부 구현이 된건 아니지만...
빌의 사상이 모든 프로그램은 OS에 상관없이 돌아야한다는 것입니다.
그리고 이 .NET 환경은 이러한 것에 아주 부합하는 것이 될 것입니다.
물론 자바도 이러한걸 위해서 태어난 언어 이지만...
제가 개인적으로 사용해보고 느낀점은 지원이 아주 미비하고...
실제로 상용화 하기에는 모험이 너무 크고 앞으로도 개선을 해야 할 부분이 많은것 같습니다.
본래의 목적인 임베디드에선 어떤질 몰라도...
그리고 앞으로의 전망을 좀 더 밝혀 주는게...
이건 C#에서의 얘기지만...
VB에보다 기능이 많고... 개념은 VC에서 보다 한 층 나아진 기능(보안 관련)이 추가가 된것 같습니다.
이는 포인터류의 사용에서 좀 더 나아진 기능을 보여 주는것 같습니다.
그리고 이미 웹서비스는 적용이 확산이 되어가고 있고...
사용자들만 느끼지 못하는 것입니다.
이게 웹이라고 느끼면은 transparent한 장점을 버리게 되는것이라고 생각을 합니다.
이의 예로...
이미 Windows에서 기본 데스크탑환경이 탐색기(웹브라우저)로 구현이 되고 구동이 됩니다.
아마 XP에선 이러한 XP / ME 에선 이러한 냄새를 더 짙게 풍기는것 같네요.
앞으로의 준비할 점은 이러한 바탕을 기본으로 해서 더욱더 나은 서비스를 준비하고 개발해 나가는 일들과...
아주 고질적인 보안문제(영원한 숙제)도 같이 해결 되면 좋지 않을까?
<어떠한 역경에도 굴하지 않는 '하양 지훈'>
#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);
모험이 너무 큰것은 자바 엔터프라이즈 프로그래밍이 아니라, 지금에서야
시장에 나온 .NET입니다. 현재 엔터프라이즈 시장에서 잘 사용되고 있는
자바 대신 .NET을 이용하는 것이 모험이다 이겁니다.
엔터프라이즈 시장이라 하면은...
보통 사람은 제대로 구경도 못하고...
그리고 솔직히 이쪽은 돈 되니깐...
sun에서도 당연히 노칠 이유도 없을 겁니다.
그렇게 생각 해보면 이해도 가고...
근데... 이건 프로그래밍이라기 보다는 순전히 컴포넌트와 돈질 하는건 아닌지?
전 그런 생각이... 제가 이쪽은 잘 몰라서 그런데... 제가 보기엔 그렇더군요...
Quote:
또한 C#은 .NET자체가 멀티플랫폼을 지원하기 때문에, Visual C++과는
달리 인터페이스가 Visual C++만큼 자유롭지는 못할 것 입니다.
만약 windows전용 컴포넌트를 불러쓰게 된다면, 그 순간부터 해당
프로그램은 시스템 종속적으로 변할테니 말입니다.
님께서 어떤 의도로 말씀을 하신는지는 모르겠지만...
제가 아는 .NET은 .NET Framework 안에서 어떠한 랭귀지/OS에 구애 받지 않고 개발을 할 수 있는 걸로 알고 있습니다.
그리고 Windows용 컴포넌트가 있고 이걸로 사용하면 편하다면 당연히 그걸 사용해야 한다고 본인은 생각을 합니다.
뭐... 아직 완전히 WebService 스펙이 잡히고 완성된 단계가 아니라...
아직도 웹서비스는 표준을 잡기 위해 많은 논의가 되고 단계입니다.
뭐... 자바랑 따른 진영에서 어떤 식으로 진행이 되는진 알 수 없지만...
앞으로 삶이 편해질 수 있게만 해준다면...
어떤건 거부하고 어떤거만 사용할 필요 까진 없지 않나 생각을 합니다.
걍... 편한이 있는거 쓰면 되는 거지요.
걍... 불철주야... 좋은거 만드니라 고생하시는 개발자들 화이팅입니다.
<어떠한 역경에도 굴하지 않는 '하양 지훈'>
#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);
엔터프라이즈 시장이라 하면은...
보통 사람은 제대로 구경도 못하고...
그리고 솔직히 이쪽은 돈 되니깐...
sun에서도 당연히 노칠 이유도 없을 겁니다.
그렇게 생각 해보면 이해도 가고...
근데... 이건 프로그래밍이라기 보다는 순전히 컴포넌트와 돈질 하는건 아닌지?
전 그런 생각이... 제가 이쪽은 잘 몰라서 그런데... 제가 보기엔 그렇더군요...
아마도 .NET으로 엔터프라이즈 쪽 프로그래밍을 작성한다면, 개발도구부터
시작하여 돈질을 더 하게 되지 않을까 생각이 드는 군요.
서지훈 wrote:
님께서 어떤 의도로 말씀을 하신는지는 모르겠지만...
제가 아는 .NET은 .NET Framework 안에서 어떠한 랭귀지/OS에 구애 받지 않고 개발을 할 수 있는 걸로 알고 있습니다.
어떠한 랭귀지/OS를 구애받지 않고 개발을 한다는 것은 좋은 개념이라고
생각을 합니다만, 현재는 C#과 VB.NET에서만 가능하다고 알고 있습니다.
그리고 다른 언어도 CLR(Common Language Runtime)에 속하게 되었을
경우 가능하겠지요. 그런데 문제는 기존의 asp개발자들이 VB.NET을
바라보았을때 어떻게 생각하느냐는 것입니다.
님께서는 "편하다"라는 것을 강조하셨는데, 기존의 asp개발자들은
VB.NET을 아마도 편하게 생각하는 것보다는 "어렵다" 라고 생각하는
분들이 많을 것 같습니다.
즉, 공통된 언어를 사용한다고 해서 장점도 있지만, 단점도 있다는 것이지요.
그리고, JAVA로 만든 상용 클라이언트 프로그램도 많이 있습니다.
JBuilder나 투게더 등이 하나의 예이지요.
제대로 된 java프로그램도 버그는 드뭅니다. 반면에 C++로 만들었다고
해도 제대로 만들지 못하면 버그가 많겠지요.
저의 생각으로는 Swing프로그램보다는 JAVA로는 현재 서버쪽 프로그래밍을
많이 하기 때문에 제대로 된 Swing프로그램을 보기 어려운 것 뿐이지
Swing자체가 특별한 문제가 있다고는 생각하지 않습니다.
그리고, 서버쪽 프로그래밍도 WAS의 경우 공개용도 있으니, 공개용을
이용할 경우 비용절감효과도 있을 것입니다.
서버쪽 프로그래밍의 경우 규모가 작다면, Servlet, jsp등만 이용해도 되겠지요.
그리고, 멀티 랭귀지를 지원한다는 것이 나중에 실제로 그렇게 되었을 경우를
봐야지( 멀티 랭귀지를 이용하여 .NET을 자유롭게 짜게 되었을 때)
지금 그런이야기는 시기상조인것 같습니다.
.net 안망합미다..
MS에게는 100년동안..
5000천명의 프로그래머에게 연봉을
지급할 돈이 있으니까요,....
그 100년이 1000년이 될지는
아무도 모르죠...
예전에 닷넷에 개념에 대해 모두 헷깔려 할때..
MS관계자가 닷넷은 XML이다 라고 말해죠..
뭐 XML에 정확히 이해하고 있진 않치만...
그것만으로도 높이 사줄수 있다고 생각합미다..
그리고 지금의 C언어 보다 훨 좋은 환경이 될꺼라..
생각합미다.. 자바론 할수 없고 C로 짜짜니 부담되는
많은 분야에서 닷넷, 모노 프로젝트는.. 윈도우와
리눅스 양쪽 모두에서 성공 하리라 봅미다..
Java VM 상에 구현된 언어들은 많이 있습니다. Java 에는 1.0 부터 초창기 시절부터, JVM을 공통의 플랫폼화하고, Multi language 화 시키는데 많은 관심들이 있어왔습니다. 그러나 현재 보이는데로, 어느것도 Java Platform의 표준으로는 오르지 않았습니다.
(Multilanguage화는 위험성이 있습니다. 언어간의 표현력 차이도 있겠지만, 대표적인 예가 들어 A언어로 제작된 package 가 B언어로 제작된것에는 못 읽는 문제 따위 말이지요.)
.NET은 WebService를 지원해주기 위한 프레임워크가 되고요...
XML은 WebService를 사용하기 위한 필수(base) 랭귀지입니다.
WebService를 보면은 전부 XML을 사용을 하게됩니다.
DB / 프로그래밍 등등...
일반 사용자는 못느끼지만...-_-ㅋ
여기서 C#이나 VB등은 API 함수등을 이용해서 이런 XML을 자신이 원하는걸로 만들어 주는 일을 하게 될 것입니다.
그리고 자료의 입력은 XML로 받아서 파싱을 해서 원하는 결과를 얻어 낼테구...
그렇다구 WebService를 구현함에 있어서 꼭 XML을 알 필요는 없습니다.
알면 좋지만... API 단에서 이 모든걸 다 떨궈 주니깐...
그리고 다른 언어와 마찬가지로...
XML은 1996에 첫 draft가 나온이후로 98년에 ver 1.0이 나왔고...
아직도 계속 발전 중입니다.
<어떠한 역경에도 굴하지 않는 '하양 지훈'>
#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);
MS는 마치 현대처럼 밀어붙이기 식이 많았고 ,그 과정에서 불협화음이나 문제도 많이 생겼습니다. 그리고 아직까지 MS의 운영체제가 그다지 안정하다고 말 할 수 있는 사람은 별로 없을 겁니다. 심지어 패치하다가 오히려 뻗어버리는 경우도 발생할 수 있으니까요.
지금 Windows XP가 나온지 한참 되었지만, 우리나라도 win2000 쓰는 사람이 XP보다 많을겁니다. 심지어 외국은 더 참담합니다. win95/98도 수두룩 합니다. 이 상황에서 기존 OS를 대폭적으로 변경시킬 .NET프레임웍을 필요로 하지 않는 경우도 많습니다. 앞으로 차차 많이 변하겠지만, 해당 프레임웍을 정착시키는 것은 MS의 돈만으로는 힘들어 보입니다. 뭔가 시장에 임팩트를 줄 수 있어야 하겠죠. 제 생각엔 차라리 홈네트워킹이나 홈오토메이션 쪽에 MS가 더 군침을 흘리는것 같이 보입니다.
많은 OS 패밀리에서 각종 OS를 모두 지원하는 프레임웍은 힘들고 ,그렇다고 하나만 지원하자면 외면받을지도 모르고... MS는 현재 난감한 것이 아닐까요? 현재 OS매출액은 매년 떨어지고 XP는 거의 실패작이란 얘기까지 있습니다.
========================================
* The truth will set you free.
지금 Windows XP가 나온지 한참 되었지만, 우리나라도 win2000 쓰는 사람이 XP보다 많을겁니다. 심지어 외국은 더 참담합니다. win95/98도 수두룩 합니다. ... MS는 현재 난감한 것이 아닐까요? 현재 OS매출액은 매년 떨어지고 XP는 거의 실패작이란 얘기까지 있습니다.
이거 읽기 전이기는 한데 우리회사 웹 서버 중 하나(영화관 사이트)에서 OS별 통계를 내 보니 재미있더군요. 브라우저 이름 보고 그중 1-15등만 갖고 낸 거라 나머지는 기타 OS 또는 여기 나열된 OS 중 일부들입니다.
98 47%
XP 35%
2000 5%
----------------------
총 합계 87%
생각보다 2000이 적고 XP가 많습니다. 한국만의 특수한 경우일까요? 물론 98이 많은거야 당연하겠죠. 사이트 특성상 컴퓨터 고수가 이용할 만한 사이트가 아니기는 합니다만...
이런식의 비교는 Java 진영보다 .NET 진영쪽이 훨씬 더 많습니다 . 처음부터 .NET 은 Java 를 의식하여 대대적인 마켓팅공세및 기술적우위임을 주장하였고 이와관련된 공격적인 컬럼들이 상당수 존재합니다 . 사실상 이런비교는 무의미하고 소모적이라 보므로 굳이 이곳에 포스팅하지는 않습니다 . .NET 이 우월함을 주장하는 컬럼들을 보고싶으시다면 데브피아 C# 자유게시판을 참조하세요 .
Quote:
글을 읽다보니. XML이 마치 .NET전용인것처럼 쓴 글이 몇개 보여서
적어봅니다.
XML 과 XML WebService 는 비슷해보이지만 사실상 다르게 보아야되며 말씀하신것처럼 XML WebService 는 .NET 에서만 구현가능한것은 아닙니다 . Java 진영에서도 훌륭하게 이를 구현하고있으며 .NET 이전의 Win32 VB, VC++ 에서도 SOAP Toolkit 을 사용하여 훌륭히 구현할수 있습니다 .
하지만 현재 XML WebService 의 표준은 XML-RPC 를 제안했던 UserLand 가 제외되면서 Microsoft, IBM 이 주도하고 있으며 이와 관련해 Java 진영의 적극적인 참여도가 떨어지는것이 사실입니다 .
또한 .NET 은 XML WebService 를 위한 플랫폼이라고 불리어도 무방할만큼 이를 효율적으로 지원하고 있으며 Visual Studio .NET 에서 그 생산성을 극대화 시키고 있습니다 .
이에 대해서 양측진영 혹은 3rd Party (Borland 등의) 등의 의견이 분분할수 있으며 이에 대한 판단은 개발자 각자의 몫이라고 보여집니다 .
우선은 .NET 의 비지니스적인 가치를 언급하기 이전에 현재의 IT 경기침체와 XML WebService 시장의 개척둔화에 대해 먼저 곱씹어볼 필요가 있다고 생각됩니다 .
하지만 현재 XML WebService 의 표준은 XML-RPC 를 제안했던 UserLand 가 제외되면서 Microsoft, IBM 이 주도하고 있으며 이와 관련해 Java 진영의 적극적인 참여도가 떨어지는것이 사실입니다 .
한가지만....IBM 은 .net 보단 자바쪽이라고 생각하거든요
그리고 자바쪽 웹서비스 기술을 최초 구현한곳은 IBM 으로 알고 있습니다.
그런만큼 자바에서 웹서비스를 말할땐 IBM 을 빼놓고는 말할수 없습니다..
Microsoft, IBM 이 주도한다고 자바 진영의 적극적 참여도가 떨어진다고 하면 않되죠~~ :D
우선은 .NET 의 비지니스적인 가치를 언급하기 이전에 현재의 IT 경기침체와 XML WebService 시장의 개척둔화에 대해 먼저 곱씹어볼 필요가 있다고 생각됩니다
웹 서비스가 꼭 필요한 것인지 한번 고민해볼 필요는 있을 듯 하네요.
아무리 프레임워크가 좋고, 개발 툴이 좋아도, 실제 필드에서는 개발의 속도나 실제 벤치마킹의 결과가 그렇게 좋지 않고, 어차피 현재의 어플리케이션들이 XML 기반이 아니고, SOAP 기반도 아니면 새롭게 다 짜고 구조를 맞춰야만 하는데, 그게 과연 필요할런지..
그리고 그 처리속도와 각종 프레임워크를 올릴 때 들어가는 부하를 감당하려면 고가의 장비가 요구될텐데, 아마두 또 하드웨어 벤더들만 신날 거 같군요. 물론 SI 업체도 좋아들 하겠죠.
모든 SOAP 트래픽은 포트 80으로 전달되므로, 어떤 웹 서버가 있는 Internet에서든 SOAP를 사용할 수 있으며, 방화벽은 더 이상 문제가 되지 않습니다
위의 인용된 말을 보시면 80포트를 통하여 XML데이터를 전송한다는
말이 틀린말이 아니라는 것을 알 것입니다.. HTTP 프로토콜의 상위 스택이라고
표현하는 것이 좋겠다고 님께서는 말씀하셨지만. 저는 하위 스택이라고
말한적도 없습니다.
그리고 제가 언제. SOAP이 네트워크 프로토콜인 것은 맞는데, M$가 제안한 프로토콜이 아니라고 말을 한 적이 있나요?
그리고 SOAP프로토콜을 자바에서 지원한다고 말한 것은 자바언어로
개발할 수 있는 환경이 마련되었다는 말이었습니다.
Quote:
솔직 담백하게 이야기 하면 자바 언어는 SOAP이나 웹서비스 XML 을 지원하지 않는다고 보는 것이 옳은 관점일 듯 합니다. 모두다 자바를 이용해서 구현한 것들이지요. 자바 언어 자체가 지원하는 것은 아닙니다.
그리고 위의 말은 무슨말인지 잘 이햐가 안가는 군요. 그렇다면 Visual C++
에서 특정 게임 엔진을 구매하여 게임을 만들었다면. Visual C++은 게임을
만드는 것을 지원하지 않는 다는 말인가요?
자바 언어 자체가 중요한 것이 아니라, 자바언어로 그런것을 할 수 있는
환경이 구성되어있다는 것이 중요한 것 같습니다. 그리고 현재 JDK 1.4.x에는 XML에 관련된 API가 일부 포함되어 있습니다. SOAP이나 웹서비스에 관련된 API들이 JDK의 버젼이 높아지면서 포함될 수 있겠지요.
님께서 말한 대로 생각한다면. 기본적인 J2SDK에 포함되어 있지
않은 servlet, jsp는 JAVA에서 지원하지 않는다는 말과도 같을 것 같습니다만......
그렇다면 JAVA는 웹프로그래밍을 지원하지도 않겠군요.
님께서 말씀하신 것은 너무 비약시킨 것 같습니다.
물론, 저가 오해할 만하게 글을 썼다고도 생각이 듭니다만. 님 역시
너무 오버하시는 것 같습니다.
아무리 기사를 봐도 공식적인 표현은 없는 거 같군요. 특히나 신문기사에서 그것도 업계에 관련된 분이 쓰신 것으로 보이는데, 많은 곳에서 표준으로 진행하는 거하고, 데이터의 표준으로 정한 거하고는 다른 개념이죠. 즉 많은 곳에 XML 관련 표준안을 만들어서 "특히 XML이 하드웨어·플랫폼·언어·DB·프로토콜에 중립적인 중간 데이터로서 모든 애플리케이션에 활용될 수 있음을 이해해야 한다. "기 때문에 XML의 표준안을 진행하는 거하고, XML이 데이터의 표준이라고 이야기하는 것은 다른 범주의 이야기입니다.
Quote:
soap 프로토콜이 80포트로 정보를 주고 받는다고 한말은,
물론 80포트 이외의 포트에서도 정보를 주고 받을 수도 있겠지만.
방화벽등의 문제로 아마 80포트로 거의 고정적으로 이용될 것입니다.
모든 SOAP 트래픽은 포트 80으로 전달되므로, 어떤 웹 서버가 있는 Internet에서든 SOAP를 사용할 수 있으며, 방화벽은 더 이상 문제가 되지 않습니다
위의 인용된 말을 보시면 80포트를 통하여 XML데이터를 전송한다는
말이 틀린말이 아니라는 것을 알 것입니다.. HTTP 프로토콜의 상위 스택이라고 표현하는 것이 좋겠다고 님께서는 말씀하셨지만. 저는 하위 스택이라고 말한적도 없습니다.
우선 위에서 예로 든 기사가 왜 나오는지는 모르겠지만, 정확한 인용은 아닌 듯 하군요. 그 기사에서 왜 80 포트가 나온지에 대해서 빼고 인용한 부분만 보면 오해하기 좋을 듯 하군요.
"예컨대, HTTP는 포트 80을 할당 받고, File Transfer Protocol (FTP)는 포트 21을 할당 받습니다. 대부분의 방화벽은 특정 프로토콜에 의해 사용되는 포트로 전송된 모든 트래픽을 거부함으로써 그 프로토콜을 블록킹합니다. 일반적으로, 방화벽은 포트 80에 트래픽이 전송되는 것을 허용하도록 구성되어 있습니다. " 이렇게 보면 하나의 예로써, 그것도 모두가 다들 인식하기 쉽고 대부분 일상에서 사용되는 포트의 번호를 예시한 것은 아닌가요? 하나의 프로토콜이 하나의 포트에 할당될 수 있다는 원칙과 그 포트를 변경할 수 있다는 원칙이 전제된 상황에서 이야기가 되는 것 같은데, 아무래도 오독하신 것은 아닌지 ?
하위스택이라고 이야기해서 문제가 된다는 것이 아니라, HTTP 프로토콜을 이용해서 하나의 프로토콜을 얹었기 때문에 상위 프로토콜이라고 표현하는 것이 좋을 듯 하다는 의견이었는데, 80 포트라고 이야기하는 것보다는 그 표현이 개념상 좋겠다는 의견이었지요.
Quote:
그리고 제가 언제. SOAP이 네트워크 프로토콜인 것은 맞는데, M$가 제안한 프로토콜이 아니라고 말을 한 적이 있나요?
문제는 네트워크 프로토콜이 한두개가 아니라는 점이면, 나는 일반적인 관점에서 윗분 쓰신 글에서 SOAP 이라는 프로토콜을 M$에서 제안을 했고, 자바 진영에서는 특히 apache-axis 같은 프로젝트를 통해서 구현하고 있다는 표현을 한 것 뿐인데, 사실 관계를 밝히는데 M$가 등장하면 안되는 것인지, 아니면 뭐가 문제되는지 궁금하네요.. 그리고 참고로 HTTP를 얹어서 사용하는 프로토콜중에는 webdav 프로토콜이 있는데, 그것 또한 XML을 기본으로 사용하며, apache tomcat의 slide 프로젝트를 통해서 자바로 구현하고 있습니다.
Quote:
그리고 SOAP프로토콜을 자바에서 지원한다고 말한 것은 자바언어로
개발할 수 있는 환경이 마련되었다는 말이었습니다.
Quote:
솔직 담백하게 이야기 하면 자바 언어는 SOAP이나 웹서비스 XML 을 지원하지 않는다고 보는 것이 옳은 관점일 듯 합니다. 모두다 자바를 이용해서 구현한 것들이지요. 자바 언어 자체가 지원하는 것은 아닙니다.
그리고 위의 말은 무슨말인지 잘 이햐가 안가는 군요. 그렇다면 Visual C++
에서 특정 게임 엔진을 구매하여 게임을 만들었다면. Visual C++은 게임을
만드는 것을 지원하지 않는 다는 말인가요?
자바 언어 자체가 중요한 것이 아니라, 자바언어로 그런것을 할 수 있는
환경이 구성되어있다는 것이 중요한 것 같습니다. 그리고 현재 JDK 1.4.x에는 XML에 관련된 API가 일부 포함되어 있습니다. SOAP이나 웹서비스에 관련된 API들이 JDK의 버젼이 높아지면서 포함될 수 있겠지요.
님께서 말한 대로 생각한다면. 기본적인 J2SDK에 포함되어 있지
않은 servlet, jsp는 JAVA에서 지원하지 않는다는 말과도 같을 것 같습니다만......
그렇다면 JAVA는 웹프로그래밍을 지원하지도 않겠군요.
님께서 말씀하신 것은 너무 비약시킨 것 같습니다.
글쎄요. 비약의 문제가 아니라 윗분께서 쓰신 글에는 분명히 "또한, JAVA언어는 이러한 SOAP프로토콜을 이용하는 웹서비스를 지원합니다. " 라고 하는 대목에 시비(!)를 건 거 뿐입니다. 그냥 java 라는 큰 개념도 아닌 분명히 "JAVA언어" 라고 표현을 쓰신 것에 대해서 표현대로 한다면 시비를 건거 뿐이죠. 만약 C언어 자체가 게임 엔진을 지원한다면 누가 게임 엔진을 만들 것인지 궁금하군요. 문제는 JAVA 라고 하는 단어 자체가 가지는 개념의 범주를 얼마만한 크기로 잡을 것인가 하는 문제인데, 윗분께서는 스스로 "JAVA언어" 라고 했기때문에 시비 건 거 뿐입니다.
Quote:
물론, 저가 오해할 만하게 글을 썼다고도 생각이 듭니다만. 님 역시
너무 오버하시는 것 같습니다.
윗분께서 그렇게 생각하셨다면 어쩔 수 없는 일이고, 나는 별로 오버했다고 생각하지 않습니다. 잘못된 개념에 대해서 시비(!)를 걸었을 뿐 글에 대해서 맞았다/틀렸다를 논하는 것이 아니었고, 분명히 개념적으로 불명확한 것이 있어서 몇자 적었다고 이야기를 했을 뿐, 다른 이야기를 하지 않았는데, 너무 흥분하지 마시길..
개인적으로 오랫만에 본 "http://sunny.sarang.net" 글쓴이 URL이 반가운 마음이 있어서 크게 생각하지 않고 쓴 글인데, 내가 폐를 끼쳤다면 미안한 생각은 해야될 거 같네요. 문제가 된다면 이 글과, 위글을 관리자에게 이야기해서 삭제를 하셔도 무방합니다. 별로 큰 의미가 있는 글도 아니므로..
.NET이 망했다고 단정짓기에는 너무 이른생각이 아닐까 합니다.
저는 웹쪽은 전혀모르고 일반 응용프로그램만을 작성해서 더 그런지는 모르지만
아직까지 속단하기에는 이르다는 생각입니다.
한 회사에서 무언가를 기획하고 프로젝트로 시작했다는 것은 그것에 일말에 가능
성이라도 있기 때문입니다.
처음 MS사가 NT로 서버시장에 진출한다고했을 때는 누구도 성공하리라는 보장을
하지 않았었던걸로 알고 있습니다.
하지만 NT는 나름대로의 마켓팅과 영업력 그리고 기술지원등으로 어느정도 자리를
잡아버렸습니다.
이미 시장조사를하고 앞으로 소비자들이 원하는 것이 무엇인지를 내다보고 그에
맞는 사람들을 영입하면서 노력을 했기때문이라고 생각을 합니다.
사실 .NET은 새로운기술도 아니고 그렇다고 아주 노후화된 기술도 아닌것으로
알고있습니다. (제가 아직도 .NET의 정확한 개념조차 파악하지 못한상태이지만... :-))
그렇지만 앞으로 MS에서 생각하는 .NET의 세계는 올것이라는 것을 저는 어느
정도 확신합니다. 이건 정보가 어떻게 흘러왔고 앞으로 어떻게 흘러갈지를 곰곰
히 생각해보면 엇비슷하게 .NET의 개념과 일치한다는 것으로 생각할 수 있었
습니다.
사실 .NET의 개념은 최근 6~7년 이내에 국내에서도 비슷하게 적용을 시키려는
흔적들을 찾을 수 있었지만 결국 성공적이진 못했었죠.
하지만 앞으로 몇년후엔 이것이 일상생활에서 보편화될것임을 나름대로 확신하고
있습니다.
5~6년 전만해도 인터넷이 이렇게까지 대중화될것이라는 생각을 미쳐 못했었다는
것을 상기하면 말이죠.
MS사의 .NET이 성공하지 못할지라도 .NET의 개념은 앞으로 일상생활에 적용되어
분명히 사용되어질 것이라고 저는 감히 생각을 합니다.
앞에서 다른 분들이 잘 말씀해주셨지만 .net이라는 것은 아직 MS에서도 그 구체적인 개념을 완전히 잡지 못하고 있습니다. 지금 당장 '.net은 이거다!'라고 말할 수 있는 사람을 찾기 힘들 것입니다. 개인적으로 MS와 관련이 있는 프로그래머와 관리자들과 이야기를 해보고 심지어 MS 본사에 있는 한국인 직원과 이야기를 해봐도 .net의 개념을 100% 이해한 사람을 보지 못했습니다.(MS 본사의 한국인 직원의 말을 빌리면 .net 관련 팀에 있는 사람들도 .net이 뭐냐고 물으면 궁색한 답이 나올 때가 많다고 합니다.)
좋게 말하면 아직 발전할 여지가 많은 개념이지만 나쁘게 말하면 개발하는 사람들은 뭐가 뭔지 모르는 상태로 빌 형(?)이 만든 .net의 바다에서 표류해야 하는 상황에 놓이게 됩니다. 아직 .net이 단단한 반석위에 놓이지 못하다 보니 그 과정에서 .net의 정책이 몇 번 바뀌게 된게 아닐까 합니다.
.net이 당장 성공한다고, 실패한다고 장담하는 것은 이르지 않을까 합니다. 적어도 몇 년 더 두고봐야 할 사항을 지금 왈가왈부하는건 희망 사항 이상의 가치는 별로 없을 것으로 보입니다.
.NET 은 망해따?????
순전히 제 생각입니다만,
.NET 프로젝트는 실패한게 아닐까? 하는 생각을 해봅니다.
주변에 .NET 인력 구하는 곳도 별로 없고,...
.NET 공부하는 사람도 별로 없고,...
.NET 프로젝트로 진행되는 곳도 별로 없고.....
예전에 그래서 닷넷 공부하면 대접이 좋아질 것 같다는 생각도 했었지만,
지금은 그것도 아니고요,..
물론, 이제야 닷넷 서버가 출시되기 시작했지만...
뿌린 돈에 비해 너무나 형편없는 마케팅 효과와,
이전보다 자주 멈추는 데브피아 사이트를 보며,
.NET 에 대한 다른분들의 생각이 궁굼해서 적어봤습니다.
아직 단정짓긴 힘들지만...
저도 그런 생각이 듭니다.
저는 일부러 C#이니 닷넷 플랫폼을 공부하고 있지 않습니다만... (그냥 Visual C++ 6.0으로 프로젝트를 하기 때문에... ㅡ,.ㅡ) 대략 둘러보면 닷넷을 이용해서 뭔가를 의욕적으로 하는 곳을 거의 보지 못했습니다.
아직 .NET 개발도구를 설치하고 사용하는 것도 좀 무겁다는 느낌이 많구요.
자바가 초창기에 속도가 어쩌니, 안정성이 어쩌니 하며 '검증'을 위한 시간을 충분(?)히 가졌던 것처럼 닷넷도 그만큼의 시간이 흘러야 될 것 같습니다.
... Do It Now!!!
조금 시간이 걸릴 뿐 아닐까요??
사실, 꼭 .NET이 아니고서라도 거의 대부분의 Project들을 진행할 수 있지요...
지금까지처럼요...
제가 다니던 회사도 ERP를 만드는 회사였는데, .NET을 어디에 써야 할까에 대해서 그냥 고민 중이고 이렇다할 Project는 하고 있지 않습니다...
뭐... 아직 .NET에 대해서 많이 모르고 있는 것도 한 몫하겠구요...
그래도 공부하고 있는 사람들은 많지 않습니까??? 아닌가???
제 주위에도 기존에 MS tool을 사용하던 사람들은 거의가 다 .NET에 대해서 끄적이고 있는 거 같던데요... 뭐... 아직은 이렇다할 뭔가를 하는 것은 아니지만요...
하지만, .NET도 기존의 MS tool들처럼 널리 사용하게 되겠죠... 시간만 좀 지나면요... 그게 .NET의 우수성 때문이 아니더라도 시간의 힘 때문에 그렇게 되겠죠... 이제 새로 tool을 사는 사람들은 다 .NET tool을 사는 게 되니까요...
그러나 그것은 그냥 tool의 전환이지, .NET이 진정으로 원하는 것으로의 전환은 아니라고 봅니다...
사실, .NET 광고에서 하는 것을 보면 그게 지금 불가능한가??? 아니면, 그게 지금 구현하는 방법으로 그렇게 어려운가??? 라는 생각을 하게 됩니다...
그만큼 참신성은 좀 떨어진다고 봐야죠...(제 생각일 뿐입니다...)
물론, 많은 면에서 개선이 이루어 졌지만, 그것은 세상을 바꿀만한 뭔가는 아니라고 봅니다...
많이 쓰는 표현처럼,
It is a evolution, not a revolution...
이 되겠죠...
올해도 아마 WEB Service가 자리를 잡는데에는 좀 어렵지 않을까요???
개발진에서도 Web Service라는 것의 효용에 대해서 아직도 반신반의 하고 있는데요...
개인적으로는 아직 더 두고 봐야 하지 않을까 생각됩니다.그 이전에
개인적으로는 아직 더 두고 봐야 하지 않을까 생각됩니다.
그 이전에 현존하던 것들을 엎을 것 같은 닷넷 광고 만큼은 현실로 나타나지 않은 관계로 실패라고 생각하는 사람들이 있겠지만, 아직은 더 두고 봐야 하겠죠..
mono project도 같이 말이죠.. ;)
저 역시 위의 분과 같은 생각입니다.좀 더 두고 봐야 합니다.
저 역시 위의 분과 같은 생각입니다.
좀 더 두고 봐야 합니다.
요즘 많이 사용하는 자바 역시 안정화 및 기능향상에 약 5년이라는
시간이 걸렸습니다.
.NET도 그 정도의 시간이 지나봐야 알 수 있을것 같습니다.
결국은 자바와 .NET의 경쟁이 .NET이 어느정도 안정화 및
기능 향상이 이루어지는 동안 자바가 얼마나 발전하는가 하는
문제가 될 것으로 보입니다.
자바가 그동안 많이 발전해서 어느정도 .NET의 효용성을 감소시킨다면
자연적으로 .NET은 사라지겠지만, 그렇지 않으면 어느정도 경쟁체제가
될 가능성은 높습니다.
물론 현재 많은 소프트웨어/하드웨어 벤더들이 자바를 공식적으로
지원하고 있습니다만 자바의 가장 큰 문제점 중 하나는 클라이언트의
지원입니다.
현재 AWT/Swing등을 지원하지만 그것으로는 부족한 면이 있죠..
앞으로 클라이언트쪽으로 자바가 어떻게 지원하느냐에 따라서
향후 상황이 결정되지 않을까요....
그럼.
[하양] 앞으로의 가망성은 많지 않나 저는 개인적으로 생각을.
일단 .NET의 장점은 어떤 환경 언어에 제약이 없이 구현이 될 수가 있다는게 아주 큰 장점이 아닌가 생각을 합니다.
아직은 이러한게 전부 구현이 된건 아니지만...
빌의 사상이 모든 프로그램은 OS에 상관없이 돌아야한다는 것입니다.
그리고 이 .NET 환경은 이러한 것에 아주 부합하는 것이 될 것입니다.
물론 자바도 이러한걸 위해서 태어난 언어 이지만...
제가 개인적으로 사용해보고 느낀점은 지원이 아주 미비하고...
실제로 상용화 하기에는 모험이 너무 크고 앞으로도 개선을 해야 할 부분이 많은것 같습니다.
본래의 목적인 임베디드에선 어떤질 몰라도...
그리고 앞으로의 전망을 좀 더 밝혀 주는게...
이건 C#에서의 얘기지만...
VB에보다 기능이 많고... 개념은 VC에서 보다 한 층 나아진 기능(보안 관련)이 추가가 된것 같습니다.
이는 포인터류의 사용에서 좀 더 나아진 기능을 보여 주는것 같습니다.
그리고 이미 웹서비스는 적용이 확산이 되어가고 있고...
사용자들만 느끼지 못하는 것입니다.
이게 웹이라고 느끼면은 transparent한 장점을 버리게 되는것이라고 생각을 합니다.
이의 예로...
이미 Windows에서 기본 데스크탑환경이 탐색기(웹브라우저)로 구현이 되고 구동이 됩니다.
아마 XP에선 이러한 XP / ME 에선 이러한 냄새를 더 짙게 풍기는것 같네요.
앞으로의 준비할 점은 이러한 바탕을 기본으로 해서 더욱더 나은 서비스를 준비하고 개발해 나가는 일들과...
아주 고질적인 보안문제(영원한 숙제)도 같이 해결 되면 좋지 않을까?
<어떠한 역경에도 굴하지 않는 '하양 지훈'>
#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);
[quote]물론 자바도 이러한걸 위해서 태어난 언어 이지만... 제
자바는 현재, 많은 엔터프라이즈 시장에서 사용되고 있습니다.
탄생은 이동기기를 위하여 나왔다지만, 자바가 실제로 각광받는 부분은
서버쪽 프로그래밍입니다.
모험이 너무 큰것은 자바 엔터프라이즈 프로그래밍이 아니라, 지금에서야
시장에 나온 .NET입니다. 현재 엔터프라이즈 시장에서 잘 사용되고 있는
자바 대신 .NET을 이용하는 것이 모험이다 이겁니다.
자바를 이용하여 상용화 하기에 모험이 너무크고 개선을 해야할 부분이
많다는 것은 사실과 다르기에 글을 작성합니다.
또한 C#은 .NET자체가 멀티플랫폼을 지원하기 때문에, Visual C++과는
달리 인터페이스가 Visual C++만큼 자유롭지는 못할 것 입니다.
만약 windows전용 컴포넌트를 불러쓰게 된다면, 그 순간부터 해당
프로그램은 시스템 종속적으로 변할테니 말입니다.
그리고 웹서비스는 .NET만이 사용하는 것이 아닙니다. 이미 자바진영에서도
웹서비스를 하기 위한 여러가지 솔루션이 나온 상태이고 열심히 뛰고
있는 상태입니다.
----------
http://sunny.sarang.net
JAVA,Oracle,MySQL,Linux,PHP
[하양] 음...
엔터프라이즈 시장이라 하면은...
보통 사람은 제대로 구경도 못하고...
그리고 솔직히 이쪽은 돈 되니깐...
sun에서도 당연히 노칠 이유도 없을 겁니다.
그렇게 생각 해보면 이해도 가고...
근데... 이건 프로그래밍이라기 보다는 순전히 컴포넌트와 돈질 하는건 아닌지?
전 그런 생각이... 제가 이쪽은 잘 몰라서 그런데... 제가 보기엔 그렇더군요...
님께서 어떤 의도로 말씀을 하신는지는 모르겠지만...
제가 아는 .NET은 .NET Framework 안에서 어떠한 랭귀지/OS에 구애 받지 않고 개발을 할 수 있는 걸로 알고 있습니다.
그리고 Windows용 컴포넌트가 있고 이걸로 사용하면 편하다면 당연히 그걸 사용해야 한다고 본인은 생각을 합니다.
뭐... 아직 완전히 WebService 스펙이 잡히고 완성된 단계가 아니라...
아직도 웹서비스는 표준을 잡기 위해 많은 논의가 되고 단계입니다.
뭐... 자바랑 따른 진영에서 어떤 식으로 진행이 되는진 알 수 없지만...
앞으로 삶이 편해질 수 있게만 해준다면...
어떤건 거부하고 어떤거만 사용할 필요 까진 없지 않나 생각을 합니다.
걍... 편한이 있는거 쓰면 되는 거지요.
걍... 불철주야... 좋은거 만드니라 고생하시는 개발자들 화이팅입니다.
<어떠한 역경에도 굴하지 않는 '하양 지훈'>
#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);
Re: [하양] 음...
아마도 .NET으로 엔터프라이즈 쪽 프로그래밍을 작성한다면, 개발도구부터
시작하여 돈질을 더 하게 되지 않을까 생각이 드는 군요.
어떠한 랭귀지/OS를 구애받지 않고 개발을 한다는 것은 좋은 개념이라고
생각을 합니다만, 현재는 C#과 VB.NET에서만 가능하다고 알고 있습니다.
그리고 다른 언어도 CLR(Common Language Runtime)에 속하게 되었을
경우 가능하겠지요. 그런데 문제는 기존의 asp개발자들이 VB.NET을
바라보았을때 어떻게 생각하느냐는 것입니다.
님께서는 "편하다"라는 것을 강조하셨는데, 기존의 asp개발자들은
VB.NET을 아마도 편하게 생각하는 것보다는 "어렵다" 라고 생각하는
분들이 많을 것 같습니다.
즉, 공통된 언어를 사용한다고 해서 장점도 있지만, 단점도 있다는 것이지요.
그리고, JAVA로 만든 상용 클라이언트 프로그램도 많이 있습니다.
JBuilder나 투게더 등이 하나의 예이지요.
제대로 된 java프로그램도 버그는 드뭅니다. 반면에 C++로 만들었다고
해도 제대로 만들지 못하면 버그가 많겠지요.
저의 생각으로는 Swing프로그램보다는 JAVA로는 현재 서버쪽 프로그래밍을
많이 하기 때문에 제대로 된 Swing프로그램을 보기 어려운 것 뿐이지
Swing자체가 특별한 문제가 있다고는 생각하지 않습니다.
그리고, 서버쪽 프로그래밍도 WAS의 경우 공개용도 있으니, 공개용을
이용할 경우 비용절감효과도 있을 것입니다.
서버쪽 프로그래밍의 경우 규모가 작다면, Servlet, jsp등만 이용해도 되겠지요.
그리고, 멀티 랭귀지를 지원한다는 것이 나중에 실제로 그렇게 되었을 경우를
봐야지( 멀티 랭귀지를 이용하여 .NET을 자유롭게 짜게 되었을 때)
지금 그런이야기는 시기상조인것 같습니다.
중요한 것은 미래가 아니라 현재이겠지요.
그리고. .NET이 멀티랭귀지를 지원한다면 JAVA도 지원할 것 아니겠습니까? :-)
----------
http://sunny.sarang.net
JAVA,Oracle,MySQL,Linux,PHP
Re: [하양] 음...
사용자 입장에서는 쉽게 좋은거 쓰면 된다지만,
그것을 만드는 쪽에서의 개발은 전쟁과 다름 없습니다.
안그러면 좋은 자바 놔두고 C# 같은거 만든다고 헛짓하겠습니까?
그리고, 사용자 입장에서도 이것 저것 일관성없이 찝적대다가는,
아무것도 안되는 수가 많지요.
앞으로 IT쪽에서 살아 남을려면,
편한거 있는거 쓰는것이 아니라,
그 편한것을 만들어 내야 한다고 생각합니다. :)
Re: [하양] 음...
.NET 에선 J# 이라고 해서 자바 언어로 닷넷 프로그래밍을 할 수 있습니다.
VS.NET 2003 에서 폼디자이너까지 지원합니다.
http://msdn.microsoft.com/visualj/
현재 계속해서 기존 언어가 닷넷용으로 개발되어 발표되고 있지만 어차피 필드에서 써먹을 수 있는건 C#, VB.NET, MC++ 이고, 나머지는 구색 맞추기 용이 아닐까 싶습니다. 멀티랭귀지 그 자체만으로 대단하긴 합니다만..^^;;
닷넷이 망하던 그렇지 않던 간에 분명한 것을 현재 윈도OS에 닷넷 프래임웍이 내장되고 있고, 손쉽게 접할 수 있는 훌륭한(?) 개발툴(VS.NET 2003, 볼랜드 C# Builder)들이 나오고, 앞으로 나올 것이고, 현재 보다 많은 곳에서 사용될 것이란 얘기죠.
제가 생각하기론....net용 언어의 개수와JVM 에서 돌아가
제가 생각하기론...
.net용 언어의 개수와
JVM 에서 돌아가는 언어의 개수는 비슷하거나
JAVA 쪽이 많을껄로 생각합니다...
몰론...자바가 나온지 꽤 됬기 때문에
직접 비교 는 좀 그렇지만...
단순 멀티 랭귀지로만 따진다면...자바도 그렇게 뒤지지만은 않는걸로 생각합니다
Java이외에 JVM 코드를 생성하는 언어가 어떤 것이 있나요?
Java이외에 JVM 코드를 생성하는 언어가 어떤 것이 있나요?
--
익스펙토 페트로눔
.net
.net 안망합미다..
MS에게는 100년동안..
5000천명의 프로그래머에게 연봉을
지급할 돈이 있으니까요,....
그 100년이 1000년이 될지는
아무도 모르죠...
예전에 닷넷에 개념에 대해 모두 헷깔려 할때..
MS관계자가 닷넷은 XML이다 라고 말해죠..
뭐 XML에 정확히 이해하고 있진 않치만...
그것만으로도 높이 사줄수 있다고 생각합미다..
그리고 지금의 C언어 보다 훨 좋은 환경이 될꺼라..
생각합미다.. 자바론 할수 없고 C로 짜짜니 부담되는
많은 분야에서 닷넷, 모노 프로젝트는.. 윈도우와
리눅스 양쪽 모두에서 성공 하리라 봅미다..
============================================================
선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-
============================================================
Re: Programming Languages for the Java Virtual Machine
말씀에 보충 설명일 수 있겠습니다.
Programming Language for the Java Virtual Machine
http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
Java VM 상에 구현된 언어들은 많이 있습니다. Java 에는 1.0 부터 초창기 시절부터, JVM을 공통의 플랫폼화하고, Multi language 화 시키는데 많은 관심들이 있어왔습니다. 그러나 현재 보이는데로, 어느것도 Java Platform의 표준으로는 오르지 않았습니다.
(Multilanguage화는 위험성이 있습니다. 언어간의 표현력 차이도 있겠지만, 대표적인 예가 들어 A언어로 제작된 package 가 B언어로 제작된것에는 못 읽는 문제 따위 말이지요.)
실제로 쓰이는가? 예, 쓰이는 경우가 있습니다. 국내 기업은 직접 보지 못했지만요. 작년 2002년 5월 Javaworld에 Java Scripting language 에 관한 기사가 실렸습니다.
http://www.javaworld.com/javaworld/jw-04-2002/jw-0405-scripts.html
JRE 1.5에서 reflection 과 메모리 모델 쪽의 발전을 기대합니다. generic도 (MS에서 주로 공격 대상으로 삼지요. reflection 속도차 20배 ;; 그때가 1.4 나오기 전이라, 지금은 모르겠네요.)
4회 Java Conference 한 섹션에서 이 부분을 시간 부족으로 발표 안된것이 아깝습니다. (JVM상의 Script Language)
Script 언어인 Jython 으로 동적으로 Swing 창을 가지고 놀아보면, Java를 컴파일하고 실행하는 언어로 알고 있는 분들에게 충격으로 다가올지 모르겠다는 친구의 말을 생각 해봅니다.
.NET
닷컴버블과함께 현재의 IT 경기가 침체기를 걷고있다는 사실을 주지해야 할것입니다 . WebService 는 분명 훌륭한 개념임에는 틀림없지만 아직 비지니스모델로서의 가치는 초기단계라고 볼수있습니다 .
.NET 은 처음부터 XML WebService 를 지향하였고 .NET 이 활성화되려면 이 WebService 에 대한 수요가 창출되어야 할것입니다 .
Windows 기반의 서버하면 항상 불거져 나오는 "안정성" 문제또한 .NET CLR 을 Windows 2000 에 장착하는 형태에 개발자나 기업들이 큰 불안을 느꼈던것도 사실입니다 .
Windows 2003 이 얼마전에 미국에서 대대적인 런칭행사를 가졌습니다 . 한국에서도 5월13일 런칭행사를 가지죠 ?
.NET CLR 을 OS 에 장착한 최초의 운영체제이며 Microsoft 의 .NET 정책에 포석역활을 하는 중요한 제품입니다 . 발매시기를 1년이나 늦출만큼 정성을 들여왔으며 베타테스트기간동안에도 좋은 평가를 받아왔습니다 .
닷컴버블이 걷히고 서서히 닷컴의 부흥기를 맞이하는 요즈음, 기업체들에게 Windows 2003 은 매력적인 제품임에 틀림없습니다 .
하지만 .NET 베타1때부터 개발자들에게 장미빛 환상을 심어온 MS 의 전략은 경계해야 될 부분이라 생각합니다 .
물론 여기계신분들이라면 진짜 장미빛이라해도 아니라고 거부하시겠지만요 ;)
--
Sang-Kil Park
[하양] .NET과 WebService와 XML
.NET은 WebService를 지원해주기 위한 프레임워크가 되고요...
XML은 WebService를 사용하기 위한 필수(base) 랭귀지입니다.
WebService를 보면은 전부 XML을 사용을 하게됩니다.
DB / 프로그래밍 등등...
일반 사용자는 못느끼지만...-_-ㅋ
여기서 C#이나 VB등은 API 함수등을 이용해서 이런 XML을 자신이 원하는걸로 만들어 주는 일을 하게 될 것입니다.
그리고 자료의 입력은 XML로 받아서 파싱을 해서 원하는 결과를 얻어 낼테구...
그렇다구 WebService를 구현함에 있어서 꼭 XML을 알 필요는 없습니다.
알면 좋지만... API 단에서 이 모든걸 다 떨궈 주니깐...
그리고 다른 언어와 마찬가지로...
XML은 1996에 첫 draft가 나온이후로 98년에 ver 1.0이 나왔고...
아직도 계속 발전 중입니다.
<어떠한 역경에도 굴하지 않는 '하양 지훈'>
#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);
MS의 전략은 좀더 조심스럽게 진행해야 한다고 생각합니다.MS는
MS의 전략은 좀더 조심스럽게 진행해야 한다고 생각합니다.
MS는 마치 현대처럼 밀어붙이기 식이 많았고 ,그 과정에서 불협화음이나 문제도 많이 생겼습니다. 그리고 아직까지 MS의 운영체제가 그다지 안정하다고 말 할 수 있는 사람은 별로 없을 겁니다. 심지어 패치하다가 오히려 뻗어버리는 경우도 발생할 수 있으니까요.
지금 Windows XP가 나온지 한참 되었지만, 우리나라도 win2000 쓰는 사람이 XP보다 많을겁니다. 심지어 외국은 더 참담합니다. win95/98도 수두룩 합니다. 이 상황에서 기존 OS를 대폭적으로 변경시킬 .NET프레임웍을 필요로 하지 않는 경우도 많습니다. 앞으로 차차 많이 변하겠지만, 해당 프레임웍을 정착시키는 것은 MS의 돈만으로는 힘들어 보입니다. 뭔가 시장에 임팩트를 줄 수 있어야 하겠죠. 제 생각엔 차라리 홈네트워킹이나 홈오토메이션 쪽에 MS가 더 군침을 흘리는것 같이 보입니다.
많은 OS 패밀리에서 각종 OS를 모두 지원하는 프레임웍은 힘들고 ,그렇다고 하나만 지원하자면 외면받을지도 모르고... MS는 현재 난감한 것이 아닐까요? 현재 OS매출액은 매년 떨어지고 XP는 거의 실패작이란 얘기까지 있습니다.
========================================
* The truth will set you free.
XML과 자바.
XML는 데이터의 표준입니다.
자바는 시스템 비종속적인 언어입니다.
데이터의 표준과 시스템 비종속적인 언어가 만나면서, 시너지 효과가
발생합니다. 어디서든 동작할 수 있는 프로그램이 탄생할 수 있는 것이지요.
자바진영에서는 (다른곳도 마찬가지지만) XML을 사용하기 위하여
많은 노력을 하고 있고, 현재 많은 곳에서 사용되어지고 있습니다.
환경설정파일부터, 데이터, 네트워크 프로토콜로도 말입니다.
이 네트워크 프로토콜을 SOAP이라고 말을 하는데, 80포트를 통하여
XML데이터를 주고 받게 됩니다. 이러한 SOAP프로토콜을 이용한
프로그래밍을 이미 JAVA는 지원하고 있습니다.
또한, JAVA언어는 이러한 SOAP프로토콜을 이용하는 웹서비스를
지원합니다.
즉, XML이라는 것은 데이터의 표준으로써 .NET에서만 사용되는 것도
아니고 .NET에서만 중요하게 바라보는 것이 아닙니다.
글을 읽다보니. XML이 마치 .NET전용인것처럼 쓴 글이 몇개 보여서
적어봅니다.
----------
http://sunny.sarang.net
JAVA,Oracle,MySQL,Linux,PHP
JAVA가 .NET보다 좋은 100가지 이유.
자바가 .NET보다 좋은 100가지 이유
http://freeroller.net/page/ceperez/20030129#finally_looks_like_we_have
----------
http://sunny.sarang.net
JAVA,Oracle,MySQL,Linux,PHP
[quote="sunyzero"]지금 Windows XP가 나온지 한참
이거 읽기 전이기는 한데 우리회사 웹 서버 중 하나(영화관 사이트)에서 OS별 통계를 내 보니 재미있더군요. 브라우저 이름 보고 그중 1-15등만 갖고 낸 거라 나머지는 기타 OS 또는 여기 나열된 OS 중 일부들입니다.
98 47%
XP 35%
2000 5%
----------------------
총 합계 87%
생각보다 2000이 적고 XP가 많습니다. 한국만의 특수한 경우일까요? 물론 98이 많은거야 당연하겠죠. 사이트 특성상 컴퓨터 고수가 이용할 만한 사이트가 아니기는 합니다만...
--
익스펙토 페트로눔
.NET, SOAP
이런식의 비교는 Java 진영보다 .NET 진영쪽이 훨씬 더 많습니다 . 처음부터 .NET 은 Java 를 의식하여 대대적인 마켓팅공세및 기술적우위임을 주장하였고 이와관련된 공격적인 컬럼들이 상당수 존재합니다 . 사실상 이런비교는 무의미하고 소모적이라 보므로 굳이 이곳에 포스팅하지는 않습니다 . .NET 이 우월함을 주장하는 컬럼들을 보고싶으시다면 데브피아 C# 자유게시판을 참조하세요 .
XML 과 XML WebService 는 비슷해보이지만 사실상 다르게 보아야되며 말씀하신것처럼 XML WebService 는 .NET 에서만 구현가능한것은 아닙니다 . Java 진영에서도 훌륭하게 이를 구현하고있으며 .NET 이전의 Win32 VB, VC++ 에서도 SOAP Toolkit 을 사용하여 훌륭히 구현할수 있습니다 .
하지만 현재 XML WebService 의 표준은 XML-RPC 를 제안했던 UserLand 가 제외되면서 Microsoft, IBM 이 주도하고 있으며 이와 관련해 Java 진영의 적극적인 참여도가 떨어지는것이 사실입니다 .
또한 .NET 은 XML WebService 를 위한 플랫폼이라고 불리어도 무방할만큼 이를 효율적으로 지원하고 있으며 Visual Studio .NET 에서 그 생산성을 극대화 시키고 있습니다 .
이에 대해서 양측진영 혹은 3rd Party (Borland 등의) 등의 의견이 분분할수 있으며 이에 대한 판단은 개발자 각자의 몫이라고 보여집니다 .
우선은 .NET 의 비지니스적인 가치를 언급하기 이전에 현재의 IT 경기침체와 XML WebService 시장의 개척둔화에 대해 먼저 곱씹어볼 필요가 있다고 생각됩니다 .
--
Sang-Kil Park
Re: .NET, SOAP
한가지만....IBM 은 .net 보단 자바쪽이라고 생각하거든요
그리고 자바쪽 웹서비스 기술을 최초 구현한곳은 IBM 으로 알고 있습니다.
그런만큼 자바에서 웹서비스를 말할땐 IBM 을 빼놓고는 말할수 없습니다..
Microsoft, IBM 이 주도한다고 자바 진영의 적극적 참여도가 떨어진다고 하면 않되죠~~ :D
.net의 아키텍쳐라는 관점에서 봤을 때
쉽게 단정하기는 힘든 문제인 듯 합니다.
.net 에서 웹 쪽의 환경만을 논하자면,
기존의 IIS 가 어플리케이션 서버였지만,
실제로는 어플리케인션 서버에 어플리케인션을 등록하기
힘들고, 컴포넌트를 등록하면 리부팅하는 단점도 있었지요.
최근에 출시 예정인 윈도우 2003 을 보니, 여러가지 측면에서
엄청난 노력을 하는 듯 하더군요.
어플리케이션 서버 이상의 것을 담으려는 듯 합니다.
EJB 수준은 되지 않을까 예상되던데..
.net을 순수하게 언어적인 관점에서 본다면야,
지금까지 가장 좋다고 이야기한 언어가 성공해서
대중적으로 쓰이는 경우는 별로 없었던 거에 비추어 볼때
별로 가치 없는 이야기인 듯 합니다.
실제로 .net 이라고하는 프레임워크가 올라가서 동작하게 될
주요한 플랫폼인 IIS5 또는 IIS6의 구조 또는 아키텍쳐에서 봤을 때,
괜찮은 구조라고 생각이 드는데..
아파치에서 데이터베이스 커낵션 풀링이나,
컨탠츠 캐싱들을 하려고 했을 때,
아파치 API에 맞춰서 개발을 해야 하지만,
.net 에서는 어느 걸로 개발을 해도 되고,
거기다가 디자인 패턴을 이용해서 쉽게 개발의 개념을 잡을 수도 있고,
m$가 망했어야 한다면 아맏 도스 시절에,
그리고 윈도 3.1 이럴 때 망해겠죠.. ~~
암튼 졸라리 큰 사고 치지 않는한 계속 될 듯 하군요.
그리고 .net 도 많은 발전이 있을 거라는 느낌도 들고요..
그런 관점에서 보면 긍정적인 관망에 한표입니다.
지금은 시기상조.
.NET은 아직 현재의 컴퓨팅 환경이나 여러가지 여건들이 갖추지지 못해서
아직까지는 허덕이고 있지만.. 시간이 흐르면 우리들이 MS-DOS를
사용하다가 요즘은 Windows 를 사용하는것처럼 변할지도 모릅니다.
중요한거는 .NET이나 Java나 다 각각 고유한 특색이 있습니다.
그러니 그 특색을 살려서 프로젝트나 프로그래밍 공부를 하시는것이
도 현명할것 같군요.
Re: XML과 자바.
흠. SOAP이 네트워크 프로토콜인 것은 많는데, M$가 제안한 프로토콜 아닌가요? 제대로 표현한다면, SOAP 프로토콜을 java로 implement 했다고 해야 옳은 표현일 듯 합니다. 아마두 그 것을 구현한 것이 apache-axis 가 아닌가 싶네요..
그리고 80포트라는 말보다는 HTTP 프로토콜의 상위 스택이라는 표현이 좋을 듯 하군요. 포트야 바꾸기 나름이고, SOAP이 아마도 HTTP 프로토콜에서 POST 를 이용해서 XML을 주고 받는 개념이 아닌지?
솔직 담백하게 이야기 하면 자바 언어는 SOAP이나 웹서비스 XML 을 지원하지 않는다고 보는 것이 옳은 관점일 듯 합니다. 현재 나온 것들은 모두다 자바를 이용해서 구현한 것들이지요. 자바 언어 자체가 지원하는 것은 아닙니다.
그리고 XML이 데이터의 표준이라고 했는데, 어디서 표준으로 정했는지 궁금하군요? 그렇게 받아들이면서 그렇게 쓰자고 하는 것이 아닌지요? 아무래도 의미상 묘한 느낌이 드는 군요.. 한편으로는 XML의 광범위한 표준화 작업이 바벨탑을 만드는 느낌까지 드는데..
글을 읽다 보니 개념적으로 조금 불명확한 것이 있어서 몇자 적어봅니다.
Re: .NET, SOAP
웹 서비스가 꼭 필요한 것인지 한번 고민해볼 필요는 있을 듯 하네요.
아무리 프레임워크가 좋고, 개발 툴이 좋아도, 실제 필드에서는 개발의 속도나 실제 벤치마킹의 결과가 그렇게 좋지 않고, 어차피 현재의 어플리케이션들이 XML 기반이 아니고, SOAP 기반도 아니면 새롭게 다 짜고 구조를 맞춰야만 하는데, 그게 과연 필요할런지..
그리고 그 처리속도와 각종 프레임워크를 올릴 때 들어가는 부하를 감당하려면 고가의 장비가 요구될텐데, 아마두 또 하드웨어 벤더들만 신날 거 같군요. 물론 SI 업체도 좋아들 하겠죠.
Re: XML과 자바.
XML이 데이터의 표준이라고 말한 것은 아직 그렇게 누군가 정하지는
않았다고 하더래도, 많은 곳에서 표준으로 진행해 나가고 있기 때문에
그렇게 표현한 것입니다.
참고로 아래의 기사를 참고하세요.
http://www.kware21.com/nb3/read.asp?seq=24&req=0&req_step=0&search_kind=&find_str=&cur_page=5&jump_page=1
soap 프로토콜이 80포트로 정보를 주고 받는다고 한말은,
물론 80포트 이외의 포트에서도 정보를 주고 받을 수도 있겠지만.
방화벽등의 문제로 아마 80포트로 거의 고정적으로 이용될 것입니다.
http://www.microsoft.com/korea/msdn/workshop/xml/general/SOAP_White_Paper.asp
mcrosoft의 SOAP white_paper를 보시기 바랍니다.
위의 인용된 말을 보시면 80포트를 통하여 XML데이터를 전송한다는
말이 틀린말이 아니라는 것을 알 것입니다.. HTTP 프로토콜의 상위 스택이라고
표현하는 것이 좋겠다고 님께서는 말씀하셨지만. 저는 하위 스택이라고
말한적도 없습니다.
그리고 제가 언제. SOAP이 네트워크 프로토콜인 것은 맞는데, M$가 제안한 프로토콜이 아니라고 말을 한 적이 있나요?
그리고 SOAP프로토콜을 자바에서 지원한다고 말한 것은 자바언어로
개발할 수 있는 환경이 마련되었다는 말이었습니다.
그리고 위의 말은 무슨말인지 잘 이햐가 안가는 군요. 그렇다면 Visual C++
에서 특정 게임 엔진을 구매하여 게임을 만들었다면. Visual C++은 게임을
만드는 것을 지원하지 않는 다는 말인가요?
자바 언어 자체가 중요한 것이 아니라, 자바언어로 그런것을 할 수 있는
환경이 구성되어있다는 것이 중요한 것 같습니다. 그리고 현재 JDK 1.4.x에는 XML에 관련된 API가 일부 포함되어 있습니다. SOAP이나 웹서비스에 관련된 API들이 JDK의 버젼이 높아지면서 포함될 수 있겠지요.
님께서 말한 대로 생각한다면. 기본적인 J2SDK에 포함되어 있지
않은 servlet, jsp는 JAVA에서 지원하지 않는다는 말과도 같을 것 같습니다만......
그렇다면 JAVA는 웹프로그래밍을 지원하지도 않겠군요.
님께서 말씀하신 것은 너무 비약시킨 것 같습니다.
물론, 저가 오해할 만하게 글을 썼다고도 생각이 듭니다만. 님 역시
너무 오버하시는 것 같습니다.
----------
http://sunny.sarang.net
JAVA,Oracle,MySQL,Linux,PHP
Re: XML과 자바.
아무리 기사를 봐도 공식적인 표현은 없는 거 같군요. 특히나 신문기사에서 그것도 업계에 관련된 분이 쓰신 것으로 보이는데, 많은 곳에서 표준으로 진행하는 거하고, 데이터의 표준으로 정한 거하고는 다른 개념이죠. 즉 많은 곳에 XML 관련 표준안을 만들어서 "특히 XML이 하드웨어·플랫폼·언어·DB·프로토콜에 중립적인 중간 데이터로서 모든 애플리케이션에 활용될 수 있음을 이해해야 한다. "기 때문에 XML의 표준안을 진행하는 거하고, XML이 데이터의 표준이라고 이야기하는 것은 다른 범주의 이야기입니다.
우선 위에서 예로 든 기사가 왜 나오는지는 모르겠지만, 정확한 인용은 아닌 듯 하군요. 그 기사에서 왜 80 포트가 나온지에 대해서 빼고 인용한 부분만 보면 오해하기 좋을 듯 하군요.
"예컨대, HTTP는 포트 80을 할당 받고, File Transfer Protocol (FTP)는 포트 21을 할당 받습니다. 대부분의 방화벽은 특정 프로토콜에 의해 사용되는 포트로 전송된 모든 트래픽을 거부함으로써 그 프로토콜을 블록킹합니다. 일반적으로, 방화벽은 포트 80에 트래픽이 전송되는 것을 허용하도록 구성되어 있습니다. " 이렇게 보면 하나의 예로써, 그것도 모두가 다들 인식하기 쉽고 대부분 일상에서 사용되는 포트의 번호를 예시한 것은 아닌가요? 하나의 프로토콜이 하나의 포트에 할당될 수 있다는 원칙과 그 포트를 변경할 수 있다는 원칙이 전제된 상황에서 이야기가 되는 것 같은데, 아무래도 오독하신 것은 아닌지 ?
하위스택이라고 이야기해서 문제가 된다는 것이 아니라, HTTP 프로토콜을 이용해서 하나의 프로토콜을 얹었기 때문에 상위 프로토콜이라고 표현하는 것이 좋을 듯 하다는 의견이었는데, 80 포트라고 이야기하는 것보다는 그 표현이 개념상 좋겠다는 의견이었지요.
문제는 네트워크 프로토콜이 한두개가 아니라는 점이면, 나는 일반적인 관점에서 윗분 쓰신 글에서 SOAP 이라는 프로토콜을 M$에서 제안을 했고, 자바 진영에서는 특히 apache-axis 같은 프로젝트를 통해서 구현하고 있다는 표현을 한 것 뿐인데, 사실 관계를 밝히는데 M$가 등장하면 안되는 것인지, 아니면 뭐가 문제되는지 궁금하네요.. 그리고 참고로 HTTP를 얹어서 사용하는 프로토콜중에는 webdav 프로토콜이 있는데, 그것 또한 XML을 기본으로 사용하며, apache tomcat의 slide 프로젝트를 통해서 자바로 구현하고 있습니다.
글쎄요. 비약의 문제가 아니라 윗분께서 쓰신 글에는 분명히 "또한, JAVA언어는 이러한 SOAP프로토콜을 이용하는 웹서비스를 지원합니다. " 라고 하는 대목에 시비(!)를 건 거 뿐입니다. 그냥 java 라는 큰 개념도 아닌 분명히 "JAVA언어" 라고 표현을 쓰신 것에 대해서 표현대로 한다면 시비를 건거 뿐이죠. 만약 C언어 자체가 게임 엔진을 지원한다면 누가 게임 엔진을 만들 것인지 궁금하군요. 문제는 JAVA 라고 하는 단어 자체가 가지는 개념의 범주를 얼마만한 크기로 잡을 것인가 하는 문제인데, 윗분께서는 스스로 "JAVA언어" 라고 했기때문에 시비 건 거 뿐입니다.
윗분께서 그렇게 생각하셨다면 어쩔 수 없는 일이고, 나는 별로 오버했다고 생각하지 않습니다. 잘못된 개념에 대해서 시비(!)를 걸었을 뿐 글에 대해서 맞았다/틀렸다를 논하는 것이 아니었고, 분명히 개념적으로 불명확한 것이 있어서 몇자 적었다고 이야기를 했을 뿐, 다른 이야기를 하지 않았는데, 너무 흥분하지 마시길..
개인적으로 오랫만에 본 "http://sunny.sarang.net" 글쓴이 URL이 반가운 마음이 있어서 크게 생각하지 않고 쓴 글인데, 내가 폐를 끼쳤다면 미안한 생각은 해야될 거 같네요. 문제가 된다면 이 글과, 위글을 관리자에게 이야기해서 삭제를 하셔도 무방합니다. 별로 큰 의미가 있는 글도 아니므로..
흠.
일단. 가볍게 시작한 글이 댓글에 댓글을 달리면서
불이날것 같아서. number3님의 마지막 글을 보고 한참후에야
이렇게 글을 답니다. 간혹 불날것 같을때는 전 이런 방법을 사용합니다.
---
일단. 님께서 말한 개념적인 것을 확실하게 하기 위하여.....
라는 말씀에 대하여는 감사하게 생각합니다. 님의 글을 보고 느낀바가
있었습니다. 역시 토론에 글을 올릴때에는 확실한 문장과 확실한 근거를
가지고 써야하겠다라는 생각을 갖게 해주셔서 감사합니다.
다만, 아쉬운 것은 제가 말한 내용에 대하여 개념적이 불명확하다. 라고
말씀하시면서 쓰신 댓글이 개인적으로는 불편한 글이었다. 라는 것을
말하고 싶습니다. 예를 들자면. 님께서 말씀 하신 "사실 관계를 밝히는데 M$
가 등장하면 안되는 것인지 아니면 뭐가 문제인지 궁금하네요."라는
글을 보면. 왜 갑작스럽게 MS가 SOAP을 제안하였다는 사실을
저의 글에 댓글을 달면서 썼는지? 아직도 전 이해가 안된다는 것입니다.
그리고, 님께서는 자바로 구현한 apache-axis와 같은 프로젝트를 말하셨는데.
그러한 프로젝트를 왜 이야기 하는지도 이해가 가지 않습니다.
전 다만 자바언어가 SOAP프로토콜을 이용하는 웹서비스를 지원한다는 말을
한 것 인데 말입니다.
또한 SOAP을 이용한 웹서비스를 지원한다는 말은요.
실제로 java.sun.com에 가보면 웹서비스에 대한 package를 다운로드
받을 수 있고 프로그램을 작성할 수 있습니다. 이러한 내용을 근거로 간단히
말한 것을 "자바언어가 지원한다"와 "자바언어로 만든 패키지가 있다."의
차이를 가지고 계속 잡으시니 당황이 되었다는 것이 저의 솔직한 심정입니다.
저의 주관적인 판단으로는 넓게 보았을때 "자바 언어가 지원한다." 가
틀린말이라고 생각되지 않기 때문이지요. "자바 언어를 이용하여 그런
패키지를 제작할 수 없다"면 자바 언어가 지원하지 않는다라고 생각할
것입니다.
님께서 저의 글에 처음으로 응답글로 쓰신 "개념적으로 조금 불명확한 것이
있어서 적었다." 라는 말을 보고 감사하게 읽고 넘어갔어야 하는데. 왠지
딴지를 거는 것같아서 쓴 글이 프레임을 유발할 것 같아서 이렇게 진화를
합니다. - 진화가 아닌 기름을 부은 것은 아니겠지요?
----------
http://sunny.sarang.net
JAVA,Oracle,MySQL,Linux,PHP
아직은 모르는 일입니다.
.NET이 망했다고 단정짓기에는 너무 이른생각이 아닐까 합니다.
저는 웹쪽은 전혀모르고 일반 응용프로그램만을 작성해서 더 그런지는 모르지만
아직까지 속단하기에는 이르다는 생각입니다.
한 회사에서 무언가를 기획하고 프로젝트로 시작했다는 것은 그것에 일말에 가능
성이라도 있기 때문입니다.
처음 MS사가 NT로 서버시장에 진출한다고했을 때는 누구도 성공하리라는 보장을
하지 않았었던걸로 알고 있습니다.
하지만 NT는 나름대로의 마켓팅과 영업력 그리고 기술지원등으로 어느정도 자리를
잡아버렸습니다.
이미 시장조사를하고 앞으로 소비자들이 원하는 것이 무엇인지를 내다보고 그에
맞는 사람들을 영입하면서 노력을 했기때문이라고 생각을 합니다.
사실 .NET은 새로운기술도 아니고 그렇다고 아주 노후화된 기술도 아닌것으로
알고있습니다. (제가 아직도 .NET의 정확한 개념조차 파악하지 못한상태이지만... :-))
그렇지만 앞으로 MS에서 생각하는 .NET의 세계는 올것이라는 것을 저는 어느
정도 확신합니다. 이건 정보가 어떻게 흘러왔고 앞으로 어떻게 흘러갈지를 곰곰
히 생각해보면 엇비슷하게 .NET의 개념과 일치한다는 것으로 생각할 수 있었
습니다.
사실 .NET의 개념은 최근 6~7년 이내에 국내에서도 비슷하게 적용을 시키려는
흔적들을 찾을 수 있었지만 결국 성공적이진 못했었죠.
하지만 앞으로 몇년후엔 이것이 일상생활에서 보편화될것임을 나름대로 확신하고
있습니다.
5~6년 전만해도 인터넷이 이렇게까지 대중화될것이라는 생각을 미쳐 못했었다는
것을 상기하면 말이죠.
MS사의 .NET이 성공하지 못할지라도 .NET의 개념은 앞으로 일상생활에 적용되어
분명히 사용되어질 것이라고 저는 감히 생각을 합니다.
------------------------------
좋은 하루 되세요.
앞에서 다른 분들이 잘 말씀해주셨지만 .net이라는 것은 아직 MS에서도
앞에서 다른 분들이 잘 말씀해주셨지만 .net이라는 것은 아직 MS에서도 그 구체적인 개념을 완전히 잡지 못하고 있습니다. 지금 당장 '.net은 이거다!'라고 말할 수 있는 사람을 찾기 힘들 것입니다. 개인적으로 MS와 관련이 있는 프로그래머와 관리자들과 이야기를 해보고 심지어 MS 본사에 있는 한국인 직원과 이야기를 해봐도 .net의 개념을 100% 이해한 사람을 보지 못했습니다.(MS 본사의 한국인 직원의 말을 빌리면 .net 관련 팀에 있는 사람들도 .net이 뭐냐고 물으면 궁색한 답이 나올 때가 많다고 합니다.)
좋게 말하면 아직 발전할 여지가 많은 개념이지만 나쁘게 말하면 개발하는 사람들은 뭐가 뭔지 모르는 상태로 빌 형(?)이 만든 .net의 바다에서 표류해야 하는 상황에 놓이게 됩니다. 아직 .net이 단단한 반석위에 놓이지 못하다 보니 그 과정에서 .net의 정책이 몇 번 바뀌게 된게 아닐까 합니다.
.net이 당장 성공한다고, 실패한다고 장담하는 것은 이르지 않을까 합니다. 적어도 몇 년 더 두고봐야 할 사항을 지금 왈가왈부하는건 희망 사항 이상의 가치는 별로 없을 것으로 보입니다.
=================================
이 세상은 썩어있다!
- F도 F시 시가지 정복 프로젝트
홈페이지: 언더그라운드 웹진 18禁.net - www.18gold.net