컨퍼런스 마지막 날이다. 오전에 두개, 오후에 두개의 세션이 있지만, 보통 오후에는 오늘 내로 집으로 가려고 하는 많은 참가자들이 미리 떠나기 때문에 사실상 오전에 중요한 세션들이 마무리된다.

첫번째 세션은 JMS in POJO. JMS쪽으로 책도 많이 쓰고, 왕성한 활동을 하는 나이가 지긋하지만 정력이 넘쳐보이는 분의 발표. 내가 딱 좋아하는 스타일의 발표였다. 처음부터 끝까지 라이브 코딩을 해가면서 복잡하고 지저분한 올드스타일의 JMS코드를 스프링의 JMSTemplate와 POJO JMS를 이용해서 5단계의 점진적인 개선을 해나가는 과정을 보여주는 것이었다. 갑자기 덜렁 최선의 소스만 들여대면 사실 그 진가를 알 수 없다. 하지만 점진적인 개선과정을 통해서 그 변화가 주는 의미가 무엇인지 하나씩 설명하면 그 기술이 추구하려는 원칙과 철학이 무엇인지, 장점이 무엇인지 명확하게 느끼게 해줄 수 있다는 장점이 있다.

JMS는 그간 스프링에서 가장 사용하지 않던 기술 중의 하나이다. 좀 더 적극적으로 적용했으면 좋았을 것이라는 후회를 가장 많이 하게 한 기술이기도 하고. POJO기반의 JMS 호출이 가능하다는 것은 이미 지난 컨퍼런스에서 들었지만 역시 시도해보고 있지 않았는데, 이제는 본격적으로 사용해야 하지 않을까 싶다.

데모에서는 OpenJMS라는 아주 단순하고, 깔끔한 JMS구현을 이용했다. JNDI와 JMS구현을 함께 가지고 있고, 설정과 설치 모두 아주 가볍기 때문에 개발 과정에서 사용하기 적합한 듯 하다.

JMSTemplate의 스프링의 Template/Callback 스타일을 JMS코드에 적용한 것이다. 그 것 많으로도 많은 장점이 있긴 하지만, 스프링과 JMS API에 대한 종속까지 깔끔하게 제거하게 만들어주는 것이 POJO방식의 JMS 기능이다. 이 것을 이용하면 더 이상 JMS와의 인터페이스 부분이 노출되지 않는 깔끔한 POJO기반의 로직을 구현해서 JMS를 통해서 그대로 사용할 수 있게 해준다. POJO의 장점인 테스트도 깔끔할테고. 물론 JMS Template을 사용해서 delegate를 하는 방법도 있겠지만, 매번 그 번거로운 호출과 변환작업을 하는 것에 비해서 스프링이 제공하는 깔끔한 설정 하나로 그 모든 것을 처리해주는 기능을 사용하는 것이 당연이 나을 것이다.

스프링이 POJO 프로그래밍 모델을 지원하기 위해서 많이 사용하는 기법 중의 하나가 Reflection과 AOP이다. 자바의 객체지향적 스타일의 언어만으로는 충분하지 않기 때문이다. 그것이 POJO의 적용의 범위를 넓혀주고, 유연성을 주는 것은 사실이지만 이런 메타-프로그래밍 스타일은 그만큼 암시적인 규약과 관례를 따라야 하고, 런타임이 아니면 검증되지 않는 것이 있다는 단점이 있다. 그럼에도 자꾸 애노테이션 사용이 늘고, 리플렉션을 이용한 CoC스타일의 사용방법이 스프링에 늘고 있는 것은 그것 주는 장점이 그만큼 크기 때문일 것이다. 흠.. 그렇다면 결국 TypeSafety를 위해서 JavaConfig으로 가야하나?

 

둘째시간은 Rop Harrop의 Concurrency시간. Spring dm Server를 만들면서 고민했던 concurrency와 관련된 다양한 주제와 내용을 빠르고 정확한 설명과 함께 잘 이야기 해주었다. 사실 나도 직접적으로 concurrency를 고민해서 무엇인가를 만들어 본게 언제인지 잘 기억이 나지 않는다. 로우레벨 기술에서의 해방을 외치는 자바서버환경으로 온 뒤로 더욱 그랬다. 오래전 서버제품 자체의 개발에 몰두할 때 프로세스와 쓰레드, 풀과 각종 락과 씨름하던 때가 언제인지 기억도 가물가물. 자바의 쓰레드 기술이 여타 언어보다 초창기에 빠르게 지원되었던 것은 사실이지만 사실 1.5가 나오기전에는 정말 힘들었던 것이 사실이다. 1.5부터 시작된 JDK차원의 고급 concurrency지원기능은 Rop이 데모를 통해서 보여준 1.7에 이르러서는 이러게 편리해도 될까 싶을 정도로 좋아졌다. 초간단 Spring dm Server를 구현한 코드를 통해서 서버차원에서의 다양한 concurrency기술의 선택 문제와 특징을 보여준 데모도 좋았다. 조만간 블로그에 소스와 함께 공개한다고 하니 기대해봐도 좋을 듯.

 

마지막 컨퍼런스 식사인 점심을 먹고 잠깐 휴식을 취하러 방에 들어왔는데, 누가 침대에 본드를 발라놨는지 -_- 침대에서 몸이 착 달라 붙어 떨어지지가 않았다. 마지막 오후 세션이라 별로 들을만한 주제도 없고 어쩌고 하다가 결국 기선이랑 스르르 잠에 빠져들었다. 어제 해변과 수영장에서 신나게 논 덕분에 얼굴이 빨개져서 귀국하면 컨퍼런스간다고 뻥치고 바캉스 다녀온게 아니냐고 오해받을만하게 변신한 영회가 상기된 얼굴로 나타나, 날씨가 매우 좋으니 다 제끼고 수영하러 나가자고 매달리는 통에 결국 항복. 컨퍼런스 기간 내내 쌀쌀하던 날씨가 드디어 따듯한 플로리다의 날씨로 변해있었다. 결국 컨퍼런스 마지막 날 오후는 수영장에서 둥둥 떠다니며 마무리. -_-

 

이번 컨퍼런스는 지금까지 참석했던 4번의 컨퍼런스 중에 가장 편안한 시간이 아니었나 싶다. 이전엔 아는 사람이 전혀 없이 거의 혼자서 전투하러 온 사람 처럼 매 시간마다 무엇있가 얻어내고, 경험하려고 애쓰고 낑낑 댄 시간들이었다. 물론 그만큼 많은 것을 얻었고, 또 새로운 사람을 만나고 친해지고 지금까지도 연락할 수 있다는 좋은 면도 있지만 사실 컨퍼런스 내내 긴장하고 다니기 때문에 몹시 피곤한 시간이었다. 하지만 이번에는 완전 재밌는 영회,기선,케누형을 비롯해서 다음에서 온 3인방과 SDS분들까지 편안하게 만나고, 심지어 놀 수도 있는 친근한 사람들과 함께 했다는 것이라서 그런지 시간시간 별로 힘들이지 않고 즐겁게 보낸 듯 하다. 시간시간마다 만나서 지난 세션의 감상이나 느낌, 비판 등을 바로바로 편안하게 말할 수도 있다는 것도 좋았다. 저녁엔 다 함께 모여서 함께 식사를 하러가기도. 광남이 형이 슬롯머신에서 한 방에 900크레딧을 딴 덕에 맛있는 아이스크림도 얻어먹고.

 

이번 컨퍼런스의 전체 느낌은 사실 이전보다 좀 딱딱하고 심각해졌다는 것이다. 여전히 가족적인 분위기와 스피커들과의 자유로운 만남, 참석자 상호간의 자유로운 교제는 있었지만, 이전에는 오픈소스 커뮤니티의 모임이라는 뭔가 좀 더 부드럽고 즐거운 만남이었다면 이번엔 스프링소스라는 벤더가 주관하는 행사라는 느낌이 종종 느껴지기도 했다. 중간에 만났던, 여러번 참석했다는 다른 사람들도 비슷한 이야기를 하기도 했다. 언제나 딱딱하고 무표정한 그 얼굴을 가지고 있는 로드 존슨이기는 하지만, 이번에는 수시로 전화를 잡고 심각한 이야기를 하며 다니는 모습에서 이전에 느꼈던 여유와 즐거움은 찾아볼 수가 없었다. VC에 적지 않은 돈을 투자 받고, 회사를 성공시켜야만 하는 큰 부담을 가지게 되었으니 그럴 수 밖에 없을 것이라고 이해해보지만… 이전엔 작은 커뮤니티였고, 약자였고, 돈도 제대로 못 버는 오픈소스 뿐이었지만 그래도 자신의 기술과 철학에 대한 강한 믿음과 그것을 인정해주고 감사하는 전세계의 개발자들과 즐거운 교류를 했던 때가 이제는 슬슬 그리워지기 시작할 것 같다.

 

잔잔하고 파란 대서양 바다를 뒤로 하고 이제 내일부터는 치열한 현장으로 가서 다시 일에 매달려야 한다. 그래도 개발자에게 가장 즐거운 시간은 현장에서 일을 할 때가 아닐까. 이번에 배우고 알게된 기술들을 어떻게 차차 적용시킬지, 또 어떻게 공부해갈지 슬슬 계획을 세워봐야겠다.

둘째 세션부터 실시간 정리를 포기했다. 두번째, 세번째 세션은 정말 잘못 선택했다. 비록 스폰서 세션이지만 평소 관심을 두고 있던 Terracotta와 Dojo이기에 과감히 선택했는데, 정말 성의없는(또는 내가 원하는 방식이 아닌) 발표에 아쉬운 시간이었다. 둘다 사전에 슬라이드를 제공하지 않았던 이유를 좀 생각했어야 하는데 말이다. 그나마 각각 기초적인 개념은 잡을 수 있었지만, 중반 이후로가면서 내용보다는 컨퍼런스 발표나 교육, 세미나 등을 어떻게 준비해야 할 것인가 또는 이런 식으로는 절대하지 말자는 생각만 더 많이 하게 된 듯 하다.

테라코타의 발표는 재작년 유럽 스프링원에서 들은 Coherence와 너무 극명하게 비교되었다. 하나는 오픈소스로 전환해서 간신히 버티고 있는 작은 회사의 발표이고 하나는 결국 오라클에 인수될 정도로 대단한 성공을 거둔 상용제품을 가진 회사의 발표라는 차이가 있긴 하지만, 근본적으로 자신의 제품의 핵심과 특징을 세션의 참석자들에게 명확히 남겨주고 좋은 인상을 줄 수 있느냐 아니라는 면에서 극과 극으로 비교되는 발표시간이었다. 컨퍼런스 세션의 성공여부는 세션 시간이 끝나고 자리를 뜨는 참석자들의 머리 속에 무엇이 남아있고, 어떤 생각을 가지게 하느냐로 평가할 수 밖에 없는 것 같다. 어디 일주일은 야근에 시달려 지친 퀭한 얼굴과 중얼거리는 듯한 어눌한 말투의 소유자이지만 Grails의 Graeme Rocher의 발표는 까탈 대마왕 영회조차 컨퍼런스 내내 "Grails 해야겠다"는 말을 중얼거리게 만들만큼 인상적이었다. 명확하게 전달하고자 하는 메시지 "Grails is Spring!"와 단 한번의 실수도 없이 45분 내내 눈을 사로잡을 만큼 빠르고, 정확하게 진행했던 라이브 개발 데모. 깔끔한 결론 등등이 컨퍼런스 첫 세션이었음에도 지금까지 눈앞에 선하다. 테라코타는? 음..

세번째 세션인 Dojo는 낚시성 제목인 0 to production이라는 말에 넘어가 참석을 했다. 적어도 Ajax나 Widget등으로 유명할 테니 화려한 데모쯤은 기대하고 갔는데, 왠걸.. 요즘 읽고 있는 프레젠테이션젠에서 계속 지적하고 있는 가장 최악의 슬라이드 구조에 지루한 설명이 이어질 뿐이었다. 5분 정도 시간에 한 두페이지면 명확하게 머리속에 넣어줄 수 있는 Dojo의 구성과 각 특징을 슬라이드 당 5~10분의 중얼중얼 설명으로 때문 무성의함 하며, 기선이를 끝나고 계속 만나는 사람마다 "No Demo!!!"라고 하고 다니게 만드는 초간단 데모조차 생략한 점. 그리고 나를 가장 황당하게 만든 마지막 production 부분까지 정말 지루하고 견디기 힘든 시간이었다. 0 to production이라는 타이틀에서 Dojo를 처음 접한 참석자들에게 그 기초와 개념부터 해서 실제 실전에 적용된 사례 내지는 실전전략 정도를 설명해주는가 했는데, 여기서 production이란 Dojo자체의 제작과정에 대한 설명일 뿐이었다 -_-; 테스트를 얼마나 잘하고 있느냐 또는 커멘트를 제거해 사이즈를 최소화 하고 있다 등등…

물론 Dojo자체에 대해서 충분히 관심을 가지게 만들어준 시간이기는 하지만.. 아까웠다. 한시간 반이라는 시간이 말이다.

 

오후에 있었던 풀 파티는 때마침 떨어진 기온과 강한 바람으로 좀 썰렁한 분위기였다. 게다가 밤에 좀 춥게 잤는지 몸이 좀 으슬으슬하고 추위가 느껴져 얼른 숙소로 올라가려고 했는데, 수영에 한이 맺힌 영회와 30대 후반이지만 탄탄한 몸매를 유지하고 있는 점을 드러내고 싶었던 광남이 형은 얼른 수영복으로 갈아입고 수영장으로 뛰어들었다. 힘없는 기선이도 함께 끌려들어갔고. 덕분에 나만 밖에서 추위에 떨며, 그 넓은 수영장에 아저씨 셋이 헤부작 거리는 것을 하염없이 지켜봐야 했다. 스프링원 참석자 500여명, 그리고 기타 컨퍼런스와 휴양차 온 수백명의 투숙객 중 그날 유일하게 수영하는 사람이 저 세 사람이었으니, 거기에 지나다닌 많은 사람들에게 아주 강한 인상을 남기지 않았을까 싶다.

 

아침에 새벽 3시에 깬 덕분에 자꾸 피곤이 몰려오는 것을 간신히 참고 저녁식사전 간단히 BoF시간에 참석하고, 저녁을 먹은 뒤, 드디어 기다리던 Adrian Colyer의 테크니컬 키노트에 참석했다. 항상 나를 즐겁고 흥분하게 만들어주었던 Adrian의 발표인지라 영회를 잡아끌고 제일 앞쪽에 자리도 잡았다. 스프링소스의 대표개그맨인 Rop Harrop과 함께 살짝 썰렁하긴 했지만 재밌는 간단한 코믹극을 하나 하고 키노트 시작. 보통 키노트 하면 먼저 이런 저런 기술적인 소개와 배경을 설명한 뒤 마지막에 데모를 보여주며 마무리 하는 것이 일반적인데, 이번 키노트는 특이하게 바로 데모로 들어갔다. 바로 스프링 인테그레이션. Cafe에서 주문을 받아 처리하고, 여러 단계와 채널을 통해 그것이 처리되는 것을 POJO와 간단한 설정만으로 동작하게 만드는 스프링 인테그레이션의 데모였다. 이어서 진행한 것은 Grails. 거의 모든 코드를 직접 라이브로 작성했는데, 사실 Adrian은 Grails를 이제 막 시작한 초보자라고 했다. 첫날 Grails 세션에 뒤에 앉아서 열심히 듣는 모습이  기억났다. Grails의 특징을 간결하게 잘 보여주는 간단한 주문용 웹 화면을 만들더니, Grails가 바로 스프링이라는 점을 강조하기 위해서 바로 앞에서 만들었던 스프링 인테그레이션의 모듈을 그대로 Grails로 만든 프로젝트에 카피하더니 코드에 간단히 DI해서 Grails의 service에서 Spring Integration으로 구현한 모듈을 간단히 호출해 버리느 것이 아니겠는가. Grails에 마음을 뺐겨버린 영회가 옆에서 눈이 둥그레져서 열심히 감상. 수영을 무리하게 한 탓에 피곤하다고 징징 거리던 것은 사라지고, 빨려들어갈 것 처럼 데모를 지켜보는 모습이었다. 마지막 마무리는 그렇게 만든 grails web app + spring integration module을 한방에 war로 만들어 Spring dm Server에 실시간 배치하는 것. 안타깝게도 여기서 살짝 오류가 났는데 메시지를 보니, 준비하면서 미리 배포해놓았던 것을 클리어하지 않아서 그랬던 것 같다.

아무튼 화끈한 데모로 시작된 키노트는 몇가지 새로운 뉴스를 던져주며 계속 진행되었다. Spring MVC, SWF, Face, js에 이어서 스프링의 웹 기술에 포함되는 5번째 것은 바로 Spring Flex이다. 컥! 

이미 Adobe랑 파트너쉽을 가지고 오픈소스와 커머셜 양쪽으로 제품이 개발되고 있다. 스프링으로 즐기는 Flex의 시대가 조만간 올지도 모르겠다.

또 하나 흥미로운 것은 VMWare와의 파트너쉽. 1월쯤에 정식 발표될 것이라고 하는데, 스프링이 tc server 등의 플랫폼과 서버군을 가지게 되었기 때문에 이제 배포환경에 대한 부분에도 집중을 하려는 듯 하게 보였다. 언젠가 DELL에서 Spring tc+dm server기반의 virtual server가 장착된 서버머신을 바로 구매할 날이 올지도 모르겠다.

이어서 dm서버의 미래에 대해서 Rop Harrop의 긴 이야기가 이어졌고, Adrian의 "엔터프라이즈 개발의 기술과 그 기반 지형이 바뀌고 있다. 하지만 스프링은 그 변화를 앞서 나가서 더욱 편하고 막강한 기능을 가지고 개발이 가능하도록 많은 것을 준비했고, 앞으로 공개할 것이다"라는 살짝은 뻔한 결론으로 마무리. 하지만 최근 일어나는 변화들을 볼때 그가 지적한 엔터프라이즈 클래스의 개발과 관련된 지형의 변화는 그저 상투적인 말은 결코 아닐 것이라는 느낌이 팍팍. 옆에서 기선이는 "공부할게 너무 많아.. 어쩌나…"라고 계속 비명을.

이제 마지막 날이다. 아침 먹으러 가야 하니 여기서 일단 마무리.

기선이는 기어코 프로페셔널 스프링 책에 나온 저자들에게 일일히 싸인을 다 받아냈다. Alef만 빼고 다 받았으니 참 대단한 수확이다. 아무도 하지 않는 특이한 포즈의 사진촬영과 질문공세, 싸인요청까지 눈도장도 확실히 찍어두었으니 아마 오래 오래 기억될 듯.

어제 12시쯤에 잠들었는데 3시에 그만 깨고 말았다. 다시 잠들려는 찰라에 부스럭 거리면서 일어나 돌아다니는 기선이 때문에 다시 잠들기회를 놓쳤다. 이런! 잠은 안오고 멀뚱히 있기 뭐해서 이런 저런 일을 하다가 결국 심심해서 4시에 광남이 형과 영회를 깨워서 불러서 함께 놀기 시작했다. 셋째날은 이렇게 일찍 시작 되었다.

모이면 맨날 하는 얘기.. 광남이 형의 OKJSP를 OKSpring으로 바꾸거나, OK Java SPring으로 바꾸자는 것. 이번 기회에 완벽한 스프링빠로 만들어야 할텐데… 만나는 외국 스프링 개발자들마다 OKJSP 사이트를 홍보하며 "JSP 걱정없다 OK!"를 외치는 형의 모습을 보니 OKJSP가 어떻게 한국최고의 자바 커뮤니티로 성장했는지를 알 수 있을 것 같다.

 

일어난지 5시간 만에 아침을 듬뿍 먹고 이제 셋째날 첫째 세션 실시간 포스팅 시작.

JavaConfig은 꽤 오랜동안 milestone 상태로 머물러있는 프로젝트였다. 3.0에는 core에 병합이 된다고 하니 기대할만하다.

  • JavaConfig은 <bean/> 을 @Bean으로 대체하자는 것.
  • Type-safety를 원하고, pure Java(refactorable)로 작업하는 것을 선호한다면 JavaConfig
  • DI container의 full power를 제공한다.

IDE와 XML namespace 등의 도움으로 spring xml config.은 상당히 편해졌다.  하지만 몇가지 문제를 남겼는데..

  • String 기반이라는 문제가 그 대표적인 것이다. String은 리팩토링에 적합하지 않다.
  • XML에서 가져오는 getBean()은 casting의 부담도 있다.

JavaConfig은 Java5+의 장점을 최대한 활용할 수 있고, string에서 벗어나게 해준다. (Generics, @nnotations)

  • <bean ..class="ClassName"> ===> @Bean ClassName method() {…}
  • <bean/>은 @bean에 그대로 매핑될 수 있다.
  • <beans />는 @Configuration으로 대체가능하다. 오호!
    • beans는 class레벨로, bean은 method레벨로 정의할 수 있다.
    • method의 이름이 bean id가 된다.

Bootstrap : JavaConfigApplicationContext

@Configuration

public class AppConfig {

  public @Bean FooService fooService() {

    return new FooService();

}

각종 annotation, component scan, aspect 설정들을 모두 JavaConfig을 통해서 처리하는 것이 가능하다.

XML을 JavaConfig으로 import 할 수도 있다. 점진적으로 JavaConfig으로 변환도 가능하다.

JavaConfig과 XML은 거의 완벽하게 상호변환이 가능하다. JavaConfig이 더 type-safe 하다는 것만 빼고.

앞으로 자체 namespace 지원기능도 추가될 예정이다.

 

여러개의 @Configuration 클래스에 @Bean이 나뉘어 있고, 상호참조를 한다면? 이때는 JavaConfig 자체에 @DI를 적용할 수 있다. 즉 @Autowired로 다른 @Bean설정을 DI해서 사용하는 것이 가능하다. DI의 DI로구만.

이렇게 설정한 JavaConfig은 거의 완벽하게 refactorable하다. 또 IDE를 통해서 navigation하는 것이 매우 편리하다.

@Import를 사용하면 import되는 클래스에는 @Configuration등의 설정이 필요없고, import시키는 쪽 클래스의 설정에 따르게 된다. XML의 import와 개념이 비슷하다.

 

WebApp은 어떻게?

일반적인 접근방법은 web.xml에 listener로 ContextLoaderListener를 정의해서 xml을 로딩한다.

ContextConfig에 옵션을 하나주어서 xml 대신 JavaConfig class를 사용하도록 재정의할 수 있다.

 

JavaConfig의 장점은 xml 작성보다는 IDE의 편리한 지원을 받아 자바코드를 작성하는 것이 더 편리하고 직관적이라는 것이다. 당연히 type-safe하며, 리팩토링이 완벽하게 지원된다는 것이 가장 큰 장점. 또한 DI나 각종 빈의 생성도 자바코드로 원하는 대로 유연하게 작성할 수 있다는 장점도 있다. 또 설정을 모듈화 하기도 편리하고.

단점으로는 아무래도 설정이 많아지면 자바코드가 많아지고 xml보다는 가독성이 좀 떨어질 것이다. 하지만 @autowired, @component 스타일의 스캔을 사용한다면 또 설정자체가 많지 않으니 별 문제가 되지 않을 수도.

이제 본격적으로 xml, annotation, java 세가지 방식의 스프링 설정이 경쟁적으로 사용되어질 때가 된듯 하다. 스프링소스에서 공개한 것은 아니지만, ruby로 설정하는 것도 있다고 하니.. 스프링설정의 유연함은 점점 더 늘어간다. 하지만 best practice와 선택의 고민이라는 문제를 던져주기도 한다. 행복한 고민일 듯.

 

PetClinic을 JavaConfig으로 변환하는 데모를 끝내고 이제 roadmap.

M5가 거의 Spring3.0과 비슷하게 등장. Spring3.0에 JavaConfig의 core가 삽입. Spring 3.0 릴리즈 직후에 1.0GA 릴리즈 목표다. 언제나 목표는 목표, 계획은 계획이니깐. 어쨌든 Spring3.0에 삽입된다는 것이 가장 중요한 결정인듯. 근데 core만 들어간다고 하는데 core가 아닌 것들은 어떻게 구분되는 것일까?

실시간 포스팅 두번째. 배터리가 다 되서 오후에는 더 이상 못하겠지만.

Ben Alex의 두번째 세션. 좁은 장소인데 상당히 많은 사람들이 찾아서 자리가 모자라 의자를 가지고 들어와서 들을만큼 인기가 대단하다. 참석자의 2/3정도는 SpringSecurity를 사용할 정도로 이미 많이 보급된 듯 하다.

2.5의 새로운 기능의 소개보다는 2.0의 전반적인 소개가 대부분인듯 하다.

 

핵심 기능 세가지는 Authentication, URL authorization, Method nocation authorization이다. 권한부여 부분이 2가지로 구분되는 것이 특징. 그 밖에 Channel, ACLs, WSS(SWS), Flow Auth(SWF). 등이 지원된다. 어제 Keynote에 사용된 데모에서 SWF+SpringSecurity가 적용되었다.

다양한 인증기술과 제품과 결합한다. NTML도 지원한다. 각종 SSO RFC1945,2617, JSR250, Grails, Mule, DWR, … 등등등. Spring Python과 .NET에도 포팅되었다고.

WebApp뿐 아니라, batch, Swing, Flex, GWT, Int. Test, .Net Remoting에서도 사용될 수 있다.

간단한 web app용 security도 제대로 적용하려면 고려해야 할 것이 매우 많다. 그것을 직접 다 구현하는 것은 결코 좋은 방법이 아니다. 또는 적지 않은 부분을 놓칠 수  있다.

 

1. Filter

DelegatingFilterProxy -> request를 FilterChain으로 매핑.

FilterChain은 BeanID를 가지고 있다. Legacy style(1.x)의 확장을 위해서는 BeanIds 클래스에 정의된 id이름을 확인할 것.

2. Authentication choices

Form, Basic LDAP, NTLM, Container, JAAS,… 등등등. 입맛에 맞게 골라 쓰며 된다.

Basic Authentication 권장 – 매우 간단하기 때문에 폭 넓게 적용가능하고, 리모팅 프로토콜을 이용할 수 있다. 단, 암호화가 안되어있으므로 HTTPS를 사용할 것! Spring의 Remoting에 결합되어져서 바로 사용할 수 있다. 기본적으로 인증방법을 설정하지 않으면 B.A가 사용된다. B.A 인증을 테스트 할 때 wget을 사용해서 간단히 console에서 테스트 가능(데모에 적용..)

3. Repository

인증된 사용자의 부가적인 정보를 제공.

JDBC repository – DB. <jdbc-user-details data-source-ref="xxxx" />로 기본 schema에서 정보를 가져올 수 있다. 초간단.

UserDetailService를 확장해서 custom repository를 만들 수 있다. 맨날 하던 작업..

 

쉬어가는 사진. 옆자리에서 열심히 강의를 듣고 있는 영회 한 컷.

사진 003

 

기타 고려사항.

  • HTTP만 가능하다면 digest를 고려할 것. cross-site request forgery issue를 고려할 것.
    • Request forgery 문제에 대한 가장 간단한 해결책은 중요한 정보변경등에 GET을 사용하지 말 것.
  • Database driven remember-me token을 쓰면 여러 시스템에 걸쳐서 remember-me의 적용이 간단해진다.
  • hashing password할 때 salt를 사용할 것.
  • Data-binding config. 방식을 잘 이해할 것.
  • HDIV프로젝트를 살펴보자

4. Web Authroization

<intercept-url>의 설정을 변경해서 사용.

고급 사용자라면 db에서 실시간으로 attrib.을 가져와 적용할 수 있다.

<intercept-url>은 top-down으로 적용된다. 따라서 specific. pattern을 꼭 위에 둘 것. 결국 URL은 아래로 갈 수록 간단해진다.

5. Method Authorization

가장 강력하고, 유연한 방법. Ben’s favorite.

가장 reusable하다. SpringAOP, AspectJ에 모두 적용가능.

Around advice type을 이용해서 적용되었다.

Method metadata – Annotations, XML, AspectJ Pointcut 또 SpringEL (3.0) 방식의 annotation도 사용가능.

@JSR250 – official standard annotation 또는 SS@Secured를 사용할 수 있다.

<global-method-security xxx="true" /> 라고 설정하면 된다.

Instance-based XML을 사용할 수 있다. 즉, bean 단위에 intercept-method 설정이 가능하다는 뜻. 여러개의 인스턴스를 각각 빈으로 만드는 경우 유용할 수 있겠다.

AspectJ pointcut을 이용하면 class-based로 설정할 수 있다.

6. Security 2.5 expression language

hasRole, hasAnyRole, hasPermission, isAnony.., isRemberMe… 등의 다양한 표현식을 가질 수 있다.

 

web이 아니면 method auth를. @JSR25으로 시작하고, 필요에 따라 EL을 적용. type-level 설정이 적당하지 않으면 instance-based xml 설정을 적용한다. 특별한 경우가 아니라면 @Secured나 protect-pointcut은 배제.

Spring 2.5의 가장 큰 변화는 EL의 적용으로 세밀한 annotation방식의 method auth.가 가능해졌다는 것이다.

EL을 이용해서 상당히 복잡한 조건 권한설정도 적용하는 것이 가능하다는 것이 Spring2.5의 가장 큰 매력. 물론 Spring3.0과 함께 사용해야 하겠지만 말이다. SpringSecurity에 적용되는 것을 보니 Spring3.0 EL의 활용방법이 매우 다양할 수 있겠다는 생각이 든다.

이제 점심 먹어야지.

Grails is Spring – Key Message.

자바와의 호환(같은 class로 컴파일)등이 장점. 당연히 Spring 2.5의 최신기능을 다 사용할 수 있다.

Plugin을 활용한 확장기능 – ex) Flex

G2One이 스프링소스에 인수되었기 때문에 이제 Groovy,Grails의 적용에 대해서 기업이 스프링소스의 지원을 받을 수 있다. 

2005년 여름 시작, 2008년 초 1.0 릴리즈. 70,000 downloads/mth. 최근 일년간 크게 인기 상승. 프로덕션 사이트에서 사용할 만큼 안정이 되었다는 뜻.

Grails의 철학

  • 이미 있는 성공한 기술을 적극 활용
  • CoC
  • Sensible Defaults

Grails는 SpringMVC의 고레벨의 추상화된 모델. 또한 Spring/Hibernate의 추상화. 스프링의 설정을 자동으로 생성&관리. 어떤 WAS에도 설치 가능.

 

SpringMVC/Grailsㅇ dispatch sequence는 똑같다. Grails View Resolver, Grails Controller…

Spring의 ViewResolver, View, DispatcherServlet, i18n, Multipart… 등을 그대로 사용.

 

GORM – Hibernate스타일의 ORM. – Grails Console을 이용해서 간단히 테스트 해볼 수 있다. (RoR Console과 비슷)

Dyamic Finder. Criteria. Cache. Lock Strategy 등 지원. – 거의 Hibernate의 기능을 최대한 활용하는 듯.

 

GSP(View)를 사용할 때 groovy로 만든 간단한 custom tag를 쉽게 적용할 수 있다.

 

Plugins – conventions, register bean def 등의 다양한 기능을 추가해서 사용할 수 있다. GrailsApp과 ApplicationContext 양쪽에 적용가능. 플러긴을 이용해서 런타임 중에 스프링의 특정 부분에 대한 설정을 추가할 수 있다.

 

데모 Twitter 만들기

Acegi plugin을 설치하면 기본 인증과 관련된 코드가 자동생성된다. Principal Info를 Acegi를 통해서 간단히 가져아서 사용 가능(PrincipalInfo.username). Domain Model에 constraint를 같이 설정할 수 있다. RoR비슷. <g:formRemote .. > – Ajax Form 기능을 간단히 만들 수 있다.

Searchable plugin을 설치하면 검색-목록 스타일의 기능을 간단히 만들 수 있다. 초간단.

스프링의 어떤 설정이라도 추가할 수 있다. (ex. Cache bean 등록후 GORM find metod에서 사용하기)

ActiveMQ plugin을 이용해서 JMS – Message Driven POJO 개발도 가능(JmsTemplate을 바로 사용가능). 스프링에서 되는 것중 안되는 것이 없다. 오호.

REST style의 publishing 기능. (withFormat { .. html, xml, rss …}) – feed plugin 이용해서 rss등의 포맷지원.

Quartz plugin – Job개발을 간단하게.

Mail plugin – def mailService라고 추가만 하면 바로 메일 전송기능 바로 이용가능.

 

정리

Grails is not just a web framework, Grails is  a platform!

왠만한 유명한 것은 plugin으로 다 되어있다.

  • Test : seleium, fitnesse, code coverage.
  • UI : Flex, GWT, GrailsUI(YahooUI)
  • Security: SpringSecureity, JSecurity, OPenID.
  • 기타 등등

 

Grails 1.1 – maven support, testing framework의 내장, Scaffolding, Better plugins & GORM. 현재 베타.

Groovy&Grails – 12권의 책이 벌써 나와있다.

 

데모와 다양한 플러그인을 보니 매우 인상적이다. 이전에 스프링을 단지 백그라운드에 사용했다고 느꼈던 것과 달리, 스프링과 거의 자연스럽게 융합되어있는 듯한 인상이다. 스프링 개발자라면 손 쉽게 기능을 활용할 수 있다는 것이 제일 큰 장점이다. 모든 복잡한 로우레벨의 프레임워크를 직접 구현하지 않고, 이용한 것이 성공의 비결이다. 스프링소스의 본격적인 지원에 힘입어서 조만간 큰 인기를 끌 수도 있지 않을까 기대가 된다. JVM과 그 위에서 동작하는 안정적인 엔터프라이즈 프레임워크의 신뢰도 덕분에 도입이 많아질 수도 있을 듯.

RoR로 개발되어서 성능으로 최근 고전하고 있다는 Twitter가 만약 Grails로 되어있다면 어쟀을까 궁금해진다.

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha