Visual Studio 2010 공식 팀 블로그 @vsts2010

사실 필자는 SOA(Services Oriented Architectures) 에 대해서 심도 있게 알고 있는 전문가는 아닙니다. 전문가는 아니지만 WCF=SOA 에 대해 제가 알고 있는 작은 부분으로 WCF=SOA 를 오해하거나 잘못 알고 계신 분들이 있는 것 같아, 이 부분을 바로 잡아 보려고 합니다.    

우선 SOA(Services Oriented Architectures) 는 직역하면 "서비스 지향 아키텍처"라고 부릅니다. 서비스 지향 아키텍처는 서비스를 제공하는 벤더(Vender) 또는 프로바이더(Provider) 를 통해 유연한 서비스를 제공하거나 제공 받는 아키텍처를 말합니다. 그리고 이 SOA 와 가장 연관 깊은 것이 바로 XML 웹 서비스(Web Services) 입니다.    

XML 웹 서비스는 특정 벤더나 프로바이더를 통해 서비스를 제공 받고, 표준으로 채택됨으로써(http://www.w3.org/2002/ws/) 플랫폼 간의 상호 운용성을 높인 기술입니다. 어떤 운영체제와 플랫폼이든 이 메시지를 이해할 수 있는 텍스트(Plain Text)로 이루어진 XML 과 WSDL, XSD 스키마를 사용하여 해석되는 것입니다. 이것을 가리켜 SOAP 프로토콜이라고 합니다. (사실 Microsoft 만큼 SOAP 을 잘 구현한 벤더는 없습니다. 유효성 검사를 해 보면 정말 엉망으로 구현하는 곳이 의외로 많습니다)    

그리고 .NET Framework 3.0 부터 WCF(Windows Communication Foundation) 이라는 기술이 출연하게 됩니다. 그리고 많은 사람들은 .NET 리모팅, XML 웹 서비스, TCP/UDP(UDP는 .NET 4.0 에 포함됨) 등을 통합한 프레임워크가 WCF 라고 이해하고 있습니다. 더불어 SOAP 뿐만 아니라 JSON, REST 방식의 통신 레이어 행위(Behavior)를 지원함으로써 "서비스 지향 아키텍처"라고 말하기도 합니다.    

필자는 이러한 SOA 에 대해서 작은 지식을 가지고 있지만, WCF 와 SOA 와 연관 관계를 지어 대화를 하게 될 때 매우 서먹하기도 합니다. 왜냐하면 바라보는 기술의 관점이 틀리기 때문에 말입니다.    

일단 용어를 명확히 하자면, SOA 는 어떤 명확한 구현 또는 산출물의 기술이 아닌 이상적인 아키텍처 측면을 의미합니다. 그리고 이상적인 아키텍처를 이야기 할 때 양자간의 관점이 틀릴 경우, 사실 그만큼 대화하기 힘든 것도 없었던 것 같습니다.

그렇다면, 여기에서 한 가지 궁금한 것이 생깁니다. XML 웹 서비스, WCF 둘 다 서비스 지향적인 아키텍처인가요?

먼저 일부 WCF 를 가리켜 SOA 라고 인지하는 분들의 경우, REST나 JSON 같은 경량화된 데이터 포멧(Data Format) 을 지원하기 때문에 서비스 지향적이라고 말합니다. 이것은 즉, 클라이언트가 웹 브라우저든 어떤 형태건 간에 선택적인 데이터 통신이 가능하다는 의미입니다. WCF 에서는 아주 간단하게 SOAP 데이터를 REST 방식이나 JSON 방식으로 쉽게 전환할 수 있죠.

또, 어떤 사람들은 여러 가지 통신 프로토콜을 통합하였기 때문에 서비스 지향적이라고 말합니다. .NET 리모팅이나 XML 웹 서비스, MSMQ, COM, COM+ 등을 통합했다는 이유로 말입니다.

그럼, 다시 질문하자면, XML 웹 서비스는 JSON 과 REST 를 지원하지 못하는 것일까요?

답변은 XML 웹 서비스는 이 과정을 .NET Framework 에서 기본적으로 제공하지 않을 뿐이지, 충분히 가능합니다. XML 웹 서비스는 통신 레이어 이전에 직렬화 및 역직렬화(Serialization/Unserialization) 과정을 거치는데, 이 과정에서 SOAP 을 REST 또는 JSON 으로 직렬화/역직렬화 하면 가능합니다.    

...

그렇다면 도대체 뭐가 서비스 지향적인 아키텍처인가?

일반적으로 일부 사람들이 이해하는 WCF 는 어떠한 방법으로도 서비스 지향적인 아키텍처를 제공하지 않습니다. 왜냐하면 WCF 든 XML 웹 서비스든 그 내부를 이해하지 못하고 사용한다면, 통신 프로토콜만 다를 뿐, 똑같은 XML 웹 서비스에 지나지 않기 때문입니다.    

필자는 서비스 지향 아키텍처에 WCF 에 한 표를 던져 주고 싶습니다. WCF 는 기본적인 환경에서 서비스 지향적인 프로그래밍을 제공해 주지는 않지만, 이미 WCF 프레임워크의 내부는 서비스 지향적인 아키텍처로 설계가 되었기 때문입니다.    

그렇다면 우리는 WCF 의 특징을 다시 한번 살펴볼 필요가 있습니다.

• HTTP 통신, .NET 리모팅, TCP 통신, MSMQ 통합
• 계약(Contracts) 기반의 아키텍처 (매우 중요)
• COM, COM+ 통합
• WS-AtomicTransaction(WS-AT) 을 통한 분산 트랜잭션 지원
• 데이터 계약 버전 관리(http://msdn.microsoft.com/ko-kr/library/ms733832.aspx)
• 서비스 라우팅 (http://msdn.microsoft.com/ko-kr/magazine/cc500646.aspx)
• 데이터 변환 (Data Transformation)
• 기타 등등

이렇듯 WCF 프레임워크는 다양한 기능을 제공합니다. 즉, 이러한 프레임워크를 알지 못하고서는 WCF 는 단지 XML 웹 서비스에 불과하다는 것과 같습니다.

SOA 에 좀 더 접근하기. ESB(Enterprise Services Bus)…

사실 SOA 는 아키텍처 측면의 용어로써 그 의미를 해석하는 것에 따라서 서로간의 바로 보는 관점이 다를 수 있습니다. SOA 를 이해함에 있어서 XML 웹 서비스도 WCF 도 SOA 에 해당됩니다.

하지만 SOA 적인 아키텍처를 좀 더 구체화한 것이 바로 ESB(Enterprise Services Bus) 라고 보셔도 좋습니다. SOA 를 적용하고 아키텍처링함에 있어서 최소한의 요구 사항을 충실히 구현한 것이 바로 ESB 입니다.    

ESB(Enterprise Services Bus) 에 대해 잘 설명해 놓은 아래의 글을 참고 하십시오.

제 1부 : 서비스 포트폴리오의 구현
제 2부 : Enterprise Service Bus 를 이용한 서비스의 연결

즉, ESB(Enterprise Services Bus) 는 서비스 가상화(Services Virtualization) 을 통해 중앙 집약적인 정책을 수립하여 적용하는 것입니다. 서비스의 제공자와 서비스의 소유자간의 명확한 계약(Contracts) 을 통해서 정책적, 중앙 집약적인 서비스가 가능한 것이 ESB 의 모티브이기도 합니다. 바로 서비스 가상화는 이 두 사이의 명확한 계약 관계가 성립됨으로써 가능한 것입니다.    

또한, 서비스 가상화를 통해서 서비스를 재조합(Recomposition) 이 가능한 것 또한 ESB 의 특징이기도 합니다. 서비스의 제공자와 서비스의 소유자 간의 명확한 계약 관계가 성립됨으로써 서비스의 제공자를 다른 서비스로의 전이, 신규 서비스 창출, 서비스의 조합이라는 것이 가능합니다.    

필자는 이러한 ESB 에 좀 더 가까운 개발 프레임워크를 만들기 위해 아래와 같은 프레임워크를 개발한 적이 있습니다. (아래는 관련 업계에 재직 당시에 개발했던 프레임워크입니다)

DxEF.Proxy.Dynamic 프레임워크 개발
DxEF.Proxy.Dynamic.SoaServices 프레임워크 개발

첫 번째로, 명확하게 서비스(Services) 와 서비스의 계약(Services Contracts or Interface) 를 구분함으로써 서비스의 소유자와 서비스의 제공자를 구분하였고, Dynamic Proxy 기법을 통해서 동적인 서비스적인 측면을 지향하였습니다.    

다시 말하면, WCF 는 SOA 를 위한 인프라스트럭처(Infrastructure) 를 제공할 뿐이지, XML 웹 서비스와 같이 '서비스 참조' 기능만 이용한다면 그것은 그냥 XML 웹 서비스와 크게 다를 바가 없다는 의미입니다.    

좀 더 서비스 지향적인 서비스를 위해...

이미 .NET Framework 는 더 이상 연습하고 학습하는 것만으로 습득할 수 있는 기술이 아닙니다. 마치 수십 수백 권의 "백과 사전" 수천 페이지가 바로 .NET Framework 입니다. 그 백과 사전이 바로 MSDN Documents Library 입니다.    

.NET 기술을 올바르게 사용하는 것은 매우 쉽습니다. 왜냐하면 MSDN 은 너무나도 자세한 부분과 샘플까지 제공하기 때문입니다. 더 중요한 것은 기술을 올바르게 이해하고 활용하는 것이지, 남용을 한다면 .NET 기술은 그저 그런 기술 밖에 되지 않습니다. 마치 .NET vs Java 를 도마 위에 올려 놓고 100분 토론을 하는 것처럼 말이죠.   

필자는 아마도 "서비스 지향적인 아키텍처"가 아니라 "서비스 지향적인 서비스"에 좀 더 초점을 맞추고 .NET 기술이 나아갈 방향을 고민해야 할 시점이 아닌가 생각합니다.

때는 바야흐로 2009년 7월이네요. Velocity 를 공부하면서 메모해 놓은 것을 이제서야 발견하여 포스팅을 하고 있습니다. ^^;

현재는 Windows Server AppFabric 이라는 이름으로 공개가 되고 있으며, 코드명은 바로 "Velocity" 라는 이름입니다. 현재 AppFabric Beta 1 까지 출시되었고 이제는 거의 모습을 찾아가고 있는 것 같습니다. 차후에 Velocity 의 현재 제품이름인 AppFabric 을 자세히 살펴보기로 하며, Velocity CTP 3 기준으로 설치와 사용 방법을 간단히 알아보고자 합니다.

Why Windows Server AppFabric (Codename "Velocity") ?

Velocity 는 분산 캐싱 프레임워크입니다. 우선 분산 캐싱이 왜 필요한지 이해가 필요합니다. 기존에는 캐싱이라고 함은 in-proc 캐싱을 의미했으며 즉 메모리 상에서 객체를 캐싱(Caching)하거나 풀링(Pooling)하기 위해 시스템의 리소스(Resource) 를 사용했습니다.

하지만 점차 엔터프라이즈 솔루션은 대규모, 대용량화 되어감에 따라 in-proc 캐싱은 시스템 리소스나 성능에 영향을 받게 되었습니다. 기존의 엔터프라이즈 솔루션은 데이터베이스의 대용량 아키텍처에 민감했고, 즉 데이터 중심의 아키텍처링을 할 수 밖에 없었습니다. 데이터의 정합성, 안정성, 성능은 기업에서 돈(Money) 와 직결되는 문제이기 때문이죠.

하지만 이미 데이터와 관련된 기술과 노하우는 이미 포화 상태이고, 엔터프라이즈 전체적인 아키텍처를 보았을때 단지 병목은 데이터에서만 존재하는 것이 아니었다는 것입니다. Middleware 나 Application Server 의 아키텍처링도 이미 포화 상태이고, 이것을 극복하기 위해서는 바로 캐싱(Caching) 이라는 기술이 필요했습니다.

위에서도 언급하였듯이 in-proc 캐싱은 굉장히 단순한 아키텍처입니다. 서버의 리소스가 받쳐 주느냐 그렇지 않느냐의 문제였고 in-proc 그리고 더 나아가 out-proc 를 이용하여 서버 자원을 최대한 활용하고자 합니다. 하지만 여기에서 또 문제가 발생합니다. 분산 out-proc 캐싱을 하자니 분산된 캐싱 데이터의 정합성을 어떻게 보장하느냐 입니다. 즉, out-proc 로 인해 캐싱은 중앙 집중화가 될 수 밖에 없으며 이것은 서버의 리소스에 의존하는 문제의 원점으로 돌아간다는 것이죠.

About Windows Server AppFabric (Codename "Velocity")

이러한 엔터프라이즈 환경의 서비스 확장에 대해서 고질적인 문제였던, 그리고 성능을 극대화 할 수 있는 캐싱이라는 기술을 어떻게 활용하느냐에 관심을 갖게 되었습니다. 현재 이런 문제를 해결할 수 있는 솔루션이 Windows Server AppFabric(Codename "Velocity") 입니다.

데이터의 정합성, 안정성, 성능은 기존의 아키텍처를 버리고 전용 Repository 를 통해 해결할 수 있습니다. 그것은 데이터베이스가 될 수 있고, 그 밖에 다른 Repository 가 될 수 도 있겠죠. 바로 이러한 컨셉은 캐싱을 어떤 분산 시스템간이라도 공유한다는 의미입니다. 이러한 캐싱을 클러스터링한다는 것은 흔히 Caching Dependency 를 해결할 수 있는 아주 좋은 해결 방법이기도 합니다. 어떤 로컬 시스템이건, 어떤 원격 시스템이건 캐싱 정책을 적용받게 되는 것입니다.

Install Windows Server AppFabric (Codename "Velocity")

아래는 필자는 게으름으로 Velocity CTP 3 기준으로 설치하는 방법입니다. (지금이라도 포스팅 하는걸 보면 대견스럽습니다만;;;)

기본적으로 캐싱 데이터는 데이터베이스를 사용합니다. 데이터베이스의 파일이 저장이 될 경로를 입력하거나 Storage 타입을 정하시면 됩니다.

Architect Development 을 위하여 무엇을 해야 할가요?
아니 Architect Development 이란 영역은?

우리가 흔히 개발을 한다고 하면 보통 요구사항 분석, 설계, 개발, 테스트 및 디버깅, 배포를 끝으로 그 다음 유지보수를 합니다. 유지보수에서는 개발, 테스트 및 디버깅 재배포 등의 단계를 거치게 됩니다.
그렇다면 여기서 앞 부분은 요구사항 분석, 설계 부분은 유지보수에서 빠지는 것일까요?

답은 " 아닙니다 " 겠죠? 그렇다면 요구사항 분석, 설계 부분이 빠지는 이유는 개발이 완료되고 배포되어 사용자가 사용하고 있는 중에 문제가 오류가 발생하여 개발자 분들이 수정하고 다시 테스팅 및 디버깅 후 배포하는 것입니다. 프로그램이 사용중에 오류가 발생하지 않고 고객 또는 사용자가 새로운 기능을 요구하였을 경우에는 어떻게 할까요?

여기서 옛날에 했던 요구사항 분석, 설계 부분을 돌아보게 됩니다. 그러면, 제가 지금까지 보아온 회사 중에서는 설계가 잘되어 있고, 요구사항 분석도 잘 되어 있어 모든 것이 일사 천리로 일이 진행 된것을 볼 수 있었습니다. 그렇지 않은 회사를 보면 어떻게 될지는 이 글을 읽는 개발자 분들이 더 잘 아실거라 생각합니다. 그럼 아키텍쳐 개발은?

아키텍처란 용어는 영한 사전에서보면  일반적으로 "건축, 천축술, 천축 양식, 구조"라고 번역합니다. 그렇다면국어사전은? 기능 면에서 본 컴퓨터의 구성방식이라고 설명합니다.(네이버 국어사전 참조) 여기서 아키텍쳐란 구조, 구성이라는 용어로 한번 보겠습니다.

구조, 저희가 개발하는 시스템에 대한 정확인 요구사항에 맞는 분석과 이를 기반으로 정확한 구조, 구성이 된 설계가 있다면 어떨까요? 이 설계의 기본적인 구조는 Windows 플랫폼에 PHP 개발, 아니면 ASP.NET 개발등으로 예를 들어 보고, 기본적인 구조를 정확히 정의하고 이를 표현할 수 있으며, 많이 사용하는 방법으로 표시하여 개발자들과 협업, 의사 소통이 이루어 질 수 있다면 어떨까요?

전 이 해답을 Visual Studio Team System(VSTS) 에서 찾았다고 생각합니다. 제가 MS 쪽 제품 중에 VSTS를 좋아하는 이유 중에 바로 Architect Development이 가능하게 해준다는 것입니다. 다른 제품 쪽도 있고 저 역시 다른 사이트에서 많은 자료를 봅니다.(다른 사이트의 Meet the Experts등 여러 사이트가 있습니다. 단 영어 입니다 ㅠ.ㅠ)

옛날 VSTS는 업계가 많이 사용하는 UML를 지원하지 않고 다른 모델링 도구등을 이용한 설계를 할 수 있도록 했습니다. 기능은 매우 훌륭했지만... 많은 사용자가 이것을 사용했을까 하는 것입니다. 지금은?

VSTS 에서도 이제 UML도 지원한다..

그럼? 네 Visio 같은 도구로 그림을 그리는 것이 줄어들었다는 것입니다. 그리고 VSTS에 통합되므로써 개발자들과의 의사소통, 협업이 가능하다는 것이 매우 좋아졌다는 겁니다. 프로젝트에서 대부분 아키텍쳐는 무시되고 요구사항이 수시로 바뀌는 등등 매우 많은 일들이 생겨나는데 이것을 대응할 수 있다는 것입니다.
업계에서 많이 사용하는 UML은 학교에서 S/W를 전공한 사람은 모두 한번씩 배웠던 것이고, 이를 이용하여 개발자들과 협업을 통해 고객의 요구사항을 능동적으로 대처할 수 있고, 실제 설계에 반영할 수 있습니다.

이런 매우 좋아진 이 VSTS 2010에 대하여 이제 부터 제가 하나씩 하나씩 알아보고 여러 분들에게 소개를 하겠습니다. ^^ 다음 은 그럼?? VSTS 2010의 모델링 개발에 대하여 이야기 하겠습니다.