쵸코쿠키의 연습장

SOA Layers 이 서비스 기반 아키텍처, 즉 SOA는 소프트웨어 아키텍처 스타일입니다. 이 아키텍처 스타일은 서비스 공급자가 제공하는 서비스를 서비스 소비자가 메시지를 주고받으면서 활용하는 기본 구조를 가집니다. SOMA 방법론에서와 같이 엔터프라이즈 SOA 구축을 위해서는 몇 개의 계층, 즉 Layer에 걸쳐서 분석과 모델링 과정이 필요합니다. 여기 보시는 그림은 SOA를 계층적인 아키텍처 스타일로 표현합니다. 이 아키텍처 스타일에서 맨 아래에 있는 Operational Systems Layer가 있습니다. 이 Layer에는 그 기업이 보유하고 있는 기존의 CRM이나 ERP 같은 레거시 시스템들이 표현되어 있습니다. 이 Operational Systems Layer 위에는 Enterprise Co..

SoaML SOMA 방법론은 서비스를 식별하고 명세하고 구현하는 전반적인 틀과 절차를 정의합니다. SoaML은 이러한 서비스 모델링 과정에서 사용할 수 있는 구체적인 언어 그리고 표현 방법을 제공합니다. SoaML은 Object Management Group, 즉 OMG에서 개발한 오픈소스 서비스 Specification 방법입니다. SoaML은 소프트웨어 모델링에 널리 사용되고 있는 Unified Modeling Language(UML)을 기반으로 합니다. SOA 구축을 위한 서비스 모델링과 디자인을 위한 여러 방법을 제공합니다. SoaML의 공식 웹사이트는 www.soaml.org입니다. SoaML을 위한 다양한 도구가 개발되었습니다. Modeling Capabilities of SoaML SoaML..

서비스 기반 모델링 먼저 이 비즈니스 도메인 자체를 잘 이해하고 시뮬레이션 할 수 있어야 합니다. 그러한 것을 잘하기 위해서는 먼저 사용자가 사용해야 되는 서비스가 무엇이고 그 주요 특성과 기능들이 무엇인지를 먼저 잘 표현해야 합니다. 그래서 서비스 기반의 모델링이라는 것은 엔터프라이즈 시스템 구축의 문제를 체계적이고 전략적으로 풀기 위해서 소프트웨어 모델링의 원칙과 기술을 효과적으로 활용하는 것을 의미합니다. 세 가지 원칙이 있습니다. 첫째는 Virtualization, 즉 가상화입니다. 가상화의 원칙은 서비스의 행위, 구조, 관계를 매우 높은 수준에서 모델링해야 한다는 의미를 말합니다. 두 번째는 서비스 모델링의 원칙은 Metamorphosis, 즉 변화에 대한 반영이 필요하다는 것입니다. 비즈니스 ..

Service Integration 웹정보나 서비스를 접근해서 실생활에 활용할 때는 그냥 각각을 독자적으로 사용하진 않습니다. 일반적으로, 여행을 가기 위해서 그 준비에 필요로 하는 정보를 확인할 때 먼저 LonelyPlanet 같은 웹사이트에 가서 여행지의 정보를 확인할 수가 있습니다. 그 이후에는 여행을 실제로 가기 위한 비행기표를 예매하고 호텔을 예약하는 작업을 실제 여행사 사이트를 통해서 수행합니다. 여러 가지 준비가 된 이후에는 실제 여행을 떠나서 목적지에 갔을 때 예기치 못한 날씨를 접할 수도 있습니다. 그래서 날씨도 체크하고 그 지역에 대한 뉴스도 확인할 수 있습니다. 이러한 일련의 웹정보 혹은 서비스를 접근함을 통해서 여행에 관련된 정보를 확인합니다. 그에 대한 실제적인 준비를 할 수가 있..

WSDL Web Service Description Language, 즉 WSDL은 XML 기반의 웹서비스 명세 언어입니다. 2001년에 IBM 등의 회사에서 W3C에 제안을 한 것입니다. 2007년에 W3C에 표준으로 지정이 되었습니다. WSDL은 웹서비스 간에 교환되는 메시지 포맷과 데이터 타입, 그리고 전송 방식에 대한 정보를 기술할 수 있는 언어입니다. WSDL을 사용하는 웹서비스 명세는 abstract한 부분과 concrete한 부분, 두 레벨로 구성이 됩니다. abstract-level 명세는 웹서비스가 받고 전달을 해야 되는 메시지를 중심으로 interface를 기술하는 것입니다. concrete한 level의 명세는 웹서비스 호출을 위한 네트워크상의 주소, 프로토콜, 이러한 기술적인 것들을..

SOAP SOAP은 웹서비스 간에 교환되는 메시지의 packaging과 전송을 위한 표준 프레임워크로서 두 가지 정의가 있습니다. 첫 번째 정의는 service oriented architecture protocol이라는 정의입니다. SOAR을 이루는 서비스의 인터페이스를 정의하고 이에 따라서 서비스 간의 정보를 교환하는 프로토콜을 의미합니다. 두 번째 정의는 RPC 모델을 기반으로 서비스를 원격으로 호출합니다. 이때 필요로 하는 메시지를 marshaling, unmarshaling하기 위한 프로토콜이라는 정의가 있습니다. 이러한 SOAP 메시지는 네 개의 요소로 구성이 되어 있습니다. 먼저 전체 SOAP 메시지는 SOAP envelope이라는 것으로 감싸져서 전송이 됩니다. 그 SOAP envelope..

은행 도메인 먼저 SOA를 적용해서 어떤 비즈니스 Goal을 달성하고자 하는지를 설정해야 합니다. 금융 도메인을 보면 다양한 비즈니스 라인에서 다양한 서비스가 제공되어야 합니다. 또한 다양한 채널을 통해서 고객들이 그러한 서비스를 소비해야 됩니다. 그래서 이 경우에서는 비즈니스 Goal로서 새로운 비즈니스 환경에서 어떻게 하면 혁신을 이루고 또한 투자 대비 효과를 빠르게 할 수 있을까 하는 것을 목표로 설정합니다. 또한 금융권을 보면 은행이 빈번하게 서로 합병을 하게 됩니다. 이러한 경우에 기존에 은행들이 사용하고 있던 서로 다른 금융 시스템들이 기존의 사용자들에게 제공되는 서비스의 중단 없이 효과적으로 통합되는 것이 굉장히 중요합니다. 그래서 SOA를 적용할 때를 이러한 문제 해결을 목표로 설정할 수 ..

웹 서비스란 무엇인가? 기능들을 API(Application Programming Interface)로 제공을 해서 프로그램에 직접 활용할 수 있는 것들을 웹 서비스라고 일반적으로 부릅니다. 그래서 웹 서비스는 전체적인 SOA의 구성 레이어에서 서비스 컴포넌트와 서비스 클라이언트 간의 Interaction이 웹 표준적인 인터페이스를 통해서 이루어집니다. 웹 서비스라는 것은 어떠한 표준적인 수단입니다. 즉, 서비스 간의 Interaction을 표준적인 수단을 통해서 하게 됩니다. 그런 것들을 통해서 애플리케이션을 개발할 수 있는 환경이 됩니다. 웹 서비스 디렉토리 이렇게 다양한 웹 서비스들이 웹에 존재합니다. 대표적인 웹 서비스 디렉토리, 웹 서비스를 찾을 수 있는 디렉토리 중에 하나가 programmab..

서비스 기반 아키텍처를 구성하는 목표 다양한 기존의 레거시 시스템, 이미 존재하고 있는 시스템들이 복잡하게 연결되어 있습니다. 어떠한 기업에서 이미 가지고 있는 다양한 시스템들이 있습니다. 이런 시스템들을 서로 상호작용하게 해서 또 다른 새로운 애플리케이션을 만듭니다. 이미 새롭게 개발된 시스템들이 있는데 그런 것들하고 어떻게 연동시킬지는 어려운 문제입니다. 그래서 서비스 기반 아키텍처를 구성하는 첫 번째 목표 중에 하나는 기존의 레거시 시스템들을 잘 활용해서 새로운 애플리케이션을 만들어내자는 목표입니다. 두 번째 중요한 목표는 기존에 기업에서 제공하는 다양한 서비스를 웹을 통해서 사용자들한테 노출하는, 사용자들이 사용할 수 있게 하는 목표가 있습니다. SOA를 사용하게 되면 기존에 기업에서 제공하던 여..

서비스의 기본 개념 MS Word는 직접 이 소프트웨어를 구매해서 설치를 해야 합니다. 또한 이러한 MS Word는 설치한 컴퓨터에서만 사용을 할 수 있습니다.그래서 Availability 차원에서 MS는 굉장히 제한적입니다. Google Docs는 인터넷만 연결돼 있으면 어떠한 컴퓨터에서든지 웹 브라우저를 통해서 접근할 수 있습니다. 또한 이렇게 설치가 필요 없는 Google Docs은 어떠한 컴퓨터든 상관없이 Operating System, Hardware 그런 플랫폼에 상관없이 사용할 수 있는 특징이 있습니다. 또한 새로운 소프트웨어 버전이 나왔다든지 문제를 해결하는 패치가 나왔을 경우에 MS Word는 설치를 해야 됩니다. Google Docs 같은 경우는 언제나 접속만 하면 최신의 소프트웨어를 ..

아키텍처의 평가 절차 첫째 단계는 평가방법 준비 단계로 이 단계에서는 아키텍처 평가 방법을 결정합니다. 둘째 단계에서는 아키텍처와 아키텍처 분석관점을 사용하여 분석을 수행하고 분석결과를 얻습니다. 분석결과는 아키텍처 설계를 통하여 이미 도출되어 있는 경우 이를 사용하면 됩니다. 그 렇지 않은 경우는 새로이 분석을 수행하여야 합니다. 마지막 단계에서는 단계2로부터 얻어진 분석결과에 대하여 단계1에서 결정된 종합 방법을 적용하여 평가결과를 얻습니다. CBAM CBAM 절차는 아키텍처 설계의 방향을 결정하는 아키텍처 전략들과 분석관점을 형성하는 N개의 품질속성 시나리오를 입력으로 하여 평가를 수행하고 평가결과로 각 아키텍처 전략의 순위를 결정합니다. CBAM은 비용과 이득 관점의 계량적 분석 방법으로 합리적인..

아키텍처 분석과 평가의 정의 아키텍처 분석과 평가라는 용어에 대하여는 표준화된 정의가 존재하지 않습니다. 분석과 평가를 구별 없이 사용하는 경우도 많습니다. 그러나 분석과 평가는 밀접히 관련된 서로 구별되는 개념입니다. 분석은 전체를 그것을 구성하는 부분들로 분리하는 활동으로 물체를 구성하는 요소들을 식별하거나 분리하는 활동, 즉 복합체와 그 요소들 및 그 관계를 상세히 검사하는 활동을 의미합니다. 평가는 가치를 판단하거나 결정하는 활동으로 신중한 조사 학습을 통하여 중요성, 가치 혹은 상태를 판단하는 활동을 의미합니다. 분석은 분해하여 들여다보는 활동이고, 분석을 위해서는 분석관점이 필요하며, 분석은 판단/평가를 위한 원시 데이터를 제공합니다. 반면 평가는 분석의 결과를 종합하여 판단하는 활동이며, 원..

품질속성 설계전략의 원리 아키텍처 패턴은 자주 발생하는 아키텍처 설계 문제에 대한 준비된 해결 방법이므로 대개의 경우 특정한 품질을 확보하는 문제에 대한 해결 방법을 제시하지 않습니다. 패턴을 통하여 품질 개선 효과가 얻어질 수도 있으나 그것이 만족스럽지 않을 수 있습니다. 또한 마땅히 적용할 패턴이 없는 상황에서 어떤 품질을 확보해야 하는 문제가 대두될 수도 있습니다. 품질속성 설계전략은 특정한 품질속성 응답을 제어하는 데 효과가 있는 설계 전략입니다. 품질 속성의 분류 성능, 상호 운영성, 변경 용이성, 가용성, 보안성, 시험 용이성 및 사용 용이성의 7개 품질속성에 대한 설계전략 도출지침이 있습니다. 이들 중 성능을 예로 하여 품질속성 설계전략이 무엇인지를 알아봅니다. 성능 설계 전략 성능은 시간에..

아키텍처 패턴 원리 테일러는 아키텍처 패턴을 반복적으로 발생하는 설계 문제에 적용될 수 있는 아키텍처 설계 결정으로 정의하였습니다. 그리고, 아키텍처 패턴의 급증으로 문제가 발생하는 여러 가지 다른 소프트웨어 개발 상황에 다뤄질 수 있도록 일반화되어 있다는 점을 강조하였습니다. 아키텍처 패턴의 표현 아키텍처 패턴을 기술하기 위하여는 패턴이 사용되는 문맥, 패턴이 해결해야 하는 문제와 그 해결 방법 외에도 패턴의 이름과 패턴의 사용에 따른 파급효과를 기술하여야 합니다. 아키텍처 패턴의 예 소프트웨어 시스템 개발에 자주 쓰이는 아키텍처 패턴의 예로 Three Tiers 아키텍처 패턴이 있습니다. 이 패턴에서 컴포넌트는 Front Tier 컴포넌트, Middle Tier 컴포넌트 Backend Tier 컴포넌..

설계의 일반 원리 아래 그림은 문제해결에 사용되는 일반적인 접근 방법의 종류를 보여줍니다. 먼저 주어진 문제를 이미 해결책이 알려져 있는 문제로 변형하는 방법입니다. 이런 방법은 그 해결책을 원래의 문제에 대한 직접적인 해결책으로 쉽게 변형할 수 있으면 원래의 문제를 해결하기 위한 좋은 방법이 됩니다. 그림의 위 부분은 이 경우를 보여줍니다. 이미 존재하는 해결책을 이용할 수 없는 경우 원래의 문제를 더 쉬운 문제들로 나누어 해결할 수 있다면, 그 하위 문제들에 대한 해결책들을 합성하여 원래의 문제에 대한 해결책을 만들 수 있습니다. 위 그림의 중간 부분은 이 경우를 보여줍니다. 만일 문제 해결에 기존의 해결책을 활용할 수 있으면 기존의 해결책을 사용할 수 없는 부분에 대해서만 새로이 해결책을 만들고, ..

아키텍트 설계 절차 원리 아키텍처 설계의 출발점은 소프트웨어 시스템의 요구사항들입니다. 소프트웨어 개발의 폭포수 모델은 요구사항 분석이 끝나고 설계가 시작되는 것으로 소프트웨어 개발 프로세스를 설명하지만, 이는 논리적인 순서이고, 실제로는 요구사항 분석과 아키텍처 설계는 서로 얽혀서 상당 부분 동시적으로 진행되는 활동입니다. 초기 단계의 요구사항으로부터 초기 아키텍처가 만들어지면 이는 더 많은 구체적인 요구사항을 파악하는 데 이용됩니다. 이는 다시 아키텍처를 더 구체화하는 데 이용되고, 이 과정이 반복되면 요구사항 명세와 아키텍처가 만들어집니다. 요구사항 분석과 아키텍처 설계가 동시에 이루어지는 이유는 요구사항의 변경 및 추가가 수시로 일어납니다. 상용 소프트웨어 컴포넌트나 오픈소스 코드를 개발에 사용할..

관점과 뷰 소프트웨어 시스템은 자체는 무엇인지 특징 짓기 어렵습니다. 그러나 특정한 시각을 갖고 그 시각이 집중하여 보려 하면 복잡한 소프트웨어 시스템도 그 방향에서의 모습을 보입니다. 이렇게 소프트웨어 시스템을 포착하기 위한 시각을 관점이라고 하고 그 관점에서 본 시스템의 모습을 뷰라고 합니다. 소프트웨어 시스템 그 자체는 볼 수 없지만 슬라이드의 사진에서와 같이 적절한 관점들과 그 관점들에서 본 뷰들로 소프트웨어 시스템의 아키텍처를 가시화시킬 수 있습니다. 관점 시스템이 관심을 갖는 이해당사자에 따라 관점이 달라지고 이들 숫자만큼 다양하다고 원칙적으로 이 질문에 답할 수 있습니다. 그러나 실제로는 많은 가능한 관점 중에서도 소프트웨어 개발을 위해 특히 중요하여 일반적으로 많이 이용되는 관점들이 있습니..

아키텍처 스타일 소프트웨어 아키텍처의 경우에도 마찬가지로 여러 스타일이 존재하며 이들이 갖는 소프트웨어 개발 용이성 및 시스템이 주는 특징이 서로 다르기 때문에 아키텍처 스타일의 선택은 소프트웨어 개발에서 매우 중요하며 이어지는 아키텍처 설계 및 개발에 큰 영향을 미치게 됩니다. 만일 분산 환경에서 많은 사용자를 위한 소프트웨어 시스템에 대하여, 컴포넌트들이 물리적으로 분리되어야 합니다. 둘째, 서비스 제공자들이 서비스 요청자들이 누구인지 알 수 없어야 합니다. 셋째, 서비스 요청자들이 서로 분리되고 보호되어 해당 서비스 제공자에게만 의존해야 합니다. 넷째, 복수의 서비스 제공자들이 동적으로 추가될 수 있어야 합니다. 이 설계 결정들을 채택할 경우 어떤 컴포넌트들이 시스템에 있어서 어떻게 작용하게 되는지..

컴포넌트, 커넥터, 인터페이스 많은 문제 해결을 위하여 분할 정복이라는 문제 해결 방식을 사용합니다. 예를 들어 여러 명이 같이 쇼핑을 할 때 빨리 쇼핑을 마치를 위해 일을 나누어 각자가 많은 물건을 고르고 계산대에서 한꺼번에 지불하는 방법을 취할 수 있습니다. 소프트웨어 시스템의 개발에 있어서는 분할 정복은 우리가 적용하게 되는 가장 기본적이고 근본적인 접근 방법입니다. 따라서 시스템이 먼저 어떤 컴포넌트들로 구성되고 그들을 어떻게 연결하여 최종적으로 원하는 시스템이 되게 할 수 있는지 구상합니다. 이 활동을 시스템 아키텍처 설계라고 보는데 이와 같이 아키텍처 설계가 만들어지면 시스템의 프로그램은 아키텍처 설계를 따라 만들게 됩니다. 결국 우리가 크고 복잡한 문제를 해결하는 데 쓰지 않을 수 없는 문제..

아키텍처 설계 문제 분석의 원리 아키텍처 설계 문제 분석은 요구사항들 속에서 아키텍처 설계를 요구하는 문제를 식별하고, 정리하고, 그 해결책의 후보를 도출하는 활동입니다. 이를 위해서는 첫 번째로 선정된 아키텍처 드라이버들로부터 어떤 설계 문제가 들어있는지를 파악하여 정리하고, 둘째로 이 문제들에 대한 가능한 해법들을 도출하고, 셋째로 이 해법들을 평가하여 그 효과를 정리하여야 합니다. 세 번째 단계의 작업이 평가를 위해서는 직관을 사용할 수도 있고, 매우 중요한 결정인 경우에는 뒤에서 12번째 아키텍처 설계 원리로 학습하게 될 비용 이득 관점의 진보된 평가 방법을 사용할 수도 있습니다. 아키텍처 설계 문제 분석 방법 과거에 여러 연구자들에 의해서 여러 가지 방법이 만들어졌지만, 여기서는 지멘스 회사의 ..