Comparing PowerBuilder ＆ .NET
PowerBuilder ＆ .Net
MS의 .NET은 2000년 6월에 'Internet For Everything'을 고안한 기술 시연회를 열었다. .NET의 기술적 능력이 있는 소비자도 .NET이 정확히 무엇인지 정의하기가 다소 광범위하고 모호하다. 거대 마케팅의 초기 영향력이 줄어들면서, 잔재하는 소문의 수위는 MS에게는 다소 실망스러운 것이었다. .NET이 소개된 지 2년이 지나고, 빌 게이츠는 "몇 가지 부분에 있어서 우리는 우리가 기대한 것 보다 훨씬 앞서있다. 그러나 다른 측면에 있어서 우리는 우리의 기대보다 진전을 이루지 못했다" 라고 말했다. 상대적으로 느린 .NET의 채택 속도는 거대한 브랜드 뒤에 좋은 기술이 존재하지만 MS의 .NET이 산업에서 주요한 변화를 이끌지 못했다는 것을 말한다. 성공적인 어플리케이션들은 .NET의 이점을 이용하지 않고 여전히 Win32의 플랫폼에서 구축되며, .NET을 채택하지 않는 양상이 쉽게 약해질 것 같지 않다.
일반적인 .NET의 정의는 프로그램 개발과 실행 플랫폼이다. 프로그램은 .NET이 있는 곳이라면 어디든 작동한다. MS .NET은 독립형, 클라이언트/서버, 모바일, 스마트 클라이언트, 그리고 웹 기반 어플리케이션 등, 광범위한 부류의 어플리케이션을 목표로 한 기술의 집합이다.
MS가 .NET에 할당한 개발 범위는 다양한 언어의 어플리케이션 개발을 지원하는 통합개발환경(IDE)의 Visual Studio.NET를 포함한다. 이 툴은 C++과 JAVA에 기반을 둔, 특히 .NET 플랫폼에 맞춰 개발된 C#을 포함한 몇 가지 언어를 지원한다. 비주얼 베이직 언어의 상속 지원을 이어가기 위해, MS는 보다 향상된 비주얼 베이직 라이브러리와 함께 VB.NET을 제공한다.
THE .NET FRAMEWORK
.NET 플랫폼 컴포넌트의 집합적인 어셈블리는 .NET 프레임 워크로 회부된다. 이 컴포넌트들은 CLR과 계층구조 클래스 라이브러리의 두 가지 주요 분야로 나눠진다. CLR은 .NET 어플리케이션을 위한 내부 실행 엔진이다.
.NET 기술의 독특한 측면 중 하나는 컴파일 된 코드를 다루는 방법이다. .NET 컴파일러는 윈도우2000이나 XP같은 특정한 OS에 코드를 생성하지 않는다. 대신에, 어셈블리안에 포함된 MS Intermediate(중개) Language(언어)(MSIL)을 생성한다. 이 MSIL 어셈블리는 .NET 플랫폼에 호환된다. 런타임에 .NET 플랫폼은 목표 OS의 코드 생성 마지막단계를 관리해준다.
CLR은 컴파일러에서 생성된 MSIL코드를 어플리케이션이 실행중인 현재의 윈도우 플랫폼에 호환적인 본래 코드로 변환하는 과정을 관리한다. 실행 가능한 코드가 새로운 시스템에 로드되면, CLR은 코드의 전체에 대한 최종 컴파일 과정을 실행하지 않는다. CLR은 코드내의 각각의 메소드를 최초 호출됐을 때의 본래형태의 시스템 코드로 컴파일 하는 Just-In-Time 전략을 사용한다. CLR은 프로그램의 로드와 실행, 메모리 관리, cross-language형의 호환문제, 그리고 실행중인 코드의 보안속성을 실행할 책임이 있다. .NET 프레임 워크의 다른 할당 범위인 클래스 라이브러리는 실행중인 어플리케이션에게 보통의 기능을 제공한다.
OVERVIEW OF POWERBUILDER
파워빌더는 데이터베이스 기반의 어플리케이션 구축에 있어서 뛰어난 하이레벨의 제품을 제공한 많은 역사가 있는 사이베이스의 강력한 개발 환경이다. 파워빌더 개발자는 클라이언트/서버와 다계층 분산어플리케이션을 만들어낸다. 파워빌더는 다양한 직관적인 IDE, 외부 표준지원, 풍부한 라이브러리 셋, 그리고 독특한 특징적인 데이터윈도우 기술을 포함한다. 이 결합은 파워빌더를 우수한 OO RAD 프로그래밍 환경으로 만들어준다.
파워빌더는 4GL, RAD 플랫폼이다. 파워빌더는 공통적으로 사용되는 표준과 최근 알려진 기술 표준까지 모든 사업에 걸쳐 컴포넌트들을 쉽게 통할 할 수 있는 광범위한 지원이 가능한 오픈 플랫폼이다. 4GL은 외부 기술을 통합하고 복잡한 원래 인터페이스를 고차원의 추상화를 통해 단순화하는 기능을 지원한다. 파워빌더를 다루는 프로그래머는 코드 개발에 있어 모든 통합된 기술도 사용할 수 있다. 파워빌더는 4GL 추상화, 성숙한 workflow 기반의 IDE, 그리고 데이터윈도우 개체의 조합에서 나오는 생산성으로 잘 알려져 있다. 이 조합은 데이터베이스 기반의 어플리케이션 개발 시 두드러지는 항목들 외에 모든 것을 숨기는 고차원의 추상화 된 환경을 제공한다.
파워빌더 어플리케이션을 .NET 어플리케이션과 구분짓는 중요한 특징은 멀티플랫폼 이식성이다. 파워빌더는 모든 Win32 플랫폼에서 작동하며, EAServer와 파워빌더가 함께 결합되어 있을 때는 유닉스 플랫폼에서도 개발할 수 있다.
파워빌더의 클라이언트-서버 시장 선두권 탈환은 고차원적 생산성과 어떤 데이터베이스와도 작동되는 능력에 기반 해 있다. 이것은 개방된, 데이터베이스 불가지(不可知)적인 개발 환경, 사이베이스 데이터베이스 기술과 다른 회사 데이터베이스 모두 지원하는 풍성한 제공력이다. 파워빌더 어플리케이션은 ODBC, JDBC, OLEDB 를 통한 광범위한 추가 데이터 소스의 접속과 함께 사이베이스 Adaptive Server, Oracle, MS SQL SERVER, DB2, Informix등 후미의 다양한 제품들과 같이 자주 사용된다.
파워빌더는 다른 언어와 잘 작동한다. 개발자들은 외부 DLL의 기능적으로 호출하는 어플리케이션을 쉽게 구축할 수 있다. 그리고 파워빌더 Native Interface(PBNI)인 파워빌더 9.X는 C와 C++ 어플리케이션을 파워빌더 어플리케이션의 파워빌더 객체로 통합할 수 있는 기능이 제공된다. 파워빌더 어플리케이션은 PBNI 를 인터페이스에 사용하여 JNI를 이용한 자바에 직접 쓸 수 있고, 3자 어플리케이션 서버에 EJB를 호출할 수 있다. PBNI는 자바 클래스가 파워빌더 기능을 호출할 수 있는 방법 또한 제공한다.
개발자들은 갈수록 이질적인 환경을 더욱 많이 제공해야 한다. 회사 합병, 획득, 그리고 어플리케이션에 새로운 기능을 추가할 때에도 투자를 계속 받아야 하는 경제적인 필요는, 각각의 RDBMS 와 다양한 플랫폼에서 작동하는 기업 어플리케이션의 혼합화를 만들었다. 파워빌더는 다양한 이러한 데이터 소스를 통합하는 훌륭한 툴을 만드는 J2EE를 포함한 오픈 된 표준을 지원한다.
파워빌더 9.0으로, 어플리케이션은 구축과 배포를 할 수 있고, 웹 서비스를 소비할 수 있다. 파워빌더는 강력하고 추상화된 XML 문서 객체 모델(DOM) 인터페이스를 가지고 있다. XML DOM 인터페이스로, 파워빌더 개발자는 웹 서비스를 지원할 수 있고, 어플리케이션의 내부 소통, 복잡한 데이터 구조와 구조화된 flat 파일들을 위한 XML의 보급화 된 기능을 이용하기 위해 XML을 분석, 조작, 창조할 수 있다.
출시될 파워빌더 10.0은 대중적인, 그리고 개인적인 웹 서비스 전개 과정을 향상시켜주는 UDDI 검색과 브라우즈 기능을 지원하여, 파워빌더의 웹 서비스를 풍성하게 한다. 파워빌더 10.0은 다른 언어를 사용하는 유저 인터페이스 유지를 단순화하는 유니코드를 지원하고, 유니코드 정보를 저장하는 데이터베이스와 상호 작용한다. 10.0의 몇 가지 추가적인 특징은, 반복되는 객체지향 모델링을 위한 파워디자이너 플러그인과, XSL의 XHTML, 동적으로 낮은 웹 트래픽을 요구하는 폭포형 스타일 쉬트를 지원하는 버전의 XML이 가능한 웹 데이터윈도우이다.
파워빌더 어플리케이션은 .NET플랫폼, J2EE 플랫폼, 웹, 그리고 전통적인 클라이언트-서버 구조에 호환된다. 파워빌더는 또한 기능적으로 모바일 유저들을 위한 포켓 파워빌더 어플리케이션으로 리패키지 될 수 있다.
파워빌더는 기업 어플리케이션을 개발하는 수백 수천명의 데이터베이스 개발자를 위한 선택가능한 언어를 개발해 왔다. 이것의 손쉬운 사용과 Reporting은 갖가지 크기의 프로젝트, 작은 회사 어플리케이션부터 중견 부서기반 어플리케이션, 그리고 Enterprise의 솔루션까지 다양한 범위의 선택을 가능하게 했다. 파워빌더의 오픈 개발 환경은 계속 생겨나는 기술을 지원함에 있어 지속적으로 능력이 향상되고 있다. 개발자의 필요가 변화함에 따라, 파워빌더도 변하는 것이다. 이는 파워빌더 개발자들이 소비자가 필요로 하고, 가장 새로운 기술이 가능함을 기초로 언제나 최신의 기술을 가지게 된다는 걸 보장하는 것이다.
EVALUATION GUIDELINES FOR POWERBUILDER SHOPS
LOOKING AT .NET
결정을 내리는 사람은 새로운 기술을 평가하고 최신의 제품이 제공하는 반사적인 마이그레이션을 피하는데에 점점 지쳐간다. 숨겨진 가격과 현장 테스트된 어플리케이션의 잠재적인 불안정성에 대한 주의깊은 산출은 종종 새 기술의 보장된 이득보다 중요하고 무겁다. 우리는 .NET으로의 이동에 대한 장점과 단점에 관한 다양한 논쟁들에 대해 생각해 볼 것이다.
ARGUMENTS FOR A .NET MIGRATION (.NET 이동에 대한 논쟁)
재 개발하는데 드는 높은 비용은 나중에 생각하고, 굳이 .NET 기술로 조직을 재편성하도록 강요할 이유가 있을까? 먼저, .NET으로 이동하는 것에 대해 요즘 널리 퍼진 주장을 살펴보자.
1. .NET은 최신 기술을 상징한다.
.NET에서, MS는 코드개발에 훌륭한 플랫폼을 창조했다. .NET은 만들고 실행하기 편했다. MS는 마케팅에 있어서 .NET이 얼마나 좋은 제품인지 세상에 알리는 노력보다는, .NET이 없는 개발은 열등하며 미래에 불이익을 당할 수도 있다는 추축을 불러일으키는 메시지를 심는 것에 가장 주력했다.
가능성 있는 기술로서 .NET을 시험할 때, MS가 .NET을 순수하게 이타적인 목적을 가지고 프로그래머로 하여금 다중적인 기능을 할 수 있도록 돕기 위해 만든 것이 아니라는 걸 명심해야 한다. 그들은 더욱이 시장을 지배하기 위한 목적으로 제품을 만들었다. 최신이라는 단어는 항상 가장 좋다는 의미와 같은 것은 아니다. 다양한 필요에 더욱 적합한 다른 실용적인 대안이 있을 수 있는 것이다.
2. 많은 프로그래머들이 .NET 개발자가 되고싶어 한다.
MS .NET은 다양한 종류의 어플리케이션을 만들 수 있는 기술을 가지고 개발자들을 유혹하는 꿀단지이다. .NET은 프로그래머가 전문적 기술에 대해 무엇이든지 다 할 수 있는 뛰어난 솜씨를 발휘할 수 있는 능력을 준다.
개발 조직을 바라보는 관점에 있어서, 이것은 그다지 영향력 있는 논쟁은 아니다. 조직의 목표는 생산성과 안정성, 그리고 –어쩌면- 이식성이다. 이는 .NET이 프로그래머를 하나의 업체와 하나의 플랫폼에 묶어버리면서 문제를 심각하게 만든다.
실제로, 많은 프로그래머들, 특히 4GL 프로그래머들은 .NET 환경에서 편안하지도 않고 생산적이지도 않다. C#은 훌륭한 범용 개발 언어이다; 그러나 그것은 또한 광범위한 객체지향언어적 토대와 3GL 기반의 기업 어플리케이션을 설계하는 데에 고급레벨의 배경 지식을 필요로 한다. .NET이 잠재적인 실행에 있어서 세부노출은 어플리케이션 개발의 복잡도를 높인다. 이 세분화된 노출이 조작의 편리성을 높여주는 반면, 생산성에는 장애물이 된다.
3. .NET은 내재된 웹 서비스를 제공한다.
웹 서비스는 .NET에 잘 지원되고 잇다. .NET 어플리케이션에서 웹 서비스를 확장하는 것은 놀라울 정도로 쉽다. 웹 서비스는 어플리케이션에서 중요한 상호교환 형식으로써 XML은 정보를 지역적으로 원거리에서 교환하기에 효율적인 메소드이다.
웹 서비스는 MS에 국한된 것은 아니다. 요즘 사용되는 어플리케이션의 대부분이 아직 사용해보지 않았음에도 불구하고 사이베이스를 포함한 대부분의 기업에서 웹 서비스를 제공한다. 객관적으로, 내재된 웹 서비스 지원이 그렇게 중요한가? 물론 웹 서비스 가능한 어플리케이션 개발을 쉽게 하는 건 사실이다. 그러나 어플리케이션에 얼마나 많은 웹 서비스가 필요한가? 대부분의 어플리케이션에는 실행 버튼에 웹 기능을 뿌려놓지 않아도 상관 없다.
웹 서비스가 처음 소개되었을 때, 많은 분석가들은 모든 어플리케이션에 이 기술을 즉각적으로 도입할 것이라고 예견했다. 그 뒤에 있던 가장 영향력 있는 아이디어중 하나는 웹서비스 기능의 공개된 레지스트리를 만드는 능력이었다. 어플리케이션은 레지스트리를 검색하고 기능을 사용하면서 널리 알려진 웹 서비스에 작동될 수 있었다. 그러나 보안 문제 때문에 그러한 단계의 채택을 발생하지 않았고, 대신에, 웹서비스 실행은 믿을만한 어플리케이션-대-어플리케이션의 사이에서는 종종 발견할 수 있었다. 공개된 레지스트리는 추진력을 점점 얻기 시작했지만 예상했던 것 보다는 훨씬 느린 것이었다. 결과는 웹서비스 가능한 어플리케이션은 중요하지만 항상 있어야 하는 건 아니라는 것이었다. 본래 웹서비스 지원은 인상적이었으나, 개발 조직의 닻에 자동적으로 바람을 불어넣어주지는 않았다. 공개 어플리케이션-대-공개 어플리케이션의 보안은 해결하기 어렵고, 알려질 때까지는 기업내의 일반적인 채택은 가망 없어 보인다. 반면에, 웹서비스가 XML에 기반해 있기 때문에, 파워빌더 어플리케이션은 쉽게 사용될 수 있다.
4. .NET은 더 많은 종류의 어플리케이션에서 능력이 있다.
MS .NET은 낮은 레벨의 시스템 프로그래밍 개발에 초점을 맞출 수 있고, 범기업적으로 쓰이는 어플리케이션 솔루션에 사용될 수 있는 융통적인 기술이다. 이런 개발의 폭은 .NET에게 있어서 영향력 있는 의견이다.
파워빌더는 낮은 레벨의 프로그래밍에 맞게 고안되지 않았다. 이것은 기업규모의, 경제적 능력이 있는, 고급기술의 고객을 위한 어플리케이션에 맞게 고안되었다. 설령 파워빌더급의 어플리케이션과 겹치는 부분이 아주 조금 있다 해도 .NET에 의해 지원되는 낮은 단계의 개발 능력은 아주 적다. 왜냐하면 파워빌더는 데이터 기반의 기업용 어플리케이션을 만들기 위한 희석되지 않는 RAD 플랫폼이기 때문이다. .NET의 다단계 적응력은 장점도 될 수 있고 단점도 될 수 있다. 비유해서 설명하자면, 많은 사람들이 스위스 군용 칼을 차에 소지하고 있다. 스위스 군용 칼은 매우 다기능 도구로서 다루기 쉽고 스크류 드라이버나, 렌치, 병따개 등 많은 도구가 들어있다. 그러나 100개의 나사를 조여야 하는 경우에 당신은 스위스 군용 칼을 우선적으로 사용하지 않을 것이다. 대신에, 당신은 나사를 조이기 위해 만들어진 강력한 도구를 원할 것이다. 만약 데이터베이스 기반의 어플리케이션을 빨리 구축하는 것이 목표라면 어플리케이션에서 다양한 종류의 활용능력이 있음을 알리기 위해 개발 환경의 기반을 더 많이 노출해야 하는 .NET은 파워빌더와 대적할 수 없을 것이다.
5. 비주얼 스투디오 .NET은 훌륭한 개발 IDE이다.
사실상, 비주얼 스투디오 .NET은 좋은 개발 환경이다. 여기에 반박할 것은 없다. C#, 비주얼 베이직, C, C++에 있어서 .NET은 훌륭한 개발과 디버깅 환경이다. 제 3자 위치의 기업들은 .NET버전의 코볼과 포트란을 제공한다. CLR이 이런 언어들에 몇 가지 제한을 가하고 있지만 지원되는 것은 사실이다.
비주얼 베이직 외에, 이들은 모두 융통성이 뛰어나고 생산성이 낮음을 의미하는 3GL 언어이다. 몇 가지 점에서, 코딩라인을 작성하는 개발자에게는 안 좋은 점이 된다. 대부분의 데이터베이스 기반 어플리케이션에게 .NET과 마찬가지로 훌륭한 IDE를 가지고 있는 파워빌더는 더 적은 코딩 라인으로 같은 기능을 제공하기 때문이다.
6. .NET에 맞게 개발된 어플리케이션은 모든 WIN32 플랫폼에서 호환성이 있다.
또다시, 여기에 반박거리는 없다. 지원되는 언어에 있어서, CLR은 Win32플랫폼에 걸친 호환성을 제공한다.
그러나 멀티플랫폼 이식성은 MS 시장 계획에 현저한 점을 부각시키지 못한다. 과거에 MS는 플랫폼 지원에 문제점이 있었지만 거의 따라잡았다. 이는 .NET이 Win32외의 플랫폼 이식성에는 문을 닫았다고 보여진다.
7. .NET 은 RAD 플랫폼을 가지고 있다.
MS는 이를 재빨리 주장하고 나섰고, 몇 가지 비교에 의하면 이는 사실이다. 비주얼 스투디오 .NET IDE는 모든 조각들을 하나로 보기 좋게 묶어 놓았고 코드 생산 능력이 있다.
.NET의 RAD 개발 기능과 파워빌더를 비교하자, MS의 빠른 개발 주장은 힘을 조금 잃었다. .NET은 순수한 프로그래머들의 개발 환경이라고 불려질 수 있다. .NET은 노출을 통해 작은 디테일까지 매우 좋은 조작을 제공한다. 이는 깊고 품위 있는 프로그래밍을 하고자 하고, 세부사항까지 모두 잘 책임을 져야 프로그램 완성을 더 잘할 수 있다고 믿는 프로그래머들에게 큰 기쁨이 되는 것이다. 시간을 알려주는 시계를 만드는 이 능력은 몇 가지 상황에는 유용할지 모르나, RAD의 정의는 될 수 없다.
빠른 어플리케이션 개발은 개발 툴이 개발의 길을 닦아준다는 의미가 되지만, 이는 최소한의 시간 내에 기능적이고 튼튼한 어플리케이션을 만드는 목표에 도달했다는 것을 의미한다. 디자인이 정해지면 개발자는 왼쪽 오른쪽을 어슬렁거려서는 안되고, 개발 툴은 세부사항을 주의 깊게 다루어 프로그래머가 어플리케이션의 독특한 측면에 집중할 수 있도록 해야 한다. 프로그래머는, 유저 인터페이스에서 데이터베이스 구조의 중요한 부분을 드러내서 워크 플로우가 엔드 유저에게 최고의 지원을 해줄 수 있게 집중하거나, 잠재된 성취의 과도한 걱정 없이 비즈니스 법칙에 집중해야 한다.
.NET이 제품의 전략을 나타내주는 기술의 집합체라는 사실을 기억해야 한다. MS는 Java 전쟁에서 승리하지 못했고 자바 개발 시장을 지배하지도 못했다. 비주얼 스투디오가 .NET 버전에서 자바를 지원하기를 포기했다는 사실은 별로 놀랍지 않다. MS는 뻔뻔하게도 ‘JUMP to .NET’전략의 판매를 촉진하고 있으며 자바에서 C#으로의 변환을 돕는 자바 언어 변환 지원을 제안하고 있다. 오히려 JSP개발을 홍보하고 있으며, MS는 왜 개발자들이 ASP. NET을 사용해야 하는지 애써 설명하고 있다. 이것은 .NET이 개발툴 중 최고의 생산력 지원이 가능한 오픈 플랫폼을 만들었다기보다는 MS 독점 지배가 잠재된 제품 전략임을 증명하고 있다.
이런 세계 지배 전략에 대한 의심은, .NET이 아직도 한 회사에 단독 채택에 대한 초기 기대가 없어왔던 이유 중 하나이다. 어떤 회사냐에 상관 없이, 독점 회사로의 융화라는 것은 많은 이유로 인해 플래너를 잠시 멈칫하게 한다. 이런 이유들은 미래의 가격상승이나 보안 공백이나 리소스 부족으로 인한 바이러스 감염 같은 잠재된 결점에의 노출, 그리고 다른 회사에서 나온 새로운 기술을 사용할 수 없다는 가능성들을 포함하고 있다.
ARGUMENTS AGAINST A .NET MIGRATION (.NET으로의 이동에 대한 반대의견)
이제 왜 파워빌더에서 MS .NET으로의 변환이 최선의 선택이 아닌지에 대해 몇 가지 이유로 검증해보자.
1. 존재하는 코드와 어플리케이션은 심각한 투자를 나타낸다.
성숙한 조직은 그들의 어플리케이션에 큰 투자를 한다. 코드는 개발되고 테스트되고 전개되고 성공적으로 정련되고 증명되어왔다. 개발 스태프들은 훈련되어왔고, 개발된 언어의 본체 뿐만이 아니라 코드가 문제의 범위에 어떻게 사상하는지도 알고 있다. 파워빌더 어플리케이션을 가진 회사들에게 있어 이런 코드는 프로그래머 전문화에 크게, 다년간에 걸쳐 이루어진 투자라는 것을 의미한다. 개발 플랫폼이 지속되지 않는다면, 또는 새로운 시작으로 속도를 유지하기가 불가능하다면 –둘 다 파워빌더의 경우는 아니다- .NET의 호의에 개발 조직을 완전히 재부팅할 강압적인 이유는 전혀 없는 것이다.
2. 빠른 어플리케이션 환경은 결과를 얻는다.
파워빌더 IDE, 파워스크립트, PBNI, 그리고 데이터윈도우의 합류는 파워빌더를 훌륭한 Rad툴로 만든다. 이런 커다란 덩치의 파워빌더 기반의 코드가 존재하는 데에는 이유가 있다. 기능적인 데이터베이스 기반 솔루션의 빠른 어플리케이션 개발에는 파워빌더를 따를 자가 없다. 개발 노력에 대한 결과는 사용자로 하여금 결과물의 세부사항에 대한 불필요한 염려 없이 복잡한 데이터셋을 볼 수 있게 하고 조작할 수 있게 하는 어플리케이션의 힘에 있다. 데이터베이스 기반의 어플리케이션은 파워빌더에서 그리 독특한 점은 없지만, 파워빌더를 유일하게 하는 점은 구축에 필요한 개발 노력이 상대적으로 낮다는 데에 있다. 조직에 있어서, RAD는 좋은 질의 제품을 시장에 빠른 시간 제공한다. RAD는 또한 적은 수의 프로그래머들이 더 많은 일을 완성할 수 있게 하기 때문에 개발과 유지 비용이 낮다는 것을 의미한다.
3. 단순함이 개발 과정을 효율적으로 만든다.
파워빌더는 객체지향 프로그래밍의 복잡함과 개발자에게 제공하는 인상적인 특징의 셋을 대거 감추고 있는 강력한 객체지향 개발 환경이다. 파워빌더 제품 자체는 C++로 작성되어 있기 때문에 개발자가 낮은 레벨의 기능을 쉽게 접근할 수 있다. 파워빌더 개발 환경은 사용자에게 친숙하고 사용하기 쉽지만 완성과 이식성에 대한 세부사항에 대해 엄청난 레벨을 감추고 있는 것이다. 제품 자체가 풍부하고 복잡한 반면, 개발자들은 효율적인 어플리케이션 개발을 위한 사용하기 쉬운 IDE가 제공되는 것이다. RAD 4GL 환경은 개발자가 더 많은 종류를 사용할 수 있다는 것을 의미한다. 정규 훈력을 받지 못했지만 프로그래밍 능력이 있는 사람도 툴을 수비게 사용할 수 있다. 이는 3GL에서는 불가능한 것이다.
4. 데이터 윈도우 기능은 다른 곳에서는 사용가능하지 않다.
파워빌더 데이터윈도우가 왜 그리 유명한가? 그 이유는 데이터윈도우가 사용하기 쉬운 인터페이스에 강력한 데이터베이스 시각화 툴이 패키지 되어있기 때문이다. MS의 데이터그리드 컨트롤을 사용해 본 프로그래머라면 데이터그리드가 고통스러운 프로그래밍 경험이 될 거라는 것을 알고 있다. 왜냐하면 데이터그리드는 개발자가 극도로 세분화된 프로그래밍 인터페이스로 프로그래밍 하도록 요구하기 때문이다. 아주 자유로운 일정에서 조차 그것을 빨리 사용하고자 하는 노력은 조직-대-조직 프로그래밍으로 귀속한다. 더 불행한 것은, 데이터그리드의 제한된 보고 능력이다.
데이터윈도우와 웹데이터윈도우는 XML을 임포트하고 익스포트하기 위한 XML이 가능하고, XSL로 임의적인 포맷이 적용된다. 데이터윈도우의 잠재된 구조는 적은 프로그래밍으로, 그래픽적인 인터페이스를 사용하여 복잡한 정보를 표현한다.
5. 하드웨어/OS 이식성은 미래의 선택을 자유롭게 한다.
파워빌더는 Win32플랫폼을 지원하며, 파워빌더 컴포넌트들은 Sun, HP, IBM AIX를 포함한 유닉스 플랫폼의 어플리케이션 서버에 배치될 수 있다. 파워빌더는 교차 플랫폼 개발을 현재와 미래의 선택사항으로 남겨두고 파워빌더 어플리케이션을 유닉스 환경에 묶어두지 않는다.
PEACEFUL COEXISTENCE (평화로운 공존)
.NET 대 파워빌더의 이슈가 꼭 대결 구도일 필요는 없다. 허위광고 마케팅의 .NET이 완전히 거품이었음을 깨달으면서, 사이베이스는 오픈 개발 환경을 유지하는 일이 가치 있음을 알았다. .NET은 현재 실행 가능한 개발 플랫폼이며, Win32 OS, 서비스, 그리고 MS 오피스 기술을 통합한 제품이다. .NET 지원은 소프트웨어 회사에 필수 요소이다. 사이베이스 파워빌더는 MS의 .NET을 지원하고 있으며, 파워빌더 상점이 계속 투자 받을 수 있도록 MS지원을 계속 향상시킬 것이다. 얼마 전, 사이베이스는 4가지 단계(four-Phase)의 .NET 지원 완료 전략을 개발했다. 사이베이스는 계속해서 조심스럽게 고려된 접근을 통해 이를 실행할 것이다.
1단계 – 이 단계는 파워빌더 9.0의 출시로 완성되었고, 웹 서비스를 지원한다. 파워빌더 어플리케이션은 MS .NET과, 지식의 확장 없이도 Simple Object Access Protocol(SOAP) 또는 Web services Definition Languate(WSDL)의 구축, 배포, 웹 서비스 사용이 가능하다.
2단계 – 이 단계는 데이터윈도우.NET의 베타버전 출시로 현재 진행중이다. 2단계는 데이터윈도우.NET과 데이터스토어.NET을 소개한다. 데이터윈도우.NET은 데이터 접근과 조작을 위한 특허 받은 데이터윈도우 기술의 이점을 취하기 위해 다른 .NET언어를 사용하는 개발자들을 위해 따로 패키지 된 툴이다.
3단계 – 개발자들이 .NET 라이브러리와 다른 플랫폼에의 접근을 가능하게 하기 위해 이 3단계는 MS 중개 언어 코드(Microsoft Intermediate Language Code)를 생성하는 컴파일러를 충족할 것이다. 이 코드는 Common Language Runtime에서 관리된 코드처럼 실행될 것이다. 이는 파워빌더 어플리케이션이 다른 .NET 어플리케이션과 혼합될 수 있다는 것을 의미한다.
4단계 – 이 마지막 단계는 .NET 유저 인터페이스 디자이너를 지원하기 위해 파워빌더 IDE를 개방하는 것이다. 이는 파워빌더 어플리케이션이 .NET 유저 인터페이스 컴포넌트에게 효력을 주게 할 것이다.
사이베이스는 이 계획을 실행중이다. 1단계와 2단계의 일부가 완료되었다. 되돌아보면, .NET채택이 생각보다 느렸다는 사실을 보아, 계획은 비전이 높은 수준에 있다는 것을 나타낸다. .NET에 이도 저도 아닌 압력을 주기보다, 사이베이스는 .NET을 사용하는 사람들을 포함한 모든 사용자들에게 파워빌더를 더 나은 방법으로 제공하는 데에 노력을 기울인다. 사이베이스는 .NET지원에 사려 깊은 접근을 해왔고, 현재까지 하고있다. 파워빌더는 중대한 임무를 띤 데이터 기반의 어플리케이션을 구축하기에 아주 좋다. 1단계를 완성하면서, 그리고 이 .NET계획이 좌초되지 않고 지속되면서 파워빌더 어플리케이션은 .NET 솔루션의 데이터베이스 엔진에 생산적으로 기반 할 수 있다.
CONCLUSION
객관적으로, .NET이 4년 전에 만병통치약을 만들 포부를 가졌던 것은 아니지만, MS .NET 기술은 인상적이다. .NET은 세력가의 마케팅 무기에 지배된 회사를 위한, 비즈니스의 몇 가지 최상 마인드로 만들어진 열매이다. 그것은 MS의 다 선위(multi-front) 소프트웨어 조직의 다양한 제품을 하나로 묶는 참고용의 보전성을 가지고 있다.
파워빌더는 데이터베이스 기반의 어플리케이션을 위해 고안되었고, 데이터 접근, 조작, 진행이 필요한 비즈니스 어플리케이션의 모든 부류에서 사실상 성공했다. 파워빌더 IDE는 강력하고 간단하다. 파워빌더 어플리케이션 제품을 만들기 위해 IDE를 사용하는 것은 RAD의 본질을 나타낸다. 과거 기록에 의해 설명하자면, 사이베이스는 새 기술을 알리기 위해 파워빌더를 계속 발전시켜 나가는 데에 헌신적이다.파워빌더는 몇 안 되는 출시에서 SML, DOM, JSP 와 무엇보다 웹 서비스 지원을 추가시켰다. 이 발전은, 개발자들이 .NET을 포함한 경쟁시장으로 어플리케이션의 기능을 확장해 나가고, 감당되는 범위에서 그들의 기술 투자의 가치를 더해나갈 수 있는 개방된 전략임을 나타낸다.
댓글 없음:
댓글 쓰기