http://KingCrap.com 으로 옮겼습니다. http://acroama.isblog.net 이 블로그는 개인블로그이며, 여기에 혹시 있을지 모를 정치적 성향이나 논점은 제가 속한 회사 방침과 무관하며, 전적으로 개인적인 것임을 밝힙니다. ko Sat, 04 Sep 2010 05:17:36 +0900 isBlog 0.9.0 http://acroama.isblog.net http://acroama.isblog.net/Uploads/BlogSetting/isblog_rss.gif http://KingCrap.com 으로 옮겼습니다. 블로그 이전합니다 http://acroama.isblog.net/blog_post_69.aspx  호스팅 서비스가 불안정하여 자주 접속이 안되어 티스토리에 둥지를 다시 틀었습니다.
몇가지 포스트만 가지고 떠납니다.

 http://kingcrap.com 

지속적인 관심 부탁드립니다.

]]> 오롯이 Fri, 22 Feb 2008 05:46:04 +0900 자바와 C#에서의 polymorphism http://acroama.isblog.net/blog_post_68.aspx
자바의 경우
자바의 경우 인터페이스를 구현하거나 다른 클래스를 상속할 경우 항상 virtual로 간주되기 때문에 virtual이라는 키워드가 존재않는다. 따라서 원하지 않는 virtual 적인 행위를 방지하기 위해 final이라는 키워드를 사용할 수 있다. 

 클래스의 상속을 막기 위해 final class로 선언할 수 있고
 public final class Babo { ... }

 상속은 허용하되 일부 메소드의 override를 막기 위해 final 메소드로 선언할 수 있다.
 pubilc class Babo
 {
    public final void tellMe() { ... }
  }
   
 참고로 final은 멤버 변수를 상수로 선언하기 위해 사용되기도 하고
 public class Babo
 {
    private final String name = "바보";
 }

 메소드의 파라메터에 로컬 변수로 선언되기도 한다.
 public void tellMe(final String name) { ... }


 닷넷의 경우 (C#의 경우)
 C#의 경우에는 지난 번에 포스팅했듯이 인터페이스의 구현과 클래스간의 상속을 구분한다. 인터페이스의 구현은 polymorphism 성격을 띄지 않기 때문에 자식이 부모의 메소드를 override 할 수 없다. 또한 상속시의 경우에도 자식이 override 할 수 있는 것과 하지 못하게 할 것을 구분하기 위해 virtual 키워드를 쓴다. virtual 이 아닌 부모의 메소드는 override 할 수 없다.
 자바의 경우 처럼, C#에도 override를 방지하는 키워드 sealed가 있다. 즉, sealed 메소드가 있다. 하지만 자바와 조금 다른데, sealed 메소드는 반드시 상속을 받는 자식 클래스가 부모의 virtual 메소드를 override하면서 자신의 자식 클래스, 즉, 손자 클래스가 더 이상 override하지 못하도록 막는 역할을 한다. 반드시 override 하는 상황에서만 사용된다는 특징이 있다. 즉, 항상 sealed는 override와 함께 다닌다.

 조금 다른 얘기인데 재밌는 사실은...
  interface IMsg
  {
    void Message();
  }
  class Parent : IMsg
  {
    public virtual void Message()
    {
      Console.WriteLine("부모가 불렸네.");
    }
  }
  class Child : Parent
  {
    public sealed override void Message()
    {
      Console.WriteLine("자식이 불렸네.");
    }

C#에서 인터페이스 IMsg에 선언되어 있는 메소드 Message()의 IL 코드를 보면 abstract virtual로 자동 선언된다.
  .method public hidebysig newslot abstract virtual instance void  Message() cil managed

이 인터페이스의 메소드를 구현하고 있는 Parent 클래스의 Message() 메소드는 IL에서 virtual final로 선언된다.
  .method public hidebysig newslot virtual final instance void  Message() cil managed

하지만, 이 인터페이스를 구현하면서 해당 메소드에 virtual을 붙이면 Parent 클래스의 Message() 메소드는 IL에서 그냥 virtual로 선언된다.
  .method public hidebysig newslot virtual instance void  Message() cil managed

인터페이스를 구현한 Parent를 상속받은 Child 클래스의 sealed override Message() 메소드는 IL에서 virtual final로 선언된다. 즉, 더이상의 override는 불가하다.
  .method public hidebysig virtual final instance void Message() cil managed

 정리하면, C#에서도(??) 인터페이스의 구현시에 자동 virtual이 선언되나 final이 있기 때문에 virtual적인 형태를 띄지 않아 override가 되지 않는 것으로 추정되며, 구현 클래스에서 명시적으로 virtual을 붙이게 되면 final이 아닌 virtual로 선언되기 때문에 override가 가능하게 되는 것 같다. 또한 위에서 보듯이 이를 상속받은 자식 클래스에서 sealed 메소드로 선언해버리면 다시 vritual fianl이 되어 더 이상의 override는 불가능하다.

자바는 모든 것을 virtual적인 것으로 간주하여 풀고 final을 써서 필요한 부분을 막고, C#의 경우 모든 것을 일단 막고 virtual 키워드를 써서 필요한 부분을 풀고 ... 이런 것인가 ? ]]> 닷넷과 자바 polymorphism 오롯이 Wed, 30 Jan 2008 14:31:22 +0900 닷넷 프레임웍 리스트 - Beta http://acroama.isblog.net/blog_post_66.aspx 프레임웍을 구분하는 방법은 여러가지이나 간단하게 티어별로 구분하도록 한다.

프리젠테이션 티어 (웹)
1. ASP.NET MVC - 2008년 1사분기에 출시 예정이 ASP.NET 기반의 MVC 프레임웍. 마이크로소프트 제공
   - 소개
   - 다운로드
   - 포럼
2. MonoRail - 오픈 소스 Castle 프로젝트에서 만든 Rail와 유사한 MVC 웹 프로임웍
3. Maverick.NET - 자바 Maverick의 닷넷 버전으로 오픈 소스 MVC 웹 프레임웍, 업데이트 안됨
4. DotNetNuke - 포털 프레임웍에 가까움. 오픈 소스

비지니스 티어 (DI Container)
1. Spring.NET - 오픈 소스. 자바 Spring의 닷넷 버전. 대표적인 DI Container.
2. ObjectBuilder - Enterprise Library(EntLib)에 들어 있으며, EntLib, Composite UI Application Block 등에 사용된 DI Container
3. Windsor Container - 오픈 소스 Castle 프로젝트 일환
4. StructureMap - 닷넷에서 가장 오래된 DI Container. Martin Fowler가 있는 ThoughtWorks에서 프로젝트 진행한 결과물이 정제된 것이라고 함

데이터 티어
1. ADO.NET
2. LINQ to SQL - .NET Framework 3.5의 기본 기능. 엔티티와 테이블의 1:1 매핑. VS2008 툴 지원
3. ADO.NET Entity Framework (LINQ to Entity)
4. NHibernate - 자바 Hibernate의 닷넷 버전. 오픈 소스
5. iBatis.NET - 자바 iBatis의 닷넷 버전. 오픈 소스
6. Active Record - 오픈 소스 Castle 프로젝트의 일환. Active Record 패턴을 구현. NHibernate 기반이나 Configuration을 XML이 아닌 Attribute을 이용
7. LLBLGen Pro - 상용.
8. WilsonORMapper - 상용.
9. LightSpeed - 상용.
10. Codus - 상용.
11. Sooda - 폴란드에서 만든 오픈 소스 ORM 으로 폴란드에서는 구직시 도움되는 기술.
12. SubSonic - 오픈 소스 ORM. ASP.NET 3.5 Extension에 포함된 ASP.NET Dynamic Data 기능 구현에 사용됨. 

기타 범용 프레임웍 (혹은 라이브러리)
1. Enterprise Library - MS patterns and practices(PnP) 팀이 Codeplex를 통해 제공. 캐싱, 로깅, 암호화 등등
2. NVelocity - 템플릿 엔진. 진전이 없어 Castle 프로젝트에서 별도 진행
3. NUnit - 단위 테스트
4. NAnt - 빌드
5. log4net - 로깅
6. CruiseControl.NET - 통합 빌드, ThoughtWorks에서 개발한 오픈 소스]]> 아키텍처 Framework 오롯이 Tue, 29 Jan 2008 20:34:01 +0900 구글과 IBM, Office Open XML을 지원하다. http://acroama.isblog.net/blog_post_67.aspx Open Office 로 부터 스키마 등을 추출하여 표준화시킨 ODF (Open Document Format)가 있다. 이 두 문서 표준은 기본적으로 각각 표준 XML 스키마가 존재하고 관련된 화일(텍스트, 이미지 등)을 Zip 포맷으로 묶어 단일한 파일로 저장하는 등 비슷한 형태를 취하고 있다. 크게 보면 결국 서로 다른 스키마 사이의 변환이라고 봐도 무방하다. 다만, 여기에 태생적인 특성이 있어 OOXML은 지금껏 만들어진 방대한 분량의 마이크로소프트 오피스 문서 포맷과의 호환성을 가지고 있고, ODF의 경우는 이런 면에서는 그다지 신경을 쓰지 않는 듯하다. 또한 OOXML이 문서를 관장하는 문서 수혜자 즉, 여러 나라 도서관, 애플, 도시바 등이 주축인 반면, ODF는 문서 처리기를 만드는 벤더 위주라는 차이도 있다. 또한 관점의 차이이긴 하나, OOXML이 자체적으로 완벽한 문서 포맷을 추구하는 반면, ODF는 여타 다른 표준에 의존하는 형태를 취하고 있다. 이 두 표준은 각각 ECMA, ISO 표준이라는 즉, 공개 표준이라는 특징을 가지고 있다.

 OOXML은 마이크로소프트 오피스 만이 유일한 구현이라고 잘못 알려져 있으며, 현재 OOXML을 지원하는 제품으로는 몇 가지만 들면, MS Office 2007, Corel Office, Altova XML Spy, PythonOffice, 썬의 스타오피스, 맥용 Neo Office, 리눅스 용 Gnumeric (스프레드쉬트) 등 플랫폼을 막론하고 다수의 제품에서 지원하고 있다. 또한 한글과 컴퓨터 자회사인 ThinkFree 오피스도 OOXML을 지원하기로 하였다.
 근래에 구글과 IBM도 OOXML을 지원하는 것으로 나타났다. 구글에서 검색을 하면 마이크로소프트 오피스 2007의 문서 내용까지도 함께 검색이 되고 이 결과를 온라인에서 보여주는 기능("HTML 버전")에서 마이크로소프트 오피스 2007의 화일까지도 브라우저에서 렌더링이 되는 것으로 나타났다.

IBM의 경우 Lotus Quickr collaboration platform, Websphere Portal for z/OS mainframes,  DB2 Content Manager v8.4,   DB2 9 pureXML database 등 제품차원에서 OOXML을 지원하는 것으로 나타났다.
http://www-1.ibm.com/support/docview.wss?uid=swg21288972

 얼마전 IDC가 OOXML에 아주 우호적인 리포트를 발표한 적이 있다. 여기에 대해 ODFA (Open Document Format Alliance) 차원에서 반박문을 발표하기도 하였다. 완전히 동일한 목적을 가지고 동일한 기능을 하는 것이 아닌 서로 다른 배경과 목적을 가진 두 개의 문서 표준에 대해 일반적인 기준으로 비교하는 것이 무리가 있을 수 있으며, 두 문서 표준에 대한 깊은 지식없이는 단편적인 스키마 수준에서의 기능 비교밖에는 이루어질 수 없다. 또한 지속적으로 변하는 두 표준의 스펙에 대해서, 그리고 XML이라는 스키마의 특성상 무한 확장성을 염두해 둔다면 비교가 어쩌면 무의미할 수도 있다. 두 스펙에 관한 비교를 원하는 사람을 위 링크를 참조하기 바란다.

 관련 기사
- http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9058038
- http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=311757&intsrc=news_ts_head
- http://blogs.zdnet.com/microsoft/?p=1121
]]> OpenXML OpenXML ODF 오롯이 Tue, 29 Jan 2008 10:28:34 +0900 초보 운전 경험기 http://acroama.isblog.net/blog_post_65.aspx  출근 내내 자동차가 이상 신호를 보내왔다.
가장 먼저 희미해진 시계 글자는 당연하였고, 냉각수 온도 게이지가 힘겹게 기준선 이하에 매달려있는게 보였다. 
조금 지나자 ABS 경고등이 들어왔다. 오호, ABS가 전자 어쩌구 하더니 전기공급이 원활치 않으니 문제가 발생할 수 있나보다.. 마치 하나 하나 알아가는 것 마냥 뿌듯하기 까지 했다.
잠시후, Air Bag 경고등이 들어왔다. 오호.. 에어백까지 전기가 부족하면 안되는 구나..
잠시후, 라디오가 제멋 대로 꺼졌다가 약간 전기가 모아 졌나 싶으나 다시 들어오고.. 또 나가고를 반복하고
잠시후, 속도계가 춤을 추더니 0으로 떨어졌다.. 우와 속도계 게이지도 전기 없으니까 이렇구나...
잠시후 눈에 들어온 건 언제부터인지 0를 가리키고 있는 RPM 게이지.. 모든 게이지가 전기 영향을 받네,,, 근데, 기름 탱크 게이지는 수동인가 ?.. 제대로 동작하는거 같네... 이런 생각을 하면서 계속 운전을 했는데,
헉.. 이거 브레이크 작동 안하면 ? 아냐.. 브레이크는 유압식인것으로 언젠가 들었으니... 괜찮을 거야.. 괜찮아... 음.

 그리고 믿는 구석이 하나 있었다. 배터리는 시동 걸때만 필요하고 일단 시동 걸리면 발전이 되니까 시동꺼질일은 없을거라고..이대로 쭉 카센터까지 가는 거야..

신호 대기... 차가 힘없이 재체기를 하더니 시동이 꺼지고 더 이상 움직일 줄을 모른다.
견인차 출동.. 이거 발전기 나갔네.. 헉.. 배터리외에 발전기까지...
카센터 기사... 운전석 등속 조인트도 나갔네.. 저거 보이죠..베어링이 다 보이네..  브레이크 패드로 갈아야하고..엔진 오일 간지도 5000넘은 거 같은데...허거덕..

평소, 때 되면 부품 갈아주어 견인차에 끌려가는 경우가 없었는데.. 오늘 제대로 걸렸다.

카센터 기사의 훈시를 정리하면, 
발전기는 통상 10만 Km 안팎, 15만 Km 정도까지 견딘다고 한다. 울 뷰롱이는 17만을 탔으니.. 갈만했다.
배터리는 통상 2~3년 마다 갈아준다. 이전에 우리 애 돌 전날 갈았으니 2년하고 5일 지났네..갈만했다.

배터리는 시동 걸때만 필요하고 일단 시동이 걸리면 발전기가 전기를 생산하여 전기를 필요로하는 각종 전자 장치에 배전을 하고 남는 전기를 배터리에 다시 보관한다고 한다. 따라서 배터리가 문제가 생기면 시동이 안 걸릴 뿐 가던 차가 꺼지지는 않는다고. 하지만 발전기에 문제가 생기면 전기 생산이 안되므로 전기를 필요로하는 전기 장치에 전기를 줄 수가 없어서 배터리에서 전기를 끌어온다고 ... 만약 배터리에 충전된 양이 목적지 까지 충분하다면 시동이 꺼지지 않겠지만, 오늘 처럼 성능이 시원치 않은 배터리의 경우 전기가 바닥나면 차가 설 수도 있다고... 

10년 경력의 운전 초보 일기]]> 새소식 오롯이 Wed, 23 Jan 2008 13:28:37 +0900 ADO.NET Entity Framework http://acroama.isblog.net/blog_post_64.aspx
 ADO.NET Entity Framework 다운받기
 ADO.NET Entity Framework Tool 12월 CTP

ADO.NET Entity Framework Design Tool은 VS2008에서 데이터베이스로부터 드래그 앤 드롭 방식으로 Entity Domain Model을 쉽게 작성할 수 있도록 해 준다. 이 툴의 사용법은 아래 싸이트에서 동영상으로 게시되어 있다.
 ADO.NET Entity Framework Tool 사용법

ADO.NET Entity Framework을 잠시 사용해보니, LINQ to SQL과 사용법이 유사하였다. LINQ to SQL이 1:1 매핑만을 제공하는 것과 달리 Entity Framework은 위의 Design Tool에서 엔티티를 데이터베이스 테이블 여러개에 매핑시킬 수 있으며 관련 Stored Procedure 조차도 툴에서 지정할 수 있다.

LINQ to SQL에서는 Entity Model이 System.Data.Linq.DataContext를 상속받아 partial class로 커스텀 DataContext에 매핑이 된다.
Entity Framework에서는 Entity Model이 System.Data.Objects.ObjectContext를 상속받아 역시 partial class로 커스텀 컨텍스트로 매핑된다.

LINQ to SQL에서는 Entity Model 상의 Entity가 두 개의 인터페이스를 구현한 일반 클래스로 생성되고 프로퍼트가 구현되어 있다.
Entity Framework에서는 Entity들이 System.Data.Objects.DataClasses.EntityObject를 상속받은 클래스로 생성되며 역시 관련 프로퍼티들이 구현되어 있다.

Entity Framework은 LINQ to Entity에서 처럼 LINQ의 특성을 활용할 수도 있고 LINQ 특성이 아닌 자체 API를 쓸 수도 있으며, LINQ to Entity는 Entity Framework을 쉽게 사용할 수 있는 또 하나의 Wrapper 같은 역할을 한다.

참고로, LINQ to SQL에서도 syntax상에서 지원하는 from, where, select 등의 구문을 통한 type-safe한 방식이외에도 LINQ Dynamic Query Library를 써서 실시간으로 query 문장을  string concatenation을 이용하여 만들어 낼 수 있다. LINQ Dynamic Query Library는 스캇 구슬리 블로그를 참고하길 바란다.
Scott Guthrie 블로그


LINQ to SQL과 Entity Framework (LINQ to Entity)의 동작 방식이나 생성되는 화일 및 클래스의 형태가 너무도 유사하여 하나를 알게 되면 다른 하나도 쉽게 적응할 수 있을 것으로 보인다. 아울러, 예전 LINQ팀이 밝혔듯이 LINQ to SQL에서 LINQ to Entity로의 자동 변환 기능도 제공할 예정이기에 LINQ to SQL에 투여하는 시간이 헛된 것은 아닐 듯 싶다.




]]> 새소식 LINQ Entity Framework 오롯이 Tue, 22 Jan 2008 17:10:55 +0900 [버튼 그룹 리포트] What's Up, .DOC ? http://acroama.isblog.net/blog_post_63.aspx
What’s Up, .DOC? ODF, OOXML, and the Revolutionary Implications of XML in Productivity Applications
 
 현재 마이크로소프트 주도로 ISO 표준으로 등록 프로세스를 밟고 있는 OOXML (Office Open XML)과, 썬, IBM이 주축이되고 Novell 등이 관련 소프트웨어를 만들고 있는 OpenOffice 기반의 ODF (OpenDocument Format)에 관한 심도 있는 분석 리포트이며, 마이크로소프트와 전혀 상관없이 독자적으로 발간한 보고서이다. 아울러 등록만 하면 누구나 다운로드 받을 수 있다.

 내용을 간단히 언급하면,
- Open XML은 ODF에 비해 상당히 표현 능력이  뛰어나고, IT 환경 친화적이며 애플리케이션 지향적이다. ODF보다 더 복잡하나 이것은 위의 기능에 비추어 봤을 때 필요이상으로 복잡한 것은 아니다.
- ODF의 기능을 살펴보면, ODF는 현실 세계의 엔터프라이즈 요구사항에 대해 불충분하며, 따라서 ODF의 사용처는 복잡한 문서 모델링에 대한 요구 사항이 없거나, 마이크로소프트 오피스 문서와 일치(통합)의 요구 사항이 없는 시나리오에 한정될 것이다.
- ODF와 Open XML은 서로 다른 디자인 요구 사항과 우선 순위를 위해 생겨난 복수 표준이며 서로 호환 가능한 포맷은 아니다.
- Open XML은 마이크로소프트 오피스 애플리케이션을 지원하는 환경적인 요인으로 인해 광범위하고 빠른 속도로 확산될 것이다.
- 저자의 포괄적인 권고사항은 Open XML의 광범위한 사용과 예외적으로 ODF를 사용하라는 것이다.

전체적으로 40페이지가 넘은 보고서이기 때문에 훨씬 방대한 내용을 담고 있다. 
관심있는 사람은 위 싸이트에서 다운로드 받아 살펴보기 바란다.]]> OpenXML OpenXML 문서표준 오롯이 Mon, 21 Jan 2008 16:05:43 +0900 오픈 소스 코드가 프로젝트를 위험에 빠뜨릴 수 있다 ?? http://acroama.isblog.net/blog_post_62.aspx
Is Hidden Open Source Code Putting Your Apps at Risk?

이 글에 언급된 오픈 소스로는 Apache Geronimo, JBoss Application Server, Libtiff, Net-SNMP, ZLIB 등이다. Apache Geronimo는 IBM(?)의 코드 기부로 시작된 무료 EJB 서버이며, JBoss는 얼마전 RedHat 인수한 역시 무료 EJB 서버이다. 

 소프트웨어 위험 관리 솔루션 회사인 Palamida의 조사 결과에 지난 한해 따르면 금융, 기술, 정부 등 다양한 분야의 엔터프라이즈를 조사하여 3억 라인 이상의 코드를 분석한 결과 위에 언급한 다섯 가지 오픈 소스에서 보안 위험성을 가장 많이 간과하며 애플리케이션이 구축되고 있음을 발견하였다.

 Palamida의 리포트는 오픈 소스가 상용 애플리케이션 보다 더 보안에 취약하다는 것을 지적한 것은 아니라고 밝히고 있다. 많은 프로젝트들이 시간이나 비용에 쫓겨 시스템을 구축시에 보안에 대해 전혀 고려하지 않고 진행되고 있으며 이로 인해 많은 위협 요소들이 발생한다고 지적한다.
 
 또 다른 견해로는 오픈 소스가 보안 위협 발생시 상용 보다 좀 더 빨리 패치 등이 나온다고 밝히고 있다. 

....

 개인적인 생각에, 오픈 소스를 중요한 애플리케이션 구축에 적용할 때는 본인이 꼼꼼히 점검해야 한다. 하나 이상의 오픈 소스를 써서 이루어진, 특히 OS에서부터 다양한 오픈 소스 모듈을 엮어 이루어진 애플리케이션의 경우, 해당 오픈 소스 모듈의 보안 위협 때문에 해당 모듈에 대한 패치가 나오기 전까지 전체 시스템이 위험에 빠질 수 있다. 또한 오픈 소스들은 대부분 그러하듯 사용하는 사람, 즉, 자기책임하에 해당 모듈을 사용하는 것이 일반적이다. 물론 유명한 것들은 커뮤니티도 많고, 유료 서비스를 제공하지만... 

 시장에서 특히 우리나라의 경우, 오픈 소스 하면 무엇이든지 용서가 되는 경향이 있다. 오픈 소스니까 좀 느려도 되고, 오픈소스니까 좀 불편해도 되고, 오픈소스니까... 오픈소스이니까... 오픈 소스를 쓰고 오픈 툴을 써서 불편하게 프로젝트하는 것이 오히려 근사해 보이기까지 한다. 자동화된 툴을 써서 GUI를 통해 각종 환경을 설정하면 초보 취급을 받고 커맨드라인에서 파이프 써 가며 다양한 커맨드 엮어 뭔지 모르지만 죽 화면 가득 띄우면 전문가다와 보이기 까지 한다. 예전 회사에 겪었던 것인데, 미국 본사에서 온 박사는 윈도우를 주로 사용하면서도 Cygwin을 통해 커맨드라인 열어 어떤 폴더까지 슬래시/백슬래시 써가며 찾아가 결국 노트 패드 열어 문서를 확인하는 것을 보면서 애처롭기까지 했다. 윈도우에 포팅안 된 많은 오픈 서버를 위해 Cygwin을 써서 테스트하는 것은 이해할 수 있지만...  혹은 세살 버릇 여든 간다는 속담처럼 한번 손에 익은 버릇일 수도... 

 오픈 혹은 오픈소스 (이 둘은 엄연히 다르다)는 특정 플랫폼, 특정 언어의 문제가 아니다. 오픈 소스의 위력은 이미 자바에서 확인되었고 닷넷 또한 오픈 소스의 활성화를 기대하고 있다. 대부분의 경우 상용이 먼저 시장을 점렴하고 이후 오픈 소스가 차차 세력을 넓혀 상용 소프트웨어의 자리를 빼았는 것이 일반적이다. 각종 라이브러리 시장이 그러했고 프레임웍(특히 각종 컨테이너형 프레임웍)이 또한 그러했으며, 개발 툴 또한 점차 그런 양상을 띄는 듯 보인다. 오픈과 상용 소프트웨어가 전달하고자 하는 가치가 같다면 상용 소프트웨어는 존재 근거를 잃게 되겠지만, 많은 상용 소프트웨어 업체들은 바로 차별화를 내세워 시장에서 오픈 소스와 경쟁하고 있는 것이다.]]> 새소식 오픈소스 보안 오롯이 Mon, 21 Jan 2008 11:05:07 +0900 Syndicated Client Experiences Starter Kit & Reader SDK 공개 http://acroama.isblog.net/blog_post_61.aspx NewYork Times Reader, Seattle P-I Reader 그리고 MSDN 잡지를 웹 브라우저가 아닌 전용 뷰어를 통해 볼 수 있는 MSDN Reader, Architecture Journal을 볼 수 있는 Architecture Journal Reader 등이 있다. 

 Syndicated Client Experiences Starter Kit & Reader SDK 구경하기

 MSDN Reader나 Architecture Journal Reader 등은 마이크로소프트의 잘 정리된 기술 아티클을 접할 수 있는 좋은 도구이다.



]]> SCE News Reader 오롯이 Fri, 18 Jan 2008 16:43:06 +0900 Visual Studio 2008 정식 출시 !!! http://acroama.isblog.net/blog_post_44.aspx 정식 출시되었다. 이는 .NET Framework 3.5의 출시를 의미한다. .NET Framework 3.5에는 이전에는 볼 수 없었던 많은 기능들이 포함되어 있다. 가장 큰 특징으로는 LINQ를 들 수 있는데, 이는 함께 출시된 C# 3.0, VB 9.0에서 언어 차원에서 지원하는 OR Mapping 도구라 할 수 있다. LINQ 중에 LINQ to SQL이 엄밀히 하면 OR Mapping 이라 할 수 있으며, 향후 출시될 ADO.NET Entity Framework기반의 진정한 의미의 OR Mapping 방안인 LINQ to Entities가 대기하고 있다. LINQ to SQL과 LINQ to Entities의 가장 큰 차이는 객체와 테이블(혹은 뷰) 간의 일대일이냐 일대다 인가의 차이이며 그 밖의 차이에 대해서는 이전 포스팅을 참고하면 좋을 듯 하다. ADO.NET에 대한 큰 틀의 변화의 완성을 내년 상반기 .NET Framework 3.5 SP1에 완성될 것으로 보인다. 이때가 되면, ADO.NET Entity Framework이 출시되고 이를 기반으로 현재 진행중인 Astoria 프로젝트도 정식 출시될 것으로 보인다. Astoria는 한마디로 데이터베이스의 데이터 정보를 웹 서비스로 노출하여 REST 기반의 클라이언트가 호출하여 로컬 데이터베이스처럼 사용할 수 있는 신개념의 데이터서비스이다. Astoria의 홈페이지를 참고하면 좀 더 상세한 정보를 얻을 수 있다.

 Astoria 홈 페이지 가기

 .NET Framework 3.5 Runtime 다운로드

 그 밖에 혁신적인 부분은 ASP.NET 3.5가 내장되어 AJAX 구현시 문제가 되었던 JavaScript에 대한 intellisense 기능이 추가되고 JavaScript 디버깅이 가능하게 되어 사용자의 개발 생산성을 획기적으로 증대시킬 것으로 보인다. 아울러 일반적인 intellisense 기능도 성능이 향상되어 좀 더 빠르게 화면상에 보여지며, 또한 대용량 파일을 편집시 느려지던 부분도 개선하였다.

 Visual Studio 2008은 현재 영문 버전만 출시되었으며 한글 버전은 내년 1월 중에 정식 발매될 예정이다. Visual Studio 2008 영문 버전은 현재 MSDN 가입자는 MSDN 싸이트에서 다운로드 받을 수 있으며, 무료 버전인 Visual Studio 2008 Express는 아래 싸이트에서 다운로드 받을 수 있다.

 Visual Studio 2008 Express 다운로드


 오늘 건대 새천년 기념관에서 DevDays 2007을 개최하고 있으며 여기에서 Visual Studio 2008의 기능이 일부 소개될 것으로 보인다. 
 

]]> 새소식 VisualStudio2008 .NET Framework 3.5 Astoria DevDays .NET Framework 오롯이 Thu, 17 Jan 2008 23:20:17 +0900 Visual Studio 2008 (코드명 Orcas) Beta 2 다운로드 http://acroama.isblog.net/blog_post_27.aspx  Visual Studion 2008 Beta 2와 .NET Framework 3.5 Beta 2 가 오늘 오후에 공개된다. 아울러, Silverlight 1.0 RC 도 내일이나 모레 공개된다. 이와 함께 세 제품에 대한 Go Live license도 진행된다. Go Live는 정식 버전이 아니더라도 개발사나 고객의 책임하에 Production에 활용할 수 있는 제도이다.
 Visual Studio 2008과 Silverlight 1.0을 통해 그 어느때보다 화려하고 인터랙티브한, 사용자 경험을 가져다 주는 웹 애플리케이션을 손 쉽게 개발할 수 있게 된다. 이번 베타 공개와 맞물려 Visual Studio 2008 에 Silverlight Add-in 모듈이 CTP(Community Technology Preview) 형태로 공개되기 때문이다.

  지금까지의 사용자 피드백을 통해 얻어진 의견을 바탕으로 Visual Studio 2008, .NET Framework 3.5, Silverlight 1.0 정식 버전이 올해말 안으로 출시될 예정이다. 
  참고로 Visual Studio 2008 공식 론치 행사는 미국 기준으로 2008년 2월 27일, 한국어 버전은 2008년 4월 초에 예정되어 있다. 이때는 Visual Stuio 2008, SQL Server 2008, Windows Server 2008이 동시에 론치된다.

  Visual Studio 2008 Beta 2는 아래 링크에서 다운로드 받을 수 있다.
http://msdn2.microsoft.com/en-us/vstudio/aa700831.aspx




]]> 새소식 VisualStudio2008 Silverlight .NET Framework 오롯이 Thu, 17 Jan 2008 23:19:29 +0900 Dependency Injection (DI) http://acroama.isblog.net/blog_post_5.aspx
DI를 제공하는 방식은 크게 두 가지로 나눌수 있다.(있었다?)

소스코드 자체에 대한 변형(닷넷:Attribute-based programming, 자바:Annotation)을 수반하여 컴파일 타임시 해당 지시어가 해석되어 적절한 코드가 삽입되거나 필요한 클래스가 생성되는 정적인 방식과, 소스코드에 대한 변형없이 DI에 대한 지시어가 XML 기반의 설정파일에 기술되어 런타임시에 Dependency가 해소되는 동적인 방식이 있다. (Spring framework)

하지만, 현재 자바나 닷넷의 경우 소스코드에 지시어를 직접 기술하는 것을 제공하고 그것이 표준으로 채택하고 있기 때문에 두 플랫폼에서 DI를 사용하는 방식은 전자의 Attribute-based programming (or Annotation) 형태가 된다고 할 수 있다. (좀 더 엄밀히 말하면, 닷넷의 경우 Attribute은 DI를 위해 사용되기 보다는 AOP (Aspect-Oriented Programming)를 위해 사용되고 있다. 물론 Attribute가 확장 가능하기 때문에 충분히 DI를 위해 사용될 수 있는데 예로써 ObjectBuilder가 있다.)


닷넷의 경우
 
기본적으로 System.ComponentModel namespace를 통해 lightweight, built-in 형태로 지원한다. 하지만, Enterprise Services와 달리 각종 서비스나 기능을 제공하지는 않고 단지 service injection 기능만을 제공한다. System.ComponentModel의 기능을 사용하기 위해서는 특정 인터페이스를 구현하여야 하는 단점이 있다.

자바에서 언어 차원에서 기본적으로 DI를 제공하기 시작한 것과 대조적으로 닷넷에서는 닷넷 프레임웍만으로 DI를 프로그래밍에서 사용할 수 없다. 다만, MS의 Patterns & Practices 팀에서 발표한 ObjectBuilder를 사용하면 Attribute 기반의 DI를 사용할 수 있다. ObjectBuilder가 제공하는 DI의 종류는 constructor injection, method injection, property injection이 있다. 
 

    using Microsoft.Practices.ObjectBuilder;

    public partial class MyForm : Form
    {
        private Customer _customer;
        private Foo _foo;

        // Constructor Injection
        [InjectionConstructor()]
        public MyForm(Customer customer) : this()
        {
            this._customer = customer;
        }

        // Setter Injection
        [Dependency( SearchMode = SearchMode.Local, CreateType = typeof(Foo), NotPresentBehavior = NotPresentBehavior.CreateNew)]
        public Foo Foo
        {
            set
            {
                this._foo = value;
            }
        }

        // Method Injection
        [InjectionMethod()]
        public void Display([Dependency(CreateType = typeof(Foo), NotPresentBehavior = NotPresentBehavior.CreateNew)] Foo foo)
        {
           System.Diagnostics.Trace.WriteLine(foo.Name);
        }
    }

ObjectBuilder는 CAB(Composite Application Block)에서 컨테이너(Shell)에, Enterprise Library 2.0에서는 Factory로서 이미 사용되고 있다.

참고로 닷넷에서 사용할 수 있는 DI기반 컨테이너로는 PicoContainer.NET, Maverick.NET Spring.NET(http://www.springframework.net) 등 자바 진영에서 널리 사용되고 있는 프레임웍의 닷넷 버전들과, Castle Project (http://castleproject.org)에서 만들어 배포하고 있는 MicroKernel, Winsor Container 등이 있고, 그외 실제 프로젝트에서 따온 StructureMap(http://structuremap.sourceforge.net)이 있다. (참고로 Castle Project에서는 웹 개발 프레임웍에 돌풍을 일으키고 있는 Rails의 닷넷 버전인 MonoRail도 제공하고 있다.)
 

자바의 경우

- EJB 3.0 (JSR 220)에서 EJB에 대한 DI를 정의하고 있고
- JAX-WS 2.0 (JSR 224)에서 Web services end-point 레퍼런스에 대한 DI를 정의하고 있고
- Common Metadata annotations for Java Platform (JSR 250)에서 각종 resource (DataSource, JMS, Mail, URL 등)에 대한 DI를 정의하고 있으며 이들 스펙을 포함하는 Java EE 5.0 은 당연히 DI를 포함하고 있다.

따라서 Java EE 5.0 compliant한 컨테이너는 DI를 지원해야 하며 현재 오라클 10g, JBoss 등은 이미 EJB 3.0을 지원하고 있기 때문에 DI를 지원한다고 할 수 있다.
Java EE 5.0에서 지원하는 형태로는 field injection과 setter injection이 있다.


field injection은

@Resource
private javax.sql.DataSource AdventureDB;

와 같이 field 선언앞에 바로 annotation으로 선언하며 별다른 정보가 없을시 field로부터 필요한 타입이나 이름을 얻어 처리한다.
 

setter injection은

@Resource
private void setAdventureDB(javax.sql.DataSource ds)
{
   adventureDB = ds;
}

private DataSource adventureDB;

와 같이 field 선언 앞에 setter를 정의하여 컨테이너가 자동으로 setter를 호출하여 injection한다.

@Resource외에도, ejb에 대한 Dependency 해소를 위해 @EJB를, 웹 서비스에 대한 Dependency 해소를 위해 @WebServiceRef를 제공한다.

@EJB LocalStatelessInterface sless;
public class MyComponent {
   @WebServiceRef(MyHelloService.class) HelloIF helloPort;

   public void myMethod() {
     // Use helloPort directly.
     helloPort.sayHello();  // Invoke an operation.
   }
}
 
Java EE 5.0 DI의 단점으로는 managed class에서만 지원하다는 점 즉, EJB나 Servlet과 같이 컨테이너가 관리하는 클래스에서만 DI를 지원 받을 수 있고 helper class의 경우 여전히 JNDI lookup을 사용하여야 한다. 닷넷과 달리 자바는 JDK 5.0이 되어서야 Annotation을 도입하였기 때문에 아직 이에 대해 개발자들이 익숙치 않아 예전 방식을 고수하는 경향이 있다.
 
DI 기반 오픈 프레임웍으로는 Spring 프레임웍, PicoContainer/NanoContainer 가 있다.
 

------------------------------------
 

DI에 대한 좀더 딱딱한(?) 문서를 원한다면 아래 파틴 파울러의 글을 추천한다.

http://www.martinfowler.com/articles/injection.html
]]> 닷넷과 자바 DI 오롯이 Thu, 17 Jan 2008 23:16:01 +0900 드디어 .NET Framework 소스 공개하다. http://acroama.isblog.net/blog_post_60.aspx NET Framework 소스 코드가 드디어 공개되었다. 지난 10월 Scott Guthrie가 블로그에 .NET Framework 소스 공개를 언급한 이후 많은 이들이 소스 공개 시점을 궁금해하였는데, 오늘 소스 코드가 공개되었다. 이미 알려진 바대로 Visual Studio 2008에서 실시간으로 .NET Framework의 소스코드를 다운 받으며 디버깅을 진행할 수도 있고 로컬에 심볼을 캐시하여 다운로드 시간을 줄일 수 있다. 현재 소스 코드를 볼 수 있는 .NET Framework 라이브러리는 다음과 같다.

.NET Base Class Libraries (including System, System.CodeDom, System.Collections, System.ComponentModel, System.Diagnostics, System.Drawing, System.Globalization, System.IO, System.Net, System.Reflection, System.Runtime, System.Security, System.Text, System.Threading, etc). 
ASP.NET (System.Web, System.Web.Extensions) 
Windows Forms (System.Windows.Forms)
Windows Presentation Foundation (System.Windows) 
ADO.NET and XML (System.Data and System.Xml) 

현재 LINQ, WCF, WF 등을 포함한 추가적인 라이브러리의 소스 공개를 추진중에 있다.

예전 발표때와 달라진 것은 라이선스에 관한 것이다. 윈도우 기반 애플리케이션 개발이 아니라면 본 소스 코드에 접근하여 볼 수 있는 권한이 원칙적으로 부여되지 않으며, 반대로 개발중인 애플리케이션이 윈도우 플랫폼 기반이라면 설사 .NET Framework의 기능과 유사하더라도 .NET Framework 소스에 접근할 수 있다. 본 라이선스는 read-only reference license 이다.

자세한 사항은 Scott Guthrie의 블로그와  Shawn Burke의 블로그를 참조하기 바란다.

Scott Guthrie 블로그 - 발표 내용 및 전반적인 사항
Shawn Burke 블로그 - 디버깅 방법 설명

]]> 새소식 소스공개 .NET Framework 오롯이 Thu, 17 Jan 2008 23:14:42 +0900 닷넷 프레임웍 소스 공개 예정 http://acroama.isblog.net/blog_post_37.aspx 마이크로소프트가 닷넷 프레임웍의 소스를 공개하기로 하였다. 닷넷 프레임웍 3.5와 Visual Studio 2008 출시에 즈음하여 소스를 공개하기로 한 것이다.  공개 범위는 Basic Class Library (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, System.Text, etc), ASP.NET (System.Web), Windows Forms (System.Windows.Forms), ADO.NET (System.Data), XML (System.Xml), and WPF (System.Windows) 등이다. 위 소스들은 Microsoft Reference License (MS-RL)에 동의하는 조건에서 접근이 허락된다. 
  또하나 주목할 만한 점은, Visual Studio 2008에서 설정만으로 위 소스들을 다운로드 받지 않고도 디버깅에서 사용할 수 있도록 마이크로소프트가 소스를 웹으로 서비스한다는 점이다. 

 자바는 초기부터 소스를 공개하여 많은 초보 개발자들로 하여금 소스 작성의 본보기로 사용하도록 하였고, 때로 말로 설명하기 어려운 소스 구현 부분(예. 객체 동일 여부 판단)을 직접 확인하면서 예를 들면 equals와 = 연산자의 쓰임새 차이를 확인할 수 있도록 하였다. 이제 닷넷도 프레임웍의 소스를 공개하면서 이러한 개발자들의 소스 작성 능력을 배가하고 및 베스트프랙티스를 직접 확인할 수 있으며 디버깅에서 이를 활용할 수 있음으로 해서 질높은 코드의 생성에 도움이 줄 것으로 보인다. 아울러 WPF 등 최신 기술에 대한 소스 공개를 통해 신기술의 확산에도 기여할 것으로 기대된다. 

  C#과 CLI (Common Language Infrastructure) 스펙은 이미 ECMA 표준으로 등록되어 공개되어 있어 노벨에서 리눅스 버전의 닷넷 운영 환경 (CLR)을 개발/배포하는데 활용하고 있다. 이번 닷넷 프레임웍의 소스 공개는 이보다 더 나아가 닷넷 개발 환경에 대한 이해를 높이고 개발자들의 개발 생산성 향상에 크게 기여할 것으로 보인다.

 좀 더 자세한 발표 내용과 웹 상의 닷넷 소스코드를 활용한 디버깅에 대한 사항은 Scott Guthrie의 블로그를 참조하기 바란다.

  Scott Guthrie 블로그 바로가기 ]]> 닷넷과 자바 닷넷 프레임웍 .NET Framework 소스공개 오롯이 Thu, 17 Jan 2008 23:10:13 +0900 DI Container 현황 http://acroama.isblog.net/blog_post_59.aspx 마틴 파울러는 이 두 용어의 쓰임새를 분명히 하고자 패턴 이름으로 DI를 쓰자고 했으나 여전히 시장에서는 IoC, DI, Hollywood Principle 등을 거의 같은 의미로 사용하고 있다. 
 현재 ASP.NET과 연동하여 비지니스 티어에 사용할 수 있는 DI Container로 주로 언급되는 것들로는 StructureMap, Windsor Container, Spring.NET, ObjectBuilder 등이 있다. 

ObjectBuilder는 Enterprise Library (EntLib) 2.0 부터 도입되기 시작하여 EntLib를 구성하는 각종 App Block들의 Factory 역할을 하는 DI 컨테이너이다. 다만, EntLib를 염두해두고 만들어졌기 때문에 외부 개발자가 애플리케이션 개발에 활용하기에 적합한 API 등을 갖추고 있지는 않았고 불편하다. 이점 때문에 많은 개발자들이 이의 개선을 요구하였고 마침내, ObjectBuilder를 대신할 새로운 Lightweight한 DI 컨테이너의 개발 계획이 발표되었다. EntLib v4 개발의 일환으로 발표되었지만, EntLib와는 함께 배포도 하고 혹은 DI 컨테이너 별도로 배포하여 다른 용도로의 활용을 쉽도록 하였으며 아울러 EntLib v4도 다른 DI 컨테이너와 사용될 수 있도록 할 예정이다. 자세한 사항은 아래 싸이트를 참조하길...

 Enterprise Library v4 개발


Spring.NET은 자바 진영에서의 성공에 힘입어 닷넷으로 포팅된 DI 컨테이너이다. Spring.NET은 Spring.Java와 마찬가지로 핵심이 되는 DI 기능이외의 모든 모듈은 쉽게 빼고 넣을 수 있어서 개발자가 원하는 부분만을 취할 수 있다. 아울러 대부분의 모듈은 이미 시장에서 그 품질이 인정된 다른 프레임웍이나 기술을 그대로 활용할 수 있도록 일종의 Wrapper와 같은 모듈만을 제공함으로써, 개발자가 갖고 있는 다른 프레임웍이나 기술에 대한 경험을 그대로 활용할 수 있는 융통성을 제공하고 있다.  Spring.NET은 다음과 같은 모듈로 구성되어 있다.
Spring.Core : DI 기능을 구현하는 Factory이자 Registry와 같은 역할을 한다.
Spring.Aop : DI와 더불의 Spring의 핵심 기능으로 불리며 AOP (Aspect-oriencted Programming)을 제공한다.
Spring.Data : ADO.NET에 대한 wrapper 기능을 제공
Spring.Data.NHibernate : NHibernate를 사용할 수 있는 wrapper 기능을 제공
Spring.Web : ASP.NET을 사용할 때 Page에 대한 DI 기능까지 제공한다.
Spring.Web.Extensions : 웹 서비스를 자바스크립트에서 접근할 수 있도록 해주는 기능이나, WCF 3.5에서는 ASMX 웹 서비스나, WCF 서비스에 기본 기능으로 제공해주고 있기 때문에 그다지 사용할 필요가 없을 듯..
Spring.Services : 일반 닷넷 클래스 (PONO - Plain Old NET Object)에 대해 자동으로 proxy 등을 생성해줌으로써 ASMX 웹 서비스, Enterprise Services, .NET Remoting 이 가능해도록 하는 기능이나, WCF가 이미 제공하고 있다. 다른 점은 Spring.Services는 각종 proxy등을 통해 기존 기술을 사용할 수 있게 해주는 것이나, WCF는 새로운 방식으로 더 나은 성능을 제공한다는 점... 예전 기술을 사용하는 경우가 아니면, 별로 효용이 없을 듯.
Spring.Testing.NUnit : 단위 테스트 NUnit 사용하도록 하는 기능

전반적으로 Spring.NET은 .NET Framework 2.0 기반으로 작성되었으며, 자바와 달리 닷넷의 빠른 변화를 따라잡지 못하는 면이 있다. ]]> 닷넷과 자바 DI Enterprise Library Spring.NET 오롯이 Wed, 16 Jan 2008 16:51:54 +0900 [재미삼아] C# 인터페이스와 자바 인터페이스의 차이 http://acroama.isblog.net/blog_post_58.aspx
// C#
  interface IMsg
  {
    void Message();
  }
  class Parent : IMsg
  {
    public void Message()
    {
      Console.WriteLine("부모가 불렸네.");
    }
  }
  class Child : Parent
  {
    public new void Message()
    {
      Console.WriteLine("자식이 불렸네.");
    }
  }

// Java
public interface IMsg
{
 void Message();
}
public class Parent implements IMsg
{
 public void Message()
 {
  System.out.println("부모가 불렸네.");
 }
}
public class Child extends Parent
{
 public void Message()
 {
  System.out.println("자식이 불렸네.");
 }
}

두 언어 중 하나만 아는 사람이 봐도 위 코드는 같게 구현되어 있음을 알 수 있다. 이 경우 아래와 같은 코드에 의해 찍히는 값은 어떻게 될까 ?
  IMsg message = new Child();
  message.Message();

C#의 경우는 "부모가 불렸네", Java의 경우 "자식이 불렸네." 이다.
Effective C# (빌와그너 저, 김명신 역)는 이렇게 적고 있다. C#에서 Inferface의 구현은 virtual 메소드의 overriding과는 전혀 다른 것이며, Interface는 그것을 구현한 클래스를 바라보는 제한된 창이며 계약이다.

Java와 같은 결과를 얻으려면 어떻게 할까 ?
우선, Child 클래스의 선언시 Interface를 구현하는 것으로 지정한다. 즉,
class Child : Parent, IMsg

자바와 마찬가지로 C#도 클래스의 단일 상속, 인터페이스의 복수 상속을 규정하고 있다.
혹은 다음과 같은 Parent 클래스의 IMsg 구현시 메소드를 virtual로 선언하고 Child에서 override하면 된다.

class Parent : IMsg
{
  public virtual void Message()
  {

class Child : Parent
{
  public override void Message()
  {

이 테스트에서 추론할 수 있는 것은 자바의 경우 Interface의 구현과, 상속을 통한 polymorphism이 동일하게 동작하는 듯 하며, C#은 이를 분명히 구분하고 있다.]]> 닷넷과 자바 Interface 오롯이 Fri, 11 Jan 2008 17:06:27 +0900 ASP.NET MVC Framework에 대한 기사 http://acroama.isblog.net/blog_post_52.aspx
ASP.NET on Rails, Finally


 기존 ASP.NET이 VB 스타일의 개발 방식, ViewState에 의존 등으로 인해 개발자들에게 유지보수성 높고 확장성 뛰어난 엔터프라이즈 웹 애플리케이션 개발하는데 있어서 대안을 찾게 만들었다면, 새로운 MVC 프레임웍은 쉬운 직관에 의한 매핑 방식 채택과 대부분의 개발자들에게 익숙한 MVC 패턴의 적용, 그리고 여러 다른 기술을 각 부문(MVC) 마다 적용할 수 있는 확장성을 제공하고 있다. 흥미로운 사실은 SubSonic 창업자를 고용하여 SubSonic의 scaffolding 기능을 ASP.NET에 추가하여 Rails의 Scaffolding 기능을 ASP.NET에서도 적용할 수 있게 하였다. 참고로 SubSonic은 창업자가 마이크로소프트에 고용되었더라도 앞으로도 계속 오픈 소스로 제공된다.

 개인적인 생각에, 이제껏 ASP의 성공과 VB 개발자의 충성도에 도취되어 마이크로소프트가 ASP.NET의 개발 방향에 대해 너무 느긋해하지 않았나하는 생각이 든다. 패턴 앤 프랙티스 책자에서도 오래전부터 Page Controller와 Front Controller의 차이와 이의 적용을 언급하면서 복잡한 분기문이 많아지고 확장성을 원할 때 Front Controller가 적합하다며 샘플까지 공개해놓고 지금껏 Page Controller 기반의 ASP.NET 자체만을 드라이브한 것도 아이러니한 모습이 아닐 수 없다. 다행히도 ASP.NET MVC의 등장으로 인해 오랜 개발자들의 숙원을 해소하였고,  오픈 소스의 접목이라는 모습을 함께 보여줌으로 인해 앞으로 닷넷 웹 개발의 방향성을 명확히 한 것이 의미 있는 일이라 생각한다. 오픈 진영을 끌어 안으려는 마이크로소프트의 적극적인 모습과 오픈 진영에 대한 닷넷 개발자들의 꾸준한 관심, 그리고 이를 통해 닷넷 개발 역량의 확대 및 시장의 확대야말로 지금 우리 닷넷 개발 진영에 필요한 일이라 생각한다.
]]> 새소식 ASP.NET MVC 오롯이 Wed, 09 Jan 2008 17:09:24 +0900 ASP.NET MVC Framework에 대한 Scott Guthrie의 첫번째 공개 강연 동영상 http://acroama.isblog.net/blog_post_57.aspx
 아래는 Scott Guthrie가 처음으로 ASP.NET MVC 프레임웍 대해 공개 강연한 동영상이다. 화질이 썩 좋지는 않으나 ASP.NET MVC의 배경이나 특징, 사용법 등을 쉽게 설명하고 있다. 언뜻 언뜻 비치는 코드가 현재의 CTP 버전과 조금 다른 듯 하다.

 Scott Guthrie 동영상

 본 동영상은 Silverlight가 설치되어 있는 브라우저에서 볼 수 있다.]]> 닷넷과 자바 ASP.NET MVC 오롯이 Wed, 09 Jan 2008 17:08:48 +0900 자바 진영의 SCA, JBI, ESB 용어 정리 http://acroama.isblog.net/blog_post_56.aspx http://osoa.org이다.
 SCA는 현재 자바만을 위한 스펙은 아니나 자바가 주축을 이루고 있다. SCA는 서비스를 제공할 애플리케이션을 컴포넌트 기반으로 어떻게 작성하고 이들 컴포넌트를 어떻게 엮어서 좀 더 복잡한 Composite Application을 만드는 가에 관한 스펙이다. 예전에 한국마이크로소프트가 주최한 아키텍트 포럼에서 강연한 David Chappell (http://davidchappell.com)이 언급한 바와 같이 SCA는 WCF와 여러 면에서 유사하다. 
 가장 큰 유사성은 하나의 비지니스 기능을 구현한 후 다양한 Binding을 제공하는 것이 Configuration 파일에서 선언하는 것만으로 가능하다. 필요한 모든 요소는 SCA 벤더가 제공하는 런타임이 다 제공한다. 차이점이라면 WCF는 닷넷 진영에서 제공해왔던 다양한 분산 환경에서의 통신 기술들은 통합한 전혀 새로운 표준 개발 방식이라면, SCA는 새로운 분산 환경에서의 통신 표준이라기 보다는 자바 진영의 기존 분산 환경 통신 기술들을 쉽게 사용할 수 있게 중간에서 매개 역할을 하며 필요한 것들을 자동화한다는 것이다.
 서비스를 제공하는 컴포넌트를 만드는 방식에서도 WCF의 ABC (Address,Binding,Contract) 기법이 그대로 적용된다. 다만 약간의 용어가 다를 뿐....uri, binding, service 라고. 다른 점이라면 SCA는 컴포넌트들을 조합하여 좀 더 복잡한 컴포넌트를 만들기 위한 스펙이 있어서 서비스를 노출하는 인터페이스외에 서비스를 참조하는 인터페이스를 기술하도록 하고 있다. 즉, 내가 필요로하는 서비스는 이런 이런 기능을 갖춘 서비스입니라..라는 식의 인터페이스를 기술하여 툴을 통해 비주얼하게 서비스를 해당 컴포넌트에 엮을 수 있게 하고 있다.
 둘의 가장 큰 차이는 구현 언어에 있다. WCF는 당연 닷넷 언어로 구현하여야 하나, SCA는 자바와에 C++, BPEL 등이 가능하며 Container 형태로 추가가 가능하다. 아울러 Spring Framework과 궁합이 잘 맞아 구현 Container로 Spring을 바로 적용할 수도 있다.

 자바에는 SCA외에도 이와 유사한 기능을 하도록 만든 스펙 및 프레임웍이 존재한다. JBI (Java Business Integration)과 ESB (Enterprise Service Bus)가 그것이다. 이 셋을 어떻게 자리매김하는 가에 대해 상이한 의견이 있는 듯 하며 이들이 향후에 어떻게 교통정리가 되어 자리매김할 지 추측해보자.
 SCA의 홈페이지에서는 SCA와 JBI에 대해 언급하면서 이 둘은 서로 충돌하여 하나가 배제되는 것이 아닌, 필요하면 함께 구현 가능하고 혹은 별개로 사용 가능하다고 밝히고 있으며, JBI가 애플리케이션 서버를 만드는 업체에서 JBI Container 만드는데 사용되는 것이며, SCA는 벤더가 아닌 개발자 및 배포자가 컴포넌트를 어떻게 만들고 조작하는가에 중점을 둔 스펙이라고 하고 있다. 이 둘의 아키텍처는 아주 유사하여 런타임이 있고 이를 기반으로 각종 container 형태의 것들이 실제 서비비스를 구현한 컴포넌트를 담고 있고, 이들간 혹은 이들과 외부 서비스간의 통신은 binding을 통해 제공되는 형태이다. 하여 SCA입장에서 JBI는 SCA 런타임위에 올라가는 각종 container를 구현하는 표준 API로서 역할로 자리매김하는 듯 하다. 하지만, JBI를 자세히 들여다 보면 SCA 만큼이나 개발 영역에도 할 말이 많음을 알게 된다. JBI 런타임 혹은 서버 구현은 물론 서비스 모니터링 기능 및 서비스 조합을 위한 에디터 등 컴포넌트 개발과 운영에 관해 큰 그림을 그리고 있음을 알 수 있다. 하지만, 대체적인 분위기는 SCA가 앞단에서 서비스를 조합하는 역할에 치중하고 JBI는 뒷단에서 서버 구현을 표준화시켜 3rd party가 만든 container를 맘껏 올릴 수 있게 하는 것으로 자리매김되고 있는 듯 하다. 썬이 엔터프라이즈 웹 서비스 분야에서의 좁아진 입지를 만회하고자 JCP를 통해 강력히 밀고 있는 JBI는 SCA의 구현을 원활히 하는 표준화 쪽으로 가닥을 잡을 것 같다. 현재 SCA를 구현한 오픈 소스 런타임으로는 아파치의 Tuscany와 Codehaus에 올라있는 Fabric3가 대표적이며 이들은 JBI와 무관하게 구현되어 있다.

 그럼 ESB와 SCA 혹은 JBI와는 어떤 관련이 있을까 ?
ESB는 SCA,JBI와 달리 스펙이 아니다. 마케팅 용어로 시작되어 현재는 SOA 기반 개발 표준 프레임웍으로 자리잡고 있으며 SOA 기반의 제품을 표방한 서버 치고 ESB를 언급하지 않은 업체가 없을 정도이다. 심지어 마이크로소프트까지도.. 그것도 뒤늦게..
ESB의 아키텍처는 JBI와 유사하며 다수의 구현에 따라 얼마든지 바뀔 수 있다. JBI의 아키텍처에는 명시적으로 런타임의 가운데에 NMR (Normalized Message Router)라는 메시지 버스가 있고 이 주변에 서비스 구현체에 해당하는 Service Engine과 바인딩을 위한 Binding Component라는 것이 있어서 서비스간 바인딩을 제공한다. ESB는 표준이 없으나 태생이 MOM (Message-oriencted Middleware) 업체의 마케팅 용어이기 때문에 아키텍처 또한 메시지 기반의 백본에 (웹) 서비스를 표준 바인딩 수단으로 하고 중간에 메시지 변환 및 addressing, routing, 메타데이터 관리 등을 제공하는 형태로 되어 있으며 근래에는 BPM 기능도 ESB의 요소로 간주하고 있다. 현재 오픈 기반의 ESB 구현체로 OpenESB가 있으며 이는 JBI 스펙을 구현한 ESB이다.
 결국, ESB 제품을 구현함에 있어서 SCA 기능을 제공할 수도 있고 JBI 스펙 기반으로 ESB 서버를 만들 수도 있는 것으로 보인다. 현재 일부 ESB 제품이라고 얘기하는 자바 진영의 서버 가운데 SCA 주도한 업체들은 대부분 SCA를 지원하는 ESB를 선보이고 있고, 썬의 애플리케이션 서버는 OpenESB를 지원하며 SCA 기능은 제공하지 않는 것으로 보인다. 참고로 썬도 Open SOA 그룹 (http://osoa.org)의 늦깍이 회원이다. 

 애초 생각은 WCF와 기능면에서 유사한 SCA에 대해 살펴보고자 했는데, SCA 이전부터 썬이 JBI 기반 구현체를 오픈/상용 형태로 개발 중이었고, 이를 애플리케이션 서버에 Servlet 컨테이너, EJB 컨테이너와 나란히 JBI 컨테이터 형태로 올리려했다는 것을 알고 있었기에 JBI까지 언급하기에 이르렀다. 현재 JBI 입장에서 JEE 컨테이너와의 연동은 중간에 브릿지 역할을 하는 JEE용 Service Engine을 통해 이루어지고 있다. ESB를 또 끌어들인 이유는, 서비스 기반 개발 방법에는 소위 ESB 서버를 빼 놓고는 현재 시장에서 관심을 끌지 못하고 있는게 현실이며 많은 소위 SOA 제품군들이 ESB를 핵심 백본으로 그리고 있어서 결국 SCA가 하고자 하는 일이 이루어지는 바탕은 ESB가 구현된 SOA 제품군 위에서이다. 
 속 깊은 내용은 알 길이 없으나 표면적으로 볼때 현재 ESB를 표방한 IBM의 SOA 제품군은 예상대로 SCA를 지원하며 특히 컴포넌트 조합을 위한 개발 툴을 통합시킨 형태로 가고 있고 JBI에 대해서는 그다지 관심이 없어 보인다. 반면 썬의 경우 JCP를 통해 표준화한 JBI관점에서 접근하며 OpenESB (http://open-esb.dev.java.net) 라는 구현체를 통해 JBI를 구현하여 자신들의 오픈 소스 애플리케이션 서버인 Glassfish (http://glassfish.dev.java.net) 에서 OpenESB를 지원함으로써 JBI를 드라이브하고 있고 SCA에 관해서는 그다지 큰 관심을 보이는 것 같지는 않다.
 밖에서 보는 입장에서 그리고 상용 벤더 입장에서 보면 SCA가 훨씬 많은 매력적으로 보인다. 컴포넌트를 WISWIG형태로 조합해서 서비스를 만드는 개발 툴과 이를 자신들의 ESB 서버에 바로 디플로이하게 함으로써 개발을 쉽게 할 수 있고, JBI는 ESB 서버를 구현할 때 확장팩 형태로 각종 자바 관련 기술들을 엮는 방식으로 지원하는게 합리적일 듯 싶다.

 언제까지 SOA가 시장을 지배할지, 그리고 ESB가 SOA의 핵심이 될 지 모르겠으나, 이런 추세라면 중첩된 기능을 통합하여 SCA + JBI = ESB 스펙으로 통합 제정함이 어떨까..닷넷하는 사람으로서 대응하기 힘들어서 .... ;)

 위 내용은 개인의 생각을 적은 것으로 의도적으로 사실을 왜곡하는 내용은 없을 듯 하나 일부 부정확한 내용이 있을 수 있다.]]> 닷넷과 자바 SCA JBI ESB WCF 오롯이 Sat, 05 Jan 2008 23:01:26 +0900 자바 JRE의 향후 모습 http://acroama.isblog.net/blog_post_55.aspx  JDK 6 Update N의 특징은 다음과 같다.
1. Startup Time 줄이기
 자바의 JVM이나 닷넷의 CLR이 처음 기동할 때, 즉 Cold Startup 일 경우, 애플리케이션에 따라 다르나 수초에서 십여초까지 걸리기도 하는 것은 이미 알려진 사실이다. 이는 JVM이나 JRE를 메모리에 올리는 과정이 필요하기 때문인데, 이를 얼마나 줄일수 있는가의 여부가 데스크탑 애플리케이션으로 할 건지 웹으로 할 건지를, 혹은 구축된 데스크탑 애플리케이션의 만족도에 지대한 영향을 미친다. 자바가 선택한 길은 PC가 처음 기동할 때 기본적으로 함께 기동되도록 하는 것이며, 이를 위해 제어판의 Java 항목에서 "Java Quick Starter"를 설정할 수 있도록 했다. Vista를 제외하고 다른 OS는 디폴트로 설정된다.
2. 하드웨어 가속기를 이용한 그래픽 처리
 마이크로소프트의 Direct3D 9 API 기반으로 하드웨어 가속 기능을 사용할 수 있도록 하여 Swing 기반의 애플리케이션에서 2D, 3D 구현을 좀 더 빠르고 현실감 있게 구현할 수 있다. 예제를 보니 정확히 할 수는 없으나, 하드웨어 벤더인 Radeon 9550이 언급되고, atiumdag.dll 등이 로드되는 것을 보니 가속기를 제대로 사용하는 듯 하다. 그외에도 "Nimbus"라는 cross-platform look & feel을 탑재하고 있다.
3. 실시간으로 사용자 PC에 깔려 있는 JRE 버전 감지 기능 향상
 사용자 PC에 설치되어 있는 JRE 버전을 Update 레벨까지 감지할 수 있는 "Deployment Toolkit"을 제공하여  애플리케이션에서 API를 통해 Toolkit을 통해 이 버전 정보에 근거하여 적절한 대응을 할 수 있게 해주는 기능이다.
4. Kernel Installation 모드
 이번 Early Access에는 포함되지 않았지만, Kernel 모드를 지원하여 최초로 JRE를 다운 받아야 하는 경우에 모든 JRE를 다운 받을때까지 사용자가 기다리지 않도록 일단 Kernel 모드에서 동작할 수 있게 한다. 기본 Kernel 모드로 일단 실행하고 향후에 필요한 라이브러리는 추가적으로 다운로드 받도록 한다.

 이 정도가 큰 특징으로 보여지며, 일부는 닷넷 CLR에도 기본적으로 탑재되어야 할 기능이라 여겨진다.]]> 닷넷과 자바 Consumer JRE JDK 6 Update N 오롯이 Thu, 03 Jan 2008 10:51:01 +0900 자바가 코볼의 전철을 밟고 있다고 ?? http://acroama.isblog.net/blog_post_54.aspx
Java is becoming the new Cobol 

 자바는 여전히 많은 영역에서 왕성한 생명력을 보여주고 있다. 특히 한국을 비롯한 동아시아에서 자바 + Unix + Oracle의 삼각 편제는 과히 무시무시할 정도다. 하지만, 전 세계적인 추세는 자바에게 유리하게 돌아가고 있지 않다는 것이 일반적인 견해다. 우선, 많은 영역에서 Ruby on Rails (이하 RoR)에 의해 프로젝트들이 win-back 당하고, 신규 프로젝트들이 RoR이 제공하는 pre-built Structure, scaffolding 등의 매력에 빠져 자바에서 이탈하고 있다. 또한 JEE의 복잡함은 더 이상 자바 진영의 비밀만은 아니다. Write Once Run Everywhere를 외치며 플랫폼 비종속성을 내세웠지만, 정작 서로 다른 Web Application Server (WAS) 사이에서의 호환성은 불가능할 뿐 더러, 새로운 프로젝트가 시작될 때 마다 도입되는 이전과 다른 WAS에 적응하느라, 또한 같은 WAS라도 버전이 다르면 또 적응하느라 가뜩이나 복잡한 엔터프라이즈 개발에 골머리를 썩이고 있는 개발자들의 불만은 커져가는 것이 현실이다. 모바일 영역에서도 자바 기반 개발 플랫폼이 사라지고 있으며 구글이 안드로이드를 만들고 있는 것도 이와 무관하지 않다고 적고 있다.

 이런 와중에 지난달 조사했다는 Info-tech 설문 결과는 자바 개발자들에게 당혹감을 줄 만 하다. 1850 여 영역에서 비지니스 사이즈와 영역에 상관없이 자바보다 닷넷을 선택한다는 조사 결과는 RoR에 쫓기고, 닷넷에 치이는 자바의 현실을 반영하고 있는 듯 하다.


 개인적으로는 위 본 기사보다는 기사에 달린 댓글를 유심히 봐 주었으면 한다. 현장에서 개발하고 혹은 팀을 이끌고 있는 사람들이 바라 본 자바와 닷넷에 대한, 혹은 개발 일반에 관한 생생한 기록이며, 크게 엇갈린 반응을 보이고 있다. 하지만, 자세히 살펴보면, 위 글의 논조와 크게 다르지 않은 글이 더 많다는 것을 알게 될 것이고, 대체로 자바의 복잡성과 닷넷의 간편함을 거론하며 C# 은 더 나은 자바이며, 자바의 다양성 및 복잡함으로 인한 TCO 부담은 관과될 수 없다는 등 한 번쯤 훑고 지나갈 만한 코멘트가 많다.

 한 언어가 우수하고 다른 언어가 저급하다는 것을 지적하는 것이 절대 아니며, 현실 개발에 있어서 적합한 언어/플랫폼과 불편한 언어/플랫폼이 있고 점점 더 닷넷이 더 많은 영역에서, 이제는 엔터프라이즈 영역까지도 개발하는 데 좀 더 편리하고 실용적이고 합리적인 언어 및 플랫폼이라는 점이 입증되고 있다는 사실이다.]]> 닷넷과 자바 .NET 오롯이 Thu, 03 Jan 2008 09:43:08 +0900 ASP.NET 3.5 Extentions - MVC Framework http://acroama.isblog.net/blog_post_48.aspx
 닷넷이든 자바든 혹은 루비든 PHP든 MVC 프레임웍 기반의 개발을 해 본 경험이 있는 사람들에게 있어서 ASP.NET이 제공하는 Page 기반의 웹 처리 방식에 있어 Page가 컨트롤러가 되고, Page가 뷰가 되기도 하는 모습은 어딘지 프로페셔날해 보이지 않고, 좀 더 나은 무언가가 나올 것 같은 조짐을 보여왔다. 특히, 자바 진영에서 Model 1 - Model 2 논쟁을 겪으면서 컨트롤러와 뷰의 역할 분담과 이를 통한 확장성 등은 이제 거의 모든 웹 개발 방식에 있어서 정석처럼 여겨져왔고, 이는 곧 자바 진영의 수 많은 MVC 프레임웍의 양산을 가져왔으며 지금도 자바 진영에 있어 MVC 기반의 웹 개발 프레임웍은 개발 시작의 필수 조건 처럼 여겨지고 있다. 닷넷 진영에서도 이러한 오픈 기반의 프레임웍이 하나 둘 씩 생겨나고, 혹은 자바 진영의 오픈 프레임웍이 서서히 포팅이 되면서 실제 닷넷 프로젝트에서도 이러한 오픈 프레임웍 기반 개발 방식이 자리를 잡아가고 있다. 여기에 마이크로소프트에서는 ASP.NET 기반 MVC 프레임웍을 통해 이러한 개발 흐름에 확고한 지지 기반을 제공하고 있다.

 내년 상반기 정식 출시될 ASP.NET MVC 프레임웍의 내용을 간단히 살펴보면...
 첫재, 컨트롤러에 있어서 System.Web.MVC.Controller Base 클래스를 제공하며 (Ruby on) Rails와 유사한 특징이 많다. 특히 핵심 사상인 Convention over configuration은 ASP.NET MVC 프레임웍에도 그대로 적용되며 많은 편리한 이점을 주고 있다. Global.asax의 code behind class에 요청 정보에 따른 컨트롤러 선택을 자동화해주는 매핑이 잡히기 때문에 별도의 설정 파일 없이 매핑을 이용할 수 있고, 원치 않으면 이를 변경하면 된다. 예를들면, /Products/Detail?id=3 혹은 /Products/Detail/3 은 실제 ProductsController라는 컨트롤 클래스의 Detail()이라는 메소드에 id라는 파라메터로 3을 넘겨주는 것을 의미한다. 여기에 필요한 별도의 매핑을 필요없다는 것... Rails 스럽다..


 둘째, 모델에 있어서 현재 가장 자연스러운 조합은 LINQ to SQL을 쓰는 것이다. 특별한 설명이 필요없을 듯...


 셋째, 뷰에 있어서는 현재 Masterpage 기반의 설정을 제공한다. 하지만, 대부분의 MVC 프레임웍이 그러하듯이 뷰는 다른 기능을 써서 표현할 수 있다. 즉, NVelocity와 같은 템플릿 언어를 통한 뷰 구현도 ASP.NET MVC 프레임웍에서 가능하다. 뷰의 구현을 위해 Base 클래스로서 System.Web.MVC.ViewPage<T>를 제공하고 있다. 여기서 T가 ViewPage에 넘겨질 ViewData를 의미한다.
 컨트롤러에서 뷰를 찾는 방법 또한 Convention over Configuration을 따르고 있다. 컨트롤러의 RenderView() 메소드에 원하는 뷰 이름을 파라메터로 넘겨주면 Views 서브 폴더 밑에 해당 컨트롤러 서브 폴더 밑에서 해당 이름의 aspx 파일을 찾는 방식이다. 즉, ProductsController.RenderView("Categories", category)라면 이는 /Views/Products/Categories.aspx가 불리며 category의 뷰 데이터가 넘어가서 렌더링되는 식이다.
 또한 <a href="  ">를 지원하기 위해 HtmlHelper.ActionLink를 두어 소스코드 상에 URL이 정적으로 명시되는 것을 방지하고 중앙에서, 즉 Global.asax에 명시된 RouteTable을 통해 동적으로 URL을 생성하게 됨으로써 향후 URL 체계가 바뀌어도 전체 소스를 바꾸지 않고 한 군데에서만 변경하면 바로 적용되는 효과를 거둘 수 있다.


좀 더 상세한 설명은 Scott Guthrie의 블로그를 참조하기 바란다.
http://weblogs.asp.net/scottgu/archive/2007/11/13/asp-net-mvc-framework-part-1.aspx
http://weblogs.asp.net/scottgu/archive/2007/12/03/asp-net-mvc-framework-part-2-url-routing.aspx
http://weblogs.asp.net/scottgu/archive/2007/12/06/asp-net-mvc-framework-part-3-passing-viewdata-from-controllers-to-views.aspx
http://weblogs.asp.net/scottgu/archive/2007/12/09/asp-net-mvc-framework-part-4-handling-form-edit-and-post-scenarios.aspx

블로그 내용을 보고 드는 느낌은 Ruby on Rails의 장점을 모두 수용하면서 ASP.NET이 제공할 수 있는 기능, Visual Studio가 제공할 수 있는 기능 등을 모두 활용할 수 있다는 점과 무엇보다도 군더더기 없이 깔끔하게 MVC에 충실하려는 모습이 매력인 듯 하다. 많은 개발자들의 ASP.NET MVC 프레임웍의 출현을 고대하는 것도 이런 장점들 때문이 아닐까 한다.

시간적 여유가 된다면 다른 오픈 기반 프레임워들, 특히 Spring.NET 과의 연계 혹은 비교를 해 볼 계획이다.]]> 닷넷과 자바 MVC ASP.NET MVC 오롯이 Fri, 28 Dec 2007 14:16:09 +0900 Microsoft Dynamics CRM 4.0 출시 http://acroama.isblog.net/blog_post_53.aspx
 마이크로소프트는 줄기차게 Software + Services (이하 S+S)를 주장하여 왔다. 오늘날 처럼 복잡하고 급변하는 비지니스 환경 속에서 사용자의 요구, 비지니스의 요구를 충족시키기 위해서는 Software나 Services 그 어느 하나 가지고는 불충분하다는 것이며, 고객을 최우선시 하여 그 목적을 달성시키고자 한다면 S+S가 답이라는 것이다. Software가 필요하면 Software적으로, Services만으로 충분하다면 Services 방식으로, 혹은 이 둘의 적절한 조합이 가장 최상이라면 이들의 결합을 통해 비지니스 문제를 해결해야 한다는 것이 S+S의 핵심이다. Microsoft Dynamics CRM 4.0은 바로 이러한 S+S를 보여주는 대표적인 사례인 것이다. 전통적인 Software Package 제품이었던 Dynmics CRM 제품을 Software 방식으로, 혹은 Services 방식으로 제공할 수 있도록 만들 것이다. 
 따라서 고객이 라이선스를 사서 자체 서버를 통해 CRM을 운영하든지, 혹은 파트너가 운영하는 CRM 시스템을 다달이 사용료를 내면서 이용하든지, 혹은 마이크로소프트가 운영하는 Dynamics CRM Live를 통해서 이용하든지, 고객은 자신의 회사 규모와 비지니스 환경에 맞는 최선의 방식을 선택할 수 있게 된다.

 참고로 Dynamics CRM 4.0은 내부적으로 .NET Framework 3.x의 핵심 요소인 WF (Windows Workflow Foundation)을 적용하여 프로세스 자동화를 구현하였고, OCS (Office Communication Server)와 연계하여 사용자의 상태 정보 (Presence)를 CRM 애플리케이션에서 확인할 수 있다. 아래 그림은 SaaS 기반 애플리케이션의 특징인 온라인에서 바로 시험 계정을 만들어 테스트해볼 수 있는 것을 나타낸다. 
 
Dynamics CRM 테스트 계정 얻기

]]> Software+Service Dynamics CRM 4.0 Software+Services 오롯이 Thu, 20 Dec 2007 11:06:06 +0900 Visual Studio International Pack 1.0 Beta 1 공개 http://acroama.isblog.net/blog_post_51.aspx Visual Studio International Pack 1.0 베타 1이 공개되었다. VS2005와 VS2008에서 사용할 수 있는 Visual Studio International Pack은 .NET 개발자의 국가별 기능이 가능한 응용프로그램 개발을 지원하기 위해 설계된 클래스 라이브러리를 포함하고 있다. VS International Pack 1.0 배포 판은 .NET Framework이 제공하는 국제화 기능을 강화하기 위하여 다음과 같은 구성요소를 포함하고 있다.

  • East Asia Numeric Formatting Library - 숫자 데이터를 한국어, 중국어 간체/번체, 및 일본어 통화 형식의 문자열로 서식을 지정.
  • Korean Auto Complete TextBox Control - 한국어 입력 시 자동 완성과 Intellisense 기능을 지원하는 TextBox 컨트롤을 제공.
  • Japanese Kana Conversion Library - 가나 문자 집합을 다른 문자 집합으로 변환.
  • Japanese Text Alignment Library - 특정 일본어 정렬 형식으로 문자열을 렌더링을 할 수 있는 클래스 라이브러리를 제공.
  • Japanese Yomi Auto-Completion Library - 일본어 IME를 인지하여 자동 완성을 제공하는 클래스 라이브러리와 TextBox 예제를 제공.
  • Simplified Chinese Pin-Yin Conversion Library - 중국어 간체문자에서 일반적으로 사용되는 다음자, 동음자, 중국어 음역(Pinyin) 혹은 획수와 같은 문자 속성을 추출.
  • Traditional Chinese to Simplified Chinese Conversion Library and Add-In Tool - 중국어 번체에서 간체로 혹은 그 반대로 텍스트를 변환. 이 구성 요소는 VS IDE에서 중국어 간체 리소스 파일을 중국어 번체로 변환하기 위한 추가 기능 도구를 포함.
본 Visual Studio International Pack 1.0 베타1은 아래 링크에서 다운로드 받을 수 있다.

다운로드 바로가기




]]> 새소식 VS International Pack 오롯이 Tue, 11 Dec 2007 15:26:42 +0900 ASP.NET 3.5 Extentions CTP Preview 출시 http://acroama.isblog.net/blog_post_50.aspx
- ASP.NET AJAX 성능 개선 : 이번 Preview에 포함된 ASP.NET AJAX관련 개선 사항으로는 브라우저에서 History 지원 기능 (이전/다음 버튼과 통합), 서버쪽 History 관리 지원 기능, 향상된 AJAX 컨텐츠 링크 지원, 추가적인 JavaScript 라이브러리 향상 등이 있다.
- ASP.NET MVC : ASP.NET 기반의 MVC 프레임웍이 드디어 실체를 나타냈다. 이전 포스트에서 밝혔듯이 ASP.NET 기반의 웹 애플리케이션 개발에 있어서 제대로된 프레임웍을 만날수 있게 되었다. ASP.NET MVC는 TDD를 지원하며, Request를 해당 비지니스 로직에 매핑 시키는데 있는 Convention over Configuration 을 수용하였고, 아울러 로직 처리 후 뷰 페이지를 매핑하는 데에도 이를 사용하고 있다.
- ASP.NET Dynamic Data Support : 데이터 중심적인 웹 싸이트 구축에 사용할 수 있는 것으로서 ASP.NET WebForms와 ASP.NET MVC 프레임웍을 기반으로 data-driven  방식으로 웹 싸이트를 쉽게 개발할 수 있는 Scaffolding 프레임웍을 제공한다.
- ASP.NET Silverlight 지원 측면 : 이번 Preview에는 ASP.NET 애플리케이션 내에 Silverlight를 쉽게 적용할 수 있는 기능을 제공한다. ASP.NET 서버 컨트롤로서 Silverlight 비디오/미디어 콘트롤을 제공한다.
- ADO.NET Data Services : ASP.NET 3.5 Extension과 함께 출시될 예정이 ADO.NET Entity Framework을 이용하여 로컬 데이터베이스를 원격지에 웹 서비스를 통해 노출하는 데이터 서비스도 함께 제공될 것이다. 이러한 데이터 서비스를 이용하여 REST 기반 URI 매핑을 통해 데이터베이스의 테이블 등의 데이터를 웹 서비스로 ASP.NET에서 쉽게 제공할 수 있도록 Astoria 프로젝트가 진행되고 있다. 

 ASP.NET 3.5 Extension CTP Preview 다운로드



]]> 새소식 ASP.NET 3.5 Extension ASP.NET MVC 오롯이 Mon, 10 Dec 2007 19:49:05 +0900