ACROAMA

기업의 비지니스 환경이 복잡해지고 고객의 요구사항이 까다로와질수록 기업 내 전산 환경은 Heterogeneous한 양상을 띄게 된다. 고객에게 전달할 최상의 서비스가 무엇인지를 고민하고 그러한 서비스를 위해 어떠한 인프라가 가장 적합한지, 또한 그러한 인프라가 IT 자산 합리화 차원에서 적절하게 관리 운영되고 있는지를 끊임없이 체크한다. 고객에게 전달하는 가치의 극대화 측면에서 내부 IT 인력과 자산을 활용하는 것이 합리적인지, 외부의 서비스 소위 SaaS 형태의 서비스를 통해 가치를 전달하는 것이 고객의 요구에 어느 정도 부합하는 것인지 고민하게 되고 결과적으로 Software와 Services가 적절한 배합 비율로 섞인 환경으로 IT 인프라가 변모하게 된다. 또한 급변하는 비지니스 환경에서 기업에게 요구되는 Agility를 확보하기 위해 기존에 개발되어 있는 시스템을 활용하여 새로운 서비스를 고객 요구에 맞추어 빠른 time-to-market을 달성할 수 있다면 그만큼 시장에서 경쟁력을 확보할 수 있게 된다. 고객의 눈높이에 맞는 서비스를 고객이 원하는 시점에 가장 합리적인 방식으로 제공하기 위해 플랫폼 및 개발 언어가 혼용되는 추세가 확산되고 있다.

JEE 기반의 시스템과 연동하여 Silverlight 기반의 더 나은 사용자 경험을 전달하고자하는 시도가 점차 늘고 있다. 아래와 같이 JEE 기반의 시스템이 구축되어 있다고 할 때, Silverlight와 연동할 수 있는 방안을 살펴보자

많이 기업들이 성능상의 이유로 Web Server와 App Server를 물리적으로 한 머신에 넣는 경우가 많은데, 설명의 편의를 위해 분리한 것이며, 이것이 물리적인 분리일 수도 논리적인 분리일 수도 있다. 대부분의 JEE 시스템은 프리젠테이션 레이어에는 Struts과 같은 Servlet기반의 MVC 프레임웍이 위치하여 HTTP 요청을 받아 들이고, 이를 적절한 매핑 매커니즘에 의해 뒷단 비지니스 레이어의 Facade에 전달하게 된다. 뒷단의 Facade는 Session EJB 기반의 Session Facade가 일반적이나 Message-driven Bean일 수도 있고, 같은 머신인 경우 POJO (Plain Old Java Object) 기반의 프레임웍이 많이 사용되는 추세이다. 프리젠테이션 레이어와 비지니스 레이어 사이의 통신은 일반적으로 EJB 호출(RMI/IIOP)이거나, 같이 티어에 위치할 경우 직접 호출을 한다. 사용자의 요청이 비지니스 레이어에서 처리되어 그 응답이 다시 프리젠테이션의 MVC에 도착하면 이를 사용자에게 전달하기 위해 프리젠테이션 레이어에서 뷰 역할을 하는 JSP 혹은 이 기반의 UI 프레임웍에 전달하여 렌더링 엔진에 의해 HTML로 최종 브라우저에 보여지게 된다. 여기에 Silverlight를 넣어보자.

Silverlight가 지원하는 통신 방식은 SOAP 기반의 XML 웹 서비스 (WS-Security까지 지원), REST 기반의 웹서비스 및 소켓 통신 (port : 4502 ~4534) 등 세 가지이며 모두 비동기 전송 방식을 지원한다. 따라서 이 세가지 방식으로 자바쪽 구현체와 통신하면 된다. 위 그림에서는 향후 확장성을 고려하여 웹 서비스 통신 방식을 채택한 것이며, 이를 위해 자바 구현체에서도 SOAP 및 REST 웹 서비스를 위한 장치가 마련되어야 한다. 자바에서 SOAP 기반 웹 서비스는 JAX-WS를 통해 Servlet이나 EJB를 통해 제공하고, REST 기반 웹 서비스는 JAX-RS를 통해 Servlet으로 구현된다. 위 그림은 프리젠테이션 레이어에서 Servlet 기반으로 SOAP 및 REST 기반 웹 서비스를 제공하는 모습을 보여준다. JSP 페이지내에 <object> 태그를 통해 embed 된 Silverlight 애플리케이션은 사용자 머신에 다운로드 되어 서버측 자바 구현체와 직접 통신을 하게 되며 이때부터는 일반적인 표준 웹 서비스 개발 방식에 따라 개발 및 통신을 하면 된다.

위 그림은 사용자 브라우저내의 Silverlight 애플리케이션이 서버측 프리젠테이션 레이어가 아닌 비지니스 레이어의 EJB와 직접 웹 서비스 통신을 하는 경우를 보여준다. REST 기반의 웹 서비스를 제공하기 위해서는 App Server에 별도의 Servlet 컨테이너가 설치되어야 하며, 그림에서는 이미 설치되어 있는 EJB 컨테이너 기반의 JAX-WS 구현체를 통해 통신하는 모습을 보여준다.

근래에 모 파트너사의 MES 솔루션을 본 적이 있었는데, 자바로 구현된 백엔드와 통신하면서 사용자에게 보여지는 화면을 WPF로 구현하려 하고 있었다. 백엔드는 메시지 기반 통신을 위해 메시지큐를 사용하고, 자바로 구현한 JMS 리스너가 있어 전달되는 메시지를 수신하여 비지니스를 구현하고 있으며 백엔드 전체에 대한 조율을 위해 ESB가 위치해 있다. JMS에 대한 접근을 원활하게 하기 위해 닷넷에서 사용할 수 있는 ESB 어댑터를 구현하였고 WPF 애플리케이션에서는 이 어댑터를 통해 JMS와 아무 문제없이 통신하는 모습을 보여주었다.

우리가 숱하게 되뇌고 있지만 정작 놓치기 쉬운 것이 바로 비지니스 포커스 혹은 고객 포커스 관점에서 접근하는 것이다. 비지니스를 위해, 고객을 위해 가장 바람직한 서비스가 무엇인지, 그 다음에 그것을 구현하기 위해 합리적인 선택이 무엇인지 접근하다 보면 점차 많은 영역에서 이기종 플랫폼 및 언어를 접하게 될 것이다. 이 때문에 공개 표준 기반의 상호운용성이 그 어느 때보다 중요하며, 이를 염두해두고 시스템을 설계하는 것이 필요하다.

실버라이트 애플리케이션 개발에 사용할 수 있는 DI (Dependency Injection) 컨테이너로 Unity가 출시됐다. Unity는 Enterprise Library (EntLib)에서 사용하던 ObjectBuilder에 Wrapper를 제공하여 개발자에게 좀 더 편리한 API를 제공하는 DI 컨테이너이며 현재 EntLib 4.1에 함께 포함되어 배포되고 있다. (물론 DI 기능만을 원하는 사람을 위해 별도로 Unity Application Block이라는 이름으로 배포되고 있다.) Unity가 ObjectBuilder의 Wrapper 형태로 제공되다보니 일반 애플리케이션용은 ObjectBuilder 관련 dll들과 함께 배포가 되어야 하지만, 실버라이트용은 이들 기능을 하나의 Microsoft.Practices.Unit.dll 파일에 모두 담아서 좀 더 나은 배포 환경을 제공하고 있다. 아래 관련 링크에서 좀 더 자세한 사항을 확인할 수 있다.

관련 싸이트 :
http://msdn.microsoft.com/en-us/library/dd362339.aspx
http://www.codeplex.com/unity

비단 실버라이트 애플리케이션 뿐만아니라 일반 애플리케이션 개발에 있어서도 간단한 형태의 구현이라면 굳이 프레임웍을 도입하여 프로젝트 복잡성을 증가시필 필요가 있는지 꼼꼼히 살펴볼 필요가 있다. 하지만, 요즘 실버라이트 애플리케이션이 간단한 동영상 플레이어 수준을 벗어나서 엔터프라이즈 영역으로 그 적용 범위를 확장하고 있는 것은 이러한 컨테이너에 관심을 갖을 필요가 있음을 느끼게한다. 인터넷 예약 화면을 좀 더 사용자 중심적인 모습으로 제공하는 것은 기본이고, 기업내 각종 실시간 모니터링 시스템이나, 임원 정보 시스템, BI 대쉬보드 등 결코 가볍지만은 않은 애플리케이션에 점차 확산되고 있는 추세이다. 이런 면에서 볼때 DI 기능을 좀 더 편리하면서 적용할 수 있는 실버라이트 개발용  Unity 출시는 주목할 만하다.

이전 포스트에서도 언급했듯이 실버라이트용 DI 기능을 제공하는 또 다른 오픈 소스 DI 컨테이너로는 NInject가 있다. NInject는 "번개처럼 빠른 DI 기능 제공"이라는 모토를 달고 나왔으며 현재 .NET Compact Framework 까지 지원한다고 밝히고 있다.

크로스 플랫폼, 크로스 브라우저, 크로스 디바이스 구현 기술이자 웹 플랫폼인 Silverlight의 리눅스 짝꿍인 Moonlight가 노벨의 모노 프로젝트를 통해 베타 상태로 공개되었다. Silverlight 1.0에 대응하는 기능을 제공하고 있으며 다음과 같은 리눅스 배포판을 지원한다. 특히 Ubuntu와 Fedora 처럼 데스크탑용으로 널리 쓰이는 배포판에 대한 지원이 눈에 띈다.

1MB 정도의 용량으로 구성되어 있으며 Moonlight 1.0 Beta 1 다운로드 싸이트에서 설치할 수 있다.

참고로, Moonlight를 포함하여 Mono Project를 이끌고 있는 노벨의 Miguel de Icaza가 지난 달 있었던 PDC2008 행사에서 Mono and .NET이라는 세션을 진행하였는데 (놀랍지 않나요?), 세션 동영상은 PDC2008 싸이트에서 감상할 수 있다.

Moonlight에 대한 자세한 사항은 Moonlight 홈페이지를 참고하시길...

<<업데이트 - 2009-02-13>>
Moonlight 1.0 정식 버전이 출시됐으며 아래 싸이트에서 다운로드 받을 수 있다.
http://www.go-mono.com/moonlight/

Silverlght for dummies #1에 이어 Silverlight에 대해 알아야하는 사항들을 간단히 정리해보자.

통신방식
Silverlight로 작성한 애플리케이션은 사용자 브라우저에서 실행되기 때문에 서버쪽과의 통신을 위해 다양한 방식을 지원한다. 기본적으로는 웹서비스 방식과 소켓 방식을 지원하며, 웹서비스 방식에는 ASMX 웹서비스, WCF SOAP 기반 웹서비스(basicHttpBinding), WCF REST 기반 웹서비스를 지원한다. 또한 일반적인 분산 환경에서의 통신 방식과 다른 특이한 점은 소켓을 제외한 웹서비스 방식은 모두 비동기 (Asynchronous) 방식이라는 점이다.
 

샌드박스 (Sandbox) 모델
Silverlight 뿐만아니라, 자바 애플릿 등 웹으로부터 다운로드 받아 브라우저 내에서 동작하는 애플리케이션들은 보안상의 이유로 로컬 리소스 (사용자 PC 및 여기에 연결되어 있는 프린터, 스캐너 등 장비 포함)에 대한 접근을 제한하는 Sandbox 모델을 채택하고 있다. 따라서 이러한 보안 제약을 넘어서서 사용자의 편의를 도모하기 위해 위해서는 singning  등의 절차를 통해 사용자가 안심하고 사용할 수 있는 증명을 해주어야 한다. 또한 이러한 Sandbox 모델에서 금지하고 있는 것중에는, 사용자 PC에 다운로드 되어 운영중인 애플리케이션과 자신이 다운로드 된 서버 이외의 다른 서버와의 통신을 금지하는 것이다. 이를 해결하기 위해 제공되는 것이 Cross domain scripting 이다. 즉, 서버 루트에 "여기 접근 가능한 도메인은 다음과 같은 것들이며, 이들로부터 온 접속만 허용합니다"라는 증명서를 놓는 것.. 따라서 SL 애플리케이션이 해당 서버에 접속하려할 때 자신이 다운로드된 서버 도메인이 대상 서버의 접근 허용 리스트에 있을 때에만 대상 서버에 접속하여 원하는 작업을 수행할 수 있다. clientaccesspolicy.xml 혹은 crossdomain.xml 파일을 작성하여 SL 애플리케이션이 접근하는 서버 루트에 놓아야 한다. Silverlight가 위 xml을 찾는 순서는 clientaccesspolicy.xml을 먼저 찾고 이 파일이 없을 경우 crossdomain.xml을 찾는다. 따라서 가급적 clientaccesspolicy.xml이라는 이름으로 제공하면 좋다. 파일에 담길 내용은 유사하다.

JavaScript와 Silverlight간 통신
JavaScript와 Silverlight 애플리케이션 간에는 쌍방향 통신이 지원된다. 즉, JavaScript가 Silverlight를 이용하여 닷넷으로 구현된 메소드를 호출할 수 있고, 또한 Silverlight의 닷넷 코드에서도 자신이 속한 Html 페이지에 정의된 JavaScript function을 호출할 수 있다.
1. Silverlight의 닷넷 코드를 JavaScript에서 사용하기
System.Windows.Browser.HtmlPage 클래스의 RegisterScriptableObject() 메소드를 이용하여 Silverlight 애플리케이션을 등록하고 노출한 메소드에 ScriptableMember라는 attribute를 지정하면 된다.
 
노출된 Silverlight의 닷넷 코드를 JavaScript에서 사용하는 방법은 아래와 같다.

2. JavaScript fucntion을 Siverlight 닷넷 코드에서 사용하기
아래 그림과 같이 JavaScript function이 정의되어 있다고 가정할 경우...

Silverlight 닷넷 코드안에서 이 JavaScript를 호출하는 방법은 역시 System.Windows.Browser.HtmlPage 클래스를 사용하여 해당 function을 요청하면, System.Windows.Browser.ScriptObject 타입으로 function을 리턴하게 된다. 임의의 닷넷 코드에서 다음과 같은 방식으로 JavaScript function을 호출할 수 있다.

애플리케이션이 구동되면서 화면 가득 정보를 채우고자 할 경우 백그라운드로 다수의 쓰레드를 만들어 서버와 통신하거나 연산 작업을 수행하는 일을 하게 되며, 일이 끝난 경우 이를 화면에 업데이트하는 것이 필요하다. 이 경우에 알아 두어야 할 것이 바로 UI 쓰레딩 모델이다. 대부분의 윈도우용 애플리케이션에서 UI 부분을 업데이트하는 쓰레드는 하나이며, 이는 WPF, Silverlight도 예외가 아니다.
한 애플리케이션 내에서 다수의 백그라운드 쓰레드를 생성하여 사용할 수 있으나, UI를 업데이트하는 쓰레드는 해당 UI 컴포넌트를 만들어낸 UI 쓰레드 하나다. 따라서 많은 쓰레드가 생성되어 백그라운드로 동시에 수행되어 업무 효율을 높일 수 있으나, 그 결과물을 화면에 반영하기 위해서는 UI 쓰레드에게 그 작업을 일임해야 한다. 백그라운드 쓰레드가 Dispatcher를 통해 UI 쓰레드에 작업을 할당하는 방법은 동기식으로는 Dispatcher.Invoke() 혹은 비동기 방식으로는 Dispatcher.BeginInvoke()를 통해서이다.

 
이러한 메소드의 호출을 통해서 전달된 작업들이 Dispatcher가 관리하는 큐에 쌓여 우선순위 (DispatcherPriority)에 근거하여 자신이 할당되어 있는 (즉, 연결된) 쓰레드를 통해 순서대로 실행하게 된다. 또한 Dispatcher는 자신이 연결되어 있는 쓰레드를 레퍼런스로 가지고 있으며, DispatherObject는 이러한 Dispatcher에 대한 레퍼런스를 가지고 있다. 이를 도식화하면, 아래 그림과 같다.

각각은 Association 관계로 엮여 있으며 DispacherObject를 통해 할당되어 있는 쓰레드에 이르기까지 접근이 가능하다. 맨 처음 코드에서 Button에 대해서 Dispatcher를 호출한 후 BeginInvoke()를 호출하여 작업을 일임하는 코드가 가능한 이유는, 아래 그림에서 보듯이 모든 UI 요소들이 바로 이 DispacherObject를 상속받아 만들어졌기 때문에, 상속에 의해 Dispatcher를 속성으로 가지게 되었기 때문이다.

쓰레드가 작업을 진행하면서 UI 요소를 업데이트하려할 때, 과연 이 쓰레드가 해당 UI에 접근 권한이 있는지를 점검하는 로직이 DispatcherObject에 CheckAccess()와 VerifyAccess()를 통해 제공되고 있다. DispatherObject (즉, UI 요소) 가 생성될 때 넘겨 받은 Dispatcher 객체와 접근하고 있는 쓰레드가 엮여 있는 Dispatcher 객체를 비교함으로써 쓰레드가 접근하고자 하는 DispatherObject (즉, UI 요소)에 업데이트 권한이 있는지를 검사하는 것이다.

Silverlight (SL)로 작성한 애플리케이션을 웹을 통해 활용하고자 할 경우에 알아야할 최소한의 것들을 간단히 정리해 보자.

 개발
Expression Blend 툴을 이용하여 시각적인 디자인을 마친후, Visual Studio에서 코드를 입히고 관련 파일들을 묶어 자동으로 .xap 파일로 패키징을 해준다. 패키징 된 .xap 파일을 <object> 태그를 이용하여 아래처럼 HTML 페이지에 추가한다.  .xap은 zip 알고리즘으로 압축한 것으로 일반 zip 관련 툴에서 열어 볼 수 있다.

운영
.xap을 포함한 웹 페이지를 서비스하기 위해서는 웹서버에 다음과 같은 마임타입이 설정되어야 한다. 단, IIS 7은 이미 이러한 설정이 되어 있다. 

확장자 .xaml을 설정하는 경우는 애플리케이션을 SL 1.0으로 작성한 했을 때, 혹은 SL 2로 작성한 애플리케이션이 로딩되는 동안 떠 있을 splash screen 을 사용하고자 할 경우에만 설정한다. splash screen이 .xaml로 작성되기 때문이다. 위 1번 샘플 코드중에 <param name="splashScreenSource" value="SplashScreen.xaml" />에서 보듯이 SL 애플리케이션의 파라메터로 splash screen 정보를 전달한다. splash screen 제어를 자바스크립트로 하는 이유는 당연하게도 아직 SL 애플리케이션이 메모리에 로딩되기 전에 일어나는 일이기 때문이다.

사용자의 PC에 4MB 정도의 SL 런타임이 설치되어 있다면 위에서 언급한 두가지만 설정되면 SL 애플리케이션이 정상 동작하게 된다. 그 외 좀 더 다양한 기능을 사용하고자 하거나 툴을 통해 좀 더 편리하게 개발하고자 한다면 다음과 같은 기능에 관심을 갖도록 한다.

보안
SL 2의 보안 모델은 sandbox 모델을 확장 보완한 모델로서 cross-domain 통신, isolated storage, socket, OpenFileDialog 등을 지원한다. SL 2 애플리케이션은 닷넷의 CAS (code access security)와는 달리 sandbox를 벗어날수 없으며, 권한 상승 등을 요청할 수 없다. 즉, 하나의 trust 레벨만 지원하므로 sandbox 하에서 실행하든지, 아니면 실행하지 않든지 둘 중의 하나다.

ASP.NET Silverlight Control
ASP.NET의 server-side control로서 Silverlight control을 제공하는데, <asp:Silverlight>와 같이 작성된 태그는 컴파일과정에서 클라이언트용 스크립트 및 일반 HTML 구문 (<object> tag 등) 으로 사용자 브라우저에서 동작할 수 있는 코드로 생성된다. 이는 ASP.NET AJAX용 server-side control인 <asp:ScriptManager>와 함께 쓰이며이를 통해 client-side 자바 스크립트 코드를 자동 생성하거나 사용자 PC에 다운로드 받아야 할 자바 스크립트 라이브러리를 지정하는 역할을 한다. 실제 SL 애플리케이션 구동에 관련된 Silverlight.js도 이러한 server-side control이 생성해준 자바 스크립트 코드에 의해 사용자에게 다운로드된다. 물론 ASP.NET이 아닌 다른 플랫폼 가령, JSP나 PHP에서 Silverlight를 적용할 경우에는 Silverlight 구동 및 속성 제어 등등을 자바스크립트로 일일이 작성해주어도 된다. 아래처럼 간단한 ASP.NET 코드가 ......

<asp:ScriptManager>와 <asp:Silverlight>의 도움으로 이처럼 복잡한 HTML을 생성한다.

SL 런타임에는 Media Player가 내장되어 있으며 이를 사용하기 위해서는 <asp:MediaPlayer>를 이용하며 <asp:Silverlight>와 마찬가지로 필요한 자바스크립트가 자동 생성된다.

사용자의 서비스에 대한 눈높이가 심상치 않다. 시장에서 만난 서비스 제공업체 관계자들은 날로 높아져가는 사용자들의 눈높이에 맞추고자 예전보다 나은 사용자 경험을 줄 수 있는 기술을 지속적으로 도입하고 있다. 얼마전 만났던 모 SI 업체 관계자도 이러한 문제를 해결하고자 지도 서비스와 Silverlight를 결합하여 Ajax와 Silverlight가 단독으로 사용되었을 때 보여줄 수 있는 기능 이상의 것들을 둘의 조합을 통해 제공하고자 고심중이었다. 그래서인지 제목과 같은 기사가 눈에 띄었다.
시장의 요구에 부응하는 Virtual Earth와 Silverlight에 관한 표준 기능이 마이크로소프트로부터 공식적으로 나온 것은 아니지만, MS 소속 에반젤리스트가  Silverlight2 애플리케이션에서 Ajax 기반의 Virtual Earth를 사용할 수 있는 Virtual Earth Wrapper for Silverlight를 코드플렉스에 공개하였다.

 

얼마전 MIX08 행사에서는 Silverlight 런타임과 XAML에 좀 더 밀접히 엮여서 제공되는  Virtual Earth Map Control이라는 것이 소개되기도 했는데, 이번 Virtual Earth Wrapper는 말 그대로 JavaScript map control에 대한 Wrapper이다. 관련 리소스는 다음과 같다.

소개 및 개발 관련 동영상 : Channel 9
코드 플렉스 : http://www.codeplex.com/views
테스트 페이지 : http://deepzoom.soulclients.com/VE/
개발자 홈페이지 : http://blogs.msdn.com/jbienz/archive/2008/07/01/virtual-earth-in-silverlight-with-views.aspx