기업의 비지니스 환경이 복잡해지고 고객의 요구사항이 까다로와질수록 기업 내 전산 환경은 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와 아무 문제없이 통신하는 모습을 보여주었다.
우리가 숱하게 되뇌고 있지만 정작 놓치기 쉬운 것이 바로 비지니스 포커스 혹은 고객 포커스 관점에서 접근하는 것이다. 비지니스를 위해, 고객을 위해 가장 바람직한 서비스가 무엇인지, 그 다음에 그것을 구현하기 위해 합리적인 선택이 무엇인지 접근하다 보면 점차 많은 영역에서 이기종 플랫폼 및 언어를 접하게 될 것이다. 이 때문에 공개 표준 기반의 상호운용성이 그 어느 때보다 중요하며, 이를 염두해두고 시스템을 설계하는 것이 필요하다.
댓글을 달아 주세요
엄밀히 말해 "JEE와 연동"이라는 기사 제목은 잘 못 기재하셨습니다. 상기 언급하신 구성은 WS을 통한 Cross Platform간 서비스 호출의 일반적인 기본 구성을 .Net와 Java 기반 Platform 기준으로 설명하신 것입니다. 이와 같은 두터운 설명의 "층"은 아직도 ASP.NET을 WS로 인식하고 있는 MS Platform 개발자가를 양산(?)하는 하나의 이유가 되지 않고 있나 생각합니다. WS의 기본설계사상은 기간 시스템의 "재활용" 입니다. 즉, 필요시점에서 특정 플랫폼의 비즈니스컴포넌트를 타 플랫폼에서 사용할 수 있도록 쉅게 서비스 할 수 있다는 점이며, 이 점에서 시스템 유연성을 위해 무조건적인 상호운용성의 적용은 개발편이성과 생산성을 놓칠수 있다는 점을 간과해서는 안됩니다.
말씀하시는 요지가 무엇인지 금방 와 닿지 않는군요. 이 포스팅의 목적은 Silverlight을 쓰고 싶으나 백엔드를 자바를 쓰고 있는 기업에서 사용할 수 있는 방안을 제시하는 것이었습니다. 모 전자에서 자바 백엔드와 연동하기 위해 Flash/Flex와 Silverlight 가 어떤 방식을 제공하는 문의가 들어와 작성했던 것을 일반화한 것입니다. 즉 억지로 그림을 보여주기 위해 양단을 끼워 맞춘 것이 아니라 기존 JEE 기반 백엔드를 활용하면서 자바가 부족한 UX를 닷넷이 채워주고자 하는 방안입니다.