티스토리 뷰
728x90
반응형
아래는 COM+ 구조에 대한 이런 저런 것들을 언급한 것입니다.
실무에서 사용하는 COM+는 주로 엔터프라이즈 개발 아키텍쳐의 미들티어로서 주로 트랜잭션 작업 처리를 위한 목적이 강하다.
물론 지금도 해당하는 거지만, .NET 1.1 까지는 거의 MS로 하는 엔터프라이즈 개발에서
WEB(ASP.NET) - (WEB SERVICE ) - COM+(BSL/DSL) - (SP)DB
라는 부동의 엔터프라이즈 개발 아케텍쳐를 위한 공식이 통용되어 오고 있다.
그러나 이 COM+는 결국 COM 기반이므로 .NET 관점에서 보면 Unmanaged 환경이다. 그래서 .NET 어셈블리(Managed)를 COM+ 컴포넌트화 시키는 것은 Managed 코드를 Unmanaged 환경에서 사용할 수 있도록 Wrapping 하는 과정을 거쳐야만 하는 결과를 낳게 하고 또한 약간의 부조화가 생기는 것도 사실이다.
그러나 최근 .NET 2.0과 SQL2005가 등장하면서 굳이 트랜잭션 처리를 위해서 COM+에 컴포넌트를 올리는 작업 자체에 대한 회의론적인 의견이 많다..
그래서 최근 엔터프라이즈 개발 프레임웍에서는 COM+를 제외시킨 SQL2005의 기본 트랜잭션 메카니즘(Transaciton Scope)을 이용하고 있다. (최소한 내가 하는 프로젝트에서는 그렇다.)
"어.. 그럼 이제 COM+ 안써도 되겠네..."라고 하시는 분.. 잘 들으시라..
일단 우리네 개발자들은 항상 피곤하다. IT환경이 우리를 그렇게 만들어 왔다. 진보하는 기술 환경 속에 과거의(?) 기술을 모르고 현재의 기술을 파악하기란 쉽지 않거나 불가능하다. 필자는 생각한다. (엔터프라이즈) 개발자라면 미들티어에 대한 이해와 그 구체화된 환경으로서의 COM+를 이해하는 것은 엔트프라이즈 솔루션의 구조를 파악하고 향후 변화하는 이 영역의 기술을 파악하는데 많은 도움이 될 것이다.
그리고 이번 강좌는 "Understanding COM+ 독후감"의 마지막이다.. 아숩다..
시간이 허락한다면 샘플도 보이면서 직관적인 공부를 해보이고 싶지만 .. 그러기엔 너무 많다..
"COM+ 컴포넌트를 작성하여 사용하는 것은 그리 어렵지 않다"는 너무도 무책임한 논리로 무마하고 싶다.. 끝.
너무 개념적인 것들만 늘어놓은 것 같아 이 글을 읽으시는 분들에게 미안한 마음까지 생기려 한다....할 수 엄따...-_- 사카라..
COM+ Component
컴포넌트란, 애플리케이션의 업무 로직을 구현하는 소프트웨어 모듈이다. 즉 고객의 요구에 맞게 애플리케이션을 작성하는 것은 결국 컴포넌트를 작성한다는 것이 된다.
컴포넌트란 COM+의 소프트웨어 기능상의 기본 단위이다. 여기서 컴포넌트는 Component Service 스냅인의 한 COM+ 애플리케이션 안에 있는 Component 폴더에 나타난 항목을 의미한다. 즉 클래스를 뜻한다.
COM+에서는 컴포넌트가 COM DLL 서버 안에 들어가 있어야 한다. 한의 DLL에 여러 개의 컴포넌트들이 들어가도 된다. 하지만 EXE 서버 안에 들어 있는 컴포넌트는 COM+가 제공하는 혜택을 모두 누리지는 못한다.
COM+ 컴포넌트는 자가 등록이 가능해야 한다. 컴포넌트가 COM+의 관리, 배포 유틸리티들과 제대로 상호작용을 하려면 컴포넌트 자신을 스스로 등록할 수 있어야 한다.
COM+ 컴포넌트는 자신을 서술하는 타입라이브러리를 가져야 한다.
COM+ 컴포넌트의 모든 인터페이스들과 메서들은 타입 라이브러리로 서술되어야 한다. 큐 활용 컴포너트라든지, 이벤트, 롤 기반 보안 등 COM+의 여러 기능들은 타입 라이브러리 없이는 작동하지 않으므로 필수적인 요소이다.
COM+ Catalog
COM+는 상당한 양의 관리적 정보를 유지하고 있어야 한다. 예를 들어 COM+는 어떤 콤포넌트가 어떤 COM+ 애플리케이션에 혹한 것인지를
알아내야 한다. 기존에는 레지스트리에 저장할 만큼 적은 양이었지만 이제는 COM+ 카달로그라고 하는 시스템 데이터베이스에 저장해야 할 만큼 그 양이 많다.
Component Service 스탭인은 카달로그 객체들을 다루기 위한 유틸리티 일 뿐이다.
COMAdminCatalog라고 하는 컴포넌트를 통해서 COM+ 카달로그에 접근할 수 있다.
COM+의 문맥(Context)
객체가 현재 어떠한 환경에서 살아가고 있는지를 말해주는 것이 바로 문맥(Context)이다.
어떤 트랜잭션에 속할 수도 그렇지 않을 수도 있다. 또 동기화나 보안 서비스를 사용할 수도 그렇지 않을 수도 있다. 이러한 COM+객체가 처한 상황이 어떠한 것이지를 설명하는 것이다.
COM+는 객체가 활성활될 때 문맥을 생성해서 객체에 부착한다. 컴포넌트가 객체풀링을 허용하지 않으면 객체가 첨은 생성될 때 활성화가 일어난다.
객체풀링을 허용하면 객체를 풀로부터 뽑아올 때 활성화가 일어난다. 일단 객체의 문맥이 생성되고, 객체에 부착되면 그 문맥은 객체가 비활성화, 즉 소멸되거나(풀링되지 않은 객체의 경우), 풀로 돌아갈 때까지(풀링되는 객체의 경우) 변경되지 않는다.
객체의 문맥을 생성할 때 COM+는 카달로그의 항목들을 조사해서 문맥에 넣을 특성들을 결정한다.
COM+ 객체에 붙어다니는 문맥 정보는 문맥객체라는 개별적인 틀에 담기게 된다.
문맥객체는 COM+ 객체에 묵시적으로 연결되는 객체이다. MTS에서는 객체에 대해 GetObjectContext 함수를 호출해서 IOObjectContext 인터페이스를 얻었다.
COM+에서는 문맥객체에 여러가지 새로운 인터페이스들이 추가되었기 때문에 문맥 객체를 사용하기가 훨씬 더 쉬워졌다.
IObjectContextInfo 인터페이스는 상태정보를 담는다.
IContextState 인터페이스는 객체를 트랜잭션에 참여시킬 때 쓰이는 메서드들과 JIT활성화에 관련된 메서드를 제공한다.
ISecurityCallContext 인터페이스는 보안을 다루는 메서드를 제공한다.
문맥객체에 대한 인터페이스들은 CoGetObjectContext를 호출하거나 IObjectContext 인터페이스를 조회해서 얻는다.
마이크로소프트의 여러 실행환경들은 문맥객체에 여러 가지 정보를 추가한다.
예를들어 IIS가 ASP 페이지를 컴파일할 때는 IIS 환경에서 ASP 스크립트가 제대로 돌아가는데 필요한 내장 객체들을 문맥객체에 추가한다.
ASP 스크립트가 클라이언트로부터 쿠키를 읽어야 한다면 Request라는 객체가 문맥 객체에 추가된다.
보안
엔터프라이즈 애플리케이션에서 보안만큼 중요한 것이 없다.
COM+ 의 보안 기반구조를 그대로 상속받기만 하면 보안코드를 거의 작성하지 않고도 강력한 보안 기능을 갖출수 있다.
인증(Authentication)
인증은 운영체제에 의해서 투명하게 처리된다. 만일 클라이언트오 서버가 지정한 인증수준이 서로 다르면 운영체제는 둘 중 높은 것을 선택한다.
클라이언트가 서버에 익명으로 접그할 수 있게 하려는 경우에만 인증 수준을 없음(None)으로 해야 한다.
암호화의 중요성이 커지고 있으나, 소프트웨어적으로 암호화를 수행하려면 성능에 부담이 생긴다. 도청의 위험을 피하려면 인중 수준을 패킷비공개(Packet Privacy)로 설정해야 한다. 그러면 모든 데이터가 자동적으로 암호화된다
권한 점검(Authorization)
어떤 사용자가 특정 작업을 할 수 있는지를 밝히는 것. 적어도 인증 수준을 호출(Call) 이상으로 설정해야 권한점검이 의미가 있어진다. 인증수준을 없음(None)으로 했다면 의미가 없다.
COM+는 권한 점검 문제를 해결하기 위한 조립식 기반 구조를 제공한다. 이 기반구조에서 핵심적인 개념은 어플리케이션 전역적인 사용자 그룹을
뜻하는 롤(Role)이다. 각각의 애플리케이션마다 고유한 롤들의 집합이 있다.
COM+는 특정 롤의 일원들만이 특정 컴포넌트에 접근할 수 있도록 제한해 준다.
기반 클라이언트가 객체에 대해 메서드를 호출하면 COM+ 중재자(Interceptor)는 호출자가 어떤 롤에 속해 있는지를 카달로그에서
찾는다. 그런 다음 그 롤에 속한 일원들이 그 메서드를 호출할 수 있는지를 알아본다.
그런데 위에서 설명한 롤 점검 과정은 COM+ 애플리케이션 외부로부터의, 즉 기반 클라이언트나 아니면 다른 어떤 COM+ 애플리케이션으로
부터의 호출에 대해서만 수행된다는 점이다. 한 애플리케이션 안의 컴포넌트 A가 컴포넌트 B를 호출하는 것에 대해서는 COM+가 롤 점검을
수행하지 않는다.
ISecurityCallContext 인터페이스를 이용하면 애플리케이션의 업무 로직 안에서 롤 점검을 수행할 수 있다.
서버 프로세스의 신원(Identity)
서버 애플리케이션이 대표하는 사용자("보안 담당자")를 지정해 주어야 한다.
Interactive user를 선택하면 서버 프로세스는 서버에 직접 로그인한 사용자의 보안 권한을 따르게 된다. 이 설정을 사용하면 서버 애플리케이션의 사용자 인터페이스가 서버 컴퓨터에 직접 나타나므로 디버깅하기에는 최적의 조건이 된다. 단 클라이언트가 서버 프로세스를 띄우려고 하는데 서버 컴퓨터에 사용자가 하나도 로그인되어 있지 않으면 클라이언트의 시도는 실패해 버린다. 또 서버 프로세스가 성공적으로 실행되었다 해도 서버쪽에서 사용자가 로그오프 해버리면 서버 프로세스가 종료되며, 결과적으로 클라이언트 역시 떨어져 나가게 된다. Interactive user는 디버깅 목적으로만 선택하는 것이 좋다.
애플리케이션을 실제로 돌려야 하는 상황에서는 This user를 통해서 서버를 대표하는 사용자를 구체적으로 지정하는 것이 좋다. 클라이언트의 신원으로 서버 프로세스를 생성하는 데, 실제로 서버 컴퓨터에 그 사용자가 로그인되어 있지 않아도 상관이 없다.
실무에서 사용하는 COM+는 주로 엔터프라이즈 개발 아키텍쳐의 미들티어로서 주로 트랜잭션 작업 처리를 위한 목적이 강하다.
물론 지금도 해당하는 거지만, .NET 1.1 까지는 거의 MS로 하는 엔터프라이즈 개발에서
WEB(ASP.NET) - (WEB SERVICE ) - COM+(BSL/DSL) - (SP)DB
라는 부동의 엔터프라이즈 개발 아케텍쳐를 위한 공식이 통용되어 오고 있다.
그러나 이 COM+는 결국 COM 기반이므로 .NET 관점에서 보면 Unmanaged 환경이다. 그래서 .NET 어셈블리(Managed)를 COM+ 컴포넌트화 시키는 것은 Managed 코드를 Unmanaged 환경에서 사용할 수 있도록 Wrapping 하는 과정을 거쳐야만 하는 결과를 낳게 하고 또한 약간의 부조화가 생기는 것도 사실이다.
그러나 최근 .NET 2.0과 SQL2005가 등장하면서 굳이 트랜잭션 처리를 위해서 COM+에 컴포넌트를 올리는 작업 자체에 대한 회의론적인 의견이 많다..
그래서 최근 엔터프라이즈 개발 프레임웍에서는 COM+를 제외시킨 SQL2005의 기본 트랜잭션 메카니즘(Transaciton Scope)을 이용하고 있다. (최소한 내가 하는 프로젝트에서는 그렇다.)
"어.. 그럼 이제 COM+ 안써도 되겠네..."라고 하시는 분.. 잘 들으시라..
일단 우리네 개발자들은 항상 피곤하다. IT환경이 우리를 그렇게 만들어 왔다. 진보하는 기술 환경 속에 과거의(?) 기술을 모르고 현재의 기술을 파악하기란 쉽지 않거나 불가능하다. 필자는 생각한다. (엔터프라이즈) 개발자라면 미들티어에 대한 이해와 그 구체화된 환경으로서의 COM+를 이해하는 것은 엔트프라이즈 솔루션의 구조를 파악하고 향후 변화하는 이 영역의 기술을 파악하는데 많은 도움이 될 것이다.
그리고 이번 강좌는 "Understanding COM+ 독후감"의 마지막이다.. 아숩다..
시간이 허락한다면 샘플도 보이면서 직관적인 공부를 해보이고 싶지만 .. 그러기엔 너무 많다..
"COM+ 컴포넌트를 작성하여 사용하는 것은 그리 어렵지 않다"는 너무도 무책임한 논리로 무마하고 싶다.. 끝.
너무 개념적인 것들만 늘어놓은 것 같아 이 글을 읽으시는 분들에게 미안한 마음까지 생기려 한다....할 수 엄따...-_- 사카라..
COM+ Component
컴포넌트란, 애플리케이션의 업무 로직을 구현하는 소프트웨어 모듈이다. 즉 고객의 요구에 맞게 애플리케이션을 작성하는 것은 결국 컴포넌트를 작성한다는 것이 된다.
컴포넌트란 COM+의 소프트웨어 기능상의 기본 단위이다. 여기서 컴포넌트는 Component Service 스냅인의 한 COM+ 애플리케이션 안에 있는 Component 폴더에 나타난 항목을 의미한다. 즉 클래스를 뜻한다.
COM+에서는 컴포넌트가 COM DLL 서버 안에 들어가 있어야 한다. 한의 DLL에 여러 개의 컴포넌트들이 들어가도 된다. 하지만 EXE 서버 안에 들어 있는 컴포넌트는 COM+가 제공하는 혜택을 모두 누리지는 못한다.
COM+ 컴포넌트는 자가 등록이 가능해야 한다. 컴포넌트가 COM+의 관리, 배포 유틸리티들과 제대로 상호작용을 하려면 컴포넌트 자신을 스스로 등록할 수 있어야 한다.
COM+ 컴포넌트는 자신을 서술하는 타입라이브러리를 가져야 한다.
COM+ 컴포넌트의 모든 인터페이스들과 메서들은 타입 라이브러리로 서술되어야 한다. 큐 활용 컴포너트라든지, 이벤트, 롤 기반 보안 등 COM+의 여러 기능들은 타입 라이브러리 없이는 작동하지 않으므로 필수적인 요소이다.
COM+ Catalog
COM+는 상당한 양의 관리적 정보를 유지하고 있어야 한다. 예를 들어 COM+는 어떤 콤포넌트가 어떤 COM+ 애플리케이션에 혹한 것인지를
알아내야 한다. 기존에는 레지스트리에 저장할 만큼 적은 양이었지만 이제는 COM+ 카달로그라고 하는 시스템 데이터베이스에 저장해야 할 만큼 그 양이 많다.
Component Service 스탭인은 카달로그 객체들을 다루기 위한 유틸리티 일 뿐이다.
COMAdminCatalog라고 하는 컴포넌트를 통해서 COM+ 카달로그에 접근할 수 있다.
COM+의 문맥(Context)
객체가 현재 어떠한 환경에서 살아가고 있는지를 말해주는 것이 바로 문맥(Context)이다.
어떤 트랜잭션에 속할 수도 그렇지 않을 수도 있다. 또 동기화나 보안 서비스를 사용할 수도 그렇지 않을 수도 있다. 이러한 COM+객체가 처한 상황이 어떠한 것이지를 설명하는 것이다.
COM+는 객체가 활성활될 때 문맥을 생성해서 객체에 부착한다. 컴포넌트가 객체풀링을 허용하지 않으면 객체가 첨은 생성될 때 활성화가 일어난다.
객체풀링을 허용하면 객체를 풀로부터 뽑아올 때 활성화가 일어난다. 일단 객체의 문맥이 생성되고, 객체에 부착되면 그 문맥은 객체가 비활성화, 즉 소멸되거나(풀링되지 않은 객체의 경우), 풀로 돌아갈 때까지(풀링되는 객체의 경우) 변경되지 않는다.
객체의 문맥을 생성할 때 COM+는 카달로그의 항목들을 조사해서 문맥에 넣을 특성들을 결정한다.
COM+ 객체에 붙어다니는 문맥 정보는 문맥객체라는 개별적인 틀에 담기게 된다.
문맥객체는 COM+ 객체에 묵시적으로 연결되는 객체이다. MTS에서는 객체에 대해 GetObjectContext 함수를 호출해서 IOObjectContext 인터페이스를 얻었다.
COM+에서는 문맥객체에 여러가지 새로운 인터페이스들이 추가되었기 때문에 문맥 객체를 사용하기가 훨씬 더 쉬워졌다.
IObjectContextInfo 인터페이스는 상태정보를 담는다.
IContextState 인터페이스는 객체를 트랜잭션에 참여시킬 때 쓰이는 메서드들과 JIT활성화에 관련된 메서드를 제공한다.
ISecurityCallContext 인터페이스는 보안을 다루는 메서드를 제공한다.
문맥객체에 대한 인터페이스들은 CoGetObjectContext를 호출하거나 IObjectContext 인터페이스를 조회해서 얻는다.
| Method |
Description |
| 트랜잭션 메서드들 | |
| IsInTransaction |
객체가 트랜잭션에 속해 있는지의 여부를 돌려준다 |
| SetComplete |
컴포넌트가 자신의 트랜잭션 작업을 마쳤으며, 결과에 만족함을 알린다 |
| SetAbort |
컴포넌트가 자신의 트랜잭션 작업을 마치긴 했으나, 결과에 만족하지 못함을 알린다 |
| EnableCommit |
컴포넌트가 자신의 트랜잭션 작업을 제대로 마치기 못했지만, 결과에는 만족함을 알린다 |
| DisableCommit |
컴포넌트가 자신의 트랜잭션 작업을 제대로 마치기 못했으며, 결과에는 만족하지 못함을 알린다 |
| 보안메서드들 | |
| IsSecurityEnabled |
이 객체에 대해 COM+ 보안 기능이 활동중인지를 뜻한다. |
| IsCallerInRole |
객체의 메서드를 직접 호출한 쪽이 지정된 롤에 속한 멤버인지를 알려준다. 객체 생성 메서드 |
| CreateInstance |
현재 문맥 안에서 새 COM 객체를 생성한다. COM+ 에서는 더 이상 필요가 없어졌다 |
마이크로소프트의 여러 실행환경들은 문맥객체에 여러 가지 정보를 추가한다.
예를들어 IIS가 ASP 페이지를 컴파일할 때는 IIS 환경에서 ASP 스크립트가 제대로 돌아가는데 필요한 내장 객체들을 문맥객체에 추가한다.
ASP 스크립트가 클라이언트로부터 쿠키를 읽어야 한다면 Request라는 객체가 문맥 객체에 추가된다.
보안
엔터프라이즈 애플리케이션에서 보안만큼 중요한 것이 없다.
COM+ 의 보안 기반구조를 그대로 상속받기만 하면 보안코드를 거의 작성하지 않고도 강력한 보안 기능을 갖출수 있다.
인증(Authentication)
인증은 운영체제에 의해서 투명하게 처리된다. 만일 클라이언트오 서버가 지정한 인증수준이 서로 다르면 운영체제는 둘 중 높은 것을 선택한다.
클라이언트가 서버에 익명으로 접그할 수 있게 하려는 경우에만 인증 수준을 없음(None)으로 해야 한다.
암호화의 중요성이 커지고 있으나, 소프트웨어적으로 암호화를 수행하려면 성능에 부담이 생긴다. 도청의 위험을 피하려면 인중 수준을 패킷비공개(Packet Privacy)로 설정해야 한다. 그러면 모든 데이터가 자동적으로 암호화된다
권한 점검(Authorization)
어떤 사용자가 특정 작업을 할 수 있는지를 밝히는 것. 적어도 인증 수준을 호출(Call) 이상으로 설정해야 권한점검이 의미가 있어진다. 인증수준을 없음(None)으로 했다면 의미가 없다.
COM+는 권한 점검 문제를 해결하기 위한 조립식 기반 구조를 제공한다. 이 기반구조에서 핵심적인 개념은 어플리케이션 전역적인 사용자 그룹을
뜻하는 롤(Role)이다. 각각의 애플리케이션마다 고유한 롤들의 집합이 있다.
COM+는 특정 롤의 일원들만이 특정 컴포넌트에 접근할 수 있도록 제한해 준다.
기반 클라이언트가 객체에 대해 메서드를 호출하면 COM+ 중재자(Interceptor)는 호출자가 어떤 롤에 속해 있는지를 카달로그에서
찾는다. 그런 다음 그 롤에 속한 일원들이 그 메서드를 호출할 수 있는지를 알아본다.
그런데 위에서 설명한 롤 점검 과정은 COM+ 애플리케이션 외부로부터의, 즉 기반 클라이언트나 아니면 다른 어떤 COM+ 애플리케이션으로
부터의 호출에 대해서만 수행된다는 점이다. 한 애플리케이션 안의 컴포넌트 A가 컴포넌트 B를 호출하는 것에 대해서는 COM+가 롤 점검을
수행하지 않는다.
ISecurityCallContext 인터페이스를 이용하면 애플리케이션의 업무 로직 안에서 롤 점검을 수행할 수 있다.
서버 프로세스의 신원(Identity)
서버 애플리케이션이 대표하는 사용자("보안 담당자")를 지정해 주어야 한다.
Interactive user를 선택하면 서버 프로세스는 서버에 직접 로그인한 사용자의 보안 권한을 따르게 된다. 이 설정을 사용하면 서버 애플리케이션의 사용자 인터페이스가 서버 컴퓨터에 직접 나타나므로 디버깅하기에는 최적의 조건이 된다. 단 클라이언트가 서버 프로세스를 띄우려고 하는데 서버 컴퓨터에 사용자가 하나도 로그인되어 있지 않으면 클라이언트의 시도는 실패해 버린다. 또 서버 프로세스가 성공적으로 실행되었다 해도 서버쪽에서 사용자가 로그오프 해버리면 서버 프로세스가 종료되며, 결과적으로 클라이언트 역시 떨어져 나가게 된다. Interactive user는 디버깅 목적으로만 선택하는 것이 좋다.
애플리케이션을 실제로 돌려야 하는 상황에서는 This user를 통해서 서버를 대표하는 사용자를 구체적으로 지정하는 것이 좋다. 클라이언트의 신원으로 서버 프로세스를 생성하는 데, 실제로 서버 컴퓨터에 그 사용자가 로그인되어 있지 않아도 상관이 없다.