IT 종합뉴스서비스

[지디넷코리아]많은 개발자들이 효율적인 분산 소프트웨어 시스템을 설계하는데 어려움을 겪는 것은 서비스와 프로세스들이 각각 다른 프로토콜들을 이용해 서로 복잡하게 얽혀 있기 때문이다. 이처럼 분산 시스템 개발과 관련해 문제에 부딪힌 개발자라면 서비스지향 아키텍처(SOA) 기반의 ‘프로토콜 독립(protocol-independent)’ 설계에 관심을 가져볼 만하다.

흔히 분산시스템의 프로토콜을 구성하는 방법은 두가지다. 하나는 프로토콜 상세를 프로세서와 서비스에 캡슐화(encapsulation)하는 방법이고, 다른 하나는 이를 프로토콜 통신 기능을 담당하는 매니저 클래스 안에 포함시키는 방법이다.

그러나 이 두가지 방법은 새로운 프로토콜이 필요할 때마다 설계와 프로그램, 컴파일, 테스트 등을 일일이 다시 해야 하는 단점이 있다. 특정 프로토콜에 종속적인 코드를 사용할수록 서비스와 프로토콜의 상호의존성이 높아지기 때문에 결국 통신 인프라를 변경하는데 잠재적인 걸림돌이 되는 것이다.

프로토콜 독립 설계의 장점
SOA는 서비스 사이의 상호의존성을 최소한으로 하는 것이 특징이다. 이러한 ‘느슨한 연결(loosely coupled)’은 아키텍처의 프로토콜 레이어에 도달하는 모든 방식을 지원해야 하는데, 따라서 SOA 기반의 통신 인프라는 기반 프로토콜 레이어와 독립적으로 설계하는 것이 바람직하다.

SOA와 같은 프로토콜 독립적인 통신 프레임워크는 기존에 사용하고 있는 프로토콜에 얽매이지 않기 때문에, ‘코드 재사용성(code reusability)’이라는 가장 중요한 장점을 제공한다. 또한 기존의 프로토콜을 중단시키지 않고도 이를 대체할 수 있기 때문에, 그동안 새로운 서버를 적용할 때 일반적으로 치뤄야 했던 서버 재시동이나 고객 불만 등 골치를 썩을 필요가 없다.

다음은 대표적인 프로토콜 독립 설계 패턴이다.

비즈니스 위임 : 검색이나 세부사항 접근 등 자세한 비즈니스 서비스 구현사항을 노출시키지 않는다. 다양한 객체와 연결된 자바빈이라면 이를 쉽게 이해할 수 있는 비즈니스 인터페이스로 표현할 수 있다.

원격 프록시와 대리 역할 수행 : 다른 층에 존재하는 객체 대신 역할을 수행한다. RMI의 스텁 클래스 설계가 대표적인 사례다.

어댑터나 래퍼 : 어댑터는 한 상호작용 인터페이스에서 다른 인터페이스로 전달되는 요구를 변환하고 가능한한 응답함으로써, 이종 객체나 서비스에 중단없는 접속할 수 있도록 한다. 자바의 포터블 오브젝트 어댑터가 한가지 예다.

브로커 : 코바의 ORB 환경처럼 다른 부문에 있는 객체와 서비스에서 비즈니스 부문 객체를 분리한다.

팩토리 : 동적 설정에 기반해 실행시간에 실체화된(instantiated) 객체로, 종종 전략 패턴 혹은 브리지 패턴의 객체로 실체화된다. RMI의 커스텀 소켓 팩토리 환경이 그 예다.

프로토콜 추상 레이어
프로토콜 독립 프레임워크에서 가장 중요한 기술이 바로 프로토콜 추상 레이어다. 프로토콜 추상 레이어는 다중 동시 프로토콜을 통해 서비스에 접근할 수 있도록 지원하며, 서비스 개발자로부터 프로토콜 상세를 감추고 서비스 중단없이 프로토콜을 대체할 수 있도록 해 준다. <그림 A>는 프로토콜 추상 레이어의 개념을 보여준다.

<그림 A> 프로토콜 추상 레이어

SOAP를 이용한 프로토콜 독립 설계
SOAP(Simple Object Access Protocol)는 분산 환경에서 정보를 교환할 수 있는 XML 기반의 경량 프로토콜이다. SOAP은 RPC(Remote Procedure Call) 형식의 정보교환 방식과 메시지 기반 방식 모두를 지원하며, 프로토콜과 언어, 플랫폼, 운영체제 등에 종속적이지 않게 설계된 것이 특징이다.

SOAP 명세는 다양한 프로토콜을 사용하는 객체 사이에서 데이터를 교환할 때 사용하는 XML 문서 구조를 정의하고 있다. SOAP 명세 버전 1.2는 특정 노드에서 다른 노드로 SOAP 메시지를 전달할 때 지켜야 할 바인딩 프레임워크를 정의하고 있는데, 바로 이것이 SOAP 프로세서에 프로토콜 독립적이고 프로토콜을 넘어서는 성격을 부여한다. 바인딩 프레임워크를 준수하는 HTTP와 SMTP는 물론 다른 프로토콜에서도 SOAP 버전 1.2 메시지를 전송할 수 있는 것은 이 때문이다.

SOAP 바인딩 프레임워크는 다음과 같다.

바인딩에 의해 제공되는 기능을 선언한다.

SOAP 메시지 전송에 사용되는 기반 프로토콜의 서비스가 어덯게 작동하는지 설명한다.

기반 프로토콜의 서비스가 바인딩에 의해 지원되는 특성에 따라 SOAP 표준을 어떻게 준수하는지 설명한다.

바인딩 내부에서 일어날 수 있는 모든 문제점에 대해 설명한다.

지정된 바인딩의 구조를 구현하기 위해 필요한 사항을 정의한다.

SOAP 바인딩 프레임워크는 이미 기존 코드로 처리하고 있는 프로토콜에 대한 바인딩을 추가로 제공해 현재의 프로토콜 추상화 레이어에 쉽게 통합할 수 있다. 예를 들어 <그림 B>를 보면 SOAP 바인딩 프레임워크와 통합된 프로토콜 추상화 레이어를 보여준다.

<그림 B> SOAP와 프로토콜 추상화 레이어

<그림 B>에서 볼 수 있듯이 서비스 요청 인터페이스와 서비스 호출 인터페이스는 변경할 필요가 없다. 따라서 실행상의 문제나 인터페이스 코드 변경 없이도 간편하게 마이그레이션이 가능하다.

분산 소프트웨어 시스템은 다양한 프로토콜을 이용해 서비스와 프로세스가 상호작용할 때 복잡해지곤 한다. 새로운 프로토콜을 도입할 때도 일반적으로 시스템을 재설계, 재프로그램, 재컴파일, 재테스트하게 된다. 그러나 SOA는 업계 표준에 따라 적절히 설계된 프로토콜 추상 레이어를 기반으로 구축돼 있기 때문에 이러한 불편함을 크게 줄일 수 있다. 때에 따라서는 번거로운 작업 자체를 없앨 수도 있다. @