KR20010024487A

KR20010024487A - 구조화된 통신용 방법 및 장치

Info

Publication number: KR20010024487A
Application number: KR1020007003970A
Authority: KR
Inventors: 반데르하이덴산데르; 데블리어로버트; 블랭크칩
Original assignee: 엑스-웨이 라이츠 비.브이.
Priority date: 1997-10-13
Filing date: 1998-10-13
Publication date: 2001-03-26
Also published as: AU729456B2; ES2158445T3; EP1025682A2; AU9652898A; US6880016B1; PT909068E; HUP0101695A3; DK0909068T3; PL340333A1; ATE200373T1; WO1999020025A2; GR3036076T3; EP0909068B1; CA2305462C; TR200000985T2; JP3274131B2; WO1999020025A3; NO20001803L; ID24180A; HUP0101695A2

Abstract

본 발명은 유연성 있는 메시지 포맷(ILMF)을 가진 메시지에 의해서 센더[SRV(m)]와 리시버[SRV(m)] 간의 포인트 투 포인트 통신을 위한 통신 방법 및 그 장치에 관한 것이다. 상기 메시지는:

최소한의 메시지 정의 레퍼런스(MSG 식별자, MSG 클래스, MSG 버젼, MSG 크리에이터), 센더 식별자(센더 식별자) 및 목적지 주소(목적지 주소)를 가진 헤더와; 필드 수(필드 카운트) 및 임의의 필드 내용[필드(1),...], 오브젝트 수(오브젝트 카운트) 및 임의의 오브젝트 내용[오브젝트(1),...], 필드 매핑 수(맵 카운트) 및 미리 결정된 필드에 의해 사용될 수 있는 임의의 필드 매핑[맵(1),...], 액션 수(액션 카운트) 및 적어도 미리 결정된 필드에 의해 사용될 수 있는 임의의 액션 내용[액션(1),...]에 관련된 메시지 내용을 포함한다.

Description

구조화된 통신용 방법 및 장치{METHOD AND APPARATUS FOR STRUCTURED COMMUNICATION}

범용 및 비지니스용 전자 데이터 통신은 4가지 별개의 문제점을 가지며 각각은 많은 부문제점(sub-problem)을 가진다. 다음의 문제점들이 전자 데이터 통신의 거의 모든 범주에 적용되지만, 비지니스 통신의 요구에 관해서 이들 문제점을 논의할 것이다. 4가지 문제점은:

1) 송수신되는 전자 데이터는 그것이 어떠한 의미를 가지는 지에 대해 분명히 인식되어야만 한다. 각각의 회사들은 심지어 가장 기본적인 비지니스 정보, 예를 들면, 주문 양식 또는 화물 인환증(bill of lading) 등을 나타내는 데 다른 방법을 사용한다.

2) 전자 데이터가 다른 회사로부터 수신되어 정확히 인식되면, 그것은 수신 회사의 데이터베이스 및 사무 처리 프로그램에 통합되어야 한다. 여기서 다시, 각각의 회사는 그들의 컴퓨터 시스템 상에 전자 데이터를 표현하고 저장하는 방법을 의미하는 데이터베이스 구조에서 많은 차이점을 가진다.

3) 전자 데이터가 최종 사용자에 표시되어야 하고 최종 사용자의 인터랙션이 허용되야 한다면, 여기서 다시, 각각의 회사는 다양한 형태의 디스플레이 소프트웨어, 다양한 시스템 요구 조건 및 다양한 비지니스 요구 조건을 가진 다른 형태의 컴퓨터 디스플레이 단말기를 사용할 것이다. 따라서, 주문형 그래픽 유저 인터페이스(GUI)를 구비하는 매우 값비싼 전자 데이터 디스플레이 프로그램을 매우 자주 설계할 필요가 있다.

4) 전문 시스템 서비스와 특정한 비지니스 기능을 완수하기 위한 전문 시스템 서비스에 관련된 데이터를 결합하여 사용할 필요성 때문에, 통합된 방식으로 전산화된 비지니스 기능과 하나 이상의 컴퓨터를 통해서 분산된 비지니스 기능에 대한 처리를 실행할 필요성이 존재할 수 있다. 이것은 기능은 본질적으로 단일 시스템과 같으면서 전산화된 비지니스 시스템이 하나 이상의 위치에 존재할 필요가 있을 수 있고, 하나 이상의 위치에서 다르게 작동할 필요가 있을 수도 있다는 것을 의미한다. 이 문제점에 대한 해법은 보통 분산 어플리케이션 또는 최근에 미들웨어로 분류되는 분산 객체 관리 시스템으로 분류된다.

문제점 4와 관련된 2개의 다른 주요한 이슈가 있는데, 첫번째 이슈는 각각의 다른 시스템을 실행하는데 필요한 비지니스 로직, 유저 인터페이스 및 네트워크 통신 인터페이스를 재작성해야 하는 필요성을 회피하기 위해서 여러 다른 시스템 상에서 동일한 비지니스 어플리케이션을 사용하고자 하는 회사의 요구 또는 욕구이다. 두번째 이슈는 단일 어플리케이션의 기능을 통신 네트워크를 통해서 하나 이상의 시스템에 분할하고 완전히 통합된 방식으로 그것을 작동시켜야 할 필요성이다.

상기 4가지 문제점을 모두 해결할 수 있는 단일 시스템은 현재 존재하지 않는다. 이에, 회사들은 매년 다양하게 조합된 상기 4가지 문제점을 해결하기에는 비능률적이고 불완전한 전자 데이터 통신 및 저장 시스템을 구입, 설계, 재설계 및 관리하는데 수백만 달러를 낭비하고 있다.

종래기술

문제점 1

첫번째 문제점을 해결하기 위해서는, 특정한 형태의 정보에 대한 전자 데이터 포맷 세트가 실제로 통신하기 전에 모든 통신하는 회사에 의해 협정되어야만 한다. 게다가, 포맷에 대한 협정은 이와 동일한 협정을 정확히 따른 통신 소프트웨어의 사용에 의해 현실화되어야 한다. 전자 데이터 교환(EDI;Electronic Data Interchange)은 이 문제점을 해결하기 위한 한 가지 방법이었다. EDI는 많은 형태의 비지니스 트랜잭션에 대한 전자 데이터 메시지 포맷 세트인데, 그 포맷은 사용자에 의해 변경될 수 없다는 의미에서 유연성이 없으며, EDI 메시지에는 상당 수의 다양한 버젼이 있다. 회사는 EDI 메시지 비지니스 통신 시스템을 사용할 수 있었지만, 여전히, 상이한 버젼의 EDI 메시지 세트를 사용하고 있는 다른 회사와는 전자 데이터를 교환할 수 없다. 현행 비지니스 시스템을 EDI로 변환하는데는 막대한 시간 및 비용이 요구되며, 또한 변경하거나 필요하다면 다른 포맷을 첨가하는데도 어려움과 비싼 비용이 요구된다.

하드 코드된(소프트웨어에서 정의됨) 메시지 포맷을 이용한 방법 및 해법은 EDI와 관련된 모든 문제점을 가지며, 단지 상이한 고정 메시지 포맷을 가질 뿐, 본질적으로 동일한 해법이다. 고정 메시지 포맷이 변경되어야만 할 때마다, 아마 데이터베이스 및 유저 인터페이스뿐만 아니라 소프트웨어에도 유사한 변경을 필요로 한다. 심지어 매우 적은 변경에서도 때때로 몇 달을 필요로 한다. 그리고, 물론, 이 전자 메시지 포맷은 장래에 전자적 통신이 정확하게 계속될 것을 보증하기 위해서 그 특정한 포맷을 이용하는 모든 비지니스의 컴퓨터 상에서 변경되어야만 한다.

본질적으로, 어떻게 해서든지 공통 데이터 포맷이 송수신자에 의해 협정되어야 한다는 요구가 항상 있다. 이러한 요구는 현재나 장래에 이용가능한 어떠한 방법에서도 존재할 것이다. 주문자 입장에서의 중대한 문제는 얼마나 빨리 그리고 값싸게 통신 방법(즉, EDI)과 관련한 시스템을 구축할 수 있는가, 얼마나 쉽게 그 시스템의 모든 부분(데이터베이스, 소프트웨어, 유저 인터페이스)에서 이전에 협정된 전자 데이터 포맷을 변경할 수 있는가이다.

문제점 2

두번째 문제점은 해결하기가 더 어렵다. 일반적으로, 대부분의 회사들은 많은 수의 데이터 입력 요원을 사용하는데, 상기 데이터 입력 요원은 인쇄 자료를 읽고, 그 읽은 데이터를 그들의 단말기에서 실행되는 컴퓨터 프로그램에 입력한다. 그러면, 상기 단말기는 그 데이터를 처리하여 바른 포맷으로 변환한 후 그 회사 데이터베이스에 저장할 것이다. EDI 또는 비슷한 공통 전자 메시지 포맷을 사용하는 이들 회사는 자동적으로 그 공통 전자 메시지 포맷을 처리 및 변환하고 데이터 저장 및 검색을 위해서 이들 회사의 현행 데이터베이스 구조와 대화하는 주문형 소프트웨어에 대한 막대한 비용을 지불해야 할 것이다. 이들 회사가 공통 메시지 포맷을 변경 또는 첨가할 필요가 있거나, 데이터베이스 구조를 변경 또는 확장할 필요가 있다면, 이들 회사는 이 전자 메시지 포맷 데이터베이스 인터페이스 프로그램의 변경 및 재작성에 많은 시간 및 비용을 들여야만 한다.

공중 영역에서의 한 범용 해결책은 커스터머 데이터베이스(customer database:CDB) 또는 저장 장치 내의 특정 위치에 특정 데이터 항목을 "매핑"하는 것에 중점을 둔다. 이 매핑은 소프트웨어 내에서 이루어지는 것이 아니며, 소프트웨어 어플리케이션 및 커스터머 데이터베이스로부터 분리된, 상기 소프트웨어 어플리케이션이 판독하는 독립되고 단순한 파일과 같은 더욱더 용이하게 변경할 수 있고 유연성 있는 리프리젠테이션(representaion) 내에 있다. 이는 데이터베이스 구조 또는 데이터 리프리젠테이션이 변경될 때마다 소프트웨어 어플리케션을 재프로그램 및 재설계해야 하는 필요성을 제거한다. 데이터 필드 맵핑 기술은 보통 프로그레스(Progress), 오라클(Oracle) 및 SQLBase(SQL=Structured Query Language)와 같은 많은 데이터베이스 회사들이 의해 공용된다. 이 잘 알려진 방법의 버젼은 본 발명의 통신 장치로 통합된 기능 및 방법의 일부가 될 것이다.

문제점 3

세번째 문제점은 용이하게 실행할 수 있는 해결책이 거의 없다. 한 종류의 해결책은 엑스 윈도우(X-Window) 또는 마이크로소프트 윈도우(Microsoft Window)와 같은 다양한 윈도우(그래픽 유저 인터페이스) 관리 시스템에 대해서 광대한 양의 소프트웨어 코드를 쓰는 것을 요구한다. 대체로, 크고 다기능의 비지니스 어플리케이션과 같은 방법은 거대한 양의 시간, 비용 및 노력을 요구하고, 유저 인터페이스에 첨가 또는 변경하는데 많은 시간과 비용이 소비된다.

새롭고 유망한 종류의 해결책은 HTML(Hyper Text Markup Language) 및 웹 브라우져의 이용에 중점을 둔다. 이는 매우 보기 좋은 그래픽 유저 인터페이스를 다이내믹하게 만들 수 있는데, 보통 월드 와이드 웹 및 인터넷 상에서 사용되기 때문에 "웹 페이지"로 불리어 지며, 이는 많은 회사들의 관심을 불러 일으키고 있다. 그들은 HTML을 이용해서 얼마나 빨리 그리고 값싸게 매우 보기 좋은 그래픽 유저 인터페이스를 설계할 수 있는지 알고 있으며, 그들의 전자 데이터 통신 및 처리 프로그램을 위한 유저 인터페이스를 그와 동일한 방법으로 만들어서 웹 브라우져 시스템과 같이 동일한 방법으로 통신할 수 있지 않을까 생각한다. 사실상, 회사는 모든 범위의 비지니스 및 개인 데이타 및 메시지를 송수신하기 위해서 인터넷을 이용하기를 원한다.

요즈음에는, HTML 및 웹 브라우져를 이용해서 인터넷을 통해 제한된 범위의 비지니스 및 일반 데이터 통신을 할 수 있는 이용가능한 몇 몇 시스템이 있다. 데이터 통신의 형태가 제한되는 이유는 웹서버/웹 브라우져 시스템이 모든 데이터 통신 서비스를 제공하도록 설계되지 않았기 때문이다. 그들 시스템은 다이내믹한 문서 검색 및 디스플레이 시스템으로서 설계되었으며, 사용자의 요청에 따라 처음 착수된 정보를 검색할 수 있다. 상기 시스템에서는 광대한 추가 프로그래밍에 의하지 아니하면, 사용자는 하나 또는 그 이상의 목적지에 정보를 전송할 수 없다. 그들 시스템에는 전송 능력이 원래 없다. 이러한 형태의 시스템으로는 프로그레스의 웹스피드(WebSpeed), IBM의 웹EDI(WebEDI) 및 사파이어그룹(SapphireGroup)의 페이저블레이저(PageBlazer)가 있다.

심지어 소위 "푸시(push)" 기술을 실행하는 웹 브라우져 및 웹서버의 "더 새로운" 형태의 것들도 전송이 아닌 단지 데이터 수신만 허용한다. 그리고, 이 "수신"은 실제로 웹 브라우져 및 웹서버 시스템에 의해서 시뮬레이트형 브로드케스트 수신기, 정보에 대한 숨은 반복 요청(폴링)으로서 설정된다. 이 "푸시" 기술을 확장하기 위한 계획은 진정한 브로드캐스트 및 멀티-캐스트 통신 기술의 이용만을 포함한다. "푸시" 기술의 예로는 마림바(Marimba)의 캐스터네츠(Castanet) 및 팁코(Tibco)의 API가 있다. 소위 이 "푸시" 기술은 새로운 방법으로 대규모 시장에 도달하기를 바라는 광고주들에게는 대단한 관심이나, HTML의 향상된 문서 표시 형태들 및 현행 데이터베이스 및 비지니스 시스템으로 용이하게 통합될 수 있는 포인트 투 포인트 프로토콜을 이용한 완전히 통합된 양방향(two-way) 정보 통신 환경 하에서 인터넷을 사용할 필요성 또는 소망을 갖는 회사나 개인에게 있어서는 거의 소용이 없다.

인터넷을 위한 웹서버 및 웹 브라우져 인터페이스는 최종 사용자가 웹 페이지에 대한 요청과 같은 메시지를 전송할 수 있도록 설정된다. 웹 브라우져 사용자는 전자 메일을 이용하는 방법을 제외하고는 결코 다른 웹 브라우져 사용자에게 메시지나 웹 페이지를 전송할 수 없다. 또한, 웹 브라우져 사용자는 먼저 요구되지 않은 특정한 메시지를 결코 수신하지 않을 것이다; 심지어 소위 "푸시" 기술 정보는 폴링에 의해 요청되고, 그 정보의 속성은 심지어 그것이 요구에 맞게 적합화되었더라도 텔레비젼 방송 또는 매스 메일링(mass mailing)에 비교될 것이다. 그 정보는 하나의 특정한 수신자에 전송되지 않는다. 이를테면, 이를 전자 메일(이메일)과 대조해 보자. 이메일 서비스를 이용하는 자는 먼저 전송자에게 어떤 수의 특정한, 개인적인 메시지를 요구하지 않더라도 그 메시지를 수신할 수 있다. 또한, 먼저 어떤 수의 특정한, 개인적인 메시지가 요구되지 않더라도 그 메시지를 특정한 수신자에게 전송할 수 있다. 이것이 메시지의 보통의 필요한 속성이다. 이처럼 통신할 수 있는 인터넷의 웹서버 시스템은 아직까지 설계되지 않았다.

그렇다면, 왜 회사 및 개인들은 웹서버 시스템을 이러한 방법으로 이용하는 것에 그렇게 관심이 있는 것인가? 왜 단지 이메일만을 이용하지 않는가? 그 이유는 이메일은 어떠한 데이터 포맷 서비스(HTML이 하는 것과 같은 서비스) 및 어떠한 유저 인터페이스 생성 시스템(웹 브라우져가 하는 것과 같은 시스템)을 그 내부에 구축하지 못했기 때문이다. 또한, 이메일 메시지는 그의 목적지에 도달하는데 불확정한 시간(몇 초에서 몇 일)이 소요될 수도 있고, 때때로 분실될 수도 있다. 이것은 표준 비지니스 전자 데이터 통신에서는 용인될 수 없다. 그것이 회사 및 개인들이 웹서버/웹 브라우져 시스템에 관심을 갖는 이유이다. 상기 시스템은 그 내에 구현된 매우 훌륭한 데이터 표시 능력 및 적당한 속도의 통신 능력 가지고 있다. 그러나, 위에서 언급된 바와 같이, 포인트 투 포인트 통신 능력 또는 표현 및 맵핑 능력은 가지고 있지 않다.

본 발명에서, 공중 영역의 HTML 표준은 매우 용이하게 구현되고, 빠르며 유연성 있는 그래픽 유저 인터페이스를 생성하기 위한 해법으로서 통합될 것이다.

문제점 4

역사적으로, 문제점 4는 매우 최근까지 단지 관계형 데이터베이스 관리 시스템(RDBMS:Relational Database Management Systems)에 의해서 해결되어 왔다. 이러한 종류의 해결책은 분산 쿼리(query) 및 분산 데이터베이스 관리의 정확한 기능을 해결하는 것으로 제한되어 왔고, 현재도 그러하며, 먼저 상술된 바와 같은 문제점 4와 관련된 2개의 주요한 이슈를 해결하지 못한다.

두번째 더 새로운 종류의 해결책은 최근 "미들웨어"로 불리어지는 시스템 또는 분산 객체 관리 시스템에서 찾을 수 있다. 이것의 좋은 예로써, CORBA(Common Object Request Broker Architecture)로 불리어지는 시스템이 있다. CORBA의 개발 역사, CORBA 2.0의 목적, 현재의 기능 및 결함에 관한 훌륭한 논문들은 1997년 3월호 DBMS 매거진, 볼륨 10, 넘버 3, p.42에 실린 와렌 케이필(Warren Kayffill)의 "CORBA masterminds object management"와 이와 동일한 발행본, p.52에 실린 티.제이. 하트(T.J. Hart)의 "Questioning CORBA. Bringing Corba-based designs to life faces a multitude of obstacles"이다.

이러한 종류의 해결책은 상호 운용성 문제, 어플리케이션 레벨에서의 공통 데이터 포맷 문제 또는 유저 인터페이스 문제를 해결하지 못한다. 그것은 통신 레벨에서 표준 데이터 및 표준 통신 인터페이스를 가지고 어플리케이션에 기록할 수 있는 능력만을 다룬다. 본질적으로, 이러한 형태의 시스템은 개발 환경, 실행 환경 및 프로그래머가 어떤 시스템에서도 실행되는 어플리케이션을 작성할 수 있도록 해주는 소프트웨어 라이브러리 세트를 제공하며, 코드에 데이터 구조(소위 오브젝트)를 규정한 후, 이 데이터 구조는 그 특별한 데이터 구조를 인식 및 이용하기 위해서 코드된 다른 소프트웨어 프로그램과 교환될 수 있다.

본질적으로, 이러한 능력과 기능은 프로그래머가 거의 모든 시스템에서 실행되는 자바(Java)로 메시지 통신 시스템을 프로그램하고 EDI 메시지 또는 어떤 다른 협정된 고정 포맷을 통신 매체로서 이용하는 것과 조금도 다를 바 없다. CORBA 시스템은 어떠한 메시지도 번역하지 않는다. 프로그래머에 의해 프로그램된 어플리케이션은 메시지를 인식할 수 있어야 한다. 이때문에 CORBA 어플리케이션은 EDI 또는 고정 메시지 포맷 어플리케이션 시스템처럼 개발, 변경 및 유지에 대한 비용 및 시간에 관한 동일한 문제점 모두를 갖는다. 심지어 CORBA로 실행가능한 분산 기능조차 CORBA에 본래부터 있는 것이 아니라 어플리케이션을 설계하고 코딩하는 프로그래머의 기술과 CORBA 통신 라이브러리의 적절한 이용에 달려있다. 본질적으로, CORBA의 유일하고 분명한 이득은 많은 실행 환경에 걸쳐서 어플리케이션 시스템의 일부의 상호 운용성이며, 자바와 같은 다른 수단을 통해서 아마 더 얻어질 수 있을 것이다.

본질적으로, 사실상 대부분의 경우에서 "미들웨어"는 표준화된 통신 환경 및 약간의 표준화된 소프트웨어 기능을 많은 컴퓨터 상에 제공하는 단지 또 하나의 전자 데이터 통신 환경일 뿐이며, 소프트웨어 어플리케이션 구현의 모든 면을 해결하지 못하기 때문에 데이터베이스 인터페이스 및 유저 인터페이스에 대한 시스템 의존적인 코드 이용을 필요로 한다. 따라서, CORBA와 같이 시스템 사용의 주된 목적을 이루지 못한다.

CORBA 기능을 자바로 병합하고, ODBC 또는 자바 시스템에서 JDBC로 불리는 표준화된 데이터베이스 인터페이스를 포함하는 어떤 시스템들이 있다. 이것은 흥미로운 개발이나, ODBC 데이터베이스 인터페이스는 단지 판독 전용 쿼리에 대해서만 유효하기 때문에, 완전한 데이터베이스 엑세스를 요구하는 표준 비지니스 트랜잭션 시스템이 성공적으로 생성될 수 없다. 또한, 이러한 조합은 문제점 1 또는 2를 전혀 해결할 수 없다. 게다가, 그것은 OBDC의 사용과 CORBA 오브젝트 브로커 시스템의 간접 비용 때문에 본 발명을 설계하는데 원하는 플랫폼이 아니다.

더 이전의 종래 기술은 아래에서 간략하게 논의될 몇 몇 특허 문서로부터 알 수 있다. 미국 특허 제 5,257,369호 [팁코(Tibco, Inc)]는 초기에 제시된 "미들웨어"를 개시한다. 게다가, 이 문서는 브로드캐스트 기능을 제공하며, 브로드캐스트 기능에 바탕을 두고 있다. 그것은 첫째로 실시간 주식 시세 또는 시장 정보와 같은 실시간 데이터를 동시에 많은 수신인에게 전송하는 문제에 대한 해결책을 제공한다. 그러나, 포인트 투 포인트 통신이나 문제점 2 또는 3을 전혀 해결하지 못한다. 메시지 포맷은 변경될 수 있으며, 또한 이전에 CORBA에서 설명한 바와 같이 데이터 구조 또는 오브젝트로서 규정될 수 있다. 그러나, 이러한 기능은 어플리케이션 코드를 변경하지 않고 메시지 포맷을 변경 또는 첨가할 수 있는 능력이나, 유저 인터페이스 또는 데이터베이스 필드에 메시지 포맷의 데이터를 매핑할 수 있는 능력을 갖지 못한다.

WO 96/20553 [알파넷 텔레콤(Alphanet Telcom, Inc)]은 음성 메일 및 팩시밀리(팩스) 정보를 포함하는 전자 메일(이메일)의 개선에 초점을 둔다. 이 시스템은 서비스 시스템에 연결된 인터넷, 전화 또는 팩스 기기를 통해서 음성 메일, 이메일 또는 팩스를 수신하기 위해서 사용자가 연결할 수 있는 집중형 서비스에 관한 것이다. 이러한 발명은 어떠한 방법으로도 문제점 1, 2, 3 또는 4를 해결할 수는 없지만, 통신 관점에서는 아마 이메일을 더 능률적으로 만드는 방법을 다룬다.

WO 96/34341 [챨즈 보보 Ⅱ(Charles Bobo Ⅱ)]은 연결된 유저를 위해서 데이타를 수집, 저장 및 엑세스할 수 있는 집중형 서비스에 초점을 둔다. 이것은 문제점 1 내지 4를 해결하기 위해서 그리고 표준 비지니스 통신의 대부분의 형태를 위해서 필요한 포인트 투 포인트 통신과 완전히 다르다. 게다가, GEIS 및 IBM 사설 데이터 네트워크등과 같이 벌써 여러해 동안 정확하게 이러한 기능을 수행해온 상업적으로 이용가능한 시스템이 많이 있다.

EP-0,747,840 A1, EP-0,747,841 Al, EP-0,747,842 A1, EP-0,747,843 A1, EP-0,747,844 A1 및 EP-0,747,845 A1 (International Business Machines Corporation 모두에 양도됨)은 어떤 형태의 데이터베이스 접근으로 현행 웹서버 기능을 강화하는데 초점을 두고 있다. 따라서, 이전에 논의된 웹서버의 통신 한계에 의해 여전히 제한된다. 그러므로, 이러한 발명은 문제점 1 및 4를 전혀 해결할 수 없고, 문제점 3은 단지 한정된 방법으로 해결할 수 있다. 게다가, 프로그래스 데이터베이스 코포레이션(Progress Database Corporation)의 웹스피드(WebSpeed)와 같이 동일하거나 심지어 더 강화된 웹서버를 제공하는 몇몇 상업적으로 이용가능한 시스템이 있다.

WO 95/11560 [사이베이스(Sybase, Inc)]은 사용되는 컴퓨터 하드웨어 또는 작동 시스템에 무관하게, 어플리케이션이 구현될 수 있는 일관된 전자 데이터 통신 소프트웨어 인터페이스를 생성하는 문제만을 해결해주는 "미들웨어"의 범주에 있다. 이 발명의 문서는 어떠한 방법으로도 통신되고 있는 전자 데이터 포맷을 해결하지 못한다. 따라서, 이러한 문제점은 CORBA와 매우 비슷하며, 본 발명에 의해 해결되고 있는 4가지 문제점의 관점에서 모든 동일한 한계를 가진다.

EP-0,421,624 A2 [텍사스 인스투루먼츠 인코포레이티드(Texas Instrument Incorporated)]는 CORBA와 같은 "미들웨어" 시스템과 어플리케이션 개발 환경의 결합이다. 데이터베이스 제어 및 관리 소프트웨어 개발 환경을 이용하여, 이러한 발명은 프래그래머가 C, COBOL 및 SQL로 어플리케이션을 개발할 수 있도록 해준다. 데이터베이스는 프로그래머들에게 복잡한 데이터베이스 트랜잭션 어플리케이션을 위한 소스 코드 제어 기술을 개발, 수정 및 이용할 수 있도록 해주는 정보를 포함한다. 또한, 상기 발명은 주로 IBM 메인프레임 시스템 및 약간의 유닉스(Unix) 시스템에 관해서 논의되고 있지만, 어플리케이션이 교체 하드웨어 시스템상에 재컴파일되도록 해주며 각각의 컴퓨터상에 동일한 방식으로 수행되로록 해주는 정보를 포함한다. 이 발명은 문제점 1 및 2에서 설명된 그와 동일한 문제점을 가지고 있으며 단지 문제점 3 및 4를 부분적으로 해결할 수 있는 하드 코드형, 컴파일형 어플리케이션의 연속이다.

EP-0,456,249 A2 [휴렛-팩카드(Hewlett-Packard Company)]는 CORBA와 같은 "미들웨어" 시스템과 부분적인 어플리케이션 개발 환경의 결합이다. 상기 부분적인 어플리케이션 개발 환경은 이전에 개발된 현행 어플리케이션을 다른 더 고수준 프로그래밍 언어에 연계해주는 주요 능력을 가진다. 이 발명에서 언급된 더 고수준 언어는 그들 데이터의 다양한 실행시 인-메모리 조직(run-time in-memory organization)을 가지며, 한 언어의 조직으로부터의 그 데이터를 다른 언어로 변형해야 한다. 이 목적으로, 중간 데이터 리프리젠테이션 및 데이터 수송 명령이 규정되는데, 이는 그 데이터 리프리젠테이션 및 수송 명령을 컴파일한 후, 한 언어의 실행시 리프리젠테이션으로부터의 식별된 데이터 구조를 다른 언어로 번역할 수 있도록 해준다. 이 발명은 어플리케이션으로써 독립적으로 실행하는데 필요한 모든 데이터 및 명령을 포함하는 메시지 포맷을 어떠한 방법으로도 해결하지 못하며, 단지 2개의 미리 존재하는 어플리케이션 사이에 특정 데이터 구조를 번역하는데 필요한 데이터 및 명령만을 다룬다. 그러므로, 이 발명은 문제점 2 및 3에서 논의된 문제점을 전혀 해결할 수 없으며, 여기서 논의되온 바와 같이 어플리케이션 수준에서가 아닌 프로그래램 언어 수준에서 단지 문제점 1 및 4에서의 문제점만을 부분적으로 해결할 뿐이다. 이와는 대조적으로, 본 발명은 대부분 메시지로 이루어지므로, 한 언어로부터의 데이터를 다른 언어로 번역할 필요가 없고, 또한 메시지 포맷 또는 명령을 컴파일할 필요도 없다; 모든 데이터는 그것이 전송되는지 또는 컴퓨터 메모리에 남아 있던지 간에 여전히 메시지 포맷으로 남아 있는다.

본 발명은 전자 데이터 통신, 조직화된 데이터베이스, 유연성 있는 포맷 전자 데이터 메시지 관리, 클라이언트-서버 및 분산 소프트웨어 어플리케이션 영역에 관한 것이다.

특히, 본 발명은 관계형 데이터베이스(relational database)를 이용하여 유연성 있는 포맷의 전자 데이터 메시지의 생성, 통신, 번역, 표시 및 실시간 응답과 하나 또는 그 이상의 전자 데이터 네트워크상의 하나 또는 그 이상의 컴퓨터 시스템에 선택적으로 분산될 수 있는 유연성 있는 포맷의 전자 데이터 메시지의 집합체로서 조직화된 어플리케이션에 대한 실시간 응답을 기술하고 및 관리한다.

본 발명은 약간의 도면을 참조로 하여 설명될 것이다. 이러한 도면은 본 발명의 기술적 사상을 제한하려는 것이 아니라, 단지 예시하기 위한 것이다.

도 1은 본 발명에 따른 시스템의 블록도로서 전반적인 개요를 보여준다.

도 2a, 2b, 2c, 2d 및 2e는 본 발명에 따른 메시지 포맷을 도시한다.

상기 사실로 보아, 이 4가지 문제점의 각각을 해결하고, 그 해결책을 하나의 통합체로 결합할 수 있는 단일 시스템 및 통신 방법에 대한 절박한 필요성이 대두된다. 이러한 발명은 복잡한 전자 데이터 통신 시스템을 설계해야만 하고, 끊임없이 이러한 문제점에 직면해야만 하는 개인 및 회사에게는 상당히 이롭다. 상기 단일 시스템 및 통신 방법은 전자 데이터 통신 시스템을 설계 및 유지하기 위한 시간, 비용 및 복잡성을 현저하게 줄일 수 있을 것이다.

상기 단일 시스템 및 통신 방법을 얻기 위해서, 본 발명은 유연성 있는 메시지 포맷을 가진 메시지에 의한 센더(sender)와 리시버(receiver) 사이에서의 포인트 투 포인트 통신 방법을 청구한다. 상기 메시지는:

적어도 메시지 정의 레퍼런스, 센더 식별자 및 목적지 주소로 이루어진 헤더와;

필드의 수 및 모든 필드의 내용,

오브젝트의 수 및 모든 오브젝트의 내용,

필드 매핑의 수 및 미리 결정된 필드에 의해 사용될 수 있는 모든 필드 매핑의 내용,

액션의 수 및 적어도 미리 결정된 필드에 의해 사용될 수 있는 모든 액션 내용에 관한 메시지 내용

을 포함하는 것을 특징으로 한다.

따라서, 어플리케이션 레벨 기능을 규정하기 위한 모든 요소가 상기 메시지 포맷 내에 존재하며, 이러한 메시지는 이미 네트워크 통신 시스템 환경 내에 존재하므로, 간단히 위치 및 목적지 주소를 변경함으로써 용이하게 분산될 수 있다.

또한, 본 발명에 따라서, 유연성 있는 메시지 포맷을 가진 메시지에 의한 다른 통신 장치와의 포인트 투 포인트 통신을 위해 마련된 처리 수단 및 데이터 베이스를 포함하는 통신 장치가 청구되며, 상기 메시지는:

적어도 메시지 정의 레퍼런스, 센더 식별자 및 목적지 주소를 포함하는 헤더와;

필드의 수 및 모든 필드의 내용,

오브젝트의 수 및 모든 오브젝트의 내용,

액션의 수 및 적어도 미리 결정된 필드에 의해 사용될 수 있는 모든 액션 내용

에 관한 메시지 내용을 포함한다.

미리 결정된 메시지 정의 데이블을 참조하기 위해 준비된 처리 수단은 미리 결정된 메시지 정의 테이블을 참조하여 메시지 정의 레퍼런스를 이용하는 데이터베이스에 저장된다.

이와 같이, 본 발명에서는, 어떠한 형태의 데이터라도 포함할 수 있고, 그 메시지 자체 내에서 데이터를 완전히 기술하기에 충분한 정보를 포함하는 유연성 있는 메시지 포맷을 규정한다. 어떤 메시지는 데이터베이스에 미리 저장된 메시지 정의(definition)를 식별하기 위해서 메시지를 수신하는 본 발명의 통신 장치에 의해서 사용되는 메시지 정의 레퍼런스를 포함한다. 그러나, 상기 기술은 미리 저장된 메시지 정의가 계속 고정된 것이 아니기 때문에 유연성이 있다. 메시지를 수신하는 통신 장치 내에서, 메시지를 완전히 기술하고 유일한 식별자로 메시지를 참조하는 관계형 데이터베이스 테이블에 기록된 것을 삽입, 갱신 또는 삭제함으로써 특정한 메시지 포맷이 생성, 편집 또는 삭제될 수 있다. 게다가, 메시지 정의가 미리 결정된 위치에 존재하지 않는다면, 전체 데이터베이스 메시지 정의는 특별한 메시지 또는 메시지 그룹을 위해서 자동적으로 교환될 수 있으며, 그에 의하여 다수의 유저를 위한 교환된 공통 포맷 메시지를 용이하게 생성한다. 본 발명의 또 다른 이점은 요구되는 비용이 적다는 것이다.

메시지 정의 레퍼런스 내에 있는 필드의 예로는 메시지를 식별하기 위한 메시지 식별자, 메일, 비지니스 메시지, 주문 또는 선적 등의 메시지를 식별하기 위한 메시지 클레스 식별자, 메시지 버젼 번호를 식별하기 위한 메시지 버젼 식별자 및 메시지 크리에이터를 식별하기 위한 메시지 크리에이터 식별자가 있다. 메시지 정의 레퍼런스 내에 있는 이러한 필드는 동등한 대응자(couterpart)를 본 발명의 통신 장치에 있는 메시지 정의 테이블 내에 갖는다.

게다가, 메시지 헤더는 사용된 암호 유형 및/또는 압축 유형에 대한 레퍼런스를 포함할 수 있다. 또한, 이러한 레퍼런스는 대응자를 상기 통신 장치에 있는 상기 메시지 정의 테이블 내에 갖는다.

바람직하게, 상기 메시지 내용은 디지털 서명에 의해 보호된다.

바람직하게, 상기 통신 장치의 데이터베이스는 그에 대한 레퍼런스가 메시지 정의 테이블로부터 만들어진 몇 개의 테이블로 조직화된다. 그 다음, 미리 결정된 메시지 정의 테이블은 데이터베이스의 추가의 테이블에 대한 레퍼런스로 사용될 메시지 시스템 식별자를 포함한다.

그러한 추가의 테이블 중의 하나는 메시지 필드에 대한 주(主) 정의를 유지하기 위한 필드 정의 테이블일 수 있다.

가급적이면, 그러한 추가의 테이블 중의 하나는 미리 결정된 필드에 의해 쓸 수 있는 매핑 정보, 예를 들면, 하이퍼 텍스트 마크업 언어 필드, 데이터베이스 필드, 플랫 파일 필드 및 다른 메시지 필드를 매핑하기 위한 매핑 정보를 포함하는 필드 매핑 테이블이다. 상기 데이터베이스 필드 및 플랫 파일 필드는 커스터머 데이터베이스에 저장된다. 게다가, 본 발명에 따른 메시지 포맷은 데이터뿐만 아니라 유저 인터페이스를 위한 매핑 명령, 커스터머 데이터베이스 필드 및 계산 및 조건 로직을 포함하는 액션 시퀀스를 포함한다. 따라서, 어플리케이션 레벨 기능을 규정하기 위한 모든 요소가 상기 메시지 포맷 내에 존재하며, 이러한 메시지 포맷은 이미 네트워크 통신 시스템 환경 내에 존재하므로, 간단히 위치 및 목적지 주소를 변경함으로써 용이하게 분산될 수 있다. 게다가, 이러한 방법으로 매우 용이하게 설계된 빠르고 유연성 있는 그래픽 유저 인터페이스를 생성하기 위해서 HTML 표준이 통합될 수 있으며, 이는 상기 청구된 통신 장치에 의해 관리, 규정 및 제어되는 본 발명에 의해서 규정되고, 그 통신 장치에 연결된 마이크로프로세서 등의 유저 터미널과의 대화 및 표시되는 메시지 포맷을 직접 매핑할 수 있도록 해준다.

또한, 그러한 추가의 테이블 중의 하나는 미리 결정된 필드에 의해 쓸 수 있는 액션 정보를 포함하는 필드 액션 테이블일 수 있다.

가급적이면, 추가의 테이블은 수신 또는 송신된 메시지에 대한 전처리로 실행되는 액션 리스트를 포함하는 메시지 전처리 테이블 및 수신된 메시지에 대한 후처리로 실행되는 액션 리스트를 포함하는 메시지 후처리 테이블이다.

필드 액션 테이블, 메시지 전처리 테이블 및 메시지 후처리 테이블은 액션형 데이터베이스 및 수학적 계산, 할당, 논리 연산, 조건 연산 및 명령을 포함하는 액션형 논리와 같은 액션 그룹으로부터 선택된 액션형 레퍼런스를 포함함다.

가급적이면, 본 발명에서는, 어플리케이션은 하나 또는 그 이상의 지명된 메시지 그룹으로 규정된다. 그 때문에, 메시지 정의 테이블은 수신된 메시지가 어플리케이션의 첫 메시지인가를 표시하기 위한 어플리케이션 필드와, 어플리케이션의 이름을 표시하기 위한 어플리케이션 네임 필드를 포함한다.

본 발명에 따라서, 상기 청구된 통신 장치는, 가급적이면, 수신된 메시지가 그의 데이터베이스에 존재하지 않는 메시지 정의를 표시한다면, 센더에게 새로운 메시지 정의를 요구하며, 상기 센더로부터 새로운 메시지 정의를 수신하고, 상기 데이터베이스의 상기 메시지 정의 테이블에 그것을 저장한다.

상기 통신 장치의 처리 수단은 수신된 메시지를 지정 HTML 파일과 병합하거나, 그 지정 HTML 파일을 그 처리 수단에 의해 찾을 수 없다면 디폴트(default) 동적 HTML 파일을 생성한다. 그러나, 양자택일로, 통신 장치의 처리 수단은 연결 터미널에게 이러한 기능을 수행하도록 명령한다. 그러므로, 또한, 본 발명은 상기 규정된 통신 장치 및 그 통신 장치에 연결된 터미널을 포함하는 시스템과 관련이 있다. 상기 터미널은 터미널 프로세서, 사용자가 데이터를 입력하기 위한 디스플레이 장치 및 입력 수단을 포함하며, 상기 통신 장치는 상기 터미널이 메시지에 목적지 주소로 표시된다면 수신된 메시지를 상기 터미널 전달한다. 상기 터미널 프로세서는 상기 메시지를 지정 HTML 파일과 병합하거나, 그 지정 HTML 파일을 상기 터미널 프로세서가 찾을 수 없다면 디폴트 동적 HTML을 생성한다.

또한, 상기 터미널 프로세서에 메시지 정의가 없는 메시지를 수신한 사용자 터미널은 수신된 메시지 내에 포함된 자체 기술(describing) 정보를 기초로 한, 시스템의 자동 번역 및 표시에 의존한다. 상기 터미널 프로세서는 메시지에 의한 데이터베이스 메시지 정의를 발견할 수 없다면 디폴트 데이터베이스 메시지 정의를 자동적으로 생성하기 위해서, 이와 동일한 자체 기술 정보를 이용할 수 있다. 터미널 사용자는 로컬 시스템을 위해 디폴트 데이터베이스 메시지 정의를 편집 및 적합시킬 수 있다.

본 발명은 문제점 1 및 4에 대한 완전히 새로운 해결책을 가진 유일한 방법으로 결합된 문제점 2 및 3을 위한 기술적 해결 상태를 포함하며, 모든 것이 상기 청구된 유연성 있는 메시지 포맷 및 통신 장치로 구성된 유일한 유연성 있는 포맷 전자 데이터 메시지 관리 시스템을 근거로 구현된다. 관계형 데이터베이스 테이블에 저장된 상세한 정보에 의해 규정 및 제어되는 본 발명의 메시지 관리 시스템은 가장 능률적이고, 완전하며, 간단하게 전자 데이터를 유연성 있는 포맷으로 통신하는 방법을 제공한다. 유연성 있는 메시지 포맷은 어떠한 형태의 전자 데이터의 포함도 고려한다. 유연성 있는 메시지 포맷은 리시버가 심지어 이전에 결코 수신하지 않았던 메시지일지라도, 그 메시지의 내용을 번역, 이해 및 표시할 수 있도록 해주는 정보를 포함한다. 또한, 리시버는 이러한 알려지지 않은 메시지 포맷을 그의 데이터베이스에 첨가할 수 있으며, 소프트웨어를 작성 및 변경함 없이 그 데이터베이스를 그의 비지니스 데이터베이스 및 HTML 유저 인터페이스에 매우 용이하고 빠르게 연결할 수 있다. 또한, HTML 유저 인터페이스는 특정된 HTML 파일 또는 이전에 생성된 HTML 파일이 없는 경우에, 터미널의 소프트웨어에 의해서 동적으로 생성될 수 있다. 이것은 첫번째 문제점을 해결한다.

본 발명에서는, ANSI 표준 SQL 인터페이스가 주요 관계형 데이터베이스에 제공될 수 있다. 이러한 인터페이스는 연속되는 저장 및 검색을 위해서 데이터 메시지의 사용자 선택 필드와 관계형 데이터베이스 테이블에 있는 필드를 자동적으로 연결하는 서비스를 제공한다. 또한, 이러한 데이터 매핑 인터페이스는 고정 길이 필드 및 CSV(Comma Separated Value) 파일과 같은 플랫 파일 포맷에 연결할 수 있다. 이러한 데이터 매핑 인터페이스는 메시지 데이터 필드와 자동 처리 제어를 위한 생산 프로토콜 및 SNMP와 같은 여러 다른 포맷을 연결하기 위해서 확장될 수 있다. 이러한 데이터 매핑 인터페이스는 ILMDB에의 가입에 의해 규정되고, ILMS에 의해 제어된다. 이것은 두번째 문제점은 해결한다.

본 발명에서는, 사용자가 메시지를 생성, 편집, 수신, 송신 및 뷰(view)할 수 있는 메시지 제어 유저 인터페이스 터미널을 제공한다. 메시지 제어 유저 인터페이스는 본 발명에 따른 네트워크 및 메시지 관리 서버와 통신한다. 본질적으로, 본 발명은 완전한 데이터 통신 능력을 요구하는 개인 또는 회사를 위해서 현행 웹서버/웹 브라우져 기술을 대체하며, 모든 데이터 통신 네트워크를 포함하기 위해서 시스템 영역을 확장한다. 이것은 사용자가 특별한 메시지로 규정한 어떠한 특정 데이터뿐만 아니라 HTML, VRML 및 자바 애플릿의 완전한 송수신을 허용한다. 이전에 설명된 특별한 형태들로 결합된 메시지 제어 유저 인터페이스는 메시지에 있는 데이터 사이의 연결을 제어하는 완전한 데이터베이스, 데이터 메시지를 검색 또는 저장하는 커스터머 데이터 소스 및 데이터 메시지를 표시하는 그래픽 유저 인터페이스(HTML 등)를 제공한다.

상술된 문제점을 해결하기 위해서, 본 발명은 메시지 전처리 및 후처리로 구성될 수 있는 자동 시스템 수행 액션을 정의하거나, 그래픽 유저 인터페이스와 연결된 메시지의 경우에서는 필드 선택 액션을 정의하는 기능을 첨가한다. 이러한 액션은 SQL 또는 "InterLingua^TMScript"로 정의될 수 있다. "InterLingua^TMScript"(IS)는 본 발명에서 정의되며, 실시간 동적으로 번역 및 실행되는 계산, 실행 및 조건 논리 제어문의 간단하고 강력한 세트를 가진다. 또한, 모든 메시지 데이터 필드와 인터랙션할 수 있다. 상기 액션은 새로운 매시지, 시스템 기능 및 외부 프로그램에 설계된 호출(call)을 생성하거나, 데이터베이스 쿼리를 송수신할 수 있다. 이러한 액션은 예를 들면, 자동 메시지 응답, 자동 필드 타당성 검사(validation), 계산 수행, 자바 애플릿 실행 또는 복잡한 데이터베이스 트랜잭션을 생성하기 위해서 사용될 수 있다.

본 발명에서는, 메시지 및 그의 관련된 액션으로 정의되는 어플리케이션의 유일한 방법을 포함한다. 데이터베이스 트랜잭션을 실행, 그래픽 유저 인터페이스 를 병합 및 생성, 또는 배경 처리로써 시스템을 조용히 실행하는 메시지간의 인터랙션의 풍부함 및 유연성 때문에, 복잡한 어플리케이션을 데이터 메시지 및 그의 관련된 액션의 집합으로 완전히 정의할 수 있다. 또한, 이것은 분산 어플리케이션 처리 영역에 크게 관련되어 있어서, 시스템의 기본 기능으로서 이러한 메시지를 그 성질에 의해 송신, 수신, 이해 및 구성할 수 있다. 이것은 무엇보다도, 어떠한 소프트웨어 코드를 변경 또는 첨가함 없이, 분산 어플리케이션이 각각의 사이트에서 로컬 유저 인터페이스 및 (비지니스 데이터베이스와 같은)커스터머 데이터 소스 인터페이스를 용이하게 그리고 유연성 있게 정의할 수 있으며, 여전히 그와 동일한 어플리케이션(메시지 세트)을 사용할 수 있다는 것을 의미한다.

도 1에서는, 다수의 서버[SRV(m), m = 1, …, M]가 도시된다. 서버[SRV(m)]는 하나 또는 그 이상의 터미널에 연결될 수 있다. 서버[SRV(1)]에 연결된 터미널은 [ILMC(n), n = 1, …, N]으로 표시된다. "ILMC"는 InterLingua^TMMessage Client의 두문자어이다. 연결선은 참조 부호(4, 5)로 표시된다.

또한, 서버[SRV(1)]는 커스터머 데이터베이스[CDB(1)]에 연결된다. 하나의 커스터머 데이터베이스[CDB(1)]가 도시되었지만, 필요하다면 그 이상이 적용될 수 있다.

터미널[ILMC(1)]은 도 1에서 매우 상세하게 도시되었다. 터미널[ILMC(1)]은 모니터 스크린(6), 처리 장치(1), 키보드(12) 및 마우스(13)을 포함한다. 키보드(12) 및 마우스(13)는 처리 장치(1)에 연결된다. 물론, 사용자가 처리 장치(1)에 데이터를 입력하기 위한 수단으로써 키보드(12) 및 마우스(13) 외에 다른 것을 사용할 수도 있다.

모니터 스크린(6)은 "버튼"(7, 8, 9, 10, 11)을 가지고 있으며, 사용자가 처리 장치(1)로 하여금 미리 결정된 일을 수행시키기 위한 명령을 마우스(13)를 이용하여 상기 버튼을 실행할 수 있다. 그러한 미리 결정된 일은 옵션의 개시, 접속 시도, 메시지 전송, 메시지 수신 및/또는 처리 장치(1)의 메모리에 데이터 저장일 수 있다.

서버[SRV(1)]는 본 발명에 따른 방법과 관련되어 메시지 수신, 전달 또는 전송을 위한 ILMS(InterLingua^TMMessage Server)로 불리어지는 프로세서를 포함한다. ILMS 프로세서의 부분은 SI(InterLingua^TMScript)로 표시되며, 그 기능은 후에 설명될 것이다.

또한, 서버[SRV(1)]는 본 발명에 따른 몇 몇 테이블을 저장하기 위한 데이터베이스[ILMDB(InterLingua^TMMessage Database)]를 포함하며, 이는 후에 설명될 것이다.

서버[SRV(1)]는 통신 경로(2)를 통해서 다른 하나의 서버와 포인트 투 포인트 통신을 위해서 배열된다. 통신 경로(2)는 유선 또는 무선등의 방법으로 개설될 수 있다.

도 1은 하나 또는 그 이상의 터미널(ILMC's)에 연결된 몇 몇 다른 서버[SRV(m)]를 도시한다. 상기 서버[SRV(m)]는 이하 상세히 설명될 본 발명에 따라서 조직화된다.

도 2a, 2b, 2c, 2d 및 2e는 메시지 포맷을 도시한다. 도 2a에서, 메시지 포맷은 4개의 필드[MSG 식별자, MSG 클래스, MSG 버젼 및 MSG 크리에이터]를 포함하며, 상기 필드는 메시지를 수신하는 임의의 장치에 의해 메시지 정의 레퍼런스로 사용된다.

필드(MSG 식별자)는 메시지를 식별하기 위한 것이다.

필드(MSG 클래스)는 메일, 비지니스 메시지, 주문 또는 선적과 같이 메시지의 종류 또는 유형을 지정하기 위해서 사용된다.

필드(MSG 버젼)는 관련된 메시지의 버젼 번호를 식별하기 위한 메시지 버젼 식별자를 포함한다.

필드(MSG 크리에이터)는 관련된 메시지의 크리에이터를 식별하기 위한 메시지 크리에이터 식별자를 포함한다.

필드(MSG 식별자, MSG 클래스 및 MSG 버젼)는 정수 값이다. 예를 들면, MSG 클래스마다 1,000,000 MSG 식별자 및 10,000 MSG 클래스가 있다. 모든 MSG 식별자, MSG 클래스 한쌍은 예를 들면, 100 MSG 버젼을 가질 수 있다. 필드(MSG 클래스)는 예를 들면, 다음과 같이 배열된다. MSG 클래스 1-20은 ILMS를 위해 남겨지며, MSG 클래스 21-100은 주문 배치, 선적등과 같이 미리 정의된 종류이다. 남은 MSG 클래스 9900은 유저 정의를 위한 것이다. 필드(MSG 크리에이터)는 예를 들면, 80 캐릭터를 가질수 있다. 이것은 용이한 자동 전송을 위해서 특정 유저 및 회사가 생성한 모든 메시지 세트를 식별하기 위한 것이다.

5개의 다른 필드와 함께 상기 메시지 정의 레퍼런스는 메시지에 헤더를 형성한다. 이 5개의 다른 필드는 센더 식별자(SENDER Id), 목적지 주소(DESTINATION ADDRESS), 암호 타입(ENCRYPTION TYPE), 압축 타입(COMPRESSION TYPE) 및 어플리케이션 네임(APPLICATION NAME)이다.

필드(센더 식별자)는 첨가된 서버[SRV(m)]의 네임과 함께 서버[SRV(m)]에 의해 인식되는 유저 네임으로서 예를 들면, 이메일 주소(즉, user-xyz@ilserver.com)와 비슷한 방법이다. 필드(목적지 주소)는 관련된 메시지가 전송될 주소를 식별하기 위한 것이다. 목적지 주소는 센더 식별자와 같은 포맷일 수 있다.

필드(암호 타입)는 필요된다면, 적용된 암호 유형을 참조하기 위한 것이다. 필드(압축 타입)는 필요된다면, 이용된 압축 유형을 표시하기 위한 것이다.

필드(어플리케이션 네임)는 관련된 메시지가 함께 어플리케이션을 형성하는 메시지 세트의 일원인지를 표시하기 위한 것이다.

필드[필드 카운트(Field Count)]는 예를 들면, 메시지에 0-256의 필드 수를 제공한다. "필드" 및 그의 내용은 특정한 유형의 데이터 및 그 데이터 자체를 언급한다. 카운트가 0 이상이라면, 사실상의 필드 데이터는 이러한 필드 다음에 온다. 도 2b에서는, 필드(Field)는 타입(Type) 식별자, 크기(Size) 값, 내부 식별을 위한 필드 네임(Name), 디폴트(default) 표시를 위한 필드 라벨(Label) 및 디폴트 표시를 위한 필드 디스크립션(Description)에 의해 정의된다. 뒤따르는 데이터(Data)의 길이는 타입(Type) 및 크기(Size) 필드의 정보를 결합함으로써 알 수 있다. 하나의 필드(Field) 정의는 첨가적인 분리자(separator) 없이 다른 필드(Field) 정의에 직접 뒤따른다.

종종, 특별히 HTML형 데이터에서는, 바이너리 이미지, 사운드 또는 프로그램 데이터를 포함하는 로컬 파일에 대한 레퍼런스가 있다. 이러한 외부 오브젝트 레퍼런스의 정확한 전송 및 레퍼렌싱(referensing)을 보증하기 위해서, 도 2a에서 도시된 바와 같이 자동적으로 메시지 종단에 배치된다. 외부 오브젝트 레퍼런스는 오브젝트를 표시하기 위한 것이다. 메시지가 수신되면, 이러한 오브젝트는 국부적으로 자동적으로 저장되며, 필드 레퍼런스는 그의 새로운 위치에서 상기 오브젝트를 액세스하기 위해서 자동적으로 조정된다. 필드[오브젝트 카운트(Object Count)]는 메시지에 0-256의 오브젝트 수를 제공한다. 카운트가 0 이상이라면, 오브젝트 데이터는 이러한 필드 다음에 온다. 도 2c에서는, 오브젝트(Object)는 MIME 타입(Type)/내용(Content) 식별자, 크기(Size) 값 및 사실상의 오브젝트 데이터(Data)에 의해 정의된다. 하나의 오브젝트(Object) 정의는 첨가적인 분리자 없이 다른 오브젝트(Object) 정의에 직접 뒤따른다.

도 2d에서는, 필드 매핑(Field Mapping)은 예를 들면, 필드 식별자, 매핑 타입 및 매핑 데이터에 의해 정의된다. 도 2e에서는, 액션(Action)은 액션 타입 및 액션 데이터에 의해 정의된다.

서버(SRV) 키(key)를 이용한 디지털 서명(Digital Signature)은 가급적이면 전체 메시지 상에 생성되며, 오브젝트(Object) 리스트의 종단에 첨가된다.

도 2a, 2b, 2c, 2d 및 2e에서 정의된 허용된 데이터 형태는 이를 테면, 다음과 같다:

1) 유니코드 캐릭터 스트링(unicode character string);

2) 모든 크기의 컴퓨터 하드웨어 독립 정수;

3) IEEE 8바이트 포맷 부동 소수점 수;

4) URL(Universal Resouce Locator);

5) GIF 또는 JPEG 포맷에서 이미지 데이터;

6) MIME 특정의 데이터 리프리젠테이션.

사실상, GIF 및 JPEG 데이터는 또한 MIME 타입으로서 정의된다. 이들 포맷에서 이미지에 대한 특정 데이터 형태를 결정하는 것은 디스플레이 시스템의 HTML 형태에서 그들의 사용 회수에 의해서 결정되었다. 가장 공통적으로 사용된 데이터 형태는 그들 자신의 정의를 가지고 있다. 어떤 첨가적인 데이터 형태는 현행 MIME 타입 또는 특정 MIME 확장으로서 포함될 수 있다. 이들 데이터 형태는 단지 예로서 특정된다. 본 발명의 보호 범위는 본 발명에서의 데이터 형태로 제한되지 않는다.

각각의 메시지는 그 자신의 디지털 서명 및 선택적 암호 및/또는 압축을 가지며, 서버[SRV(m)]에 의해 자동적으로 관리된다.

메시지 데이터베이스

유연성 있는 메시지 포맷 정의, 관리 및 제어 시스템은 관계형 데이터베이스로서 데이터베이스(ILMDB)를 이용하면서 실행되며, 상기 데이터베이스(ILMDB)는,

a) 상세한 메시지 정의;

b) 메시지 매핑 명령:

b.1) 커스터머 데이터베이스 필드 매핑;

b.2) 커스터머 플랫 파일 포맷 매핑;

b.3) 커스터머 유저 인터페이스(HTML) 필드 매핑;

b.4) 다른 메시지 필드 매핑;

c) 메시지 액션 리스트:

(SQL, 자바, 계산, 논리 흐름, 메시지 호출, 외부 프로그램 호출)

c.1) 메시지 전처리 액션;

c.2) 메시지 후처리 액션;

c.3) 메시지 필드 유저 인터페이스 이벤트(event) 액션

을 보유한다.

이러한 정보는 관계형 데이터베이스(ILMDB)의 테이블에 보유되며, 시스템이 어떠한 메시지도 완전히 번역 및 처리할 수 있도록 해준다. 새로운 메시지 정의가 첨가될 수 있고, 이전의 메시지가 변경될 수도 있다. 메시지 정의는 즉시 메시지 데이터베이스(ILMDB)로 통합되기 위해서 서버[SRV(m)]로부터 다른 서버[SRV(m)]로 전송될 수 있다. 모든 유연성 있는 메시지 포맷은 서버[SRV(m)]로 하여금 자동적으로 이전의 볼 수 없었던 메시지를 번역하고 새로운 메시지 정의 입력을 데이터베이스(ILMDB)에 생성할 수 있도록, 충분한 자체 기술 정보를 포함한다. 이러한 새로운 메시지 정의는 리시버의 시스템에 매핑하기 위해서 시스템 관리자에 의해 편집 및 개선될 수 있다.

메시지 데이터는 데이터베이스(ILMDB)에 보존되지 않으며, 단지 그 정의만이 보존된다. 메시지 데이터는 디스크 저장 시스템 상에 압축된 파일로 보존된다. 이러한 파일은 시스템 관리자에 의해 선택된 서버 메시지 존속 옵션에 따라 주기적으로 보관 또는 삭제된다.

수신 또는 전송된 메시지를 정의 및 제어하기 위해서 필요한 데이터베이스(ILMDB) 내에 있는 주요 관계 테이블은 다음과 같다.

테이블 네임	설명
msgdef	InterLingua^TM메시지 정의
flddef	메시지 필드 정의
fldmap	필드 매핑
fldact	필드 액션 정의(필드마다 하나의 액션)
msgpre	메시지 전처리(메시지 액션의 시퀀스)
msgpost	메시지 후처리(메시지 액션의 시퀀스)

능숙한 시스템 개발자는 좀더 용이하게 사용할 수 있는 전체 시스템을 만들기 위해서 그리고 종속적인 시스템 특징부를 제어하기 위해서 필요한 관계된 정보의 많은 다른 테이블이 있다는 것을 인지할 것이다. 이러한 예로, 유저 어카운트 및 유저 정보와 시스템 관리 및 시스템 보안에 관련된 모든 테이블이 있을 수 있다. 상기 제시된 테이블은 본 발명의 실시예에 따라서 본 발명을 실행하기 위해서 필요한 핵심 테이블이며, 확장 또는 개선도 본 발명의 범주 내에 있는 것으로 고려된다.

테이블:msgdef

이 테이블은 메시지의 주요 정의를 보유한다. 메시지는 이 테이블의 처음 4개의 필드에 의해서 완전히 식별되며, 상기 필드는 또한 메시지 헤더에도 있다(도 2a 참조). 다섯번째 필드(msysid)는 서버 프로세서(ILMS)에 의해서 내부적으로 할당된 식별자이며, 데이터베이스 내에 있는 다른 테이블에 빠른 액세스 및 식별을 위한 레퍼런스로서 이용된다.

필드 네임	유형	설명
msgid	integer	메시지 식별자
msgver	integer	메시지 버젼
msgclass	integer	메시지 클래스
creatid	char	크리에이터 식별자
msysid	integer	메시지 시스템 식별자
creatdate	date	생성된 날짜
usedate	date	사용된 날짜
다음 2개의 필드는 ILMS에 의해서 얼마나 오랜동안 메시가 저장되는가를 제어한다.
durdays	integer	존속 일(day)
durmins	integer	존속 분(mimute)
다음 2개의 필드는 암호 및 디지털 서명 알고리즘 방식을 식별한다.
encrtype	char	암호 타입
sigtype	char	디지털 서명 타입
다음 필드는 메시지가 디스플레이를 위한 것인지 아닌지를 표시한다.
silent	boolean	메시지 사일런트(silent) 플래그(flag)
다음 필드는 메시지가 액션에 응답 또는 개시할 수 있는지를 표시한다.
active	boolean	처리 인에이블(enable) 플래그
msgicon	char	(ILMC 디스플레이에 대한) 메시지 아이콘(icon) 파일
msghtml	char	(ILMC 디스플에이에 대한) 메시지 HTML 파일
다음 필드는 메시지가 어플리케이션에서 처음인지를 표시한다.
appmain	boolean	어플리케이션 메인(main) 플래그
다음 필드는 메시지가 어플리케이션의 일부라면 네임을 포함한다.
appname	char	어플리케이션 네임
descr	char	메시지 디스크립션(description)

테이블:flddef

이 테이블은 모든 메시지의 모든 필드에 대한 주요 정의를 보유한다. 필드는 테이블(msgdef)에 할당된 'msysid'와 필드 시퀀스 수(fldseq) 또는 필드 네임(fldname)에 의해서 유일하게 식별된다.

필드 네임	유형	설명
msysid	integer	메시지 시스템 식별자
fldseq	integer	필드 시퀀스
fldname	char	필드 네임
다음 3개의 필드는 1, 2(테이블) 또는 3 디멘션 어레이를 생성하기 위해서 사용된다.
ar1	integer	어레이 디멘션(array dimension) 1
ar2	integer	어레이 디멘션 2
ar3	integer	어레이 디멘션 3
fldtype	char	필드 데이터 타입
다음 필드는 상기 데이터 타입에 따라서 상이하게 번역된다.
fldsize	integer	필드 크기
다음 필드는 필드가 데이터 구조로서 다른 메시지에 대한 레퍼런스라면 사용된다.
smsysid	integer	서브 메시지 시스템 식별자
다음 2개의 필드는 필드가 MIME 데이터를 포함한다면 사용된다.
mimecont	char	MIME 내용 식별자
mimetype	char	MIME 타입 식별자
fldlabel	char	(ILMC 디스플레이에 대한) 필드 라벨
fldcom	char	(ILMC 대스플레이에 대한) 필드 코멘트

테이블:fldmap

이 테이블은 필드가 이용할 매핑 정보를 보유한다. 이 테이블은 데이터베이스 필드, 플랫 파일 필드 및 다른 메시지 필드에 대한 매핑을 정의할 수 있다. 상기 필드는 테이블(flddef)과 같은 방법으로 식별된다. 필드가 어레이로 정의된 경우를 제외하고는, 각각의 필드를 고려한 하나의 디스플레이에 대한 매핑 및 하나의 데이터에 대한 매핑이 있다. 데이터 및 디스플레이 매핑은 하나 또는 그 이상의 요소나 어레이의 디멘션 로우(row)로 할당될 수 있다.

파일 네임	유형	설명
msysid	integer	메시지 시스템 식별자
fldseq	integer	필드 시퀀스
fldname	char	필드 네임
다음 3개의 필드는 특정 어레이 요소 또는 디멘션 로우에 대한 매핑을 허용한다.
ar1	integer	어레이 디멘션 1
ar2	integer	어레이 디멘션 2
ar3	integer	어레이 디멘션 3
다음 필드는 데이터가 가장 최근의 유효한 이전 메시지로부터 그와 동일한 메시지 환경 내에 전송될수 있도록 해주며, 특별한 유저 연결에 대한 현행 유효한 메시지의 세트이다.
cpyfld	char	(Msg로부터) 카피(copy) 필드
다음 3개의 필드는 특별한 필드를 SQL 액세서블 관계형 데이터베이스에 특정하기 위해서 사용된다.
dbnam	char	데이터베이스 네임
tblnam	char	테이블 네임
fldnam	char	필드 네임
다음 필드는 디스플레이에 대한 HTML 파일(msgdef.msghtml)로 필드를 특정한다.
tagnam	char	HTML 태그(tag) 네임
다음 2개의 필드는 고정 필드 길이 또는 콤마 분리 값의 플랫 파일을 특정한다.
flatfile	char	필랫 파일 네임
filetype	char	파일 타입(고정, CSV)
다음 4개의 필드는 플랫 파일에 대한 필드 위치를 특정한다.
rowbegin	integer	로우(row) 시작
colbegin	integer	컬럼(column) 시작(또는 CSV에 대한 필드 # )
rowend	integer	로우 끝
colend	integer	컬럼 끝

테이블:Fldact

이 테이블은 필드가 이용할 어떠한 액션 정보를 보유한다. 액션은 액션의 데이터베이스 형태 및 액션의 논리 형태일 수 있다. 필드가 어레이로 정의되는 경우를 제외하고는, 필드 마다 하나의 액션이 있다. 액션은 하나 또는 그 이상의 요소나 어레이의 디멘션 로우로 할당될 수 있다.

필드 네임	유형	설명
msysid	integer	메시지 시스템 식별자
fldseq	integer	필드 시퀀스
fldname	char	필드 네임
ar1	integer	어레이 디멘션 1
ar2	integer	어레이 디멘션 2
ar3	integer	어레이 디멘션 3
다음 필드는 액션 타입을 정의 한다:SQR 또는 IS, 파일 또는 로컬.
acttype	char	액션 타입
다음 필드는 컨텐츠가 SQL 또는 IS인 파일 네임, SQL 또는 IS를 포함한다.
actscript	char	액션 스크립

테이블:msgpre 및 msgpost

2개의 테이블(msgpre 및 msgpost)은 동일한 구조를 가지고 있다. 테이블(msgpre)은 특별한 메시지에 대한 전처리로서 서버 프로세서(ILMS)에 의해 실행되는 액션 리스트를 보유한다. 이것은 어떠한 디스플레이 또는 필드 액션이 발생하기 전에, 서버 프로세서(ILMS)가 리스트 또는 전처리 기능을 완성하는 것을 의미한다. 테이블(msgpost)은 특별한 메시지에 대한 후처리로서 서버 프로세서(ILMS)에 의해 실행되는 액션 리스트를 보유한다. 이것은 모든 다른 메시지 액션 및 디스플레이가 완성된 후에, 서버 프로세서(ILMS)가 주 메모리로부터 메시지를 삭제하기 전에 후처리 기능의 리스트를 완성하는 것을 의미한다. 프로세서 시퀀스 수는 액션 리스트의 제어된 실행을 생성하기 위해서 사용된다. 이전 시퀀스 수는 다음 것이 시작하기 전에 완성되어야만 한다. 만약 동일한 시퀀스 수를 가진 액션이 더 있다면, 그들은 동시에 시작하거나 진정한 병렬 프로세서로서 복수의 CPU 또는 대규모의 병렬 환경 내에서 시작할 것이다.

테이블:msgpre

필드 네임	유형	설명
msysid	integer	메시지 시스템 식별자
procseq	integer	처리 시퀀스
다음 필드는 액션 타입을 정의한다:SQL 또는 IS, 파일 또는 로컬.
proctype	char	전처리 타입
다음 필드는 컨텐츠가 SQL 또는 IS인 파일 네임, SQL 또는 IS를 포함한다.
procscript	char	전처리 스크립트

테이블:msgpost

필드 네임	유형	설명
msysid	integer	메시지 시스템 식별자
procseq	integer	처리 시퀀스
다음 필드는 액션 타입을 정의한다:SQL 또는 IS, 파일 또는 로컬.
proctype	char	후처리 타입
다음 필드는 컨텐츠가 SQL 또는 IS인 파일 네임, SQL 또는 IS를 포함한다.
procscript	char	후처리 스크립트

InterLingua^TM스크립트(액션 정의 및 제어 언어)

메시지 전처리 및 후처리 또는 필드 액션에 대한 액션은 SQL 액션 또는 IS 액션일 수 있다. SQL(Structure Query Language)은 관계형 데이터베이스에 대한 ANSI 표준 인터페이스 언어이다. IS(InterLingua^TMScript)는 서버 프로세서(ILMS)의 미리 결정된 부분이며(도 1 참조), 메시지에 어플리케이션 레벨 기능을 부여하는 작지만 강력한 계산, 실행 및 조건 논리 문 세트이다. 본 발명에서의 IS에 대한 정의는 다음과 같다:

계산

덧셈(+), 뺄셈(-), 곱셈(*) 및 나눗셈(/) 연산은 정수 및 부동 소수점 값에 사용된다. 괄호 "( )"는 수학적 연산에 사용된다.

대입

대입(=)은 정수, 부동 소수점 값, 스트링 및 URL에 사용된다.

논리 및 조건

"AND"(논리곱), "OR"(논리합), "＞"(보다 크다), "＜"(보다 작다), "＞="(보다 크거나 같다), "＜="(보다 작거나 같다), "="(같다), "!="(같지 않다) 및 "!"(부정)을 표현하는 기호는 정수, 부동 소수점 값, 스트링 및 URS에서 사용된다.

제어 흐름

END-MSG - 메시지 종료. 자체의 전처리 리스트로부터의 최종 명령이어함.

END-APP - 어플리케이션 종료. 멤버(member) 메시지 후처리 리스트로부터의 최종 명령이어함.

For Loop:

FOR i = x TO y

BEGIN

＜문＞

END

While Loop:

WHILE ＜조건＞

BEGIN

＜문＞

END

If-Then-Else:

IF ＜조건＞ THEN

BEGIN

＜문＞

END

ELSE

BEGIN

＜문＞

END

커맨드

매핑된 필드 데이터를 로드하라:

LOAD {WHERE ＜외부 필드 네임＞ = ＜값＞}

매핑된 필드 데이터를 저장하라:

STORE {WHERE ＜외부 필드 네임＞ = ＜값＞}

외부 프로그램을 실행하라:

CALL [ JAVA | EXEC | SHELL ] ＜프로그램 네임＞＜파라메터 1＞...＜파라메터 n＞

메시지를 실행하라:

ILMP://＜호스트 네임＞/＜메시지 식별자＞

내부 펑션을 실행하라(이것은 유저 인터페이스 이벤트에 대해 사용된다):

ILMP://＜호스트 네임＞/＜메시지 식별자＞/＜필드 식별자＞[ UI-ACT | MSG-END | APP-END ]

ILMP://＜호스트 네임＞/＜메시지 식별자＞/＜필드 식별자＞[ ADD-DATA | DEL-DATA | CHG-DATA ]＜데이터＞

어플리케이션

InterLingua^TM메시지들은 함께 분류되며, InterLingua^TM어플리케이션으로서단일하게 명명 및 사용될 수 있다. 이러한 논의 목적에 대해서, 어떠한 프로그래밍 언어 또는 시스템 플랫폼에 대해서, 어플리케이션은 입력 데이터 및 유저 및 시스템 이벤트에 의존하는 것을 변경할 수 있는 연산 시퀀스를 가진 하나 또는 그 이상의 펑션으로서 정의될 수 있다; 외부 저장 장치와 인터랙트 및 액세스할 수 있고; 유저 인터페이스를 통해서 유저와 인터랙트할 수 있다.

이 지명된 메시시 세트 모두 또는 일부는 하나 또는 그 이상의 위치에 하나 또는 그 이상의 서버[SRV(m)]에 거주할 수 있다. 이 지명된 메시지 세트 또는 어플리케이션은,

a) 지시된 일련의 펑션

b) 로컬 및 공유 데이터

c) 유저 인터페이스 스크린

d) 네트워크 분산 어플리케이션 기능

을 이행한다.

지시된 일련의 펑션은 데이터베이스 쿼리와 같은 액션 타입, 계산 및 첨가 메시지의 활성화 중의 어느 하나를 포함한다. 이러한 환경에서 메시지를 활성화하는 것은 어플리케이션 펑션을 호출하고, 가까운 유저 인터페이스 스크린을 표시하고, 또는 로컬 또는 외부 네트워크 목적지에 메시지를 전송하는 것과 같은 동등한 기능을 위해 이용될 수 있다. 연산 명령에 대한 실시간 구조 흐름 또는 바꾸어 말하면 지시된 펑션은 메시지 액션 리스트에 의해서 결정되며, 또한 이벤트 액션은 필드 또는 버튼에 대한 마우스 선택과 같이 유저 인터페이스에 의해서 생성된다.

로컬 및 공유 데이터는 허용된 데이터 타입을 포함한다. 이러한 데이터 타입은 데이터 구조로 통합될 수 있다. 이러한 메시지 데이터는 유저 데이터베이스 및 유저 인터페이스에 매핑될 수 있으며, 다른 메시지에 전달될 수 있다. 이러한 개념은 그 자신의 로컬 데이터를 가질 수 있고 어떠한 로컬 데이터를 전달할 수 있는 다른 펑션(메시지)을 호출할 수 있는 기능으로서 메시지를 이용한다. 이러한 로컬 데이터가 둘 또는 그 이상의 메시지 사이에 전달될 때, 그것은 공유 데이터로 된다.

네트워크 분산 어플리케이션 기능은 메시지 센더 및 리시버로서 InterLingua^TM클라이언트[ILMC(n)] 및 서버의 고유 기능을 이용함으로써 이행될 수 있다. 어플리케이션 세트가 하나의 서버 상에서의 단일 어플리케이션과 대조하여 몇 몇 서버를 걸쳐 분산형으로 실행되기 위해서 생성된다면, 이에 대한 주요한 차이점은 어플리케이션 펑션으로서 활동하는 하나 또는 그 이상의 메시지가 로컬 서버 보다는 오히려 목적지로서 멀리 떨어진 서버를 가질 것이다라는 점이다. 이것은 이전에 볼 수 없었던 간단함 및 유연성을 가진 매우 수월한 네트워크 분산 어플리케이션을 생성한다.

InterLingua^TM메시지 클라이언트(ILMC) 및 서버(SRV)

가급적이면, InterLingua^TM메시지 클라이언트(ILMC) 소프트웨어는 완전히 자바로 기록되며, 또한 자바를 사용할 수 있는 컴퓨터 시스템을 실행할 수 있으며, 가장 일반적으로 사용되는 거의 모든 컴퓨터를 포함한다. InterLingua^TM메시지 클라이언트(ILMC)는 HTML/VRML/자바 애플릿 디스플레이 콘솔(console) 및 서버[SRV(m)]에 대한 네트워크 통신 인터페이스로서 기능한다.

유저 인터페이스 스크린은 메시지와 HTML 정의를 결합하는 능력 및 메시지와 HTML 디스플레이 사이에 데이터를 매핑하는 능력을 이용한다. 이것은 선택한 펑션(메시지)이 필요한 유저 인터페이스를 갖도록 한다. 유저 키보드 및 마우스 이벤트는 필드 액션에 연계된다.

한 서버로부터 다른 서버로, 서버와 터미널(ILMC) 사이에서의 메시지 송수신 기능을 이행하는 통신 서브 시스템은, 멀티스레드(multi-threaded) 방식으로 최적화 설계되며, 메시지의 완전성을 검사하기 위한 체크섬의 이용을 디지털 서명의 사용으로 대체한다. 이것은 수신된 메시지의 완전성을 철저히 확인할 수 있도록 해주며, 동시에 센서의 신원 및 인증에 대한 시큐어러티(security) 검증을 허락한다. 통신 서브 시스템은 서버(SRV) 및 터미널(ILMC) 모두에 존재한다. 통신 서브 시스템은 독립된 네트워크 프로토콜로 설계된다. 통신 서브 시스템은 그의 현행 버젼으로 TCP/IP, XTP/IP 및 XTP/ATM/AAL5를 실행할 것이나, 그것은 AppleTalk, IPX, SNA, X.25, DECNET, OSI 또는 소켓 인터페이스 및 포인트 투 포인트 어드레싱 스킴(scheme)을 이용할 수 있는 어떤 다른 프로토콜을 용이하게 실행할 것이다.

통신 서브 시스템은 본 발명의 중요한 부분이 아니다. 본 발명의 진보는 많은 다양한 형태의 통신 서브 시스템에 이행될 수 있다. 본 기술 분야의 당업자는 통신 서브 시스템이 높은 전송 성공율 및 데이터 보전율을 보증할 수 있는 신뢰성 있는 전송 프로토콜을 가지는 한, 상기 선택된 네트워크 통신 서브 시스템의 형태 및 상세한 이행은 본 발명의 기능을 변경하지 않을 것임을 인지할 수 있다.

유럽 특허 출원 번호 제97202945.8호인 발명에서 설명 및 청구된 바와 같은 메시지 프라이어티 스케줄링 및 서비스 매커니즘은 상기 통신 서브 시스템에 첨가될 수 있다. 이러한 매커니즘은 개인 프라이어티 레벨을 위한 분리된 커넥션을 이용하여, 모든 메시지 프라이어티 레벨에 대한 공평한 서비스를 자동적으로 보증하기 위한 간단한 네트워크 및 시스템 버퍼링 알고리즘을 이용한다. 이러한 매커니즘은 메시지 크기를 모니터하거나 더 낮은 프라이어티 메시지가 로크아웃되는 것을 방지하기 위한 복잡한 스케줄링 알고리즘이 필요치 않으며, 높은 프라이어티 메시지를 계속해서 더 빠르게 전송한다.

메시지 수신

서버[SRV(m)]에 의해 수신된 메시지는 통신 서브 시스템을 통해 전달될 것이다. 디지털 서명이 검증되면 수송층 헤더는 제거될 것이다. 메시지가 암호 또는 압축되었다면 이때 해독 또는 해제될 것이다. 메시지는 그 후에 데이터베이스 층(ILMDB)에 전달될 것이다.

메시지 정의가 소망 위치에 부재하면, 모든 데이터베이스 메시지 정의는 특별한 메시지 또는 메시지 그룹으로 자동적으로 교환될 것이며, 그에 의해서 다수의 유저를 위한 교환된 공통 포맷 메시지를 용이하게 생성한다.

양자 택일로, 수신된 메시지에 대한 메시지 정의가 존재하지 않는다면, 그 메시지는 시스템 관리자의 인박스(in-box)로 전송될 것이다. 그 때, 시스템 관리자는 터미널(ILMC)을 이용하여 메시지를 검사할 수 있으며, 자동적으로 기본 메시지 정의를 첨가하여 메시지 필드를 필요한 로컬 데이터베이스 필드 및 HTML 디스플레이 필드에 연계할 수 있다. 또한, 시스템 관리자는 그 메시지의 센더에게 완전한 메시지 정의를 전송하도록 자동적으로 요청할 것이며, 그 완전한 메시지 정의는 로컬 데이터베이스(ILMDB)에 자동적으로 배치될 것이다. 이러한 요청은 한 서버로부터 다른 서버로 메시지처럼 전송될 것이다.

수시된 메시지에 대한 메시지 정의가 존재한다면, 그 메시지는 데이터베이스(ILMDB)로부터 리드(read)될 것이다. 메시지 전처리 액션 리스트는 서버[SRV(m)]에 의해 실행될 것이며, 메시지 필드에 대한 타당성 검사, 데이터베이스 쿼리, 계산 및 다른 메시지등의 펑션을 규정한다. 메시지가 디스플레이를 위해 유저로 전송되면, 터미널(ILMC)의 프로세서 1은 메시지를 지정된 HTML 파일과 병합하지만, 지정된 HTML 파일이 프로세서 1에 의해 발견되지 않으면, 터미널(ILMC)은 디폴트 동적 HTML을 생성할 것이다. 필드 액션은 그것이 메시지에서 정의되었다면, 특정 마우스 및 키보드 이벤트에 의해 활성화될 수 있다. 필드 액션은 표준 HTTP URL을 호출, 로컬 이미지의 디스플레이에 대한 요청을 전송, SQL 데이터베이스 트랜잭션을 활성화, 로컬 디스플레이 데이터를 업데이트, 또는 InterLingua^TM스크립트(IS) 명령을 실행할 수 있다. 메시지가 정의된 유저 인터페이스를 가지고 있지 않다면, 그것은 "사일런트(silent)"로 불리어지며, 시스템에서는 단지 시스템 관리자만이 알 수 있다.

사일런트 메시지 전처리 및 엔카운터가 완료될 때에, END-MSG 명령 또는 터미널 메시지 유저 인터페이스는 END-MSG 명령을 전송하며, 서버[SRV(m)]는 메시지 후처리 액션 리스트를 실행할 것이다. 메시지가 어플리케이션의 일부라면, 서버[SRV(m)]가 END-APP를 만나거나 수신할 때까지 메모리에 남아 활동할 것이다. 어플리케이션 세트가 완성되면, 서버[SRV(m)]는 아직 실행되지 않은 모든 메시지 후처리 리스트를 실행할 것이다. 또한, 이러한 기능은 트랜잭션 환경 및 어플리케이션 데이터 및 상태의 자동 유지를 보증한다. 단일 메시지 또는 어플리케이션 세트가 완성되면, 시스템 메모리는 다른 메시지 및 어플리케이션의 사용을 위해서 클린 및 리턴될 것이다.

메시지 전송

터미널(ILMC)로부터:

메시지 포맷(ILMF)은 ILMDB/ILMS로부터 요청 및 수신된다. 메시지 내용 및 주소는 터미널 유저에 의해서 첨가된다. 터미널 사용자는 유저 인터페이스 액션을 통해 사용자가 등록된 서버에게 메시지를 전송한다.

서버[SRV(m)]로부터:

InterLingua^TM스크립트(IS)를 통해서 서버[SRV(m)] 상에서 메시지를 활성화시키기 위한 직접 호출의 결과로서 메시지는 자동적으로 시작될 수 있거나, 서버[SRV(m)]에 의해서 처음으로 수신 및 처리된 연결된 터미널의 요청일 수도 있다. 서버는 어떠한 것이 정의된다면 메시지 전처리를 수행한다. 목적지 주소가 서버 자신이라면, 메시지 후처리는 END-MSG를 만나거나 수신한 후에 실행되며, 메시지는 종료된다. 목적지 주소가 다른 서버라면, 메시지는 통신 서브 시스템에 전달되고, 압축 또는 암호화되며, 디지털 서명을 받아, 포인트 투 포인트 연결을 통해 수신 서버에 전송된다.

두문자 리스트

ANSI(American National Standard Institute)

CORBA(Common Object Request Broker Architecture)

CSV(Comma Separated Value)

EDI(Electronic Data Interchange)

GIF(Graphics Interchange Format)

HTML(Hyper Text Markup Language)

HTTP(Hyper Text Transfer Protocol)

ILMC(InterLingua^TMMessage Client)

ILMDB(InterLingua^TMMessage Database)

ILMF(InterLingua^TMMessage Format)

ILMP(InterLingua^TMMessage Protocol)

ILMS(InterLingua^TMMessage Server)

IS(InterLingua^TMMessage Script)

JDBC(Java DataBase Connectivity)

JPEG(Joint Photographers Expert Group)

MIME(Muli-purpose Internet Mail Extensions)

ODBC(Open DataBase Connectivity)

RDBMS(Relational Database Management Systems)

SNMP(Simple Network Management Protocol)

SQL(Structured Query Language)

URL(Universal Resource Locator)

VRML(Virtual Reality Markup Language)

Claims

유연성 있는 메시지 포맷(ILMF)을 가진 메시지에 의한 센더[SRV(m)]와 리시버[SRV(m)] 간의 포인트 투 포인트 통신 방법에 있어서, 상기 메시지는 모두:

적어도 메시지 정의 레퍼런스(MSG 식별자, MSG 클래스, MSG 버젼, MSG 크리에이터), 센더 식별자 및 목적지 주소를 포함하는 헤더와;

필드의 수(필드 카운트) 및 모든 필드의 내용[필드(1),...], 오브젝트의 수(오브젝트 카운트) 및 모든 오브젝트의 내용[오브젝트(1),...], 필드 매핑의 수(맵 카운트) 및 미리 결정된 필드에 의해 사용될 수 있는 모든 필드 매핑의 내용[맵(1),...], 액션의 수(액션 카운트) 및 적어도 미리 결정된 필드에 의해 사용될 수 있는 모든 액션의 내용[액션(1),...]에 관련된 메시지 내용

을 포함하는 것을 특징으로 하는 통신 방법.
제1항에 있어서, 상기 메시지 정의 레퍼런스는 임의의 상기 메시지를 식별하기 위한 메시지 식별자(MSG 식별자)를 포함하는 것인 통신 방법.
제1항 또는 제2항에 있어서, 상기 메시지 정의 레퍼런스는 메일, 비지니스 메시지, 주문 또는 선적 등의 임의의 상기 메시지에 대한 메시지 클래스를 식별하기 위한 메시지 클래스 식별자(MSG 클래스)를 포함하는 것인 통신 방법.
제1항 내지 제3항 중의 어느 한 항에 있어서, 상기 메시지 정의 레퍼런스는 임의의 상기 메시지의 버젼 번호를 식별하기 위한 메시지 버젼 식별자(MSG 버젼)를 포함하는 것인 통신 방법.
제1항 내지 제4항 중의 어느 한 항에 있어서, 상기 메시지 정의 레퍼런스는 임의의 상기 메시지의 크리에이터를 식별하기 위한 메시지 크리에이터 식별자(MSG 크리에이터)를 포함하는 것인 통신 방법.
제1항 내지 제5항 중의 어느 한 항에 있어서, 상기 헤더는 적용된 암호화 타입에 대한 레퍼런스(암호 타입)를 포함하는 것인 통신 방법.
제1항 내지 제6항 중의 어느 한 항에 있어서, 상기 헤더는 적용된 압축 타입에 대한 레퍼런스(압축 타입)를 포함하는 것인 통신 방법.
제1항 내지 제7항 중의 어느 한 항에 있어서, 상기 헤더는 임의의 상기 메시지가 어플리케이션와 함께 형성된 메시지 세트의 일부인지 아닌지를 표시하기 위한 어플리케이션에 대한 레퍼런스(어플리케이션 네임)를 포함하는 것인 통신 방법.
제1항 내지 제8항 중의 어느 한 항에 있어서, 임의의 상기 메시지는 디지털 서명을 포함하는 것인 통신 방법.
유연성 있는 메시지 포맷(ILMF)을 가진 메시지에 의한 다른 통신 장치[SRV(m)]와의 포인트 투 포인트 통신을 위해서 마련된 처리 수단(ILMS) 및 데이터베이스(ILMDB)를 구비하는 통신 장치에 있어서,

상기 메시지는,

적어도 메시지 정의 레퍼런스(MSG 식별자, MSG 클래스, MSG 버젼, MSG 크리에이터), 센더 식별자 및 목적지 주소를 포함하는 헤더와;

필드의 수(필드 카운트) 및 모든 필드의 내용[필드(1),...], 오브젝트의 수(오브젝트 카운트) 및 모든 오브젝트의 내용[오브젝트(1),...], 필드 매핑의 수(맵 카운트) 및 미리 결정된 필드에 의해 사용될 수 있는 모든 필드 매핑의 내용[맵(1),...], 액션의 수(액션 카운트) 및 적어도 미리 결정된 필드에 의해 사용될 수 있는 모든 액션의 내용[액션(1),...]에 관련된 메시지 내용을 포함하며,

상기 처리 수단(ILMS)은,

상기 미리 결정된 메시지 정의 테이블에 대한 레퍼런스로서 상기 메시지 정의 레퍼런스를 이용하여 상기 데이터베이스(ILMDB)에 저장된 미리 결정된 메시지 정의 테이블(msgdef)를 찾기 위해서 마련되는 것을 특징으로 하는 통신 장치.
제10항에 있어서, 상기 미리 결정된 메시지 정의 테이블(nsgdef)은 임의의 상기 메시지를 식별하기 위한 메시지 식별자(msgid)를 포함하는 것인 통신 장치.
제10항 또는 제11항에 있어서, 상기 미리 결정된 메시지 정의 테이블(msgdef)은 메일, 비지니스 메시지, 주문 또는 선적 등의 임의의 상기 메시지에 대한 메시지 클래스를 식별하기 위한 메시지 클래스 식별자(msgclass)를 포함하는 것인 통신 장치.
제10항 내지 제12항 중의 어느 한 항에 있어서, 상기 미리 결정된 메시지 정의 테이블(msgdef)은 임의의 상기 메시지의 버젼 번호를 식별하기 위한 메시지 버젼 식별자(msgver)를 포함하는 것인 통신 장치.
제10항 내지 제13항 중의 어느 한 항에 있어서, 상기 미리 결정된 메시지 정의 테이블(msgdef)은 임의의 상기 메시지의 크리에이터를 식별하기 위한 메시지 크리에이터 식별자(creatid)를 포함하는 것인 통신 장치.
제10항 내지 제14항 중의 어느 한 항에 있어서, 상기 미리 결정된 메시지 정의 테이블(msgdef)은 적용된 암호화 타입(encrtype)에 대한 레퍼런스를 포함하는 것인 통신 장치.
제10항 내지 제15항 중의 어느 한 항에 있어서, 상기 미리 결정된 메시지 정의 테이블(msgdef)은 적용된 디지털 서명 타입(sigtype)에 대한 레퍼런스를 포함하는 것인 통신 장치.
제10항 내지 제16항 중의 어느 한 항에 있어서, 상기 미리 결정된 메시지 정의 테이블(msgdef)은 상기 데이터베이스(ILMDB)에서 추가의 테이블에 대한 레퍼런스로서 사용되는 메시지 시스템 식별자(msysid)를 포함하는 것인 통신 장치.
제17항에 있어서, 상기 추가의 테이블은 상기 메시지의 모든 필드에 대한 주(主) 정의를 유지하기 위한 필드 정의 테이블(flddef)을 포함하는 것인 통신 장치.
제17항 또는 제18항 중의 어느 한 항에 있어서, 상기 추가의 테이블은 예를 들면, HTML 필드, 데이터베이스 필드, 플랫 파일 필드 및 기타 메시지 필드인 미리 결정된 필드에 의해 사용될 수 있는 매핑 정보를 가진 필드 매핑 테이블(fldmap)을 포함하며, 상기 데이터베이스 필드 및 플랫 파일 필드는 커스터머 데이터베이스에 저장되는 것인 통신 장치.
제17항 내지 제19항 중의 어느 한 항에 있어서, 상기 추가의 테이블은 미리 결정된 필드에 의해 사용될 수 있는 액션 정보를 가진 필드 액션 테이블(fldact)을 포함하는 것인 통신 장치.
제17항 내지 제20항 중의 어느 한 항에 있어서, 상기 추가의 테이블은 수신된 또는 전송될 메시지에 대한 전처리로서 실행될 액션의 리스트를 포함하는 메시지 전처리 테이블(msgpre)과, 수신된 메시지에 대한 후처리로서 실행될 액션의 리스트를 포함하는 메시지 후처리 테이블(msgpost)을 포함하는 것인 통신 장치.
제20항 또는 제21항 중의 어느 한 항에 있어서, 상기 필드 액션 테이블(fldact), 상기 메시지 전처리 테이블(msgpre) 및 상기 후처리 테이블(msgpost)은 데이터베이스 액션 타입 및 수학적 계산, 대입, 논리 연산, 조건 연산 및 명령을 포함하는 논리 액션 타입의 그룹으로부터 선택되는 액션 타입에 대한 레퍼런스를 포함하는 것인 통신 장치.
제10항 내지 제22항 중의 어느 한 항에 있어서, 상기 메시지 정의 테이블(msgdef)은 수신된 메시지가 어플리케이션의 처음 메시지인지를 표시하기 위한 어플리케이션 필드(appmain)와 상기 어플리케이션의 이름을 나타내기 위한 어플리케이션 네임 필드(appname)를 포함하는 것인 통신 장치.
제23항에 있어서, 상기 어플리케이션은 다수의 통신 장치에 분산된 분산 어플리케이션인 통신 장치.
제10항 내지 제24항 중의 어느 한 항에 있어서, 상기 통신 장치는, 수신된 메시지가 그의 데이터베이스(ILMDB)에 존재하지 않는 메시지 정의에 관한 것이라면, 센더에게 새로운 메시지 정의를 요청하고, 상기 센더로부터 상기 새로운 메시지 정의를 수신한 후, 상기 데이터베이스(ILMDB)에 있는 상기 메시지 정의 테이블(msgder)에 상기 새로운 메시지 정의를 저장하기 위해서 마련되는 것인 통신 장치.
제10항 내지 제25항 중의 어느 한 항에 있어서, 상기 처리 수단(ILMS)은 수신된 메시지를 지정된 HTML 파일과 병합하거나, 상기 지정된 HTML 파일이 상기 처리 수단(ILMS)에 의해 발견되지 않는다면 디폴트 동적 HTML 파일을 생성하기 위해서 마련되는 것인 통신 장치.
제10항 내지 제25항 중의 어느 한 항의 통신 장치[SRV(m)] 및 상기 통신 장치에 연결된 터미널(ILMC)을 포함하는 시스템에 있어서,

상기 터미널은 터미널 프로세서(1), 디스플레이 장치(6) 및 사용자가 데이터를 입력하기 위한 입력 수단(12, 13)을 포함하며,

상기 통신 장치는 상기 터미널이 수신된 메시지에서 목적지 주소가 표시된다면 상기 터미널에 상기 수신된 메시지를 전달하기 위해서 마련되며,

상기 터미널 프로세서(1)는 상기 메시지를 지정된 HTML 파일과 병합하거나 상기 지정된 HTML 파일이 상기 터미널 프로세서(1)에 의해 발견되지 않는다면 디폴트 동적 HTML을 생성하기 위해서 배치되는 것을 특징으로 하는 시스템.