Binding VS Mapping

어제 스터디에서는 매우 흥미로운 주제에 사로잡혔습니다.
JAXB 2.0을 다루면서
Binding과 Mapping의 구분을 두는 개념이 책에 나왔기 때문입니다.
솔직히 저는, 바인딩과 매핑이 크게 다르지 않다고 생각했었는데,
책에서는 바인딩을 유도형, 매핑을 대응형으로 보고 있습니다.
유도형이란, 한쪽(자바 클래스 또는 XML 스키마)로부터 반대쪽이 유도되는 형태이고, 대응형은 이미 존재하는 양쪽을 이어주는 형태입니다.
따라서 바인딩은, From Java니 From XML이니 하는 프로그래밍 모델이 나올 수 있습니다. (JAX-WS와 매우 흡사하지요) 하지만 어느 한쪽은 이제 만들 대상이고, 이미 있는 것을 쓸 수는 없습니다.
하지만, 이 세상에는 기존의 리소스들이 엄청나게 많습니다. 매핑은 그런 데이터의 처리에 적합합니다.
재밌는 것은, 제가 2003년 방카슈랑스 프로젝트를 할 때, 바로 그 문제, 즉 매핑의 요구가 있었다는 사실입니다. 그리고 이 책으로 돌아와보면, 그때 만들었던 커스텀 매핑 방식이 매우 흡사하게 소개되고 있다는 것이 참 놀랍습니다.
아마도, 이런 문제는 (저자가 컨설팅을 업으로 하고 있다는 점에서) 자주 드러나나 봅니다. 사실, XML만의 관점으로 보면 XSLT로 다 되겠지만(실제 저도 방카슈랑스 할 때 XSLT를 도입할 뻔 했습니다), 현재 소프트웨어 실행 플랫폼이 자바와 같은 오브젝트 지향 프로그래밍 언어로 되어 있어서 변환이 늘 필요로 합니다. 그래서

XML 스키마 -> (JAXB로 바인딩된) 자바 클래스 -> 기존 자바 클래스

와 같은 방식으로 매핑을 해결한다는 것이죠.

다소 비효율적으로 보입니다만, 실제 썩 잘 돌아가는 얼개입니다. 더 자세한 이야기는 책의 본문을 기대해주세요.

예제 오픈 소스 프로젝트 출범!

http://code.google.com/p/soabook/
에 책의 원저자인 Mark Hansen이 올렸습니다.
가장 최신의 소스 코드가 올라올 예정이므로,
원서를 보시는 분들도 이쪽 예제를 쓰시기를 권해드립니다.
번역을 하면서 예제도 더 좋아지기를 희망합니다.

기술의 정반합

안녕하세요. 팀 블로그에 올리는 첫 글입니다. 개인적으로 팀 블로그란 매개가, 같은 주제에 대한 다양한 시선을 접할 수 있다는 점에서 매우 흥미롭다고 생각했었는데, 이렇게 직접 참여해서 경험해볼 수 있는 좋은 기회가 주어졌네요.

이 책의 1장을 읽어내려가면서, 저는 기술의 변화에는 흥미로운 흐름이 존재한다는 생각을 했습니다. 어떠한 시대에는 보통, 그 시대의 요구를 반영하는 이상이란 것이 출현하기 마련입니다. 이러한 이상을 구체화한것이 개념이라면, 그 개념을 실제로 만드는 것은 구현이라고 할 수 있습니다. 하지만, 현실에 적용하기에는 다양한 변수를 고려해야 하기에 개념과 구현간의 격차는 아무래도 클 수 밖에 없겠지요. 현대의 컴퓨팅 환경의 특징중 하나가, 각 요소간에 그 경계를 넘나드는 통합과 복합화라는 것을 감안하면 이러한 격차는 더욱 두드러져 갈 것임을 짐작해 볼 수 있습니다. 게다가 사회적, 문화적 요인이나, 각 집단간의 정치적 입장까지 고려하면, 아이고~ 무엇인가를 실체화하는 것은 꽤나 골치 아픈 일이긴 하군요.

그 가운데, 웹이라는 네트워크가 중심이 되는 오늘날의 세상은 크게 두 가지를 요구합니다. 분산된 환경들간의 통합. 여러 개별적인 기능들을 급변하는 환경에 맞게 빨리 조합해서 재창조. 이 두 가지 요구를 해결하기 위해서 나타난 것이 소위 SOA라고 할 수 있겠습니다. 앞서 말한 두 가지 요구처럼, SOA에 대한 정의도 제각기 다릅니다. 추상화 단계(Level of Abstraction)의 관점에서 설명하는 이도 있고, 혹자는 통합(Integration)과 상호운용성(Inter-operability)의 관점에서 설명을 하기도 합니다. 사실, 이 모든 요소들에 대한 요구들을 다 해결하고자 하는 것이 SOA의 이상이니만큼, 아직까지도 그 개념을 속시원하게 정의내리기는 쉽지 않습니다.

이러한 SOA를 구현할 수 있는 기술에는 여러가지가 있겠지만, 현재 SOA를 구현하는데 있어서 가장 대표적이고 대중적인 기술이라면, 이 책에서 다루고 있는 Web Services가 있겠습니다. 그리고 그 중심에는 엔터프라이즈 시장을 평정해버린 자바 웹서비스가 위치하고 있겠구요. 그리고 책에서 말하는 것처럼, 웹서비스는 WS-* 라고 총칭되는 엄청난 표준들을 쏟아내며 허우적거렸습니다. 그러다가 근래에는 REST라고 하는 대안적인 아키텍쳐 스타일이 주목을 받고 있기도 하지요. 그리고 새로운 표준, 새로운 기술들과 함께 돌아온 자바 웹서비스는, 보다 간결한 모습을 띄고 있습니다.

비대한 표준기술의 등장 그리고 퇴화. 대안 기술의 등장과 열광적인 환호. 다시 표준기술의 경량화. 비단, 웹서비스만이 이런 기술적 흐름을 타는 것은 아니지만, SOA와 웹서비스에 거는 기대가 컸던 만큼, 이러한 흐름이 더 뚜렷하게 나타났다고 생각해 볼 수도 있겠습니다. 그런데 여기서 두 가지 정도의 질문이 발생하죠. 그러면 왜 처음부터 간단하게 만들지 못했어? 또는 대안기술로 충분히 왠만큼 커버할 수 있는데, 대안기술로 갈아타야되지 않겠어? 류의 질문들 말이죠.

하지만, 인간의 모든 역사가 그러하듯이, 기술의 발전도 시행착오를 거쳐서야 발전합니다. 웹서비스가 포용하려고 했던 요구들을 정의하는 과정에서, 너무 많은 것을 담으려 했던 것이 문제였겠죠. 결국, 다양한 요구와 환경을 모두 수용하려했고, 점차 확장을 통해 그 몸집을 불려 왔기에 필연적으로 따라오게 되는 문제였을 뿐입니다. 구현이 어렵고 복잡하다. 데이터의 양이 비대해진다. 개발자 뿐이 아닌, 서비스 이용자측면에서도 접근성이 낮다… 하지만, 이런 단점들에도, 불구하고 여전히 웹서비스는 시장의 중심에 있는 기술임에는 틀림없습니다. 아직 하나의 단순한 아키텍쳐 스타일에 불과하고, 해석이 분분한 REST. 좋은 대안기술로 발전할 수는 있겠지만, 단순성이 만병통치약은 아니듯이, 그 나름의 용도는 분명히 제한적일 것입니다. 아직 검증되어야할 부분도 많구요. 반면에 엔터프라이즈 시장의 요구는 더더욱 커져만 가고, 동시에 자바가 축적해온 수많은 시행착오를 거친 노하우들은 그 자체로 큰 자산이 됩니다. 그리고 중요한 것은 자바 웹서비스도 이제, 그러한 REST의 장점들이나, 다른 단순성을 위한 시도들을 받아들여, 한 단계 더 도약하려고 하고 있다는 점입니다. 좀 늦었지만, 이제야 더 큰 확산을 위한 채비를 마쳤다고 할까요? 웹서비스가 이제는 확산의 시기를 넘어선 기술이라는 가트너의 보고서내용은 아직은 조금 시기상조인지도 모르겠습니다. 이제부터가 시작일지도 모르지요.

서울 가는 길이 하나가 아니라고 하듯이, 기술도 여러가지 길을 따라 진화합니다. 표준기술이 시장을 평정할 일도, 대안기술이 체제를 전복할 일도 쉽게 일어나지 않습니다. 저마다 각자의 쓰임새에 따라 길을 택할 뿐이고, 기술은 그 가운데도 표준과 대안이 서로 경쟁하고 대립하며, 정-반-합의 충돌로 새로움을 끊임없이 만들어냅니다. 더 나은 표준, 더 나은 기술이 생겨나겠지요. 하지만, 그 기술도 얼마 있어 등장할 새로운 요구가 도래하면, 또 다시 한참동안 새로운 정반합의 길을 가야만 합니다. 그리고 그 길 가운데서 어느 것을 선택할것은, 각자가 선택해야할 몫이겠지요.

보다 즐거운 자바 웹서비스라는 변화. 이 책이야말로 그런 새로운 변화의 도래를 알리는 책인것 같아, 하나 하나 책장을 넘기는 순간이 즐거운 것 같습니다. 아무쪼록 어서 알찬 번역으로 가득찬 이 책이 세상에 선보여서, 좀 더 많은 분들이 웹서비스에서 변화를, 새로운 즐거움을 맞이하게 되었으면 좋겠습니다 :)

REST 갑론을박

REST는

Roy Fielding의 박사 논문에서부터 시작합니다.

그런데, 그 논문은 어찌보면 매우 형이상학적이어서,

우리가 통상 스펙이라고 말하는

특히 프로그래밍 언어 수준의 API도 없습니다.

그러다보니, REST에 대한 해석이 분분한데,

동적인 요소, 예를 들어 서비스들 중에서 어떤 서비스를 지칭할 때 URL로

services/dummy

가 좋을지(혹은 맞을지)

services?name=dummy

가 그런 이슈입니다.

사실 엄밀하게 말하면 ?name=dummy는 URL상의 경로는 아닙니다. 말하자면 부가 정보인 셈이죠. 따라서 특정 리소스의 존재성을 부각시킨다는 차원에서는 services/dummy가 좋아 보입니다. 

한편, 동적인 요소를 파라미터로 처리해오던 것이 그동안의 웹 애플리케이션의 관행이었고, 경로를 분석해서 동적인 요소를 추출하는 것에 대한 API나 설정의 배려가 아직까지 (요청 파라미터 처리에 비해 상대적으로) 부족한 플랫폼에서는 아무래도 현실적으로 services?name=dummy를 선호하게 됩니다.

단적인 실례가 되겠지만,  레일스는 전자를 기본으로 삼는 반면, SOA 책에서는 후자를 선보이고 있습니다.

경로 VS 매개변수의 이슈와 더불어, 또 하나 재밌는 이슈가 있습니다. 바로 명사 VS 동사의 문제입니다.  지난번 강규영님의 멋진 예에서 REST가 리소스의 상태 변경으로 우리가 원하는 동작을 실현한다고 했는데, 상태변경의 표현을 명사로 하느냐 동사로 하느냐 하는 것입니다. 예를 들어

services/dummy?action=investigate

라고 하면 services/dummy라는 리소스에 investigate라는 액션을 취하는 것으로 보이지만, CRUD 입장에서는 (investigate가 기본적으로 리소스를 본다라고 가정하여)

GET services/dummy

로 하면 된다는 것이죠. 특히나 CRUD로 표현이 안되는 동작에서는 더욱 이 논쟁이 뜨겁습니다. 그래서 레일스에서도 ;과 같은 살짝 비표준적인 방식을 썼다가 사파리 브라우저에서의 문제로 _method 파라미터를 쓰고 있습니다.

HTTP 메소드가 확장적으로 쓰이면서 WebDAV 같은 경우에도 HTTP 기본 메소드 이상의 메소드를 정의해 쓰고 있습니다만, 만약 애플리케이션마다 자기나름의 HTTP 메소드를 정해서 쓴다면 어떨까요? 예를 들어

INVESTIGATE services/dummy

이 경우에는 안타까운 것이,  INVESTIGATE라는 메소드는 표준이 아니어서 이 리소스 이외에서는 재활용이 불투명하고, 어떤 리소스가 INVESTIGATE가 가능한지도 알기 힘듭니다.

WADL(Web Application Description Language)과 같은 메타데이터가 이 경우에 도움이 될 수도 있겠네요.

스키마에 WADL에, 점점 웹 서비스처럼 복잡해지는 것을 경계하는 사람들도 있습니다만, 편의성의 측면에서 접근하는 시각도 음미해볼만합니다.

예제를 오픈 소스 프로젝트로!

원저자인 Marc와 협의하여 책의 예제들을 오픈 소스로 공식 출범하기로 했습니다.

원서를 사신 분들에게도 도움이 되리라 생각합니다.

정확한 소식은 추후 공지하겠습니다.

처음 번역을 하면서 ㅎㅎ

음, 아아 - 목을 가다듬고 ...

저는 주로 게시물이나 블로그를 소비하는 충실한 reader 역할을 하는데 ㅋㅋ
블로그에 글을 쓴다는게 어색하긴 하군요~
개인 블로그도 운영하지 않는 게으름이 수반된 무딘 성격 탓에...

3장 맨 처음에 번역을 할 때는 감회가 남다르더군요~
영어를 꾸준히 해온 것도 아니고, 전에 원서만 읽어 봤지 직접 번역을 해 본 적도 없기에
걱정이 무척 앞서긴 했습니다 ...

- 처음 각오 -
안 해본거 해본다는 기대 심리와
하면 되겠지~ 안되는게 어디 있겠어~
하는 안일한(?) 생각으로

- 시작부터 닥치는 시련 -
난 3장이니 4주간의 여유가 있군, 1장하고 2장 어떻게 하는지 보고 잘 참고해서 해보자!
란 생각을 갔고 있던 어느 목요일, 전체 스케줄이 어떻게 되는지 함 다시 볼려고 들어갔다가
알고야 말았다. 첫번째 시간이 나라는 걸 ...

ㅋ. 음 늦었지만 함 봐야지....
이제 시작~ 한 시간이 지났다. 1페이지도 번역을 못했다. 이게 어찌된 일이란 말인가?
앞이 깜깜해 지기 시작한다...
모르는 단어는 왜이리 많은지 - 일일이 사전 찾는데 지쳐간다.
우리말로 써 놓고는 내가 이해가 안간다 - 도대체 정확한 의미의 우리말이 생각이 안난다. 어휘력의 빈곤이란 말인가?
앞뒤 순서를 모르겠다 - 뒤에서 해석해야 하는거야 앞에서부터 해석해야 하는거야? 그게 그거 같은데~
내가 이렇게 국어를 몰랐나? - 앞뒤 순서 생각 안하고 썼던 말들이 순서를 바꿔 보니 의미가 확 틀려진다. 도대체 이런 세계는 머지?
... 더 많지만 부끄러워서 이만해야 겠다.

- 시간 확보하기 -

주말에는 컴퓨터 앞에만 있어야지하는 하는 각오로, 어떻게 주말을 사수할까 고민하고 있는데,
와이프가 어딜 가자고 한다. - 난 번역을 해야 하는데~
얘기가 안 통한다. 그럼 저녁에 잠깐 갔다오자고 하니 그러자고 한다.
함 집에서 해본다. 딸에는 책상 위에서 혼자 논다고는 하지만 내 팔을 가끔씩 엉덩이로 툭툭 치고 있고, 돌도 안 지난 둘째 애가 내 다리를 붙잡고 일어서기를 연습을 하고 있다. - 도대체 애엄마는 어디 간거여?
이대로는 안 되겠다. 어떻게 장소와 시간을 확보하지???

음 길어지는 군요~
다음에 이어서 써야 겠군요~ 이만...

REST vs WS-*

http://www.infoq.com/news/2007/07/wsrest
에 매우 논쟁적인 글이 올라왔습니다만,
한때 WS-*에 몸담으며 밥을 먹고 살았던 저로서는 WS-*의 태두 David Chappell의 REST vs WS-* 전쟁의 정전 선언은 착잡한 마음마저 들게 합니다. (게다가 비유로 한국의 예를 들었으니···)
REST와 WS-*(SOAP/WSDL/UDDI 포함)은 마치 경쟁관계처러 비춰져서 한쪽이 완전 승리하지 않으면 안되는 듯한 관계로 여겨질 수도 있었지만, 실은 그렇게 생각한 사람은 별로 없지 않을까 싶습니다. 왜냐면, REST+WS-*계의 다수는 사용자이고, 어떤 경우에 어떤 것이 좋다는 경험과 원칙만 서면 뭐가 되었건 상관 없기 때문입니다.
제가 한때 자주 이분법적으로 불렀던 “민간 인터넷 vs 기업 인터넷”의 구분도 그리하여 점차 사라지고 있습니다. 웹에 대한 변증법적 진화가 이루어지면서, 우리는 또 다른 커뮤니케이션의 세상을 보게 되리라 믿습니다.

썬의 Metro, 이어지는 채택

http://blogs.sun.com/theaquarium/entry/glassfish_s_metro_now_also

에 나온대로, 썬의 웹 서비스 스택인 메트로(Metro)가 티맥스의 제우스,  BEA의 웹로직에 이어 JBoss에 까지 채택되었습니다. (아마 오라클도 OEM 했을 겁니다)

RI인 GlassFish는 물론이고, 이제 남은 건 IBM와 제로니모(Geronimo)같네요.

한때 JAX-RPC의 사실상의 RI로 위세를 떨쳤던 Axis 1의 다음 새대인 Axis2는 자바 표준보다는 경량 SOAP 프로세서를 지향했던 탓에 표준 채택에서는 밀리는 현상이 나타나고 있습니다. J2EE 1.4 때는  제우스, JBoss, JonAS, 제로니모 (그리고 살짝 포크를 뜬 IBM)까지 상당한 세를 자랑했던 점을 비추어보면 격세지감을 느낍니다.

여기에 WSIT까지 채택이 확대되면, WS-* 영역에서도 Axis2 진영은 밀리는 형국이 되지 않을까 싶습니다.

표준과 구현, 그 미묘한 관계에서 냉정한 시장 논리를 봅니다.

WSDL 2.0 마침내 W3C 공식 권고안으로 승인

제목이 제법 거창합니다만, 길고 긴 여정끝에 WSDL 2.0 스펙에 종지부를 찍게 되었습니다.
SOAP 1.2와 더불어 차세대 웹 서비스를 견인할 것으로 기대되온 WSDL 2.0은, 하지만 REST의 득세와 더불어 난관에 봉착한 듯 보입니다.
WSDL 2.0은 REST 서술에 적합하지 않습니다. 그 용도로는 오히려 WADL이 원래 웹 애플리케이션 인터페이스를 위한 것이라 REST를 온전히 다룹니다.
한편, SOAP 1.1과 WSDL 1.1로 (어쩌면 이제 겨우) 성숙된 웹 서비스 최하단을 무리하게 SOAP 1.2와 WSDL 2.0으로 올리려는 시도는 시간을 요구할 것이라 생각합니다. 특히 WSDL 2.0은 WSDL 1.1과 하위호환도 되지 않아 파장이 클 것이고, 이는 결국 기술의 소비자인 고객이 선택을 꺼리게 하는 가장 큰 이유가 될 것입니다.
그렇다면 어째서 WSDL 2.0은 하위 호환성까지 버리면서 무리한 변혁을 꾀했던 것일까요? 또 왜 REST에 대한 전폭적인 지지를 표하지 못했을까요?
재밌는 주제들입니다만, 다음 포스트로 미루면서 여운을 남겨 보도록 하겠습니다.