일반적으로 '결합도(Coupling)'란 체인의 연결처럼 두 가지 사물을 하나로 묶는 것을 말한다. 그러나 소프트웨어 개발에 있어서 결합도는 소프트웨어 컴포넌트 및 모듈의 상호 의존성을 의미하는 말로 널이 사용된다.컴포넌트간 결합도는 특정 솔루션이 다른 솔루션과 어느 정도의 연관성을 갖고 있는지를 나타내는 바로미터다. 결합도가 높으면 각 컴포넌트와 부가적인 의존형 객체들이 컴파일 타임 뿐만 아니라 실행 시간에 있어서도 동기화 되어야 하며, 결합도가 낮으면 컴포넌트가 다른 객체와 상관없이 독립적으로 실행될 수 있다.컴파일 타임 결합도흔히 ‘결합’은 개발자가 일반적인 프로그래밍 기술을 사용해 하나 이상의 컴포넌트와 다른 솔루션을 연결할 때 사용한다. 예를 들어 C나 C++ 개발자라면 소스 파일 내에 특정 외부 소스 파일을 포함시켜 컴포넌트를 결합한다. 이 때 외부에서 끌어오거나 삽입한 소스를 보면 현재 클래스나 파일들과 향후 삽입될 것들 사이의 결합도를 짐작할 수 있다. 다음 사례를 보자.
#include #include "externalprocs.h"void doSomething(MyStruct* aStruct) {dumpStructContents(aStruct);}
위를 보면 외부 파일을 삽입하는 소스가 포함돼 있음을 알 수 있다. 첫번째 줄에는 'externalstructs.h'라는 파일이 언급돼 있는데, 'struct MyStruct'이 파일 내에 정의됐음을 예상할 수 있다. 두번째 줄에는 'externalprocs.h'이란 파일명이 있다. 'dumpStructContent' 과정은 이를 이용해 정의된 것이다.이 소스들은 C 언어를 이용해 작성했기 때문에 모든 코드의 의존도는 ‘초기 바인딩(early binding)’이라는 컴파일 타임에 의해 결정된다. 이 때 형성된 컴파일 타임 의존도는 매우 긴밀한 결합도를 나타내는데, MyStruct 구조나 dumpStructContents 서명에 변화가 일어나면 곧바로 doSomething이나 dumpStructContents 등을 포함하는 파일들이 다시 컴파일되기 때문이다.런타임 결합도결합은 상호작용하는 두 개의 컴포넌트들이 동일한 런타임 처리 공간에 존재해야 할 때에도 발생한다. 이런 유형의 결합에서 컴포넌트를 선택할 때는 다른 컴포넌트의 구성 요소를 고려해야 한다.시간 측면의 결합도는 컴포넌트가 런타임에서 다른 컴포넌트를 호출하고, 호출된 컴포넌트가 다시 원래 컴포넌트의 응답을 기다려야 할 때 일어난다. '동기 요청(synchronous call)'이라 불리는 이러한 시간 결합은, 이 과정에서 호출하는 컴포넌트가 대기 시간을 초과하면 애플리케이션에 심각한 장애를 유발할 수 있다(반면 비동기 요청은 시간 측면의 관계에 있어서 각 컴포넌트의 결합을 분리하는 매카니즘을 제공한다).결합도의 이완모든 결합이 나쁜 것은 아니다. 오히려 매우 간단한 프로그램이 아니라면 모든 프로그램에는 일정 수준의 결합이 필요하다. 문제는 결합이 애플리케이션의 능력을 제한하는 요소로 작용할 때다. 애플리케이션의 개발, 테스트, 실행 등 모든 단계에서 나타날 수 있다.대부분의 애플리케이션은 컴포넌트 사이의 결합을 최소화하면 자연스럽게 결합도가 낮아진다. 느슨한 결합도의 컴포넌트들은 안정적인 컴파일 타임과 반대로 런타임에 위치하며 역동적으로 상호작용을 한다. 이처럼 결합 정도가 느슨한 애플리케이션은 결합도가 높은 경우의 부작용을 막을 수 있어 다양하게 활용된다.그렇다면 어떻게 이를 구현할 것인가? 이때는 개발 초기에 애플리케이션을 어떻게 채택할 것인가 하는 방법론보다는 채택 시간의 측면에서 결정된다. 애플리케이션 내부 컴포넌트의 결합을 이완시키는 또 다른 방법은 응답/대답 수준에 관련된 결합 요소들을 제거하는 것이다. 이 방법은 비동기 애플리케이션에 사용할 수 있다.모든 애플리케이션에서 시간 측면의 결합을 해제할 수 있는 것은 아니지만, 이와 같은 강력한 기술은 즉각적으로 반응할 필요가 없는 애플리케이션 환경에서는 큰 이점을 기대할 수 있다.SOA의 결합 완화 효과서비스 지향 아키텍처(SOA)는 서비스와 애플리케이션의 다른 컴포넌트 사이의 결합을 완화시키는 내부 매커니즘을 갖고 있다. SOA를 이용하면 이러한 서비스 요소들을 기억 장소, 프로토콜, 시간 등의 측면에서 다른 컴포넌트들과 확실히 분리할 수 있다.위치투명성서비스는 위치투명성(Location transparency)을 보장해야 한다. 즉 어느 곳이나 위치할 수 있어야 하며, 다른 컴포넌트나 애플리케이션이 서비스를 찾아 사용하기 쉬워야 한다. SOA는 서비스 등록 방법을 통해 위치 투명성을 위한 방법론을 제공한다.일반적인 서비스는 데이터베이스, 디렉토리 서비스, UDDI 레지스트리, 또는 XML 파일 등과 같이 공적/사적 레지스트리로 등록된다. 일단 서비스가 등록되면, 서비스 요청이 필요한 각 컴포넌트들은 서비스 위치 선정과 서비스 요청 등의 작업에 레지스트리를 이용할 수 있다. SOA 플랫폼은 서비스가 채택되는 방법이나 위치 선정에 대한 부담을 덜어주는 방법을 통해 서비스를 등록, 발견할 수 있도록 한다.프로토콜 독립성서비스는 프로토콜에 종속적이어서는 안된다. 어떤 프로토콜이 사용되든 서비스는 항상 동일한 방법으로 커뮤니케이션되어야 한다는 것을 의미하는 것으로, 각 서비스가 커뮤니케이션에 어떤 프로토콜을 사용하는지 알 필요가 없는 것이다.SOA 플랫폼은 언어, XM 혹은 표준 기반에서부터 완전히 새로운 그 무엇까지 다양한 커뮤니케이션 프로토콜을 지원한다. 이때 중요한 것은 서비스가 커뮤니케이션 프로토콜과 독립적으로 개발된다는 사실이다. SOA를 이용하면 새로운 커뮤니케이션 프로토콜을 추가하거나, 서비스 자체에는 추가 작업없이도 새롭고 각기 다른 클라이언트 환경에서 서비스를 지속적으로 실행할 수 있다.시간 독립성서비스 요청은 동기적/비동기적으로 이루어진다. 그러나 실제 서비스에서는 도메인 측면에서 세부화된 사업 구조만 고려하면 되므로, 애플리케이션 각 부분의 서비스 요청과 이용 방법에 대해서는 고민할 필요가 없다. 즉 비즈니스 로직만 같다면 완전히 새로운 별도의 애플리케이션에서도 재활용될 수 있다.물론 이때 일부 애플리케이션이 서비스를 비동기적으로 이용하는 동안 다른 애플리케이션은 이를 동기적으로 이용하고 있을 수도 있다. 하지만 서비스에선 이는 그다지 중요한 사실이 아니다.SOA 환경에서의 느슨한 결합도 사례 ‘지니’지니(Jini)는 SOA의 자바 구현체로, 높은 성능의 서비스들을 이용해 애플리케이션을 개발할 수 있는 플랫폼이다.지니를 이용하면 클라이언트는 서비스를 검색해 찾을 수 있어 서비스 및 서비스 요청 코드와 같은 2가지 컴포넌트가 위치투명성을 가질 수 있도록 한다. 지니가 서비스 위치 장소를 결정하기 때문에 서비스나 서비스 요청 코드는 그 위치를 찾을 필요가 없는 것이다.SOA 결합 이완의 또 다른 장점은 웹서비스와 관련됐다. 웹서비스는 런타임 검색용 UDDI와 같은 레지스트리의 최적화를 통해, 위치투명성을 제공하고 서비스를 구현하는 SOA 방법론으로 점점 각광 받고 있다. 웹서비스 아키텍처는 서비스를 역동적으로 배치, 결합, 요청하는 메카니즘을 통해 느슨한 결합에서 오는 많은 혜택을 제공하며, 서비스 개발자들이 자바나 닷넷 등 다양한 프로그래밍 툴을 동시에 활용할 수 있도록 한다.지금까지 느슨한 웹서비스 결합의 잇점에 대해 살펴 봤다. SOA를 통해 구축할 수 있는 컴포넌트 간의 느슨한 결합 환경은 위치투명성, 프로토콜 독립성, 시간 독립성 등의 장점을 제공한다. @
