'안영회'에 해당되는 글 38건
- 2009/02/17 Blaze DS or LiveCycle Data Services
- 2008/12/31 올해의 스프링 기술 top5, 내년 유망 스프링 기술 top5 (javajigi 편) (1)
- 2008/12/30 올해의 스프링 기술 top5, 내년 유망 스프링 기술 top5 (안영회 편) (4)
- 2008/12/09 SpringSource의 또 다른 야심작, tc Server (1)
- 2008/11/25 "Spring Python" 파이썬 개발자에게도 봄(?)을
- 2008/11/20 스프링 2.5.x 버전을 쓰시는 분들은 2.5.5 이상으로 빨리 업데이트 하세요
- 2008/11/12 Spring, Grails를 품에 안다 (4)
- 2008/10/30 KSUG 스크린 캐스트 연재 시작
- 2008/09/17 스프링 레퍼런스 한글화 프로젝트 시작 (2)
- 2008/08/01 OSGi 관련 블로그 소개: Universal Framework - OSGi
명확한 비교표를 제시하는군요. 비용과 기술 지원 조합에 따라 네 가지 선택사항이 있습니다. NIO 은 LiveCycle DS라도 Community Edition에서는 지원하지 않는군요. 더 자세한 내용은 원문(Blaze Data Services or LiveCycle Data Services?)을 보세요.
연말연시를 맞아서 KSUG 필진 중심으로 올해 두각을 나타냈던 스프링 관련 기술과 내년 떠오를 것으로 보이는 유망 스프링 기술을 각각 다섯 개씩 선정해보았습니다. 여러분들도 포럼을 통해 스스로 견해를 나눠보는 것이 어떨까요? 세 번째 주자는 javajigi 박재성님입니다. 박재성님은 QCon에 다녀오신 터라 Spring과 유관한 엔터프라이즈 기술을 포괄하여 정리한 듯 합니다.
안녕하세요. 박재성입니다.
Spring 프레임워크와 관련해서는 두 분이 너무 잘 정리해주셔서 자바 개발자라면 관심을 가져야 될 것으로 생각되는 부분을 정리해봤습니다. Spring 프레임워크와 관련되지 않아서 활용하기 힘들다면 그렇게 하셔도 괜찮습니다. 2008년과 2009년으로 나누지 않고 최근의 기술 흐름에 대해서 QCon에서 느꼈던 부분을 정리했습니다. 이런 글을 적는다는게 생각보다 쉽지 않네요.
1. Domain Driven Design(DDD)
2004년에 Eric Evans가 Domain Driven Design 책을 출간했지만 아직 적용한 곳이 많지 않은 상태이다. 그러나 점점 더 많은 활용사례가 나타나면서 DDD에 대한 중요성이 부각될 것으로 생각한다. 이미 자바 뿐만 아니라 C#에서도 활용사례가 나타나고 있다. Spring Batch가 DDD 사상으로 개발되었다는 글(http://java-chimaera.blogspot.com/2008/11/spring-batch-domain-driven-design-in.html)도 볼 수 있으며, 2009년의 Spring 로드맵에는 DDD 기반의 소스 생성기인 ROO가 포함되어 있는 것도 주목할 만하다. 앞으로 DDD 기반으로 개발된 애플리케이션이 점점 더 증가할 것으로 예상된다.
2. Domain Specific Language(DSL)
지금까지 특정 Context에 맞는 구문들이 많들어져 사용되어 왔다. 예를 들어 SQL, CSS, Junit, Ant등과 같이 특정 Context에 맞는 형태로 구문을 정의하고 사용되어 왔는데 최근에 이를 통틀어 DSL로 지칭하고 있다. RSpect, JBehave와 같은 DSL이 등장하면서 DSL에 대한 관심도가 더욱 높아지고 있다. 업무 분석가와 고객이 좀 더 쉽게 이해할 수 있는 언어로 테스트 시나리오를 작성하고 이를 실제 애플리케이션 테스트에 적용할 수 있다면 더 없이 좋을 듯하다. 국내 현실에서는 좀 더 많은 시간이 필요하겠지만 외국은 이미 움직임이 시작되고 있다.
3. Ployglot와 Poly-Paradigm
최근의 경향은 하나의 애플리케이션을 개발하기 위하여 여러 개의 언어를 같이 사용하며(Ployglot), 여러 개의 패러다임(Poly Paradigm)을 같이 사용하는 방향으로 움직이고 있다. 예를 들어 Adobe Lightroom은 C++ 과 Lua, Google Android는 Linux + libraris(C)+ Java로 개발되어 있다. 또한 애플리케이션의 요구사항따라 Object Language와 Functional Language를 혼용해서 사용하는 사례들이 나타나고 있다. 자바 개발자에게 Grails와 같은 프레임워크가 널리 보급된다면 이와 같은 방식의 접근 방법에 거부감을 쉽게 없앨 수 있을 것으로 기대한다.
4. 애자일 프로세스의 성장
해외에서는 이미 애자일 프로세스가 많이 보급되었으며, 다양한 적용 사례가 컨퍼런스를 통하여 공유되고 있다. 애자일 프로세스에 맞는 아키텍트의 역할까지 논하고 있는 상황이다. 아직 국내에서는 많은 프로젝트에서 적용하지 않고 있는 상황이지만 점진적으로 성장할 것으로 판단된다. 애자일 프로세스의 실천 방법 중에 일부분이라도 적용하는 프로젝트가 많아질 것으로 예상한다. 그 중에서 잦은 통합을 위하여 지속적 통합툴의 활용과 테스트에 대한 중요성이 높아질 것으로 예상한다.
5. Grails와 ORM
안영회씨와 정상혁씨도 언급했지만 자바 개발자라면 앞으로 Grails의 성장에 관심을 가져야 될 것으로 생각한다. 국내에서는 Hibernate 프레임워크에 대한 관심도 가 낮은데 Grails의 성장으로 인해 자연스럽게 Hibernate ORM 프레임워크에 대한 관심도도 높아질 것으로 생각한다. ORM 프레임워크에 대한 학습 비용이 높지만 Grails를 좀 더 잘 사용하고자하는 개발자들을 중심으로 Hibernate가 보급될 것으로 생각한다. 또한 Groovy에 대한 관심도가 높아지면서 Script Language와 DSL에 대한 관심도도 높아질 것으로 예상해본다.
6. 자바진영에서 Spring 프레임워크의 영향력 확대
Spring 프레임워크는 급격하게 성장하고 있으며, 자바 진영에서 그 영향력이 점점 더 커지고 있다. 하지만 Spring 프레임워크에 대한 회의감을 표시하는 개발자들도 등장하고 있다. Spring 프레임워크의 도입에 대한 찬반 논쟁이 지속적으로 발생할 것으로 생각한다. 또한 Spring 프레임워크에서 Spring Security와 Spring Batch와 같은 서브 프로젝트의 국내 적용 사례가 점점 더 증가할 것으로 판단된다. 점점 더 비대해져가는 Spring 프레임워크를 이해하기 위하여 Spring 프레임워크가 가지는 핵심 사상과 방향을 전파하려는 노력도 지속될 것으로 생각한다.
안녕하세요. 박재성입니다.
Spring 프레임워크와 관련해서는 두 분이 너무 잘 정리해주셔서 자바 개발자라면 관심을 가져야 될 것으로 생각되는 부분을 정리해봤습니다. Spring 프레임워크와 관련되지 않아서 활용하기 힘들다면 그렇게 하셔도 괜찮습니다. 2008년과 2009년으로 나누지 않고 최근의 기술 흐름에 대해서 QCon에서 느꼈던 부분을 정리했습니다. 이런 글을 적는다는게 생각보다 쉽지 않네요.
1. Domain Driven Design(DDD)
2004년에 Eric Evans가 Domain Driven Design 책을 출간했지만 아직 적용한 곳이 많지 않은 상태이다. 그러나 점점 더 많은 활용사례가 나타나면서 DDD에 대한 중요성이 부각될 것으로 생각한다. 이미 자바 뿐만 아니라 C#에서도 활용사례가 나타나고 있다. Spring Batch가 DDD 사상으로 개발되었다는 글(http://java-chimaera.blogspot.com/2008/11/spring-batch-domain-driven-design-in.html)도 볼 수 있으며, 2009년의 Spring 로드맵에는 DDD 기반의 소스 생성기인 ROO가 포함되어 있는 것도 주목할 만하다. 앞으로 DDD 기반으로 개발된 애플리케이션이 점점 더 증가할 것으로 예상된다.
2. Domain Specific Language(DSL)
지금까지 특정 Context에 맞는 구문들이 많들어져 사용되어 왔다. 예를 들어 SQL, CSS, Junit, Ant등과 같이 특정 Context에 맞는 형태로 구문을 정의하고 사용되어 왔는데 최근에 이를 통틀어 DSL로 지칭하고 있다. RSpect, JBehave와 같은 DSL이 등장하면서 DSL에 대한 관심도가 더욱 높아지고 있다. 업무 분석가와 고객이 좀 더 쉽게 이해할 수 있는 언어로 테스트 시나리오를 작성하고 이를 실제 애플리케이션 테스트에 적용할 수 있다면 더 없이 좋을 듯하다. 국내 현실에서는 좀 더 많은 시간이 필요하겠지만 외국은 이미 움직임이 시작되고 있다.
3. Ployglot와 Poly-Paradigm
최근의 경향은 하나의 애플리케이션을 개발하기 위하여 여러 개의 언어를 같이 사용하며(Ployglot), 여러 개의 패러다임(Poly Paradigm)을 같이 사용하는 방향으로 움직이고 있다. 예를 들어 Adobe Lightroom은 C++ 과 Lua, Google Android는 Linux + libraris(C)+ Java로 개발되어 있다. 또한 애플리케이션의 요구사항따라 Object Language와 Functional Language를 혼용해서 사용하는 사례들이 나타나고 있다. 자바 개발자에게 Grails와 같은 프레임워크가 널리 보급된다면 이와 같은 방식의 접근 방법에 거부감을 쉽게 없앨 수 있을 것으로 기대한다.
4. 애자일 프로세스의 성장
해외에서는 이미 애자일 프로세스가 많이 보급되었으며, 다양한 적용 사례가 컨퍼런스를 통하여 공유되고 있다. 애자일 프로세스에 맞는 아키텍트의 역할까지 논하고 있는 상황이다. 아직 국내에서는 많은 프로젝트에서 적용하지 않고 있는 상황이지만 점진적으로 성장할 것으로 판단된다. 애자일 프로세스의 실천 방법 중에 일부분이라도 적용하는 프로젝트가 많아질 것으로 예상한다. 그 중에서 잦은 통합을 위하여 지속적 통합툴의 활용과 테스트에 대한 중요성이 높아질 것으로 예상한다.
5. Grails와 ORM
안영회씨와 정상혁씨도 언급했지만 자바 개발자라면 앞으로 Grails의 성장에 관심을 가져야 될 것으로 생각한다. 국내에서는 Hibernate 프레임워크에 대한 관심도 가 낮은데 Grails의 성장으로 인해 자연스럽게 Hibernate ORM 프레임워크에 대한 관심도도 높아질 것으로 생각한다. ORM 프레임워크에 대한 학습 비용이 높지만 Grails를 좀 더 잘 사용하고자하는 개발자들을 중심으로 Hibernate가 보급될 것으로 생각한다. 또한 Groovy에 대한 관심도가 높아지면서 Script Language와 DSL에 대한 관심도도 높아질 것으로 예상해본다.
6. 자바진영에서 Spring 프레임워크의 영향력 확대
Spring 프레임워크는 급격하게 성장하고 있으며, 자바 진영에서 그 영향력이 점점 더 커지고 있다. 하지만 Spring 프레임워크에 대한 회의감을 표시하는 개발자들도 등장하고 있다. Spring 프레임워크의 도입에 대한 찬반 논쟁이 지속적으로 발생할 것으로 생각한다. 또한 Spring 프레임워크에서 Spring Security와 Spring Batch와 같은 서브 프로젝트의 국내 적용 사례가 점점 더 증가할 것으로 판단된다. 점점 더 비대해져가는 Spring 프레임워크를 이해하기 위하여 Spring 프레임워크가 가지는 핵심 사상과 방향을 전파하려는 노력도 지속될 것으로 생각한다.
연말연시를 맞아서 KSUG 필진 중심으로 올해 두각을 나타냈던 스프링 관련 기술과 내년 떠오를 것으로 보이는 유망 스프링 기술을 각각 다섯 개씩 선정해보았습니다. 여러분들도 포럼을 통해 스스로 견해를 나눠보는 것이 어떨까요? 두 번째는 접니다.
올해의 스프링 기술 top5
1. Annotation 기반 설정(since Spring 2.5)
지난 Spring One Americas에서는 "설정은 XML 에서"라는 오랜 고정관념을 깨려는 듯 애노테이션 사용을 적극 장려하는 분위기였다. 설정 기반으로 애노테이션 기반으로 옮기는데 있어 오랫동안 J2EE/JEE 에서는 설정을 XML(EJB의 DD, Struts 등등)에서 했다는 점이 관성으로 작용한다. 그리고, 아직은 IDE 지원 역시 XML이 더욱 우위에 있다. 반면, Spring 2.5 부터 등장한 애노테이션 기반 설정은 light-weight 설정(?)을 가능하게 한다. Spring 3.0 에서 Java Config가 Core로 포함되면 애노테이션과 함께 시너지를 내는 모습을 볼 수 있지 않을까. 설정은 XML 영역이었던 시절이 현재형에서 과거형으로 바뀌어 가는 시점이다.1
2. Spring dm Server
엔터프라이즈 시장에서 아직 OSGi 애플리케이션은 실험적인 단계로 볼 수 있다. Spring dm Server은 실험적인 단게에서 실용적인 단계로 견인하는 큰 축을 차지하고 있다. Spring dm Server가 없었더라도 엔터프라이즈 영역에서 OSGi의 발전이 이렇게 빨랐을까? OSGi에서도 POJO 프로그래밍을 고수할 수 있었을까? dm Server의 순위를 놓고 고민했는데 당장은 가시적인 효과가 나타나지 않았더라도 영향력에 있어서는 첫 손가락으로 꼽하도 과하지 않다.
3. Spring Batch
Spring Batch는 새로운 프로젝트이긴 하지만, Accenture의 오랜 노하우가 Spring의 옷을 입고 등장한 것으로 봐야 할 듯 하다. 몇 주전 필자의 소속회사에서 성공리에 국내 대형 금융사에 성공적으로 배치 개선 프로젝트를 끝냈다. 실험적인 것이 아니라 이미 운영 중인 애플리케이션에 도입했다는 점에서 국내 환경, 그것도 대용량 금융환경 적용 가능성을 검증한 것이라 볼 수 있다. 작년 말에는 소문만 무성했는데 한 해 만에 릴리즈하고, 사이트 적용이 가능해졌다니 놀랍도록 빠른 발전이다. 마침 KSUG에서 Spring Batch에 대한 benelog님의 시리즈를 연재 하고 있다.
4. Spring Web Flow 2.0
SWF가 2.0을 출시하면서 Spring Web Flow는 선택적 웹 기술에서 MVC의 중심으로 위상이 바뀐 듯 하다. Spring Faces나 Spring JavaScript 등의 웹 기반 프로젝트 모두는 SWF를 중심으로 MVC의 확장 기술로 위치하고 있다. AJAX 나 RIA 기술 등장으로 비롯한 다양한 웹 화면 요구가 SWF를 축으로 Spring에서도 구현되고 있다. SWF를 유망 기술로 꼽아야 하나 고민이지만, 2.0 릴리즈 이후 기반을 닦았다는 점에서 올해의 기술로 꼽았다.
5. Spring Integration
올해 처음으로 선을 보인 Spring Integration이 빠른 속도로 발전하고 있다. 아직은 incubator 수준이긴 하지만 Spring Integration Adapters 까지 생겨나 Spring Integration의 발전 가능성을 높여주고 있다. 아직 기능에 있어서는 부족한 모습이지만, SpringSource의 다양한 기술을 고려하면 향후 어떤 시너지를 창출할지 기대가 된다.
내년 유망 스프링 기술 top5
1. Spring Twin Server (Spring tc Server + Spring dm Server)2
tc Server는 아직 데모밖에 보지 못한 상태지만, 파급효과에 대한 기대감에 있어서는 타의 추종을 불허한다. 과거 문제가 있어도 반쪽 EJB(?)를 그대로 쓰던 상황을 Spring이 타개했듯, 반쪽 WAS(?)를 쓰는 상황을 tc Server가 개선해주기를 바란다. 그리고, 올해의 top5에 선정했지만 dm Server 역시 내년에는 더욱 발전하여 tc Server/dm Server가 Application Server 시장에도 일대 혁신을 가져오길 기대한다.
2. Grails
Spring One Americas 2008에 참석하기 전까지는 SpringSource의 G2One 인수가 얼마나 큰 의미를 지니는지 알지 못했다. Grails는 Spring/Hibernate의 기반을 똑같이 활용하면서 완전히 새로운 API 스타일을 추가한 격이다. DSL 개발 등을 통해 개발 과정을 고도화 한다면, 엔터프라이즈 환경에서도 요구사항 반영 주기/시스템 개선 주기를 혁신적으로 개선할 수 있을 가능성을 보여주고 있다. 개인적으로 내년도 가장 흥미롭게 연구해볼 주제 가운데 하나다.
3. Spring 3.0
2.5, 3.0 대신에 3.0, 3.5 라고 하는 것이 어땠을까 할만큼 완전히 새로운 면모보다는 2.5의 일대 개선처럼 보인다. 이러한 면에서 Spring 커뮤니티의 지속적인 개선을 더욱 높이사게 된다. 물론 영원하지야 않겠지만, 내년 이맘때에도 지금처럼 Spring의 꾸준한 발전을 볼 수 있기를 기대한다.
4. Spring Security 2.5
benelog님 말처럼 가장 복잡한 영역 가운데 하나인 보안 프로그래밍 쪽에 단비와 같은 프레임워크가 Spring Security 이다. 엔터프라이즈 프로그래밍에 국한해서 보면, 확장성에 있어서는 거의 독보적인 솔루션이 아닌가 싶다. Acegi 1.5 에서 Spring Security 2.0 개선할 때는 Spring 2.0의 스키마 기반 설정을 대폭 보강하더니 2.5에서는 Spring 3.0과 궤를 같이 하여 애노테이션 및 EL 활용에 대한 밀착 연계를 제공한다. 출시 시점도 Spring 3.0에 맞춰져 있다.
5. Consolidation 솔루션
다소 무리한 분류라 할 수 있지만, terracotta 류의 클러스터 솔루션과 플랫폼 가상화 솔루션 등을 묶어서 consolidation3 솔루션으로 분류했다. 기존에 Spring의 영역은 "개발"에 국한했었지만, 캐시에서 클러스터 솔루션으로 변모한 Spring 유관제품이 등장하더니 VMWare와 손잡고 새 제품 출시를 준비중이다. Spring Portfolio의Consolidation 시장 진출은 "Ubiquitous Spring" 현상을 강화하는 전기가 될 것이다.
올해의 스프링 기술 top5
1. Annotation 기반 설정(since Spring 2.5)
지난 Spring One Americas에서는 "설정은 XML 에서"라는 오랜 고정관념을 깨려는 듯 애노테이션 사용을 적극 장려하는 분위기였다. 설정 기반으로 애노테이션 기반으로 옮기는데 있어 오랫동안 J2EE/JEE 에서는 설정을 XML(EJB의 DD, Struts 등등)에서 했다는 점이 관성으로 작용한다. 그리고, 아직은 IDE 지원 역시 XML이 더욱 우위에 있다. 반면, Spring 2.5 부터 등장한 애노테이션 기반 설정은 light-weight 설정(?)을 가능하게 한다. Spring 3.0 에서 Java Config가 Core로 포함되면 애노테이션과 함께 시너지를 내는 모습을 볼 수 있지 않을까. 설정은 XML 영역이었던 시절이 현재형에서 과거형으로 바뀌어 가는 시점이다.1
2. Spring dm Server
엔터프라이즈 시장에서 아직 OSGi 애플리케이션은 실험적인 단계로 볼 수 있다. Spring dm Server은 실험적인 단게에서 실용적인 단계로 견인하는 큰 축을 차지하고 있다. Spring dm Server가 없었더라도 엔터프라이즈 영역에서 OSGi의 발전이 이렇게 빨랐을까? OSGi에서도 POJO 프로그래밍을 고수할 수 있었을까? dm Server의 순위를 놓고 고민했는데 당장은 가시적인 효과가 나타나지 않았더라도 영향력에 있어서는 첫 손가락으로 꼽하도 과하지 않다.
3. Spring Batch
Spring Batch는 새로운 프로젝트이긴 하지만, Accenture의 오랜 노하우가 Spring의 옷을 입고 등장한 것으로 봐야 할 듯 하다. 몇 주전 필자의 소속회사에서 성공리에 국내 대형 금융사에 성공적으로 배치 개선 프로젝트를 끝냈다. 실험적인 것이 아니라 이미 운영 중인 애플리케이션에 도입했다는 점에서 국내 환경, 그것도 대용량 금융환경 적용 가능성을 검증한 것이라 볼 수 있다. 작년 말에는 소문만 무성했는데 한 해 만에 릴리즈하고, 사이트 적용이 가능해졌다니 놀랍도록 빠른 발전이다. 마침 KSUG에서 Spring Batch에 대한 benelog님의 시리즈를 연재 하고 있다.
4. Spring Web Flow 2.0
SWF가 2.0을 출시하면서 Spring Web Flow는 선택적 웹 기술에서 MVC의 중심으로 위상이 바뀐 듯 하다. Spring Faces나 Spring JavaScript 등의 웹 기반 프로젝트 모두는 SWF를 중심으로 MVC의 확장 기술로 위치하고 있다. AJAX 나 RIA 기술 등장으로 비롯한 다양한 웹 화면 요구가 SWF를 축으로 Spring에서도 구현되고 있다. SWF를 유망 기술로 꼽아야 하나 고민이지만, 2.0 릴리즈 이후 기반을 닦았다는 점에서 올해의 기술로 꼽았다.
5. Spring Integration
올해 처음으로 선을 보인 Spring Integration이 빠른 속도로 발전하고 있다. 아직은 incubator 수준이긴 하지만 Spring Integration Adapters 까지 생겨나 Spring Integration의 발전 가능성을 높여주고 있다. 아직 기능에 있어서는 부족한 모습이지만, SpringSource의 다양한 기술을 고려하면 향후 어떤 시너지를 창출할지 기대가 된다.
내년 유망 스프링 기술 top5
1. Spring Twin Server (Spring tc Server + Spring dm Server)2
tc Server는 아직 데모밖에 보지 못한 상태지만, 파급효과에 대한 기대감에 있어서는 타의 추종을 불허한다. 과거 문제가 있어도 반쪽 EJB(?)를 그대로 쓰던 상황을 Spring이 타개했듯, 반쪽 WAS(?)를 쓰는 상황을 tc Server가 개선해주기를 바란다. 그리고, 올해의 top5에 선정했지만 dm Server 역시 내년에는 더욱 발전하여 tc Server/dm Server가 Application Server 시장에도 일대 혁신을 가져오길 기대한다.
2. Grails
Spring One Americas 2008에 참석하기 전까지는 SpringSource의 G2One 인수가 얼마나 큰 의미를 지니는지 알지 못했다. Grails는 Spring/Hibernate의 기반을 똑같이 활용하면서 완전히 새로운 API 스타일을 추가한 격이다. DSL 개발 등을 통해 개발 과정을 고도화 한다면, 엔터프라이즈 환경에서도 요구사항 반영 주기/시스템 개선 주기를 혁신적으로 개선할 수 있을 가능성을 보여주고 있다. 개인적으로 내년도 가장 흥미롭게 연구해볼 주제 가운데 하나다.
3. Spring 3.0
2.5, 3.0 대신에 3.0, 3.5 라고 하는 것이 어땠을까 할만큼 완전히 새로운 면모보다는 2.5의 일대 개선처럼 보인다. 이러한 면에서 Spring 커뮤니티의 지속적인 개선을 더욱 높이사게 된다. 물론 영원하지야 않겠지만, 내년 이맘때에도 지금처럼 Spring의 꾸준한 발전을 볼 수 있기를 기대한다.
4. Spring Security 2.5
benelog님 말처럼 가장 복잡한 영역 가운데 하나인 보안 프로그래밍 쪽에 단비와 같은 프레임워크가 Spring Security 이다. 엔터프라이즈 프로그래밍에 국한해서 보면, 확장성에 있어서는 거의 독보적인 솔루션이 아닌가 싶다. Acegi 1.5 에서 Spring Security 2.0 개선할 때는 Spring 2.0의 스키마 기반 설정을 대폭 보강하더니 2.5에서는 Spring 3.0과 궤를 같이 하여 애노테이션 및 EL 활용에 대한 밀착 연계를 제공한다. 출시 시점도 Spring 3.0에 맞춰져 있다.
5. Consolidation 솔루션
다소 무리한 분류라 할 수 있지만, terracotta 류의 클러스터 솔루션과 플랫폼 가상화 솔루션 등을 묶어서 consolidation3 솔루션으로 분류했다. 기존에 Spring의 영역은 "개발"에 국한했었지만, 캐시에서 클러스터 솔루션으로 변모한 Spring 유관제품이 등장하더니 VMWare와 손잡고 새 제품 출시를 준비중이다. Spring Portfolio의Consolidation 시장 진출은 "Ubiquitous Spring" 현상을 강화하는 전기가 될 것이다.
- 참고로 Spring 2.5 릴리즈는 작년 말이다. [본문으로]
- 둘은 다른 시장을 대상으로 하면서도 같은 목적과 기반을 갖고 있어 Twin 서버라고 지칭했지만, 필자 임의로 붙이 이름이다. :) [본문으로]
- IFRS 회계 국경이 사라진다 에서 '연결과 통합'이라고 번역했다. [본문으로]
SpringSource의 경영층 일원인 Peter Cooper-Ellis가 The cat is out of the bag – tc Server announced라는 글로 tc 서버(Server) 공표 소식을 온라인에도 옮겼다. tc 서버에 대해서는 SpringOne Americas에서 로드 존슨의 키노트를 통해 처음으로 알려졌다.
tc 서버는 톰캣 기반의 서버로써 가볍다는 면에서는 톰캣과 같지만, 상용 WAS 제품과 경쟁하기 위해 등장했다고 할 수 있다. tc 서버는 SpringSource가 인수한 Covalent1의 경험에서 기초한다. 개발자들은 톰캣을 좋아하지만, 운영 시점에서는 톰캣만으로는 어려움이 있다는 점에서 착안하여, tc 서버는 배포, 진단 및 트러블슈팅 기능을 개선하기 위해 등장했다. 또한, 그들의 경험에 따르면 많은 사이트에서 개발 시점에서는 톰캣, 운영시점에서는 상용 WAS를 쓴다고 한다. 필자가 참여했던 몇 번의 스프링 기반 프로젝트에서도 모두 그랬다. 운영시점에서 톰캣이 부족한 것과 반대로 개발시점에서 WAS를 쓰는 일은 무척 번거로운 일이다. tc 서버는 톰캣 기반으로 톰캣과 완벽하게 호환되기 때문에 톰캣 -> tc 서버 이전도 쉽고, tc 서버 자체가 가벼워 tc 서버를 개발시점부터 쓸 수도 있을 것이다. 필자의 경우 3년 전 톰캣으로 개발한 소스를 T사의 WAS로 이전하면서 개발팀이 불평했던 기억이나, 호환성 테스트를 진행할 때 최신 버전을 기준으로 어떤 WAS도 완벽하게 톰캣에서 구동하는 서블릿 코드가 한방에 돌아가지는 않았던 기억이 있다.
tc 서버는 내년 1월 중순에 발표될 예정이며, 개발자는 무료로 사용할 수 있다. 서버 배포시에는 CPU당 500달라 내외로 책정할 모양이다.
마침 Webinar: Introduction to SpringSource tc Server 가 한다.
ust like Tomcat, tc Server is lightweight, easy to use and fast. It has
a memory-footprint of about 7 megabytes and it cold-starts in under 3
seconds.
tc 서버는 톰캣 기반의 서버로써 가볍다는 면에서는 톰캣과 같지만, 상용 WAS 제품과 경쟁하기 위해 등장했다고 할 수 있다. tc 서버는 SpringSource가 인수한 Covalent1의 경험에서 기초한다. 개발자들은 톰캣을 좋아하지만, 운영 시점에서는 톰캣만으로는 어려움이 있다는 점에서 착안하여, tc 서버는 배포, 진단 및 트러블슈팅 기능을 개선하기 위해 등장했다. 또한, 그들의 경험에 따르면 많은 사이트에서 개발 시점에서는 톰캣, 운영시점에서는 상용 WAS를 쓴다고 한다. 필자가 참여했던 몇 번의 스프링 기반 프로젝트에서도 모두 그랬다. 운영시점에서 톰캣이 부족한 것과 반대로 개발시점에서 WAS를 쓰는 일은 무척 번거로운 일이다. tc 서버는 톰캣 기반으로 톰캣과 완벽하게 호환되기 때문에 톰캣 -> tc 서버 이전도 쉽고, tc 서버 자체가 가벼워 tc 서버를 개발시점부터 쓸 수도 있을 것이다. 필자의 경우 3년 전 톰캣으로 개발한 소스를 T사의 WAS로 이전하면서 개발팀이 불평했던 기억이나, 호환성 테스트를 진행할 때 최신 버전을 기준으로 어떤 WAS도 완벽하게 톰캣에서 구동하는 서블릿 코드가 한방에 돌아가지는 않았던 기억이 있다.
tc 서버는 내년 1월 중순에 발표될 예정이며, 개발자는 무료로 사용할 수 있다. 서버 배포시에는 CPU당 500달라 내외로 책정할 모양이다.
subscriptions for production deployment will be available for around $500/CPU
마침 Webinar: Introduction to SpringSource tc Server 가 한다.
- Covalent는 대부분의 Tomcat 코드를 만들고 있는 업체다. [본문으로]
Spring Python의 저자 Spring Python에 대해 이야기 할 때 Django 정도로 짐작하는 것에 대한 답변으로 Spring Python isn't a simple port of the Spring Framework 이라는 글을 썼다. 이미 Spring.NET이 있긴 하지만, J2EE와 .NET 은 이미 산업 라이벌로 오랫동안 경쟁해 온 점을 생각하면 Spring Python은 놀랍고도 신선하다.
Spring 도입 초기에 Struts와 Spring을 비슷하게 보는 국내 개발자들을 흔히 만날 수 있었다. Spring이 Struts를 대체하고자 등장한 것이 아니듯, Spring Python 역시 Django를 대체하려고 나온 것은 아니다. 스프링은 이론적 배경에서 출발한 것이 아니라 엔터프라이즈 시스템 구현 과정에서 바람직한 방법을 총망라한 것이다. Python is Not Java임에도 불구하고... 그야말로 전도(Evangelism)라는 말이 딱 어울린다. 전도를 위해서는 그 나라 언어와 문화를 배워야 하듯, Spring의 철학을 Python에서 실현하기 위해서는 보다 Python 스러움을 수용해야 한다.
0.8.0 ... 현재 Spring Python의 버전이다. 레퍼런스를 보면서.. 벌써 하고 놀라지 않을 수 없었다.
Spring 도입 초기에 Struts와 Spring을 비슷하게 보는 국내 개발자들을 흔히 만날 수 있었다. Spring이 Struts를 대체하고자 등장한 것이 아니듯, Spring Python 역시 Django를 대체하려고 나온 것은 아니다. 스프링은 이론적 배경에서 출발한 것이 아니라 엔터프라이즈 시스템 구현 과정에서 바람직한 방법을 총망라한 것이다. Python is Not Java임에도 불구하고... 그야말로 전도(Evangelism)라는 말이 딱 어울린다. 전도를 위해서는 그 나라 언어와 문화를 배워야 하듯, Spring의 철학을 Python에서 실현하기 위해서는 보다 Python 스러움을 수용해야 한다.
0.8.0 ... 현재 Spring Python의 버전이다. 레퍼런스를 보면서.. 벌써 하고 놀라지 않을 수 없었다.
스프링 2.5 최신 버전은 2.5.6 입니다. 최신 버전으로 지속적으로 갱신해주면 좋겠지만 여의치 않는 경우가 있습니다. 개발 중인 경우라면 번거로운 정도지만, 운영 단계에 접어든 경우라면 만만치가 않을 수도 있죠. 제 블로그에 글을 올렸는데, 스프링 2.5.4 이하의 경우 데이터 타입 변환에 버그가 있어 DB에 의도하지 않은 데이터가 들어갈 수 있습니다. 2.5.4 의 경우 타입 대응 관계를 담고 있는 Map을 다음과 같이 초기화 하는 코드를 확인할 수 있습니다.
long 혹은 Long의 경우에도 INTEGER 로 초기화 하는 코드를 확인할 수 있습니다. 스프링처럼 심하게 잘 만들어진 코드에 이런 오류가 있는지 잘 이해가 가지 않습니다. 위 코드를 처음 확인한 제 동료의 경우는 설마 스프링에 이런 버그가 있지는 않을 듯 해서 본인이 모르는 뭔가가 있는지 저에게 확인했습니다. 아래는 JDBC 스펙에서 오린 것인데요. 스펙에서도 long to BIGINT 는 명기하고 있습니다.
제 블로그에 글에 알려드린 바대로 2.5.5 버전에서는 갱신해서 배포했습니다.
데이터 타입에 대한 오류는 매우 민감합니다. 만일, 2.5.4 이하 버전으로 운용하는 시스템이라면 데이터베이스에 의도하지 않는 값이 있을 수 있습니다. 테스트 해본 팀원에 따르면 Types.INTEGER 를 벗어나는 값이 오면 예외를 발생하는 것이 아니라 오버플로우가 일어나 이상한 수치가 들어간다고 하네요. 특정 클래스 Map에 담으면 알 수 없는 타입으로 인지해 정상적으로 long 수치를 저장하더군요. Transaction Script의 남용으로 객체 대신 Map을 쓰는 경우가 많은 국내 현실 탓에 오히려 문제가 없었을 수도 있겠다 싶어 씁쓸하기도 했습니다.
이런 버그 하나로 스프링의 신뢰도를 의심할 분들이 있지는 않을까 하는 노파심도 들었습니다. 허나 스프링 이슈 트래커를 보면 그렇지 않음을 확인할 수 있습니다. 문제는 물론 해결책까지 제시하는 스마트한 고객(스프링 커뮤니티의 일원이죠), 3시간만에 접수하고 그날 밤 빌드에 반영하는 기민한 기술지원, 이러한 과정을 투명하게 공유하는 시스템 등을 상용 제품과 비교해보면 단박에 알 수 있습니다. 과거에 기술지원이 없어 오픈소스를 못쓴다는 말을 수십, 수백번 들은 바 있는데요. 상용 제품은 버그를 찾아내면 바로 해결해주던가요? 얼마전 국내 대표적인 솔루션 회사의 시장 선도 제품에 버그를 발견했던 일이 있습니다. 우리 팀원이 여섯 차례 문제를 보고했습니다. 빠른 조치를 위해 현상 뿐 아니라 예외로그를 분석해서 문제가 되는 클래스까지 알려주었습니다. 업체의 사이트에는 게시판이 있기는 했지만, 기술적인 문의가 오가는 것은 거의 없었습니다. 몇 일 후에 기술지원 인력이 와서 반나절을 앉아 있다가 '해결할 수 없어서 연구소에 보고하겠다'는 말만 남긴 채 떠나갔습니다. 안타까운 것은 경험을 통해 이미 그러한 결과를 예상하고 있었지만, 혹시나 하고 있었다는 점입니다.
long 혹은 Long의 경우에도 INTEGER 로 초기화 하는 코드를 확인할 수 있습니다. 스프링처럼 심하게 잘 만들어진 코드에 이런 오류가 있는지 잘 이해가 가지 않습니다. 위 코드를 처음 확인한 제 동료의 경우는 설마 스프링에 이런 버그가 있지는 않을 듯 해서 본인이 모르는 뭔가가 있는지 저에게 확인했습니다. 아래는 JDBC 스펙에서 오린 것인데요. 스펙에서도 long to BIGINT 는 명기하고 있습니다.
제 블로그에 글에 알려드린 바대로 2.5.5 버전에서는 갱신해서 배포했습니다.
데이터 타입에 대한 오류는 매우 민감합니다. 만일, 2.5.4 이하 버전으로 운용하는 시스템이라면 데이터베이스에 의도하지 않는 값이 있을 수 있습니다. 테스트 해본 팀원에 따르면 Types.INTEGER 를 벗어나는 값이 오면 예외를 발생하는 것이 아니라 오버플로우가 일어나 이상한 수치가 들어간다고 하네요. 특정 클래스 Map에 담으면 알 수 없는 타입으로 인지해 정상적으로 long 수치를 저장하더군요. Transaction Script의 남용으로 객체 대신 Map을 쓰는 경우가 많은 국내 현실 탓에 오히려 문제가 없었을 수도 있겠다 싶어 씁쓸하기도 했습니다.
이런 버그 하나로 스프링의 신뢰도를 의심할 분들이 있지는 않을까 하는 노파심도 들었습니다. 허나 스프링 이슈 트래커를 보면 그렇지 않음을 확인할 수 있습니다. 문제는 물론 해결책까지 제시하는 스마트한 고객(스프링 커뮤니티의 일원이죠), 3시간만에 접수하고 그날 밤 빌드에 반영하는 기민한 기술지원, 이러한 과정을 투명하게 공유하는 시스템 등을 상용 제품과 비교해보면 단박에 알 수 있습니다. 과거에 기술지원이 없어 오픈소스를 못쓴다는 말을 수십, 수백번 들은 바 있는데요. 상용 제품은 버그를 찾아내면 바로 해결해주던가요? 얼마전 국내 대표적인 솔루션 회사의 시장 선도 제품에 버그를 발견했던 일이 있습니다. 우리 팀원이 여섯 차례 문제를 보고했습니다. 빠른 조치를 위해 현상 뿐 아니라 예외로그를 분석해서 문제가 되는 클래스까지 알려주었습니다. 업체의 사이트에는 게시판이 있기는 했지만, 기술적인 문의가 오가는 것은 거의 없었습니다. 몇 일 후에 기술지원 인력이 와서 반나절을 앉아 있다가 '해결할 수 없어서 연구소에 보고하겠다'는 말만 남긴 채 떠나갔습니다. 안타까운 것은 경험을 통해 이미 그러한 결과를 예상하고 있었지만, 혹시나 하고 있었다는 점입니다.
SpringSource가 Groovy와 Grails 개발을 주도하는 G2One을 인수했다. SpringSource의 대표인 Rod Johnson의 글을 통해 인수 의도를 살펴볼 수 있다. Grails는 단순함과 생산성에 있어서는 스프링과 같은 가치를 추구하지만(Like Spring, Grails is a technology that simplifies the lives of developers and makes them more productive), 기술적으로는 상이한 방법을 취한다(dynamic versus strongly typed languages). RoR이 가고 있는 길을 보면, 자바가 엔터프라이즈 영역에서 기존에 넘어왔던 장벽을 고스란히 넘고 있는 모습을 볼 수 있는다. Grails는 동적 언어의 장점과 자바가 만들어논 유산을 함께 취할 수 있는 길이다.
이로써 SpringSource는 모토로 삼고 있는 자바의 복잡함과 싸우는 전쟁(Weapons for the War on Java Complexity)에서 새로운 무기를 추가한 격이다.
로그 존슨은 Groovy의 강점을 다음과 같이 설명하고 있다. 이는 Ruby와 비교될 듯 해서 옮겨본다.
With Grails, you can enjoy rapid application development and programming
in a dynamic language without needing to throw away your investment in
Java middleware; without the need to make inefficient web services
calls to talk to functionality coded in Java; without losing the
benefits of sophisticated O/R mapping; without the risk of hitting a
wall with scalability or enterprise capabilities; without adopting an
unfamiliar programming language for all your coding. You get the
positives, without the very real risks.
이로써 SpringSource는 모토로 삼고 있는 자바의 복잡함과 싸우는 전쟁(Weapons for the War on Java Complexity)에서 새로운 무기를 추가한 격이다.
Through this acquisition, SpringSource is able to meet the needs of
those who prefer to program in a dynamic language, in additional to our
existing user and customer base of Java developers.
로그 존슨은 Groovy의 강점을 다음과 같이 설명하고 있다. 이는 Ruby와 비교될 듯 해서 옮겨본다.
- 자바 클래스 파일로 바로 컴파일할 수 있는 유일한 동적 언어(only dynamic language that can compile directly to Java .class files)
- 자바와 자연스럽게 섞어 쓸 수 있는 유일한 언어(the only language that can be used mixed seamlessly with
Java)
- 자바 애노테이션을 처리할 수 있는 유일한 언어(the only language that can process Java annotations)
- 자바 개발자가 다른 동적 언어에 비해 습득이 쉬움(it has a natural migration path from Java, rather than calling for a big, risky leap of faith)
- DSL 구현에 적합
애초에 약속했던 일정과 주제와는 다소 차이가 있었습니다. 1 연재는 이번주 박찬욱님이 올리는 Spring DAO를 시작합니다.
차주부터는 제가 제작한 Spring @MVC 프로그래밍 그리고, 백기선님의 Spring AOP 시리즈를 연이어 연재할 예정이며, 주 1~2회 정도 간격으로 스크린캐스트를 공개합니다.
각 시리즈 연재 일정입니다.
백기선님의 Spring AOP 시리즈(총 5회)
안영회의 Spring Web MVC
차주부터는 제가 제작한 Spring @MVC 프로그래밍 그리고, 백기선님의 Spring AOP 시리즈를 연이어 연재할 예정이며, 주 1~2회 정도 간격으로 스크린캐스트를 공개합니다.
각 시리즈 연재 일정입니다.
백기선님의 Spring AOP 시리즈(총 5회)
- 1회: 11/4(이하 화)
- 2회: 11/11
- 3회: 11/18
- 4회: 11/25
- 5회: 12/2
안영회의 Spring Web MVC
- from MVC to @MVC: 11/6 (목) (Webniar로 대체)
- 아직은 조직적이 아니고 소규모로 운영하는 터라 깔끔한 모습을 보여드리지 못하는게 아쉽네요. 점차 더 나은 모습을 보여드리도록 하겠습니다. [본문으로]
포럼을 통해 의견이 모아지고, 번역팀 결성을 완료해서 드디어 9월 8일 프로젝트가 시작되었습니다. 순수하게 원격으로 진행하는 프로젝트인지라 철저한 관리는 어려울 것으로 예상합니다. 하지만, 기대 이상으로 자발적으로 참여해주시는 모습에서 희망을 배웁니다. 포럼 소프트웨어가 엑셀 파일 업로드를 허용하지 않아 이곳에 올리려는 터에 공지를 하여 KSUG의 작지만 진화하는 모습을 알립니다.
결실의 계절 가을인데, 우리는 이제 꽃을 뿌리고 겨울을 나고 봄이 찾아오면... 결실을 피울 예정입니다. :)
한글화프로젝트관리@20080917.xls결실의 계절 가을인데, 우리는 이제 꽃을 뿌리고 겨울을 나고 봄이 찾아오면... 결실을 피울 예정입니다. :)
Universal Framework - OSGi
OSGi에 대해 해박한 분 같은데 오늘에야 블로그를 알았습니다. 마소에 기고한 글도 올려두셨네요. OSGi 관련 글 링크를 올려둡니다.
OSGi에 대해 해박한 분 같은데 오늘에야 블로그를 알았습니다. 마소에 기고한 글도 올려두셨네요. OSGi 관련 글 링크를 올려둡니다.
- 자바 모듈 시스템 – JSR 277
- 마이크로소프트웨어 OSGi 기고
- HttpLogService를 이용한 Bundle 구현
- OSGi Bundle Programming (1)
- OSGi - Reference (3)
- OSGi - Reference (2)
- OSGi - Reference (1)
- Universal Framework - OSGi (2)
- Universal Framework - OSGi (1)
- OSGi 의 새로운 이슈 - JSR 277 vs. JSR 291 (OSGi)
- Eclipse Platform, 그리고 Equinox 의 미래 (1)
- Platform으로 가는 첫 걸음; Eclipse - Equinox (7)
- Platform으로 가는 첫 걸음; Eclipse - Equinox (6)
- Platform으로 가는 첫 걸음; Eclipse - Equinox (5)
- Platform으로 가는 첫 걸음; Eclipse - Equinox (4)
- Platform으로 가는 첫 걸음; Eclipse - Equinox (3)
- Platform으로 가는 첫 걸음; Eclipse - Equinox (1)
Prev
Rss Feed
