KR20100101855A

KR20100101855A - 응용서버 개발시스템

Info

Publication number: KR20100101855A
Application number: KR1020090020259A
Authority: KR
Inventors: 김수길
Original assignee: 주식회사 엘지씨엔에스
Priority date: 2009-03-10
Filing date: 2009-03-10
Publication date: 2010-09-20
Also published as: KR101061326B1

Abstract

실시예는 응용서버 개발시스템에 관한 것이다.

실시예에 따른 응용서버 개발시스템은 응용서버 개발에 있어서, 다이아그램을 이용한 리파지토리(Repository) 기반의 실시간 응용서버 개발시스템을 포함한다.

응용서버, 모델링, 테스트

Description

응용서버 개발시스템{DEVELOPING SYSTEM FOR APPLICATION SERVER}

실시예는 다이어그램을 이용한 리파지토리(Repository) 기반의 실시간 응용서버 개발 및 그 운영 시스템에 관한 것이다.

종래에는 응용시스템 개발시, 생산성과 품질향상의 요구가 커지고 있으며, 이를 위해 설계문서작성, 소스코딩, 컴파일, 배포하는 각 과정을 지원하는 여러 도구들의 사용이 필수화 되고 있다.

그런데, 종래기술에 의하면 최초 개발시 뿐만 아니라 지속적인 변화관리 시 생산성 및 품질을 저하시키는 요인이 많다.

예를 들어, 종래기술에 의하면 각 도구 생성물 형태가 다르고 통합적 연계성 부족으로 수동 동기화 작업이 필요하다.

또한, 종래기술에 의하면 컴파일 시 상호종속관계 불일치, 배포 시 환경과의 불일치로 인한 추가 작업 필요하다.

또한, 종래기술에 의하면 테스트 시 설계, 개발 사전검증 미비로 버그 제거 작업등의 추가 작업 필요하다.

또한, 종래기술에 의하면 재사용 시 비즈니스 모델 파악이 매우 어려워 소스 코드 수준의 카피(Copy) 후 붙히기(Paste)의 활용수준에 그친다.

실시예는 상기 문제점 등을 해결하기 위한 것으로, 단일 형태(다이아그램)로 생성, 변경, 실행이 가능하도록 함으로써 완전한 통합성 및 추가작업을 제거하여 생산성과 품질 향상 모두를 극대화하고, 또한, 이를 통한 비즈니스 모델 정제 및 갭(GAP) 반영 신속성을 통해 재사용성을 극대화 하기 위한 것이 목적이다.

실시예에 따른 응용서버 개발시스템은 응용서버 개발에 있어서, 다이아그램을 이용한 리파지토리(Repository) 기반의 응용서버 개발시스템을 포함한다.

실시예에 따르면, 소스코딩작업 없이 설계사양을 다이아그램으로 생성, 변경, 실행하게 함으로써 일관된 뷰(View)로 여러작업(설계작성, 소스코딩, 빌드, 배포)을 단일화하여 생산성 및 품질 향상을 제공하며, 정형화된 비즈니스 모델 획득 및 활용을 통한 재사용성 향상을 제공할 수 있다.

즉, 실시예는 소스코딩, 컴파일, 배포 작업 없이 설계사양을 다이아그램으로 표현하는 것으로 응용서버개발 완료 및 운영(변경관리, 실행)을 통한 생산성 극대화 및 품질향상과 비즈니스 모델의 재사용성 극대화할 수 있다.

실시예는 응용서버를 개발하는 방법에 있어서, 설계사양을 문서화하고 다시 소스코딩 및 컴파일하고 배포하는 것이 아니라, 설계사양을 다이아그램으로 표현하면 Repository 기반의 통합관리(변경관리, 호출관계관리)를 통한 품질향상(설계검 증, 문서와 소스 불일치 문제 제거)과 Repository 기반의 실행엔진을 통한 생산성 향상(소스코딩 제거) 및 품질 향상(코딩오류제거)을 가져올 수 있다.

또한, 실시예는 기존 사례 활용 시, 불일치된 설계문서로 어려운 소스코드를 분석해서 부분적으로 활용해야 하는 것이 아니라, 기 모델링된 비즈니스 모델을 담고 있는 Repository의 정제 유연성(소스코드가 아닌 다이아그램을 통한 이해도 증가)과 실행 즉시성(운영환경과 상관없는 엔진을 통한 실행)을 통해 재사용 가치를 극대화할 수 있다.

이하, 실시예를 첨부된 도면을 참조하여 상세히 설명한다.

실시예에 따르면, 소스코딩작업 없이 설계사양을 다이아그램 만으로 생성, 변경, 실행하게 함으로써 일관된 뷰(View)로 여러작업(설계작성, 소스코딩, 빌드, 배포)을 단일화하여 생산성 및 품질 향상을 제공하며, 정형화된 비즈니스 모델 획득 및 활용을 통한 재사용성 향상을 제공할 수 있다.

실시예에 따른 다이어그램을 이용한 Repository 기반의 실시간 응용서버 개발 및 그 운영 시스템(100)은 모델링UI(110) 와 서버(120)를 포함할 수 있다.

상기 모델링UI(110)는 서버환경 정의를 위한 관리화면과 비즈니스 모델링을 위해 4개의 Layer(Business Service, Business Rule, Data Access, Service Access)를 포함할 수 있으며, 각 Layer 별 모델링 기능을 제공하고 원격지의 서버 (모델링엔진)와 통신을 통해 생성, 변경, 테스트 기능을 수행할 수 있다.

상기 서버(120)는 모델링엔진(121), 실행엔진(122), Repository(123)를 포함 할 수 있다.

상기 모델링엔진(121)은 서버환경 관리자와 4개의 Layer 별 모델 관리자로 구성되며, 모델링 UI로부터 받은 정보를 Repository에 저장관리하고, 실시간 반영 및 테스트를 위해 서버(실행엔진)에 요청하는 기능을 수행한다.

상기 실행엔진(122)은 4개의 Layer별 실행자로 구성되며, 각 Layer 별 Repository 정보를 로딩하여 비즈니스 로직, DB 질의 및 Legacy 연동 등을 수행할 수 있다.

또한, 상기 실행엔진(122)은 테스트용과 서비스용으로 구분되어, 테스트용은 테스트 DB를 사용하여 모델링UI 에서 실시간 검증 시 사용되며, 서비스용은 운영 DB를 사용하여 업무용UI, Legacy시스템 등에서 요청 시 서비스를 제공하는 역할을 한다.

상기 Repository(123)는 다이아그램으로 그려진 모든 비즈니스 로직을 통합 저장하는 비즈니스 모델 저장소 역할을 한다.

실시예는 도 2와 같이 동작할 수 있다.

즉, 실시예는 소스코딩, 컴파일, 배포 작업 없이 설계사양을 다이아그램으로 표현하는 것 만으로 응용서버개발 완료 및 운영(변경관리, 실행)을 통한 생산성 극 대화 및 품질향상과 비즈니스 모델의 재사용성 극대화할 수 있다.

실시예는 응용서버를 개발하는 방법에 있어서, 설계사양을 문서화하고 다시 소스코딩 및 컴파일하고 배포하는 것이 아니라, 설계사양을 다이아그램으로 표현하면 Repository 기반의 통합관리(변경관리, 호출관계관리)를 통한 품질향상(설계검증, 문서와 소스 불일치 문제 제거)과 Repository 기반의 실행엔진을 통한 생산성 향상(소스코딩 제거) 및 품질 향상(코딩오류제거)을 가져올 수 있다.

(실시예)

이하 실시예에 따른 응용서버 개발시스템을 활용하여 비즈니스 솔루션 서버를 구축하고, 서비스를 오픈 하고 변화관리에 대응하는 방법을 eLibrary를 이용해 설명한다. eLibrary는 실시예에 따른 응용서버 개발시스템에 기본적으로 포함되어 있는 예제 비즈니스 솔루션이며, 비즈니스 솔류션이 이에 한정되는 것은 아니다.

이하에서는 요구 사항의 정의 단계, 모델링 계획 단계, 모델링 및 테스트 단계, 메소드(Method) 노출단계, 변경관리 단계 순으로 설명하기로 한다.

한편, 실시예를 도서관리 등에 대한 응용서버 개발시스템에 대해서 설명하나 실시예가 이러한 도서관리 등에 한정되는 것은 아니다.

먼저, 요구사항 단계는 요구사항을 정의할 수 있으며, 요구사항은 업무구분에 따라 도서관리, 도서대출 및 반납, 현황조회 등이 있을 수 있으며, 도서관리의 경우 도서입고, 도서검색, 도서조회, 도서수정, 도서폐기 등의 세부 요구사항이 있을 수 있다.

다음으로, 상기 요구사항에 따라 모델링 계획 단계를 설명한다.

실시예에서는 모델링 계획을 위해 유스케이스 다이어그램을 설정하고, 이에 따라 시퀀스 다이어그램을 설정할 수 있다.

예를 들어, 도 3과 같이 "도서관리" 요구사항 중 "도서입고"에 대한 시퀀스 다이어그램을 설정할 수 있으며, 도서검색, 도서수정 등 다른 요구사항에 대한 시퀀스 다이어그램을 설정할 수 있다.

다음으로, 모델링 및 테스트 단계를 설명한다.

모델링 및 테스트 단계는 비즈니스 로직(Business Logic)을 모델링하고 테스트하면서 서비스를 완성해 나가는 단계이다. 실시예에서의 모델링 및 테스트 단계는 모델링 및 테스트 환경구축 단계, 데이터 액세스(Data Access) 모델링 및 테스트 단계, 데이타 액세스 메소드 실행단계(Activate Data Access Method), 비즈니스 룰(Business Rule) 모델링 단계, 비즈니스 룰 메소스 실행단계(Activate Business Rule Method)를 포함할 수 있으나 이에 한정되는 것은 아니다. 이하 순차적으로 설명한다.

우선, 모델링 및 테스트 환경구축 단계를 설명한다.

모델링 및 테스트 환경구축은 관리자가 직접 수행할 수 있다. 따라서, 환경 구축을 위해서는 응용서버 개발시스템에 ".admin." 등으로 사용자로 로그인할 수 있다. ".admin." 사용자의 최초 암호는 ".admin."일 수 있다.

이후, DB(Database) 서버등록을 진행한다. 이 단계에서는 Data Access 레이어에서 접속할 Database 서버를 등록한다. 이때 실시예는 Database 서버 변경에 의한 영향을 최소화 하기 위하여, Database 서버 등록 시 Alias를 부여할 수 있다. 이에따라 Data Access 레이어에서는 각 Database 서버에 부여된 Alias를 참조하며, Database 서버 관련 정보가 변경되었다 하더라도, Data Access 레이어는 변경될 필요가 없으며, Database 서버 관련 정보만 변경해주면 된다.

예를 들어, eLibrary가 사용하는 Database에 대한 Alias로 ".eLibraryDB."를 입력할 수 있다. Database 등록 화면의 ".Name." 텍스트 박스에 입력할 수 있다.

실시예에서 eLibrary가 사용하는 Database는 Oracle과 MS SQL Server 2000 이상을 지원할 수 있으며 이에 한정되지 않는다. 예를 들어, 실시예는 Microsoft SQL Express 2005를 채용할 수 있으며, 서버 유형을 SQL(Structured Query Language) Server로 선택할 수 있으나 이에 한정되는 것은 아니다. 실시예는 자바(Java) 버전과 닷넷(.NET) 버전으로 구현이 가능하며, Java 환경의 경우 예를 들어 JDK 1.4 이상, WAS(WebLogic/WebSphere/JEUS이 가능하다.

실시예에서 eLibrary가 사용하는 Database는 구축 단계에서 사용할 Database와 서비스 중에 사용할 Database가 별도로 구분되어 있지 않을 수 있으며, 각 Item과 Value는 각각 쌍을 이루어 Database Connection String으로 연결될 수 있다. 만약 더 필요한 연결 정보가 있다면 관리자가 직접 추가할 수 있다.

실시예에 따른 응용서버 개발시스템은 비즈니스 솔루션 서버 구축 단계에서 접속할 Database 서버 정보(Test Server Information)와, 실제 서비스 중일 때 접속할 Database 서버 정보 (Service Server Information)를 구분하여 관리할 수 있다. 즉, 비즈니스 솔루션 서버 구축 시에 발생하는 Database 관련 작업은 Test Server Information에 정의된 Database 서버에서 수행되고, 서비스가 시작된 후 발생하는 Database 관련 작업은 Service Server Information에 정의된 Database 서버에서 수행될 수 있다.

다음으로, 모델러를 등록단계를 설명한다. 이단계는 모델링 및 테스트에 참가할 모델러를 등록하는 단계로서 ID 부여와 Password 부여할 수 있다. 예를 들어, 실시예에서 eLibrary는 기본적으로 추가되어 있는 ".sample." 계정을 이용할 수 있으므로 별도의 ID 등록이 필요 없을 수 있고, ".sample." 계정의 초기 암호는".sample."일 수 있다.

이때 실시예에서 eLibrary의 Component와 Method는 ".sample." 계정이 소유권을 가질수 있다. 따라서 ".sample." 계정으로 로그인해야 Method를 변경할 수 있으며, 만약 다른 계정으로 로그인 한다면 참고만 가능할 수 있다.

다음으로, 데이터 액세스(Data Access) 레이어 모델링 및 테스트 단계를 설명한다. Data Access 레이어는 Database 서버에 접속하여 작업을 수행하는 Component와 Method들의 집합이다. Data Access 레이어의 Method는 Business Rule 레이어의 Method들에 의하여 호출 되거나 직접 외부에 노출될 수 있다.

먼저, Data Access 레이어의 Component는 하나의 table / view를 사용하는지 여부에 따라 One table / view management Component(표 1 참조), Ad-hoc / Stored Procedure Component(표 2 참조)의 두 가지로 구분할 수 있다.

표 1과 같이 One table / view management Component는 생성시 사용할 table / view를 미리 지정 받게 된다. 따라서 이 Component에 속하는 대부분의 Method들은 Component에서 지정한 table / view 로만 작업하는 단순한 SQL 문을 포함한다. 그리고 SQL 문들의 패턴이 거의 동일하기 때문에, 모델러는 응용서버 개발시스템의 Manager가 제공하는 안내에 따라 마우스 클릭만으로 쉽고 빠르게 SQL 문을 작성할 수 있다.

표 2와 같이 Ad-hoc / Stored Procedure Component는 생성 시 사용할 table / view를 미리 지정 받지않는다. 따라서 이 Component에 속하는 Method들은 Database의 여러 개체를 사용하는 복잡한 SQL 문을 포함한다. 그리고 SQL 문들의 패턴이 정해져 있지 않기 때문에, 모델러는 직접 모든 SQL문을 작성해야 한다.

다음으로, 데이터 액세스 메소드(Data Access Method)를 설명한다. Data Access Method는 실제 Database에서 모델러가 지정한 작업을 수행한다.

Data Access Method는 Business Rule Method에 의해 호출 될 수도 있고, 직접 노출되어 외부에 서비스될 수도 있다. Data Access Method는 One table / view management Component에 속하는 Data Access Method(Wizard 방식, Script 방식)(표 3 참조), Ad-hoc / Stored Procedure Component에 속하는 Data Access Method(Normal SQL 문과 Optional Condition SQL을 포함하는 Ad-hoc SQL 문, Stored Procedure 호출)(표 4 참조) 등 여러 종류가 있다.

One table / view management Component에 속하는 Data Access Method는 표 3과 같다.

Ad-hoc / Stored Procedure Component에 속하는 Data Access Method는 표 4와 같다.

다음으로, Data Access Method의 모델링이 끝나면 테스트를 수행한다. 테스트가 성공적으로 수행되어야만 다른 모델러들과 공유할 수 있게 된다. 테스트는 트리 Context Menu의 ".Test." 메뉴 혹은 Data Access Method 창의 ".Test." 버튼으로 가능할수 있다.

다음으로, Activate 단계를 설명한다. Activate은 모델링과 테스트가 끝난 Data Access Method를 다른 모델러들이 호출하여 사용할 수 있도록 하는 명령이다. 즉, Activate은 모델러가 어떤 Method에 대하여 모델링과 테스트가 끝냈음을 선언하는 명령으로 생각 할 수 있다. Activate가 성공적으로 수행된 Data Access Method는 모든 모델러들이 호출하여 사용할 수 있으며, Activate가 성공적으로 수행되면 해당 Method의 아이콘이 "A"로 변경될 수 있다.

다음으로, Business Rule 레이어 모델링 및 테스트 단계를 설명한다.

Business Rule 레이어는 모델러가 모델링한 Business Logic을 수행하는 Component와 Method들의 집합이다. Business Rule 레이어의 Method는 다른 Business Rule 레이어의 Method들에 의하여 호출될 수도 있고, 직접 외부에 노출될 수도 있다. 또한 내부적으로 Data Access Method를 호출할 수 있다.

우선, Business Rule Component를 설명한다.

Business Rule Component는 Data Access Component와는 달리 종류도 없으며, 생성에 필요한 정보도 단순할 수 있다. 보통 업무 종류로 구분하여 나눌수 있으며, 예를 들어, 실시예에서 eLibrary는 Business Rule Component를 표 5와 같이 같이 구성할 수 있으나 이에 한정되는 것은 아니다.

다음으로, Business Rule Method를 설명한다. Business Rule Method는 모델러가 모델링한 Business Logic을 수행할 수 있다.

실시예에서 eLibrary의 Business Rule Method 구성은 표 6과 같을 수 있으나 이에 한정되는 것은 아니다.

이하 도 4a 내지 도 4n은 실시예에 따른 응용서버 개발시스템을 이용하여 Business Rule Method를 모델링하는 예이나 이에 한정되는 것은 아니다.

우선, 도 4a와 같이 ID와 Input/Output 파라미터를 정의한다.

다음으로, 도 4b와 같이 내부에서 필요한 변수들을 정의할 수 있다.

다음으로, 도 4c와 같이 이미 만들어진 메서드를 호출하기 위한 스텝을 추가할 수 있다.

다음으로, 도 4d와 같이 호출하고자 하는 메서드를 선택한다.

다음으로, 도 4e와 같이 호출하고자 하는 메서드의 Input/Output 데이터를 할당한다.

다음으로, 도 4f와 같이 확인을 누르면 아래와 같이 호출 스텝이 추가될 수 있다.

다음으로, 도 4g와 같이 위의 절차와 동일하게 다른 메서드 호출 스텝을 더 추가한 후 Loop 스텝을 추가할 수 있다.

다음으로, 도 4h와 같이 반복 조건과 인덱스 초기값 및 증가값을 정의할 수 있다.

다음으로, 도 4i와 같이 확인을 누르면 아래와 같이 Loop 스텝이 추가될 수 있다.

다음으로, 도 4j와 같이 값을 변경하거나 할당하기 위해 Substitution 스텝을 추가할 수 있다.

다음으로, 도 4k와 같이 대상 변수 셀을 선택할 수 있다.

다음으로, 도 4ㅣ과 같이 다른 변수나 계산된 값을 할당할 수 있다.

다음으로, 도 4m과 같이 확인을 누르면 아래와 같이 Substitution 스텝이 추가될 수 있다.

다음으로, 도 4n은 호출 스텝을 더 추가하여 완성된 모습니다.

이하 Business Rule Method에 대한 테스트 단계를 설명한다.

도 5a 내지 도 5c는 실시예에 따른 응용서버 개발시스템을 이용하여 Business Rule Method를 테스트하는 예시도이다.

Business Rule Method의 모델링이 끝나면 테스트를 수행해야 한다. 테스트가 성공적으로 수행되어야만 다른 모델러들과 공유할 수 있게 된다. 도 5a와 같이 테스트는 트리 Context Menu의 "Test" 메뉴 혹은 Business Rule Method 창의 "Test" 버튼으로 가능하다.

Business Rule Method를 테스트 할 때는 한 스텝씩 테스트를 수행 할 수 있다. 도 5b와 같이 테스트 창의 "Request by step" 버튼을 이용하면 Flow 다이어그램이 나타나며 "Start", "Go next step", "Stop" 버튼을 이용해 한 스텝씩 진행 혹은 중지 할 수 있다. 한 스텝을 수행하고 난 후 그 결과는 도 5c와 같이 Output 탭을 이용해 확인 할 수 있다.

다음으로, Business Rule Method의 Activate 단계를 설명한다.

Business Rule Method 역시 Data Access Method와 마찬가지로 Activate 되어야 모델러와 공유가 가능하며 외부에 서비스를 시작할 수가 있다. Activate에 의해 상태가 "C"에서 "A"로 바뀌게 된다.

다음으로, Method 노출단계를 설명한다.

도 6a 내지 도 6b는 실시예에 따른 응용서버 개발시스템에서 Method 노출 예시도이다.

Business Rule Method, Data Access Method, Service Access Method는 모두 외부에 노출될 수 있다. 즉, 외부에서 요청을 받으면 서비스를 해 줄 수가 있다. Method를 외부에 노출하기 위해서는 Activate 되어 있어야 하며, 도 6a와 같이 "Start Service" 명령을 내려 주어야 한다.

외부에 노출하기 위한 Method를 선택하고 "Start Service" 명령을 내리면 Method의 아이콘은 "A"에서 "S"로 변하고 해당 Method는 "Business Service" 노드 아래에 추가된다.

실시예에서 현재 외부에 노출되어 있는 모든 Method는 트리의 "Business Service" 노드 아래에 존재하게 된다. 실시예의 eLibrary에서는 도 6b와 같은 Method가 외부로 노출되어 서비스 될 수 있다.

다음으로, 변경관리 단계를 설명한다.

먼저, 의존성 확인 단계를 설명한다.

Activate 된 Method 들은 다른 Business Rule Method에 의해서 호출 될 수 있다. 이런 Method들 간의 호출 관계는 각 Method 창의 Dependency 탭에서 확인 할 수 있다. Caller는 자신을 호출하는 Method 목록이며, Callee는 자신이 호출하는 Method 목록일 수 있다.

다음으로, Activate된 Method 변경에 대해 설명한다.

도 7a 내지 도 7c는 실시예에 따른 응용서버 개발시스템에서 Activated Method 변경 예시도이다.

Activate 된 Method는 다른 모델러가 작성한 Method들에 의해서 호출되고 있으므로 변경할 경우 다른 Method에도 영향을 줄 수 있다. 따라서 변경에 신중을 기해야 한다. Activate 된 Method를 변경하고 "Apply" 버튼을 클릭하게 되면 "Modifying" 상태로 변경되며 수정 및 테스트가 다 끝나면 "Reactivate" 명령을 통해 실제 Method에 반영하게 된다. "Reactivate" 되기 전에는 수정 전의 Method가 계속 동작한다.

변경에는 다음 두 가지 경우가 있으며, 다른 Method들에게 미치는 영향에 차이가 있다. 내부 로직만 변경하는 경우는 수정된 Method를 호출하는 Method 변경 불필요하다. 반면, In/Out Parameter를 변경하는 경우에는 수정된 Method를 호출하는 Method 변경 필요하다.

먼저, 내부 로직 변경에 대해 설명한다.

Data Access Method이던 Business Rule Method 이던 In/Out Parameter 변경 없이 내부에만 변경이 발생한다면, 변경된 Method를 호출하는 다른 Method들은 직접적으로 변경될 필요가 없다. 즉, 변경하고자 하는 Method만 수정 후 "Reactivate" 하면 된다.

다음으로, In/Out Parameter 변경을 설명한다.

In/Out Parameter가 변경된 경우에는 변경된 Method를 호출하고 있는 모든 Method들이 변경 되어야 한다. 즉, 호출할 때 맵핑했던 In/Out Parameter를 모두 재확인 해야 한다.

도 7a는 실시예에서 변경 영향 확인에 관한 예시도이다.

만약 어떤 Method의 In/Out Parameter가 변경되면 영향을 받는 모든 Method들에는 "?"가 표시되게 된다. 도 7a는 eLibrary의 "도서입고" Method에서 호출하던 "도서마스터번호생성" Method의 In/Out Parameter가 변경되어 "도서입고" Method가 변경될 필요가 있음을 알리는 "?" 마크가 표시된 화면이다. 모델러는 "?" 마크가 있는 Method를 Open 한 후 필요한 부분을 수정하고 다시 "Reactivate" 할 수 있다.

도 7b는 Parameter가 추가된 경우 변경 순서에 관한 예시도이다.

Parameter가 추가된 경우 서비스의 중단 없이 변경 내용을 반영하기 위해서는 호출 체인에 있는 모든 Method들을 수정하고, 가장 상위에 있는 Method부터 차례로 Reactivate할 수 있다. 만약 도 7b와 같이 호출 관계를 가지고 있고, Method D의 Parameter가 추가될 필요가 있다면, Method A, Method B/Method C, Method D 순서로 수정 후 Reactivate을 수행할 수 있다.

다음으로, 도 7c는 실시예에서 Parameter가 삭제된 경우 변경 순서의 예시도이다.

Parameter가 삭제된 경우 서비스의 중단 없이 변경 내용을 반영하기 위해서는 호출 체인 에 있는 모든 Method들을 수정하고, 가장 하위에 있는 Method부터 차례로 Reactivate 할 수 있다. 만약 도 7c와 같이 호출관계를 가지고 있고, Method D의 Parameter가 삭제될 필요 가 있다면, Method D, Method B/Method C, Method A 순서로 수정 후 Reactivate을 수행할 수 있다.

실시예는 다음과 같은 추가적인 특징이 있다.

우선, 실시예는 자바(Java) 버전과 닷넷(.NET) 버전으로 구현이 가능하며 이에 한정되는 것은 아니다. 실시예는 Java 환경 지원(JDK 1.4 이상/WAS(WebLogic/WebSphere/JEUS))이 가능하다. 즉, 실시예에 대한 기술영역이 확대되어, .NET 환경(.NET 2.0 이상/COM+)은 물론 Java 환경지원(JDK 1.4 이상/WAS(WebLogic/WebSphere/JEUS))이 가능하며, 기타 WAS 도 커스터마이징을 통해 가능하다.

둘째, 실시예는 형상관리 기능에 의해 Repository 내에 저장되어 있는 서비스 정의에 대한 이력관리 및 롤백 기능을 제공할 수 있다.

즉, 실시예는 변경도구와 통합된 형상관리 기능에 의해 기존의 Check In/Out 기반 다운로드/업로드 방식의 형상관리 방식과는 달리 다운로드/업로드 등의 행위 없이 모델링 UI를 통해 서버 상의 Repository 내에 저장되어 있는 서비스 정의의 변경 및 이를 통한 변경 이력관리 및 이전 버전 중 선택하여 롤백 할 수 있다.

셋째, 실시예는 모델 원격 Merge 기능에 의해 원격에 있는 BizActor 간 Repository 내 서비스 정의 내용의 선택적 이동 기능을 제공할 수 있다.

즉, 실시예는 모델 원격 Merge 기능에 의해 기존의 배포방식과는 다르게 실시간으로 원격에 있는 BizActor 간 Repository 내 서비스 정의 내용의 선택적 이동 기능 및 실시간 실행 상태를 동기화 할 수 있다.

넷째, 실시예는 실행 성능 분석 기능에 의해 정의한 서비스의 세부 단계별 실행 성능 로깅 및 리포팅 기능을 제공할 수 있다.

즉, 실시예는 실행엔진 자체가 제공하는 실행 성능 분석 기능에 의해 기존의 컴포너트 등의 실행프로그램 외부에서 모니터링 하는 방식과는 다르게 엔진 자체가 실행 및 로깅을 하기 때문에 정의한 서비스의 세부 단계별 상세한 실행 성능 로깅 및 리포팅 기능을 제공할 수 있다.

다섯째, 실시예는 변경 영향도 분석 기능에 의해 모든 서비스간 호출체계 및 SQL(Structured Query Language) 리포팅 기능을 제공할 수 있다.

즉, 실시예는 통합관리를 통한 실시간 변경영향 분석기능에 의해 서비스간 종속관계 및 파라미터를 관리하여, 파라미터를 변경하면 영향 받을 서비스를 즉시 알려주며, 변경 시에는 영향 받은 서비스와 세부 단계별 위치까지도 표시를 통해 변경을 보완할 수 있도록 가이드하고, 또한 모든 서비스간 호출체계 및 SQL(Structured Query Language) 리포팅 기능을 제공할 수 있다.

본 발명은 기재된 실시예 및 도면에 의해 한정되는 것이 아니고, 청구항의 권리범위에 속하는 범위 안에서 다양한 다른 실시예가 가능하다.

도 1은 실시예에 따른 실시예에 따른 응용서버 개발시스템의 구성도.

도 2는 실시예에 따른 응용서버 개발시스템의 활용 예시도.

도 3은 실시예에 따른 응용서버 개발시스템에서의 모델링 계획 중 시퀀스 다이어그램의 예시도.

도 4a 내지 도 4n은 실시예에 따른 응용서버 개발시스템을 이용하여 Business Rule Method를 모델링하는 예시도.

도 5a 내지 도 5c는 실시예에 따른 응용서버 개발시스템을 이용하여 Business Rule Method를 테스트하는 예시도.

도 6a 내지 도 6b는 실시예에 따른 응용서버 개발시스템에서 Method 노출 예시도.

도 7a 내지 도 7c는 실시예에 따른 응용서버 개발시스템에서 Activated Method 변경 예시도.

Claims

응용서버 개발에 있어서, 다이아그램을 이용한 리파지토리(Repository) 기반의 응용서버 개발시스템.
제1 항에 있어서,

상기 응용서버 개발시스템은,

비즈니스 로직을 모델링하는 모델링UI와 상기 모델링된 비즈니스 로직을 테스트하고 실행하는 서버를 포함하는 응용서버 개발시스템.
제2 항에 있어서,

상기 모델링 UI는

서버 환경 정의를 위한 관리화면과 상기 비즈니스 로직 모델링을 위해 복수의 레이어를 포함하며,

상기 각 레이어 별 모델링 기능을 제공하고 상기 서버와 통신을 통해 비즈니스 로직을 생성, 변경, 테스트 기능을 수행하는 응용서버 개발시스템.
제2 항에 있어서,

상기 서버는

상기 모델링UI에서 받는 정보를 상기 리파지포토리에 저장관리하는 모델링엔 진; 및

상기 비즈니스 로직에 대한 테스트와 실행을 하는 실행엔진;을 포함하는 응용서버 개발시스템.
제4 항에 있어서,

상기 모델링엔진은 서버환경 관리자와 복수의 레이어(Layer) 별 모델 관리자를 포함하며, 실시간 반영 및 테스트를 위해 상기 실행엔진에 요청하는 기능을 수행하는 응용서버 개발시스템.
제4 항에 있어서,

상기 실행엔진은

복수의 레이어(Layer)별 실행자를 포함하며, 각 레이어(Layer) 별 리파지토리 정보를 로딩하여 비즈니스 로직에 대한 테스트와 실행, DB 질의 및 Legacy 연동을 수행하는 응용서버 개발시스템.
제4 항에 있어서,

상기 실행엔진은 테스트용 실행엔진과 서비스용 실행엔진을 포함하는 응용서버 개발시스템.
제7 항에 있어서,

상기 테스트용 실행엔진은 테스트 DB를 사용하여 상기 모델링UI 에서 실시간 검증 시 사용되며,

상기 서비스용 실행엔진은 운영 DB를 사용하여 업무용UI, Legacy시스템에서 요청 시 서비스를 제공하는 역할을 하는 응용서버 개발시스템.
제1 항에 있어서,

상기 리파지토리는 다이아그램으로 그려진 비즈니스 로직을 통합 저장하는 비즈니스 모델 저장소 역할을 하는 응용서버 개발시스템.
제4 항에 있어서,

상기 리파지토리는 상기 다이아그램으로 표현된 비즈니스 로직을 저장하고,

상기 비즈니스 로직은 상기 실행엔진이 실행할 수 있는 비즈니스 실행모델인 것을 특징으로 하는 응용서버 개발시스템.
제1 항에 있어서,

상기 응용서버 개발시스템은

닷넷(.NET) 버전 또는 자바(Java) 버전으로 구현이 가능한 것을 특징으로 하는 응용서버 개발시스템.
제1 항에 있어서,

상기 응용서버 개발시스템은

형상관리 기능에 의해 상기 리파지토리 내에 저장되어 있는 서비스 정의의 이력관리 및 롤백 기능을 제공하는 것을 특징으로 하는 응용서버 개발시스템.
제1 항에 있어서,

상기 응용서버 개발시스템은

모델 원격 머지(Merge) 기능에 의해, 복수의 응용서버 개발시스템간에 각각의 리파지토리 내의 비즈니스 로직 내용의 선택적 이동기능을 제공하는 것을 특징으로 하는 응용서버 개발시스템.
제1 항에 있어서,

상기 응용서버 개발시스템은

실행성능 분석기능에 의해 정의한 비즈니스 로직 서비스의 세부 단계별 실행 성능 로깅 및 리포팅 기능을 제공하는 것을 특징으로 하는 응용서버 개발시스템.
제1 항에 있어서,

상기 응용서버 개발시스템은

변경영향도 분석 기능에 의해, 비즈니스 로직 서비스간 호출체계 및 SQL(Structured Query Language) 리포팅 기능을 제공하는 것을 특징으로 하는 응용서버 개발시스템.