오늘날 많은 Buzzword들이 난무하고 있지만, 그중 유난히 우리의 시선을 잡아 끄는 것들이 있다. SOA, SaaS, Web 2.0 등이 그것이다. 오늘날처럼 사용자의 요구가 다변화되어 있고, 변덕이 심한 상황에서 서비스를 제공하는 입장에서는 다양한 기술을 적용해보고 다양한 방법을 고안해나가며 대처해나가는 과정에서 자연스럽게 많은 buzzword들이 생겨나게 된 것이다. 마이크로소프트가 IT 변혁기마다 어떠한 변화를 겪어가며 헤쳐나왔는지, 그리고 그러한 연장선상에서 오늘날 어떤 무기를 들고 대처해가는지를 살펴봄으로써 근래에 내놓은 "Software + Services" 전략을 엿보기로 하자

마이크로소프트는 1975년 설립되어 1981년에 IBM PC에 처음 MS-DOS 1.0이 탑재되어 세상에 나오게 되었다. 1990년에 Windows 3.0을 출시하여 GUI 환경의 운영 및 개발 플랫폼의 대중화을 이끌었다. 그 당시 Lotus 123 및 워트퍼펙 등 non-GUI 기반의 막강한 소프트웨어의 영향으로 GUI 기반 플랫폼이 주목을 받지 못해 애플 등도 고전을 면치 못하던 시기였다. 마이크로소프트는 GUI 기반 운영 및 개발 플랫폼의 가능성을 주목하여 일련의 Windows 출시에 주력하게 된다. 5년후 1995년 경에는 바로 웹이 폭발적인 성장을 막 시작하려는 시기였으며 마이크로소프트는 데스크탑 위주의 전략에서 웹 포괄적인 전략으로 변화를 꾀하게 된다. 이때 만들어진 것이 IE, IIS, 웹 저작 도구들이며, 아울러 AJAX의 기반 기술인 DHTML을 만들고, XMLHTTP객체를 IE에서 지원하는 등 웹에 대한 투자 및 전략에 많은 노력을 경주하던 시기이다. 다시 5년후 2000년 경에는 닷컴 버블이 붕괴되던 시기이다. 그렇게 천정부지로 치솟던 IT에 대한 가치 평가와 닷컴 회사들의 주가가 곤두박질치기 시작하는 시기이다. 마이크로소프트는 이 시기에 중대한 결심을 하게 된다. 닷컴 붕괴를 통해 소통의 중요성, 즉, 시스템과 시스템의 소통의 중요성을 파악하고 XML 웹 서비스 확대를 위해 많은 노력을 기울이게 된다. SOAP 제정과 XML 태동에 많은 기여를 하고 웹 서비스 표준화에 적극 참여하게 된다. 또하나 그전까지 컴파일과 링크를 하게 되면 바로 OS에 최적화된 바이너리 기반의 개발 방식에서 벗어나 가상의 운영환경인 CLR 기반의 managed 환경에서의 개발 방식, 즉 닷넷을 도입하게 된다. 실로 마이크로소프트로서는 최대의 도박이자 결단을 한 것이다. 다행이도 닷넷 플랫폼은 그 이후 순항을 거듭하여 성공적으로 정착했다. 그 후 5년후 2005년을 전후에서 또하나의 변혁이 도래하게 되는데 바로 서비스 중심적인 사고의 확대이다.

마이크로소프트에게 있어서, 그것도 소프트웨어 라이선스 판매를 통해 돈을 버는 회사 입장에서 광고 기반의, 서비스 기반의 소프트웨어 전략, 서비스 기반의 경제 논리는 위협이 될 수 있는 상황이었다. 마이크로소프트는 2005년 Notes를 만들었던 Ray Ozzie를 영입하여 서비스 시대에 걸맞는 전략 수립에 박차를 가하며 마이크로소프트의 서비스 전략, 바로 Software + Services를 제시하게 된다. Software + Services (이하 S+S)는 단순히 Software도 하고 Services도 하겠다는 것이 아니라 현재의 사회적, IT 환경적 상황이 Software와 Services의 결합을 통한 사용자 경험의 극대화를 추구하고 있음을 간파한 전략인 것이다.

여러분이 익숙한 많은 온라인 서비스 업체들, 특히 서비스만이 살길이라고 외치던 업체들도 이미 Software와 Services의 결합을 통해 충성도 높은 사용자를 끌어들이고자 노력하고 있다. 구글 데스트탑, 툴바, 위젯, 게젯, 위젯바 등등 국 내외를 막론하고 서비스 중심적인 회사들이 앞다투어 무언가를 데스크탑에 깔고자 했으면 이를 통해 동종업계의 다른 회사와의 차별성을 부각시키고자 했던 것이다. 더 전문영역으로 가면, "모든 소프트웨어는 구름속에 위치할 것이다"라며 NO SOFTWARE를 자사 전화번호로 삼을 정도로 전문 서비스 업체를 표방했던 Salesforce.com 조차도 Offlie edition, mobile edition을 만들어 데스크탑에 소프트웨어를 설치하고 있는 게 현실이다. ebay같은 경우도 일반 사용자들은 브라우저만을 통해 경매를 할 수 있고, 소위 파워셀러들은 Turbo Lister라는 데스크탑 애플리케이션을 통해 경매에 참여하게 하는 등 Software와 Services를 결합해 자사 서비스의 만족도, 사용자 경험을 최적화하려 하고 있다. Apple의 iTunes도 그러한 데스크탑 애플리케이션이다. Google Gears 또한 어떤한가. 이러한 현상들이 말하는 것은 하나다. 사용자 중심적인 사고, 사용자 경험 최적화, 비지니스 요구를 최우선시 하고자 한다면 자연스럽게 Software와 Services의 결합을 통한 시너지, Software와 Services를 통한 사용자 선택의 폭 확대를 꾀할 수 밖에 없다는 것이다. 이것이 마이크로소프트가 바라보는 서비스 전략인 것이다.

세상에 존재하는 대다수의 서비스들은 100% Software이거나 100% Services일 가능성은 매우 적다. 더군다나 그것이 다른 사용자를 위해 제공되는 것이라면, 그리고 사용자를 위한 것이라면 더 더욱 그러하다. 즉, 막대의 한쪽 끝을 전통적인 IT가 추구했던 100% Software 즉, 필요한 Software 라이선스를 구입하여 회사 방화벽안에 설치하여 내가 필요한 것은 모두 내가 소유하는 방식을, 또 다른 끝은 초기 Salesforce.com이 추구했던 100% Services기반으로 필요한 것은 하나도 내가 소유하지 않고 돈 내고 빌어쓰는 형태라고 봤을때 대부분의 서비스는 이 둘을 잇는 중간 어딘가에 위치하게 된다는 것이다. 즉, Software와 Services의 "배합비율"이 달라질 뿐 Software와 Services의 두 가지 장점을 향유하고자 둘 다 채택할 것이다.
또 다른 의미에서 S+S를 살펴보면, 회사에서 데스크탑 애플리케이션인 Outlook을 통해 회사 메일 서버에 접속해 메일을 확인하던 직원이 지방 출장을 위해 공항에서 키오스크의 웹 기반 애플리케이션을 통해 한 두 메일을 확인하고 지방의 버스 안에서 PDA나 포켓피씨 등의 mobile outlook등을 통해 메일을 확인하는 경우를 상정해보자. 이 경우 세가지 장치를 통해 사용자는 동일한 서비스에 접속해 서비스를 받고 있는 것이다. 즉, 사용자가 처한 환경, 처한 상황, 처한 장치에 최적화된 방식으로 사용자는 서비스를 이용하는 것이다. 즉, 사용자에게 Software, Services 혹은 S+S를 통해 선택의 폭을 넓혀주는 것이다. 모든 경우 항상 브라우저를 통해 메일을 확인하는 것이 사용자를 위해 가장 바람직한 서비스일까 ? 또한 이처럼 동일한 메일 서비스에 접속해 메일을 확인할 경우 어느 장치의 경우던 한번 읽은 메일은 "새메일"로 표시되지 않도록, 즉, 아웃룩에서 봤던지, 공항 키오스크 웹 브라우저를 통해 읽었던지간에 PDA를 통해 메일 서비스에 접속하면 이전에 읽은 것은 여전히 읽은 메일로 표시되어야 한다는 것이다. 이를 "Seamless User Experience"라고 한다. 즉, 어떤 장치, 어떤 통로를 통해서든 동일한 서비스에 접속하면 사용자 경험이 죽 하나로 끊김없이 이어져야 한다는 것이다. 이처럼 사용자가 처한 상황, 장치, 시간 등을 고려하여 최적의 사용자 경험을 제공할 수 있는 Software 혹은 Services 혹은 S+S가 바로 마이크로소프트가 제시하는 가장 실질적인 접근 방식인 것이다.
아래 그림이 바로 마이크로소프트가 바라보는 시각, S+S 모델이다.

기업이 SOA기반 인프라를 갖추었다고 하면 대부분의 경우 기업내 애플리케이션들로부터 재사용 가능한 비지니스 기능(business functionality)들을 서비스 형태로 추상화하여 BPM엔진이나 서비스 오케스트래이션 엔진에서 관리하면서 급변하는 비지니스 상황에 대처하기위해 비지니스가 요구하는 새로운 서비스를 만들고자 할 경우 SOA 기반의 재사용가능한 서비스들을 조합하여 그때 그때 새로운 서비스를 만들 수있는 제반 여건이 만들어졌다고 할 수 있다. 즉, Business Agility를 위한 필수적인 요소로서 IT를 자리매김해주는 것이 SOA인 것이다. 이제는 SOA 인프라에서 관리하는 서비스가 자사 서비스 뿐만아니라, SaaS 형태로 외부에서 제공되는 서비스까지 포괄하여 이들을 조합할 수 있어야 한다. 즉, 기업이 가져가야 할 IT 핵심 역량으로 삼을 것은 계속 사내 애플리케이션 형태로 유지, 보수를 해 나가야 하나, 이미 Commoditized되어 있어서 회사의 핵심 역량이 아닌 것들은 SLA (Service Level Aggreement)를 통해 외부 서비스를 이용하는 것이 합리적이다. 즉, 어떤 것을 핵심역량으로 하고 어떤 것을 commoditized된 서비스를 볼 것인지에 대한 회사 차원에서의 정책 즉, IT Governance가 필요하다. 이러한 IT Governnance하에서 신규 프로젝트가 강제되어 일관성을 유지할 수 있어야 한다. 이러한 것이 다름아닌 Enterprise Architecture의 기초가 된다. 이렇게하여 SOA와 SaaS가 엮이게 된다. 
정작 사용자 입장에서는 뒷단의 SOA 와 SaaS의 결합에 별로 관심이 없다. 사용자가 관심있는 것은 뒷단이 몽땅 사내 서비스에서 제공되건, 몽땅 외부 SaaS 서비스로 제공되건 상관없이, 내가 하고자 하는 일, 나의 업무에 최적화된 형태로 해당 서비스가 제공됐으면 하는 것이다. 영업 대표인 내가 고객 응대를 위해 필요한 정보를 내가 업무 처리에 맞게 제공해주고 내 업무에 맞게 화면 전환을 제공하며, 내가 한번에 알 수 있게 다양한 차트와 표를 통해 제공해준다면 금상첨화일 것이다. 또한 내가 사무실을 떠나도 PDA 등을 통해 여전히 서비스를 이용할 수 있다면 더할 나위 없이 환상적일 것이다. 바로 이것이 Web 2.0 적인 요소가 가미되는 것이다. 
마이크로소프트가 바라보는 세상은 이처럼 Software와 Services의 조합으로 구성되어 있으며 자연스럽게 Software와 Services는 결합될 수 밖에 없는 것이다. 중요한 것은 기술이나 서비스 자체의 대의 명분이 아니라 그것을 통해 뭘 제공하려하는지 즉, 사용자 중심적인 사고가 최우선이라는 것이다.

Posted by 장현춘

얼마전 마이크로소프트는 CodePlex를 통해 SaaS 샘플 애플리케이션(LitwareHR)을 공개하였다.

이 애플리케이션에 구현된 SaaS의 아키텍처 면에서의 특징을 살펴보기로 한다.
아키텍처 관점에서 SaaS 애플리케이션의 가장 큰 특징은 single-instance multi-tenancy이다. 한 애플리케이션의 동일한 인스턴스로부터 다양한 사용자의 요구를 만족시키는 서비스를 제공하기 위해서는 애플리케이션의 각 Tier를 설계할 때 이에 대한 충분한 고려가 선행되어야 한다. 이점이 기존의 ASP (Application Service Provider)가 실패한, 혹은 비효율적이라고 얘기되어 지는 부분이다.

SaaS 애플리케이션이 3 Tier 아키텍처로 구현된다고 가정할 경우, single-instance multi-tenancy를 제공하기 위해서는 애플리케이션의 각 Tier 마다 해당 사용자에 맞게 customize가 일어나야 하는데, 이를 위해서 metadata-driven 아키텍처가 필요하다. 즉, 로그인한 사용자의 metadata 정보에 근거하여 사용자 고유한 애플리케이션처럼 동작하여야 하며, 이를 위해 presentation tier, business tier, data tier에서 customize를 제공할 수 있어야 한다.(엄밀히 말하며, customizable이라기보다는 configurable이라고 할 수 있다.)

presentation tier에서의 customization에 대해 살펴보면...
사용자마다 고유한 ui를 제공할 수 있는 방법은 다양하겠으나 가장 손쉬운 방법은 css를 적용하여 사용자가 자신의 화면을 디자인하여 업로드할 수 있도록 하거나 ASP.NET 2.0부터 지원하는 theme이나 skin 기능을 이용하여 손쉽게 제공할 수 있다. 좀 더 고차원적인 방법을 제공한다면, 사용자가 화면 디자인을 할 수 있는 페이지를 제공하는 것이다. 다만, 사용자가 계약한 레벨에 따라, 즉, 사용하고 있는 서비스 레벨에 따라 사용자가 이용할 수 있는 메뉴나 화면의 다양성 측면에서 차등을 주는 것이다. 고급 서비스를 이용하는 사용자는 좀 더 많은 부가 기능을 갖춘 화면 디자이너를 이용하여 차별화된 ui를 디자인하여 사용할 수 있게 하고, 반대의 경우는 제약이 가해진 화면 디자이너를 통해 제한된 기능 및 사용자 경험을 갖도록 한다. LitwareHR에서는 사용자가 자신이 원하는 ui를 css로 작성하여 업로드하는 것으로 하고 있다.

business tier에서의 customization에 대해 살펴보면...
business tier에서 사용자별 metadata에 근거하여 사용자에 고유한 비지니스 로직을 제공한다는 것은 쉬운 일이 아니다. 이를 가능하게 하는 기술이 바로 workflow이다. 마이크로소프트는 .NET Framework 3.0의 핵심 요소 중 하나로 WF (Windows Workflow Foundation)을 제공하고 있다. .NET Framework 3.0은 비스타에 기본 내장되어 출시되며 따라서 OS에 이미 Workflow 엔진이 탑재되게 된다. 따라서 비스타 이후의 OS에서는 애플리케이션 레벨의 Workflow 기능은 간단히 OS에서 제공하는 기능을 사용할 수 있다.
business tier에서의 customization은 WF에서 제공하는 rule set과 policy를 이용하여 서로 다른 권한을 가진 사람들에 대해서 서로 다른 workflow을 타도록 할 수 있다. 즉, 모든 비지니스 로직을 workflow에 의해 customize하는 것이 아니라, workflow를 구성하는 단위 activity로 분해/조립이 효과적인 업무에 적용하는 것이 바람직하다. 말 그래로 OLTP성이 아니라 사람이든 기계든 workflow 개념이 포함되는 업무에 적합한 customization이다. SaaS 샘플 애플리케이션의 경우 Interview 단계를 뽑고자 하는 사람의 레벨에 따라 사용자가 설정할 수 있도록 하는 기능을 WF를 통해 구현하고 있다.
마이크로소프트가 웹 싸이트나 혹은 책으로 제공하고 있는 Pattern & Practices 시리즈 중에 "Application Architecture for .NET : Designing Application and Services"가 있는데, 이 책에서 제시하는 Tier별 구성 요소가 본 LitwareHR 설계에 그대로 사용되고 있다. 특히 비지니스 로직을 customize하기 위해 workflow을 사용하고 있고 이 workflow에서는 필요한 로직의 조합을 통해 원하는 flow을 구성하도록 하고 있다. LitwareHR 샘플 애플리케이션 외에도 Remend에서 제공하는 SaaS 서비스도 P&P에서 제시하는 아키텍처 설계 가이드를 충실히 구현하고 있다. 물론 P&P가 제시하는 것은 신주단지 모시듯 그대로 따라야 하는 것이 아니라, 아키텍처 설계시 참고할 가이드를 제공하는 것 뿐이다.


data tier에서의 customization에 대해 살펴보면...
사용자가 새로 서비스 이용 계약을 하게 되면, 서비스 제공하는 측에서는 사용자마다 테이블을 새로 생성하여 사용자 전용으로 사용하게 할 수도 있고, 하나의 테이블에 구분자를 두어 같이 사용하게 할 수도 있다. 혹시라도 커뮤니티 싸이트에서 커뮤니티 생성/관리 로직을 구현해 봤거나, 웹 호스팅 업체의 서비스 신청 로직을 구현해 본 독자라면 한번쯤은 고민해봤을 것이다. 이 같은 예보다 더 심각한 경우는, 같은 서비스를 이용하는 사용자라도 큰 차이가 없지만 데이터 스키마가 다른 경우이다. 즉, 기본적으로 제공되거나 사용하는 데이터가 존재하고 여기에 몇가지 필드가 추가되어 사용자 입장에서는 자기만의 데이터 스키마를 가지고 있다고 생각하게 하는 경우이다. 이 경우도 지금껏 여러분이 비슷한 경우에 처해본 적이 있다면 SaaS의 경우도 다르지 않다는 것을 말해 두고 싶다. 즉, 기본 정보를 제공하는 테이블이 있고, 그 외 사용자별로 고유한 필드가 함께 제공되어야 한다면, 해당 필드는 별도의 테이블에서 제공되어야 한다. 이 필드를 나타내기 위해서는 타입을 기술하는 테이블이 있어야 하고 실제 값을 가지고 있는 테이블이 있어야 한다. 즉, main 테이블외에 최소 두 개 이상의 테이블을 조인하여 사용자 고유의 데이터 스키마 처럼 착각하게 만드는 것이다. 
한 가지 고려해야 할 사항은 여러 사용자가 한 테이블에 데이터를 저장하고 읽게 될 경우, 혹시라도 있을지 모를 보안이나 개인 정보 유출에 대비하여 구현하여야 한다. 즉, 모든 sql 문장이 직접 테이블을 건드리는 것이 아니라 그 앞에 해당 customize된 view에 대해 작업을 진행하도록 하여야 한다. 이를 "Tenant View Filter" 패턴이라고도 한다.

전반적으로 LitwareHR 샘플 애플리케이션은 production 환경에서 바로 사용할 수 있는 코드를 제공하기 위함이 아니라, Microsoft가 SaaS의 아키텍처 관점에서 줄곧 제시해 온 Technical Guide의 사상이 실제로 구현될 수 있음을 예시하고자 함이다. 즉, 아키텍처 관점에서 multi-tier 환경의 애플리케이션이 metadata-driven한 방식으로 사용자별로 각 tier에서 customize가 일어나서 서로 다른 화면과 로직과 데이터를 사용할 수 있음을 보여주고 있다. 참고로 LItwareHR은 SaaS maturity model에서 level 3 까지 구현하고 있다. 즉, maturity model을 구분하는 아키텍처적인 특징인 "configurable, muti-tenant efficient, scalable" 중에서 "scalable"을 제외한 기능이 구현되어 있는 것이다. 자세한 것은 마이크로소프트 SaaS 싸이트를 참고하길 바란다.

Posted by 장현춘

ASP.NET MVC Framework이 매월 CTP 형태로 공개 되면서 출시가 임박함을 알리고 있다. ASP.NET MVC가 개발자들의 관심을 끄는 이유는 기존 WebForms 기반의 ASP.NET 웹 애플리케이션 개발 방식이 갖는 ViewState와 Postback의 한계로 인해를 발생하는 여러 문제점을 극복해줄 수 있는 프레임웍이기 때문이다. ASP.NET의 ViewState 역할과 Postback 처리 방식은 각 Page의 라이프싸이클 관리와 이벤트 처리 로직을 통해 Stateless한 HTTP의 속성과 배치되는 개발 방식에 개발자들을 익숙하게 만들어 복잡하고 방대한 스케일의 웹 애플리케이션 개발에 많은 어려움을 가져다 주었다. 많은 웹 개발자들이 유독 닷넷에만 없는 MVC 기반 프레임웍의 출현을 바라고 있었고, 마이크로소프트가 Page Controller 기반의 WebForms에 주력하고 있을때, 닷넷 오픈 진영에서 하나 둘 이에 대한 구현이 나타나기에 이르렀고 마침내 마이크로소프트가 Front Controller 기반의 프레임웍을 제공하기에 이른 것이다.
아래는 Scott Guthrie가 처음으로 ASP.NET MVC 프레임웍 대해 공개 강연한 동영상이다. 화질이 썩 좋지는 않으나 ASP.NET MVC의 배경이나 특징, 사용법 등을 쉽게 설명하고 있다. 언뜻 언뜻 비치는 코드가 현재의 CTP 버전과 조금 다른 듯 하다.

Scott Guthrie 동영상

본 동영상은 Silverlight가 설치되어 있는 브라우저에서 볼 수 있다.

Posted by 장현춘

ASP.NET MVC 프레임웍의 출시와 더불어 함께 부각되고 있는 것이 IoC (Inversion of Control) 혹은 DI (Dependency Injection) 컨테이너이다. 마틴 파울러는 이 두 용어의 쓰임새를 분명히 하고자 패턴 이름으로 DI를 쓰자고 했으나 여전히 시장에서는 IoC, DI, Hollywood Principle 등을 거의 같은 의미로 사용하고 있다. 
현재 ASP.NET과 연동하여 비지니스 티어에 사용할 수 있는 DI Container로 주로 언급되는 것들로는 StructureMap, Windsor Container, Spring.NET, ObjectBuilder 등이 있다.

StructureMap은 Jeremy D. Miller가 만들고 유지보수호가 있으며, 닷넷 DI 컨테이너 가운데 가장 오래된 것이며 가장 널리 사용되고 있다.

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 기반으로 작성되었으며, 자바와 달리 닷넷의 빠른 변화를 따라잡지 못하는 면이 있다.

Posted by 장현춘

닷넷 프로젝트에서 사용할 수 있는 프레임웍을 한눈에 볼 수 있도록 정리해보자
프레임웍을 구분하는 방법은 여러가지이나 간단하게 티어별로 구분하도록 한다.

프리젠테이션 티어 (웹)
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. Unity - Enterprise Library 4.0 버전에 사용될 DI Container로 ObjectBuilder 후속작. EL과 별개로 사용될 수 있도록 별도 프로젝트로 진행중이며 Codeplex에 현재 2008년 2월 CTP 공개.
4. Windsor Container - 오픈 소스 Castle 프로젝트 일환
5. StructureMap - 닷넷에서 가장 오래된 DI Container. Jeremy D. Miller가 만들고 유지보수하고 있는 오픈 소스 프레임웍
6. NInject - "Lightning-fast dependency injection for .net"을 표방한 오픈 소스 DI Container. 닷넷 프레임웍 3.5 및 Compact Framework 3.5 지원, Silverlight 지원 등이 특징

데이터 티어
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 기능 구현에 사용됨.
13. NConstruct - 상용 / 무료, NHibernate 용 코드 자동 생성(HBM, Entity 등), VS용 project 파일 생성 등

All-in-one
1. DotNetNuke - 복잡한 웹 싸이트 구축, CMS에 까깝다고 할 수 있음
2. Oxite - ASP.NET MVC를 사용, 블로그 엔진, Mix Online 싸이트 운영

기타 범용 프레임웍 (혹은 라이브러리)
1. Enterprise Library - MS patterns and practices(PnP) 팀이 Codeplex를 통해 제공. 캐싱, 로깅, 암호화 등등
2. NVelocity - 템플릿 엔진. 진전이 없어 Castle 프로젝트에서 별도 진행
3. NUnit - 단위 테스트
4. NAnt - 빌드
5. log4net - 로깅
6. CruiseControl.NET - 통합 빌드, ThoughtWorks에서 개발한 오픈 소스

Posted by 장현춘