* 2006년 8월 9일 엠파스에 써둔 것인데, 우연한 기회에 발견하여 옮겨둡니다.
내용 요약이 아닌 일종의 독후감(?)이라 사견을 포함하고 있습니다.
1. Spring is not lightweight. It aims to do everything and is becoming fat and bloated.
Spring은 모든 것을 다 하려 들고, 점점 커지고 있기 때문에 가볍지 않다는 오해.
Spring이 커 보이는 것은 enterprise services나 3rd party 제품과의 통합을 위한 모듈 때문이다.
대규모 프로젝트에서 이들을 통합하는 일은 모험(?)에 가깝다.
Spring은 이러한 모험을 줄여주기 위해 주요 3rd party 제품과의 통합을 위한 기반을 제공한다.
예를 들어보면(2.0M3 기준)
- enterprise services: JNDI, JTA, JMX, JCA, JMS, JDBC, JPA, AOP, JSP, JSTL, Portlet, JAX-RPC, EJB, JavaMail, ...
- 3rd party integration: Log4J, WebWork, Struts, Tapestry, JSF,
Velocity, FreeMarker, JasperReports, BSH, Groovy, JRuby, Quartz,
EHCache, Commons FileUpload, COS, Tiles, iText, POI, Hessian, Burlap,
Hibernate2, Hibernate3, TopLink, OJB, iBATIS SQL Maps, AspectJ, JUnit,
...
무척 많은 것을 지원하지만, 이들 때문에 복잡해지는 것은 아니다.
특정 기능만 사용하기 위해 Spring을 사용하는 것도 매우 유용하다.
Spring은 초기부터 non-invasive와 모듈화를
매우 중요하게 여겼기 때문에 Spring 전체 모듈이 커지는 것은 큰 부담으로 볼 수 없다. 단적인 표현으로 Spring 1.2
기반에서 개발한 코드가 있다면, Spring 2.0 라이브러리로 변경하여도 기존 코드의 실행에는 영향을 미치지 않는다.
2. Spring is overkill for simple applications.
위와 같은 맥락이다. Spring을 적용하면 Application이 복잡해졌다면, '세상에 이런 일이'에 제보할 필요가 있다. 실제로 경험할 수 있는 현상은
Spring의 진정한 위력에서 언급한 바처럼 코드가 현격하게 줄어든다.
저러한 오해를 갖는 것은 Spring이 유도하는 좋은 개발 방식에 적응하는 어려움에서 나온 것이라고 생각된다. 기존에 몸에 밴 습관을 고치는 일은 무척 힘든 일이다.
3. Spring does not scale to handle very large applications.
아래는 Interface21에 Spring 레퍼런스를 문의한 메일에 대한 회신이다.
Below are some of our references.
• 6 of the 10 largest banks in the world use Spring in financial applications, among them is JPMorganChase.
• Voca – implementation of a payment engine used in the United Kingdom.
• European Patent Organisation (EPO)
• European Commission
• French Tax Authority – implementation of public facing tax application
• DekaBank – German domestic bank
• Ilse Media – Holland’s biggest internet portal (
ilse.nl,
vindex.nl and more)
• BEA WebLogic – as underpinning technology in the WebLogic EJB3 server
• Oracle – Oracle's next generation SOA solution "Service Fabric" is based on Spring
세계 10대 은행 중에 6개.
영국의 결체 처리 엔진, 유럽 특허청, 프랑스 세무국, 네덜란드 최대 포탈
이름만 들어도.. 이들의 트래픽을 예상할 수 있다.
흥미로운 사실은 BEA의 EJB3 서버와 오라클의 SOA 솔루션 기반으로 쓰고 있다는 사실이다. 특히, BEA의 접근은
Mastering EJB 저자들이나 JBoss 진영과는 달리 EJB3와 Spring을 상생 모델로 효과적으로 활용하고 있다.(
네거티브 전략 그리고 Spring의 경쟁자 참조)
4. Spring forces you to use Aspect-Oriented Programming (AOP) which is experimental.
AOP는 아직 성숙되지 않았는데 Spring이 AOP를 쓰도록 종용하고 있는가?
그렇지 않다. 2.0 이전의 Spring AOP는 JDK의 Dynamic Proxy를 통해 구현된다.
이런 기법은 비단 Spring AOP가 아니더라도 꽤 널리 쓰인 것이다.
Spring 2.0에서 Spring AOP의 기능을 확장한 것이지, 이것을 쓰도록 유도하는 것은 아니다.
어떤 면에서는 Spring 1.2 에서 다른 기능들은 충분해져서
2.0에서 AOP 강화가 이루어져 더 부각될 뿐이라고 할 수도 있지 않을까?
5. Spring replaces Java Enterprise Edition (JEE).
Spring은 EJB 중심의 기존 J2EE 모델(Java 등장으로 이젠 JEE라 함)을 개선하기 위해 나왔다.
그래서 JEE에 대한 새로운 프로그래밍 모델이다. JEE를 기반으로 하고 있는 것이다.
다음은 Spring이 지원하는 JEE API:
· Java Message Service (JMS)
· Java Management Extensions (JMX)
· Java Transaction API
· JEE Connector Architecture (JCA)
· Java API for XML-based Remote Procedure Calls (JAX-RPC)
· JavaMail
· Java Naming and Directory Interface (JNDI)
· and Enterprise JavaBeans (EJB) including version 3.
6. Spring and EJB are mutually exclusive.
Spring은 비즈니스 로직을 EJB가 아닌 가장 순수한 자바 객체(POJO)에 넣도록 유도한다.
그러나, 굳이 EJB를 쓰려고 한다면 이를 지원하는 유틸리티 클래스를 제공한다.
이때에도 비즈니스 로직을 EJB에 직접 넣는 것이 아니라
POJO에 로직을 넣고 EJB로 쓸 수 있게 해주어 더 유리하다.
7. Spring cannot take advantage of Java 5 annotations like EJB3 does.
Interface21과 BEA의 협업 프로젝트의
Pitchfork에서 오픈소스(under the Apache 2.0 license)로 EJB 3.0 구현을
내놓았다. 오픈소스라는 점은 단지 웹로직에만 채용하지 않고, 공개하겠다는 이야기다. 한편, 3.0에서 부터 기존의 엔터티빈
모델을 대치하는 JPA (EJB3 persistence)의 경우에는 Spring 자체적으로 지원한다. 또한, Spring
2.0에서는 @AspectJ-style의 어노테이션도 지원한다고 한다.(아직 안써봐서..)
8. For a large application, Spring’s XML can become a maintenance nightmare.
분명 XML 설정 정보가 부담스럽긴 하다.
Spring 2.0의 XSD 지원을 잘 활용하면 도메인 특유의 네임스페이스를 정의할 수 있으니 적절한 해결책을 마련할 수 있을 것 같다.
9. Spring does everything with reflection, so it is slow.
Dependency Injection에서 주로 리플렉션을 쓰기 때문에 성능 문제와는 무관하다.
Proxy 기반의 AOP 사용시의 성능저하도 염려할 수준은 아니라고 한다.
다만, JDK 1.3과 1.4의 차이는 현격하니 JDK 업그레이드는 중요할 수 있다.
10. Spring MVC is complex and not as simple as the rest of Spring.
개인적인 소견으로는 'Spring MVC는 Struts에 비해 모든 면에서 우월하다'라고 말하고 싶을 만큼.... 편향된 견해를 갖고 있다. ^^
Struts의 Form 객체 생성이라거나 Parameter 타입 변환 시의 번거로움을
Spring MVC가 말끔하게 해결해준 점은 무척 매력적이다.
또한, Servlet 종속적인 Action으로 인해 테스트가 어려운 점과 같이 Struts는 많은 단점을 갖고 있다.
아마 Spring MVC가 어렵다고 하는 사람들은 JSP 모델1 기반 웹 개발자이거나 Struts 사용자일 가능성이 높다. 반대로 Spring MVC를 쓰던 사람이 Struts를 쓰게 되면 똑같은 반응을 보일 것이다.
Spring MVC를 포함한 Web tier의 프레임워크는 모두 복잡하다. 그래서, 'Spring 2.0 활용 전략 세미나'에서 소개했던 CoC를 적용한 Spring MVC는 상당히 매력적으로 보였다.
* 원문이 너무 길어 부담스럽고 제 사견을 배제한 단순 요약을 원하신다면: