KR102659150B1 - 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체 - Google Patents
애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체 Download PDFInfo
- Publication number
- KR102659150B1 KR102659150B1 KR1020230101952A KR20230101952A KR102659150B1 KR 102659150 B1 KR102659150 B1 KR 102659150B1 KR 1020230101952 A KR1020230101952 A KR 1020230101952A KR 20230101952 A KR20230101952 A KR 20230101952A KR 102659150 B1 KR102659150 B1 KR 102659150B1
- Authority
- KR
- South Korea
- Prior art keywords
- data
- package
- information
- client
- adapter
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 82
- 238000011161 development Methods 0.000 claims abstract description 99
- 230000006870 function Effects 0.000 claims description 120
- 238000013507 mapping Methods 0.000 claims description 114
- 238000006243 chemical reaction Methods 0.000 claims description 22
- 230000008569 process Effects 0.000 claims description 19
- 239000003795 chemical substances by application Substances 0.000 description 275
- 238000010586 diagram Methods 0.000 description 92
- 230000010354 integration Effects 0.000 description 64
- 230000005540 biological transmission Effects 0.000 description 54
- 238000012545 processing Methods 0.000 description 36
- 238000013515 script Methods 0.000 description 32
- 238000000547 structure data Methods 0.000 description 30
- 238000007726 management method Methods 0.000 description 26
- 230000008859 change Effects 0.000 description 20
- 230000014509 gene expression Effects 0.000 description 19
- 238000004891 communication Methods 0.000 description 13
- 238000004422 calculation algorithm Methods 0.000 description 10
- 238000012360 testing method Methods 0.000 description 9
- 238000012544 monitoring process Methods 0.000 description 8
- 238000012546 transfer Methods 0.000 description 7
- 235000010627 Phaseolus vulgaris Nutrition 0.000 description 6
- 244000046052 Phaseolus vulgaris Species 0.000 description 6
- 239000003607 modifier Substances 0.000 description 6
- 230000000007 visual effect Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 4
- 238000009434 installation Methods 0.000 description 4
- 238000012795 verification Methods 0.000 description 4
- RWSOTUBLDIXVET-UHFFFAOYSA-N Dihydrogen sulfide Chemical compound S RWSOTUBLDIXVET-UHFFFAOYSA-N 0.000 description 3
- 238000013497 data interchange Methods 0.000 description 3
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000001276 controlling effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003213 activating effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/34—Graphical or visual programming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/36—Software reuse
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/38—Creation or generation of source code for implementing user interfaces
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Human Computer Interaction (AREA)
- Information Transfer Between Computers (AREA)
Abstract
개시하는 일 실시 예는 개발 도구 팔레트 및 GUI 블록 영역을 포함하는 사용자 인터페이스를 제공하는 단계; 사용자로부터 상기 개발 도구 팔레트에 포함된 제 1 그래픽 블록을 선택하는 신호를 수신함에 따라, 상기 제 1 그래픽 블록에 대응하는 제 1 함수 블록을 생성하는 단계; 및 상기 생성된 제 1 함수 블록을 상기 GUI 블록 영역에 출력하는 단계를 포함하는, 애플리케이션 서비스 제공 방법을 제공한다.
Description
이하의 개시는 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체에 관한 것이다.
기업과 기업, 또는 기업과 개인간의 거래에 따라 거래와 관련된 정보 교환 또는 그 정보를 포함한 서류의 교환이 이루어지고 있다.
그러나 서류의 교환, 서류에 포함되어야 하는 정보의 형식 또는 규격은 기업에 따라 달라질 수 있고 여러 가지 거래 형태에 따라 서류의 포맷, 내부의 요청 내용, 또는 기재 방식들이 각각 다르기 때문에 여러 가지 소프트웨어들이 개발되어 왔다.
이러한 소프트웨어는 전자 문서 교환 등 여러 기업들 간의 정형화된 양식으로 거래에 필요한 정보를 기입하고 교환할 수 있도록 도움을 줄 수 있다. 이러한 전자 문서 교환 방식이 일반화됨에 따라 표준화된 방식이 규정되어 표준화된 전자문서로 변화시켜 거래 당사자의 컴퓨터로 교환, 축적, 처리하면 시간과 노력을 단축할 수 있다.
그러나 이러한 표준화된 전자문서를 생성하는 소프트웨어도 종종 거래의 당사자, 거래의 양태, 거래의 형식과 내용에 따라 개별적으로 변경해야 하는 불편함이 있었다.
시장의 신규 업체의 경우 기존 거래 당사자가 요구하는 표준화된 양식과 형식으로 준비하기 어려운 경우가 있다. 시장의 복잡한 거래 양태들과 요구사항들이 많기 때문에 이러한 표준화된 거래 형식을 이해하거나 따르기 힘든 경우가 있는 등의 문제로 거래를 활성화하기 힘든 경우가 있다.
또한 거래 당사자들이 서로 호환되지 않는 소프트웨어를 사용하거나, 서로 호환되지 않는 시스템에서 별도의 소프트웨어를 구비하는 경우 거래를 위해 소프트웨어를 개발해야 하거나, 시스템에 맞는 소프트웨어를 구비하는 등의 기술적인 불편함이 있었다.
그리고 동일한 소프트웨어 이미지로 애플리케이션 서비스를 제공하더라도 각각의 클라이언트들에 대해 모든 버전과 종류들의 소프트웨어 패키지들이 준비되고 제공되어야 하는 등 효율적인 서비스를 제공하기 힘든 어려움이 있었다.
특히, 거래 당사자들은 각자가 사용하는 EDI 정보를 서로 매핑할 수 있는 매핑 프로그램이 필요함에도 불구하고, 전문적인 지식을 가진 사람이 아닌 경우, 그 개발이 어려운 문제가 있었다.
개시하는 실시 예는, 위와 같은 불편한 문제점들을 해결하기 위한 것으로서, 매핑 프로그램 정의 도구를 지원하기 위한 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체를 제공할 수 있다.
개시하는 일 실시 예는, 개발 도구 팔레트 및 GUI 블록 영역을 포함하는 사용자 인터페이스를 제공하는 단계; 사용자로부터 상기 개발 도구 팔레트에 포함된 제 1 그래픽 블록을 선택하는 신호를 수신함에 따라, 상기 제 1 그래픽 블록에 대응하는 제 1 함수 블록을 생성하는 단계; 및 상기 생성된 제 1 함수 블록을 상기 GUI 블록 영역에 출력하는 단계를 포함하는, 애플리케이션 서비스 제공 방법을 제공한다.
상기 애플리케이션 서비스 제공 방법은 상기 GUI 블록 영역에 포함된 함수 블록에 대응하는 소스 코드를 소스 코드 영역에 출력하는 단계를 포함하는 것을 특징으로 한다.
상기 애플리케이션 서비스 제공 방법은 상기 사용자로부터 상기 소스 코드를 수정하는 신호를 수신하는 경우, 실시간으로 상기 GUI 블록 영역에 출력 중인 함수 블록을 수정하되, 상기 함수 블록은 상기 소스 코드에 기초하여 수정되는 것을 특징으로 한다.
개시하는 일 실시 예는 데이터를 저장하는 데이터베이스; 및 상기 데이터를 처리하는 프로세서를 포함하고, 상기 프로세서는, 개발 도구 팔레트 및 GUI 블록 영역을 포함하는 사용자 인터페이스를 제공하고, 사용자로부터 상기 개발 도구 팔레트에 포함된 제 1 그래픽 블록을 선택하는 신호를 수신함에 따라, 상기 제 1 그래픽 블록에 대응하는 제 1 함수 블록을 생성하고, 상기 생성된 제 1 함수 블록을 상기 GUI 블록 영역에 출력하는, 애플리케이션 서비스 제공 장치를 제공한다.
상기 프로세서는, 상기 GUI 블록 영역에 포함된 함수 블록에 대응하는 소스 코드를 소스 코드 영역에 출력하는 것을 특징으로 한다.
상기 프로세서는, 상기 사용자로부터 상기 소스 코드를 수정하는 신호를 수신하는 경우, 실시간으로 상기 GUI 블록 영역에 출력 중인 함수 블록을 수정하되, 상기 함수 블록은 상기 소스 코드에 기초하여 수정되는 것을 특징으로 한다.
개시하는 일 실시 예는 개발 도구 팔레트 및 GUI 블록 영역을 포함하는 사용자 인터페이스를 제공하는 단계; 사용자로부터 상기 개발 도구 팔레트에 포함된 제 1 그래픽 블록을 선택하는 신호를 수신함에 따라, 상기 제 1 그래픽 블록에 대응하는 제 1 함수 블록을 생성하는 단계; 및 상기 생성된 제 1 함수 블록을 상기 GUI 블록 영역에 출력하는 단계를 수행하는, 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체를 제공한다.
개시하는 실시 예에 따르면 거래를 위해 기술적인 불편함을 해결하고 거래를 더욱 활성화시킬 수 있다.
개시하는 실시 예에 따르면 기존 거래의 표준화된 양식이 준비되지 못했거나, 복잡한 거래 요구사항이 있더라도 소프트웨어를 이용하여 기술적으로 시장 거래를 활성화시킬 수 있다.
개시하는 실시 예에 따르면 거래 당사자들이 서로 호환되지 않는 소프트웨어를 사용하거나, 서로 호환되지 않는 시스템에서 별도의 소프트웨어를 구비하는 경우라도 편리한 거래 시스템을 구비할 수 있다.
개시하는 실시 예에 따르면, 사용자가 개발 스크립트에 친숙하지 않아도 비교적 간편하게 매핑 프로그램을 정의할 수 있다는 장점이 있다.
개시하는 실시 예에 따르면, 개발자들은 사용자 친화적인 인터페이스와 시각적 프로그래밍 방식을 통해 복잡한 매핑 로직을 쉽게 구현하고 관리할 수 있다.
개시하는 실시 예에 따르면, 사용자는 실제 사용되는 언어나 컨텍스트에 따라 다른 구현 방식과 문법으로 함수를 생성할 수 있다.
도 1은 실시 예에 따른 애플리케이션 서비스 제공 방법의 일 예를 개시하는 흐름도
도 2는 개시한 실시 예 중 워크스페이스를 통해 클라이언트에 애플리케이션 서비스를 제공하는 예를 개시한 도면
도 3은 개시한 애플리케이션 서비스 장치의 예에서 패키지들을 각 노드로 배포하는 예를 개시한 도면
도 4는 실시 예에 따른 애플리케이션 서비스 제공에 대한 레이어 별 요소들을 개시한 개념도
도 5는 실시 예에 따른 애플리케이션 서비스 제공 장치가 인스턴스와 클라이언트 또는 파트너 사이의 채널을 설정하는 개념을 개시한 도면
도 6은 실시 예에 따른 애플리케이션 서비스 제공 장치가 인스턴스와 클라이언트 또는 파트너 사이의 채널을 설정하는 구체적인 예를 개시한 도면
도 7은 실시 예에 따라 분산 채널을 설정하고 서비스를 제공받는 예를 개시한 도면
도 8은 실시 예에 따라 설치되는 패키지의 설정 정보를 관리하는 예를 개시한 도면
도 9는 개시하는 실시 예의 워크스페이스에 따라 패키지를 관리하고 이용하는 예를 개시한 도면
도 10은 실시 예에 따라 애플리케이션 서비스의 일종으로서 EDI 정보를 매핑하는 예를 개시한 도면
도 11은 실시 예에 따라 통합 패키지를 이용하여 애플리케이션 서비스를 제공하는 예를 개시한 도면
도 12는 개시한 애플리케이션 서비스 제공하는 예에 따른 플랫폼의 인터페이스의 일 예를 도시한 도면
도 13은 개시한 애플리케이션 서비스 제공하는 예에 따른 플랫폼의 인터페이스의 다른 일 예를 도시한 도면
도 14는 실시 예에 따른 애플리케이션 서비스 제공 장치가 서로 다른 시스템을 통합할 수 있는 프레임워크를 제공하는 예를 개시한 도면
도 15는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 커넥터를 그래픽 기반으로 코딩하는 예를 나타낸 도면
도 16는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 서비스를 그래픽 기반으로 코딩하는 예를 나타낸 도면
도 17는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 프로세서를 그래픽 기반으로 코딩하는 예를 나타낸 도면
도 18는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 컨트롤 플로우(Control flow)를 그래픽 기반으로 코딩하는 예를 나타낸 도면
도 19는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 모디파이어(modifier)를 그래픽 기반으로 코딩하는 예를 나타낸 도면
도 20은 실시 예에 따라 클라이언트에 따라 격리된 고유의 워크스페이스를 제공하는 일 예를 개시한 도면
도 21은 실시 예에 따라 격리된 워크스페이스로부터 클라이언트에 패키지를 제공하는 일 예를 개시한 흐름도
도 22은 실시 예에 따른 인스턴스 시스템의 플랫폼에서 제공하는 에이전트가 실행된 경우 에이전트의 인터페이스를 예시한 도면
도 23는 실시 예에 따른 인스턴스 시스템의 플랫폼에서 제공하는 에이전트 어댑터의 인터페이스의 일 예를 예시한 도면
도 24는 실시 예에 따른 인스턴스 시스템의 플랫폼에서 제공하는 에이전트 어댑터의 인터페이스의 다른 일 예를 예시한 도면
도 25는 실시 예에 따른 인스턴스 시스템의 플랫폼의 에이전트 어댑터가 송수신 채널을 설정하는 예를 나타낸 도면
도 26은 실시 예에 따른 인스턴스 시스템의 플랫폼을 이용해 거래 정보인 EDI 데이터를 송신하는 예를 개시한 도면
도 27은 실시 예에 따른 인스턴스 시스템의 플랫폼이 클라이언트 시스템에 데이터를 제공하는 예를 개시한 도면
도 28은 실시 예에 따른 인스턴스 시스템의 플랫폼이 파트너 시스템으로부터 데이터를 수신받는 예를 개시한 도면
도 29는 실시 예에 따른 워크스페이스에서 어댑터를 실행하는 실시 예를 개시한 도면
도 30은 어댑터 패키지의 일 예를 개시한 도면
도 31은 실시 예에 따른 워크스페이스에서 어댑터를 실행하는 일 예를 개시한 도면
도 32는 실시 예에 따른 어댑터가 프레임워크를 사용하는 일 예를 개시한 도면
도 33은 실시 예에 따른 어댑터 패키지가 제공하는 서비스의 일 예를 개시하는 도면
도 34는 실시 예에 따른 워크스페이스에서 개발된 어댑터의 일 예를 개시한 도면
도 35는 실시 예에 따른 어댑터 패키지를 개발하는 프레임워크를 제공하는 일 예를 개시한 도면
도 36은 실시 예에 따른 애플리케이션 서비스 제공 장치가 앱스토어 플랫폼에서 애플리케이션 패키지를 제공하는 예를 개시하는 도면
도 37은 실시 예에 따른 애플리케이션 서비스 제공 방법의 다른 일 실시 예를 개시하는 흐름도
도 38은 실시 예에 따른 애플리케이션 서비스 제공 방법의 다른 일 실시 예를 개시하는 흐름도
도 39는 실시 예에 따른 애플리케이션 서비스 제공 장치가 애플리케이션 패키지에 대한 서비스를 제공하는 예를 개시하는 도면
도 40은 실시 예에 따른 애플리케이션 서비스 제공 장치가 애플리케이션 패키지에 대한 서비스를 제공하는 다른 예를 개시하는 도면
도 41은 실시 예에 따른 애플리케이션 서비스 제공 방법의 예를 개시하는 흐름도
도 42는 실시 예에 따른 애플리케이션 서비스 제공 방법이 서비스를 제공하는 예를 개시하는 흐름도
도 43은 실시 예에 따른 애플리케이션 서비스 제공 장치가 데이터 형식을 변환하는 예를 개시하는 도면
도 44는 실시 예에 따른 애플리케이션 서비스 제공 장치가 스키마 및 매핑 스크립트를 사용하여 데이터 형식을 변환하는 예를 개시하는 도면
도 45는 실시 예에 따른 스키마에 기반한 역직렬화와 직렬화의 예를 개시하는 도면
도 46은 실시 예에 따른 매핑 스크립트의 예를 개시하는 도면
도 47은 실시 예에 따른 애플리케이션 서비스 제공 방법이 데이터 형식을 변환하는 예를 개시하는 흐름도
도 48은 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면
도 49는 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면
도 50은 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면
도 51은 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면
도 52는 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면
도 53은 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면
도 54는 개시한 실시 예 중 애플리케이션 서비스 제공 방법의 일 예를 개시한 도면
도 2는 개시한 실시 예 중 워크스페이스를 통해 클라이언트에 애플리케이션 서비스를 제공하는 예를 개시한 도면
도 3은 개시한 애플리케이션 서비스 장치의 예에서 패키지들을 각 노드로 배포하는 예를 개시한 도면
도 4는 실시 예에 따른 애플리케이션 서비스 제공에 대한 레이어 별 요소들을 개시한 개념도
도 5는 실시 예에 따른 애플리케이션 서비스 제공 장치가 인스턴스와 클라이언트 또는 파트너 사이의 채널을 설정하는 개념을 개시한 도면
도 6은 실시 예에 따른 애플리케이션 서비스 제공 장치가 인스턴스와 클라이언트 또는 파트너 사이의 채널을 설정하는 구체적인 예를 개시한 도면
도 7은 실시 예에 따라 분산 채널을 설정하고 서비스를 제공받는 예를 개시한 도면
도 8은 실시 예에 따라 설치되는 패키지의 설정 정보를 관리하는 예를 개시한 도면
도 9는 개시하는 실시 예의 워크스페이스에 따라 패키지를 관리하고 이용하는 예를 개시한 도면
도 10은 실시 예에 따라 애플리케이션 서비스의 일종으로서 EDI 정보를 매핑하는 예를 개시한 도면
도 11은 실시 예에 따라 통합 패키지를 이용하여 애플리케이션 서비스를 제공하는 예를 개시한 도면
도 12는 개시한 애플리케이션 서비스 제공하는 예에 따른 플랫폼의 인터페이스의 일 예를 도시한 도면
도 13은 개시한 애플리케이션 서비스 제공하는 예에 따른 플랫폼의 인터페이스의 다른 일 예를 도시한 도면
도 14는 실시 예에 따른 애플리케이션 서비스 제공 장치가 서로 다른 시스템을 통합할 수 있는 프레임워크를 제공하는 예를 개시한 도면
도 15는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 커넥터를 그래픽 기반으로 코딩하는 예를 나타낸 도면
도 16는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 서비스를 그래픽 기반으로 코딩하는 예를 나타낸 도면
도 17는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 프로세서를 그래픽 기반으로 코딩하는 예를 나타낸 도면
도 18는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 컨트롤 플로우(Control flow)를 그래픽 기반으로 코딩하는 예를 나타낸 도면
도 19는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 모디파이어(modifier)를 그래픽 기반으로 코딩하는 예를 나타낸 도면
도 20은 실시 예에 따라 클라이언트에 따라 격리된 고유의 워크스페이스를 제공하는 일 예를 개시한 도면
도 21은 실시 예에 따라 격리된 워크스페이스로부터 클라이언트에 패키지를 제공하는 일 예를 개시한 흐름도
도 22은 실시 예에 따른 인스턴스 시스템의 플랫폼에서 제공하는 에이전트가 실행된 경우 에이전트의 인터페이스를 예시한 도면
도 23는 실시 예에 따른 인스턴스 시스템의 플랫폼에서 제공하는 에이전트 어댑터의 인터페이스의 일 예를 예시한 도면
도 24는 실시 예에 따른 인스턴스 시스템의 플랫폼에서 제공하는 에이전트 어댑터의 인터페이스의 다른 일 예를 예시한 도면
도 25는 실시 예에 따른 인스턴스 시스템의 플랫폼의 에이전트 어댑터가 송수신 채널을 설정하는 예를 나타낸 도면
도 26은 실시 예에 따른 인스턴스 시스템의 플랫폼을 이용해 거래 정보인 EDI 데이터를 송신하는 예를 개시한 도면
도 27은 실시 예에 따른 인스턴스 시스템의 플랫폼이 클라이언트 시스템에 데이터를 제공하는 예를 개시한 도면
도 28은 실시 예에 따른 인스턴스 시스템의 플랫폼이 파트너 시스템으로부터 데이터를 수신받는 예를 개시한 도면
도 29는 실시 예에 따른 워크스페이스에서 어댑터를 실행하는 실시 예를 개시한 도면
도 30은 어댑터 패키지의 일 예를 개시한 도면
도 31은 실시 예에 따른 워크스페이스에서 어댑터를 실행하는 일 예를 개시한 도면
도 32는 실시 예에 따른 어댑터가 프레임워크를 사용하는 일 예를 개시한 도면
도 33은 실시 예에 따른 어댑터 패키지가 제공하는 서비스의 일 예를 개시하는 도면
도 34는 실시 예에 따른 워크스페이스에서 개발된 어댑터의 일 예를 개시한 도면
도 35는 실시 예에 따른 어댑터 패키지를 개발하는 프레임워크를 제공하는 일 예를 개시한 도면
도 36은 실시 예에 따른 애플리케이션 서비스 제공 장치가 앱스토어 플랫폼에서 애플리케이션 패키지를 제공하는 예를 개시하는 도면
도 37은 실시 예에 따른 애플리케이션 서비스 제공 방법의 다른 일 실시 예를 개시하는 흐름도
도 38은 실시 예에 따른 애플리케이션 서비스 제공 방법의 다른 일 실시 예를 개시하는 흐름도
도 39는 실시 예에 따른 애플리케이션 서비스 제공 장치가 애플리케이션 패키지에 대한 서비스를 제공하는 예를 개시하는 도면
도 40은 실시 예에 따른 애플리케이션 서비스 제공 장치가 애플리케이션 패키지에 대한 서비스를 제공하는 다른 예를 개시하는 도면
도 41은 실시 예에 따른 애플리케이션 서비스 제공 방법의 예를 개시하는 흐름도
도 42는 실시 예에 따른 애플리케이션 서비스 제공 방법이 서비스를 제공하는 예를 개시하는 흐름도
도 43은 실시 예에 따른 애플리케이션 서비스 제공 장치가 데이터 형식을 변환하는 예를 개시하는 도면
도 44는 실시 예에 따른 애플리케이션 서비스 제공 장치가 스키마 및 매핑 스크립트를 사용하여 데이터 형식을 변환하는 예를 개시하는 도면
도 45는 실시 예에 따른 스키마에 기반한 역직렬화와 직렬화의 예를 개시하는 도면
도 46은 실시 예에 따른 매핑 스크립트의 예를 개시하는 도면
도 47은 실시 예에 따른 애플리케이션 서비스 제공 방법이 데이터 형식을 변환하는 예를 개시하는 흐름도
도 48은 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면
도 49는 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면
도 50은 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면
도 51은 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면
도 52는 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면
도 53은 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면
도 54는 개시한 실시 예 중 애플리케이션 서비스 제공 방법의 일 예를 개시한 도면
이하에서는 위와 같은 문제점을 해결하고 거래를 위해 기술적인 불편함을 해결할 수 있는 실시 예들을 개시한다.
이하에서 실시 예들의 구성요소를 언급하는 경우, 특별히 물리장치로 제한하지 않는 한 최적화된 하드웨어 또는 소프트웨어로 모두 구현이 가능하다.
도 1은 실시 예에 따른 애플리케이션 서비스 제공 방법의 일 예를 개시하는 흐름도이다.
개시하는 실시 예에 따른 애플리케이션 서비스 제공 방법은 플랫폼을 통해 여러 클라이언트들이 거래에 필요한 애플리케이션을 얻거나, 다운로드 받거나 원하는 기능을 추가 또는 변경할 수 있다.
실시 예는 가상의 격리된 워크스페이스를 이용하는 클라이언트로부터 정보를 송수신하는 채널 요청을 수신할 수 있다(S100).
클라이언트가 플랫폼에 접속하면 시스템은 클라이언트에 가상의 격리된 워크스페이스를 제공할 수 있다.
클라이언트는 별도의 서비스 제공받을 수 있는 워크스페이스를 가질 수 있으나, 각 워크스페이스를 제공하는 시스템의 하드웨어 기반은 공통될 수 있다.
시스템 관리자 또는 클라이언트는 클라이언트가 위와 같은 서비스를 제공받을 수 있도록 시스템의 원격 제어 및 업데이트를 수행할 수 있으며, 시스템은 여러 가지 표준들과 연계된 프로토콜에 따라 통신기능을 구비할 수 있다.
클라이언트는 원하는 정보를 송수신할 수 있는 채널을 플랫폼으로부터 요청할 수 있고, 플랫폼은 클라이언트에 채널을 설정하도록 허용할 수 있다.
이에 대한 상세한 예는 이하에서 개시한다.
실시 예는 클라이언트가 자신의 워크스페이스에서 애플리케이션 패키지를 생성, 변경, 또는 저장 등 변환할 수 있는 플랫폼 서비스를 제공할 수 있다(S200).
클라이언트는 실시 예와 같은 시스템에서 애플리케이션 패키지 또는 패키지의 일부를 개발하여 관련 애플리케이션 또는 소프트웨어를 거래하고 거래 관련 사업을 운영할 수도 있다.
이하에서 애플리케이션 패키지 또는 패키지라고 함은, 프로그램이나 파일의 묶음을 지칭하는 것으로서 프로토콜(protocol)이나 서비스를 지원하는 어댑터(adapter) 패키지, 프로그램 수행에 필요한 리소스 패키지, 여러 가지 패키지가 다시 통합된 통합 패키지 등을 포함한다. 이하의 예에서 경우에 따라 애플리케이션 패키지는 소프트웨어 패키지라고 호칭할 수도 있다.
시스템은 클라이언트가 원하는 여러 가지 데이터 포맷과 구조에 대한 매핑을 지원하는 여러 가지 수단 또는 전문 컴퓨터 언어를 제공할 수 있다. 또한 클라이언트가 애플리케이션 패키지를 변경할 수 있도록 애플리케이션과 관련 도구를 제공할 수 있다.
이에 대한 상세한 예는 이하에서 개시한다.
실시 예는 상기 클라이언트가 애플리케이션 패키지를 이용하거나, 다른 클라이언트가 자신의 워크스페이스에서 애플리케이션 서비스를 제공받는 경우 서비스를 스케일 아웃(scale-out)을 제어하는 서비스를 제공할 수 있다(S300). 이 단계는 서비스 제공에 관련된 스케일 제어가 필요에 따라 진행될 수 있다. 클라이언트는 제공된 시스템에 따라 애플리케이션 서비스를 중단없이 제공받거나 애플리케이션 서비스를 운영할 수 있다.
이에 대한 상세한 예는 이하에서 개시한다.
도 2는 개시한 실시 예 중 워크스페이스를 통해 클라이언트에 애플리케이션 서비스를 제공하는 예를 개시한 도면이다.
이 도면은 개시한 애플리케이션 서비스를 제공하는 실시 예 중에서 워크스페이스와 멀티테넌시(multi-tenancy)을 설명하기 위한 개념도이다.
실시 예는 사용자에게 소프트웨어로서의 서비스(Software-as-a-Service; 이하 사스(SaaS))를 제공할 수 있다.
실시 예는 당사자들의 거래(transaction) 등의 정보 송수신에 이용되는 애플리케이션이나 사스(SaaS) 방식의 소프트웨어 서비스를 제공할 수 있다.
이 도면에서 거래 당사자를 클라이언트 1(110), 클라이언트 2(120) 또는 클라이언트 3(130)으로 나타내었다.
클라이언트들(110, 120, 130)은 각각의 파트너들과 사업 거래를 포함한 여러 가지 정보를 송수신할 수 있다. 이 경우 클라이언트들(110, 120, 130)은 예시한 애플리케이션 서비스 제공 방식을 이용할 수 있다.
실시 예에 따른 애플리케이션 서비스 제공 장치는, 사스(SaaS) 방식의 소프트웨어를 포함하는 애플리케이션을 제공하는 인스턴스 시스템(1000)과, 인스턴스 시스템(1000)을 통해 애플리케이션 서비스 제공하도록 하는 매니저 시스템(2000)을 포함한다.
매니저 시스템(2000)은 클라이언트들(110, 120, 130)에게 스케일-아웃(scale-out)이 가능한 인스턴스 시스템(1000)을 제공할 수 있다.
인스턴스 시스템(1000)에서는 매니저 시스템(2000)이 클라이언트들(110, 120, 130)에게 제공하는 서비스의 인터페이스가 실행될 수 있다.
매니저 시스템(2000)을 인스턴스 시스템(1000)을 연결하고 제어하는 매니저 서버(2100)와 송수신된 정보와 클라이언트들(110, 120, 130)의 요구사항들을 저장할 수 있는 데이터베이스(2200)를 포함할 수 있다. 매니저 시스템(2000)의 기능에 대해서는 이하에서 상술한다.
매니저 시스템(2000)에 의해 제공되는 인스턴스 시스템(1000)은 적어도 하나 이상의 노드를 포함할 수 있다.
이 도면의 예에서 노드#0 (1100)은, 매니저 시스템(2000)의 제어에 따라 애플리케이션 서비스를 제공하고 스케일-아웃을 수행하는 서비스 코디네이터(coordinator)로서 역할을 할 수 있다.
이 예에서 노드 #0인 코디네이터(coordinator) (1100)는, 워커노드(worker node)들인 제 1 노드(Node #1), 제 2 노드(Node #2), 제 3 노드(Node #3), 및 제 N 노드(Node #N) 등과 연결되어 시스템의 스케일을 제어할 수 있다.
예를 들어 노드들 간 연결은 RESTful 애플리케이션 프로그램밍 인터페이스(API)의 HTTP 프로토콜(이하 HTTP/REST로 표시) 등 인터페이스 프로토콜을 이용할 수 있는데, RESTful 애플리케이션 프로그램밍 인터페이스(API)는 HTTP를 사용하여 서버들 간의 데이터가 전송되고 수신되도록 할 수 있다.
예를 들어 노드#0인 코디네이터(coordinator)(1100)는 제 1 노드(Node #1), 제 2 노드(Node #2), 제 3 노드(Node #3), 내지 제 N 노드(Node #N)의 각각의 노드와 HTTP/REST에 의해 데이터를 송수신할 수 있다.
마찬가지로 제 1 노드(Node #1)는 HTTP/REST 기반으로 다른 노드들(노드#0, 제 2 노드(Node #2), 제 3 노드(Node #3), 및 제 N 노드(Node #N))와 데이터를 송수신할 수 있다.
코디네이터(coordinator) (1100)는 매니저 시스템(2000)의 소프트웨어 패키지 설치 요청에 따라 각 노드들(이 예에서, 제 1 노드(Node #1) 내지 제 N 노드(Node #N))에 상기 소프트웨어 패키지를 설치하도록 할 수 있다.
각 노드들은 시스템의 종류에 구애받지 않고 워크스페이스를 생성할 수 있는 프레임워크를 포함할 수 있다. 이에 대해서는 후술한다.
코디네이터(coordinator)(1100)는 각 노드의 프레임워크에서 구동하는 워크스페이스들(1510, 1520, 1530)을 각각의 클라이언트들(110, 120, 130)에 각각 제공할 수 있다.
클라이언트들(110, 120, 130)은 서로 격리된 워크스페이스들(1510, 1520, 1530)을 가질 수 있고, 격리된 워크스페이스들을 통해 애플리케이션 또는 소프트웨어 패키지들을 제공받거나, 변경 또는 이용할 수 있다.
이 예에서 제 1 노드(Node #1)는 제 1 노드(Node #1) 내부의 프레임워크에 의해 제공된 소프트웨어 패키지 A과 소프트웨어 패키지 C를 코디네이터(coordinator)(1100)를 통해 클라이언트에 제공할 수 있다.
제 2 노드(Node #2)는 제 2 노드(Node #2) 내부의 프레임워크에 의해 제공된 소프트웨어 패키지 A과 소프트웨어 패키지 B를 코디네이터(coordinator)(1100)를 통해 클라이언트에 제공할 수 있다.
제 3 노드(Node #3)는 제 3 노드(Node #3) 내부의 프레임워크에 의해 제공된 소프트웨어 패키지 B과 소프트웨어 패키지 C를 코디네이터(coordinator)(1100)를 통해 클라이언트에 제공할 수 있다.
매니저 시스템(2000)은 인스턴스 시스템(1000)를 통해 클라이언트들(110, 120, 130)에게 서로 격리된 각각의 워크스페이스들(1510, 1520, 1530)을 안정적으로 제공할 수 있다.
예를 들어 클라이언트 1(110)는 워크스페이스(1510)를 독립적으로 사용할 수 있다.
클라이언트1 (110)은, 코디네이터(coordinator)(1100)와 설정된 채널을 통해 자신의 워크스페이스에서 필요한 데이터를 송수신할 수 있다. 예를 들어 클라이언트1 (110)은 워크스페이스 A(1510)에서 HTTP 채널을 통해 코디네이터(coordinator) (1100)로부터 필요한 소프트웨어 패키지 A와 C를 제공받을 수 있다. 워크스페이스와 코디네이터(coordinator)(1100) 사이에 또는 코디네이터(coordinator) (1100)와 각 노드들 사이에 채널을 설정하는 상세한 예는 후술한다.
클라이언트 2(120)는 워크스페이스 B(1520)에서 예를 들어 HTTP 채널을 통해 코디네이터(coordinator) (1100)로부터 필요한 소프트웨어 패키지 A와 B를 제공받을 수 있다.
마찬가지로 클라이언트 3(130)는 워크스페이스 C(1530)에서 HTTP 채널을 통해 코디네이터(coordinator)(1100)로부터 필요한 소프트웨어 패키지 B와 C를 제공받을 수 있다.
인스턴스 시스템(1000)은 가상화된 시스템을 제공할 수 있어서 클라이언트들(110, 120, 130)는, 자신의 워크스페이스들(1510, 1520, 1530)에서 인스턴스 시스템(1000) 내에 어느 노드가 원하는 소프트웨어 패키지를 제공하는지 인지할 필요가 없다.
코디네이터(coordinator)(1100)에 의해 소프트웨어 패키지를 저장하고 제공하는 각각 노드들(Node #1, Node #2, Node #3, Node #N)은 워크스페이스들(1510, 1520, 1530)에 제공할 수 있는 소프트웨어 패키지들을 저장할 수 있다. 즉 여러 개의 노드들은(Node #1, Node #2, Node #3, Node #N)는 가상화되어 서로 격리된 워크스페이스들(1510, 1520, 1530)을 제공할 수 있다.
각각 노드들(Node #1, Node #2, Node #3, Node #N)은 각각 프레임워크를 포함하고, 각 프레임워크에서 소프트웨어 패키지를 소프트웨어 패키지 저장부(미도시)에서 다운로드하여 실행하도록 제어할 수 있다. 이에 대해서는 이하에서 상세히 설명한다.
각각 노드들(Node #1, Node #2, Node #3, Node #N)들 중 적어도 하나 이상의 노드에 클라이언트 1(110)이 이용하는 워크스페이스 A(1510)에 필요한 소프트웨어 패키지를 저장할 수 있다.
이 예에서 소프트웨어 패키지 A는 제 1 노드(Node #1)과 제 2 노드(Node #2)에 저장되어 있지만, 코디네이터(coordinator)(1100)의 스케일 아웃에 의해 다른 노드들(Node #3, Node #N)로 전달되어 저장될 수도 있다.
소프트웨어 패키지 B는 제 2 노드(Node #2)과 제 3 노드(Node #3)에 저장되어 있지만, 코디네이터(coordinator)(1100)의 스케일 아웃에 의해 다른 노드들(Node #1, Node #N)로 전달되어 저장될 수도 있다.
유사하게 소프트웨어 패키지 C는 제 3 노드(Node #3)와 제 1 노드(Node #1)에 저장되어 있지만, 코디네이터(coordinator)(1100)의 스케일 아웃에 의해 다른 노드들(Node #2, Node #N)로 전달되어 저장될 수도 있다.
이와 같이 소프트웨어 패키지는 여러 노드들에 분산 설치될 수 있다. 코디네이터(1100)은 소프트웨어 패키지가 어느 노드에 설치되는지 정보를 저장하고 필요한 경우 소프트웨어 패키지 요청에 대한 라우팅(routing)을 수행할 수 있고, 관리하는 노드들의 작업 스케줄링 기능을 수행할 수 있다.
따라서, 클라이언트들(110, 120, 130)은 코디네이터(coordinator)(1100)의 스케일 아웃에 의해 원하는 소프트웨어 패키지가 어느 노드에 저장되어 있는지 인지할 필요가 없이 각자의 가상화되고 격리된 워크스페이스들(1510, 1520, 1530)에서 소프트웨어 패키지들을 얻을 수 있다.
매니저 시스템(2000)은 코디네이터(coordinator)(1100)를 제어하여 클라이언트들(110, 120, 130)들이 원하는 소프트웨어 패키지를 얻을 수 있도록 애플리케이션 서비스를 제공할 수 있다.
노드들은 이하에서 설명하는 어댑터 패키지나 소프트웨어 패키지가 설치되고 실행되는 워커(worker) 노드로서 역할을 한다. 인스턴스 시스템(1000)에서 워커 노드들은 필요한 경우 매니저 시스템(2000)의 관리에 따라 자동 또는 수동으로 스케일-아웃(scale-out)되어 확장될 수 있다.
도 3은 개시한 애플리케이션 서비스 장치의 예에서 패키지들을 각 노드로 배포하는 예를 개시한다.
실시 예에 따르면 소프트웨어 개발자는 소프트웨어 이미지를 사용하여 애플리케이션을 신속하게 개발하고 배포할 수 있다.
각 노드의 프레임워크는 애플리케이션을 실행할 수 있고, 애플리케이션을 실행하는데 필요한 만큼의 노드의 리소스를 사용할 수 있다. 노드가 클라우드 시스템에 포함될 경우 클라우드 리소스를 기반으로 애플리케이션을 실행할 수 있다. 만약 노드가 온프레미스 기반의 시스템인 경우 온프레미스 리소스를 기반으로 애플리케이션을 실행할 수 있다. 이 도면에서는 클라우드의 경우를 예시하여 나타내었다.
인스턴스 시스템에 포함되는 노드들 상의 프레임워크는, 애플리케이션의 가상화 처리를 위해 노드가 포함된 클라우드/온프레미스 리소스를 제어할 수 있고, 애플리케이션 패키지를 다른 노드로 이식할 수 있도록 할 수 있다.
애플리케이션 서비스 프로바이더는 서비스와 관련된 소프트웨어 패키지(service app)를 생성하여 저장장치 또는 애플리케이션 저장소(Registry)에 저장할 수 있다. 여기서, 이하에서는 설명을 용이하게 하기 위해 애플리케이션 서비스 프로바이더가 제공하는 애플리케이션 서비스를 EDI (Electronic Data Interchange) 서비스로 예시하고, 소프트웨어 패키지를 EDI 서비스의 소프트웨어 이미지(EDI service app)로 예시한다.
예를 들어 EDI는 상거래와 관련된 정보를 합의된 표준 서식에 기입하여 표준화된 송수신 방법에 따라 기입된 정보를 교환하는 방식을 지칭한다. EDI 서비스는 여러 가지 거래 양식, 거래되는 물품이나 서비스, 거래 주체들에 따라 매우 많은 서비스들이 존재할 수 있다.
애플리케이션 서비스 프로바이더(ASP)는 이러한 EDI 서비스와 관련된 소프트웨어 패키지(EDI service app)를 생성하고, 이를 데이터베이스(database)에 등록하거나 또는 애플리케이션 저장소(Registry)에 저장할 수 있다.
소프트웨어 패키지는, 클라이언트가 소프트웨어를 설치하고 사용할 수 있도록 소프트웨어에 구성요소를 포함하는 소프트웨어의 묶음을 지칭한다. 이 예에서 소프트웨어 패키지(App 패키지)는 애플리케이션과 그 애플리케이션의 실행 가능한 바이너리 파트나 라이브러리 파트를 포함하는 패키지로 표시하였다.
따라서 소프트웨어 패키지는 가상화된 클라우드 리소스에서 실행되는 소프트웨어 이미지인 파일 형태를 가질 수 있다.
각 클라이언트는 각 워크스페이스(미도시)에서 저장소(Registry)에 저장되거나 데이터베이스(database)에 등록된 소프트웨어 패키지(EDI service app)를 다운로드받고, 이를 변경하거나 실행할 수 있다.
저장소(Registry)에 저장되거나 데이터베이스(database)에 등록된 소프트웨어 패키지(EDI service app)는 동일한 패키지라도 각 워크스페이스를 제공하는 노드들에 다운로드되거나 실행될 수 있다.
각 클라이언트는 각자의 격리된 워크스페이스(미도시)에서 필요한 소프트웨어 패키지(EDI service app)를 소프트웨어 이미지로 다운받아 원하는 EDI 서비스에 이용할 수 있다.
각 클라이언트는 소프트웨어 이미지로 다운받아 원하는 EDI 서비스를 얻는데 사용하거나, 상기 클라이언트의 파트너에 EDI 서비스를 제공할 수도 있다.
클라이언트가 격리된 워크스페이스에서 소프트웨어 이미지로 다운받아 원하는 EDI 서비스를 제공할 경우 소프트웨어 패키지(EDI service app)를 저장소(Registry)에 저장하거나 데이터베이스(database)에 등록시킬 수도 있다.
애플리케이션 서비스 프로바이더(ASP)는, 클라이언트가 EDI 서비스 등의 서비스에 관련된 소프트웨어 패키지를 이용, 변경 또는 제공할 수 있도록 인스턴스 시스템을 제공하고, 인스턴스 시스템과의 데이터 송수신을 관리할 수 있다. 이에 대해서는 이하에서 상술한다.
도 4는 실시 예에 따른 애플리케이션 서비스 제공에 대한 레이어 별 요소들을 개시한 개념도이다.
실시 예에 따른 애플리케이션 서비스 제공 장치는 매니저 시스템(2000)에 의해 제어되고 관리될 수 있다.
매니저 시스템(2000)은 온프레미스 시스템 또는 클라우드 시스템을 이용하여 EDI 서비스와 같은 애플리케이션 서비스를 제공할 수 있다. 매니저 시스템(2000)이 서비스를 제공하는 상세한 예는 아래에서 후술한다.
컴퓨팅 시스템은 온프레미스 시스템 또는 클라우드 시스템 중 적어도 하나를 포함할 수 있다.
컴퓨팅 시스템은 컴퓨팅 리소스를 가상화할 수 있는 컨테이너나 가상머신(VM)과 같은 가상화 레이어(virtualization layer)를 포함할 수도 있다.
이 도면은 가상화 레이어가 포함되는 경우를 예시하는 것으로 가상화 레이어는 점선으로 표시하였다.
예를 들면, 컴퓨팅 시스템은 가상화 레이어(virtualization layer)로서 컨테이너를 제공할 수 있다. 컨테이너는 호스트 운영 체제(OS) 위에서 애플리케이션을 실행하는 데 필요한 만큼 호스트의 리소스를 사용하도록 할 수 있다. 컨테이너 이미지를 사용하면 애플리케이션을 신속하게 개발하고 배포하도록 할 수 있다.
컴퓨팅 시스템은 프레임워크를 제공하는 프레임워크 레이어(1700)를 포함할 수 있다. 프레임워크는 응용프로그래밍인터페이스(API)(1610, 4100)를 통해 여러 가지 애플리케이션이들이 구동할 수 있도록 할 수 있다.
워크스페이스(1500, 3000)나 인터페이스 거버넌스 플랫폼(4000)은 응용프로그래밍인터페이스 (API)(1610) 또는 거버넌스 API(4100)는 상에 위치하고, 여러 가지 애플리케이션들이 응용프로그래밍인터페이스 (API)(1610, 4100)상에서 구동될 수 있다.
클라이언트(100)는, 매니저 시스템(2000)이 제공하는 애플리케이션 서비스, 즉, 소프트웨어 패키지를 이 도면에서 예시하는 바와 같은 레이어들을 가진 시스템에 의해 제공받을 수 있다.
예를 들어 클라이언트(100)는 격리된 워크스페이스(1500)를 통해 EDI 애플리케이션(EDI App.) 등의 서비스를 이용할 수 있다. 이 예에서 클라이언트(100)는 워크스페이스(1500)를 통해 EDI와 다른 애플리케이션 서비스(App.), 메시지 서비스(message), 웹 서비스(web service), 프로토콜 어댑터 서비스(protocol adapter), 데이터 변환 서비스(transformation), 모니터링 서비스(monitoring), 보안 서비스(security) 등의 애플리케이션 또는 서비스를 이용할 수 있다. 워크스페이스(1500)상의 애플리케이션 또는 서비스는 이하에서 상세히 개시한다.
파트너(200)는 클라이언트(100)의 실제 거래 파트너이거나, 거래와 관계된 다른 거래 주체로서 워크스페이스(1500)을 통해 애플리케이션 서비스를 이용하거나 클라이언트(100)가 제공하는 EDI 서비스와 같은 애플리케이션 서비스를 제공받을 수 있다.
클라이언트(100)가 EDI 서비스와 관련된 애플리케이션을 통해 거래를 진행하는 경우 파트너(200)는 클라이언트(100)가 제공하는 EDI 서비스 애플리케이션을 통해 거래를 진행할 수 있다.
매니저 시스템(2000)은 클라이언트가 자신의 거래에 필요한 애플리케이션을 개발할 수 있는 환경을 제공할 수 있다.
매니저 시스템(2000)은 개발워크스페이스(3000)에서 애플리케이션을 개발, 테스트하여 워크스페이스(1500)를 통해 개발한 애플리케이션 서비스를 제공할 수 있다. 뿐만 아니라 매니저 시스템(2000)은 개발워크스페이스(3000)를 클라이언트(100)나 파트너(200)에게 제공하는 컴퓨팅 환경을 관리하고, 클라이언트(100)나 파트너(200)가 개발워크스페이스(3000)에서 필요한 애플리케이션을 개발할 수 있도록 할 수 있다.
이러한 개발워크스페이스(3000)는 애플리케이션을 개발할 수 있는 개발 툴 애플리케이션 (development tool), 개발한 애플리케이션에 대한 이용과 과금체계를 정하는 빌링 애플리케이션(payment/billing), 개발한 애플리케이션을 판매할 수 있는 앱스토어(app. Store), 이러한 기능을 지원하고 제어하고 백오피스 애플리케이션(back-office)를 포함할 수 있다.
예를 들면, 클라이언트(100) 또는 파트너(200)는 개발워크스페이스(3000)를 통해 애플리케이션을 개발하고 변경하고 테스트할 수 있다. 클라이언트(100) 또는 파트너(200)는 매니저 시스템(2000)이 제공하는 애플리케이션 뿐만 아니라 개발워크스페이스(3000)에서 자체적으로 애플리케이션 또는 소프트웨어 패키지를 개발할 수 있다.
또한 클라이언트(100)는 개발워크스페이스(3000)를 통해 개발한 애플리케이션을 도면에 예시한 앱 스토어(app store)(3000)를 통해 다른 클라이언트나 파트너들에게 제공할 수도 있다.
파트너(200) 또한 매니저 시스템(2000)은 제공하는 시스템을 통해 클라이언트(100)와 같이 소프트웨어 패키지를 개발, 테스트, 활용 및 서비스 제공에 이용할 수 있다.
매니저 시스템(2000)은 솔루션 API(4100) 상의 인터페이스 거버넌스 플랫폼(4000)을 통해 클라이언트 시스템에 대한 점검, 제어 등을 제공할 수도 있는데 이러한 서비스에 대해서는 별도로 상세히 개시한다.
이하에서는 먼저 클라이언트(100)가 워크스페이스(1500)를 통해 소프트웨어 패키지를 이용하여 서비스를 제공받거나 제공하는 상세한 예들을 설명한다.
도 5는 실시 예에 따른 애플리케이션 서비스 제공 장치가 인스턴스와 클라이언트 또는 파트너 사이의 채널을 설정하는 개념을 개시한 도면이다.
개시한 바와 같이 인스턴스 시스템은 적어도 하나 이상의 노드를 포함할 수 있다. 예를 들어 인스턴스 시스템은, 코디네이터 노드와 상기 코디네이터 노드와 소프트웨어 패키지를 송수신하는 워커 노드를 포함할 수 있다.
인스턴스 시스템은 자체의 워커노드들을 확장할 수 있을 뿐만 아니라 둘 이상의 인스턴스 시스템들로 확장될 수 있다. 따라서 클라이언트가 증가하여도 지속적으로 확장된 시스템 환경과 서비스를 제공할 수 있다.
애플리케이션 서비스가 제공되기 위해 애플리케이션 서비스 매니저(2100)는 클라이언트 또는 파트너(300)들에 자원 등의 정보를 수집할 수 있다.
이 경우 애플리케이션 서비스 매니저(2100)가 직접 클라이언트/파트너(300)의 시스템을 직접 접근하여 클라이언트/파트너(300)의 자원정보를 수집하면 보안 상 문제가 될 수 있다.
따라서, 실시 예는 클라이언트/파트너(300)에 에이전트(350)을 설치하도록 하고, 클라이언트/파트너(300)가 직접 접속정보를 관리할 수 있도록 할 수 있다.
에이전트(350)는 클라이언트/파트너(300) 내의 자원관리정보 또는 접속정보에 대한 연결정보를 설정할 수 있다. 이 예에서 에이전트(350)는 클라이언트/파트너(300)의 자원관리정보 또는 접속정보, 클라이언트/파트너(300)의 사용자정보, 기타 파일 시스템 정보를 수집할 수 있다. 또한 에이전트(350)는 클라이언트/파트너(300)의 데이터베이스에 접근하여 저장된 정보를 수집할 수 있다. 에이전트(350)는 수집된 정보를 저장할 수 있다.
클라이언트/파트너(300)의 에이전트(350)는 애플리케이션 서비스를 제공받을 수 있는 인스턴스 시스템의 임의의 노드인 제 N 노드(Node #n)(1300)에 설치된 에이전트 어댑터(1350)와 연결될 수 있다.
애플리케이션 서비스 매니저(2100)는 제 N 노드(1300)에 설치된 에이전트 어댑터(1350)으로부터 클라이언트/파트너(300)의 에이전트(350)에서 수집된 클라이언트/파트너(300) 관련 정보를 얻을 수 있다.
제 N 노드(1300)는 설정 저장부(Config. Repository)(1330)를 포함할 수 있는데 매니저 시스템(2100)이 설정한 정보, 예를 들면 에이전트를 위한 설정 정보 또는 에이전트와 에이전트 어댑터 간의 송수신 정보가 저장될 수 있다. 위한 에이전트 어댑터(1350)가 클라이언트/파트너(300)의 에이전트(350)로부터 전달받은 여러 가지 정보를 저장할 수 있다.
애플리케이션 서비스 매니저(2100)는 메시지 박스(2110)을 포함할 수 있는데, 메시지 박스(2110)는 제 N 노드(1300)의 에이전트 어댑터(1350)가 저장된 정보를 수신(outbox slot)하거나, 에이전트 어댑터(1350)에 정보를 요청(inbox slot)할 수 있다.
에이전트 어댑터(1350)는, 애플리케이션 서비스 매니저(2100)의 메시지 박스(2110)으로부터 받은 정보(inbox slot)를 클라이언트/파트너(300)의 에이전트(350)로 전달한다. 그리고, 에이전트 어댑터(1350)는, 클라이언트/파트너(300)의 에이전트(350)로부터 수신한 정보(outbox slot)를 애플리케이션 서비스 매니저(2100)의 메시지 박스(2110)로 전달한다.
메시지 박스(2110)는 송수신하는 데이터, 파일, 또는 문서 등을 저장할 수 있는 저장소이며 별도의 서버로 구성될 수도 있다. 따라서 메시지 박스(2110)는 메시지 서버라고 호칭할 수도 있으나, 이 도면의 예에서는 논리적인 구분과 모니터링의 단위로서 메시지 박스로 표시한다.
클라이언트/파트너(300)에 등록된 에이전트(350)는 에이전트 어댑터(1350)로 데이터를 보낼 수 있다(send). 그리고 에이전트(350)는 에이전트 어댑터(1350)로부터 일정한 주기로 데이터를 수신 또는 폴링(polling)할 수 있다.
클라이언트/파트너(300)에 서비스를 제공하는 제 N 노드(1300)의 설정 저장부(Config. Repository)(1330)는 에이전트(350)와 에이전트 어댑터(1350) 사이의 채널 설정 정보나 에이전트 어댑터(1350)가 에이전트(350)로부터 수신하는 설정 정보 등을 저장할 수 있다.
애플리케이션 서비스 매니저(2100)는 노드(1300)에 설치된 에이전트 어댑터(1350)로부터 클라이언트/파트너(300)에 제공되는 서비스에 필요한 정보를 제공하거나 얻을 수 있다.
에이전트(350)는 클라이언트/파트너(300)의 필요한 정보만 수집하기 때문에 클라이언트/파트너(300)에 발생하는 보안문제를 최소화시킬 수 있다. 또한, 에이전트(350)가 불필요한 데이터를 가져오지 않고 일정 주기로 데이터가 송수신되기 때문에 제 N 노드(1300)와 클라이언트/파트너(300)사이의 채널 과부하가 생기지 않을 수 있다.
제 N 노드(1300)는 설정 저장부(Config. Repository)(1330)에 필요한 정보를 저장하므로 에이전트(350)가 수집하는 정보의 최신상태를 유지할 수 있으며 채널을 경량화시킬 수 있다.
실시 예에 따르면 제 N 노드(1300)에 클라이언트/파트너(300)에 관련된 정보의 최신 상태가 저장될 수 있어서 클라이언트/파트너(300)에 부담을 주지 않고 보안을 강화할 수 있다.
개시한 예와 같이 설정된 채널을 통해 제 N 노드(1300)내 에이전트 어댑터(1350)의 서비스에 필요한 정보를 송수신하는 이하에서 상세하게 개시한다.
도 6은 실시 예에 따른 애플리케이션 서비스 제공 장치가 인스턴스와 클라이언트 또는 파트너 사이의 채널을 설정하는 구체적인 예를 개시한 도면이다.
위에서 개시한 개념에 따라 애플리케이션 서비스 매니저(2100)는, 클라이언트 또는 파트너(300)가 인스턴스 시스템(1000)을 통해 애플리케이션을 제공, 이용, 변경할 수 있도록 할 수 있다. 인스턴스 시스템(1000)은 코디네이터(1100)과 임의의 노드인 제 N 노드(1300)을 포함할 수 있다.
애플리케이션 서비스 매니저(2100)는 클라이언트/파트너(300)에 에이전트(350)의 설치를 위한 정보를 배포할 수 있다. 예를 들면 에이전트(350)의 설치를 위한 정보는 에이전트 설정 정보, 에이전트 설정을 위한 키 정보, 자원 관리 정보, 사용자 관리 설정 정보 등을 포함할 수 있다.
예를 들어 에이전트 설정 정보는 채널 정보를 동기화하는 시간, HTTP 요청에 대한 타임아웃, 설치 브라우저와 관련된 세션키의 키(key) 값, 에이전트가 관련 정보를 송수신하는데 필요한 경로 등의 정보를 포함할 수 있다.
채널은 애플리케이션 서비스 매니저(2100)가 제공하는 서비스를 사용하기 위해 설정되는 것으로서, 예를 들어 어댑터(adapter) 패키지와 같은 패키지와 연결하기 위한 컴포넌트로 설명할 수 있다. 이와 관련된 예는 이하에서 상세히 설명한다.
클라이언트/파트너(300)는 에이전트(350)가 설치될 수 있고, 에이전트(350)는 클라이언트/파트너(300)의 자원관리정보, 접속정보, 사용자정보 등을 수집할 수 있다. 필요한 경우 에이전트(350)는 클라이언트/파트너(300)의 데이터베이스나 파일시스템에 접근할 수 있다.
에이전트(350)는 인스턴스 시스템(1000)의 코디네이터(1100)에 소프트웨어 패키지를 요청할 수 있다. 이 경우 에이전트(350)는 코디네이터(1100)의 에이전트 어댑터(1350)에 소프트웨어 패키지를 수신하기 위한 채널 서비스를 요청할 수 있다. 여기서는 에이전트(350)가 에이전트 어댑터(1350)에 요청하는 채널 서비스를 위해 HTTP 요청 이용할 수 있다.
예를 들어 클라이언트/파트너(300)의 에이전트(350)가 사전 설정된 HTTP URI로 요청을 전달하면, 코디네이터(1100)는 특정 포트로 들어오는 HTTP 트래픽, 즉 인바운드(inbound) HTTP 연결을 허락하고, 이 HTTP 서비스를 워커 노드인 제 N 노드(1300)의 에이전트 어댑터(1350)로 전달하는 채널 서비스로 변환할 수 있다.
에이전트(350)의 설치를 위한 정보에는 인스턴스 시스템(1000)에 접속할 수 있는 경로 정보가 이미 포함되어 있다.
클라이언트/파트너(300)에 에이전트(350)가 설치되면 클라이언트/파트너(300)의 관리자는 에이전트(350)가 관리하는 클라이언트/파트너(300) 시스템의 관리 정보, 사용자 정보 등을 설정할 수 있고, 제 N 노드(1300)의 에이전트 어댑터(1350)와의 동기화 시간 등을 설정할 수도 있다.
애플리케이션 서비스 매니저(2100)은, 상기 등록된 에이전트(350)와 관련하여 인스턴스 시스템(1000)에 설치되는 에이전트 어댑터(1350)에 대한 설정 정보, 상기 등록된 에이전트(350)와 동기화 활성 여부 정보를 설정할 수 있다.
애플리케이션 서비스 매니저(2100)은, 상기 등록된 에이전트(350)가 전송하는 정보를 저장하기 위한 메시지 박스내 아웃박스 슬롯(outbox slot) 정보와 상기 등록된 에이전트(350)가 수신하는 정보를 저장하기 위한 메시지 박스내 인박스 슬롯(inbox slot) 정보를 설정할 수 있다.
애플리케이션 서비스 매니저(2100)는 위와 같이 설정한 정보에 따라 에이전트(350)가 전송하는 정보와 에이전트(350)가 수신하는 정보를 메시지 박스(2110)내의 아웃박스 슬롯(outbox slot) 과 인박스 슬롯(inbox slot)에 각각 저장한다. 메시지 박스 내의 슬롯(slot)은 데이터의 처리단위를 저장하는 논리적인 구분 개념으로서, 메시지 박스는 큐(queue) 같이 데이터 처리단위를 저장하고 출력될 수 있다.
한편, 애플리케이션 서비스 매니저(2100)는 상기 등록된 에이전트(350)와 에이전트 어댑터(1350)가 인증을 진행할 수 있는 인증키 정보도 설정할 수 있다.
이와 같이 에이전트(350)가 클라이언트/파트너(300)에 등록되고 에이전트 어댑터(1350)가 인스턴스 시스템(1000)에 설정되면, 에이전트 어댑터(1350)는 에이전트(350)에 설정된 자원과 연결될 수 있다.
그리고 에이전트(350)로부터 설정된 정보에 따라 관련 정보나 데이터를 에이전트 어댑터(1350)와 송수신할 수 있다.
이 도면에서 에이전트(350)가 클라이언트/파트너(300)의 자원으로부터 설정된 주기에 따라 출력되는 정보(outbox)를 전송하는 채널을 송신(send) 채널로 표시하였다. 그리고 에이전트(350)가 에이전트 어댑터(1350)로부터 전송되는 정보(inbox)를 수신하는 채널을 수신(receive/polling) 채널로 표시하였다.
에이전트(350)는 설정된 송신(send) 채널과 설정된 수신(receive/polling) 채널을 통해 에이전트 어댑터(1350)로부터 요청한 데이터를 보내고 받을 수 있다.
도 7는 실시 예에 따라 분산된 시스템에서 채널을 관리하고 서비스를 제공받는 예를 개시한 도면이다.
예시한 바와 같이 인스턴스 시스템(1000) 내에 노드들은 서비스를 제공하기 위해 채널을 통해 데이터를 송수신할 수 있다. 채널은 서비스를 제공하기 위한 데이터 또는 패키지를 호출하거나 또는, 이미 등록된 채널이 어느 노드에서 실행되고 있는지를 조회하는 서치하는 통로를 총칭한다.
여기서는 인스턴스 시스템(1000)의 코디네이터(1100)가 분산 환경의 노드들을 설치되는 패키지들을 채널 연결을 통해 관리하는 예를 개시한다.
코디네이터(1100)는 워커노드들을 각각 연결할 수 있는 채널 정보와 각 워커노드들에 저장된 패키지들에 대한 정보를 저장할 수 있다.
예를 들어 코디네이터(1100)는 워커노드들(1110, 1120)에 저장된 패키지에 대한 정보를 등록하여 저장할 수 있다. 코디네이터(1100)는, 제 1 노드(Node #1)의 워커노드(1110)가 저장하는 어댑터 패키지 A와 통합 패키지(integration package)에 대한 정보를 등록하여 저장하고, 제 2 노드(Node #2)의 워커노드(1120)가 저장하는 어댑터 패키지 B에 대한 정보를 등록하여 저장할 수 있다.
코디네이터(1100)는 클라이언트 또는 파트너로부터 패키지와 관련된 서비스 요청을 수신할 수 있다. 위에서 개시한 바와 같이 여기서는 서비스 요청을 URL 정보가 포함된 HTTP 요청을 통해 수신하는 경우를 예시한다.
코디네이터(1100)는 HTTP 요청에 포함된 URL 정보에 기초하여 코디네이터(1100)에 등록되어 매핑된 경우 워커노드들을 위한 서비스 채널을 설정할 수 있다.
여기서의 예와 같이 코디네이터(1100)는 클라이언트 또는 파트너의 URL 정보가 포함된 HTTP 요청에 따라 HTTP 서비스 채널을 설정한다. 코디네이터(1100)는 제 1 워커노드(워커 노드 #1) (1110)가 제공하는 어댑터 패키지 A를 설정된 HTTP 서비스 채널을 통해 호출할 수 있다.
클라이언트 또는 파트너는 코디네이터(1100)가 제공하는 격리된 워크스페이스를 이용하므로 클라이언트들(또는 파트너들)은 각자의 워크스페이스 내의 패키지들 버전은 달라질 수 있고, 서로 다른 버전의 어댑터 패키지를 이용할 수 있다.
클라이언트가 요청하는 어댑터 패키지 A는, 코디네이터(1100)에 등록된 정보에 따라 제 1 워커노드(워커 노드 #1) (1110)에서 HTTP 서비스 채널을 통해 호출될 수 있다.
제 1 워커노드(워커 노드 #1) (1110)는 HTTP 서비스 채널에 따라 등록된 어댑터 패키지 A를 제공할 수 있다.
클라이언트 또는 파트너가 해당 워크스페이스에서 애플리케이션 패키지를 개발할 경우 어댑터 패키지 B가 포함된 통합 패키지가 필요할 수도 있다.
코디네이터(1100)는 등록된 정보에 따라 제 1 워커노드(워커 노드 #1) (1110)가 통합 패키지를 저장하고, 제 2 워커노드(워커 노드 #2) (1110)가 어댑터 패키지 B를 저장한 것을 알고 있다.
코디네이터(1100)는 어댑터 기능 채널을 통해 제 1 워커노드(워커 노드 #1) (1110)에서 어댑터 패키지 B가 포함된 통합 패키지를 조회서치할 수 있다. 그리고 어댑터 패키지 B가 제 1 워커노드(워커 노드 #1) (1110)에 저장된 통합 패키지에 포함되지 않은 경우, 제 1 워커노드(워커 노드 #1) (1110)는, 제 2 워커노드(워커 노드 #2) (1120)에 저장된 어댑터 패키지 B를 워커노드들 사이의 채널 연결을 통해 호출하도록 할 수 있다.
그러면 제 2 워커노드(워커 노드 #2) (1120)는 호출된 어댑터 패키지 B를 제공할 수 있는데 그 경우 코디네이터(1100)는 어댑터 패키지 B를 제공하는 채널을 어댑터 기능 채널에 등록하여 통합패키지와 함께 어댑터 패키지 B가 함께 제공되도록 할 수 있다.
이와 같이 개시하는 실시 예는 여러 가지 패키지들이 여러 노드에 분산 설치할 수 있다. 패키지 사이의 통신 또는 인스턴스 시스템 외부에서 특정 어댑터 패키지를 호출하기 위해 코디네이터(1100)는 패키지 서비스를 제공할 수 있는 워커노드들에 해당 패키지를 서치, 호출 또는 등록하는 채널들을 관리하고 저장할 수 있다.
코디네이트(1100)인스턴스 시스템(1000)의 에이전트 어댑터(1350)는 예시한 바와 같이 에이전트(350)으로부터의 송신 채널과 수신 채널에 대해 설정할 수 있다. 에이전트 어댑터(1350)는 에이전트의 식별자, 채널 주기 등 채널과 관련된 정보를 이용해 특정 에이전트와 채널을 설정할 수 있다.
이와 같이 코디네이터(1100)는 요청된 패키지 관련 서비스가 워커노드들에 분산되어 수행될 수 있도록 여러 가지 정보를 관리할 수 있다. 위에서는 HTTP 서비스 채널을 예시하였으나 FTP와 같은 파일 전송 채널을 통해 패키지가 전달될 수도 있다.
코디네이터(1100)는 여러 개의 워커노드들에 분산 수행되는 어댑터 패키지들의 경우 공유 메모리(미도시) 또는 저장소에 저장할 수도 있다.
또한 코디네이터(1100)는 여러 클라이언트들이 사용하는 어댑터와 관련된 로그 등의 데이터도 저장하고 관리할 수 있다.
도 8은 실시 예에 따라 설치되는 패키지의 설정 정보를 관리하는 예를 개시한 도면이다.
이 도면의 예에서 인스턴스 시스템(1000) 내의 분산 시스템인 코디네이터(1100), 제 m 노드(node #m)(3110), 및 제 n 노드(node #n)(3210)는 각각 노드 내의 설정 저장부들(1115, 3115, 3215)를 포함할 수 있다.
매니저 시스템(2000)의 애플리케이션 서비스 매니저(2100)는 패키지와 관련된 여러 가지 설정 정보(사각형)를 저장할 수 있다. 저장되는 설정 정보는 패키지가 각 노드에서 실행될 때 필요한 여러 가지 설정 정보를 포함할 수 있다.
애플리케이션 서비스 매니저(2100)는 패키지의 설정 정보를 데이터베이스(2200)에 저장할 수 있다. 애플리케이션 서비스 매니저(2100)는 특정 노드, 이 예에서는 제 m 노드(node #m)(3110)로부터 패키지의 설정 정보를 얻거나 외부에서 요청한 패키지의 설정 정보를 데이터베이스(2200)에 저장할 수 있다.
코디네이터(1100)는 애플리케이션 서비스 매니저(2100)에 의해 관리되는 패키지의 설정 정보를 자신의 설정 저장부(1115)에 저장할 수 있다. 애플리케이션 서비스 매니저(2100)는 제어 화면 등을 통해 패키지의 설정 정보를 관리하고 저장할 수 있다.
인스턴스 시스템(1000)내의 위커 노드들인 제 m 노드(node #m)(3110, 및 제 n 노드(node #n)(3210)는 코디네이터(1100)의 설정 저장부(1115)로부터 관련된 패키지의 설정 정보를 수신하여 각각의 설정 저장부(3115, 3215)에 저장할 수 있다.
이 예에서 워크 노드워커 노드인 제 n 노드(node #n)(3210)가 코디네이터(1100)의 설정 저장부(1115)에 저장된 패키지의 설정 정보로 해당 패키지의 설정 정보를 동기화 할 수 있다. 이러한 동기화는 주기적으로 수행될 수도 있고, 설정에 따라 다른 주기로 동기화될 수도 있다.
워크 노드워커 노드인 제 n 노드(node #n)(3210)가 패키지를 실행하여야 하는 경우에는 자신의 설정 저장부(3215)에 동기화되어 저장된 설정 정보를 이용하여 패키지를 실행할 수 있다.
클라이언트/파트너는 코디네이터(1100)의 패키지 설정 화면 등을 통해 워크 노드워커 노드인 제 m 노드(node #m)(3110)의 패키지의 설정 정보를 변경하고 저장할 수 있다.
워크 노드워커 노드인 제 m 노드(node #m)(3110)의 패키지 설정 정보가 변경된 경우, 애플리케이션 서비스 매니저(2100)에 패키지의 변경된 설정 정보를 전송할 수 있다.
다시 애플리케이션 서비스 매니저(2100)는 제 m 노드(node #m)(3110)로부터 전송된 패키지의 변경된 설정 정보를 데이터 베이스(2200)에 저장할 수 있다.
도 9는 개시하는 실시 예의 워크스페이스에 따라 패키지를 관리하고 이용하는 예를 개시한 도면이다.
클라이언트는 격리된 워크스페이스에서 여러 가지 패키지를 생성, 실행 및 변경할 수 있다.
예를 들어 클라이언트는 워크스페이스에서 어댑터 패키지를 실행할 수 있는데, 어댑터 패키지는 설정 저장소에 저장된 설정 정보를 이용하여 실행될 수 있다. 그런데 경우에 따라 패키지는 설정 저장소의 설정 정보 이외에 리소스 파일을 참고하여 실행되는 경우도 있다.
리소스 파일은 일종의 리소스 패키지인 매핑 프로그램으로서 워크스페이스에 설치될 수 있다. 리소스 파일은 어댑터 패키지와 같은 패키지 실행 시에 리소스 경로를 이용해 액세스되어 어댑터 패키지가 실행되도록 할 수 있다.
개시하는 실시 예에 따르면 워크스페이스에서 패키지의 개발 또는 테스트와 운영이 모두 가능하다.
따라서, 실시 예에 따르면 `운영을 위한 워크스페이스와 개발을 위한 워크스페이스를 분리하여 리소스 파일을 제공할 수 있다.
이 도면의 예에서 개발을 위한 워크스페이스(1510)에서 어댑터 패키지를 개발할 경우, 해당 어댑터 패키지는 리소스 파일을 읽기뿐만 아니라 쓰기 가능한 프로그램으로서 이용할 수 있다. 이 경우 매핑 프로그램인 리소스 파일은 쓰기가 가능한 공유 리소스 경로로 지정되어 액세스되도록 할 수 있다.
반면에 운영을 위한 워크스페이스(1520)에서 어댑터 패키지를 실행할 경우, 리소스 파일은 어댑터 패키지가 읽기만 할 수 있고 쓰기가 불가능한 리소스 패키지로서 제공될 수 있다. 이 경우 어댑터 패키지는 리소스 패키지를 참조하여 설치, 및 액세스할 수 있고 리소스 패키지 내의 리소스 파일을 변경할 수 없다.
도 10은 실시 예에 따라 애플리케이션 서비스의 일종으로서 EDI 정보를 매핑하는 예를 개시한 도면이다.
개시하는 실시 예들을 여러 가지 애플리케이션 서비스를 제공할 수 있을 뿐만 아니라 여러 가지 애플리케이션 서비스를 개발하는 플랫폼 환경을 제공할 수 있다.
이하에서는 이러한 애플리케이션 서비스의 일 예로서 EDI 서비스를 예를 들어 설명한다. 개시된 바로부터 당업자가 이해할 수 있듯이 실시 예를 이용하면 여러 가지 애플리케이션 서비스들을 개발 또는 제공할 수 있으므로 반드시 EDI 서비스에 한정될 필요는 없다.
애플리케이션 서비스의 일종으로 EDI는 산업별로 여러 타입의 거래들과 거래 당사자들, 거래 양식들이 요구된다. 따라서, 산업별로 복잡하고 여러 타입의 거래 양태들에 개시하는 실시 예를 활용할 경우 효율적인 거래가 가능하므로 산업적 거래 활성화에 매우 효과적이다.
이 도면은 EDI 서비스에 요구되는 여러 가지 정보 또는 문서를 거래 당사들 사이에 변환하도록 하는 애플리케이션 서비스를 예시한다.
EDI는 산업에 따라 특정 규칙과 규정을 따라 매우 다양한 형식이 있으며 이러한 형식에 따라 EDI 문서를 작성하고 처리해야 거래가 성립될 수 있다. EDI 서비스는 전자 상거래 뿐만 아니라 운송, 물류, 금융이나 보험 등의 다양한 산업에 따른 형식이 있다. EDI는 국제 표준화 기구인 ISO 등에서 표준화되고, UN/EDIFACT (United Nations/Electronic Data Interchange for Administration, Commerce and Transport)나 ANSI(American National Standards Institute) X.12에 의해 규정되고 관리된다.
주문과 공급을 수행하는 거래의 특성에 따라 서로 다른 데이터나 정보를 포함하는 다른 형태의 문서가 사용될 수 있고 거래 당사자가 사용하는 시스템도 다를 수 있다.
EDI 서비스를 위해서는 두 거래 당사자들 사이의 문서의 매핑(mapping)되어야 한다.
이 도면의 예는 EDI 서비스를 제공하기 위해 데이터를 포함한 문서를 범용 시스템으로 변환하는 프로그램인 매핑 엔진(advanced mapping engine)을 개념적으로 개시한다.
예를 들어 거래 당사자가 거래에 필요한 EDI 문서와 EDI 스키마(schema)를 제공할 수 있다. 이러한 데이터는 입력된 스키마에 따른 EDI 데이터(즉, EDI 문서)에 포함된 바이트나 스트링을 디코딩하여 디코딩된 데이터(unmarshal data)로 변환할 수 있다.
매핑 엔진은 변환할 데이터와 변환될 데이터의 스키마들을 기반으로 스키마들을 서로 매핑하는 기준 정보를 포함할 수 있다. 여기서는 매핑 기준 정보를 매핑 스크립트라고 호칭한다.
매핑 기준 정보는 언마샬링(Unmarshalling)한 데이터를 타겟한 다른 형식의 문서로 변환하기 위한 것으로 스크립트 형식을 가질 수 있다.
매핑 엔진은 EDI 데이터와 EDI 스키마가 디코딩된 데이터(unmarshal data)를 일반적인 문서의 인터페이스로 사용될 수 있는 특정 포맷의 파일(여기서는 제이슨(JSON) 파일을 예시)과 그에 상기 특정 포맷의 파일에 대한 스키마(여기서는 제이슨(JSON) 스키마로 예시)로 매핑하여 변환할 수 있다.
보다 상세하게 EDI 스키마로서 SEF(Standard Exchange Format) 표준의 EDI 포맷을 이용하거나 EXF(EDI Exchange Format) 등의 EDI 포맷을 이용할 수 있다.
변경된 형식의 파일은 일반적인 파일(flat file), 제이슨(JSON), XML 등의 형식의 파일일 수 있다.
변경된 형식의 파일에 대해 각 파일 타입별 마샬링(Marshalling) 또는 언마샬링(Unmarshalling)을 수행하면, 주석(annotation)으로 정의된 스키마 파일로 변환될 수 있다. 즉, 변환될 데이터에 대응되는 타입과, 특정 데이터 타입에 대응되는 주석(annotation)이 정의된 스키마로 마샬링 또는 언마샬링된 결과를 얻을 수 있다.
실시 예는 이러한 매핑 엔진을 통해 스키마를 생성하고, 매핑 기준 정보인 매핑 스크립트를 작성할 수 있는 그래픽 인터페이스를 사용자에게 제공할 수 있다.
도 11은 실시 예에 따라 통합 패키지를 이용하여 애플리케이션 서비스를 제공하는 예를 개시한 도면이다.
실시 예에 따르면 클라이언트(310)는 원하는 파트너(320)에게 개시한 예와 같은 애플리케이션 서비스를 제공할 수 있다. 실시 예는 단순히 클라이언트(310)에서 서비스를 제공할 뿐만 아니라 클라이언트(310)가 실시 예를 이용해 직접 원하는 파트너(320)에게 커스텀마이즈된 서비스(customized service)를 제공할 수 있도록 할 수 있다.
여기서 애플리케이션 서비스 중 EDI 서비스를 예시하여 설명한다. 클라이언트(310)가 파트너(320)와 거래를 하기 위해 실시 예는 인스턴스 시스템에 포함되는 코디네이터(1100)와 워커노드(1300)를 제공할 수 있다.
애플리케이션 서비스 매니저(2100)는 클라이언트(310)와 파트너(320)가 인스턴스 시스템을 통해 거래에 필요한 정보를 교환할 수 있도록 인스턴스 시스템을 제공하고 관리할 수 있다.
개시한 바와 같이 클라이언트(310)에는 에이전트(미도시)가 설치되어 있고, 에이전트를 통해 거래에 필요한 정보인 EDI 정보를 요청할 수 있다. 이 경우 EDI 정보의 요청은 HTTP 트래픽으로 전송될 수 있다.
인스턴스 시스템의 코디네이터(1100)는 클라이언트(310)로부터 전달된 EDI 정보를 포함한 HTTP 요청을 지정된 채널로 매핑하고 해당 워커노드에 전달한다. 위의 예에서 코디네이터(1100)는 URL 정보를 포함한 HTTP 요청으로 채널의 등록을 조회하고 관리하는 예를 개시하였다. 코디네이터(1100)는 HTTP 요청을 채널 서비스로 변경하고 채널 서비스를 수신할 수 있는 해당 워커노드(1300)의 에이전트 어댑터(1350)로 전달한다.
에이전트 어댑터(1350)는 채널 서비스를 통해 요청된 EDI 정보를 애플리케이션 서비스 매니저(2100)의 메시지 박스(2110)로 전달한다.
애플리케이션 서비스 매니저(2100)의 메시지 박스(2110)는 에이전트 어댑터(1350)로부터 전달된 EDI 정보를 클라이언트 인박스(2111)에 저장할 수 있다.
애플리케이션 서비스 매니저(2100)의 메시지 박스(2110)는 워커노드(1300)의 통합 패키지(integration package)(1380)로 요청된 EDI 정보를 전달한다.
여기서 통합 패키지(integration package)(1380)는 개발 아이템이 통합된 프로그램의 묶음으로써, 여러 가지 개발 플로우(flow)들, 자바 또는 스크립트 프로그램들을 포함한다. 통합 패키지(integration package)(1380)는 이러한 개발 아이템을 조합하여 사용하도록 허용하고 통합적인 요구사항을 해결하도록 할 수 있다.
통합 패키지(integration package)(1380)는 메시지 박스(2110), 워커노드의 어댑터들(1350, 1370, 1390) 및 코디네이터의 채널 서비스과 정보를 교환하여 클라이언트(310)와 파트너(320)가 거래할 수 있는 여러 가지 요구사항을 구현하도록 할 수 있다.
통합 패키지(integration package)(1380)는 분산된 채널 서비스에 따라 특정 채널이 호출된 경우 패키지내 필요한 정보 교환을 위한 라우팅을 생성 및 등록할 수 있어 사용자의 요구 사항을 해결할 수 있다.
통합 패키지(integration package)(1380)에 대한 요소와 활용 예는 이하에서 상세히 개시한다.
통합 패키지(integration package)(1380)는 메시지 박스(2110)의 클라이언트 인박스(2111)에 저장된 EDI 정보를 매핑 어댑터(1370)에 전달할 수 있다.
매핑 어댑터(1370)는 통합 패키지(integration package)(1380)로부터 전달받은 클라이언트(310)의 EDI 정보를 언마샬링(unmarshalling)하고 이를 파트너(320)가 필요한 정보로 매핑한 EDI 변환 데이터로 출력한다.
통합 패키지(integration package)(1380)가 매핑 어댑터(1370)가 출력한 EDI 변환 데이터를 수신하면 메시지 박스(2110)의 파트너 아웃박스(2113)에 전송하여 저장하고, 이를 EDI 어댑터(1390)로 전달할 수 있다.
EDI 어댑터(1390)는 통합 패키지(integration package)(1380)로부터 출력되거나 파트너 아웃박스(2113)에 저장된 EDI 변환 데이터를, 표준화된 형식, 예를 들면 UN/EDIFACT나 ANSXI X.12 등의 형식으로 변환할 수 있다.
EDI 어댑터(1390)는 표준화된 EDI 변환 데이터를 메시지 박스(2110)의 파트너 아웃박스(2113)에 전송하여 저장할 수도 있다.
코디네이터(1100)는 메시지 박스(2110)의 파트너 아웃박스(2113)에 저장되거나 EDI 어댑터(1390)가 변환한 표준화된 EDI 변환 데이터를 채널 서비스를 통해 수신하고, 이를 파트너(320)에 HTTP 트래픽으로 변환하여 전송할 수 있다.
결과적으로 파트너(320)는 클라이언트(310)가 전달한 EDI 정보를 표준화된 EDI 변환 데이터로를 수신할 수 있다. 파트너(320)가 클라이언트(310)에 자신의 EDI 정보를 전달하는 경우에도 유사한 프로세스에 따라 데이터를 전달할 수 있다.
따라서, 클라이언트(310)와 파트너(320)는 개시하는 실시 예에 따라 EDI 서비스와 같은 애플리케이션 서비스를 쉽게 이용할 수 있고, 표준화된 형식을 모르거나 거래 상대방이 요청하는 문서와 정보를 정확하게 이해하지 못하더라도 표준화된 형식에 따라 용이하게 거래를 진행할 수 있다.
클라이언트(310) 또는 파트너(320)는 자신의 워크스페이스에서 여러 소프트웨어 패키지들을 개발하거나 이용할 수 있고, 이를 통합 패키지(1380)에 연계시킬 수도 있다.
실시 예는 이러한 패키지의 개발과 기존 패키지와의 연결도 매우 쉬운 인터페이스를 통해 제공할 수 있고, 개발된 패키지도 판매, 공유, 별도 제공할 수도 있다.
도 12는 개시한 애플리케이션 서비스 제공하는 예에 따른 플랫폼의 인터페이스의 일 예를 도시한 도면이다.
이 도면은 사용자가 애플리케이션 서비스를 제공하는 예에 따른 플랫폼을 접속한 경우 플랫폼이 제공하는 인터페이스를 예시한다.
클라이언트가 개시하는 시스템에 접속하는 경우, 플랫폼은 사용자 전용의 워크스페이스와 관련된 사용자 인터페이스 메뉴를 제공할 수 있다.
클라이언트는, 이 도면에서 예시한 바와 같이 매니저 시스템이 제공하는 인터페이스 플랫폼을 통해 인스턴스 시스템을 이용하거나 또는 URL 등을 포함하는 HTTP를 이용해서 인스턴스 시스템에 접속할 수 있다.
이 도면의 예에서 매니저 시스템이 제공하는 인터페이스 플랫폼은 사용자 전용 워크스페이스(workspace)(151), 메시지 박스(Message box)(152), 파일 전송(File transfer)(153), 이동단말기로 전송한 메시지(SMS)(154), 및 정보 교환이 EDI와 관련된 경우 해당 표준 매핑에 대한 정보(155)에 대한 옵션을 제공할 수 있다.
워크스페이스(workspace)(151)는 클라이언트가 자신의 워크스페이스를 이용할 수 있는 메뉴이고, 메시지 박스(Message box)(152)는 클라이언트와 관련된 메시지를 저장한다.
파일 전송(File transfer)(153)은 인스턴스 시스템을 통해 송수신된 파일 전송 방식 또는 히스토리를 확인할 수 있다.
사용자는 자신이 사용하거나 개발한 패키지(161) 또는 구매한 패키지(162) 등을 사용자 인터페이스 메뉴를 선택하여 확인할 수 있다.
도 13은 개시한 애플리케이션 서비스 제공하는 예에 따른 플랫폼의 인터페이스의 다른 일 예를 도시한 도면이다.
이 도면은 클라이언트가 개시한 애플리케이션 서비스를 제공하는 예에 따른 플랫폼을 접속하고 자신의 워크스페이스를 선택한 경우 볼 수 있는 사용자 인터페이스 메뉴를 예시한다.
클라이언트는 자신이 생성한 워크스페이스(171), 그 워크스페이스와 관련된 인스턴스 시스템(172), 워크스페이스별 생성일자(173), 워크스페이스의 설명 정보(174), 워크스페이스의 활성화 여부(175), 워크스페이스와 관련된 서비스(176) 와 패키지(177) 등을 확인하고 이용할 수 있다.
이하에서는 애플리케이션이 서로 다른 시스템을 연결하는 애플리케이션일 경우 서로 다른 시스템과 연동이 가능한 애플리케이션을 제공할 수 있는 실시 예를 개시한다. 실시 예의 워크스페이스를 통해 개발된 소프트웨어 또는 애플리케이션을 여러 클라이언트에 공유되어 사용될 수 있다. 만약 클라이언트 또는 파트너가 사용하는 시스템이 서로 다른 경우 클라이언트(또는 파트너)가 개발한 애플리케이션은 파트너(또는 클라이언트)의 시스템에서 사용 가능해야 한다.
실시 예에 따른 인스턴스 시스템은 이러한 서로 다른 시스템을 통합할 수 있는 프레임워크를 제공할 하늘 수 있는데 그 실시 예를 개시하면 다음과 같다.
도 14는 실시 예에 따른 애플리케이션 서비스 제공 장치가 서로 다른 시스템을 통합할 수 있는 프레임워크를 제공하는 예를 개시한 도면이다.
실시 예에 따른 애플리케이션 서비스 제공 장치는 서로 다른 시스템에서 실행 가능한 애플리케이션을 제공하는 프레임워크를 포함할 수 있다. 따라서 이러한 통합 프레임워크는 서로 다른 시스템의 사용자들이 서로 연결할 수 있는 애플리케이션을 제공할 수 있어 위에서 예시한 EDI 서비스 등을 제공하는데 효율적이고 이상적이다.
이 도면은 서로 다른 시스템들을 통합할 수 있는 프레임워크로서 통합 시스템 아키텍처를 예시한다. 실시 예의 프레임워크가 제공하는 통합 시스템 아키텍처는 하나 이상의 라우트 엔진을 포함한다.
라우트 엔진은 서로 다른 시스템인 엔드포인트들과 엔드포인트들 사이에 수행되는 일(task)인 프로세서를 연결하는하여 라우트를 제공한다.
라우트는 시스템 간의 연동 인터페이스를 설명할 수 있으며 이 예에서 라우트 엔진은 라우트 1, 2, …, N을 제공하는 예를 개시하였다.
프로세서는 송수신 시스템들, 즉 엔드포인트들 사이에 수행되어야 하는 데이터처리를 의미하는데, 이 예에서는 라우터 프로세서와 메시지 필터 프로세서를 예시하였다.
컴포넌트는 연동하고자 하는 송수신 시스템의 어댑터를 의미하는데, 이 예에서 통합 시스템 아키텍처는 파일, JMS, HTTP 등의 컴포넌트들을 이용하여 엔드포인트에 대한 통일적인 인터페이스 제공하여 서로 다른 시스템을 연결하는 예를 개시한다.
컴포넌트로부터 데이터를 가져오거나 수신받거나(또는 호출받거나)는 것을 컨슈머(consumer)라고 하고, 컴포넌트로부터 데이터를 호출하거나, 전송 또는 조회하는 것을 프로듀서(producer)라고 한다.
메시지(message)는 시스템의 통신을 위해 주고받는 데이터로서 메시지는 본문(body), 헤더(header) 및 첨부(attachments)를 포함할 수 있다.
익스체인지(exchange)는 시스템 간 주고받는 메시지를 담는 컨테이너로서, 라우트의 흐름(flow) 시작 시에 생성되어 흐름 종료 시 까지만 라이프 사이클이 유지되는 객체이다.
이와 같은 통합 시스템 아키텍처를 이용하면 서로 다른 시스템에 사용될 수 있는 애플리케이션들을 생성하고 통합 패키지(integration package)로 개발할 수 있다. 이러한 예로서 위의 예에서 통합 패키지(integration package)(1380)를 예시한 바 있다.
통합 시스템 아키텍처를 기반으로 개발된 통합 패키지(integration package)는, 실시 예에 따른 플랫폼이 제공하는 서비스나 어댑터 패키지와 연계하여 통합 요구사항을 해결할 수 있는 통합 플로우(integration flow)를 제공할 수 있다.
통합 패키지(integration package)는 통합 시스템 아키텍처의 플로우 내 필요한 프로세스를 구현하고, 여러 가지 데이터 변환이 가능한 스크립트(script)나 자바(java) 프로그램을 제공할 수 있다.
클라이언트(또는 파트너)는 실시 예에 따른 플랫폼을 기반으로 위에서 예시한 통합 시스템 아키텍처를 이용하여 자신의 서비스 제공에 필요한 통합 패키지들을 생성할 수 있다.
실시 예에 따른 플랫폼은, 클라이언트(또는 파트너)가 통합 플로우를 구현하는 통합 패키지를 그래픽 기반의 코딩으로 아주 쉽게 개발할 수 있는 환경도 제공할 수 있다.
이하에서는 실시 예에 따른 플랫폼의 통합 시스템 아키텍처가 제공하는 통합 패키지(integration package)로서 통합 플로우(integration flow)를 개발할 수 있는 환경을 예시한다.
애플리케이션 서비스 제공하는 장치의 실시 예에 따른 플랫폼은 라이브러리를 이용하여 그래픽 기반의 개발 환경을 제공할 수 있다.
클라이언트(또는 파트너)는 실시 예를 이용하여 그래픽 기반의 통합 플로우(integration flow)를 개발할 수 있는데 통합 플로우(integration flow)는 크게 5개의 기능을 포함할 수 있다.
여기서 통합 플로우(integration flow)가 포함하는 5개의 기능을 커넥터(connector), 서비스(service), 프로세서(processor), 컨트롤 플로우(control flow), 모디파이어(modifier)라고 호칭한다. 이러한 명칭은 예시적인 것이며 각 기능을 상세하게 설명하면 다음과 같다.
도 15는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 커넥터를 그래픽 기반으로 코딩하는 예를 나타낸 것이다.
커넥터(connector)는 위에서 예시한 통합 시스템 아키텍처의 라우트의 시작을 정의하는를 나타내는 From 그래픽 요소를 포함할 수 있다.
커넥터(connector)는 서비스 또는 어댑터 등의 호출, 데이터의 저장 등, 개발 환경에서 개발되는 플로우가 구현될 경우, 외부로의 동작을 정의하는 To 그래픽 요소를 포함할 수 있다.
이 도면에서 예시하는 바와 같이 실시 예가 제공하는 그래픽 기반의 개발 환경에서 라우트의 입출력(From/To)을 그래픽 코딩으로 표현할 수 있는 커넥터(connector)를 이용하여 통합 플로우(integration flow)를 개발할 수 있다.
커넥터(connector)를 조금 더 상세하게 설명하면, 커넥터는 컨슈머(consumer)로서 특정 데이터를 호출(From Connector)하고, 프로듀서(producer)로서 플로우를 통해 처리한 데이터를 통합 플로우(integration flow) 외부에 제공(To Connector)할 수 있다.
컨슈머(consumer)는, 통합 플로우가 특정 데이터를 호출(From Connector)하는 경우로서 애플리케이션 패키지 내 라우트(route)를 호출하는 다이렉트(direct), 작업 스케줄러에 의해 주기적으로 데이터를 호출하는 타이머(timer)가 있을 수 있다.
또한 통합 플로우가 특정 데이터를 호출(From Connector)하는 다른 경우로서, 라우트를 채널로 등록하고 채널이 호출되면 라우트를 시작하는 채널(channel), 주기적으로 미처리된 메시지를 확인하고 미처리된 메시지가 있는 경우 라우트를 시작하는 메시지박스(message box), 또는 등록된 FTP 서비스 경로에 문서가 있는지 확인하고 문서가 존재할 경우 라우트를 시작하는 에프티피(FTP)가 있을 수 있다.
이러한 컨슈머(consumer)는 통합 패키지 내 라우트 식별자(Route ID), 패키지 설치 시점에 라우트의 시작 여부를 나타내는 오토스타트(Auto Start), 패키지 설치 해당 라우트의 시작 순서를 나타내는 스타트 오더(Start Order) 등의 옵션을 포함할 수 있다.
프로듀서(producer)는, 통합 플로우의 수행 결과로써 커넥터의 외부 출력 동작(To connector)을 의미한다. 프로듀서(producer)의 종류로서 동일한 애플리케이션 패키지 내 다른 다이렉트 라우트를 호출하는 것을 의미하는 다이렉트(direct), 메시지 박스에 문서를 저장하는 것을 의미하는 메시지 박스(message box)이 있을 수 있다. 또한, 프로듀서(producer)로서 워크스페이스 내에 다른 채널을 호출하는 것을 의미하는 채널(channel), 또는 등록된 FTP 서비스로 문서를 전송하는 것을 의미하는 에프티피(FTP)가 있을 수 있다.
따라서 이 도면의 예시와 같이 그래픽 코딩으로 라우트의 입출력(From connector/To connector) 코딩 요소를 포함하는 커넥터(connector)를 이용하여 통합 플로우(integration flow)를 개발할 수 있다.
도 16는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 서비스를 그래픽 기반으로 코딩하는 예를 나타낸 것이다.
실시 예에 따라 그래픽 기반으로 개발될 수 있는 통합 플로우(integration flow)는 서비스 블록을 이용하여 시각적인 인터페이스를 기반으로 코딩될 수 있다.
이 도면의 예에서 서비스 블록은, 그래픽으로 제공되는 getNextControlNumber 요소, isDuplicatedControlNumber 요소, putUsingConrolNumber 요소, remoteCache 요소 등을 포함할 수 있다.
getNextControlNumber 요소는 새로운 컨트롤 넘버를 발급받는 것을 의미하고 isDuplicatedControlNumber 요소는 컨트롤넘버의 중복 여부 확인하는 요소이다.
이 도면에서 컨트롤넘버가 중복되는 경우(True)와 중복되지 않는 경우(False)를 같이 정의할 수 있다.
통합 플로우를 개발하는 데 있어서 서비스 블록 중, putUsingConrolNumber 요소는 사용된 컨트롤 넘버를 스토리지에 저장하여 중복여부 확인에 사용하고, remoteCache 요소는 워크스페이스의 캐시서비스에 접근하는 것을 예시한다.
따라서 이 도면의 예시와 같은 서비스 블록을 이용하여 통합 플로우(integration flow)를 그래픽 기반으로 코딩할 수 있다.
도 17는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 프로세서를 그래픽 기반으로 코딩하는 예를 나타낸 것이다.
실시 예에 따라 그래픽 기반으로 개발될 수 있는 통합 플로우(integration flow)는 프로세서 블록을 이용하여 시각적인 인터페이스를 기반으로 코딩될 수 있다.
이 도면의 예에서 프로세서 블록은 그래픽으로 제공되는 log 요소, process 요소, xslt 요소, groovy 요소 및 delay 요소 등을 포함할 수 있다.
log 요소는 플로우 실행 시에 필요한 사항을 패키지 로그에 남기도록 하는 것으로 패키지 로그는 패키지의 실행 상태를 모니터링하는 어댑터에서 확인할 수 있다.
process 요소는 업로드한 자바(Jar) 패키지 아이템에 등록된 Bean의 메소드를 호출하여 커스텀(custom) 처리를 수행할 수 있도록 한다.
xslt 요소는 XSLT 패키지아이템을 선택하여 XSLT 변환을 수행하도록 할 수 있다.
groovy 요소는 Groovy 패키지 아이템을 선택하여 스크립트를 호출할 수 있도록 할 수 있다.
delay 요소는 플로우의 라우트를 잠시 지연시키도록 할 수 있다.
따라서 이 도면의 예시와 같은 프로세서 블록을 이용하여 통합 플로우(integration flow)를 그래픽 기반으로 코딩할 수 있다.
도 18는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 컨트롤 플로우(Control flow)를 그래픽 기반으로 코딩하는 예를 나타낸 것이다.
실시 예에 따라 그래픽 기반으로 개발될 수 있는 통합 플로우(integration flow)는 컨트롤 플로우(Control flow) 블록을 이용하여 시각적인 인터페이스를 기반으로 코딩될 수 있다.
이 도면의 예에서 컨트롤 플로우(Control flow) 블록은 그래픽으로 제공되는 split 요소, for 요소, while 요소, xslt 요소, If 또는 Switch-Case 요소 및 Try-Catch 요소 등을 포함할 수 있다.
split 요소는 플로우 실행 시에 필요한 사항을 패키지 로그에 남기도록 하는 것으로 패키지 로그는 패키지의 실행 상태를 모니터링하는 어댑터에서 확인할 수 있다. split 요소는 하나의 통합된 문서(Exchange)를 여러 Exchange로 분할해서 처리할 수 있는 기능으로서, Delimiter, Xpath, Bean 방식을 지원할 수 있다.
for 요소는 메시지를 여러 번 처리할 경우 사용하는 것으로서, 각 반복마다 다른 방식으로 처리할 수 있는 기능을 제공한다.
While 요소는 Simple 표현식이 false 또는 null로 평가될 때까지 루프하는 while 루프를 활성화하는 기능을 제공한다.
If 또는 Switch-Case 요소는 메시지 교환의 컨텐츠를 기반으로 메시지를 올바른 대상으로 라우팅할 수 있도록 하는 기능을 제공한다.
Try-Catch 요소는 Java의 Try-Catch와 동일한 예외처리 기능을 지원할 수 있다.
따라서 예시한 컨트롤 플로우(Control flow) 블록을 이용하여 통합 플로우(integration flow)를 그래픽 기반으로 코딩할 수 있다.
도 19는 실시 예를 기반으로 통합 플로우(integration flow)를 개발할 경우 통합 플로우(integration flow)기능 중 모더파이어모디파이어(modifier)를 그래픽 기반으로 코딩하는 예를 나타낸 것이다.
실시 예에 따라 그래픽 기반으로 개발될 수 있는 통합 플로우(integration flow)는 모더파이어모디파이어(modifier)블록을 이용하여 시각적인 인터페이스를 기반으로 코딩될 수 있다.
이 도면의 예에서 모더파이어모디파이어(modifier) 블록은 그래픽으로 제공되는 loadProperty 요소, setProperty 요소, setHeader 요소, setBody 요소, removerHeader 요소 및 removeProperty 요소 등을 포함할 수 있다.
loadProperty 요소는 설정 저장소에서 설정 노드를 가져와 Exchange Property에 저장하는 기능을 제공한다.
setProperty 요소는 Exchange Property에 값을 지정하는 기능을 제공할 수 있다
setHeader 요소는 Exchange Message Header에 값을 지정하는 기능을 제공할 수 있다.
setBody 요소는 Exchange Message Body에 값을 지정하는 기능을 제공할 수 있다.
removerHeader 요소는 Exchange Message Header에서 값을 제거하는 기능을 제공할 수 있다.
removeProperty 요소는 Exchange Property에서 값을 제거하는 기능을 제공할 수 있다.
예시한 모더파이어모디파이어(modifier) 블록을 이용하여 통합 플로우(integration flow)를 그래픽 기반으로 코딩할 수 있다.
이하에서는 위에서 개시한 실시 예에 따라 클라이언트 등의 사용자를 구분하고 각 워크스페이스를 격리할 수 있는 일 예를 개시한다.
워크스페이스를 이용하는 클라이언트에 제공되는 소프트웨어 패키지가 동일한 경우 클라이언트마다 동일한 소프트웨어 이미지가 실행된다면, 각각의 클라이언트들에 대해 모든 버전과 종류들의 소프트웨어 패키지들이 준비되고 제공되어야 한다.
그러나 아래 개시하는 실시 예에 따르면, 동일한 소프트웨어 패키지를 이용하여 애플리케이션 서비스를 제공하더라도, 자원을 효율적으로 이용하고 클라이언트가 이용하는 워크스페이스 별로 격리된 서비스를 제공할 수 있다.
상세한 예를 개시하면 다음과 같다.
도 20은 실시 예에 따라 클라이언트에 따라 격리된 고유의 워크스페이스를 제공하는 일 예를 개시한 도면이다.
도시한 예에서 인스턴스 시스템(1000)은 코디네이터(미도시)와 하나 이상의 워커노드를 포함할 수 있는데, 이 예에서는 다수의 워커노드들(Node #1, Node #2, Node #3, Node #N)을 예시하였다.
실시 예에 따른 코디네이터(미도시)는, 사용자가 접속한 경우 사용자 인증을 통해 접속을 허용하고 사용자에 따라 각각의 워크스페이스를 제공할 수 있다.
이 예에서 클라이언트 1(110), 클라이언트 2(120), 클라이언트 3(130)이 실시 예에 따른 인스턴스 시스템(1000)을 접속한다고 가정한다.
매니저 시스템(미도시)은 인스턴스 시스템(1000)의 코디네이터 및 워커노드들(Node #1, Node #2, Node #3, Node #N)을 관리할 수 있다.
인스턴스 시스템(1000)은 코디네이터(미도시)를 통해 클라이언트들(110, 120, 130)이 각각 접속한 경우, 사용자에 따라 서로 격리되는 워크스페이스들(1510, 1520, 1530)을 각각 제공하도록 할 수 있다.
이 예에서 클라이언트 1(110)은 워크스페이스 A(1510), 클라이언트 2(120)는 워크스페이스 B(1520), 클라이언트 3은 워크스페이스 C(1530)를 각각 할당 받아 사용할 수 있다.
클라이언트 1(110)가 인스턴스 시스템(1000) 상에 워크스페이스 A(1510)를 할당 받은 경우, 워커노드 1(Node #1)는 워크스페이스 A(1510)에 고유한 워크스페이스 번들(bundle)인 패키지 E를 제공할 수 있다.
여기서, 워크스페이스 번들(bundle)은 소프트웨어 패키지로서 상세한 메타데이터를 포함한 확장 가능한 소프트웨어 프로그램들의 그룹을 나타낸다.
이 때 워커노드 1(Node #1)는 클라이언트 1(110)의 요청에 따라 워크스페이스 A(1510)에 의존(dependency)하는 또는 워크스페이스 A(1510)에 고유한 워크스페이스 번들(bundle)로서 소프트웨어 패키지 E를 제공할 수 있다.
여기서 소프트웨어 패키지가 워크스페이스 A(1510)에 의존(dependency)한다는 의미는, 워커노드(Node #1)의 프레임워크에 의해 제공되는 소프트웨어 패키지 E가 워크스페이스 A(1510)와 관련된 인증 정보를 포함한다는 것을 의미한다.
즉, 워커노드 1(Node #1)의 프레임워크가, 고유한 워크스페이스 번들(bundle)로서 워크스페이스 A(1510)와 관련된 인증 정보를 포함한 소프트웨어 번들(bundle)인 패키지 E를, 워크스페이스 A(1510)에 제공한다.
유사하게, 워커노드 2(Node #2)의 프레임워크가 클라이언트 2(120)의 요청에 따라 고유한 워크스페이스 B(1520)의 번들(bundle)로서, 워크스페이스 B(1520)와 관련된 인증 정보를 포함한 소프트웨어 번들(bundle)인 패키지 E를, 워크스페이스 B(1520)에 제공한다.
마찬가지로, 워커노드 3(Node #3)의 프레임워크가 클라이언트 3(130)의 요청에 따라 워크스페이스 C(1530)와 관련된 인증 정보를 포함한 고유한 소프트웨어 번들(bundle)인 패키지 E를, 워크스페이스 C(1530)에 제공한다.
여기서 각각의 워커노드들((Node #1, Node #2, 및 Node #3)은 동일한 소프트웨어 패키지 E를 제공하지만, 각각의 워크스페이스들(1510, 1520, 1530)별로 고유한 인증 정보를 포함한 소프트웨어 패키지 E를 제공한다.
따라서, 워크스페이스들(1510, 1520, 1530)별로 동일한 소프트웨어 패키지 E와 서로 다른 고유의 인증 정보가 결합된 이미지가 제공되므로, 클라이언트들(110, 120, 130)은 자신의 워크스페이스들에 각각 격리되는 효과가 발생할 수 있다.
이와 같이 이 예에서는, 워커노드 1(Node #1)의 프레임워크는 워크스페이스 A의 식별 정보가 포함된 패키지 E와 별개의 패키지 F를 워크스페이스 A(1510)에 제공하고, 워커노드 2(Node #2)의 프레임워크는 워크스페이스 B의 식별 정보가 포함된 패키지 E와 별개의 패키지 G를 워크스페이스 B(1520)에 제공한다. 마찬가지로 워커노드 3(Node #3)의 프레임워크는 워크스페이스 C의 식별 정보가 포함된 패키지 E와 별개의 패키지 H를 워크스페이스 C(1530)에 제공한다.
각 워크스페이스의 식별 정보는 각 워크스페이스를 인증하는 정보로서 사용될 수 있는데 인증 정보의 일 예로서 RSA (Rivest-Shamir-Adleman)암호화 알고리즘 기반의 부인방지 토큰(Non-Repudiation Token) 등이 사용될 수 있다.
따라서, 각 클라이언트가 각 워크스페이스를 통해 애플리케이션 서비스를 제공받는 경우, 인스턴스 시스템은 워크스페이스 별로 제공되는 애플리케이션 서비스를 각 워크스페이스의 인증 정보를 기반으로 검증함으로써, 각 클라이언트는 애플리케이션 서비스에 대한 권한을 인증할 수 있다.
따라서, 각 워크스페이스를 통해 소프트웨어 번들에 따른 애플리케이션 서비스가 제공될 경우 각 워크스페이스에 유니크(unique)한 소프트웨어 번들이 설치되고, 그에 따라 제공되는 서비스와 실행 영역은 격리될 수 있다.
워커노드들(Node #1 내지 Node #N)은 워크스페이스들로부터 소프트웨어 패키지가 요청될 경우, 각각의 워크스페이스들에 고유한 인증 정보를 기반으로 요청된 애플리케이션의 다운로드 또는 실행을 승인하거나 거부할 수 있다.
한편, 워커노드들(Node #1 내지 Node #N)의 프레임워크의 실시 예로서 OSGi와 같은 자바 프레임워크가 이용될 수 있다. OSGi는 일종의 자바 프레임워크로서 실행 환경에서 자바 컴포넌트들과 메타데이터가 포함된 소프트웨어 번들을 제공할 수 있다. 이 경우 워커노드들(Node #1 내지 Node #N)은 OSGi 프레임워크를 제공할 수 있다.
도 21은 실시 예에 따라 격리된 워크스페이스로부터 클라이언트에 패키지를 제공하는 일 예를 개시한 흐름도이다.
워크스페이스를 이용하는 클라이언트(또는 파트너)로부터 애플리케이션 패키지에 대한 요청을 수신한다(S110).
매니저 시스템은 인스턴스 시스템을 관리하여 애플리케이션 패키지에 대한 서비스를 제공할 수 있다.
인스턴스 시스템은 코디네이터와 워커노드들을 기반으로 각 클라이언트(또는 파트너)에 워크스페이스를 제공할 수 있다.
각 클라이언트(또는 파트너)의 워크스페이스는 격리될 수 있고, 클라이언트(또는 파트너)는 격리된 워크스페이스를 통해 애플리케이션 패키지에 대한 서비스 요청을 인스턴스 시스템에 요청할 수 있다.
상기 워크스페이스와 관련된 소프트웨어 번들에 포함된 인증 정보를 기반으로 상기 요청한 애플리케이션 패키지의 인증을 수행한다(S120).
인스턴스 시스템 내의 워크스페이스를 제공하는 워커노드가 그 워크스페이스에 소프트웨어 번들을 설치할 경우, 그 워크스페이스에 고유한 인증 정보를 포함하는 소프트웨어 번들을 설치할 수 있다.
여기서 인증 정보는 다른 애플리케이션 패키지 서비스를 사용할 수 있는 인증을 제공할 수 있다. 예를 들어 인증 정보로서, RSA (Rivest-Shamir-Adleman) 암호화 알고리즘 기반의 부인방지 토큰(Non-Repudiation Token) 등이 사용될 수 있다.
따라서 워커노드가 제공하는 워크스페이스들에 동일한 소프트웨어 번들이 설치되는 경우라도, 워크스페이스마다 다른 인증 정보를 포함할 수 있다. 이를 이용해 소프트웨어 번들은 그 번들이 설치되는 워크스페이스에 의존성(dependency)를 가질 수 있다.
그리고 워크스페이스의 인증 정보를 인증 키(key)로 이용하여 요청된 서비스의 애플리케이션 패키지에 대한 인증을 수행할 수 있다.
인증 정보를 제외한 동일한 소프트웨어 번들이 실시될 수 있는 워크스페이스를 제공하여 워크스페이스들은 서로 격리시킬 수 있다. 즉, 동일한 소프트웨어가 워크스페이스에서 실행되는 경우라도 다른 인증 정보를 포함하므로 워크스페이스들은 서로 격리될 수 있다.
상기 인증 수행 결과에 따라 상기 수신한 애플리케이션 패키지에 대한 서비스 요청을 승인하거나 거부한다(S130).
워커노드가 워크스페이스로부터 요청된 애플리케이션 패키지를 제공하는 경우, 상기 워크스페이스에 설치된 소프트웨어 번들의 인증 정보는 상기 워크스페이스에 대한 인증 정보로 사용될 수 있다. 이러한 워크스페이스를 제공할 수 있는 프레임워크의 일 예로서 OSGi 프레임워크 등을 예시하였다.
따라서, 워커노드는 각 워크스페이스에 설치된 소프트웨어 번들의 인증 정보를 기반으로, 상기 워크스페이스가 인증된 경우에만 요청된 애플리케이션 패키지를 상기 워크스페이스에 제공할 수 있다.
워커노드는, 워크스페이스에 설치된 소프트웨어 번들의 인증 정보가 일치하지 않는 경우, 해당 워크스페이스에 요청된 애플리케이션 패키지 서비스에 대한 제공을 거부한다.
위에서 개시한 실시 예에 따른 애플리케이션 서비스 제공 장치를 매니저 시스템과 인스턴스 시스템을 포함할 수 있다.
인스턴스 시스템은 코디네이터와 워커노드를 포함하는 적어도 하나의 서버로서, 상기 서버는 데이터를 저장하는 저장매체와 프로세서를 포함할 수 있다.
이때 서버의 프로세서는, 클라이언트로부터 애플리케이션 패키지에 대한 서비스 요청을 수신하고, 워크스페이스와 관련된 소프트웨어 번들에 포함된 인증 정보를 기반으로 상기 요청한 애플리케이션 패키지의 인증을 수행할 수 있다. 그리고, 인스턴스 시스템의 프로세서는 인증 수행 결과에 따라 상기 수신한 애플리케이션 패키지에 대한 서비스 요청을 승인하거나 거부하는, 연산들을 수행할 수 있다.
만약 위와 같은 실시 예가 인스턴스 시스템 기반의 프로그램으로 수행될 경우, 그 프로그램은 워크스페이스를 이용하는 클라이언트로부터 애플리케이션 패키지에 대한 서비스 요청을 수신할 수 있다. 그리고 컴퓨터로 실행 가능한 프로그램은, 워크스페이스와 관련된 소프트웨어 번들에 포함된 인증 정보를 기반으로 상기 요청한 애플리케이션 패키지의 인증을 수행하고, 인증 수행 결과에 따라 상기 수신한 애플리케이션 패키지에 대한 서비스 요청을 승인하거나 거부할 수 있다.
워크스페이스를 이용하는 클라이언트(파트너)에 제공되는 소프트웨어 패키지가 동일하더라도 클라이언트(파트너)마다 다른 소프트웨어 이미지가 실행된다면, 한 클라이언트(파트너)에 대해 모든 버전과 종류의 소프트웨어 패키지들을 준비하여 제공하여야 한다.
그러나 개시한 실시 예와 같이 클라이언트마다 고유한 인증 정보를 포함한 소프트웨어 번들이 실행되는 워크스페이스를 제공하는 프레임워크를 이용하면, 워크스페이스를 서로 격리할 수 있고, 동일한 소프트웨어 패키지를 이용해 애플리케이션 서비스를 제공할 수 있어 컴퓨팅 자원을 효율적으로 운영할 수 있다.
위에서 클라이언트 또는 파트너가 매니저 시스템이 제공하는 플랫폼을 기반으로 관련 정보를 송수신할 수 있는 채널을 이용하는 예를 개시하였다.
이하에서는 위와 같은 클라이언트와 파트너가 정보 보안을 유지하면서 데이터를 송수신할 수 있는 실시 예를 개시한다. 위에서 클라이언트 또는 파트너 내에 에이전트와 인스턴스 시스템이 제공하는 플랫폼 내의 에이전트 어댑터가 서로 정보를 송수신하는 예를 개시하였다.
이와 같이 클라이언트 또는 파트너 내에 에이전트를 설치하지 않고 접근하면 클라이언트 또는 파트너의 시스템에 보안 문제를 발생시킬 수 있다. 이런 문제를 회피하기 위해 클라이언트 또는 파트너는 에이전트를 설치할 수 있다. 또한 매니저 시스템은 클라이언트 또는 파트너 내에 설치된 에이전트를 이용하여 패치 또는 업그레이드를 용이하게 수행할 수 있다.
또한 에이전트 어댑터는 데이터 송수신을 위한 프로토콜 변환이나 데이터 변환을 수행할 수 있어서 에이전트로부터 전달되는 채널 또는 데이터 송수신을 위한 프로토콜을 변환해 통신을 원활히 하도록 할 수 있다.
에이전트는 설치된 클라이언트 또는 파트너 시스템에 대한 접속 정보 등을 관리할 수 있다. 이 경우 에이전트는 클라이언트 또는 파트너 시스템에 자원 접근에 대한 연결 정보를 설정할 수 있다. 예를 들어 에이전트는 설치된 시스템의 데이터베이스, 파일 시스템, 사용자 정보나 자원 접속 또는 관리 정보를 설정할 수 있다. 그리고 설정된 주기나 조건에 따라 에이전트 어댑터로부터 정보를 폴링(polling)할 수 있다.
인스턴스 시스템이 제공하는 플랫폼 내의 에이전트 어댑터는 애플리케이션 패키지로서 인스턴스 시스템에 설치될 수 있다. 에이전트 어댑터는, 클라이언트 또는 파트너 시스템에 설치된 에이전트가 등록된 경우 설정된 주기나 조건에 따라 등록된 에이전트로부터 정보를 수집 또는 저장하도록 설정할 수 있다.
인스턴스 시스템의 코디네이터는 에이전트와 연결될 수 있는 채널을 설정할 수 있다. 그리고, 에이전트로부터 설정된 채널로 요청을 받으면 코디네이터는 그 채널을 매핑하여 워커 노드의 에이전트 어댑터로 전달할 수 있다.
클라이언트 또는 파트너의 시스템에 설치될 때 에이전트는 여러 가지 설정 정보를 가질 수 있다. 예를 들면, 에이전트 애플리케이션은, 에이전트 관련 설정 정보, 에이전트 실행 관련된 보안 키 정보, 자원 관리 설정 정보, 사용자 관리 정보 등을 포함하는 설정 정보를 가질 수 있다.
인스턴스 시스템의 플랫폼은 클라이언트 또는 파트너는 에이전트 애플리케이션을 다운받아 실행할 수 있는 접속 인터페이스를 제공할 수 있다.
이하에서 에이전트 또는 에이전트 어댑터의 사용자 인터페이스를 예시하고 이를 제어하는 일 예를 설명한다.
도 22는 실시 예에 따른 인스턴스 시스템의 플랫폼에서 제공하는 에이전트가 실행된 경우 에이전트의 인터페이스를 예시한 도면이다.
클라이언트 또는 파트너는, 인스턴스 시스템의 플랫폼이 제공하는 에이전트 애플리케이션을 설치하여 에이전트 애플리케이션을 실행할 수 있다.
이 도면은 에이전트 애플리케이션이 실행되어 관리자 또는 사용자가 에이전트를 실행한 경우 에이전트의 인터페이스를 예시한다.
클라이언트 또는 파트너의 관리자는 에이전트를 통해 현재의 상태를 나타내는 상태 메뉴(2115)를 확인할 수 있다.
관리자는 상태 메뉴(2115)로부터 에이전트 공개 키 정보, 에이전트와 에이전트 어댑터를 동기화시키는 정보, 동기화 오류 시 상태 메시지 등을 확인할 수 있다.
그리고 관리자는 상태 메뉴(2115)로부터 에이전트 어댑터에서 설정한 채널이 자원에 접속되었는지, 그 접속 시간 및 접속 상태에 대한 정보를 얻을 수 있다.
클라이언트 또는 파트너의 관리자는 에이전트를 통해 관리할 수 있는 자신의 자원을 관리할 수 있는 메뉴(2120)를 이용할 수 있다. 이 도면의 예에서 자원관리(2120) 메뉴는 클라이언트 또는 파트너 시스템에 포함되어 관리될 수 있는 자원으로서 여기서는 데이터베이스, 디렉토리, SAP 시스템, 또는 IBM MQ시스템 등을 예시한다. 관리자는 자원관리(2120) 메뉴를 통해 자원을 관리하고 각 자원의 위치 정보 또는 접속 정보와, 접속 경로를 설정할 수 있다.
또한 클라이언트 또는 파트너의 관리자는 에이전트를 통해 에이전트 사용자를 관리할 수 사용자 관리 메뉴(2130)를 이용한다. 관리자는 사용자 관리 메뉴(2130)를 이용하여 에이전트 사용자를 관리하고 각 사용자의 권한을 설정할 수 있다.
도 23은 실시 예에 따른 인스턴스 시스템의 플랫폼에서 제공하는 에이전트 어댑터의 인터페이스의 일 예를 예시한 도면이다.
클라이언트 또는 파트너는, 인스턴스 시스템의 플랫폼이 제공하는 에이전트 어댑터를 이용할 수 있다. 클라이언트 또는 파트너는, 인스턴스 시스템의 플랫폼이 제공하는 에이전트 어댑터에서 예시한 에이전트를 등록할 수 있다.
이 도면은 에이전트 어댑터의 인터페이스를 예시하는데, 이 예에 따라 클라이언트(또는 파트너)는 에이전트 어댑터에 서로 통신할 수 있는 파트너(또는 클라이언트) 시스템에 설치된 에이전트의 식별자(2210), 에이전트의 명칭(2220), 에이전트를 설명할 수 있는 디스크립션(2230) 등을 에이전트 어댑터에 등록할 수 있다.
에이전트 어댑터의 인터페이스는, 에이전트가 수신하는 문서 또는 정보를 저장하는 메시지 박스 슬롯(2240), 에이전트가 송신하는 문서 또는 정보를 저장하는 메시지 박스 슬롯(2250)을 포함할 수 있다.
그리고 에이전트 어댑터의 인터페이스는, 에이전트의 인증을 위한 에이전트 공개 키(2290) 정보를 포함할 수 있다. 여기서는 에이전트 공개 키 정보로서 공개 키의 해쉬 값을 예시하였다.
에이전트 어댑터의 인터페이스는 위와 같이 등록된 에이전트와 연결 또는 동기화를 활성화할 수 있는 수단(2295)를 포함한다. 이 예는 에이전트와 동기화(active)되는 버튼(2295)을 통해 에이전트 어댑터가 에이전트와 정보를 송수신하는 예를 개시하였다.
위와 같이 에이전트 어댑터는 에이전트의 설정 정보를 등록할 수 있고, 에이전트의 설정 정보는 에이전트 어댑터가 설치된 워커노드의 설정 저장소에 저장될 수 있다.
이와 같이 에이전트 어댑터를 이용하여 클라이언트 또는 파트너에 설치된 에이전트 설정 정보를 등록하거나 변경할 수 있다. 에이전트 어댑터를 통해 설정된 에이전트는, 그 에이전트가 설치된 시스템의 자원을 연결하고 인스턴스 시스템과 데이터를 송수신할 수 있다.
설명한 바와 같이, 송신 채널은 파트너 (또는 클라이언트) 시스템의 자원으로부터 어떤 정보를 어떤 주기로 가져와 클라이언트(또는 파트너) 시스템으로 전송하는 채널을 의미한다. 그리고 수신 채널은 클라이언트(또는 파트너) 시스템으로부터 받은 정보를 파트너(또는 클라이언트) 시스템의 설정된 위치에 설정된 형식으로 저장하는 채널을 의미한다.
따라서, 여기에서 송신 채널의 설정은, 클라이언트 또는 파트너의 시스템에 설치된 에이전트로부터 정보나 문서를 가져와 메시지 박스에 저장하는 설정을 의미한다.
그리고 수신 채널의 설정은, 채널 설정을 통해 에이전트 어댑터에 수신된 정보나 문서를 클라이언트 또는 파트너의 시스템의 어떤 위치에 저장하는 설정을 의미한다.
이하에서 채널 설정의 예는 상세하게 예시한다. 에이전트 어댑터는 이와 같이 채널 설정을 통해 정보나 문서의 송수신을 제어할 수 있다.
도 24는 실시 예에 따른 인스턴스 시스템의 플랫폼에서 제공하는 에이전트 어댑터의 인터페이스의 다른 일 예를 예시한 도면이다.
인스턴스 시스템의 노드에 설치되는 에이전트 어댑터에 설정되는 채널의 타입은 다를 수 있고, 에이전트 어댑터에서 송수신 채널에 대해 다른 설정을 할 수 있다. 각 어댑터에서 설정하는 채널의 타입은 에이전트가 관리하는 자원의 타입과 동일할 수 있다.
이 도면은 어떤 에이전트가 관리하는 자원을 예시한다. 이 도면의 예에서 에이전트는 그 에이전트가 설치된 시스템의 데이터베이스, 디렉토리, 해당 시스템 내의 SAP 시스템(SAP JCO), 해당 시스템 내의 IBM 시스템의 (IBM MQ)을 관리한다.
이러한 경우 에이전트 어댑터는, 데이터베이스에 대해서는 그 데이터베이스를 접속할 수 있는 자바 API인 JDBC (Java Database Connectivity)(2310)을 채널 타입으로 설정할 수 있고, 디렉토리에 대해서는 해당 디렉토리에 송수신될 수 있는 파일(FILE)(2320)을 채널 타입으로 설정할 수 있다.
여기서 에이전트 어댑터는 SAP 시스템에 대해서는 자바 커넥터(JCO)(2330)를 채널 타입으로 설정할 수 있고, IBM 시스템에 대해서는 네트워크 소프트웨어인 메시지 큐(MQ)(2340)를 채널의 타입으로 설정할 수 있다.
여기서는 SAP 시스템과 IBM 시스템을 예시하였고 클라이언트 또는 파트너 시스템이 다른 시스템을 포함하는 경우에도 그 시스템과 관련된 채널 타입을 설정할 수 있다.
도 25는 실시 예에 따른 인스턴스 시스템의 플랫폼의 에이전트 어댑터가 송수신 채널을 설정하는 예를 나타낸 도면이다.
이 예는 에이전트 어댑터가 전송하는 송신 채널을 설정하는 예(상단)와 수신 채널을 설정(하단)하는 예를 각각 예시한다.
이 예에서 송신 채널을 설정하는 경우(상단)로서 에이전트 어댑터가 전송하는 에이전트의 식별자(agent ID)는 test-agent, 채널의 식별자(channel ID)는 file-send, 어댑터의 타입은 파일(FILE), 전송 방향(Direction)은 전송(SEND), 어댑터의 버전(adapter version)은 1.0 이라고 가정한다.
에이전트 어댑터는 전송 스케줄(polling schedule)의 단위를 초(second) 또는 크론(cron)로 설정할 수 있고, 어댑터의 타입에 따라 채널을 설정할 수 있다.
도시한 예는, 송신 채널을 위한 파일의 위치 정보인 소스 정보(2410)를 설정할 수 있다. 여기서 소스 정보(2410)로서 디렉토리 명칭(file-send), 파일 명칭 또는 확장자(*.txt), 파일 인코딩 타입(UTP-8) 등을 설정할 수 있다.
그리고 송신 채널로 정보를 전송한 후 처리 모드(processing mode)(2420), 설정된 채널 상에서 변경된 내용이 있는지 체크하는 시간 정보(modification check wait millis) 및 최대 파일 사이즈 정보(2430) 등을 설정할 수 있다.
이 예에서 수신 채널을 설정하는 경우(하단)로서 에이전트 어댑터로부터 수신하는 에이전트의 식별자(agent ID)는 test-agent, 채널의 식별자(channel ID)는 file-recv, 어댑터의 타입은 파일(FILE), 전송 방향(Direction)은 전송(RECV), 어댑터의 버전(adapter version)은 1.0 이라고 가정한다.
이 예는 수신 채널을 통해 수신하는 파일의 위치 정보(file-recv), 파일 명칭 또는 확장자(*.txt), 파일 인코딩 타입(UTP-8) 등(2450)을 설정할 수 있음을 예시한다.
도 26은 실시 예에 따른 인스턴스 시스템의 플랫폼을 이용해 거래 정보인 EDI 데이터를 송신하는 예를 개시한다.
실시 예에 따른 인스턴스 시스템이 제공하는 에이전트 어댑터(1350)는 클라이언트 또는 파트너에 설치된 에이전트(350)의 시스템과 서로 정보를 송수신할 수 있다. 이런 경우 송수신하는 정보는 인스턴스 시스템을 제공하고 관리하는 매니저 시스템의 메세지 박스(2110)에 저장될 수 있다.
실시 예에 따른 인스턴스 시스템의 워커 노드에 설치되는 에이전트 어댑터(1350)는 에이전트 제어부(1351), 송수신 설정부(1352), 송수신 처리부(1353)를 포함할 수 있다.
한편 클라이언트 또는 파트너 시스템에 설치되는 에이전트(350)는 에이전트 제어처리부(351), 송수신설정처리부(353) 및 송수신부(357)을 포함할 수 있다.
일반적으로 에이전트 어댑터(1350)는 소프트웨어 패키지이므로 에이전트 제어부(1351), 송수신 설정부(1352), 송수신 처리부(1353)는 각각 소프트웨어의 논리적인 구성요소일 수 있다. 마찬가지로 에이전트(350) 또한 소프트웨어 패키지이므로 에이전트 제어처리부 (351), 송수신설정처리부(353) 및 송수신부(357)는 각각 소프트웨어의 논리적인 구성요소일 수 있다.
클라이언트 또는 파트너 시스템의 데이터를 EDI 데이터와 같은 거래를 위한 데이터로 송수신하기 위해서, 클라이언트 또는 파트너는 에이전트를 설치하여 내부 시스템과 정보를 통신할 수 있다. 이 예는 클라이언트 또는 파트너 시스템이 내부 시스템으로서 SAP ERP 시스템, RDBMS와 같은 데이터베이스, IBM 시스템의 message queue 메시지 큐 등을 포함하는 경우를 예시하였다.
에이전트 제어부(1351)는 클라이언트 또는 파트너 시스템에 설치된 에이전트(350)를 제어할 수 있다. 예를 들어 에이전트 제어부(1351)는 에이전트(350)를 시작, 종료 또는 업데이트할 수 있다.이 경우 에이전트 제어부(1351)가 에이전트(350)를 직접 요청해 제어하지 않고 에이전트(350)를 제어할 요청 정보만을 갱신하면 에이전트(350)의 에이전트 제어처리부 (351)가 갱신된 요청 정보를 설정된 주기에 따라 가져와 요청 정보에 따른 에이전트 제어를 수행할 수 있다.
에이전트 어댑터(1350)의 송수신설정부(1352)는 에이전트(350)의 송수신 처리 정보를 변경하여 설정하도록 할 수 있다. 이 경우 변경할 송수신 처리 정보는 에이전트(350)로 전송되지 않고 송수신 설정부(1352)에 저장되도록 할 수 있다.
그러면, 에이전트(350)의 송수신설정처리부(353)는 에이전트 어댑터(1350)의 송수신설정부(1352)가 변경한 송수신 처리 정보를 주기적으로 가져와 그 송수신 처리 정보를 파일로 저장할 수 있다. 저장된 송수신 처리 정보는 에이전트(350)가 실행되는 동안에만 유효하다. 만약 에이전트(350)가 재시작되는 경우 에이전트(350)는 에이전트 어댑터(1350)로부터 송수신 처리 정보를 새롭게 가져와 다시 처리할 수 있다. 따라서, 에이전트 어댑터(1350)는 에이전트(350)의 송수신 동작을 원격으로 설정하고 제어할 수 있다.
에이전트(350)의 송수신부(357)은 파일로 저장된 송수신 처리 정보를 이용하여 내부 시스템(여기서는 SAP ERP 시스템, RDBMS 데이터베이스, message queue 메시지 큐)으로부터 정보를 가져와 에이전트 어댑터(1350)의 송수신처리부(1353)로 송신하거나, 에이전트 어댑터(1350)의 송수신처리부(1353)로부터 수신된 정보를 내부 시스템에 변경하여 저장하도록 할 수 있다.
한편 송수신처리부(1353)는 에이전트(350)의 송수신부(357)가 송신한 시스템의 정보를 매니저 시스템 내의 메시지 박스(2110)에 저장하거나, 또는 에이전트 어댑터(1350)에서 설정된 여러 가지 정보를 에이전트(350)의 송수신부(357)가 수신하도록 하고, 그 정보를 메시지 박스(2110)에 저장한다.
이와 같이 인스턴스 시스템에 따른 플랫폼은, 클라이언트 또는 파트너 시스템에 에이전트를 설치하도록 하고, 설치된 에이전트와 플랫폼의 에이전트 어댑터가 통신하도록 하여 클라이언트 또는 파트너의 시스템 데이터를 안정하게 통신하도록 할 수 있다.
또한 에이전트는 인증을 통해 에이전트 어댑터와 통신하고, 에이전트 어댑터는 에이전트의 데이터 송수신에 대한 설정을 원격으로 설정할 수 있다. 따라서, 에이전트 어댑터가 에이전트에 직접적으로 동작이나 정보를 설정하는 것을 최소화하여 설정 관리를 안전하고 용이하게 할 수 있다.
도 27은 실시 예에 따른 인스턴스 시스템의 플랫폼이 클라이언트 시스템에 데이터를 제공하는 예를 개시하면 다음과 같다.
실시 예에 따른 인스턴스 시스템의 플랫폼은 파트너 시스템으로부터 전달된 데이터를 클라이언트 시스템에 제공할 수 있다.
실시 예는 격리된 워크스페이스를 제공하는 플랫폼을 기반으로 상기 플랫폼의 외부의 제1 컴퓨팅 시스템에 제공할 채널 정보를 설정한다(S171).
격리된 워크스페이스를 제공하는 플랫폼은 인스턴스 시스템을 포함하고, 하나 이상의 노드를 포함할 수 있다. 예시한 바에 따라 제1 컴퓨팅 시스템은 파트너(또는 클라이언트) 시스템일 수 있으며, 그 경우 예시한 인스턴스 시스템의 워커노드에 설치된 에이전트 어댑터에 파트너 시스템에 설치된 에이전트에 제공할 채널 정보를 설정될 수 있다.
워크스페이스를 제공하는 인스턴스 시스템의 워커노드에 에이전트 어댑터가 설치되는 경우, 그 에이전트 어댑터는 그 워커노드를 통해 인스턴스 시스템의 코디네이터에 자신의 채널 정보를 설정하도록 할 수 있다.
상기 채널 정보는, 채널 타입을 포함하고, 상기 채널 타입은, 데이터베이스를 접속할 수 있는 채널 타입, 디렉토리에 송수신될 수 있는 파일 타입, 컴퓨팅 시스템의 커넥터 타입, 컴퓨터 네트워크 소프트웨어의 메시지 타입 등을 포함할 수 있다. 채널 설정에 관련한 예는 도 25에 개시하였다.
상기 설정된 채널 정보에 따라 상기 제1 컴퓨팅 시스템에 관련된 데이터를 수신한다(S175).
위와 같이 채널 정보가 에이전트 어댑터에 설정된 경우, 제1 컴퓨팅 시스템인 파트너(또는 클라이언트) 시스템에 설치된 에이전트로부터 상기 제1 컴퓨팅 시스템과 관련된 데이터를 수신할 수 있다.
즉, 일정 조건 하에서 상기 설정된 채널 정보에 따라 파트너 시스템의 에이전트로부터 파트너 시스템에 관련된 정보를 수신할 수 있다.
상기 수신된 제1 컴퓨팅 시스템과 관련된 데이터를, 상기 플랫폼의 외부의 상기 워크스페이스를 이용하는 제2 컴퓨팅 시스템에 제공한다(S179).
수신된 정보는 제2 컴퓨팅 시스템인 클라이언트 시스템에 제공될 수 있는데, 이와 같이 실시 예에 따른 인스턴스 시스템의 플랫폼을 통해 파트너 시스템과 클라이언트 시스템 사이의 거래 정보와 같은 데이터가 송수신될 수 있다.
인스턴스 시스템 중 에이전트 어댑터가 설치된 워커노드가 파트너 시스템으로부터 전달된 데이터를 수신하는 상세한 예는 도 26에 개시하였다.
도 28은 실시 예에 따른 인스턴스 시스템의 플랫폼이 파트너 시스템으로부터 데이터를 수신받는 예를 개시하면 다음과 같다.
격리된 워크스페이스를 제공하는 플랫폼을 기반으로 설정된 채널 정보를 상기 플랫폼의 외부의 제1 컴퓨팅 시스템에 설치된 에이전트에 제공한다(S181). 채널 설정에 관련한 예는 도 25에 개시하였다.
워크스페이스를 제공하는 인스턴스 시스템 내의 워커노드에 에이전트 어댑터가 설치되는 경우, 그 에이전트 어댑터는 설정된 채널 정보를 일정 조건 하에서 외부의 제1 컴퓨팅 시스템(파트너 또는 클라이언트 시스템)의 에이전트로 제공할 수 있다.
상기 채널 정보는, 채널 타입을 포함하고, 상기 채널 타입은, 데이터베이스를 접속할 수 있는 채널 타입, 디렉토리에 송수신될 수 있는 파일 타입, 컴퓨팅 시스템의 커넥터 타입, 컴퓨터 네트워크 소프트웨어의 메시지 타입 등을 포함할 수 있다. 채널 설정에 관련한 예는 도 25에 개시하였다.
상기 제공한 채널 정보에 기초하여 상기 제1 컴퓨팅 시스템과 관련하여 수집된 데이터를 수신할 수 있다(S185).
인스턴스 시스템에 설치된 에이전트 어댑터는 제공된 채널 정보에 기반하여 상기 제1 컴퓨팅 시스템인 파트너(또는 클라이언트) 시스템에 관련된 데이터를 수신할 수 있다.
상기 수집된 데이터를 저장 매체에 저장하고 상기 저장된 데이터를 상기 플랫폼의 외부의 제2 컴퓨팅 시스템에 제공할 수 있다(S189).
제1 컴퓨팅 시스템인 파트너 시스템의 데이터는 EDI와 같은 거래와 관련되거나 필요한 정보일 수 있는데, 제2 컴퓨팅 시스템인 클라이언트 시스템은 제1 컴퓨팅 시스템인 파트너 시스템으로부터 수신한 정보를 메시지 박스와 같은 저장 매체에 저장하도록 할 수 있다. 그리고 상기 워크스페이스를 제공하는 플랫폼을 기반으로 상기 저장된 데이터를 클라이언트 시스템에 제공할 수 있다.
수신된 파트너 시스템의 데이터를 메시지 박스에 저장하도록 제공하는 예는 도 26에 개시하였다.
위에서 개시한 실시 예에 따른 애플리케이션 서비스 제공 장치는 매니저 시스템와 인스턴스 시스템을 포함할 수 있다.
인스턴스 시스템은 코디네이터와 워커노드를 포함하는 적어도 하나의 서버로서, 상기 서버는 데이터를 저장하는 저장매체와 프로세서를 포함할 수 있다.
인스턴스 시스템은 격리된 워크스페이스를 포함하는 플랫폼을 제공할 수 있는데, 상기 서버의 프로세서는, 상기 플랫폼을 기반으로 상기 플랫폼의 외부의 제1 컴퓨팅 시스템에 제공할 채널 정보를 설정하도록 한다. 여기서 제1 컴퓨팅 시스템은 파트너 시스템(또는 클라이언트 시스템)일 수 있다.
상기 서버의 프로세서는 상기 설정된 채널 정보에 따라 상기 제1 컴퓨팅 시스템과 관련하여 수집된 데이터를 수신하고, 상기 수집된 데이터를 상기 격리된 워크스페이스를 이용하는 제2 컴퓨팅 시스템에 제공에 제공할 수 있다. 여기서 제2 컴퓨팅 시스템은 클라이언트 시스템(또는 파트너 시스템)일 수 있다.
한편, 상기 서버의 프로세서는 상기 플랫폼을 기반으로 설정된 채널 정보를 상기 플랫폼의 외부의 제1 컴퓨팅 시스템에 제공할 수 있다.
상기 서버의 프로세서는 상기 제공한 채널 정보에 기초하여 상기 제1 컴퓨팅 시스템과 관련하여 수집된 데이터를 수신하고, 상기 수집된 데이터를 저장 매체에 저장하도록 하고 상기 저장된 데이터를 상기 플랫폼의 외부의 제2 컴퓨팅 시스템에 제공할 수 있다.
여기서 제1 컴퓨팅 시스템은 파트너 시스템(또는 클라이언트 시스템)일 수 있고, 여기서 제2 컴퓨팅 시스템은 클라이언트 시스템(또는 파트너 시스템)일 수 있다.
애플리케이션 서비스 제공 장치에 대한 예는 위에서 인스턴스 시스템과 채널 설정에 대한 상세한 예를 참조할 수 있다.
만약 위와 같은 실시 예가 인스턴스 시스템 기반의 프로그램으로 수행될 경우, 그 프로그램은 상기 플랫폼을 기반으로 상기 플랫폼의 외부의 제1 컴퓨팅 시스템에 제공할 채널 정보를 설정하고, 상기 설정된 채널 정보에 따라 상기 제1 컴퓨팅 시스템과 관련하여 수집된 데이터를 수신하고, 상기 수집된 데이터를 상기 격리된 워크스페이스를 이용하는 제2 컴퓨팅 시스템에 제공에 제공하도록 할 수 있다.
또한, 상기 프로그램은, 상기 플랫폼을 기반으로 설정된 채널 정보를 상기 플랫폼의 외부의 제1 컴퓨팅 시스템에 제공하고, 상기 제공한 채널 정보에 기초하여 상기 제1 컴퓨팅 시스템과 관련하여 수집된 데이터를 수신하고, 상기 수집된 데이터를 저장 매체에 저장하도록 하고 상기 저장된 데이터를 상기 플랫폼의 외부의 제2 컴퓨팅 시스템에 제공할 수 있다.
여기서 제1 컴퓨팅 시스템은 파트너 시스템(또는 클라이언트 시스템)일 수 있고 제2 컴퓨팅 시스템은 클라이언트 시스템(또는 파트너 시스템)일 수 있다.
개시한 실시 예에 따르면, 클라이언트 또는 파트너 내에 보안 문제를 발생시키지 정보를 송수신할 수 있고, 플랫폼 외부의 클라이언트 또는 파트너 내에 설치된 에이전트를 이용하여 패치 또는 업그레이드를 용이하게 수행할 수 있다.
도 29는 실시 예에 따른 워크스페이스에서 어댑터를 실행하는 실시 예를 개시한 도면이다.
어댑터 패키지의 간편한 개발을 위하여 본 발명은 다양한 표준 연계 프로토콜에 대한 손쉬운 구축 방법을 제공하며, 개발자들 간의 어댑터 패키지 교환을 위한 앱 스토어(app store, 1510) 제공을 목표로 한다.
여기에서, 앱 스토어(1510)는 어댑터 패키지 판매부(1501) 및 어댑터 패키지 구매부(1502)를 포함할 수 있다. 이때, 앱 스토어(1510)는 상술한 실시 예를 참고할 수 있으며, 개발자가 어댑터 패키지를 업로드하고, 사용자가 어댑터 패키지를 구매 및 다운로드할 수 있는 플랫폼을 나타낼 수 있다. 이에 대한 내용은 후술하도록 한다. 일 실시 예에서, 개발자가 앱 스토어(1510)를 통하여 어댑터 패키지의 판매하기 위해서는 관리자의 승인이 필요하다.
상술한 바와 같이, 클라이언트(여기에서, 클라이언트는 개발자와 사용자를 모두 포함할 수 있다, 100)는 워크스페이스(1500, 3000)에서 여러가지 패키지를 생성, 실행 및 변경할 수 있다. 특히, 클라이언트(100)는 워크스페이스(1500, 3000)에서 어댑터 패키지를 실행할 수 있다. 어댑터 패키지를 실행하는 실시 예에 대하여는 상술한 바와 같다.
일 실시 예에서, 개발자는 애플리케이션 서비스 매니저에서 어댑터를 개발하고, 개발된 어댑터를 테스트하기 위하여 워크스페이스(1500, 3000)에서 어댑터를 실행할 수 있다. 이때, 어댑터 패키지 단위로 워크스페이스(1500, 3000)에 설치되고, 설치된 어댑터 패키지에 포함된 프로그램(프로그램 코드 및 관련 설정들)이 워크스페이스(1500, 3000) 상에서 실행될 수 있다.
일 실시 예에서, 어댑터를 실행하는 경우, 상술한 플랫폼과 상호 작용하여 요구사항을 해결할 수 있다. 즉, 도면에서 나타나는 플랫폼은 상술한 애플리케이션 서비스 매니저를 통하여 제공될 수 있으며, 워크스페이스(1500, 3000)에 포함되는 개념은 아니다.
플랫폼이 제공하는 서비스는 다음과 같은 기능을 지원할 수 있다.
메시지 박스 서비스는 송수신 문서를 가져오고 저장하는 서비스를 나타낸다.
통신 프로토콜 접근 서비스는 외부와의 통신 프로토콜 접근을 위한 서비스를 나타낸다. 예를 들어, HTTP/HTTPS, FTP 접근을 위한 서비스를 나타낸다.
설정 저장소 서비스는 어댑터가 실행되기 위해 필요한 설정을 저장하고 가져오는 서비스를 나타낸다.
이를 통해 플랫폼 서비스 제공자는 어댑터를 사고 파는 앱 스토어를 제공하고, 어댑터를 개발하여 실행하는 워크스페이스(1500, 3000)를 제공함으로써 부가 수익 및 확산 효과를 기대할 수 있다는 장점이 있다.
또한, 사용자는 만들어진 어댑터를 구매, 설치, 설정, 실행 과정을 통해 다양한 표준 연계 프로토콜을 구축할 수 있고, 어댑터를 개발하는 입장(개발자)에서는, 어댑터를 개발하여 판매함으로써 수익을 창출할 수 있다는 장점이 있다.
도 30은 어댑터 패키지의 일 예를 개시한 도면이다.
패키지란 워크스페이스에 설치 및 실행되는 프로그램(코드 파일 또는 설정 파일)의 묶음으로 어댑터 패키지, 통합 패키지 및 리소스 패키지를 포함한다. 통합 패키지 및 리소스 패키지에 대한 설명은 상술한 바와 같다.
어댑터 패키지는 통합(integration)을 위한 여러가지 종류의 프로토콜 및 플랫폼 내의 각종 서비스들의 사용을 지원하는 패키지를 나타낸다. 일반적으로 어댑터 패키지는 플랫폼 내의 서비스들을 사용하여 웹 기반으로 설정하고, 설정된 사항(채널)을 통합 패키지에서 사용할 수 있다. 이에 대한 설명은 상술한 바와 같다.
일 실시 예에서, 어댑터 패키지는 다음과 같은 어댑터들을 포함할 수 있다. 즉, 후술하는 어댑터 패키지를 통해 매우 다양한 종류의 요구사항을 해결할 수 있다.
제 1 어댑터 패키지(1520a)는 프로토콜 어댑터를 포함할 수 있다. 여기에서, 프로토콜 어댑터는 EDIINT, OFTP 등의 표준 프로토콜 통신 어댑터를 포함한다.
제 2 어댑터 패키지(1520b)는 매핑/변환 프로그램 어댑터를 포함할 수 있다. 여기에서, 매핑/변환 프로그램 어댑터는 매핑 및 변환 작업을 쉽게 할 수 있도록 제공하는 어댑터를 나타낸다.
제 3 어댑터 패키지(1520c)는 웹 스크랩 어댑터를 포함할 수 있다. 여기에서, 웹 스크랩 어댑터는 표준적인 통신이 아닌 웹 서비스로만 제공하는 웹 서비스에서의 스크랩 기능 어댑터를 나타낸다.
제 4 어댑터 패키지(1520d)는 개발 위자드 어댑터를 포함할 수 있다. 여기에서, 개발 위자드 어댑터는 특정 패턴들의 연계 플로우(프로그램 흐름)를 위자드 방식으로 생성해주는 어댑터를 나타낸다.
어댑터 패키지는 상술한 어댑터 이외에 워크스페이스를 통하여 개발자가 개발하는 다른 어댑터들이 포함될 수 있음은 물론이다.
도 31은 실시 예에 따른 워크스페이스에서 어댑터를 실행하는 일 예를 개시한 도면이다.
일 실시 예에서, 어댑터를 개발하는 애플리케이션 서비스 매니저와 개발된 어댑터를 실행하는 워크스페이스를 제공할 수 있다(S210).
개발자는 상술한 애플리케이션 서비스 매니저를 통하여 어댑터를 개발할 수 있다. 이후, 개발자는 개발된 어댑터를 테스트하기 위하여 개발 워크스페이스에서 개발된 어댑터를 실행할 수 있다.
보다 상세하게는, 개발자는 어댑터 패키지를 개발, 버전 업(version-up)할 수 있고, 이를 위하여 개발자는 워크스페이스로 어댑터 패키지를 설치하고 어댑터를 실행할 수 있다.
이때, 개발된 어댑터를 테스트를 위하여 실행하는 개발 워크스페이스와 어댑터를 실제로 사용하는 운영 워크스페이스는 분리될 수 있다. 이때, 개발워크스페이스와 운영워크스페이스의 구분은 논리적인(logical) 개념에 해당한다.
일 실시 예에서, 개발된 어댑터 패키지를 판매 및 구매하는 앱 스토어를 제공할 수 있다(S220).
개발자는 개발된 어댑터를 어댑터 패키지에 포함시켜 앱 스토어를 통해 판매할 수 있다. 일 실시 예에서, 어댑터 패키지의 개발자는 다른 사용자에게 개발자 권한을 부여할 수 있다.
특히, 어댑터 패키지의 개발자는 커스텀(custom)한 클래스를 개발하여 후술하는 application context에 컴포넌트로 등록할 수 있다. 이때, 개발자는 다른 컴포넌트(Component)를 참조(reference)할 수 있으며, 웹 서비스(Rest, Servlet 클래스)에서도 참조할 수 있다.
개발자는 지정된 클래스를 Singleton Component로 지정할 수 있다. 여기에서, 컴포넌트는 다른 컴포넌트나 Rest, Servlet Service에서도 Application Context를 통해 참조될 수 있다.
사용자는 앱 스토어 내에서 판매 중인 어댑터 패키지를 구매할 수 있다.
일 실시 예에서, 구매한 어댑터 패키지를 설치하고, 어댑터 패키지 내에 포함된 어댑터를 실행하는 워크스페이스를 제공할 수 있다(S230).
사용자는 워크스페이스에서 어댑터 패키지를 설치하고, 어댑터 패키지 내에 포함된 어댑터를 설치 및 실행할 수 있다. 일 실시 예에서, 어댑터 패키지를 구매한 사용자는 자신이 소유한 워크스페이스에만 해당 어댑터 패키지를 설치할 수 있다. 이는 상술한 바와 같이 사용자 별로 격리된 워크스페이스를 사용하기 때문이다.
도 32는 실시 예에 따른 어댑터가 프레임워크를 사용하는 일 예를 개시한 도면이다.
코어(Core)는 다음과 같은 서비스를 제공할 수 있다. 이때, 코어는 상술한 프레임워크에 대응한다.
(1) Configuration Repository: 구성 설정 정보를 저장하고 관리할 수 있다. 이를 통하여, 시스템의 설정 데이터를 저장하고 필요한 구성 정보에 대한 액세스를 제공할 수 있다.
(2) Distributed Task Service: 분산 환경에서 작업을 처리하고 관리할 수 있다. 이를 통하여, 여러 노드 또는 시스템 간의 작업 분산, 상태 추적 등을 처리할 수 있다.
(3) Channel Registry: 통신 채널에 대한 등록 및 관리를 담당할 수 있다. 이를 통하여, 서로 다른 시스템 또는 패키지 간의 통신을 위한 채널을 등록하고 사용할 수 있다.
(4) Message Box Service: 메시지 기반 통신을 지원할 수 있다. 이를 통하여, 메시지 전송, 수신, 저장, 라우팅 등의 기능을 제공하여 다양한 시스템 간의 비 동기적인 통신을 지원할 수 있다.
(5) File Watch System: 파일 변경 및 감시를 처리하는 시스템으로, 파일 시스템의 변경 사항을 모니터링하고 필요한 작업을 수행할 수 있다.
본 발명의 어댑터는 프레임워크를 사용하기 위해 API를 사용할 수 있다. 즉, 어댑터는 API를 통해서 코어의 서비스들을 이용할 수 있다.
API는 다음과 같은 서비스를 제공할 수 있다.
(1) Configuration Service: 구성 설정에 대한 액세스를 제공하는 서비스 인터페이스로, 구성 데이터의 조회, 수정, 삭제 등을 지원할 수 있다.
(2) Task Service: 작업 처리와 관련된 기능을 사용하기 위한 서비스 인터페이스로, 작업 생성, 상태 조회, 결과 반환 등의 작업 관리 기능을 제공할 수 있다.
(3) Channel Access Service: 통신 채널에 대한 액세스를 제공하는 서비스 인터페이스로, 채널 생성, 메시지 전송, 수신 등의 기능을 제공할 수 있다.
(4) Message Box Access Service: 메시지 박스에 대한 액세스를 제공하는 서비스 인터페이스로, 메시지 생성, 전송, 수신, 삭제 등의 기능을 제공할 수 있다.
(5) User Class: API를 사용하여 레지스트리(Registry)에 등록한 클래스로 웹 서비스나 다른 클래스에 의해 참조(Reference)될 수 있다.
(6) File Watcher: 파일 감시를 처리하는 인터페이스로, 파일 변경 이벤트를 처리하고 필요한 작업을 수행할 수 있다.
user implement는 다음과 같은 서비스를 제공할 수 있다.
(1) Web Service: 사용자가 웹 기반의 서비스를 개발하는데 사용되는 구현 코드로, 어댑터가 실행하는데 필요한 설정을 웹 인터페이스를 통해 제공할 수 있다.
(2) User Classes: 개발자가 자신의 로직을 구현하기 위해 작성하는 사용자 정의 클래스로, Core나 API의 기능을 활용하여 특정 도메인 또는 비즈니스 로직을 구현할 수 있다.
(3) File Watcher Implementation: 파일 감시를 처리하는 구현 코드로, File Watch System과 상호 작용하여 파일 변경 이벤트를 처리하고 필요한 작업을 수행할 수 있다.
도 33은 실시 예에 따른 어댑터 패키지가 제공하는 서비스의 일 예를 개시하는 도면이다.
Application Context는 프레임워크에 포함되는 구성 요소로 어댑터 패키지 개발을 위한 서비스 API를 포함할 수 있다. 예를 들어, 서비스 API는 WorkspaceIdentity, MessageAccessService, MessageSlotInfoService, ConfigurationService, TaskService, ChannelAccessService, FileAccessService 등을 포함할 수 있다.
일 실시 예에서, 어댑터 패키지의 개발자는 어댑터 패키지의 생명 주기(life cycle)에 따라 수행되는 방법(Method)를 지정할 수 있다. 이때, 개발자는 생명 주기에 관련된 Annotation을 사용할 수 있다. 예를 들어, 패키지 시작 시 또는 종료 시 특정 Method를 실행하게끔 지정할 수 있다. 이에 대하여 후술하도록 한다.
또한, Application Context에 등록된 서비스들은 빈(Bean)으로 등록된 사용자 클래스(User Class)와 상호 작용할 수 있다. 예를 들어, 빈으로 등록된 user implement class는 FileWatcher, TaskImple, ChannelProcessorImple 및 이외의 사용자 정의 클래스 등이 포함될 수 있다. 이들 클래스들은 애플리케이션의 특정기능 또는 비즈니스 로직을 구현하고, application context에 빈으로 등록되어 다른 컴포넌트에 사용될 수 있도록 한다. 이를 통해 사용자 클래스의 인스턴스를 프레임워크에서 관리하고 애플리케이션에서 필요한 객체를 생성하고 사용할 수 있다.
일 실시 예에서, Application Context는 사용자 컴포넌트를 빈(Bean)으로 등록하여 웹 서비스(예를 들어, Rest, Servlet)에서 참조(reference)할 수 있다. 일 실시 예에서, 웹 서비스에서 사용자 컴포넌트 참조 시, Application Context를 통해서 직접 참조하는 것을 특징으로 한다. 방법은 다음과 같다.
Method:
- T getInstacne(Class<T> type): Application Context에 등록된 서비스 및 객체를 반환
- WorkspaceIdentity getWorkspaceId(): WorkspaceIdentity 참조
- String getPackageId(): 패키지의 ID값 반환
이때, Rest API는 JAX-RS API를 통해 구현될 수 있다. 이를 위하여, @RestService Annotation으로 REST 서비스를 등록하고, /pkg/{workspace_install_path}/{package_install_path}/rest/{path)로 접근이 가능하다.
또한, Servlet API는 javax.servlet API를 통해 구현될 수 있다.
이를 위하여, @Servlet("Servlet패턴")으로 Servlet을 등록하고, pkg/{workspace_install_path}/{package_install_path}/{Servlet 패턴}로 접근이 가능하다.
WorkspaceIdentity에 대한 설명은 다음과 같다. WorkspaceIdentity는 어댑터 패키지가 속한 워크스페이스 정보를 포함하고 있으며 Ticket을 생성할 수 있다. WorkspaceIdentity는 어댑터 패키지가 클라우드 EDI 서비스를 이용할 때 워크스페이스 인증을 위한 클래스에 대응한다. WorkspaceIdentity는 클라우드 EDI 플랫폼에서 제공하는 API를 사용할 때 필요하다. 방법은 다음과 같다.
Method:
- getId(): 패키지가 속한 워크스페이스의 고유 ID 반환
- getTicket(): 패키지가 속한 워크스페이스를 인증할 수 있는 Ticket 반환
TaskService에 대한 설명은 다음과 같다. TaskService는 분산 작업 스케줄링과 관련된 기능을 제공할 수 있다. TaskService는 분산 환경에서 작업을 등록하고, 주기적으로 실행되도록 스케줄링할 수 있다. 분산 작업 서비스에 의해 등록된 작업은 지정된 시간 또는 이벤트에 따라 실행될 수 있다.
즉, TaskService는 어댑터 패키지에서 특정 Task를 분산 스케줄러에 등록 및 해지하기 위해서 사용할 수 있다. 사용자는 Task 인터페이스를 구현할 수 있고, 분산 스케줄러는 Cron, Second 방식을 지원할 수 있다. 방법은 다음과 같다.
Method:
- register(TaskConfig config, Task task): 분산 스케줄러에 작업 등록
- return: task 고유 ID)
- unregister(String taskId): 분산 스케줄러에서 고유ID를 가지고 있는 Task 등록 해제
MessageBoxAccessService에 대한 설명은 다음과 같다. MessageBoxAccessService는 EDI 메시지 박스에 접근하여 문서의 송수신을 가능하게 한다. 일 예에서, 클라우드 기반의 메시지 박스에 접근하여 데이터를 전송하고, 수신된 데이터를 처리할 수 있다. 여기에서, 메시지 박스는 메시지 박스 저장소에 접근하여 문서를 저장, 조회 또는 삭제할 수 있는 API를 나타낸다. 방법은 다음과 같다.
Method:
- send(): MessageBox에 문서를 저장
- queryPendingMessageList(): 해당 슬롯/경로명에 있는 전송 대기상태(TBDL, WAIT)의 메시지 레코드(메시지 헤더) 목록 반환
- receivePayload(): 메시지 본문 반환
- updateMessageStatus(): 메시지 상태 변경
- deleteMessage(): 메시지 삭제
MessageSlotInfoService에 대한 설명은 다음과 같다. MessageSlotInfoService는 메시지 박스의 슬롯 정보를 가지고 있는 서비스에 대응한다. 방법은 다음과 같다.
Method:
- getSlotId(String workspaceId, String pathname): 워크스페이스 ID 및 경로(path) 명에 맞는 메시지 슬롯 ID를 반환
- getMessageBoxId(String slotId): 메시지 슬롯이 속한 메시지박스 ID 반환
- getSlotMap(String workspaceId): 워크스페이스에서 접근 가능한 메시지 슬롯 목록 반환
ConfigurationService에 대한 설명은 다음과 같다. ConfigurationService는 설정 저장소(Config Repository)에 접근하여 설정 정보를 조회, 변경, 삭제할 수 있는 서비스에 대응한다. 이를 통하여, 설정 데이터를 관리하고 필요한 구성 정보에 접근할 수 있다. ConfigurationService는 패키지에서 설정 저장소로 직접 접근하여 패키지의 설정을 읽어오고 수정, 변경 또는 삭제할 수 있는 API를 나타낸다. 방법은 다음과 같다.
Method:
- list(WorkspaceIdentity, String packageId, String nodePath): 특정 워크스페이스 및 패키지의 요청된 경로(path)에 있는 node path의 목록을 가져오고, Web Admin에서 설정 화면 UI에 필요한 설정정보를 가져오는 웹서비스를 제공하기 위한 방법
이때, 어댑터 패키지에서 설정 값을 적용하는 것은 FsWatchSystem 사용이 권장된다.
- create(WorkspaceIdentity, String packageId, ConfigNode node): 설정 노드를 생성
- update(WorkspaceIdentity, String packageId, ConfigNode node): 설정 노드를 변경
- remove(WorkspaceIdentity, String packageId, ConfigNode node): 설정 노드를 삭제
FileWatchSystem에 대한 설명은 다음과 같다. FileWatchSystem은 주어진 경로나 디렉토리의 파일 변경 사항을 모니터링하고 필요한 작업을 수행하는 기능을 제공할 수 있다. 보다 상세하게는, FileWatchSystem은 등록된 경로의 디렉토리를 주기적으로 감시하며 파일의 생성, 변경, 삭제를 탐지하고, 등록된 FsWatcher를 통해 인터페이스를 수행할 수 있다. 여기에서, FsWatcher는 경로 내 파일 변경을 감지하는 경우, 수행할 액션을 구현할 수 있다. 예를 들어, 방법은 다음과 같다.
Method:
- init(Set<File> fset, String path): FsWatcher가 최초 등록 시 수행, 파라미터로 등록된 경로 내의 파일Set을 넘겨줌
- process(FsEvent): 변동이 감지된 파일, 이벤트 유형을 넘겨줌
FileAccessService에 대한 설명은 다음과 같다. FileAccessService는 File Access Service를 사용하여 클라우드 EDI 내 FTP 서버에 접근하거나 외부 FTP에 접근하여 파일을 Access할 수 있다. 방법은 다음과 같다.
Method:
- put(String workspaceId, String serviceName, String folderPath, String filename, byte[] body): workspace에 등록된 ServiceNamed을 가진 FTP서비스 경로에 파일 전송
- get(String workspaceId, String serviceName, String folderPath, String filename): workspace에 등록된 ServiceNamed을 가진 FTP서비스 경로에 있는 파일 수신
- list(String workspaceId, String serviceName, String folderPath, String pattern): 대상 경로에 있는 파일중에 GLOB 패턴에 맞는 파일 목록 조회
- delete(String workspaceId, String serviceName, String folderPath, String filename): 대상 경로에 있는 파일 삭제
ChannelAccessService는 채널 요청에 따라 분산 채널 접근 서비스를 제공하는 구성(component)로, 특정 프로세스가 채널을 구독하여 채널로부터 수신되는 메시지나 이벤트를 처리할 수 있다. 이를 통하여 채널을 통해 데이터를 전송하고, 채널로부터 데이터를 수신하여 처리할 수 있다. 방법은 다음과 같다.
Method :
- create(String channelId, String channelName): 워크스페이스에 채널을 미리 생성
- subscribe(ChannelProcessor processor): 패키지의 기본 채널로 채널 처리할 인터페이스를 등록
- Subscribe(String channelId,ChannelProcessor processor): 특정 채널 ID로 채널을 등록
- unsubscribe(): 패키지의 기본 채널 등록을 해제
- unsubscribe(String channelId): 특정 채널의 등록을 해제
- call(ChannelRequest request): 특정 채널을 호출
도 34는 실시 예에 따른 워크스페이스에서 개발된 어댑터의 일 예를 개시한 도면이다.
상술한 실시 예를 통하여 개발자는 Router의 역할을 수행하는 제 1 어댑터 패키지(324)를 개발할 수 있다. 여기에서, 제 1 어댑터 패키지(324)에 포함된 어댑터는 설정에 의해 라우팅을 쉽게 해주는 서비스에 대응한다.
실시 예에 따르면 클라이언트(310)는 원하는 파트너(320)에게 개시한 예와 같은 애플리케이션 서비스를 제공할 수 있다. 실시 예는 단순히 클라이언트(310)에서 서비스를 제공할 뿐만 아니라 클라이언트(310)가 실시 예를 이용해 직접 원하는 파트너(320)에게 커스텀마이즈된 서비스(customized service)를 제공할 수 있도록 할 수 있다.
본 도면에서는, 상술한 제 1 어댑터 패키지(324)를 이용하여 EDI 서비스를 제공하는 실시 예를 설명한다. 클라이언트(310)가 파트너(320)와 거래를 하기 위해 실시 예는 인스턴스 시스템에 포함되는 코디네이터(1100)와 워커노드(1300a, 1300b)를 제공할 수 있다. 여기에서 제 1 워커노드(1300a)와 제 2 워커노드(1300b)는 동일하거나 상이한 노드에 대응한다.
일 실시 예에서, 클라이언트(310)가 통신하는 어댑터 패키지(311)에는 제 1 에이전트(312)가 설치되어 있고, 제 1 에이전트(312)를 통해 거래에 필요한 정보인 EDI 정보를 요청할 수 있다. 여기에서, EDI 정보는 original EDI message(313)에 대응한다.
클라이언트(310)가 통신하는 제 1 에이전트(312)는 수신한 요청된 EDI 정보를 메시지 박스 서비스(2110)로 전달한다. 일 실시 예에서, 메시지 박스 서비스(2110)는 애플리케이션 서비스 매니저에 의해 제공될 수 있다.
메시지 박스 서비스(2110)는 제 1 에이전트(312)로부터 전달받은 EDI 정보를 클라이언트 인박스(2111)에 저장할 수 있다.
이후, EDI 정보는 인스턴스 시스템 내의 제 1 워커 노드(1300a)에서 실행 중인 제 1 어댑터 패키지(324)에 전달될 수 있다. 여기에서, 제 1 어댑터 패키지(324)는 상술한 바와 같이 라우터의 역할을 수행할 수 있다.
일 실시 예에서, 제 1 어댑터 패키지(324)는 코디네이터(1100)로부터 수신한 정보에 기초하여 Original EDI Message(313)가 포함된 EDI 정보를 메시지 박스 서비스(2110) 내의 제 1 파트너 아웃박스에 저장할 수 있다. 또한, 제 1 어댑터 패키지는 코디네이터(1100)로부터 수신한 정보에 기초하여 Original EDI Message(313)가 포함된 EDI 정보를 제 2 워커 노드(1300b)의 통합 패키지(integration package)(1380)로 전달할 수 있다. 이때, 제 1 어댑터 패키지는 코디네이터(1100)의 분산 스케줄러(Distributed Scheduler)를 참조하고 어댑터 채널 레지스트리(Adapter Channel Registry)를 조회(Lookup)할 수 있다.
통합 패키지(1380)는 상술한 실시 예를 통하여 전달받은 EDI 정보를 변환할 수 있다. 이때, 통합 패키지(1380)는 어댑터 채널 레지스트리를 구독(Subscribe)할 수 있다. 여기에서, 구독이란 통합 패키지의 특정 플로우(flow) 또는 로직(logic)이 라우터 패키지로부터 호출 받을 때, 호출 받을 “분산 채널 명”을 등록(구독)하는 과정을 나타낸다. 예를 들어, 노드 #1의 라우터 패키지는 해당 채널이 어떤 노드에 있는지 코디네이터(1100)를 조회(Lookup)하여 호출할 수 있다.
이에 따라, 통합 패키지(1380)가 포함된 제 2 워커 노드(1300b)는 Transformed EDI Message(314)가 포함된 EDI 정보를 메시지 박스 서비스(2110)의 제 2 파트너 아웃박스에 저장할 수 있다.
이후, 메시지 박스 서비스(2110)는 제 1 파트너 아웃박스에 저장된 Original EDI Message(313)가 포함된 EDI 정보를 파트너(320)와 통신하는 어댑터 패키지(321)의 제 1 파트너(322)에게 전달할 수 있다. 또한, 메시지 박스 서비스(2110)는 제 2 파트너 아웃박스에 저장된 Transformed EDI Message(314)가 포함된 EDI 정보를 파트너(320)와 통신하는 어댑터 패키지(321)의 제 2 파트너(323)에게 전달할 수 있다. 여기에서, 제 1 파트너(322)와 제 2 파트너(323)는 고객사의 거래 파트너에 대응한다. 고객사(클라이언트)는 여러 파트너와 문서를 주고 받을 수 있기 때문이다.
결과적으로 파트너(320)는 클라이언트(310)가 전달한 EDI 정보를 표준화된 EDI 변환 데이터로 수신할 수 있다. 파트너(320)가 클라이언트(310)에 자신의 EDI 정보를 전달하는 경우에도 유사한 프로세스에 따라 데이터를 전달할 수 있다.
따라서, 클라이언트(310)와 파트너(320)는 개시하는 실시 예에 따라 EDI 서비스와 같은 애플리케이션 서비스를 쉽게 이용할 수 있고, 표준화된 형식을 모르거나 거래 상대방이 요청하는 문서와 정보를 정확하게 이해하지 못하더라도 표준화된 형식에 따라 용이하게 거래를 진행할 수 있다.
또한, 클라이언트(310) 또는 파트너(320)는 자신의 워크스페이스에서 위와 같은 어댑터 패키지를 개발하거나 이용할 수 있고, 이를 통합 패키지(1380)에 연계시킬 수도 있다. 실시 예는 이러한 패키지의 개발과 기존 패키지와의 연결도 매우 쉬운 인터페이스를 통해 제공할 수 있고, 개발된 패키지도 판매, 공유, 별도 제공할 수 있다.
도 35는 실시 예에 따른 어댑터 패키지를 개발하는 프레임워크를 제공하는 일 예를 개시한 도면이다.
일 실시 예에서, 어댑터 패키지를 개발하는 애플리케이션 서비스 매니저를 제공할 수 있다(S240). 이를 위하여, 애플리케이션 서비스 매니저는 개발자에게 개발 툴(developer tool)을 제공할 수 있다. 애플리케이션 서비스 매니저에 대한 설명은 도 2 내지 4를 참고하도록 한다.
일 실시 예에서, 개발된 어댑터 패키지를 테스트하는 제 1 워크스페이스를 제공할 수 있다(S250). 여기에서, 제 1 워크스페이스는 개발 워크스페이스에 대응한다. 개발 워크스페이스에 대한 자세한 설명은 도 2 내지 도 4 및 도 9를 참고하도록 한다.
일 실시 예에서, 개발된 어댑터 패키지를 실행하는 제 2 워크스페이스를 제공할 수 있다(S260). 여기에서, 제 2 워크스페이스는 운영 워크스페이스에 대응한다. 클라이언트(개발자 또는 사용자)는 운영 워크스페이스에서 어댑터 패키지를 실행하여 다양한 애플리케이션 서비스를 이용할 수 있다. 여기에서, 애플리케이션 서비스는 메시지 박스 서비스, 통신 프로토콜 접근 서비스, 설정 저장소 서비스 중 적어도 하나를 포함할 수 있다. 이에 대하여는 도 11, 도 32 및 도 33을 참고하도록 한다.
이후, 애플리케이션 서비스 제공 방법은 개발된 어댑터 패키지를 앱스토어에 업로드할 수 있다. 일 실시 예에서, 개발된 어댑터 패키지는 관리자의 승인에 기초하여 앱스토어에 업로드되거나 업로드되지 않을 수 있다. 이에 대하여는 이하에서 자세히 설명하도록 한다. 사용자는 앱스토어로부터 업로드된 어댑터 패키지를 다운로드할 수 있고, 다운로드된 어댑터 패키지를 사용자의 격리된 워크스페이스에서 실행하여 운영할 수 있다.
도 36은 실시 예에 따른 애플리케이션 서비스 제공 장치가 앱스토어 플랫폼에서 애플리케이션 패키지를 제공하는 예를 개시하는 도면
본 발명의 실시 예에 따른 애플리케이션 서비스 제공 장치는 인스턴스 시스템(1000) 및 매니저 시스템(2000)을 포함할 수 있다.
매니저 시스템(2000)은 클라이언트(110)가 애플리케이션 패키지를 개발할 수 있는 환경을 제공할 수 있다. 즉, 사용자(타사, 개발사)의 클라이언트(110)는 자신의 필요에 의해 또는 판매를 목적으로 매니저 시스템(2000)이 제공하는 환경을 통해 애플리케이션 패키지를 개발할 수 있다.
일 실시 예에서, 애플리케이션 패키지는 어댑터 패키지, 통합 패키지 및 리소스 패키지 중 적어도 하나를 포함할 수 있다. 이 경우, 어댑터 패키지는 연계를 위한 프로토콜 어댑터 또는 여러 기능을 가진 소프트웨어 패키지를 포함할 수 있다. 또한, 통합 패키지는 실질적인 통합(Integration) 흐름을 가진 소프트웨어 패키지를 포함할 수 있다. 통합 패키지는 클라이언트(120)에 의해 구매된 후 클라이언트(120)의 요구사항에 맞게 변경될 수 있다. 또한, 리소스 패키지는 어댑터 패키지 동작을 위해 추가로 필요로 하는 리소스 파일들을 별도로 패키징하는 패키지를 포함할 수 있다.
클라이언트(110)는 개발된 애플리케이션 패키지를 개발워크스페이스(3000)를 통해 테스트하고, 테스트된 애플리케이션 패키지 및 추가적인 메타데이터를 포함하는 업로드 요청을 매니저 시스템(2000)의 애플리케이션 서비스 매니저(2100)에게 송신할 수 있다.
애플리케이션 서비스 매니저(2100)는 해당 애플리케이션 패키지의 미리 정의된 여러 승인 판단 조건들을 분석하여, 애플리케이션 패키지가 판매에 적합한지를 판단하고 업로드를 승인할 수 있다. 승인이 되는 경우, 해당 애플리케이션 패키지는 앱스토어에서 클라이언트(120)에 의해 구매가 가능한 애플리케이션 패키지가 될 수 있다.
클라이언트(120)는 구매 가능한 해당 애플리케이션 패키지를 구매하기 위해 애플리케이션 서비스 매니저(2100)에게 애플리케이션 패키지의 구매 요청을 송신할 수 있다.
클라이언트(120)는 구매한 애플리케이션 패키지를 자신의 워크스페이스(1520)에 설치할 수 있다. 클라이언트(120)는 설치된 애플리케이션 패키지를 자신의 요구사항에 맞게 설정을 하여 실제 운영할 수 있다.
도 37은 실시 예에 따른 애플리케이션 서비스 제공 방법의 다른 일 실시 예를 개시하는 흐름도
제 1 클라이언트로부터 앱스토어에 대한 애플리케이션 패키지의 업로드 요청을 수신한다(S301).
일 실시 예에서, 업로드 요청은 애플리케이션 패키지 및 애플리케이션 패키지에 대한 메타데이터를 포함할 수 있다. 예를 들어, 메타데이터는 애플리케이션 패키지에 대한 패키지 명, 패키지 상세설명, 패키지 종류, 패키지 버전 정보, 결제 유형(예: 일시불, 구독형, 분할결제), 국가 통화 별 판매 가격, 등록자 유저 정보 및 등록 시간 중 적어도 하나를 포함할 수 있다.
상기 업로드 요청에 따라, 상기 애플리케이션 패키지에 대한 미리 정의된 승인 판단 조건에 기반하여, 상기 앱스토어에 대한 상기 애플리케이션 패키지의 업로드를 승인한다(S303).
일 실시 예에서, 애플리케이션 패키지에 대한 소스 코드, 상기 애플리케이션 패키지에 대한 외부 접근 허가요청 호스트 목록, 상기 애플리케이션 패키지에 대해 사용되는 외부 라이브러리 및 상기 애플리케이션 패키지의 파일 크기 중 적어도 하나가 상기 미리 정의된 승인 판단 조건을 만족하는 경우, 상기 앱스토어에 대한 상기 애플리케이션 패키지의 업로드를 승인할 수 있다.
일 실시 예에서, 애플리케이션 패키지에 대한 소스 코드의 보안 취약점이 없거나 소스 코드가 악성 코드를 포함하지 않는 경우, 상기 앱스토어에 대한 상기 애플리케이션 패키지의 업로드를 승인할 수 있다.
일 실시예에서, 애플리케이션 패키지가 어댑터 패키지를 포함하는 경우, 어댑터 패키지에 대한 소켓 연결 및 파일 액세스의 권한이 제한될 수 있다. 따라서, 특정한 목적을 위해 외부 네트워크에 접속해야 되는 어댑터 패키지의 경우(예: Mail Sender, Web Scraper 등), 접속해야 되는 외부 접근 허가요청 호스트 목록을 검사하여, 해당 목록에 포함된 외부 호스트가 외부 접근 가능한 호스트인 경우, 상기 앱스토어에 대한 상기 애플리케이션 패키지의 업로드를 승인할 수 있다. 이 경우, 외부 접근 허가요청 호스트 목록은 어댑터 패키지 내의 리소스 파일에 포함될 수 있다.
일 실시예에서, 애플리케이션 패키지가 설치되어 정상적으로 작동하기 위해, 애플리케이션 패키지가 참조하는 외부 라이브러리들이 설치되는 플랫폼 환경에서 제공되어야 한다. 이 경우, 해당 플랫폼 환경에서 제공되지 않는 외부 라이브러리인 경우, 해당 애플리케이션 패키지가 참조할 수 있도록 추가적인 절차가 수행되어야 하므로, 참조되는 외부 라이브러리에 대한 의존도(dependency)를 검사할 수 있다. 따라서, 외부 라이브러리가 애플리케이션 패키지에 의해 사용될 수 있는 경우, 상기 앱스토어에 대한 상기 애플리케이션 패키지의 업로드를 승인할 수 있다.
일 실시예에서, 애플리케이션 패키지의 파일 크기가 임계값보다 크지 않은 경우, 상기 앱스토어에 대한 상기 애플리케이션 패키지의 업로드를 승인할 수 있다. 즉, 애플리케이션 패키지의 파일 크기를 검사하여, 애플리케이션 패키지에 불필요한 리소스가 포함되지 않는지, 애플리케이션 패키지가 플랫폼 환경에서 무리한 자원 점유를 하지 않는지 확인할 수 있다.
상기 앱스토어에서 상기 승인된 애플리케이션 패키지를 제공한다(S305).
일 실시예에서, 애플리케이션 패키지에 대한 메타 데이터에 기반하여 앱스토어에 상기 승인된 애플리케이션 패키지를 등록하고, 애플리케이션 패키지의 구매 요청에 따라, 애플리케이션 패키지를 제공할 수 있다.
도 38은 실시 예에 따른 애플리케이션 서비스 제공 방법의 다른 일 실시 예를 개시하는 흐름도
제 2 클라이언트로부터 상기 애플리케이션 패키지의 구매 요청을 수신한다(S311).
일 실시예에서, 제 2 클라이언트로부터 앱스토어에 업로드되어 구매 가능한 패키지인 애플리케이션 패키지에 대한 구매 요청을 수신할 수 있다.
상기 구매 요청에 따라, 상기 제 2 클라이언트에게 상기 애플리케이션 패키지를 제공한다(S313).
일 실시예에서, 구매 요청에 따라, 구매 요청에 대한 애플리케이션 패키지와 해당 애플리케이션 패키지의 메타데이터에 포함된 패키지 설명 및 판매 조건에 기반하여 애플리케이션 패키지의 판매가 승인된 경우 제 2 클라이언트에게 해당 애플리케이션 패키지를 제공할 수 있다.
일 실시 예에서, 상기 제공된 애플리케이션 패키지는, 상기 제 2 클라이언트의 워크스페이스에 설치될 수 있다. 즉, 제 2 클라이언트에 의해 구매된 애플리케이션 패키지는 제 2 클라이언트의 실행 가능 영역인 워크스페이스에 설치될 수 있다. 일 실시예에서, 설치된 애플리케이션 패키지는 제 2 클라이언트의 설정 정보에 따라 실행되어 운영될 수 있다.
도 39는 실시 예에 따른 애플리케이션 서비스 제공 장치가 애플리케이션 패키지에 대한 서비스를 제공하는 예를 개시하는 도면
본 발명의 실시 예에 따른 애플리케이션 서비스 제공 장치(400)는 적어도 하나의 고객사에게 내부 시스템을 제공하는 클라이언트(100)와 적어도 하나의 파트너(200)에게 서비스형 소프트웨어(Software as a Service, SaaS) 형 서비스를 제공할 수 있다.
예를 들어, 내부 시스템은 ERP(enterprise resource planning), CRM(Customer Relationship Management) 및 WMS(warehouse management system)을 포함할 수 있으나, 이에 제한되지 않고 다양한 시스템을 포함할 수 있다.
일 실시 예에서, 클라이언트(100)는 멀티테넌시(Multi-tenancy)로 연결된 적어도 하나의 고객사(미도시)에게 내부 시스템을 통한 서비스를 제공할 수 있다.
일 실시 예에서, 애플리케이션 서비스 제공 장치(400)는 클라이언트(100)에게 애플리케이션 패키지를 API 형태로 제공하여 클라이언트(100)의 내부 시스템에 접목하여 서비스를 이용하도록 할 수 있다.
일 실시 예에서, 클라이언트(100)와 애플리케이션 서비스 제공 장치(400)는 메시지를 송수신할 수 있다. 이 때, 클라이언트(100)는 애플리케이션 서비스 제공 장치(400)에게 메시지를 송신할 수 있다. 예를 들어, 메시지는 EDI(Electronic Data Interchange) 메시지를 포함할 수 있다.
애플리케이션 서비스 제공 장치(400)는 메시지에 포함된 클라이언트(100)에 대응하는 인증키에 기반하여 클라이언트(100)를 식별하고, 식별된 클라이언트(100)에 대하여 애플리케이션 패키지에 대한 서비스를 제공할 수 있다. 일 실시예에서, 인증키는 애플리케이션 패키지에 대한 클라이언트(100)에 대응하는 API(Application Programming Interface) 키를 포함할 수 있다.
본 발명에 따르면, 멀티테넌시(Multi-tenancy) 제공을 위해 API 키와 비대칭키암호화(Rivest-Shamir-Adleman, RSA) 방식이 적용될 수 있다.
따라서, 본 발명에 따르면, 애플리케이션 서비스 제공 장치(400)는 여러 회사를 대상으로 ERP, CRM 및 WMS 등의 기업용 서비스를 제공하는 서비스 제공업체와의 EDI/API를 연결할 수 있다. 이에, 국내외 유통업체, 자동차 제조사 등 1개의 기업에 다수의 공급업체가 연결되어 EDI/API를 사용할 경우, 1번 연결된 기업은 다수의 공급업체가 공통적으로 이용할 수 있다.
도 40은 실시 예에 따른 애플리케이션 서비스 제공 장치가 애플리케이션 패키지에 대한 서비스를 제공하는 다른 예를 개시하는 도면
클라이언트(100)는 API 제공부(610), 메시지 관리부(620), 암복호화부(630), 송수신부(640)를 포함하는 에이전트(350), 관리 화면부(650) 및 데이터베이스(660)를 포함할 수 있다. 이 경우, API 제공부(610)는 내부 시스템(예: ERP 시스템)에서 사용할 수 있도록 데이터에 대한 송신 및 수신 기능 및 모니터링을 위한 API를 제공할 수 있다.
또한, 관리 화면부(650)는 내부 시스템 이용 클라이언트별 API 키를 관리하고, 메시지의 송수신 내역을 모니터링하기 위한 화면을 디스플레이할 수 있다.
일 실시 예에서, 애플리케이션 서비스 제공 장치(400)는 클라이언트(100)에게 인증키 관리 및 메시지 송수신 내역을 모니터링하기 위한 사용자 인터페이스(User Interface, UI)를 제공할 수 있다. 이를 통해, 클라이언트(100)의 사용자는 관리 화면부(650)을 통해 메시지의 송수신 문서 처리 이력을 조회하고, 송수신 문서 내용을 조회할 수 있다. 예를 들어, 문서의 처리 내역, 상태 및 처리시간이 조회될 수 있다.
메시지 관리부(620)는 메시지의 관리 및 보관정책에 따라 메시지의 암호화와 삭제를 수행할 수 있다. 또한, 메시지 관리부(620)는 데이터베이스(660)에 메시지 및 송수신 내역 정보를 저장할 수 있다.
암복호화부(630)는 데이터에 대한 암복호화를 수행하고, 데이터에 대한 전자 서명(digital signature) 및 검증(verify)을 수행할 수 있다. 예를 들어, 암복호화부(630)는 RSA 암호화 알고리즘 기반의 암복호화, 서명 및 검증을 수행할 수 있다.
송수신부(640)는 애플리케이션 서비스 제공 장치(400)의 에이전트 어댑터(1350)에게 데이터, 전자 서명 및 인증키를 포함하는 메시지를 송신하고, 에이전트 어댑터(1350)로부터 메시지를 수신할 수 있다.
송수신부(640)는 내부 시스템(예: ERP 시스템)으로부터 정보를 가져와 데이터로 변환하여 에이전트 어댑터(1350)의 송수신부(710)로 송신하거나, 에이전트 어댑터(1350)의 송수신부(710)로부터 수신된 데이터를 변환하여 내부 시스템에 저장하도록 할 수 있다.
일 실시 예에서, 애플리케이션 서비스 제공 장치(400)는 에이전트 어댑터(1350) 및 매니저 서버(2100)를 포함할 수 있다. 에이전트 어댑터(1350)는 송수신부(710), 고객사 식별부(720), 암복호화부(730) 및 포맷 변환부(740)를 포함할 수 있다.
송수신부(710)는 클라이언트(100)의 에이전트(350)로부터 메시지를 수신하거나 에이전트(350)에게 메시지를 송신할 수 있다. 일 실시 예에서, 송수신부(710)는 에이전트(350)의 송수신부(610)로부터 수신한 메시지를 매니저 시스템(2100) 내의 메시지 박스(2110)에 저장하거나, 또는 에이전트 어댑터(1350)에서 설정된 여러 가지 정보를 에이전트(350)의 송수신부(610)가 수신하도록 하고, 그 정보를 메시지 박스(2110)에 저장할 수 있다. 고객사 식별부(720)는 메시지에 포함된 인증키를 이용하여 클라이언트(100)의 내부 시스템을 통해 서비스를 제공받는 고객사를 식별할 수 있다.
암복호화부(730)는 데이터에 대한 암복호화를 수행하고, 데이터에 대한 전자 서명 및 검증을 수행할 수 있다. 예를 들어, 암복호화부(730)는 RSA 암호화 알고리즘 기반의 암복호화, 서명 및 검증을 수행할 수 있다. 포맷 변환부(740)는 복호화된 데이터의 데이터 포맷을 변환할 수 있다. 송수신부(710)는 데이터 포맷이 변환된 메시지를 파트너(200)에게 송신할 수 있다.
도 41은 실시 예에 따른 애플리케이션 서비스 제공 방법의 예를 개시하는 흐름도
클라이언트(100)로부터 클라이언트(100)의 내부 시스템에 대한 고객사의 인증키를 포함하는 메시지를 수신한다(S401).
일 실시 예에서, 상기 메시지는, RSA 암호화 알고리즘 기반의 애플리케이션 서비스 제공 장치(400)의 공개키를 이용하여 암호화된 데이터 및 RSA 암호화 알고리즘 기반의 클라이언트(100)의 개인키를 이용하여 서명된 전자 서명을 더 포함할 수 있다. 예를 들어, 데이터는 EDI 데이터와 같은 거래를 위한 데이터를 포함할 수 있다.
인증키에 기반하여 고객사를 식별한다(S403). 일 실시 예에서, 상기 인증키는 고객사의 식별 정보를 나타내는 API 키를 포함할 수 있다. 예를 들어, API 키는 고객사를 식별하기 위한 고유 코드를 포함할 수 있다.
일 실시 예에서, 애플리케이션 서비스 제공 장치(400)에 미리 저장된 인증키 테이블에 기반하여, 해당 인증키 테이블에 포함된 고객사들에 대한 인증키 리스트와 수신된 메시지에 포함된 인증키를 비교하여 고객사를 식별할 수 있다.
식별된 고객사에 대한 메시지에 기반하여 서비스를 제공한다(S405). 일 실시 예에서, 암호화된 데이터에 대한 복호화를 수행하고, 복호화된 데이터의 데이터 포맷을 변경하여, 해당 데이터를 파트너에게 송신할 수 있다. 즉, 본 발명에 따르면, 여러 고객사를 대상으로 내부 시스템을 통한 서비스를 제공하는 클라이언트(100)의 제휴업체 서비스를 제공할 수 있다.
도 42는 실시 예에 따른 애플리케이션 서비스 제공 방법이 서비스를 제공하는 예를 개시하는 흐름도
RSA 암호화 알고리즘 기반의 애플리케이션 서비스 제공 장치(400)의 개인키를 이용하여, 암호화된 데이터를 복호화한다(S411). 일 실시 예에서, RSA 암호화 알고리즘 기반의 애플리케이션 서비스 제공 장치(400)의 공개키를 이용하여 암호화된 데이터를 애플리케이션 서비스 제공 장치(400)의 개인키를 이용하여 복호화할 수 있다. 일 실시 예에서, 복호화한 데이터를 해쉬(hash)하여 해쉬값을 생성할 수 있다.
RSA 암호화 알고리즘 기반의 클라이언트(100)의 공개키를 이용하여, 복호화된 데이터에 대한 전자 서명을 검증한다(S413). 일 실시 예에서, RSA 암호화 알고리즘 기반의 클라이언트(100)의 개인키를 이용하여 서명된 전자 서명을 클라이언트(100)의 공개키를 이용하여 검증할 수 있다. 일 실시 예에서, 클라이언트(100)가 암호화 전 데이터를 해쉬하여 생성된 해쉬값과 복호화된 데이터를 해쉬하여 생성된 해쉬값이 일치함을 확인할 수 있다.
데이터에 대한 미리 저장된 스키마(schema) 및 미리 저장된 맵핑 스크립트에 기반하여, 복호화된 데이터의 데이터 포맷을 변경한다(S415).
일 실시 예에서, EDI 서비스를 위해서는 두 거래 당사자들 사이의 문서의 매핑(mapping)되어야 하며, 미리 저장된 스키마에 따른 데이터(예: EDI 데이터)에 포함된 바이트나 스트링을 디코딩하여 디코딩된 데이터로 변환하고, 매핑 스크립트에 기반하여 데이터와 변환될 데이터의 스키마들을 기반으로 스키마들을 서로 매핑하며, 데이터 포맷을 변경할 수 있다.
데이터 포맷이 변경된 데이터를 파트너(200)에게 송신한다(S417). 일 실시 예에서, 본 발명에 따르면, 기업 간 거래에 관한 데이터를 표준화하여 거래 당사자 간 전송하여 정보를 전달할 수 있다. 이 경우, 내부 시스템의 서비스를 제공하는 클라이언트(100)에 멀티테넌시로 연결된 고객사에 개별적으로 EDI 시스템을 구축하지 않고 효율적으로 연결을 진행할 수 있다.
도 43은 실시 예에 따른 애플리케이션 서비스 제공 장치가 데이터 형식을 변환하는 예를 개시하는 도면
도시한 예에서 애플리케이션 서비스 제공 장치(300)는 인스턴스 시스템(미도시)과 매니저 시스템(미도시)을 포함할 수 있다. 인스턴스 시스템은 에이전트 어댑터(1350)와 매핑 어댑터(1370)가 설치된 워커노드(예: Node #N)를 포함할 수 있고 클라이언트(100)와 파트너(200)에게 애플리케이션 서비스를 제공할 수 있다.
매니저 시스템(미도시)은 애플리케이션 서비스 매니저(2100)를 포함할 수 있으며, 애플리케이션 서비스 매니저(2100)는 워커노드에 설치된 에이전트 어댑터(1350)으로부터 클라이언트(100)의 에이전트(350)와 파트너(200)의 에이전트(450)에서 수집된 데이터를 얻을 수 있다. 매핑 어댑터(1370)는 클라이언트(100)의 소스 문서 데이터를 언마샬링(unmarshalling)하고 이를 파트너(200)가 필요한 정보로 매핑한 타겟 문서 데이터로 출력할 수 있다.
이에, 본 발명의 실시 예에 따른 애플리케이션 서비스 제공 장치(300)는 에이전트 어댑터(1350), 매핑 어댑터(1370) 및 애플리케이션 서비스 매니저(2100)를 포함할 수 있다.
에이전트 어댑터(1350)는 송수신부(810)를 포함할 수 있다. 송수신부(810)는 클라이언트(100)의 에이전트(350)로부터 소스 문서 데이터를 수신할 수 있다. 예를 들어, 소스 문서 데이터는 텍스트 데이터로 표현될 수 있다. 일 실시 예에서, 에이전트(350)로부터 수신된 소스 문서 데이터는 애플리케이션 서비스 매니저(2100)에 포함된 메시지 박스(2110)에 저장될 수 있다.
맵핑 어댑터(1370)는 역직렬화부(820), 매핑부(830) 및 직렬화부(840)를 포함할 수 있다. 이 경우, 역직렬화부(820)는 미리 저장된 소스 스키마(schema)에 기반하여 제 1 데이터 형식을 갖는 소스 문서 데이터를 소스 구조 데이터로 변환할 수 있다. 매핑부(830)는 미리 저장된 소스 스키마, 미리 저장된 매핑 스크립트 또는 미리 저장된 타겟 스키마 중 적어도 하나에 기반하여 소스 구조 데이터를 타겟 구조 데이터로 변환할 수 있다. 직렬화부(840)는 미리 저장된 타겟 스키마에 기반하여 타겟 구조 데이터를 제 2 데이터 형식을 갖는 타겟 문서 데이터로 변환할 수 있다. 일 실시 예에서, 변환된 타겟 문서 데이터는 메시지 박스(2110)에 저장될 수 있다.
일 실시 예에서, 소스 스키마, 매핑 스크립트 또는 타겟 스키마 중 적어도 하나는 클라이언트(100) 또는 파트너(200)에 제공되는 인스턴스 시스템(1000)의 플랫폼의 그래픽 유저 인터페이스(graphic user interface, GUI)에 대한 클라이언트(100) 또는 파트너(200)의 사용자 입력에 기반하여 생성될 수 있으며, 에이전트 어댑터(1350)를 통해 수신되어 메시지 박스(2110)에 미리 저장될 수 있다.
에이전트 어댑터(1350)는 제 1 데이터 형식을 갖는 소스 문서 데이터로부터 변환된 제 2 데이터 형식을 갖는 타겟 문서 데이터를 메시지 박스(2110)로부터 전달 받아 파트너(200)의 에이전트(450)로 송신할 수 있다.
도 44는 실시 예에 따른 애플리케이션 서비스 제공 장치가 스키마 및 매핑 스크립트를 사용하여 데이터 형식을 변환하는 예를 개시하는 도면
역직렬화부(820)는 미리 저장된 소스 스키마에 기반하여 제 1 데이터 형식을 갖는 소스 문서 데이터를 소스 구조 데이터로 변환할 수 있다. 일 실시 예에서, 제 1 데이터 형식은 제 1 데이터 포맷 또는 제 1 데이터 구조 중 적어도 하나를 포함할 수 있다.
역직렬화부(820)는 직렬화의 반대로 소스 문서 데이터(예: 텍스트)를 소스 구조 데이터(즉, 내부 구조)로 변환할 수 있다. 다시 말해, 역직렬화부(820)는 소스 문서 데이터로부터 소스 구조 데이터를 파싱(parsing)할 수 있다.
즉, 역직렬화부(820)는 소스 문서 데이터에 대한 소스 스키마의 구조(structure) 정보와 주석(annotation) 정보에 기반하여 소스 문서 데이터(즉, 원본 데이터)를 매핑 가능한 내부 데이터 구조를 만들기 위해 역직렬화(파싱)를 수행할 수 있다.
매핑부(830)는 미리 저장된 소스 스키마, 미리 저장된 매핑 스크립트 또는 미리 저장된 타겟 스키마 중 적어도 하나에 기반하여 소스 구조 데이터를 타겟 구조 데이터로 변환할 수 있다. 일 실시 예에서, 매핑 스크립트는 프로그래밍 언어의 문법을 나타내는 문장(statement) 정보 또는 특정한 결과값을 나타내는 표현식(expression) 정보 중 적어도 하나를 포함할 수 있다.
일 실시 예에서, 매핑부(830)는 해당 소스 문서 데이터의 구조(트리) 및 이름(Identifier)를 포함하는 구조 정보를 이용하여 소스 구조 데이터를 타겟 구조 데이터로 변환하는 매핑을 수행할 수 있다.
일 실시 예에서, 소스 스키마, 매핑 스크립트 또는 타겟 스키마 중 적어도 하나는 매핑 프로그램에 포함되어 저장될 수 있다. 매핑부(830)는 매핑 프로그램에 기반하여 소스 구조 데이터를 타겟 구조 데이터로 변환할 수 있으며, 이때 소스 스키마와 타겟 스키마의 주석 정보는 직렬화와 역직렬화에서만 사용되고, 매핑 프로그램에서는 사용되지 않는다. 이는, 매핑 스크립트에 기반한 매핑은 소스 스키마와 타겟 스키마의 스키마 노드 간 데이터의 매핑만을 집중적으로 수행하기 위함이다.
즉, 본 발명에 따르면, 매핑 스트립트와 스키마의 주석 정보의 역할을 의도적으로 분리 (SoC - Separation of Concerns)하여, 매핑 스크립트는 직렬화와 역직렬화와는 관계 없이 매핑에만 집중적으로 사용되고, 스키마의 주석 정보는 직렬화와 역직렬화에만 집중적으로 사용됨으로써, 효과적으로 전문언어(DSL) 기반 매핑을 지원할 수 있다.
또한, 본 발명에 따르면, 직렬화와 역직렬화는 데이터 형식(즉, 데이터 포맷 또는 데이터 구조 중 적어도 하나)을 변환하기 위해 수행되며, 매핑은 데이터 형식의 변환에 관련 없이 소스 구조 데이터를 타겟 구조 데이터로 변환하기 위해 수행될 수 있다.
직렬화부(840)는 미리 저장된 타겟 스키마에 기반하여 타겟 구조 데이터를 제 2 데이터 형식을 갖는 타겟 문서 데이터로 변환할 수 있다. 일 실시 예에서, 제 2 데이터 형식은 제 2 데이터 포맷 또는 제 2 데이터 구조 중 적어도 하나를 포함할 수 있다. 즉, 예를 들어, 타겟 문서 데이터는 소스 문서 데이터와 데이터 포맷이 다를 수 있다. 또한, 다른 예를 들어, 타겟 문서 데이터는 소스 문서 데이터와 데이터 포맷은 동일하지만 데이터 구조가 다를 수 있다.
구체적으로, 직렬화부(840)는 미리 저장된 타겟 스키마의 구조 정보와 주석 정보에 기반하여 타겟 구조 데이터를 제 2 데이터 형식을 갖는 타겟 문서 데이터(예: 텍스트)로 변환하는 직렬화를 수행할 수 있다.
예를 들어, 직렬화부(840)는 내부의 프로그램 언어 변수에 담긴 타겟 구조 데이터를 EDI, XML 또는 JSON 등의 타겟 문서 데이터로 변환할 수 있다.
따라서, 본 발명에 따르면, 주석 정보를 활용하여 다양한 데이터 형식의 문서를 직렬화/역직렬화하기 위한 스키마 정의하기 위한 전문언어(Domain Specific Language, DSL)가 사용될 수 있다.
또한, 본 발명에 따르면, 비교적 간단한 프로그래밍 언어의 문법으로 다양한 매핑 요구사항 해결할 수 있는 자체 매핑 스크립트 언어가 제공될 수 있다.
또한, 본 발명에 따르면, 다양한 데이터 형식의 문서에 대해 통일된 스키마 정의 문법을 제공할 수 있다.
또한, 본 발명에 따르면, 비교적 간단한 매핑 스크립트 언어와 Lua 커스텀 함수 기능을 통해 간단한 매핑부터 복잡한 매핑까지 만들 수 있는 기능을 제공할 수 있다.
또한, 본 발명에 따르면, 이러한 기능을 DSL로 제공함으로써, 손쉽게 기능을 개발할 수 있도록 할 수 있다.
도 45는 실시 예에 따른 스키마에 기반한 역직렬화와 직렬화의 예를 개시하는 도면
일 실시 예에서, 문서 데이터에 대한 스키마에 기반하여, 문서 데이터를 구조 데이터로 변환하는 역직렬화를 수행할 수 있다. 예를 들어, 문서 데이터는 EDI 문서, XML 문서, JSON 문서 등 다양한 문서 데이터를 포함할 수 있다. 이 경우, 역직렬화는 언마샬링(unmarshaling) 또는 이와 동등한 기술적 의미를 갖는 용어로 지칭될 수 있다. 일 실시 예에서, 역직렬화를 위한 문서 데이터는 소스 문서 데이터를 포함하고, 구조 데이터는 소스 구조 데이터를 포함할 수 있다.
일 실시 예에서, 문서 데이터에 대한 스키마에 기반하여, 구조 데이터를 문서 데이터로 변환하는 직렬화를 수행할 수 있다. 이 경우, 직렬화는 마샬링(marshaling) 또는 이와 동등한 기술적 의미를 갖는 용어로 지칭될 수 있다. 일 실시 예에서, 직렬화를 위한 구조 데이터는 타겟 구조 데이터를 포함하고, 문서 데이터는 타겟 문서 데이터를 포함할 수 있다.
일 실시 예에서, 스키마는 문서 데이터에 대한 구조 정보 또는 주석 정보 중 적어도 하나를 포함할 수 있다. 구조 정보는 문서 데이터의 구조 데이터를 나타내며, 데이터 유형(type)으로 정의되는 데이터를 포함할 수 있다. 예를 들어, 데이터 유형은 Primitive, Record, Array 또는 TypeRef 중 적어도 하나를 포함할 수 있다.
Primitive는 string, int, long, double, decimal과 같은 원시 유형을 지정할 수 있다. 예를 들어, String은 문자열 데이터 유형을 나타내고, Int는 정수 데이터 유형을 나타낸다. Record는 하위에 또 다른 유형들이 올 수 있으며, 서로 다른 유형의 데이터의 모음으로 구성될 수 있다. Array는 특정 유형에 대한 배열로 정의될 수 있으며, 서로 동일한 유형의 데이터의 모음으로 구성될 수 있다. TypeRef는 이미 정의되어 있는 Record를 참조해서 가져올 수 있다.
일 실시 예에서, 주석 정보는 데이터 유형에 대응되고, 문서 데이터에서 해당 데이터로 인지(파싱, 역직렬화)할 때 사용되는 정보를 포함할 수 있다. 예를 들어, @XmlElement(name=””는 주석을 나타낼 수 있으며, @다음에 기재된 XmlElement은 해당 주석의 이름을 나타내고, name이라는 이름의 요소(element)를 포함하고, 이에 대한 값은 “employee”일 수 있다.
또한, 예를 들어, 만약, @JsonProperty(name=””주석 정보가 스키마에 포함된 경우, 마샬링 시 해당 주석 정보에 따라 JSON 문서의 박스 표시에 id가 아닌 employee-id로 표시될 수 있다. 반면, @JsonProperty(name=””주석 정보가 스키마에 포함되지 않은 경우, 마샬링 시 스키마의 int id; 구조 정보에 따라 JSON 문서의 박스 표시에 id로 기재될 수 있다. 일 실시 예에서, 이러한 스키마는 프로그래밍 언어의 구문을 정의할 수 있는 문법 표현식인 BNF(Backus-Naur Form)로 정의될 수 있다.
도 46은 실시 예에 따른 매핑 스크립트의 예를 개시하는 도면
매핑 스크립트는 타겟 스키마의 형태에 맞게 소스 구조 데이터를 타겟 구조 데이터로 변환하기 위해 사용될 수 있다. 일 실시 예에서, 매핑 스크립트는 프로그래밍 언어의 문법을 나타내는 문장 정보 또는 특정한 결과값을 나타내는 표현식 정보 중 적어도 하나를 포함할 수 있다.
여기서, 문장 정보는 매핑 스크립트의 프로그래밍 언어의 각 라인(line)을 나타낼 수 있다. 즉, 매핑 스크립트는 문장 정보로 구성될 수 있다. 일 실시 예에서, 문장 정보는 소스 스키마의 구조 정보와 타겟 스키마의 구조 정보 간 대응관계를 나타낼 수 있다.
예를 들어, 문장 정보는 MapStmt, LoopStmt, IfStmt, MatchStmt, LoopVarSetStmt 및 LoopVarIncStmt를 포함할 수 있으나, 이에 제한되지 않고 다양한 문장 정보를 포함할 수 있다. 이 경우, MapStmt는 매핑을 수행하는 문장 정보를 포함할 수 있다. LoopStmt는 반복문을 나타내는 문장 정보를 포함할 수 있으며, 일반적인 프로그래밍 언어의 for 문과 같은 기능을 수행할 수 있다. IfStmt는 조건문을 나타내는 문장 정보를 포함할 수 있으며, 일반적인 프로그래밍 언어의 if 문과 같은 기능을 수행할 수 있다. MatchStmt는 조건 제어문을 나타내는 문장 정보를 포함할 수 있으며, 일반적인 프로그래밍 언어의 switch 문과 같은 기능을 수행할 수 있다. LoopVarSetStmt는 Loop안에서 사용할 변수를 선언할 수 있다. LoopVarIncStmt는 특정 변수(예: LoopVar)를 증가시키는 문장 정보를 포함할 수 있다.
또한, 표현식 정보는 사용할 값을 가져올 곳을 지정할 수 있으며, 평가(evaluate)를 통해 하나의 값으로 환원되는 표현식을 나타낼 수 있다. 예를 들어, 표현식 정보는 Constant, Path, Custom Function 및 LoopVar를 포함할 수 있으나, 이에 제한되지 않고 다양한 표현식 정보를 포함할 수 있다. 이 경우, Constant는 문자열(String)이나 숫자(Number)를 직접 지정하여 나타낼 수 있다. Path는 소스(Source)의 특정 경로(Path)를 나타낼 수 있다. Custom Function은 사용자에 의해 생성된 함수(function)를 나타낼 수 있다. LoopVar Loop 반복문의 변수를 나타내며, 예를 들어 #i와 같은 LoopVar를 나타낼 수 있다.
일 실시 예에서, 매핑 스크립트는 매핑 프로그램에 포함될 수 있다. 일 실시 예에서, 이러한 매핑 스크립트는 프로그래밍 언어의 구문을 정의할 수 있는 문법 표현식인 BNF로 정의될 수 있다.
도 47은 실시 예에 따른 애플리케이션 서비스 제공 방법이 데이터 형식을 변환하는 예를 개시하는 흐름도
클라이언트(100)로부터 제 1 데이터 형식을 갖는 소스 문서 데이터를 수신한다(S501). 예를 들어, 제 1 데이터 형식은 제 1 데이터 포맷 또는 제 1 데이터 구조 중 적어도 하나를 포함할 수 있다. 이 경우, 제 1 데이터 포맷은 EDI, 플랫 파일(flat file), JSON 또는 XML 포맷을 포함할 수 있다.
예를 들어, EDI 포맷은 표준화되어 있는 X.12 또는 EDIFACT 포맷을 포함할 수 있으나, 이에 제한되지 않고 다양한 포맷을 포함할 수 있다. 일 실시 예에서, 소스 문서 데이터가 EDI 데이터인 경우, 소스 스키마는 EDI 스키마로서 SEF 표준의 EDI 포맷을 이용하거나 EXF 등의 EDI 포맷을 이용할 수 있다.
또한, 플랫 파일은 구조적 상관관계가 없는 레코드들이 포함된 파일을 의미할 수 있다. 예를 들어, 플랫 파일은 모든 문서 처리나, 다른 구조 문자들 또는 마크업들이 제거된 상태의 텍스트 문서를 포함할 수 있다.
제 1 데이터 형식을 갖는 소스 문서 데이터를 제 2 데이터 형식을 갖는 타겟 문서 데이터로 변환한다(S503).
일 실시 예에서, 소스 문서 데이터에 대한 미리 저장된 소스 스키마에 기반하여, 소스 문서 데이터를 소스 구조 데이터로 변환하고, 소스 구조 데이터 및 타겟 구조 데이터에 대한 미리 저장된 매핑 스크립트에 기반하여, 소스 구조 데이터를 타겟 구조 데이터로 변환하며, 타겟 문서 데이터에 대한 미리 저장된 타겟 스키마에 기반하여 타겟 구조 데이터를 제 2 데이터 형식을 갖는 타겟 문서 데이터로 변환할 수 있다.
일 실시 예에서, 구체적으로, 미리 저장된 소스 스키마에 포함된 소스 문서 데이터에 대한 구조(structure) 정보 또는 구조 정보에 대한 주석(annotation) 정보 중 적어도 하나에 기반하여, 제 1 데이터 형식을 갖는 소스 문서 데이터를 소스 구조 데이터로 변환하는 역직렬화를 수행할 수 있다.
일 실시 예에서, 미리 저장된 소스 스키마에 포함된 소스 문서 데이터에 대한 구조 정보, 미리 저장된 매핑 스크립트에 포함된 프로그래밍 언어의 문장(statement) 정보, 표현식(expression) 정보 또는 미리 저장된 타겟 스키마에 포함된 타겟 문서 데이터에 대한 구조 정보 중 적어도 하나에 기반하여 소스 구조 데이터를 타겟 구조 데이터로 변환하는 매핑(mapping)을 수행할 수 있다.
일 실시 예에서, 미리 저장된 타겟 스키마에 포함된 타겟 문서 데이터에 대한 구조 정보 또는 구조 정보에 대한 주석 정보 중 적어도 하나에 기반하여, 타겟 구조 데이터를 제 2 데이터 형식을 갖는 타겟 문서 데이터로 변환하는 직렬화를 수행할 수 있다.
제 2 데이터 형식을 갖는 타겟 문서 데이터를 파트너(200)에게 송신한다(S505). 예를 들어, 제 2 데이터 형식은 제 2 데이터 포맷 또는 제 2 데이터 구조 중 적어도 하나를 포함할 수 있다. 이 경우, 제 2 데이터 포맷은 EDI, 플랫 파일, JSON 또는 XML 포맷을 포함할 수 있으나, 이에 제한되지 않고 다양한 포맷을 포함할 수 있다.
이하에서는 클라이언트 또는 파트너가 워크스페이스에서 다운받은 애플리케이션 패키지를 기반으로 필요한 애플리케이션을 개발할 수 있는 실시 예를 개시한다.
클라이언트 또는 파트너는 인스턴스 시스템의 플랫폼의 자신의 워크스페이스에 접속하고, 플랫폼이 제공하는 그래픽 유저 인터페이스 (graphic user interface; GUI) 기반으로 여러 가지 업무 또는 거래 등에 필요한 애플리케이션을 개발할 수 있다.
예를 들어 클라이언트가 서비스로서 EDI 정보를 전달하는 애플리케이션을 개발할 경우, 클라이언트는 파트너와 표준화된 거래 정보를 매핑할 수 있는 매핑 프로그램을 개발하고 이를 기반으로 파트너에 정보를 제공할 수 있다. 또는 이렇게 개발한 매핑 프로그램 자체를 매니저 시스템의 플랫폼에서 판매할 수 있다.
여기서는 매핑 프로그램을 예시하였으나 클라이언트 또는 파트너는 운영하는 사업의 종류, 거래의 종류 등에 따라 서로 다른 정보 또는 문서의 매핑이 요구된다. 여기에서, 매핑이라 함은 A 스키마(schema)를 가지는 a 데이터(소스)에서 B 스키마를 가지는 b 데이터(타겟)로 변환하는 과정을 의미한다. 여기에서, 스키마는 데이터의 구조를 나타내며, 각 이름을 가진 노드들이 계층적인 구조를 가진다.
이러한 사업의 종류가 매우 다양하기 때문에, 여기의 실시 예는 사용자에게 EDI 정보를 매핑할 수 있는 매핑 프로그램을 매우 용이하게 개발할 수 있는 예를 개시한다.
실시 예에 따른 플랫폼은 매핑 프로그램을 개발할 수 있는 환경과 인터페이스를 제공할 수 있는데 이에 대해 상세히 개시하면 다음과 같다.
도 48은 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면이다.
본 발명의 매핑 플로우 개발을 위한 사용자 인터페이스는 개발 도구 팔레트(901)와 개발 GUI 코드 영역(902)을 포함할 수 있다.
여기에서, 개발 도구 팔레트(901)는 매핑 프로그램에서 사용되는 언어의 구조 및 함수들에 대응하는 그래픽 블록들을 포함할 수 있다. 즉, 개발 도구 팔레트(901)는 매핑 프로그램에서 사용되는 키워드의 목록 전부를 포함할 수 있다. 예를 들어, 개발 도구 팔레트(901)는 매핑 프로그램에서 사용되는 “Statements”, “MAP”, "If", “Then”, “Loop for”, “LoopVar”, “LoopVar ++”, “Match”와 같은 제어 구조 및 함수들에 대응하는 그래픽 블록을 포함할 수 있다. 다만, 본 도면에 포함된 함수들은 예시일 뿐으로 다른 함수들이 포함될 수 있음은 물론이다.
일 실시 예에서, 애플리케이션 서비스 제공 방법은 개발 도구 팔레트(901) 및 개발 GUI 코드 영역(902)을 포함하는 사용자 인터페이스를 제공할 수 있다. 사용자 인터페이스 내에서 사용자는 개발 도구 팔레트(901)에 포함된 그래픽 블록을 선택한 뒤 개발 GUI 코드 영역(902)으로 드래그 앤 드롭(drag & drop)할 수 있다.
예를 들어, 사용자 인터페이스가 사용자로부터 제 1 함수(예를 들어, “Statements”블록)의 그래픽 블록을 선택한 뒤 개발 GUI 코드 영역으로 드래그 앤 드롭하는 입력 신호(903a)를 수신하는 경우, 제 1 함수의 그래픽 블록을 개발 GUI 코드 영역(902)에서 출력할 수 있다. 이때, 드래그 앤 드롭하는 입력 신호는 예시일 뿐으로 사용자로부터 수신하는 다른 기 설정된 입력 신호를 포함할 수 있다.
여기에서, “Statements” 블록은 다른 블록들을 순차적으로 포함하는 블록으로 매핑 프로그램의 최상위 블록이어야 한다. 즉, “Statements” 블록은 매핑 프로그램의 시작과 끝을 포함하는 블록에 대응한다.
이후, 사용자 인터페이스가 사용자로부터 제 2 함수(예를 들어, “LoopVar”블록)의 그래픽 블록을 선택한 뒤 개발 GUI 코드 영역(902)으로 드래그 앤 드롭하는 입력 신호(903b)를 수신하는 경우, 제 2 함수의 그래픽 블록을 개발 GUI 코드 영역(902)에서 출력할 수 있다. 이때, 개발 GUI 코드 영역(902)은 자동으로 제 2 함수를 제 1 함수 안에 포함시켜 구성할 수 있다.
뿐만 아니라, 개발 GUI 코드 영역은 제 2 함수의 그래픽 블록에 포함된 파라미터의 입력 칸을 그대로 출력할 수 있다. 상술한 “LoopVar”블록을 참고하면, 개발 도구 팔레트에서 “LoopVar”블록은 “Loop for”블록에서 쓰일 루프변수를 선언하는 블록으로 “변수의 이름”과 “초기 값”을 정해야 한다. 이에 따라, “LoopVar”블록의 파라미터의 입력 칸이 2개(변수의 이름, 초기 값)기 때문에, 개발 GUI 코드 영역에서도 “LoopVar”블록을 출력하면서, 파라미터의 입력 칸을 그대로 출력할 수 있다.
이후, 사용자는 “LoopVar”블록의 파라미터의 입력 칸에 파라미터를 직접 입력할 수 있다. 예를 들어, 사용자는 “LoopVar”블록에 변수이름을 “k”및 초기 값을 “1”로 입력할 수 있다. 이에 따라, 개발 코드는 반복문에서 k라는 반복 변수를 선언하고, 초기 값으로 1을 할당할 수 있다.
이후, 사용자 인터페이스가 사용자로부터 제 3 함수(예를 들어, “Loop for” 블록)의 그래픽 블록을 선택한 뒤 개발 GUI 코드 영역(902)으로 드래그 앤 드롭하는 입력 신호(미도시)를 수신하는 경우, 제 3 함수의 그래픽 블록을 개발 GUI 코드 영역(902)에서 출력할 수 있다. 이때, 개발 GUI 코드 영역(902)은 자동으로 제 3 함수를 제 1 함수 안에 제 2 함수 다음으로 포함시켜 구성할 수 있다.
이와 같이 본 발명의 매핑 플로우 개발을 위한 사용자 인터페이스는 사용자가 개발 도구 팔레트(901)에 포함된 그래픽 블록을 이용하여 개발 GUI 코드 영역(902)에서 코드 구조를 형성하는데 시각적인 도움을 줄 수 있다. 이를 통해 사용자가 개발 스크립트에 친숙하지 않아도 비교적 간편하게 매핑 프로그램을 정의할 수 있다는 장점이 있다.
도 49는 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면이다.
본 발명의 매핑 플로우 개발을 위한 사용자 인터페이스는 개발 GUI 코드 영역(902)에 대응하는 개발 소스 코드(905)를 제공할 수 있다.
보다 상세하게는, 애플리케이션 서비스 제공 방법은 개발 GUI 코드 영역(902)에 출력된 함수에 대응하는 소스 코드들을 개발 소스 코드 영역(904) 상에 출력할 수 있다. 즉, 상술한 실시 예를 참고하면, 사용자가 개발 도구 팔레트에 포함된 그래픽 블록을 선택해 개발 GUI 코드 영역(902)에 함수를 출력하고, 함수에 대응하는 파라미터를 입력한 경우, 애플리케이션 서비스 제공 방법은 개발 소스 코드 영역(904) 상에 함수 및 파라미터에 대응하는 소스 코드(905)를 생성하여 출력할 수 있다.
일 실시 예에서, 사용자가 소스 코드(905)를 직접 수정한 경우 매핑 플로우 개발을 위한 사용자 인터페이스는 실시간으로 소스 코드를 반영하여 개발 GUI 코드 영역(902)에 수정한 소스 코드(905)에 대응하는 그래픽 블록을 출력할 수 있다.
이를 통하여, 개발자들은 개발 도구 팔레트와 개발 GUI 코드 영역(902)을 통하여 매핑 프로그램을 시각적으로 구성하고 이를 소스 코드(905)로 변환하여 확인할 수 있다.
다만, 프로그래밍에 익숙하지 않은 개발자는 본 발명의 사용자 인터페이스를 통하여 손쉽게 접근할 수 있으나, 프로그래밍에 익숙한 개발자에게는 프로그램을 압축적으로 보여주는 소스 코드 방식이 보다 더 익숙할 수 있고, 다량의 매핑이 반복적으로 수행되는 매핑 프로그램의 흐름에서는 소스 코드 방식이 보다 생산성이 높을 수 있다.
즉, 본 발명을 통해 개발자는 개인의 성향에 따라 소스 코드 방식의 개발 소스 코드 영역(904)을 직접 수정하거나 개발 GUI 코드 영역(902)의 그래픽 블록을 드래그 앤 드롭하는 방식을 선택적으로 이용할 수 있다.
이러한 GUI 기반의 손쉬운 매핑 프로그램 정의 도구는 사용자 친화적인 인터페이스와 시각적 프로그래밍 방식을 통해 개발자들이 복잡한 매핑 로직을 쉽게 구현하고 관리할 수 있도록 지원한다.
도 50은 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면이다.
일 실시 예에서, 애플리케이션 서비스 제공 방법은 GUI 기반의 라이브러리를 활용하여 매핑 플로우 개발을 위한 사용자 인터페이스(User Interface, UI)를 제공할 수 있다. 이때, 매핑 플로우를 개발 또는 편집하기 위한 GUI 도구로 Google 사의 Blockly 라이브러리를 활용할 수 있으나 이에 한정되는 것은 아니다.
보다 상세하게는, 매핑 플로우 개발을 위한 사용자 인터페이스는 매핑 프로그램 편집 화면 및 함수 편집 화면을 포함할 수 있다.
본 도면은 매핑 프로그램 편집 화면을 나타낸다. 일 실시 예에서, 매핑 프로그램 편집 화면은 매핑 프로그램(mapping program) 영역(906), 소스 스키마(Source Schema) 영역(907), 타겟 스키마(Target Schema) 영역(908) 및 매핑 표현(mapping expression) 영역(909)을 포함할 수 있다.
여기에서, 매핑 프로그램 영역(906)은 상술한 개발 도구 팔레트 및 개발 GUI 코드 영역을 포함할 수 있다. 즉, 매핑 프로그램 영역(906)에서 사용자는 필요한 블록(statement)들을 흐름 순으로 배치하여 복잡한 소스 스키마와 타겟 스키마 간의 변환을 수행할 수 있도록 한다.
일 실시 예에서, 매핑 프로그램 영역(906)은 소스 코드 영역을 출력하기 위한 아이콘(910)을 포함할 수 있다. 사용자가 아이콘(910)을 선택하는 경우, 사용자 인터페이스는 매핑 프로그램 영역(906) 내에 포함된 개발 GUI 코드에 대응하는 소스 코드를 출력하기 위한 소스 코드 영역 팝업 창을 출력할 수 있다. 여기에서, 소스 코드 영역 팝업 창은 상술한 개발 소스 코드 영역을 포함할 수 있다.
또한, 일 실시 예에서, 사용자는 매핑 프로그램 영역(906) 안에 출력 중인 개발 GUI 코드 중 맵(MAP) 블록을 선택할 수 있다. 이에 따라, 사용자 인터페이스는 맵 블록에 대응하는 소스 스키마 및 타겟 스키마를 각각 소스 스키마 영역(907) 및 타겟 스키마 영역(908)에 출력할 수 있다.
보다 상세하게는, 소스 스키마 영역(907)은 변환하기 전의 데이터 스키마에 대한 정보를 나타낸다. 일 실시 예에서, 사용자는 소스 스키마에 대한 정보를 추가하거나 삭제할 수 있다.
타겟 스키마 영역(908)은 변환 후의 데이터 스키마에 대한 정보를 나타낸다.
소스 스키마 영역(907)과 타겟 스키마 영역은 소스 스키마와 타겟 스키마 노드 간의 연결을 쉽게 할 수 있도록 한다.
또한, 일 실시 예에서 사용자 인터페이스는 소스 스키마에 포함된 노드와 타겟 스키마에 포함된 노드의 매핑 라인(line)을 출력할 수 있다. 이를 통하여, 사용자는 소스 스키마의 노드가 어떤 타겟 스키마의 노드와 매핑되는지 여부를 시각적으로 알 수 있다.
또한, 다른 일 실시 예에서 사용자 인터페이스는 소스 스키마에 포함된 노드를 선택한 뒤 타겟 스키마에 포함된 노드로 드래그 앤 드롭하는 입력 신호를 수신하는 경우, 자동으로 해당 매핑 식을 매핑 표현 영역(909)에 출력할 수 있다.
매핑 표현 영역(909)은 실제 노드 간의 매핑들을 수행하는 영역으로 앞선 블록(Statement)들 중 매핑 블록을 선택할 때 표시되어 각 노드 간의 매핑 식을 여러 개 삽입할 수 있도록 한다. 즉, 매핑 표현의 세부 값(value)들을 설정하는 영역에 대응한다. 이에 대하여는 후술하도록 한다.
도 51은 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면이다.
매핑 표현 영역(909)은 실제 노드 간의 매핑을 수행하는 영역에 대응한다. 일 실시 예에서, 사용자가 매핑 프로그램 영역(906)에 포함된 블록들 중 맵 블록(Map block)을 선택하면, 사용자 인터페이스는 매핑 표현 영역(909) 상에 매핑 블록에 포함되는 경로(Path), 데이터 유형(예를 들어, String), 함수(function), 입력 값(Arguments)을 입력할 수 있는 GUI 블록을 제공할 수 있다.
이에 따라, 사용자는 함수 블록을 선택하여 매핑 블록에서 사용되는 다양한 함수 중 하나를 선택할 수 있다. 매핑 블록에서 사용되는 다양한 함수에 대하여는 후술하도록 한다.
도 52는 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면이다.
일 실시 예에서, 매핑 플로우 개발을 위한 사용자 인터페이스는 스키마 편집 화면을 제공할 수 있다. 여기에서, 스키마 편집 화면은 스키마 편집 영역(911)과 주석 영역(912)을 포함할 수 있다.
상술한 바와 같이 스키마 편집 영역(911)은 사용자가 매핑 플로우에 사용되는 스키마를 편집하는 영역으로, 본 도면에서는 예시를 나타낸다. 여기에서, 스키마 편집 영역(911)은 데이터의 구조를 나타내며, 이름을 가진 노드들의 계층적인 구조를 나타낼 수 있다. 여기에서, 각 노드들은 유형(Type)으로 Int, String 등을 가질 수 있다. 예를 들어, 사용자는 매핑 프로그램 영역에서 샘플 노드를 작성할 수 있으며, 각각 노드 별로 데이터 유형이나 구조를 설정할 수 있다. 예를 들어, “String”은 문자열 데이터 유형을 나타내고, “Int”는 정수 데이터 유형을 나타낸다.
주석(Annotation) 영역(912)은 데이터의 계층적인 구조 외에 해당 데이터가 텍스트로 표현될 때(직렬화) 필요한 정보를 편집하는 영역에 대응한다. 또한, 주석 영역(912)은 데이터의 계층적인 구조 외에 텍스트에서 해당 데이터로 인지(파싱, 역직렬화)할 때에 추가적으로 필요한 정보를 편집하는 영역에 대응한다. 이에 따라, 주석 영역(912)은 주석 리스트(913)를 포함할 수 있다. 여기에서, 주석 리스트(913)는 주석 이름과 문서 유형(Document Type)을 포함할 수 있다.
이때, 각 주석은 노드 별로 여러 개 추가될 수 있으며, 같은 이름의 주석이 여러 개 추가될 수 없다. 각 주석은 문서 유형(XML, JSON)에 따라 여러 종류가 있으며, 각 주석 별로 고유한 속성(argument)을 가질 수 있다.
예를 들어, “ZmlAttribute”는 해당 노드가 XML로 직렬화 또는 역직렬화될 때, 이 노드는 XML의 element가 아닌 Attribute임을 나타낼 수 있다.
또한, 주석 영역(912)은 사용자 주석 리스트(914)를 더 포함할 수 있다. 여기에서, 사용자 주석 리스트(914)는 기존의 주석에 대응하는 고유 속성(argument)으로 name과 namespace을 더 추가할 수 있으나 필수 값은 아니다. 즉, name과 namespace 모두 선택적(optional)으로 추가할 수 있다. 여기에서, name은 해당 argument의 역할이나 의미를 설명하기 위해 사용될 수 있으며, namespace는 속성이 속하는 논리적인 그룹을 식별하기 위해 URI(Uniform Resource Identifier) 형식으로 표현될 수 있다. 상술한 예를 들어, “XMLAttribute”에서 추가 속성으로 name은 XML Attribute 이름이 노드 이름과 다를 경우 지정할 수 있으며, namespace는 해당 XML Attribute가 특정 XML 네임스페이스에 속할 경우 지정할 수 있다.
이들은 이후 XML 또는 JSON과의 상호작용에서 사용되며 데이터를 직렬화하거나 역직렬화하는 과정에서 어떤 멤버가 어떤 방식으로 처리되어야 하는지를 나타낼 수 있다.
도 53은 개시한 실시 예 중 매핑 플로우 개발을 위한 사용자 인터페이스를 제공하는 예를 개시한 도면이다.
상술한 바와 같이 사용자는 매핑 블록에 포함되는 함수를 커스터마이징(customizing)할 수 있다. 매핑 프로그램에서 어떤 데이터를 소스 스키마에서 타겟 스키마로 매핑하려고 할 때 필요한 함수를 만들어 매핑 표현 영역 안에서 사용할 수 있다.
일 실시 예에서, 매핑 플로우 개발을 위한 사용자 인터페이스가 제공하는 함수 편집 화면은 함수 리스트 영역(915)과 편집 영역(916)을 포함할 수 있다.
함수 리스트 영역(915)은 사용자가 함수를 커스터마이징(customizing)할 수 있는 영역을 나타낸다. 예를 들어, 사용자는 함수를 생성하고 함수에 대한 파라미터의 개수를 설정할 수 있다. 예를 들어, “concat”함수는 문자열을 이어 붙이는 역할을 수행하기 때문에 주어진 문자열들을 하나로 합쳐서 새로운 문자열을 생성하는 함수이다. 이에 따라, “”함수는 파라미터로 2개의 문자열을 입력받을 수 있다.
함수 편집 화면에 포함된 +버튼을 통해 사용자는 함수 리스트에 함수를 추가할 수 있다. 또한, 편집 버튼을 통해 함수 리스트 영역에 출력된 함수들을 편집할 수 있고, 삭제 버튼을 통해 함수 리스트 영역(915)에 출력된 함수들을 삭제할 수 있다.
편집 영역(916)은 함수 리스트 영역(915)에서 선택된 함수에 대한 정보를 편집하는 영역에 대응한다.
여기에서, 각 함수들은 자체적인 동작을 수행하며, 프로그래밍이나 데이터 처리 작업에서 유용하게 활용될 수 있다. 사용자는 실제 사용되는 언어나 컨텍스트에 따라 다른 구현 방식과 문법으로 함수를 생성할 수 있다.
도 54는 개시한 실시 예 중 애플리케이션 서비스 제공 방법의 일 예를 개시한 도면이다.
일 실시 예에서, 애플리케이션 서비스 제공 방법은 개발 도구 팔레트 및 GUI 블록 영역을 포함하는 사용자 인터페이스를 제공할 수 있다(S601). 이에 대하여는 도 15 내지 도 19, 및 도 48에서 상술한 내용을 참고하도록 한다.
일 실시 예에서, 애플리케이션 서비스 제공 방법은 사용자로부터 개발 도구 팔레트에 포함된 제 1 그래픽 블록을 선택하는 신호를 수신함에 따라, 제 1 그래픽 블록에 대응하는 제 1 함수 블록을 생성할 수 있다(S603). 이때, 개발 도구 팔레트는 적어도 하나의 그래픽 블록을 포함할 수 있다. 예를 들어, 사용자는 개발 도구 팔레트에 포함된 적어도 하나의 그래픽 블록 중 하나를 선택한 뒤 드래그(drag)하여 개발 GUI 코드 영역 상에 드롭(drop)할 수 있다.
일 실시 예에서, 애플리케이션 서비스 제공 방법은 생성된 제 1 함수 블록을 GUI 블록 영역에 출력할 수 있다(S605). 이때, 애플리케이션 서비스 제공 방법은 GUI 블록 영역에 포함된 함수 블록에 대응하는 소스 코드를 소스 코드 영역에 출력할 수 있다. 일 실시 예에서, 사용자로부터 소스 코드를 수정하는 신호를 수신하는 경우, 애플리케이션 서비스 제공 방법은 실시간으로 GUI 블록 영역에 출력 중인 함수 블록을 수정하되, 함수 블록은 소스 코드에 기초하여 수정되는 것을 특징으로 한다. 이에 대하여는 도 49에서 상술한 내용을 참고하도록 한다.
110, 120, 130, 310: 클라이언트
200, 320: 파트너
300: 클라이언트 또는 파트너
350: 에이전트
351: 에이전트 제어처리부
353: 송수신 설정처리부
357: 송수신부
1000: 인스턴스 시스템
1100: 코디네이터
1110, 1120, 1300, 3110, 3210: 노드
1330, 1115, 3115, 3215: 설정 저장부
1350: 에이전트 어댑터
1351: 에이전트 제어부
1352: 송수신 설정부
1353: 송수신 처리부
1370: 매핑 어댑터
1380: 통합 패키지
1390: EDI 어댑터
1500, 1510, 1520, 1530: 워크스페이스
1610: API
1700: 프레임워크레이어
1800: 가상화레이어
1900: 리소스레이어
2000: 매니저 시스템
2100: 애플리케이션 서비스 매니저
2110: 메시지 박스
3000: 개발워크스페이스
4000: 인터페이스 거버넌스 플랫폼
4100: 거버넌스 API
200, 320: 파트너
300: 클라이언트 또는 파트너
350: 에이전트
351: 에이전트 제어처리부
353: 송수신 설정처리부
357: 송수신부
1000: 인스턴스 시스템
1100: 코디네이터
1110, 1120, 1300, 3110, 3210: 노드
1330, 1115, 3115, 3215: 설정 저장부
1350: 에이전트 어댑터
1351: 에이전트 제어부
1352: 송수신 설정부
1353: 송수신 처리부
1370: 매핑 어댑터
1380: 통합 패키지
1390: EDI 어댑터
1500, 1510, 1520, 1530: 워크스페이스
1610: API
1700: 프레임워크레이어
1800: 가상화레이어
1900: 리소스레이어
2000: 매니저 시스템
2100: 애플리케이션 서비스 매니저
2110: 메시지 박스
3000: 개발워크스페이스
4000: 인터페이스 거버넌스 플랫폼
4100: 거버넌스 API
Claims (8)
- 애플리케이션 패키지가 실행되는 서로 격리된 워크스페이스를 클라이언트에 제공하는 플랫폼을 관리하는 컴퓨팅 시스템에서, 애플리케이션 플로우에 대한 개발 도구 팔레트 및 GUI(graphic user interface) 블록 영역을 포함하는 사용자 인터페이스를 제공하는 단계,
여기서, 상기 애플리케이션 플로우는 소스데이터를 타겟데이터로 변환하는 매핑 플로우를 포함하고, 상기 사용자 인터페이스는 상기 소스데이터를 상기 타겟데이터로 변환하는데 필요한 함수를 편집하는 인터페이스를 포함하고;
사용자로부터 상기 개발 도구 팔레트에 포함된 제 1 그래픽 블록을 선택하는 신호를 수신함에 따라, 상기 제 1 그래픽 블록에 대응하는 제 1 함수 블록을 생성하는 단계; 및
상기 생성된 제 1 함수 블록을 상기 GUI 블록 영역에 출력하는 단계를 포함하는, 애플리케이션 서비스 제공 방법.
- 제 1 항에 있어서,
상기 GUI 블록 영역에 포함된 상기 제 1 함수 블록에 대응하는 소스 코드를 소스 코드 영역에 출력하는 단계를 포함하는, 애플리케이션 서비스 제공 방법.
- 제 1 항에 있어서,
상기 사용자 인터페이스는 사용자가 요청하는 블록들의 흐름 순으로 상기 소스데이터를 상기 타겟데이터로 변환하는 인터페이스를 제공하는, 애플리케이션 서비스 제공 방법.
- 제 1 항에 있어서,
여기서 상기 개발 도구 팔레트는 소스 스키마 영역, 및 타겟 스키마 영역을 포함하고,
상기 소스 스키마 영역은 상기 변환 이전의 데이터 스키마 정보를, 상기 타겟 스키마 영역은 상기 변환 이후의 데이터 스키마 정보를 포함하는 애플리케이션 서비스 제공 방법. - 데이터를 저장하는 데이터베이스; 및
상기 데이터를 처리하는 프로세서를 포함하고,
상기 프로세서는,
애플리케이션 플로우에 대한 개발 도구 팔레트 및 GUI(graphic user interface) 블록 영역을 포함하는 사용자 인터페이스를 제공하고, 여기서 상기 애플리케이션 플로우는 소스데이터를 타겟데이터로 변환하는 매핑 플로우를 포함하고, 상기 사용자 인터페이스는 상기 소스데이터를 상기 타겟데이터로 변환하는데 필요한 함수를 편집하는 인터페이스를 포함하고;
사용자로부터 상기 개발 도구 팔레트에 포함된 제 1 그래픽 블록을 선택하는 신호를 수신함에 따라, 상기 제 1 그래픽 블록에 대응하는 제 1 함수 블록을 생성하고; 및
상기 생성된 제 1 함수 블록을 상기 GUI 블록 영역에 출력하는, 애플리케이션 서비스 제공 장치.
- 제 5 항에 있어서,
상기 프로세서는,
상기 GUI 블록 영역에 포함된 상기 제 1 함수 블록에 대응하는 소스 코드를 소스 코드 영역에 출력하는, 애플리케이션 서비스 제공 장치.
- 제 5항에 있어서,
여기서 상기 개발 도구 팔레트는 소스 스키마 영역, 및 타겟 스키마 영역을 포함하고,
상기 소스 스키마 영역은 상기 변환 이전의 데이터 스키마 정보를, 상기 타겟 스키마 영역은 상기 변환 이후의 데이터 스키마 정보를 포함하는, 애플리케이션 서비스 제공 장치.
- 애플리케이션 플로우에 대한 개발 도구 팔레트 및 GUI(graphic user interface) 블록 영역을 포함하는 사용자 인터페이스를 제공하고, 여기서 상기 애플리케이션 플로우는 소스데이터를 타겟데이터로 변환하는 매핑 플로우이고, 상기 사용자 인터페이스는 상기 소스데이터를 상기 타겟데이터로 변환하는데 필요한 함수를 편집하는 인터페이스를 포함하고;
사용자로부터 상기 개발 도구 팔레트에 포함된 제 1 그래픽 블록을 선택하는 신호를 수신함에 따라, 상기 제 1 그래픽 블록에 대응하는 제 1 함수 블록을 생성하고; 및
상기 생성된 제 1 함수 블록을 상기 GUI 블록 영역에 출력하는 단계를 수행하는, 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020230101952A KR102659150B1 (ko) | 2023-08-04 | 2023-08-04 | 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020230101952A KR102659150B1 (ko) | 2023-08-04 | 2023-08-04 | 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR102659150B1 true KR102659150B1 (ko) | 2024-04-19 |
Family
ID=90881825
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020230101952A KR102659150B1 (ko) | 2023-08-04 | 2023-08-04 | 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체 |
Country Status (1)
| Country | Link |
|---|---|
| KR (1) | KR102659150B1 (ko) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20100126939A (ko) * | 2009-05-25 | 2010-12-03 | 일공일시스템(주) | 공급망 관리 연결용 데이터 변환 장치 및 데이터 변환 방법 |
| KR20150063409A (ko) * | 2012-09-28 | 2015-06-09 | 아브 이니티오 테크놀로지 엘엘시 | 프로그래밍 속성의 그래픽 표현 |
| KR102300005B1 (ko) * | 2021-03-05 | 2021-09-08 | 주식회사 스트라토아이티 | 소프트웨어 컴포넌트를 표현하는 각각의 그래픽 객체 간의 연결 조작을 이용한 소프트웨어 개발 어시스트 방법 및 그 시스템 |
-
2023
- 2023-08-04 KR KR1020230101952A patent/KR102659150B1/ko active IP Right Grant
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20100126939A (ko) * | 2009-05-25 | 2010-12-03 | 일공일시스템(주) | 공급망 관리 연결용 데이터 변환 장치 및 데이터 변환 방법 |
| KR20150063409A (ko) * | 2012-09-28 | 2015-06-09 | 아브 이니티오 테크놀로지 엘엘시 | 프로그래밍 속성의 그래픽 표현 |
| KR102300005B1 (ko) * | 2021-03-05 | 2021-09-08 | 주식회사 스트라토아이티 | 소프트웨어 컴포넌트를 표현하는 각각의 그래픽 객체 간의 연결 조작을 이용한 소프트웨어 개발 어시스트 방법 및 그 시스템 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11126481B2 (en) | Fulfilling a request based on catalog aggregation and orchestrated execution of an end-to-end process | |
| US11087249B2 (en) | Method and apparatus for triggering execution of a workflow over a network | |
| JP5026415B2 (ja) | データセントリックワークフロー | |
| Indrasiri et al. | gRPC: up and running: building cloud native applications with Go and Java for Docker and Kubernetes | |
| US7350184B2 (en) | System and method for enterprise application interactions | |
| CN109919586B (zh) | 多层安全移动交易使能平台 | |
| US8850454B2 (en) | Method and computer program product for integrating a first application providing a B2B gateway and one or more second applications | |
| US7509398B2 (en) | System and method for protocol independent access and invocation of web services | |
| JP7097958B2 (ja) | 自動ユニバーサルコネクタパッケージを使用してクラウドアプリケーションをクラウドサービスブローカプラットフォームに統合するためのシステムおよび方法 | |
| US20060136923A1 (en) | System for distributed task execution | |
| JP2005196767A (ja) | ウェブ・サービス呼び出しをサポートするスケジューラ | |
| Leymann et al. | Modeling business processes with BPEL4WS | |
| Ferreira | Enterprise systems integration | |
| Sharma | Modern API Development with Spring and Spring Boot: Design highly scalable and maintainable APIs with REST, gRPC, GraphQL, and the reactive paradigm | |
| Sanderson | Programming Google App Engine with Python: Build and Run Scalable Python Apps on Google's Infrastructure | |
| Indrasiri | Beginning WSO2 ESB | |
| KR102659150B1 (ko) | 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체 | |
| KR102659154B1 (ko) | 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체 | |
| KR102663420B1 (ko) | 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체 | |
| US20130024834A1 (en) | Managing an application development environment | |
| KR102663418B1 (ko) | 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체 | |
| KR102660700B1 (ko) | 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체 | |
| KR102659148B1 (ko) | 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체 | |
| KR102637168B1 (ko) | 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스 제공하는 프로그램이 저장된 컴퓨터가 판독 가능한 기록매체 | |
| Indrasiri et al. | Integrating microservices |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| GRNT | Written decision to grant |