Younghoe.Info v3

• What is OSGi?

더 감이 오게 정의된 표현은 "The Dynamic Module(Bundle) System for Java"
특징을 훑어 보면

- 모듈화 된 시스템을 위해 고안되었고
- visibility rules을 갖고 있다.(자바의 private/public과 유사한)
- a resolution process(의존성 관리를 위한)가 있고
- 버전 인식이 가능하고
- 설치, 삭제, 갱신, 구동 등이 모두 동적으로 실행 가능하며
- 번들 형태로 서비스를 배포(publish)할 수 있고, Service Registry가 있다.

• What problems does it help us to solve?

어디어 써먹을 수 있는가?

Visibility
reflection이나 classloading으로도 접근이 불가능하다. 즉, black-box 기반의 CBD가 가능하고, 보안에도 유리

Operational Control
OSGi 콘솔이나 JMX를 통해 모니터링이 가능하다. 현재 WAS류가 제공해주는 hot deploy 기능보다 한발 더 나아갔다고 해야 하나. 최대 강점은 모든 조작에 재시작이 필요없을 것이란 점

• How does it work?

What is an OSGi bundle?
jar 형태이며 META-INF/MANIFEST.MF 파일에 다음의 선언만을 필요로 한다.
Bundle-SymbolicName: org.swf.beans

이클립스는 OSGi 번들을 플로그인로 관리하려 생성/편집할 수 있다.
JSR 277 (Java Module System)과 유사해보이는데, 이 녀석은 동적이지 못하여 발표자 등은 OSGi에 기반한 JSR 291 (Dynamic Component Support for Java SE)에 밀릴 것이라고 예상했다.

• Where does Spring fit in?
• Spring-OSGi

more..

• Meaning is specific to a context.
• Usefulness is specific to some set of scenarios.
• Practicality is determined by enabling technology.

Eric's Favorite Modeling Tools (currently available)

• Whiteboard (with a digital camera for persistence)
• IDE
• Unit tests
• Our Mouths and Ears

TSE2006 둘쨋날 저녁 파티를 마치고 숙소로 돌아온 토비님의 메시지를 시작으로 즐겁고 흥미로운 대화가 시작되었다. 모 단체와는 달리 허술하기 짝이 없는 검열을 통과한 일부를 발췌... ㅋㅋ

더 자세한 TSE2006 둘쨋날 내용은 토비님이 포스팅하셨습니다:
The Spring Experience 둘째날

Core Functionality

• Navigation is controlled by a flow (complete navigational control)
• Automatic state management (scoping, cleanup)
• A flow is a reusable application module (fully encapsulated: input/output contract, black box)

전체적인 개념 설명

SWF is not a general purpose workflow engine. It's simplified for use with web conversations and lacks features like split and join.
범용적인 워크플로우 엔진이 아니라 웹상에서의 Continuation을 위해 단순화 된 것이다. 고로 플로우의 fork/join이 안된다.

continuation이란?

서비스와의 링크는 어떻게 시키냐?

<bean-action bean="phonebook" method="search"> 
    <method-arguments> 
        <argument expression="flowScope.searchCriteria"/> 
    </method-arguments> 
    <method-result name="results"/> 
</bean-action>

bean 이름과 메소드를 지정해주면

허걱 이렇게 되면.. Controller는 사라지느냐?

<bean name="/phonebook.htm" 
     class="org.springframework.webflow.executor.mvc.FlowController"> 
    <property name="flowExecutor" ref="flowExecutor"/> 
</bean>

설정만으로 가능한 모양이다.

매개변수를 넘기는 방식은 Form을 쓴다면 아래와 같고

<form:form action="phonebook.htm" commandName="searchCriteria" method="post"> 
    <input type="hidden" name="_flowExecutionKey" value="${flowExecutionKey}"> 
    <input type="submit" class="button" name="_eventId_search" value="Search"> 
    ... 
</form:form>

Link 사용시는 아래와 같다.

단지 영감을 줄 정도만 요약했다.

SWF comes with 4 repository (storage) implementations

다음 세션을 듣느라 토비님의 중계가 끝나고 난 후 막 자려던 찰나에 Raible의 블로그를 통한 실황 중계가 시작되었다.

DDD 보다는 역시 그에겐 [TSE] Rapid Web Application Development with Rob Harrop가 흥미로운 모양이다. 세 개의 세션 가운데 망설이다가 롭 해럽의 세션을 선택한 사유가 흥미롭다.

맞다. 뭐든 곧 활용할 것이 아니라면 모르는 것이 약이 될 수도 있다.

아젠더에 대한 그의 긴 메모를 그대로 옮기는 것 대신에 흥미로운 부분만 요약해본다.

Basic Tool Set

Rob recommends IDEA. 흠... Jetty is your friend! It allows you to rapidly deploy, it's resilient to hot deploy, starts everything in about 2 seconds and integrates with everything.

IDEA와 Jetty라... 일단 Jetty는 조만간 시도해봐야겠다.


Accelerating Spring MVC development

Rob이 SimpleFormController을 권장하지 않는 점이 흥미로웠다고 한다. Spring MVC에 처음이라면 차라리 SFC를 배우지 말고 바로 Web Flow를 쓸 것은 권장했다고 한다.

몰랐던 내용이다. 그리고 CoC를 위해 기억해둘만한 것

more..

Ruby 연동에 관한...

<lang:jruby id="stocklistController"
  script-source="WEB-INF/script/StocklistController.rb"
  script-interfaces="org.springframework.web.servlet.mvc.Controller"
  ... />

Raible의 요약을 옮겨본다.

Summary: Rapid Development with Spring MVC

• Use a project template: Build your own (simply create a ZIP file) or use Maven 2 archetypes.
• Make sure you can deploy quickly and frequently: Jetty is the way to go here.
• Build deployment into your build script: slapped wrists for using Tomcat Manager!
• Adhere to a code/test cycle: create mock tests to test error conditions. Use integration tests to verify end-to-end functionality.
• Code by Convention reduces repetition and increases uniformity.
• Dynamic languages: rapid prototyping, take advantage of additional language features
• JSP form tags: Largely replace <spring:bind/>

Exploiting Web Flow

왜 굳이 Web Flow를 써야 하는가?

Web Flow의 핵심 컴포넌트

폼 컨트롤이나 위저드에 비해 Web Flow의 강점은 테스트라고 한다: AbstractXmlFlowExecutionTests



Cool tools to save you time

• SiteMesh: Apply site-wide formatting, use it in conjunction with a CSS Framework (Rob is using the same one that AppFuse does - Mike Stenhouse's CSS Framework).
• AspectJ: Great for adding in filtering, monitoring and profiling.
• Jamon: Great in conjunction with AspectJ.
• JMX: Adds in management functionality.

토비님이 주로 DDD 세션을 듣기 때문에 Raible의 글을 보충역할을 해준다.

댓글 보기

책상 한켠에 자리한 카카오 두 통. 보통 56%라고 불러줘야 맛(?)을 느낄 수 있다. 언젠가 모임에서 한 친구가 들고 왔을 때는 그저 하나의 음식물에 지나지 않았다. 그 친구가 72%가 어떻고 99%가 어떻고...

신경 쓰지 않고 들었지만 그런 정보는 바로 복사가 되는 모양이다. 우유를 사러 간 슈러 카운터에 잔뜩 싸인 56%를 보니 왠지 72%나 99%를 찾아 보게 된다. 그후에도 서너 번 카운터에 노출되고 나니 56%와 함께 72%도 사게 되었다.

그 친구가 그랬던 것처럼 나도 어처구니 없이 전파에 나선다. (지금 생각해보면 그런 행동 양식의 복사는 놀라운 일이다.) 동생에게 72%를 내밀고 자랑을 한다. 동생 역시 56%는 먹어보았다고 한다. 그리고 보니 2,3일 전에 사무실에서 누군가 99%를 맛보라고 준 기억이 난다. 별로 중요하지도 하는 수치가 정확한지 한참 고민하게 된다. 동생이 65%라고 할 때 56%라고 수차례 정정한 기억이 떠오른다. ㅡㅡ^

어제인가 명록이에게 밥주고간 분은 메이지 카카오라는 일산을 즐기신다. 88%와 99%. 내가 구매한 초컬릿은 복사기 제조사는 아니자만 복사로 유명한 회사의 제품이다. 아마도 메이지의 영향을 받았나 보다 하고 생각한다.

순식간에 두통을 먹어치우고 나서... 다행히 의도된 FAD에 개입된 상황을 인지하고 나니... 자유로운 상태가 된다. 왠지 꼭 또 사와야 할 것 같은 강박관념은 자연스럽게 소멸 되었다. 항상 내가 무언가 선택할 수 있는 상태라고 느끼는 것은 상당한 착각이다.

가족들과 둘러 앉아 본 TV 프로에서 발로 비즈 공예를 하는 장애인이 출연했다.
보는 사람도 불편하기 이를데 없는 자세로 구슬을 한땀 한땀 꿰는 일이 숙련된 여성이다.
워낙에 밝게 웃는 모습은 내게 아름다움이란 무엇인가를 제대로 보라는 듯하다.

순간 부끄러운 마음이 들었다. 이런저런 일로 우쭐했던 마음이 있었기에...
사사건건 일터에서의 불평으로 하루를 소진한 나에게 묻는 것 같다.

생활에 임하는 자세 혹은 일을 하는 태도를 놓고 보면 과연 누가 장애인인가?

그 몸으로 비즈 공예에 이어 이젠 대학 검정고시를 준비한다니
나로썬 위대하다 라고 호들갑을 떨며 고개를 떨구는 역할이 주어졌다.
그리고, 내 자신이 의지박약의 장애인이라는 사실을 각인하게 되었다.

TV에선 소개하지 않았지만 환한 미소를 가진
위대한 비즈 공예가의 발가락은 수도 없이 바늘에 찔렸을 것이다.
환한 미소는 그러한 고통을 의연하게 견뎌낸 결과로 빚어진 것일테고...

과연 가능할까 하는 불신의 마음부터 피어나지만...
나 역시 앞으로 수백번 작심삼일을 경험하더라도...
다시 한번 마음을 고쳐 먹는다면... 근처라도 갈수 있을지 모르겠다.

언젠가는 이런 나약한 글은 쓰지 않고,
아름다운 모습을 보면 흐뭇한 미소로 지나칠 수 있기를 바라는 마음에 남긴다.

이것저것 욕심을 부리다 보면 실속 없이 시간과 에너지를 낭비하게 된다.
버려진 것들보다 더 무서운 것은 소모적인 시간이 습관으로 내 안에 자리한다는 사실이다.

블로그를 옮겨 새단장을 한지 세달이 조금 넘었다.
Spring 2.1 출시에 맞춰서 버전2.1을 달아볼까 하는
그야말로 뜬금 없는 생각을 하다가... 지난 블로그를 추억해본다.
2003/10/02 개설했다고 하니 3년이 지났다.
초반에는 축구에 관한 글을 메모했던 모양이다.
그리곤 당시 공부했던 것들을 산발적으로 메모하고, 그걸 정리해왔다.

몇일 동안 블로그를 쉬었다.
생활의 변화를 꾀하는 시점에서 블로그도 첨병 역할을 해야 할 것 같다.
그간의 습관과는 다르게 사용해서...
글쓰기의 달콤함은 좀 뺐기더라도...
보다 수렴형 블로그를 지향하고, 수렴형 생활로 새해를 맞아야겠다.

프로젝트를 하다 보면 현행화라는 것이 중요시된다.

현행화란 실제 상황과 관리 장표나 관리 데이터가 일치하게 만드는 것을 의미한다.
관리조직/팀에서는 최고의 관심사 중의 하나다.
현행화를 위해서 추적성을 확인해야 하고, 형상관리도 요구된다.

가령, UML 모델이나 엑셀 파일 형태의 관리 데이터와
실제 소스 코드의 동기화가 요구되는 경우를 가정해보자.

현장 경험이 적다면 RTE(Round-trip Engineering) 같은 것을 떠올려 볼 수 있다.
작은 시스템이라면 도전해볼 수 있겠지만
대규모 시스템이라면 툴 지옥^[각주:1]을 경험할 수 있다.

경험 많은 사람이라면 엑셀 시트나 코드 체계^[각주:2] 같은 것을 떠올린다.

또 한번 그야말로 가상상황을 만들어보자.

만일, 어떤 시스템이 개발 과정에서 모델을 만들어 놓고서
일목요연한 관리표가 별도로 필요하다고 엑셀 시트를 별도로 만들었다고 하자.
엑셀 시트가 유지보수 주체에게 전달되었다.

운영환경에서 코드를 하나 고치려면 영향을 받는 다른 코드를 찾아내야 한다.
인간의 존재 이유가 따분함을 극복하기 위해서만은 아니기 때문에.. ^^
그때마다 일일이 엑셀 시트를 보면서 수정할 소스 파일을 찾아나갈 수는 없다.

가상상황이지만 충분히 발생할 법한 이야기고,
엑셀은 그렇다 쳐도 별도의 UML 모델과의 연계까지 관리하라면...
변경 자체를 어렵게 하는 일이다.

필연적으로 업무 변화를 빠르게 하자는 경영이론들이 쏟아져 나오는데
이를 가능하게 하는 정보시스템에서는 변경을 어렵게 한다면 심각한 문제다.

...

- 점심을 먹으러 식당을 찾아 가는데 건물밖에 간판만 있고 실제 식당이 없는 경우가 있었다.

- 더불어 학생 시절에 SCM(Supply Chain Management) 관련한 수업을 들을 때
강사가 '상물의 분리'라는 모호한 용어를 쓰면서 실제 정보와 정보 시스템의 데이터의 불일치에서 나오는 현상을 열올려 설명하던 기억이 떠올랐다.

- 겨울인데 어떤 식당에서 '봄맞이 냉이국 추가'라는 문구를 본 기억까지 쏟아져나온다.

정보 시스템 만의 문제는 아니다. 현행화.. 답은.. 꾸준히 열심히 하는 것.
변화에 기민하게 대응하는 것. 매직은 없다.

기본 구성: 이클립스 SDK 3.2.1 + WTP 1.5.2-200610261841 [다운로드]

확장 플러그인
1) zip 파일 다운로드를 통해 설치해야 하는 플러그인
- Classpath Helper 1.2.2 <http://classpathhelper.sourceforge.net/>
- Copy Fully Qualified Class Name Plugin 1.1 <http://www.jave.de/eclipse/copyfully/index.html>
- JSEclipse 1.5.3 (12/19 갱신 및 개발사 Adobe로 인수)http://www.interaktonline.com/downloads/eclipse/100/JSEclipse_1.5.3.zip
- JUtils ToString Generator 2.0 <http://eclipse-jutils.sourceforge.net/>
- SwitchUnit 0.5beta

2) 업데이트 사이트를 통해 설치가 가능한 플러그인
- Spring IDE for Eclipse 1.3.6 [ http://springide.org/updatesite ]
- AnyEdit tools Plug-in 1.6.1.1 (12/19 갱신)
- JDepend4Eclipse Plug-in 1.1 [ http://andrei.gmxhome.de/eclipse/ ]
- Subversive SVN Team Provider 1.1 M8a [ http://www.polarion.org/projects/subversive/download/1.1/update-site/ ]
- Implementors plugin 0.0.15 [http://eclipse-tools.sourceforge.net/updates/ ]
- Metrics 1.3.6 [ http://metrics.sourceforge.net/update ]
- HTTP Headers 1.0 [ http://httpheaders.info/eclipse/update ]

발췌한 글 논지의 중심에 선 그림은 아니지만, 글 자체보다는 이 그림이 확 시선에 들어왔다.

모델러가 모델을 그릴 때는 메타를 염두해야 한다.
메타(Meta)라는 말을 알 필요는 적다.
더구나 거북한 단어니까 가급적 남용할 필요도 없다.
다만, 어떤 기준을 가지고 모델을 도출하고 표현해야 하는데 그 기준이 곧 메타라 할 수 있다.

UML로 객체지향 모델링을 하면 가장 기본적인 단위가 클래스이다.
클래스 역시 일종의 타입이 된다.
모델링을 하면 구체적인 타입으로 클래스 이름이 부여된다.
클래스라는 타입과 개별 클래스 사이에서의 구분이 요구되는 경우는 거의 늘상 일어난다.
가령, 한국과 개별 번지 사이에 구분이 필요한 것처럼 세상은 무척 복잡하기 때문이다.

그래서, UML에서 확장방안으로 제공하는 것이 스테레오타입(stereotype)이다.
그렇다고, 반드시 스테레오 타입에 메타 타입을 부여해야 할 이유는 전혀 없다.
모델은 의사소통을 위한 것이라는 대전제를 잊지 않는한 그야말로 아무거나 부여할 수 있다.
'왜 그런 것을 스테레오타입으로 부여하느냐'라고 묻는 분들에게 대답을 준비할 필요는 있다.

하지만, 효용성의 관점과 형식적 완성이 늘 부합하지는 않는다.

그래도 우리는 선택의 자유가 있다. ^^

나는 대개의 경우 둘 사이의 조화를 찾으려고 노력한다. 조화가 궁극에 다다르면 오늘 조엘이 올린 글에 소개된 다리처럼 우아함을 갖게 된다.



하지만, 소프트웨어 개발에서는 우아함만 고수하기엔 현실이 척박하다. 따라서, 둘 중 하나를 포기해야 할 상황이 발생하고... 나는 어느 때고 효용성을 택한다. 그리고, 그래야 한다고 떠들고 다닌다. (그래서, Pragmatic 시리즈가 너무 좋다. ^^)

어디까지나 순전히 가상상황이지만, 내가 어떤 제품을 쓰는데 클래스나 메소드이름을 영문과 숫자가 섞인 12자리 암호로 정해야 한다면 어떻게 할 것인가? 스테레오타입에 한글 클래스명을 넣겠다. UML만 공부한 사람이 '쟤는 UML 알긴 하는거야' 라고 코웃음 칠 수 있지만... 나는 UML을 졸업했으니까, 굳이 규정(disciplines)에 얽매일 필요는 없다.

규칙과 원칙(principle)이 충돌하면, 원칙을 새우기 위해서 새 규정을 만들어야 한다.