서비스 지향 아키텍처(Service Oriented Architecture, 약칭 SOA 「에스오에이」혹은 「소아」로 발음)란 대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상에 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하여 그 서비스를 네트워크상에 연동하여 시스템 전체를 구축해 나가는 방법론이다. 업무 처리 변화를 시스템에 빠르게 반영하고자 하는 수요를 대응하기 위해 2004년부터 IT 업계에서 주목을 하고 있다.
목차[숨기기] |
[편집]정의
- 토마스 얼은 그의 저서 SOA 서비스 지향 아키텍처에서 서비스지향 아키텍처(SOA)를 다음과 같이 정의하고 있다. 최신 SOA는 공개, 기민성, 확장, 연합, 자립적 요소들로 구성된 조합가능한 아키텍처, 서비스 품질, 다양한 벤더, 상호 운영성, 서비스 발견 그리고 잠재적으로 재사용 가능한 서비스들이 웹서비스로 구현된다. SOA는 비지니스 로직과 기술을 추상화하여, 이 도메인 간에 느슨한 결합을 유도한다. SOA는 과거 플랫폼의 진화물로서, 전통적인 아키텍처의 특징들을 고스란히 가지고 있으며, 명확한 원칙을 가지고 SOE를 지원하며 서비스 지향을 촉진한다. SOA는 엔터프라이즈 환경을 이상적으로는 표준화하지만, 치밀한 사전 계획에 의한 이전 필요성과 현재도 진화하고 있는 기술에 대한 지원만이 이러한 목적을 달성할 수 있다.
- 책 “Enterprise SOA(Dirk Krafzg, Karl Banke, Dirk Slama)”에서는 서비스 지향 아키텍처를 “애플리케이션 프론트엔드, 서비스, 서비스 리포지토리, 서비스 버스의 주요 개념에 바탕을 둔 소프트웨어 아키텍처이다. 서비스는 계약, 하나 이상의 인터페이스, 그에 대한 구현으로 이루어진다.”라고 정의 하고 있다.
- W3C의 Web Service Architecture Working Group에서 활동하고 있는 Hao He 박사는 “상호 작동하는 시스템 사이를 느슨하게 연결하려는 목적을 가진 아키텍처(Service Oriented Architecture is an architectural style whose goal is to achieve loose coupling among interacting software agents)”라고 정의 하고 있다.
[편집]구성요소
[편집]서비스
- 명확한 기능적인 의미를 지닌 소프트웨어 컴포넌트로, 고차원의 비즈니스 개념을 캡슐화 하고 있는 것을 말한다. [1]
- SOA의 관점에서 서비스는 인터페이스를 통해 자신이 가진 비즈니스 프로세스를 처리할 수 있는 컴포넌트로 정의된다. 서비스는 인터페이스와 구현 부분으로 구성된다. 서비스가 가지는 특징을 다음과 같이 3가지로 요약할 수 있다. [2]
- 서비스의 인터페이스는 플랫폼에 독립적이다.
- 서비스는 동적으로 검색될 수 있으며, 호출될 수 있다.
- 서비스는 self-contained하다. 즉, 자신의 상태를 스스로 유지한다.
[편집]메시지
SOA를 이루는 두 번째 중요한 개념은 메시지이다. 서비스 제공자와 서비스 사용자는 메시지를 통해 서로 통신한다. 서비스 제공자는 서비스 명세를 통해 자신이 가진 서비스의 인터페이스를 공개하는데, 이 명세 내에는 서비스가 제공하는 기능과 이를 이용하기 위해 사용자와 주고 받아야 하는 메시지의 형식이 정의되어 있다. SOA 관점에서 서비스는 플랫폼 독립적이어야 하므로, SOA에서 정의되는 메시지는 특정 기술에 독립적이어야 한다.[2]
[편집]특징
- 서비스는 발견이 가능하고 동적으로 바인딩된다. [2]
- 서비스는 컴포넌트와 같이 독립된 모듈이다. [2]
- 서비스의 플랫폼간 상호 운용이 가능하다. [2]
- 서비스는 느슨하게 연결된다. [2]
- 서비스는 네트워크 주소로 접근 가능한 인터페이스를 갖는다. [2]
- 서비스는 위치 투명성을 제공한다. [2]
- 서비스의 조립이 가능하다. [2]
- 서비스는 자기 치유(self-healing)를 지원한다.[2]
[편집]참고문헌
[편집]관련도서
- SOA 서비스 지향 아키텍처 - 저자 : 토마스 얼, 출판사 : 성안당
- SOA 서비스 지향 아키텍처 - 저자 : 에릭 마크스 & 마이클 벨, 출판사 : 엠플래닝
- 엔터프라이즈 SOA - 저자 : 더크 크래프지그 & 칼 방케 & 더크 슬라마, 출판사 : 태극미디어
- SOA, What & How: A Road to SOA - 저자 : 전병선, 출판사 : 와우북스
[편집]관련기술
영림원소프트랩 개발설계실 김진환 과장
1. 들어 가는 말
모든 기업은 비즈니스 영속성을 전제로 존재한다. 그렇다면 불확실성이 높고 빠르게 변하는 경영 환경에서 기업이 살아남기 위해 갖추어야 할 기본 소양은 무엇인가? 해답은 지속적인 혁신이다. 당면한 비즈니스 문제 해결뿐만 아니라 장기적인 관점에서 공고한 기반을 다지기 위해서는, 시시각각 변화하는 역동적인 시장 요구사항에 민첩하게 대응할 수 있는 인프라를 구축하는 것이 진정한 비즈니스 혁신의 핵심 요소라 할 수 있다. 이에 실시간 기업, 경영혁신, 차세대 시스템 등의 여러 가지 개념이 생겨났으며, 이 중 SOA(Service Oriented Architecture, 서비스지향 아키텍처)는 단연 IT업계 최대의 화두로 떠올랐다. SOA는 1996년Gartner 그룹에 의해 최초 소개되었다. Web Service ebXML (electronic business XML) 등의 모태 개념인 SOA는 비표준 맞춤형 어플리케이션 표준 프로세스 기반 아키텍처로 Gartner 보고서에 따르면 2006 년까지 전 세계 비즈니스 어플리케이션의80% 이상이 SOA를 기반으로 개발 될 것이라고 전망 되고 있다.
이 글에서는 SOA의 기본 개념, SOA의 등장 배경에 대하여 살펴보고, 최신 SOA의 필요성과 비즈니스 어플리케이션 측면에서의 SOA역할에 대해 간략히 살펴 보고자 한다.
2. SOA의 등장배경
초기의 프로그램들은 기계어(어셈블리어)를 이용하여 작성되었으나, FORTRAN과 같은 고급 언어가 등장함에 따라 프로그램을 쉽게 작성 할 수 있게 되었다. 그러나 초기의 프로그래밍 언어들은 문제마다 접근법이 각각 다르고 대형 프로그램을 개발하기가 복잡한 문제를 안고 있었다. 이러한 문제는 구조적 프로그래밍 언어의 정의된 제어구조, 코드블록, 순환호출 및 지역 변수를 지원하는 부프로그램 함수를 이용해서 해결해 왔으나 문제 해결 방식이 직관적이지 못해 현재에는 객체라는 직관적인 방법을 도입한 객체지향적 프로그래밍언어(C++, Java, C#)를 통해 프로그램을 개발하고 있다. 객체지향적 프로그래밍 언어의 출현 이후에는 코드의 재사용을 위한 다형성, 잘 정의된 인터페이스를 통해 이진 형식으로 재사용을 위하여, 컴포넌트개발방법론(CBD : Component Based Development)에 대한 연구가 진행 되었다.CBD에서는 문제 해결을 위해 소프트웨어 블록(Component)을 통한개발, Component의 생성, 통합, 재사용을 고려한 개발을 해오게 된다.
분산컴포넌트는 플랫폼, 운영체제, 소프트웨어 등의 환경 제약 없이 분산환경에서 개별적, 독립적으로 실행 될 수 있는 컴포넌트(CORBA, COM+. EJB 등)를 말한다. 이상적인 분산환경에서는 사용자들이 분산 컴포넌트의 이용에 어떠한 제약도 없어야 하며, 이를 위해서 분산컴퓨터환경은 아래조건을 충족해야 한다.
■ 개발언어에 상관없이 서비스제공
■ 플랫폼 독립적 컴포넌트
■ 쉽고 간단한 서비스의 유지보수
그러나 CORBA, COM+, EJB 등은 자신의 프레임워크에서 독립적이지 못하다. 이에 반해 SOA는 표준화 된 인터페이스와 XML을 이용한 인터페이스 노출로 개발 언어에서 독립, Messaging Protocol을 이용한 약결합으로 쉽고 간단한 유지보수,
플랫폼에 보다 유연한 웹기반으로 플랫폼에서 독립함으로써 SOA가 등장하였다.
3. SOA의 기본 개념
SOA는 소프트웨어 아키텍처의 일종이다. 따라서, SOA를 이해하기 위해서는 이를 구성하고 있는 요소들을 파악할 필요가 있는데, 이 장에서는 먼저 SOA와 서비스를 정의하고 이를 기반으로 구성요소들을 살펴보도록 한다.
1) SOA의 정의
사실 SOA는 이미 CORBA나 DCOM등의 분산 객체 기술에서 그 기본 개념이 사용되었으나, 기술적인 문제(기술적인 미성숙 및 공개 표준의 부재)와 비즈니스 문제들(주요 소프트웨어 벤더들 간 협력의 부재)로 인하여 그리 큰 주목을 받지 못했다. 하지만 XML 기반의 웹 서비스 기술이 등장하면서 SOA는 새롭게 조명을 받고 있다. W3C는 SOA를 "호출 가능한 컴포넌트의 집합"으로 정의 하고 있다. 여기서 컴포넌트는 그 인터페이스의 정의 내용이 공개(publish), 발견(discovery)이 가능한 것을 의미한다.
하지만 CBDI는 이 정의에 대해 두 가지 문제점을 지적하고 있다. SOA가 단순한 컴포넌트의 집합이 아니라는 점과, 정의 자체가 아키텍처의 구성 방법 보다는 이미 정의되어 있는 컴포넌트만을 염두 해두고 있다는 점이다. 따라서 CBDI는 SOA를 "애플리케이션의 기능들을 사용자(consumer)에 적합한 크기(granularity)로 공개한 서비스들의 집합으로 제공하고 사용되게 하는 정책(policy), 적용(practice), 또는 프레임워크(framework)"로 정의하고, 이 때 서비스는 "단일한 표준기반의 인터페이스 형태를 사용하여 구현과 독립적으로 추상화되며, 호출(invoke)되고, 공개(publish)되며, 발견(discover)할 수 있는 것"이라 정의하였다. 즉, SOA란 서비스라 불리는 분할(decomposition)된 애플리케이션 조각들을 단위로 느슨하게 연결해 하나의 완성된 애플리케이션으로 만드는 아키텍처이다.
2) SOA의 구성요소
SOA의 기본 구성요소는 아래와 같다.
- 서비스 사용자(Service Consumer) : '서비스 제공자'에 의해 제공되고 있는 하나 이상의 서비스를 사용한다.
- 서비스 제공자(Service Provider) : '서비스 사용자'가 호출시 입력하는 값을 가공하여, 그에 해당하는 결과를 제공한다. 경우에 따라 '서비스 제공자'는 또 다른 '서비스 제공자'의 서비스를 사용하는 '서비스 사용자'가 될 수도 있다.
- 서비스 레지스트리(Service Registry) : 서비스에 대한 설명 정보(descriptions)를 저장하고 있다. '서비스 제공자'는 자신이 제공하고 있는 서비스를 등록하고, '서비스 사용자'는 자신의 원하는 서비스를 발견하여 사용한다.
SOA의 기본 요소는 서비스, 메시지 그리고 서비스 발견 등이 있다.
가. 서비스(Services)
SOA의 관점에서 서비스는 인터페이스를 통해 자신이 가진 비즈니스 프로세스를 처리할 수 있는 컴포넌트로 정의된다. 서비스는 인터페이스와 구현 부분으로 구성된다. 서비스가 가지는 특징을 다음과 같이 3가지로 요약할 수 있다.
- 서비스의 인터페이스는 플랫폼에 독립적이다
- 서비스는 동적으로 검색될 수 있으며, 호출될 수 있다.
- 서비스는 self-contained하다. 즉, 자신의 상태를 스스로 유지한다.
서비스의 탄생으로 인해 자체적으로 소프트웨어를 만드는 기업은 점차 사라지고, 향후에는 만들어져 있는 소프트웨어를 서비스 단위로 구입하여 사용하는 패러다임이 대세를 이룰 것으로 예상된다.
나. 메시지 (Messages)
SOA를 이루는 두 번째 중요한 개념은 메시지이다. 서비스 제공자와 서비스 사용자는 메시지를 통해 서로 통신한다. 서비스 제공자는 서비스 명세를 통해 자신이 가진 서비스의 인터페이스를 공개하는데, 이 명세 내에는 서비스가 제공하는 기능과 이를 이용하기 위해 사용자와 주고 받아야 하는 메시지의 형식이 정의되어 있다. SOA 관점에서 서비스는 플랫폼 독립적이어야 하므로, SOA에서 정의되는 메시지는 특정 기술에 독립적이어야 한다.
다. 서비스 발견(Discovery)
서비스 발견이란 서비스 사용자가 서비스 레지스트리로부터 자신의 원하는 서비스 제공자를 찾는 작업을 말한다. 이를 위해서는 서비스 레지스트리는 서비스를 등록하고 발견하는 기능을 제공해야 한다. SOA의 관점에서 서비스 레지스트리는 다음과 같은 요구사항을 만족해야 한다.
- 서비스의 확장성(scalability) 보장
- 서비스 사용자와 제공자의 분리 (decoupling)
- 서비스의 동적인 변경 기능 제공 (hot update)
- 서비스 사용자를 위한 검색 기능 제공 (동적인 검색 기능 포함)
3) SOA의 특징
SOA가 가지고 있는 중요한 특징을 정리하면 다음과 같다.
- 서비스는 발견이 가능하고 동적으로 바인딩 된다.
- 서비스는 컴포넌트와 같이 독립된 모듈이다.
- 서비스의 플랫폼간 상호 운용이 가능하다.
- 서비스는 느슨하게 연결된다.
- 서비스는 네트워크 주소로 접근 가능한 인터페이스를 갖는다.
- 서비스는 위치 투명성을 제공한다.
- 서비스의 조립이 가능하다.
- 서비스는 자기 치유(self-healing)를 지원한다.
4) SOA의 이점
SOA는 기업 내의 어플리케이션 아키텍처를 보다 유연하고 확장 가능하도록 구성할 수 있게 하는 패러다임이다. 이러한 특징으로 인해 기업은 SOA를 통해 다음과 같은 이점을 얻을 수 있다.
- 기존 자산을 최대한 이용할 수 있게 한다.
- 빠른 시장 접근이 가능케 한다.
- 전반적인 IT 비용을 절감해준다.
- 위험관리를 용이케 한다.
- 끊임없는 비즈니스 프로세스의 진보를 이루게 한다.
- 프로세스 중심의 아키텍처를 유지할 수 있게 한다.
5) SOA 와 Web Services
SOA와 웹 서비스의 관계는 많은 자료에서 언급하고 있다. 일반적으로 그 내용은 거의 유사하지만 제시하는 기관마다 약간의 시각차이가 존재하고, 특히 SOA를 정의하는 관점에 따라서도 차이가 존재한다. 여기서는 여러 자료를 토대로 SOA와 웹 서비스의 관계를 도출하고 구체적으로 웹 서비스를 통해 SOA를 구현하는 방법까지 정리하였다.
가. SOA와 웹 서비스의 관계
SOA는 웹 서비스 개념보다 먼저 출현하였으며, 웹 서비스 보다 포괄적인 개념이다. SOA는 소프트웨어 개발 패러다임에 가깝고, 웹 서비스는 이러한 SOA의 패러다임을 실현하기 위한 다양한 기술 구현 사례라고 할 수 있다. 이름에서 알 수 있듯이 SOA는 아키텍처이다. 웹 서비스와 달리 특정 기술의 집합이 아니다. SOA는 기술적인 것을 초월할 뿐만 아니라 기술로부터 독립적이다. 비즈니스 환경에서 SOA의 순수한 아키텍처적인 정의는 "호출 가능한 잘 정의된 인터페이스를 갖는 독립된 기능의 서비스로 정의한 애플리케이션 아키텍처"이다. 반면, 웹 서비스는 기술의 집합이며 SOA의 개념을 보다 구체화한 것이다. 웹 서비스는 단순히 SOA를 구현한 것만은 아니다. 웹 서비스는 SOA 구현의 Best Practice라고 할 수 있다. 왜냐하면 SOA의 근본적인 철학을 고스란히 실현할 수 있도록 플랫폼 독립적인 프로토콜과 기술을 채택했기 때문이다. 웹 서비스가 HTTP, XML, SOAP, WSDL, UDDI 등의 프로토콜을 채택한 것은 SOA의 기본적인 요구사항을 만족하기 위해서라고 할 수 있다. 이들 기술은 특정 컴퓨팅 기술에 중립적이며, de-facto 표준에 가깝다.
웹 서비스는 SOA를 개념 수준에서 구현이 가능한 현실로 끌어올리는데 중요한 역할을 한다. 현재도 웹 서비스를 이루는 기술표준들은 진화하고 있으며, 이들이 보다 견고해짐에 따라 SOA를 채택하기 위한 위험요소도 점차 제거될 것으로 기대된다.
나. 웹 서비스를 이용한 SOA의 구현
SOA에서 기본적으로 요구하는 컴퓨팅 관련 사항과 웹 서비스의 대응 기술은 다음과 같다.
- SOA는 플랫폼 독립적인 방식으로 호출될 수 있는 서비스로 구성된다 - XML, SOAP
- 서비스는 플랫폼, 프로그래밍 언어에 독립적인 인터페이스를 갖는다. - WSDL
- 서비스는 표준체계에 의해 등록이 가능하며, 동적으로 발견 가능하다. - UDDI
웹 서비스는 W3C SOAP 1.2 표준을 통해 서비스 사용자와 제공자 사이의 통신을 구현한다. 아래 그림은 SOAP를 통한 서비스 호출을 나타낸다.
웹 서비스에서 사용하는 서비스 기술의 표준은 WSDL(Web Services Definition Language)이다. WSDL은 서비스 사용자와 제공자가 주고 받을 메시지를 XML로 정의하며, 모든 프로그래밍 언어에 독립적으로 작동한다.
웹 서비스에서 사용하는 서비스 공개, 저장 및 발견의 표준은 UDDI(universal description, discovery, and integration)이다. UDDI는 서비스 공개, 저장, 발견을 위한 기본적인 인터페이스를 정의하고 있으며, 이는 웹 서비스를 발견하고 공개하기 위해 표준 SOAP메시지를 정의한 서비스 레지스트리(registry)이다. 아래 그림은 UDDI가 동작하는 패턴을 보여주는데, 서비스 레지스트리의 역할을 UDDI가 수행한다.
< UDDI의 동작 패턴>
4. SOA의 필요성
앞서는 SOA의 기술적인 측면에서 특징과 기본 구조에 대해 간략히 살펴 보았다. 이번 장에서는 기업의 실무적인 측면에서의 SOA의 필요성을 살펴 보도록 하자.
기업의 대규모IT 시스템이 가진 가장 큰 문제는 고비용으로 도입한 시스템을 극히 제한적인 용도로 그리고 제한적인 사람들만 이용한다는 것이다. 예를 들어, 직원 신원 정보를 담고 있는 정보시스템을 인력관리(HR) 부서의 직원만 사용 할 수 있고 다른 직원은 그러한 시스템이 존재한다는 사실조차도 모른다는 가정하에, 회사에서 직원들의 성과를 적극 관리하기 위해 CIM(Corporate Incentive Management)을 도입해서 직원정보시스템과 연동하고자 한다면 방법은 비싼 비용을 지불하고 직원정보시스템과 CIM을 연동하기 위한 별도의 커넥터를 개발하는 것이다. 그리고 향후 또 다른 시스템이 직원 정보시스템과 연동을 원한다면, 그리고 그 방법이 CIM과 연동했던 방법과 다르다면 어떻게 할 것인가? 이처럼 시스템 도입과 활용문제는 기업 내에 존재하는 아주 전형적인 통합(Integration)과 관련된 문제이다. 그리고 이 전형적인 문제를 해결하기 위해 기업들은 엄청난 비용과 시간을 투자하고 있다. SOA는 바로 이러한 문제를 적은 비용으로 쉽게 해결 할 수 있다. 즉, 직원 정보시스템이 외부에 제공 할 수 있는 서비스를 정의하고 이를 WSDL(Web Service Description Language) 같은 표준 XML 인터페이스로 정의한다. 그리고 WSDL 인터페이스를 통해 들어오는 요청을 기존 직원정보시스템과 연동 시키기 위한 부분을 개발해 준다. 바로 이 부분에서 Web Service가 요청되는데 JSP/Servlet, 혹은ASP와 같은 웹어플리케이션으로 쉽게 개발이 가능하다.
WSDL의 장점은 표준화 된 방법으로 시스템이 제공하는 서비스를 비교적 자세히 기술 할 수 있다는 것이다. 즉, WSDL 표준을 이해하는 그 누구라도 이 서비스를 이용할 수 있다는 것이다. 위의 두 과정을 통해 직원정보시스템은 누구나 쉽게 접근할 수 있고 이용 가능한 서비스가 될 수 있는 것이다. 또한 향후 제3의 시스템을 직원정보시스템과 연동시키더라도 추가 비용을 소요하지 않아도 더욱 많은 이용 가치를 가지므로 회사입장에서는 많은 비용절감 효과를 볼 수 있다.
그런데 여기서 한 가지 의문점을 제기 할 수 있다. 즉, '왜 Web Service 를 이용해야 하는가?'이다. 물론 J2EE, .Net, CORBA 같은 방법도 이용할 수 있지만 이 같은 기술을 이용하면 또 다른 문제점을 야기 할 수 있기 때문이다. 예를 들어 모든 인터페이스를 Java 인터페이스를 통해 정의하고, RMI(Remote Method Invocation)로 연동 부분을 개발 했다고 가정하면 제3의 시스템이 직원 정보시스템과 연동하고자 해도 이 시스템은 .Net으로만 개발되어 Java와는 통신이 어렵다. 따라서 이 문제를 해결하기 위해서 추가 비용과 개발이 필요하다는 결론에 이른다. 결국 SOA에서의 Web Service 사용은 서비스 이용에 따른 연동문제와 비용을 최소화 하고자 하는 취지에 가장 현실적인 답이 되는 것이다.
5. 맺음말 – 기업에서의 SOA
조직은 단순한 개인의 총합이 아니라 이미 유기체로서 작동하는 하나의 실체와 같다. 따라서 환경 변화에 능동적으로 적응하고 대처하기 위해서는 기업도 개인과 마찬가지로 지속적인 대응 및 업그레이드 시스템 구축이 필요하다. 이처럼 SOA는 적정 시점에, 적정 인력에게, 적정한 콘텐츠를 제공함으로써, 주어진 상황에서 최선의 의사결정을 할 수 있고 경쟁자보다 빨리 비즈니스 기회를 발굴하며 혁신적인 아이디어를 촉진할 수 있도록 만들어주는 일련의 프로세스 및 행동 방식으로 정의할 수 있다.
SOA의 도입은 그 자체가 목적이 아니라 기업의 비즈니스 목표를 달성하기 위한 수단이라는 점을 분명히 인지하여야 한다. 기업은 무작정 SOA를 도입하기보다는 산업별 기업의 핵심 업무에 맞춘 도입 기대효과 예측 및 목적을 분명히 해야 한다. 예컨대, 금융계의 차세대 시스템의 핵심은 시스템 다운 타임이 없이 물 흐르듯 이어지는 금융 서비스를 고객에게 제공하는 것이 가장 큰 목적이 될 것이다. 제조업의 경우 제품 수명 주기관리(PLM) 솔루션과의 연계를 통한 관리 업무 효율 극대화, 텔레커뮤니케이션 업계의 경우 경쟁사 보다 신규 서비스를 신속하게 제공하여 매출을 극대화하는 것이 SOA도입의 가장 큰 효과이자 목적이 될 것이다.
SOA 도입 시 단기적인 효과를 기대하기보다는 장기적인 시각을 가지고 접근하여야 한다. 지금까지 대부분의 IT 인프라 프로젝트들은 내부의 유지비를 효과적으로 줄여서 TCO 감소를 통한 총생산성의 향상을 유도했다. 하지만 IT 자산의 재사용 및 서비스간 연결이 쉽지 않아 각 프로젝트마다 새로운 인프라 요소의 추가 및 통합을 필요로 하여 시간이 지날수록 비즈니스 민첩성과 IT 자산의 유연성을 떨어뜨렸다. 이에 반해 SOA 기반의 인프라는 내부의 비용을 줄여 단기간의 생산성을 높이기 보다, 장기적인 시각으로 기업이 새로운 비즈니스 기회를 포착하여 신규 서비스 프로젝트나 새로운 서비스의 창출 등의 새로운 비즈니스 요구가 있을 시 IT 자원의 재사용과 유연한 데이터 흐름을 보장하여 경쟁사보다 신속한 타임투마켓(Time to Market)을 가능하게 한다. 즉 내부보다는 외부에서 수익을 창출하는 형태이며, 시간이 지날수록 그 생산성은 향상된다.
기업은 SOA의 핵심이 기업 애플리케이션에 포함된 개별적인 기능들을 변화하는 비즈니스의 요구에 따라 신속하게 조립 및 재사용할 수 있고 상호운영이 가능한 표준기반 서비스로 구성하는 IT 전략이라는 점을 감안하여, 충분한 컨설팅 기간을 거쳐 각 산업별 기업의 특성에 맞춘 `맞춤형' SOA를 구현하는 지혜를 보여야 할 것이다.
21세기 경영의 핵심은 `기업의 변화 능력제고'에 있다. GE의 잭 웰치가 지적했듯이 변화에 대한 신속한 적응능력, 이것이 향후 급변하는 환경 속에서도 변하지 않는 기업의 핵심역량이다. 이제는 급변하는 시장환경에서 기업의 IT환경이 얼마나 비즈니스의 요구에 민첩하게 대응할 수 있는 최적의 SOA의 도입방안에 대하여 고민하여야 할 것이다.
출처 - http://blog.naver.com/clickspace/120026142040
'Web > Common' 카테고리의 다른 글
| BEA 시스템즈 (0) | 2012.01.18 |
|---|---|
| RIA(Rich Internet Applications) (0) | 2012.01.17 |
| 웹 서비스(Web Service) (0) | 2012.01.16 |
| Sun ONE (0) | 2012.01.13 |
| HTTP1.0과 1.1 차이점 (0) | 2011.12.29 |
