| http://blog.naver.com/locusty/80018522852 | |||||||||||||||
히치하이커를 위한 PHP 가이드 ⑦ PHP 5, 오라클, 그리고 미래 PHP 5의 release manager, Andi Gutmans로부터 PHP 5의 새로운 기능과, 오라클 사용자를 위한 향후 로드맵에 대한 이야기를 들어 봅니다. PHP 5 (PHP: Hypertext Preprocessor Version 5)가 2004년 7월 13일 공식 발표되었습니다. PHP가 웹 애플리케이션 시장에서 차지하는 비중을 감안했을 때, 많은 언론 매체에서 이 사실을 앞다투어 보도한 것은 결코 놀랄 일이 아닙니다. .NET 또는 J2EE 등의 테크놀로지가 PHP 보다 더 오랜 기간 동안 발전해 온 것은 사실이지만, 사용 편의성, 성능, Apache 웹 서버와의 통합 수준, 다양한 애플리케이션 구성 요소 등으로 인해 PHP는 가장 중요한 웹 애플리케이션 개발 언어의 하나로써 자리매김하는데 성공하였습니다. 여기서 의문을 갖는 분들이 계실 줄로 압니다. Zend Engine을 탑재한 PHP 4가 그처럼 성공적이었는데, 지금 PHP 5와 Zend Engine II를 굳이 사용해야 하는 이유가 무엇일까요? 먼저 PHP 4가 모든 부분에서 뛰어난 언어는 아니었다는 것을 인정해야 할 것입니다. 특히, 조직적인 프로젝트 관리와 시스템 간의 호환성이 필수적으로 요구되는 엔터프라이즈 환경에서 PHP 4는 능력의 한계를 드러내었습니다. PHP 5는 바로 이러한 문제를 해결하기 위해 개발되었습니다. 본 문서에서 다루게 될 주제가 다음과 같습니다: • PHP 5의 개발 동기 Zend Engine II의 오브젝트 지향형 모델 배경정보 PHP의 사용자 수가 지속적으로 증가하면서, 대규모 프로젝트 환경에서의 적용 사례도 꾸준히 늘고 있습니다. 대규모 프로젝트는 오브젝트 지향형(OO) 방법론에 의존하는 경향이 강합니다. 물론 작은 규모의 OO 애플리케이션을 작성하는 것도 가능하고, 오브젝트 지향형 프로그래밍(OOP)을 사용하지 않고 대규모 애플리케이션을 구현하는 것도 가능합니다. 하지만 OOP가 기능적/기술적 설계를 위한 툴(UML ? Unified Modeling Language), 반복적인 문제를 위한 솔루션의 재활용(디자인 패턴), OO 언어를 이용한 소프트웨어 설계를 위한 빌트-인 메커니즘 등을 제공한다는 점에서, 프로젝트의 규모가 클 수록 OO 패러다임을 선택하는 경향이 뚜렷해지는 것은 분명한 사실입니다. 이전 버전의 PHP가 제공하는 오브젝트 모델은 복제 방식을 이용한 네이티브 타입으로 구현되었습니다. 이로 인해 개발자가 매우 혼란스러워할 만한 상황이 연출되곤 했으며, 때로는 예상치 못한 오브젝트 클로닝(object cloning) 작업이 PHP에 의해 암시적으로 수행되기도 했습니다. 또 메소드로부터 반환된 오브젝트의 참조를 해제(de-reference)하는 것과 같은 기본적인 일부 기능의 구현이 불가능했습니다. 아래 예는 위에서 설명한 두 가지 문제를 예시하고 있습니다. 대부분의 개발자는 “andi”라는 결과가 출력될 것으로 기대할 것입니다. 하지만, PHP 4에서는 놀랍게도 “Andi”라는 결과를 반환합니다. PHP4는 오브젝트를 네이티브 타입으로 처리합니다. 따라서, $obj는 lowerCaseName()에 “pass-by-value” 방식으로 전달되며, 그 결과 오브젝트의 클로닝(cloning)이 수행됩니다. lowerCaseName()은 $obj에 대한 작업을 수행하면서 오브젝트의 클론 버전을 사용합니다. 이러한 문제를 사전에 인지하고 있는 개발자라 하더라도, “pass-by-reference” 방식으로 오브젝트를 반환하는 방식을 사용해야 하며, 따라서 코드의 여러 부분에 “&” 기호(passing by-reference, returning by-reference, assigning by-reference)를 추가해야 합니다. 이러한 코드는 작성하기도 어렵고, 관리하기도 어렵습니다. b) 메소드로부터 반환된 오브젝트의 참조를 제거(de-reference)할 수 없음: $obj->getParentObject()->method(); PHP 4에 익숙하지 않은 개발자라면, 위의 코드가 정상적으로 동작할 것이라고 생각할 것입니다. 하지만 앞에서 설명한 암시적 클로닝(implicit cloning) 때문에, 반환된 오브젝트의 참조를 제거할 수 있는 방법이 없는 것이 현실입니다. 따라서 문제를 해결하기 위해서는 다음과 같은 코드를 사용해야만 합니다: $temp_obj &= $obj->getParentObject(); PHP4의 오브젝트 활용 문제에 관련한 예는 이것 말고도 여러 가지가 있지만, 여기에서 설명된 두 가지 예만으로도 충분히 감을 잡으셨으리라 생각합니다. PHP 5의 주요 신기능. PHP 5의 가장 기본적이면서도 중요한 개선 사항으로, 오브젝트가 네이티브 데이타타입(native datatype)으로 정의되지 않으며, 대신 핸들(handle, 또는 id)을 통해 활용된다는 점을 들 수 있습니다. 오브젝트가 복제될 때는 핸들(또는 id number)만이 복제되며, 이 핸들이 참조하는 오브젝트 자체는 복제되지 않습니다. 이것은 일견 사소한 변화로 보일 수 있겠지만, 실제로 이것은 PHP 5의 많은 신기능을 뒷받침하고 있는 매우 중요한 변화입니다. 이와 같은 개선이 있었기 때문에 SimpleXML을 비롯한 다양한 신기능과 PHP extension의 추가가 가능했습니다. PHP 5의 새로운 기능을 간단하게 요약하면 다음과 같습니다. Object Cloning Semantics의 변경. 앞에서 설명한 것처럼, PHP5의 스크립팅 엔진은 “assign”, “pass-by-value” 또는 “return-by-value” 등의 작업을 수행하는 과정에서 절대로 오브젝트를 클로닝(cloning) 하지 않습니다. 오브젝트의 클로닝이 꼭 필요한 경우에는 새로 추가된 clone 키워드를 사용하여 오브젝트를 명시적으로 클로닝 해야 합니다 (예: clone $obj;). 또 클래스에 “__clone()”이라는 이름을 갖는 메소드를 구현할 수도 있습니다. 이 메소드는 클로닝을 통해 기존 오브젝트 속성의 복제 작업이 완료된 후, 새로 생성된 오브젝트를 대상으로 호출 작업을 수행하는 용도로 사용됩니다. 이러한 콜백(callback) 작업은 꼭 필요한 것은 아니지만, 특정 리소스(특히 파일)의 별도 복제본을 활용하고자 하는 경우에 유용하게 활용할 수 있습니다. Public/private/protected access modifiers. PHP 5는 C++, Java와 같은 오브젝트 지향형 언어가 공통적으로 지원하는 PPP (Private/Public/Protected) access modifier를 지원합니다. 이 access modifier를 속성(property) 또는 메소드(method)에 적용하여 액세스 제한을 적용할 수 있습니다. 인터페이스, abstract 클래스, 메소드. Zend Technologies에서는 PHP에 MI (multiple inheritance) 기능을 추가해달라는 사용자의 요청이 많았던 점을 감안하여, 이 기능을 PHP 5에 구현하기로 결정하였습니다. 우리는 C++와 Java를 포함하는 다양한 언어의 MI 구현 방식과 다이내믹한 성격을 갖는 PHP 환경에서의 적합성을 검토한 끝에, Java 스타일의 인터페이스와 abstract 클래스를 갖는 MI를 구현하기로 합의하였습니다. PHP Extension의 PHP Object Syntax Overloading. PHP 5에서 가장 주목할만한 변화의 하나로, 오브젝트의 syntax와 semantics을 구분하기 위한 abstraction layer가 Zend Engine II에 구현되었다는 점을 들 수 있을 것입니다. 따라서 사용자 레벨의 PHP 오브젝트와는 전혀 다른 성격을 갖는 오브젝트를 PHP extension에서 자체적으로 생성하는 것이 가능해졌습니다. 예를 들어 새로운 COM extension에서 이러한 overloading 기능을 이용하는 경우, (PHP 개발자들이 친숙한) 정규 PHP 오브젝트 문법을 사용하여 COM 오브젝트에 접근할 수 있게 됩니다: $ie = new COM("InternetExplorer.Application"); 그 밖에 overloading 기능의 활용이 가능한 extension으로 SimpleXML, SOAP, Perl extension 등을 들 수 있습니다. 기타 주요 기능 그 밖에도 class constant, static property/method, __autoload(), instanceof operator 등 PHP 5에 다양한 기능이 새롭게 추가되었습니다. 자세한 정보는 http://www.zend.com/php5 에서 확인하실 수 있습니다. Design Patterns 이미 앞에서 설명한 것처럼, 대규모 PHP 소프트웨어 프로젝트에서 디자인 패턴의 활용은 매우 중요한 요소입니다. PHP 4에서도 디자인 패턴의 활용이 가능했지만, static property/method, PPP access modifier, interface 등의 핵심 기능이 빠진 상태에서 디자인 패턴의 semantics를 제대로 활용하기는 어려웠습니다. Singleton Pattern 가장 널리 사용되는 디자인 패턴의 예로 Singleton 패턴을 들 수 있습니다. Singleton 패턴은 비교적 단순한 형태의 패턴이지만, 제대로 구현하려면 static property/method와 PPP access modifier가 필수적으로 요구됩니다. 예가 다음과 같습니다: <?php class MySingleton { static private $instance = NULL; private function __construct() { } private function __clone() { } static public function Instance() { if (self::$instance == NULL) { self::$instance = new MySingleton(); } return self::$instance; } // ... Additional code for the MySingleton class. }위의 코드는 PHP 5의 기능을 활용하여 보다 명확하고 에러 가능성이 낮은 Singleton 패턴을 구현하고 있습니다. 한 예로, constructor와 clone method를 private으로 선언함으로써 개발자가 실수로 MySingleton 클래스의 복제본을 추가로 생성하는 실수를 방지하고 있습니다 (오직 MySingleton 클래스만이 선언된 메소드에 액세스할 수 있습니다). 또 static property를 이용하여 클래스의 단일 인스턴스를 참조하는 (글로벌 액세스가 가능한) property (self::$instance)를 정의하고 있습니다. 마지막으로 이 property를 private으로 선언함으로써, 기존의 MySingleton 클래스만이 property를 이용할 수 있게 하였습니다. Immutable Object Pattern Immutable Object 패턴은 Singleton 패턴과 비교했을 때 활용도가 다소 낮습니다. 이 패턴은 비교적 적은 수의 값에 대해 많은 수의 참조가 사용되는 애플리케이션에서 사용됩니다. Immutable Object 패턴은 오브젝트를 “immutable”하게 (그 상태를 변경할 수 없게) 설정하고, 애플리케이션 코드가 해당 오브젝트를 공유할 수 있게 합니다. (오브젝트의 상태를 변경하고자 하는 경우에는 클래스의 새로운 인스턴스를 생성해야만 합니다.). 아래 코드는 특정 SQL 쿼리를 대표하는 클래스를 생성하는 방법을 예시하고 있습니다. 클래스에서 조합된 쿼리 구문은 애플리케이션 내에서 반복적으로 활용될 수 있습니다. 쿼리 구문의 변경이 필요한 경우에는 코드에 changeStmt() 메소드를 사용해야 합니다. changeStmt() 메소드는 새로운 쿼리 구문을 위한 오브젝트를 생성하고, 오브젝트를 참조하는 핸들(handle)을 반환합니다. <?php final class ImmutableQueryStatement { private $stmt; public function __construct($stmt) { $this->stmt = $stmt; } public function getStmt() { return $this->stmt; } public function changeStmt($stmt) { return new ImmutableQueryStatement($stmt); } }위의 예제는 PHP 5의 몇 가지 새로운 기능을 활용하고 있습니다. 먼저, final 키워드를 사용하여 클래스가 “subclass”되지 않도록 하였습니다. 이러한 방법을 사용하여 “subclassing”을 방지하고, “mutable”한 버전을 구현할 수 있습니다. 또 changeStmt() 메소드는 새롭게 생성된 오브젝트를 새로운 오브젝트 핸들을 통해 “pass-by-value” 방식으로 반환합니다 (PHP 4에서는 새로운 오브젝트 인스턴스가 “pass-by-reference” 방식으로 반환되는 문제가 있었습니다). 마지막으로, 이전의 예제와 마찬가지로 access modifier를 이용하여 이 클래스가 준수해야 하는 액세스 정책을 명시하고 있습니다. PHP 5의 XML 및 Web Service 배경정보 지난 수년 동안, 표준 툴과 방법론을 통해 서로 다른 애플리케이션/시스템의 데이타를 통합하기 위한 테크놀로지로서의 XML의 중요성은 점점 더 강조되어 왔습니다. 오라클과 다른 벤더들이 XML 테크놀로지를 적극적으로 지원 또는 채택하고 있는 이유도 여기에 있습니다. 어떤 기업에게서나 데이타는 비즈니스의 중심으로써 활용되고 있습니다. PHP 4의 XML 지원 기능은 매우 조잡한 수준이었습니다. PHP 4가 SAX (Simple API for XML), DOM (Document Object Model), XSL (eXtensible Stylesheet Language)을 지원하기는 했지만, 통합적이고 표준적인 구현방식이 존재하지 않았습니다. PHP 4에 구현된 SAX는 이미 낡은 기술이 되어 버린 Expat XML parser를 기반으로 하고 있었으며, DOM extension의 명명 규칙은 표준을 준수하지 않고 있었습니다. 또 DOM extension의 완성도도 실험적인 수준을 벗어나지 못했으며, XSL은 Sablotron이라는 별도의 XML 라이브러리를 사용하는 경우에만 지원이 가능했습니다. PHP 5에 XML 지원 기능을 새롭게 구현하기로 결정된 이후, PHP 커뮤니티의 소수 개발자들이 개발작업을 진행하였습니다. 모든 XML 기능은 Gnome's project에서 제공되는 libxml2 라이브러리를 기반으로 구현되는 것으로 결정되었습니다. 이러한 결정을 바탕으로 기존의 세 가지 extension이 모두 완전히 재작성 되었습니다. 특히 DOM extension의 경우, 코드가 완전히 재작성 되었을 뿐 아니라 인터페이스 역시 W3C 표준에 근거하여 재정의 되었습니다. PHP 5가 출시되면서, DOM은 실험적인 수준을 벗어나 기능과 안정성 면에서 충분히 성숙한 기능으로써 활용 가치를 얻게 되었습니다. SimpleXML 기존의 XML extension을 재작성하고 통합하는 것과는 별도로, 새로운 XML extension이 각광을 받기 시작했습니다. SimpleXML이라 불리는 이 extension은, 개발자들이 마치 네이티브 PHP 오브젝트를 사용하는 것처럼 XML 파일에 접근할 수 있는 환경을 제공합니다. 이 기능 역시 (앞에서 설명한 것처럼) Zend Engine II에 OO syntax의 overloading 기능이 추가됨으로써 그 구현이 가능해졌습니다. 다음과 같은 XML 파일을 가정해 봅시다: <clients> <client> <name>John Doe</name> <account_number>87234838</account_number> </client> <client> <name>Janet Smith</name> <account_number>72384329</account_number> </client> </clients>아래 PHP 5 코드는 XML 파일에 존재하는 클라이언트의 name과 account number 정보를 출력합니다: <?php $clients = simplexml_load_file('clients.xml'); foreach($clients->client as $client) { print "$client->name account: $client->account_number\n"; }샘플 스크립트를 실행한 결과가 다음과 같습니다: John Doe account: 87234838 SimpleXML이 구현되면서, XML 파일에 액세스하는 작업이 한층 용이해졌습니다. 필자는 SimpleXML이 PHP 개발자의 XML 파일 처리 방식에 혁신적인 변화를 가져올 것이라고 믿습니다. 또 SimpleXML로 처리할 수 없는 작업이 있다면, SimpleXML 오브젝트를 DOM tree로 변환하고 DOM 환경에서 고급 XML 기능을 활용할 수 있습니다 (SimpleXML과 DOM extension은 동일한 라이브러리를 공유하고 있으므로 이와 같은 변환 작업이 가능합니다). SimpleXML과 DOM 간의 변환 작업은 “zero-copy” 방식으로 실행됩니다. 다시 말해, 전혀 시간이 소요되지 않으며 메모리를 추가로 사용하지도 않습니다. SOAP 문서의 서두 부분에서, 엔터프라이즈 환경에서는 호환성(interoperability)이 핵심적인 이슈가 된다고 언급한 바 있습니다. 웹 서비스, 또는 (보다 정확히 표현하자면) SOAP 프로토콜은 서로 다른 시스템 간의 호환성 이슈를 해결하기 위한 해결책으로 높은 인기를 얻고 있습니다. PHP 4의 배포판에는 통합적인 SOAP 지원 기능이 포함되어 있지 않았으며, 따라서 PHP 5에서 이 기능을 구현하기 위한 계획이 수립되었습니다. 그 결과로, PHP 개발자가 웹 서비스를 쉽게 생성하고 활용하기 위한 네이티브 SOAP 지원 기능(클라이언트 및 서버 API)이 PHP 5에 추가되었습니다. 아래 예제는 PHP에서 SOAP 서비스를 호출하는 과정이 얼마나 간단한지 보여주고 있습니다. 이 extension 역시 앞에서 언급한 OO overloading 기능을 활용하고 있음을 확인하실 수 있습니다. <?php $client = new SoapClient("http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl"); print($client->getQuote("ORCL"));이 코드를 실행하면 "11.23. "이 결과로 출력됩니다. PHP의 미래와 오라클 PHP 5가 출시된 지 얼마 되지 않았지만, 이미 PHP 개발 환경에는 새로운 변화가 확인되고 있습니다. 스크립팅 엔진의 성능을 개선하기 위한 작업에 많은 진전이 있었으며, 데이타베이스에 관련한 여러 가지 프로젝트가 새롭게 시작되고 있습니다. PHP 커뮤니티에서 오라클은 매우 인기 있는 플랫폼이며, Zend Technologies의 고객 중 상당수가 오라클을 사용하고 있기도 합니다. 사용자들은 오라클의 검증된 역사, 다양한 고급 기능 때문에, 또는 기존에 사용해 오던 오라클 인프라스트럭처를 고려하여 오라클 제품을 선택하고 있습니다. 스크립팅 엔진의 성능 PHP 5를 개발하면서, Zend Technologies와 PHP 커뮤니티는 성능 보다는 기능에 우선적으로 초점을 맞추어 개발 작업을 진행하였습니다. 이러한 이유로, 몇 가지 예외적인 경우를 제외하고는 PHP 5의 스크립팅 엔진 성능은 PHP 4와 비교하여 개선되지 않았습니다. PHP 애플리케이션에서 PHP의 자체적인 실행 성능이 성능 병목으로 작용하는 경우는 드뭅니다. 대부분의 성능 문제는 I/O 또는 데이타베이스와 관련하여 발생합니다. 그렇다 하더라도, 우리는 스크립팅 엔진의 성능을 개선하는 것이 PHP 사용자에게 매우 큰 도움이 될 것이라고 믿고 있으며, 같은 이유로 PHP 5.1.x에서의 성능 개선을 위해 많은 리소스를 투자하고 있습니다. PHP 5가 발표된 이후로, 우리는 스크립팅 엔진의 튜닝을 위해 많은 리소스를 투자했습니다. 이 과정에서 Thies Arntzen와 Sterling Hughes가 일 년 전에 공개한 성능 패치가 많은 도움이 되었습니다. 그 밖에도 Zend Technologies 내부와 PHP 개발자 커뮤니티를 통해 다양한 아이디어가 제공되었습니다. 그 결과, 우리는 “synthetic” 벤치마크(I/O와 실제 환경의 코드를 포함하지 않는 벤치마크)에서 PHP 4.0 또는 PHP 5.0에 비해 두 배 이상의 성능을 보여주는 엔진을 구현할 수 있었습니다. 이러한 개선 효과는 매우 놀랄 만한 수준입니다. PHP 5.1.0이 출시되면, PHP 사용자들은 소스 코드를 전혀 변경하지 않고도 개선된 성능의 혜택을 누릴 수 있을 것입니다. 필자는 PHP 5.1.0이 2005년 1/4분기 초에 공개될 것으로 기대하고 있지만, 오픈 소스 프로젝트의 일정은 아무도 장담할 수 없는 것이 현실입니다. SQL Relay. SQL Relay는 매우 흥미로운 써드 파티 프로젝트입니다. SQL Relay는 SQL 연결을 위한 proxy broker를 구현하는 프로젝트로, PHP를 이용한 데이타베이스 연결의 “connection pooling”을 가능하게 합니다. 이 프로젝트는 독자적인 PHP 데이타베이스 extension을 제공하고 있습니다 (이 extension을 사용하려면 PHP 데이타베이스 코드를 변경해야 합니다). 이 extension은 데이타베이스로부터 쿼리와 결과 셋을 중개하는 SQL Relay broker와의 커뮤니케이션을 위해 사용됩니다. SQL Relay가 제공하는 장점이 다음과 같습니다: • “connection pooling”을 이용하여 데이타베이스에 설정된 연결의 수를 제한할 수 있습니다. SQL Relay의 단점으로 지적되는 부분이 다음과 같습니다: • PHP Oracle extension이 아닌 다른 API를 사용해야 합니다. 오라클 데이타베이스의 “connection pooling”이 요구되는 환경이라면, SQL Relay를 검토해 볼 것을 개인적으로 권장합니다. SQL Relay가 완벽하지는 않으며 충분히 성숙되기까지 시간이 필요하다는 점을 감안하더라도, 당장 활용 가능한 솔루션임에는 분명합니다. PDO PHP 커뮤니티는 오라클 데이타베이스에 대한 네이티브 인터페이스를 제공하는 oci8 PHP extension과 별도로, 새로운 데이타베이스 추상화 계층(database abstraction layer)을 개발하기 위해 노력해 왔습니다. 이미 OTN에 PHP Data Objects (PDO)을 주제로 하는 Wez Furlong의 아티클이 공개되고 있으므로, 여기에서는 PDO를 주목할 필요가 있다는 언급만으로도 충분할 것 같습니다. 필자는 PDO가 우리 모두가 오랫동안 기다려 오던 솔루션이라 믿고 있습니다. PDO는 PHP 커뮤니티의 리더들에 의해 설계되었으며, 필자 역시 그들의 PDO 개발 접근방식에 공감하고 있습니다. PDO의 개발자들이 밝힌 설계 목표가 다음과 같습니다: 1. “lightweight” 형태로 구현한다. PDO는 다양한 데이타베이스 환경에서 호환 가능한 공통 API를 제공하며, 또 한편으로 각 드라이버를 통해 데이타베이스 벤더 별로 제공되는 추가적인 기능을 구현하고 있습니다. 따라서 PDO는 오라클과 같은 데이타베이스가 제공하는 고급 기능을 효과적으로 활용할 수 있는 환경을 지원하게 될 것입니다. Propel Propel은 오브젝트 persistence 및 쿼리를 위한 프레임워크입니다. Propel은 ORM(object/relational mapping)을 지원하며 Apache Torque 프로젝트를 기반으로 하고 있습니다. PDO와 달리, Propel은 상위 레벨의 데이타베이스 추상화 계층(database abstraction layer)으로써 구현되며, 개발자가 쿼리를 수행하고 persistent 오브젝트를 생성/조작하는 방법을 재정의하고 있습니다. 또 다른 OO/RDBMS 매핑 시스템과 마찬가지로, Propel은 데이타베이스 스키마 생성 과정을 정의하고 있습니다. Propel과 같은 시스템이 제공하는 혜택은 매우 다양합니다. 먼저, 개발자들이 데이타베이스 연결에 관련한 복잡한 문제에 시간을 뺏기지 않고 비즈니스 로직을 구현하는데 집중할 수 있다는 점을 들 수 있습니다. 데이타베이스 작업은 매우 자연스러운 형태로 수행됩니다. 개발자들은 정규 오브젝트만을 처리하며. 데이타베이스의 필드와 로우를 업데이트하는 하위 레벨 작업은 persistent layer가 담당하게 됩니다. 개발자의 역량이 제한될 수 있다는 것은 Propel의 단점입니다. OO 모델과 관계형 데이타베이스 간의 자동적인 매핑이 언제나 명확하게 이루어지는 것은 아닙니다. 때문에 강력하고 정교한 쿼리를 작성하기가 어려워지게 되며, 심지어 추상화 개념에 위배된다는 이유로 이러한 시도가 금지되기도 합니다. 결국 개발자는 툴이 강요하는 규칙을 강제적으로 준수해야 합니다. 대부분의 경우에는 그에 상응하는 대가(생산성의 향상, 개발 시간의 단축, 코드 품질의 개선 등)가 제공됩니다. 하지만 경우에 따라서는 개발자의 역량이 최대한 발휘되어야만 하는 상황이 있을 수도 있습니다. Propel은 매우 흥미로운 프로젝트이며, 앞으로 유용하게 활용될 가능성이 높습니다. Propel은 Creole이라는 데이타베이스 추상화 계층(database abstraction layer)을 기반으로 구현되었습니다. PDO와 달리, 이 추상화 계층은 JDBC를 에뮬레이션하고 있으며, 특히 Java 코드를 PHP로 변환하고자 하는 경우에 유용합니다. 하지만 PDO가 주류 기술로 인정받고 PHP 배포본에 기본 포함되는 날이 온다면, PDO를 선택하는 것이 가장 합리적인 판단이 될 것입니다. Java 통합 지금으로부터 약 1 년 전, Zend Technologies와 Sun Microsystems는 PHP와 Java 간의 격차를 좁히기 위한 표준 정의 작업의 일환으로써Java Specification Request (JSR) 223을 공개하였습니다. 오늘날 JSR의 전문가 그룹에는 오라클을 포함한 많은 소프트웨어 벤더들이 참여하고 있습니다. JSR은 현재 모든 종류의 스크립팅 언어를 그 대상으로 하고 있지만, 초기에는 PHP와 PHP를 이용한 Java 코드의 호출을 주된 관심사로 하고 있었습니다. 프론트엔드PHP 서버를 백엔드 J2EE 애플리케이션 서버에 연결하거나, 또는 PHP 코드로부터 EJB(Enterprise Java Beans)를 직접 호출하는 방법에 대한 논의가 JSR 발표의 핵심적인 동기가 되었습니다. 아래 코드는 Java 인터페이스를 이용하여 Oracle JDBC 쿼리를 수행하는 가상의 예를 보여주고 있습니다:
위 코드에서 확인할 수 있듯, 앞으로는 PHP에서 Java 코드를 작성하는 것이 가능해질 것입니다. 따라서 기존에 구현된 Java 비즈니스 로직, 특히 EJB를 호출할 수 있게 될 것입니다. PHP를 이용하여 백엔드 비즈니스 로직을 활용함으로써 개발 기간을 단축하고자 하는 Oracle Application Server 사용자의 입장에서도 새로운 가능성이 열린 셈입니다. 결론 PHP 5를 통해 PHP와 PHP 커뮤니티는 매우 중요한 진전을 이루었습니다. O'Reilly Open Source 컨퍼런스 행사에서, 한 기자가 PHP 커뮤니티의 리더들에게 “PHP 5를 통해 목표한 바를 모두 이루었는가”라는 질문을 던진 일이 있습니다. 모든 참석자들은 이구동성으로 “PHP 5는 우리가 애초에 목표하고 기대했던 것을 훨씬 뛰어넘는 성과”라고 답변하였습니다. 필자는, 특히 오라클 사용자들의 입장에서 앞으로도 많은 것을 기대할 수 있을 것이라고 생각합니다. 오라클은 Statement of Direction을 통해Oracle Application Server의 향후 버전에 PHP 지원 기능이 포함될 것임을 발표함으로써, PHP 테크놀로지의 중요성을 분명하게 인식하고 있음을 천명하였습니다. 필자는 오라클의 이러한 인식이 다양한 솔루션을 통해 Oracle/PHP 환경의 생산성과 유연성을 개선하는 방향으로 발전할 것이라 믿고 있습니다. Oracle 10g의 다음 버전에 번들되는 PHP와, PHP Extension for Oracle JDeveloper는 오라클의 PHP 지원을 위한 매우 중요한 첫 번째 발걸음이 될 것입니다. | |||||||||||||||
'php' 카테고리의 다른 글
| 다른 도메인간(www.url.com, shop.url.com등) 세션공유 (2) | 2007.07.21 |
|---|---|
| php 날짜, 시간 함수 관련 팁 (2) | 2007.05.03 |
| 히치하이커를 위한 PHP 가이드 ⑥ : PHP 5 Data Object (PDO)... (1) | 2007.05.03 |
| 히치하이커를 위한 PHP 가이드 ⑤ : 오라클/PHP 환경의 확장 (0) | 2007.05.03 |
| 히치하이커를 위한 PHP 가이드 ④ : PHP, 어른이 되다 (0) | 2007.05.03 |