WCF=SOA 에 대한 고찰

Architect Development 2010. 7. 21. 08:30 Posted by POWERUMC

사실 필자는 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 의 특징을 다시 한번 살펴볼 필요가 있습니다.

   

이렇듯 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 기술이 나아갈 방향을 고민해야 할 시점이 아닌가 생각합니다.