수안이의 컴퓨터 연구실

[개요]

이전 두개의 아티클에서 호스트 방식을 달리한(사용자정의호스트,IIS) 리모팅서비스 구축을

알아 보았다.

우리는 MarshalByRefObject 상속받는 리모트 클래스를 정의하고 그 클래스의 인스턴스를

원격지 클라이언트에서 사용하는 방법을 알고 있다.

앞서 살펴본 예제에서 우리가 정의한 리모트객체는 과연 어디에서 인스터스화 되었을까?

보통 클래스를 정의하고 그 클래스의 인스턴스를 생성(new 연산자를 통한)하면

실행 컴퓨터의 특정 메모리영역에 인스턴스가 올라가게 되고 그 메모리 주소가 참조를 잃기 전까지는

계속해서 그 인스턴스를 사용할 수 있는게 일반적이다.

또한 일정시간 이상 참조를 당하지 않는 객체는 가비지콜렉트로 넘겨져 GC에 의해 불특정한 시점에

메모리에서 사라지게 된다

그러면 리모팅 환경에서는 과연 어디(서버or클라이언트)의 메모리에 실제 클래스에 대한
인스턴스가 생성되며 그 객체의 수명은 어떻게 될까?

우선, 우리는 리모트객체의 두 가지 타입에대해 알아볼 필요가 있다.

물론 임대기반수명이라는 메커니즘도 존재하지만 이번 아티클에서는
리모트 객체의 타입에 따른 리모트객체의 생명주기와 개별 클라이언트에서의 상태공유를 알아 볼 것이다.

리모트객체의 종류

리모드 객체는 크게 두가지의 종류로 나누어 진다.

Ⅰ. 서버활성화 개체(Well-Known 개체) - 서버가 활성화 한 개체

  ①SingleCall 모드

  ②Signleton 모드

Ⅱ. 클라이언트활성화 개체 - 클라이언트가 활성화 한 개체

우선, 간략히 정리하자면 서버활성화 개체는 클라이언트에서 리모트 객체의 메서드를 호출할때 활성화 되며

클라이언트 활성화 개체는 클라이언트에서 new 연산자로 리모트 객체를 생성할때 활성화 된다.

주의할 것인 위의 서버/클라이언트 활성화 라는 말은 서버/클라리이언트 메모리에 인스턴스가 생긴다는 기준이 아니라

서버/클라이언트에서 리모팅 객체를 활성화 한다는 말이다.

그럼 이제 차례대로 그 차이점을 알아보도록 하자

1. Well-Known(SingleCall) 개체에 대해서 알아보자.

  설정 파일의

  <service>

       <wellknown

           mode="SingleCall"

           type="RemotingServiceDemo.RemotingObject , RemotingObject"

           objectUri="RemotingObject" />              

  </service>

  이 부분에서 우리는 이미 개체의 종류를 명시하였다.

  -SingleCall 모드에서는 두가지를 기억 하여야 한다.

   ㉠ 클라이언트에서 리모트객체의 메서드를 호출할 때 마다 새로운 객체가 만들어 진다.

   ㉡ (데이터의)상태유지가 되지 않는다.

  - 예제를 통해 알아보자

  * RemotingObject.cs (리모트 객체)

   - 객체 생성 시점 확인을 위한 생성자와 데이터의 상태유지 확인을 위한 shareValue 라는 변수를 두었다.

  using System;

  namespace RemotingServiceDemo{

   public class RemotingObject : System.MarshalByRefObject {

     private int shareValue = 0;

     public RemotingObject(){

       Console.WriteLine("원격객체가 새로 생성되었습니다.");

     }      

     public int ADD(){

         return this.shareValue++;

     }

   }    

  }

  * 서버 설정파일의 service 항목 - mode 를 SingleCall로..

  <service>

       <wellknown

           mode="SingleCall"

           type="RemotingServiceDemo.RemotingObject , RemotingObject"

           objectUri="RemotingObject" />              

   </service>

  * 클라이언트 실행 파일

    - 리모트객체 생성시점과 데이터 공유 유/무를 확인하기 위해 메서드를 세번 호출한다.

   using System;

   using System.Runtime.Remoting;

   using RemotingServiceDemo;

   class SimpleClient{

       public static void Main(){

         RemotingConfiguration.Configure("Client.exe.config");      

         RemotingObject remoteObject = new RemotingObject();                        

         for(int i=0; i < 3; i++)

           Console.WriteLine(remoteObject.ADD().ToString());              

       }

    }

  * 클라이언트 설정 파일은 이전과 동일하다.

  * 실행 결과

  * 결론

    실행화면을 보면 클라이언트에서 리모트 객체의 메서드를 호출할때마다
    서버측 리모트객체의 생성자가 실행되며,

    각각이 별도의 객체이므로 데이터의 공유는 전혀 되고 있지 않음을 알 수 있다.

    이처럼 Well-Known 개체의 SingleCall 모드로 리모트 객체를 생성하면 데이터의 공유는 기대할수 없다.

2. Well-Known(Singleton) 개체에 대해서 알아보자.

  설정 파일의 mode 부분만 바꿔주자  

    <wellknown

      mode="Singleton"

      type="RemotingServiceDemo.RemotingObject , RemotingObject"

      objectUri="RemotingObject" />

  * 클라이언트 실행파일

   - 클라이언트에 new 연산자를 두번 사용해서 새로운 객체를 만드는것처럼 했다              

  using System;

   using System.Runtime.Remoting;

   using RemotingServiceDemo;

   class SimpleClient{

       public static void Main(){

         RemotingConfiguration.Configure("Client.exe.config");      

         RemotingObject remoteObject = new RemotingObject();                        

         for(int i=0; i < 3; i++)

           Console.WriteLine(remoteObject.ADD().ToString());  

         RemotingObject remoteObject2 = new RemotingObject();                      

         for(int i=0; i < 3; i++)

           Console.WriteLine(remoteObject2.ADD().ToString());            

       }

    }

  -Singleton 모드에서도 두가지를 기억 하여야 한다.

   ㉠ 리모트개체는 클라이언트의 첫번째 메서드 호출시 리모트 객체가 단 한번 만들어 진다

      다음번 메서드 호출부터는 같은 객체를 쓴다

   ㉡ (데이터의)상태유지가 가능하다.      

  * 실행 결과

  * 결론

    실행화면을 보면 리모트 객체는 클라이언트가 첫번째 메서드 호출시 단한번 생성되고

    그 이후로는 이미 생성된 객체를 사용함을 알 수 있다.

    하물며 RemotingObject remoteObject2 = new RemotingObject()                    

    이 부분에서 클라이언트가 new 연산자로 새로운 리모트 객체를 생성하는 것처럼해도

    같은 객체가 사용된다.

    이것은  Well-Known 개체는 클라이언트의 new 연산자가 아닌 메서드 호출시
    실제로 생성됨을 확연히 알 수 있는 대목이다.

    결론적으로 Well-Known 의 Singleton 모드의 리모트 개체는 클라이언트의 첫번째 메서드 호출시
    단 한번 생성되고,

    GC에 넘어가기 각 클라이언트에서는 하나의 인스턴스를 사용하는 결과를 초래한다.

    이것은 또한 각각의 클라이언트에서 데이타의 공유가 가능함을 의미하기도 한다.

3. 클라이언트 활성화 개체에 대해서 알아보자.

  - 이 개체는 우리가 일반적으로 프로그램을 짤때 클래스의 인스턴스를 생성하는 개념과 유사하다.

    즉 new 연산자를 통해서 인스턴스가 생성되고 각각의 new연산자로 생성된 인스턴스는

    서로 다른 메모리 주소를 가지는 즉 서로다른 인스턴스가 되는 것이다.  

  -Singleton 모드에서는 두가지를 기억 하여야 한다.

   ㉠ 클라이언트에서 리모트객체를 new 연산자로 생성할때 서버에서 객체가 생성된다.

   ㉡ (데이터의)상태유지 가능하다. 단, Signton과는 달리 new 연산자로 생성된 각각의 객체내에서만.

  - 예제를 통해 알아보자  

  * 서버 설정파일의 service 항목 - wellknown 를 activated 로..(종단점이 필요치 않다)

  <service>

       <activated          

           type="RemotingServiceDemo.RemotingObject , RemotingObject"

          />              

   </service>

  * 클라이언트 설정파일 - 역시 wellknown 를 activated 로..(역시 종단점이 필요치 한다)

    <client url="tcp://localhost:4989/ServerHosting">                  

       <activated

           type="RemotingServiceDemo.RemotingObject, RemotingObject"

           url="tcp://localhost:4989/ServerHosting" />      

     </client>      

  * 실행 결과

  * 결론

    실행화면을 보면 리모트개체는 클라이언트에서 new 연산자로 리모트개체를 생성할때
    실제로 생성됨을 알 수 있다

    두번의 new 연산자로 두개의 리모트 객체를 생성한 셈이다.

    여기서의 데이터 공유는 각 객체별로 공유가 가능하다.(일반적인 우리의 객체상식이다)

추가사항

리모트개체에 기본생성자 이외의 생성자 사용에 대해...

만일 리모트개체에 파라메타가 있는 생성자를 정의 했다고 하자.

그럼 클라이언트에서는 그 생성자를 호출 하기 위해서는 new 연산자로 파라메타를 넘겨줘야 한다.

그럼 Well-Known 과 클라이언트 활성화 개체 모두 기본생성자 이외의 생성자 사용이 가능할까??

이미 눈치를 채신분도 있으리라 본다.

답은 클라이언트 활성화 개체만 가능하다

상식적으로 생각해보자.

Well-Known 개체의 생성시점은 클라이언트의 new 연산자가 아닌 메서드 호출시 실제 리모트객체가 생성된다고 했다.

즉 파라메타가 있는 생성자에게 파라메타를 넘겨줄 방법이 없는 것이다.

그러나 클라이언트활성화타입의 개체사용시에는 new연산자로 넘겨주면 된느 것이고... (당연하죠? ^^;>

정리

이상 닷넷 리모팅서비스에서 리모트개체에 대한 타입과 그 타입에 따른 리모트개체 생성시점과

데이터 공유에 대해 알아 보았습니다.

감사합니다.
아래에는 간단히 비교한 표입니다.

[닷넷 리모팅 - IIS를 호스트 서버로 사용하기]

개요

이전 아티클에서 사용자가 정의 호스트를 사용하는 예를 살펴 보았다.
이번에는 그 예제와 동일한 예제로 호스트 방식을 바꿔

IIS가 호스트를 하는 방식의 리모팅 서비스를 살펴 볼 것이다.

달라지는 것은 기존에 서버설정파일이 web.config 로 만들어 져야 하는 것과

종단점이 달라진다는 것이다.

구현

전반적인 설명을 이전 아티클과 동일하며 아래에는 소스코드와 변경된 부분만
간략히 소개한다.(변경된 코드는 색깔을 달리한다)

1. 리모팅 객체는 동일하다.
2. 서버설정파일을 web.config로 만든다.

<configuration>

<system.runtime.remoting>

   <application>

     <service>

       <wellknown mode="SingleCall" type="RemotingServiceDemo.RemotingObject, RemotingObject"

        objectUri="Object1.soap" />

       <wellknown mode="SingleCall" type="RemotingServiceDemo.RemotingObject2, RemotingObject"

        objectUri="Object2.soap" />

     </service>

   </application>

</system.runtime.remoting>

</configuration>

- 개체가 IIS(인터넷 정보 서비스)에 호스팅된 경우에는 요청이
  .NET Remoting IHttpHandler로 라우팅되도록 objectUri의 확장명은 .soap 또는 .rem이어야 합니다

- objectUri="Object1.soap" Object1.soap이 서버의 어떤 클래스와 매핑되어 있는지 정의한다
 

3. 리모팅객체를 컴파일한 어셈블리를 웹응용프로그램 폴더의 bin 폴더에 둔다.
   web.config 를 웹응용프로그램 폴더에 둔다
   (asp.net 와 동일합니다)

-- 서버측 호스팅 준비 끝 --

4. 클라이언트 프로그램 동일.

5. 클라이언트 설정파일

<configuration>

<system.runtime.remoting>

   <application>

     <client url="http://localhost/Remoting">

       <wellknown type="RemotingServiceDemo.RemotingObject, RemotingObject"

        url="http://localhost/Remoting/Object1.soap" />

       <wellknown type="RemotingServiceDemo.RemotingObject2, RemotingObject"

        url="http://localhost/Remoting/Object2.soap" />

     </client>

     <channels>

       <channel ref="http" />

     </channels>

   </application>

</system.runtime.remoting>

</configuration>

   iis 경로와 url만 맞춰 주시면 됩니다.

정리

이전 아티클의 내용중 일부 변경되 사항만을 정리 하였습니다.

이 아티클을 보신다면 이전 아티클(닷넷 리모팅 서비스에 대한 이해) 를 먼저 보고나신 후

이 아티클을 봐 주십시요..

감사합니다.

[.NET 리모팅 서비스]

개요프로젝트의 규모가 커지고 B2B와 같은 기업간 협업형태의 솔류션 개발시 분산환경에서의
개발은 더 이상 이슈화가 될 수 없을정도로 보편화 되고 있다.

초기에는 COM을 개발하고 각각의 분산서버에 물리적인 배포와 설치로 적당히(?) 해결해
왔었다. 그러나 COM의 버전변경등과 같은 이유로 재배포와 재등록의 과정에서
DLL HELL 과 같은 아주 지저분한 문제가 대두되었었다.
(이 경험이 있는 사람은 얼마나 개발자를 짜증나게 하는지 다 알고 있을 듯 싶다)
COM의 배포문제는 DLL HELL 과 같은 문제가 아니더라도 여러가지 불편한 사항들이
많이 있었다.

서버/클라이언트간의 정보교환의 중요성과 필수성이 증가하고 보다 안정적이고 쉬운배포,
생산성의 향상과 같은 요구사항을 만족시키기 위해 DCOM이나 RMI 같은 기술들이 나오게
되었다.(DCOM,RMI는 따로 설명하지 않겠습니다.)

이제는 더욱더 발전해 웹서비스라는 개념이 등장하였고 MS에서는 ASP.NET 웹서비스라는
혁신적인 기술로 개발자에게 쉬운개발,쉬운배포,이기종 플랫폼 호환을 가능케 하였다.

또한 현재 많은 중대형 프로젝트에서 도입하고 있는 닷넷의 스마트 클라이언트
환경에서의 솔루션 개발시 ASP.NET의 라운드트립(포스트백)을 사용하지 않기에
서버와 통신하는 방법으로 웹서비스와 닷넷리모팅이 사용되어지고 있다.

이번 아티클에서는 이 웹서비스와 비슷한 기능을 가진 닷넷리모팅서비스에 대해서
간략하게 알아볼 것이다.

두 서비스 모두 네트워크나 인터넷을 통해 서버/클라이언트간 정보교환을 할 수 있게 하는
서비스이지만 약간의 차이는 있다.

둘간의 차이는 깊이 들어가면 상당히 많은 부분이 있겠지만 간략하게 말을 한다면
웹서비스는 개방형 표준을 준수하여 이기종 플랫폼과 이기종 언어사이에서도 데이터교환이
가능하며,
ASP.NET 웹서비스는 ASP.NET 런타임을 요구하며 호스팅을 위해 IIS를 반드시 필요로 하는 모델인 반면,
리모팅서비스는 SOAP와 같은 표준을 반드시 준수하지는 않으며
IIS와 같은 호스팅서버에 의존적이지 않으며  닷넷환경에 보다 빠르고 유연한 데이터 송수신을 보장한다.


아래는 리모팅 서비스의 실행구조에 관한 몇가지 다이어그램이다.

 

-웹서비스와 마찬가지로 클라이언트에 프록시가 존재하여 서버와 실제 통신을 한다.
(웹서비스도 웹참조를 하면 프록시클래스가 자동으로 생긴다- Reference.cs)
-세번째 다이어그램과 같이 방화벽을 통과하기 위해서는 HTTP에 SOAP로 통신을
해야 한다. (리모팅에서의 데이터 전송 프로토콜과 포멧은 개발자가 지정 가능하다)


= 보다 이론적인 배경은 저도 다 알지를 못하기에 실제 리모팅을 개발하는 개발자

입장에서 소스코드와 함께 간략한 예제를 설명하도록 하겠습니다 =

<configuration>

결과 화면

참고사항위에서 클라이언트측 프로그램(Client.cs)를 컴파일 할때 리모트객체의 어셈블리를 참조하여햐
한다고 했다.
위에서도 언급했었지만 클라이언트에 참조된 어셈블리는 단지 프록시 역할을 할 뿐이다.
참조했다고 해서 그 어셈블리의 객체를 생성하는것이 아니라는 것이다.
확인 방법은
클라이언트에가 컴파일시 참조하는 RemotingObject 의 메서드안에 리턴값을 다른 글자로 변경해서
재컴파일후 Client.cs를 재컴파일된 RemotingObject.dll 을 참조해보자
이렇게...
public string RemotingMethod(){

       return "클라이언트가 바꿔버린 문자";

}
그러면 컴파일을 정상적으로 되고 실행을 해보면 여전히 서버에 있는 RemotingObject.dll이 호출될
것이다.(당연하겠지만 -.-;)
하지만 변경시 네임스페이스명,클래스명, 메서드 시그너처 같은 것은 바꾸면 Client컴파일시 에러가
난다(이것도 당연하겠죠)

정리

어디서나 구할수 있을법한 예제를 가지고 설명을 하였습니다.
하지만 중요한것은 리모팅서비스의 제대로된 이해와 그 이해를 바탕으로 한 응용이라고 봅니다.
리모팅 서비스를 구축할때 알아야 할 것은 이것이 모두가 아닙니다.
앞으로 여건이 된다면 리모팅 서비스의 다른 사항들도 확인해 보겠습니다.

감사합니다.