최근에 많은 기술이 쏟아지고, .NET 의 생태계에도 새로운 국면을  맞이했습니다. 바로 Microsoft  에서 야심차게 준비하고 있는 .NET 4.0 플랫폼과 Team Foundation Server 기술은 상상과 생각을 현실로 이루어주는 강력한 밑거름이 되기 때문입니다.

 

지금이 아마 우리도 함께 변화할 수 있는 최고의 시점이며, 본 세미나는 그 길을 열어주는 가장 효과적인 세미나가 될 것입니다.



본 세미나는 프로젝트를 주도하는 관리자나 프로젝트 매니저를 위한  세미나입니다. 세미나 신청은 아래 "세미나 등록하기" 버튼을 클릭하십시오.

 

ALM 의 도입과 그 필요성

여러분의 조직은 효율적이라고 생각하나요? 바꾸어 보십시오. 국내 최고 아키텍처겸 컨설턴트인 닷넷엑스퍼트의 안재우 수석님의 많은 경험을 전수해드립니다. Team System MVP 엄준일 선임은 ALM 을 이용하여 효과적인 관리 방법, 팀과 조직이 한발 앞의 미래를 바라보는 노하우를 알려드립니다.

 

기업용 LOB 프로그램의 테스트 환경 구축
"왜 소프트웨어에 결함이 발생할까?" 라는 80년대의 구세대적이고 형식적인 질문은 버리십시오. 오늘날 소프트웨어 개발부터 운영까지 최신의 테스팅 기법과 기술을 직접 눈으로 확인하십시오. 테스트 자동화와 테스트 가상화는 분명 여러분들의 감탄과 탄성을 자아낼 것입니다.

 

WPF 기반 스마트클라이언트 적용 고객 사례
국내에 한번 있을까 말까한 최대 규모의 .NET 프로젝트를 닷넷엑스퍼트에서 수행하였습니다. 최신 프레젠테이션 기술인 WPF 를 이용하여 UX 컨설턴트 김선구 책임이 직접 참여한 프로젝트입니다. 최신 기술과 UX 와의 교감, 개발까지 아우르는 현장감있는 그들의 고민과 재미있는 경험을 들을 수 있을 것입니다.


 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

우리 회사는 트위터를 오픈하여 회사의 소식과 .NET 뉴스를 전하고 있습니다.

 

http://twitter.com/dxnews

   

저희 이건복 대표 이사님께서 관리하시는 이 트위터를 통해 좋은 정보 많이 얻어가시고, 여러분들과의 좋은 소통의 장이 되길 기대해 봅니다.

'UMC > 엄씨 생각' 카테고리의 다른 글

나쁜 관리자가 프로젝트를 망치고 있다! 정말~?  (3) 2010.03.26
좀 더 UX 에 다가가기  (0) 2010.02.16
.NETXPERT 의 트위터 오픈  (0) 2010.02.09
당신이 생각하는 UX 란?  (8) 2010.02.08
꿈 (Dream)  (0) 2009.03.07
20대 가기전에 취미만들기  (1) 2008.11.03
Posted by 땡초 POWERUMC

댓글을 달아 주세요

앞서 얘기한 DxEF Dynamic Proxy 를 통해 WCF 서비스 확장 프레임워크가 탄생되었습니다. SoaServices 라는 이름에서도 알 수 있듯이 SOA(Services Oriented Architecture-서비스 지향 아키텍처) 를 구현하도록 도와주는 SOA 프레임워크입니다.

먼저 SOA, 그리고 SOA 를 구현하는 ESB(Enterprise Services Bus) 의 이해를 돕기 위해 아래의 링크를 참고하세요.

Enterprise Service Bus를 이용한 서비스의 연결
http://www.oracle.com/technology/global/kr/tech/soa/mastering-soa-series/part2.html

바로 SOA 를 구현하는 ESB 의 핵심 키워드는 아래와 같이 3개로 뽑을 수 있습니다.

  • 서비스 가상화
  • 중앙 집중적
  • 정책 (Policy)

   

즉, SOA 인프라스트럭처로 전환하기 위해서는 많은 노력이 필요한데, DxEF.Proxy.Dynamic.SoaServices 는 개발 초기부터 SOA 기반으로 개발이 용이하도록 도와주는 프레임워크입니다.

 

실제로 대규모의 시스템에서 서비스의 확장을 고민하고, 서비스를 물리적/논리적으로 아무리 갈기 갈기 찢어 놓아봐야 결국 서비스 지향 아키텍처로 눈을 돌릴 수 밖에 없는 것이 현실입니다. 그렇지 않으면 지속적인 서비스 확장에 중복적인 비용이 들어갈 수 밖에 없으니까요.

DxEF.Proxy.Dynamic.SoaServices 프레임워크는 바로 개발 단계와 운영 단계별로 Provider 가 완벽하게 분리가 되어있습니다. 개발자는 서버의 물리적인 배치, 서비스의 종류, 서비스 제공자를 전혀 알지 못해도 개발이 가능하고, 이런 서비스는 즉시 운영 단계에서 서비스가 가능합니다. 그야말로 How 가 아닌, 좀 더 중요한 What 이라는 비즈니스 관점에서 개발과 운용이 가능하다는 점입니다.

개발 초기부터 Interface Contract 를 통해 완벽하도록 느슨하게 서비스가 결합되고, 프레임워크에서 제공하는 Interface Metadata 로 빠르게 서비스의 Delivery 가 가능합니다.

DxEF SOA Services 프레임워크에 대해서는 좀 더 베일에 가려놓도록 하고, 다음에 기회가 되면 다시 언급하도록 하겠습니다. ^__^

Posted by 땡초 POWERUMC

댓글을 달아 주세요

최근 .NET 에서도 오픈 소스 프레임워크가 상당히 대세이고, 많은 오픈 소스 프레임워크가 공개되고 있습니다. 개발자들은 선택의 폭이 굉장히 넓어졌고, 참고할 수 있는 레퍼런스의 양도 이제는 헤어릴 수 없을 정도입니다. 심지어 .NET Framework 소스 코드까지 디버그 심볼로 그 내부를 볼 수 도 있으며, 최근 .NET Framework 4.0 에 포함되는 일부 라이브러리는 아예 오픈 소스로 공개하고 있습니다.

이러한 프레임워크 홍수 속에서 어떤 프레임워크를 선택하느냐 또한 큰 고민이 아닐 수 없습니다. 예전 Pattern & Practice 스터디를 할 때 토론했던 내용 중에 '왜 돈주고 프레임워크를 쓰느냐! 오픈 소스를 써라' 라는 질문에 굉장히 좋은 비유의 답변을 들은 적이 있었습니다.

"내가 미국을 가기 위해서 조립 설명서를 보고 비행기를 조립해서 갈 수 도 있지만, 이미 만들어진 비행기를 타고 가는 방법이 있다. 선택은 자유다!"

필자는 오픈 소스 프레임워크를 반대하는 사람은 아닙니다. 저 또한 좋은 레퍼런스를 너무 감사하게 생각하고 있습니다. 대부분의 오픈 소스 프레임워크는 범용적으로 사용되기 위한 목적이기 때문에 도메인 집약적인 큰 프로젝트에서는 오픈 소스 프레임워크의 내부적인 파이프라인을 모르고서는 원활하게 쓰기가 힘이 들 수 도 있습니다. 특히 장애 발생 시 장애 추적의 범위가 훨씬 넓어지며, 문제 해결 또한 쉬운 작업은 아닐 것입니다.

어쨌든 나의 Dynamic Proxy 프레임워크 개발은 이러한 범용성이 강한 오픈 소스 프레임워크로는 도저히 불가능했습니다. 일부 검증되지 않은 오픈 소스 프레임워크와 돌아다니는 코드를 조합하여 원하는 기능을 만들자니 내 기분은 짜증이 나기 시작했습니다.

처음에는 P&P Unity Application Block 과 몇몇 오픈 소스를 사용하고자 했으나 제가 원하는 스팩 미달이었습니다. 일단 Unity Block 의 Dynamic Proxy 는 대략 아래와 같은 스팩을 제공해 줍니다.

종류

설명

비고

Interface Proxy

인터페이스를 구현한 객체의 Proxy 를 만듦

반드시 인터페이스를 구현해야 함

Virtual Method Proxy

Virtual 로 선언된 Method 의 Proxy 를 만듦

(.NET 에서는 명시적인 virtual 선언 없이는 불가능 하기 때문에 좀 불편하죠. 참고로 Java 에서는 명시적인 virtual 이 없이도 virtual 메서드로 컴파일 됩니다)

반드시 virtual 로 선언해야 함

Transparent Proxy

.NET Remoting 의 Real Proxy 를 이용하여 Proxy 를 만듦

성능이 느림

Interceptor Extension

프락시 객체에 AOP 와 같이 위빙(Weaving) 처리

  

결국 내가 하고자 하는 Dynamic Proxy + Mock 와 같은 좀 더 로우 레벨로 제어하기 힘들었습니다. 특히 Unity Application Block 에서는 IoC Container 와 함께 사용해야 하는 Extension 형태로 Dynamic Proxy 와 Interceptor 가 제공이 되기 때문에 단독적인 Proxy Framework 로는 사용하기에 적합하지 않았습니다.

   

DxEF.Proxy.Dynamic - Dynamic Proxy 프레임워크

결국 Interface 계약 기반의 Dynamic Proxy 와 Mock Object Proxy 를 생성이 가능한 프레임워크가 필요로 했습니다. 그리고 여기에 Interception 기능을 추가하여 Dynamic AOP 가 가능해졌습니다.

 

DxEF Dynamic Proxy 의 약간의 샘플을 보여드립니다. 어떤 느낌인지 감이 오셨는지요~?

[TestClass]

public class ProxyTest

{

[TestMethod]

public void TestMethod1()

{

InterfaceImplementationDynamicProxy<ILogger, Logger> proxy =

new InterfaceImplementationDynamicProxy<ILogger, Logger>();

var proxyObject = proxy.CreateProxy();

   

proxyObject.Write("A");

}

}

   

public interface ILogger

{

[SampleInterceptor]

void Write(string msg);

}

   

public class Logger

{

}

   

   

public class SampleInterceptorAttribute : InterceptorAttribute

{

public override IInterceptor CreateInterceptor()

{

return new SampleInterceptorHandler();

}

}

   

public class SampleInterceptorHandler : IInterceptor

{

#region IInterceptor 멤버

   

public InterceptorReturnMessage Invoke(InterceptorInputMessage input, InvokeRealMethod invoke)

{

Console.WriteLine("Before Action...");

   

var returnMsg = invoke(input);

   

Console.WriteLine("After Action...");

   

return returnMsg;

}

   

#endregion

}

   

이러한 Interface 계약 기반으로 C# 4.0 에서 제공하는 Duck Typing 을 Dynamic Proxy 만으로도 가능해집니다. 더 나아가 Mock Object 로 단위 테스트(Unit Test) 의 확장이 가능하고, PostSharp 과 같은 Assembly Rewrite AOP 방식으로도 활용이 가능합니다.

또한 빠른 성능을 위해 Proxy Object 는 Caching 이 되고, 특히 런타임에서 JIT 컴파일이 되지 않기 때문에 빠른 성능을 보장할 수 있습니다.

   

   

지금까지 단순히 DxEF Dynamic Proxy 에 대해서 주절주절 했는데, 이 프레임워크를 확장하여 훨씬 기가 막힌 재미있는 것은 다음 편에 계속 됩니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 태디 2010.01.13 22:13 신고 Address Modify/Delete Reply

    잘 이해는 안가지만 잠깐 테스트 해본 개인적인
    입장에서...

    Dynamic 키워드 데이터 타입이나 형변환에 있어서
    뭐라고 표현할까?... 굉장히 유연하네...

    var 키워드가 linq에 더 효과적인 듯 잘쓰면
    유용하지만 여기저기 .Net 3.5, .Net 4.0 프레임워크가
    더 보편화되면 초보개발자들이나 나같이 무식한
    개발자들은 쓰기 쉽고 편하다고 여기저기 남발하는건
    아닌지 모르겠다...

    잘쓰면 약 못쓰면 독이 되듯 말이야

    • 땡초 POWERUMC 2010.01.13 23:14 신고 Address Modify/Delete

      아마도 이해가 다른 듯 해서...
      Dynamic Proxy 는 내부적으로 Proxy 를 생성하는데..
      .NET Framework 에도 대표적인것이 Remoting Proxy 이고
      실제로 Runtime Type AOP 로 .NET 진영에서는 가장 널리 쓰기이기도 하는데,
      이 리모팅 프락시의 가장 큰 단점은 클래스 단위밖에
      Interceptor 를 걸 수 없다는 단점이 있어..
      결국 .NET Remoting Proxy 는 Nested Method Proxy 를 구현할 수 없다는 단점이 있었는데...
      이것을 극복하고자 다양한 DI Framework 나 Spring.NET 에서 구현한 방법인데
      이번 Dynamic Proxy 는 쓰임새가 명확한 프레임워크라고 볼 수 가 있어.
      좀 범용적이지는 않지만, Dynamic Proxy 와 더불어 WCF 와 통합할 목적이었거든 ^_^;;
      에구에구

    • 테디 2010.01.14 07:00 Address Modify/Delete

      고마워 좀더 공부해보고 리플 달아준 부분에 대해서 접근을 해야겠네

  2. 2010.01.26 18:22 Address Modify/Delete Reply

    지금은 잘 maintenance 되지 않고 있는 듯한 linfu project

    http://code.google.com/p/linfu/

    등에 비해 확실히 뛰어난 점이 있는지요?

    • 땡초 POWERUMC 2010.01.26 18:47 신고 Address Modify/Delete

      같은 Dynamic Proxy 라는 점에서 그리 뛰어난 점은 없습니다.
      대부분의 Proxy 프레임워크가 그러하듯 말입니다.

      하지만 제가 만든 Dynamic Proxy 는 위의 3가지 Proxy 이 외의 Proxy 객체를 만들 수 있습니다.
      (그리고 현재는 위의 3가지를 지원하지도 않지만, 지원하도록 할 수도 있지요.)

      예를 들어, Interface 를 통해 Mockup 을 하는데, 다음 장에 소개가 되는 Dynamic Proxy SoaService 와 연관이 깊습니다.

      어찌되었건 더 뛰어난 점도 뒷쳐지는 점도 없습니다만,
      Linfu 나 Unity 의 Interceptor/Proxy 기능도 제공되지만,
      궁극적으로 저는 ESB/SOA 를 구현하는 Proxy 를 주목적으로 하였습니다.

    • 2010.01.27 00:37 Address Modify/Delete

      어디서 많이 본 프로젝트인데.. 싶어서 단 댓글에 친절하게 답변해주시니 그저 감사할 따름입니다. (굽신)

      하긴 그전에도 리모팅을 위한 serialization을 고려했다든지, 요샌 WCF 등과 연계해서 객체를 주고받는 쪽과 연계시키는게 많아보이더군요. 전문 프로그래머가 아니라 자세히는 안파봤지만..

이례적으로 우리 회사에서 직원들의 추천이 아닌 형태로 직원을 채용합니다. 지원 분야는 UX Engineer 와 Software Engineer 로 개발자 뿐만 아니라, 디자이너에게도 채용의 문이 활짝 열려있습니다.

인생에 있어 기회는 세 번이라고도 하죠? 아마도 이번이 당신에게 기회가 될 수 있습니다. 주저하지 마시고 얼른 지원해 보세요.

 

 Job Title: UX Engineer

직급: Open

 

업무:

응용프로그램 소프트웨어를 UX(User Experience)적인 관점에서 분석하고, 이를 향상시키기 위한 방향을 제시합니다. UI 디자인 뿐만 아니라, 소프트웨어에 대한 사용자의 상호 작용 관계를 이해하고 응용프로그램 개발자와 협업을 할 수 있어야 합니다. UI에 대한 표준을 수립하고, 이를 UI 디자이너 및 UI 개발자들에게 교육시키는 역할을 수행합니다.

 

필수 자격 요건:

·         디자인 Skill

·         UI 분석 능력

·         Expression Bend 및 XAML 사용 경험자

 

선택 자격 요건(우대사항)

·         Expression Blend XAML 사용 경험자

·         WPF / Silverlight을 사용한 프로젝트 수행 경험자

·         Windows 응용프로그램 디자인 경험자

 

전형절차:

·         서류 전형 : 이력서 및 포트폴리오

·         면접

 

연락처 및 이력서 접수: job@dotnetxpert.com

 

 

 Job Title: Software Development Engineer

직급: 사원, 선임

업무:

응용프로그램 프레임워크/솔루션 개발 업무를 수행합니다. Agile 개발 프로세스에 의해 작업을 진행하며, Team Foundation Server를 통해 응용프로그램 수명 주기 관리(ALM : Application Lifecycle Management) 하에서 개발을 수행하게 됩니다.

 

필수 자격 요건:

·         .NET Framework에 대한 이해

·         Visual Studio C#

·         .NET 기반의 웹 응용프로그램 개발(ASP.NET / Silverlight) 또는 Windows 응용프로그램(WinForm/WPF) 개발 경험 또는 개발 가능자

·         협업 및 의사소통 기술

 

선택 자격 요건(우대사항)

·         응용프로그램 프레임워크(: DxFramework, Microsoft.Framework, Spring.NET, Enterprise Library )  사용 경험

·         Microsoft MVP 자격

·         Agile 개발 방법론에 대한 이해

·         ALM(Application Lifecycle Management) 도구 사용 경험(: Visual Studio Team System)

 

전형절차:

·         서류 전형 : 이력서 및 프로젝트 수행 경력

·         면접

 

연락처 및 이력서 접수: job@dotnetxpert.com

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

저희 닷넷엑스퍼트에서 아래와 같이 직원을 채용한다고 합니다. 숨어 계시는 무림 고수분들,, 서둘러 지원해 주세요^^

혹시라도 주변에 자격 요건이 되시는 분이 계시면 추천해 주셔도 괜찮습니다.

 

Job Title: Lead(Senior) Consultant

직급: 책임

업무:

고객사의 개발 컨설팅 프로젝트에 참가하여 아키텍처를 수립하고 기술 표준화에 대한 가이드를 제공하고 전반적인 소프트웨어 개발 프로세스에 대하여 컨설팅을 진행합니다.

또한 개발사 또는 개발인력이 효과적으로 프로그램을 개발할 수 있도록 표준 Framework에 기반을 두고 컨설팅 서비스를 제공합니다. 다양한 프로젝트의 개발 경험을 가지고 있고 개발 컨설팅에 관심이 있으며 솔루션 개발 경험이 있는 인원을 찾습니다.  또한 이 직책은 특성상 팀을 리드할 수 있는 높은 기술수준과 커뮤니케이션 스킬이 요구됩니다.  

 

요구사항:

·         경력사항: 최소 7년 이상의 소프트웨어 개발 경력

·         기술 항목: 소프트웨어 개발 방법론, Windows Operating System구조 이해, .NET Framework의 동작 모델 이해, Smart Client, WPF, WCF RDBMS의 사용과 이해

·         프로그램 개발도구(언어): Visual Studio (C#, VB), C/C++

·         프로토콜: Http, TCP/IP, XML 웹서비스  

 

전형절차:

·         이력서 접수 서류전형 및 면접

연락처 및 이력서 접수: job골뱅이dotnetxpert.com

Posted by 땡초 POWERUMC

댓글을 달아 주세요