MSFL :: 모리스 소프트웨어 공작소

  자바에서 손 쉽게 웹 어플리케이션을 구동시키는데는 톰캣(Tomcat)이 많이 사용되는 것 같아서 초보자의 입장에서 정리해 보도록 한다.   톰캣은 웹 컨테이너 (Web Container) 로 웹 서버안에서 Servlet 과 JSP 를 지원한다. 물론 이런 웹 컨테이너를 제공하는 웹 서버 프로그램은 다양하다. 그 중에서 무료이고 많이 사용하는 것이 Tomcat 이다.  톰캣이 구동되기 위해서는 JDK/JRE 가 필요하며 JAVA_HOME 설정이 존재해야 한다. 환경변수 설정   이미 JDK/JRE 는 설치되었다는 전제하에 기본 환경변수를 설정하는 것에 대해 알아보도록 하자. 내 컴퓨터나 내 PC에서 마우스 우측 버튼을 눌러 "속성 > 고급 시스템 환경" 을 선택하면 아래와 같은 화면이 나타난다. 여기서 "환경변수" 버튼을 누른다.   환경변수 창에서 "시스템변수" 항목의 "새로 만들기" 버튼을 눌러서 새로운 시스템 변수를 생성한다.   이름은 "JAVA_HOME" 으로 하고 값은 JDK 가 설치된 경로를 설정한다. 설치된 JDK 버전과 시스템 유형 (x86, x64) 에 따라서 설치된 경로를 지정한다.   "확인" 버튼을 눌러서 생성하고 "사용자 변수" 항목에서 "path"를 선택하고 "편집" 버튼을 누르거나 더블클릭하여 선택하도록 한다. (path 변수는 사용자와 시스템에 양쪽에 존재하므로 아래와 동일하게 구성하도록 한다)   이미 존재하는 값들 뒤에 ";" 를 붙이고 "%JAVA_HOME%\bin;" 을 추가한다. (사용자 및 시스템 path 에 모두 적용)   이번에는 다시 "시스템 변수" 항목에서 "새로 만들기" 버튼을 누르고 "CLASSPATH...

  Application Performance Management 에 대한 여러 가지 정보를 검토하던 중에 생소한 용어들이 보여서 하나씩 정리해 놓도록 한다. (자바 쪽에서는 모든 용어들이 생소하기는 하지만 ㅠㅠ) JMX (Java Management eXtension) - 쉽게 생각하면 Windows 의 WMI (Windows Management Instrumentation) 와 같은 것이라고 판단이 된다. Spring Framework에서 제공되는 JMX 에 대한 정리가 필요하다. PMI (Performance Monitoring Infrastructure) - 현재까지의 자료로는 JMX Connector를 통해서 연동되는 Websphere Application Server 의 서비스로 판단이 되며, 성능에 관련된 모니터링 자료를 제공하는 듯 하다. BCI (Byte Code Instrumentation) - 자바 컴파일러에 의해서 생성되는 Byte Code (Meta Data) 를 직접 처리하여 소스 코드의 변경 없이도 원하는 기능을 추가하는 방법을 제공한다. APM 적인 측면에서 바라보면 AOP를 통해서 성능 측정과 관련된 기능을 소스코드의 수정없이 추가할 수 있는 것이라고 생각된다.   항상 개발을 할 때는 베이스 깔고 시작하는 프레임워크에 따라서 변동이 있기 때문에 검토해야 할 방향이 변경될 수는 있지만 아마도 위의 3가지는 고정 불변의 경우라고 생각된다. 단, PMI 는 아직 특정한 제품에서 제공이 되는 것인지에 대한 추가 검토가 필요할 듯 하다.

  다음 프로젝트가 자바로 개발을 해야 하는 것이라서 자바에 대해서 잘 정리된 사이트를 찾던 중에 몇 가지 사이트를 확인하고 정리해 둔다. 소설같은 자바 II   점프 투 자바 그 동안 .NET Framework 에서만 작업을 했지만, 급하게 개념적인 부분만이라도 정리를 해 놓고 플젝을 시작해야 할 듯 하여 정리한 것이므로 내용이 개념적인 부분의 정리만 존재한다. 기타 실제 개발하는 과정에서 필요한 각종 요소들은 그때 그때 정리할 수 밖에는 없을 듯...

  다음 프로젝트는 APM (Application Performance Management) 를 위한 프레임워크 구성이 될 듯 하다. 개인적으로는 별도로 접근했던 적이 없었기 때문에 흥미롭고, 도전해 볼만한 주제라서 좋다. 다양한 측면에서 여러 가지 기술이나 기법들을 파악해야 하므로 하나씩 정리해 놓도록 한다. APM Solution   말 그대로 어플리케이션의 성능을 관리하기 위한 솔루션이라고 보면 된다. 우리 나라 제품군에서는 아마도 가장 유명한 것이 Jennifer (Java/.NET) 일 것이다. 그럼 어떤 기능들이 있어야 APM Solution이라고 할 수 있을지 검토해 보도록 하자. 운영서버 모니터링 웹 어플리케이션 사이트 모니터링 전체 거래 모니터링 실행 서비스 모니터링 응답 시간 분석과 그래프 (View) 측정 결과 분석을 통한 문제 발견 기능 부하량 제어 사용자 정의 대시보드 기타   아마도 상기와 같은 기능들이 기본적으로 제공될 수 있어야 할 것이다. 즉, 문제가 발생한 후에 문제를 파악하기 위한 용도라기 보다는 현재의 상황에 대한 명확한 판단의 근거와 향후 예측 및 현재 발생한 문제의 해결을 위한 솔루션이라고 정의하고 접근하는 것이 맞을듯 하다.   여기서 APM 솔루션에서 가장 중요한 부분은 "문제" 라고 하는 것이 어떻게 정의될 것인가? 에 대한 기준을 제시하는 것이다. 그래야 성능에 대한 정량화와 서비스 운영에 대한 가시성이 확보될 것이기 때문이다. 따라서 이런 기준을 바탕으로 문제의 발생 여부를 확인하고 대처할 수 있는 정보를 제공할 있어야 APM 솔루션이라고 할 수 있을 듯 하다. 또한 성능을 모니터링하고 문제점을 검증 및 해결하기 위한 정보를 제공하는 솔루션으로서의 APM 이 어플리케이션의 성능에 영향을 줄 정도로 부하가 발생되어서는 안 된다. 따라서 많은 경험과 패턴들을 이용해서 최적화된 솔루션 이어야 한다.   그럼 이제 위에서 ...

  아직 명확하게 DSL 특정 지우기에는 시기상조이기는 하지만 Visual Studio 에서 제공하는 DSL Tools 기능을 이용해서 솔루션을 만들어서 아주 간단하게 실체를 확인해 보도록 하자. DSL Authoring Solution   DSL 을 사용할 수 있도록 DSL 자체를 구성하는 작업을 "DSL Authoring" 이라고 한다. 즉, 배포된 DSL을 이용할 수 있도록 DSL 의 Shape, Connector 등의 기본 요소들을 구성하는 단계라고 보면 된다.   이 작업을 위해서는 사용할 Visual Studio 버전에 맞는 " Visual Studio SDK " 가 미리 설치되어 있어야 한다. 설치가 되어 있다면 Visual Studio에서 새 프로젝트를 추가할 때 아래의 그림과 같이 "확장성" 부분이 있는 것을 볼 수 있다.   "Domain-Specific Language Designer" 는 DSL 구성을 위한 프로젝트들로 구성된 솔루션을 만드는 템플릿이다. 프로젝트 이름과 위치를 설정한 후에 확인 버튼을 눌러서 계속 진행하면 프로젝트를 구성하기 위한 마법사가 진행된다.   DSL 에 대한 Template 은 "Minimal"을 선택하고, DSL 이름은 "IssueStateModels" 라고 지정하도록 한다.   위의 그림과 같이 DSL 을 구성하기 위한 여러 개의 템플릿들이 존재하는 것을 볼 수 있다. MSDN 에는 템플릿들에 대해서 아래의 표와 같이 설명하고 있다. Template Features Description Class Diagrams Compartment shapes Class inheritance Relationship inheritance Shape inheritance Relationship properties Use this sol...

  진행 중인 프로젝트에서 동일 경로에 존재하는 동일한 어플리케이션이 중복 실행이 되지 않도록 하여야 하는 요구가 들어와서 프로세스를 검증하는 로직을 구성하였다. 아래의 예제에서는 자체적으로 구성한 프레임워크를 사용하는 것도 포함되어 있으므로 해당하는 구문은 알아서 전환 처리해야 한다. Process 가져오기   실행 중인 프로세스들은 다음과 같은 명령을 사용해서 동일한 명칭을 가지는 프로세스들을 가져온다. Process [] processes = Process .GetProcessByName( Path .GetFileNameWithoutExtension( AppContext .ApplicationName)); 현재 Process 를 제외한 나머지 검증   프로세스의 이름이 동일하기 때문에 현재 자신의 프로세스도 포함이 된다. 따라서 아래와 같이 자신을 제외한 것들을 대상으로 하여야 한다. Process [] processes = Process .GetProcessByName( Path .GetFileNameWithoutExtension( AppContext .ApplicationName)); foreach ( Process p in processes) { // 자기 자신 검증. if ( Process .GetCurrentProcess().Id != p.Id) { . .. } } }   이제 작업 경로를 비교하여 동일한 경로에 속한 것만 중복 메시지로 처리한다. Process [] processes = Process .GetProcessByName( Path .GetFileNameWithoutExtension( AppContext .ApplicationName)); foreach ( Process p in processes) { // 자기 자신 검증. if ( Process .GetCurrentProces...

  이번에는 프레임워크 구성의 실질적인 중심이 될 수 있는 DSL 에 대해서 여러 가지 자료를 검색해 본 결과를 기준으로 나름대로 하나씩 정리를 해 나가도록 한다. 이 글을 정리하고 있는 현재도 아직 뚜렷한 대상이나 구분이 명확하게 인식된 것이 아니기 때문에 좀 더 많은 글들과 사례들을 확인해 볼 필요가 있다. DSL 이란?   Domain Specific Language (DSL) 은 특정한 도메인(산업, 분야등 특정 영역)에서 발생하는 문제점을 해결하는 것에 중점을 두고 도메인을 기준으로 모든 것을 풀어나가기 위해서 제공되는 언어라고 생각하면 된다. 즉, 특정 영역의 해결에는 그 영역에 맞는 특화된 도구를 사용하자는 의미다. 이와 연관되어 나오는 단어는 DDD (Domain Driven Design) 이라는 것으로 모두 처음 발표된지 이미 최소한 10년 정도의 시간이 경과한 기술이며 정의이다.   현실에서도 많이 구현되어 사용되고 있지만 아직도 DSL 에 대한 정의 자체부터 논란이 있다. 단어 자체로는 "특정 문제에 맞는 언어"라고 볼 수 있지만, 보는 입장에 따라서, 그리고 구현되는 방식에 따라서 다양한 형태로 정의될 수 있기 때문일 것이다.   DSL 에 대해서 가장 잘 정리된 글은 마틴 파울러의 글 을 참고하면 된다. 외부 OOPSLA 컨퍼런스에서 Domain-Specific Modeling 에 대한 워크샾등으로 많은 논의가 되었던 것으로 알고 있다.   DSL 이 도메인 전문자 (Domain Expert) 의 입장에서 작성이 되려면 High-Level 언어로 작성이 되고, 이를 Code Generator를 통해서 일반 언어로 변환이 되어야 한다. 그러나 이런 경우에 코드의 최적화가 어렵고, 프로그래머가 작성하는 DSL 에 비해서 유연성이 떨어질 수 밖에는 없다. 그리고 프로그래머가 작성하는 DSL 도 Internal 과 External 에 따라서 테스트 용이성이나 통합 비용 등에 차이가 ...

현재 진행 중인 프로젝트에서 IMAGE 나 PDF 등 (Binary Data)을 저장하고 조회하는 기능이 필요해서 오라클 DB에 ODP.NET을 이용해서 작업을 구성하였다. BLOB  작업 LOBs Basic   LOBs 는 데이터베이스에 저장할 수 있는 데이터 스트림으로서의  Large OBject 를 의미한다. 최대 처리할 수 있는 크기는 4G이며 다음과 같은 형식을 제공한다. BLOB - 비정형 바이너리 데이터로 저장되는 형식으로 문자형식(Character set)에 상관없는 비트스트림이다. CLOB - Single byte 와 Multi byte 의 문자형 데이터를 의미하고 고정/가변 길이를 제공하고 데이터베이스의 Character Set 기준을 따라서 저장된다. NCLOB - CLOB 과 같지만 Unicode 데이터로 저장된다.    LONG 이나 LONG RAW 형식을 처리하는 것과 같이 OracleDataReader를 이용해서 LOB 필드에 저정된 값을 읽을 수 있다. LOB 데이터 형식을 사용하는 방식의 다른 점은 DML 이나 PL/SQL 을 이용해서 해당 필드에 접근하는 경우에 명확하게 구분된다. BLOB 이나 CLOB 의 경우는 별도의 테이블스페이스에 저장이 되기 때문에 해당 필드는 데이터가 존재하는 위치의 포인터 정보만 가지고 있게 된다. (LOB Locator) 따라서 LONG 이나 LONG RAW 형식과는 다른 방식으로 관리가 된다. Working with BLOB   아래와 같이 기본 테이블을 구성하도록 한다. CREATE TABLE BLOBSAMPLE (    FILE_ID VARCHAR2(32) NOT NULL,    FILE_NAME VARCHAR2(200) NOT NULL, FILE_EXTENSION VARCHAR2(10) NOT NULL, ...

기존 게시글 까지 해서 기본적인 방법에 대해서 알아 보았으므로 이번 부터는 좀 더 다양하게 활용하는 방법에 대해서 알아보도록 하자. 뭐... 굉장한 응용은 아니고 이미 Visual Studio IDE를 통해서 처리되는 것들이지만 Visual Studio 의 도움 없이도 처리할 수 있도록 스크립트를 구성해 보는 것이기 때문에 아마도 모르고 지나간 원리들을 정리하는데 도움이 될 것이다. MSBuild 응용   요즘 거의 대부분의 PC 들이 멀티 프로세스 환경이기 때문에 이 환경에서 Rebuild 문제를 검토해 보고, 그 다음에는 MSBuildTasks 를 통해서 확장을 하는 것 까지 검토해 보도록 한다. Rebuild on Multi Processor or Core   개인 PC 와 빌드 서버의 차이는 아마도 Processor 나 Core 라고 해도 될 것이다. 2 CPU * 2 Core 인지, 1 CPU * 2 Core 일지 등등 말이다. 그냥 생각하면 별 것 아닌 것 같지만 아래의 내용을 검토해 보면 차이가 존재하고 이것이 문제가 될 수도 있으므로 이를 검토해 보도록 하자. <Target Name="Build"> <Message Text="타겟: Build" /> <Message Text="빌드 조건: '$(BuildCondition)'" Importance="high" /> <MSBuild Projects="@(ProjectReferences)" Properties="Configuration=%(ProjectReferences.Configuration);Platform=%(ProjectReferences.Platform)" StopOnFirstFailure="true" /> </Targ...