사전지식
 com+
 spring.net

서문
Spring.net을 통해 com+ 을 사용하시는 분들이 당연히 많으실꺼라 의심하지 않는다. 
이번해 테스트 겸 작업을 진행하며 모호한 부분들에 대해서 정리할 심산으로 작성한다.
어짜피 내가 실력이 허접해서 좀 피곤했을 수도 있다. ^^;

많은 사람들이 com+ 의 장점과 단점을 알고 있고 그리고 그 장점을 활용하기 위해 각종 설정과 등록과정등을 거쳐 드디어 사용하고자 하는 test 용 또는 client 프로그램을 실행하여 테스트를 시작한다.
그나마 3tier , 4tier 가 흔한 개발 환경에서 해당 com+ 을 리모팅 , Webservice , wcf 등으로 서비스로서 제공한다면 그 서버 기능들 까지 활성화 해가며 테스트를 해야한다.
.net 2.0 이후 System.Transaction 기능이 들어오면서 메서드 단위 Transaction 이 되고 MTS 를 위해 꼭 com+ 을 등록안해도 MTS 가 사용가능한 환경이 왔지만 com+ 또 다른 장점인 객체 관리 기능에 대해 무시 할 순 없다.
Spring 의 가장 강한 장점인 IoC 로서 com+ 로의 등록 목적이 아닌 component 도 com+ 로 등록할수 있도록 Service 를 제공한다.
그외에도 Service(webservice, remoting, wcf 등(?) )들에 대해서도 spring container 를 통해 서비스가 가능하다.
이렇게 됨으로써 이제 개발 환경과 배포 환경을 완전히 분리 가능하다.
예를 들어 하나의 dll 로 config를 통해 webservice , remoting , wcf 로 서비스 가능하고 com+ 로 등록이 되도록도 가능하다. 
 그런데 이글의 내용의 포커스가 com+ 에 대한 사용 방법일까? 
 솔찍히 다른 서비스에 대해서는 별다른 이질감 없이 바로 적용할 수 있었다 ( 그만큼 springframework.net 의 메뉴얼은 잘되어 있었다.) 그러나 com+ 과 관련한 내용이 좀 적고 com+ 에 대한 이해가 없으면 안될만한 내용이 있어 지극히 개인적으로 관리 목적으로 적고 그리고 혹시나 저 처럼 고생하는 분들이 없으면 좋겠다 라는 마음에 작성하게 되었다. ^^ 마음껏 욕(?)해주시면 감사하겠다.

본문
1. 아주 간단한 dll 을 하나 작성한다.

이게 다다 자 이것을 이제 com+ 에 등록할수 있게 만들어야 한다. 말그대로 테스트(?) 인것이다.
이게 하나의 dll 로서 EnterObject.dll 로 작성된다.

여기서 주의 사항이 하나 있다. Com+ 로 등록시 IAddService 라는 것이 안보인다. Library 형식으로 com+ 서비스가 등록되었다면 별다른 문제가 없다. 만약 com+ 에 Server 형식으로 서비스가 된다면 문제가 된다. 이 문제를 해결하기 위해 AssemblyInfo.cs 에 있는 ComVisible(false) ComVisible(true)  설정 한다.
Library 형식과 Server 형식의 차이점을 모르신다면 검색해서 확인 한번 해보시면 com을 이해하는데 도움이 될꺼라고 생각한다. 

이렇게 함으로써 차후 com+ Service 등록후의 IAddService 라는 Interface 형식이 노출된것을 확인해볼수 있다.
( 등록된 com+ 의 Interface 로서 IAddService 가 등록된것이 보이는가?  ^^ )




2. 이제 com+ 을 등록할 window 또는 console  Project 를 하나 더 추가한다.
이 프로젝트 정말로 할꺼 없다. 단순히 Com+ 에 대한 등록만을 전담한다. 
정말이지 많이 본 내용 아닌가? 샘플에도 있다. 샘플보다 몇가지를 더 추가한것 정도이다.
코딩으로 하면 각 클래스에 종속적으로 다 설정되어야 하는 내용들이다. 
AddService 가 보이는가?
당연히 등록 되어 있어야 한다.

이제 com+ 의 설정부분을 보겠다.
자. 여기에서 주의 할점  ActivationMode 는 기본적으로 library 이다. 그러나 나는 Server가 의미가 있으므로 Server 로 설정한다. (만약 library 도 상관없다면 이 글이 아니라. spring 에서 제공해주는 것만으로도 충분하다.) , 그리고 Property name 중 Assembly 가 보이는가? 이것은 먼저 만든 EnterObject 라는 샘플 dll 을 어떤 dll 이름으로 노출할지에 대한 설정이다. ( 나는 여기서 오해 했다 만들 Assembly 명인가?? 라는 생각을..... 난 바보였다.  ㅠㅠ )
이렇게 대략 spring 과 관련된 정보들을 셋팅하고 빌드 한다. 그러면 참 서비스 좋게도 자동으로 com+ 로 등록까지 자동으로 해주신다. ( 아 ... 편해..~~! ) 그리고 Assembly 에 등록한 value 이름으로 dll 도 하나 만들어 주신다. ( 빌드 패스에 있다. )
여기서 극악의 장점? 단점? 테스트는 해보지 않았으나 만약 EnterObject 에서 com+ 로 등록할 클래스를 2개 만들고 Assembly 로 2개를 노출하게 되면 물리적으로 2개로 분리가 가능할것으로 보이나 테스트는 나중으로 미룬다... 하.하.하. ( 확인해 보았더니 잘!!! 된다.!!! )

이렇게 하고 난후 샘플에서 제공 하는 방법으로 서비스 받으면 된다. 혹시 귀찮으신 분들을 위해.
자.. 끝났다.. addComponent 라는 이름으로 등록된 com+ 의 기능을 enter 라는 이름으로 끌어내 사용하면 된다.

여기서 추가로.. com+ 로 등록된 이 addComponent 를 바로 remoting 이나 wcf , webservice 로 오픈 가능할까?  답은..... 가능하다.. 이다. ( 너무 당연한 이야긴가? ^^;; )

추가로 이렇게 remoting으로 서비스 후 com+ 등록 내용이 변경 되었을 경우 remoting 의 재시작 없이 com+ 의 shutdown 만으로 수정된 내용이 반영된다. ( 이걸 위해서 였다. 흑흑... ㅠㅠ ) 혹시 이 방법 말고서비스의  끈김없는 pooling 이 가능 한 방법을 안다면 알려주시면 감사하겠다. ( 혹시나 iis app pool 은 테스트 해보았고 잘되는 것도 확인 하였다. 그러나 web 기반 서비스 이다 보니 속도 문제가 있어서... )

중간에 큰 작업없이 일을 진행할려고 하다보니 이런모습으로 작업된것 같다. 

p.s. 혹시 질문 있으시면 email 도 좋고 리플도 좋으니 이런부분들에 대한 정보를 공유 했으면 좋겠습니다. ^^





 

신고
posted by Bloody Guy

Web.config 에서 httpHandlers 에서 *.aspx 파일에 대한 핸들을 다른 객체로 변경했을 경우 아주 당연한 이야기 겠지만 사용이 불가능하다.

more..


기본적으로 설정되지 않으나. springframework.net 사용시 aspx 파일에서 injection 에 대한 관리를 하기 위해서 설정 한다.

설정하지 않았을시 aspx 파일에서는 injection 되지 않는다.

다른 방법으로 사용하여야 하는데 springframework 의 ContextRegistry의 GetContext 를 이용하여
해당 타입을 가져 올수 있다.

<Sample Code>
public CtrlType getSeesionObject<CtrlType>(string CtrlTypeName)
{
    IApplicationContext ctx = ContextRegistry.GetContext();
    return (CtrlType)ctx[CtrlTypeName];
}

그리고 Injection을 Ctrl class 를 별도로 두어 Page 에서는 해당 object 들에 대한 injection 을 한다.

신고
posted by Bloody Guy
제어역행(IoC) 는 스프링 프레임워크의 핵심이다.
제어역행의 의미는 무엇인가?

마틴파울러는 2004년의 글에서 제어의 어떤 측면이 역행되는 것인지에 대한 의문을 제기했다. 그는 의존하는 객체를 역행적으로 취득하는 것이라는 결론을 내렸다. 그는 그와 같은 정의에 기초하여 제어 역행이라는 용어에 좀더 참신한 "의존성 주입(dependency injection)" 이라는 이름을 지어줬다.

Ioc 를 적용함으로써 객체들은 시스템 내의 각 객체를 조정하는 어떤 외부의 존재에 의해 생성 시점에서 의존성을 부여 받는다. 즉 의존성이 객체로의 주입(inject) 된다는 말이다.
따라서 IoC는 한 객체가 협업해야 할 다른 객체의 참조를 취득하는 방법에 대한 책임의 역행이라는 이미를 갖는다.


신고
posted by Bloody Guy


티스토리 툴바