http://soaujws.springbook.playmaru.net/
으로 옮겼습니다.
고맙습니다.
2007년 12월 23일 일요일
2007년 10월 1일 월요일
soabook FAQ에 올라온 webservices-rt.jar 못 찾는 문제
mvn install을 하면 아래와 같은 오류가 나옵니다.
저는 symbolic link를 걸어 해결을 했습니다(복사를 하거나 pom.xml에서 파일 이름을 바꿔줘도 됩니다).
예) ln -s appserv-rt.jar webservices-rt.jar
참고 : soabook faq
Missing:이것은 말 그대로 webservices-rt.jar 파일을 못 찾는 건데, J2EE 버전이 올라가면서 이름이 webservices-rt.jar에서 appserv-rt.jar 파일로 이름이 변경되어 못 찾는 문제입니다.
----------
1) glassfish:webservices-rt:jar:system
Try downloading the file manually from the project website.
Then, 생략 ...
저는 symbolic link를 걸어 해결을 했습니다(복사를 하거나 pom.xml에서 파일 이름을 바꿔줘도 됩니다).
예) ln -s appserv-rt.jar webservices-rt.jar
참고 : soabook faq
2007년 8월 22일 수요일
SOA JWS 토론을 위해 구글 그룹 안내
http://groups.google.com/group/soabook
입니다. 공개 그룹이므로 자유롭게 토론 내용을 보고 참여하실 수 있습니다.
혹시 원서의 오탈자를 보셨거나 질문이 있으시면 이 그룹을 통해 공유하기를 권합니다.
번역서에서는 최대한 그러한 부분을 반영하도록 노력하겠습니다.
입니다. 공개 그룹이므로 자유롭게 토론 내용을 보고 참여하실 수 있습니다.
혹시 원서의 오탈자를 보셨거나 질문이 있으시면 이 그룹을 통해 공유하기를 권합니다.
번역서에서는 최대한 그러한 부분을 반영하도록 노력하겠습니다.
2007년 8월 17일 금요일
2007년 7월 24일 화요일
Binding VS Mapping
어제 스터디에서는 매우 흥미로운 주제에 사로잡혔습니다.
JAXB 2.0을 다루면서
Binding과 Mapping의 구분을 두는 개념이 책에 나왔기 때문입니다.
솔직히 저는, 바인딩과 매핑이 크게 다르지 않다고 생각했었는데,
책에서는 바인딩을 유도형, 매핑을 대응형으로 보고 있습니다.
유도형이란, 한쪽(자바 클래스 또는 XML 스키마)로부터 반대쪽이 유도되는 형태이고, 대응형은 이미 존재하는 양쪽을 이어주는 형태입니다.
따라서 바인딩은, From Java니 From XML이니 하는 프로그래밍 모델이 나올 수 있습니다. (JAX-WS와 매우 흡사하지요) 하지만 어느 한쪽은 이제 만들 대상이고, 이미 있는 것을 쓸 수는 없습니다.
하지만, 이 세상에는 기존의 리소스들이 엄청나게 많습니다. 매핑은 그런 데이터의 처리에 적합합니다.
재밌는 것은, 제가 2003년 방카슈랑스 프로젝트를 할 때, 바로 그 문제, 즉 매핑의 요구가 있었다는 사실입니다. 그리고 이 책으로 돌아와보면, 그때 만들었던 커스텀 매핑 방식이 매우 흡사하게 소개되고 있다는 것이 참 놀랍습니다.
아마도, 이런 문제는 (저자가 컨설팅을 업으로 하고 있다는 점에서) 자주 드러나나 봅니다. 사실, XML만의 관점으로 보면 XSLT로 다 되겠지만(실제 저도 방카슈랑스 할 때 XSLT를 도입할 뻔 했습니다), 현재 소프트웨어 실행 플랫폼이 자바와 같은 오브젝트 지향 프로그래밍 언어로 되어 있어서 변환이 늘 필요로 합니다. 그래서
XML 스키마 -> (JAXB로 바인딩된) 자바 클래스 -> 기존 자바 클래스
와 같은 방식으로 매핑을 해결한다는 것이죠.
다소 비효율적으로 보입니다만, 실제 썩 잘 돌아가는 얼개입니다. 더 자세한 이야기는 책의 본문을 기대해주세요.
JAXB 2.0을 다루면서
Binding과 Mapping의 구분을 두는 개념이 책에 나왔기 때문입니다.
솔직히 저는, 바인딩과 매핑이 크게 다르지 않다고 생각했었는데,
책에서는 바인딩을 유도형, 매핑을 대응형으로 보고 있습니다.
유도형이란, 한쪽(자바 클래스 또는 XML 스키마)로부터 반대쪽이 유도되는 형태이고, 대응형은 이미 존재하는 양쪽을 이어주는 형태입니다.
따라서 바인딩은, From Java니 From XML이니 하는 프로그래밍 모델이 나올 수 있습니다. (JAX-WS와 매우 흡사하지요) 하지만 어느 한쪽은 이제 만들 대상이고, 이미 있는 것을 쓸 수는 없습니다.
하지만, 이 세상에는 기존의 리소스들이 엄청나게 많습니다. 매핑은 그런 데이터의 처리에 적합합니다.
재밌는 것은, 제가 2003년 방카슈랑스 프로젝트를 할 때, 바로 그 문제, 즉 매핑의 요구가 있었다는 사실입니다. 그리고 이 책으로 돌아와보면, 그때 만들었던 커스텀 매핑 방식이 매우 흡사하게 소개되고 있다는 것이 참 놀랍습니다.
아마도, 이런 문제는 (저자가 컨설팅을 업으로 하고 있다는 점에서) 자주 드러나나 봅니다. 사실, XML만의 관점으로 보면 XSLT로 다 되겠지만(실제 저도 방카슈랑스 할 때 XSLT를 도입할 뻔 했습니다), 현재 소프트웨어 실행 플랫폼이 자바와 같은 오브젝트 지향 프로그래밍 언어로 되어 있어서 변환이 늘 필요로 합니다. 그래서
XML 스키마 -> (JAXB로 바인딩된) 자바 클래스 -> 기존 자바 클래스
와 같은 방식으로 매핑을 해결한다는 것이죠.
다소 비효율적으로 보입니다만, 실제 썩 잘 돌아가는 얼개입니다. 더 자세한 이야기는 책의 본문을 기대해주세요.
2007년 7월 19일 목요일
예제 오픈 소스 프로젝트 출범!
http://code.google.com/p/soabook/
에 책의 원저자인 Mark Hansen이 올렸습니다.
가장 최신의 소스 코드가 올라올 예정이므로,
원서를 보시는 분들도 이쪽 예제를 쓰시기를 권해드립니다.
번역을 하면서 예제도 더 좋아지기를 희망합니다.
에 책의 원저자인 Mark Hansen이 올렸습니다.
가장 최신의 소스 코드가 올라올 예정이므로,
원서를 보시는 분들도 이쪽 예제를 쓰시기를 권해드립니다.
번역을 하면서 예제도 더 좋아지기를 희망합니다.
2007년 7월 14일 토요일
기술의 정반합
안녕하세요. 팀 블로그에 올리는 첫 글입니다. 개인적으로 팀 블로그란 매개가, 같은 주제에 대한 다양한 시선을 접할 수 있다는 점에서 매우 흥미롭다고 생각했었는데, 이렇게 직접 참여해서 경험해볼 수 있는 좋은 기회가 주어졌네요.
이 책의 1장을 읽어내려가면서, 저는 기술의 변화에는 흥미로운 흐름이 존재한다는 생각을 했습니다. 어떠한 시대에는 보통, 그 시대의 요구를 반영하는 이상이란 것이 출현하기 마련입니다. 이러한 이상을 구체화한것이 개념이라면, 그 개념을 실제로 만드는 것은 구현이라고 할 수 있습니다. 하지만, 현실에 적용하기에는 다양한 변수를 고려해야 하기에 개념과 구현간의 격차는 아무래도 클 수 밖에 없겠지요. 현대의 컴퓨팅 환경의 특징중 하나가, 각 요소간에 그 경계를 넘나드는 통합과 복합화라는 것을 감안하면 이러한 격차는 더욱 두드러져 갈 것임을 짐작해 볼 수 있습니다. 게다가 사회적, 문화적 요인이나, 각 집단간의 정치적 입장까지 고려하면, 아이고~ 무엇인가를 실체화하는 것은 꽤나 골치 아픈 일이긴 하군요.
그 가운데, 웹이라는 네트워크가 중심이 되는 오늘날의 세상은 크게 두 가지를 요구합니다. 분산된 환경들간의 통합. 여러 개별적인 기능들을 급변하는 환경에 맞게 빨리 조합해서 재창조. 이 두 가지 요구를 해결하기 위해서 나타난 것이 소위 SOA라고 할 수 있겠습니다. 앞서 말한 두 가지 요구처럼, SOA에 대한 정의도 제각기 다릅니다. 추상화 단계(Level of Abstraction)의 관점에서 설명하는 이도 있고, 혹자는 통합(Integration)과 상호운용성(Inter-operability)의 관점에서 설명을 하기도 합니다. 사실, 이 모든 요소들에 대한 요구들을 다 해결하고자 하는 것이 SOA의 이상이니만큼, 아직까지도 그 개념을 속시원하게 정의내리기는 쉽지 않습니다.
이러한 SOA를 구현할 수 있는 기술에는 여러가지가 있겠지만, 현재 SOA를 구현하는데 있어서 가장 대표적이고 대중적인 기술이라면, 이 책에서 다루고 있는 Web Services가 있겠습니다. 그리고 그 중심에는 엔터프라이즈 시장을 평정해버린 자바 웹서비스가 위치하고 있겠구요. 그리고 책에서 말하는 것처럼, 웹서비스는 WS-* 라고 총칭되는 엄청난 표준들을 쏟아내며 허우적거렸습니다. 그러다가 근래에는 REST라고 하는 대안적인 아키텍쳐 스타일이 주목을 받고 있기도 하지요. 그리고 새로운 표준, 새로운 기술들과 함께 돌아온 자바 웹서비스는, 보다 간결한 모습을 띄고 있습니다.
비대한 표준기술의 등장 그리고 퇴화. 대안 기술의 등장과 열광적인 환호. 다시 표준기술의 경량화. 비단, 웹서비스만이 이런 기술적 흐름을 타는 것은 아니지만, SOA와 웹서비스에 거는 기대가 컸던 만큼, 이러한 흐름이 더 뚜렷하게 나타났다고 생각해 볼 수도 있겠습니다. 그런데 여기서 두 가지 정도의 질문이 발생하죠. 그러면 왜 처음부터 간단하게 만들지 못했어? 또는 대안기술로 충분히 왠만큼 커버할 수 있는데, 대안기술로 갈아타야되지 않겠어? 류의 질문들 말이죠.
하지만, 인간의 모든 역사가 그러하듯이, 기술의 발전도 시행착오를 거쳐서야 발전합니다. 웹서비스가 포용하려고 했던 요구들을 정의하는 과정에서, 너무 많은 것을 담으려 했던 것이 문제였겠죠. 결국, 다양한 요구와 환경을 모두 수용하려했고, 점차 확장을 통해 그 몸집을 불려 왔기에 필연적으로 따라오게 되는 문제였을 뿐입니다. 구현이 어렵고 복잡하다. 데이터의 양이 비대해진다. 개발자 뿐이 아닌, 서비스 이용자측면에서도 접근성이 낮다… 하지만, 이런 단점들에도, 불구하고 여전히 웹서비스는 시장의 중심에 있는 기술임에는 틀림없습니다. 아직 하나의 단순한 아키텍쳐 스타일에 불과하고, 해석이 분분한 REST. 좋은 대안기술로 발전할 수는 있겠지만, 단순성이 만병통치약은 아니듯이, 그 나름의 용도는 분명히 제한적일 것입니다. 아직 검증되어야할 부분도 많구요. 반면에 엔터프라이즈 시장의 요구는 더더욱 커져만 가고, 동시에 자바가 축적해온 수많은 시행착오를 거친 노하우들은 그 자체로 큰 자산이 됩니다. 그리고 중요한 것은 자바 웹서비스도 이제, 그러한 REST의 장점들이나, 다른 단순성을 위한 시도들을 받아들여, 한 단계 더 도약하려고 하고 있다는 점입니다. 좀 늦었지만, 이제야 더 큰 확산을 위한 채비를 마쳤다고 할까요? 웹서비스가 이제는 확산의 시기를 넘어선 기술이라는 가트너의 보고서내용은 아직은 조금 시기상조인지도 모르겠습니다. 이제부터가 시작일지도 모르지요.
서울 가는 길이 하나가 아니라고 하듯이, 기술도 여러가지 길을 따라 진화합니다. 표준기술이 시장을 평정할 일도, 대안기술이 체제를 전복할 일도 쉽게 일어나지 않습니다. 저마다 각자의 쓰임새에 따라 길을 택할 뿐이고, 기술은 그 가운데도 표준과 대안이 서로 경쟁하고 대립하며, 정-반-합의 충돌로 새로움을 끊임없이 만들어냅니다. 더 나은 표준, 더 나은 기술이 생겨나겠지요. 하지만, 그 기술도 얼마 있어 등장할 새로운 요구가 도래하면, 또 다시 한참동안 새로운 정반합의 길을 가야만 합니다. 그리고 그 길 가운데서 어느 것을 선택할것은, 각자가 선택해야할 몫이겠지요.
보다 즐거운 자바 웹서비스라는 변화. 이 책이야말로 그런 새로운 변화의 도래를 알리는 책인것 같아, 하나 하나 책장을 넘기는 순간이 즐거운 것 같습니다. 아무쪼록 어서 알찬 번역으로 가득찬 이 책이 세상에 선보여서, 좀 더 많은 분들이 웹서비스에서 변화를, 새로운 즐거움을 맞이하게 되었으면 좋겠습니다 :)
이 책의 1장을 읽어내려가면서, 저는 기술의 변화에는 흥미로운 흐름이 존재한다는 생각을 했습니다. 어떠한 시대에는 보통, 그 시대의 요구를 반영하는 이상이란 것이 출현하기 마련입니다. 이러한 이상을 구체화한것이 개념이라면, 그 개념을 실제로 만드는 것은 구현이라고 할 수 있습니다. 하지만, 현실에 적용하기에는 다양한 변수를 고려해야 하기에 개념과 구현간의 격차는 아무래도 클 수 밖에 없겠지요. 현대의 컴퓨팅 환경의 특징중 하나가, 각 요소간에 그 경계를 넘나드는 통합과 복합화라는 것을 감안하면 이러한 격차는 더욱 두드러져 갈 것임을 짐작해 볼 수 있습니다. 게다가 사회적, 문화적 요인이나, 각 집단간의 정치적 입장까지 고려하면, 아이고~ 무엇인가를 실체화하는 것은 꽤나 골치 아픈 일이긴 하군요.
그 가운데, 웹이라는 네트워크가 중심이 되는 오늘날의 세상은 크게 두 가지를 요구합니다. 분산된 환경들간의 통합. 여러 개별적인 기능들을 급변하는 환경에 맞게 빨리 조합해서 재창조. 이 두 가지 요구를 해결하기 위해서 나타난 것이 소위 SOA라고 할 수 있겠습니다. 앞서 말한 두 가지 요구처럼, SOA에 대한 정의도 제각기 다릅니다. 추상화 단계(Level of Abstraction)의 관점에서 설명하는 이도 있고, 혹자는 통합(Integration)과 상호운용성(Inter-operability)의 관점에서 설명을 하기도 합니다. 사실, 이 모든 요소들에 대한 요구들을 다 해결하고자 하는 것이 SOA의 이상이니만큼, 아직까지도 그 개념을 속시원하게 정의내리기는 쉽지 않습니다.
이러한 SOA를 구현할 수 있는 기술에는 여러가지가 있겠지만, 현재 SOA를 구현하는데 있어서 가장 대표적이고 대중적인 기술이라면, 이 책에서 다루고 있는 Web Services가 있겠습니다. 그리고 그 중심에는 엔터프라이즈 시장을 평정해버린 자바 웹서비스가 위치하고 있겠구요. 그리고 책에서 말하는 것처럼, 웹서비스는 WS-* 라고 총칭되는 엄청난 표준들을 쏟아내며 허우적거렸습니다. 그러다가 근래에는 REST라고 하는 대안적인 아키텍쳐 스타일이 주목을 받고 있기도 하지요. 그리고 새로운 표준, 새로운 기술들과 함께 돌아온 자바 웹서비스는, 보다 간결한 모습을 띄고 있습니다.
비대한 표준기술의 등장 그리고 퇴화. 대안 기술의 등장과 열광적인 환호. 다시 표준기술의 경량화. 비단, 웹서비스만이 이런 기술적 흐름을 타는 것은 아니지만, SOA와 웹서비스에 거는 기대가 컸던 만큼, 이러한 흐름이 더 뚜렷하게 나타났다고 생각해 볼 수도 있겠습니다. 그런데 여기서 두 가지 정도의 질문이 발생하죠. 그러면 왜 처음부터 간단하게 만들지 못했어? 또는 대안기술로 충분히 왠만큼 커버할 수 있는데, 대안기술로 갈아타야되지 않겠어? 류의 질문들 말이죠.
하지만, 인간의 모든 역사가 그러하듯이, 기술의 발전도 시행착오를 거쳐서야 발전합니다. 웹서비스가 포용하려고 했던 요구들을 정의하는 과정에서, 너무 많은 것을 담으려 했던 것이 문제였겠죠. 결국, 다양한 요구와 환경을 모두 수용하려했고, 점차 확장을 통해 그 몸집을 불려 왔기에 필연적으로 따라오게 되는 문제였을 뿐입니다. 구현이 어렵고 복잡하다. 데이터의 양이 비대해진다. 개발자 뿐이 아닌, 서비스 이용자측면에서도 접근성이 낮다… 하지만, 이런 단점들에도, 불구하고 여전히 웹서비스는 시장의 중심에 있는 기술임에는 틀림없습니다. 아직 하나의 단순한 아키텍쳐 스타일에 불과하고, 해석이 분분한 REST. 좋은 대안기술로 발전할 수는 있겠지만, 단순성이 만병통치약은 아니듯이, 그 나름의 용도는 분명히 제한적일 것입니다. 아직 검증되어야할 부분도 많구요. 반면에 엔터프라이즈 시장의 요구는 더더욱 커져만 가고, 동시에 자바가 축적해온 수많은 시행착오를 거친 노하우들은 그 자체로 큰 자산이 됩니다. 그리고 중요한 것은 자바 웹서비스도 이제, 그러한 REST의 장점들이나, 다른 단순성을 위한 시도들을 받아들여, 한 단계 더 도약하려고 하고 있다는 점입니다. 좀 늦었지만, 이제야 더 큰 확산을 위한 채비를 마쳤다고 할까요? 웹서비스가 이제는 확산의 시기를 넘어선 기술이라는 가트너의 보고서내용은 아직은 조금 시기상조인지도 모르겠습니다. 이제부터가 시작일지도 모르지요.
서울 가는 길이 하나가 아니라고 하듯이, 기술도 여러가지 길을 따라 진화합니다. 표준기술이 시장을 평정할 일도, 대안기술이 체제를 전복할 일도 쉽게 일어나지 않습니다. 저마다 각자의 쓰임새에 따라 길을 택할 뿐이고, 기술은 그 가운데도 표준과 대안이 서로 경쟁하고 대립하며, 정-반-합의 충돌로 새로움을 끊임없이 만들어냅니다. 더 나은 표준, 더 나은 기술이 생겨나겠지요. 하지만, 그 기술도 얼마 있어 등장할 새로운 요구가 도래하면, 또 다시 한참동안 새로운 정반합의 길을 가야만 합니다. 그리고 그 길 가운데서 어느 것을 선택할것은, 각자가 선택해야할 몫이겠지요.
보다 즐거운 자바 웹서비스라는 변화. 이 책이야말로 그런 새로운 변화의 도래를 알리는 책인것 같아, 하나 하나 책장을 넘기는 순간이 즐거운 것 같습니다. 아무쪼록 어서 알찬 번역으로 가득찬 이 책이 세상에 선보여서, 좀 더 많은 분들이 웹서비스에서 변화를, 새로운 즐거움을 맞이하게 되었으면 좋겠습니다 :)
2007년 7월 11일 수요일
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)과 같은 메타데이터가 이 경우에 도움이 될 수도 있겠네요.
예제를 오픈 소스 프로젝트로!
원저자인 Marc와 협의하여 책의 예제들을 오픈 소스로 공식 출범하기로 했습니다.
원서를 사신 분들에게도 도움이 되리라 생각합니다.
정확한 소식은 추후 공지하겠습니다.
2007년 7월 10일 화요일
처음 번역을 하면서 ㅎㅎ
음, 아아 - 목을 가다듬고 ...
저는 주로 게시물이나 블로그를 소비하는 충실한 reader 역할을 하는데 ㅋㅋ
블로그에 글을 쓴다는게 어색하긴 하군요~
개인 블로그도 운영하지 않는 게으름이 수반된 무딘 성격 탓에...
3장 맨 처음에 번역을 할 때는 감회가 남다르더군요~
영어를 꾸준히 해온 것도 아니고, 전에 원서만 읽어 봤지 직접 번역을 해 본 적도 없기에
걱정이 무척 앞서긴 했습니다 ...
- 처음 각오 -
안 해본거 해본다는 기대 심리와
하면 되겠지~ 안되는게 어디 있겠어~
하는 안일한(?) 생각으로
- 시작부터 닥치는 시련 -
난 3장이니 4주간의 여유가 있군, 1장하고 2장 어떻게 하는지 보고 잘 참고해서 해보자!
란 생각을 갔고 있던 어느 목요일, 전체 스케줄이 어떻게 되는지 함 다시 볼려고 들어갔다가
알고야 말았다. 첫번째 시간이 나라는 걸 ...
ㅋ. 음 늦었지만 함 봐야지....
이제 시작~ 한 시간이 지났다. 1페이지도 번역을 못했다. 이게 어찌된 일이란 말인가?
앞이 깜깜해 지기 시작한다...
모르는 단어는 왜이리 많은지 - 일일이 사전 찾는데 지쳐간다.
우리말로 써 놓고는 내가 이해가 안간다 - 도대체 정확한 의미의 우리말이 생각이 안난다. 어휘력의 빈곤이란 말인가?
앞뒤 순서를 모르겠다 - 뒤에서 해석해야 하는거야 앞에서부터 해석해야 하는거야? 그게 그거 같은데~
내가 이렇게 국어를 몰랐나? - 앞뒤 순서 생각 안하고 썼던 말들이 순서를 바꿔 보니 의미가 확 틀려진다. 도대체 이런 세계는 머지?
... 더 많지만 부끄러워서 이만해야 겠다.
- 시간 확보하기 -
주말에는 컴퓨터 앞에만 있어야지하는 하는 각오로, 어떻게 주말을 사수할까 고민하고 있는데,
와이프가 어딜 가자고 한다. - 난 번역을 해야 하는데~
얘기가 안 통한다. 그럼 저녁에 잠깐 갔다오자고 하니 그러자고 한다.
함 집에서 해본다. 딸에는 책상 위에서 혼자 논다고는 하지만 내 팔을 가끔씩 엉덩이로 툭툭 치고 있고, 돌도 안 지난 둘째 애가 내 다리를 붙잡고 일어서기를 연습을 하고 있다. - 도대체 애엄마는 어디 간거여?
이대로는 안 되겠다. 어떻게 장소와 시간을 확보하지???
음 길어지는 군요~
다음에 이어서 써야 겠군요~ 이만...
저는 주로 게시물이나 블로그를 소비하는 충실한 reader 역할을 하는데 ㅋㅋ
블로그에 글을 쓴다는게 어색하긴 하군요~
개인 블로그도 운영하지 않는 게으름이 수반된 무딘 성격 탓에...
3장 맨 처음에 번역을 할 때는 감회가 남다르더군요~
영어를 꾸준히 해온 것도 아니고, 전에 원서만 읽어 봤지 직접 번역을 해 본 적도 없기에
걱정이 무척 앞서긴 했습니다 ...
- 처음 각오 -
안 해본거 해본다는 기대 심리와
하면 되겠지~ 안되는게 어디 있겠어~
하는 안일한(?) 생각으로
- 시작부터 닥치는 시련 -
난 3장이니 4주간의 여유가 있군, 1장하고 2장 어떻게 하는지 보고 잘 참고해서 해보자!
란 생각을 갔고 있던 어느 목요일, 전체 스케줄이 어떻게 되는지 함 다시 볼려고 들어갔다가
알고야 말았다. 첫번째 시간이 나라는 걸 ...
ㅋ. 음 늦었지만 함 봐야지....
이제 시작~ 한 시간이 지났다. 1페이지도 번역을 못했다. 이게 어찌된 일이란 말인가?
앞이 깜깜해 지기 시작한다...
모르는 단어는 왜이리 많은지 - 일일이 사전 찾는데 지쳐간다.
우리말로 써 놓고는 내가 이해가 안간다 - 도대체 정확한 의미의 우리말이 생각이 안난다. 어휘력의 빈곤이란 말인가?
앞뒤 순서를 모르겠다 - 뒤에서 해석해야 하는거야 앞에서부터 해석해야 하는거야? 그게 그거 같은데~
내가 이렇게 국어를 몰랐나? - 앞뒤 순서 생각 안하고 썼던 말들이 순서를 바꿔 보니 의미가 확 틀려진다. 도대체 이런 세계는 머지?
... 더 많지만 부끄러워서 이만해야 겠다.
- 시간 확보하기 -
주말에는 컴퓨터 앞에만 있어야지하는 하는 각오로, 어떻게 주말을 사수할까 고민하고 있는데,
와이프가 어딜 가자고 한다. - 난 번역을 해야 하는데~
얘기가 안 통한다. 그럼 저녁에 잠깐 갔다오자고 하니 그러자고 한다.
함 집에서 해본다. 딸에는 책상 위에서 혼자 논다고는 하지만 내 팔을 가끔씩 엉덩이로 툭툭 치고 있고, 돌도 안 지난 둘째 애가 내 다리를 붙잡고 일어서기를 연습을 하고 있다. - 도대체 애엄마는 어디 간거여?
이대로는 안 되겠다. 어떻게 장소와 시간을 확보하지???
음 길어지는 군요~
다음에 이어서 써야 겠군요~ 이만...
2007년 7월 4일 수요일
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 기업 인터넷”의 구분도 그리하여 점차 사라지고 있습니다. 웹에 대한 변증법적 진화가 이루어지면서, 우리는 또 다른 커뮤니케이션의 세상을 보게 되리라 믿습니다.
에 매우 논쟁적인 글이 올라왔습니다만,
한때 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 진영은 밀리는 형국이 되지 않을까 싶습니다.
표준과 구현, 그 미묘한 관계에서 냉정한 시장 논리를 봅니다.
2007년 7월 3일 화요일
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에 대한 전폭적인 지지를 표하지 못했을까요?
재밌는 주제들입니다만, 다음 포스트로 미루면서 여운을 남겨 보도록 하겠습니다.
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에 대한 전폭적인 지지를 표하지 못했을까요?
재밌는 주제들입니다만, 다음 포스트로 미루면서 여운을 남겨 보도록 하겠습니다.
2007년 6월 29일 금요일
리소스 URL의 진정성
REST에서는 Uniform Identifier가 매우 중요한 개념입니다.
그런데, 이것이 URL로 발현되면서 미묘한 문제가 생깁니다.
예를 들어 스프링노트의 페이지 URL을 보면
http://dev.springnote.com/pages/4434
와 같이 pages/ 뒤로 페이지 ID가 붙습니다.
그런데, 사실 이전 웹 애플리케이션에서는
pages?id=4434
와 같이 짰었죠.
즉, 전에는 /pages와 같은 URL을 리소스(즉 웹의 자원)이라고 생각했다기 보다는,
pages?action=view&id=4434
지극히 RPC스러운 호출 주소(http://..../pages) + 함수(action=view) + 인수(id=4434) 의 구조를 띄고 있었던 것입니다.
그렇다면, 웹에 있는 데이터로서의 리소스는 과연 어떤 URL을 가져야 할까요?
이런 생각을 해봅니다.
pages와 pages?id=3, pages/1의 차이.
pages는 페이지 콜렉션을 의미합니다.
pages?id=3에서 id=3은 매개변수이고, 부가 정보입니다.
즉
pages와 pages?id=3은 본질적으로 같은 리소스를 나타내야 한다는 것입니다.
한편, pages/3 은 pages와는 다른 URL을 가진 리소스입니다.
이렇게 3이라는 숫자를 부가적인 매개변수로 나타내느냐 아니면 경로의 일부로 삼느냐에 따라 리소스에 대한 시각이 달라집니다.
기존 웹 RPC 방식은 URL을 호출의 대상으로 삼고, 무슨 일을 할지와 무엇을 다룰지를 인풋 메시지로 넘겨 그 결과를 아웃풋 메시지로 받았습니다. 반면 REST에서는 URL로 접근할 수 있는 리소스 자체가 컴퓨팅의 대상이고, 그 리소스의 상태와 라이프사이클을 조정하는 일이 바로 웹을 통해 일어날 수 있는 일인 셈입니다.
그렇다면 어떨 때 매개변수 대신 부분 경로를 쓰는 것이 좋을까? 그 정보가 리소스의 타입을 바꾼다면 경로로 들어가는 것이 어떨까요? 예를 들어
pages 는 페이지 콜렉션
page/id 는 페이지 하나
와 같이요.
그런데, 이것이 URL로 발현되면서 미묘한 문제가 생깁니다.
예를 들어 스프링노트의 페이지 URL을 보면
http://dev.springnote.com/pages/4434
와 같이 pages/ 뒤로 페이지 ID가 붙습니다.
그런데, 사실 이전 웹 애플리케이션에서는
pages?id=4434
와 같이 짰었죠.
즉, 전에는 /pages와 같은 URL을 리소스(즉 웹의 자원)이라고 생각했다기 보다는,
pages?action=view&id=4434
지극히 RPC스러운 호출 주소(http://..../pages) + 함수(action=view) + 인수(id=4434) 의 구조를 띄고 있었던 것입니다.
그렇다면, 웹에 있는 데이터로서의 리소스는 과연 어떤 URL을 가져야 할까요?
이런 생각을 해봅니다.
pages와 pages?id=3, pages/1의 차이.
pages는 페이지 콜렉션을 의미합니다.
pages?id=3에서 id=3은 매개변수이고, 부가 정보입니다.
즉
pages와 pages?id=3은 본질적으로 같은 리소스를 나타내야 한다는 것입니다.
한편, pages/3 은 pages와는 다른 URL을 가진 리소스입니다.
이렇게 3이라는 숫자를 부가적인 매개변수로 나타내느냐 아니면 경로의 일부로 삼느냐에 따라 리소스에 대한 시각이 달라집니다.
기존 웹 RPC 방식은 URL을 호출의 대상으로 삼고, 무슨 일을 할지와 무엇을 다룰지를 인풋 메시지로 넘겨 그 결과를 아웃풋 메시지로 받았습니다. 반면 REST에서는 URL로 접근할 수 있는 리소스 자체가 컴퓨팅의 대상이고, 그 리소스의 상태와 라이프사이클을 조정하는 일이 바로 웹을 통해 일어날 수 있는 일인 셈입니다.
그렇다면 어떨 때 매개변수 대신 부분 경로를 쓰는 것이 좋을까? 그 정보가 리소스의 타입을 바꾼다면 경로로 들어가는 것이 어떨까요? 예를 들어
pages 는 페이지 콜렉션
page/id 는 페이지 하나
와 같이요.
2007년 6월 28일 목요일
RPC vs REST의 좋은 비유
지난 스터디에서 강규영님이 RPC와 REST를 비교하는 좋은 비유를 들어 주셨습니다.
사용자가 어떤 서비스를 쓰기 위해 인증하는 과정을 겪는데, 그때 기능적으로
로그인
로그아웃
이라고 본다면, 상태적으로는
사용자 세션이 있는가 없는가
로 대응된다는 것입니다.
좀 더 구체적으로 형상화해보면, 웹 서비스에서는
http://localhost:8080/AuthService 엔드포인트에
... 또는 ...
과 같이 메시지를 날리는 것과 REST에서
http://localhost:8080/session 리소스에
POST로 생성, DELETE로 제거를 하는 것이 같다는 뜻입니다.
즉 “행위”가 “상태의 변이”로 1대 1 투영되는 셈입니다.
사용자가 어떤 서비스를 쓰기 위해 인증하는 과정을 겪는데, 그때 기능적으로
로그인
로그아웃
이라고 본다면, 상태적으로는
사용자 세션이 있는가 없는가
로 대응된다는 것입니다.
좀 더 구체적으로 형상화해보면, 웹 서비스에서는
http://localhost:8080/AuthService 엔드포인트에
과 같이 메시지를 날리는 것과 REST에서
http://localhost:8080/session 리소스에
POST로 생성, DELETE로 제거를 하는 것이 같다는 뜻입니다.
즉 “행위”가 “상태의 변이”로 1대 1 투영되는 셈입니다.
2007년 6월 26일 화요일
SOA Using Java Web Services 번역을 시작하며
안녕하세요?
이 블로그는 SOA Using Java Web Services의 한국어 번역(출판사는 위키북스)을 맡은 팀의 공식 블로그입니다.
앞으로 책에 관련된 소식이나 번역 팀의 스터디로부터 얻어 함께 하고 싶은 생각들을 쓸 예정입니다.
번역서의 출간은 2007년 4사분기로 희망하고 있습니다 ^^
여러분들의 많은 관심과 참여(덧글을 통한 질문이나 의견) 바랍니다.
고맙습니다.
이 블로그는 SOA Using Java Web Services의 한국어 번역(출판사는 위키북스)을 맡은 팀의 공식 블로그입니다.
앞으로 책에 관련된 소식이나 번역 팀의 스터디로부터 얻어 함께 하고 싶은 생각들을 쓸 예정입니다.
번역서의 출간은 2007년 4사분기로 희망하고 있습니다 ^^
여러분들의 많은 관심과 참여(덧글을 통한 질문이나 의견) 바랍니다.
고맙습니다.
피드 구독하기:
글 (Atom)