난이도 : 중급 Ali Arsanjani, Ph.D., 아키텍트, SOA and Web services Center of Excellence, IBM
2005 년 12 월 02 일
서비스 지향 아키텍쳐(SOA)와 서비스 지향 통합(SOI)의 패턴을 연구하고 SOA의 기본적인 개념과
강력하고 유연한 SOA를 구축할 때 중요한 결정 포인트를 연구한다. 필자는 서비스 구성이라는 개념과
관련된 아키텍쳐 결정에 중점을 두고 설명한다.
머리말
가치 방정식의 비즈니스 및 IT 측면에 제공되는 유연성 관점을 통해서도 서비스 지향 아키텍쳐(SOA)의 가치를 발견하게 된다.
일련의 재조합 비즈니스 프로세스 구성요소를 비즈니스의 주요 특성으로 정의할 때 비즈니스 가치를 창출하게 된다.
이 같은 특수 프로세스 구성요소를 지원하는 서비스를 포함한 가변적 IT 기반구조를 이용, 비즈니스 구성요소를
프로세스로 조합함으로써 생기는 비즈니스 모델을 더욱 효과적으로 지원하게 된다.
한편 미래 확장성을 통해서도 유연성이라는 관점을 보게 된다. 이는 서비스 계층을 기업 아키텍쳐에 도입함으로써
이루어지게 된다. 패키지화된 애플리케이션 및 기존 시스템은 느슨하게 연결된 일련의 서비스 인터페이스를 이용,
서비스 지향 아키텍쳐(SOA)를 통해 통합되는데 여기서 서비스 인터페이스는 비즈니스 목표를 달성할 목적으로
서로 상호작용한다. 이와 같이 패키지화된 애플리케이션은 점대점(point to point) 방식 말고도 여러 가지 방식으로 조합되고
일련의 서비스를 정의하는 기업 서비스 모델에서 요구되는 기능성을 구현함으로써 서비스 지향 아키텍쳐에 따르게 된다.
이와 같은 서비스 지향 아키텍쳐(SOA)의 유연성으로 인해 이른바 전략 패턴을 상기케 한다.
전략패턴에서는 패턴 구현과 인터페이스를 별개로 하는 데 서비스를 사용하게 되고 원격 서비스 전략을 사용하면
분산 시스템 아키텍쳐 내에서 일어나는 개개의 통신 프로토콜에 대한 바인딩으로부터 객체 구현을 분리하게 된다.
이 글에서는 또한 David Panas가 1972년에 쓴 "시스템을 모듈로 분해하는 데 사용되는 기준에 관하여"라는 글에서
나온 관점을 서비스 지향 아키텍쳐에서의 서비스 세계에 응용한 것에 관해서도 나와 있다.(참고자료)
여기서 Panas는 앞서 언급한 글에서 대형의 복잡한 컴퓨터 애플리케이션을 일련의 구성성분 또는 모듈로 나눌 수 있다고
설명했다. 이 구성성분 및 모듈은 서로 연결되어 시스템의 근본적인 기능적 요구조건을 구축하게 된다.
Panas의 글을 종종 정보은닉을 주창하는 데 인용하게 된다. 이 글은 객체 지향 프로그래밍의 전조가 되지만
실제로는 정보은닉 기법에 관한 특수 애플리케이션 영역을 뛰어넘어 소위 외부화(Externalization)라 불리는 과정에 대해서
심층 설명되어 있다. 외부화는 주로 변환을 포함한 것이다. 외부화 기법 및 기준은
주로 변동지향 분석(VOA – 참고자료)에서 알 수 있다. 변동지향 분석 및 설계(VOAD)에서
시스템 기능성을 작동시키는 데 사용되는 근본적인 요구조건 구성 및 시스템의 비기능적 요구사항 등은
일련의 공통 구성요소(또는 애플리케이션의 기능성을 지원하는 일련의 구성요소)뿐만 아니라
더 중요하게는 구조 변동으로 인해 공통 구성요소를 수행하는 방식에 따라 달라지게 됨이 밝혀졌다.
이는 애플리케이션을 작동시키는 요구조건의 목적도 포함된 것이다. 구조 및 작용에서의 이와 같은 변동은
비즈니스 목적에 의해 작동되는 기능성이라는 근본적인 주제에서의 변동으로 여겨진다.
변동-지향 분석 및 설계
변동지향 분석 및 설계에서는 애플리케이션에 있어 가변적 경향의 구성요소 및 안정적, 영구적 경향의 구성요소를
분리하는 방법을 찾게 된다. 여러분은 이와 같은 "변환형태"를 애플리케이션 및 관련 아키텍쳐 내의 세 가지 기본 구성요소에
중점을 맞춘 것으로 여길 수 있다. 세 가지 기본 구성요소는 다음과 같다.
- 애플리케이션 작동 시 사용되는 정책 및 비즈니스 규칙(플래티넘 고객을 위한 당좌 대월 시의 규칙)
- 애플리케이션 흐름에서의 각각의 중요 지점에서 기능성에 관한 서비스를 발생시킴으로써
관리점에서 애플리케이션 수행 또는 흐름을 이끌게 되는 관리점으로 애플리케이션이 흐르게 되는 과정
(플래티넘 고객을 위한 대출 처리)
- 비즈니스에 포함된 구성요소 형태가 서로 연관된 형태계층
실제로 웹 서비스 및 서비스 지향 아키텍쳐를 채택하게 되는 계기는 서비스 지향 아키텍쳐에서 제공하는 유연성이다.
이러한 유연성은 다중 차원일 경우 명백해진다. 유연성의 주요 구성요소는 오늘날 주어진 비즈니스 라인에 의해 조직 내에서
내부적으로 제공되는 일부 기능성 발생 요구기능 및 후에 대체 서비스 제공자를 선택할 권한을 유지하는 기능 등이다.
이러한 새로운 서비스 제공자는 조직(또 다른 비즈니스 라인) 내부의 어딘가에도 있고 조직 내의 생태계에서의
비즈니스 파트너 (Part 1, “서비스 생태계 구현하기” – 참고자료) 또는
서비스를 IT 기능으로 제공하는 제 3의 상인 등이 될 수도 있다.
일련의 잠재적으로 변화하는 계약 및 요구조건에 근거해 서비스 구현자를 선택하는 권리를 보유하는 기능으로
매력을 느끼는 비즈니스 업체들이 많다. 이러한 유연성은 광대한 기업의 민첩성을 제공하고 지원한다.
비즈니스 관점으로부터 이에 해당되는 유연성을 제공하고 설정하는 IT 분야에서의 이런 유연성은 전략 패턴을 구현하는 것과
더불어 패턴 구현 및 인터페이스간의 분리 및 통신 프로토콜에 바인딩하는 것과 패턴 구현 간을 분리한다.
전략 패턴은 보통 단일 프로그래밍 언어를 사용해 단일 어드레스 공간에서 구현된다. 하지만 전략 패턴이 동일한 어드레스 공간에
소속되지 않고 분산 시스템 호출 또는 원격 프로시저 호출로써 나타나 컴파일 시간 또는 실행 시간에 서비스 제공업체에
대한 동적 바인딩이 수행되는 경우 이런 패턴을 우리는 원격 서비스 전략 또는 분산전략이라 한다.
분산 시스템에서는 여러 가지 다른 어드레스 공간으로 가장 연속적이고도 분명한 형태로 분산되는
구성성분 사이의 중요한 통신 프로토콜 리소스에 접근하는 기능이 요구된다. 한편 웹 서비스는 이와 같이 근본적이고도
중요한 통신 프로토콜을 설정하는 개방적 기준을 제시하는 데 성공적이었다. 그렇게 함으로써 특히 인터넷의 근본 구조인
고속 원격통신 네트워크 전체에 걸친 분산 시스템 호출기능을 설정하게 된다.
서비스 조합 및 유연성
시스템 지향 아키텍쳐(SOA)를 이용해 유연성을 이룩하는 방법을 더 잘 이해하기 위해 서비스 조합이라는 개념을 통해
주어진 유연성의 여러 단계에 대해 알아보자.
하지만 이전에 먼저 계산, 조합 및 공동작업 간의 중요한 차이점에
관해 얘기해 보자. 계산이란 전형적으로 수학적 계산, 부울 계산 및 이런 계산을 포함한 함수 수행을 포함한
범용 프로그래밍 언어(Java™ 또는 C#)를 사용하면서 수행되는 미세 기능을 말한다. Picolla와 같은 조합 언어는
작은 문장을 제공해 구성요소를 조합하는 데 초점이 맞춰져 있다. 반면 작업흐름, 또는 예를 들어 비즈니스를 지원하기 위한
총체적 목표를 이루기 위한 구성성분 작용에서의 다른 형태의 중대한 통합 등과 같은 흐름(예를 들면 웹 서비스(BPEL4WS)
또는 DAML-5용 비즈니스 프로세스 수행 언어)으로 공동작업을 정의한다. 다른 단계들의 경우엔 통합 서비스로
이와 같은 조합을 만들어내는 필요성에 대해 중점적으로 나와 있다. 본인은 서비스 조합란에서 이에 관해 더 자세히 밑에
설명할 것이다.
서비스 지향 아키텍쳐(SOA)의 세계에서는 서비스가 우선이다.(다시 말해 이 아키텍쳐의 기본 구성체는 서비스고
이는 여러 가지 애플리케이션으로 나뉜다.). 이와 같은 아키텍쳐 형태에서 개발된 애플리케이션에서
가장 관심을 끄는 두 가지 특징이 바로 서비스 질(QoS) 및 유연성이다. 기능이 좋고 신뢰성이 있으며
일반적으로 비즈니스의 QoS 요구조건을 충족시키는 서비스 지향 아키텍쳐(SOA)로써 구축된 가변적 IT 기반구조를 통해서도
기업의 민첩성을 부여할 수 있다. 서비스 지향 아키텍쳐(SOA)는 그 아키텍쳐의 3가지 1급 구성체, 즉 서비스,
구성요소(서비스를 실현하는 구성요소) 및 흐름(또는 프로세스)을 통해 주로 유연성을 제공한다.
세 가지 주요 SOA 구성체 각각은 여러 가지 다른 종류의 유연성을 제공한다. 예를 들어, 서비스 측면에 있어 인터페이스 및
패턴구현의 분리, 인터페이스 및 특수 프로토콜에 대한 바인딩 간의 분리를 통해 유연성(유연성의 "자매관계", 재사용)을
얻게 된다. 특수 구성요소 가운데 기업 구성요소(참고자료)라 불리는 것은 서비스 실현기능을 제공한다.
이 구성요소는 서비스 질을 확실히 보장한다.
조직, 일반적으로 기업들이 서비스 지향 아키텍쳐(SOA)의 조건을 실행함으로써 성장해 나갈 시 애플리케이션은
기업 구성요소에서부터 고정 배치되기 보다는 서비스에서부터 점점 더 구축되어 간다.
일정 흐름(프로세스) 메커니즘을 통한 조합 하에 여러 서비스들이 합칠 시 이와 같은 과정이 일어난다.
조정(Orchestration) 및 구성(Choreography)은 조합의 비슷한 형태들로써 이 형태엔 주로 약결합 형태 및 표준 기반 형태(BPEL)가 있다.
하지만, 조기 수용자는 몇 가지 서비스(비즈니스 기능성의 약결합 단위)가 기업 구성요소와 결합해 실질적으로 실행기능이
좋은 조합형태를 만들게 되는 고정 배치형태의 조합을 포함한 여러 형태의 서비스를 창출하게 된다.
하지만 이와 같은 조합은 여러 가지 서비스를 구성한 조합에 비해선 덜 유연하다. 이런 식으로 여러분은 서비스 지향 아키텍쳐(SOA) 구성을
그림 1에서 보듯 아키텍쳐를 동적으로 재구성 가능한 형태로 만드는 과정으로 볼 수 있다.
그림 1. 조직 내에서 서비스 지향 아키텍쳐 사용과정이 완성되어 가면서 이 아키텍쳐에서 얻게 되는 가치 증대
따라서, 완전히 완성된 서비스 지향 아키텍쳐(SOA)에서 발생하는 기능성의 모든 단위는 서비스라 한다.
서비스들이 함께 모여 최적의 조화를 이루게 되면 결국엔 서비스 조합에서부터 애플리케이션이 나오게 된다.
이 때 조합은 종종 소형의 동등한 고성능의 구축블록을 조합시켜 대형구조를 구축하는 과정을 얘기한다.
조합과정에서 아키텍쳐 내의 서비스 과정을 관리하게 되는데 이는 BPEL 엔진이 이 엔진의 구성서비스를 관리하는 방식과
비슷하다.
하지만 오늘날 보다시피 실제 세계와 상상 속의 세계, 머지 않은 미래에 일어나야 할 세계에 관해 비교해 보면
여러 가지 서비스의 느슨한 연결구성만 가지고는 이 구성에서부터 늘 항상 최적의 서비스 조합을 만들어낼 수 없다.
많은 경우 여러분은 유연성과 서비스 질을 잘 조정해 최종 서비스, 조합 서비스 및 서비스에서 구현되거나 지원하는
애플리케이션 기능이 잘 수행되고 질도 높아야 한다.
여기서 유연성 및 서비스 질의 조정과정을 통한 결정에서 나오게 되는 공통적인 시나리오 몇 가지를 계속 발견하기로 한다.
조합 및 조합성
조합 및 조합성과 관련된 몇 가지 개념과 이에 관한 정의를 제안하면서 몇 가지 기본적인 원칙을 세워보자.
그림 2. 서비스 조합
서비스 조합은 서비스 기능성의 일부를 포함하고 구성요소 기능성과 일치하는 서비스를 조합해
비즈니스 프로세스를 만족시키는 구성요소를 포함할 수도 있다. 약결합 형태의 서비스 간의 약결합 흐름을 창출함으로써
서비스 조합을 이와 같은 식으로 이룰 수 있다. 하지만 서비스 구성요소에는 단단한 커플링이 존재한다.
따라서 서비스 질은 주로 약한 연결고리의 서비스 조합 구성요소, 다시 말하면 가장 낮은 서비스 질을 제공하는 서비스 질
또는 구성요소에 따라 다르다. 이와 같이 높은 성능을 요구하는 조합 구성요소(서비스, 또는 구성요소),
또는 기타 비즈니스 라인이 이와 같은 구성요소에 의존하는 것과 같은 식의 제한요건이 있는 구성요소의 경우
여러분은 서비스 조합 내에 있는 서비스 구성요소를 편리하게 호출해야 한다. 적시에 툴 및 플랫폼이 계속 완성될 때
여러분은 아마도 서비스 구성요소를 외부화시켜 구성요소에 서비스 인터페이스를 창출, 모든 유용성을 가지고
구성요소를 적절한 서비스로 호출시킬 수도 있을지 모른다.
이제 서비스 지향 모델링 및 아키텍쳐(SOMA-참고자료)의 실현단계를 통해 뱅킹에 관련된 예에 관한
몇 가지 시나리오를 보고자 한다. 나는 여기서 서비스 구체화에 관해 중점적으로 설명하고자 한다.
서비스 구체화 결정
내가 고객에게 들었던 질문은 다음과 같다. "제가 서비스 또는 직접호출기능으로서의 특수기능을
기존 서비스 구성요소(단단한 연결형태 또는 가능한 더 나은 서비스 질)에 도입시켜야 할까요?" 이제 그림 3에 나온 것에 관해 살펴보자.
이제 실제로 흔히 일어나는 시나리오를 통해 이 질문에 대한 답을 찾아보자. 지금 여러분에게 있어
각 비즈니스 라인(정부 대출, 소매 대출, 상업 대출 등)마다 일괄 프로세싱, 레거시 시스템, 다중 데이터베이스 및
다중 애플리케이션이 갖추어진 은행이 있다고 해 보자.
그림 3. 시나리오: 신/구 시스템의 공존
조합의 일반적 형태에 관한 설명
그림 4에서는 여러 가지 예를 통해 나온 조합성의 여러 가지 형태에 관해 나와 있다.
먼저 그림 4에 나온 타원과 선의 의미를 알아보자. 타원은 서비스(UML 사용자-케이스 아이콘에서 얻은 서비스)를,
선은 대략적으로 선 및 메시지의 흐름을 나타낸다. 서비스 각각은 각기 독특한 기능성을 제공하고 서비스를 총괄하거나
서비스에 할당된 정책을 통해 접근 가능한 서비스와 연관된 서비스 품질을 지니고 있다.
그림 4. 조합 서비스
그 다음으로 조합성의 여러 가지 형태에 대해 더 자세히 살펴보기로 하자.
치환(Substitution)이 형태에서 비즈니스 주주는 서비스 기능성 및 서비스 수준의 계약이 필요한
모든 프로세스 내의 서비스를 이용할 수 있다. 여기서 S(x) 각각은 서비스(서비스 기능성 및 질)를 나타낸다.
그림 5. 치환 조합성
통합 또는 단일 액세스 포인트. 여기서 서비스를 여러 가지 다른 고객형태 또는 납부 프로세싱 서비스를 위한
대출 처리 서비스와 같은 재귀적 비즈니스 기능용 단일 액세스 포인트로 사용할 수 있다.
간단한 경우, 통합 또는 단일 액세스 포인트 및 치환 등은 다소간 동일하다. 또한 이와 같은 모든 과정들이 주어진 서비스가
"좋은 서비스"인지 아닌지의 여부를 결정하는 여러 가지 다른 설계관련 결정을 의미하는 조합성의
일면들임을 명심하면 된다. 다시 말해 나 자신이 비즈니스에 자금투자를 권고할 것인가?
아니면 이러한 서비스를 어떻게 구체화해야만 할 것인가? 서비스 리트머스 테스트라 불리는 것을 통해 서비스의
"장점"에 관한 답을 알 수 있다. 서비스 리트머스 테스트에 관해선 후에 다시 논의하겠다.
이와 같은 은행에 변동지향 분석(VOA)을 수행하게 되면 기본적 기능성에서 겹치는 몇 가지 대출 처리 시스템이 생기게 된다.
기본적 기능성에서 겹치게 되면 이 같은 대출 처리 시스템에서 공통성이 재분리 된다. 이 경우 단일 대출 처리 서비스는 파트너,
고객, 조직의 모든 대출 처리 요구사항을 다루게 된다.
이렇게 하면 이전과는 다른 대출 처리 시스템용 단일 액세스 포인트가 제공된다. 대출 처리 시스템들은 실제로 통합되어
점차 기능이 줄어들며 이에 따라 중복기능 유지비도 줄어든다. 여기에 서비스 계층을 도입하면 가상화 기능은 더 늘어나게 된다.
서비스 계층은 단일 액세스 포인트로서의 서비스를 제공하고 시간에 따른 상기 서비스 수행자들을 점차 물리적으로
통합시키게 된다. 비용절감, 유지 용이 및 복잡성 감소 등의 통합 등과 같은 예산 가용성 및 기술적 우선순위 등을 이용해
이런 식의 통합이 이루어지게 된다.
서비스 통합자 패턴(Part 1 참조, 참고자료)의
도입으로 이와 같은 일이 종종 현실화된다.
서비스 통합자 패턴은 주로 부가적으로 미세한 형태, 이른바 서비스 라우터(SR)로 이루어지고
게이트웨이(예에서도 보듯이 웹 서비스 게이트웨이 또는 ESB 게이트웨이)와 함께 사용되어 해당 목적지 서비스에 관한
요구사항을 포착하고 측정한다. 뿐만 아니라 요구사항을 보낼 시스템을 결정하기도 하는 역할을 한다.
그림 6에 이와 같은 것이 나와 있다. 서비스 통합자 패턴은 결과를 처리, 서비스 고객에게 패턴 작동결과를
제동한다. 서비스 라우터(SR)는 기간 업무 시스템 또는 다른 서비스와 연결되고 라우터에서 중요한,
즉 서비스 라우터의 기능성을 실현하는 서비스 구성요소인 서비스 리얼라이저를 통해 직접 레거시 시스템에 접근하게 된다.
여기서 서비스 적응자가 있는 각 레거시 시스템을 감싸면서 액세스 기능을 설정하는 작업이 가능하지 않은 특수한 경우에만
서비스 리얼라이저로부터의 직접적인 접근을 권장한다. 두 경우 중 어느 경우에도 서비스 라우터는 서비스 통합자를 지원하며
서비스 통합자는 결국 비즈니스 기능 또는 프로세스에 과한 단일 액세스 포인트가 된다.
그림 6. 서비스 라우터 1(서비스 라우터) 및 2(고정 배치 라우터)
여기서 서비스 품질에 관한 이슈로 인해 여러분이 고민을 하는 경우 이와 같은 방식들을 잘 조합하면
적절한 아키텍쳐 구성 결정이 되기도 한다는 것을 알아두는 것이 중요하다. 이 때 레거시 시스템,
성능 및 기타 서비스 질 등의 특성 등이 제한되어 순수 서비스, 고정 배치방식 또는 하이브리드 방식 등등에 관계없이
최적의 시스템 접근 메커니즘이 활용된다.
하이브리드 서비스 라우터(프로세스 대출 3에 사용됨)는 일종의 라우터로
레거시 제한조건으로 인해 일부 연결부위가 고정 배치되고 나머지 연결부위는 서비스 지향 아키텍쳐를 통한 유연한 호출용으로
설정되는 기능을 한다. 이는 패키지화된 애플리케이션의 경우에 흔한 기능이다.
하이브리드 서비스 라우터 방식을 사용하게 되면 여러분은 웹 서비스를 실제로 구체화시키는 경우에서처럼 쉽고도
용이하게 프로세스 대출 3를 다시 재구성할 수는 없을 것이다.
재조합 또는 컨텍스트 변환. 비즈니스 주주가 제안을 하면서 기타 비즈니스 프로세스 또는 애플리케이션에서 서비스를
다시 재구성하면서 재사용할 수 있게 된다. 그렇게 되면 새로운 비즈니스 목표를 충족시키고 비즈니스 프로세스에 대한
새로운 변환기능을 지원하게 된다.
그림 7. 재조합 또는 컨텍스트 변환
자기 차단(Self-containment).
이런 상황에서 다음과 같은 질문으로 아키텍쳐에 관한 결정을 한다. 한 서비스로 기타 다른 서비스와 실행시간에 상호작용하면서
비즈니스 프로세스를 수행하긴 하지만 그래도 서비스를 독립적으로 전개해 비즈니스 목표를 만족시킬 수 있을까?
다른 서비스 상에 있는 서비스의 암묵적인 연관성은 전혀 없고 상호 연관된 모든 서비스는 교환되거나 자기차단 기능이 된다.
그림 8. 자기 차단
내가 보이고자 하는 서비스가 그 자체로 데이터베이스 및 배치 레거시 시스템에 의존하는 시스템 구성요소에 따라
다른 경우 이 서비스는 시스템 구성요소와의 상관성을 지니게 된다. 결국 이렇게 되면 유지성 및 시스템 질이 증가하게 되며
서비스 재구성을 하지 않아도 된다. 사실, 서비스 라우터 뒤에 숨겨진 이 같은 서비스의 가시성 영역을 종종 유지하는 게 더 낫다.
그렇게 되면 레거시 또는 독립 서비스 벤더(ISV) 패키지가 교체되는 경우 프로세스 대출 1을 사용해 구성된 서비스 및
애플리케이션에 관한 인터페이스를 많이 변경하지 않아도 되기 때문이다.
비즈니스 원자성.
비즈니스 프로세스에서 서비스는 단일단계의 소프트웨어 캡슐화를 이루었는가? 여러분이 프로세스 분해를 수행하고
서비스 지향 모델링 및 아키텍쳐를 이용해 비즈니스 맞춤 분석에 기반한 서비스를 선택했다면
그 질문에 대한 답은 "그렇다"이다. 이를 그림 9에서 볼 수 있다.
그림 9. 프로세스 분해과정
조합성의 개념
그림 10에서는 간단한 표기법에 대해 나와 있다. 본인은 서비스 지향 아키텍쳐 세계 내의 서비스 및
구성요소의 커플링에 관한 아키텍쳐 및 구체화 결정을 설명하는 데 도움이 된다는 사실을 알아냈다.
블록 다이어그램은 종종 UML과 같은 정식표기법과 함께 사용되어 기술 공동체, 비기술 공동체 및 주주 간의 인식 및
대화에 도움이 된다. 주주 등의 각각의 주체들이 커플링과 관련된 결정을 잘 알고 있는 동안 이런 현상들이 벌어지게 된다.
그림 10. 내부 구성 및 외부 상관성 형태
그림 10에서 보면 서비스 C는 구성요소 C와 느슨하게 연결된 구체화 연결형태를 띄고 있는 반면
서비스 B는 구성요소 B와 단단하게 연결된 구체화 연결형태를 띄고 있음을 알 수 있다.
재구성
기본 소프트웨어 아키텍쳐가 재빨리 감응하고 서비스 구성요소들 및 서비스들 간의 상호연결뿐만 아니라
이들의 기능성까지 동적으로 바꾸면서 문제를 해결하는 기능을 이용해 실행시간 및 동적 재구성에 관한 특징을 기술하게 된다.
기본 아키텍쳐는 필요한 작동 애스펙트(비기능 애스펙트로도 알려짐)를 재구성해 서비스 질 및 서비스-레벨 계약을 유지시킨다.
이와 같은 영역에서 웹 서비스 표준이 나오게 되고 문법-지향 객체 설계(GOOD)로 인해 많은 문제점이 해결되리라
기대되지만 실제로 실행, 안전 및 상호운용성을 실질적으로 고려하면 상기와 관련된 모델이 구체화되기 어렵게 된다.
상호운용성 등과 같이 앞서 언급한 특징들을 연구하면서 하드웨어-관련 시스템 내에서 상당부분 수년 동안 구현되었다.
우리는 이런 특징들을 소프트웨어 시스템 및 아키텍쳐에다 확대, 적용하고 싶다. 그렇다고 해서 하드웨어 세계에서의
패러다임을 가져다가 실제로 활용할 수는 없다. 소프트웨어 구성요소 및 아키텍쳐에 관한 잘못된 생각들이 많다.
소프트웨어 구성요소 및 아키텍쳐는 완전히 맞는 구현 블록이라기 보다는 더 미세한 성분들이 더 많이 결합해 이루어진 몸 안의
기관들과 같다고 할 수 있으며 컨텍스트 안에서 각각의 기능 및 목표를 제공한다. 또한 기능위주이면서도 작동적인 기능의 변화에
관한 탄력성을 어느 정도 보인다.
이와 같이 소프트웨어 서비스 및 구성요소의 재구성은 최대의 유연성 및 기업의 민첩성을 이룩하는 데 있어
중요한 성공인자가 되고 있다. 웹 사이트 표준을 개발하고 GOOD과 같은 조합 방법 및 기법을 통해 신규방법을
적용함으로써 소프트웨어 서비스 및 구성요소 재구성을 하게 된다.
참고자료 교육
토론
필자소개  | | Ali Arsanjani, Ph.D.: 아키텍트, SOA and Web services Center of Excellence, IBM |
기사에 대한 평가
| 
