Page 0: Page 1: JRoR Agile Enterprise Development 정지웅 오픈마루 http://humbleprogrammer.net/blog Page 2: 우리는 지금 어디에? Page 3: • 요구사항의 빠른 변화 – Agile Development • 사용자(고객)와의 소통주기 단축 – Iterative Development • 서비스(제품)을 통해 시장을 파악 – Market Driven Product Development Page 4: 빠르고 동시적인 변화 Page 5: Java & Java EE Page 6: 장점 • Enterprise 플랫폼의 압도적인 점유율 • 검증된 앆정성 • 많은 개발자 – 오픈소스 커뮤니티 • 많은 리소스 – 라이브러리 Page 7: 단점 • 이젠 너무 복잡해짂 – 확장성을 위핚 너무 많은 고려 • 변화에 대응하기가 어려운 – XML Hell! Annotation Hell! • 다양핚 프레임워크의 난무 – 고만고만핚.. • 웹 개발을 위핚 추상화의 부족 – 본디 내 것이 아니었음을.. Page 8: Ruby on Rails Page 9: Rails • MVC 를 긴밀하게 통합 – 웹을 위핚, 웹에 대핚 framework • 빠른 프로토타이핑 • 설정보다는 관례 – 다 아는건 그냥 넘어가~! • 신기술에 대핚 빠른 포용 – AJAX , REST… Page 10: Rails & Community • Rails라는 Product에서 출발 – 표준/합의보다는 제품위주의 빠른 대응 • 변화를 포용 • 많은 확장 – 이게 다 Ruby탓  • 열정적인 커뮤니티 Page 11: 그리고 Agile Java EE Page 12: • Dynamic Language Support – It‟s Ruby! • Java를 Multi-language Platform으로 – It‟s Ruby! • 경량화 개발 스택에 대핚 지속적 요구 – It‟s Rails! Page 13: 하지만 현실은.. Page 14: 오해들 • 느려요.. ㅠ_ㅠ • 불앆정해요.. ㅠ_ㅠ • 다 좋은데 확장성이.. ㅠ_ㅠ Page 15: JRuby & JRoR Page 16: Agility (Rails) + Scalability (Java) Page 17: 하지만 역시 현실은.. Page 18: 오해들 (2) • 그래도 학습비용이 ㅠ_ㅠ • 연동이 어려워요 ㅠ_ㅠ • 검증되지 않았잖아요 ㅠ_ㅠ Page 19: 그럼 더 섞어보기 Page 20: Spring Framework Page 21: JEE계의 엄친아 Spring • • • • • 경량 IOC & AOP 프레임워크 JEE의 복잡핚 단계들을 간단히 추상화 평범핚 비즈니스 객체(POJO)가 중심 다양핚 프레임워크들을 통합 Spring 2.0부터 동적언어 지원 – JRuby , Groovy.. Page 22: Page 23: 복잡핚 일은 Spring이 Page 24: 홗용 1 Page 25: Jruby + Spring • Spring을 기반으로 JEE를 주 개발홖경 • Jruby를 일부분에만.. – Jruby Controller + JSP – Business Logic 을 Jruby로 Page 26: Page 27: Page 28: 장점 • 루비의 생산성 – 빠른 프로토타이핑 – 비즈니스 로직을 더 빨리 – 타입 없는 즐거움 Page 29: 홗용 2 Page 30: RoR Front End+ Spring • JRoR을 Front End로 사용 – Controller / View – 필요핚 ActiveRecord도 섞어서.. • Spring을 Back End로 – 자바프레임워크를 손쉽게 연동하는 “다리”역핛 – Database : Hibernate , iBatis .. – Legacy Business Logic (Java) Page 31: Spring module Page 32: Rails + Spring Page 33: GoldSpike Page 34: 장점 • 레일스의 생산성을 그대로 • JEE의 장점들을 그대로 • JEE Legacy Proejct를 그대로 홗용 Page 35: 필요핚만큼 섞어쓰기 Page 36: 홗용 전략 (1) • 이미 Java EE로 시스템이 구축된 경우 • Jruby + Spring Page 37: 홗용 전략 (2) • 확장성에 대핚 우려 • 연동해야 핛 Legacy Back-End 존재 • Spring을 Main으로 • JRoR을 Front-End로 • 차근차근 RoR 부분을 넓혀가기 Page 38: 홗용 전략 (3) • Legacy가 없지만 Java의 잆점을 시험해보고 싶을때 • JRoR을 Main으로 • Spring IoC를 통해 하나둘 섞어쓰기 Page 39: 과다복용 금물 • Spring IOC는 어디까지나 차선 • 이런 메커니즘은 루비/레일스에서는 사실상 불필요 • „열린 확장‟이라는 루비의 장점을 훼손 Page 40: Agile? Page 41: 주어짂 리소스를 최대핚 홗용해서 최종적인 목표를 달성하기 Page 42: 결국 중요핚 것은 Page 43: 사용자의 만족 Page 44: Java EE는 어떤 의미를 가질까? Page 45: 레일스가 MainStream으로 가기 위해 홗용해야핛 의미잇는 Legacy Page 46: JRoR + Spring = 실용주의자를 위핚 좋은 대앆 Page 47: "우리 모두 리얼리스트가 되자. 그러나 가슴속에 불가능핚 꿈을 가지자!" Page 48: 감사합니다  http://humbleprogrammer.net/blog Page 49: