IT/모바일
저자: 이아스님(http://www.iasandcb.pe.kr)
JDC 채팅 이야기
썬이 운영하고 있는 자바 개발자 모임(JDC)에서는 부정기적으로 자바 기술에 대한 채팅 세션을 엽니다(JDC Chat Sessions). 참가해보고 싶지만 시간대가 영 안맞아(사실은 실시간 영어 구사 문제...) 세션이 끝난 후 대화록을 보는 정도인데요, 올해 있었던 대화 중 흥미로운 것들 몇 가지에 대해 짚고 넘어가겠습니다.
JCP 선거가 시작되었습니다. 법인과 개인 상관없이 표는 한 장! 저도 소중히 행사하였습니다.
JCP에는 책임 위원회(Executive Committee)가 SE/EE, ME 플랫폼별로 있는데, JCP의 중요 사안에 대한 결의를 하는 의결 기관입니다. 예를 들어 어떤 JSR의 발의, 내부-공개-최종권고-최종 초안 승인 절차들이 EC의 승인을 기다리죠. 자세한 것은이곳<>을 참고하시기 바랍니다.
안타깝게도 한국 업체는 EC에 있지 않는데, 올해 새롭게 EC에 들어가고자 하는 후보자들로 SE/EE에는 애플, BEA, SAP이 ME에는 IBM, 노키아, 필립스가 있습니다. 저는 개인적으로 애플의 적극적인 모습이 무척 반갑고 앞으로 애플의 SE적인 활동뿐만 아니라 맥 서버의 엔터프라이적 활용에도 좋은 모습을 기대합니다. BEA와 SAP의 경우 오히려 "EC 아니었나?"라는 느낌이 들 정도로 이미 EE계의 거두들이고, IBM이 이제 ME에까지 발을 뻗고 있습니다. 그리고 노키아의 최근 표준 연구가 정말로 왕성하구나 하는 생각도 들었습니다.
어디에 찍었냐구요? ^^ 글쎄요... 올 우리나라 대선도 궁금해지네요.
톰켓4의 치명적인 보안 허점인 invoker 폐지후... 대안은 무엇인가
크랙 맥크래너헌씨는 다음과 같이 말하고 있습니다.
예를 들어 아래와 같은 식은 톰켓 4.1.12(그리고 톰켓 4.0.5, 또한 invoker를 무효화한 경우)에서 돌아가지 않습니다.
http://localhost:8080/myapp/servlet/com.mypackage.MyFooServlet
http://localhost:8080/myapp/servlet/com.mypackage.MyBarServlet
그래서, 두 가지 해결안이 있습니다.
이제 서블릿 규격의 참조 구현체인 톰켓이 invoker를 지양함으로써 서블릿 클래스만으로 서블릿을 호출하는, 즉 다른 식으로 말하면 서블릿 이름과 서블릿 대응의 정의 없이 서블릿 클래스를 호출하는 것 또한 자연스럽게 지양되는 상황이 연출되고 있습니다. 어찌 보면 현상이 규격을 다시 한번 정립하는 과정인데… 현재 서블릿 규격에서는 "하나의 서블릿 (클래스)는 반드시 서블릿 이름과 서블릿 대응을 가져야 한다."라는 규정이 없습니다. 이는 현실적으로 invoker와 같은 기능이 대부분의(아마 모든) 컨테이너에 탑재되어 있기 때문이죠. 하지만 웹 애플리케이션 개념의 정립을 위해서라도 이 부분에 대한 명확화가 필요했다고 봅니다.
그래서, 다음과 같은 결론을 얻습니다. "하나의 서블릿 (클래스)는 반드시 서블릿 이름과 서블릿 대응을 가져야 호출할 수 있다." 이것은 사실적인 규정입니다. 즉 서블릿 규격에는 없지만, 현실적으로 따라야 하는 정책이라는 것이죠.
여기서 생기는 또 하나의 의문은, 하나의 서블릿 클래스에 꼭 하나의 서블릿 이름이 붙어야 하는가, 즉 "일대일 대응(전단사)이어야 하는가"입니다. (서블릿 이름과 서블릿 대응은 당연히도 1대 다 대응이 가능합니다. 예를 들어 invoker 서블릿을 /servlet/* , /servlets/* 양 URL 패턴에 대응시킬 수 있습니다.)
이것도 매우 흥미롭게도 서블릿 클래스와 서블릿 이름은 1대 다 대응이 가능합니다. 즉 반드시 1대1 대응일 필요가 없다는 것이죠. 그러나 역으로 서로 다른 서블릿 클래스가 하나의 (같은) 서블릿 이름을 가지는 다 대 1 대응은 안됩니다. (이유는 극명합니다. 서블릿 이름이 의미 그대로 서블릿을 구분하기 위한 방책인데, 두 서블릿이 하나의 이름을 갖는다는 것 자체가 모순이죠.)
그래서, 다음과 같이 정리할 수 있습니다.
서블릿 클래스 -(1대 다)- 서블릿 이름 -(1대 다)- 서블릿 대응
어떻습니까? 위의 원리에 대한 예는 다음과 같습니다.
http://localhost:8080/test/servlet/iasandcb.TestServlet (기존에 invoker가 자동으로 제공해주었던 방식)
http://localhost:8080/test/servlet/TestServlet(완전 수식명에서 패키지명이 빠진 방식)
http://localhost:8080/test/servlet/cb
http://localhost:8080/test/cb
이런 원리는 톰켓뿐만 아니라 모든 웹 컨테이너가 준수하므로 비표준적인 invoker 류의 기능에 의존하지 말고 시실상의 규정에 따라 이식성과 보안성 높은 서블릿 작성과 배치에 힘써야겠습니다.
KVM에서도 웹 서비스를?
정확히는 CLDC-MIDP 이상에서 XML(SOAP메시지)를 다룰 수 있게 해주는 라이브러리가 있더군요. 이름하야 KSOAP. http://ksoap.enhydra.org/ 에서 보실 수 있습니다.
덧붙이는 말
저에게 책을 번역하고 쓸 수 있게 기회를 열어주시는 데에 결정적 도움을 주신 한 분에게 어제서야 비로서 저녁을 대접하게 되었습니다. 이번에는 일로 만나는 것이 아니니 편안한 이야기를 나눠야겠다고 했건만, 결국 1시간 넘게 책과 업계에 대해 떠들고 말았습니다. 오죽했으면 동석하셨던 사모님께서 "일얘기를 너무 재밌게 한다"고 하셨을까요. -.-;
사람들이 보통 말하는 "뜨고 잘나가는" 일은 아니지만, 아니 오히려 이제는 모두가 기피하는 그런 일이 되어버렸지만, 좋아하고 즐겁다는 것 하나로 해나가는 사람들을 만나면 세상은 혼자가 아니다라는 생각에 밤 바람도 따뜻하게 느껴집니다.
JDC 채팅 이야기
썬이 운영하고 있는 자바 개발자 모임(JDC)에서는 부정기적으로 자바 기술에 대한 채팅 세션을 엽니다(JDC Chat Sessions). 참가해보고 싶지만 시간대가 영 안맞아(사실은 실시간 영어 구사 문제...) 세션이 끝난 후 대화록을 보는 정도인데요, 올해 있었던 대화 중 흥미로운 것들 몇 가지에 대해 짚고 넘어가겠습니다.
- 자바 TV는 PBP?
최근 JCP에서는 J2ME 기술을 CDC와 CLDC로 이원적 통합하고 있는데, (물론 자바 카드는 별도로 하고) 자바 TV는 어디에 속하는 지에 대해 명확한 언급이 없었던 차, 이제 PBP와 PP에 대한 개념이 정립되면서 자바 TV는 PBP기반이라는 이야기가 나왔습니다. PBP와 PP는 눈에 띄는 차이가 있습니다. PBP는 Xlet을 GUI 애플리케이션의 틀로 하는 반면 PP는 옛날 퍼스널자바의 모습을 보여주는 Applet도 지원합니다. 더욱이 Xlet은 PBP가 나오기 이전 자바 TV에서 소개된 개념이니… PBP는 자바 TV, PP는 퍼스널 자바의 후예인 셈이죠. - 빠른 XML 처리를 위한 Streaming API for XML
여기에서 현재 논의 중입니다. (아직 어떠한 초안도 나와있지 않습니다만) XML 파싱을 스트리밍 개념(입력 스트림, 출력 스트림)으로 고속화하자는 것입니다. 이 기술을 JAXP, JAX-RPC, JAXB가 쓰면 더욱 효율적일 것이라고 합니다.
JCP 선거가 시작되었습니다. 법인과 개인 상관없이 표는 한 장! 저도 소중히 행사하였습니다.
JCP에는 책임 위원회(Executive Committee)가 SE/EE, ME 플랫폼별로 있는데, JCP의 중요 사안에 대한 결의를 하는 의결 기관입니다. 예를 들어 어떤 JSR의 발의, 내부-공개-최종권고-최종 초안 승인 절차들이 EC의 승인을 기다리죠. 자세한 것은
안타깝게도 한국 업체는 EC에 있지 않는데, 올해 새롭게 EC에 들어가고자 하는 후보자들로 SE/EE에는 애플, BEA, SAP이 ME에는 IBM, 노키아, 필립스가 있습니다. 저는 개인적으로 애플의 적극적인 모습이 무척 반갑고 앞으로 애플의 SE적인 활동뿐만 아니라 맥 서버의 엔터프라이적 활용에도 좋은 모습을 기대합니다. BEA와 SAP의 경우 오히려 "EC 아니었나?"라는 느낌이 들 정도로 이미 EE계의 거두들이고, IBM이 이제 ME에까지 발을 뻗고 있습니다. 그리고 노키아의 최근 표준 연구가 정말로 왕성하구나 하는 생각도 들었습니다.
어디에 찍었냐구요? ^^ 글쎄요... 올 우리나라 대선도 궁금해지네요.
톰켓4의 치명적인 보안 허점인 invoker 폐지후... 대안은 무엇인가
크랙 맥크래너헌씨는 다음과 같이 말하고 있습니다.
예를 들어 아래와 같은 식은 톰켓 4.1.12(그리고 톰켓 4.0.5, 또한 invoker를 무효화한 경우)에서 돌아가지 않습니다.
http://localhost:8080/myapp/servlet/com.mypackage.MyFooServlet
http://localhost:8080/myapp/servlet/com.mypackage.MyBarServlet
그래서, 두 가지 해결안이 있습니다.
1. 다시 invoker를 활성화한다. (conf/web.xml에서 주석을 풀면 됩니다.) 이 경우 보안에 있어서는 여전히 차후 취약점을 가지고 있습니다. 그리고 이식성도 없습니다. (톰켓 컨테이너간의 경우 더욱 그렇죠.)보안 문제때문이기도 하지만, 이 사안에 대해서 저는 이미 서블릿 규격 자체의 애매모호함에 대해 해당 JSR에 지적했었습니다. 원래 서블릿 규격이 성숙되기 시작하면서 서블릿 이름-서블릿 클래스-서블릿 대응의 개념이 생겨났는데, 특히 서블릿 클래스가 서블릿 이름 없이도 호출할 수 있는 빌미를 제공하는 것이 바로 invoker에 상당하는 기능 덕분이었습니다.
2. 필요한 서블릿을 해당 컨텍스트의 web.xml에 서블릿 대응시킵니다.이 방법은 필요한 서블릿 대응 설정을 선택적으로 유효화한 것으로, 톰켓뿐만 아니라 모든 컨테이너에 호환합니다. (invoker는 톰켓만의 기능이고, 서블릿 규격에는 서블릿 클래스에 대한 "/servlet/완전 수식 클래스명" 방식의 호출을 강제하지 않습니다.)Foo com.mypackage.MyFooServlet Bar com.mypackage.MyBarServlet Foo /servlet/com.mypackage.MyFooServlet Bar /servlet/com.mypackage.MyBarServlet
이제 서블릿 규격의 참조 구현체인 톰켓이 invoker를 지양함으로써 서블릿 클래스만으로 서블릿을 호출하는, 즉 다른 식으로 말하면 서블릿 이름과 서블릿 대응의 정의 없이 서블릿 클래스를 호출하는 것 또한 자연스럽게 지양되는 상황이 연출되고 있습니다. 어찌 보면 현상이 규격을 다시 한번 정립하는 과정인데… 현재 서블릿 규격에서는 "하나의 서블릿 (클래스)는 반드시 서블릿 이름과 서블릿 대응을 가져야 한다."라는 규정이 없습니다. 이는 현실적으로 invoker와 같은 기능이 대부분의(아마 모든) 컨테이너에 탑재되어 있기 때문이죠. 하지만 웹 애플리케이션 개념의 정립을 위해서라도 이 부분에 대한 명확화가 필요했다고 봅니다.
그래서, 다음과 같은 결론을 얻습니다. "하나의 서블릿 (클래스)는 반드시 서블릿 이름과 서블릿 대응을 가져야 호출할 수 있다." 이것은 사실적인 규정입니다. 즉 서블릿 규격에는 없지만, 현실적으로 따라야 하는 정책이라는 것이죠.
여기서 생기는 또 하나의 의문은, 하나의 서블릿 클래스에 꼭 하나의 서블릿 이름이 붙어야 하는가, 즉 "일대일 대응(전단사)이어야 하는가"입니다. (서블릿 이름과 서블릿 대응은 당연히도 1대 다 대응이 가능합니다. 예를 들어 invoker 서블릿을 /servlet/* , /servlets/* 양 URL 패턴에 대응시킬 수 있습니다.)
이것도 매우 흥미롭게도 서블릿 클래스와 서블릿 이름은 1대 다 대응이 가능합니다. 즉 반드시 1대1 대응일 필요가 없다는 것이죠. 그러나 역으로 서로 다른 서블릿 클래스가 하나의 (같은) 서블릿 이름을 가지는 다 대 1 대응은 안됩니다. (이유는 극명합니다. 서블릿 이름이 의미 그대로 서블릿을 구분하기 위한 방책인데, 두 서블릿이 하나의 이름을 갖는다는 것 자체가 모순이죠.)
그래서, 다음과 같이 정리할 수 있습니다.
서블릿 클래스 -(1대 다)- 서블릿 이름 -(1대 다)- 서블릿 대응
어떻습니까? 위의 원리에 대한 예는 다음과 같습니다.
실제 서블릿 클래스는 완전 수식명상 iasandcb.TestServlet 밖에 없지만 이 하나의 클래스에 대한 이름은 ias와 cb로 두 개, 또 그 이름에 대한 URL 대응도 각각 2개 이기 때문에 사실상 이 하나의 서블릿을 부르는 방법은 네 가지씩이나 됩니다.ias iasandcb.TestServlet cb iasandcb.TestServlet ias /servlet/iasandcb.TestServlet ias /servlet/TestServlet cb /servlet/cb cb /cb
http://localhost:8080/test/servlet/iasandcb.TestServlet (기존에 invoker가 자동으로 제공해주었던 방식)
http://localhost:8080/test/servlet/TestServlet(완전 수식명에서 패키지명이 빠진 방식)
http://localhost:8080/test/servlet/cb
http://localhost:8080/test/cb
이런 원리는 톰켓뿐만 아니라 모든 웹 컨테이너가 준수하므로 비표준적인 invoker 류의 기능에 의존하지 말고 시실상의 규정에 따라 이식성과 보안성 높은 서블릿 작성과 배치에 힘써야겠습니다.
KVM에서도 웹 서비스를?
정확히는 CLDC-MIDP 이상에서 XML(SOAP메시지)를 다룰 수 있게 해주는 라이브러리가 있더군요. 이름하야 KSOAP. http://ksoap.enhydra.org/ 에서 보실 수 있습니다.
덧붙이는 말
저에게 책을 번역하고 쓸 수 있게 기회를 열어주시는 데에 결정적 도움을 주신 한 분에게 어제서야 비로서 저녁을 대접하게 되었습니다. 이번에는 일로 만나는 것이 아니니 편안한 이야기를 나눠야겠다고 했건만, 결국 1시간 넘게 책과 업계에 대해 떠들고 말았습니다. 오죽했으면 동석하셨던 사모님께서 "일얘기를 너무 재밌게 한다"고 하셨을까요. -.-;
사람들이 보통 말하는 "뜨고 잘나가는" 일은 아니지만, 아니 오히려 이제는 모두가 기피하는 그런 일이 되어버렸지만, 좋아하고 즐겁다는 것 하나로 해나가는 사람들을 만나면 세상은 혼자가 아니다라는 생각에 밤 바람도 따뜻하게 느껴집니다.
TAG :
최신 콘텐츠