소개

서비스 지향 아키텍처(SOA) 환경에서 패키지된 애플리케이션 구현은 종종 합의된 의사결정을 기반으로 한다. 이로 인해 비즈니스 필요성에 전적으로 부합하지 않는 결과가 나타날 때도 있다. 합의는 종종 작성 대 구매 시나리오 사이의 균형이다. 한편, 작성 시나리오는 전체적인 기능적 일치와 사용자 정의 개발된 컴포넌트로 구현된 비즈니스 민첩성이 허용된다. 다른 한편으로, 구매 시나리오는 즉시 사용 가능한 패키지된 애플리케이션으로 통합되는 표준의 성숙된 프로세스의 사용을 활용한다.

분명한 방식으로 비즈니스 필요성의 모든 측면을 설명하면 복잡하기 때문에 SOA 환경에서 패키지된 애플리케이션에 대한 선택 기준을 설정하는 것이 과제이다. 이는 패키지된 애플리케이션을 성공적으로 배치하기 위해 패키지된 애플리케이션을 선택하기 위한 기준이 모든 비즈니스 필요성을 수용하도록 SOA 환경에 어떻게 설정되어야 하는가라는 질문으로 이어진다.

SOA 환경에서 패키지된 애플리케이션에 대한 선택 기준은 기능적인 비즈니스 측면 위에 기능 외적인 비즈니스 측면도 다루어야 한다. 기능 외적인 비즈니스 측면을 심각하게 고려하는 데에는 몇 가지 이유가 있다. 우선 대상 서비스 지향 아키텍처는 각각 특정한 기능 외적인 비즈니스 측면을 도입하여 몇 가지 인식 시나리오를 사용하여 접근할 수 있다. 두 번째로, 진정한 서비스 지향을 달성하기 위해 여러 비즈니스 측면들을 다루어야 한다. 세 번째로, 패키지된 애플리케이션의 조달 및 배치 도중에 서비스 지향의 목표를 인식하기 위해 서비스 지향의 기능 외적인 측면도 다루어야 한다.

이러한 측면들은 다음 세 개의 섹션에서 개별적으로 다룰 것이다. 마지막 섹션에서는 SOA 환경에서 패키지된 애플리케이션의 선택 기준을 설정하기 위한 실질적인 안내를 제공한다.

위로

대상 서비스 지향 아키텍처는 몇 가지 인식 시나리오를 사용하여 접근할 수 있다

대부분의 아키텍처는 서비스 지향이 된다. 대상 또는 서비스 지향 아키텍처를 인식하는 몇 가지 방법들, 즉 새 컴포넌트를 개발하고 기존의 엔터프라이즈 범주의 애플리케이션을 재사용하며 패키지된 애플리케이션을 배치하는 것들이 있다. 이러한 세 가지 방법들은 대상 서비스 지향 아키텍처에 접근하도록 결합할 수 있다. 하지만, 몇 가지의 서로 다른 측면들을 고려해야 한다.

새 컴포넌트를 개발할 때에 SOA 표준을 채택하는 것은 중요하다. 예로는 상호 운용성과 보안의 영역이 있다. SOA 경연장에서는 아키텍처의 일부가 되는 컴포넌트의 개발과 통합을 표준화하는 수많은 결과들이 달성되었다.

기존 엔터프라이즈 애플리케이션의 재사용 및 패키지된 애플리케이션의 배치는 아키텍처의 의사결정 지점을 도입한다. 이러한 아키텍처의 주제들은 통합 스타일이나 더 나은 통합 옵션과 관련하여 의사결정이 되어야 하는 초기에 통합과 상호 운용성 도메인에서 나타난다.

기존 애플리케이션을 통합할 때에 통합 스타일은 화면 스크랩핑, 배치 지향 프로세싱, 메시지 지향 통합 및 서비스 랩핑에서부터-여기에서 전부 열거하지 않음- 다양할 수 있다. 인터페이스는 기존 엔터프라이즈 애플리케이션을 재사용할 때에 받은 것으로 간주한다. 패키지된 애플리케이션을 조달하고 배치할 때에 전체적인 아키텍처의 통합 스타일을 설정하는 가능성이 더 높은 것처럼 보인다. 하지만, 통합 목표 수준은 대상 통합 스타일을 성공적으로 인식하기 위해 패키지된 애플리케이션을 조달할 때에 선택 기준의 형태로 통신되어야 한다.

위로

여러 비즈니스 측면들을 다루어야 한다

서비스 지향을 달성하기 위해 여러 비즈니스 측면들을 다루어야 한다는 것을 인식하는 것이 좋다. 비즈니스와 IT 연결의 이점과 비즈니스 민첩성은 기능적 해체를 통해서만 접근할 수 없다. 프로세스 기반 기능적 해체는 당연히 기능 비즈니스 요구사항을 충족하는 데 필요한 서비스와 컴포넌트를 식별하기 위한 실용적인 기술이다. 하지만, 비즈니스 기대를 충족하는 면에서 물론 더 많은 측면들이 있다. 이러한 다른 측면들은 때로는 기능 외적인 성향을 가진다.

이 기사는 몇 가지 비즈니스 측면들, 즉 기능 및 기능 외적인 비즈니스 요구사항들을 구별하는 용어를 소개한다. 여기에서 요구사항이라는 단어에 앞서 비즈니스라는 단어는 신중하게 선택되었다. 기능 및 기능 외적인 비즈니스 요구사항 사이에 이러한 구별은 기능 및 기능 외적인 요구사항 사이에 의미하는 바와 같이 기존의 구별이 아니다.

기능적 비즈니스 요구사항들은 시스템에 의해 성취되는 요구와 필요성을 표현하는 기존의 기능적 요구사항들이다. 이러한 비즈니스 요구사항은 프로세스 및 유스 케이스를 지향한다. 서비스들은 프로세스와 유스 케이스 분석으로 식별될 수 있으며 반복 가능한 비즈니스 태스크로 맵핑될 수 있다.

기능 외적인 비즈니스 요구사항들은 비즈니스와 최소한 동등하게 중요한 다른 필요성을 설명한다. 이들은 비즈니스 민첩성, 비즈니스 개념 확장성 및 비즈니스 감사가능성과 같은 측면들에 대한 목표 수준을 설명한다. 이러한 기능 외적인 비즈니스 요구사항들로 인해 분해도에 관한 의사결정이 나타난다. 그 예로는 프로세스 조직, 반복 가능한 비즈니스 단계(서비스), 서비스 컴포넌트 배치 모델 및 서비스 테스트 계획 등이다. 기능 외적인 비즈니스 요구사항 외에도 가용성, 보안 및 성과와 같은 기존의 기능 외적인 요구사항들은 여전히 중요한 역할을 담당한다. 기능 외적인 비즈니스 요구사항들은 전체 서비스 지향을 달성하도록 다루는 추가적인 측면으로 고려해야 한다. 그림 1은 요구사항 유형의 카테고리화를 보여준다. 여기에서 언급한 기능 외적인 비즈니스 요구사항들의 위치는 요구사항의 다른 유형과 관련하여 예를 들어 보여준다.

오늘날 업계에 정립된 관점은 훌륭하게 정의된 기능적인 비즈니스 요구사항은 성공적인 솔루션을 확보하기 위한 전제조건이라는 것이다. 모델링과 정의 언어를 사용하여 기능적인 비즈니스 요구사항을 정의하는 것은 일반적인 사례를 확보하는 것이다. 기능적인 모델링과 정의 언어의 예는 각각 UML을 기반으로 하는 유스 케이스 모델링 및 BPMN(Business Process Management Notation)을 기반으로 하는 프로세스 정의 언어이다.

하지만, 성공적인 프로젝트를 실행하기 위해 적절하게 묘사된 기능 외적인 비즈니스 요구사항에 대한 필요성은 때로는 심각하게 인식되지 않는 경우도 있다. 기능 외적인 비즈니스 요구사항을 묘사하는 모델링과 정의 언어의 가용성은 배후에서 누락되었다. 다음 섹션에서는 이와 관련하여 일부 안내를 제공할 것이다.

위로

패키지된 애플리케이션을 조달하고 배치하는 동안 다루어야 하는 SOA의 기능 외적인 측면들

거시적인 관점에서 기본적으로 기능 외적인 비즈니스 요구사항의 설명을 상위 레벨로 끌어 올리는 두 개의 접근방식들이 있다. 접근방식 중 하나는 선언문과 애플리케이션 통합 패러다임과 같이 가치 균형 모델을 사용하는 것이다. 또 다른 접근방식은 SOA 참조 아키텍처가 도입한 측면들을 기반으로 새 비즈니스 시스템의 품질과 제약을 표현하는 것이다. 이러한 두 가지 접근방식들은 다음 섹션에서 다룰 것이다.

위로

기능 외적인 비즈니스 필요성은 균형 모델을 사용하여 표현할 수 있다

SOA 선언문은 여기에서 기능 외적인 비즈니스 요구사항을 더 잘 이해하기 위한 균형 모델로 선택된다(SOA 선언문 작성자). SOA 선언문은 몇 가지 디자인 딜레마의 균형을 설명한다. 이러한 디자인 딜레마는 서로 앞의 두 개의 디자인 값을 제시하여 표현된다. 딜레마는 하나의 명령문을 포함하며, 이 값은 SOA 환경에서 선호된다. 이후에 원칙들은 이러한 SOA 선언문 딜레마에서부터 파생된다.

SOA 선언문의 다음 원칙들은 패키지된 애플리케이션을 선택하는 프로세스 도중에 연관된다.

• 다른 속도로 변경하는 시스템의 다른 측면들을 분리한다.
• 내포된 종속성을 줄이고 모든 외부 종속성을 발행하여 견고성을 높이고 변경의 영향력을 줄인다.
• 모든 추상 레벨에서 응집력이 있고 관리 가능한 기능의 단위와 관련하여 각 서비스를 조직한다.
• 외부적으로 통일성을 지속하는 한편 내부적으로 다양성을 허용한다.

이러한 원칙들은 다음 서브섹션에서 기능 외적인 요구사항들과 관련하여 논의된다.

다른 속도로 변경하는 시스템의 다른 측면들을 분리한다

다른 변경 속도를 기반으로 시스템의 부분을 분리하는 것은 시스템의 아키텍처를 계층화하여 달성할 수 있다. 전체적인 시스템이 패키지된 애플리케이션을 포함하는 경우, 패키지된 애플리케이션의 아키텍처의 컴포넌트들과 계층화가 관심의 초점이다. 이상적으로 말하면, 패키지 애플리케이션의 계층과 컴포넌트들은 개별적으로 구성될 수 있다. 그러면 패키지된 애플리케이션의 다른 부분들은 패키지된 애플리케이션의 전체 체계를 변경하고 새로 구성된 설정을 배치하지 않고도 변화하는 비즈니스 필요성에 적응할 수 있다.

다른 원인들로 인해 패키지된 애플리케이션의 일부분들이 변경되거나 다른 부분들보다 높은 속도로 다시 구성되어야 한다. 따라서 패키지된 애플리케이션의 계층화 및 컴포넌트화는 중요한 기능 외적인 비즈니스 요구사항이다. 이 방식으로 전체 시스템 범위에 대한 비즈니스 민첩성이 확보될 수 있다.

내포된 종속성을 줄이고 모든 외부 종속성을 발행하여 견고성을 높이고 변경의 영향력을 줄인다

내포된 종속성을 줄이고 특히 외부 종속성을 발행하는 것은 패키지된 애플리케이션의 매우 중요한 기능 외적인 비즈니스 요구사항이다. 이 방식으로 전체 시스템의 견고성은 달성될 수 있으며, 변경의 영향력은 줄어들 수 있다. SOA 환경에서 이 원칙을 적용하는 동안, 패키지된 애플리케이션이 나머지 아키텍처에 도입하는 제약과 내포적인 종속성을 이해하는 것은 중요하다. 종속성의 예제로는 패키지된 애플리케이션 서비스의 호출의 필수적인 순서가 될 수 있다. 이러한 종속성은 적절하게 정의된 서비스의 사전 조건으로 표현되어야 한다.

패키지 애플리케이션 선택 기준은 서비스의 종속성을 통일된 포괄적인 설명 언어를 사용하여 적절히 표현하는 진술을 포함해야 한다.

모든 추상 레벨에서 응집력이 있고 관리 가능한 기능의 단위와 관련하여 각 서비스를 조직한다

응집력이 있고 관리 가능한 기능의 단위와 관련하여 서비스를 조직하는 것은 우려를 분리하기 위해 시스템의 계층화와 컴포넌트화에 관련된다. 패키지된 애플리케이션은 이전에 언급한 대로 이상적으로 컴포넌트화되어야 한다. 이 원칙의 목표는 연관성이 높은 기능과 관련하여 단위를 구성하는 전체 시스템-패키지된 애플리케이션 포함-을 달성하는 것이다. 이러한 방식으로 패키지된 애플리케이션은 변경에 대해 관리 가능하며 취약성도 줄어든다.

외부적으로 통일성을 지속하는 한편 내부적으로 다양성을 허용한다

내부적으로 다양성을 허용하는 동시에 외부적으로 통일성을 지속하는 원인은 컴포넌트들이 구현 다양성을 포기하지 않고 통일된 표준 방식으로 호출될 수 있는 환경을 확보하는 것이다. 내부 기능의 구현에 대한 지침은 호출 표준이 사용되는 한 느슨해 질 수 있다. 기능의 구현이 달라질 수 있으므로 이 원칙은 패키지된 애플리케이션에 적용 가능성이 높다. 호출 표준이 패키지된 애플리케이션에서 유지되는 한, 기능은 통일된 방식으로 외부 컴포넌트에서 활용할 수 있다. 외부 통일성을 지정하는 표준의 예제는 WS-I(Web Services Interoperability Organization)에 의해 정립된 표준 및 우수 사례들이다.

위로

기준은 SOA 참조 아키텍처의 몇 가지 측면에 따라 파생될 수 있다

기능 외적인 비즈니스 요구사항과 선택 기준을 이끌어내는 또 다른 중요한 소스는 SOA 참조 아키텍처이다. 계층화된 아키텍처의 지원을 통해 몇 가지 기능 외적인 측면들을 다룰 수 있다. 이 방식으로 참조 아키텍처의 계층들은 기능 외적인 비즈니스 요구사항을 식별하기 위한 지원으로 사용될 수 있다. 또한 계층화는 기능 외적인 비즈니스 필요 및 개별 선택 기준 목록의 카테고리화로 사용될 수도 있다.

첫 번째 서브 섹션에서 SOA 참조 아키텍처를 소개할 것이다. 그 다음에 몇 가지의 아키텍처 계층에서 다루는 일반적인 기능 외적인 비즈니스 측면들을 논할 것이다.

SOA 참조 아키텍처 소개하기

그림 2는 자원 계층, 서비스 컴포넌트 계층, 서비스 계층, 비즈니스 프로세스 계층, 이용자 인터페이스 계층, 통합 계층, 서비스의 품질 계층, 정보 계층 및 거버넌스 계층으로 5개의 수평 계층과 4개의 수직 계층으로 구성된 SOA 참조 아키텍처의 개요를 보여준다. 이 계층화된 참조 아키텍처는 오픈 그룹 참조 아키텍처(Open Group Reference Architecture)를 기반으로 한다. 아키텍처 계층의 자세한 설명은 오픈 그룹의 SOA 참조 아키텍처 웹 사이트를 참조한다(오픈 그룹 SOA 참조 아키텍처 작성자 2009). 이 아키텍처는 업계에서 원활히 채택된다. 이 아키텍처의 계층들은 기능 외적인 비즈니스 요구사항들을 식별하고 카테고리화하는 데 사용될 수 있다.

여기에서 패키지된 애플리케이션 그 자체가 자원 계층에 위치되었음을 인식하는 것은 중요하다. 그럼에도 불구하고, 여기에서 참조 아키텍처의 계층들은 패키지된 애플리케이션의 선택 프로세스에 대해 기능 외적인 비즈니스 요구사항을 이끌어 내는 데 사용된다. 다시 말해서 참조 아키텍처는 적용 가능한 기능 외적인 비즈니스 측면들과 각각의 선택 기준을 식별하는 사고 모델로 사용된다. 다음 섹션에서는 SOA 참조 아키텍처의 특정 계층으로 맵핑될 수 있는 기능 외적인 비즈니스 측면들의 예를 설명한다.

프로세스 관리

프로세스 관리 측면은 소개한 SOA 참조 아키텍처의 비즈니스 프로세스 계층에서 처리한다. 프로세스 관리는 비즈니스 민첩성과 비즈니스 최적화 둘 다에서 중요한 역할을 담당한다.

비즈니스 민첩성에 대해 반복 가능한 비즈니스 단계의 호출은 프로세스 템플리트로 정의된 프로세스 엔진이 조직한다. 비즈니스 단계의 호출 순서 및 적용 가능한 비즈니스 규칙에 대한 적응은 프로세스 템플리트를 변경하여 구현될 수 있다.

비즈니스 최적화에 관련하여 프로세스 관리 기능은 프로세스 모델링, 프로세스 조직, 프로세스 모니터링 및 프로세스 모델 적응으로 구성된 최적화 주기를 포함한다.

패키지된 애플리케이션을 적용할 때에 두 개의 시나리오가 비즈니스 민첩성과 비즈니스 최적화를 달성하기 위해 구별될 수 있다.

첫 번째 시나리오는 각각의 패키지 애플리케이션이 내부 프로세스 관리 기능을 포함하는 것이다. 이러한 경우에 이러한 내적인 비즈니스 프로세스 관리 기능을 위한 기능 외적인 요구사항을 이끌어 내는 것이 중요하다. 패키지된 애플리케이션의 내부 프로세스 및 비즈니스 규칙은 구성 가능한 모델 및 매개변수를 사용하여 적응 가능해야 한다. 패키지 애플리케이션의 내부 프로세스가 전체 시스템의 엔드투엔드 프로세스와 통합될 수 있는 것도 중요하다. 엔드투엔드 프로세스 통합을 통해 전체 체인 모니터링과 최적화를 사용할 수 있다. 각각의 패키지된 애플리케이션 자체는 엔드투엔드 프로세스의 대부분을 다룰 수 있음을 참고하자. 이는 설명한 시나리오의 변화를 소개할 것이며, 여기에서는 패키지된 애플리케이션의 프로세스 엔진이 엔드투엔드 프로세스를 조직한다.

이러한 기능 외적인 비즈니스 필요성에서부터 이끌어 내야 하는 선택 기준은 패키지된 애플리케이션의 내부 프로세스를 BPMN(Business Process Modelling Notation)과 같은 표준 프로세스 노테이션 및 BPEL(Business Process Execution Language)과 같은 표준 프로세스 구현 언어로 적절히 설명하는 것이다. 게다가 패키지된 애플리케이션은 엔터프라이즈 이벤트 인프라 표준에 따라 비즈니스 모니터링 이벤트를 전송하거나, 패키지된 애플리케이션 프로세스 엔진이 엔드투엔드 프로세스를 조직하는 경우에 비즈니스 모니터링 이벤트를 수신할 수 있어야 한다. 사전 정의된 프로세스 정의에 따라 비즈니스 모니터링 이벤트와 프로세스 모니터링 엔진을 교환하면 패키지된 애플리케이션으로 압축되는 부분을 포함하는 엔드투엔드 프로세스의 추적을 사용할 수 있다.

두 번째 시나리오는 패키지된 애플리케이션이 외부 비즈니스 프로세스 관리 엔진으로 호출할 수 있는 반복 가능한 비즈니스 단계를 노출하는 것이다. 이러한 경우에 패키지된 애플리케이션이 잘 설명된 서비스를 사용하여 반복 가능한 비즈니스 단계를 제공하는 것이 중요하다. 서비스 정의는 다음 섹션의 주제이다.

서비스 정의

서비스 정의는 SOA 참조 아키텍처의 서비스 계층으로 처리된다. 서비스 정의는 반복 가능한 비즈니스 단계, 호출 세부사항 및 사전 조건의 기능을 설명한다. 재사용을 완수하는 것에서 잘 설명된 서비스가 핵심 요인이다. 따라서 기능의 분명한 정의는 그 자체로 중요한 기능 외적인 비즈니스 요구사항이다.

이 기능 외적인 비즈니스 요구사항에서부터 이끌어 낼 수 있는 패키지된 애플리케이션의 선택 기준은 패키지된 애플리케이션이 제공하는 서비스를 설명하는 표준을 사용하는 것이다. 서비스를 정의하는 표준의 예는 WSDL(Web Service Description Language)이다(웹 서비스 설명 언어 작성자). 서비스 액세스 프로토콜의 예는 SOAP(Service Object Access Protocol)이다(서비스 오브젝트 액세스 프로토콜 작성자).

서비스 컴포넌트

서비스 컴포넌트는 SOA 참조 아키텍처의 서비스 컴포넌트 계층에서 처리된다. 서비스 컴포넌트들은 서비스 인터페이스에서 정의하는 대로 기능을 인식하고 있다. 서비스 컴포넌트 그 자체는 다른 기능적인 기술 컴포넌트에 의존할 수 있다. 일반적으로 시스템의 컴포넌트화를 통해 컴포넌트를 조정하고 구성할 수 있기 때문에, 이로 인해 비즈니스 솔루션에서 민첩성이 나타난다.

비즈니스 민첩성을 완수하는 것은 컴포넌트 구조의 분해도에 밀접하게 관련된다. 일반적인 진술은 더 잘게 쪼개진 컴포넌트 구조가 큰 덩어리로 나누는 구조보다 반복 가능한 비즈니스 단계에 맞추고 구성하는 데 더 많은 기회를 제공한다는 것이다. 비즈니스 민첩성을 완수하는 면에서 컴포넌트 구조가 새 컴포넌트로 증가될 수 있는 정도도 중요한 측면이다. 이는 패키지된 애플리케이션이 적응 가능한 컴포넌트화된 구조를 가져야 하는지 아니면 구성 가능한 컴포넌트화된 구조를 가져야 하는지의 비즈니스 목표에 따라 달려있다. 이는 대부분의 경우에 즉시 사용 가능한 표준 솔루션을 배치하는 것이나 사용자 정의 비즈니스 서비스 범주를 개발하는 것 사이의 균형이다.

비즈니스 목표가 패키지된 애플리케이션으로의 컴포넌트 레벨 민첩성 정도이면, 선택 기준은 컴포넌트 레벨에서 적응 가능성 또는 구성 가능성에 대한 필요성을 표현하도록 설정해야 한다.

또 하나의 측면은 향후 개발이다. 이상적으로 보면 패키지된 애플리케이션은 전체 릴리스 관리 철학에 적합할 것이다. 전체 릴리스 관리 및 테스트 철학이 컴포넌트 레벨에서 소프트웨어 홍보 프로세스를 요구하면 패키지된 애플리케이션은 컴포넌트 레벨에서 테스팅 및 활성 제품 프로세스도 활용해야 한다.

데이터

데이터 측면은 소개한 SOA 참조 아키텍처의 정보 계층에 위치한다. SOA 데이터는 서비스로 요약된다. 그럼에도 불구하고 개념적인 엔터프라이즈 엔티티 모델은 종종 비즈니스 오브젝트와 그 상호연관성을 이해하는 첫 단계이다. 엔티티 모델은 솔루션의 서비스 컴포넌트 아키텍처(SCA) 요소들 사이의 모든 교환 메시지를 구성하는 고전적인 메시지 모델을 이끌어 내는 기본이다.

패키지된 애플리케이션이 데이터 모델도 소개하기 때문에 비즈니스 엔티티 모델 맞춤을 고려해야 한다. 통합 관점에서 보면 고전적인 상호교환 메시지 모델은 새 패키지된 애플리케이션이 소개하는 새 비즈니스 엔티티를 반영하도록 확대되어야 한다. 메시지 브로커와 같은 미들웨어 기술 또는 마스터 데이터 관리 솔루션들은 이러한 과제를 극복하는 데 유용하다. 더 높은 기술 레벨에서는 교환 메시지의 형식과 구현도 고려해야 한다. 교환 메시지가 XML(Extensible Markup Language)로 구현되고 XSD(XML Schema Definitions)로 정의되면, 요소와 유형-전역 대 로컬 선언-의 선언 스타일은 패키지된 애플리케이션이 전사적으로 선호하는 선언 스타일을 얼마나 엄격히 고수하느냐에 따라 달라지는 측면이 된다.

서비스 통합

서비스 통합 주제의 주요 부분은 SOA 참조 아키텍처의 통합 계층으로 처리된다. SOA의 통합 메커니즘은 정적 또는 동적으로 서비스의 발견을 기반으로 한다. 이는 서비스 정의의 섹션에서 설명한 대로 처음부터 서비스가 잘 정의되어야 한다.

서비스 발견 및 바인딩의 구현은 SOA 내에서 서비스 등록 기능을 기반으로 한다. 따라서 기능 외적인 요구사항들은 전사적 서비스 등록 또는 협력적인 서비스 등록에 나열된 서비스 정의를 전달하도록 패키지된 애플리케이션에 대해 설정되어야 한다. 선택 프로세스의 기준은 대개 서비스 정의 섹션에서 소개한 기준들과 유사하다.

패키지된 애플리케이션이 서비스 이용자로서의 역할이 있고 엔터프라이즈 서비스를 호출하는 경우에 전사적 서비스 발견 및 바인딩 메커니즘을 활용할 수 있어야 한다.

이기종 환경에서 서비스들 사이의 활동 조정은 문제가 될 수 있다. 패키지된 애플리케이션이 이러한 일반적인 활동에서 협업하면 엔터프라이즈 레벨에서 조정 프레임워크를 협의하는 것이 중요하다. 패키지된 애플리케이션이 포함된 모든 당사자들은 트랜잭션의 통합을 유지보수하기 위해 이러한 조정 프레임워크를 고수해야 한다. 업계에 널리 정립된 프레임워크의 예는 OASIS 웹 서비스 트랜잭션이 승인한 WS-Coordination(Web Service Coordination), WS-AtomicTransaction(Web Services Atomic Transaction) 및 WS-BusinessActivity(Web Service Business Activity)의 협력이다(OASIS 웹 서비스 트랜잭션 작성자).

서비스 보안

가용성, 조정성, 처리량 및 반응 시간 성능과 같은 정규 품질 측면 이외에도 서비스 계층의 품질은 서비스의 보안 측면을 처리한다.

서비스 보안 요구사항은 토큰을 사용하여 서비스 사이에 전달된 ID와 인증을 통해 구현되는 싱글 사인온(SSO)과 같이 ID 인증과 권한 부여 철학에 따라 엔터프라이즈 레벨로 설정될 수 있다. 의사결정은 패키지된 애플리케이션이 전사적 보안 구현 스타일을 엄격하게 고수하는지 여부를 결정해야 한다. 그러한 경우 선택 기준은 이러한 보안 요구사항들을 반영해야 한다. 선택 기준을 정의할 때에 업계 표준을 활용하는 것이 좋다. 널리 승인된 표준의 예는 OASIS에서 발행한 웹 서비스 보안이다(OASIS 웹 서비스 보안 작성자).

서비스 거버넌스

서비스 거버넌스 측면은 SOA 참조 아키텍처의 수직적 거버넌스 계층에서 처리된다. 서비스 거버넌스의 핵심 요소는 서비스 소유 모델, 서비스 모금 모델, 서비스 변경 모델 및 재사용 자극 모델의 정의와 배치이다. SOA 환경의 경우 소유자와 후원자를 서비스(그 그룹)에 지정하는 것이 중요하다. 재사용 및 변경 모델을 비즈니스 목표에 맞게 정의하는 것이 권장된다.

서비스 거버넌스 모델의 성공적인 배치는 기능 외적인 비즈니스 필요성으로 고려해야 한다. 이러한 기능 외적인 비즈니스 요구사항들은 패키지된 애플리케이션의 배치에도 적용 가능하며 조달 프로세스 도중에 적용되는 선택 기준으로 표현되어야 한다. 선택 기준의 예는 패키지된 애플리케이션의 서비스 구조가 서비스 소유 모델의 분해도로 맵핑될 수 있다는 것이다. 기준의 또 다른 예는 패키지된 애플리케이션의 서비스 구조가 전사적 서비스 저장소가 관리하는 서비스 라이프사이클에 통합될 수 있다는 점이다.

위로

감사의 인사

저자는 이 글을 완전히 검토해준 Gerard Alderden에게 깊은 감사의 말을 전한다.

위로

참고문헌

• OASIS 웹 서비스 보안 작성자. OASIS 웹 서비스 보안(WSS) TC. Organization for the Advancement of Structured Information Standards (OASIS). (2010년 6월 15일에 액세스됨).
  
  
• OASIS 웹 서비스 트랜잭션 작성자. OASIS 웹 서비스 트랜잭션(WS-TX) TC. Organization for the Advancement of Structured Information Standards(OASIS). (2010년 6월 15일에 액세스됨).
  
  
• 오픈 그룹 SOA 참조 아키텍처 작성자. 2009. The Open Group SOA Reference Architecture. The Open Group. (2010년 6월 15일에 액세스됨).
  
  
• 서비스 오브젝트 액세스 프로토콜 작성자. SOAP Version 1.2 Part 1: Messaging Framework(Second Edition). 월드 와이드 웹 컨소시엄(W3C). (2010년 6월 15일에 액세스됨).
  
  
• SOA 선언문 작성자. SOA Manifesto. http://www.soa-manifesto.org(2010년 6월 15일에 액세스됨). The Web Services Description Language Authors. Web Services Description Language(WSDL) 1.1. 월드 와이드 웹 컨소시엄(W3C). (2010년 6월 15일에 액세스됨).
  
  
• Web Services Interoperability Organization. (2010년 6월 15일에 액세스됨).

참고자료

• 자신에게 가장한 적합한 방법으로 IBM 제품을 평가해 보자. 시험판 제품을 다운로드하거나, 온라인으로 제품을 사용해 보거나, 클라우드 환경에서 제품을 사용하거나, SOA Sandbox에서 SOA(Service Oriented Architecture)를 효과적으로 구현하는 방법을 배울 수 있다.
  
  
• My developerWorks 커뮤니티에 참여하자. 개발자가 운영하고 있는 블로그, 포럼, 그룹 및 위키를 살펴보면서 다른 developerWorks 사용자와 의견을 나눌 수 있다.
  
  

필자소개

아티클 순위

의견

위로

목차

• 소개
• 대상 서비스 지향 아키텍처는 몇 가지 인식 시나리오를 사용하여 접근할 수 있다
• 여러 비즈니스 측면들을 다루어야 한다
• 패키지된 애플리케이션을 조달하고 배치하는 동안 다루어야 하는 SOA의 기능 외적인 측면들
• 기능 외적인 비즈니스 필요성은 균형 모델을 사용하여 표현할 수 있다
• 기준은 SOA 참조 아키텍처의 몇 가지 측면에 따라 파생될 수 있다
• 감사의 인사
• 참고문헌
• 참고자료
• 필자소개
• 의견