애플리케이션 개발

ProObject 런타임은 ProObject 프로그래밍 모델에 맞게 작성된 애플리케이션을 수행시킬 수 있으며, 개발자는 이를 이용해 자신이 작성한 애플리케이션을 사용자들에게 서비스할 수 있다.

본 장에서는 ProObject 애플리케이션의 구성과 각 애플리케이션의 구성요소들의 개발 방법, 배포 방법에 대하여 설명한다.

1. 개요

ProObject 애플리케이션은 웹을 통해 제공되는 웹 애플리케이션(Web Application)이다.

개발자들은 ProObject를 통해 원하는 서비스를 개발할 수 있다. ProObject 애플리케이션은 웹 개발에 사용되는 MVC(Model, View, Controller) 개발 패턴에서 Model과 Controller를 담당한다. ProObject의 애플리케이션은 기본적인 화면 없이 모델을 통해 웹 화면이나 다른 서버들로부터 요청과 응답을 데이터 오브젝트(DataObject)에 담아 전달한다. 따라서 ProObject 애플리케이션은 모델에 해당하는 데이터와 서비스의 동작이 담긴 Controller의 집합라고 할 수 있다.

ProObject의 애플리케이션은 제공하는 프로그래밍 모델을 이용하여 서비스들을 작성해야 하며, 작업에 따라 적합한 프로그래밍 모델을 선택해서 구현한다.

다음은 애플리케이션의 계층별 프로그래밍 모델에 대한 설명이다.

  • 데이터 계층 입출력 프로그래밍 모델

    데이터 계층 입출력 프로그래밍 모델은 데이터를 담는 계층으로, 외부와의 통신을 통해 전달되는 입출력과 이를 상호 변환하는 계층을 담당한다. 이 계층은 실제로 존재하는 계층은 아니며 애플리케이션에서 네트워크 I/O 등의 작업을 통해 실제 데이터를 담아내는 객체인 데이터 오브젝트와의 상호 작용을 하는 가상의 계층이다. 이 계층에 속하는 리소스들은 실존하는 채널 이벤트 계층, 이벤트 계층, 서비스 계층에서 모두 사용할 수 있다.

    • 데이터 오브젝트

    • 데이터 오브젝트 팩토리

  • 채널 이벤트 계층 프로그래밍 모델

    채널 이벤트 계층 프로그래밍 모델은 이벤트 드리븐(Event-Driven) 방식으로 특정한 이벤트가 발생했을 때 처리 방식을 작성한 프로그래밍 모델이 제공된다. 채널 이벤트는 다른 서버나 다른 프로세스와 통신을 수행할 때 메시지가 도착했거나, 송신할 메시지가 발생하는 등 채널에 관련된 이벤트들로 정의된다.

    일반적으로 네트워크 카드(Network Interface Card)의 소켓 수신 버퍼(Socket Read Buffer)에 네트워크로부터 데이터가 작성되었거나, 소켓 송신 버퍼(Socket Write Buffer)에 빈 공간이 발생하였을 때, 혹은 엔진으로부터 송신할 메시지가 발생했을 때 등을 채널 이벤트로 처리된다.

    모든 채널 이벤트는 동기적(Synchronous)으로 코드를 작성되지만 ProObject의 이벤트 계층은 싱글 스레드에서 처리되기 때문에 스레드가 대기 상태에 빠질 수 있다. 이를 방지하기 위해서 Java의 NIO를 이용하여 비동기(Asynchronous)적 코드를 작성해주어야 한다.

    채널 이벤트를 처리하기 위해 채널 이벤트 핸들러(Channel Event Handler)와 채널 어셉트 핸들러(Channel Accept Handler)라는 프로그래밍 모델이 제공되며, 이 모델들을 이용한 프로그래밍에 대해서는 채널 이벤트 계층 개발을 참고한다.

  • 이벤트 계층 프로그래밍 모델

    이벤트 계층은 이벤트 드리븐(Event-Driven) 방식으로 특정한 이벤트가 발생했을 때 이 이벤트를 처리 방식을 작성하기 위한 프로그래밍 모델이 제공된다.

    ProObject에서 제공되는 이벤트의 종류와 프로그래밍 모델들은 다음과 같다.

    • 이벤트

      이벤트는 채널 이벤트를 제외한 모든 이벤트를 의미한다. ProObject 런타임 엔진이 처리하는 이벤트는 채널 이벤트나 다른 이벤트 핸들러를 통해서 발생될 수 있다. 채널 이벤트에서 필요한 정보들이 모두 도착한 경우 정보들을 모아 이벤트 객체를 생성해 이벤트를 발생시킬 수 있으며, ProObject 런타임 엔진은 해당 이벤트를 처리하기 위해 이벤트 핸들러(Event Handler)라는 프로그래밍 모델을 제공한다.

      이벤트는 타입에 따라 처리할 이벤트 핸들러의 종류가 1 대 1의 관계를 지니므로, 동일한 타입의 이벤트는 반드시 동일한 이벤트 핸들러를 통해 처리된다. 이러한 이벤트와 이벤트 핸들러를 개발하는 방법에 대한 자세한 내용은 이벤트 계층 개발을 참고한다.

    • 이벤트 서비스(순 서비스)

      사용자는 채널 이벤트와 이벤트를 처리하는 이벤트 핸들러들을 이용하여 싱글 스레드에서 간단한 작업들을 처리할 수 있으나, 프로그래밍 모델이 굉장히 복잡하고 어려워질 수 있다. 따라서 ProObject는 RR Model(Request-Response Model)을 적용하여 보다 쉽게 서비스를 작성할 수 있도록 이벤트 서비스라는 프로그래밍 모델을 제공한다.

      이벤트 서비스는 기본적인 서비스 계층의 서비스 개발방법과 크게 다른 점이 없어 보다 용이하게 개발을 진행할 수 있다. 이벤트 서비스에서는 동기적인 작업이나 오버헤드가 큰 작업들을 처리하는 것을 금지하고 있으며, 다른 서버, 프로세스, 스레드의 응답이 필요한 경우에는 비동기적으로 작업을 처리할 수 있도록 코드를 작성해야 한다. 이러한 서비스를 개발하는 방법에 대해서는 Event Service를 참고한다.

  • 서비스 프로그래밍 모델

    서비스 계층은 서비스 기반 방식으로, RR 모델(Request-Response Model)에 맞는 프로그래밍 모델이 제공된다. 이 계층을 통해 수행되는 서비스들은 한 번 작업이 시작되면 종료될 때까지 별도의 스레드가 할당되어 작업이 수행되기 때문에 이벤트 계층과는 달리, 동기적인 작업이나 오버헤드가 큰 작업들을 처리하기에 적합하다.

    서비스 계층은 그 외에도 트랜잭션을 보장, 의존성 주입(Dependency Injection)등의 강력한 기능들을 기본적으로 제공하고 있어, 서비스를 개발할 때 필요한 복잡하고 어려운 작업들을 손쉽게 처리하는 것이 가능하다. 실제 업무를 개발할 때에는 서비스 계층에서 제공되는 다양한 기능들이 매우 중요한 경우가 많기 때문에, 실제 애플리케이션을 작성할 때에는 이러한 서비스 계층의 요소들을 개발하는 작업이 주를 이루게 된다. 서비스 계층의 요소들을 개발하는 방법에 대해서는 서비스 개발을 참고한다.

    • 서비스 오브젝트

    • 비즈니스 오브젝트

2. 애플리케이션 구성

ProObject의 애플리케이션은 크게 이벤트 계층과 서비스 계층에 속하는 바이너리들과 설정들로 구성된다.

figure application structure
ProObject 애플리케이션 구성도

이벤트 계층에 속하는 바이너리들은 채널 이벤트 핸들러와 이벤트, 이벤트 핸들러들로 구성되며, 자세한 내용은 이벤트 계층 개발을 참고한다. 서비스 계층에 속하는 바이너리들은 같은 속성을 지니는 서비스들을 묶은 서비스 그룹으로 구성되는데 이에 대한 자세한 설명은 서비스 그룹을 참고한다.

2.1. 애플리케이션 바이너리

애플리케이션 공용으로 반드시 사용되어야 하는 바이너리 파일들로 애플리케이션의 리소스로 취급된다. 따라서 애플리케이션이 배포될 때 함께 배포되어야 한다. 바이너리가 누락되어 배포되는 경우 애플리케이션을 수행하는데 있어 문제가 발생할 수 있다.

다음은 애플리케이션 바이너리에 속하는 리소스에 대한 설명이다.

  • 애플리케이션 공용 바이너리

    애플리케이션에 속한 모든 곳에서 참조하기를 원하는 바이너리이다. 채널 이벤트 핸들러, 이벤트, 이벤트 핸들러 등 거의 모든 곳에서 여기에 배포된 바이너리를 참조할 수 있다. 애플리케이션에서 전역적으로 사용을 원하는 바이너리이다.

  • 3rd-party 라이브러리

    ProObject의 리소스로써 개발되지 않았으나 애플리케이션의 각종 작업을 처리하는데 필요한 외부 라이브러리이다.

  • 채널 이벤트 핸들러

    네트워크 I/O와 프로토콜을 처리하기 위해 사용되는 객체이다.

  • 이벤트 / 이벤트 핸들러

    채널 이벤트 핸들러와 이벤트 서비스에서 발생시키고자 하는 이벤트와 해당 이벤트를 처리하는 이벤트 핸들러이다.

2.2. 서비스 그룹

서비스 그룹은 애플리케이션에서 제공할 여러 가지 서비스들 중 같은 유사한 성격의 서비스들을 묶어 그룹화한 것이다. 서비스 그룹은 개발자들이 용이하게 개발할 수 있게 하고 실제 서비스를 보다 쉽게 설정하고 운영할 수 있도록 한다. 서비스 그룹은 서비스를 수행하는데 필요한 업무 로직과 필요한 리소스들로 구성된다.

다음은 서비스 그룹에 속하는 구성요소에 대한 설명이다.

  • 서비스 그룹 공용 바이너리

    서비스 그룹에 속한 서비스들의 공통 작업들을 처리하거나 서비스 그룹에 속한 다른 리소스들에서 참고하기를 원하는 공용 바이너리이다. 주로 비즈니스 오브젝트나 싱글턴 생명주기(Life Cycle)을 지니는 데이터 오브젝트 등의 라이브러리가 주를 이룬다.

  • 3rd-party 라이브러리

    ProObject의 리소스로써 개발되지 않았으나 서비스 그룹 내에서 외부 라이브러리와 실제 업무를 처리하는데 필요한 외부 라이브러리이다. 애플리케이션 3rd-party 라이브러리와 중복되지 않도록 주의해야 한다.

  • 서비스 리소스

    ProObject 툴을 통해 개발된 로직이 정의되어 있는 리소스이다.

    • ServiceObject

    • EventServiceObject

    • BusinessObject

    • DataObject

    • DataObjectFactory

    기본적으로 서비스는 하나의 서비스 그룹에 속하도록 구현된다. 각 구성 요소에 속한 리소스들은 같은 서비스 그룹 내에서라면 서로 참조가 가능하나 다른 서비스 그룹의 리소스는 참조할 수 없다. 다수의 서비스 그룹에서 사용하길 원하는 리소스가 있는 경우에는 애플리케이션 바이너리로써 사용해야 한다.

    데이터 오브젝트의 경우는 다른 서비스 그룹에 속하더라도 업무 로직 내에서 참조가 가능하다. 작성하고자 하는 업무를 다른 서비스 그룹에 작성하는 경우 여러 가지 문제가 발생될 수 있으므로 주의해야 한다.

3. 클래스 로더 구조

ProObject 런타임 엔진은 애플리케이션과 서비스 그룹으로 수직적인 계층 구조(Hierarchy)를 갖는다. 런타임 엔진은 서비스 그룹에서 애플리케이션의 리소스를 참조할 수 있다.

다음은 계층적인 클래스 로더의 계층 구조에 설명이다.

figure application classloader
런타임 엔진의 기본 클래스 로더 구조

서비스 그룹은 애플리케이션에 존재하는 데이터 오브젝트와 여러 리소스를 참조할 수 있지만 서비스 그룹에서 다른 서비스 그룹에 존재하는 데이터 오브젝트는 참조할 수 없다. 이와 같은 구조에서는 다른 서비스 그룹으로 호출이 일어날 수 있는 가능성이 있는 모든 데이터 오브젝트가 애플리케이션의 리소스로 정의되어 한다. 이러한 문제를 해결하기 위해 ProObject 런타임의 클래스 로더는 일반적인 부모-자식 관계 외의 참조(Reference) 관계를 지원한다.

figure application cl reference
일반적인 클래스 로더와 런타임 엔진의 클래스 로더 비교

CASE1과 같이 일반적인 Java 클래스 로더 모델에서는 Child #1 클래스 로더가 Child #2 클래스 로더를 사용할 수 없다. 그러나 CASE2와 같은 런타임 엔진에서는 Child #1 클래스 로더가 Child #2 클래스 로더를 참조함으로써 Child #2의 리소스를 Child #1 클래스 로더가 리소스를 사용할 수 있다.

위와 같은 구조를 이용해 ProObject의 클래스 로더는 다음과 같은 계층구조와 참조 구조를 갖는다(이 장에서 사용되는 모든 그림에서 실선은 상속 관계, 점선은 참조 관계를 나타낸다).

figure application classloader wt ref
데이터 오브젝트의 참조 관계를 포함한 클래스 로더 구조

위 그림에서 보이듯 데이터 오브젝트 컨테이너 클래스 로더는 현재 서버에 배포된 애플리케이션 공용 데이터 오브젝트나 서비스 그룹에 속한 데이터 오브젝트들에 모두 참조 관계를 지니도록 설계되어 있다. 이러한 구조 때문에 애플리케이션 클래스 로더와 서비스 그룹 클래스 로더는 데이터 오브젝트 컨테이너 클래스로더를 참조하여 현재 서버에 배포된 모든 데이터 오브젝트 관련 리소스를 참조할 수 있다.

3.1. 애플리케이션 클래스 로더

애플리케이션 클래스 로더는 서비스 그룹 클래스 로더들의 부모 클래스 로더로 설정된다. 서비스 그룹의 클래스 로더가 클래스를 찾지 못한 경우에는 애플리케이션 클래스 로더에게 클래스를 요청한다.

일반적인 Java 클래스 로더는 부모에게서 먼저 클래스를 찾고 자식이 클래스를 로딩한다. ProObject의 애플리케이션과 서비스 그룹에서 사용하는 리소스는 자신의 애플리케이션과 서비스 그룹에 속한 리소스일 확률이 높다. 따라서 ProObject 런타임의 애플리케이션 클래스 로더와 서비스 그룹 클래스 로더는 자신의 클래스 로더에서 먼저 클래스를 탐색한 후 부모의 클래스를 탐색한다.

서비스 그룹에서 클래스 로더가 자신의 클래스 패스에서 클래스를 찾지 못한 경우 애플리케이션 클래스 로더로 클래스 탐색을 요청한다. 클래스를 탐색을 요청받은 애플리케이션 클래스 로더는 직접 클래스를 로드하지 않고 자신이 관리하는 리소스들 중 서비스 그룹이 바라볼 수 있는 리소스 만을 클래스 로드할 수 있도록 허용한다.

애플리케이션 클래스 로더는 리소스들의 분류에 따라 4가지로 나뉜다.

figure application cl
애플리케이션 클래스 로더 참조 관계

  • 애플리케이션 클래스 로더(Application ClassLoader)

    자신이 직접 리소스를 불러오지는 않고 애플리케이션에 속한 클래스 로더들을 관리하는 역할을 담당한다. 리소스 탐색이 요청된 경우 애플리케이션의 공통 리소스들을 탐색하도록 공용 라이브러리 클래스 로더(Common Lib ClassLoader)에게 요청한다. 이때 공용 라이브러리 클래스 로더는 공용 데이터 오브젝트 클래스 로더와의 참조 관계가 있어 간접적으로 공용 데이터 오브젝트 클래스 로더까지 리소스 탐색을 진행한다.

  • 공용 라이브러리 클래스 로더(Common Lib ClassLoader)

    애플리케이션 공용 바이너리와 애플리케이션 공용 3rd-party 라이브러리들을 불러오는 역할을 담당한다. 공용 라이브러리 클래스 로더는 공용 데이터 오트젝트 클래스 로더로부터 공용 데이터 오브젝트 클래스들을 불러와 사용할 수 있다.

  • 공용 데이터 오브젝트 클래스 로더(Common DataObject ClassLoader)

    자신의 애플리케이션에 속하지 않거나 자신의 서버에 존재하지 않는 데이터 오브젝트들의 클래스를 로드하여, 애플리케이션 내에서 원하는 데이터 오브젝트들을 사용할 수 있도록 한다. 다른 클래스 로더를 참조할 수 없어 자기 자신과 자신의 부모 클래스인 ProObject 최상위 클래스 로더의 리소스만을 참조할 수 있다.

  • 이벤트 클래스 로더(Event ClassLoader)

    채널 이벤트 핸들러, 이벤트, 이벤트 핸들러와 같은 클래스를 로딩한다. 애플리케이션 클래스 로더를 부모로 삼고 있어, 간접적으로 공용 라이브러리와 공용 데이터 오브젝트의 리소스를 참조하여 사용할 수 있다.

3.2. 서비스 그룹 클래스 로더

서비스 그룹 클래스 로더는 기본적으로 서비스 레이어(Sevice Layer)에 속하는 리소스들을 불러오는 역할을 담당한다. 이 외의 영역에 속하는 리소스들은 모두 별도의 클래스 로더가 불러오도록 설정되어 있으며, 서비스 그룹 클래스 로더는 각 클래스 로더들의 참조 관계를 관리한다.

다음은 서비스 그룹 클래스 로더가 관리하는 리소스 영역과 클래스 로더들의 관계에 대한 설명이다.

figure application sg cl
서비스 그룹 클래스 로더 참조 관계

  • 서비스 그룹 클래스 로더(ServiceGroup ClassLoader)

    서비스 그룹에 속한 클래스 로더들을 관리하며, 자신이 직접 서비스 레이어에 속하는 리소스들을 탐색하는 역할을 담당한다.

    서비스 그룹 클래스 로더는 서비스 오브젝트, 비즈니스 오브젝트와 업무 로직의 데이터 I/O를 담당하는 데이터 오브젝트, 데이터 오브젝트 팩토리 등의 리소스들을 불러올 수 있다. 서비스 그룹 라이브러리 클래스 로더를 참조하고 있어 공용 바이너리와 데이터 오브젝트의 리소스들을 참조할 수 있다.

  • 서비스 그룹 라이브러리 클래스 로더(ServiceGroup Lib ClassLoader)

    서비스 그룹 공용 바이너리와 서비스 그룹 공용 3rd-party 라이브러리들을 불러오는 역할을 담당한다. 애플리케이션 클래스 로더를 부모로 삼고 있어, 애플리케이션 클래스 로더가 참조할 수 있는 리소스들을 참조할 수 있다.

  • 서비스 그룹 데이터 오브젝트 클래스 로더(ServiceGroup DataObject ClassLoader)

    서비스 그룹에 속한 데이터 오브젝트들을 불러오는 역할을 담당한다. 위의 그림에서는 표현되지 않았지만 데이터 오브젝트 컨테이너 클래스 로더(DataObjectContainerClassLoader)를 부모로 삼고 있어, 자신외의 다른 데이터 오브젝트 관련 리소드들을 참조하는 것이 가능하다.

  • 서비스 그룹 이벤트 서비스 클래스 로더(ServiceGroup EventService ClassLoader)

    일반적인 서비스 그룹의 리소스와는 달리 이벤트 영역에 속하며 이벤트의 리소르를 다루어야 하는 이벤트 서비스의 클래스를 불러오는 역할을 담당한다. 서비스그룹 클래스 로더를 부모로 지니며, 서비스 그룹 데이터 오브젝트와 서비스 그룹 라이브러리 클래스 로더를 참조할 수 있다.

3.3. 클래스 로더 참조 관계

런타임에서는 클래스 로더의 참조 관계에 따라 사용 가능한 리소스가 달라지게 된다. 따라서 애플리케이션 내에 속하는 여러 리소스를 작성하거나 개발할 때에는 반드시 클래스 로더의 참조 관계를 고려해야 한다. 이 내용이 제대로 고려되지 않는 경우에는 원하는 리소스를 불러오지 못할 수도 있다.

다음은 런타임 엔진의 전체 클래스 로더 참조 관계이다.

figure application classloader full ref
런타임 엔진 클래스 로더 참조 관계

4. 애플리케이션 배포

ProObject의 런타임 엔진에서 애플리케이션을 실행하려면 엔진이 애플리케이션을 인식하고 실행할 수 있어야 한다. 또한 애플리케이션 리소스도 엔진이 인식할 수 있는 디렉터리 구조에 배포해야 한다.

본 절에서는 서버에 애플리케이션을 배포하는 방법에 대해 설명한다.

4.1. 애플리케이션 디렉터리 구조

다음은 런타임 엔진에서 애플리케이션을 수행하기 위한 디렉터리 구조에 대한 설명이다.

{APP_HOME}
  |-- config
  |-- common
       |--dto
       |--lib
  |-- event
  |-- servicegroup
          |-- {SVG_HOME}
                 |--config
                 |--dto
                 |--async
                 |--lib
{APP_HOME}

애플리케이션의 최상위 디렉터리를 의미한다. 애플리케이션의 이름과 디렉터리 이름은 반드시 일치해야 한다. 애플리케이션 이름과 이 디렉터리의 이름이 일치하지 않는 경우에는 리소스를 정상적으로 인식하지 못할 수 있다.

config

애플리케이션 설정에 관련된 모든 파일(application.xml, application.properties, channel.xml, event.xml 등)이 저장되는 디렉터리이다. 각 설정에 대한 자세한 내용은 애플리케이션 설정을 참고한다.

common

애플리케이션에서 공용으로 사용되는 리소스들이 배포되는 공용 바이너리 디렉터러리이다. 배포할 바이너리의 목적에 따라 하위 디렉터리를 사용한다.

하위 디렉터리 설명

dto

애플리케이션에서 다른 서버에 있는 서비스를 호출하는 경우 서비스의 입출력을 하는 데이터 오브젝트와 메시지 클래스를 배포하는 디렉터리이다.

lib

애플리케이션에서 공통으로 사용하는 외부 라이브러리(3rd-party 라이브러리)들을 배포하는 디렉터리이다. 해당 디렉터리에 배포되는 바이너리에는 제한이 없다.
event

애플리케이션에서 사용하는 채널 이벤트 핸들러, 이벤트, 이벤트 핸들러에 관련된 바이너리들이 배포되는 디렉터리이다.

servicegroup

애플리케이션에 속한 서비스 그룹들을 실제로 배포하는 디렉터리이다. 대부분의 경우 애플리케이션에 속한 모든 서비스 그룹들을 한꺼번에 배포하지만 필요한 경우에는 애플리케이션의 특정 서비스 그룹 몇 개만을 배포해도 무방하다.

서비스 그룹은 애플리케이션에 속하기 때문에 항상 자식이 속한 ${APP_HOME}/servicegroup/ 디렉터리가 배포되며, 해당 디렉터리는 서비스 그룹 루트 디렉터리(ServiceGroup Root Directory)가 된다. 해당 경로에 하위에 애플리케이션의 서비스 그룹 이름으로 디렉터리를 생성해서 서비스 그룹을 배포한다.

이때 만들어진 ${APP_HOME}/servicegroup/{SERVICE_GROUP_NAME} 디렉터리가 서비스 그룹 홈 디렉터리(ServiceGroup Home Directory)이며, 본 문서에서는 ${SVG_HOME}이라는 용어로만 서술한다. example 서비스 그룹을 배포하고자 할 때에는 ${APP_HOME}/servicegroup/example 디렉터리가 {SVG_HOME}이 된다.

  • {SVG_HOME}

    서비스 그룹의 최상위 디렉터리이다. 서비스 오브젝트, 비즈니스 오브젝트, 데이터 오브젝트 팩토리의 바이너리들이 배포된다.

    데이터 오브젝트는 반드시 dto 디렉터리에 배포해야 하며, 이벤트 서비스의 경우에는 async 디렉터리에 배포해야 한다. 바이너리들은 대부분 JAR 파일로 배포하나 class 파일들로 배포시켜도 무방하다. 여기에 배포되는 리소스들의 개발 방법에 대해서는 서비스 개발과 데이터 오브젝트/데이터 오브젝트 팩토리 개발을 참고한다.

    하위 디렉터리 설명

    config

    서비스 그룹의 여러 설정 정보가 담기는 디렉터리로, 서비스 그룹의 설정에 관련된 모든 파일이 저장된다. servicegroup.xml과 servicegroup.properties 등 서비스 그룹과 관련된 설정 파일들이 위치하며, 각 설정들에 대한 내용은 서비스 그룹을 참고한다.

    dto

    서비스 그룹에서 사용하기를 원하는 데이터 오브젝트들을 배포하는 디렉터리이다. 서비스 입출력에 사용되는 데이터 오브젝트와 메시지 클래스(네트워크 통신에 사용되는 네트워크 데이터 오브젝트 팩토리)만이 배포된다.

    async

    서비스 그룹의 이벤트 서비스들이 배포되는 위치이다.

    lib

    서비스 그룹에서 공통적으로 사용하는 각종 라이브러리들과 외부 라이브러리(3rd-party 라이브버리)들을 배포시키는 디렉터리이다.

4.2. 애플리케이션 활성화

애플리케이션 디렉터리 구조에서 설명한 것과 같이 애플리케이션을 성공적으로 배포하였다면 런타임 엔진이 해당 애플리케이션을 수행할 수 있도록 해당 애플리케이션을 활성화해주어야 한다.

애플리케이션을 활성화하기 위해서 배포한 애플리케이션의 이름(SYSTEM_APPLICATION)을 system.properties에 설정해야 한다. 자세한 내용은 ProObject 설치 안내서의 서비스 설정을 참고한다.

ProManager를 통해 애플리케이션을 배포하는 경우에는 이러한 작업이 자동으로 이루어지므로 특별히 개발자나 관리자가 처리할 작업이 없다.

5. 애플리케이션 설정

ProObject 애플리케이션은 애플리케이션과 런타임으로 나눠서 설정한다. 본 절에서는 각 설정하는 내용에 대해서 설명한다.

5.1. 애플리케이션 메타 설정

애플리케이션을 개발할 때 작성되는 애플리케이션의 기본 속성을 정의한다. 개발할 때 이미 명시적으로 결정된 사항이기 때문에 애플리케이션 개발 단계 외에는 설정이 불가능하다. 애플리케이션의 이름과 애플리케이션을 수행하는데 필요한 공통 로직, 속성들이 정의하는데 사용된다.

애플리케이션 메타는 아래 경로에 XML 형식으로 작성한다.

${APP_HOME}/config/application.xml

해당 파일은 ProObject의 리소스로 인식되며 ProObject Resource Schema의 네임스페이스를 따른다. 따라서 각 항목은 반드시 'application' 네임스페이스와 일치해야 한다. 네임스페이스가 일치하지 않으면 오류를 발생하며 정상적으로 ProObject가 부팅되지 않으므로 주의한다.

application.xml은 반드시 아래의 예제와 동일한 구조로 작성해야 한다.

<?xml version="1.0" encoding="utf-8"?>
<ns4:application
    xmlns:to="http://www.tmaxsoft.com/proobject/resource/taskobject"
    xmlns:ns16="http://www.tmax.co.kr/proobject/sourcecode"
    xmlns:ns17="http://www.tmax.co.kr/proobject/servicegroup"
    xmlns:ns14="http://www.tmax.co.kr/proobject/jobobject"
    xmlns:ns15="http://www.tmax.co.kr/proobject/serviceobject-automatic"
    xmlns:so="http://www.tmaxsoft.com/proobject/resource/serviceobject"
    xmlns:ns18="http://www.tmax.co.kr/proobject/contents"
    xmlns:ns19="http://www.tmax.co.kr/proobject/probuilder_config"
    xmlns:ns21="http://www.tmax.co.kr/proobject/serverConfig"
    xmlns:ns9="http://www.tmax.co.kr/proobject/flow"
    xmlns:ns22="http://www.tmax.co.kr/proobject/property"
    xmlns:ns23="http://www.tmaxsoft.com/proobject/resource"
    xmlns:jo="http://www.tmaxsoft.com/proobject/resource/jobobject"
    xmlns:ns5="http://www.tmax.co.kr/proobject/dataobject"
    xmlns:ns12="http://www.tmax.co.kr/proobject/serviceobject"
    xmlns:ns6="http://www.example.org/externalObjectConfig"
    xmlns:ns13="http://www.tmax.co.kr/proobject/taskobject"
    xmlns:ns7="http://www.tmax.co.kr/proobject/dto"
    xmlns:ns10="http://www.tmax.co.kr/proobject/dataobjectfactory"
    xmlns:ns20="http://www.tmax.co.kr/proobject/siteConfig"
    xmlns:ns8="http://www.tmax.co.kr/proobject/message"
    xmlns:ns11="http://www.tmax.co.kr/proobject/bizobject"
    xmlns:ns2="http://www.tmax.co.kr/proobject/resource"
    xmlns:bo="http://www.tmaxsoft.com/proobject/resource/bizobject"
    xmlns:ns4="http://www.tmax.co.kr/proobject/application/runtime"
    xmlns:ns3="http://www.tmax.co.kr/proobject/mapping"
    xmlns:xc="http://www.tmaxsoft.com/proobject/resource/contents"
    xmlns:do="http://www.tmaxsoft.com/proobject/resource/dataobject">
    <!-- Application 설정 -->
          :
          :
</ns4:application>
태그 설명

<name>

애플리케이션의 이름을 설정한다.

애플리케이션의 이름은 반드시 설정되어야 하며, 이름이 제대로 설정되어 있지 않으면 오류를 반환하므로 주의한다.

<initializer>

애플리케이션이 부팅될 때 초기화해주는 클래스를 설정한다.

클래스는 반드시 com.tmax.proobject.model.initializer.ApplicationInitializer 인터페이스를 상속받아 구현해야 하며, 바이너리는 애플리케이션 공용 디렉터리에 배포되어야 한다.

바이너리를 배포한 후에는 이 요소에 패키지 이름을 포함한 클래스 이름을 설정한다.

<on-boot-event>

애플리케이션이 부팅된 후 실행할 이벤트들의 타입을 설정한다(실행할 이벤트의 타입은 여러 개가 설정될 수 있다).

애플리케이션의 부팅이 완료되면 설정한 이벤트 타입으로 설정된 com.tmax.proobject.engine.event.po.systemevent.EngineReadyEvent가 발생한다.

<on-boot-service>

애플리케이션이 부팅된 이후 실행할 서비스의 이름을 설정한다.

애플리케이션의 부팅이 완료된 이후에 서비스들이 수행되며, 입력으로는 com.tmax.proobject.engine.system.dto.EmptyDataObject 객체가 전달되며, 출력은 항시 무시된다.

on-boot-service는 다음과 같은 속성들을 지닐 수 있다.

  • order

    • 서비스가 요청되는 순서를 설정할 수 있으며, 오름차순(1, 2, 3, 4 순)으로 실행된다. 설정이 없다면 XML 설정을 읽어온 순서대로 실행하게 된다.

    • order를 설정할 지라도 서비스가 순차적으로 수행되는 것이 아니라, 누가 먼저 요청을 보낼지만을 결정할 수 있음을 유의해야 한다.

  • async

    • 설정한 on-boot-service가 종료되지 않아도 서버를 서비스 가능 상태로 변경할지 여부를 설정한다. (기본값: false)

    • 설정을 하지 않거나, true로 설정하게 되면 설정된 on-boot-service가 종료되기 전까지는 그 어떠한 외부 서비스도 받아들일 수 없는 상태가 된다.

<pre-processor>

애플리케이션에 속한 모든 서비스 그룹의 서비스가 수행되기 전에 수행될 선처리 로직이 작성된 클래스를 설정한다.

클래스는 반드시 com.tmax.proobject.model.service.PreProcessor 인터페이스를 상속받아 구현해야 한다.

생성된 바이너리는 애플리케이션 공용 디렉터리에 배포되어야 한다.

<post-processor>

애플리케이션에 속한 모든 서비스 그룹의 서비스가 수행된 후에 수행될 후처리 로직이 작성된 클래스를 설정한다.

클래스는 반드시 com.tmax.proobject.model.service.PostProcessor 인터페이스를 상속받아 구현해야 한다.

생성된 바이너리는 애플리케이션 공용 디렉터리에 배포되어야 한다.

<custom-header>

애플리케이션에 속한 모든 요청에서 사용할 사용자 정의 헤더의 클래스를 설정한다.

클래스는 반드시 com.tmax.proobject.network.protocol.proobject.request.Header 클래스를 상속받아 구현해야 한다.

생성된 바이너리는 애플리케이션 공용 데이터 오브젝트 디렉터리에 배포되어야 한다. 바이너리 배포한 후에는 이 요소에 패키지 이름을 포함한 클래스 이름을 설정한다.

(기본값: com.tmax.proobject.network.protocol.proobject.request.Header)

<message-bundle-config>

애플리케이션에서 사용할 메시지 번들을 설정한다. 자세한 내용은 메시지 번들을 참고한다.

<web-socket>

애플리케이션에서 사용할 웹 소켓을 설정한다. 자세한 내용은 웹 소켓 개발을 참고한다.

<image-log>

애플리케이션에서 사용할 이미지로그를 설정한다. 자세한 내용은 이미지 로그 설정을 참고한다.

<system-context>

애플리케이션에서 사용할 시스템 컨텍스트와 관련된 설정을 한다. 자세한 내용은 시스템 컨텍스트를 참고한다.

5.2. 런타임 설정

애플리케이션을 배포한 이후 서버에서 운영되는 경우 사용되는 설정을 정의한다. 서버별로 다르게 설정이 가능한 옵션들로 서버의 상태에 따라 변경이 가능하다. 애플리케이션 메타에 작성된 일부 기능을 서버마다 활성화/비활성화하거나 기본 로그 레벨을 변경하는 등 애플리케이션의 운영 설정을 한다.

런타임 설정은 아래 경로에 properties 형식으로 작성하며, 다음 중 하나를 읽어 사용하게 된다.

  • 기본 런타임 설정 파일 위치

    ${APP_HOME}/config/servers/{SERVER_NAME}/application.properties

    {SERVER_NAME} 항목에는 proobject.xml 혹은 환경변수로 등록한 서버의 이름을 사용하게 된다.

  • 통합 런타임 설정 파일 위치

    ${APP_HOME}/config/application.properties

config 디렉터리 하위에 application.properties 파일이 있는 경우에는 해당 파일만 사용하고, 파일이 없는 경우 자신의 서버 이름에 해당되는 디렉터리에서 파일을 찾아서 사용한다. 파일이 작성되지 않은 경우 ProObject에서 기본값으로 설정된 파일을 새로 생성하므로 필요한 경우에만 작성한다.

5.2.1. 로그 설정

애플리케이션에서 기본으로 사용하는 로그에 대해서 설정한다. 애플리케이션 내의 서비스 그룹이나 서비스에서 로그 설정을 추가로 설정하지 않으면 애플리케이션 런타임에 설정된 값으로 설정된다. 애플리케이션 런타임과 ProObject 엔진 설정도 없는 경우 기본값이 사용된다.

APPLICATION_LOG_LEVEL = [SEVERE|WARNING|INFO|CONFIG|FINE|FINER|FINEST]
APPLICATION_LOG_DEBUG_ENABLE = [true|false]
APPLICATION_LOG_ENCODING = log_encoding_code

APPLICATION_LOG_FILEHANDLER_REMOVAL_PERIOD_TYPE = [NONE|DAY|HOUR]
APPLICATION_LOG_FILEHANDLER_REMOVAL_PERIOD = log_filrhandler_period
APPLICATION_LOG_FILEHANDLER_INTERVAL_TYPE = [NONE|DAY|HOUR]
APPLICATION_LOG_FILEHANDLER_INTERVAL = log_filehandler_interval
APPLICATION_LOG_FILEHANDLER_DATE_FORMAT = log_filrhandler_date_format
APPLICATION_LOG_FILEHANDLER_LIMIT = log_filehandler_limit

APPLICATION_EXECUTE_SHELL_BEFORE_LOG = shell_before_log
APPLICATION_EXECUTE_SHELL_AFTER_LOG = shell_after_log
항목 설명

APPLICATION_LOG_LEVEL

애플리케이션의 기본 로그 레벨을 설정한다.

JDK 로거 레벨 중에 설정한다.

  • SEVERE

  • WARNING

  • INFO (기본값)

  • CONFIG

  • FINE

  • FINER

  • FINEST

APPLICATION_LOG_DEBUG_ENABLE

애플리케이션 로그에서 디버그 정보를 출력할지 여부를 설정한다.

true로 설정하면 로그를 남긴 클래스의 이름과 라인 넘버를 함께 기록해서 성능이 저하될 수 있으므로 설정에 주의한다. (기본값: false)

APPLICATION_LOG_ENCODING

애플리케이션 로그에서 사용할 기본 인코딩의 종류를 설정한다.

(기본값: UTF-8)

APPLICATION_LOG_FILEHANDLER_REMOVAL_PERIOD_TYPE

로그를 파일로 기록할 때 어떤 주기로 로그 파일을 삭제할지를 설정한다.

다음 중 하나를 설정한다.

  • NONE : 로그 파일을 삭제하지 않는다.

  • DAY : 정해진 날짜 주기마다 로그 파일을 삭제한다. (기본값)

  • HOUR : 정해진 시간 주기마다 로그 파일을 삭제한다.

APPLICATION_LOG_FILEHANDLER_REMOVAL_PERIOD

로그를 파일로 기록할 때 어떤 주기로 얼마나 지났을 때 로그 파일을 삭제할지를 양의 정수로 설정한다.

(기본값: 1, 현재 시간부터 하루 이상 지난 로그 파일이 삭제된다.)

APPLICATION_LOG_FILEHANDLER_INTERVAL_TYPE

로그를 파일로 기록할 때 어떤 주기로 로그 파일을 서로 분리할지를 설정한다.

다음 중 하나를 설정한다.

  • NONE : 로그 파일을 변경하지 않는다.

  • DAY : 정해진 날짜 주기마다 로그 파일을 변경한다. (기본값)

  • HOUR : 00시를 기준으로 정해진 시간 주기마다 로그 파일을 변경한다.

APPLICATION_LOG_FILEHANDLER_INTERVAL

로그를 파일로 기록할 때 로그 파일을 서로 분리할 주기를 양의 정수로 설정한다. (기본값: 1, 하루마다 로그 파일을 분리한다.)

APPLICATION_LOG_FILEHANDLER_DATE_FORMAT

서비스 그룹 로거의 사용할 로그 파일이름의 Date 포맷을 설정한다.

APPLICATION_LOG_FILEHANDLER_LIMIT

로그를 파일로 기록할 때 각 파일의 최대 크기를 설정한다. 설정한 크기에 근접하는 경우 새로운 파일을 만들어 로그를 계속 작성하게 된다. (기본값: -1)

다음 타입들 중 동작을 원하는 형태로 값을 설정하여 사용한다.

  • 음수 : 파일의 크기를 바탕으로 로그를 나누지 않는다.

  • 양수 : 설정한 값의 KB 단위로 파일이 분할된다.

APPLICATION_EXECUTE_SHELL_BEFORE_LOG

서비스 그룹 로그가 rotate 될 시기 파일이 생성되기 직전 수행하는 shell 명령어를 설정한다.

APPLICATION_EXECUTE_SHELL_AFTER_LOG

서비스 그룹 로그가 rotate 될 시기 파일이 생성된 후 수행하는 shell 명령어를 설정한다.

5.2.2. 메시지 번들 설정

애플리케이션 전역에서 사용하는 메시지 번들에 대해서 설정한다.

APPLICATION_MESSAGE_BUNDLE_ENABLE = [true|false]
APPLICATION_MESSAGE_BUNDLE_LOCALE = bundle_locale
APPLICATION_MESSAGE_BUNDLE_DATASOURCE = bundle_datasource
APPLICATION_MESSAGE_BUNDLE_TABLE = bundle_table
APPLICATION_MESSAGE_BUNDLE_SCHEMA = bundle_schema
항목 설명

APPLICATION_MESSAGE_BUNDLE_ENABLE

애플리케이션 메시지 번들을 활성화할지 여부를 설정한다. 기본적으로는 사용하지 않는다. (기본값: false)

APPLICATION_MESSAGE_BUNDLE_LOCALE

애플리케이션 메시지 번들의 기본 로케일을 설정한다.

APPLICATION_MESSAGE_BUNDLE_DATASOURCE

애플리케이션 메시지 번들을 가져올 페어 데이터소스(Pair Datasource) 이름을 설정한다.

JNDI의 이름을 직접 설정할 필요는 없으며, dbio_config.xml에서 Alias를 설정한다.

APPLICATION_MESSAGE_BUNDLE_TABLE

애플리케이션 메시지 번들을 가져올 데이터베이스의 테이블 이름을 설정한다.

APPLICATION_MESSAGE_BUNDLE_SCHEMA

애플리케이션 메시지 번들을 가져올 데이터베이스의 스키마 이름을 설정한다(생략 가능).

5.2.3. 서비스 관련 설정

애플리케이션에 속한 서비스들의 공용 설정과 서비스 그룹과 관련된 설정을 한다.

APPLICATION_SERVICEGROUP = service_group1,service_group2,service_group3....
APPLICATION_WORKER_THREAD_PRIORITY = thread_priority_value
APPLICATION_TIMEOUT = timeout_value
항목 설명

APPLICATION_SERVICEGROUP

서버에서 수행할 서비스 그룹의 목록을 설정한다.

애플리케이션에 속한 모든 서비스 그룹을 활성화할 수도 있으나, 필요한 경우에는 일부 서비스 그룹들만 활성화할 수도 있다. 다수의 서비스 그룹을 배포하는 경우 콤마(,)를 이용한다.

예를 들어 example, example2 서비스 그룹을 배포하는 경우에는 다음과 같이 설정한다.

APPLICATION_SERVICEGROUP=example,example2

APPLICATION_WORKER_THREAD_PRIORITY

애플리케이션에 속한 모든 서비스 그룹 워커 스레드의 기본 우선순위를 설정한다.

서비스 그룹이나 서비스에 우선순위가 설정된 경우에는 해당 서비스가 수행될 때 이 옵션이 무시된다.

(기본값: 5, 범위: 2~9 사이의 양의 정수)

APPLICATION_TIMEOUT

애플리케이션에 속한 모든 서비스의 기본 타임아웃 시간을 설정한다. 서비스 그룹이나 서비스에 타임아웃 시간을 설정한 경우 이 옵션은 무시된다.

다음의 타입들 중 동작을 원하는 형태로 값을 설정한다.

  • 음수 : 타임아웃이 발생하지 않는다.

  • 양수 : 설정한 값의 ms 단위로 타임아웃 시간이 설정된다.

5.2.4. 이미지 로그 설정

애플리케이션 전역에서 사용하는 이미지 로그에 대해서 설정한다. 설정 항목에 대한 자세한 설명은 이미지 로그 설정의 런타임 설정을 참고한다.

5.2.5. 시스템 컨텍스트 설정

애플리케이션 전역에서 사용하는 시스템 컨텍스트에 대해서 설정한다. 설정 항목에 대한 자세한 설명은 시스템 컨텍스트의 애플리케이션 런타임 설정을 참고한다.

6. 서비스 그룹 설정

ProObject 애플리케이션에 속한 서비스 그룹은 서비스 그룹과 런타임으로 나눠서 설정한다.

설정한 파일은 애플리케이션 디렉터리의 ${SVG_HOME}/config에 배포된다. 서비스 그룹의 디렉터리는 애플리케이션 디렉터리의 하위에 위치하며 기본적으로 ${APP_HOME}/servicegroup/ 디렉터리에 사용할 서비스 그룹들을 배포한다. 자세한 내용은 애플리케이션 디렉터리 구조를 참고한다.

본 절에서는 서비스 그룹을 설정하는 방법과 항목에 대해서 설명한다.

6.1. 서비스 그룹 메타 설정

서비스 그룹을 개발할 때 작성되는 서비스 그룹의 기본 속성으로, 서비스 그룹의 이름과 서비스 그룹을 수행하는데 필요한 공통 로직, 속성들을 정의한다.

서비스 그룹 메타는 아래 경로에 XML 형식으로 작성한다.

${SVG_HOME}/config/servicegroup.xml

해당 파일은 ProObject의 리소스로 인식되며 ProObject Resource Schema의 네임스페이스를 따른다. 네임스페이스가 일치하지 않으면 오류를 발생하며 정상적으로 ProObject가 부팅되지 않으므로 주의한다.

servicegroup.xml은 반드시 아래의 예제와 동일한 구조로 작성해야 한다.

<?xml version="1.0" encoding="utf-8"?>
<ns17:service-group
    xmlns:to="http://www.tmaxsoft.com/proobject/resource/taskobject"
    xmlns:ns16="http://www.tmax.co.kr/proobject/sourcecode"
    xmlns:ns17="http://www.tmax.co.kr/proobject/servicegroup"
    xmlns:ns14="http://www.tmax.co.kr/proobject/jobobject"
    xmlns:ns15="http://www.tmax.co.kr/proobject/serviceobject-automatic"
    xmlns:so="http://www.tmaxsoft.com/proobject/resource/serviceobject"
    xmlns:ns18="http://www.tmax.co.kr/proobject/contents"
    xmlns:ns19="http://www.tmax.co.kr/proobject/probuilder_config"
    xmlns:ns21="http://www.tmax.co.kr/proobject/serverConfig"
    xmlns:ns9="http://www.tmax.co.kr/proobject/flow"
    xmlns:ns22="http://www.tmax.co.kr/proobject/property"
    xmlns:ns23="http://www.tmaxsoft.com/proobject/resource"
    xmlns:jo="http://www.tmaxsoft.com/proobject/resource/jobobject"
    xmlns:ns5="http://www.tmax.co.kr/proobject/dataobject"
    xmlns:ns12="http://www.tmax.co.kr/proobject/serviceobject"
    xmlns:ns6="http://www.example.org/externalObjectConfig"
    xmlns:ns13="http://www.tmax.co.kr/proobject/taskobject"
    xmlns:ns7="http://www.tmax.co.kr/proobject/dto"
    xmlns:ns10="http://www.tmax.co.kr/proobject/dataobjectfactory"
    xmlns:ns20="http://www.tmax.co.kr/proobject/siteConfig"
    xmlns:ns8="http://www.tmax.co.kr/proobject/message"
    xmlns:ns11="http://www.tmax.co.kr/proobject/bizobject"
    xmlns:ns2="http://www.tmax.co.kr/proobject/resource"
    xmlns:bo="http://www.tmaxsoft.com/proobject/resource/bizobject"
    xmlns:ns4="http://www.tmax.co.kr/proobject/application/runtime"
    xmlns:ns3="http://www.tmax.co.kr/proobject/mapping"
    xmlns:xc="http://www.tmaxsoft.com/proobject/resource/contents"
    xmlns:do="http://www.tmaxsoft.com/proobject/resource/dataobject">
    <!-- 서비스 그룹 메타 설정 -->
            :
            :
</ns17:service-group>

다음은 설정 항목에 대한 설명이다.

태그 설명

<group-name>

서비스 그룹의 이름을 설정한다.

<initializer>

서비스 그룹의 초기화를 담당하는 클래스를 설정한다.

클래스는 반드시 com.tmax.proobject.model.initializer.ServiceGroupInitializer 인터페이스를 상속받아 구현해야 한다.

생성된 바이너리는 서비스 그룹 공용 라이브러리 디렉터리에 배포되어야 한다. 바이너리를 배포한 후에는 이 요소에 패키지 이름을 포함한 클래스 이름을 설정한다.

<post-initializer>

서비스 그룹의 초기화가 끝난 직후 수행해야 하는 로직이 작성된 클래스를 설정한다.

클래스는 반드시 com.tmax.proobject.model.initializer.ServiceGroupPostInitializer 인터페이스를 상속받아 구현해야 한다.

생성된 바이너리는 서비스 그룹 공용 라이브러리 디렉터리에 배포되어야 한다. 바이너리를 배포한 후에는 이 요소에 패키지 이름을 포함한 클래스 이름을 설정한다.

<pre-processor>

서비스가 수행되기 앞서 먼저 처리되어야 할 로직이 작성된 선처리 클래스를 설정한다.

클래스는 반드시 com.tmax.proobject.model.service.PreProcessor 인터페이스를 상속받아 구현해야 한다.

생성된 바이너리는 서비스 그룹 공용 라이브러리 디렉터리에 배포되어야 한다. 바이너리 배포한 후에는 이 요소에 패키지 이름을 포함한 클래스 이름을 설정한다.

<post-processor>

서비스가 수행된 후에 처리되어야 할 로직이 작성된 후처리 클래스를 설정한다.

클래스는 반드시 com.tmax.proobject.model.service.PostProcessor 인터페이스를 상속받아 구현해야 한다.

생성된 바이너리는 서비스 그룹 공용 라이브러리 디렉터리에 배포되어야 한다. 바이너리 배포한 후에는 이 요소에 패키지 이름을 포함한 클래스 이름을 설정한다.

<worker-priority>

서비스 그룹에 속한 워커 스레드의 기본 우선순위를 설정한다. 런타임 설정이 해당 서비스가 수행될 때 이 옵션이 무시된다.

(기본값: 5, 범위: 2~9 사이의 양의 정수)

<service-object>

서비스 그룹에 속한 서비스 오브젝트들에 대한 설정을 설정한다. 자세한 내용은 서비스 설정을 참고한다.

<error-service-on>

서비스 그룹에서 설정된 오류 처리 서비스 기능을 사용할지 여부를 설정한다. (기본값: false, 범위: true | false)

<error-service>

서비스 그룹에서 사용할 오류 처리 서비스들을 설정한다.

해당 옵션을 사용하기 위해서는 반드시 <error-service-on>이 true로 활성화된 상태여야만 한다. 자세한 내용은 서비스 설정을 참고한다.

오류 처리 서비스 설정

오류 처리 서비스에 대한 자세한 내용은 서비스 설정을 참고한다.

태그 설명

<service-name>

오류 처리 서비스에서 사용할 서비스의 이름을 설정한다.

6.2. 런타임 설정

서비스 그룹을 배포한 이후 서버에서 운영되는 경우 사용되는 설정으로 서버마다 설정되는 서비스 그룹 설정이다. 서비스 그룹 메타에 작성된 일부 기능을 서버 마다 활성화/비활성화하거나, 기본 로그 레벨을 변경하는 등을 설정한다.

런타임 설정은 아래 경로에 properties 형식으로 작성한다.

${SVG_HOME}/config/servicegroup.properties

파일이 작성되지 않은 경우 ProObject에서 기본값으로 설정된 파일을 새로 생성하므로 필요한 경우에만 작성한다. 파일을 새로 생성하는 경우 모든 설정값을 기본값으로 사용한다.

6.2.1. 로그 설정

애플리케이션에서 기본으로 사용하는 로그에 대해서 설정한다. 애플리케이션 내의 서비스 그룹이나 서비스에서 로그 설정을 추가로 설정하지 않으면 애플리케이션 런타임에 설정된 값이 설정된다. 애플리케이션 런타임과 ProObject 엔진 설정도 없다면 기본값이 사용된다.

SERVICEGROUP_LOG_LEVEL = [SEVERE|WARNING|INFO|CONFIG|FINE|FINER|FINEST]
SERVICEGROUP_LOG_DEBUG_ENABLE = [true|false]
SERVICEGROUP_LOG_ENCODING = log_encoding_code

SERVICEGROUP_LOG_FILEHANDLER_REMOVAL_PERIOD_TYPE = [NONE|DAY|HOUR]
SERVICEGROUP_LOG_FILEHANDLER_REMOVAL_PERIOD= log_filrhandler_period
SERVICEGROUP_LOG_FILEHANDLER_INTERVAL_TYPE = [NONE|DAY|HOUR]
SERVICEGROUP_LOG_FILEHANDLER_INTERVAL = log_filehandler_interval
SERVICEGROUP_LOG_FILEHANDLER_DATE_FORMAT = log_filrhandler_date_format
SERVICEGROUP_LOG_FILEHANDLER_LIMIT = log_filehandler_limit

SERVICEGROUP_EXECUTE_SHELL_BEFORE_LOG = shell_before_log
SERVICEGROUP_EXECUTE_SHELL_AFTER_LOG = shell_after_log
항목 설명

SERVICEGROUP_LOG_LEVEL

애플리케이션의 기본 로그 레벨을 설정한다.

JDK 로거 레벨 중에 설정한다.

  • SEVERE

  • WARNING

  • INFO (기본값)

  • CONFIG

  • FINE

  • FINER

  • FINEST

SERVICEGROUP_LOG_DEBUG_ENABLE

서비스 그룹 로그에서 디버그 정보를 출력할지 여부를 설정한다.

true로 설정하면 로그를 남긴 클래스의 이름과 라인 넘버를 함께 기록하나, 성능상에 하락이 발생하므로 주의깊게 설정한다.

(기본값: false)

SERVICEGROUP_LOG_ENCODING

서비스 그룹 로그에서 사용할 기본 인코딩의 종류를 설정한다.

(기본값: UTF-8)

SERVICEGROUP_LOG_FILEHANDLER_INTERVAL_TYPE

로그를 파일로 기록할 때 어떤 주기로 로그 파일을 서로 분리할지를 설정한다.

다음의 값들 중 하나를 설정한다.

  • NONE : 로그 파일을 변경하지 않는다.

  • DAY : 정해진 날짜 주기마다 로그 파일을 변경한다. (기본값)

  • HOUR : 00시를 기준으로 정해진 시간 주기마다 로그 파일을 변경한다.

SERVICEGROUP_LOG_FILEHANDLER_INTERVAL

로그를 파일로 기록할 때 어떤 주기로 얼마나 지났을 때 로그 파일을 서로 분리할지를 양의 정수로 설정한다.

(기본값: 1, 하루마다 로그 파일이 따로 작성되도록 되어 있다.)

SERVICEGROUP_LOG_FILEHANDLER_REMOVAL_PERIOD_TYPE

로그를 파일로 기록할 때 어떤 주기로 로그 파일을 삭제할지를 설정한다.

다음의 값들 중 하나를 설정한다.

  • NONE : 로그 파일을 삭제하지 않는다.

  • DAY : 정해진 날짜 주기마다 로그 파일을 삭제한다. (기본값)

  • HOUR : 정해진 시간 주기마다 로그 파일을 삭제한다.

SERVICEGROUP_LOG_FILEHANDLER_REMOVAL_PERIOD

로그를 파일로 기록할 때 어떤 주기로 얼마나 지났을 때 로그 파일을 삭제할지를 양의 정수로 설정한다.

(기본값: 1, 현재 시간부터 하루 이상 지난 로그 파일이 삭제된다.)

SERVICEGROUP_LOG_FILEHANDLER_DATE_FORMAT

서비스 그룹 로거의 사용할 로그 파일이름의 Date 포맷을 설정한다.

SERVICEGROUP_LOG_FILEHANDLER_LIMIT

로그를 파일로 기록할 때 각 파일의 최대 크기를 설정한다. 설정한 크기에 근접하는 경우 새로운 파일을 만들어 로그를 계속 작성한다. (기본값: -1)

아래의 타입들 중 동작을 원하는 형태로 값을 설정하여 사용한다.

  • 음수 : 파일의 크기를 바탕으로 로그를 나누지 않는다.

  • 양수 : 설정한 값의 KB 단위로 파일이 분할된다.

SERVICEGROUP_EXECUTE_SHELL_BEFORE_LOG

서비스 그룹 로그가 rotate 될 시기 파일이 생성되기 직전 수행하는 shell 명령어를 설정한다.

SERVICEGROUP_EXECUTE_SHELL_AFTER_LOG

서비스 그룹 로그가 rotate 될 시기 파일이 생성된 후 수행하는 shell 명령어를 설정한다.

6.2.2. 메시지 번들 설정

서비스 그룹에서 사용하는 메시지 번들에 대해서 설정한다.

SERVICEGROUP_MESSAGE_BUNDLE_ENABLE = [true|false]
SERVICEGROUP_MESSAGE_BUNDLE_LOCALE = bundle_locale
SERVICEGROUP_MESSAGE_BUNDLE_DATASOURCE = bundle_datasource
SERVICEGROUP_MESSAGE_BUNDLE_TABLE = bundle_table
SERVICEGROUP_MESSAGE_BUNDLE_SCHEMA = bundle_schema
항목 설명

SERVICEGROUP_MESSAGE_BUNDLE_ENABLE

서비스 그룹 메시지 번들을 활성화할지 여부를 설정한다. 기본적으로는 사용하지 않는다. (기본값: false)

SERVICEGROUP_MESSAGE_BUNDLE_LOCALE

서비스 그룹 메시지 번들의 기본 로케일을 설정한다.

SERVICEGROUP_MESSAGE_BUNDLE_DATASOURCE

서비스 그룹 메시지 번들을 가져올 페어 데이터소스(Pair Datasource)의 이름을 설정한다. 다만 JNDI의 이름을 직접 설정할 필요는 없으며, dbio_config.xml에서 Alias를 설정한다.

SERVICEGROUP_MESSAGE_BUNDLE_TABLE

서비스 그룹 메시지 번들을 가져올 데이터베이스의 테이블 이름을 설정한다.

SERVICEGROUP_MESSAGE_BUNDLE_SCHEMA

서비스 그룹 메시지 번들을 가져올 데이터베이스의 스키마 이름을 설정한다.

6.2.3. 서비스 관련 설정

다중 애플리케이션을 사용할 때에만 사용되는 옵션으로 현재 애플리케이션에서 사용할 서비스 그룹의 설정과 애플리케이션에 속한 서비스들의 공용 설정을 한다.

SERVICEGROUP_TIMEOUT = timeout_value
SERVICEGROUP_WORKER_THREAD_PRIORITY = thread_priority_value
SERVICEGROUP_WORKER_THREAD_COUNT = thread_value
SERVICEGROUP_WORKER_THREAD_CORE_COUNT = thread_core_count_value
SERVICEGROUP_WORKER_THREAD_MAX_COUNT = thread_max_value
항목 설명

SERVICEGROUP_TIMEOUT

서비스 그룹에 속한 모든 서비스의 기본 타임아웃 시간을 설정한다. 서비스에 타임아웃 시간을 설정한 경우 이 옵션은 무시된다.

아래의 타입들 중 동작을 원하는 형태로 설정한다.

  • 음수 : 타임아웃이 발생하지 않는다.

  • 양수 : 설정한 값의 ms 단위로 타임아웃 시간이 설정된다.

SERVICEGROUP_WORKER_THREAD_PRIORITY

서비스 그룹에 속한 워커 스레드의 기본 우선순위를 설정한다.

서비스에 우선순위가 설정된 경우에는 해당 서비스가 수행될 때 이 항목은 무시된다. (기본값: 5, 범위: 2~9 사이의 양의 정수)

SERVICEGROUP_WORKER_THREAD_COUNT

서비스 그룹에서 사용할 워커 스레드의 초기 개수를 양의 정수로 설정한다. 특별한 부하가 없는 상황에서 워커 스레드는 이 항목에 설정된 초기 개수 만큼의 스레드 수가 유지된다. (기본값: 10)

SERVICEGROUP_WORKER_THREAD_CORE_COUNT

서비스 그룹에서 사용할 워커 스레드의 부하 대비 개수를 설정한다. 설정값은 초기 개수 이상의 양의 정수로 설정한다.

한 번 이상 부하가 발생한 경우 부하를 대비하기 위해 유지할 스레드의 수를 설정한다. 최대 스레드 수에 도달한 후 부하가 사라지면 이 항목에 설정한 개수만큼의 스레드 수를 유지한다.

(기본값: 30)

SERVICEGROUP_WORKER_THREAD_MAX_COUNT

서비스 그룹에서 사용할 워커 스레드의 최대 개수를 설정한다. 설정값은 부하 대비 개수 이상의 양의 정수로 설정한다.

심한 부하가 주어진 경우 워커 스레드가 늘어날 최대의 개수를 의미한다. (기본값: 50)