2010년 5월 18일 화요일

MSDN Magazine April, 2010 (1)

Editor's Note

Scott Guthrie on Visual Studio 2010

These are whirlwind days for Microsot ’s Scott Guthrie. A corporate vice president for the .NET developer platform, he oversees development of Visual Studio, the Microsot .NET Framework, ASP.NET, Silverlight, CLR and more. Many of those products are in the “milestone” phase, with major new versions being released, or about to be released. That includes, of course, Visual Studio 2010 and the .NET Framework 4, which take flight in April. Silverlight 4 is on the way, too.

펼쳐두기..


And you thought your job was busy.

펼쳐두기..


Because this issue covers the launch of Visual Studio 2010, it made sense to talk to the man most responsible for getting it out the door. And Guthrie had much to say.

Visual Studio 2010, he says, “is a pretty big release. From a feature set and capability set, it’s pretty ambitious.” The goal from the beginning, Guthrie explains, was not just to create new features, but to answer the question: “How do we make existing developers’ lives easier?” To that end, he says, Visual Studio 2010 includes “so many new features that don’t require you to learn a whole bunch of new things.”

Using multiple monitors is one example. It’s something that isn’t a knock-’em-dead upgrade, but can definitely enhance productivity. Guthrie explains why it excites him: “Most developers have a multimonitor setup at work. Visual Studio in the past didn’t let you leverage those monitors. In Visual Studio 2010, they can tear of any code-editing window and drop it into the second monitor. It makes navigating through large products a lot easier.”

There’s even more  stuffed into Visual Studio 2010. Silverlight, for instance, is fully supported for the first time—and Guthrie says Silverlight 4 will be as well, as soon as it ships. Visual Studio 2010 also marks the debut of F#, a new .NET Framework-based language for large-scale parallel programming, such as that done in scientific and financial settings.

It’s those kinds of enhancements that, when taken as a whole, will make developers more productive. Guthrie puts it this way: [There are] a lot of things that people go ‘Finally! Yes, great, I’ve been asking for that!’”

Guthrie also notes that making sure Visual Studio 2010 was stable and fast out the door led to the month delay in shipping; as you may remember, it was originally scheduled to ship in March. User feed-back on the beta resulted in the slippage, he says: “We got feedback that performance and stability weren’t where they should be. We moved the dates to make sure we had confidence that we were building the right product.”

Guthrie believes Microsoft succeeded. Visual Studio 2010, he says, “makes developers much more productive and writing code a lot more fun.”

Magazine Revisions

It’s not only Visual Studio 2010 and .NET that are getting upgraded this month. MSDN Magazine has experienced a number of changes. To begin with, we’ve incorporated the new Microsoft MSDN logo as the nameplate on the cover. The cover had not been updated in some time, and it’s always good to look at things in a new light. Plus,the “network wave” is way cool, I think. The more “artsy” readers may also notice that our color palette has been modii ed to align with the logo colors. It makes the magazine feel more cohesive.

A more subtle change on the cover is that we’ve increased the font size of the text. MSDN sports a text-heavy cover, and making it a little easier to read all that text is what we’re going for here.

Inside, the most immediate change you’ll notice is that we’ve added illustrations for our regular columnists like Charles Petzold, Dino Esposito, David Platt and others. h ese folks are our core contributors, and I hope that by seeing their images, you might feel a little more connected to them. After all, coders are people too!

If you’re using Visual Studio 2010, we’d love to hear from you on what you like—and don’t like—about it. We also want your feedback on the changes in the magazine—do they work for you? Should we have let  well-enough alone? What other changes would you like to see? Send all comments to mmeditor@microsoft  .com.

2010년 5월 12일 수요일

2) 서버버전 전문용어

서버버전 버전 관리 시스템에서 사용하는 전문용어를 정리하여 이후 혼동을 피하도록 할 필요성이 있다.

1. 저장소 (repository)
   : 버전관리시스템에서 작업한 모든 것을 저장하는 공간

버전관리시스템 마다 저장소로 사용하는 것이 다른다. 데이터베이스를 저장소로 사용하기도 하고 일반적인 파일들을 사용하거나, 데이터베이스와 파일을 혼용해서 사용하기도 한다.

2. 작업 복사 (working copy)
    :  저장소에서 가져온 파일을 로컬의 특정장소에 저장

다른 용어로 working directory or workspace 라고도 한다.

3. checking out
    : 작업을 위해 저장소에서 최초로 working copy를 하는 행위

4. export files
    : 저장소에서 단순히 export 시점에서의 파일들은 가져오는 행위

5. committing
    : 저장소에 working copy에 작업한 내용을 반영하는 행위

6. update
    : 저장소에서 반영된 변경된 내용을 working copy 반영하는 행위

때때로 update 용어와 check out 용어를 같이 사용하기도 한다.

7. externals
    : 프로젝트의 디렉토리 내에 또 다른 서브버전 저장소 위치를 포함시킴

8. file-specific numbering 과 repository-wide numbering
    - file-specific numbering : 변경된 파일 단위로 버전관리
    - repository-wide numbering : 논리적 변경 단위로 버전관리

서브버전은 repository-wide numbering 방식을 사용한다

9. tags
    : 특정 시점에 이름을 부여하여 기억하기 쉽게 함

10. trunk
    : 개발하는 코드의 중요 몸체이자 주요 라인을 의미하는 코드

11. lazy copies
    : branch를 만들기 위해 trunk에서 간단히 특정위치로 복사하는 행위

서브버전은 내부적으로 lazy copies을 구현하기 위해 원본에서 간단히 링크만을 저장한다.

12. strict locking
    : 동시 작업시 충돌을 피하기 위해 작업 중인 파일에는 읽기 권한만 파일에 부여하고 작업이 끝나면
      쓰기 권한을 부여하는 방식

13. optimistic locking
    : 동시 작업시 모든 작업자에게 쓰기 권한을 부여하지만 저장소 저장시 가장 최근에 변경사항을 업
       데이트 할 지에 대해 물어봐서 처리

서버버전은 optimistic locking 방식을 사용한다.




1) 서버버전 사용하기

우리는 프로젝트 진행하면서 생산되는 많은 코드를 관리하기 위해 의무적으로 버전관리 툴을 사용한다. 그렇지만 이에 대한 전반적인 학습부재로 제한적인 기능만을 사용하고 있기도 하지만 이 보다 더 심각한 문제는 필요성에 대한 자기 고찰이 없어 수동적인 사용만을 강요당하고 있다는 것이다.

이에 버전관리(version control) 또는 소스코드관리(source code control)에 대한 고민을 풀어 보고자 한다.

먼저 누구나 공감(?)할 수 있는 장점을 나열해 보자

1. 과거로의 여행의 자유 (불행하게도 미래는 안된다.. -,.-;;)
    - 자신의 작성한 코드의 한시간 전, 하루 전, 또는 한 달전으로 언제든지 롤백이 가능하다.

2. 코드의 보호
    - 팀단위로 작업시 한번씩 스팀팩 받아 본 경험이 있겠지만 열심히 만든 코드를 누군가 덮어쓰기를
      할 수 있는 여지를 만들지 않는다.

3. 코드의 발자국
    - 코드가 만들어진 역사를 편하게 볼 수 있다. ( 역사를 이해하면  미래를 예측할 수 있다나....)

4. 코드 작성과 동시에 제품 탄생
    - 약간에 과장이 있기는 하지만 하루하루 또는 일정한 단위로 자동 빌드 및 릴리즈가 가능한 시스템        에서는 반드시 필요하기는 하다.

5. 프로젝트 이력
    - 버전관리를 이용하면 프로젝트가 특정한 날짜에 어떻게 진행되고 있었는지를 알 수 있다. (개발자
       가 오늘은 몇라인을 코딩했을까? .. ^^!)

지금까지 글에서 버전관리를 위한 특정 프로그램을 언급하지 않았다. 이제 서브저번에 대해서 이야기 해보자. 왜 버전관리 툴롴써 서버버전을 사용하는 것일까?

서버버전 프로젝트는 CVS에 엄청난 경험이 있는 개발자들이 시작했다. 이들은 CVS 결점을 잘 알고 있었고 높은 성능과 현시대에 부응하는 버전 관리시스템을 설계했다.

서버버전의 특징적인 기능은 다음과 같다.

1. 서버버전은 파일들 뿐만 아니라 디렉토리와 메타데이터 까지 버전관리하는 객체로 본다.
   : 여기서 메타데이터는 파일과 디렉토리와 관련 있는 서버버전 프로퍼티 정의 파일이다. 따라서 이
     메타데이터가 관리됨으로써 서버버전이 어떻게 파일을 다루는지, 키워드 확장등을 광범위하게 제
     어 할 수 있다.

2. 서버버전은 atomic commit을 지원한다.
   : 서버버전은 사용자가 커밋을 하면 전체변화가 성공적으로 반영되든지, 아니면 취소되거나 롤백된
     다. 어중간한 상태는 없다. 이것의 이점은 모든 개발자가 저장소의 동일한 뷰를 바라볼수 있다는 것
     이다.  atomic commit 과정의 일부로써 서버버전은 모든 변경된 내용을 revision (= changeset) 이
     라는 불리는 것으로 그룹핑한다. 그리고 revision number로 할당한다. 이 그룹핑에 의해 많은 변경
     파일들이 하나의 논리적 단위로 관리될 수 있다.

3. 서버버전은 똑똑한 네트워킹을 지원한다.
    : SSH 지원, Apache Web Server 연동 지원등의 다양한 옵션과 효과적인 네트워크 프로토콜을 사
      용한다.

4. 부하가 적은 branching, tagging, Merging을 지원한다.
    : CVS의 경우 branching과 labeling은 서버에 접근해서 저장소의 모든 파일들을수정해야하는 부담
       스러운 작업이다. 이런작업을 효울적인 데이터베이스 모델을 이용하여 적은 비용으로 작업이 가
      능하다.

5. 서버버전은 다양한 플랫폼에서 운영가능하다.
    : 특히 윈도우 환경에서도 잘 운영되며, 다른 머신으로 이전 또한 한번에 가능하다.
      ( 진입장벽을 깨버린 중요한 요소이다. )

2010년 4월 12일 월요일

SpringSource tc server

▶ SpringSource tc Server Features.

1. Server Group Administration
   
2. Application Configuration Management

3. Advanced Diagnostics

4. Performance Monitoring and Diagostics

5. Professional Support

2010년 4월 1일 목요일

[방법론]MSF/CD

※ MSF/CD (Microsoft Solution Framework / Component Design)
=> 마이크로소프트에서 권고하는 컴포넌트 디자인 방향을 기반으로 한 설계 방법론







2010년 3월 10일 수요일

[03] 관련노트 셋

:: 참조문서 ::


★ OSGi 에서의 이벤트 시스템

OSGi 라이프사이클 레이어에서는 BundleEvent, FrameworkEvent를 서비스 레이터에서는 ServiceEvent라는 형태의 EventType객체를 정의하고 있다.

이벤트설명
BundleEvent번들의 Life Cycle 변경을 알리기 위한 이벤트
ServiceEvent서비스의 변경사항등을 알리기 위한 이벤트
FrameworkEventOSGi 프레임워크의 변경사항을 알리기 위한 이벤트

이 이벤트가 발생하면 번들컨텍스트에 각 타입에 대한 리스너를 등록할 수 있다. 이 이벤트들은 주로 OSGi의 동적인 환경을 이용하는 Extender를 개발할 때 주로 쓰이게 된다.

번들이 동적으로 설치되는 환경이라면, 설치할 때 각 번들마다 해줘야 할 일들을 Extender에 만들어 줌으로써 각 번들마다 각각 코딩할 필요가 없게 되어 중복된 코드를 줄이고 한 곳에서 관리할 수 있다.

※ Extender
Extender는 OSGi상에서 종종 사용되는 개념으로, 동적으로 설치되는 다른 번들/서비스의 설치/삭제 시 이벤트를 받아서 특정 동작을 수행하는 형태를 말한다. 특히 SpringDM이 Extender 개념을 아주 잘 활용한 예라고 볼 수 있다.

★ BundleEvent

BundleEvent는 번들의 라이프 사이클 변경을 알려주는 이벤트, BundleListener인터페이스를 구현한 객체를 생성하여 BundleContext.addBundleListener를 호출하여 등록한다.

public class MyListener implements BundleListener {
    public void bundleChanged(BundleEvent event) {
    }
}

또는 Activator에 BundleListener 인터페이스를 구현하면 간단히 핸들링 할 수 있다.

public class Activator implements BundleActivator, BundleListener {

    public void start(BundleContext context) throws Exception {
        context.addBundleListener(this);
    }

    public void stop(BundleContext context) throws Exception {
        context.removeBundleListener(this);
    }

    public void bundleChanged(BundleEvent event) {
        ...
        ...
    }
}

번들을 설치할 때는 INSTALLED ▷ RESOLVED ▷ start() 메소드 실행 ▷ STARTED 순으로 이벤트가 진행된다. 번들을 삭제할 때는 stop() ▷ STOPPED ▷ RESOLVED ▷ UNINSTALLED 순으로 이벤트가 진행된다.

★ FrameworkEvent

FrameworkEvent는 프레임워크에서 일어나는 주요 이벤트로, BundleEvent와 마찬가지로 아래와 같이 FrameworkListener 인터페이스를 구현한 객체를 생성한 후 BundleContext.addFrameworkListener메소드를 호출하여 등록한다.

public class MyListener implements FrameworkListener {
    public void frameworkEvent(FrameworkEvent event) {
    }
}

FrameworkEvent는 일반적으로 잘 일어나지 않는 이벤트이며, 다음과 같은 이벤트가 존재한다.

번호이벤트설명
1STARTED프레임워크를 시작할 때 발생하는 이벤트
2ERROR프레임워크가 오류가 발생했을 때 던져주는 이벤트
3PACKAGES_REFRESHED각 번들이 임포트/익스포트하는 패키지가 리프레시되었을때 발생하는 이벤트
4STARTLEVEL_CHANGED각 번들의 ServiceLevel이 변경되었을 때마다 발생하는 이벤트
5WARNING번들에 관련하여 경고가 있을 때 발생

★ ServiceEvent

ServiceEvent는 서비스가 등록/수정/삭제되었을 때 알려주는 이벤트로 BundleEvent/FrameworkEvent와 마찬가지로 ServiceListener를 등록하면 프레임워크로부터 받을 수 있다.

public class MyListener implements ServiceListener {
    public void serviceChanged(ServiceEvent event) {
    }
}

이벤트설명
1REGISTERED서비스가 등록된 후에 발생하는 이벤트
2MODIFIED서비스가 변경된 후에 발생하는 이벤트
3UNREGISTERING서비스가 삭제되기 전에 발생하는 이벤트

초기 OSGi 설계당시에는 ServiceListener를 구현함으로써 각 번들은 자신이 원하는 서비스가 등록되었는지를 동적으로 알아내어 사용할 수 있었지만, 지금은 ServiceTracker를 이용하면 간단히 자신이 원하는 서비스에 대한 Tracking이 가능함으로 ServiceListener는 이제 별도 의미가 없어졌다.

★ OSGi 애플리케이션 이벤트

기존 자바에서 사용하던 일반적인 리스너 객체는 아래와 같은 방식이다.


그림1. 일반적인 리스너 객체

▶ 절차

1. 이벤트를 받고자 하는 Client가 이벤트 리스너를 생성해서 이벤트를 실제 생성하는 이벤트 객체에 자신을

   등록

2. 이벤트 소스는 OSGi 프레임워크가 되고, 작성한 번들의 액티베이터가 이벤트 리스너이다.

3. Add Listener 함수에서 이벤트 소스는 전달받은 이벤트 리스너들은 자신이 관리하는 리스너 객체 리스트

    에 추가한다.

4. 이벤트소스는 이벤트 발생시 이벤트 객체를 생성하고, 자신이 관리하는 리스너 리스트에 있는 모든 리스너

    객체들의 handleEvent 메소드를 호출하여 이벤트가 발생했음을 통보


위와 같은 구조는 자바에서 많이 사용하는 구조로 AWT와 같은 데에서는 매우 많이 쓰이고 있다. 하지만 OSGi 환경에서는 약간 부담이 되는 구조이다.

문제1. 각각의 이벤트와 리스너를 위해 클래스 또는 인터페이스를 작성해야 하는데, 클래스 개수가 늘어나는
         것은 관리상으로나 성능상으로나 문제가 있다.

문제2. 대부분의 경우 이벤트 리스너를 여러 개 관리(Stored Event Listeners)해야 하므로 이벤트 소스마다
         이를 저장하기 위한 컬렉션 개체가 하나씩 필요

문제3. 동적인 OSGi에서는 이벤트소스나 이벤트 리스너가 언제라도 없어질 수 있으므로, 이벤트 리스너 번들
         이 제거되었을 때 이벤트 소스에서 삭제하는 역할이 반드시 필요하며, 이벤트 소스는 매번 이벤트 리스
         너 존재여부를 체크해야 한다.


상기와 같은 문제로 OSGi에서는 주로 화이트보드 패턴을 이용한 이벤트 전달방식을 사용한다.



그림2. 화이트보드 패턴

화이트보드 패턴은 OSGi 프레임워크의 서비스 레지스트리를 이용하는 것으로, 각각의 이벤트 소스들에 이벤트 리스너를 등록하는 방식이 아니라 이벤트를 받고자 하는 번들이 이벤트 리스너를 서비스 레지스트리에 등록하고 이벤트 소스는 이벤트를 발생하고자 할 때, 서비스 레지스트리에서 이벤트를 받은 리스너들을 가져와서 이벤트를 던져주는 방식이다.

장점1. 이벤트 소스와 이벤트 리스너 사이의 직접적인 의존관계가 없다.

장점2. 이벤트 리스너가 모두 서비스 레지스트리에 등록되므로, 관계가 외부에 공개되며 통합적인 디버깅 툴
         의 지원이 가능하다.

장점3. 이벤트 리스너에 대한 다양한 테스트가 가능하여 개발작업이 용이하다.

장점4. 공개된 레지스트리를 이용하게 되므로, 이벤트소스나 이벤트 리스너 양측의 소스코드양이 줄어든다.

★ Event Admin 서비스

화이트보드 패턴은 쉽게 사용할 수 있지만 여전히 문제점이 남아 있다.

문제1. 이벤트 소스와 이벤트 리스너가 완벽히 분지되지 않는다. 즉, 이벤트 소스가 특정한 리스너, 특정한 이
         벤트 객체를 알고 있어야 한다는 것은 변함이 없다.

문제2. 서비스 레지스트리로부터 리스너 서비스를 얻어오고 트래킹하는 등의 코드를 이벤트 소스에 추가해야
         한다.

상기와 같은 문제점을 해결하고자 추가된 서비스가 OSGi Event Admin이다.




그림3. Event Admin 서비스

설명1. 각 번들은 Event Admin 서비스가 제공하는 EventHandler라는 인터페이스를 구현하여 이것을 서비스  
        레지스트리에 등록한다.

설명2. 이벤트 소스 번들에서 이벤트를 생성하여 Event Admin 서비스에게 Event를 보낸다.

설명3. Event Admin 서비스가 이벤트를 받은 시점에 등록된 이벤트 핸들러들의 스냅샷스냅샷을 만든다는 의미는, 이벤트를 받았을 떄 마치 사진을 찍듯이 등록된 이벤트 핸들러들의 리스트를 복사해두고 전달을 시작하고, 전달하는 작업 중간에 새로운 핸들러가 등록이 되더라도 그 핸들러는 현재 전달중인 이벤트를 받을 수 없다. 을 만들고 그 이벤트
         핸들러들에게 이벤트 객체를 전달한다.


상기와 같이 Event Admin 서비스를 구현한 Equinox 구현체는 org.osgi.service.event에 들어 있다.

★ Event Object


이벤트 객체는 다음과 같은 2개의 속성을 가진다.

1. Topic

이벤트 타입을 표시하기 위한 주제 속성. [주로 Event Listener들이 자신이 원하는 이벤트만 받고자 할 때 필터링시 사용]
- '/'로 분리된 Reverse Domain 형태의 계층 구조 스트링을 사용
- 일반적으로 fully/qualified/package/ClassName/ACTION 형태의 구조를 가진다.

2. Properties

이벤트에 대한 추가적인 속성을 가지는 컬렉션 개체.
다음은 주로 사용하는 속성들이며 이 상수에 대한 정의는 org.osgi.service.event.EventConstants에 정의


값의 형식키 이름 문자열속성 상수설명
BUNDLEbundleBundle해당 이벤트와 관련된 번들
BUNDLE_IDbuild.idLong번들의 ID
BUNDLE_SYMBOLINAMEbundle.symbolicNameStringManifest에 정의된 번들의 SymbolicName
EVENTeventObject이벤트 재전송을 위해 쓸 수 있는 현재 이벤트 객체 자체
EVENT_TOPICevent.topicsString[]이벤트가 해당하는 Topic 값, Event개체의 topic 변수와 중복되는 값이지만, 필터링할 때 사용할 수 있도록 Properties안에도 들어 있다.
EXCEPTIONexceptionThrowable발생한 Exception 또는 Error 개체
EXCEPTION_CLASSexception.classStringException 클래스 이름
EXCEPTION_MESSAGEexception.messageStringException.getMessage()에서 얻어지는 Exception 문자열
MESSAGEmessageString이벤트의 내용을 설명하는 문자열
SERVICEserviceServiceReference등록되거나 수정된 Service에 대한 ServiceReference
SERVICE_IDservice.idLongService의 ID
SERVICE_OBJECTCLASSservice.objectClassString[]서비스의 실제 객체인 objectClass의 이름배열
SERVICE_PIDservice.pidString프레임워크에서 부여한 Service의 Persistent ID값
TIMESTAMPtimestampLong이벤트가 일어난 시간

EventHandler를 등록할 때 EVENT_TOPIC과 EVENT_FILTER 두 가지 옵션을 통해 필터링이 가능하다.

1. EVENT_TOPIC

'*'을 지정하면 모든 이벤트를 받을 수 있으며 'org/osgi/framework/BundleEvent/*'과 같이 세부 항목에 '*'을 지정하면 그 패키지에 해당하는 모든 이벤트를 받을 수 있다. 중간에는 '*'이 올 수 없으며 배열형태로 원하는 이벤트만 지정하여 받을 수도 있다.

2. EVENT_FILTER

RFC2254 "The String Representation of LDAPLDAP(Lightweight Directory Access Protocol)은 TCP/IP 위에서 디렉토리 서비스를 조회하고 수정하는 응용프로토콜  Search Filters." 에 기반한 필터 문자열을 지정하여 원하는 속성의 이벤트만 필터링이 가능하다.

예를 들면 SymbolicName이 Google인 것만 : bundle.symbolicName=*.Google로 지정하면 되며 번들 id가 4이하 중에서, symbolic name에 eclipse인 것은 (&(bundle.id<=4)(bundle.symbolicName=*eclipse*))라고 하면 된다.

★ Event Admin에게 이벤트 보내기

Event Admin 서비스에게 이벤트를 전송하기 위해서는, 서비스 레지스트리로 부터 Event Admin 서비스를 가져와야 한다. 이를 위해서는 BundleContext.getServiceReference 함수나 4장에서 배운 ServiceTracker를 이용해서 손쉽게 가져와서 사용할 수 있다.

Event Admin의 이벤트 전송 함수는 sendEvent와 postEvent 두 가지가 있다.

1. sendEvent : 동기 전송

sendEvent를 호출할 때, 해당 Event를 받는 쪽에서 모든 처리를 할 동안 호출하는 쪽으로 리턴되지 않는다. 이 경우 받는쪽에 문제가 발생하면 호출하는 쪽까지 위험하므로 반드시 스레드 처리를 해주는 것이 좋다.

2. postEvent : 비동기 전송

postEvent를 호출할 때는 EventAdmin 내부에서 해당 Event를 받을 핸들러로 보내는 비동기처리가 되므로,
postEvent를 호출하는 쪽으로 바로 리턴된다.