난이도 : 중급 Stefan Hepper, WebSphere Portal Programming Model Architect, IBM
Stefan Liesche, WebSphere Portal Foundation Lead Architect, IBM Development Laboratory
Marcia Stockton, Senior Technical Staff Member, IBM
2005 년 8 월 09 일
서비스 지향 프로그래밍 모델은 인터페이스를 추상화 하고 메시지를 표준화하고, 사용자 또는 관리자가 제어하는 표현 레이어에서
독립적인 정보 소스를 모음으로서 프로그램 대 인간(program-to-human) 인터랙션의 개발을 간소화 할 수 있다.
이번 시리즈에서는 인간 개입 서비스들과 Human Task Manager를 통해서 제공되는 서비스를 설명한다.
이전 글에서는 서비스 지향 아키텍처 개념에 기반한 웹 서비스용 언어 중립적인 데이터 액세스와 프로그래밍 모델을 설명했다.
서비스 지향 아키텍처용 사용자 인터페이스
웹 서비스는 프로그램 대 프로그램(program-to-program) 인터랙션이라는 정황속에서 논의된다.
하지만 이 글에서는 웹 서비스용 SOA 프로그래밍 모델이 인간이 개입하는(human-facing) 서비스의 개발을
어떻게 촉진시킬 수 있는지를 설명하고자 한다. 사용자 개입 UI 컴포넌트를 만들고 이들을 모아서 일관성 있는 UI로 나타내는데
사용할 수 있는 여러 접근 방식들과 프로그래밍 모델이 있다.
더욱이 WebSphere Process Choreographer의 새로운 Human Task Manager 컴포넌트로는 새로운 종류의 서비스를 실행할 수 있다. 소프트웨어에 구현된 비즈니스 프로세스의 프레임웍 내에서 사람들이 서비스를 제공할 수 있다.
Model-View-Controller(MVC) 패러다임은 대부분의 현대적인 UI 애플리케이션 프레임웍의 기본이 된다. SOA의 실행은 모델(Model) 레이어를 제공하는 것이라면 UI는 뷰(View) 레이어를 차지한다. UI 기술은 작은 장치 및 스마트 폰 부터 브라우저와 상당한 양의 클라이언트 측 프로세싱을 처리할 수 있는 리치(rich) 클라이언트까지, 장치에 대한 정보를 렌더링 할 수 있다. 미들웨어와 툴은 뷰 레이어 UI 기술을 모델-레이어 웹 서비스와 데이터에 연결한다.
SOA 접근 방식에서, 컴포넌트를 호스팅하는 환경은 컨테이너(containers)로서 추상화 된다. UI 관점에서 볼 때, 클라이언트 측 UI 컴포넌트를 호스팅 하는 세 가지 주요한 컨테이너가 있다.
- 기본적인 웹 브라우저
- Java™Script와 동적 HTML까지 확대된 웹 브라우저
- IBM Workplace™ Client Technology™ -- Eclipse-rich 클라이언트와 원래의 IBM WebSphere® Application Server 클라이언트 지원
이러한 컨테이너들은 서블릿, JavaServer Pages(JSP), JSP Tag 같은 기술을 지원하면서 증대될 수 있다. 페이지 시퀀싱을 위한 Struts, 고급 페이지 구성을 위한 JavaServer Faces(JSF), 같은 페이지에 여러 애플리케이션의 뷰들을 결합하는 포틀릿 등이 있다.
UI 개발용 프레임웍
UI 개발 프레임웍은 복잡한 사용자 개입 애플리케이션의 생성을 간소화 할 수 있다. 다음의 UI 프레임웍들은 UI 컴포넌트 생성에 자주 사용된다.
-
Struts:
대규모 개발자 커뮤니티와 뛰어난 툴 지원을 갖춘 Struts는 Apache 오픈 소스 프로젝트이다. Java Portlet Specification인 JSR 168(참고자료) 보다 먼저 생긴 프로젝트이다. Struts는 서블릿/JSP 패러다임을 사용하는 서버 기반의 UI 개발용 멀티 페이지 MVC 프레임웍이다. Struts의 특별판인 Version 1.1 라이브러리는 IBM WebSphere Portal 상에 JSR 168 포틀릿을 지원한다.
-
JavaServer Faces:
자바 웹 애플리케이션의 MVC 구현이며 이전 기술을 기반으로 구현되었다. 포틀릿 개발, 포틀릿/서블릿 제공, 상태 핸들링, 밸리데이션, 이벤트에 알맞다. JSF 페이지는 페이지 상에서 UI 컨트롤과 인터랙팅 하는 한 개 이상의 로컬 모델을 갖고 있다. 이러한 컨트롤들은 UI 속성들을 아웃풋으로 렌더링 하고, 세련된 로직으로 표현 로직을 "올바르게" 배치한다. 클라이언트 측 모델은 엔터프라이즈 서비스 버스와 연결되어 이벤트를 송수신 한다.
-
Java Widget Library(JWL):
포탈과 포틀릿 프로그래머들이 사용하는 확장 위젯이며 JavaScript 클라이언트 측 프로세싱을 JSF에 추가하고 IBM Rational® Suitef® DevelopmentStudio에서 지원된다. 클라이언트 상에 로컬로 뷰를 업데이트 하면 서버로의 왕복 시간을 줄일 수 있고 응답 시간을 줄이며 결과적으로 사용자 경험을 향상시킨다.
포탈(Portals)은 일급 UI 지원을 제공한다. 포탈 아키텍처에서 포틀릿(portlet, 위에 언급한 UI 프레임웍들 중 한 가지를 사용하여 개발됨)은 기본적인 구현 블록이다. 이 아키텍처에서는 개발자가 자신의 애플리케이션에만 집중할 수 있고, 수명 주기, 사용자 별 커스터마이징, 집합, 다른 컴포넌트들과의 통합 등의 일반적인 기능들은 미들웨어에 위임한다.
다음 섹션에서는 개별 서비스와 포탈용 포틀릿 컴포넌트를 설명하겠다.
서비스 지향 UI용 포틀릿
포틀릿 컴포넌트는 표준화된 서비스 인터페이스와 프로토콜을 구현한다. Java Portlet Specification과 Web Services for Remote Portlet(WSRP) 표준은 각각 자바와 웹 서비스에 대한 인터페이스를 정의한다.(참고자료) 이 두 개의 표준은 매우 비슷하다. 두 개의 인터페이스에 작성된 포틀릿이 적당한 컨테이너나 프록시만 존재한다면 서로 교환 가능하다.
자바 포틀릿 예제
모든 자바 포틀릿은 포틀릿 인터페이스를 구현하거나 이것을 구현하는 클래스를 확장한다. 이 인터페이스는 포틀릿과 컨테이너 간 서비스 계약을 정의하고 포틀릿 수명 주기를 정의한다.
- 포틀릿을 초기화 하고 이를 서비스에 배치한다. (
init 메소드)
- 요청 핸들링 (
processAction과 render 메소드)
- 서비스에서 포틀릿 없애기 (
destroy 메소드)
요청이 처리되는 동안, 포틀릿 컨테이너는 다음을 호출한다.
-
processAction 메소드를 호출하여 포틀릿에 사용자 액션을 알린다. 클라이언트 요청 당 단 하나의 사용자 기반 액션이 실행된다. 포틀릿은 리다이렉트를 실행하거나, 포틀릿 모드나 윈도우 상태를 변경하고, 또는 이것의 상태를 변경한다.
-
render 메소드를 호출하여 마크업을 요청한다.
포틀릿은 더 많은 서비스들을 호출하여 원하는 기능을 수행 할 수 있다. Listing 1 샘플 에서는 웹 서비스를 사용하여 특정 사용자에게 주식 시세를 디스플레이 하고 있다.
Listing 1. " 주식 시세 포틀릿" 코드 샘플
public class StockQuotePortlet extends GenericPortlet {
private ServiceManager serviceManager;
public void init(PortletConfig config) throws PortletException {
serviceManager = new ServiceManager();
}
public void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException {
response.setContentType("text/html");
// invoke autogenerated wrapper to locate service
NetXmethodsServicesStockquoteStockQuoteServiceLocator loc =
new NetXmethodsServicesStockquoteStockQuoteServiceLocator();
NetXmethodsServicesStockquoteStockQuotePortType port =
loc.getNetXmethodsServicesStockquoteStockQuotePort();
// loop through all stock quotes the user is interested in
PortletPreferences prefs = request.getPreferences();
Iterator quoteKeys = prefs.getMap().keys().iterator();
String key;
Float quote;
StockBean quoteBean = new StockBean();
while ( quoteKeys.hasNext() ) {
key = quoteKeys.next();
quote = port.getQuote (key);
quoteBean.add(key, quote);
}
request.setAttribute("StockQuoteBean", quoteBean);
// render stock quotes using a JSP
PortletRequestDispatcher rd = getPortletContext().getRequestDispatcher("jsp/View.jsp");
rd.include(request,response);
}
}
|
지금까지 Java Portlet Specification을 사용하여 UI 서비스를 구현하는 방법과, 포틀릿으로 추가 웹 서비스들을 호출하는 방법을 설명했다. 다음 섹션에서는 WSRP를 사용하여 UI를 웹 서비스로서 퍼블리시 하는 방법을 설명하겠다.
Web Services for Remote Portlets
WSRP는 포틀릿의 원격 렌더링에 대한 표준으로서 포탈이 여러 소스들로부터 컨텐트를 모을 수 있도록 해 준다. WSRP는 웹 서비스의 통합 기능을 표현 중심의 컴포넌트로 확장하고 뷰 레이어를 플랫폼, 구현 언어, 벤더들에 노출한다. 컨텐트와 애플리케이션 공급자 서비스는 별도의 프로그래밍 없이 표준 순응의 애플리케이션으로 연결된다.
전형적인 웹 서비스는 원격 표현 방식을 사용한다. 모든 뷰 로직이 클라이언트에서 실행된다. 반면 애플리케이션 로직과 데이터 레이어(컨트롤러와 모델)는 서버에 상주한다. 반대로, WSRP는 분산된 패러다임을 채택하여 클라이언트와 서버로 표현을 분리한다.
그림 1. 데이터 지향 웹 서비스와 WSRP 표현 지향 웹 서비스의 비교
위 그림은 그 차이를 보여주고 있다. 왼쪽은 전형적인 데이터 지향 웹 서비스로서 포맷되지 않은 데이터를 제공한다. 데이터 표현을 하기 위해서는 클라이언트 측 렌더링 코드에 전적으로 의존해야 한다. (클라이언트에 클라이언트 측 애플리케이션 컴포넌트를 설치 및 관리해야 한다.) 오른쪽은 WSRP 서비스이다. 분산 표현 로직은 표현 태스크들을 나눈다.
- 마크업 언어의 생성
- 마크업을 웹 페이지로 모으기 (보이지 않음)
- 표준 클라이언트 측 컨테이너에 의한 마크업 언어의 렌더링
WSRP 예제
Listing 2는 Simple Object Access Protocol(SOAP)을 통해 WSRP 소비자가 만든 WSRP getMarkup 요청 예제이다.
Listing 2. SOAP을 통한 WSRP GetMarkup 요청
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<getMarkup xmlns="urn:oasis:names:tc:wsrp:v1:types">
<registrationContext>
<registrationHandle>192.168.66.57_1096235652731_0</registrationHandle>
</registrationContext>
<portletContext>
<portletHandle>0.1</portletHandle>
</portletContext>
<runtimeContext>
<userAuthentication>wsrp:none</userAuthentication>
<portletInstanceKey>ProxyTest_row1_col1_p1</portletInstanceKey>
<namespacePrefix>Pluto_ProxyTest_row1_col1_p1_</namespacePrefix>
</runtimeContext>
<userContext>
<userContextKey>dummyUserContextKey</userContextKey>
</userContext>
<markupParams>
<secureClientCommunication>false</secureClientCommunication>
<locales>en</locales>
<locales>de</locales>
<mimeTypes>text/html</mimeTypes>
<mode>wsrp:view</mode>
<windowState>wsrp:normal</windowState>
<clientData>
<userAgent>WSRP4J Proxy Portlet</userAgent>
</clientData>
<markupCharacterSets>UTF-8</markupCharacterSets>
<validNewModeswsrp:view</validNewModes>
<validNewModes>wsrp:help</validNewModes>
<validNewModes>wsrp:edit</validNewModes>
<validNewWindowStates>wsrp:normal</validNewWindowStates>>
<validNewWindowStates>wsrp:maximized</validNewWindowStates>
<validNewWindowStates>wsrp:minimized</validNewWindowStates>
</markupParams>
</getMarkup>
</soapenv:Body>
</soapenv:Envelope>
|
이 요청에 대한 WSRP 생산자의 응답은 HTML 조각이다. 소비자(일반적으로 포탈)는 이를 완전한 문서(포탈 페이지)로 모은다.
모든 서버에 각 애플리케이션이나 포틀릿을 전개하는 대신 네트워크 전반에 걸쳐 애플리케이션을 공유하는 데에는 분명한 장점이 있다. WSRP는 다음을 가능케 한다.
-
더욱 쉬운 관리 --
연결 가능한 컴포넌트들의 전개(로컬)를 관리하는 대신, 포탈 관리자는 WSRP 서비스가 제공할 레지스트리를 검색할 수 있다. 사용자들은 때에 맞춰 새로운 서비스를 사용할 수 있고 온 디맨드 컨텐트 통합도 가능하다.
-
부하 분산 -- 여러 서버들로 부하가 분산된다.
-
인프라 비용 감소 -- 애플리케이션은 호스팅 인프라를 공유할 수 있다. 예를 들어, 백엔드 뱅킹 애플리케이션의 표현 레이어를 (WSRP를 통해) 분산하면 애플리케이션 공급자의 컴퓨팅 환경은 보안이 유지되고 사용자들은 공유 UI와 인터랙팅 할 수 있다.
-
컨텐트 표현 제어 -- 포탈이 컨텐트를 재배포 하기 때문에 컨텐트와 애플리케이션 공급자들은 새로운 사용자에 접근할 수 있다.
포탈: 서비스 지향 UI의 집합소
여러 백엔드 서비스의 UI들을 중앙에서 관리되는 UI로 통합하는 포탈의 뷰 레이어 통합은 분산된 IT 인프라를 통합시키고 사용자에게 단일 UI를 갖춘 하나의 IT 서비스 뷰를 제공할 수 있다. 원래 개별적으로 설계된 애플리케이션들은 함께 연결되어 합성 애플리케이션이 되고 새로운 기능을 수행한다. 예를 들어, 협업 포틀릿으로 연결된 이메일 포틀릿은 수신함을 걸러 발신자가 온라인일 때 이메일을 디스플레이 하도록 설정할 수 있다.
포탈 모델은 온 디맨드 비즈니스에 향상된 기민성을 제공한다. 관리자들은 새로운 페이지를 정의하고, 포틀릿을 여기에 추가하고, 포틀릿들을 함께 연결한 다음, 이름(액세스 제어)을 설정하여 프로그래밍 없이도 새로운 합성 애플리케이션을 만드는 애플리케이션 통합자가 되는 것이다. 셀프 서비스 포탈에서는 사용자가 자신의 작업 환경을 필요에 맞게 변경할 수 있다. 포탈 아키텍처에서는 애플리케이션 개발자들이 새로운 비즈니스 가치를 만드는 것에만 집중할 수 있다.
앞으로 포탈은 합성 서비스들을 모으고 더 높은 차원에 UI들을 모을 수 있을 것이다. 포탈은 다른 포탈들에서 컨텐트들을 완벽하게 통합하여 수평적인 엔터프라이즈급의 컨텐트를 제공하게 될 것이다.
SOA의 양방향 사용자 인터랙션
WebSphere Portal은 사용자가 서비스 지향 아키텍처에 참여하는 관문이다. 참여는 양방향이다. 사용자는 적절한 포틀릿 인터페이스들을 통해 서비스에 액세스하고 서비스를 제공할 수도 있다.
 |
워크플로우에서의 휴먼 태스크(Human Task)
서비스 공급자 개념은 웹 서비스 범위를 넘어 생각한다면 더욱 익숙할 것이다. 우리 모두는 전화 교환원에게 전화번호를 물어본 적이 있다. 교환원은 음성 서비스 요청에 대한 응답으로 서비스를 제공한다.
따라서 사람은 서비스 공급자가 될 수 있고, 서비스 호출은 포탈 기반의 사용자 인터페이스를 사용하여 웹 서비스로서 구현될 수 있다. 포탈은 태스크에 대한 정보(인풋 데이터)를 사용자에게 주면 사용자는 태스크(서비스)를 수행하고 결과(아웃풋 데이터)를 포탈에 제공한다.
워크플로우 프로세스 내의 휴먼 태스크 예제 중에 보다 이해하기 쉬운 것으로는 소비자에게 안경을 공급하기 전에 안경사가 직접 안경을 검사하는 예를 들 수 있다. 또는 새로운 자동차 타이어를 장착한 후에 제 2의 정비사에게 안전성 검사를 수행하도록 하는 것도 또 다른 예이다. 대규모의 현금 인출을 허용하기 전에 사용자의 아이디를 확인하는 은행원 또한 예가 될 수 있다. 전형적인 비즈니스 프로세스에서 몇 가지 단계는 컴퓨터에 의해 몇 가지 단계는 사람이 수행한다. 그림 2는 인간이 수행하는 서비스와 기계가 수행하는 서비스의 여러 결합 형태이다.
|
|
Human Task Manager
Human Task Manager(HTM)는 비즈니스 워크플로우에 참여하는 사용자에게 통합된 작업 뷰를 제공한다. HTM을 사용함으로서 사용자는 작업을 제공하고 작업을 요청한다. 이 작업은 상응하는 서비스의 실제 구현과는 독립적으로 수행되어야 한다.
HTM은 또한 자동화된 웹 서비스에 인간이 수행하는 작업에 대한 통합 뷰를 제공한다. 시스템은 태스크를 태스크 리스트에 추가하여 인간이 수행할 수 있도록 할 수 있다. 일단 태스크가 수행되면 시스템에 공지가 되고 태스크 실행에 대한 결과를 얻은 다음 프로세싱을 지속한다.
HTM은 사용자가 제공하는 서비스에 대한 요청을 관리하고 조정한다. HTM은 서비스 요청 리스트를 관리한다. 이 리스트는 사용자가 사용할 수 있다. 태스크 리스트는 다양한 사용자들 마다 다르며 기업 내에서의 역할에 의존한다. 예를 들어, 컨텐트 작성자의 태스크 리스트에는 생성할 컨텐트에 대한 요청이 포함되는 반면 그의 관리자의 태스크 리스트에는 부서원이 만든 컨텐트에 대한 승인 요청이 포함된다. 사용자가 자신의 작업 리스트 상의 특정 작업을 수행하려면 태스크를 요청하고, 요청된 액티비티를 수행하고, 그 결과를 HTM에 전달한다.
사용자들은 HTM을 사용하여 그러한 작업이 수행되도록 요청한다. 요청된 서비스는 또 다른 사람이나 자동화된 서비스가 제공한다. 태스크는 전형적으로 비즈니스 프로세스 같은 장기 실행이다. 서비스 요청은 현재의 서비스 공급자와는 독립되어 있다. 따라서 서비스 요청자를 변경하지 않고도 서비스 공급자를 변경할 수 있다. 인간이 직접 제공하는 서비스는 자동화된 서비스로 대체될 수 있고 또 그 반대로 대체될 수 있다. 사용자는 HTM을 사용하여 요청된 작업의 상태를 쿼리할 수 있다. HTM은 초기화된 태스크의 상태를 제공한다.
그림 2. Human Task Manager 시나리오
요약
SOA 개념을 사용자 인터페이스에 적용하고 일반적인 소프트웨어 수명 주기를 포탈/포틀릿 아키텍처를 사용하는 UI 컨테이너에 위임하면 소프트웨어 개발자의 작업을 향상시킬 수 있다. WSRP 표준은 컨텐트 공급자와 컨텐트 소비자 모두에게 이익이 된다. 별도의 프로그래밍 없이도 애플리케이션 집합을 실행할 수 있다. 포탈 프레임웍은 포틀릿을 사용자 인터페이스로 모은다. SOA에 참여한 사용자는 웹 서비스로 모델링 되어서 Human Task Manager를 통해 인터랙션 할 수 있다.
참고자료 교육
토론
필자소개 | 
| Stefan Hepper, WebSphere Portal Programming Model Architect, IBM |
| 
| Stefan Liesche, WebSphere Portal Foundation Lead Architect, IBM Development Laboratory |
| 
| Marcia Stockton, Senior Technical Staff Member, IBM |
기사에 대한 평가
| 
