잘 적용된다면 이라는 가정이 필수적이죠. 잘 적용됐을 때의 이점은 분명합니다.
서비스의 재사용으로 인해 비용 절감, 빠른 시장 진입, 비즈니스 유연성 등을 보장 받을 수 있죠.
문제는 개념이 아니라 실행입니다.
비즈니스 부서에서 시작되어야 하는데, IT 부서가 SOA를 Drive하는 형태로 진행된다면 정말 성공하기 어려울 겁니다. 투입되는 막대한 예산에 대한 ROI를 얻기가 정말 어렵죠.
조금 더 구체적으로 설명해보면 SOA 디자인의 핵심은 독특한 비즈니스 기능을 수행하는 서비스를 재활용 가능하도록 만드는 것이었습니다. 웹서비스를 만드는데 기본 프로토콜은 SOAP을 사용했고, WSDL, UDDI 등의 기본적인 표준이 포함됐고 기타 플랫폼과의 상호운영성을 위해 XML 스키마를 이용하여 개발되는 등 복잡하고 어려운 단점이 있습니다. 이에 반해 오늘 설명할 WOA(Web Oriented Architecture)는 데이터에 초점이 맞춰져 있습니다.
또한, 검증된 기술, 바로 WWW을 이루는 HTTP 프로토콜을 그대로 사용하고, SOAP보다 간단한 REST(Representational State Transfer) 프로토콜을 사용하여 URI(Uniform Resource Identifier) 형태로 참조되면서 웹서비스를 구현할 수 있습니다.
이렇게 말하면 WOA가 SOA를 대체하는 개념인가? 하고 궁금하실 겁니다. 그렇지는 않고 상호 보완 관계로 이해하시면 될 것 같습니다. SOA가 사용하는 SOAP, WSDL, UDDI 는 처음에는 스펙이 단순했지만 약 8년간 지나오면서 지원해야 하는 스펙이 타 기술과의 경쟁, 비준 등의 이유로 50개 이상으로 확대 되었습니다. 따라서, 이런 복잡한 방식말고 그냥 쉽게 웹서비스를 가져다가 쓰고 싶은 욕구가 당연히 생기겠죠? 그때 사용한 프로토콜이 바로 REST 입니다. 간단한 것이 대중화가 훨씬 쉬운 법이죠. 아마존의 웹서비스, AWS 중 S3 (Simple Storage Service), EC2(Elastic Cloud Computing) 역시 REST/WOA 방식으로 서비스 되고 있습니다. 처음 개발자들에게 SOA/SOAP, WOA/REST 방식을 선택해서 쓰라고 해봤더니 85%가 WOA/REST 방식을 선택하였기에 해당 서비스가 WOA/REST 방식으로 이루어지고 있는 거죠. 마이크로소프트도 역시 REST 방식의 프로토콜을 이용한 WOA를 지원하는데, .NET Framework 3.0 SP1에서 제공하는 WCF 서비스, ADO.NET 서비스, SQL Server Data Services 등도 모두 이 예에 속합니다.
이렇게 설명하면 WOA가 새로운 기술이라고 생각하시나요? 그렇게 보지 마시고, 기존에 모두 있던 기술, 즉 "REST, HTTP 프로토콜을 활용해 웹서비스를 생성한 것"이라고 이해하시면 되는데, 여기에 이름을 붙였다라고 보시면 될 것 같네요.
자, 이제 그럼 WOA가 어디에 쓰이고, 왜 많이 쓰일까 좀 살펴봐야겠죠. 웹2.0에서 아주 중요한 개념입니다. 웹기반 SW는 브라우저, 웹서비스로도 지원되어 새로운 형태로 메시업되어 사용될 수 있어야 합니다. 이렇게 되면 SW가 단순한 어플리케이션에서 진정한 플랫폼으로 변환 되는 것을 의미합니다. 마이크로소프트의 Virtual Earth를 가져다가 자동차 보험회사에서 사고처리 하는 웹을 구현하는 것도 하나의 예가 되고, Salesforce.com의 AppExchange를 통해 서비스를 조합하여 원하는 형태의 업무가 가능하게 하는 것도 또다른 예가 되겠죠.
즉, 어플리케이션을 웹서비스로 공유하여 내가 만든 기능과 데이터를 다른 사람이 혁신적인 방식으로 유용하게 사용하는, 이전에는 상상하기 어려운 진보를 이루어 내는 겁니다. 누구나 거대한 서비스의 공급망의 일원이 되는 거죠. 단순하고 직관적으로, "Just Work"를 이루어 내는 겁니다. 내부에서 사용하는 방식도 HTTP의 GET, POST, PUT, DELETE 등의 이미 알고 있는 형태로 조작됩니다.
짐작하셨겠지만 장점만 있을까요? 당연히 아니겠죠. Two-phase commit, 메시징에 대한 보안 등은 처리가 안됩니다. SOAP에서 가능한 WS-* 표준이 지원되지 않기 때문이죠. HTTPS를 통한 전송에 대한 보안만 제공됩니다.
WOA에 대해 조금 설명을 해보겠습니다.
1. 네트웍상에 리소스 형태, 즉 URI로 표현, 접근, 조작됩니다. (HTTP 프로토콜)
2. 네트웍상의 모든 자원은 URI 형태로 배치됩니다.
- URI는 자원임을 알 수 있는 것이 바람직합니다.
예) http://domain.com/blogs/feeds/sruby.com -> http://domain.com/resources/1234567
3. 자원은 HTTP 동사(즉, GET, POST, PUT, DELETE)로 조작됩니다. using REST
4. 자원의 형식(XHTML, XML, MP3, AVI 등)은 URI에 인코딩 되어야 합니다. .xml 일반적
5. 네트웍상의 자원에 대한 조작은 네트웍상의 컴포넌트를 통해 조작됩니다. (브라우저, 웹서버)
6. 자원에 대한 접근은 계층적으로 이루어지고, 기본 네트웍 지식으로 사용 가능합니다.
7. 보내지는 상태에 대한 전송은 각 컴포넌트가 책임져야 합니다.
8. WOA 자원은 더 큰 네트웍을 표현할 수 있도록 내장 URI를 가져갈 수 있습니다. (예, 주문 컴포넌트는 인벤토리 포함가능)
9. WOA는 Thomas Erl의 "SOA 핵심 원칙"을 따릅니다.
SOA와 WOA의 차이점 입니다.
1. SOA는 작고, 잘 정의된 Endpoint가 있는 경향이 있습니다. WOA는 매우 크고, Open된 많은 Endpoint가 있습니다.
2. 전통적으로 SOA는 SOAP을 사용한 HTTP 프로토콜 위에 메시지 Layer를 구축하는데, 유일하고 웹 개발자가 그대로 따라하도록 만들어집니다. WOA는 HTTP 및 그에 맞는 전송 메커니즘을 따르게 됩니다.
3. SOA는 벤더를 중심으로 Top Down 형태로 디자인 되고, WOA는 개발자들 중심의 Bottom Up 방식으로 나타납니다. 간단한 절차 코드와 XML 파서만 있으면 됩니다.
4. SOA는 보안 기능을 위해, 즉 메시지 암호화 등을 위해 WS-Security를 사용하는데 반해 WOA는 HTTPS를 사용합니다.
5. 웹 서비스 간의 상호 운영성을 위해 SOA는 XML 스키마를 사용해야만 합니다 WOA는 일반적으로 어떤 포맷도 가능합니다.
6. 전통적으로 SOA는 웹 브라우저 및 매시업 형태로 사용하기 어렵고 성가십니다. WOA는 어디서나 쉽게 사용 가능합니다.
즉, SOA와 WOA는 완전히 별개가 아니고 상호 보완 하는 형태로 이해하는 것이 좋습니다.
