Don Box의 Indigo가 무엇인지/왜 Indigo를 만들었는지에 대해 ‘5분 안에 설명하기’. 영문를 읽기 싫어하는 사람들을 위해 대충 번역을 해주겠다.
Indigo는 structureal contracts (schemas) 또는 behavioral contracts (message exchange pattern) 를 사용하여 software를 연결한다.
CLR과 COM을 연동하고, local type을 data contracts나 service contracts로 추출해준다. Indigo의 특히 멋진 기능은 sender와 receiver가 같은 CLR type을 공유할 필요가 없다는 것이다. (Indigo와 CLR 혹은 COM 사이에서도..)
Indigo에서 사용하는 message는 SOAP processing/data model이 기반하고 있지만, 필요하지 않다면, angle bracket을 사용하지 않을 수 있다.
여러 message transport를 지원하고 transport-level/SOAP-level 모두에서 보안과 신뢰성(reliability)을 지원한다.
System.Transactions와 queueing system과도 tight하게 연동한다.
Indigo가 local type에 독립적으로 동작한다는 점은 매우 마음에 든다. 왜냐하면, Indigo와 같은 integration solution에서 가장 큰 문제 중 하나가, platform (예를 들면, programming language) 별로 local type을 어떤 common type으로 static하게 binding 해야한다는 점이 solution을 매우 구리게 만드는 점 중의 하나였기 때문이다. php와 C++ 간의 data mapping을 예로 들면, php 상의 array는 (요즘 대부분의 dynamic language에서 그런 것처럼) 실제로 hash이다. 하지만, C++의 array는 hash가 아닐 뿐더러, size 정보조차 없다. 물론 standard library (container)를 사용할 수 있다. 하지만, std::vector를 선택할 것인가? 아니면 hash container를 추가할 것인가? 논의가 이렇게 되면 C++ 개발자는 raw array를 돌려달라고 외친다. Microsoft의 경우 local type의 문제는 CLR에서 어느 정도 해결했겠지만, non-CLR platform에서는 다시 이 문제가 불거지게 마련이므로, Indigo에서 이러한 점을 해결(?)한 것은 매우 훌륭하다고 생각한다. 아마도 구현상으로는 XML messaging이 이러한 점을 해결해주는 것이 아닐까 하는데, contract 상에 정의된 데이터 모델과 local type 사이의 변환이 매우 자유로운 스타일 정도가 아닐까 생각된다. 자세한 것은 좀 더 살펴봐야할 듯 하다.
Message 자체와 Message Transport의 분리, 그리고 거기에 Aspect의 형태로 여러가지 서비스(Transaction, Security, …)를 붙일 수 있는 점은 매우 훌륭한 architecture인 것 같다. 물론 CORBA도 이러한 architecture이고, EIP 같은 책에서도 이러한 architecture를 언급하고 있으므로 절대 처음은 아니다.
SOAP/XML은 Service간의 integration을 위한 Web Services에서는 표준 프로토콜이 되었지만, 하나의 Service 내에서의 component/module 간의 integration에 과연 XML을 사용하는 것이 맞는 solution일까 하는 의문이 든다. 성능 때문에 XMLRPC도 버리는 마당에 말이다. (이것이 미신은 아니라고 생각한다.) angle bracket 없이 SOAP data를 전송한다는 것도 흥미로운 점인데, 일종의 binary protocol인지 아니면 단순히 약간의 성능을 위한 tweak인지가 궁금하다.
Why Indigo? : The Five Minute Challenge
대부분의 소프트웨어 개발은 이미 만들어진 코드와 이미 저장된 정보를 서로 붙이는 (gluing together) 것이다. 순수하게 처음부터 개발을 시작하는 (pure green fields development) 사치를 가진 사람은 거의 없다.
Microsoft나 업계 전체의 현상태는 integration (CORBA, DCOM, EDI)와 access (JNDI, JDBC, JMX)를 위한 여러 solution들을 만들어내고, 개발자들이 알아서 해결하는 것이다. Indigo에서는 XML messaging을 사용하여 interact하는 service에 기반한 새로운 범용 platform을 만들 수 있다.
중심 metaphor로 messaging을 선택한 것은, pipe의 end(역주: messaging을 주고 받는 peer/endpoint)에 사용되는 기술이 아닌, 교환되는 데이터의 통합(integration)에 집중을 하게 해준다. 이것은 great discipline으로 증명되었고, Indigo의 시작으로부터 수백명의 사람을 가진 팀(역주: Indigo 팀)이 집중을 할 수(초점을 가질 수) 있게 해주었다.
XML을 선택한 것은 진입점(bar of entry)을 가능한 한 낮게 해주었다. 돌아보면, XML stack은 상당히 복잡해졌고, (XSD, XML DSIG, XML Encryption, XQuery) 나는 XML 대신 Lisp S-Expressions에 기반한 architecture를 원했었다. 하지만 우리는 XML을 선택했다.
“service”란 용어를 선택한 것은 사실 어느 정도 임의적이다. 업계는 XML message를 사용하는 code에 대해 용어를 필요로 했고, “service”는 그 첫번째 용어였다. “SOA”의 인기(glow)가 사그라들기 시작하면, 우린 다른 이름을 사용하게 되리라고 확신한다. (예를 들면, “business agents”?)
재미있는 의문은 도대체 왜 Microsoft가 이것을 하느냐이다. 그것은 쉽다. 우리는 새로운 platform을 만들기 위한 local execution의 토대를 필요로 했고, CLR을 만들었다. CLR-based platform은 distributed/heterogeneous integration/access를 위한 토대를 필요로 하고 있고, 따라서 Indigo를 만들고 있는 것이다.
“Message”라는 metaphor를 왜 썼느냐보다, ‘metaphor’를 적극적으로 활용하고 있는 것이 인상적이었다. 우리 회사의 경우, 개개의 ‘requirement’가 개발의 주축을 이루기 때문에, 결과물인 product는 공유된 ‘metaphor’를 가지지 못하는 문제가 있는 것 같다. 진짜 문제는 ‘metaphor’가 없는 것이 아니라, 이로 인해, 해당 product의 정체를 아무도 모른다는 것이고, 또한 앞으로 어떤 방향으로 나가야할 지를 모른다는 것이다.
Indigo가 완성되면, CLR과 함께 엄청난 시너지를 발생시킬 것 같다. 어떻게 보면 ‘reinventing wheel’처럼 보이지만, ‘wheel’은 승합 마차에 쓰이느냐, 전차에 쓰이느냐에 따라 새로 발명할 필요도 있는 것이다.