KR20010040348A - 확장가능한 분산된 기업용 애플리케이션 통합 시스템 - Google Patents

확장가능한 분산된 기업용 애플리케이션 통합 시스템 Download PDF

Info

Publication number
KR20010040348A
KR20010040348A KR1020007007862A KR20007007862A KR20010040348A KR 20010040348 A KR20010040348 A KR 20010040348A KR 1020007007862 A KR1020007007862 A KR 1020007007862A KR 20007007862 A KR20007007862 A KR 20007007862A KR 20010040348 A KR20010040348 A KR 20010040348A
Authority
KR
South Korea
Prior art keywords
message
adapter
string
agent
data
Prior art date
Application number
KR1020007007862A
Other languages
English (en)
Other versions
KR100684680B1 (ko
Inventor
이혼시유
테일러존티모시
고던가리알란
Original Assignee
사가 소프트웨어, 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/412,595 external-priority patent/US6256676B1/en
Application filed by 사가 소프트웨어, 인크. filed Critical 사가 소프트웨어, 인크.
Publication of KR20010040348A publication Critical patent/KR20010040348A/ko
Application granted granted Critical
Publication of KR100684680B1 publication Critical patent/KR100684680B1/ko

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • 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/465—Distributed object oriented systems
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/80—Management or planning

Abstract

네트워크 기업에 걸쳐서 보통 배치되는 타입의 애플리케이션을 통합하는 시스템 및 방법에서 사용되는 에이전트 어댑터 구조 및 메시지 오브젝트가 개시된다. 에이전트는 복수의 어댑터를 밀봉하며, 복수의 어댑터 각각은 복수의 기업용 애플리케이션의 각각과 연관된 별개의 기능을 수행하도록 적용된다. 이런 에이전트는 연장가능하며, 하나 이상의 내장된 오브젝트를 포함한다. 각각의 내장된 오브젝트는 복수의 기업용 애플리케이션 각각과 연관되거나 또는 연관되지 않는 별개의 기능을 수행하도록 유사하게 적용된다. 메시지 오브젝트는 복수의 부속물 및 복수의 변환기를 사용하여 적용되는 메시지 스킴을 포함한다. 메시지 스킴은 복수의 섹션부, 복수의 테이블 요소, 및 복수의 아이템 요소로부터 선택되는 복수의 메시지 요소를 포함하는 계층적 데이터 구조이다. 아이템 요소는 복수의 기업용 애플리케이션들중 선택된 것에 대한 네이티브 데이터를 포함한다.

Description

확장가능한 분산된 기업용 애플리케이션 통합 시스템{EXTENSIBLE DISTRIBUTED ENTERPRISE APPLICATION INTERGRATION SYSTEM}
한 논평가에 따르면, 오늘날의 기업의 혈액이 정보라고 할 때, 기업의 동맥은 기업내에서의 데이터 이동을 용이하게 해주는 "애플리케이션간 인터페이스"에 해당한다고 한다. 이를 보다 최근에는 "애플리케이션 네트워크"라고 하고 있다.
통상의 조직체에 있어서, 애플리케이션 네트워크는 유기적으로 결합되어 특수 목적의 애플리케이션 통합 프로그램들로 이루어진 집합체를 형성하게 되었다. 이러한 각종의 애플리케이션들이 집합되어 있어 새로운 애플리케이션을 구축하는데 드는 시간이 증가하고 최고 관리자들이 경영에 대한 명확한 실상을 파악하지 못하게 되어, 요컨대 회사의 동맥이 막혀버리게 됨에 따라 경영에 아주 심각한 영향을 주어 왔다. 애플리케이션 통합이 경쟁력있는 기업으로서 생존하는데 아주 중요하다는 사실에도 불구하고, 종래의 기술에서는, 회사는 이를 위해 장기간 막대한 비용을 들여가면서 커스텀 코드(custom code)를 수작업으로 작성(handcraft), 즉 해크(hack)하는 것을 당연시해오고 있었다. 장기간의 애플리케이션 통합 결정도 마찬가지로 단지 개별적인 프로젝트 기준에 따라 가장 낮은 수준에서 이루어져 왔다. 이들 문제의 특성상 명확한 해결책을 찾기가 어렵기 때문에, 효과적인 기업용 애플리케이션 통합(enterprise application integration, EAI) 솔루션을 찾아내야만 한다.
인터넷의 출현, 클라이언트/서버 컴퓨팅, 기업 합병 및 매수, 글로벌화 및 경영 프로세스 리엔지니어링 등으로 인하여, 기업의 정보기술(IT) 부서는 이 기종의 시스템들이 그 일부가 얼마나 구식 기종인지에 관계없이 서로 통신할 수 있도록 하는 새로운 방법-종종 수작업에 의하지만-을 계속 강구해야만 한다. 이에 따른 혼란속에서, 부적절한 통신 시스템으로 인해 기업 운영에 필요한 IT의 대처 능력을 떨어뜨리는 결과를 가져온다.
최근 IT의 동향을 살펴보면, 이러한 것들을 지원하기 위하여 애플리케이션간 인터페이싱의 양이 증가함에 따라 이 문제는 더 악화되고 있다. 가장 최근에는, 기업용 애플리케이션들이 데이터 웨어하우징 및 전사적 자원 관리(ERP) 등의 기능을 수행하여 전자 상거래를 촉진시키고 있다. 따라서, 이들 3가지 기술들을 개략적으로 살펴보는 것이 아직도 미해결의 숙원 사업인 EAI의 필요성을 이해하는데 도움이 될 것이다.
데이터 웨어하우징 기술에서는 많은 분량의 클린 이력 데이터(clean historical data)를 정규적으로 다수의 가동중인 시스템으로부터 웨어하우스로 이동시켜야만 한다. 소스 데이터는 보통 온라인 거래 처리(online transactional processing, OLTP)용으로 구성된 반면, 통상의 데이터 웨어하우스는 온라인 분석 처리(online analytical processing, OLAP) 포맷에도 적합하게 되어 있다. 따라서, 소스 데이터는 웨어하우스로 전송될 때 광범위하게 군집화(aggregation) 및 재포맷화(reformatting)가 되어야만 한다.
종래 기술에 따른 통상의 데이터는 이하의 4 단계에 따라 정착된다: (a) 소스 데이터의 추출 단계; (b) 이 추출된 데이터의 클리닝 단계; (c) 추출되어 클리닝된 데이터를 다수의 크기로 군집화(aggregate)하는 단계 ; 및 (d) 웨어하우스(warehouse)에 로딩하는 단계. 각각의 웨어하우스 소스는 특정 데이터 추출, 클리닝, 군집화 및 로드 루틴을 작성할 필요가 있다. 포레스터 리서치(Forrester Research)에 따르면 보통의 큰 회사는 약 4개의 데이터 웨어하우스를 가지고 있다고 한다. 2년 후에 이 개수는 6개로 증가할 것으로 예상되고 있다. 각 웨어하우스내에 포함된 평균 데이터량도 이 동일 기간후에 그 크기가 2배로, 즉 약 130 기가바이트에서 약 260 기가바이트로 될 것으로 예상된다.
이와같이 많은 데이터량이 계속적으로 증가하고 있는데 따른 문제점은 소스 데이터의 품질로 더 악화되고 있다. 메타 그룹(META Group)이 실시한 연구에 따르면, 일반적인 데이터 웨어하우스에는 현재 20%정도나 저품질의 데이터가 로드되고 있다. 이 연구에 따르면, 그 응답자 중 약 70%가 수작업으로 코딩한 추출, 클리닝, 및 로딩 프로세스를 사용하였다고 한다. 필수적인 군집화 프로세스에 있어서는, 이 기능 하나를 완료하는데 50시간이나 되는 컴퓨터 타임이 소요되기도 한다는 사례가 있기도 하다. 이러한 방식으로 코딩된 프로그램에는 상당한 유지 보수 노력이 있어야 한다는 것은 너무나도 자명하다.
반면에, 통상의 ERP 시스템(예를 들면, 독일 발도르프(Walldorf) 소재의 SAP AG가 개발한 R/3 기업용 애플리케이션과, 피플 소프트(PeopleSoft), 오라클(Oracle) 및 바안(Baan)이 개발한 애플리케이션)은 기본적으로 급여(payroll), 제조(manufacturing), 재무제표(general ledger) 및 인사(human resources) 등의 핵심적인 경영 기능들을 지원하는 대규모의 통합·패키지화된 애플리케이션이다. 큰 기업체들은 이러한 소프트웨어 솔루션을 한 업체로부터 구입하는 것이 특히 낫다는 것을 알고 있다. 이것는 동일 기능을 회사내에서 개발하는 것이 그것을 구매하는 것보다 10 내지 20배 이상의 비용이 들 수 있기 때문이다. 그러나, ERP 시스템을 구축하는 일은 여러가지 이유로 엄두도 못낼 작업이 될 수 있다.
우선 첫째로, 회사는 제품을 구매하지 솔루션을 제작하지는 않는다. 이것은 회사내의 경영 조직을 달리 어떻게 하지 않고 그 제품 및 그의 동작 방식에 적합하게 만들어야만 한다는 것을 의미한다. 게다가, 오늘날의 ERP 시스템이 회사의 모든 커스텀 솔루션을 대체할 수는 없다. 따라서, 이들도 현재 사용중인 다른 레거시 시스템과 효과적으로 통신해야만 한다. 결국, 한 업체가 조직의 모든 필요를 충족시킬 수 없는 것이 보통이기 때문에, 회사가 하나 이상의 완전히 서로 다른 ERP 시스템을 사용하는 것은 전혀 이상한 것이 아니다.
결과적으로, ERP 시스템에 대한 데이터의 출납 방식의 다양성으로 인해 데이터 웨어하우징에 사용한 기존의 방법이 쓸모없게 된다. 각 ERP 시스템은 그 전유의 데이터 모델을 가지며 이는 그 판매업체에 의해 계속적으로 개량되고 있다. 이러한 모델을 조작하는 추출 또는 로드 루틴을 작성하는 것은 복잡할 뿐만 아니라 판매업체가 이를 하지 못하게 하는데 그 이유는 기업용 애플리케이션에 내재하는 데이터 검증 및 경영 룰을 간과할 가능성이 있기 때문이다. 그 대신에, ERP에서는 재무제표, 예산 또는 미불금(accounts payable) 등의 특정 경영 현상(business entity)을 처리하는 경영 오브젝트 레벨에서의 상호작용이 필요하게 된다. 널리 알려지고 채택된 ERP 시스템의 구축 및 사용에 관한 더 구체적인 상세에 대해서는 큐 코포레이션(Que Corporation)의 1997년판 Special Edition Using SAP R/3(2판), ISBN:0-7897-1351-9에서 찾아볼 수 있다.
수년동안 이런저런 형태의 전자 상거래가 이루어져 왔다. 그 본질에 있어 전자 상거래의 출발점은 전자 서류 교환(electronic data exchange, EDI)에서부터다. EDI로 인해 많은 회사들이 그들의 구매 주문서나 송장을 전자적으로 통보할 수 있게 되었고, 이처럼 계속 발전하여 오늘날의 회사들은 공급 연쇄 관리(supply chain management)를 위해 EDI를 사용할 정도가 되었다. 그러나, 보다 최근에 들어서서는 관심있는 물건들을 구매, 판매, 심지어 경매하기 위해 온라인 인터넷 웹사이트의 사용이 폭발적으로 늘어남에 따라, 확실하고 효과적인 EAI에 대한 필요성이 이와같이 절실하게 되었다. 예를 들면 미국 특허 제5,627,972호 참조.
계획한 기간내에 특정의 경영 목표를 달성하기 위해 애플리케이션들을 개발하게 되었다. 예를 들면, 일반적인 큰 조직내에서는, 각종 운영 시스템(OS), DBMS 및 개발 툴을 사용하는 구성원으로 이루어진 여러 팀들이 수백가지의 애플리케이션을 개발하고 있다. 각 경우에, 여타 다른 애플리케이션과의 통합은 고려하지도 않고 그의 특정 요건만을 충족시키고 있다.
몇몇 대세의 흐름에 따라 시장은 애플리케이션 통합쪽으로 가고 있다. 예를 들면, 피어-투-피어 네트워킹(peer-to-peer networking) 및 분산 처리에서 상당한 발전이 이루어져 기업체들은 그의 기능부서들을 효과적으로 통합할 수 있고 또한 그의 거래처와 공급업자와도 통합할 수 있게 되었다. 상기한 인터넷 /"인트라넷(intranet)"/"익스트라넷(extranet)"의 폭증으로 백-엔드 레거시 애플리케이션(back-end legacy application)과의 통합을 필요로 하는 새로운 계층의 "인간 활동" 애플리케이션에 대한 수요도 촉발시키고 있다. 전세계적으로 기업용 애플리케이션 소프트웨어 패키지(예를 들면, SAP R/3)의 채용이 크게 증가함에 따라서 백-엔드 레거시 애플리케이션과의 통합도 필요하게 되었다. 결국, 메시지 지향 미들웨어(message oriented middleware, MOM)--IBM의 MQ시리즈 메시지 큐잉 제품 등의 제품--가 점점 보급되어가고 있다. 고객이 MOM을 가지고서 간단한 일대일 애플리케이션 접속의 잇점을 깨닫게 된다면, 다대다(many-to-many) 애플리케이션 통합에 대한 그들의 관심도 크게 증가하게 될 것이다.
경영의 통합 필요성이 증가함에 따라, 애플리케이션 통합에 드는 IT 달러도 급속히 증가하고 있다. 여러 산업 분석가들에 따르면, "특수 목적(mission critical)" 애플리케이션 통합의 필요성으로 인해 시장의 통합이 가속화되어 MOM이나 "메시지 브로커(message broker)"가 1997년에 300억 달러에서 1999년에는 7억달러를 넘어 성장하는 쪽으로 가게 될 것이라고 한다. 큰 고객에 대한 IBM의 조사에 따르면, 오늘날 작성되는 모든 코드의 거의 70%가 인터페이스, 프로토콜 및 각종 시스템간의 연결을 확립하기 위한 다른 프로시저로 이루어져 있다고 한다. Savvy IT 담당자들은 재고 소프트웨어를 이러한 요건을 만족하도록 함으로써 달러를 절약할 수 있을 것으로 보고 있다.
메시지 브로커는 메시지의 출판자(즉, 송출자)와 가입자(즉, 수신자)간의 계약을 기록 및 관리하는 소프트웨어 허브이다. 경영 사건이 발생하면, 애플리케이션은 그 경영 사건에 해당하는 메시지를 출판한다. 브로커는 그의 가입자 명부를 검토하여 그 메시지 유형에 대한 각 가입자에 전달하게 한다. 가입자는 자기가 가입한 데이터만 수신하게 된다. 어떤 애플리케이션이 출판한 메시지에 다수의 수요자 애플리케이션(consumer application)이 가입할 수 있다. 마찬가지로, 가입 애플리케이션은 다수의 출판 애플리케이션으로부터 메시지를 수신할 수 있다.
애플리케이션은 메시지를 출판 또는 그에 가입하기 전에, 그의 관심 분야를 브로커를 사용하여 등록해야만 한다. 애플리케이션이 관심있는 메시지 유형을 등록하는 기본적인 방법에는 2가지가 있다: 주제별 어드레싱(subject-based addressing) 및 메시지 내용 필터링(message-content filtering). 주제별 어드레싱의 경우, 브로커는 주제를 사용해 메시지를 식별하여 그 주제에 관심을 표명한 모든 상대방에게로 경로지정한다. 이 주제는 메시지의 내용을 기술하는데 사용되는 단어이다. 예를 들면, 명칭 "hr. emp. new"의 주제는 새로 고용한 사원의 정보(예를 들면, 이름, 주소, 사원 번호 등)를 배포하는 역할을 할 수 있다. 반면에, 메시지 내용 경로지정에서는, 그 메시지내의 필드의 내용에 근거하여 가입이 이루어진다. 가입은 메시지 유형 및/또는 메시지내의 필드에 대한 특정 선택 기준에 따라 이루어진다. 예를 들면, 대출 승인 애플리케이션은 10만 달러를 넘는 모든 구매 주문에 가입할 수 있다.
출판/가입의 2개의 패러다임을 가지게 됨으로써 얻는 잇점은 개별 가입 애플리케이션에 메시지를 어드레스할 필요가 없다는 것이다. 그 외에, 출판 애플리케이션에 아무런 변경도 하지 않고 새로운 가입 애플리케이션을 추가할 수 있다는 것이다.
통상의 출판/가입 브로커는 애플리케이션간에 메시지를 실제로 배포하기 위해 확실한 전달체를 사용한다. 특수 목적 메시지가 외부 네트워크와 내부 네트워크의 혼합체를 통해 전달될 때, 시스템 소프트웨어는 네트워크 장해가 있는 경우 메시지가 손실되거나 중복되지 않도록 해주어야 한다. 종종 기억-발송 메시지 큐잉(store-and-forward message queuing)을 이용하는 비동기 메시지 전달 기능이 제공된다. 이와같은 패러다임에서는, 가입 애플리케이션이 이용가능하게 되면, 큐-투-큐 전송(queue-to-queue)이 의사 실시간으로 일어나게 된다. 가입 애플리케이션을 이용할 수 없는 경우에는, 메시지는 지속성 큐(persistent queue)에 기억시켰다가 차후에 전달하게 된다.
효율성을 위해, 메시지 전달체는 비지니스 트랜잭션 코디네이션 기능을 포함해야 한다. 비지니스 트랜잭션은 보통 몇몇 작업 단위로 이루어진다. 각각 및 모든 작업 단위는 트랜잭션이 발생하도록 완료되어야 한다. 만약 하나의 작업 유닛이라도 실패한다면, 전체 트랜잭션을 실패하고, 그러면 반드시 모든 완성된 작업 단위가 번복될 것이다. 이 트랜잭션들은 오랫동안 지속되고, 메시지에 기초한 다중 데이터 베이스로의 갱신을 요구한다. 이 비지니스 트랜잭션 코디네이션 기능은 이런 관리 서포트를 제공한다.
2개의 다른 중요한 성분은 규칙에 기초한 엔진과 데이터 변형 성분이다. 비지니스 규칙 엔진은 조직이 그들의 비지니스의 고유한 필요물에 의거하여 메시지들을 처리하도록 한다. 통상, 비지니스 규칙 엔진들은 처리상의 언어로 프로그램할 필요를 없게 하기 위해 시각적 프론트 엔드를 제공한다. 이런 융통성있는 접근방법으로, 비지니스 처리에서의 변화가 변경된 규칙 구성에 쉽게 반영될 수 있다.
데이터 변형 성분은 애플리케이션 특정 어댑터들을 개발하는데 사용된다. 이 어댑터들은 데이터 포맷 및 애플리케이션 의미 체계(semantics)를 전송 애플리케이션으로부터 수신 애플리케이션으로 변환한다. 많은 변환 필요물들이 있다. 이들은 공유되어야 할 정보의 구조(즉, 구문론(syntax))와, 의미(즉, 의미 체계(semantics)) 및 타이밍 사이에 존재하는 비양립성들을 해결하기 위한 기본 데이터 변형에서부터 범위가 정해진다.
종래 기술에 의하면 애플리케이션 어댑터들을 위한 2개의 주요 전략이 있다. 하나의 전략은 모든 소스 데이터를 변환하여 스탠더드 기준 형식으로 애플리케이션들을 동기화(또는 "sync")하는 것이다. 메시지들은 이 스탠더드 형식으로 소스 어댑터로부터 동기 어댑터로 이동한다. 동기 어댑터에서, 메시지들은 동기 애플리케이션의 포맷으로 변환된다.
애플리케이션 어댑터들의 제2 전략은 어떤 중간 포맷 없이, 1단계에서 포맷과 의미 체계를 전송 애플리케이션에서 수신 애플리케이션으로 자동적으로 변환하는 것이다. 이 접근 방법에서는, 서로와 통신하는 2개의 애플리케이션에 대해 하나의 어댑터만이 요구되고 이 애플리케이션들 중 하나로 통합될 수 있다.
규칙에 기초한 엔진과 데이터 변형 성분은 애플리케이션들간의 차이를 조정하기 위해 함께 작용한다. 예를 들어, 2개의 애플리케이션이 오더(order) 주위에 통합될 수 있기 전에, 오더에 관련된 비지니스 규칙은 각 시스템내에서 정의되어야 한다. 애플리케이션 "A"내에서, 오더는 다수의 파일과 데이터 베이스로부터의 데이터의 집합으로 구성될 수도 있는 반면, 애플리케이션 "B"내에서 오더는 비지니스 트랜잭션의 더 큰 파일내에 포개어 끼워진 각 메시지로서 존재할 수도 있다. 어려운 도전은 각 애플리케이션에서 정의된 바와 같이 데이터의 구조와 오더의 기초가 되는 내용 사이의 비양립성을 해결하는 것이다.
메시지 브로커링(brokering)이 제공하는 많은 잠재적인 비지니스 이점이 있다. 우선 애플리케이션 통합의 용이함이 있다. 메시지 브로커들로, 기존의 리거시(legacy)를 갖는 새로운 애플리케이션들이나 제3자 애플리케이션들이 단기간에 실행될 수 있다. 각 애플리케이션의 내부 구조와 설계를 이해할 필요없이 통합이 발생할 수 있다. 메시지로서의 인터페이스에 초점을 맞춤으로써, 기존의 애플리케이션들이 파괴를 최소화한 채로 통합될 수 있다.
전자상거래에 대한 지원은 메시지 브로커링이 제공하는 제2의 이점이다. 비지니스들이 그 파는 사람들과 파트너들의 공급 체인을 자동화하기 시작함에 따라, 느슨하게 연결된 방식으로 통신하기 위해 그 독립적인 애플리케이션이 필요하다. 이것이 정확하게 메시지 브로커링의 본질이며 강점이다. 메시지 브로커는 비지니스적 요구에 적합하다.
마지막으로, 계속되는 이종(heterogeneity)에 대한 메시지 브로커링 지원이 단지 확실히 가장 적지는 않다. 새로운 기술이 발전하여 옴에 따라, 새로운 구조가 개발되었고, 이종(heterogeneity)이 시간에 걸쳐 증가하고 있다. 메시지 브로커링과 같은 방법론은 오늘날의 다른 종류의 계를 수용하도록 고안되어 있고, 앞으로 유용할 것이다. 새로이, 메시지 브로커내의 기존 애플리케이션으로의 변화없이도, 다른 애플리케이션들이 발행자나 가입자 중 하나로서 시간에 걸쳐 부가될 수 있다.
요컨데, 메시지 브로커들은 기업내에서 통합 이종 애플리케이션에 적어도 공통 명명자 접근법을 제공하기 위한 잠재력을 갖는다. 사용자들은 그 애플리케이션이 기업내에서 다른 애플리케이션과 어떻게 통합하는지에 관계없이, Java(미국 캘리포니아주 마운틴 뷰에 소재한 Sun Microsystems 사의 등록 상표)든지, Active X(미국 워싱턴주 레드몬드에 소재한 Microsoft 사의 등록 상표)든지 또는 COBRA(미국 메사추세츠주 프라밍검에 소재한 Object Management Group 사의 등록 상표)든지 각 개개의 애플리케이션에 대해 최상의 기술을 선택할 수 있다. 이에 의해 메시지 브로커들은 미래의 애플리케이션들 및 오늘날의 애플리케이션 카타로그에 현재 존재하는 본질적으로 다르고 복잡한 상품 및 기술들 간의 격차를 메운다.
메시지 브로커 전략을 채택하는데 많은 이익이 있는 반면, 잠재적인 함정들도 있음을 명심해야 한다. 그 느슨한 연결 융통성면에서 메시지 브로커링의 바로 그 강점이 또한 그 최대 약점이 될 수 있다. 메시지 브로커 소프트웨어의 본질은 상기한 바와 같이 매우 일반화된다는 것이다. 그렇게 많은 다른 상태들을 처리하도록 고안되었기 때문에, 모든 가능한 엔드-투-엔드(end-to-end) 코드 경로들을 테스트하는 것은 극복할 수 없는 업무이다. 미감지 버그가 소프트웨어 내에 존재하는 경우, 메시지는 손실되거나, 두번 전달되거나 지연될 수도 있다. 이와 같은 "사고(accidents)"로부터의 손상은 메시지 브로커를 미션 크리티컬 트랜잭션 프로세싱 애플리케이션(mission critical transaction processing application)들을 통합하기 위해 사용하는 기업에서는 가장 예민하게 느껴질 것이다. 예를 들어, 재정 트랜잭션에서는, 하나의 단일 메시지의 전송이 수백만 달러의 가치가 있을 수 있는 동시에, 그 미전송 또는 지연 전송이 수백만 달러의 손실을 일으킬 수 있다.
메시지 브로커 실행에 대한 두번째 위험은 외국 애플리케이션들이 미인증 메시지들을 브로커에 소개할 가능성이다. 이것도 또한 손실을 일으킨다. 예를 들어, 금융 산업에서, 허위 메시지가 공표되어 기금의 철회나 횡령을 일으킬 수 있다.
메시지 브로커 실행에 대한 세번째 위험은 종래의 "단일 포인트의 실패(single point of failure)"이다. 종래 기술의 메시지 브로커들은 보통 "허브 및 스포크(hub and spoke)" 구조로 구현된다. 이것은 대부분의 메시지 통화가 몇몇 중앙 허브를 통과한다는 것을 의미한다. 이 허브들 중 하나에 운전 중지나 물리적 재해가 있는 경우에, 비지니스의 미션 크리티컬 동작은 작업 중단될 수 있다.
분배된 허브에 있어서의 또다른 문제는 메시지 브로커 복합체를 관리하는 어려움이다. 많은 브로커들이 매우 많은 다른 비지니스 애플리케이션들을 몇몇 결합 허브들로 통합하기 때문에, 메시지 브로커 복합체를 관리하고 감독하는데 요구되는 재능과 전문 지식이 획득될 수 없다.
기업의 미션 크리티컬 트랜잭션 프로세싱 애플리케이션에 기술이 적용될 때마다 잠재적인 위험의 노출은 크다. 메시지 브로커링에 대한 한가지 문제는 그것이 미션 크리티컬 정보를 다룬다는 점이다. 상대적인 관점에서, 메시지 브로커링은 완전히 새롭다. 그런데, 몇몇 초기의 채택 회사들은 메시지 브로커링의 개념으로 큰 성공을 했지만, 메시지 브로커링과 EAI가 주류에 진입할 수 있기 전에 훨씬 더 많은 것이 필요하다.
1980년대에는 소프트웨어 시스템 개발을 이종 시스템들이 서로 통신하도록 하는 능력에 집중했다. 이것은 대부분 독점적인 통신 프로토콜의 확산으로 인한 것이다. 어떤 새로이 개발된 시스템도, 접속이나 통신을 원하는 시스템에 대해 적절히 애플리케이션과 데이터 포맷에 응답하거나, 이런 애플리케이션에 구체적인 번역을 제공해야한다. 따라서, 모든 소프트웨어는 다소간에 주문받아 제조되었다.
오늘날의 신속하게 변화하는 환경에서는, 전세계의 수천의 개발자들의 협력은 다수의 주문 제조된 애플리케이션 특정 번역 기구(scheme)의 필요없이, 다른 애플리케이션들이 서로 통신하기 위한 필요를 만족시키는 시스템을 개발하는데 초점이 맞추어져 있다.
〈발명의 요약〉
따라서, 본 발명의 전반적인 목적은 기업 애플리케이션들을 통합하기 위한 시스템 및 방법을 제공하는 동시에 중앙 집중된 모니터링, 조작 및 배치를 포함하여 상기와 같은 기업 애플리케이션들의 포괄적인 관리를 제공하는 것이다.
본 발명의 더 구체적인 목적은, 메시지 트래킹과 이와 같은 시스템과 방법의 조작을 함께 향상시키는 에이전트-어댑터 구조와 메시지 스키마(schema)를 제공하는 것이다.
본 발명의 또다른 목적은 이와 같은 시스템 및 방법에서, 인증, 인가, 프라이버시, 비거부 및 감사 등의 양상을 포함하여 강화된 보안 특성을 제공하는 것이다.
본 발명의 또다른 목적은 재해 복구, 페일-세이프 롤오버(fail-safe rollover), 메시지 재생 및 이중 사이트 로깅(dual-site logging)용 수단을 포함하는 기업 애플리케이션들을 통합하는 시스템 및 방법을 제공하는 것이다.
본 발명의 전반적인 목적은 또한 선두의 ERP 애플리케이션, 커스텀/리거시(custom/legacy) 애플리케이션, 패키지된 애플리케이션 및 데이터베이스의 고속 및 단순 통합을 용이하게 하는 것이다. 더 구체적으로, 본 발명의 목적은 또한 애플리케이션들을 통합하는데 종래에 요구되었던 비싼 커스텀 코딩(custom coding)에 대한 필요를 경감하거나 또는 실질적으로 배제하는 것이다.
본 발명의 또다른 목적은 오늘날의 기업에 필요한 장기간의 신뢰성, 스케일러빌리티(scalability), 융통성 및 확장성을 용이하게 하는 분포 구조를 갖는 EAI 시스템을 제공하는 것이다.
본 발명의 또다른 목적은, 기업이 그 기존의 IT 투자를 차입금으로 투기할 수 있게 함으로써 투자에 대한 기업의 보상을 증가시키고, 시장 거래하고 해결책을 이행하고 이득을 더 신속하게 실현하기 위한 그 속도를 증가시키고, 그 동작 비용을 경감한 EAI 시스템을 제공하는 것이다.
본 발명의 또다른 목적은 기업의 고객과 빌링 정보에의 더 빠른 억세스를 제공하여 기업이 그 고객들에게 더 강하고 더 효과적인 관계를 창출하면서, 더 효율적이고 효과적으로 서비스할 수 있는 EAI 시스템을 제공하는 것이다.
본 발명의 또다른 목적은, 종래의 허브 및 스포크 시스템과 그 단일 포인트 실패의 위험의 우려를 실질적으로 배제한 다수 대 다수 지점의 통합을 갖는 EAI 시스템을 제공하는 것이다.
본 발명의 또다른 목적은 가상의 모든 애플리케이션과 플랫폼에 대해 통합의 중앙점을 제공함으로써 기업 IT 구조를 간소화하는 EAI 시스템을 제공하는 것이다.
본 발명의 또다른 목적은 효과적이고 비용 효율적인 정보 공유를 제공하는 EAI 시스템을 제공하는 것이다.
여기에 기재된 제조의 방법, 장치 및 물품들은 상기 기재된 문제들을 회피하는 동시에, 본 발명에 따른 상기 및 다른 목적, 이점 및 신규한 특징들을 달성할 것이다.
본 발명의 중요한 양상에 따르면, 방법은 제1 컴퓨터 애플리케이션과 제2 컴퓨터 애플리케이션 사이에 메세지를 전달하기 위한 컴퓨터로 구현된 수단을 포함한다. 그러한 방법은 일반적으로 다음의 단계를 포함한다 :(a)제1 컴퓨터 애플리케이션으로부터 제1 데이터 구조를 갖는 제1 메시지를 제공하는 단계; (b)제1 메시지를 발표하여 제1 발표된 메시지를 획득하는 단계; (c)제1 발표된 메시지의 제1 데이터 구조를 제2 메시지를 획득하기 위한 제2 데이터 구조로 전환하는 단계; (d)제2 메시지를 발표하여 제2 발표된 메시지를 획득하는 단계; 및 (e)제2 발표된 메시지를 제2 컴퓨터 애플리케이션으로 제공하는 단계.
본 발명의 다른 중요한 양상에 따르면, 장치는 다수의 컴퓨터 애플리케이션을 통합하기 위한 시스템을 포함한다. 그러한 장치는 일반적으로 시스템 내부의 메시지를 라우팅(routing)하기 위한 수단; 다수의 데이터 변환 컨피그레이션과 다수의 규칙을 메시지를 저장하기 위한 수단; 데이터 변환 컨피그레이션을 메시지에 적용하기 위한 수단; 규칙을 메시지에 적용하기 위한 수단; 시스템과 컴퓨터 애플리케이션 내부의 메시지를 라우팅하기 위한 수단간의 메시지를 라우팅하고, 개별 컴퓨터 애플리케이션에 대한 메시지를 라우팅 하기 위한 전용 수단을 갖기 위한 수단.
대안적으로, 본 발명의 장치는 다수의 컴퓨터 애플리케이션을 통합하기 위한 시스템을 포함한다. 그러한 시스템은 일반적으로 컴퓨터 애플리케이션 간에 메시지를 전달하는 기업 메시징 시스템; 다수의 데이터 변환 컨피그레이션과 다수의 규칙을 저장하는 상기 기업 메시징 시스템에 연결된 데이터베이스 저장 시스템; 상기 기업 메시징 시스템과 연결되고, 상기 데이터베이스 저장 시스템에 저장된 데이터 변환 컨피그레이션을 사용한 데이터 변환 엔진과 데이터베이스 저장 시스템에 저장된 규칙을 사용하는 규칙 평가 엔진을 포함하는 통합 서비스; 상기 기업 메시징 시스템과 개별 컴퓨터 애플리케이션 간에 메시지를 전달하는 컴퓨터 애플리케이션 각각에 연결되는 각 에이젼트-어댑터를 가진 기업 메시징 시스템이 연결되는 다수의 에이젼트-어댑터를 포함한다.
본 발명의 또 다른 양상에 따르면, 제조의 품목(article)은 다수의 컴퓨터 애플리케이션을 통합하기 위한 코드 세그먼트를 합체하는 컴퓨터-판독 가능 매체(computer-readable medium)를 포함한다. 이러한 점에서 그러한 "컴퓨터-판독 가능 매체"의 한정되지 않은 예는 자기 하드 디스크; 플로피 디스크; 광 디스크,(예, CD-ROM, CD-R, CD-RW, 기지의 DVD 표준을 따르는 디스크); 광자기 디스크; 자기 테이프; 메모리 칩; e-메일을 전송하고 수신하거나 인터넷, 인트라넷, 엑스트라넷(extranet), 가상 개인 네트워크(virtual private network,VPN), 근거리 통신망(LAN), 광역망(WAN)을 포함하는 네트워크에 접근하는데 사용되는 것과 같은 컴퓨터-판독 가능 전자적 데이터를 운반하는데 사용되는 캐리어 웨이브(carrier wave); 컴퓨터에 의해 접근할 수 있는 데이터를 저장하는데 사용되는 다른 저장 장치를 포함한다. "코드-세그먼트"의 한정되지 않은 예는 소스 코드 세그먼트와 목적 코드 세그먼트 뿐만 아니라, 어떤 언어, 명령, 목적, 소프트웨어, 또는 어떤 컴퓨터를 제어하기 위한 수단에서의 컴퓨터 프로그램을 포함한다. 그러한 코드 세그먼트는 일반적으로 :(a)컴퓨터 애플리케이션 간에 메시지를 전달하기 위한 제1 코드 세그먼트; (b) 메시지의 데이터 변환을 수행하기 위한 제2 코드 세그먼트; (c)메시지에 규칙을 적용하기 위한 제3 코드 세그먼트; 및 (d)다수의 제4 코드 세그먼트-상기 제4 코드 세그먼트각각은 개별 컴퓨터 애플리케이션과 제1 코드 세그먼트 간에 메시지를 전달함.
본 발명의 또 다른 중요한 양상에 따르면, 시스템과 방법은 컴퓨터에 의해 지시를 받는다. "컴퓨터"의 한정하지 않은 예는: 일반적인 목적의 컴퓨터; 메인프레임; PC; 웹 브라우저; e-메일 사용자; e-메일 서버; 네트워크 파일 또는 메시징 서버; 인터넷 장치; 무선 전화기; 호출기; PDA(personal digital assistant); 팩스 머신; 디지털 스틸 또는 비디오 카메라; 디지털 음성 또는 비디오 리코더; 디지털 복사기 또는 스캐너; 쌍방향 텔레비젼; 위의 컴퓨팅 수단과 쌍방향 텔레비젼의 하이브리드 결합 ;또는 프로세서, 메모리, 입력을 수신 용량(capability) 그리고 출력 용량을 포함하는 다른 장치를 포함한다.
본 발명의 다른 신규하고 동등하게 중요한 양상은 상세한 설명과 다음의 도면과 관련하여 고려할 때 더욱 명백해질 것이다.
본 발명은 일반적으로 컴퓨팅 기술 분야에서 "미들웨어(middleware)"로 알려져 있는 것에 관한 것으로서, 보다 상세하게는 네트워크화된 기업에 보통 설치되어 있는 미들웨어 타입의 애플리케이션을 통합하기 위한 확장가능한 분산 시스템 및 그 운용 방법에 관한 것이다.
도 1(a)는 본 발명에 따른 기업용 애플리케이션 통합(enterprise application intergration, EAI) 시스템이 유산(legacy) 시스템, 패키지 소프트웨어 애플리케이션 및 관련 데이터베이스 관리 시스템을 포함한 환경에 통합되었을 때의 기업 응용 통합 시스템을 도시한 것이다.
도 1(b)는 도 1(a)에 도시된 시스템이 기업 자원 계획(ERP) 패키지 소프트웨어 애플리케이션과 커스텀 유산 시스템을 통합하는데 사용되는 제1 시나리오를 도시한 것이다.
도 1(c)는 도 1(a)에 도시된 시스템이 둘 이상의 다른 ERP 패키지 소프트웨어 애플리케이션을 통합하는데 사용되는 제2 시나리오를 도시한 것이다.
도 1(d)는 도 1(a)에 도시된 시스템이 하나 이상의 프론트-오피스 패키지 소프트웨어와 하나 이상의 백-오피스 패키지 소프트웨어를 통합하는데 사용되는 제3 시나리오를 도시한 것이다.
도 1(e)는 도 1(a)에 도시된 시스템이 둘 이상의 다른 관계 데이터베이스 관리 시스템(RDBMS) 또는 다차원 데이터베이스 관리 시스템을 사용하는 데이터 웨어하우스 소프트웨어 애플리케이션을 통합하는데 사용되는 제4 시나리오를 도시한 것이다.
도 2는 도 1(a)내지 도 1(e)에 도시된 EAI 시스템의 블럭 다이어그램이다.
도 3은 도 2에 도시된 시스템에서 사용되는 어댑터 개발 키드를 도시한 것이다.
도 4(a)는 본 발명의 제1 실시예에 따른 유용한 기본 에이젼트-어댑터 아키텍춰를 도시한 것이다.
도 4(b)는 본 발명의 제2 실시예에 따른 유용한 확장된 에이젼트-어댑터 아키텍쿼를 도시한 것이다.
도 4(c)는 본 발명에 따른 에이젼트-어댑터의 현재의 바람직한 실시를 나타낸 블럭 다이어그램이다.
도 5(a)내지 도 5(c)는 본 발명에 따른 시스템에서 사용되는 디자인과 통합 오브젝트를 도시한 것이다.
도 6은 본 발명에 따른 시스템에서 사용되는 메시지 스키마를 도시한 것이다.
도 7은 본 발명에 따른 다른 오브젝트를 도시한 것이다.
도 8은 본 발명에 따라 사용되는 전형적인 변환 프로세스를 도시한 것이다.
도 9는 도 8에 도시된 변환 프로세스를 좀 더 상세하게 도시한 것이다.
도 10(a)와 도 10(b)는 본 발명에 따른 메시지 허브의 이점을 도시한 것이다.
도 11(a)내지 도 11(c)는 본 발명에 따른 노드와 서비스가 관리되는 다양한 오퍼레이팅 환경을 도시한 것이다.
도 12는 본 발명에 따른 시스템 서비스를 나타낸 블럭 다이어그램이다.
도 13은 생 데이터를 변환시키지 않은 본 발명에 따른 메시지를 생성하는데 필요한 단계를 도시한 플로우차트이다.
도 14는 생 데이터를 변환함으로써 본 발명에 따른 메시지를 생성하는데 필요한 단계를 도시한 플로우차트이다.
도 15(a)는 본 발명의 제1 실시예에 따른 애플리케이션으로부터 메시지 인스턴스로 메시지를 생성하는 한 방법을 도시한 것이다.
도 15(b)는 본 발명의 제2 실시예에 따른 애플리케이션으로부터 메시지 인스턴스로 메시지를 생성하는 한 방법을 도시한 것이다.
도 15(c)는 본 발명의 제3 실시예에 따른 애플리케이션으로부터 메시지 인스턴스로 메시지를 생성하는 한 방법을 도시한 것이다.
도 15(d)는 본 발명의 제4 실시예예 따른 애플리케이션으로부터 메시지 인스턴스로 메시지를 생성하는 한 방법을 도시한 것이다.
도 16은 본 발명에 따른 제1 클래스 다이어그램이다.
도 17은 본 발명에 따른 제2 클래스 다이어그램이다.
기업 컴퓨팅 실행시간 환경
동일한 참조 문자나 숫자가 여러 도면 각각에 대해 동일하거나 대응하는 부분을 지시하는 도면을 참조하면, 도 1은 기업 컴퓨팅 실행시간 환경(10)에 대한 개략적인 도면이다. 통상의 실행시간 환경(10)은 기업 자원 계획(ERP)에 대한 "백-오피스(back-office)" 애플리케이션(20)과 고객 관계 관리(customer relationship management, CRM)에 대한 "프론트-오피스(front-office)" 애플리케이션(30), 하나 이상의 주문 유산 시스템(cuntomized legacy system)(40), 하나 이상의 다차원/관계 데이터베이스 관리 시스템(multi-dimensional/relational database management system, RDBMS)(50)을 포함하는 다수의 패키지 소프트웨어 애플리케이션을 사용한다.
과거 몇 십년동안, 비즈니스 기업은 많은 큰, 단일-목적 소프트웨어 애플리케이션을 디자인하고 구매해왔다. 이러한 "유산" 애플리케이션은 계속해서 사용되고 있고, 대부분은 종종 특정한 기능(예, 재고, 재정, 회계, 판매 촉진 자동화, 인사 관리)을 수행하기 위해 디자인되었다. 좀 더 최근에는, 실체적인 투자가 SAP, PeopleSoft, Oracle 및 Bann과 같은 소프트웨어 개발자로부터 패키지 소프트웨어를 획득하기 위해 그것들과 같은 기업에 의해 또한 이루어지고 있다. 이러한 패키지 소프트웨어 애플리케이션 각각은 자신만의 고유한 강점을 즐겼다. 따라서, 전형적인 비즈니스 기업은 같은 실행시간 환경에서 둘 이상의 다른 패키지 소프트웨어를 사용했다. 그러한 패키지 소프트웨어 애플리케이션은 초기에는 그것들 사이에 정보를 공유하도록 디자인되지 않았다. 결과적으로, 기업은 비싼 커스텀(custom) 코드를 갖는 다른 패키지 소프트웨어 애플리케이션을 통합시키려고 해왔다. 그러한 통합 노력은 완성하는데 종종 몇년씩은 아니라 하더라도 몇달이 결렸다.
도 1(a)에 도시된 시스템과 같은, 기업용 애플리케이션 통합(EAI) 시스템은 그러므로 필수적이다. 그러나 종래의 기술에 따른 EAI 시스템과는 다르게, 시스템(100)은 해결 지향 미들웨어(solution-oriented middleware)를 포함하여 그것의 사용자가 하나의 공통 인프라스트럭쳐를 통해 다른 애플리케이션 내부에 존재하는 정보를 변경하는 것과 완전히 통합하는 것을 용이하게 한다. 이는 최대의 생산성을 달성하여 사용자가 종업원, 고객, 공급자 사이에 한결같고, 투명하고, 빠르게 정보를 이동시킬 수 있게 되었다.
이러한 방식으로, 시스템(100)은 신뢰할 만한 저장-전송하는 메시징 시스템, 가능한 메시지 중개 시설; 및 다른 기업 애플리케이션을 통합하기 위한 강력한 에이젼트-어댑터 아키텍춰를 제공한다. 그것은 쉬운 관리와 경영을 위해 배치하는데 적용되고, 디자인된다. 그것은 큰 단체의 완전하고, 이질적인 컴퓨팅 요구를 충족시키는 것을 목적으로 한다. 그것은 다양한 애플리케이션을 종합적으로 조정하여 연결해서 정보를 호출하고 공유한다. 그것은 미들웨어에 애플리케이션을 억지로 적응시키려고 하기 보다 애플리케이션에 적응하는 미들웨어이다.
시스템(100)은 사용자가 최소화된 커스텀 코딩을 가진 기업의 도처에 있는 ERP 애플리케이션(20), 패키지 애플리케이션(30), 커스텀과 유산 애플리케이션(40), 데이터베이스(50)와의 연결을 가능하게 하므로써 대부분의 EAI문제를 해결한다. 완전히 통합되었을 때, 기업은 빨리 세계적인 사업과 분배를 동시성을 가지게 할 수 있고, 계속해서 변하는 시장의 수요에 응할 수 있다. 고객과 빌링 정보(billing information)를 더 빠르게 입수하여 사용자의 단체는 고객에게 좀 더 효과적이고, 효율적으로 서비스할 수 있으며, 더 강력하고 효과적인 관계를 창조할 수 있다. 시스템(100)은 비즈니스 분석자에게 목적이 맞춰진 통합 흐름 디자인 환경을 가진 비즈니스-중심 기업 통합 솔루션이다. 분석자는 비즈니스 기간안의 문제를 정의하고, 생산품은 기술적 이슈를 다룬다.
예를 들어, 도 1(b)에서 보여지는 바와 같이, 커스텀 유산 시스템을 갖는 기업 자원 계획(ERP) 통합의 공통 시나리오(scenario)는 단체가 표준 ERP 구현내로 복잡한 프로세스를 적당히 요약하는 것-하기 쉬운일은 아님-을 요구한다. 많은 기업은 재고와 오더 경영과 같은 표준 비즈니스 프로세스에 대한 패키지 애플리케이션을 구현하는 것을 선택한다. 그러나 패키지 애플리케이션은 수직 조직에서는 거의 사용되지 않는다. 이러한 목적을 위해, 시스템(100)은 이상적이다. 그것은 유산 시스템(44,48)에 연결하기 위한 랩퍼-제너레이션(wrapper-generation) 기술 뿐 아니라 ERP 시스템(22,24,26,28)에 대한 목적 인터페이스를 제공한다.
세계적인 공급 체인의 확장은 또한 미들웨어가 두 개 이상의 다른 ERP 시스템(22,24,26,28)에 다리를 놓는 것을 요구한다. 도 1(c)에 도시한 바와 같이, 하찮은 일이 비즈니스 대 비스니스(business to business) 협동에 더 중요할 수 있다는 것을 쉽게 통찰할 수 있을 것이다. 그러므로 시스템(100)은 기본적인 기술의 세부 사항을 드러내지 않은 상태에서 한 시스템(예, SAP 시스템 (22))에서 비즈니스 이벤트가 다른 시스템(예, Bann 시스템 (28))에 대응하는 이벤트를 일으키는 인터-ERP 트랜잭션(inter-ERP transaction)을 가능하게 하는데 중요한 역할을 한다.
기업의 "프론트-오피스"와 "백-오피스"의 통합은 중요한 기능으로, 백-엔드(back-end) 생산 애플리케이션과 협동하기 위한 고객과 상호작용하여 프론트-오피스 애플레케이션이 가능하게 된다. 예를 들어, 도 1(d)를 참조하면, 고객-지원 시스템이 ERP 재고 모듈과 협동하는 것은 결정적으로 중요하다. 그러므로 시스템(100)은 최고로 생산된(best-of-breed) 프론트 -오피스와 백-오피스를 한결같고 투명하게 통합하는 것을 용이하게 한다.
도 1(e)에서 보여지는 바와 같이 데이터 웨어하우스(warehouse) 시나리오에서, 다른 시스템으로부터의 데이터는 중앙 데이터 웨어하우스나 저장소로 이주되어야 한다. 여러 ERP시스템(도 1(e)에는 도시되지 않았다)으로부터 다수의 다른 데에터베이스(53,56,59)를 포함하는 중앙의 관계 또는 다차원 데이터베이스로 실시간정보를 이동시키는 것은 이 문제의 예이다. 그러나, 데이터 웨어하우스 개발자는 좀 더 상세하게 후술되는 바와 같이, 실시간 데이터 집합 또는 다른 동작으로 시스템(100)의 데이터 번역 서비스를 이용할 수 있다. 데이터는 그것에 의하여 이해가능하고 의미있는 상태로 번역된다.
정의
이하에서 사용되는 바와 같이, 다음 용어들은 당 기술분야의 통상의 기술을 가진 자들에 의해 해당 용어의 일반적이고 익숙한 의미에 따라서 파악되어야 한다. 이하에 나타나 있는 정의가 당 기술분야의 통상의 기술을 가진 자들에 알려져 있는 다른 일반적인 의미와 상이한 정도까지, 그런 용어들은 본 출원인이 그 청구 용어를 그렇게 재정의하고자 하였음을 당 기술분야에 상당히 숙련된 자에게 알려주도록 이하에 명확히 제시되어 있음을 이해해야 할 것이다.
"액세서"(accessor)는 시스템(100)이 데이터에 액세스하기 위해 이용하는 메시지 정의에 특정된 기능이다. 액세서는 애플리케이션 데이터 필드의 시작과 끝 및 시스템 메시지 요소들을 식별해주고, 마커를 제거하거나 삽입한다.
"어댑터 임플리멘테이션"(adapter implementations)은 데이터를 추출하고 시스템 메시지를 생성하거나; 시스템 메시지를 수신하고 데이터를 업데이트하거나; 또는 요구에 응답하여 데이터를 추출할 수 있는 특정 애플리케이션에 지정된 코드이다. 사용자가 인테그레이션 플로에 사용할 어댑터를 작성할 때, 사용자는 그것을 어댑터 임플리멘테이션 주위에서 구축한다. 시스템 어댑터 임플리멘테이션은 기본적인 예외 핸들링을 제공하고 임의의 메시지 정의를 핸들링할 수 있다. 사용자는 이하에 보다 상세히 정의되고 설명된 ADK를 이용하여 커스텀 어댑터 임플리멘테이션을 작성한다.
"어댑터"(adapters)는 기업용 애플리케이션과 대화식으로 작용하여 데이터를 추출하거나 데이터를 삽입, 업데이트, 또는 삭제하는 인테그레이션 플로 오브젝트이다.
"관리 콘솔"(administration console)은 시스템 관리자가 시스템(100)의 노드 및 서비스를 구성하고 관리하는데 이용되는 그래픽 유저 인터페이스(GUI)이다.
"에이전트 서비스"(agent services)는 어댑터에 시스템 서비스를 제공한다. 에이전트 서비스는 어댑터를 실행시키는 각 호스트 상에서 요구된다.
"클래스패스"(classpath)는 자바 가상 머신(Java virtual machine)에게 사용자 정의의 클래스 라이브러리를 포함하는, 클래스 라이브러리를 어디에서 찾을지를 알려주는 환경 변수이다.
"클라이언트"(clients)는 계산 능력 및 대용량 메모리와 같이, 컴퓨터 서버 자원에 원격으로 액세스하는 프로세서이다. 전형적인 시스템 클라이언트는 인테그레이션 워크벤치(120) 및 관리 콘솔(160)이다(도 2 참조).
"커넥션"(connection)은 어댑터에 대한 스타트업 또는 접속 파라미터를 특정하는 오브젝트이다. 예를 들면, RDBMS 커넥션은 JDBC 드라이버, 데이터베이스의 URL, 사용자명, 및 패스워드를 특정한다.
데이터를 "변환"(convert)하는 것은 메시지 정의 내에 특정된 컨버터가 애플리케이션의 본래 데이터 타입을 시스템(100)이 지원하는 자바 데이터 타입으로 변환하거나, 또는 반대로 변환하는 프로세스이다.
"컨버터"(converter)는 시스템(100)이 데이터를 변환하기 위해 이용하는 메시지 정의 내에 특정된 기능이다. 그런 방식으로, 컨버터는 본래 데이터 타입을 시스템(100)이 지원하는 자바 데이터 타입으로 변환하고, 반대로 변환한다.
"커스텀 어댑터 임플리멘테이션"(custom adapter implementations)은 데이터를 추출하고 시스템 메시지를 생성하거나; 시스템 메시지를 수신하고 데이터를 업데이트하거나; 또는 요구에 응답하여 데이터를 추출할 수 있는 특정 애플리케이션에 지정된 코드이다. ADK를 이용하여 작성된, 커스텀 어댑터 임플리멘테이션은 시스템(100)이 현재 지원하지 않는 애플리케이션에 접속할 수 있다.
"정의 오브젝트"(definition object)는 시스템이 실행하기로 되어 있는 프로세스에 명령을 제공하는 인테그레이션 플로 오브젝트이다.
"디리미터"(delimiters)는 데이터 내의 데이터 필드를 기업용 애플리케이션과 분리하는 토큰 또는 마커이다.
"영구 신청"(durable subscription)은 허브 타킷 오브젝트가 그들에게 지정된 모든 메시지를 확실히 수신할 수 있게 해주는 시스템 메시지 허브의 특성이다. 만일 타킷 오브젝트가 인액티브 상태가 되면, 시스템은 타킷 메시지가 수신한 이들 메시지를 기억한다. 타깃이 다음에 액티브 상태가 되면, 시스템은 타킷이 아직 수신하지 않은 메시지를 전달한다.
"기업용 애플리케이션"(enterprise applications)은 그로부터 어댑터가 데이터를 추출하거나 또는 거기에 어댑터가 데이터를 전달하는 애플리케이션이다(예를 들면, SAP R/3 또는 MQSeries).
본 발명에 따른 "기업 메시징 서비스"(EMS : Enterprise Messaging Service)는 자바 메시징 서비스(JMS)를 이용하여 실행된다. 그것은 시스템(100)이 다수의 메시징 모드를 이용할 수 있게 해주고, 메시지 허브를 지원하고 메시지 지속성을 제공한다.
"기업 자원 계획"(ERP : Enterprise Resource Planning) 애플리케이션은 통상의 비즈니스 문제에 대한 턴키 솔루션(예를 들면, 창고 관리, 인적 자원 관리, 및 재료 관리)을 제공한다. ERP 상품의 예를 들면, SAP R/3, PeopleSoft, 및 Baan이 있다.
"전체X 브로커"(ETB : EntireX Broker)는 본 발명에 따른 크로스플랫폼 메시지 지향 미들웨어로서, 메인프레임인 윈도 NT, 및 UNIX 애플리케이션과 컴포넌트인 인터넷 및 인트라넷 클라이언트, 및 액티브 X 및 자바가 허용되는 워크스테이션을 링크한다.
"필터 정의"(filter definitions)는 인테그레이션 플로로부터 메시지를 가려내기 위한 기준을 특정하는 정의 오브젝트이다.
"기능 호스트"(function hosts)는 윈도 NT 서버 또는 워크스테이션, 또는 OS/390 메인프레임과 같은, 계산 플랫폼이다.
"허브"(hubs)는 소스 오브젝트로부터 메시지를 수신하고 시스템(100)이 그 메시지를 특정 타킷 오브젝트에 전달할 때까지 메시지를 보유하는 인테그레이션 플로 오브젝트이다. 허브는 어댑터 및 트랜스포머가 메시지를 비동기적으로 교환하는 것을 허용한다. 허브는 또한 메시지 플로를 집중시키는 데 유용하며; 동종의 메시지를 생성하는 다수의 오브젝트들은 모두 그들 메시지를 하나의 메시지 허브에 송신할 수 있어서, 오브젝트들 사이의 링크가 간단해진다.
"중간 문서 추출기"(IDoc Extractor)는 SAP R/3 트랜잭션 WE63에 의해 생성된 플랫 파일들을 판독하여 임플리멘테이션 구성 및 메시지 정의를 작성하고 시스템의 저장 서비스에 그들을 저장한다.
"임플리멘테이션 세팅"(Implementation settings)은 어댑터에 대한 런타임 파라미터이다(예를 들면, 폴링 간격).
"인테그레이션 플로"(integration flow)는 하나 또는 그 이상의 기업용 애플리케이션으로부터 다른 기업용 애플리케이션으로 데이터를 이동시키는 일련의 링크된 시스템 오브젝트들이다.
"인테그레이션 오브젝트"(integration objects)는 메시지를 송신하거나, 메시지를 수신하거나, 또는 둘 다를 실행하는 인테그레이션 플로 오브젝트이다. 예를 들면, 어댑터, 허브, 및 트랜스포머를 참조할 것.
"인테그레이션 워크벤치"(integration workbench)는 사용자가 인테그레이션 플로를 설계하기 위해 이용하는 그래픽 유저 인터페이스(GUI)이다.
"중간 문서"(IDocs : Intermediate documents)는 R/3이 다른 R/3 시스템 및 다른 애플리케이션과 데이터를 교환하는 데 이용하는 SAP R/3 데이터 포맷이다.
"아이템 메시지 요소"(item message element)는 데이터를 포함하는 메시지 요소이다. 아이템은 메시지 정의의 계층 내의 최저 레벨 메시지 요소이다. 이들은 다른 메시지 요소를 포함할 수 없다.
"자바 데이터베이스 접속성"(JDBC : Java Database Connectivity)은 SQL을 이용한 데이터베이스 액세스에 대한 자바 API 규격이다.
"자바 개발 키트"(JDK : Java Development Kit)는 자바 프로그래밍 언어로 애플리케이션을 작성하기 위한 소프트웨어 개발 환경이다.
"자바 메시지 서비스"(JMS : Java Message Service)는 메시징을 위해 선 마이크로시스템이 특정한 자바 API이다.
"자바 네이밍 및 디렉토리 인터페이스"(JNDI : Java Naming and Directory Interface)는 다수의 네이밍 및 디렉토리 서비스로의 인터페이싱을 돕는 API 세트이다.
"자바 런타임 환경"(JRE : Java Runtime Environment)은 자바 가상 머신, 자바 코어 클래스, 및 지원 파일들로 이루어지는 런타임 환경을 재분배하는 데 이용되는 자바 개발 키트의 서브세트이다.
"자바 가상 머신"(JVM : Java virtual machine)은 바이트코드 해석의 책임이 있는 자바 런타임 환경의 부분이다.
"링크 마커"(link markers)는 데이터 내의 데이터 필드를 기업용 애플리케이션과 분리하는 토큰 또는 디리미터이다.
"메시지 정의 카테고리"(message definition category)는 메시지 정의의 논리적 분류이다.
"메시지 정의"(message definitions)는 시스템(100)이 기업용 애플리케이션으로부터 추출하거나 또는 거기에 전달하기로 되어 있는 데이터를 식별해주는 정의 오브젝트이다. 메시지 정의는 또한 시스템(100)이 기업용 애플리케이션 데이터로부터 시스템 메시지를 구축하거나 또는 시스템 메시지로부터 기업용 애플리케이션을 작성하는 방법을 정의한다.
"메시지 요소 (message element)"는 메시지 정의의 메시지 스키마 (schema)를 구성하는 데이터 대상물 (data object)이다. 메시지 요소들은 계층적 구조로 배열되고 섹션 (sections), 테이블 (tables), 또는 아이템 (items)일 수 있다.
"메시지-지향 미들웨어 (Message-Oriented Middleware : MOM)"는 동일한 또는 상이한 플랫폼에서 애플리케이션들로 하여금 통신이 가능하도록 하는 메시지를 사용하는 소프트웨어이다. 통신 프로토콜은 상기 애플리케이션에 숨겨져 있다. MQSeries, EntireX Broker, 및 JMS는 MOM의 예이다.
"메시지 퍼시스턴스 (message persistence)"는 회복가능한 미디어로 메시지를 저장하는 것과 관련있다. 상기 시스템은 하나의 통합 대상물 (integration object)로부터 다른 하나로 넘겨주는 각각의 메시지를 상기 사용자가 규정한 위치의 안정된 저장장치에 기록한다. 메시지가 수송중에 시스템 장애가 발생하면, 시스템 (100)이 회복될 때, 상기 메시지를 저장장치로부터 검색하여 타겟으로 상기 메시지를 전달한다.
"메시지 스키마"는 메시지를 구성하는 방법을 정의하는 메시지 정의의 일부분이다. 메시지 스키마들은 계층적 구조로 배열된 섹션, 테이블, 및 아이템 메시지 요소들을 포함할 수 있다.
"모니터 서비스 (Monitor services)"는 시스템 로그 (logs) 및 통계 정보를 포함하는 시스템 실행시간 데이터 (runtime data)를 저장한다.
"노드 (node)"는 하나 또는 그 이상의 시스템 및 애플리케이션 서비스들을 지원하는 물리적 프로세스 (또는 자바 버츄얼 머신 (Java virtual machine)이다.
"노드 호스트 (node hosts)"는 상기 사용자로 하여금 머신에서 노드를 구성 및 실행하도록 하는 소프트웨어이다. 상기 사용자는 상기 노드 관리기 (node manager)이외에, 모든 머신에 노드를 호스트할 노드 호스트를 설치해야 한다.
"노드 관리기"는 노드들이 관리되는 인터페이스이다. 상기 인터페이스는 상기 사용자가 서비스를 구성, 시작, 중지, 또는 정지할 수 있게 한다. 또한, 노드 관리기들은 노드를 시작 및 정지시킨다. 상기 노드 관리기는 상기 노드에 분배된 모든 상기 서비스들의 상태를 유지한다. 추가로, 상기 노드 관리기는 노드 또는 서비스의 상태 정보 (예를 들면, 현재 상태 또는 활동 레벨)를 유지한다.
"포인트-투-포인트 메시징 (Point-to-point messaging)"은 허브에 관한 메시징 스타일로서, 상기 허브에 도달하는 각각의 메시지를 상기 시스템이 단일 허브 타겟 (즉, 제1 이용가능한 타겟)에만 전달하는 것이다.
"1차 입력 메시지 (primary input message)"는 변환기 (transformer) 정의내에 규정된 상기 시스템 변환 프로세스에 대한 주 입력 데이터이다. 상기 시스템은 입력 데이터를 받고, 변형하며, 타겟 애플리게이션에 필요한 출력 데이터를 생성한다.
"발표/가입 메시징 (Publish/subscribe messaging)"은 허브에 관한 메시징 스타일로서, 상기 시스템이 상기 허브에 도달하는 각각의 메시지들을 모든 허브 타겟으로 전달하는 것이다.
"응답기 (replier)"는 상기 데이터 변형 프로세스동안에 변형기가 요청시, 데이터를 제공하는 응답 어댑터와 같은 시스템 대상물이다.
"응답 어댑터 (Reply adapters)"는 다른 통합 대상물로부터의 데이터에 관한 요청에 대해 애플리케이션으로부터 상기 데이터를 추출함으로써 응답하는 통합 대상물이다. 요청기 (requesters)는 키 (key) 메시지 요소내의 데이터를 포함하는 시스템 메시지들을 전송하고, 상기 응답 어댑터는 데이터를 관련된 메시지 요소내로 삽입하며, 상기 시스템 메시지들을 되돌려 전송한다.
"리포지터리 서비스 (repository service)"는 자바 고유 디렉토리 인터페이스를 통하여 인터페이스되고, 모든 구성된 서비스 및 통합 플로우 대상물들에 대한 구성을 저장한다.
"라우팅 서비스 (Routing services)"는 상기 시스템으로 하여금 메시지의 내용 - 상기 사용자가 정의한 기준에 따른 필터링 메시지 내용을 포함함 - 에 기초하여 상기 시스템을 통해 메시지를 지시하게 한다. 상기 라우팅 서비스는 필터를 지원한다.
"시스템 메시지 (system message)"는 플랫폼-중성 형식으로서, 상기 시스템이 에플리케이션에서 애플리케이션으로 데이터를 이동하기 위해 사용하는 메시지이다.
"섹션 메시지 요소 (Section message elements)"는 실질적인 데이터를 포함하지 않는 메시지 요소들의 반복되지 않는 그룹이다. 그것은 데이터 (즉, 그것은 아이템을 포함함)를 포함하는 다른 메시지 요소들을 포함한다. 섹션은 메시지 요소 타입들의 임의의 조합도 포함할 수 있다.
"서비스 (service)"는 생산 기능성 (product functionality)을 제공하는 프로세스이다. 상기 시스템은 시스템, 메시징, 통합, 및 에이전트 서비스들로 구성된다.
"소스 어댑터 (Source adapters)"는 기업 애플리케이션으로부터 데이터를 추출하고, 상기 데이터로부터 시스템 메시지들을 구성하며, 상기 메시지들을 다른 시스템 통합 대상물에게 전송하는 통합 대상물이다.
"소스 대상물 (source object)"은 다른 대상물들, 예를 들면, 소스 어댑터, 변환기, 및 허브들에게 메시지들을 제공하는 통합 플로우 대상물이다.
"지원 입력 메시지 (Supporting input messages)"는 변형기 정의에서 규정된 것과 같이, 상기 시스템 변형 프로세스로의 선택적 입력 데이터이다. 변형 프로세스들은 제1 입력 메시지 데이터를 추가하기 위해 지원 입력 메시지 데이터를 사용한다. 상기 시스템은 입력 데이터를 받고, 변형하며, 타겟 애플리케이션이 필요로 하는 출력을 생성한다.
"테이블 메시지 요소 (table message element)"는 임의의 회수만큼 반복할 수 있는 소위, 로우 (row)인 섹션 메시지 요소들의 그룹이다. 테이블 요소들은 실질적인 데이터를 포함하지 않는다. 대신에, 데이터 (즉, 그것은 아이템을 포함함)를 포함하는 다른 메시지 요소들을 포함한다. 테이블들은 메시지 요소 타입들의 임의의 조합도 포함할 수 있다.
"타겟 어댑터 (Target adapters)"는 다른 통합 대상물들로부터 시스템 메시지를 수신하고, 상기 시스템 메시지로부터 애플리케이션 데이터를 생성하며, 타겟 애플리케이션으로 상기 데이터를 전파하는 통합 대상물이다.
"타겟 통합 대상물"은 다른 대상물, 예를 들면, 타겟 어댑터, 변형기, 및 허브들로부터 메시지들을 수신하는 통합 플로우 대상물이다.
"트랜젝션 프로세싱 모니터 (Transaction Processing Monitor : TPM)"는 많은 사용자들을 위해 저장 장치 및 애플리케이션과 같은 컴퓨팅 자원들의 사용을 최적화하도록 디자인된 소프트웨어 시스템이다.
"데이터를 변형 (transform data)"하는 것은 변형기가 하나 또는 그 이상의 기업 애플리케이션으로부터 취득한 데이터를 다른 기업 애플리케이션이 필요로 하는 데이터로 수정하는 프로세스이다.
"변형 서비스 (Transformation service)"는 상기 시스템으로 하여금 분리된 메시지 (splitting message), 조합된 메시지 및 조작된 메시지 (manipulating message) 데이터를 포함하는 메시지들을 변형할 수 있게 한다. 상기 변형 장치는 변형기를 지원한다.
"변형 단계 (transformation step)"는 상기 변형 프로세스를 구성하는 명령이다. 각각의 단계는 입력 메시지 데이터를 읽고, 변형하며, 입력 메시지 데이터를 출력 메시지 정의로 매핑하거나 또는 변형된 데이터를 출력 메시지로 기록한다.
"변형기 정의 (transformer definitions)"는 상기 시스템이 하나 또는 그 이상의 기업 애플리케이션으로부터 추출된 시스템 메시지들을 다른 기업 애플리케이션이 필요로 하는 시스템 메시지로 변형하는 방법을 정의하는 정의 대상물 (definition object)이다.
"변형기 (transformer)"는 변형기 정의를 구현하는 통합 대상물이다. 변형기들은 소스 통합 대상물들로부터 입력 메시지들을 수집하고, 상기 내용 및 상기 메시지 데이터의 형식을 변형하며, 출력 메시지들을 생산하여 타겟 통합 대상물들로 전송한다.
"사용자 인터페이스 서비스 (User interface services : UIS)"는 상기 클라이언트 구성요소 (즉, 상기 통합 워크벤치 (workbench) (120) 및 상기 운영 콘솔 (administration console) (160))들을 실행하는데 필요한 상기 사용자 인터페이스 설비를 제공한다.
지금, 도 2를 참조로 하면, 시스템 (100)은 일반적으로 복수의 디자인 구성요소 (110) 및 복수의 실행시간 관리 구성요소 (150)를 포함한다. 좀 더 구체적으로, 상기 디자인 구성요소 (110)는 통합 워크벤치 (120), 어댑터 개발 키트 (adapter development kit : ADK) (130) 및 레포지터리 서비스 (140)를 포함한다. 상기 실행시간 관리 구성요소 (150)는 운영 콘솔 (160), 기업 메시징 엔진 (180)을 포함하는 통합 서버 (170), 노드 서비스 구성요소 (190), 복수의 지능형 에이전트 어댑더 (200)을 포함한다.
상기 통합 워크벤치 (120)은 일반적으로 통합 프로젝트 개발을 위해 그래프 모델링 및 구성 도구를 포함한다. 또한 이벤트, 상기 이벤트와 관련된 메시지, 통합 플로우, 및 상기 통합 플로우와 관련된 비지니스 규칙을 정의할 뿐만 아니라, 상기 정의된 이벤트를 발표 및 가입하는 에이전트를 식별하는데 사용된다. 덧붙여, 상기 통합 워크벤치 (120)는 일관성을 위해 통합 플로우를 검사 및 테스트하는 진단을 제공한다.
ADK(130)는 개별화된 지능형 에이전트-어댑터(200)를 구성하고 생성하는데 이용된다. 도 3에 더 상세하게 도시된 바와 같이, ADK(130)는 일반적으로 클래스 라이브러리(132), 위저드(134), 및 템플릿(136)를 포함하는 오브젝트 프레임워크로 구성된다. ADK(130)는 종래의 개발 툴로부터 액세스될 수 있는 오브젝트를 생성한다. 시스템(100)은 광범위한 어플리케이션과 리소스에 대한 복수의 표준 지능형 에이전트-어댑터(200)를 포함하고 있는데 반해, 그러한 표준 지능형 에이전트-어댑터(200)가 전혀 없는 특정 어플리케이션도 존재할 수 있다. 그 경우에, ADK(130)는 목표 어플리케이션 환경에 의해 제공되는 공개된 인터페이스에 더 익숙한 개발자들이 개별화되고 지능형인 에이전트-어댑터(200)를 구축하는 것을 또한 가능하게 한다.
저장 서비스(140, repository service)는 통상 시스템(100)에 대한 모든 스페시피케이션, 메타-데이터, 및 메세지 브로커 서비스 룰을 포함하는 관련 데이터 베이스와, 상기 관련 데이터 베이스로의 인터페이스를 포함한다.
관리 콘솔(160, administration console)은 시스템(100)의 실행시간 호나경을 정의하고 관리하는데 이용되고, 통상 그래픽 콘솔을 포함한다. 이것은 시스템 구조, 유지, 모니터링, 및 진단의 제어 포인트로서 기능한다. 관리 콘솔(160)을 통해, 구성 요소 개시 및 종료와 같은 포괄 서비스(comprehensive service) 및 내장 소프트웨어 분배를 포함하는 시스템(100)의 개개 구성 요소 각각이 관리된다.
통합 서버(170, integration server)는 통합 플로우를 트리거링하고 실행하여 이벤트를 프로세싱함으로써 지능형 메시징을 구현한다. 이것은 이벤트 데이터를 평가하고, 변형하며, 루팅하는 스태틱 및 다이나믹 컨텍스트 의존 룰을 실행한다. 상기 지적한 바와 같이, 통합 서버(170)는 모든 이벤트 데이터를 관리하고, 분산 메시징 서브 시스템으로 이루어지는 기업 메시징 엔진(180)을 포함한다. 한편으로 이것은 시스템(100)의 핵심 구성 요소이다. 다른 한편으로는, 이것은 시스템(100) 이용자에게는 대부분 보이지 않으며(transparent), 통상 화면뒤에서 동작한다. 이것은 완전한 내구성(full persistence), 온스-앤-온리-온스(once-and-only once)메세지 전달, 및 비한계적 대용량 메세지 요구에 대한 인-메모리(in-memory) 모드를 지원한다.
노드 서비스 구성 요소(190)는 개시/재개시 회복, 예외 처리, 및 시스템(100)의 다이나믹 구조를 관리한다. 이것은 모든 참가 클라이언트및 서버에 대해 자동화된 시스템 인스털레이션과 원격 관리에 대한 기능을 제공한다. 더구나, 멀리 이격된 구성 요소들을 인스톨하고 업데이팅을 용이하게 할 수 있다.
상기 지적한 바와 같이, 복수의 지능형 에이전트-어댑터(200)는 시스템(100)에 분사된 표준 지능형 에이전트-어댑터(200)들 뿐만 아니라 ADK(130)에 의해 개발되는 개별 지능형 에이전트-어댑터(200)를 포함한다. 그 유형에 관계없이, 각 지능형 에이전트-어댑터(200)는 통상적으로 외부 어플리케이션 리소스(300) 중 특정한 하나를 시스템(100)에 접속시키는 실행시간 인터페이스 모듈을 포함한다.
도 4a 및 4b를 참조하면, 본 발명의 특히 중요한 양상에 따른 지능형 에이전트 어댑터(200)가 독립적인 에이전트의 기능들을 어댑터 기술에 통합한다는 것은 자명하다. 에이전트 구성 요소(210)는 하나 이상의 어댑터 구성 요소(220(도 4a) 또는 222, 224(도 4b))를 호스팅하는 독립적인 소프트웨어 프로세스로서 작동한다. 이것은 저장 및 포워드 캐싱, 필터링, 리소스 풀링, 및 스케줄링과 같은 고도의 기능을 인캡슐레이트한다.
이러한 에이전트-어댑터 아키텍처의 주요한 장점은 상태를 유지하고 어플리케이션 리소스(300)들과 트랜잭션을 협상하기 위해 복잡한 비지니스 논리를 호스팅하는 능력이다. 이러한 능력을 "대화 모드 프로세싱"이라 간주할 수 있는데, 특히 트랜잭션 성질의 어플리케이션(300)을 통합하는 경우에 중요하다. 종종, 그러한 어플리케이션 리소스(300)로부터 메세지를 브로커링하는데 요구되는 데이터 요소는 서브-트랜잭션내에 깊게 네스팅된다. 그러므로, 이들 깊게 네스팅딘 데이터 요소들은 트랜잭션형 어플리케이션 리소스(300)와의 대화에 참여함으로써만 얻어질 수 있다. 과거에 이용되었던 다른 "원시적인" 어댑터는 트랜잭션형 어플리케이션 리소스(300)의 복잡한 양상을 적절하게 다루지 못한다.
도 4a에 도시된 바와 같이, 본 발명에 따른 전형적인 지능형 에이전트-어댑터(200)는 에이전트 구성 요소(210)와 어댑터 구성 요소(220)를 포함한다. 이러한 아키텍쳐의 한편에서는, 에이전트(210)는 시스템(100)의 특정 이벤트 및 메시징 모델을 따른다. 이러한 에이전트-어댑터 아키텍처의 다른 한편에서, 어댑터(220)는 특정 어플리케이션 리소스(300)의 고유 어플리케이션 프로그래밍 인터페이스(API, 510), 또는 다른 적합하게 공개된 인터페이스 메카니즘을 이용한다. 또한, 에이전트(210) 및 어댑터(220)은 인터페이스 프로토콜과 데이터 구조의 차이를 중재하여 그들이 공개하고 소비하는 비지니스 이벤트의 일정하고 정규화된 시각을 제공한다.
EAI에 대한 과거 접근법과는 달리, 상기한 에이전트-어댑터 아키텍처는 확장성을 가지고 있다. 이것은 변화를 현재의 API에 이음매없이 수용시키는 능력을 이용할 수 있게 할 뿐만 아니라, 현재의 API를 레거시(legacy) 시스템과 함께 이용하는 것을 계속해서 가능하게 한다. 도 4b에 더 상세하게 도시된 바와 같이, 이러한 확장성을 갖는 에이전트-어댑터 아키텍처는 통상 제1 어댑터 A'(222)와 제2 어댑터 A"(224)를 인캡슐레이팅하는 에이전트(210)을 포함한다.
예를 들면, 어댑터 A'(222)는 API의 기존 셋트 A'를 갖는 어플리케이션 리소스(300)에 대응한다. 반면에, 어댑터 A"(224)는 API의 새로운 셋트 A"를 갖는 동일한 어플리케이션 리소스(300)에 대응한다. 그러므로, 확장성의 에이전트-어댑터 아키텍처의 이용자는 인터페이스 A' 및 A"를 모두 동시에 적용하도록 선택할 수도 있다. 예들 들면, API의 기본 셋트 A'는 제조 환경에 대응할 수 있고, API의 새로운 셋트 A"는 특정 어플리케이션 리소스(300)의 새로운 버젼의 선제조 환경에 대응할 수 있다. 그러므로, API의 기본 셋트 A'가 이전에 테스팅되고 증명된 기능을 유지하는데 이용되는 것과 동시에, API의 새로운 셋트 A"는 시스템(100)내에서 "라이브하게" 테스팅될 수 있다. 그러한 방식으로, 이러한 확장성 에이전트-어댑터 아키텍처는 어플리케이션 리소스(300)로의 점진적인 변화를 통합 환경으로 이음매없이 완벽하게 중재할 수 있게 한다.
도 4c를 참조하면, 본 발명의 양호한 실시예에 따른 에이전트-어댑터(200)의 확대도를 도시하고 있다. 도 4a 및 4b에 도시된 에이전트-어댑터와 같이, 도 4c에 도시된 에이전트-어댑터(200)는 시스템(100)과 기업 어플리케이션(도시하지 않음)의 고유 API(510)간에 통신하는데 이용된다. 그러나, 본 실시예에 따른 에이전트-어댑터(200)는 3개의 어댑터(222, 224, 226)를 포함한다. 이하에 상세하게 기술되는 바와 같이, 어댑터(222)는 소스 어댑터 종류이고, 어댑터(224)는 타겟 어댑터 종류이며, 어댑터(226)은 응답 어댑터 종류이다. 그러므로, 본 기술의 당업자에게는 본 발명의 실시예에 따른 에이전트-어댑터(200)는 에이전트(210)에 의해 인캡슐레이트되는 특정 의도의 어댑터의 수가 특정 수로 제한되지 않는다는 것은 자명하다. 예를 들면, 이하에 더 상세하게 설명되는 형태의 요구 어댑터(228, 도 4c에 도시되지 않음)는 도시된 바와 같은 어댑터(222, 224, 226)와 조합하여, 또는 대체하여 이용될 수 있다.
또한, 본 발명의 또 다른 특히 중요한 양상에 따르면, 에이전트(210)는 에이전트-어댑터(200)의 기능을 확장하는데 유용한 복수의 오브젝트(230-240)를 포함한다. 예를 들면, 오브젝트(230)는 현재 변환 오브젝트를 포함하는데, 이는 시스템(100)의 집중화되지 않은 기능의 성능을 에이전트-어댑터(210) 자체내에서 국부적으로 이용할 수 있게 한다. 마찬가지로, 오브젝트(231)는 에러 관리 오브젝트를 포함하고, 오브젝트(232)는 접속 관리 오브젝트를 포함하며, 오브젝트(234)는 룰 관리 오브젝트를 포함한다. 에이전트-어댑터(200)의 확장성의 확대는 에이전트(210)와 함께 배치되는 부가 오브젝트(235-240)의 수에 의해서만 제한된다.
시스템(100)의 메시지 핸들링 양상의 탈집중화를 용이하게 할 수 있으므로, 상기 기술은 본 발명의 특히 중요한 양상이다. 그러므로, 본 발명의 실시예에 따른 에이전트-어댑터(200)가 시스템(100)의 어떤 노드와도 연관될 수 있으므로, 분산된 기업 어플리케이션 통합이 보장된다.
시스템(100)이 기업 어플리케이션간에 데이터를 공유하는 방식은, 이하에 더 상세히 기술되는 바와 같이, 통합 플로우에 의해 결정된다. 전형적인 통합 플로우는 하나 이상의 시스템 메시지를 이용한다. 시스템 메시지 각각은 통상 선정된 데이터를 하나의 소프트웨어 어플리케이션에서 다른 소프트웨어 어플리케이션으로 이동시키는, 플랫폼-중립형 포맷의 커뮤니케이션을 포함한다. 또한, 통합 플로우는 복수의 오브젝트와 오브젝트간 링크로 구성되어 있다. 각 오브젝트는 데이터를 기업 어플리케이션간에 운송하는 시스템 메시지에 관련한 특정 임무를 수행한다.
도 5(a) 부터 5(c)까지 참조하여 예를들면, 통합 플로우(540)내에서의 오브젝트는 정의 오브젝트(510) 또는 통합 오브젝트(530)을 포함한다.
본 발명에 사용되는 정의 오브젝트(510)의 세가지 기본적인 유형들은 : (1) 메시지 정의(512) ; (2) 변환 정의(514) ; 및 (3) 필터 정의(516)이 있다. 정의 오브젝트(510)은 어떠한 통합 플로우(540) 에서도 반복적으로 사용된다. 예를 들면, 동일한 메시지 정의(512)는 메시지 정의(512)를 사용하며 생산되는 시스템 메시지들을 다룰 모든 오브젝트들(510, 530)에 할당되여야 한다.게다가, 동일한 필터 정의(516)은 통합 플로우(540)의 복수개의 섹션들에 사용된다.
메시지 정의 오브젝트(512)는 시스템(100)이 추출하거나 기업 어플리케이션 (541, 549)에 전파하는 데이타를 식별한다. 그것은 또한 시스템(100)이 어떻게 기업 어플리케이션 데이타 로부터 시스템 메시지를 구성할뿐아니라 시스템 메시지들로부터 기업 어플리케이션 데이타를 만들어 낼수 있는지를 정의 한다.
변환 정의 오브젝트들(514)는 어떻게 시스템(100)이 하나 또는 그 이상의 기업 어플리케이션들로부터 추출된 시스템 메시지들을 다른 기업 어플리케이션들에 의해 요구되는 시스템 메시지들로 변환할수 있는지를 정의 한다.
필터 정의 오브젝트(516)은 시스템(100)이 통합 플로우들로부터 불필요한 시스템 메시지들을 제거하느데 사용할 기준을 정의 한다. 새로운 고객 데이타를 인보이스로 변환하는 통합 플로우에서는, 예를 들어 유용한 필터 정의 오브젝트(516)은 이미 지불한 고객들에 관한 시스템 메시지들이 제거되는 시스템일 수 있다.
통합 오브젝트(530)은 세가지 기본적인 유형들이 있는데 실제적으로 시스템 메시지들을 주고 받는다. 통합 오브젝트(530)의 세가지 기본적인 유형들은 : (1) 어댑터(220); (2) 메시지 허브(518) ; 및 (3) 변환기(520) 이 있다. 게다가, 상기에 간략히 기술된 바와 같이 어댑터(220)의 네가지 기본적인 유형들 : (a) 소스 어댑터(222) ; (b) 타겟 어댑터(224) ; (c) 응답 어댑터(226) ; 및 (d) 리퀘스트 어댑터(228)이 있다.
소스 어댑터(222)는 소스 기업어플리케이션으로부터 데이타를 추출하고, 그 데이타로부터 시스템 메시지를 구성하고, 그 시스템 메시지들을 다른 통합 오브젝트들(530)(예를 들어 메시지 허브(518))에 보낸다. 타겟 어댑터는 다른 통합 오브젝트들(530) (예를 들어 변환기(520) 부터 필터 정의 오브젝트(516))로부터 시스템 메시지들을 받고, 그러한 시스템 메시지들로부터 어플리케이션 데이타를 만들어 내고, 그 데이타를 타겟 기업 어플리케이션에 전파한다. 응답 어댑터(226)은 어플리케이션들로부터 데이타를 추출함에 의해 다른 통합 오브젝트들(530)의 데이타 리퀘스트에 응답한다.
일반적으로, 메시지 허브들(518)은 하나 또는 그 이상의 소스 통합 오브젝트들(530)으로부터 시스템 메시지들을 받는데 쓰이고, 또한 시스템(100)이 같은 것을 하나 또는 그 이상의 타겟 통합 오브젝트들(530)에 전달할수 있을때 까지 그러한 시스템 메시지들을 보유하는데도 쓰인다.
변환기들(520)은 세 단계로 변환기 정의들을 구현하는데 쓰인다. 처음에 그것들은 소스 통합 오브젝트들(530) (예를 들어 메시지 허브(518))로부터 시스템 메시지들을 모은다. 모으는 단계 이후에, 그것들은 그러한 시스템 메시지들 안에 있는 데이타의 내용과 형식을 변환한다. 최종적으로 그들은 출력시스템 메시지들을 만들고 타겟 통합 오브젝트들(530) (예를 들어 타겟 어댑터(224))에 보낸다.
메시지 정의(512)는 본 발명에 의해 통합 플로우(540)이 주위에 세워진 프라이머리 오브젝트들이다. 사용자가 통합 플로우를 만들때, 메시지 정의는 그 플로우내의 모든 오브젝트(510, 530)에 할당된다. 메시지 정의(512)는 오브젝트(510, 530)이 다루어야할 그러한 종류의 시스템 메시지들을 식별할뿐아니라 시스템 메시지의 계층적 구조와 개요를 정의한다.
예를 들어, 메시지 정의(512)는 사용자의 통합 플로우(540)에 있는 모든 소스 어댑터(222)에 할당되어야 한다. 각 소스 어댑터(222)는 사용자가 할당한 메시지 정의(512)에 근거해서 만들어 내야 할 메시지가 어떠한 것인지를 안다. 어댑터들(220), 허브들(518), 및 필터들(516)은 단지 하나의 메시지 정의(512)만을 다룬다. 반면에, 변환기 정의들(514)와 변환기(520)은 입출력들과 같이 복수의 메시지 정의들(512)를 다루는 것이 가능하다.
어떤 어플리케이션들은 시스템(100)이 지원하는 자바 데이타 유형들을 만들수 있다. 그러한 경우에, 소스 어댑터(222)는 그것의 메시지 정의(512)에서 특징화된 데이타 유형들을 추출할수 있고 그것들을 직접 시스템 메시지에 저장할 수 있다. 마찬가지로, 타겟 어댑터(224)는 시스템 메시지로부터 그 데이타 유형들을 복원할 수 있고 직접 그것들을 어플리케이션(예를 들어 타겟 기업 어플리케이션 (549))에 삽입할 수 있다. 다른 어플리케이션들은 원래 데이타의 레이아웃을 기술하기 위한 잘 정의된 메시지 포맷을 사용한다. 그러한 경우에, 소스 어댑터(222) 를 위한 메시지 정의(512)는 어플리케이션 데이타로부터 자바 데이타 유형들을 만들기 위한 명령들을 포함해야 한다. 유사하게, 타겟 어댑터(224)를 위한 메시지 정의(512)는 시스템 자바 오브젝트들로부터 어플리케이션 데이타를 만들기 위한 명령들을 포함해야 한다.
특수한 종류의 메시지 정의(512)는 다른 시스템 오브젝트들(510, 530)으로부터 데이타를 리퀘스트하는 통합 오브젝트(530)에 의해 사용된다. 예를 들어, 메시지 정의들(512)는 메시지 확인 기준을 지정할 수 있다. 시스템(100)은 어댑터(220)과 변환기(520)에 의해 만들어진 시스템 메시지들이 유효한 데이타(예를 들어 거기에 사용자는 메시지들을 정의하는 메시지 정의(512)를 포함하는데 그것은 종업원 급료 정보를 포함한다)를 포함하는지를 결정하는 기준을 사용한다. 따라서, 사용자는 시스템(100)에 들어감에 의해 부정확한 급료 데이타를 방지할 수 있다. 예를 들어 , 만약 메시지 정의(512)가 아이템 요소 "급료"를 포함한다면, 사용자는 "급료"에서의 값이 양수일때만 메시지가 유효하다는 아이템에 대한 확인 기준을 정의할 수 있다. 사용자는 관련된 메시지 정의들(512)를 메시지 카테고리로 불리는 논리 그룹들로 조성할 수 있다. 예를 들어 사용자가 시스템(100)을 사용하는 세가지 어플리케이션들을 통합한다고 가정해 보라. 사용자는 사용자들의 프로젝트에 있는 메시지들을 각 어플리케이션마다 하나의 세가지 메시지 카테고리들로 그룹화 할 것이다.
메시지 정의(512)의 특별한 메시지 개요(600)은 메시지 구성들로 불리며, 도 6에 나타난 계층적 구조에 배열된 데이타 오브젝트들로 구성된다는 점을 이 시점에서 주목해야 한다. 일반적으로, 메시지 개요(600)은 하나 또는 그 이상의 섹션 (620), 테이블(640), 아이템(660)을 포함한다. 섹션(620) 또는 테이블(640) 은 메시지(600)계층의 최상부에 나타나야 한다.
섹션(620)은 메시지 구성들의 반복하지 않는 그룹이다. 그러한 섹션 구성들은 실제 데이타를 포함하지 않는다. 대신에, 그것들은 데이타(즉, 아이템들(660)을 포함한다)를 포함하는 다른 메시지 구성들을 포함한다. 섹션(620)은 어떠한 메시지 구성유형들의 조합도 포함할 수 있다.
테이블(640)은 몇 회든지 반복할 수 있는 열들로 불리는 섹션구성들의 그룹이다. 테이블 구성들도 또한 실제 데이타를 포함하지 않는다. 그것들은 데이타(즉, 그것들은 아이템들을 포함한다)를 포함하는 다른 메시지 구성들을 포함한다. 테이블(640)은 어떠한 메시지 구성유형들의 조합도 포함할 수 있다.
아이템(660)은 데이타를 포함하는 메시지 구성이다. 아이템(660)들은 메시지 정의의 계층에서 최하위 레벨의 메시지이다. 그것들은 다른 메시지 구성들을 포함할 수 없다.
각 메시지 정의(512)는 그러한 정의에 근거한 메시지들을 확인하는 기준을 포함할 수 있다. 즉, 사용자가 메시지 정의를 정의할때, 개인적 메시지 구성들에 있는 데이타가 시스템(100)내에서 유효하다고 생각되는 메시지를 만나야 하는 기준을 지정할 수 있다.
사용자는 모든 레벨들의 메시지에 대한 확인 기준을 지정할 수 있다. 즉, 사용자는 섹션들 또는 테이블들 내의 메시지 아이템들의 기준을 지정할 수 있다. 모든 메시지는 확인 기준을 통하며 플로우를 통해 유지되거나 통하지 않고 버려진다. 만약 심지어 한 테이블의 하나의 열이 지정된 기준을 통하지 않는다면, 모든 메시지는 통하지 않는다. 시스템(100)은 적당한 메시지 정의에서 확인 기준을 사용하는 어댑터(220) 또는 변환기(520)에 의해 산출된 모든 메시지를 유효화 한다.
어댑터들(220)은 데이타를 추출하거나 전파하기 위해 기업 어플리케이션과 연결된다. 각 어댑터(220)은 사용자가 할당하는 메시지 정의(220)을 사용하여 메시지들을 생산하고, 받고, 응답한다. 시스템(100)은 어플리케이션들에게 표준 어댑터(220)을 제공하고 통합할 것이다. 상기 각 표준 어댑터(220)은 소스 어댑터(222), 타겟 어댑터(224), 응답 어댑터(226), 리퀘스트 어댑터(228) 이고, 특별한 에이전트 서비스 유형을 위해 고안되었다. 예를 들어 모든 X 브로커를 위해 그 시스템은 ETB 표준 소스 어댑터와 ETB 표준 타겟 어댑터를 제공한다. 표준 어댑터들은 포괄적이다. 그것들은 베이직 기초적 예외 조작을 제공하며 어떤 메시지 정의도 다룰수 있다. 만약 표준 어댑터(220)이 사용자가 어플리케이션(예를 들어 사용자가 더 자세한 예외 조작을 지정하기를 원한다)과 상호작용하는데 필요한 모든 코드를 포함하지 않는다면, 사용자는 ADK(130)을 써서 커스텀 어댑터(220)을 만들수 있다. 사용자는 또한 시스템(100)에 의해 현재 지원되지 않는 어플리케이션들을 위한 커스텀 어댑터들(220)을 만들기 위해 ADK(130)을 사용할 수 있다. 이와 같이, 사용자는 자바 어플리케이션 프로그래밍 인터페이스와 함께 어떤 어플리케이션에도 연결하는 커스텀 어댑터들(220)을 만들기 위해 ADK(130)을 사용할 수 있다.
통합 플로우(540)에서 표준 또는 커스텀 어댑터(220)을 사용할때, 사용자는 특별한 메시지 정의(512)를 다루기 위해 그것을 배열해야 한다. 사용자는 통합 플로우(540)에서 포함할 필요가 있는 모든 메시지를 다루기 위해 필요한 만큼의 많은 각 유형의 어댑터(220)을 배열할 수 있다.
소스 어댑터(222)는 기업 어플리케이션으로부터 데이타를 추출하고 다른 통합 오브젝트들(530)에 보내는 메시지들을 산출한다. 특히, 소스 어댑터(222)는 : (1) 폴링하거나 어플리케이션 (예를 들어 새로운 고객의 가입에 관한 데이타) 에서 발생한 특별한 유형의 사건에 관한 어플리케이션에 의해 인식되고; (2) 그 어플리케이션에서의 사건에 관계된 데이타를 추출하고; (3) 메시지 정의 인스트럭션들을 사용하여 데이타로부터 시스템 메시지를 구성하고 ; (4) 메시지를 산출하여 하나 또는 그 이상의 타겟 통합 오브젝트들(530)에 보낸다.
타겟 어댑터(224)는 통합 플로우(540)에 있는 다른 시스템 오브젝트들(510, 530)으로부터 메시지를 받고 그 메시지 데이타를 기업 어플리케이션들(541, 549)에 전파한다. 특히, 타겟 어댑터(224)는 : (1) 하나 또는 그 이상의 소스 통합 오브젝트들(530)으로부터 시스템 메시지들을 받고 ; (2) 메시지 정의(512)로부터의 인스트럭션들을 사용하여 시스템 메시지로부터 어플리케이션 데이타를 만들고 ; (3) 새로운 데이타를 삽입하고, 데이타를 업데이트 하고, 적절하게 데이타를 삭제하여 그 데이타를 타겟 어플리케이션(549)에 전송한다.
응답 어댑터들(226)은 변환기들(520)과 같은 통합 오브젝트들(530)에 의해 리퀘스트될때 기업 어플리케이션으로부터 데이타를 추출한다. 특히, 응답 어댑터(226)은 : (1) 통합 오브젝트(530)으로부터 리퀘스트 데이타를 받고 ; (2) 기업 어플리케이션(541, 549)로부터 리퀘스트된 데이타를 추출하고 ; (3) 리퀘스트 메시지와 동일한 메시지 정의(512)에 기초한 응답 메시지로 그 데이타를 변환기(520)에 전송한다.
응답 변환기들(522)와 접합되어 있는 리퀘스트 어댑터들(228)은 그러한 어플리케이션들로부터 특별한 리퀘스트 없이 기업 어플리케이션들(541, 549)로부터 데이타를 추출하는데 쓰인다. 도 7에 도시된 바와 같이, 그것들은 다른 리퀘스트를 만들어내는 어플리케이션 오브젝트(710)에 필요하게 되기를 기대하는 정보를 복원한다. 예를 들어, 어플리케이션 오브젝트(710)으로부터의 리퀘스트는 " 나는 고객의 선적 데이타를 보고 싶다" 만큼 간단할 것이다. 그러한 고객 선적 데이타를 포함하는 모든 데이타는 미리 뽑아지고, 리퀘스트된 동일 메시지 정의에 접속되고, 어플리케이션 오브젝트(710)에 푸쉬된다. 특히, 리퀘스트 어댑터(228)는 : (1) 어플리케이션 오브젝트(710)으로부터 리퀘스트 메시지를 수신하고 ; (2) 시스템(100)에 있는 다른 오브젝트(540)으로부터 직접 또는 응답 변환기(522)를 통한 지원으로 선행 데이타를 추출하고; (3) 리퀘스트 메시지와 동일한 메시지 정의(512)를 통하는 메시지로 그 데이타를 어플케이션 오브젝트(710)에 전송한다.
아래에 상세히 설명된 바와 같이, 어댑터(220)들은 에이전트 서비스들에 의해 호스트된다. 에이전트 서비스들은 어댑터(220)들이 자신들의 애플리케이션에 접속시킬 필요가 있는 정보(가령, 패스워드 및 사용자 ID)를 제공한다. 시스템(100)은 자신이 통합할 수 있는 기업 애플리케이션마다 에이전트 서비스들을 제공한다. 즉, 시스템은 SAP R/3 에이전트 서비스, EntireX Broker 에이전트 서비스 들을 제공한다. 시스템(100)은 또한 사용자가 ADK(130)를 사용해서 생성하는 커스텀 어댑터들에 대해 에이전트 서비스들을 제공한다.
사용자는, 시스템(100)을 사용해서 자신이 통합하기를 원하는 기업 애플리케이션 각각에 대해 하나의 에이전트 서비스를 필요로 한다. 예를 들어, 사용자가 한개의 RDBMS와 함께 세개의 SAP R/3 시스템을 통합하기를 원한다면, 사용자는 세개의 SAP R/3 에이전트 서비스와 한개의 RDBMS 에이전트 서비스를 필요로 한다. 각 에이전트 서비스는 자신이 접속할 기업 애플리케이션에 대한 모든 어댑터(220)들을 호스트한다.
변환자 정의(514)는 하나 또는 그 이상의 애플리케이션으로부터 추출된 데이터를 포함하는 메시지들을 하나 또는 그 이상의 애플리케이션에 필요한 데이터를 포함하고 있는 메세지들로 변환하는 프로세스를 정의한다. 변환자(520)들은 소스 대상들로부터 입력 메시지들을 수집하고, 이 데이터를 변환하고, 출력 메시지들을 타겟 대상들로 전송함으로써 변환자 정의(514)를 이행한다.
변환자 정의(514)에서 정의된 변환 프로세스는, 도 8에 도시된 바와 같이 적어도 두 종류의 메시지: 주 입력 메시지(primary input message)와 하나 또는 그 이상의 출력 메시지를 항상 포함한다. 주 입력 메시지는, 일반적으로, 사용자가 출력 메시지 내에서 타겟 애플리케이션으로 전송하기를 원하는 데이터의 대부분 또는 모두를 포함한다. 출력 메시지들은 타겟 애플리케이션에 필요한 형태로 변환된 입력 메시지들로부터의 데이터를 포함한다.
사용자가 변환자 정의(514)를 생성할 때, 사용자는 우선 805에서 주 입력 메시지를 구체화 한다. 다음에, 810에서, 사용자는 자신이 주 입력 메시지로 사용하기를 원하는 메시지들을 정의하는 메시지 정의(512)를 식별한다. 다음에, 임의의 보조 입력 메시지(supporting input message)들이 815에서 구체화된다. 다음에, 820에서 사용자는 이러한 보조 입력 메시지들을 정의하는 메시지 정의(512)를 식별한다. 단일 변환 프로세스는 임의 수의 출력들을 산출할 수 있다. 따라서, 사용자는 이 출력 메시지들을 825에서 구체화하고, 사용자가 출력들로서 산출하기를 원하는 메시지들을 정의하는 메시지 정의(512)들을 식별해야 한다.
다음에, 사용자는, 835에서 시작하여, 일련의 단계들 840, 845, 850, 855, 860, 865를 생성하며, 여기서 입력 데이터를 판독 시점, 입력 데이터를 변환하는 방법, 입력 메시지 정의들로부터 출력 메시지 정의들로 입력 데이터를 맵핑하는 방법, 변환된 데이터를 실제 출력 메시지들에 기록하는 시점을 정의한다.
사용자는 자신이 필요로 하는 출력 메시지들을 생성하기 위해 필요한 임의의 방식으로 입력 데이터를 변환한다. 예를 들어, 타겟 애플리케이션이 하나의 데이터 필드에 고객의 성명(full name)을 기록하기를 요구하기 때문에, 사용자는 고객의 이름(first name)을 포함하는 메시지 항목과 고객의 성(last name)을 포함하는 메시지 항목을 연관시키는 것을 구체화하는 변환 표현을 생성할 수 있다. 사용자는 메시지 항목으로부터 특정 문자들만을 선택하는 것, 또는 타겟 애플리케이션 내의 대응하는 데이터 필드에 대해 올바른 길이가 되도록 하는 간격을 두고서 메시지 항목을 패딩(padding)하는 것을 구체화하는 변환 표현을 생성한다. 다음에 사용자는 서로 다른 출력 메시지들을 변환 프로세스 내의 서로 다른 시점에서 기록함으로써 산출한다.
주 입력 메시지가 출력 메시지들을 산출하기 위해 필요한 모든 데이터를 포함하지 않을 때, 사용자는 요청/답신 메시지를 정의들을 사용하는 변환 프로세스에 대한 보조 입력을 획득할 수 있다. 예를 들어, 사용자가 변환자 정의 내에서 사용하는 주 입력 메시지가, 미국의 주명들에 대한 약어(가령, 버지니아주에 대해 VA)를 사용한다고 가정하자.
예를 들어, 타겟 애플리케이션은 주명 전체를 요구한다고 가정한다. 출력 메시지들을 산출하는데 필요한 전체 주명을 얻기 위해, 사용자는 약어들을 애플리케이션에 전송하고 이에 대한 회답으로써 주명을 수신할 수 있는 요청/답신 메시지 정의를 사용할 것이다.
사용자가 변환자 정의(514)를 생성한 후에, 사용자는, 통합 흐름에서 이것을 사용하기 전에 적절한 출력 메시지들을 산출할 수 있는지를 확인하기 위해 테스트를 할 수 있다. 그 후에, 사용자는 변환자 정의를 하나 또는 그 이상의 변환자(52)들에 할당할 수 있다.
변환자(520)는 변환자 정의(514)를 이행한다. 사용자가 변환자(520)를 생성할 때, 사용자는 주 입력 메시지의 소스들로서 사용하기 위한 대상(510, 530)들과, 출력 메시지들에 대한 타겟이 될 대상들(510, 530)을 구체화한다. 또한 사용자는 보조 입력들의 대한 요청들에 응답할 대상들을 구체화한다. 변환자(520)가 소스 대상(540)으로부터 주 입력 메시지를 수신할 때, 변환 프로세스를 설정하는 변환자 정의(514) 내에 정의된 일련의 단계들을 구동시킨다. 그 다음에, 주 및 보조 입력 메시지들을 판독하고, 입력 데이터를 변환하고, 변환된 데이터를 하나 이상의 출력 메시지에 기록하고, 출력 메시지를들을 타겟 대상(540)에 전송한다. 전형적인 변환 프로세스가 도 9에 도시되어 있다. 변환자(520)는 허브(518)로부터 주 입력 메시지(920)를 수신한다. 다음에, 답신 어댑터(226)로부터 보조 입력 메시지(940)를 얻는다. 마지막으로, 변환자(520)는 두 개의 서로 다른 출력 메시지들(960, 980)을 두 개의 서로 다른 타겟 어댑터들(224)로 전송한다.
허브(518)는 어댑터(220) 및 변환자(520)을 위한 메시지 홀딩 영역이다. 허브(518)는 어댑터(220) 및 변환자(520)가 비동기로 메시지들을 교환하도록 하며, 대상들 간의 링크를 단순화 한다. 예를 들어, 사용자는 메시지들을 변환자(520)로 산출할 수 있는 소스 어댑터(222)를 가질 수 있다. 사용자는 어댑터(222)가 자신의 메시지를 변환자(520)가 수신할 준비가 되었는지의 여부에 관계없이 메시지를 산출하고 생성하는 것을 원할 수 있다. 사용자는 어댑터(222)가 자신의 메시지를 메시지 허브(518)에 전송하는 것을 설정할 수 있고, 변환자(520)가 어댑터의 메시지를 허브(518)로부터 수신하는 것을 설정할 수 있다. 다음에, 시스템(100)은 타겟이 메시지들을 수신할 준비가 되었을 때, 허브(518)로부터 타겟 대상(540)에 메시지를 전달한다.
또한, 사용자는 동일한 메시지 정의(512)에 기초하여 메시지들을 5개의 타겟(224, 520)들에 전송하는 세개의 소스 어댑터들(222)을 가질 수 있다. 사용자가 허브(518)를 사용하지 않을 때(도 10 a에 도시됨), 사용자는 이들 대상 간에 총 15개의 링크들을 생성해야 할 것이다. 반면에, 사용자가 허브(518)를 사용한다면(도 10(b)에 도시됨), 사용자는 단지 8개의 링크만을 생성해야 할 것이다. 메시지 허브(518)는 한 종류늬 메시지(즉, 단일 메시지 정의(512)로부터 산출된 메시지)만을 홀드할 수 있다. 허브(518)들의 타겟들은 영구적인 예약(durable subscription)을 갖는다. 시스템(100)은, 태겟 대상들(224, 520)이 아직 수신하지 못한 메시지들뿐만 아니라, 각 타겟 대상(224, 520)들이 허브(518)로부터 수신한 메시지들의 트랙을 유지한다. 타겟 대상(224, 520)이 비활성이 되면, 시스템(100)은 타겟 댜상(224, 520)들이 수신한 최종 메시지들을 기억한다. 이 타겟 대상들(24, 520)이 다음에 활성이 되면, 시스템(100)은 타겟 대상들(224, 520)이 아직 수신하지 못한 메시지들만을 전달한다. 허브 예약은 영구적이지 못하다면, 타겟 대상들(224, 520)은 타겟 대상들(224, 520)이 활성인 동안에 허브(518)에 도착한 메시지들을 수신할 수 있으나, 타겟 대상들(224, 520)이 비활성인 동안에 허브(518)에 도착한 메시지들은 수신할 수 없다.
사용자는, 허브(518)로부터 메시지들을 전달할 때 시스템(100)에 사용되기를 자신이 원하는 두 개의 메시징 스타일[(1)point-to-point, 시스템(100)은 각 메시지를 제1 타겟에만 전달함; (2)publish/subscribe, 시스템(100)은 각 메시지를 사용자가 허브(518)의 타겟으로서 식별한 대상마다 전달함)로부터 선택할 수 있다.
사용자가 특정 종류의 데이터를 통합 흐름(540)의 일부로부터 스크린하기를 원한다면, 사용자는 필터 정의(516)를 사용해야 한다. 필터 정의(516)는 메시지 데이터에 기초한 기준을 구체화(즉, 이 기준을 건네주는 데이터는 흐름 동안 게속됨)하고, 반면에 이 기준을 건네주지 않는 데이터는 폐기된다.
사용자가 특정 종류의 메시지를 필터링하기를 원할 때, 사용자는 필터 정의(516)를 생성하고, 이런 종류의 메시지를 다루는 대상들(540) 사이의 하나 이상의 링크에 이 필터 정의를 할당한다. 시스템(100)은 필터 정의(516) 내의 기준을 이들 링크를 통해 전송된 모든 메시지에 적용한다.
예를 들어, 허브(520)가 새로운 고객에 대한 데이터를 포함하는 메시지들을 타겟 어댑터(224)에 전송하는 경우를 고려한다. 사용자는 타겟 어댑터(224)에 아직 도달했음을 표하지 못한 고객들에 대한 데이터만을 원할 수 있다. 이 경우에, 사용자는 필터 정의(516)[기준 "Status = Paid"를 구체화하며, 이것을 허브(518)와 타겟 어댑터(224) 사이의 링크에 할당함]를 생성할 수 있다.
사용자는, 사용자의 통합 흐름(540)에서 각 메시지 정의(512)에 대해 하나 이상의 필터 정의(516)를 생성할 수 있다. 사용자는 단일 필터 정의(516)를 다중 링크에 할당하거나, 혹은 동일한 종류의 메시지에 대해 서로 다른 필터 정의(516)를 서로 다른 링크에 할당할 수도 있다.
예를 들면, 허브(518)가 새로운 고객에 대한 데이타를 포함하는 메시지를 두 개의 어댑터(220)로 전송하는 상황을 고려하기로 한다. 사용자는, 하나의 어댑터(220)가 이미 지불한 고객에 대한 데이타만을 수신하도록 하고 다른 어댑터(220)가 지불하지 않은 고객에 대한 데이타만을 수신할 것을 원할 수도 있다. 따라서, 사용자는 두 개의 필터 정의(516)를 생성할 것이다. 그중 하나는 기준 "Status=Unpaid"를 규정하며, 다른 하나는 기준 "Status=paid"를 규정한다. 그 후, 사용자는 각 필터 정의(516)를 적절한 링크로 할당할 것이다.
사용자가 데이타 테이블을 포함하지 않는 메시지에 대한 필터 정의(516)를 생성할 때 사용자가 규정하는 기준은 전체 메시지에 효력을 발휘할 것이다. 전체 메시지는 필터 기준을 통과시키고 흐름를 계속 진행하거나, 혹은 필터 기준을 통과시키지 않고 폐기된다.
사용자가 데이타 테이블을 포함하는 메시지에 대한 필터 정의(516)를 생성할 때, 사용자는 전체 메시지에 영향을 미치거나 혹은 테이블 내의 데이터에만 영향을 미치는 기준을 구체화할 수 있다. 사용자가 섹션(620) 내의 메시지 아이템에 대한 기준을 구체화할 경우, 전체 메시지는 기준을 통과하여 흐름를 계속 진행하거나, 혹은 기준을 통과하지 않고 폐기된다. 사용자가 테이블(640) 내의 메시지 아이템에 대한 기준을 구체화할 경우, 메시지는 기준을 통과하는 데이터 열들만을 갖는 흐름를 통과하여 계속 진행할 것이다. 기준을 통과하지 않는 열은 폐기된다.
예를 들면 메시지가, 각각이 9명의 새로운 고객에 대응하는 9개의 데이타 행을 갖는 테이블(640)을 포함하는 상황을 고려한다. 사용자가, $1000 미만을 소비한 고객을 필터링하는 필터 정의(516)를 설정할 경우, $1000 이상을 소비한 고객에 대한 데이터를 갖는 열은 계속해서 흐름를 통과하여 진행될 것이며, 반면에 $1000 미만을 소비한 고객에 대한 데이타를 갖는 열은 폐기될 것이다.
사용자가 필터 정의(516)를 생성한 후, 사용자는 통합 흐름(540)에서 이를 사용하기 전에 이 필터 정의가 적절하게 동작하는 지를 확인하기 위해 테스트할 수 있다.
사용자가 통합 흐름(540)에서 사용하기를 원하는 시스템 오브젝트가 존재하면, 사용자는, 사용자가 시스템이 이들중 메시지를 루팅하기를 원하는 방법을 나타낼 수 있다. 이렇게 하기 위해, 사용자는 통합 오브젝트(530)중 링크를 설정한다. 각 링크는 하나의 오브젝트를 소스로서 다른 하나를 타겟으로서 설정하거나, 혹은 하나의 오브젝트를 요구자로서 다른 하나를 응답자로서 설정한다. 소스 어댑터는 항상 메시지 소스이다. 이들은 메시지를 동일한 에이전트 서비스 유형의 타겟 어댑터, 메시지 허브(518), 및 트랜스포머(520)에 전송할 수 있다(예를 들면, SAP R/3 소스 어댑터는 메시지를 SAP R/3 타겟 어댑터로 메시지를 전송할 수 있다).
트랜스포머(520)는 타겟, 요구자 및 소스일 수 있다. 이들은 소스 어댑터(222), 메시지 허브(518), 및 그 밖의 다른 트랜스포머(520)로부터 주요 입력 메시지(920)를 수신할 수 있다. 이들은 또한 응답 어댑터(226) 및 메시지 허브(518)로부터의 입력 메시지(940)를 지원할 것을 요구하여 출력 메시지(960, 980)를 타겟 어댑터(224), 허브(518), 및 그 밖의 다른 트랜스포머(520)로 전송할 수 있다. 메시지 허브(518)는 타겟 및 소스일 수 있다. 타겟 어댑터(224)는 항상 타겟이다. 이들은 동일한 에이전트 서비스 유형의 소스 어댑터(222), 허브(518), 및 트랜스포머(520)로부터 메시지를 수신할 수 있다.
디폴트에 의해, 시스템(100)은 "메시지 유지"를 사용한다. 즉, 사용자가 구체화하는 위치 내에서 저장 장치를 안정화하기 위해 하나의 통합 오브젝트(530)로부터 다른 오브젝트로 전달하는 각 메시지를 기록한다. 메시지가 전송되는 동안 시스템 오류가 발생할 경우, 시스템이 복구되고 메시지를 타겟으로 전달할 때 시스템(100)은 저장 장치로부터 메시지를 검색할 수 있다.
메시지 유지로 인해 시스템 오버헤드가 증가되기 때문에, 시스템(100)은 사용자로 하여금 임의의 통합 오브젝트(530)에 대한 유지를 턴 오프하도록 해준다. 그러나, 그 오브젝트와 메시지 전달이 행해지고 있는 동안 시스템 오류가 발생할 경우, 이들 메시지가 손실될 수도 있다. 시스템(100)은, 사용자가 사용자의 시스템 자원을 관리하는 것을 돕는 다른 전달 관련된 옵션을 제공한다. 시스템(100)은 통합 흐름 내의 각 통합 오브젝트에 대한 메시지 보유 영역을 유지한다. 사용자는 또한 이들 보유 영역을 제어할 수 있다.
사용자는, 시스템(100)이 한번에 각 오브젝트에 대해 보유하는 메시지의 수를 제한할 수 있으며, 시스템(100)이 각 메시지를 보유하는 시간의 길이도 제한할 수 있다. 통합 오브젝트(530)가, 타겟이 메시지를 수신할 수 있는 것보다 더 빨리 메시지를 생성하는 경우, 이들 제한으로 인해, 오브젝트의 보유 영역이 시스템 자원을 스트레인(strain)하는 크기로 성장하는 것을 방지할 수 있게 된다.
사용자는 작업대(120) 상의 프로젝트 내의 모든 통합 흐름를 설계한다. 사용자가 설계하고 저장하는 이들 통합 흐름(즉, 사용자가 생성하는 정의(510) 및 통합 오브젝트(530)와, 이들간의 링크)는 모두 저장소(140) 내에 저장된다. 이 프로젝트는 사용자가 저장소(140)를 보게 하는 논리적 구조이다. 시스템(100)의 각 장치는 하나의 프로젝트와 하나의 저장소(140)를 갖는다.
시스템(100) 내의 모든 메시지 생성기에 의해 사용되는 메시지 오브젝트의 일반적인 구조 및 설계 원리를 이하 기술한다. 본 명세서에 개시된 메시지 모델은 무한히 확장될 수 있으며, 시스템(100) 내의 노드에서 노드로 내부 메시지를 전송하는데 유용할 뿐만 아니라 원시 파일 포맷으로 변환 또는 원시 파일 포맷으로부터의 변환에도 유용하다. 이 메시지는 원래 계층적이며 명칭/값 쌍 패러다임을 사용하여 데이타를 표현한다. 본 발명에 따른 메시지 모델에 의해 표현된 데이터는 항상 오브젝트 기반한 것이다. 이는 소정의 클래스의 자바 오브젝트의 예이다. 각 데이타 노드는, 구체화된 클래스의 데이타만을 포함할 수도 있다는 의미에서 타입-안전(type-safe)이다. 메시지의 구조는 메타데이타-드리븐(metadata-driven)이다.
즉, 메시지 정의(512)로 알려진 오브젝트 내에 놓인 구조를 이용하여 구성이 잘된 메시지가 항상 구축된다. 소정의 "타입"의 모든 메시지는 동일한 메시지 정의(512)로부터 구축된다. 메시지 정의(512)는, 자신의 노드가 원시 애플리케이션 파일 포맷으로부터 혹은 원시 애플리케이션 파일 포맷으로 데이터를 변환하는 방법에 관한 선택적인 정보 뿐만 아니라 기술되는 포맷의 예를 구축하는 정보도 포함하도록 확장되지만, 그 자체는 메시지의 예이다.
전술한 바와 같이, 메시지(600)는 간단하고 복합적인 오브젝트의 트리 구조 집합이다. 메시지 내에 나타날 수 있는 모든 오브젝트는 여러 유형의 "메시지 엔트리"이다. 본 발명의 바람직한 실시예에서, 메시지 엔트리는, (1) 데이타 엘리먼트, (2) 어레이 엘리먼트, (3) 테이블 엘리먼트, (4) 섹션 엘리먼트 또는 "메시지 링크"중 하나를 포함한다. 메시지는 "탑 레벨 섹션"으로 알려진 트리의 상부에 단일 섹션 엘리먼트를 항상 가지고 있다. 이 섹션 및 다른 섹션은 임의의 4개의 엘리먼트 타입의 예를 포함할 수도 있다.
데이타 엘리먼트는, 데이타가 자바 클래스로 되어 있지만 "아토믹(atomic)" 데이타를 포함한다. 예를 들면, 자바 언어로 정수 데이타가 저장된다. 정수 오브젝트, 데이타/시간 정보는 자바 유틸리티 내에 캡슐화된다. 캘린더 오브젝트 등도 마찬가지이다. 어레이 엘리먼트는 하나 이상의 원시 엘리먼트의 집합이다. 어레이의 길이는, 이 길이가 허용가능한 범위로서 구체화될 수 있지만 메타데이타 내에서 구체되며, 이 경우 길이는 원시 애플리케이션의 파일 레코드를 파싱함으로써 결정된다. 테이블 엘리먼트는 실질적으로 동일 구조의 섹션 엘리먼트의 집합이며, 이는, 테이블의 각 "열"이 명칭 및 유형의 동일한 조합을 포함하는 섹션임을 의미한다. 이는 또한 가변가능한 범위의 명세를 갖는다. 메시지 링크는 시스템 내의 다른 지속적인 메시지 정의에 대한 포인터이며, 포맷을 병합하는데 사용된다. 이는 "재규정"을 실현하는 데에 유용하다. 메시지는 메시지 정의에서 규정된 바와 같이 디폴트 값 뿐만 아니라 선택사양적인 데이타도 표현할 수 있다.
가장 간단한 사용에서, 메시지 정의 클래스 내의 정적인 팩토리 방법을 유발함으로써 생성되는 비어 있는 포괄적인 메시지를 생성한다. 이는, 모든 적절한 명칭/값 쌍을 갖는 메시지를 생성하지만, 각 데이타 아이템은 널(null)로 설정된다. 이 오직 공공연하게 외부로 반출되는 메시지 구축자는 파라미터로서 메시지 정의를 요구하여 적절한 형식을 보장한다. 메시지 API는 지정된 룩업 또는 섹션 반복자를 통해 자신의 엘리먼트에 액세스하는 방법을 제공한다. 이 시점에서, 메시지는 구성가능한 분리기를 사용하여 계층적인 명칭화 구조를 지원하여, 계층 구조 내의 임의의 성분으로의 완전하거나 혹은 관련된 "경로 명칭" 액세스를 허용한다.
섹션(620)은 메시지 엘리먼트의 비반복적인 그룹이다. 이러한 섹션 엘리먼트는 실질적인 데이타를 포함하지 않는다. 대신에, 데이타를 포함하는 다른 메시지 엘리먼트를 포함한다(즉, 아이템(660)을 포함한다). 섹션(620)은 메시지 엘리먼트 유형의 임의의 조합을 포함할 수 있다.
도표(640)는 임의의 횟수 반복될 수 있는 행이라고 하는 일군의 섹션 요소이다. 도표 요소들도 실제 데이터를 갖고 있지 않다. 이들은 데이터를 갖는 다른 메시지 요소를 갖는다(즉 이들은 항목을 갖는다). 도표(640)는 메시지 요소 유형의 임의 조합을 포함할 수 있다.
항목(660)은 데이터를 갖는 메시지 요소이다. 항목(660)은 메시지 정의의 계층 내의 최저 레벨 메시지 요소이다. 이들은 다른 메시지 요소를 포함할 수 없다.
사용자는 워크벤치(120) 상의 한 프로젝트 안에 모든 통합 흐름(540)을 설계한다. 사용자가 설계하고 저장하는 통합 흐름(540)(즉, 사용자가 만든 정의(610) 및 통합 오브젝트(620), 및 이들간의 링크)은 모두 저장소(140)에 저장된다. 프로젝트는 사용자가 저장소(140)를 보도록 하는 논리 구조이다. 시스템(100)의 각 장치는 하나의 프로젝트와 하나의 저장소(140)를 갖는다.
본 발명의 다른 중요한 특징에 따르면, 시스템(100)은 분산 시스템을 포함한다. 즉, 사용자는 하나 이상의 물리적 머신(즉, 호스트) 상에서 시스템(100)을 구성하는 시스템 요소를 구동할 수 있으나, 모든 요소는 하나의 애플리케이션으로 함께 구동된다.
노드는 호스트에서 구동되고 하나 이상의 서비스를 지원하는 물리적 프로세스이다. 각 노드는 자바 가상 머신(JVM)이며 운영 체제에 의해 javaw.exe 프로세스로서 인식된다. 사용자는 자신이 통합하기를 원하는 기업 애플리케이션을 구동하는 각 호스트에 대해 적어도 하나의 노드를 만들어야 한다. 사용자는 자신의 사업 요건이 지시하는 만큼의 많은 노드를 가질 수 있다.
시스템(100)에는 2개의 주 인터페이스, 즉 (1) 워크벤치 및 (2) 관리 콘솔(160)이 있다. 워크벤치(120)는 통합 흐름(540)을 생성하고 수정하기 위한 도구를 제공하며, 관리 콘솔(160)은 시스템 노드 및 서비스를 관리하기 위한 모든 도구를 제공한다. 이들은 후에 상세히 설명된다.
본 발명에 따른 통합 흐름(540)의 생성은 다음과 같이 이루어질 수 있다. 사용자는 먼저 시스템(100)으로부터 에이전트 서비스를 얻어야 한다. 사용자는 이어서 관리 콘솔(160) 상에서, 사용자가 통합하기를 원하는 애플리케이션을 실행하는 각 호스트 머신의 시스템 노드를 구성한다. 이어서, 사용자는 자신이 통합하려고 하는 각 애플리케이션에 대한 에이전트 서비스를 포함하는 노드 상에서의 요구 서비스를 구성한다.
통합 흐름을 계획하기 위하여 사용자는 다음의 요소를 결정해야 한다. 예컨대, 사용자는 자신이 애플리케이션으로부터 추출해야 하는 데이터의 종류를 결정하여 애플리케이션에 전송하여야 한다. 또한, 사용자는 (1) 자신이 시스템 오브젝트들 사이에서 메시지를 어떻게 루팅하기를 원하는가, (2) 자신이 하나의 애플리케이션으로부터의 데이터를 어떻게 변형하여 이 데이터가 다른 애플리케이션에서 사용될 수 있도록 할 것인지, 그리고 (3) 자신이 흐름으로부터 소정의 데이터를 필터링하는 것이 필요한지의 여부를 고려해야 한다.
워크벤치(120)에서 사용자는 먼저 프로젝트를 생성한 다음, 다음과 같은 방식으로 통합 흐름을 생성해야 한다. 먼저, 사용자는 사용자 애플리케이션과 대화하기 위한 어댑터(220)를 구성하고 사용자가 통합 흐름(540)에서 적당한 메시지를 생성해야 한다는 메시지 정의(512)를 생성해야 한다. 이어서, 이러한 메시지 정의(512)는 적당한 메시지를 생성한다는 것을 보장할 수 있도록 검사되어야 한다.
그 다음, 사용자는 어댑터(220) 및 트랜스포머(518)로부터의 메시지를 유지하기 위한 허브(518)를 생성해야 한다. 그러면, 사용자는 소스 애플리케이션(541)으로부터의 메시지를 타겟 애플리케이션(549)에 대한 메시지로 변환하기 위한 맵핑 정의(514)를 생성할 수 있다. 또한, 사용자는 샘플 입력 메시지(920,940)를 생성하여 이들을 각 맵핑 정의(514)를 검사하는 데 사용함으로써 맵핑 정의가 적당한 출력 메시지(960,980)를 생성한다는 것을 보장할 수 있다.
그 다음, 사용자는 맵핑 정의(514)를 구현하는 데 필요한 트랜스포머(520)를 생성해야 한다. 필요에 따라, 어댑터(220), 트랜스포머(520) 및 허브(626)는 링크되어야 한다. 사용자가 흐름(540)으로부터 소정의 데이터를 필터링하는 것이 필요한 경우, 사용자는 필터 정의(516)를 생성해야 한다. 이어서, 샘플 메시지를 바람직하게 사용하여 사용자는 필터 정의가 적당한 데이터를 필터링한다는 것을 보장할 수 있도록 필터 정의(516)를 검사해야 한다. 그러면, 사용자는 필터 정의(516)를 오브젝트들간의 링크에 할당할 수 있다.
이어서, 사용자는 워크벤치(120)에서 통합 흐름(540)의 유효성을 검사하고 필요에 따라 이를 수정해야 한다. 그러면, 사용자는 프로젝트를 저장하고 종료할 수 있다. 이어서, 사용자는 관리 콘솔(160)에서 사용자가 시스템 액티비티 상의 메시지를 볼 수 있도록 로그 뷰어를 구성해야 한다. 사용자가 시스템 액티비티 상의 통계(예컨대 개별 트랜스포머에 의해 특정 시간 간격으로 생성된 메시지의 수)를 보기를 원하는 경우, 사용자는 통계 뷰어를 구성해야 한다.
또한, 사용자는 관리 콘솔(160)에서 사용자가 통합하려고 하는 애플리케이션에 대한 에이전트 서비스를 포함하는 관련 노드 및 서비스를 시작함으로써 통합 흐름을 시작할 수 있다. 그 다음, 사용자는 통합 흐름(540)이 적절히 실행되는 것을 보장할 수 있도록 로그 및 통계를 검사한다. 사용자가 통합 흐름(540)을 변경시킬 필요가 있는 경우, 사용자는 관리 콘솔(160) 상에서 관련 서비스를 중지하고 워크벤치(120) 상에서 통합 흐름(540)을 수정한 후 관리 콘솔(160) 상에서 서비스플 재개해야 한다.
아래에서 본 발명에 따라 소스 어댑터 마법사(wizard), 타겟 어댑터 마법사 및 응답 어댑터 마법사와 함께 사용되어 어댑터(22)를 적당히 구성할 수 있는 절차가 설명된다. 일반적으로, 4개의 개별 프로세스가 있다.
첫째, 사용자는 다음과 같은 일반 단계, 즉 (1) 어댑터(200)의 명칭을 정하는 단계, (2) 사용자 어댑터(220)에게 제공하기를 원하는 에이전트 서비스를 선택하는 단계, 및 (3) 어댑터(220)가 생성하고 수신하고 또는 응답하려고 하는 메시지에 대한 메시지 정의(512)를 선택하는 단계를 수행해야 한다. 둘째, 사용자는 다음과 같은 일반 단계, 즉 (1)구성될 특정 어댑터(220)(즉, 표준형 또는 주문형)를 선택하는 단계, (2) 접속 정보를 제공하는 단계, 및 (3) 구현 정보를 제공하는 단계를 수행해야 한다. 종종, 구현 정보를 제공하는 단계는 당해 어댑터(220)의 메시지 정의(512)를 추출하는 단계를 포함한다.
제3 프로세스는 생성될 어댑터(220)의 유형에 종속된다. 사용자가 소스 어댑터(222)를 생성하고 있는 경우, 사용자는 어댑터를 사용하여 메시지를 전송할 타겟을 지정해야 한다. 반면, 사용자가 타겟 어댑터(224)를 생성하고 있는 경우, 사용자는 어댑터(224)를 사용하여 메시지를 수신할 소스를 지정해야 한다. 사용자가 응답 어댑터(226)를 생성하고 있는 경우에는 사용자는 어댑터(226)를 사용하여 응답 메시지를 전송할 요구자(즉, 트랜스포머(520))를 지정해야 한다.
사용자는 최종적으로 어댑터의 메시지에 대한 전송 옵션(예컨대 메시지 수명)을 지정해야 한다. 그러나, 사용자가 어댑터(220)를 생성할 수 있기 전에, 어댑터에게 서비스되는 에이전트 서비스는 관리 콘솔(160) 상에 존재해야 한다. 예컨대, 사용자는 EntireX Broker 어댑터를 생성할 수 있기 전에, EntireX Broker에 대한 에이전트 서비스가 존재해야 한다. 사용자가 어댑터 마법사를 이용하여 어댑터(220)에 대한 소스, 타겟 또는 요구자 오브젝트도 지정하기를 원하는 경우, 이러한 오브젝트들은 사용자가 어댑터 마법사를 열기 전에 존재해야 한다.
도 4a 및 4b를 참조하면, 에이전트 어댑터(200)는 일측에서 애플리케이션 자원과, 타측에서 시스템(100)의 하부구조와 인터페이스한다. 한편, 각 에이전트 어댑터(200)의 어댑터 절반은 자신의 특정 애플리케이션 자원의 API 또는 임의의 다른 공지된 인터페이스 기구를 사용한다. 반면, 에이전트 측은 후술되는 바와 같이 시스템(100)의 이벤트 및 메시징 모델에 따른다. 종합적으로, 에이전트 및 어댑터는 인터페이스 프로토콜 및 데이터 구조의 차이를 조정하여 자신들이 공표하고 사용한 사업 이벤트의 균일하고 정규화된 관찰을 제공한다.
다른 애플리케이션 통합 솔루션과 달리, 확장형 어댑터 아키텍쳐 설계는 애플리케이션 인터페이스의 변화에 무난히 적응하는 능력을 제공하면서도 기존의 기본 인터페이스 세트를 지원한다. 이것은 이미 생산되고 있는 시스템에서 특히 중요하다. 예컨대, 패키지화된 애플리케이션은 특정 버전의 에이전트 어댑터(200)에 의해 지원되는 기본 인터페이스 세트 A'를 갖는다. 더 새로운 애플리케이션 버전이 더 새로운 인터페이스 세트 A'를 구비할 경우, 사용자는 새로운 인터페이스를 검사하기 위하여 예비 생산 환경에 대해 A''에 적응하면서 생산 환경에 대해 종래의 인터페이스 A'에 동시에 적응하도록 선택할 수 있다. 이러한 용이성에 의해 통합 환경으로의 증가적인 변화가 무난히 타개될 수 있다.
시스템(100)의 모든 요소는 모든 지원 플랫폼에 대해 분산될 수 있다. 에이전트 어댑터(200)는 이것을 관련 애플리케이션에 유연하게 확장시킨다. 따라서, 시스템(100)의 주 요소(예컨대 에이전트 어댑터(200) 또는 통합 서버(26))는 애플리케이션과 접속되거나 원격으로 접속되거나, 또는 이들 둘 다 될 수 있다. 많은 확장 구성이 가능하며, 환경은 유효성, 성능 및 관리 요건을 조절할 수 있도록 최적화된다.
SAP, MQSeries, ENTIRE Broker, RDBMS ＆ CICS를 포함한 많은 표준 어댑터(200)가 시스템(100)에 제공된다. 어댑터(200)는 정보 자원의 빠른 확장 및 용이한 통합을 지원한다. 이들은 또한 필요한 트레이닝 및 스킬을 줄인다. 자동화 마법사 템플릿들 모두를 포함하는 ADK(130)는 높은 생산성을 제공한다. 이것은 임의의 사용자 IDE에 적응할 수 있으며, 제공된 어댑터를 개별화(customizing)하는 것과 고객 인터페이스를 개발하는 것을 용이하게 한다. 어댑터(200)는 C++, 자바, EJB, COBRA, COM 및 자연어를 포함하는 대중 언어 및 인터페이스 결합으로 구성된다. 이러한 방식으로 이들 어댑터는 임의의 사용자 환경 및 도구에 플러그된다. 이들은 사내 언어 평가에 대한 레버리지를 제공하며 복잡한 자원 인터페이스 요건에 적응할 수 있다. 따라서, 본 발명에 따른 에이전트 어댑터 아키텍쳐는 훨씬 더 많은 간단한 인터페이스를 지원하는 강건한 장치를 제공한다. 이 아키텍처는 자원 포트폴리오에서의 균일한 이벤트를 보장한다.
에이전트 어댑터 서브시스템은 외부 애플리케이션을 EAI에 접속시키는 실행시간 인터페이스 모듈을 포함한다. 어댑터 측에서 볼 때, 이 서브 시스템은 외부 애플리케이션에 대한 물리 인터페이스이다. 에이전트 측은 어댑터에 대한 호스트로서 작용하며, 자원을 관리하고 어댑터 대신 이벤트를 공표한다.
시스템(100) 내의 베이스 어댑터 클래스는 다음과 같다. "어댑터 메인" 클래스는 어댑터에게 스스로 개시하고 그 구성 정의를 처리하는 능력을 제공한다. 또한, 이것은 4개의 가능한 유형의 어댑터 통신에 의해 사용될 클래스를 예시한다. "어댑터 수신기" 클래스는 어댑터에게 EAI로부터 문서를 수신하고 이것을 제3 당사자 패키지에 전송하는 능력을 제공한다. "어댑터 송신기" 클래스는 어댑터에게 제3 당사자 패키지로부터 문서를 수신하고 이것을 EAI로 전송하도록 하는 능력을 제공한다. "어댑터 응답기" 클래스는 어댑터에게 EAI로부터 문서를 수신하고 이것을 제3 당사자 패키지로 전송하며, 제3 당사자 패키지로부터 응답을 수신하고 처리를 위해 이 응답을 EAI로 복귀시키는 능력을 제공한다. "어댑터 요구자" 클래스는 어댑터에게 제3 당사자 패키지로부터 문서를 수신하고 처리를 위해 이 문서를 EAI로 전송하며, EAI로부터 응답을 수신하여 이 응답을 제3 당사자 패키지로 복귀시키는 능력을 제공한다.
본 발명에 따른 EAI 에이전트-어탭터 인터페이스는 수개의 자바 인터페이스를 실행하는 어댑터에 의해 실현되는 한편, 에이전트 인터페이스에 대한 어댑터는 노드/에이전트 요소의 공지된 방법을 사용하는 어댑터에 의해 실현된다.
본 발명의 다른 중요한 양태에 따르면, 모든 어댑터는 다음의 인터페이스를 실행해야 한다. 어댑터브리지(AdapterBridge)로서, 상기 방법은 초기 상태 설정 동안 에이전트에 의해 initialize(Agent-adapterConfig)되고 어댑터에 의해 부트스트랩 자체로서 사용된다. 어댑터 브리지는 어댑터(220, 220', 220'')가 에이전트(210)에 어떤 도규먼트 정의가 처리될 것인지 및 각 도큐먼트에 대해 어떤 타입의 처리를 제공할 것인지를 질문하여야 한다. 이것은 다음과 같은 에이전트 방법을 사용함으로써 달성된다.
GetSendDocumentDefinitions()
getReceiveDocumentDefinitions()
getRequestDocumentDefinitions()
getResponseDocumentDefinitions()
그런 다음 상기 방법은 AdaptorConfiguration 도큐먼트를 분석하여특정 도큐먼트 정의에 관계하는 서브섹션을 위치지정하고, 도큐먼트 특정 구성 정보를 보호하고, 처리 타입 (송신, 수신, 요청 또는 응답)에 기초하여 특정 클래스의 예를 생성한다. 이어서, Thread (송신 또는 요청 타입)을 개시하고, Agent.setReceiveListener()(수신 타입)을 발행하거나 또는 Agent.setResponseListener()(응답 타입)을 발행하여 메시지가 도달하면 발생될 에이전트 콜백을 등록한다.
restart() 방법은 에이전트(220, 220', 220'')에 의해 발생되어 어댑터(210)로 하여금 모든 동작의 종료, 구성 데이타의 재로드 및 재기동시키게 한다. shutdown() 방법은 종료 처리 동안 에이전트(220, 220', 220'')에 의해 발생된다.
이하에서 설명되는 다음의 인터페이스는 어댑터(220)에 의해 실현된다. ReceiveListener 인터페이스로서, JMS 메시지를 수신하면 에이전트(210)에 의해 onReceiveMessage(ReceiveData) 방법이 발생되고, 이 에이전트는 처리시 도규먼트를 어댑터로 통과시킬 것이다. 이러한 처리는 JMS 세션 스레드의 제어하에 발생할 것이다. 상기 어댑터 처리는 기본적으로 애플리케이션에 의해 제공된 인터페이스를 사용하여 제3부 소프트웨어 애플리케이션으로의 일방향 도큐먼트 루팅으로 구성된다. 그러나, 이러한 타입의 콜에서 예상되는 응답은 없음을 주지하기 바란다. 어댑터(220, 220', 220'')는 애플리케이션으로부터의 성공 또는 실패의 응답을 기대할 것이다. EAI가 제3부 시스템으로부터 실제 응답을 기대한다면, 그 대신 ResponseListener 인터페이스가 사용되어야 한다.
SendListener 인터페이스로서, 어댑터(220, 220', 220'')가 노드/에이전트의 타이머 특성을 사용한다면 에이전트(210)에 의해 onSendTimerEvent(SendData) 방법이 발생된다. 이러한 특성은 제3부 인터페이스가 처리시 EAI로 송신될 도큐먼트에 대한 이벤트 구동된 통지를 실현하는 방법이 없을 경우 유용하다.
RequestListener 인터페이스로서, 어댑터(220, 220', 220'')가 노드/에이전트의 타이머 특성을 사용한다면 에이전트(210)에 의해 onRequestTimerEvent(RequestData) 방법이 발생된다. 이러한 특성은 제3부 인터페이스가 처리시 EAI로 송신될 도큐먼트에 대한 이벤트 구동된 통지를 실현하는 방법이 없을 경우 유용하다. 그러나 이 때, RequestListner 인터페이스는 도규먼트를 EAI에 송신하고 응답시 도큐먼트를 대기한다는 점에서 SendListner 인터페이스와는 다름을 주지하기 바란다.
ResponseListner 인터페이스로서, JMS 메시지 수신시 에이전트(210)에 의해 onResonseMessage(ResponseData)가 발생하고, 에이전트(210)는 처리시 이 도큐먼트를 어댑터(220, 220', 220'')로 통과시킬 것이다. 이러한 처리는 JMS 세션의 제어하에 발생할 것이다. 어댑터 처리는 애플리케이션에 의해 제공된 인터페이스를 사용하여 제3부 소프트웨어 애플리케이션으로의 도큐먼트를 루팅시킨 다음 추가의 처리를 위해 시스템(100)으로 응답을 반송하는 것으로 이루어진다. 그러나, 만약 시스템(100)이 제3부 시스템으로부터 실제 응답을 기대하지 않는다면 ReceiveListner 인터페이스가 대신 사용되어야 한다.
사용자가 시스템(100)을 인스톨하면, 사용자가 인스톨하는 주요 요소는 도 12에 도시된 바와 같이 노드 매니저(1210)이다. 노드 매니저(1210)는 자바 가상 머신(JVM)이고, 다른 모든 노드에 서비스를 제공하고 사용자가 시스템을 인스톨하는 것을 서비스한다. 시스템 인스톨레이션은 저장 서비스(1220), 사용자 인터페이스 서비스(UIS)(1230), 및 노드 매니저(1210)를 호스트하는 머신에 대한 모니터 서비스(1240)를 자동적으로 생성한다.
사용자가 클라이언트(1205) (예를 들어, 관리 콘솔(160) 또는 통합 워크벤치(integration workbench)(120)) 세션을 개시하기 전에 사용자는 노드 매니저(1210)를 개시해야 한다. 상기에서 지적한 바와 같이, 노드 매니저(1210)는 저장 서비스(1220) 및 UIS(1240)를 자동적으로 개시한다. 그 반대로, 이러한 서비스가 실행되지 않는 한 사용자는 관리 콘솔(160) 또는 통합 워크벤치(120)를 사용할 수 없다. 사용자가 실행하는 특정한 관리 콘솔(160) 또는 통합 워크벤치(120) 태스크에 따라 다른 서비스를 필요로 할 수도 있다.
일단 노드 매니저(1210)가 움직이면, 사용자는 사용자가 통합하기를 원하는 애플리케이션에 대한 에이전트 서비스(1250)를 포함하여 시스템 노드와 서비스를 구성해야 한다. 사용자는 우선 관리 콘솔(160) 세션을 사용하여 이를 개시한다. 사용자는 통합 워크벤치(120) 세션을 개시한 다음 도 5c에 도시된 바와 같이 통합 흐름(540) 설계를 개시할 수 있다. 사용자가 이러한 통합 흐름(540) 설계를 완료한 다음에는 관리 콘솔(160) 세션으로부터 노드와 서비스를 개시함으로써 통합 흐름를 개시할 수 있다.
사용자가 클라이언트 세션을 개시하면, 사용자는 노드 매니저(1210)를 클라이언트 서버(1215)로서 식별한다. 사용자는 사용자의 비즈니즈 요건이 요구하는 대로 많은 통합 워크벤치(120)와 관리 콘솔(160) 세션을 노드 매니저(1250)에 접속할 수 있다. 이러한 모든 통합 워크벤치(120)와 관리 콘솔(160) 세션은 판독 전용일 것이다. 노드 매니저(1250)에 접속된 콘솔 세션은 노드 매니저(1210)에서 행해지는 저장 서비스(520)의 내용을 액세스한다. 시스템(100)을 동작시키면, 사용자는 노드 매니저(1210), 관리 콘솔(160) 세션, 및 통합 워크벤치(120) 세션을 가동해야만 한다.
노드
상술한 내용과, 도 12와 연관된 도 13a 내지 13c를 참조하면, 노드(1310)는 호스트(1300)에서 행해지는 물리적 프로세스로 하나 이상의 서비스를 지원한다. 각 노드(1310)는 자바 가상 머신(JVM)이고, javaw.exe 프로세스와 같은 동작 시스템에 의해 인식된다. 사용자는 각 호스트(130)에 대해 적어도 하나의 노드(1310)를 생성하여 사용자가 통합하기를 원하는 기업 애플리케이션을 실행해야 한다. 사용자는 사용자의 비즈니스 요건이 지시하는 만큼 많은 노드(1310)를 가질 수 있다.
서비스는 프로덕트를 기능적으로 제공하는 것이 목적이다. 시스템(100)은 일반적으로 시스템 서비스와 애플리케이션 서비스를 포함한다. 통합 워크벤치(120) 및 관리 콘솔(160) 등의 클라이언트 그래픽 사용자 인터페이스(GUI)는 사용자로 하여금 시스템(100)을 동작시킬 수 있게 한다. 클라이언트(도 12의 1250)는 노드(1310) 및 서비스가 동일한 물리적 호스트(1300)에서 실행되게 하거나 또는 다른 호스트(1200)에서 실행될 수 있게 한다.
또한, 각 기업는 노드 매니저(1210)를 가져야 한다. 노드 매니저(1210)는 시스템(100)에서 다른 모든 모드(1310)에 서비스를 제공한다. 사용자 인터페이스 서비스(UIS)와 저장 서비스(1220)를 실행한다. 도 13a는 3개 호스트(1300)를 갖는 하나의 환경을 설명한다. 호스트1은 노드 매니저(1210)를 움직이게 하는 한편, 호스트1 및 호스트2 둘다는 노드(1310)를 움직이게 한다.
시스템(100)은 시스템 서비스 및 애플리케이션 서비스를 수집한 것이다. 시스템 서비스는 노드 및 서비스를 지원한다. 예를 들어, 모니터 서비스(1240)는 노드(1310)에 대한 시스템 런타임 데이타 및 서비스를 저장한다. 애플리케이션 서비스는 시스템(100)에 대한 기능을 제공한다. 예를 들어, CICS 에이전트 서비스는 CICS 애플리케이션을 접속하게 위해 필요한 어댑터를 지원한다.
시스템 서비스
본 발명에 따른 시스템 서비스는 일반적으로 사용자 인터페이스 서비스(UIS)(1230), 리포지터리 서비스(1220), 및 모니터 서비스(1240)를 포함한다. USI(1230)는 더 구체적으로 클라이언트 성분[즉, 통합 워크 벤치(120) 및 운영 관리 콘솔(160)]를 실행하는데 필요한 설비를 제공한다. 이와 같이, 리포지터리 서비스(1220)는 모든 구성된 서비스와 통합 플로우 오브젝트(540)에 대한 구성을 저장한다. 마침내, 모니터 서비스(1240)는 시스템 런타임 데이터를 저장하는데, 시스템 로그와 통계 정보를 포함한다.
애플리케이션 서비스
다시 도 12를 참조하여, 시스템(100)에서 사용된 애플리케이션 서비스는 기업 메시징 서비스(EMS)(1260)를 포함하는데, 이는 시스템(100)이 멀티플 메시징 모드를 사용할 수 있게 하고 포인트-투-포인트, 발행/가입, 및 리퀘스트/리플라이 메시징을 포함한다는 것이 자명하다. 또한, EMS(1260)는 메시지 허브(hub)를 지원하여, 메시지 잔상을 제공한다. 또한, 애플리케이션 서비스는 통합 서비스(IS)(1270)를 포함하는데, 이는 시스템(100)이 메시지를 변형할 수 있고, 스플리팅 메시지, 결합 메시지, 및 조작 메시지 데이터를 포함한다. IS(1270)도 또한 트랜스포머를 지원한다. RMI 팩토리 서비스(도시되지 않음)를 애플리케이션 서비스로서 선택적으로 사용하여, 원격 방법 발동(remote method invocation : RMI) 링크를 외부 애플리케이션으로 관리한다. 라우팅 서비스(1280)도 또한 애플리케이션 서비스를 포함하는데, 이는 시스템(100)이 메시지의 컨탠트에 기초하여 시스템을 통해 메시지로 향하게 하고, 사용자 정의의 기준에 따른 필터링 메시지 컨탠트를 포함하고, 메시지가 유효한지를 판정한다. 라우팅 서비스(1280)도 또한 필터를 지원한다. 에이젼트 서비스(1250)는 어댑터를 지원한다. 사용자가 통합하기 원하는 기업용 애플리케이션을 실행하는 각 호스트(600) 상에서 사용자는 에이젼트 서비스를 인스톨해야 한다. 도 13(b)에 도시된 바와 같이, 호스트(1, 2)는 모두 서비스를 실행한다. 호스트(3)는 노드(1310)를 가지지 않으므로, 서비스를 실행하지 못한다.
클라이언트
시스템(100)은 사용자가 통합 플로우(540)와 함께 동작할 수 있게 하는 2 개의 클라이언트 GUI를 포함한다. 클라이언트는 호스트(1300)가 노드 매니저(1210)를 실행하는지, 노드(1310)와 서비스를 실행하는지, 또는 어떠한 노드(1310)와 서비스도 실행하지 않는지에 관계없이, 어떠한 호스트(1300)도 실행할 수 있다. 사용자는 사용자의 비즈니스 요구 조건 규정 만큼 많은 클라이언트를 인스톨할 수 있다. 예를 들면, 사용자는 네트워크-부착된 호스트 상에서 클라이언트(1205)를 인스톨하여, 원격 위치로부터의 사용자의 통합 플로우(540)와 함께 동작할 수 있기를 원한다. 도 13(c)에 도시된 바와 같이, 호스트(2, 3) 모두는 운영 관리 콘솔(160)과 통합 워크 벤치(120) 클라이언트를 실행한다. 반면에, 호스트(1)는 운영 관리 콘솔(160) 또는 통합 워크 벤치(120) 클라이언트를 전혀 실행하지 않는다.
시스템(100) 내에 2 개의 제1 인터페이스가 존재한다: (1)워크 벤치(120) 및 운영 관리 콘솔(160). 워크 벤치(120)는 통합 플로우(700)를 생성하여 변형하기 위한 툴을 제공하고, 운영 관리 콘솔(160)은 시스템 노드와 서비스를 관리하기 위한 모든 툴을 제공한다. 이하, 두가지 모두 상세히 설명된다.
본 발명에 따라 통합 플로우(700)를 생성하는 것은 다음과 같이 이루어질 수 있다. 사용자는 먼저 시스템(100)으로부터 에이전트 서비스를 얻어야 한다. 운영 관리 콘솔(160) 상에서, 사용자는 사용자가 통합하기를 원하는 애플리케이션이 실행되는 각각의 호스트 머신의 시스템 노드를 구성한다. 다음, 사용자는 노드 상에서 요청된 서비스를 구성하는데, 사용자가 통합할 각 애플리케이션에 대한 에이젼트 서비스를 포함한다.
통합 플로우를 계획하기 위해, 사용자는 다음 요인을 결정해야 한다. 예를 들면, 사용자는 사용자가 애플리케이션으로부터 감산하고 애플리케이션으로 전달해야 하는 데이터의 종류를 결정해야 한다. 또한, 사용자는 다음을 고려해야 한다 : (1)사용자가 시스템 오브젝트 중에서 어떻게 메시지를 라우트하기 원하는지; (2)다른 애플리케이션에 의해 사용될 수 있도록 사용자가 어떻게 하나의 애플리케이션으로부터 데이터를 변형하기 원하는지; (3) 사용자가 플로우로부터 임의의 데이터를 필터하기 원하는지의 여부.
변환 프로세스-억세서 및 컨버터
상술된 바와 같이, 메시지 모델의 다른 중요한 기능은 임의의 애플리케이션으로부터의 원파일 포맷으로부터 수입/수출하는 것이다. 애플리케이션과 플랫폼-특정 포맷에서 문자와 2진 데이터를 모두 포함하는 파일은 상술된 바와 같이 "정전(canonical)" 형태를 따르는데, 여기서 데이터는 자바 오브젝트로서 표현된다. 이러한 스킴의 설계시 가장 중요한 목표는 재사용을 최대화하는 것이다. 따라서, 주어진 메시지 정의는 개념적인 "디바이스 드라이버"와 함께 통상적으로 구성될 수 있다. 즉, 구조적으로 동일한 데이터 포맷을 나타내는 2개의 원파일 포맷은 적절한 드라이버로 구성될 때 동일한 구조의 정전 메시지를 발생시킬 수 있다. "디바이스 드라이버"는 실제적으로 "억세서"와 "컨버터"로 불리는 자바 오브젝트 세트로서, 메시지 정의 메타데이터 및 글로벌 메타데이터에서 적절한 노드에 부착된다.
자바 오브젝트 직렬화를 통해 지속되는 완전히 구성된 메시지 정의가 패키지되고, 바로 갈 수 있는(ready-to-go) 원파일 포맷 분석 및 주어진 원파일 포맷 변환 프로세스에 대한 포맷터는, 최근 문자 세트 인코딩 및 자바 디벨롭먼트 키트(JDK)에 의해 제공된 한정 설비를 이용한다. 모든 원래의 스트링은 바이트 어레이로서 관찰되고, 루틴을 분석 및 포맷팅하여 사용하기 위한 유니코드로 내부적으로 변환된다.
JDK의 버전 1.1.6이 거의 100 가지의 상이한 문자 인코딩을 지원하므로, 본 발명에 따른 메시지 모델은 동일한 로직으로 모두를 취급한다는 것에 유의해야 한다. 또한, 메시지 모델은 아이템의 상속 특성을 가능한 한 많이 사용하려고 노력한다. 따라서, 애플리케이션 특정 데이터가 디폴트 바이트-오더, 인코딩 및 로케일을 가지고 있다고 추정할 수 있다. 개별적인 억세서는 이들을 완충할 수 있으나, 실제적으로 거의 일어나지 않는다.
억세서 및 컨버터는 2-방향 오브젝트이다. 이들은 원데이터를 메시지 트리에 저장될 자바 오브젝트로 변환하고, 자바 오브젝트를 다시 원표현으로 변경할 수 있다. 재사용의 측면에서, 본 발명의 하나의 목적은 기록되어야 하는 총 변환 클래스의 수를 최소화하는 것이다. 따라서, 상술된 변환 프로세스는 2가지 주된 문제를 가지는데, 하나는 표시/포맷팅이고, 다른 하나는 바이트 변환이다. 억세서 클래스의 예증으로서, 원 분야에서 "신텍스 슈거"를 통해 선별되어, 특정 컨버터에서 필요한 실제적인 바이트를 분리하여 자바 오브젝트로부터 발생하거나 변환하는 방법을 아는 자바 오브젝트가 있다.
예를 들어, 부동 소수점 데이터 필드가 기정의 바이트 또는 문자 시퀀스에 의해 양측에 마크되는(mark) 경우를 고려하면. 이것들은 시스템(100) 내에서 "마커(marker)"로서 알려져 있다. 특정 종류의 액세서(accessor)(본 경우에는 트레일링 마커 액세서(trailing marker accessor))는 부동 소수점 데이터의 실질적인 "본체(meat)"인 4개의 바이트들을 격리시키기 위해 리딩 마커(leading marker)를 건너뛰고 트레일링 마커의 위치를 찾을 수 있다. 이전에 메시지 정의에서 형성된 부동 소수점 데이터 바이트 컨버터는 상기 바이트들로부터 자바 플로트 오브젝트(java Float object)를 발생시킨다. 다른 방향에서는, 액세서는 리딩 마커를 기록하고, 컨버터가 원래의 바이트들을 기록하도록 명령하고, 다음으로 액세서는 트레일러와 함께 중지한다. 본 구조의 직접적인 장점은 소수의 액세서들 및 대략 2 다스의 변환기들 만이 기록되면 된다는 것이다. 본 발명의 액세서들 및 변환기들은 실질적으로 기형성된 판독 전용 오브젝트들이기 때문에, 메시지 정의 사이즈는 가능한 오브젝트 분배로 인해 상대적으로 작게 유지될 수 있다. 자바 가비지 수집기는 편리하게도 본 경우에 누가 어떤 오브젝트를 가졌는가에 대한 결과를 제거한다.
액세서들 및 변환기들의 일부는 초기 세팅에서 구성될 필요가 있으며, 반면에 나머지는 그럴 필요가 없다. 일들 오브젝트들은 필요한 단순 프로퍼티 다이알로그들을 가지고 자바빈들(JavaBeans)로서 패키지된다. 본 발명의 본 양호한 실시예에 따라, 다음의 표는 시스템(100)을 지원하는 액세서들을 진열한다. 새로운 타입들이 필요함에 따라, 이것들은 새로운 변환기들을 기록할 필요 없이 시스템(100)에 매끄럽게 첨가될 수 있다.
액세서 타입 특성
고정 길이 액세서 필드는 항상 고정 길이이다. 이러한 고정 길
이는 전체 필드 길이, 또는 그 길이에 마커들 중에
어떤 것을 뺀 것 중에 하나라는 것을 표시한다.
표시 길이 데이터 내의 다른 정수-호환 필드가 길이 지정기를
포함한다는 것을 제외하고는, 고정 길이 액세서등
과 실질적으로 동일하다. 이러한 길이 표시기들은
"링크된" 오브젝트들이라고 알려진 것이며, "전이"
오브젝트로서 선택적으로 플래그될 수 있다. 보다
상세한 설명이 이하 후술된다.
트레일링 마커 필드는 트레일링 마커에서 정지한다.
암시 길이 필드 길이는 변환기 타입에 포함된다.
- 대부분 바이너리 포맷을 위해 사용됨
구분 섹션 포함하는 섹션이 구분기 구조를 사용하는 경우, 구
분기는 오브젝트의 끝을 신호할 수 있다.
구문 기초 오브젝트 오브젝트는 정규의 표시들과 정합한다.
상술된 각각의 액세서들은 아이템 액세서들인 것에 주의해야 한다. 하지만, 보다 간단하게, 섹션 액세서들인 유사하게 사용될 수도 있다. 그러한 섹션 액세서들은 선택적인 마커를 갖고 있으며, 구분기 구조를 사용할 수도 있다. 어느 정도까지는, 그러한 구분기 구조를 포함한다는 것은 그 포함된 엘레먼트들의 성공적인 분석에 의존한다. 구분기는 프리픽스, 인픽스, 또는 포스트픽스 구조 중에 하나를 사용하고, 실제로 필드들을 제약하도록 사용된 것과 동일한 마커 엘레먼트들이다. 표 액세서들은 섹션 액세서들이 기록 카운트를 표시하는 링크된 아이템을 가지고 작업하도록 연장한다.
시스템(100)을 지원하는 변환기의 초기 번호는 상대적으로 작지만, 상업적 파일 포맷들의 분석에 기초하여서는 매우 완전하다. 본 발명에 따른 변환기들은 2개의 기본 타입들을 포함하는데, 하나는 문자-기본 변환기이고 다른 것은 이진 변환기이다. 모든 문자 변환기들은 자라맞춤 또는 패딩 문자들의 표시를 제공하는 공통의 베이스 클래스로부터 승계된다. 그러한 패딩 문자들은 절대적 바이트값 문자들 또는 유니코드 문자들로서 표시될 수 있어서, 원래의 코딩으로 맵될 수 있다. 본 발명에 따른 문자 변화기들은 다음을 포함한다.
문자 변환기 타입 특성
소수 자바.텍스트.데시멀.포맷에 명기된 것으로부터 도
출된 "포맷 마스크"에 따라 포맷하고 파스한다.
이 마스크는 #,##0.0## 의 형태이며, 리딩 또는 트
레일링에 사인들(sign)을 뺀것과 같은 성질들을 명
기할 수 있다. 마스크 문법은 어떤 프리- 또는 포
스트-프로세싱이라도 인에이블될 필요가 있으면 연
장될 것이다. 소수 변환기와 같지만, 소수가 위치
되는 것이 허용되지 않는다. 커렌시 역시 자바에
의해 지원됨, 소수 변환기의 더욱 개선된 형태.
일/시 자바.텍스트.심플데이트포멧 마스크 명세를 사용한
다. 이 포맷은 매우 확장적이고, 모든 요구를 만
족시켜야 한다.
총칭 스트링 고정 길이에 의존, 디마케이션에 대한 트레일링 마
커 또는 섹션 구분기.
이진 변환기는 디폴트 메시지-명기 바이트-순서를 승계하지만, 컨스트럭터 아규먼트를 통하여 개별적으로 간과될 수 있다. 그러한 본 발명에 따른 이진 변환기는 다음을 포함한다.
이진 변환기 타입 특성
사인된/언사인된 2 보상 숫자 8, 16, 32, 및 64 비트들. 언사인된 타
입들은 필요하다면 다음의 더 큰 자바 정수 타입으
로 진행된다. 자바는 언사인된 롱들에 대한 자바.
매쓰 내의 임의의 정확도 패키지를 포함한다는 것
을 주의해야 한다.
IEEE 754 플로트 및 JNI은 이것을 위해 사용될 수 있을 뿐만 아니라
더블(1985 명세서) 플로트 및 더블 클래스들에서 제공된 정수비트 및
롱비트를 위해 사용될 수도 있다. 이것은 원래의
플로트 타입의 플랫포옴들 상에서만 지원될 수 있
다는 것을 주의해야 한다.
변환기들은 하나 이상의 자바 타이들을 발생시키거나 소비할 수 있다. 예를 들어, 원래의 플로트 변환기는 다른 여러 가지 중에, 플로트, 더블, 정수, 롱 또는 스트링으로 적당하게 맵할 수 있다. 모든 변환기들은 "오브젝트 로드(클래스, ...)" 및 "보이드 저장(Object ...)"를 기능적으로 명기하는 원래의 변환기 인터페이스를 이행한다. 그러나, 다른 변환기 인터페이스가 어떤 것인가에 따라 발생된 실재의 서브클래스는 오브젝트에 의해 실행된다. 이것들은 실질적으로는 마커 인터페이스들이고, 어떠한 새로운 방법들에도 기여하지 않는다. 예를 들어, 더블변환기, 정수변환기, 스트링변환기, 등등이 본 발명의 진정한 정신 및 범위를 벗어남이 없이 시스템(100)에 사용될 수 있다. 그래픽 사용자 인터페이스(GUI) 같은 구성 툴은 클래스 인트로스펙션을 통하여, 특정의 경우에 사용하기 위해 현재의 변환기의 적합한 리스트를 결정한다. 로드 및 저장 방법들 내에는, 변환기는 상응하는 클래스로 이행하는 그 지원된 인터페이스들 중에 오브젝트는 "인스턴스오브"인가 또는 공급된 클래스인가를 시험한다. 복귀되거나 처리된 총칭 오브젝트는 이제 실제로 적합한 서브타입이다.
마커들
마커들은 필드 구분기 및 개별적인 아이템 토큰으로서 유용한 구문 슈가로서 간주될 수 있다. 모든 오브젝트들은, 섹션이건 아이템이건 간에, 리딩 마커, 트레일링 마서, 또는 양자 모두를 포함할 수 있다.
본 발명의 양호한 실시예에 따르면, 기본적인 세 가지 마커 포맷이 있다. 고정 패턴 마커 및 "strtok" 스타일 마커로 알려진 두 가지 포맷은 네이티브 문자 엔코딩으로 맵핑되는 바이트 패턴 또는 유니코드 스트링을 지정한다. 0 또는 그 이상의 문자가 있는 문자 세트에서 "strtok" 스타일 마커는 빈 공간 또는 바이너리 패딩을 가리키는데 유용하다. 제3의 포맷인 키-베이스 마커는 처리되는 오브젝트의 키가 패턴으로 대체되는 패턴을 갖는다. 예를 들어, 마커 쌍 〈X-〉 및 〈/-X-〉는 〈Customers〉 및 〈/Customers〉 로 되므로, XML 스타일 메시지를 파싱하는데 유용하며, 일반적으로 선택적 아이템의 위치 설정에 도움을 준다.
선택적 독립변수
선택적 독립변수의 파싱 및 인식은 상이한 프로세스이다. 예를 들어, 지정된 입력 데이타가 5개의 임의 길이의 선택적 스트링이고 3개의 스트링이 성공적으로 판독되었다면, 어떤 스트링이 판독된 스트링인지 알 수 없다. 알려지지 않은 선택적 아이템은 메시지에서 널(null)값으로 세트된다. 본 발명에 따른 선택적 아이템이 인식될 수 있는 일련의 조건은 후술되겠다.
한 섹션이 델리미터들을 사용하고 공백 필드를 위한 델리미터가 있는 경우를 고려해 보자. 예를 들어, 입력이 삽입 체계에서 "Able,,Charley"라면, 사용자는 두 번째 요소가 없어졌다고 알게 된다. 필드가 자체 인식용 키-베이스 마커를 사용하면 선택적 아이템이 인식되는 다른 조건이 발생한다. C++ 디폴트 함수 독립변수 스타일에서는, 다른 조건이 발생하는데, 모든 선택적 독립변수가 리스트의 끝에 오고 섹션의 끝이 검출되면, 파싱이 성공적으로 된다. 일반적으로, 사용자가 필드를 정확히 파싱하는데 실패하고 필드가 선택적이라면, 사용자는 다음번 필드로 건너가서 섹션의 끝에 도달할 때까지 다시 시도한다. 여기에는 후미 마커(또는 end-of-file)를 가진 섹션이 요구된다. 섹션의 끝에서, 비-선택적 아이템에 값이 지정되지 않았다면, 파싱은 실패한다. 그러므로, 연속적인 아이템의 포맷이 분명하지 않으면 정확한 결과를 보장할 수 없다.
디폴트는 그것이 섹션이던지 아이템이던지 간에 상이하게 동작한다. 한 아이템을 위한 메시지 메타데이타는 디폴드 오브젝트를 보유한다. 디폴트에 의해, 오브젝트가 모사가능한 인터페이스를 지원하면, 오브젝트는 메타데이타로부터 메시지 단계로 모사된다. 상기 인터페이스를 지원하지 않는다면, 그 값이 메타데이타에 스트링으로서 그 클래스와 함께 기억되며, 자바 리플렉션(Java Reflection) API가 사용되어 오브젝트의 스트링-베이스 콘스트럭터로하여금 메시지에 오브젝트를 제공하게 한다. 섹션을 위하여, 디폴트는 다른 영구 기억된 메시지 정의에 링크된다. 참조된 메시지 정의의 최상위 레벨 섹션은 메시지 메타데이타와 접목되어 조합된 구조의 메시지가 생성된다.
링크된 과도 아이템
어떤 경우, 네이티브 데이타는 자체 설명적이다. 예를 들어, 테이블에는 그의 로우 카운트가 선행할 수 있다. 사용자는 최종적으로 생성된 전형적인 메시지에 상기 카운트를 포함하는 것을 원치 않는데, 그 이유는 테이블을 나타내는 자바 어레이의 길이로부터 알 수 있기 때문이다. 이러한 경우, 노드는 과도적인 것으로 선택적으로 마크될 수 있다. 노드는 일시적으로 메시지에 추가되고, 테이블이 생성되어 추가되면 제거된다. 이러한 방식으로, 사용자는 두 개의 상이한 드라이버가 동일한 전형적인 메시지를 생성하는 메시지 정의를 구성할 수 있다. 만일 어떤 경우 데이블 길이가 카운트 표시자 없이도 결정된다면, 노드에 정수 필드를 생성하지 않는다. 이런 경우 테이블들이 동일 구조로 되므로 독립변수는 과도적인 것이다.
상기한 예에서, 카운트와 테이블 간에는 고유한 접속관계가 있다는 것을 알 것이다. 그 결과, 이들은 링크 관계를 갖는 것으로 마크된다. 이들은 부가적으로, 하기와 같이, 다른 오브젝트의 상대 및 절대 경로명을 보유하고, 또한 그들의 억세서에 상태 표시자를 보유한다.
카운트-제공자
카운트-사용자
길이-제공자
길이-사용자
재정의-제공자
재정의-사용자
재정의(redefine)의 경우, 제공자는 스트링 또는 통합 식별자를 제공한다. 제공자 아이템은, 파싱 방향으로 통과 및 변환중인 그 사용자에 앞서서 나타난다. 포맷팅 방향으로는, 제공자가 먼저 위치 보유자로 기록되고 추후에 적절한 값이 채워진다. 카운트 제공자는 전술한 작업을 위해 고정 길이 포맷을 사용해야 한다.
유효 조항 및 관계
메시지 정의는 유효 조항 및 인터-메시지 관계의 리스트를 위한 메타데이타 아이템내에 위치 보유자를 갖는다. 본 발명의 양호한 실시예에 따르면, 유효 조항은 모두 전체 메시지가 변환된 다음 변환된 메시지상에서 수행된다. 오브젝트 디자인에서는 필요하다면 아이템 마다의 유효 조항이 가능하다. 또한, 한 메시지의 테이블의 컬럼과 다른 메시지의 컬럼간의 관계를 지정하는 위치 보유자도 있다. 이 것은 값과 연결부와의 맵핑을 용이하게 해준다.
미가공 데이타를 변환하여 또는 변환하지 않고 메시지를 생성하는 방법은 도 13 및 도 14에 도시된다. 도 13은 미가공 데이타를 변환하지 않는 방법(1340)을 도시하며 어플리케이션(541)에서 시작한다.
사용자는 (1320)에서 공백 메시지(예컨대, "DocDef.createNewInstance")를 생성하고, 상기 공백 메시지에는 메시지 정의 API(1330)를 통해 어플리케이션의 데이타가 포함된다. 그러므로, 메시지 단계(1340)가 생성된다. 메시지 단계(1340)는 다른 어플리케이션의 메시지 정의 API(1350)를 통해 메시지를 해당 어플리케이션(1360)으로 보낼 수 있다.
미가공 데이타를 변환시킬 필요가 있는 경우, 도 14에 도시된 방법이 사용된다. 먼저 어플리케이션 지정 데이타(1410)가 어플리케이션(1420)으로부터 수신된다. 공백 메시지는 (1430)에서 생성되며, 상기 어플리케이션 지정 데이타(1410) 뿐만 아니라 미가공 변환 정보를 포함한다. 어플리케이션 지정 데이타(1410)는 억세서 및 변환기(1440)에 의해 메시지 단계(1450)로 보내지며, 메시지 단계(1450)는 (1430)에서 공백 문서에 포함된 정보도 수신한다. 예를 들어, 다음과 같은 것에 의해 수행된다:
DocDef.createDocumentFromFile
API는 하기의 방법을 지원하여 메시지를 생성한다:
DocDef.createDocumentFromFile
DocDef.createDocumentFromBytes
그런 다음, 다른 억세서 및 변환기(1460)를 통해 메시지는 다른 어플리케이션의 어플리케이션 지정 데이타(1470)로 변환되어 해당 어플리케이션(1480)에서 수신된다.
도 15a 내지 15d를 참고하여, 본 발명에 따른 메시지 오브젝트의 장점을 설명하겠다. 도 15a는 본 발명에 따라 미가공 어플리케이션 데이타를 변환하지 않고 메시지를 생성하는 방법(1510)을 보여준다.
제1 스텝으로 어플리케이션(1512)에 의해 공백 메시지가 생성된다. 이는 메시지 정의를 생성하는 것(512)에 의해 이루어진다 (예컨대, "def;//initialize elsewhere def.creatEmptyDocument(docname);"). 어플리케이션 API(1514)은 메시지 정의 API(1516)을 이용하여 메시지를 포함시키기 위해 메시지 정의 API(1516)에 결합된다. 다음으로 메시지 디폴드가 제공되고 (예컨대, "def.applyDocumentDefault값s(docname)"), 메시지 단계(1518)이 생성된다. 어플리케이션 API(1526)에 결합되고 필드 값을 포함시키기 위해 사용되는 메시지 정의 API(1524)를 통해 메시지 단계(1522)가 보내지는 반대의 방법(1520)이 도15b에 도시되어 있다. 메시지는 어플리케이션(1528)으로 보내진다.
어플리케이션 데이타를 변환하여 메시지를 생성하는 방법이 좀 더 어렵다. 도 15c에 도시된 것처럼, 본 발명에 따라 어플리케이션(1532)으롭퉈 메시지 단계(1538)로 메시지를 변환하는 방법(1530)은 변환기를 통해 메시지가 어플리케이션으로부터 보내지는 것에서 시작된다.
메시지 정의 API 1536은 엠프티 메시지를 생성하고, 이 엠프티 메시지를 애플리케이션으로부터의 데이터(즉, 파일 또는 바이트 중 어느 하나)와 함께 실고 (populate), 액세서로부터의 원변환 정보(raw conversion information)를 부가하여 본 발명에 따라 변환한다.
예:
Document Definition def;//Add Accessors and Converters
Initialize elsewhere
def.createDocumentFromFile(docname,filename)
def.createDocumentFromBytes(docname,byte[])
리버스 방법 1540이 도 15(d)에 도시되어 있고, 메시지 예 1542는 메시지 정의 1544를 통해 전송되어, 메시지 예 1532로부터의 데이터와 함께 파일 또는 바이트어레이 1546가 존재하고, 이어서 애플리케이션 1548로 전송된다. 예를들어:
Document Definition def;//Add Accessors and Converters
Initialize elsewhere
def.storeDocumentToFile(filename)
or,
def.storeDocumentToBytes(docname,byte[])
이러한 프로세서와 유사한 클래스 다이어그램이 도 16과 도 17에 도시되어 있다.
본 발명의 또다른 양상에 따르면, 시스템(100)은 분배 시스템을 구비하고 있다. 즉, 사용자는 하나 이상의 물리적 머신(즉, 호스트)상에 시스템(100)을 구성하는 시스템 부품(system components)을 수행시킬 수 있지만, 이들 부품 전부는 애플리케이션으로서 동작한다. 시스템(100)의 매 부품은 모든 지원 플랫폼을 통해 분배가능하다. 에이전트 어댑터(200)는 이것을 참여 어플리케이션(participating application)으로 융통성있게 확장한다. 따라서, 시스템(100)의 키 성분(예를들어, 에이전트 어댑터(200) 또는 통합 서버(integration server;26))은 어플리케이션에 따라 함께 위치하거나 또는 원격으로 액세스되거나 또는 이들 모두가 행해질 수 있다. 수많은 전개 구성(deployment configuration)이 가능하고, 환경은 효용성(availability)과, 실행(performance), 및 운영 요구에 대한 균형을 위해 최적화된다.
연산자(operator)
다음의 표는 현재 고려되고 있는 모든 시스템 연산자에 대한 일반적인 설명이며, 사용자는 메시지 정의, 트랜스포머 정의 및 필터 정의에 대한 표현을 설정할 수 있다. 시스템(100)은 이러한 연산자들을 지원한다.
연산자 설명
＆＆ 논리 "and"
?? 논리 "or"
! 논리 "not"
= 할당(assignment)
== 논리 "equal"
!= 논리 "not equal"
+ 단항셈 플러스(unary plus)
- 단항셈 마이너스(unary minus)
* 승산
/ 나눗셈
〈 미만
〈= 이하
〉 초과
〉= 이상
함수(functions)
다음 페이지에 이어지는 표는 현재 고려되고 있는 모든 시스템 기능에 대한 일반적인 설명이며, 사용자는 메시지를 확인하거나(validating) 또는 필터링하고 메시지 데이터를 변환하기 위한 표현을 설정하는데 사용할 수 있다. 각각의 설명은 기능이 무엇인지, 요구하는 파라미터와, 되돌려지는 값을 포함하고 있다.
메시지 데이터를 변환하는 경우, 사용자는 통상 이러한 기능을 이용하여 입력 메시지로부터 메시지 아이템 값을 취하고, 출력 메시지에 대한 아이템값을 생성한다. 메시지를 확인하거나 필터링하는 경우, 사용자는 통상 불리안 표현을 생성하는데 이러한 기능을 이용한다. 이러한 기능에 대한 파라미터값들은 메시지 아이템 또는 상수 중 어느 하나일 수 있다(즉, 리터럴(literal)).
데이터 유형 리터럴예(Literal Examples)
Integer 1234,0xFF,077,-1234
Long 1234,1234L,-0xFF,077L
Double 12.34
String "Sagavista"
Boolean true or false(참 또는 거짓)
BigDecimal 12.34a,where "a"means arbitrary precision
Calendar #DATE(2000,2,13)
#DATE_TIME(2000,2,13,23,59)
#DATE_FORMAT("m/D/yyy", "2/13/2000")
사용자가 시스템(100)을 사용하는 동안 사용자 자신의 기능을 기록할 수 있다고 하더라도, 시스템(100)은 이하에 설명되는 기능도 제공한다.
함수 설명
addToDate 캘린더의 오브젝트 날짜에 특정회수의 날짜를 부가
하고, 그 결과적인 Calendar 오브젝트 날짜를 되돌
린다.
bigDecimalTo Boolean BigDecimal 오브젝트를 Boolean 오브젝트으로 변환
한다.
bigDecimalToDouble BigDecimal 오브젝트를 Double 오브젝트으로 변환
한다.
bigDecimalToLong BigDecimal 오브젝트를 Long 오브젝트으로 변환한
다.
bigDecimalToString BigDecimal 오브젝트를 String 오브젝트으로 변환
한다.
booleanToBigDecimal Boolean 오브젝트를 BigDecimal 오브젝트으로 변환
한다.
booleanToLong Boolean 오브젝트를 Long 오브젝트으로 변환한다.
booleanToString Boolean 오브젝트를 String 오브젝트으로 변환한
다.
calendarToString Calendar 오브젝트를 String 오브젝트으로 변환한
다.
compareDates 2개의 Calendar 오브젝트 날짜값을 비교하고, 첫
번째 날짜값이 2번째 날짜값에 못미치는지, 동일한
지, 또는 그보다 큰지를 나타낸다.
doubleToBigDecima l Double 오브젝트를 BigDecimal 오브젝트으로 변환
한다.
doubleToLong Double 오브젝트를 Long 오브젝트으로 변환한다.
doubleToStrong Double 오브젝트를 String 오브젝트으로 변환한다.
findString 또다른 String 오브젝트 내의 String 대상을 서치
하고, 다른 String 내의 발견된 String's 제1 문자
의 위치를 되돌려준다.
findWord String 오브젝트내의 워드를 검색하고 String 내의
워드의 제1 문자 위치를 리턴시킨다.
foundString 또 다른 String 오브젝트 내의 String 오브젝트를 검색하고 Boolean 오브젝트를 리턴시킨다.
foundWord String 오브젝트 내의 워드를 검색하고 Boolean 오
브젝트를 리턴시킨다.
getDate Calendar 오브젝트의 데이타를 발견하고 Integer
오브젝트로서 달을 리턴시킨다.
getMonth Calendar 오브젝트의 달을 발견하고 Integer 오브
젝트로서 달을 리턴시킨다.
getYear Calendar 오브젝트의 년을 발견하고 Integer 오브
젝트로서 년을 리턴시킨다.
getTokenAt String 오브젝트를 토큰(tokens)으로 파스(parse)
하고, 특정 토큰을 발견하며, 토큰을 String 오브
젝트로서 리턴시킨다.
integerToString Integer 오브젝트를 String 오브젝트로 변환환다.
isAlpha Sting 오브젝트의 모든 문자가 알파벳인지를 결정
하고 Boolean 오브젝트를 리턴시킨다.
isAlphaNumeric String 오브젝트의 모든 문자가 문자숫자식인지를
결정하고 Boolean 오브젝트를 리턴시킨다.
isNumeric String 오브젝트의 모든 문자가 숫자인지를 결정하
고 Boolean 오브젝트를 리턴시킨다.
justifyCenter 특정 길이의 String 오브젝트를 생성하고 그 안에
또 다른 String 오브젝트를 중심에 둔다.
justifyLeft 특정 길이의 String 오브젝트를 생성하고 그 안에
또 다른 String 오브젝트를 좌로 정렬한다.
justifyRight 특정 길이의 String 오브젝트를 생성하고 그 안에
또 다른 String 오브젝트를 우로 정렬한다.
longToBigDecimal Long 오브젝트를 BigDecimal 오브젝트로 변환한다.
longToBoolean Long 오브젝트를 Boolean 오브젝트로 변환한다.
longToDouble Long 오브젝트를 Double 오브젝트로 변환한다.
longToString Long 오브젝트를 String 오브젝트로 변환한다.
lookup 또 다른 String 오브젝트에 지정된 lookup 테이블
에 String 오브젝트를 룩업한다.
lowercase String 오브젝트의 모든 문자를 lowercase로 변환
한다.
replaceString 특정 String 오브젝트용 String 오브젝트를 검색하
고, 발견된 String 오브젝트를 대체 String 오브젝
트로 대체하고, 대체 String 오브젝트를 갖는
String 오브젝트를 제자리에 리턴시킨다.
replaceWord 특정 워드 오브젝트용 String 오브젝트를 검색하
고, 발견된 워드 오브젝트를 대체 String 오브젝
트로 대체하고, 대체 워드를 갖는 String 오브젝트
를 제자리에 리턴시킨다.
sizeOf String 오브젝트 또는 ByteArray 오브젝트의 크기
를 결정하고 크기를 Long 오브젝트로서 리턴시킨
다.
stringToBigDecimal String 오브젝트를 BigDecimal 오브젝트로 변환시
킨다.
stringToBoolean String 오브젝트를 Boolean 오브젝트로 변환시킨
다.
stringToCalendar String 오브젝트를 Calendar 오브젝트로 변환시
킨다.
stringToDouble String 오브젝트를 Double 오브젝트로 변환시킨다.
stringToInteger String 오브젝트를 Integer 오브젝트로 변환시킨
다.
stringToLong String 오브젝트를 Long 오브젝트로 변환시킨다.
Subarray 또 다른 ByteArray 오브젝트 내의 ByteArray 오브
젝트를 찾고, 찾은 ByteArray 오브젝트를 리턴시킨
다.
substring 또 다른 String 오브젝트 내의 String 오브젝트를
찾고, 찾은 String 오브젝트를 리턴시킨다.
trim String 이전 및 이후로부터 화이트 스페이스를 제
거한다.
uppercase String 오브젝트의 모든 문자를 uppercase로 변환
한다.
addToDate
이 기능은 임의의 수의 날짜를 지정하는 Long 오브젝트를 Calendar 오브젝트 데이트에 더하고, 최종 Calendar 오브젝트 데이트를 리턴시킨다.
Calendar addToDate(Calendar,Long)
파라미터 유형 값
(Calendar,Long) 날짜, 날짜에 더하기 위한 다수의 날짜
리턴 타입 값
Calendar 최종 날짜
예
DatePurchased라고 명명된 메세지 아이템이 Calendar 오브젝트로서 정의된다. 다른 메세지에 대해서는, 사용자는 DatePurchased의 값 더하기 Calendar 오브젝트의 5일을 필로로 한다. 사용자는 다음과 같은 함수를 입력한다.
addToDate(MsgDef.DatePurchased, 5)
만일 DatePurchased의 값이 2000년 2월 13일과 같다면, 함수(function)는 그 값이 2000년 2월 18일과 동일한 캘린더 오브젝트으로 되돌려질 것이다.
bigDecimalToBoolean
이 기능은 BigDecimal 오브젝트를 불리안 오브젝트으로 변환한다.
Boolean bigDecimalToBoolean(bigDecimal)
파라미터 유형 값
(BigDecimal) BigDecimal to convert
리턴 유형 값 경우
불리안 참 BigDecimal은 0 이외의 어느값
거짓 BigDecimal은 0
bigDecimalToDouble
이 함수는 BigDecimal 오브젝트를 Double 오브젝트으로 변환한다.
Double bigDecimalToDouble(BigDecimal)
파라미터 유형 값
(BigDecimal) BigDecimal to convert
리턴 유형 값
더블 결과적인 더블
bigDecimalToLong
이 기능은 BigDecimal 오브젝트를 Long 오브젝트으로 변환한다.
LongbigDecimalToLong(BigDecimal)
파라미터 유형 값
(BigDecimal) BigDecimal to convert
리턴 유형 값
Long 결과적인 Long
bigDecimalToString
이 기능은 BigDecimal 오브젝트를 String 오브젝트으로 변환한다.
String bigDecimalToString(BigDecimal)
파라미터 유형 값
(BigDecimal) BigDecimal to convert
리턴 유형 값
String Resulting String
booleanToBigDecimal
이러한 기능은 불리안 오브젝트를 BigDecimal 오브젝트으로 변환한다.
Bigdecimal booleanToBigDecimal(Boolean)
파라미터 유형 값
(Boolean) Boolean to convert
리턴 유형 값 경우
BigDecimal 1 불리안은 참
0 불리안은 거짓
booleanToLong
이 기능은 불리안 오브젝트를 Long 오브젝트으로 변환한다.
Long booleanToLong(Boolean)
파라미터 유형 값
(Boolean) Boolean to convert
리턴 유형 값 경우
BigDecimal 1L 불리안은 참
0L 불리안은 거짓
booleanToString
이 기능은 불리안 오브젝트를 String 오브젝트으로 변환한다.
String booleanToString(Boolean)
파라미터 유형 값
(Boolean) Boolean to convert
리턴 유형 값
String 결과적인 String
calendarToString
2가지 함수에 대한 버전이 있다.
다음의 함수는 캘린더를 String 오브젝트로 변환한다.
String calendarToString(Clendar)
파라미터 유형 값
(Calendar) Calendar to convert
반환 형 값
String String으로 결과
다음 함수는 String 오브젝트(object)를 포매팅하기 위해 포맷 마스크를 사용하여, Calendar 오브젝트를 String 오브젝트로 변환한다.
String CalendarToString(Calendar,String)
파라미터 유형 값
(Calendar, String) 변환할 Calendar, 포맷 마스크
반환 형 값
String 마스크에 구체화된 포맷의 String으로 결과
보기:
DataPurchased로 이름지어진 메세지 아이템은 Calendar 오브젝트로 정의된다. 다른 메세지에 대해서, 사용자는 M/d/yyyy 포맷으로, String 오브젝트에서의 DataPurchased 값을 필요로 한다. 사용자는 다음과 같은 함수를 이용할 것이다.
CalendartoString(MsqDef.DatePurchased, "M/d/yyyy")
DarePurchsed 값이 2000, 2, 13이라면, 함수는 그 값이 "2/13/2000"인 String 오브젝트를 반환할 것이다.
compareDates
이 함수는 2개의 Calendar 오브젝트 데이트(date) 값을 비교하여서, 제1 데이트가 제2 데이트 값보다 작은지, 같은지, 또는 더 큰지를 가리킨다.
Long compareDates(Calendar, Calendar)
파라미터 유형 값
(Calendar, Calendar) 비교할 제1 데이터, 비교할 제2 데이터
반환 형 값 반환 시기
Long -1 제1 데이터가 제2 데이터보다 작을 때,
0 제1 데이터가 제2 데이터와 같을 때,
1 제1 데이터가 제2 데이터보다 클 때,
DoubleToBigDecimal
이 함수는 Double 오브젝트를 BigDecimal 오브젝트로 변환한다.
BigDecimal DoubleToBigDecimal(Double)
파라미터 유형 값
(Double) 변환할 Double 형
반환 형 값
BigDecimal BigDecimal로 결과
DoubleToLong
이 함수는 Double 오브젝트를 Long 오브젝트로 변환한다.
Long DoubleToLong(Double)
파라미터 유형 값
(Double) 변환할 Double
반환 형 값
Long Long으로 결과
DoubleToString
이 함수는 2가지 이형이 있다.
다음 함수는 Double 오브젝트를 String 오브젝트로 변환한다.
String DoubleToString(Double)
파라미터 유형 값
(Double) 변환할 Double
반환 형 값
String String으로 결과
다음 함수는 String 오브젝트를 포맷하기 위해 포맷 마스크를 사용하여, Double 오브젝트를 String 오브젝트로 변환한다.
String DoubleToString(Double, String)
파라미터 유형 값
(Double, String) 변환할 Double, 포맷 마스크
반환 형 값
String 마스크에 의해 구체화된 포맷의 String으로 결과
보기:
Discount로 이름붙여진 메세지 아이템은 Double 오브젝트로 정의된다. 다른 메세지에서, 사용자는 #.##의 포맷으로 String 오브젝트에서의 Discount 값을 필요로 한다. 사용자는 다음과 같은 함수를 사용할 것이다.
DoubleToString(MsgDef.Discount, "#.##")
Discount 값이 0.04531이라면, 함수는 그 값이 "0.05"인 String 오브젝트를 반환할 것이다.
findString
이 함수는 다른 String 오브젝트내의 String 오브젝트를 탐색한다. 함수가 구체적인 String 오브젝트를 찾는다면, 다른 String내의 String의 제1 문자(character)의 위치를 반환한다.
Long findString(String, String)
파라미터 유형 값
(String, String) 탐색할 String, 찾을 String
반환 형 값 반환 시기
Long 다른 String내의 String이 찾을 때
String의 제1 문자의 위치
-1 String이 찾아지지 않
을 때
findword
이 함수는 String 오브젝트내의 word를 탐색한다. 함수가 구체적인 word를 찾으면, 이 함수는 String내의 word의 제1 문자의 위치를 반환한다. 함수는 String내의 여백(white space)에 의해 표시된 워드를 찾기만 할 수 있다.
Long findWord(String, String)
파라미터 유형 값
(String, String) 탐색할 String, 찾을 word
반환 형 값 반환 시기
Long String내의 Word의 워드가 찾을 때
제1 문자의 위치
-1 워드가 찾아지지 않을 때
foundString
이 함수는 다른 String 오브젝트내에서의 String 오브젝트를 탐색하고, Boolean 오브젝트를 반환한다.
Boolean foundString(String, String)
파라미터 유형 값
(String, String) 탐색할 String, 찾을 String
반환 형 값 반환 시기
Boolean True String이 찾아질 때
False String이 찾아지지지 않을 때
foundWord
이 함수는 String 오브젝트내의 word를 탐색하고, Boolean 오브젝트를 반환한다. 이 함수는 String내의 여백에 의해 표시된 word를 찾기만 할 수 있다.
Boolean foundWord(String, String)
파라미터 유형 값
(String, String) 탐색할 String, 찾을 Word
반환 형 값 반환 시기
Boolean True Word가 찾아질 때
False Word가 찾아지지 않을 때
getDate
이 함수는 Calendar 오브젝트에서의 데이트를 찾아서 Integer 오브젝트로 데이트를 반환한다.
Integer getDate(Calendar)
파라미터 유형 값
(Calendar) 판독할 Calendar
반환 형 값
Integer 1에서 31까지의 Integer로 결과
보기:
DatePurchased로 이름 지어진 메세지 아이템은 Calendar 오브젝트로 결과된다. 다른 메세지에 대해서, 사용자는 Integer 오브젝트의 DatePurchased 값으로부터의 데이트를 필요로 한다. 사용자는 다음과 같은 함수를 사용할 것이다.
GetDate(MsgDef.DatePurchased)
DatePurchased 값이 2000, 2, 13이라면, 함수는 그 값이 13인 Integer 오브젝트를 반환할 것이다.
getMonth
이 함수는 Calendar 오브젝트에서 달(month)을 찾아서, Integer 오브젝트로서 달을 반환한다.
Integer GetMonth(Calendar)
파라미터 유형 값
(Calendar) 판독할 Calendar
반환 형 값
Integer 1에서 12까지의 Integer로 결과
보기:
DatePurchased로 이름 지어진 메세지 아이템은 Calendar 오브젝트로서 정의된다. 다른 메세지에 대해서, 사용자는 Integer 오브젝트의 DatePurchased 값으로부터 달(month)을 필요로 한다. 사용자는 다음과 같은 함수를 사용할 것이다.
getMonth(MsgDef.DatePurchased)
DatePurchased 값이 2000, 2, 13이라면, 이 함수는 그 값이 2인 Integer 오브젝트를 반환할 것이다.
getTokenAt
이 함수에는 2개의 이형이 있다.
다음 함수는 Strng 오브젝트를 토큰(token)으로 분해하여서(parse), 특정 토큰을찾고, 그 토큰을 String 오브젝트로서 반환한다. 함수는 코마(comma)는 토큰의 한계를 정하며, 사용자가 반환할 토큰의 위치를 가리키도록 가정한다. 분해할 스트링이 널(null) 값을 포함하거나, 구체화된 토큰 위치가 범위 외라면, 함수는 널 값을 반환한다.
String getTokenAt(String, Integer)
파라미터 유형 값
(String, Integer) 분해할 String, 찾을 토큰의 위치(0으로 시작)
반환 형 값
String 지시된 토큰, 또는 널 값
다음 한수는 String 오브젝트를 토큰으로 분해하여, 특정 토큰을 찾아서, 그 토큰을 String 오브젝트로서 반환한다. 함수는 토큰의 범위를 제한하는 문자를 사용자가 특정화하도록 하게 하며, 찾을 토큰의 위치를 사용자가 가리키도록 한다.
분해할 String이 널 값을 포함하거나, 구체화된 토큰 위치가 범위 외라면, 함수는 널 값을 반환한다.
String getToken(String, String, Integer)
파라미터 유형 값
(String, String, Integer) 분해할 String, 디리미터(delimiter),
찾을 토큰의 위치(0으로 시작)
반환 형 값
String 지시된 토큰, 또는 널 값
보기:
(1) Date로 이름 지어진 메세지 아이템은 M/d/yy 포맷의 데이트를 포함한 String 오브젝트로서 정의된다. 다른 메세지에 대해서, 사용자는 String 오브젝트의 Date 값으로부터 달을 필요로 한다. 사용자는 다음과 같은 함수를 사용할 것이다.
getTokeAt(Msgdef.Date, "/", 0)
Date가 "2/13/2000"을 포함했다면, 이 함수는 그 값이 "2"인 String 오브젝트를 반환할 것이다.
(2) Date로 이름 지어진 메세지 아이템은 MM.dd.yy 포맷의 데이트를 포함하는 String 오브젝트로서 정의된다. 다른 메세지에 대해서, 사용자는 String 오브젝트의 Date 값으로부터 데이트를 필요로 한다. 사용자는 다음과 같은 함수를 사용할 것이다.
getToken(MsgDef.date, "/", 1)
Date가 "02.13.00"을 포함했다면, 이 함수는 그 값이 "13"인 Sting 오브젝트를 반환할 것이다.
(3) Date로 이름 지어진 메세지 아이템은 M/d/yyy 포맷의 데이트를 포함하는 String 오브젝트로서 정의된다. 다른 메세지에 대해서, 사용자는 String 오브젝트의 Date 값으로부터 해(year)를 필요로 한다.
getTokenAtMonth(MsgDef.Date, "/", 2)
Date가 "2/13/2000"을 포함했다면, 이 함수는 그 값이 "2000"인 String 오브젝트를 반환할 것이다.
getYear
이 함수는 Calendar 오브젝트에서 해를 찾아서, 그 해를 Integer 오브젝트로서 반환할 것이다.
Integer getYear(Calendar)
파라미터 유형 값
(calendar) 판독할 Calendar
반환 형 값
Integer Integer로 결과
보기:
DatePurchased로 이름 지어진 메세지 아이템은 Calendar 오브젝트로서 정의된다. 다른 메세지에 대해서, 사용자는 Integer 오브젝트의 DatePurchased 값으로부터 해를 필요로 한다. 사용자는 다음과 같은 함수를 사용할 것이다.
getYear(MsgDef.DatePurchased)
DatePurchased 값이 2000, 2, 13이라면, 이 함수는 그 값이 2000인 Integer 오브젝트를 반환할 것이다.
integerToString
이 함수에는 2개의 이형이 있다.
다음 함수는 Integer 오브젝트를 String 오브젝트로 변환한다.
String integerToString(Integer)
파라미터 유형 값
(Integer) 변환할 Integer
반환 형 값
String String으로 결과
다음 함수는 String 오브젝트를 포맷하기 위해 포맷 마스크를 사용하여, Integer 오브젝트를 String 오브젝트로 변환한다.
String integerTostring(Integer, String)
파라미터 유형 값
(Integer, String) 변환할 Integer, 포맷 마스크
반환 형 값
String 마스크에 의해 구체화된 포맷의 String으로 결과
보기:
Quantity로 이름 지어진 메세지 아이템은 Integer 오브젝트로서 정의된다. 다른 메세지에 대해서, 사용자는 #,### 포맷의 String 오브젝트의 Quantity 값을 사용한다. 사용자는 다음과 같이 함수를 사용할 것이다.
IntegerToString(MsgDef.Quantity, "#,###")
Quantity 값이 2540이었다면, 이 함수는 그 값이 "2,540"인 String 오브젝트를 반환할 것이다.
isAlpha
이 함수는 String 오브젝트에서의 모든 문자들이 알파벳인지를 결정하여, Booean 오브젝트로 반환한다.
Boolean isAlpha(String)
파라미터 유형 값
(String) 체크할 String
반환 형 값 반환 시기
Boolean True 모든 문자가 알파벳일 때
False 모든 문자가 알파벳이 아닐 때
isAlphaNumeric
이 함수는 String 오브젝트내의 모든 문자가 알파뉴메릭인지를 결정하여, Boolean 오브젝트로 반환한다.
Boolean isAlphaNumeric(String)
파라미터 유형 값
(String) 체크할 String
반환 형 값 반환 시기
Boolean True 모든 문자들이 알파뉴메릭임.
False 모든 문자가 알파뉴메릭은 아님.
isNumeric
이 함수는 String 오브젝트 내의 모든 문자들이 뉴메릭인지를 판정하여 Boolean 오브젝트를 리턴한다.
Boolean isNumeric(String)
파라미터 유형 값
(String) 체크할 String
Return Type 값 When
Boolean True 모든 문자들이 뉴메릭임.
False 모든 문자가 뉴메릭은 아님.
justify Center
이 함수의 두가지 버젼이 있다.
다음의 함수는 Integer 오브젝트에 의해 지정된 길이의 String 오브젝트를 생성하고 그 안에서 String 오브젝트를 센터링한다. 만일 센터링된 String이 특정된 길이보다 짧다면, 이 함수는 String의 각 사이드에 같은 개수의 스페이스들을 채운다.
만일 센터링된 String이 특정된 길이보다 길다면, 이 함수는 널값을 리턴한다.
String justifyCenter(String, Integer)
파라미터 유형 값
(String, Integer) 센터링할 String, 리턴할 String의 길이
Return Type 값
String 결과 String, 또는 널값
다음의 함수는 Integer 오브젝트에 의해 지정된 길이의 String 오브젝트를 생성하고 그 안에서 String 오브젝트를 센터링한다. 만일 센터링된 String이 특정된 길이보다 짧다면, 이 함수는 String의 각 사이드에 다른 String 내에 지정된 문자를 같은 개수만큼 채운다.
만일 센터링된 String이 특정된 길이보다 길다면, 이 함수는 널값을 리턴한다.
String justifyCenter(String, Integer, String)
파라미터 유형 값
(String, Integer, String) 센터링할 String, 리턴할 String의 길이, String을 채우는 데 사용할 문자
Return Type 값
String 결과 String, 또는 널값
예:
Name으로 이름이 지어진 메시지 아이템은 String 오브젝트로서 정의된다. 다른 메시지를 위해, 사용자는 길이가 20인 String 오브젝트 내에 센터링되고 필요에 따라 아스테리스크(*)로 채워진 Name의 값이 필요하다. 사용자는 다음과 같이 함수를 입력할 것이다.
JustifyCenter(MsgDef.Name, 20, "*")
만일 Name의 값이 "Wolfgang A. Mozart"라면, 이 함수는 "*Wolfgang A. Mozart*"라는 값을 갖는 String 오브젝트를 리턴할 것이다.
justifyLeft
이 함수의 두가지 버젼이 있다.
다음의 함수는 Integer 오브젝트에 의해 지정된 길이의 String 오브젝트를 생성하고 그 안에서 String 오브젝트를 좌측 정렬한다. 만일 좌측 정렬된 String이 특정된 길이보다 짧다면, 이 함수는 String의 우측 사이드에 스페이스들을 채운다.
만일 좌측 정렬된 String이 특정된 길이보다 길다면, 이 함수는 널값을 리턴한다.
String justifyLeft(String, Integer)
파라미터 유형 값
(String, Integer) 좌측 정렬할 String, 리턴할 String의 길이
Return Type 값
String 결과 String, 또는 널값
다음의 함수는 Integer 오브젝트에 의해 지정된 길이의 String 오브젝트를 생성하고 그 안에서 String 오브젝트를 좌측 정렬한다. 만일 좌측 정렬된 String이 특정된 길이보다 짧다면, 이 함수는 String의 우측 사이드를 다른 String 내에 지정된 문자들로 채운다.
만일 좌측 정렬된 String이 특정된 길이보다 길다면, 이 함수는 널값을 리턴한다.
String justifyLeft(String, Integer, String)
파라미터 유형 값
(String, Integer, String) 좌측 정렬할 String, 리턴할 String의 길이,
String을 채우는 데 사용할 문자
Return Type 값
String 결과 String, 또는 널값
예:
Name으로 이름이 지어진 메시지 아이템은 String 오브젝트로서 정의된다. 다른 메시지를 위해, 사용자는 길이가 20인 String 오브젝트 내에 좌측 정렬되고 필요에 따라 스페이스로 채워진 Name의 값이 필요하다. 사용자는 다음과 같이 함수를 입력할 것이다.
JustifyLeft(MsgDef.Name, 20, "*")
만일 Name의 값이 "Franz Shubert"라면, 이 함수는 "Franz Shubert"라는 값을 갖는 String 오브젝트를 리턴할 것이다.
justifyRight
이 함수의 두가지 버젼이 있다.
다음의 함수는 Integer 오브젝트에 의해 지정된 길이의 String 오브젝트를 생성하고 그 안에서 String 오브젝트를 우측 정렬한다. 만일 우측 정렬된 String이 특정된 길이보다 짧다면, 이 함수는 String의 좌측 사이드에 스페이스들을 채운다.
만일 우측 정렬된 String이 특정된 길이보다 길다면, 이 함수는 널값을 리턴한다.
String justifyRight(String, Integer)
파라미터 유형 값
(String, Integer) 우측 정렬할 String, 리턴할 String의 길이
Return Type 값
String 결과 String, 또는 널값
다음의 함수는 Integer 오브젝트에 의해 지정된 길이의 String 오브젝트를 생성하고 그 안에서 String 오브젝트를 우측 정렬한다. 만일 우측 정렬된 String이 특정된 길이보다 짧다면, 이 함수는 String의 좌측 사이드를 다른 String 내에 지정된 문자들로 채운다.
만일 우측 정렬된 String이 특정된 길이보다 길다면, 이 함수는 널값을 리턴한다.
String justifyRight(String, Integer, String)
파라미터 유형 값
(String, Integer, String) 우측 정렬할 String, 리턴할 String의 길이,
String을 채우는 데 사용할 문자
Return Type 값
String 결과 String, 또는 널값
예:
Name으로 이름이 지어진 메시지 아이템은 String 오브젝트로서 정의된다. 다른 메시지를 위해, 사용자는 길이가 20인 String 오브젝트 내에 우측 정렬되고 필요에 따라 아스테리스크(*)로 채워진 Name의 값이 필요하다. 사용자는 다음과 같이 함수를 입력할 것이다.
JustifyRight(MsgDef.Name, 20, "*")
만약 Name의 값이 "Sergei Rachmaninoff"이면, 함수는 값이 "*Sergei Rachmaninoff"인 String 오브젝트를 리턴한다.
longToBigDecimal
이 함수는 Long 오브젝트를 BigDecimal 오브젝트로 변환한다.
BigDecimal longToBigDecimal(Long)
파라미터 유형 값
(Long) 변환할 Long
Return Type 값
BigDecimal Resulting BigDecimal
longToBoolean
이 함수는 Long 오브젝트를 Boolean 오브젝트로 변환한다.
Boolean longToBoolean(Long)
파라미터 유형 값
(Long) Long to convert
Return Type 값 When
Boolean True Long은 0 이외의 임의의 값임
False Long은 0
longToDouble
이 함수는 Long 오브젝트를 Double 오브젝트로 변환한다.
Double longTodouble(Long)
파라미터 유형 값
(Long) 변환할 Long
Return Type 값
Double Resulting Double
longToString
2가지 버젼의 함수가 존재한다.
다음의 함수는 Long 오브젝트를 String 오브젝트로 변환한다.
String longToString(Long)
파라미터 유형 값
(Long) 변환할 Long
Return Type 값
String Resulting String
다음의 함수는 String 오브젝트를 포맷하는 포맷 마스크를 사용하여 Long 오브젝트를 String 오브젝트로 변환한다.
String longToString(Long,String)
파라미터 유형 값
(Long,String) 변환할 Long,포맷 마스크
Return Type 값
String Resulting String, 마스크에 의해 특정화된 포맷으로
예:
CustID라는 명칭의 메시지 아이템은 Long 오브젝트로서 정의된다. 다른 메시지의 경우, 사용자는 String 내에 ##,### 포맷으로 CustID의 값이 필요하다. 사용자는 다음과 같이 함수를 입력한다.
longToString(MsgDef.CustID,"##,###")
CustID 값이 10321인 경우, 함수는 값이 "10,321"인 String 오브젝트를 리턴한다.
lookup
2가지 버젼의 함수가 존재한다.
다음의 함수는 다른 String 오브젝트에서 특정화된 룩업 테이블에서 String 오브젝트를 룩업하여 대응값을 리턴한다. 이 함수가 룩업 테이블에서 대응값을 찾지 못하면 널 값을 리턴한다.
String lookup(String,String)
파라미터 유형 값
(String,String) 룩업할 String,룩업 테이블
Return Type 값
String 룩업 테이블에서 찾은 값 또는 널 값
다음의 함수는 다른 String 오브젝트에서 특정화된 룩업 테이블에서 String 오브젝트를 룩업하여 대응값을 리턴한다. 이 함수가 룩업 테이블에서 대응값을 찾지 못하면 제3 String 오브젝트에서 특정화된 디폴트 값을 리턴한다.
String lookup(String,Strin,String)
파라미터 유형 값
(String,String,String) 룩업할 String,룩업 테이블,디폴트 값
Return Type 값
String 룩업 테이블에서 찾은 값 또는 디폴트 값
State라는 명칭의 메시지 아이템은 String 오브젝트로서 정의된다. State는 미국 내의 3개의 주중 하나의 명칭에 대한 2글자 약자를 항상 포함한다. 다른 메시지의 경우에는, 사용자는 String 오브젝트에서 주의 전체 명칭을 필요로 한다. 약자에 대응하는 전체 명칭이 없으면, 사용자는 String 오브젝트가 N/A를 포함하기를 바란다. 사용자는 다음과 같이 함수를 입력한다.
lookup(MsgDef.State,"MD=Maryland,PA=Pennsylvania,VA=Virginia","N/A")
State 값이 "VA"이면, 함수는 값이 "Virginia"인 String 오브젝트를 리턴한다.
lowercase
이 함수는 String 오브젝트 내의 모든 문자를 lowercase로 변환한다.
String lowercase(String)
파라미터 유형 값
(String) 변환할 Long
Return Type 값
String Resulting String
replaceString
이 함수는 특정 String 오브젝트에 대해 String 오브젝트를 서치하여, 찾은 String 오브젝트를 대체 String 오브젝트로 대체하고, 적소에 대체 String이 있는 String 오브젝트를 리턴한다.
이 함수가 대체할 String를 찾지 못하면, 그것을 변경시키지 않고 서치된 String을 리턴한다.
String replaceString(String,String,String)
파라미터 유형 값
(String,String,String) 대체 String, 대체 String, 서치할 String
Return Type 값
String 적소에 대체 String이 있는 String
예:
Address라는 명칭의 메시지 아이템은 String 오브젝트로서 정의된다. Virginia 주에서의 어드레스의 경우, Address 내의 값은 때때로 2글자 약자를 포함한다.
다른 메세지에 대해서, 사용자는 Address 값을 포함하지만 약어(abbreviation)로 대체된 주의 풀 네임을 갖는 String 오브젝트를 요구한다. 사용자는 아래와 같은 함수를 입력한다.
replaceString("VA", "Virginia", MsgDet.Address)
Address 값이 "Reston, VA 20191" 이었다면, 이 함수는 그 값이 "Reston, Virginia 20191" 인 String 오브젝트를 리턴한다.
replaceWord
이 함수는 특정 단어에 대한 String 오브젝트를 검색하고, 발견된 단어를 다른 단어로 교체하여, String 오브젝트를 교체 단어로 대신하여 리턴한다.
이 함수는 그 단어가 (1) 전후에 스페이스가 있고, (2) String 오브젝트 내에서 좌측에 정의되며 스페이스가 뒤따르고, (3) String 오브젝트 내에서 우측에 정의되며 스페이스를 뒤따르는 경우에만, String 오브젝트 내에 특정된 단어를 찾을 수 있다.
String replaceWord(String, String, String)
파라미터 타입 값
(String, String, String) 교체할 단어, 교체 단어, 검색할 String
리턴 타입 값
String 교체 단어를 갖는 String
예:
Address로 명명된 메세지 항목은 String 오브젝트로서 정의된다. Maryland 주의 주소에 대하여, Address 값은 때때로 두 글자 약어인 MD를 포함한다. 다른 메세지에 대하여, 사용자는 Address 값을 포함하지만 약어로 대체된 주의 풀 네임을 갖는 String 오브젝트를 요구한다. 사용자는 아래와 같은 함수를 입력한다.
replaceWord("MD", "Maryland", MsgDef.Address)
Address 값이 "Bethesda, MD 20904" 이었다면, 이 함수는 그 값이 "Bethesda, Maryland 20904" 인 String 오브젝트를 리턴한다.
sizeOf
이 함수는 두 가지 버젼이 있다.
아래의 함수는 String 오브젝트의 사이즈를 판정하고 그 사이즈를 Long 오브젝트로서 리턴한다.
Long sizeOf(String)
파라미터 타입 값
(String) 그 사이즈가 판정될 String
리턴 타입 값
Long String의 사이즈
아래의 함수는 ByteArray 오브젝트의 사이즈를 판정하고 그 사이즈를 Long 오브젝트로서 리턴한다.
Long sizeOf(ByteArray)
파라미터 타입 값
(ByteArray) 그 사이즈가 판정될 ByteArray
리턴 타입 값
Long ByteArray의 사이즈
stringToBigDecimal
이 함수는 String 오브젝트를 Big Decimal 오브젝트로 변환한다.
BigDecimal stringToBigDecimal(String)
파라미터 타입 값
(String) 변환할 String
리턴 타입 값
BigDecimal BigDecimal 결과
stringToBoolean
이 함수는 String 오브젝트를 Boolean 오브젝트로 변환한다.
Boolean stringToBoolean(String)
파라미터 타입 값
(String) 변환할 String
리턴 타입 값
Boolean Boolean 결과
stringToCalendar
이 함수는 두 가지 버젼이 있다.
아래의 함수는 String 오브젝트를 Calendar 오브젝트로 변환한다.
stringToCalendar(String)
파라미터 타입 값
(String) 변환할 String
리턴 타입 값
Calendar Calendar 결과
아래의 함수는 String 오브젝트를 해석하는 포맷 마스크를 이용하여 String 오브젝트를 Calendar 오브젝트로 변환한다.
Calendar stringToCalendar(String, String)
파라미터 타입 값
(String, String) 변환할 String, 포맷 마스크
리턴 타입 값
Calendar Calendar 결과
예:
DatePurchased로 명명된 메세지 항목은 "M/d/yy" 포맷의 날짜를 포함하는 String 오브젝트로서 정의된다. 다른 메세지에 대해서, 사용자는 Calendar 오브젝트에서의 DatePurchased 값과 등가인 Calendar를 요구한다. 사용자는 아래와 같은 함수를 입력한다.
stringToCalendar(MsgDef.DatePurchased, "M/d/yy")
DatePurchased 값이 "2/13/2000" 이었다면, 이 함수는 그 값이 2000년 2월 13일과 등가인 Calendar 오브젝트를 리턴한다.
stringToDouble
이 함수는 두 가지 버젼이 있다.
아래의 함수는 String 오브젝트를 Double 오브젝트로 변환한다.
Double stringToDouble(String)
파라미터 타입 값
(String) 변환할 String
리턴 타입 값
Double Double 결과
아래의 함수는 String 오브젝트를 해석하는 포맷 마스크를 이용하여 String 오브젝트를 Double 오브젝트로 변환한다.
Double stringToDouble(String, String)
파라미터 타입 값
(String, String) 변환할 String, 포맷 마스크
리턴 타입 값
Double Double 결과
예:
TotalCost로 명명된 메세지 항목은 "##,###.##" 포맷의 달러량을 포함하는 String 오브젝트로서 정의된다. 다른 메세지에 대해서, 사용자는 Double 오브젝트에서의 TotalCost 값을 요구한다. 사용자는 아래와 같은 함수를 입력한다.
stringToDouble(MsgDef.TotalCost, "##,###.##")
TotalCost 값이 "5,137.29" 이었다면, 이 함수는 그 값이 5137.29 인 Double 오브젝트를 리턴한다.
stringToInteger
이 함수는 두 가지 버젼이 있다.
아래의 함수는 String 오브젝트를 Integer 오브젝트로 변환한다.
Integer stringToInteger(String)
파라미터 타입 값
(String) 변환할 String
리턴 타입 값
Integer Integer 결과
아래의 함수는 String 오브젝트를 해석하는 포맷 마스크를 이용하여 String 오브젝트를 Integer 오브젝트로 변환한다.
Integer stringToInteger(String, String)
파라미터 타입 값
(String, String) 변환할 String, 포맷 마스크
리턴 타입 값
Integer Integer 결과
예:
Quantity로 명명된 메세지 항목은 "#,###" 포맷의 양을 포함하는 String 오브젝트로서 정의된다. 다른 메세지에 대해서, 사용자는 String 오브젝트에서의 Quantity 값을 요구한다. 사용자는 아래와 같은 함수를 입력한다.
stringToInteger(MsgDef.Quantity, "#,###")
Quantity 값이 "2,540" 이었다면, 이 함수는 그 값이 2540 인 Integer 오브젝트를 리턴한다.
stringToLong
이 함수는 두 가지 버젼이 있다.
아래의 함수는 String 오브젝트를 Long 오브젝트로 변환한다.
Long stringTolong(String)
파라미터 타입 값
(String) 변환할 String
리턴 타입 값
Long Long 결과
아래의 함수는 String 오브젝트를 해석하는 포맷 마스크를 이용하여 String 오브젝트를 Long 오브젝트로 변환한다.
Long stringToLong(String, String)
파라미터 타입 값
(String, String) 변환할 String, 포맷 마스크
리턴 타입 값
Long Long 결과
예:
CustID로 명명된 메세지 항목은 "##,###" 포맷의 숫자를 포함하는 String 오브젝트로서 정의된다. 다른 메세지에 대해서, 사용자는 Long 오브젝트에서의 Cust 값을 요구한다. 사용자는 아래와 같은 함수를 입력한다.
stringToLong(MsgDef.CustID, "##,###")
CustID 값이 "10,321" 이었다면, 이 함수는 그 값이 10321 인 Long 오브젝트를 리턴한다.
subarray
이 함수는 다른 ByteArray 오브젝트 내에서 ByteArray 오브젝트를 검색하고, 발견된 ByteArray 오브젝트를 리턴한다.
이 함수가 ByteArray를 발견하지 못하면, 널 값을 리턴한다.
ByteArray subarray(Long, Long, ByteArray)
파라미터 타입 값
(Long, Long, ByteArray) 검색할 ByteArray의 최초 바이트 위치,
검색할 ByteArray의 최후 바이트 위치, 및
검색할 ByteArray를 포함하는 ByteArray
(위치는 '0'에서 시작함)
리턴 타입 값
ByteArray 발견된 ByteArray
예:
Array로 명명된 메세지 항목은 ByteArray 오브젝트로서 정의된다. 다른 메세지에 대해서, 사용자는 ByteArray 오브젝트에서의 최초 8 바이트를 요구한다. 사용자는 아래와 같은 함수를 입력한다.
subArray(0, 7, MsgDef.Array)
substring
이 함수는 다른 String 오브젝트 내에서 String 오브젝트를 검색하고, 발견된 String 오브젝트를 리턴한다.
이 함수가 String을 발견하지 못하면, 널 값을 리턴한다.
String substring(Long, Long, String)
파라미터 타입 값
(Long, Long, String) 검색할 String의 최초 문자 위치,
검색할 String의 최후 문자 위치, 및
검색할 String을 포함하는 String
리턴 타입 값
String 발견된 String
trim
이 함수는 String 오브젝트 전후의 스페이스를 제거한다.
String trim(String)
파라미터 타입 값
(String) 스페이스를 제거할 스트링
리턴 타입 값
String String 결과
uppercase
이 함수는 String 오브젝트의 모든 문자를 대문자로 변환한다.
String uppercase(String)
파라미터 타입 값
(String) 변환할 스트링
리턴 타입 값
String String 결과
이상에서 보여지고 설명된 실시예는 본 발명의 범위를 제한하는 것을 의미하는 것은 아니다. 따라서, 본 발명에 따른 변조 및 변형은 첨부된 청구범위의 사상 및 범위를 벗어나지 않고도 당업자에게 명백할 것이다.

Claims (29)

  1. 복수의 컴퓨터 애플리케이션을 통합하기 위한 시스템에 있어서,
    상기 컴퓨터 애플리케이션들 간에 메시지를 통과시키는 기업(enterprise) 메시징 시스템;
    상기 기업 메시징 시스템에 연결되며, 복수의 데이터 전송 형태(configuration) 및 복수의 규칙을 저장하는 데이터베이스 저장 시스템;
    상기 기업 메시징 시스템에 연결되며, 상기 데이터베이스 저장 시스템에 저장된 상기 데이터 전송 형태를 사용하는 데이터 전송 엔진 및 상기 데이터베이스 저장 시스템에 저장된 상기 규칙을 사용하는 규칙 평가 엔진을 포함하는 통합 서비스;
    상기 기업 메시징 시스템과 연결되며, 각각이 상기 컴퓨터 애플리케이션들의 각각의 하나와 연결되며, 각각이 상기 기업 메시징 시스템과 상기 각각의 컴퓨터 애플리케이션 사이에 메시지를 통과시키는 복수의 에이전트 어댑터; 및
    상기 에이전트 어댑터와 연관되어 동작하여 상기 컴퓨터 애플리케이션으로부터 각각의 메시지 요소를 분석하는 메시지 스킴(scheme)
    을 포함하는 복수의 컴퓨터 애플리케이션 통합 시스템.
  2. 제1항에 있어서, 상기 통합 시스템은 상기 기업 메시징 시스템으로부터 메시지를 분할하고 결합하며, 상기 컴퓨터 애플리케이션에 대한 메시지의 콘텐츠-기초 라우팅을 실행하는 복수의 컴퓨터 애플리케이션 통합 시스템.
  3. 제1항에 있어서, 상기 에이전트 어댑터는 상기 기업 메시징 시스템으로부터 상기 각각의 컴퓨터 애플리케이션으로 통과되는 메시지를 시스템 포맷으로부터 각각의 컴퓨터 애플리케이션 포맷으로 변환하며, 상기 각각의 컴퓨터 애플리케이션으로부터 상기 기업 메시징 시스템으로 통과되는 메시지를 상기 각각의 컴퓨터 애플리케이션으로부터 상기 시스템 포맷으로 변환하는 복수의 컴퓨터 애플리케이션 통합 시스템.
  4. 제1항에 있어서, 상기 각각의 에이전트 어댑터는 다른 상기 에이전트 어댑터와 상기 각각의 컴퓨터 애플리케이션 사이에 메시지를 더 통과시키는 복수의 컴퓨터 애플리케이션 통합 시스템.
  5. 제1항에 있어서, 상기 각각의 에이전트 어댑터는 어댑터부와 상기 어댑터부를 밀봉하는 에이전트부를 포함하는 복수의 컴퓨터 애플리케이션 통합 시스템.
  6. 제1항에 있어서, 상기 각각의 에이전트 어댑터는 하나 이상의 어댑터부와, 상기 하나 이상의 어댑터부의 모두를 밀봉하는 에이전트부를 포함하는 복수의 컴퓨터 애플리케이션 통합 시스템.
  7. 에이전트 어댑터를 포함하는 개선된 기업용 애플리케이션 통합 시스템에 있어서,
    상기 기업용 애플리케이션들 중 선택된 하나에 대해 구성된 어댑터;
    상기 어댑터를 호스팅하는 에이전트 서비스;
    상기 어댑터가 생성하며, 수신하며, 또는 응답하는 복수의 메시지 각각에 대한 메시지 정의;
    상기 어댑터를 상기 선택된 기업용 애플리케이션에 연결하기 위한 수단; 및
    상기 연결 수단을 통해 상기 어댑터를 구현하는 수단
    을 포함하는 개선된 기업용 애플리케이션 통합 시스템.
  8. 제7항에 있어서, 상기 어댑터는 소스 어댑터, 타깃 어댑터, 응답 어댑터, 및 요청 어댑터로 이루어지는 그룹으로부터 선택되는 개선된 기업용 애플리케이션 통합 시스템.
  9. 제1 컴퓨터 애플리케이션과 제2 컴퓨터 애플리케이션 사이에 메시지를 통과시키는 방법에 있어서,
    상기 제1 컴퓨터 애플리케이션으로부터 제1 데이터를 갖는 제1 메시지를 제공하는 단계;
    상기 제1 메시지를 공개하여 제1 공개된 메시지를 획득하는 단계;
    상기 제1 공개된 메시지의 상기 제1 데이터를 상기 제2 데이터로 변환하여 제2 메시지를 획득하는 단계;
    상기 제2 메시지를 공개하여 제2 공개된 메시지를 획득하는 단계; 및
    상기 제2 공개된 메시지를 상기 제2 컴퓨터 애플리케이션에 제공하는 단계
    를 포함하는 메시지 통과 방법.
  10. 제9항에 있어서,
    상기 제1 메시지를 공개하기 전에 제1 컴퓨터 애플리케이션 포맷으로부터 상기 제1 메시지를 시스템 포맷으로 변환하는 단계; 및
    상기 제2 공개된 메시지를 상기 제2 컴퓨터 애플리케이션에 제공하기 전에 상기 제2 공개된 메시지를 상기 시스템 포맷으로부터 제2 컴퓨터 애플리케이션 포맷으로 변환하는 단계
    를 더 포함하는 메시지 통과 방법.
  11. 제9항에 있어서, 상기 제1 데이터를 변환하는 상기 단계는,
    데이터베이스로부터 상기 제2 데이터를 요청하는 단계, 및
    상기 데이터베이스로부터 상기 제2 데이터를 수신하는 단계를 포함하는 메시지 통과 방법.
  12. 기업용 애플리케이션 통합 시스템에서 사용되는 에이전트 어댑터에 있어서,
    상기 기업용 애플리케이션들 중 선택된 하나에 대해 구성되는 어댑터;
    상기 어댑터를 호스팅하는 에이전트 서비스;
    상기 어댑터가 생성하며, 수신하며, 또는 응답하는 복수의 메시지 각각에 대한 메시지 정의;
    상기 어댑터를 상기 선택된 기업용 애플리케이션에 연결하기 위한 수단; 및
    상기 연결 수단을 통해 상기 어댑터를 구현하기 위한 수단
    을 포함하는 에이전트 어댑터.
  13. 제12항에 있어서, 상기 어댑터는 소스 어댑터, 타깃 어댑터, 응답 어댑터 및 요청 어댑터로 이루어지는 그룹으로부터 선택되는 에이전트 어댑터.
  14. 제13항에 있어서, 상기 어댑터는 소스 어댑터를 포함하며, 상기 소스 어댑터가 하나 이상의 메시지에 적용되는 복수의 타깃들 중 선택된 하나를 지정하기 위한 수단을 더 포함하는 에이전트 어댑터.
  15. 제13항에 있어서, 상기 어댑터는 타깃 어댑터를 포함하며, 상기 타깃 어댑터가 하나 이상의 메시지에 적용되는 복수의 타깃들 중 선택된 하나를 지정하기 위한 수단을 더 포함하는 에이전트 어댑터.
  16. 제13항에 있어서, 상기 어댑터는 응답 어댑터를 포함하며, 상기 응답 어댑터가 하나 이상의 메시지에 적용되는 복수의 타깃들 중 선택된 하나를 지정하기 위한 수단을 더 포함하는 에이전트 어댑터.
  17. 제1 컴퓨터 애플리케이션과 제2 컴퓨터 애플리케이션 사이에 메시지를 통과시키는 방법에 있어서,
    상기 제1 컴퓨터 애플리케이션으로부터의 제1 데이터를 갖는 제1 메시지를 제공하는 단계;
    상기 제1 메시지를 공개하여 제1 공개 메시지를 획득하는 단계;
    상기 제1 공개 메시지의 상기 제1 데이터를 제2 데이터로 변환하여 제2 메시지를 획득하는 단계;
    상기 제2 메시지를 공개하여 제2 공개 메시지를 획득하는 단계; 및
    상기 제2 공개 메시지를 상기 제2 컴퓨터 애플리케이션에 제공하는 단계
    를 포함하는 메시지 통과 방법.
  18. 제17항에 있어서,
    상기 제1 메시지를 공개하기 전에 상기 제1 메시지를 제1 컴퓨터 애플리케이션 포맷으로부터 시스템 포맷으로 변환하는 단계; 및
    상기 제2 공개 메시지를 상기 제2 컴퓨터 애플리케이션에 제공하기 전에 상기 제2 공개 메시지를 상기 시스템 포맷으로부터 제2 포맷으로 변환하는 단계
    를 더 포함하는 메시지 통과 방법.
  19. 제18항에 있어서, 상기 제1 데이터를 변환하는 상기 단계는,
    데이터베이스로부터 상기 제2 데이터를 요청하는 단계, 및
    상기 데이터베이스로부터 상기 제2 데이터를 수신하는 단계
    를 더 포함하는 메시지 통과 방법.
  20. 제19항에 있어서,
    상기 컴퓨터 애플리케이션들 중 선택된 하나에 대해 구성된 어댑터를 제공하는 단계,
    에이전트 서비스를 제공하여 상기 어댑터를 호스팅하는 단계,
    상기 어댑터가 생성하며, 수신하며, 또는 응답하는 복수의 메시지 각각에 대한 메시지 정의를 정의하는 단계, 및
    상기 어댑터를 선택된 컴퓨터 애플리케이션에 연결하는 단계
    를 더 포함하는 메시지 통과 방법.
  21. 복수의 기업용 애플리케이션- 상기 애플리케이션 각각은 복수의 메시지를 생성하며, 수신하며, 저장하며, 처리하기 위한 네이티브 포맷을 각각 가짐 -을 통합하는 기업용 애플리케이션 통합 시스템에 있어서,
    에이전트에 의해 밀봉되는 복수의 어댑터를 포함하는 에이전트 어댑터
    를 포함하되,
    상기 에이전트에 의해 밀봉된 상기 복수의 어댑터는 상기 에이전트에 의해 밀봉되는 동안 별개의 기능을 수행하기 위한 수단을 포함하는 기업용 애플리케이션 통합 시스템.
  22. 제21항에 있어서, 상기 에이전트는 이에 내장된 복수의 오브젝트를 더 포함하며, 상기 복수의 오브젝트 각각은 별개의 기능을 수행하도록 적용되는 기업용 애플리케이션 통합 시스템.
  23. 제22항에 있어서, 상기 에이전트에 의해 내장된 상기 복수의 오브젝트들 중 제1오브젝트는 상기 기업용 애플리케이션들 중 선택된 애플리케이션과 상기 시스템 사이의 상기 에이전트 어댑터의 연결을 관리하기 위한 수단을 더 포함하는 기업용 애플리케이션 통합 시스템.
  24. 제23항에 있어서, 상기 에이전트에 의해 내장된 상기 복수의 오브젝트들 중 제2오브젝트는 상기 기업용 애플리케이션들 중 선택된 애플리케이션과 상기 시스템 사이의 상기 에이전트 어댑터에서 검출된 에러를 관리하기 위한 수단을 더 포함하는 기업용 애플리케이션 통합 시스템.
  25. 제23항에 있어서, 상기 에이전트에 의해 내장된 상기 복수의 오브젝트들 중 제3오브젝트는 상기 기업용 애플리케이션들 중 선택된 애플리케이션과 상기 시스템 사이의 상기 에이전트 어댑터내에서 상기 복수의 메시지의 변환을 관리하기 위한 수단을 더 포함하는 기업용 애플리케이션 통합 시스템.
  26. 제22항에 있어서, 복수의 노드와, 상기 노드에 상주하는 복수의 시스템 서비스를 더 포함하는 기업용 애플리케이션 통합 시스템.
  27. 제26항에 있어서, 상기 에이전트는 이에 내장되는 복수의 오브젝트를 더 포함하며, 상기 복수의 오브젝트 각각은 별개의 기능을 수행하도록 적용되는 기업용 애플리케이션 통합 시스템.
  28. 제27항에 있어서, 상기 에이전트에 내장된 상기 복수의 오브젝트 각각은 상기 복수의 노드들 중 임의의 하나에서 그 각각의 기능을 수행하도록 적용되는 기업용 애플리케이션 통합 시스템.
  29. 제27항에 있어서, 상기 에이전트에 내장된 상기 복수의 오브젝트 각각은 상기 시스템에서 다른 에이전트에 내장된 상기 오브젝트들의 각각과 연관된 각각의 기능을 수행하도록 적용되는 기업용 애플리케이션 통합 시스템.
KR1020007007862A 1998-11-18 1999-11-18 확장가능한 분산된 기업용 애플리케이션 통합 시스템 KR100684680B1 (ko)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US10899398P 1998-11-18 1998-11-18
US60/108,993 1998-11-18
US41263399A 1999-10-05 1999-10-05
US09/412,595 US6256676B1 (en) 1998-11-18 1999-10-05 Agent-adapter architecture for use in enterprise application integration systems
US09/412,633 1999-10-05
US09/412,595 1999-10-05

Publications (2)

Publication Number Publication Date
KR20010040348A true KR20010040348A (ko) 2001-05-15
KR100684680B1 KR100684680B1 (ko) 2007-02-22

Family

ID=27380580

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020007007862A KR100684680B1 (ko) 1998-11-18 1999-11-18 확장가능한 분산된 기업용 애플리케이션 통합 시스템

Country Status (18)

Country Link
EP (1) EP1016989A3 (ko)
JP (1) JP2002530732A (ko)
KR (1) KR100684680B1 (ko)
CN (1) CN1182467C (ko)
AU (1) AU776938B2 (ko)
BR (1) BR9907032A (ko)
CA (1) CA2318203A1 (ko)
EA (1) EA003744B1 (ko)
ID (1) ID25779A (ko)
IL (1) IL137276A (ko)
IS (1) IS5563A (ko)
MX (1) MXPA00007085A (ko)
NO (1) NO20003652L (ko)
NZ (1) NZ505945A (ko)
PL (1) PL343772A1 (ko)
TR (1) TR200002083T1 (ko)
WO (1) WO2000029924A2 (ko)
YU (1) YU45600A (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100788138B1 (ko) * 2003-06-09 2007-12-21 주식회사 케이티 네트워크 기반의 서비스 플랫폼을 이용한 통신 서비스제공 시스템 및 방법
KR100950212B1 (ko) * 2003-02-17 2010-03-29 노키아 코포레이션 이동 통신 애플리케이션들을 테스트하기 위한 소프트웨어 개발 시스템, 상기 소프트웨어 개발 시스템에서 소프트웨어 구성요소들간에 데이터를 전송하는 방법, 상기 소프트웨어 개발 시스템을 포함하는 데이터 처리 장치, 및 상기 데이터 처리 장치를 제어하는 컴퓨터 프로그램이 수록된 컴퓨터 판독가능 저장 매체
KR20210057679A (ko) * 2019-11-12 2021-05-21 한국전자통신연구원 크로스도메인 확장형 워크플로우 엔진 프레임워크

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001166938A (ja) * 1999-09-29 2001-06-22 Toshiba Corp エンタープライズシステムの構築方法
US6308178B1 (en) * 1999-10-21 2001-10-23 Darc Corporation System for integrating data among heterogeneous systems
AU2001276827A1 (en) * 2000-06-20 2002-01-02 Invertix Corporation Method and system for interconnecting remote intelligent devices with a network
US6754672B1 (en) 2000-09-13 2004-06-22 American Management Systems, Inc. System and method for efficient integration of government administrative and program systems
AU2002243335A1 (en) * 2000-10-20 2002-06-18 Polexis, Inc. Extensible information system (xis)
WO2002039351A2 (en) * 2000-11-01 2002-05-16 Seebeyond Technology Corporation Sytems and methods for providing centralized management of heterogeneous distributed enterprise application integration objects
US7383355B1 (en) 2000-11-01 2008-06-03 Sun Microsystems, Inc. Systems and methods for providing centralized management of heterogeneous distributed enterprise application integration objects
US20020069123A1 (en) * 2000-12-01 2002-06-06 Mats Soderlind Electronic commerce system
JP2002175274A (ja) 2000-12-06 2002-06-21 Sony Corp 情報処理装置及び情報処理方法、ネットワーク・システム、記憶媒体、並びにコンピュータ・プログラム
SG98440A1 (en) * 2001-01-16 2003-09-19 Reuters Ltd Method and apparatus for a financial database structure
US7143190B2 (en) 2001-04-02 2006-11-28 Irving S. Rappaport Method and system for remotely facilitating the integration of a plurality of dissimilar systems
US9912722B2 (en) 2001-04-02 2018-03-06 Irving S. Rappaport Method and system for facilitating the integration of a plurality of dissimilar systems
US7051334B1 (en) * 2001-04-27 2006-05-23 Sprint Communications Company L.P. Distributed extract, transfer, and load (ETL) computer method
GB2378357B (en) * 2001-06-25 2003-08-27 Empower Interactive Group Ltd Message transmission system and method
US20030023471A1 (en) * 2001-07-25 2003-01-30 Kettler Edward W. Method and tool for achieving data consistency in an enterprise resource planning system
WO2003027872A2 (en) * 2001-09-24 2003-04-03 Empower Interactive Group Limited Distributed system architecture
WO2003034182A2 (en) * 2001-10-18 2003-04-24 Bea Systems, Inc. System and method for invoking business functionality for a workflow
EP1440367B1 (en) * 2001-10-29 2014-11-26 Accenture Global Services Limited Connector for an application to an enterprise java bean (ejb) compliant application programming interface (api)
US20050131805A1 (en) * 2001-11-19 2005-06-16 Wolfgang Bross Software interface, method and computer program product product for linking a business application to a component of a computer-based transaction tax processing system
US8694394B2 (en) 2001-11-19 2014-04-08 Hewlett-Packard Development Company, L.P. Methods, data record, software interface, data warehouse module and software application for exchanging transaction-tax-related data
GB2382962A (en) 2001-12-07 2003-06-11 Altio Ltd Data routing without using an address
US8046238B2 (en) 2001-12-20 2011-10-25 Accenture Global Services Limited Business transaction management
US7065746B2 (en) * 2002-01-11 2006-06-20 Stone Bond Technologies, L.P. Integration integrity manager
US7346647B2 (en) 2002-04-19 2008-03-18 Computer Associates Think, Inc. System and method for interfacing with existing system management products or software solutions
EP1403793A1 (de) * 2002-09-27 2004-03-31 Sap Ag Verfahren zur automatischen integrierten Belegablage bei der Protokollierung von Geschäftsvorfällen
EP1403794A1 (de) * 2002-09-27 2004-03-31 Sap Ag Verfahren und System zur automatischen Speicherung von betriebswirtschaftlichen Daten
US7191450B2 (en) * 2003-02-06 2007-03-13 International Business Machines Corporation Data-driven application integration adapters
US7895589B2 (en) * 2003-02-26 2011-02-22 International Business Machines Corporation Dynamic data-driven application integration adapters
US8112481B2 (en) 2003-03-28 2012-02-07 Microsoft Corporation Document message state management engine
US7614057B2 (en) * 2003-03-28 2009-11-03 Microsoft Corporation Entity linking system
US7418496B2 (en) * 2003-05-16 2008-08-26 Personnel Research Associates, Inc. Method and apparatus for survey processing
GB0314800D0 (en) * 2003-06-25 2003-07-30 Hyfinity Ltd System and associated methods for software assembly
US7321939B1 (en) 2003-06-27 2008-01-22 Embarq Holdings Company Llc Enhanced distributed extract, transform and load (ETL) computer method
US20050066002A1 (en) * 2003-07-31 2005-03-24 Arnold Teres Workflow compatible healthcare information message communication system
US8782405B2 (en) 2004-03-18 2014-07-15 International Business Machines Corporation Providing transaction-level security
US7594236B2 (en) * 2004-06-28 2009-09-22 Intel Corporation Thread to thread communication
DE602005008557D1 (de) 2005-04-19 2008-09-11 Sap Ag System und Verfahren zum Vermitteln in einem Netzwerk
US7869585B2 (en) * 2006-03-17 2011-01-11 Microsoft Corporation Declarations for transformations within service sequences
US8386409B2 (en) 2009-05-12 2013-02-26 Emc Corporation Syslog message routing systems and methods
DE102009050830A1 (de) * 2009-10-27 2011-04-28 Bizerba Gmbh & Co. Kg Verfahren betreffend den Betrieb von elektronischen Geräten
CN102346685B (zh) * 2010-07-29 2016-09-28 甲骨文国际公司 集成适配器管理系统和方法
EP2625655A4 (en) 2010-10-06 2014-04-16 Planet Data Solutions SYSTEM AND METHOD FOR INDEXING ELECTRONIC DETECTION DATA
KR20130076062A (ko) * 2011-12-28 2013-07-08 한국과학기술정보연구원 분산 데이터 품질 관리 시스템 및 그 방법
CN103488699A (zh) * 2013-09-04 2014-01-01 用友软件股份有限公司 基于内存数据网格的数据处理装置和方法
US10768975B2 (en) * 2016-03-04 2020-09-08 Ricoh Company, Ltd. Information processing system, information processing apparatus, and information processing method
US10924576B2 (en) 2016-11-15 2021-02-16 Nec Corporation Relay apparatus, client apparatus, data relay method, and program storage medium in which computer-readable program is stored
CN116540638B (zh) * 2023-07-05 2023-09-05 成都瑞雪丰泰精密电子股份有限公司 后置处理cam数控加工程序的方法、装置和存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0456249B1 (en) * 1990-05-10 1998-12-09 Hewlett-Packard Company System for integrating application programs in a heterogeneous network enviroment
AU639802B2 (en) * 1990-08-14 1993-08-05 Oracle International Corporation Methods and apparatus for providing dynamic invocation of applications in a distributed heterogeneous environment
AU4237293A (en) * 1992-05-08 1993-12-13 Release Management Systems (Rms) Data interchange system
WO1993026109A1 (en) * 1992-06-17 1993-12-23 The Trustees Of The University Of Pennsylvania Apparatus for providing cryptographic support in a network
IL111154A0 (en) * 1993-10-21 1994-12-29 Martino Ii John A Systems and methods for electronic messaging

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100950212B1 (ko) * 2003-02-17 2010-03-29 노키아 코포레이션 이동 통신 애플리케이션들을 테스트하기 위한 소프트웨어 개발 시스템, 상기 소프트웨어 개발 시스템에서 소프트웨어 구성요소들간에 데이터를 전송하는 방법, 상기 소프트웨어 개발 시스템을 포함하는 데이터 처리 장치, 및 상기 데이터 처리 장치를 제어하는 컴퓨터 프로그램이 수록된 컴퓨터 판독가능 저장 매체
KR100788138B1 (ko) * 2003-06-09 2007-12-21 주식회사 케이티 네트워크 기반의 서비스 플랫폼을 이용한 통신 서비스제공 시스템 및 방법
KR20210057679A (ko) * 2019-11-12 2021-05-21 한국전자통신연구원 크로스도메인 확장형 워크플로우 엔진 프레임워크

Also Published As

Publication number Publication date
MXPA00007085A (es) 2005-09-20
IL137276A0 (en) 2001-07-24
CA2318203A1 (en) 2000-05-25
AU1731100A (en) 2000-06-05
IS5563A (is) 2000-07-17
JP2002530732A (ja) 2002-09-17
NZ505945A (en) 2003-12-19
EP1016989A3 (en) 2002-01-02
AU776938B2 (en) 2004-09-30
NO20003652D0 (no) 2000-07-17
IL137276A (en) 2005-11-20
BR9907032A (pt) 2001-01-16
CN1182467C (zh) 2004-12-29
PL343772A1 (en) 2001-09-10
EP1016989A2 (en) 2000-07-05
KR100684680B1 (ko) 2007-02-22
CN1294710A (zh) 2001-05-09
YU45600A (sh) 2002-10-18
NO20003652L (no) 2000-09-15
EA003744B1 (ru) 2003-08-28
EA200000778A1 (ru) 2001-06-25
WO2000029924A3 (en) 2000-10-26
ID25779A (id) 2000-11-02
WO2000029924A2 (en) 2000-05-25
TR200002083T1 (tr) 2001-02-21

Similar Documents

Publication Publication Date Title
KR100684680B1 (ko) 확장가능한 분산된 기업용 애플리케이션 통합 시스템
US6738975B1 (en) Extensible distributed enterprise application integration system
US6256676B1 (en) Agent-adapter architecture for use in enterprise application integration systems
US6964053B2 (en) Type descriptor language (TDLanguage) metamodel
US6904598B2 (en) COBOL metamodel
US6775680B2 (en) High level assembler metamodel
US6915523B2 (en) PL/I metamodel
US7761406B2 (en) Regenerating data integration functions for transfer from a data integration platform
JP3842213B2 (ja) Ｃ／ｃ＋＋メタモデルを含む共通アプリケーション・メタモデル
US8074228B2 (en) Systems and methods for providing mockup business objects
US20030163585A1 (en) Type descriptor metamodel
US20050243604A1 (en) Migrating integration processes among data integration platforms
US8056091B2 (en) Systems and methods for using application services
US20050251533A1 (en) Migrating data integration processes through use of externalized metadata representations
US20080306986A1 (en) Migration of Legacy Applications
US20050278270A1 (en) Data services handler
US20030093403A1 (en) System and method for implementing an event adapter
US20060294048A1 (en) Data centric workflows
EP1815349A2 (en) Methods and systems for semantic identification in data systems
EP1444609A1 (en) Application view component for system integration
Vandersluis XML-based integration with xaware: Unifying applications and data in Today's e-business world
Akbay et al. Design and implementation of an enterprise information system utilizing a component based three-tier client/server database system
Ayandeh Simulation study of the token bus local area network
Holloway Engineering Analysis and Literature Review of the use of CORBA on Distributed Object-Oriented Systems
Baker et al. z/TPF and WebSphere Application Server in a Service Oriented Architecture

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
LAPS Lapse due to unpaid annual fee