맛봬기로 널려져 있는 문제점을 몇가지로 풀어보았습니다.

이러한 문제점을 해결하고자 무지막지한 넘이 나타났으니 그것이 닷넷입니다.
닷넷은 MS 의 비즈니스 모델이자 처음에 제가 긴 말들로 이야기했던 세상에 널려져 있던 전산환경에서의 문제점을 해결하고자 혜성같이?(혜성같이는 아니지만...) 나타난 하나의 기술입니다.
수많은 Device, 이질적인 환경에 적합하고, 개발하기 용이하고 수많은 사용자의 수많은 요구사항에 대응할 수있는, 그리고 기존에 존재하는 legacy system, application 과 함께 사용할 수 있도록 하는 기술인 것이죠.
JAVA 또한 같은 기술중의 하나라 할 수 있습니다. 하지만 MS의 .NET과는 조금 다른 차이점이 있다고 생각합니다. MS 는 인프라를 함께 구축해 나간다는 것이죠. 하나의 개발툴만이 아닌 하나의 플랫폼을 구축해 나간다고 할수 있습니다. MS 의 개발툴뿐만이 아니라 많은 서버군들, Office 제품군들 모두 닷넷이라는 방향성을 가지고 개발되어 나간다는 것입니다. 이런 제품들을 개발하기 위한 바탕기술들을 몇년전부터 발표하고 표준으로 만들고 있습니다. 이런 추진력 또한 고개를 설래설래 흔들게 하고 무시무시하게 느껴지도록 하는 것 같습니다.

이런 기반하에 구축된 MS 의 닷넷 플랫폼의 중심에 .NET Framework이 있고 BuidingBlock Service, 그리고 VisualStudio 가 있습니다.
그리고 우리는 VisualStudio 가 지원하는 언어중의 하나인 VisualBasic.NET 을 사용하고자 하는 것이구요.

vb.net, c#, asp.net, webservice, ... 등등을 그냥 단순히 바라보기 이전에 이러한 기술들이 어떻게 발생하게 되었나를 알고 있는 것 또한 이들에 접근하는데 약간의 도움이 될 듯 합니다.

이때 이런 독보적인 위치를 점령한 MS. 이것 또한 걱정이 아닐수 없습니다. 지금까지 수많은 제품의 독점판정으로 소송에 시달렸구요. 타 개발툴들과는 당연한 일이겠지만 경쟁구도를 갖을수 밖에 없었습니다. 그래서 약간의 생각을 바꾼거죠. (생각을 바꾸면 돈이 보인다~~ ^^)

"공개".

CLI 를 공개합니다.
그리고 VisualStudio를 많은 개발툴에 오픈을 하게 됩니다. 많은 개발자들을 기술표준에 끌어들일수 있고 다른 개발랭귀지 회사들은 자신의 툴을 VS 에 포함시키려고 할 것입니다.(Cobol이 그렇고 비록 컨트롤과 같은 유사한 형태지만 PowerBuilder 의 Datawindow 이 그렇습니다. Python.net, JVM 위에서 구동되는 것은 아니지만 JAVA Language를 사용하는 J# 또한... 이렇듯 많은 랭귀지를 포함하고 있습니다. ) 그럼 자연스레 수많은 다른 랭귀지를 사용하는 개발자를 VS 사용자로 끌어들일수 있고(파워빌더.NET을 만들어달라~달라달라... ^^;), 타 랭귀지개발사들과도 경쟁구도 보다는 한결 쉬운 구도가 되겠죠? 거기다 점점 닷넷의 영향력이 커진다면... VisualStudio 는 더 많이 팔리지 않을까? ^^(하기사 많은 기업들이 기존에 가지고 있는 고가의 Unix 기반 머신들을 한꺼번에 바꿀리 없고, 모두다 개발툴을 VS 로 바꿀리는 만무하지만, 이전의 환경보다는 나은 환경을 지원할 수있도록 기업들도 조금씩 바꾸어 나가려는(Webservice와 같은 기술로) 생각을 가지지 않을까 라는 저의 막연한 작은 소견...ㅋㅋ .NET Framework을 unix 머신에 포팅까지 하는 것을 보면^^)

지금까지 본격적으루다가 강의를 시작하기 전에 맛베기를 풀어봤습니다.
(이것도 너무길면 싫어하시지 않을까 라는 걱정에... ^^;)

강의를 이런식으로 진행을 해 나가는 것이 좋은지? 아니면
간단간단하게 요점만을 똑똑 끊어서 진행하는 것이 좋은지... 고민과 걱정이 많이 되네요.

10강정도로 생각하고 있다고 말씀을 드렸건만... 1차 강의를 어느정도의 내용을 가지고 할지 지금도 아리까리 합니다.

제머리 가지고 이만큼 쓰는 것. 장난 아니게 오래 걸리거든요... ^^

그럼 저는 고생할터이니 여러분은 행복한 휴일 보내시고 행복하세요... ^^


woojja ))*
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\












Posted by woojja
TAG .NET
2009.03.05 21:57

오늘부터 요즘 내가 공부하고 있는 닷넷과 XML 에 대해 정리해서 올리고자 합니다.

내용이 허접하더라도 예쁘게 보아 주기 바라며 많은 질책과 질문을 보내주기 바랍니다.

이 글은 다른 사람들을 대상으로 했다기 보다 공부한 것을 정리한 것이라 생각해 주기 바랍니다.

아는 바가 없어 되도록이면 쉽게 풀어 나가겠지만 읽던 도중 의문점이나 틀린점이 발견되면 제게 한 수 알려주시기 바랍니다.

지금부터 몇번에 걸쳐 연재를 할 생각인데

순서는 이렇습니다.

일단은 닷넷에서 지원하고 있는 XML의 개요를 간단히 짚고 넘어 갈 것이고

XML 읽기, XML 쓰기, XML 쿼리하기, XML 조작, XML 변형, XML 전송, 그리고 XML Web service등을 짚고 넘어 갈 것입니다.

크게는 8부분이지만 한번에 한 부분씩 하는 것은 제게 무리가 따를 것 같은 생각이 드는군요. 그래서 되는 데로 많이 올려 빨리 XML 하나를 마치도록 하겠습니다.

 

그럼 시작해 보도록 할까요? ^^;

현재 기업들은 인터넷이라는 네트웍 건너의 다른 많은 업체와 데이터를 교환하고자 하고 있습니다. 이런 이유로 그러한 기업들은 시스템을 다시 구축하고, 변경하는데 막대한 시간과 돈을 들이고 있습니다.

그래서 현재 사용하고 있는 데이터와 파트너 사가 현재 사용하고 있는 데이터를 통합하는 것이 지금 프로그래머에게 닥친 문제라 하겠습니다.

이렇게 파트너사들과 데이터를 통합하려하는데 있어서 생각해 봐야 할 것들엔 어떤 것들이 있을까요? 통합을 어렵게 하는 점은 어떤 것이 있을까요?

그리고 그런 문제점은 어떻게 하면 해결을 할 수 있을까요?

1.       다른 프로그램들의 통합

현재 각 회사에서 실행중인 어플리케이션은 다른 OS 환경에서 동작하고 종류도 억쓰로 많습니다.

이런 상황에서 통합을 위해 시스템을 새로 구축하려 한다면? 뜨아… 상상치 못할 정도의 자금이 들 것입니다.

그리고 데이터가 저장되어있는 공간 또한 SQL Server 와 같이 RDBMS 에 저장되어있는 경우가 있기도 하고 문서파일에 저장되어있기도 하죠.

2.      서로 다른 문서 포맷사이에서의 translating

문제점들 가운데 가장 큰 문제라고 할 수 있는 점이죠.

예를 들어 Xml로 데이터들을 교환을 하겠다고 결정하더라도 xml의 특성중의 하나인 element나 attribute 사용에 있어서의 유연성 때문에 너무 많은 포맷이 나올 수 있을 것입니다.

교환된 xml파일을 바탕으로 각 포맷에 맞도록 다시 변환해야 하겠죠.

그래서 이점을 해결하려면 문서 포맷을 표준화 하는 것 밖에 없겠죠…

또한 데이터의 source는 RDBMS 보다는 많은 종류의 포맷으로 된 문서가 더욱 많을 것입니다. 예를 들면 CVS 파일이나 Tab을 구분된 파일, 워드파일일 수도 있고 XML 파일일 수도 있겠죠, text 파일일수도 있구요.

이런 파일로부터 다시 상대 회사에서 원하는 형태의 XML을 생성해야 하겠죠.

그리고 XML을 생성할 때는 데이터가 유효한 형태인지 그 구조가 정확한지를 check 해야 할 것입니다..

3.      데이터 탐색, 쿼리

여러 종류의 데이터 포맷의 데이터 source로부터 내가 필요로 하는 정보를 찾아내기란 쉬운 일이 아니겠죠..

찾아 낸 정보는 다시 나 자신이 원하는 형태로 출력하기 위해 비교하고 조합해야 할 것이구요.

4.       데이터 조작

그렇게 데이터를 변형하여 전의 데이터 포맷과는 다른 HTML이나 PDF와 같은 포맷의 문서로 변형시킬 수도 있어야 겠지요.

그 데이터들을 display 하고 report 하기도 해야 할 테니까 말이죠…

 

이러한 점들을 해결하기 위한 것을 XML이라고 본것이죠.

그 선택에서 단점보다는 장점을 더욱 많이 찾을 수 있기 때문일 것입니다.

그리고 .NET은 XML을 다루는 데 있어서 간편하고 다양한 interface를 제공하고 있습니다.

 

woojja ))*

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

허접하고 말주변이 없어...죄송합니다. ^^

 












'XML' 카테고리의 다른 글

[XML] AutomationML  (0) 2017.04.05
[XML] XML ??? ... (3)  (0) 2009.03.05
[XML] XML ??? ... (2)  (0) 2009.03.05
[XML] XML ??? ... (1)  (0) 2009.03.05
Posted by woojja
TAG xml

두달여 기간동안 여러 좋은 분들과 모여 준비하고, 힘든 것을 함께한 시간.
다리찟느라 힘들었고, 뒷차기 격파연습하니라 어지러웠으며, 세계 여러나라 개발자들 앞에서 보이느라 많이도 떨었습니다.

언제 또 이런 날들이 올까요?

멋진 추억 만들어 주신분들 감사합니다.

함께 있어 소중하고 행복한 시간이었습니다.


아래 링크는 Global Summit 에서 선보였던 태권무입니다.

외국 사람들 좋아라 합니다. 멋쪄라 합디다.

끝나고나서도 한쪽에 서있으면 한사람씩 다가와 말을 거네요.

못하는 영어에 말을 받아줍니다.

세미나때도 말을 거네요. 햐~~ 너 태권무때 봤어. 잘 하던데... 하며... VB 개발자구나... 라며...

그러나 저는 별 말이 없네요... 간단한 말 밖에는... 영어 공부 좀 더 많이 해야겠습니다. ^^'


마이크로소프트 부사장도 연설에 나와 전날 있었던 우리나라 개발자들의 태권무에 대해 열변을 토합니다.


제겐 너무나도 멋찐 추억이었습니다.


Korea MVPs TaeKwonDo Dancing Demo(1)

Korea MVPs TaeKwonDo Dancing Demo(2)

Korea MVPs TaeKwonDo Dancing Demo(3)


정환이를 찾아보셔요... ^^



행복한 고수되세요...

woojja ))*
\\\\\\\\\\\\\\\\\\\\\\\\\\\













Posted by woojja
프로그램을 Cording 하고 배포하기위해서는 반드시 Build 라는 과정을 거쳐야만하고(Script 가 아니라면...) 우리는 거의 매일 Build 의 과정을 반복한다.
프로그래밍의 한 과정인 Build 를 하는데 사용되는 Tool 에는 여러가지 종류가 있다.
그중 몇가지 잘 알려진 Build Tool 에 대해서 알아보고 다음편에서는 Microsoft 사의 MSBuild 에 관해 정리해 보고자 한다.

Make 방식의 Build Tool
몇가지 Build Tool은 BSD(Berkeley Software Distribution) Make Tool의 확장판이라고 할 수 있다.
그중에 잘 알려진 것들이 보면 GNU Make, NMake, OPus Make, Jam, Cook, GBS, CMake 그리고 QMake 같은 Tool 들이 있다.
위의 Tool들의 설명은 추후 Update 하거나 추가로 덫붙이기로 하겠다.

Ant/NAnt
위에 나열한 Tool 의 경우는 모두 makefile 파일 같은 Build Description File 을 이용하며 대부분 사용하기에 애매한 명령어나 Build 하는 데 필요한 완전한 Programming Language를 사용한다.
이것들의 문제점을 든다고 하면 유지보수가 어렵다는데 있다.(뭐 익숙한 사람들에게는-그렇게 말하는 고수분들은-더할 나위없는 유지보수가 쉬운 방식일수도 있겠지만...)

Ant 는 자바진영에 잘 알려진 Cross-Platform Build Tool 이다.
이는 Build 를 하기위해 명령어를 사용하거나 Programming Language 를 사용하는 것을 버리고 XML-Base 의 Configuration File 을 사용한다.

Build 의 단계는 Java Language로 구현된 Task 라고 불리는 것으로 설명되어지며 이런 Task는 다시 Target에 의해서 Group 지어진다.

Ant File 의 예

<project>
  <target name="compile">
    <mkdir dir="build/classes"/>
      <javac srcdir="src" destdir="build/classes"/>
  </target>
  <target name="jar">
    <mkdir dir="build/jar"/>
    <jar destfile="build/jar/HelloWorld.jar" basedir="build/classes">
      <manifest>
        <attribute name="Main-Class" value="sayed.HelloWorld"/>
      </manifest>
    </jar>
  </target>
  <target name="run">
    <java jar="build/jar/HelloWorld.jar" fork="true"/>
  </target>
</project>


Ant 를 사용해서 Build 를 하기 위해서는 프로그램의 Source Tree 상에 Build.xml 파일을 위치시카고 Command prompt 상에서 Ant 를 입력하고 실행시킨다.
Ant 는 Command-Line 으로 실행되지만 GUI 또한 제공된다.

다음편에서는 Microsoft의 MSBuild 에 관해 정리해 보기로 하겠다.












Posted by woojja

나 자신이 보지 못했던 컴퓨터 환경에서부터 지금까지.. 아직도 널리퍼져있는 문제들이 어떤 것들이 있는지 부터 살펴보는 것이 좋을 듯하다.


#사용자들의 요구사항은 폭발적이다.
#웹은 이질적이다.
#서버메모리에 아무리 돈을 쏟아부어도 메모리 부족으로 죽는다.
#버전을 관리할 수가 없다.
#보안... 좀 몰래 들여다보지 좀 마라.
#지금까지 개발된 COM 은 어떻게 할 것인가? 상호운용되어야 한다.


지금 생각나는 것은 이정도 인것 같다. 아래 설명은 위 사항들에 대한 부연설명들이다.
읽기 귀찮으신 분은 걍 넘어가셔도 될듯 하다.(나 같은 단무지-단순무식 같은 사람들은 이런 장문은 읽기 귀찮다. 그런데 또 쓰자니... 읽는 사람 생각안하고 길게 쓰게 되드라... ㅡㅡ)


#######사용자들의 요구사항은 폭발적이다.
기술교과서에서 봄직한 집채만한 컴퓨터가 나오면서부터 항상 문제점은 발생하였을 터이고, 그 문제점은 개선되기 위해서 Hardware와 Software 의 기술은 계속해서 발전을 거듭했을 것이다. 거대한 계산기에서 퍼스널 컴퓨터로 발전을 하고
그러한 하나의 단세포생물 아메바와 같던 개인의 데스크 탑은 서로 얽이?昰?네트웍으로 연결되어 이젠 인터넷은 사람들의 생활 깊숙히 자리 잡았다. 데스크탑 뿐이겠는가? 우리 주위의 모든 기기들(휴대폰, 냉장고, 아파트마저도-기계는 아니지만...)은 모두 네트웍에 연결되어 사람들을 거미줄로 꽁꽁 묶어버리려 하고 있다... (컬럼쓰냐? ㅡㅡ;;;)

되지도 않는 말주변으로 이런 이야기를 하는 이유는 우리 생활이 점점더 발전을 하면서 발생되는 사람들의 요구사항이 기하급수적으로 늘어나는 것을 이야기 하기 위해서 이다. 사람들은 주위에 널려져 있는 네트웍을 사용하고 싶어할 것이고 모든 일을 네트웍을 통해서 쉽고 빠르게 해결하려 할 것이다. 사용자들이 사용하는 그 많은 데이터들을 일순간 처리하기위해 Hardware 또한 발전할 것이도 처리속도와 처리량은 기하급수적으로 늘어날 것이다. 또 네트웍을 사용하면서 언제 어디서든지 내가 원하는 곳에 연결할 수 있지만, 반대로 악의의 사용자에 의해 그 정보가 노출되기를 원하지는 않을 것이다. 이러한 요구사항은 기술의 발전을 낫고 개발자에겐 새로운 꽁수를 낫게한다. (고로 꽁수는 기술이다. 나만 그런가? ㅋㅋㅋ)
정보를 처리하기위해서 개발자들은 자신이 개발하는 데있어서 효율적인 언어를 선택해야 했고 다른 개발자들이 사용하는 언어를 폄하하기도 했다(아직도 그렇지... java가 최ㄱ오야... vb는 쓰레드 기능을 사용할 수 없어... VB는 쥐나 개나 다해... ㅡㅡ; 내가 쥐, 개란 말인가? )
세상의 개발자들이 꽁수로 처리할 수 있는 정보의 양은 한정되어있었고
그러한 꽁수를 줄여보고자 여러가지 기술들이 나타나게된다.

#######웹은 이질적이다.
그중에 하나가 MS 에 의해 명명된 대표적인 기술 COM 이다. (이미 알려진 기술을 멋진? 단어로 재 생산하지 않는가? 마치 자신이 탄생시킨 것처럼... 하긴 윈도우즈 진영만을 이야기 한다면 그 말도 맞지 않을까?. ^^)

이제 COM을 사용하면 개발자들은 처음부터 개발할 필요가 없어졌다. 획기적이지 않은가? 써드파티에서 만들어 놓은 컨트롤을 사다가 내 로직과 연결만 시켜놓으면 된다. 그 제품의 내부가 어떻게 구현되어있는지 알 필요도 없다.(우린 발생하는 버그에 제품을 욕하기도 한다... 어떤때는 버그에 못견딘나머지 인터넷을 뒤져 컨트롤을 만들어 버리곤 하지..ㅡㅡ;)

우리의 친구 비쥬얼베이직은 COM 의 상승세를 타고 무한히 발전하는 듯 보였다.(요놈만 잘해보좌~~)
잔머리도 많이 줄어드는 듯 했다.(사실 많이 줄었다. ㅡㅡ)

하지만 이러한 환상적인 COM 은 문제점 또한 가지고 있었다.
두가지나 된다고 한다.(완벽한줄 알았던 넘인데...)

한가지는 COM은 각각이 떨어져 있는 클라이언트/서버에서 동작한다는 것(최소한 얼마라도...)과 COM 의 내부 구현을 공유하는 것이 아니라 인터페이스를 통해 서로 통신한다는 점이다. 그렇기 때문에 COM 간의 통신을 위해서 특정 메카니즘을 구현하고 있어야 하고, COM 인터페이스는 구현하는 Language(VB, C++) 에 따라서도 다르다는 단점을 가지고 있다.
그래서 VB 로 제작된 COM을 C++에서 사용한다거나 C++로 만든 COM 혹은 JAVA 로 제작된 CORBA 를 사용하기 위해서는 별도의 Mapping? 을 통해서 그 차이점을 줄이는 작업을 별도로 해주어야만 한다.
이런 작업들로 추가적인 많은 작업을 하고 있다 (배보다 배꼽이 크다면... ㅡㅡ; 포기하고 같은 언어로 하시죠 라고 말한다. ㅡㅡ)

우리 개발자들.. 특히 우리는 이세상 많은 사용자들이 모두 윈도우즈만 사용했으면 좋겠다고 생각할 것이다. (아니 윈도우즈가 아니라 리눅스라도 좋다. 제발 하나만 써다오.)

(위를 보니 너무 많이 썼다. 아래 내용은 아시는 내용이 많을테니... 양을 줄이련다. ㅡㅡ;)

#######서버메모리에 아무리 돈을 쏟아부어도 메모리 부족으로 죽는다.
우리 서버는 많은 사용자들이 요구하는 수많은 데이터를 처리하느라 늘 바쁘다.
그런 서버에게 개발자는 친절히 메모리 할당과 해제를 친절히 능숙하게 해주어야할 기본적인 의무를 가지고 있음에도 불구하고... 잠시 음주코딩으로, 졸음 코딩으로 의무를 다하지 못하는 상황이 간혹 발생한다. 그로 인해 서버의 메모리 누수는 계속 발생하여 종래에는... "수고하셨습니다~~." 서버를 다시 켜게되며 이런 상황이 발생하지 않더라도 서버관리자는 추후에 발생할지도 모르는 서버의 살해사건방지를 위해 주기적으로 부팅시켜주는 일을 하고 있다.

#######버전을 제대로 관리할 수가 없다.
우리가 프로그램을 제작을 하게 되면 배포버젼을 제작하는 그 순간부터 발생하는 버그를 수정하게 되고 곧 새로운 버젼의 프로그램을 제작하여 Patch 하거나 새 제품을 출시하게 되는데 이때 이전 버전의 제품과 호환을 이루게 하는 것이 또 하나의 작업이 되게 된다. 때문에 버전을 관리하기 위한 표준적인 메카니즘이 필요하게 됐단다..

(거기다 COM 의 문제점인 DLL Hell 도 한몫 거들고 있다.-버전이야기 하니까 갑자기 생각나네...)

#######보안... 좀 몰래 들여다보지 좀 마라.
우리는 최근들어 인터넷을 통해서 많은 일을 하게 되었다. 업무를 보고, 인터넷뱅킹을 통해 현금을 송금하고, 물건을 구입하고 게임도 한다. 이때 보안은 필수적인 것이 될 것이다.
우리가 브라우져를 통해 설치하는 ActiveX 컨트롤은 그힘이 막강하여 한번 깔리게 되면 내 PC 를 내어주는 것이나 다름 없이 모든 권한들 가지고 내 PC를 제어?할 수 있다. 이것은 사용자에게 그리 좋은 것이 아니다. 그런 프로그램은 하는 역할에 합당한 권한이 주어져야 하기 때문이다. 특정 파일에 접근하여 쓰지는 못하되 읽을수만 있게 한다거나 하도록 설정하게 하는 방법이 필요하다.

#######지금까지 개발된 COM 은 어떻게 할 것인가? 상호운용되어야 한다.
우리는 그동안 환상적이었던(아직도 환상적이기는 한) COM을 많이도 만들었다. (내가 만든것 또한 Test 프로그램을 포함해서 너무 많이 만들지 안았나? ^^;) 이런 COM 을 일시에, 한번에, 무자비하게 다 없애 버릴수 있는가?
함께 써야 한다... 내가 만든 COM 을 사용할 수 있어야 한다.
돈주고 산 써드파티 컨트롤을 이젠 못쓰니 다른 버전으로, 또는 다른 제품으로 사달라고 하면 어떤 싸장님이 좋아하시겠는가? 기존에 산 써드파티 컨트롤을 쓸수 있는 사람을 당신 대신 구할수도 있지 않을까? ^^;












Posted by woojja
TAG .NET

티스토리 툴바