RAPID APPLICATIONpds.devpia.com/MAEUL/top_pds/1000/12/NSTL RAD … · Web view개발자가 개발을 시작하기 전에 IIS SDK와 인프라이즈의 웹 사이트를 조심스럽게

RAPID APPLICATION DEVELOPMENT TOOLS 6/98

RAPID APPLICATIONDEVELOPMENT TOOLS

국립 소프트웨어 검사 연구소

본 보고서는 미국 국립 소프트웨어 검사 연구소에서 지난 6 월에 실시한 벤치마크 자료를 완전히 번역한 것으로, 마이크로소프트 또는 관련 협력업체에 요청하시면, 본 테스트를

위하여 사용된 소스코드와 증빙자료를 확인하실 수 있습니다.

CONFIDENTIAL PAGE 1 5/19/2023


요약

National Software Testing Laboratories (NSTL)는 마이크로컴퓨터 산업에서 선도적인 하드웨어, 소프트웨어 검사 기관으로 고품질의 서비스와 테스트 툴 제공에 전념하고 있다. NSTL 은 호환성, 성능, 유용성, 버그 테스트, BIOS 평가 면에서 기존의 제품 또는 신제품을 측정하는 폭 넓은 경험을 보유하고 있다.

여기에서 비교된 제품들은 마이크로소프트의 Visual Basic 6.0, 사이베이스의 PowerBuilder 6.0 과 인프라이즈의 Delphi 3.0 이다.

유용성/생산성 결과 (요약)

Visual Basic 은 3 가지 제품 중에서 가장 사용하기 쉬웠다. Visual Basic 은 우리가 테스트한 제품 중에서 가장 뛰어난 데이터베이스 개발 툴이다. 데이터베이스 브라우저에서 데이터베이스 필드를 끌어와서 폼 또는 보고서에 놓기만 하면 데이터베이스 폼과 보고서가 작성된다. 사용자는 개발 환경 내에서 테이블을 생성하거나 변경하고, 스토어드 프로시저를 편집하거나 디버깅하고 별다른 수고없이도 SQL 질의를 시각적으로 구성할 수 있어, 데이터베이스를 완벽하게 조작할 수 있다.

웹 사이트의 경우도 마찬가지로 쉽다. 첫 번째 웹 사이트를 만들려면, 그저 애플리케이션 마법사 기능을 두 번 클릭하고 “run”을 클릭하면 된다. 얼마나 환상적인가! 개발자는 디버그 창을 클릭하면 적절한 페이지로 이동하여 웹 사이트를 쉽게 디버깅할 수도 있다. Visual Basic 은 디버거에서 COM 을 전문으로 지원하는 유일한 툴이었다. Visual Basic 은 가장 우수한 온라인 도움말을 제공하며 도움말은 웹 사이트와도 완벽하게 통합되어 있다.

Delphi 는 우수한 유저 인터페이스를 가지고 있지만, 버그와 빈약한 도움말로 상당한 학습이 필요했다. 데이터베이스 프로그래밍 툴은 특히 3 가지 제품 중에서 가장 떨어졌다. 우리는 개발 환경 내에서 데이터베이스를 변경할 수 없었으며, 보고서 생성기는 작업하기 힘들었다. Borland Desktop Engine (BDE)은 어떻게 해야 할 지를 알려주지 않는 에러 메시지를 계속 만들어냈다. 우리는 BDE 에서의 문제 때문에, 개발 도중에 개발 환경을 빠져 나가야만 했다. 경우에 따라서는 작업 관리자로 이동하여 작업 종료를 선택해야만 했던 것이다.

우리가 시도한 첫 번째 Delphi 웹 애플리케이션 개발 시도는 분명히 빠르게 진행되지 않았다. 실제로 C++ 원시코드와 ISAPI 는 더 빨랐다. 개발자가 개발을 시작하기 전에 IIS SDK 와 인프라이즈의 웹 사이트를 조심스럽게 살펴보지 않는다면, 웹 마법사 기능과 웹 도움말 부분의 문제점은 개발자를 괴롭힐 것이다.



PowerBuilder 6.0 은 이전 버전에 비해 개선되었지만, 여전히 개선될 여지가 많이 남아있다. PowerBuilder 의 핵심인 DataWindows 는 Visual Basic 의 새로운 드랙앤드롭 데이터베이스 툴에 비교하면 상당히 번잡한 것처럼 보인다. 새로운 디버거는 이전 버전보다 나아졌지만, Visual Basic 또는 Delphi 의 디버깅 수준에는 못 미친다.

PowerBuilder 의 웹 개발 모델은 PowerBuilder 개발 환경에서 최악이라 할 수 있다. PowerBuilder 웹 모델은 배우기 쉽지만, 웹 사이트를 실시간으로 디버깅할 수 없기 때문에, 사용하기 불편하다. 긍정적인 면은, PowerBuilder 가 뛰어난 통합 보고서 작성 솔루션과 완벽한 온라인 도움말을 제공한다는 것이다.

성능 결과 (요약)

Visual Basic 과 Delphi 간의 성능 비교는 사실 무승부인 셈이다. 두 제품은 비교적 우수한 머신 코드 컴파일러를 제공한다. Visual Basic 프로그래밍은 ODBC 와 ADO 데이터베이스 접속을 제공하며, 이 부분은 Delphi 의 자체적인 BDE 접속보다 더 빠르다. 개발자는 Delphi 에서도 순수 ODBC 와 ADO 를 사용하여 더 나은 성능을 얻을 수 있지만, 대부분의 비주얼 지원 기능을 포기해야 한다. Delphi 의 순수 ISAPI 웹 모델은 Visual Basic 의 COM 기반의 모델보다 빠르지만, 두 제품 모두 매우 빠르며, Visual Basic 웹 사이트는 멀티 프로세서 머신에서 확장성이 더 뛰어나다. 두 제품의 컴파일러는 놀라울 정도로 빠르며, 순식간에 컴파일된다.

PowerBuilder 는 성능 면에서는 감히 나서지 못한다. 이 제품은 클라이언트/서버에서 느리며, 3 계층 개발에서는 더 느리고, 웹 애플리케이션에서는 거의 정지 상태이다. ISAPI 연결은 작동하지 않으며, 이 때문에 성능이 크게 저하된다.

기능성 결과 (요약)

Visual Basic 은 여러 중요한 부문에서 빛을 발하고 있다. 디버거는 다양한 기능 면에서 탁월하다. 디버거는 COM 호출과 SQL Server 스토어드 프로시저를 하나씩 진행할 수 있다. Visual Basic 만이 레지스트리와 씨름할 필요없이 IIS 애플리케이션을 디버깅할 수 있었다. 마찬가지로 Microsoft Transaction Server (MTS) 컴포넌트도 쉽게 디버깅할 수 있다. Visual Basic 은 개발 환경을 확장할 수 있는 가장 완벽한 자동화 모델을 제공한다. Visual Basic 은 비교 제품 중에서 유일하게 순수 Alpha 코드를 생성할 수 있기 때문에, 매우 빠른 웹 서버를 개발하는데 유용하다.

Visual Basic 은 가장 막강한 “엔터프라이즈 개발 기능”을 번들하고 있다. Enterprise 에디션에는 버전 관리 툴인 Source Safe, SQL Server 6.5, SNA Server, Microsoft Transaction Server, Microsoft Repository, Visual Modeler 와 Microsoft Message Queuing 서버 등이 번들되어 있다. Visual



Basic 은 표준 관계형 데이터베이스 인터페이스 외에도 CICS, IMS, AS/400 과 VSAM 등의 데이터 소스에 대한 인터페이스를 제공한다.

Delphi 는 Visual Basic 또는 PowerBuilder 에서 제공되지 않는 몇 가지 기능을 제공한다. 이 제품은 ISAPI, NSAPI, CGI 와 WIN-CGI 를 모두 지원한다. PowerBuilder 와는 달리, 개발자가 웹 사이트에 있는 패치를 설치하면 ISAPI 인터페이스는 실제로 작동을 한다. 또한 Delphi 는 내장된 어셈블러, 포인터 지원과 쓰레드 애플리케이션 지원 기능을 제공한다. 그러나 Delphi 는 다른 기능을 가장 빈약하게 제공하고 있다. 버전관리 기능이 제공되지 않으며, 거의 사용되지 않는 InterBase 가 SQL 개발 플랫폼으로 제공된다.

PowerBuilder 의 번들 기능(주로 ObjectCycle 과 QL Anywhere)은 그다지 매력적이지 않다. PowerBuilder 는 전통적인 SQL 데이터 소스 외에 Lotus Notes 에 대해 자체적인 접속 기능을 제공한다. PowerBuilder 는 유닉스 플랫폼에서 실행 파일을 만들 수 있는 유일한 제품이었지만, 한글은 지원하지 않는다. 더욱이, Visual Basic 또는 Delphi 는 브라우저가 설치된 모든 플랫폼에서 웹 애플리케이션을 지원할 수 있지만, PowerBuilder 는 웹 사이트 개발 면에서 간신히 지원할 뿐이다.

결론과 권고 사항

Visual Basic 은 현재 출시된 제품 중에서 가장 강력한 엔터프라이즈 개발 툴이다. Visual Basic 은 훌륭한 성능을 보유하고 있으며, 가장 사용하기 쉽고 비교될 수 없는 엔터프라이즈 기능들을 제공한다. 새로운 OLEDB 드라이버들은 테스트한 프로그램 중에서 가장 빠른 데이터 접속 속도를 보였다. 새로운 데이터베이스 툴은 가장 강력한 데이터베이스 프로그래밍 툴이라고 단정할 수 있다. Visual Basic 은 COM 관련 프로그래밍 작업에 가장 적합한 제품이다. 비교될 수 없는 디버깅 능력과 순수 COM 객체 모델을 보유하고 있어 ActiveX 컨트롤과 Microsoft Transaction Server 컴포넌트를 간단하게 작성할 수 있다. 새로운 ADO 지원 기능과 Microsoft Transaction Server 통합 기능으로 다계층 구조의 애플리케이션을 쉽게 개발할 수 있다. 웹 개발의 경우, Visual Basic 은 ASP, IIS 와 통합되어 있어 이미 이 플랫폼을 사용하고 있는 많은 개발자들에게는 필수적인 제품이 될 것이다.

Delphi 는 Visual Basic 과 유사한 성능을 보이지만, Visual Basic 의 매력적인 유저 인터페이스와 드랙앤드롭 데이터베이스 프로그래밍 툴이 부족하다. 우리는 Borland Desktop Engine 이 Visual Basic 의 OLEDB 드라이버보다 더 느리며, 안정성이 부족하고 조작하기 힘들다는 것을 발견했다. Delphi 의 ActiveX 와 COM 컴포넌트는 Visual Basic 에 비교될만한 성능이지만, 프로그램하기는 더 어렵다. Delphi 는 심도깊은 프로그래밍에서는 어느 정도의 장점을 가지고 있지만, 이와 같은 경우에는 대부분의 프로그래머들은 C++ 형식의 프로그래밍을 더 선호할 것이다.



PowerBuilder 는 윈도우 플랫폼에서 어느 것을 개발하던 올바른 선택이 아니다. 클라이언트/서버 환경에서는 그래도 참을 만 하지만, 웹 또는 3 계층 개발에서는 도저히 참을 수 없을 정도다. 성능 문제, 버그와 빈약한 디버거(6.0 에서도 여전히 좋지 않다)로 인해 웹 개발에는 적합하지 않다.

CLIENT/SERVER 개발 환경

엔터프라이즈 개발의 철칙은 클라이언트 서버 프로그래밍이다. 윈도우 95 또는 윈도우98 에서 실행되는 클라이언트 애플리케이션은 네트워크를 통해 데이터베이스 서버에 연결된다. 클라이언트/서버 프로그래밍 지원에 대하여 각각의 툴을 평가하기 위하여, 우리는 다음과 같은 4 가지 필수적인 기능들을 검토했다:

1. 데이터베이스 통합. 개발자가 개발 환경 내에서 SQL 또는 비 SQL 데이터 소스에 얼마나 쉽게 접속할 수 있는가? 개발자가 얼마나 쉽게 데이터베이스 질의를 하고 폼과 보고서를 작성할 수 있는가?

2. 스토어드 프로시저. 개발 환경 내에서 얼마나 쉽게 스토어드 프로시저를 조작할 수 있는가? 스토어드 프로시저를 사용하는 코드를 얼마나 쉽게 작성하고 디버깅할 수 있는가?

3. 보고서 작성. 완성된 애플리케이션의 일부로 실행될 수 있는 WYSIWYG 보고서를 얼마나 쉽게 작성할 수 있는가?

4. 개발 환경의 확장. 새로운 ActiveX 컨트롤과 COM 컴포넌트를 얼마나 쉽게 작성할 수 있는가? 써드파티 COM/ActiveX 컴포넌트를 얼마나 쉽게 툴에 통합시킬 수 있는가? 커스텀/전용 컴포넌트와 툴 애드인 유틸리티들을 얼마나 쉽게 사용할 수 있는가?

데이터베이스 통합

Visual Basic 의 새로운 Visual Database 툴은 데이터베이스 접속성 면에서 Delphi 와 PowerBuilder 를 훨씬 앞서고 있다. 데이터베이스를 언제라도 데스크톱에서 이용할 수 있다. 조정이 가능한 (dockable) “데이터 뷰(Data View)” 창은 익스플로러 방식으로 데이터베이스를 살펴볼 수 있으며, 데이터베이스 객체들을 프로그래밍 환경으로 드랙앤드롭할 수 있다. 데이터 뷰의 팝업 메뉴를 이용하여 개발 환경 내에서 데이터베이스 객체를 생성하거나 변경할 수 있다. 테이블, 뷰, 스토어드 프로시저와 데이터베이스 다이어그램은 언제라도 간편하게 조작할 수 있다.

새로운 “Data Environment”는 스토어드 프로시저와 커스텀 질의와 같은 비시각적인 프로그래밍 요소를 가져다 놓을 수 있는 장소를 제공한다. Data Environment 는 특정



프로그램이 사용하는 데이터베이스 객체에 대하여 간단하게 살펴볼 수 있으며, Data View 는 데이터베이스의 전체적인 상태를 살펴볼 수 있다. 또한 Data Environment 는 데이터베이스 계층구조를 구성하여 보고서를 상세하게 작성할 수 있는 기능을 가지고 있다. 개발자는 Data Environment 에서 데이터베이스 객체들을 끌어와서 데이터베이스 폼, 깔끔한 WYSIWYG 보고서 작성기와 같은 비주얼 애플리케이션 요소에 놓을 수 있다. 마우스 오른쪽 클릭 기능을 사용하여, 폼에서 데이터가 표현되는 방법(바운드 컨트롤, 데이터 그리드 또는 계층구조식 그리드)을 간단하게 선택할 수 있다.

PowerBuilder 는 Visual Basic 이 개발 환경 내에서 할 수 있는 작업 중 대부분을 할 수 있지만, 거의 통합되지 않았거나 이용하기가 쉽지 않다. 개발자는 직접 조작하기보다는 PowerBuilder 의 번거로운 인터페이스의 다이얼로그 박스들을 돌아다녀야 한다.

Delphi 는 유명한 SQL 데이터베이스와 비교적 통합이 되어 있지 않다. Delphi 에 내장된 Database Desktop 은 Delphi 와 거의 통합되지 않았으며, 데이터베이스 조작과는 거리가 멀다. Database Desktop 은 Paradox 데이터베이스를 조작할 수 있지만, SQL 서버와 오라클 데이터베이스는 살펴볼 수만 있을 뿐이다.

스토어드 프로시저의 사용

스토어드 프로시저는 보안, 비즈니스 로직과 데이터 무결성을 보장하기 위하여, 그리고 성능을 향상시키기 위하여 널리 사용된다. 개발 툴들은 적어도 스토어드 프로시저를 자체적인 프로그래밍 객체로 포장하는 정도의 지원은 한다.

Visual Basic 은 스토어드 프로시저를 가장 잘 지원한다. 특히 마이크로소프트의 SQL 서버의 경우는 더 말할 필요가 없다. 간단한 임포트 작업 후에, 우리는 스토어드 프로시저가 Visual Basic 의 메쏘드인 것처럼 사용할 수 있었다. Data View 에서 더블 클릭만 하면, 에디터/디버거에서 스토어드 프로시저를 불러올 수 있다. 스토어드 프로시저를 호출하는 클라이언트 애플리케이션과 함께 소스 코드 컨트롤 내에 스토어드 프로시저를 통합시킬 수 있다. 다음은 스토어드 프로시저를 실행하는 Visual Basic 코드의 예다:

Visual Basic Stored Procedure Callcn.is_valid_publisher "9999"is_valid= cn.rs_is_valid_publisher(0)cn.rs_is_valid_publisher..Close

Delphi 가 스토어드 프로시저를 지원하는 것은 다소 기초적인 수준이다. 스토어드 프로시저는 다이얼로그 박스를 사용하여 Delphi 형식과 맵핑되는 인수와 함께 한 번에 하나씩 프로젝트 내에 링크된다. Delphi 개발 환경 내에서 스토어드 프로시저를



실행시킬 수 있지만, 변경시킬 수는 없다. 다음은 동일한 스토어드 프로시저에 대한 Delphi 구문이다:

Delphi Stored Procedure Callwith is_valid_publisher_sp do begin ParamByName('@a').AsString := '9999'; Open; Is_valid := Fields[0].AsInteger; Close; end;

PowerBuilder 는 스토어드 프로시저에 대하여 시각적인 지원이 거의 없다. 스토어드 프로시저를 프로그래밍 객체로 살펴보거나 임포트할 수 없는 대신에, 스토어드 프로시저를 호출하는 특수 구문을 제공한다:

PowerBuilder Stored Procedure Calllong id declare is_valid_publisher_sp procedure for is_valid_publisher @id=:id;execute is_valid_publisher_sp;fetch is_valid_publisher_sp into :is_valid;close is_valid_publisher_sp;

이와 같은 방식은 나름대로 장점과 단점을 가지고 있다. Embedded SQL 에 친숙한 프로그래머들에게는 편안하게 생각될 수 있지만, 비주얼 프로그래밍/객체 지향 지식을 가진 프로그래머들에게는 어려울 것이다.

폼 빌딩

Visual Basic 은 새롭게 드랙앤드롭 데이터베이스 기능을 통합했기 때문에, Delphi보다 앞서있다. 두 제품 모두 기본적인 데이터베이스 폼 마법사 기능을 제공하지만, Visual Basic 은 질의를 폼에 드랙앤드롭하기만 하면 되기 때문에 더 쉽다. Visual Basic 내에서 폼을 변경하는 것은 새로운 컨트롤을 작성하고 이름을 부여하고 연결하는 3 개 작업에서 1 개 작업으로 줄어서 훨씬 더 쉽다. 또한 두 제품 중 어느 제품도 확실한 우위를 보이지는 않지만, Visual Basic 은 약간 더 많은 컨트롤들을 포함하고 있다. Visual Basic 은 커스텀 데이터 소스를 지원하는 것이 약간 더 쉽고, 폼 마법사 기능에서 이 기능을 지원한다. Delphi 도 커스텀 데이터 소스를 지원하지만, 자연스럽게 통합시키기 위해서는 더 많은 작업이 필요하다.

Visual Basic 은 순수 객체 모델로 COM/ActiveX 객체 모델을 채택하고 있다. Visual Basic 과 ActiveX 컨트롤의 완벽한 통합을 다른 개발 툴에서 기대하기는



힘들다. Delphi 디자이너들은 ActiveX 컴포넌트를 사용할 수 있도록 노력을 많이 했지만, Visual Basic 에 비해서는 몇 가지 불충분한 점을 가지고 있다. Delphi 는 Visual Basic 의 object browser 와 같은 기능이 없으며, 팝업 에디터의 도움은 Visual Basic 에디터에서와 같이 자연스럽거나 강력하지 못하다. Delphi 는 변수 선언에서 팝업 기능이 없으며, 메쏘드 호출의 팝업은 Visual Basic 에서 제공하는 것처럼 인수 정의를 원활하게 하지 못한다. Pascal 은 Basic 이 할 수 있는 선택적인 인수(optional arguments), 이름별 인수 패싱(argument passing) 또는 이름별 호출 을 할 수 없기 때문에, 일부 컨트롤들은 사용하기 상당히 어렵다.

버전 6.0 에서, Visual Basic 은 Internet Explorer 를 중심으로 DHTML 이라고 하는 새로운 폼을 도입하고 있다. 이 폼들은 새로운 HTML 헬프 시스템과 유사하게 로컬레서 실행되지만 웹 사이트처럼 보인다. 이 폼들은 전통적인 Visual Basic 폼과 유사한 이벤트 처리 모델을 사용하는 동시에 Internet Explorer 의 풍부한 포맷팅(rich formatting) 기능을 활용한다.

Delphi 는 Visual Basic 이 아직 지원하지 않는 세밀한 수준까지의 통제 기능을 제공한다. 대부분의 Delphi 자체 컨트롤들은 소스 코드가 제공되며, 결과치 폼 객체에 정적으로 링크된다. 문제를 발견하기 위하여 하나씩 진행할 수 있다는 장점 외에도, 폼을 약간 생기있게 만들 수 있다. 소스를 읽음으로써 Delphi 에 숙련될 수 있다. 개발자는 코드 재사용을 위한 자르고 붙이기 기능의 소스를 사용할 수도 있다.

PowerBuilder 6.0 은 유저 인터페이스를 말끔하게 만들었지만, 지난 버전의 효과적이지 못한 모델 인터페이스를 거의 그대로 답보하고 있다. PowerBuilder 는 여전히 한 번에 한 기능만을 보여주고 있다. 이미 열려있는 객체에 클릭하려고 하면. 그 객체로 이동하기 보다는 에러 메시지를 보여준다. 툴바는 이상한 모양을 변했다. 개발자는 많은 작업이 툴바에서만 지원되기 때문에, 여전히 툴바를 이용해야 한다.

PowerBuilder 는 ActiveX/COM 통합 측면에서 Delphi 와 Visual Basic 에 상당히 뒤처져 있다. 오직 다이나믹 디스패치(dynamic dispatch)만 지원된다. Visual Basic이 컴파일 시에 안전하게 포착할 수 있는 에러들이 PowerBuilder 에서는 런타임 에러를 발생시킨다. 또한 정적 타이핑(static typing)없기 때문에 성능이 저하되며, 높은 가격에도 불구하고 컨트롤은 가장 빈약한 편이다.

보고서 작성

종이없는 사무실이라고 해서, 윗 사람들이 보고서를 원하지 않는 것은 아니다. 보고서 작성기는 클라이언트/서버 프로그래밍 툴의 중요 기능이다.



멋진 드랙앤드롭 데이터베이스 통합 덕분에 Visual Basic 은 이제 가장 매력적인 보고서 작성기를 자랑하고 있다. 새로운 보고서 디자이너는 ActiveX 컴포넌트를 추가하기만 하면 쉽게 확장될 수 있다.

그럼에도 불구하고, 보고서 작성기는 Visual Basic 의 화려한 레파토리에서 약점으로 남아있다. 새로운 보고서 폼은 실행화일에서만 사용될 수 있으며, 크로스 탭 보고서는 여전히 Crystal Reports 를 사용해야 한다.

Delphi 의 보고서 작성기는 빈약한 웹 통합과 같은 부분에서 많은 약점을 공유하고 있다. Delphi 의 보고서 작성기는 도움말이 제대로 제공되지 않지만, 소스 코드는 제공된다.

PowerBuilder 는 가장 강력한 보고서 작성 기능을 제공하며, 웹 애플리케이션에서 직접 사용할 수 있는 유일한 제품이다. PowerBuilder 는 크로스 탭 보고서, 네스티드 보고서(nested reports)와 다른 멋진 기능을 제공한다.

컴포넌트 작성

RAD 툴은 컴포넌트 사용제품으로 잘 알려져 있다. 최신의 RAD 툴은 새로운 소프트웨어 컴포넌트를 만들 수 있는 능력도 제공한다. 기업들은 자신의 활동에 맞는 컴포넌트를 사용하여 클라이언트/서버 프로그래밍 프로젝트를 향상시킬 수 있다.

자신의 컴포넌트를 작성할 수 있다는 것은 클라이언트/서버 개발자들에게는 비교적 새로운 개념이다. 개발툴들은 컴포넌트를 완성된 제품 내에 신속하게 통합시킬 수 있는 능력으로 유명해졌지만, 툴 자체 내에서 컴포넌트를 작성하는 것은 어렵거나 불가능한 경우가 많다. PowerBuilder 가 이와 같은 경우에 해당하여, 새로운 컨트롤과 다른 컴포넌트를 작성하는 것은 대개 비효과적이다. Delphi 와 Visual Basic 은 모두 컴포넌트 생성 부분에서 매력적이다.

Visual Basic 은 새로운 컨트롤을 쉽게 만든다. 애플리케이션 폼을 작성하는데 사용되는 폼 디자이너로 컨트롤을 개발한다. 컨트롤들은 순수 ActiveX 컨트롤로 모든 ActiveX 컨테이너에서 바로 사용할 수 있다. DLL 의 Visual Basic 컨트롤은 보통 Delphi 와 PowerBuilder 의 컨트롤보다 크기가 더 작다.

Delphi 는 다중 ActiveX DLL 을 포함하는 프로젝트를 지원하지 않는다. 개발자는 개발하거나 디버깅하는 각각의 컴포넌트에 대하여 Delphi 의 인스턴스를 열어 주어야 한다. 개발자는 프로세스 간의 ActiveX 호출을 쉽게 파악할 수 없다. 개발자가 효과적으로 디버깅하려면, 모든 컴포넌트를 동일한 프로세스에 로드되게 만들어야 한다. 이 때문에, 디버깅 세션을 설정하는 수고를 들여야 한다. Delphi 컴포넌트는 Visual Basic 컴포넌트보다 크기가 더 크지만, 별도의 런타임 DLL 이 필요한 것은 아니다.



PowerBuilder 컴포넌트는 다른 PowerBuilder 애플리케이션에서만 사용된다. 다양한 개발 언어를 사용하는 엔터프라이즈 환경에서 PowerBuilder 컴포넌트를 사용하는 것은 가장 큰 문제점이다. 컴포넌트는 정적으로 형식을 정하거나 디버깅할 수 없다. 개발자는 별도로 “ PowerBuilder deployment packs”을 설치한 컴퓨터에서 컴포넌트를 사용할 수 있을 뿐이다.

엔터프라이즈 개발을 위한 RAD

동일한 방식으로 테스트한 각각의 툴들은 엔터프라이즈 소프트웨어 개발에 적합하다고 주장하고 있다. 이 말이 의미하는 뜻이 다양하지만, 우리는 여기에서 3 가지 필수적인 부분으로 엔터프라이즈 소프트웨어 개발을 정리하였다:

1. 새로운 종류의 서버를 개발할 수 있는 능력. 확장성과 지원 능력의 경우, 엔터프라이즈 WAN 을 통해 접속되는 “비즈니스 로직” 컴포넌트를 작성하는 것이 종종 유용하다. 이 컴포넌트들은 Microsoft Transaction Server 와 같은 트랜잭션 관리 소프트웨어에서 실행될 수도 있다.

2. 비전통적인 데이터 소스를 지원할 수 있는 능력. 엔터프라이즈 정보 중 비교적 작은 비율만이 관계형 데이터베이스에 존재한다. 엔터프라이즈 솔루션은 비 관계형 데이터베이스, 플랫 파일과 다른 비 SQL 데이터 소스에서 데이터를 통합할 수 있어야 한다.

3. 수십 명의 개발자가 작업하는 팀 프로젝트를 지원할 수 있는 능력. 소스 코드와의 통합이 필수적이지만, 모델링 툴과 컴포넌트 리파지토리와 같은 다른 툴들도 대규모 팀 프로젝트에서 인기를 얻고 있다.

새로운 서버 개발

RAD 툴이 지원해야 하는 새로운 분야는 “3 계층” 애플리케이션의 디자인이다. 3 계층 로직은 클라이언트, “비즈니스 로직” 서버와 최후위 데이터베이스 서버로 구성된다.

Delphi 와 Visual Basic 의 3 계층 디자인은 DCOM 을 기반으로 하고 있는 반면, PowerBuilder 는 자체적인 전용 분산 객체 모델을 제공한다. 이와 같은 차이는 Delphi와 Visual Basic 이 윈도우에 초점을 맞추고 있는 반면에, PowerSoft 는 다중 플랫폼을 지향하고 있는 탓이다.

Visual Basic 에서 3 계층 로직을 개발하는 것은 놀라울 정도로 쉽다. COM 은 Visual Basic 의 순수 객체 모델이기 때문에, 분산형 객체를 개발하는 것은 로컬 객체를 개발하는 것만큼이나 쉽다. 다양한 COM 컴포넌트들이 동일한 작업영역에서



작성된 후에 코드가 제대로 작동하면 즉시 분산될 수 있다. 디버거는 다중 컴포넌트 테스트에 쓰일 수 있는 강력한 기능을 많이 가지고 있다. COM 호출을 하나씩 살펴보면, 프로세스를 이동하게 된다.또 다른 애플리케이션이 컴포넌트를 작성하면 그 애플리케이션이 디버거 환경에서 실행되지 않았을지라도 브레이크포인트(Breakpoints)가 작동할 수 있다. 이 기능은 NT 서비스가 사용하는 컴포넌트를 테스트하는데 매우 유용한 기능이다. 경우에 따라서는 번들된 Visual Studio 디버거를 이용하는 경우가 있을 수 있지만, 이렇게 뛰어난 멀티쓰레드 디버거가 Visual Basic 개발 환경에 통합되지 않았다는 것은 유감스럽다.

6.0 에서 간단하지만 중요한 장점은 CreateObject 에 두 번째 인수를 추가하여 컴퓨터 명세가 객체를 계속 만들 수 있게 한 것이며, 또 다른 기능 향상은 ADO 지원 기능을 추가한 것이다. ADO 는 서버에서 결과 값을 넘겨받아 클라이언트에서 이것을 볼 수 있게 한다. 새로운 스탠드얼론 ADO 데이터 소스는 데이터를 배열에 채워 넣기만 하면 만들어진다.

Microsoft Transaction Server 는 3 계층 애플리케이션을 신속하게 전개할 수 있는 대단한 제품이다. 개발자는 MTS 를 사용하여, 프로그래밍을 거의 하지 않고도 분산 트랜잭션 지원, 다양한 보안과 성능 관리 기능을 이용할 수 있다. Delphi 와 PowerBuilder 도 MTS 객체를 생성할 수 있지만, Visual Basic 은 MTS 컴포넌트를 가장 쉽게 개발할 수 있다. Object browser 에서 한 개의 속성을 설정하는 것만으로, COM 컴포넌트는 완전한 기능을 하는 MTS 컴포넌트로 만들어진다. Visual Basic 의 COM 디버깅 지원은 정말 대단한 장점이다. 개발자는 중간 계층이 전혀 존재하지 않는 것처럼 간편하게 클라이언트 소프트웨어에서 MTS 를 통해 서버 컴포넌트를 이용할 수 있다. 이에 반해, Delphi 는 클라이언트 측과 서버 측에 대하여 두 개의 개발 환경을 사용해야 하며, PowerBuilder 는 디버깅 기능을 전혀 지원하지 않는다.

Delphi 에서 3 계층 로직을 작성하는 것은 약간 더 어렵다. DCOM 객체를 쉽게 만들 수 있지만, 순수 Delphi 객체는 프로세스에서 벗어난(out-of-process) 클리언트로 간단하게 전달될 수 없다. 타입 라이브러리는 제공된 라이브러리 툴을 사용하여 작성되어야 한다. 너무 어려운 것은 아니지만, 도움말은 개발자를 한 순간 어리둥절하게 만들 수도 있다.

Delphi 는 IProvider 인터페이스에서 ADO 와 유사한 기능을 제공한다. 그러나 이 인터페이스는 Delphi 에만 해당되며, 마이크로소프트가 제시하는 ADO 모델만큼 많은 써드파티들이 지원하지 않는다. 동일한 작업영역에서 한 개 이상의 DLL 을 작성할 수 없기 때문에, 개발자는 별도의 세션을 열어 작업을 해주어야 한다. 디버거는 Visual Basic 과는 달리 프로세스 간의 COM 호출을 하나씩 지원할 수 없다.

PowerBuilder 는 Visual Basic 보다 쓰레딩에 대한 통제가 약하며, 다중 컴포넌트 환경에서는 디버거가 쓸모없다. PowerBuilder 의 방식은 단일 사용자, 분산 환경이



아닌 곳에서 테스트하여, 이것이 분산형의 다중 컴포넌트 환경에서도 작동하기를 원하는 방식으로 그다지 바람직한 방식이 아니다.

PowerBuilder 의 느린 성능은 서버 애플리케이션에서 충돌을 하곤 한다. 성능이 좋은 클라이언트에서, 개발자는 PowerBuilder 스크립트를 실행하는 일부 프로세서 사이클을 전용으로 사용할 수도 있지만, 수 백 명의 사용자를 동시에 지원하는 서버에서는 PowerBuilder 를 사용할 수 없을 것이다.

비 관계형 데이터 소스

대부분의 엔터프라이즈 데이터는 여전히 관계형 데이터베이스가 아닌 플랫 파일, 레거시 데이터베이스, 디렉토리 서버 또는 메시징 서버와 같은 새로운 데이터 저장소에 존재한다. 비교 제품들은 각각 프로그래머가 관계형 데이터베이스가 아닌 데이터 소스에 컨트롤을 연결할 수 있도록 하고 있다.

Visual Basic 과 PowerBuilder 는 유사한 방식으로 해결책을 제시하고 있다. 먼저, 데이터 소스에서 가져온 데이터를 일반적인 레코드 컨테이너 객체에 옮기고, 옮겨진 데이터를 클라이언트로 전송한다. 이 프로세스의 핵심은 SQL 소스에 연결될 필요가 없는 레코드 컨테이너 객체를 보유하는 것이다.

Delphi 의 방식은 좀더 전통적인 OOP 패턴을 채택하고 있다: 자신의 데이터 소스를 만들려면, 개발자는 자신의 커스텀 객체에 IProvider 인터페이스를 구현해야 한다. 이 방식은 OOP 프로그래머들에게는 친숙하지만, 처음에 익숙해지기에는 시간이 더 많이 걸리고 어렵다. 이 방식의 장점은 개발자가 더 높은 성능으로 더 유연한 데이터 소스를 만들 수 있다는 것이다. Visual Basic 도 이와 같은 방식을 지원하여 OLEDB 소스를 만든다.

비관계형 데이터 소스를 사용하는 단점은 클라이언트에 데이터를 제공하기 위하여 서버에 데이터를 넣어야 한다는 것이다. 그 동안 개발자들은 ODBC 를 통해 비관계형 데이터를 넣었지만, ODBC 는 이와 같은 애플리케이션에 적합한 것이 아니다. 새로운 OLEDB/ADO 모델이 비관계형 SQL 데이터 소스를 처리하기에 더 유연한 패턴을 제공한다.

우리는 모든 비교제품들이 ADO 객체 모델에 접속하는 코드를 작성하여 OLEDB 데이터 소스를 처리할 수 있다는 것을 발견했다.

Visual Basic 에서의 ADO 1. Dim rs As New ADODB.Recordset2. Dim r As String3. rs.Open "select * from publishers",

"DSN=pubs;UID=sa;PWD=;DATABASE=pubs"4. While Not rs.EOF



5. r = r & rs(0)6. rs.MoveNext7. WendVisual Basic 은 ADO 를 완벽하게 지원하는 유일한 개발 환경이었다. ADO 소스는 모든 데이터베이스 브라우저와 마법사 기능에서 지원된다.

Delphi 에서의 ADO 1 Var2 rs: Recordset;3 r: string;4 Begin5 rs:= CoRecordset.Create;6 rs.Open('select * from

publishers','DSN=pubs;UID=sa;PWD=;DATABASE=pubs'7 ,adOpenForwardOnly,adLockReadOnly,adCmdText);8 while not rs.EOF do9 Begin10

r := r + rs.Fields[0].Value ;

11

rs.MoveNext;

12

end;

Delphi 컨트롤에 ADO 소스를 연결하려면 상당한 노력이 필요했다. 포장용 객체(wrapper object)를 만들어, 표준 ADO 임포트에서 최악의 상황을 피할 수 있었고 데이터 바인딩도 단순화시킬 수 있었다. Delphi 에서 ADO 를 코딩하는 것은 Visual Basic 보다는 불편했다. 6 번 줄에서, Visual Basic 과 PowerBuilder 에서는 기본적인 인수를 제공해야 한다는 것을 확인할 수 있다.

PowerBuilder 에서의 ADO1 OLEObject rs 2 string r3 rs = CREATE OLEObject 4 rs.ConnectToNewObject("ADODB.Recordset.1")5 rs.Open("select * from publishers",

"DSN=pubs;UID=sa;PWD=;DATABASE=pubs")6 do while Not rs.EOF7 r = r + rs.Fields[0].Value8 rs.MoveNext9 Loop

PowerBuilder 는 COM 인터페이스의 정적 형식을 지원하지 않는다. 간단한 ADO 프로그래밍 외에는 적합하지 않다는 것이 우리의 의견이다. 구문이 Visual Basic



만큼이나 간결하다는 장점이 있지만, 모든 구문 에러는 컴파일러가 아닌 런타임 시에 포착된다. 동적 타이핑으로 인해 성능이 저하되며, 외부 객체 모델의 구문을 살펴 볼 때에 팝업 도움 기능을 제공하지도 않는다.

팀 프로그래밍

비교제품들은 모두 다수 프로그래머의 엔터프라이즈 프로젝트를 목표로 하고 있다. 이것은 소스 코드 관리 기능이 통합되어 있어야 한다는 것을 의미한다. 제공되고 있는 신기능들은 미리 구성된 소프트웨어 컴포넌트의 관리 기능인 컴포넌트 리파지토리이다. 또한 많은 OOP 기반의 프로젝트들은 클래스 디자인을 위해 비주얼 모델링 툴에 의존하고 있다. 비주얼 클래스 디자인의 가장 유명한 방법론은 Unified Modeling Language (UML)이다. UML 은 이전의 Booch 과 OMT 방법론보다 선호되고 있다.

Visual Basic 과 PowerBuilder 는 모두 제품에서 소스 코드 관리 시스템을 지원할 뿐만 아니라 다른 소스 코드 관리 시스템에 대한 연결 모듈을 제공하고 있다. Visual Basic 은 널리 사용되고 있는 SourceSafe 제품을 제공하고 있는 반면에, PowerBuilder 는 그다지 알려지지 않은 ObjectCycle 을 제공하고 있다. SourceSafe는 두 제품 중에서 가장 사용하기 쉽고 프로젝트 관리자와 잘 통합되어 있다. ObjectCycle 은 관계형 데이터베이스에서 사용할 수 있는 유일한 버전 관리 시스템이다.

Delphi 는 소스 코드 관리 시스템을 제공하지 않지만, 연결 기능은 가지고 있다.

Visual Basic 은 가장 완벽한 리파지토리 기능을 제공하며, 비주얼 모델링 툴을 유일하게 제공하고 있다. Visual Basic 은 Microsoft Repository 를 사용하며, Microsoft Repository 는 다양한 언어와 객체 모델을 모두 지원한다. Visual Basic 은 컴포넌트를 삽입하고 추출하는 GUI 인터페이스를 제공하는 Visual Component Manager 를 제공한다. Microsoft Repository 자체는 관계형 데이터베이스를 이용한다. 이와 같은 방식으로 비정규 보고서 작성과 확장이 쉽다. 비주얼 모델링 툴은 Rational Rose for Visual Basic 을 통합한 것으로, Rational Rose 는 현재 제공되는 비주얼 모델링 툴 중에서 가장 유명하다.

이에 반해, PowerBuilder 와 Delphi 는 자신의 객체만을 위한 리파지토리를 제공한다. Delphi의 리파지토리는 관계형 데이터베이스를 이용하기 않기 때문에, 보고서 작성이 쉽지 않다. 두 제품 모두 비주얼 모델링 툴을 제공하지 않는다.

또한 Visual Basic 은 Application Performance Explorer 를 제공한다. 이 툴은 개발자가 다양한 데이터베이스와 인터페이스(예를 들면, ADO 와 ODBC)를 사용하여 2계층과 3 계층 솔루션의 다양한 구성 환경의 성능을 테스트할 수 있게 한다. 이 기능은 프로그래밍을 시작하기 전에 대안들을 이해하고 테스트할 수 있는 유용한 기능이다.



웹 사이트를 위한 RAD

대부분의 새로운 엔터프라이즈 프로그래밍 프로젝트는 웹을 필수적인 컴포넌트로 간주하고 있다. 클라이언트/서버는 기존 엔터프라이즈 하부구조의 중요한 부분으로 남아 있지만, RAD 툴은 이제 웹을 기반으로 하는 애플리케이션을 구축하는 방향으로 조정하고 있다. 각각의 툴은 HTTP 요청을 해석하고 HTML 을 사용하여 디스플레이될 수 있는 데이터베이스 질의를 디자인하기 위한 그래픽 인터페이스를 제공한다. 그러나, 어느 툴도 강력한 HTML 에디터 또는 HTML 폼 디자이너를 제공하지 않고 있다. 물론, Visual Basic 은 InterDev, FrontPage 등의 외부 툴을 쉽게 사용할 수 있다. 또한 각각의 제품은 GUI 데이터베이스 폼과 보고서가 Netscape Plugins 또는 ActiveX 컨트롤로 브라우저에서 사용될 수 있게 한다.

Visual Basic 은 현재까지 가장 쉽게 웹 사이트로 전개될 수 있는 제품이다. 구성을 변경할 필요도 없고, 웹 기동(web startup) 마법사 기능은 변경 내용이 즉시 반영되는 웹 사이트를 만들어 낸다. 애플리케이션을 디버깅하면, 웹 사이트가 실행되고 동시에 Internet Explorer 에서 웹 사이트를 연다. 정말 환상적인 기능이다. InterDev 사용자들은 Active Server Pages (ASP)와 Visual Basic 의 완벽한 통합에 만족할 것이다. Visual Basic 으로 집중 사용되는 페이지를 다시 작성하여 ASP 사이트를 간단하게 조정할 수 있다. 완성된 애플리케이션은 ASP 에서 COM 객체로 실행되기 때문에, 완성된 애플리케이션은 자체적으로 등록하는 COM 객체, 매니저 COM 객체, Visual Basic 런타임 DLL, Visual Basic 이 자동으로 생성하는 ASP 페이지로 구성된다. 완성된 웹 사이트의 성능은 정말 빠르다.

Visual Basic쿠키(cookies)를 사용하여, 사용자 세션을 쉽게 추적할 수 있다. 표준 ASP 모델을 따라, 사용자가 웹 애플리케이션에 처음으로 접속하면, 세션 쿠키가 자동으로 생성된다. 웹 객체는 세션 시스템 객체를 참조하여 현재 세션에 대한 정보를 조회하고 저장한다. 세션은 자동으로 종료된다. 다른 툴을 사용하는 개발자들은 쿠키가 사용되어야 한다면, 쿠키 추적 코드를 작성해야 한다. 특히 PowerBuilder 로 쿠키를 추적하는 것은 너무 힘든 작업이다.

Delphi 는 작업한다는 것이 도전이었다. Delphi 에서는, 어떤 것도 지원되지 않았다. 다음은 Delphi 로 작업해야 하는 경우에 발생하는 문제와 해결책이다.

1. “안녕하십니까?” 웹 사이트를 구현해보자. 그다지 나쁜 편은 아니다. Visual Basic과는 달리, 웹 사이트 마법사 기능은 작동하는 웹 사이트를 만들지 않을 뿐만 아니라, 매뉴얼을 보면서도 1 시간 내에 만들 수도 없다.

2. 사이트에 과부하를 주면 다운된다.



3. 디버거에서 IIS 를 실행하기 위한 지시를 따라 해 보자. 작동하지 않는다. IIS 매뉴얼을 참조하여 IIS 를 프로세스로 실행하라는 것을 알았다. 겨우 작동하였다.

4. 사이트는 아무런 도움이 안 되는 에러 메시지를 보이며 다운된다. 예제를 찾아보자. 샘플도 하나만 로드하면 작동하지만, 두 개를 로드하면 다운된다.

5. 인프라이즈 웹 사이트를 뒤져보자. 시스템 전역 IsMultithread 를 True 로 설정하지 못하는 웹 마법사 기능의 버그를 발견할 수 있다. “Multithread:=true”를 추가한다. 혹시나 해서, 매뉴얼에[서 IsMultithread 를 찾아보자. 매뉴얼에는 존재조차 없으며, 온라인 도움말에서 그 흔적을 겨우 발견할 수 있다. “스레드”에 대하여 온라인 도움말을 발견하려면, “thread” 탐색을 하고 발견할 수 있는 모든 정보를 읽는다.

6. 이제 10 개까지 로드될 수 있는 웹 사이트를 만들었지만 “too many connections error”로 다운된다. 매뉴얼에서는 어떤 도움도 받을 수 없다. 온라인 도움말에서 “ Max Connections”를 찾는다. 이제 “안녕하십니까?” 웹 사이트는 100 개의 쓰레드까지 작동한다.

7. 데이터베이스를 시작한다. 매뉴얼을 따라서 몇 번의 시도와 “ BDE out of memory”라는 에러가 반복된다. Delphi 를 다시 기동시킨다. “BDE Directory Locked” 에러가 발생한다. 처음부터 시작한다. 이 번에는, 처음의 에러에서 벗어나 작동을 한다.

8. 부하가 걸린 사이트는 “ duplicate database name” 에러를 발생시킨다. 기동 시에 유일한 데이터베이스 이름을 만들 수 있는 방법을 모색한다. 데이터베이스 세션이 자동으로 유일한 이름을 갖지 못하는 이유가 궁금하지만, 데이터베이스는 그 이름을 갖지 못한다.

9. 부하가 걸린 사이트가 이제는 “BDE out of memory” 메시지를 나타낸다. BDE administrator 도움말 파일을 찾는다. BDE 는 얼마나 많은 메모리가 필요한 것일까? 자료가 없다. 얼마나 많은 메모리를 사용하는 것일까? 자료가 없다. 시도와 실패의 연속이다. 약간 수정하면 몇 번의 에러 메시지가 발생한다. 결국 작동하는 패러미터들을 발견했다.

Delphi 의 장점은 IIS 이외의 웹 서버를 지원한다는 것이다. Active Server Pages 와는 통합되어 있지 않지만, 약간의 수고로 통합될 수 있다. Delphi 의 전개 모델은 비교 제품 중에서 가장 간단하다.

완성된 Delphi 애플리케이션은 일부 테스트에서는 뛰어나지만, 다른 테스트에서는 터무니 없이 뒤 처진다. Delphi 런타임 라이브러리는 SMP 컴퓨터에서 확장성이 좋지



않다. 한 개 이상의 프로세서를 잘 활용하지 못한다. 런타임 소스를 살펴보면, 다수의 “critical sections”이 Delphi 의 속도를 저하시키는 것을 알 수 있다.

서버 환경에서의 BDE 의 신뢰성은 문제가 될 수 있다. 가끔씩 메모리를 낭비하여, “BDE out of memory” 에러를 발생시키며, Delphi 애플리케이션이 작동을 멈추게 만든다. 한가지 해결책은 웹 프로세스를 다시 시작하여 BDE 를 깨끗하게 만들거나 BDE 을 사용하지 않는 것이다.

PowerBuilder 는 중요한 웹 사이트 개발에는 사용할 수 없다는 것을 입증했다. PowerBuilder 는 개발자가 브라우저에서 실행되는 애플리케이션을 디버깅할 수 없는 유일한 제품이다. 대신에, 각각의 기능은 스탠드얼론 애플리케이션으로 테스트한 후에, 개발자는 이것이 웹 브라우저에서 실행되기를 기대하는 수밖에 없다. 전개된 애플리케이션의 성능은 참담하다.

PB.Web 솔루션의 신뢰성은 끔찍할 정도다. 우리는 ISAPI 버전을 실행한지 몇 초도 지나지 않아서 웹 서버가 전부 다운된다. CGI 버전을 사용할 때 조차도, PowerBuilder CGI 부분에서 가끔씩 보호오류(protection faults)가 발생한다. 그래도 CGI 로는 웹 서버가 실행되기는 한다. 애플리케이션은 다른 보호 오류를 발생시킨다. 우리는 PB.Web 가 적당한 부하가 걸리는 웹 사이트에도 적합하지 않다고 생각한다

다른 두 제품과는 달리, PowerBuilder 웹 애플리케이션은 자체적인 프로세스에서 실행되어야 한다. 추가적인 부하로 서버 성능이 저하된다. 전개는 PowerBuilder 의 일부, 애플리케이션을 실행할 작은 실행파일, 실제적인 애플리케이션 코드를 위한 DLL, PowerBuilder 웹 라이브러리를 위한 DLL 과 이 모든 것을 연결하는 pbweb.ini 파일로 구성된다.

IIS 와 Netscape 3.51 를 각각 사용하여 ISAPI 와 NSAPI 버전을 테스트하는 경우, 우리는 얼마 지나지 않아 다운되었다. 사이베이스에서 조차도 CGI 를 사용하는 것 외에는 다른 해결책을 주지 못했다. CGI 의 성능은 정말 끔찍했다.

PowerBuilder 는 웹 애플리케이션에서 시각적으로 설계된 보고서를 효과적으로 사용할 수 있는 유일한 애플리케이션이었다. 모든 데이터 윈도우는 HTML 문자열로 출력되어, 웹 사이트에서 편하게 사용할 수 있다.

성능 결과Visual Basic Delphi PowerBuild

er

전체적인 성능 (큰 숫자가 더 좋은 성능)



전체 속도 PowerBuilder 와 비교한 속도

9.3 8.9 1.0

큰 숫자가 더 좋은 성능 (페이지/초)웹 Hello, world 120 230 11 (1)

Hello, world x 1,000 80 29 1.8 (1)

Hello, 프로그램 120 120 9.5 (1)

Shared State 110 230 9.5 (1,2)

웹 트잭션 레코드 삽입 58 110 2.5

23 개 레코드 질의 50 25 2.3

작은 숫자가 더 좋은 성능 (milliseconds)컴파일러 COM 호출 1.8 .70 290

Tak Function 5.9 5.4 210

거르기(Sieve) 17 8.2 490

순열(Permutations) 160 120 7,800

문자열 문자열 형성 140 37 820

모두 찾기(Find all) 0.4 11.0 21

전방위로 하나 찾기 4.4 3.2 0.7

후방위로 하나 찾기 3.4 3.4 1.0

모두 대체(Replace all) 100 100 1100

SQL 스토어드 프로시저 호출 2.8 4.1 4.0

구성된 질의 2.8 4.9 8.9

복잡한 질의: Compute median value

5.4 10.0 7.5

Visual Basic 과 Delphi 는 100 개 쓰레드의 ISAPI 연결, PowerBuilder 는 10 개 쓰레드의 CGI.



2 개의 200 MHz Pentium Pro 프로세서를 장착한 테스트 장비SQL Server 6.5Windows NT 4.0, 서비스 팩 3, 옵션 팩 (IIS 4.0)컴파일 최적화 기능 활성화1 CGI 애플리케이션 다운2 애플리케이션 전체 다운

Visual Basic 과 Delphi 는 모두 속도가 상당한 코드를 생성하는 머신 코드 컴파일러를 가지고 있다. 동일한 코드를 Delphi 로 컴파일하면 Visual Basic 으로 컴파일된 코드보다 약간 더 빠르지만, Visual Basic 의 컴포넌트가 Delphi 의 컴포넌트보다 더 빠르다. Visual Basic 의 OLEDB 기반의 데이터베이스 접속 컴포넌트는 Borland Database Engine 을 이용한 Delphi 데이터베이스 접속 컴포넌트보다 확실히 빠르다.

PowerBuilder 는 가장 느린 프로그램을 만들어 냈다. PowerBuilder 는 전체적인 속도에서 Visual Basic 보다 9 배나 느렸다. 원시 코드 속도에서는 Visual Basic 보다 50 배나 느렸다.

PowerBuilder ActiveX 컴포넌트는 Visual Basic 보다 200 배나 더 느렸다.

PowerBuilder 의 머신 코드 컴파일은 6.0 에서 더 느려졌다. 머신 코드 컴파일러가 만들어낸 코드가 느리기는 해도, PowerBuilder 의 p-code 보다는 훨씬 더 빠르다.

테스트 설명

Web Hello, world “Hello, world”를 동적으로 생성하는 웹 페이지. 이 테스트는 동적인 웹 페이지의 최소 부하를 보여준다. 100 개의 쓰레드를 사용하여 초당 페이지를 계산.

Hello, world x 1K

생성된 웹 페이지의 전송 부하를 보여준다. 100개의 쓰레드를 사용하여 초당 페이지를 계산.

Hello, 프로그램 큰 폼을 전송하는 시간과 응답을 하는 시간. 100개의 쓰레드를 사용하여 초당 페이지를 계산.

Shared State 프로그램이 실행된 후에 얼마나 많은 애플리케이션이 히트를 했는지를 보여주기 위하여 갱신된 애플리케이션의 카운트. 100 개의 쓰레드를



테스트 설명

사용하여 초당 페이지를 계산.

컴파일러 COM 호출 프로세스 중인 COM 컴포넌트를 1 만 번 호출

Tak(Integer) y 가 x 보다 크거나 같다면, Tak(x, y, z)는 z. 이것은 비회귀적인 중단 조건(non-recursive stopping condition). y 가 x 보다 작다면, Tak(x, y, z)은 Tak(Tak(x-1, y, z), Tak(y-1, z, x), Tak(z-1, x, y))

거르기(Sieve) 최초 십만 개의 정수 중에서 소수를 찾는다. 100 회를 반복.

순열(Permutations)

정수 0 에서 8까지 모든 순열을 찾는다. 이 알고리즘은 데이터 추출과 다른 최적화 코드에 적합하다. C++ 표준 라이브러리를 이용.

SQL 스토어드 프로시저 호출

간단한 스토어드 프로시저를 호출하여 레코드의 존재를 확인

간단한 질의 스토어드 프로시저 테스트와 동일한 질의, 그러나 스토어드 프로시저는 사용하지 않는다.

Compute Median 21 개 레코드 집합의 중심을 발견(Pubs.sales)

레코드 삽입 웹 페이지 히트에 대하여 40 바이트 레코드를 삽입. 100 개의 쓰레드를 사용하여 초당 페이지를 계산.

23 개 레코드 질의 SQL 서버에서 반환된 23 개 레코드 중에서 HTML 테이블을 생성(Pubs database, author). 100개의 쓰레드를 사용하여 초당 페이지를 계산.

문자열 문자열 형성 정수에서 변환된 1000 0 자의 문자열을 연결

전부 찾기 10,000 바이트 문자열에서 100건의 2 자 문자열을 발견

전방위 찾기 10,000 자 문자열의 끝에서 10바이트 문자열을



테스트 설명

찾기

후방위 찾기 뒤에서부터 시작하여 10,000 자 문자열의 처음에서 10바이트 문자열을 찾기

모두 대체 10,000바이트 문자열에서 한 자 문자열을 2 자 문자열로 대체



유용성 결과Visual Basic Delphi PowerBuilder

디버거 Excellent Good Fair컴파일 속도 (디버깅) Excellent Excellent Excellent컴파일 속도 (릴리스) Excellent Excellent Poor컴파일 경고/에러 Good Excellent Poor에디터 Excellent Excellent Fair언어 Good Good Good설치/전개 Good Excellent Poor마법사 기능 Good Good Good보고서 작성기 Excellent Fair Good질의 작성기 Excellent Fair Fair데이터베이스 디자이너 Excellent Fair Fair멀티쓰레드 지원 Fair Good Poor코드 살펴보기 Excellent Good PoorSQL 구문 Good Good ExcellentCOM 인터페이스 Excellent Good FairWin32 API Good Fair Poor쿠키 사용 Excellent Good Poor웹 상태 공유 Excellent Good Fair

Visual Basic 은 Delphi 보다 배우기 쉬우며, Visual Basic 과 Delphi 모두 PowerBuilder 보다는 배우고 작업하기 훨씬 쉽다. 우리는 Visual Basic 과 Delphi 개발자들이 PowerBuilder 개발자보다 하루에 더 많은 코드를 디버깅하여 더 나은 생산성을 보일 것으로 판단한다.

Visual Basic 의 학습은 Delphi 보다 더 쉬우며, 최고의 에디터와 디버거를 보유하고 있으며, 가장 안정적인 것으로 판정되었다. 순식간에 컴파일되며 유저 인터페이스는 프로그래머에 편하게 되어 있다. 온라인 도움말도 훌륭하며, Visual Basic 의 순수 객체 모델은 COM 이기 때문에, ADO 또는 MTS 컴포넌트와 같은 COM 컴포넌트를 개발하는 데 가장 적합한 툴이다. Visual Basic 은 웹 사이트를 개발하기에 가장 쉬운 RAD 툴이다.

PowerBuilder 는 테스트 코드를 개발하는 데 가장 오랜 시간이 걸렸다. 웹 페이지에 대한 디버거 지원이 부족하여, 우리는 별도의 테스트 코드를 작성해야만 했다. 디버거는 5.0 에 비해 상당히 개선되었지만, 에디팅 환경과 잘 통합되어 있지 않다.

PowerBuilder 개발 환경은 클래스를 살펴보기 곤란하게 되어있다. 동시에 한 개 이상의 함수를 보거나 출력할 수 없으며, 아직은 개선될 여지가 많다.



RAD 툴의 선택

각각의 툴들은 이전 제품에 비해 상당한 발전을 했다. 기존의 프로젝트를 유지보수하기 위하여, 이전 버전에서 업그레이드할 것을 강력하게 추천한다. 한 가지 예외는 웹 프로젝트에 PowerBuilder 6.0 을 사용하는 것이다. 오히려 5.0 이 더 안정적이었다.

개발 툴을 처음사용하는 프로그래머들은 Visual Basic 이 가장 배우기 쉽다는 것을 알게 될 것이다. 학습 기간 동안의 생산성은 낮기 때문에, Visual Basic 은 개발팀의 생산성을 향상시킨다. 제품에서 제공되지 않는 것은 이미 써드파티를 통해 이용할 수 있다. 개발자들이 이미 Visual Basic 과 친숙하다면, 다른 개발 툴을 고려할 이유가 거의 없다. 이제 Visual Basic 은 PowerBuilder 의 데이터베이스 통합, 그리고 Delphi의 머신 코드 속도를 보유하고 있다.

PowerBuilder 에 친숙한 프로그래머들은 다른 툴을 심각하게 고려해야 한다. Visual Basic 이 이제는 더 나은 데이터베이스 통합 툴을 제공하고 있다. Delphi 와 Visual Basic 은 모두 훨씬 우수한 컴파일러와 디버거를 제공한다. PowerBuilder 의 성능은 항상 문제였지만, 웹과 다계층 분산형 소프트웨어를 개발하는 경우에는 높은 벽을 실감하게 만든다. 능숙한 PowerBuilder 개발자들도 Visual Basic 개발자보다 디버깅 시간을 더 소비해야 할 것이다. PowerBuilder 프로그램은 서버 코드를 개발하는 능력이 부족하여 다중 계층 환경으로 쉽게 조정되거나 분할될 수 없다. 또한 PowerBuilder 프로젝트는 극복할 수 없는 성능으로 인해 사라질 운명에 처해있다. 이것은 유용한 엔터프라이즈 애플리케이션을 개발함에 있어서 더 낮은 생산성을 보인다는 것을 의미한다.

경쟁 RAD 환경 중에서, PowerBuilder 개발자들은 Visual Basic 으로 전환하는 편이 가장 편안할 것이다. PowerScript 는 주로 Basic 의 변종이며 Java, C++, 또는 Delphi 의 Pascal 보다는 Basic 에 가깝다. Visual Basic 의 데이터베이스 툴은 하루면 마스터할 수 있을 정도이고, 유지보수 비용 또한 최소화될 수 있다.

능숙한 Delphi 팀은 가장 곤란한 결정에 직면하게 될 것이다. 가장 어려운 학습을 마쳤기 때문에, Delphi 프로그래머들은 Visual Basic 프로그래머들처럼 생산성이 높을 것이다.

모든 장점에도 불구하고, Delphi 는 주류에서 벗어나 있다. 솜씨있는 Delphi 프로그래머를 찾기도 어렵다. 새로운 프로그래머를 교육하는 것은 Visual Basic 의 경우보다 훨씬 비용이 많이 들며, 데이터베이스 툴도 가장 빈약한 상태다. 버전 관리 기능, 모델러, 리파지토리 기능이 없거나 매우 약한 상태이며, 써드 파티 지원도 드문



편이다. Delphi 의 가장 큰 약점은 Borland Desktop Engine 으로, 이것은 신뢰성과 관리성 면에서 엔터프라이즈 소프트웨어의 표준에 적합하지 않다. 새로운 프로젝트의 경우, Delphi 를 사용하는 프로그래머와 관리자들은 더 쉬운 Visual Basic 이나 같은 난이도에 더 강력한 Visual C++로의 전환을 심각하게 고려하는 것이 좋다.


Documents

RAPID APPLICATIONpds.devpia.com/MAEUL/top_pds/1000/12/NSTL RAD … · Web view개발자가 개발을 시작하기 전에 IIS SDK와 인프라이즈의 웹 사이트를 조심스럽게