난이도 : 초급 Doug Davis, ETTK Technical Lead, IBM
2003 년 8 월 19 일 비교적 새로운 개념인 그리드 서비스(Grid services)에 대해 연구해본다. 특히
그리드 서비스가 무엇이며 기존의 웹 서비스를 그리드 서비스로 전환해야 하는 이유에 대해 설명한다.
그리드 서비스
단순한 StockQuote 서비스와 기타 stateless 웹 서비스를 작성하고 관리하는 것은 매우 사소한
일이다. 서비스에서 제공되는 특정 작동(이 경우 getQuote())를 제외하고,
다른 것에 대해 사용자들은 알 필요도 없고 수행할 필요도 없다. 그저 작동을 호출하고 결과를 받으면 된다.
하지만 웹 서비스가 영속적인 데이터를 원할 때 상황은 좀더 복잡해진다.
영속 데이터가 클라이언트에 의해 쿼리되는 방법은 다양하다. 예를 들어 StockQuote 서비스는 getQuote()
메소드를 사용하여 그 시나리오에 맞는 솔루션인 데이터를 리턴한다. 웹 서비스가 노출해야 할 데이터가 여럿이라면?
클라이언트가 데이터가 쿼리할 수 있는 리스트를 얻을 수 있는 표준 방식도 없고 데이터를 얻거나 설정하는
표준 방식 조차 없다. 예를 들어 각 데이터의 경우 서비스는 getFoo()와 setFoo()
메소드를 제공할 수 있지만 그것이 getfoo(), get_foo(),
getFOO(), getFoo()중 어떤 것인지는 아무도
모른다. 작동 이름의 정확한 포맷 같이 사소한 것은 두통거리이다. 이와 같은 문제를 해결하기 위해 Open
Grid Service Infrastructure (참고자료)에서
표준을 개발했다. Grid infrastructure는 클라이언트가 데이터 리스트(Service Data
Elements 또는 SDEs)를 쿼리할 수 있는 표준 방식을 제공한다.
물론 Grid infrastructure가 이 데이터를 관리하도록 하려면 이를 인식하도록 만들어져야
한다. 그리드 스팩 구현에 따라 방식은 다양하다. 이 글에서는 OGSA (Open Grid Services
Architecture) 구현에 기반한 IBM Grid Toolbox와 Emerging Technologies
Toolkit (ETTK) (참고자료)를
사용할 것이다. 이 구현에서 서비스용 WSDL의 포트 유형은 사용할 수 있는 데이터를 언급하는 추가 태그로
수정된다. 예를 들어 다음을 추가할 수 있다:
<sd:serviceData name="CounterState"
type="counter-state:CounterStateType"
minOccurs="1"
maxOccurs="1"
mutability="mutable"
modifiable="false"
nillable="false">
<documentation>Counter State Complex Type</documentation>
</sd:serviceData>
|
CounterState
라고 하는 데이터와 CounterStateType 유형의 데이터가 SDE 로서 클라이언트에
노출되어야 할 것을 Grid infrastructure에 명령하고 있다. 일단 이것이 수행되면 Grid
클라이언트측 API를 통해, 클라이언트는 서비스에 의해 노출된 사용 가능한 Service Data Elements
리스트를 요청하고 각각의 값을 질의 한 다음 (허용된다면) 이를 설정한다.
영속 데이터가 이 그림에 적용되면 영속 데이터 관리와 관련된 문제들은 매우 중요해진다:
- 영속 데이터가 얼마나 오래 지속되는가?
- 사용자는 그 영속 데이터를 어떻게 보는가?
- 모든 사용자들이 같은 인스턴스를 보는 것인가 아니면 그 데이터만의 고유한 인스턴스를 갖는가?
- 만일 그 인스턴트들이 (각각의 사용자용) 이 데이터의 개별 인스턴트라면 사용 가능한 인스턴트 리스트를
사용자가 어떻게 질의하는가?
Grid infrastructure는 클라이언트가 이 정보를 관리할 수 있도록 하는 표준 방식을 제공한다.
특히 클라이언트가 서비스의 새로운 인스턴스를 만들 수 있도록 하고 그러한 인스턴스들을 관리하고 발견하는데
필요한 메소드를 제공한다.
ETTK에서 찾아낸 샘플 웹 서비스인 AddressBook 서비스를 예로 들어보자. 이 예제에서 서비스의
모든 사용자들은 여기에 저장된 같은 주소 세트를 보게 된다. 이 서비스를 Grid 서비스로 전환하면 각각의
사용자들은 자신만의 AddressBook 서비스의 인스턴스를 만들 수 있다. 다른 사용자의 정보에 영향을
주지 않으면서 이름과 주소를 변경할 수 있다. SDE와 유사하게 사용자들은 시스템에 사용할 수 있는 AddressBook
인스턴스가 포함되어 있는지 쿼리할 수 있다. 물론 새로운 서비스 인스턴스를 만드는 것은 저장 문제를 일으킬
수 있다. 이 문제를 해결하기 위해 Grid는 인스턴스가 종료 시간을 선택적으로 가질 수 있는 메커니즘을
제공한다. 시스템은 서비스의 오래된 인스턴스를 자동적으로 파괴할 수 있다.
Grid infrastructure의 또 다른 유용한 기능은 공지 시스템(notification system)
이다. Service Data Element로서 관리 및 노출되는 데이터의 현재 값을 쿼리하는 것 외에도,
클라이언트는 Service Data Elements중 하나가 변경될 때 공지를 받을 수 있도록 요청할 수
있다. 이것은 클라이언트가 Grid 서비스에서 섭스크라이브 작동을 호출함으로서 작동된다. 이때 관심있는
데이터가 어떤 것인지와 클라이언트의 공지 리시버 위치를 알려주면 된다. 따라서 관심있는 데이터가 변경되면
(서버 상의) Grid infrastructure는 공지 메시지를 클라이언트에게 보낸다. 이 메시지를 받으려면
클라이언트는 SOAP 서버를 실행하고 있어야 한다.
Service Data Elements가 변경될 때 공지를 받는 것 이외에도 클라이언트는 서비스의 새로운
인스턴스가 만들어질 때도 공지를 받을 수 있다. 이것 역시 비슷한 방식으로 수행된다. ETTK의 Grid
AddressBook 샘플을 보면 다중 클라이언트들이 같은 Addressbook에 액세스하여 데이터 내에서
클라이언트 중 한명이 필드를 변경하면서 자동으로 업데이트 될 때 이 공지 시스템이 어떻게 사용되는지를 알
수 있다. 그림
1은 이 데모가 사용하는 인터페이스이다.
그림 1. ETTK 데모에 사용된 인터페이스
두 개의 패널이 있고 각각 주소록의 Grid 레파지토리에 액세스하는 클라이언트를 나타내고 있다는 것을
알 수 있다. 상단의 패널을 사용하여 새로운 주소록 인스턴스를 만들 수 있다. 각 클라이언트는 드롭 다운
박스에서 선택하여 어떤 주소록 인스턴스를 볼 것 인지를 선택할 수 있다. 두 클라이언트 모두 같은 인스턴스를
선택하면 변경은 한 쪽에서 이루어지고 이는 다른 클라이언트 패널에서 자동적으로 보인다.
참고자료
필자소개  | | Doug는 Emerging Technologies Toolkit (ETTK)의 기술팀의 책임 멤버이다. |
기사에 대한 평가
| 
