현대의 기업 조직 내에서 기업 구성원들은 이미 서로 복잡하게 연결되어 있다. 일상적인 업무 처리를 위한 팀과 팀 간의 연결, 부서와 부서간의 연결 뿐 아니라, 파트너와의 연결, 심지어 경쟁사, 그리고 인터넷을 이용한 고객과의 연결 등이 그 예이다. 이러한 연결은 앞으로 점점 더 복잡하고 넓게 분포될 것이다. 물론 성공적인 비즈니스를 위해 기업 내 구성원들은 유연하게 변화해야 하지만, 이에 못지않게 IT 인프라 또한 기업 환경 변화에 유연하게 적응할 수 있어야 한다. 이러한 변화에 대한 대처 능력을 비즈니스 유연성(agility)이라 한다.
엔터프라이즈 애플리케이션은 기업 구성원이 자신의 비즈니스 목적을 보다 용이하게 달성하기 위해 사용하는 애플리케이션을 의미한다.
그런데 앞서 살펴본 것과 같이 기업 구성원간의 상호 연결의 필연성은 이들이 사용하는 개별 애플리케이션 역시 끊임없이 상호 연결되어야 하는 필요성, 즉 통합에 대한 요구를 내포하게 된다. 뿐만 아니라 누구나 인정하듯 모든 상황에 가장 완벽한 단일한 플랫폼은 존재하지 않으므로 기업 내의 IT 시스템은 이질적인 환경에 노출될 수밖에 없다. 이질적인 플랫폼간의 애플리케이션 통합은 현대 기업 시스템의 필수적인 요구사항이 될 수밖에 없다.
그러나 분석과 설계 단계를 거치면서 성공적으로 구축된 애플리케이션들을 필요에 따라 통합하는 것은 그리 쉬운 일이 아니다. 이를 힘들게 하는 가장 근본적인 이유는 해당 애플리케이션들의 분석과 설계 과정에서 통합에 대한 요구 사항이 결여되어 있기 때문이다.
또한 이것은 개별적인 단위 애플리케이션을 위해서는 비교적 잘 정의된 아키텍처가 있는 반면 애플리케이션과 애플리케이션 통합에 관한 전체적인 아키텍처가 결여되어 있기 때문이기도 하다. SOA는 바로 이러한 유연한 통합에 관한 해결책을 제시한다.

이와 같은 SOA의 도입에 따른 효과를 정리해 보면 아래와 같다.


기존 자산의 이용

SOA를 통해 기업은 현존하고 있는 컴포넌트를 보다 쉽게 통합하여 비즈니스 서비스를 완성할 수 있고, 이것을 기업에 적용시킬 수 있다. 이러한 새로운 서비스 기술은 인터페이스와 이름만 알면 사용이 가능하다. 서비스의 구현은 서비스를 만드는 컴포넌트를 통해 데이터 흐름의 복잡함과 기능적인 컴포넌트를 분리하고 구체화시킨다.
서비스는 조직이 기존의 자산을 이용하며, 서로 다른 기계로부터 서비스를 쉽게 통합할 수 있도록 한다. 이는 서로 다른 운영 시스템을 작동시키며, 서로 다른 프로그램 언어 환경 속에서 개발을 진행하도록 돕는다. 기존의 시스템도 서비스 인터페이스를 통하여 은닉화되고 접근될 수 있다. 가장 중요한 것은 기존의 시스템이 그들의 기능에 서비스의 가치를 부여함으로써 새롭게 변화될 수 있다는 점이다.

IT 컨설팅 회사인 실크로드 사의 사장 팀 바스는 “SOA가 좋은 점은 기존의 포트폴리오를 활용할 수 있게 해 준다는 것이다.”라고 말한다. SOA는 기업이 기존 시스템을 제거하고 새로운 시스템으로 대체할 필요가 없도록 해준다. 기존 시스템의 기능들을 파악한 후 그것들을 활용함으로서, 위험을 최소화하면서 기존 IT 투자의 가치를 극대화할 수 있다는 것이다.


인프라에 독립적

새롭게 개발된 서비스와 다양한 판매자들로부터 얻은 서비스는 잘 정의된 SOA에 의해서 통합될 수 있다. 이러한 서비스들 간의 통합은 존재하고 있는 인프라에 새로운 서비스로서 배치될 수 있다. 그 결과, 기업 내 시스템 인프라는 쉽게 교체될 수 있다. 시간이 지남에 따라 서비스는 하드웨어의 자원으로부터 점점 loosely coupled되고 서비스가 실시간으로 적용이 됨으로써 더 이상 하드웨어 환경에 의존하지 않고 하드웨어를 최적화 할 수 있다.


빠른 시장 접근

서비스는 SOA 의 한 부분으로써 조직의 핵심 자산이 될 것이다. 이러한 서비스를 가지고 SOA를 설계하고 배치시킨다는 것은 시장에의 접근시간을 극적으로 줄여줄 것이다. 이것은 기존의 서비스와 컴포넌트의 재사용, 다자인, 개발, 테스트와 배치 시간을 줄임으로써 가능하다.


비용절감

SOA를 통해 새롭게 요구되는 비즈니스 요구사항을 지원하기 위한 IT 비용을 감소시킬 수 있다. 새로운 서비스를 기존의 서비스들을 통합하여 쉽게 창출할 수 있으며, 기존 레거시에 대한 복잡한 통합 고려사항에 대한 비용을 줄일 수 있기 때문이다. 또한 SOA를 통해 개발부서의 학습곡선을 줄일 수 있다.
SOA를 통하면, 개발자들은 애플리케이션들을 연결하는 새로운 코드를 작성하기 위해 과도한 시간을 낭비할 필요가 없어진다. 대신 개발자들은 웹서비스 같은 표준 프로토콜을 사용할 수 있다. 그리고 SOA 코드의 상당 부분은 재사용이 가능하기 때문에 개발 비용도 줄어든다. 더구나 SOA는 기존에 리거시에 투자했던 것들을 한데 묶어 저렴하게 활용할 수 있도록 해 준다.


위험관리

서비스의 재사용을 통해 새로운 비즈니스를 창출하거나 강화하는 프로세스에 대한 실패 우려를 줄일 수 있다. 또한 서비스를 지원하는 인프라를 관리하고 유지하는 것에 대한 위험은 기존 인프라에 비해 훨씬 줄어들게 된다.


끊임없는 비즈니스 프로세스의 진보

SOA는 특정한 비즈니스 서비스에서 사용되는 컴포넌트의 명령에 의하여 프로세스 흐름이 설명되며, 이것을 명확히 나타낸다. 그리고 비즈니스 운영에 관해서 관리가 가능하도록 사용자들에게 이것을 제공한다. 즉, 프로세스 모델링은 비즈니스 서비스를 반영하는 것이다. 프로세스의 조작은 패턴을 인식함으로써 가능하다. 이러한 기능은, 계속되는 진보에 따른 영향을 관리하는 동안에 프로세스 흐름의 변화를 인식한다.


프로세스 중심의 아키텍처

현존하는 아키텍처나 보아왔던 사례들은 대부분 프로그램 중심적으로 만들어졌다. 즉, 애플리케이션이 프로그래머의 입장에서 만들어진 것이다. SOA 중심의 애플리케이션은 내부에 포함된 비즈니스 로직의 세부사항을 감추는 블랙 박스와 같다. 기존의 방식과 달리 프로세스 중심적인 아키텍처에서 애플리케이션은 프로세스를 위해 개발된다. 프로세스는 단계 별로, 각각을 대표하는 비즈니스 서비스로 분해된다. 이러한 하부 애플리케이션은 사업의 요구사항을 만족시키는 프로세스의 능력을 생성해낸다. 이것은 조직 내에서 프로세스의 이용과 하위 애플리케이션의 재사용을 통해 가능하다.


기업 적응력 향상

SOA의 또 다른 이익은, SOA가 IT 스탭들로 하여금 기술 아키텍처가 아니라 비즈니스 아키텍처 측면에서 생각하도록 강요하기 때문에, IT 스탭들과 비즈니스 중역들 사이의 대화를 더 매끄럽게 해 줄 수 있다는 점이다.
예를 들어, 만약 비즈니스 프로세스가 개선된 재고관리 시스템을 구축하고자 한다면, 비즈니스 실무자는 IT 스탭들과 직접 대화 하면서, 프로세스를 설계/구현할 수 있는 것이다. 결국, SOA가 완벽하게 구축된다면 변화하는 비즈니스 요구와 매순간 바뀌는 시장 조건들에 대한 기업의 적응력은 크게 높아지게 된다.


ROI의 향상

마지막으로 통합이 쉬워지고 유연성이 높아짐으로써 ROI가 높아진다는 부수적 이익도 얻을 수 있다. 다시 말해 개발자들은 모든 종류의 전방처리 시스템들과 작동하기에 충분할 만큼의 일반적인 형태의 서비스를 디자인할 수 있으며, 이로 인해 개발시간이 단축되고 개발자들은 비즈니스 솔루션에 더 많은 시간을 쏟을 수 있게 된다. 여기에 IT 스탭들은 새 기술을 SOA에 쉽게 결합할 수 있어, 위험과 비용을 줄이면서 새 애플리케이션의 개발 속도를 높일 수 있게 된다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SOA는 비지니스 로직과 데이터를 서비스 중심으로 전환함으로써 소프트웨어 아키텍처의 패러다임을 이동시킨다. SOA는 다음과 같은 4가지 원칙을 반영하는데, 이것이 바로 전통적인 소프트웨어 아키텍처 접근방법과의 차이점이다. 따라서, 기존의 아키텍처를 SOA를 기반으로 한 아키텍처로 바꾸어 디자인하기 위해서는 다음 4가지 사항을 유의하여 고려해야 한다.


프로세스 중심

서비스 혹은 애플리케이션 통합에 대한 요구는 결국 비즈니스 프로세스 자동화라는 필요에 의해서 발생된다.
실제로 비즈니스 서비스는 타인에게 자신의 서비스를 제공하는 반면 프로세스 서비스는 이들 간의 통합을 위한 공통 인프라를 제공한다. 비즈니스 서비스가 실제 비즈니스 로직을 제공한다면, 프로세스 서비스는 프로세스 오케스트레이션(Orchestration). 즉, 언제, 어디서, 누구를, 어떻게 통합해야 하는 지 같은 제어 역할을 담당하게 된다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SOA는 다음과 같은 주요 특징을 가진다.

• 서비스는 발견이 가능하고 동적으로 바인딩 된다.
• 서비스는 컴포넌트와 같이 독립된 모듈이다.
• 서비스의 플랫폼간 상호 운용이 가능하다.
• 서비스는 느슨하게 연결된다.
• 서비스는 네트워크 주소로 접근 가능한 인터페이스를 갖는다.
• 서비스는 위치 투명성을 제공한다.
• 서비스의 조립이 가능하다.
• 서비스는 자기 치유(self-healing)를 지원한다.

발견과 동적 바인딩

SOA는 “서비스의 발견과 동적 바인딩”이라는 개념을 지원한다.
어떤 서비스를 필요로 하는 사용자는 작업 수행 중(runtime)에 필요로 하는 서비스를 찾고, 그것을 사용할 수 있는 것이다.
예를 들어 금융관련 애플리케이션에서 신용카드 기능을 포함시키고자 한다고 하면, 금융 애플리케이션은 레지스트리에서 신용카드 기능을 지원하는 서비스를 조회한 후, 자신에게 맞는 서비스를 골라 동적으로 바인딩하게 된다.


모듈 독립성

SOA에서 사용하는 서비스는 컴포넌트에서와 마찬가지로 독립적인 모듈이다. 각각의 서비스는 독립적으로 개발, 유지, 관리되며, 서로의 작동 자체에 큰 영향을 미치지 않는다.
이런 점은 특정 서비스를 수정했을 때 발생하는 파문 효과(ripple effect)를 최소화 시켜 결합도를 낮추는 중요한 특성이 된다.


상호 운용성

SOA에서의 서비스는 플랫폼에 관계없이 상호운용이 가능하다.
각 서비스는 자신을 호출할 수 있는 인터페이스를 제공하고 있다. 이때 호출이 이루어지는 프로토콜과 호출 메시지의 포맷만 이해 할 수 있다면 서로 다른 플랫폼 위에서 개발, 운영 되는 서비스끼리도 통신이 가능한 것이다.


느슨한 연결

각 모듈을 연결하는 방법에는 밀접한 연결(tightly coupling)과 느슨한 연결(loose coupling)이라는 두 가지 방법이 있다. 뒤에 다시 언급하겠지만 느슨한 연결 방법은 단단한 연결 방법에 비해 모듈간의 결합도를 낮춘다.
결합도가 높을수록 한 모듈의 변화가 다른 모듈에도 영향을 주어 파문 효과(ripple effect)를 일으키게 되는데, 파문 효과가 클수록 시스템을 유지보수는 어려워진다. 파문 효과는 하나에 영향이 생겼을 때 다른 것들에 많은 영향을 끼치는 것이다.
대개의 소프트웨어 구조는 결합도가 낮은 것을 지향하는데, SOA에서는 서비스 사용자와 제공자를 느슨하게 연결해 결합도를 낮출 수 있도록 하고 있다.


네트워크 주소로 접근 가능한 인터페이스

네트워크는 SOA의 개념상 그 핵심에 위치하고 있다.
각 서비스는 네트워크 주소를 통해 접근할 수 있는 인터페이스를 제공 하는데, 서비스 사용자는 서비스를 연결하고 있는 네트워크를 통해 그 서비스를 호출하게 된다.
이렇게 네트워크를 통해 사용자가 서비스를 사용할 수 있게 됨에 따라 각각의 서비스는 불특정한 다수의 사용자에 의해 재사용될 수 있게 되는 것이다.


위치 투명성

위치 투명성은 SOA의 핵심 특징 가운데 하나이다.
서비스 사용자는 레지스트리에서 서비스를 찾아 바인딩 하기 전까지는 자신이 사용할 서비스의 정확한 위치를 알지 못한다. 같은 이유로 서비스 제공자가 임의의 이유로 자신의 서비스 위치를 바꾸게 되더라도, 사용자는 쉽게 바뀐 위치의 서비스를 이용할 수 있게 되는 것이다.
또, 서비스를 제공하는 물리적인 위치가 변경 되더라도 DNS의 유지 보수를 통해, 서비스의 제공과 사용에는 큰 영향을 주지 않게 할 수도 있다.


조립

SOA에서의 각 서비스는 재사용성을 높이기 위해 각각의 기능별로 모듈화 되어 있다.
이렇게 모듈화 된 서비스들은 하나의 완성된 기능을 제공하기 위해 조립되는데, 그 방법에는 다음과 같이 크게 세 가지가 있다.

• 애플리케이션에서의 조립
• 서비스 연합(service federation)
• 서비스 오케스트레이션(service ochestration)

애플리케이션에서 서비스를 조립하는 것은 가장 전통적인 방법으로 서비스와 컴포넌트, 애플리케이션의 로직을 기능에 맞게 작성하는 방법이다. 또, 서비스 연합은 보다 큰 범주의 서비스 안에 관련된 서비스들을 모아 관리하는 방법이다. ‘계좌 조회’, ‘입금’, ‘출금’이라는 서비스는 ‘은행 계좌’라는 서비스에 의해 관리되는 것이 그 예이다.
마지막으로 서비스 오케스트레이션은 비즈니스 프로세스를 사용해 각 서비스의 호출 순서와, 에러처리 등을 제어하는 방법이다.


자기 치유(self-healing)

SOA는 자기 치유를 지원한다. 앞에서도 언급했다시피 SOA에 의해 개발된 소프트웨어는 자신이 사용하고 있는 서비스를 발견하고, 동적으로 바인딩 할 수 있다. 만약 SOA에 의해 개발된 소프트웨어가 사용하고 있는 특정 서비스가 임의의 원인에 의해 정상적인 기능을 할 수 없는 경우, 소프트웨어는 그와 같은 기능을 하는 서비스를 새로 찾아 바인딩 하므로서 자신의 내부에 있는 오류의 원인을 제거할 수 있는 것이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

위 그림은 SOA의 기본 구성요소를 도시하고 있는데, 각 요소는 다음과 같다.

• 서비스 사용자(Service Consumer) : '서비스 제공자'에 의해 제공되고 있는 하나 이상의 서비스를 사용한다.
• 서비스 제공자(Service Provider) : '서비스 사용자'가 호출시 입력하는 값을 가공하여, 그에 해당하는 결과를 제공한다. 경우에 따라 '서비스 제공자'는 또 다른 '서비스 제공자'의 서비스를 사용하는 '서비스 사용자'가 될 수도 있다.
• 서비스 레지스트리(Service Registry) : 서비스에 대한 설명 정보(descriptions)를 저장하고 있다. '서비스 제공자'는 자신이 제공하고 있는 서비스를 등록하고, '서비스 사용자'는 자신이 원하는 서비스를 발견하여 사용한다.

여기서 우리는 SOA를 이해하기 위한 세 가지 주요 요소를 추출할 수 있다. '서비스', '메시지' 그리고 '서비스 발견'이 그것이다. 이들 각각에 대한 이해를 통해, 우리는 SOA의 본질에 보다 가까이 갈 수 있다.


서비스

SOA의 관점에서 서비스는 인터페이스를 통해 자신이 가진 비즈니스 프로세스를 처리할 수 있는 컴포넌트로 정의된다. 아래 그림과 같이 서비스는 인터페이스와 구현 부분으로 구성된다.

• 서비스의 인터페이스는 플랫폼에 독립적이다.
• 서비스는 동적으로 발견될 수 있으며, 호출될 수 있다.
• 서비스는 self-contained하다. 즉, 자신의 상태를 스스로 유지한다.

서비스의 탄생으로 인해 자체적으로 소프트웨어를 만드는 기업은 점차 사라지고, 향후에는 만들어져 있는 소프트웨어를 서비스 단위로 구입하여 사용하는 패러다임이 대세를 이룰 것으로 예상된다.

메시지

SOA를 이루는 두 번째 중요한 개념은 메시지이다. 서비스 제공자와 서비스 사용자는 메시지를 통해 서로 통신한다. 서비스 제공자는 서비스 명세를 통해 자신이 가진 서비스의 인터페이스를 공개하는데, 이 명세 내에는 서비스가 제공하는 기능과 이를 이용하기 위해 사용자와 주고 받아야 하는 메시지의 형식이 정의되어 있다. SOA 관점에서 서비스는 플랫폼 독립적이어야 하므로, SOA에서 정의되는 메시지는 특정 기술에 독립적이어야 한다. 아래 그림은 서비스 제공자와 서비스 사용자가 메시지를 통해 통신하는 모습을 보여준다.

• 서비스의 확장성(scalability) 보장
• 서비스 사용자와 제공자의 분리 (decoupling)
• 서비스의 동적인 변경 기능 제공 (hot update)
• 서비스 사용자를 위한 발견 기능 제공 (동적인 발견 기능 포함)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

사실 SOA는 이미 CORBA나 DCOM등의 분산 객체 기술에서 그 기본 개념이 사용되었으나, 기술적인 문제(기술적인 미성숙 및 공개 표준의 부재)와 비즈니스 문제들(주요 소프트웨어 벤더들 간 협력의 부재)로 인하여 그리 큰 주목을 받지 못했다. 하지만 XML 기반의 웹 서비스 기술이 등장하면서 SOA는 새롭게 조명을 받고 있다.

W3C는 SOA를 "호출 가능한 컴포넌트의 집합"으로 정의 하고 있다. 여기서 컴포넌트는 그 인터페이스의 정의 내용이 공개(publish)‧발견(discovery) 가능한 것을 의미한다.
하지만 CBDI는 이 정의에 대해 두 가지 문제점을 지적하고 있다. SOA가 단순한 컴포넌트의 집합이 아니라는 점과, 정의 자체가 아키텍처의 구성 방법 보다는 이미 정의되어 있는 컴포넌트만을 염두 해두고 있다는 점이다. 따라서 CBDI는 SOA를 “애플리케이션의 기능들을 사용자(consumer)에 적합한 크기(granularity)로 공개한 서비스들의 집합으로 제공하고 사용되게 하는 정책(policy), 적용(practice), 또는 프레임워크(framework)"로 정의하고, 이 때 서비스는 ”단일한 표준기반의 인터페이스 형태를 사용하여 구현과 독립적으로 추상화되며, 호출(invoke)되고, 공개(publish)되며, 발견(discover)할 수 있는 것“이라 정의하였다.

즉 SOA란 서비스라 불리는 분할(decomposition)된 애플리케이션 조각들을 단위로 느슨하게 연결해 하나의 완성된 애플리케이션으로 만드는 아키텍처이다.


서비스(Service)의 개념

SOA가 무엇인지 좀 더 명확히 하기 위해서 서비스가 무엇인지 좀더 상세히 설명할 필요가 있다.
일반적으로 서비스란 생산된 재화를 운반·배급하거나 생산이나 소비에 필요한 노무를 제공하는 것을 말한다. 즉 하나의 컴포넌트가 다른 컴포넌트와 인터페이스 계약을 통하여 제공 되어지는 행동을 서비스라고 한다.

사실 “서비스”란 용어는 IT분야에서도 지난 10여 년동안 폭넓게 사용되어왔다. 예를 들면, 이미 1990년대 초기에 트랜잭션 모니터링(Transaction Monitoring) 소프트웨어는 “서비스”란 용어를 사용해 왔다. 이 소프트웨어는 애플리케이션의 플랫폼에 상관없이 미들웨어에서 트랜잭션 모니터링기능을 제공했다. 또한 1990년대 후반부터는 많은 웹 기반 응용시스템들이 검색엔진(search engine)이나 권한(authorization) 관리, 로그인관리 등 공통적으로 사용 할 수 있는 서비스들(shared component services)을 제공해 왔다.

여기서 중요한 사실은 어떤 과정을 거쳐 우리에게 서비스가 제공되는 지는 관심 밖이라는 사실이다. 단지 우리는 원하는 결과물만을 중요하게 생각하고 있다는 것이다.
114 전화번호 안내 서비스를 예로 들어 보도록 하자. 우리는 찾고자 하는 상호를 말하고, 2~3초 정도를 기다린 후 결과물인 전화번호를 서비스 받는다. 여기서 우리는 전화번호를 찾아내기 위한 과정이나, 시스템의 구현 형태, 보안 따위의 문제는 전혀 중요하게 생각하지 않는다. 단지 안내 받은 전화번호와 그 정확성에만 관심을 두고 있다.

그럼 이제 우리가 다루는 SOA에 좀 더 가까운 또 다른 서비스의 예를 들어보도록 하자. 현재 개발하고 있는 시스템에 사용자가 성인인지 여부를 판단해 주는 기능이 필요한 상황이라고 가정해 보자. 하지만 현재 보유하고 있는 관련 데이터가 없어 직접 구현하는 것이 불가능 하다. 이럴 때 이 기능을 서비스로 제공하는 사업자가 있다면 조회 건수당 얼마씩의 비용을 지불하고 손쉽게 이용할 수 있다. 바로 이러한 것들이 SOA에서 말하고 있는 서비스이다. 즉, 우리가 원하는 결과를 어떻게 해서든 제공하고, 우리가 그것을 이용할 수 있도록 하는 것이 서비스인 것이다. 또 이전의 서비스들과 달리 상호운용성을 강조하며 네트워크에서 접근할 수 있도록 공개된 인터페이스를 가지고 있어야 하며,  동적으로 발견‧사용될 수 있어야 한다. 서비스는 여러 애플리케이션으로부터 추출된 것이며, 이들 서비스를 서로 조합하여 비즈니스 프로세스를 구성할 수 있으며, 서비스는 기술적 계층과는 독립성을 갖는다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이상적인 분산 컴퓨팅 환경에서는 사용자들이 서비스를 제공받는데 어떠한 제약도 없어야 한다. 그렇기 때문에 분산 컴퓨팅 환경은 다음과 같은 조건을 충족시켜야 한다.

• 개발언어에 상관없이 서비스가 제공되어야 한다.
• 애플리케이션이 특정한 플랫폼에 종속되지 않아야 한다.
• 제공되는 서비스의 유지보수가 용이해야한다.

이러한 모든 조건을 만족시키기 위해서는 표준화된 기술 요소가 필요한데, 이를 위해 대두된 것이 SOA이다. SOA는 지금까지 소프트웨어 개발을 위해 혁신적인 개념으로 생각됐던 객체지향적인 방법(Object Oriented)에서 컴포넌트 중심적인 방법(Component Based Development)과 모델 기반의 접근 방법(Model Driven Architecture)의 연장선상에 있는 가장 포괄적이고도 현실적인 개념으로 인식되고 있다.
이전에도 비즈니스 로직을 컴포넌트화 하여 이것을 서비스로 보고자 하는 COM+, EJB, CORBA와 같은 개념도 있었지만 이들은 SOA에서의 서비스와는 명확한 차이를 가지고 있다. 이들은 자신이 가지는 프레임워크 내부에서 비즈니스 로직을 어떻게 잘 모듈화 해서 최대의 효율성을 가지게 하는가 에만 주안점을 두고 있다.

"만약 COM+로 만들어진 시스템을 리눅스 사용자가 사용하려 한다면 어떻게 할 것인가?"

바로 이것이 기존의 컴포넌트 중심적인 개념들이 가지는 한계점이다. 각자의 원래(native) 방식으로는 아주 효율적이고 강력하게 개발되고 사용될 수 있지만 자신의 시스템 경계를 넘어설 경우에는 당면하는 문제점들이 너무나 많다.

반면 SOA는 시스템을 누구나 이용 가능한 서비스로 간주하고 연동과 통합을 전제로 아키텍처를 만든다. 즉, 시스템을 개발하면서 처음부터 불특정 다수의 외부 시스템 혹은 고객과의 연동을 고려한다. 여기서 불특정 다수라는 것이 기존 컴포넌트와 큰 차이를 나타내는데, 이는 어떠한 플랫폼에 있는 사용자가 요청을 하더라도 문제 없이 처리할 수 있도록 한다. 또 서비스의 경우 각 서비스의 제공자가 규정한 내용에 따라 개별적인 보안이나 운영 정책을 실현하는 것이 가능하지만, 분산컴포넌트의 관리는 중앙에 집중되어 일괄적으로 운영되는 점도 큰 차이점이다.
그리고 더 나아가 서비스를 이용하기 위해서 특정 기술(EJB, DCOM, CORBA)에 얽매이지 않아도 되기 때문에 매우 유연한 시스템을 만들 수 있다.

유연하다는 것은 'A' 라는 회사에서 제공하던 서비스를 사용하던 소프트웨어가 별다른 수정 없이 'B' 라는 회사에서 제공하는 같은 기능의 서비스를 이용할 수 있다는 것을 의미한다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

분산시스템은 각 시스템의 자원을 공유하기 위해 컴퓨터들이 서로 연결되어 있고, 사용자에게는 하나의 시스템으로 보이게 하는 것을 의미한다.

먼저 현대 분산 컴퓨팅의 흐름을 설명하기 위해 한 가지 예를 들어보도록 하겠다.
거대한 은행이 전 세계에 지점을 가지고 있다. 이 은행은 메인프레임 기반 컴퓨팅 센터를 세계 본부에 두어 왔고 모든 지점들은 메인프레임에 연결된 터미널을 사용해 왔다.
그런데 이 은행은 메인프레임 컴퓨터를 퇴출시키고 분산시스템으로 교체하기로 결정했다. 각 지점은 이제 로컬 계정을 저장하고 로컬 트랜잭션을 처리하는 마스터 컴퓨터를 갖게 됐다. 그리고 컴퓨터는 전 지역 네트워크를 통해 다른 지역 컴퓨터들과 연결되었다. 만약 고객이 있는 장소나 고객의 계정이 저장되어 있는 곳과 상관없이 트랜잭션이 수행될 수 있다면, 그리고 사용자는 새로운 시스템과 기존의 중앙집중(centralized) 메인프레임 기반 시스템과의 차이를 느낄 수 없다면 이는 매우 성공적인 분산시스템이라고 할 수 있다.

전 산업계에 걸쳐 분산시스템으로 옮겨 가는 가장 중요한 이유는 바로 비용이다. 메인프레임 컴퓨터 한대를 구입해서 유지보수 하는 것 보다 여러 대의 PC를 구매해서 관리하는 것이 훨씬 경제적일 수 있다.
하지만 이것은 H/W의 비용만을 의미하지는 않는다. 잘 설계된 분산시스템은 동일한 비용을 들였을 때 훨씬 좋은 처리 능력을 낼 수 있다. 분산시스템은 작업을 업그레이드 하거나 유지하기 위해 연결을 끊을 필요가 없다. 또 사용자에게 불편함을 끼치지 않고, 회사의 중요 업무를 위태롭게 하지 않고도 서버 여러 대의 연결을 동시에 끊거나, 서버를 추가 할 수도 있다. 이에 따라 수용능력 계획도 보다 더 안정적이고 논리적인 방식으로 세울 수 있는데, 필요시점 이전에 미리 처리 능력을 늘리는 것이 그리 어려운 작업이 아니기 때문이다.

이와 같은 환경에서 대두된 것이 분산컴포넌트이다. 분산시스템을 이루는 각 컴퓨터에 필요에 따라 컴포넌트들을 분산시키고, 이것들을 조립하여 하나의 완성된 소프트웨어를 만드는 방법이다. 이렇게 분산 환경에서 사용되는 컴포넌트 기술들에는 CORBA, COM+, EJB 등이 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

소프트웨어의 개발에 있어, 유사한 코드와 알고리즘의 재개발은 비일비재 했던 일이고, 이것은 막대한 시간과 노력, 개발비의 낭비를 불러 일으켰다. 이런 점에서 객체지향프로그래밍은 개발자들로 하여금 다른 프로젝트간의 코드를 공유할 수 있도록 해주기 때문에 큰 인기를 얻었다.
하지만 코드 재사용이라는 것을 잘 이해하려면 보다 정확한 정의가 필요하다. 진정한 코드 재사용이란 코드가 동작하는 방식이나 하는 일을 사용자가 정의할 수 있으면서도, 보다 커다란 것을 만들 때는 재사용 하기에 충분할 만큼 정형화된 코드(normalized code)를 작성해야 한다는 것을 의미한다.
이러한 점에서 기존의 객체지향프로그래밍은 원래 개발자와 그 코드를 재사용하기를 원하는 사람이 동일한 프로그램 언어로 작업해야 한다는 문제가 있다. 예를 들어 클래스 라이브러리가 C++로 작성되었다면 다른 언어로 작성된 프로그램에서는 그 코드를 재사용한다는 것이 기본적으로 불가능하다. 마찬가지로 Java 클래스는 Java프로그램에서만 사용할 수 있는데, 이런 점은 객체지향프로그래밍 언어를 사용하여 보다 많은 소프트웨어 재사용성을 달성할 수 있지만 여전히 한계가 있다는 점을 드러내고 있다.


컴포넌트(Component)

컴포넌트는 객체지향프로그래밍에서의 객체와는 달리 다형성과 상속성을 배제하고 잘 정의된 인터페이스를 통해 소스 코드가 아닌 이진 형식(binary form)으로 재사용 함으로서, 소프트웨어의 재사용성을 극단적으로 높인 일종의 "소프트웨어 조각" 혹은 "소프트웨어의 빌딩블록(building block)"이라고 할 수 있다.
소프트웨어의 개발 과정에서 컴포넌트를 다시 컴파일을 하지 않아도 되기 때문에 컴포넌트의 사용에 있어 프로그래밍 언어의 제약을 받지 않을 수 있다. 이런 과정을 이진 재사용(binary reuse)이라고 하는데, 이것은 컴포넌트를 소스코드 수준에서 재사용 하는 것이 아니라 인터페이스에 기반을 두고 사용하고 있기 때문에 가능하다.

자동차 산업에서도 컴포넌트 사용과 유사한 예를 발견할 수 있다. 완성차 제조 업체는 협력 업체에서 생산한 타이어나, 트랜스 미션과 같은 별개의 자동차 부품을 구입해 조립 함으로서 자동차를 완성한다. 이와 마찬가지로 컴포넌트를 이용하면 외부 업체에서 개발한 소프트웨어 빌딩블록을 조립하여 하나의 완성된 소프트웨어를 보다 쉽게 개발할 수 있다.


컴포넌트의 특성

컴포넌트는 각각 명세(specification)를 가지고, 자신이 제공하는 서비스를 식별하도록 한다. 서비스는 기능을 구체화시켜 이를 통해 밖으로부터 접근할 수 있도록 인터페이스를 제공하는데 여기에는 서비스의 이름과 파라미터 목록이 포함되어 있다.
캡슐화(encapsulation)개념은 객체지향프로그래밍 기술에서와 마찬가지로 CBD에서도 근본을 이루고 이루는 중요한 요소지만, 컴포넌트에 접근해 기능을 수정할 수 있는 방법은 이미 정의된 인터페이스를 통하는 방법뿐이다. 이 "폐쇄 경계(closed boundary)" 개념은 컴포넌트 기술이 객체지향프로그래밍 기술과는 구별되는 특성이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

서비스지향 아키텍처(Services-Oriented Architecture; 이하 SOA)는 최근 각광받고 있는 웹 서비스, ebXML(electronic business XML)등의 모태가 되는 개념으로 새로운 소프트웨어 아키텍처로 주목 받고 있다. 시장조사업체 Gartner는 2006년까지 전 세계 비즈니스 애플리케이션의 80% 이상이 SOA를 기반으로 개발될 것이라고 전망하기도 했다.
앞으로 몇몇의 글을 통해 이러한 SOA가 어떻게 진화되어 왔는지의 과정과 SOA의 개념 및 특징, SOA의 디자인 원칙에 대해 살펴보고, SOA를 도입하면 얻을 수 있는 효과에 대해 기술할 것이다.

사실 SOA는 결코 새로운 개념이 아니다. 이미 SOA의 기본개념은 CORBA나 DCOM등의 분산 객체 컴퓨팅에도 기반이 되었으며, 그 이전부터의 소프트웨어의 생산성을 높이려는 여러 가지 시도들로부터 점진적으로 발전되어 온 것이다.


소프트웨어 위기(software crisis)

컴퓨터가 발명된 이후 소프트웨어의 수요는 기하급수적으로 증가해 왔으나, 개발자들의 생산성이나 인력의 공급은 산술급수적으로 밖에 성장하지 못했다. 다시 말해 컴퓨터가 모든 사회생활에 깊숙이 활용됨에 따라 사용자들은 컴퓨터에 대한 더 많은 지식과 서비스를 요구하고 있으나, 현재의 생산성은 이를 뒷받침해 주지 못하고 있다는 것이다.
이러한 소프트웨어에 대한 '수요와 공급 불균형'은 날이 갈수록 심화되고 있으며, 소프트웨어의 생산성이 향상되지 않는다면 이러한 소프트웨어 위기 현상은 점점 심화될 것이라는 우려를 낳고 있다. 하지만 이러한 위기를 극복하려는 노력이 끊임없이 진행되어 왔고, 현재 시점의 정점에 SOA가 위치하고 있는 것이다.


객체지향프로그래밍(Object-Oriented Programming)

초기의 프로그램들은 컴퓨터의 계기판 스위치를 올리거나 내리는 방식으로 기계어를 이용하여 작성되었다. 하지만 이러한 접근법은 아주 작은 프로그램을 작성하는 데만 적합했으며 이러한 한계를 극복하기 위해 어셈블리 언어가 개발 되었다.
1950년대에 들어서 포트란(FORTRAN)과 같은 고급 언어가 속속 등장 함에 따라, 프로그래머들은 수천 줄의 프로그램을 보다 쉽게 작성할 수 있게 되었다. 그러나 초기의 프로그래밍 방법은 문제마다 서로 다른 접근법을 이용하고 있었다. 이러한 방법은 비교적 짧은 프로그램에서는 문제가 발생하지 않았지만, 대형 프로그램으로 갈수록 스파게티코드(spaghetti-code)라 불리는 복잡한 코드가 될 수 밖에 없었다.
이렇게 복잡한 코드는 1960년대에 등장한 구조적 프로그래밍(structured programming)을 통해 점차 사라져갔다. Algol, Pascal, C 등이 대표적인 구조적 프로그래밍 언어인데, 이들은 잘 정의된 제어구조(well-designed control structure), 코드 블록(code block), GoTo의 사용 억제, 순환 호출(recursion)과 지역 변수를 지원해주는 부프로그램(sub-program) 등에 기반을 두고 있다.
구조적 프로그래밍이 복잡한 프로그램에 적용될 때 아주 좋은 결과를 가져 올 수는 있지만, 특정 크기를 넘어 선 후에는 여러 가지 문제가 발생했다. 더 복잡한 프로그램을 작성하기 위해서는 새로운 프로그래밍 접근 방법이 필요했는데, 이러한 시점에서 개발된 것이 객체지향프로그래밍이다.

객체지향프로그래밍은 소프트웨어 산업에서 오랫동안 호평을 받아온 패러다임 가운데 하나이다. 이는 Ada, Smalltalk, C++, Java, C#과 같은 객체지향언어들의 인기에서도 잘 나타난다.
객체지향프로그래밍 기술은 개발자로 하여금 실세계에서 생각하는 방식 그대로를 소프트웨어로 작성할 수 있도록 해준다. 대부분의 소프트웨어는 우리가 매일 다루는 사물을 모델링하고 가상화 하는데, 객체지향프로그래밍은 개발자가 사물의 존재를 좀더 직관적으로 객체 단위로 코드화 할 수 있도록 한다.
개발자가 객체지향 패러다임을 보다 더 잘 사용할 수 있도록 대부분의 객체지향프로그래밍 언어는 다음과 같은 세가지 개념을 지원한다.

• 캡슐화(encapsulation) : 객체의 상세 구현을 숨기는 기능
• 다형성(polymorphism) : 사용된 객체에 따라 다양한 행동을 보이는 기능
• 상속성(inheritance) : 새로운 객체나 보다 특수화된 객체를 생성할 때 기존 객체를 재사용할 수 있는 기능
  

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.