'개발 지식 공유하기'에 해당되는 글 101건
- 2010/10/14 폴리텍 대학 스프링 강좌 7차 강의 (1)
- 2010/07/05 Shallow eTag의 정확한 의미
- 2010/07/02 전자정부 FW 실행환경 기능 분석 리스트
- 2010/07/02 REST 표준 수립 시 고민해야 할 문제들
- 2010/05/20 SpringSource(VMWare)와 Google의 클라우드 전략
- 2010/05/07 클라우드 환경에 적응하고 있는 스프링
- 2010/03/26 갑자기 Ant task를 실행했는데 콘솔에 아무런 메세지가 안 나올 때는 이렇게 하세요!
- 2009/12/18 Java Persistence with Hibernate 베타 리더 모집 현황 (7)
- 2009/12/17 Java Persistence With Hibernate 한글판 베타 리더 모집합니다. (2)
- 2009/11/24 Eagerly 번역 용어 생각해보기 - 의견 수렴하기 (8)
일곱 번째 강의 입니다.
이제는 폴리텍 대학 홈페이지를 통해서만 접수 받습니다.
홈페이지에 방문하셔서 서류 작성 후 팩스로 보내면 바로 접수 됩니다.
자세한 내용은 폴리텍 대학 담당자 번호인 02-6300-6300 로 연락하시면 됩니다.
[접수하러 가기]
그럼 즐거운 하루 되세요.
저도 처음에는 오해를 했던 것 중의 하나가 shallow eTag의 정확한 의미입니다.
Spring에서는 shallow etag 방식으로 구현한 ShallowEtagHeaderFilter 필터가 존재합니다.
최초에는 "아..여기서 갱신 여부를 비교해 변경된 내용이 없다고 하면 캐싱해둔 뷰 내용을 다시 내리니 다시 응답(resposne body)를 처리할 필요가 없겠구나"라고 생각했는 데 실제로는 그런 의미가 아니었습니다..
일단 이 필터에서는 변경 여부를 비교 하는데 여기서는 해당 요청에서 생성된 응답(response body)를 기준으로 해시 값을 구합니다. 그러므로 이미 뷰 처리가 된 것이지요.. 요청 헤더의 'If-Non-Match'의 해시 값과 이번 요청의 해시 값을 비교하게 됩니다.
비교해서 값이 같다면(즉, 변경이 없었다면) response body의 컨텐츠가 없음으로 표시하고(response.setContentLength(0)), 응답 상태를 변경 없음으로 해서(response.setStatus(HttpServletResponse.SC_NOT_MODIFIED))해서 내립니다.
결론적으로 뷰를 다시 렌더링하는 데 들어가는 비용이 아닌 클라이언트와 서버 간의 데이터 전송양(bandwidth)를 줄이는 역할을 해줍니다.
응답이 단지 변화가 없다라고 나오기 때문에 이 응답을 받아서 동작하는 방식은 역시나 클라이언트에서 결정해야 합니다.
그리고 클라이언트는 etag 헤더 값의 경우에도 클라이언트에서 비교 대상이 되는 헤더 값을 알고 있다가 서버로 요청 시에 'If-Non-Match' 헤더로 보내줘야 하는 불편함(?)이 있습니다. 이를 해결하려면 shallow eTag가 아닌 deep eTag 방식으로 서버에서 알고 있는 방법을 사용할 수도 있습니다. 아니면 Last-Modified:와 같은 헤더 값을 활용하는 방법을 제안하는 사람도 있네요.(Last Modified를 활용할 때는 구현 방식이 조금 달라질수도 있겠네요..)
eTag에 대해 정리하면서도 역시나 기존의 웹 시스템의 구현이나 구성 방식의 경험을 기준으로 생각하면 안 된다는 것을 다시 한 번 느꼈습니다.
일전에 전자정부 FW 실행환경 소스를 쭈욱 살펴보다가 개인적으로 정리했던 자료 입니다.
강의때도 그렇고 근래 들어 전자정부 FW에 대해 질문 주시는 분들이 가끔 계시는데 혹시나 살펴보시는 데 도움이 되실까 해서 올립니다.
제가 살펴보면서 참고할 목적으로 정리되어 있기 때문에 내용 자체보다는 전체적인 구성이나 기본적으로 제공하는 기능 정도를 살펴보는 정도로 참고하시면 됩니다.
레퍼런스나 참고 문서들이 있으나 대부분 스프링이나 관련 오픈소스를 기반으로 설명을 하고 있기 때문에 실제로 전자정부 FW에서만 제공하는 기능을 보기에는 혼란(?)스러운 면이 있습니다. 그래서 순수하게 전자정부 FW 고유의 기능만 클래스 수준으로 정리해봤습니다. (물론 표준을 제시하고 가이드 하는 것 자체도 의미가 있습니다).
전자정부 FW 자체에 대한 가치를 논하기는 사실 어렵지만, 전자정부 FW가 있음으로 프로젝트에서 올바른 기술 구조를 선택하고 적용할 최소한의 기회의 기반이 된다는 측면에서는 확실히 가치가 있다고 생각합니다. 물론 다른 여러 분야(자체적인 기능, 기술 지원 등)는 차차 좋아지겠죠^^
사실 전자 정부 FW는 (아직까지는) 실행 환경을 통한 다양한 기능 지원보다는 환경적인 측면이나 공통 기능 지원에서 더 큰 장점을 가지고 있다고 볼 수 있습니다. 사실 아직까지는 실행 환경 자체를 활용해서 얻는 메리트는 그렇게 크지는 않다고 생각합니다.(앞으로 개선되겠지만요..) 연계 통합 레이어에 메타 수준의 관리 기능부터 많은 클래스들이 개발되어 있지만, 실제로 활용되는 건지는 모르겠습니다..(역시 사이트 별로 다르겠지만 실제로 경험해신 분들에게 확인해봐야겠지요..)
이번에 정리한 건 기능 분석의 관점이었고, 실제 적용의 관점에서는 다시 한 번 정리해봐야겠습니다.
틀린 내용이 있다면 피드백 주세요.
전자정부FW_실행환경기능분석.xlsx
오랜만에 자리에 앉아 차분히 블로깅을 하네요^^;
조만간 REST 표준 수립에 관련된 일을 하게되어 잠시 REST에 대해서 서베이를 좀 해봤습니다..
사실 'RESTful'이라는 용어에 대해 이해하기가 쉽지가 않습니다.
글세요.. 역시나 보는 사람에 따라 다양한 방식으로 정의할 수 있겠지만 제가 생각하기에 핵심은
"기존의 '요청(Request) 중심'의 사고 방식에서 '자원(Resource) 중심'의 사고 방식으로 변환"
이라고 생각합니다.
여기에 더해서 이러한 사고 방식의 변화에 따라 엔드 포인트와 뒷 단의 서비스를 구현 하는 방식도 중요하겠지요.
실제 표준 수립 시에는 이러한 '자원 중심'의 관점에 입각하여 REST의 주요 세 가지 구성 요소인 "Resource, Action, Message"의 표준을 수립하는 게 중요할 것으로 생각합니다.
Resource의 경우 자원에 유일성(Identity)을 부여해야 하는 데 이게 말처럼 쉽지가 않습니다.
기존에는 다양한 파라미터와 조건에 따라 컴포넌트가 다양한 형태의 결과를 조합해서 서비스를 제공하면 됐는데, REST의 경우 이렇게 구성하면 자원을 기준으로 유일성을 부여하기가 어렵게 됩니다. REST가 아키텍처 스타일이기 때문에 REST 구성시 단순히 엔드포인트(컨트롤러) 수준에서의 표준이 아닌 뒷단의 서비스 컴포넌트(서비스나 DAO 등) 수준에서의 설계와 구현 입장에서도 REST에 적합한 구현 스타일을 가져가야 합니다.
Action의 경우에는 역시나 다양한 HTTP Method의 정확한 의미를 규명하는게 우선시 됩니다. 다양한 자료에서 HTTP Method에 따라 의미를 정의하고 활용하는 방식을 설명하고 있는 데, 정리해보니 조금씩 다르기도 하고 보는 관점에 따라 해석이 다르기도 합니다. 물론 일반적으로 이해되는 방식을 준수하면서 시스템을 구현하는 요건에 맞게 재정의할 필요는 있어 보입니다. 더군다나 기본적으로 사용할 수 있는 HTTP Method로는 자연스럽게 의미가 일치하지 않는 요건을 구현할 때가 더 문제입니다. 메서드들에 대한 의미를 일반화하거나 별도의 메서드를 수립하는 등의 방법을 좀 생각해봐야 겠습니다.
Message의 경우에는 스키마 구성을 잘 고민해야 할 것 같은데, 이 문제는 대상 조직이나 시스템의 표준을 기준으로 할 수도 있으니 구현은 복잡하겠지만 고민거리는 상대적으로 적은 부분입니다. 그래도 hypermedia와 같은 REST의 속성을 적용하는 부분은 고민해야 되니 역시나 쉽지는 않네요.. 그리고 역시나 대규모 시스템에 적용할 때의 비기능 요건도 고려해야 하니 오히려 기존의 가지고 있는 구조와 REST 표준 간의 연계성이나 대체 방식을 고민하는 게 문제일 것 같습니다.
사실 하다보니 이 세가지 기준 외에도 고려하고, 생각해봐야 할 내용이 더 많습니다.
저도 처음에 프로토타이핑하면서 삽집을 많이 했는데 데이터와 페이지 네비게이션 등의 처리와 같은 요청에 대한 응답을 위주로 구현하는 컨트롤러 방식에서 해당 자원에 대한 다양한 서비스를 노출해야 하는 방식으로 구현하려니 먼가 어색하고, 기존 개발 방식으로는 처리하지 못하는(하면 안 되는) 부분이 발생하기 시작했습니다.
일례로 컨트롤러 메서드의 인자와 반환 타입이 웹 파라미터나 HTTP Request의 속성이 아니라 모두 Request/Response의 Body로 처리해야 합니다. 그래서 스프링의 경우 별도의 애노테이션(@RequestBody, @ResponseBody)을 이용해 이를 표시(markup) 해주도록 하고 있습니다. 더군다나 페이지 네비게이션에 대한 내용은 이제 컨트롤러에는 전혀 등장하면 안 되는 친구가 되버렸습니다.
REST의 단점 중 하나로는 주고 받는 데이터 형식 등에 대한 표준 기술과 같은 기준이 없기 때문에 자체적으로 표준 수립 시 클라이언트 단의 공통 기능, 또는 매핑 원칙을 제공해야 합니다. XML이나 JSON 같은 데이터 형식에 대한 가이드가 필요합니다.
또 가장 고민되는 부분 중의 하나는 상태(state)에 관련된 내용인데, REST의 경우 자원에 대한 요청 간에 의존성이 없어야 하기 때문에 서버에서의 상태 유지를 하면 안 됩니다. 그러나 기존의 시스템 구현 시 서버의 상태를 가지고 제공하는 다양한 서비스나 기능들이 있는데 이를 어떻게 구현하고, 적용해야 하는지가 가장 고민입니다.
Spring @MVC와 JAX-RS도 비교해 봤는데 이 부분은 사실 그렇게 크게 문제가 되지 않을 것 같습니다. 기능 목록 상에서는 거의 동일하기 때문에 선택의 문제가 됩니다. 다만 기존 시스템의 기반 기술이나 프로그래밍 모델을 고려하면 될 것 같습니다. REST와 비REST(일반 웹)의 구현이 상호 보완적으로 구성할 수 있는 경우에는 확실히 스프링 쪽이 유리하겠죠.
티스토리가 확실히 표 기능이 약해 비교 표를 올리기 조금 어려운데 둘 간의 매핑 정보만 간단히 정리해보면 다음과 같습니다.
Spring @MVC : JAX-RS
@RequestMapping : @Path
@PathVariable : @PathParam
@RequestMapping(method=RequestMethod.*) : @GET, @POST, @PUT, @DELETE, @HEAD
@RequestParam : @QueryParam
@CookieParam : @CooikeValue
@RequestHeader : @HeaderParam
HttpMessageConveter(또는 Conversion, Formatter) : MessageBodyReader
HttpMessageConverter(또는 View) : MessageBodyWriter
@ResponseStatus : Response.*()
물론 REST 관점에서 시스템의 전체적인 아키텍처 스타일에 대한 고민도 해봐야 하는데 이런 고민은 조금 더 넓은 시야를 가지고 생각해봐야 하기 때문에 차후에 한 번 해보도록 하겠습니다..
일단 제가 몇 일간 고민하던 내용 중 일부를 정리해 봤는데요, 이런 문제에 대해 답을 내면서 공유할 내용들이 생기면 다시 한 번 다루도록 하겠습니다.
요약해보자면,
- STS+Spring ROO를 통해 생산성(Productivity) 향상
- Spring 기반이므로 다양한 클라우드 플랫폼에 배포 가능한 이식성(Portability) 확보 -> Open PaaS
- Spring Insight=> Server Profiling + Gogole Speed Tracer=> Client Profiling
STS+GPE 버전이 벌써 배포되었습니다. 다운로드 페이지에 들어가면 "Spring ROO를 통해 프로젝트 생성 -> 바로 GAE 배포 시나리오"에 대한 간단한 설명과 STS을 받을 수 있가 있습니다.
자세한 내용은 각 항목의 링크를 참조해주세요.
서비스(또는 클래스) 수준의 추상화를 통해 PSA를 주창한 스프링이 이제는 플랫폼 수준의 투명한 서비스 제공으로 발전해나가고 있습니다.
모 회사와의 전략적 방향을 잘 세워 빠르게 진행하고 있는 것 같습니다.
익숙한 개발 환경이 클라우드까지 확장됐다는 것에 반가운 마음이 우선 듭니다.
이런 생각은 저만 하는 것은 아닐테고 스프링 커뮤니티에서 환영할 만한 일임에 분명합니다.
스프링 개발자에게 접근하기 쉬운 환경이 될테니까요..
물론 화면에서 보는 것처럼 적용하기가 간단하지는 않겠지만, 일단 시도해볼 수 있는 판(?)이 만들어지는 것에 의미를 둘 수 있을 것 같습니다.
ps. 그럼 CloudFactory.com의 존재는 어떻게 되는건지?
가끔 이런 일이 있습니다.. import한 프로젝트거나 이클립스를 업그레이드 했거나, 때로는 따로 변경한게 없는 것 같은데 갑자기 태스크를 실행해도 이상하게 콘솔에 아무런 메세지가 나오지 않을 때가 있습니다.
저는 주로 이클립스를 업그레이드 했을 때와 Ant(+ivy, grand등) 라이브러리 업데이트 시에 겪었었는데요..
해결책은 간단합니다. 실행하는 앤트 태스크가 돌아가서,
JVM을 웍스페이스에서 사용하는 JVM과 동일한 JVM으로 맞춰주시면 됩니다.
베타리딩 부탁 하는 글을 올렸었는데 현재 총 두 분께서 지원해주셨습니다^^
그래서 현재 총 4분의 베타리더가 모집되었습니다.
안영회님
최한수님
토비님
김상준님
남종환님
성종천님
남한산님
다음 주까지 계속 모집하도록 하겠습니다^^.
그래서 현재 총 4분의 베타리더가 모집되었습니다.
안영회님
최한수님
토비님
김상준님
남종환님
성종천님
남한산님
다음 주까지 계속 모집하도록 하겠습니다^^.
저를 포함 세 분이 공역중인 Java Persistence With Hibernate의 베타리더를 모집합니다.
전체 부분은 아니고 제가 맡은 부분에 대한 베타리더 입니다^^.
중간에 여러 일들이 있어서 1년이나 걸리게 됐습니다.
아직 마무리할 내용도 많지만, 고생한 만큼 애정이 어릴 수 밖에 없습니다.
제가 맡은 부분은 책 후반부로 9~15장입니다.
객체 제어, 컨버세이션, HQL, Criteria 등에 대한 내용을 다루고 있습니다.
관심 있고 성심으로 결과물을 함께 검토하고 의견주실 분을 찾습니다.
현재는 안영회님과 최한수님께서 베타리더로 지원(^^?) 해주셨습니다.
아, 여기에 전수 검토를 언제나 완벽히 해주시는 공역자이신 이대엽님도 계시구요^^.
관련 서적도 거의 전무하고, 공감대가 형성된 한글 용어가 없기 때문에 걱정이 많이 되는 것도 사실입니다.
그러니 많은 분들이 보시고 공유하고 의견을 개진해주셨으면 좋겠네요.
베타리딩 시작은 빨라야 다음주 중이나, 아마도 다다음주 초가 될듯 합니다.
관심있는 분들께서는 댓글이나 메일(chanwook.god@지메일)로 연락주세요.
그럼 즐거운 하루 시작하세요.
전체 부분은 아니고 제가 맡은 부분에 대한 베타리더 입니다^^.
중간에 여러 일들이 있어서 1년이나 걸리게 됐습니다.
아직 마무리할 내용도 많지만, 고생한 만큼 애정이 어릴 수 밖에 없습니다.
제가 맡은 부분은 책 후반부로 9~15장입니다.
객체 제어, 컨버세이션, HQL, Criteria 등에 대한 내용을 다루고 있습니다.
관심 있고 성심으로 결과물을 함께 검토하고 의견주실 분을 찾습니다.
현재는 안영회님과 최한수님께서 베타리더로 지원(^^?) 해주셨습니다.
아, 여기에 전수 검토를 언제나 완벽히 해주시는 공역자이신 이대엽님도 계시구요^^.
관련 서적도 거의 전무하고, 공감대가 형성된 한글 용어가 없기 때문에 걱정이 많이 되는 것도 사실입니다.
그러니 많은 분들이 보시고 공유하고 의견을 개진해주셨으면 좋겠네요.
베타리딩 시작은 빨라야 다음주 중이나, 아마도 다다음주 초가 될듯 합니다.
관심있는 분들께서는 댓글이나 메일(chanwook.god@지메일)로 연락주세요.
그럼 즐거운 하루 시작하세요.
짧은 시간에 많은(?) 분들이 답글을 남겨주셨습니다^^. 감사합니다.
총 다섯 분의 의견을 받았습니다.
Eagerly의 한글 의미를 다시 한 번 생각해보면,
그 다음 이 용어와 쌍을 이루는 'lazy loading'과의 대칭성(여기서는 미학까지는 아니더라도..;;)도 생각해봐야 하는데, '늦은 로딩'으로 번역을 했으니 제 생각으로는 '즉시 로딩'이 어울려 보이는군요.
어떠신가요? 어색하지 않으신가요? 의미가 와닿으신가요?
물론 저혼자 결정하는게 아니니 다른 역자님들과 공유를 해봐야겠습니다.
총 다섯 분의 의견을 받았습니다.
권남님: '즉시'
박형근님: '빠른'
Javanese님: '앞선'
기선님: '적극적인'
대엽님: '즉각적인'
영회님: '바로'
성철님: '적극적'
박형근님: '빠른'
Javanese님: '앞선'
기선님: '적극적인'
대엽님: '즉각적인'
영회님: '바로'
성철님: '적극적'
Eagerly의 한글 의미를 다시 한 번 생각해보면,
연산 요청 시에 요청에 해당하는 모든 결과값을 바로(즉시) 불러온다입니다. 어떻게 보면 Eagerly의 뜻이 되기도 하는 '바로, 즉시 불러온다'가 핵심이 됩니다. 이러한 관점에서 보면 권남님이 의견을 주신 '즉시'와 대엽님이 의견을 주신 '즉각적인'이 적절하다고 생각됩니다.
그 다음 이 용어와 쌍을 이루는 'lazy loading'과의 대칭성(여기서는 미학까지는 아니더라도..;;)도 생각해봐야 하는데, '늦은 로딩'으로 번역을 했으니 제 생각으로는 '즉시 로딩'이 어울려 보이는군요.
'늦은 로딩 - 즉시 로딩'
어떠신가요? 어색하지 않으신가요? 의미가 와닿으신가요?
물론 저혼자 결정하는게 아니니 다른 역자님들과 공유를 해봐야겠습니다.
Prev
Rss Feed