[J2EE] J2EE 커넥터 아키텍쳐 white paper

[정재동]

white 페이퍼

J2EE 커넥 아키텍쳐

기존의 엔터프라이즈 어플리케이션과 자바 어플리케이션을 통합합니다.

Executive summury

J2EE Connector Architecture, 자바 2 Platform의 부분은 다양한 Enterprise Information Systems (EIS)에 있는 자원을 접근하는 데 대해서 표준이 되는 아키텍쳐를 명시합니다. (J2EE) 이것은 SAP R/3과 같은 ERP 시스템을 포함할 수도 있습니다. 그런데 그것은 IBM CICS와 legacy 어플리케이션과 non-relational 데이타베이스 시스템과 같은 시스템을 처리하는 Mainframe 처리입니다.

현재, JDBC Data Access API 는 관계형 데이타베이스 시스템으로 자바에게 쉬운 통합을 제공합니다. 그런데 그들은 어플리케이션입니다. 비슷한 방식으로, Connector Architecture는 이질적인 EIS 시스템을 가진 자바 어플리케이션의 통합을 단순하게 합니다.

이 페이지는 하이 레벨의  Connector Architecture 명세의 1.0 버전을 설명합니다.

• 보안, 리소스어댑터,커넥션 풀링, 그리고 트랜젝션 메니지먼트 설비를 제공하면서, 시스템 계약은 J2EE platform-based 어플리케이션 서버와 EIS 리소스어댑터 사이에 정의했습니다.
• Common Client Interface (CCI)는 EIS 리소스어댑터와 어플리케이션 컴포넌트나 툴 사이에 위치한다
• 어플리케이션 서버 환경에서 패키징과 리소스어댑터의 디플로이를 수행한다.

Connector Architecture Specification 문서는 그 아키텍쳐에 대한 상세한 정보를 포함합니다. Connector Architecture에 대한 그 명세와 최근의 정보는 http://java.sun.com/j2ee/connector에서 찾을 수 있습니다.

소개

대부분의 회사는 ERP 시스템, legacy 시스템, mainframe 데이타베이스와 시스템을 처리하는 것과 같은 Enterprise Information Systems (EISs) 안에 거대한 투자를 가지고 있습니다. 현재, 웹기반이고 multi-tiered 어플리케이션의 부분으로 이 시스템을 지렛대 역할을 하는 것은 시도하고 있습니다. 엔터프라이즈 어플리케이션 통합을 위해 지원의 수준을 변화시키면서, EIS 벤더는 인터페이스를 제공합니다. 어플리케이션 서버 벤더는 다른 지원된 EIS에 대해 분리된 인터페이스를 빌드하고 유지해야 합니다. 그리고 어플리케이션 개발자는 어플리케이션 안에 시스템 레벨의 보안과 트랜젝션, 커넥션 풀링을 관리할 필요가 있습니다.

EIS 통합 시도

EIS를 가지는 통합은 많은 시도를 보여줍니다.

• 뒤단의 끝 EIS는 복잡하고 이질적입니다. 어플리케이션 통합의 그 복잡함과 노력을 증가시키면서, 그 어플리케이션 프로그래밍 모델은 이 시스템 사이에 넓게 변화합니다. 이 통합 노력을 단순하게 할 수 있는 어플리케이션 개발 도구는 중요합니다.
• 트랜젝션과 보안 관리는 back-end EIS 시스템으로 통합에 복잡함을 더합니다.
• 그 웹 기반의 아키텍쳐는 엔터프라이즈 어플리케이션에 접근할 수 있는 클라이언트의 잠재한 수의 면에서 중요한 측정 가능성을 요구합니다.

J2EE Platform과 Connector Architecture

Connector Architecture는 이 시도를 직접적으로 다룹니다. 플랫포옴과 vendor-independent인 multi-tier 어플리케이를 개발하고 배치시키기 위해 Enterprise JavaBeans 와 JavaServer Pages 기술을 사용하면서, J2EE 플랫포옴은 재사용할 수 있는 컴포넌트 모델을 제공합니다. J2EE 플랫포옴은 자바 플랫포옴의 "Write Once, Run Anywhere" 접근을 공유합니다. 그리고 중요한 산업 지원을 가지고 있습니다.

Connector Architecture는 이 플랫포옴에 간소화한 EIS 통합을 더합니다. 그 목적은 EIS 통합의 시도를 언급하기 위해 J2EE 플랫포옴 - including component models, transaction and security infrastructures -의 힘을 지렛대 역할을 하는 것입니다.

Connector Architecture는 어플리케이션 서버 안으로 EIS-specific 리소스어댑터에 구현되면서 어플리케이션 서버와 EIS 시스템 사이의 공통의 인터페이스를 정의합니다. 확장할 수 있고 표준이 되는 J2EE 플랫포옴의 이익을 지렛대 역할을 하는 아키텍쳐를 사용하면서, 그 결과는 간소화한 엔터프라이즈 어플리케이션 통합입니다.

그림 Connector Architecture를 사용하면서, 각각의 EIS가 단지 한 Connector Architecture-compliant 리소스어댑터에게 쓰고 각각의 어플리케이션 서버는 EIS 자원어댑과 밑에 있는 EIS로 통합을 지원하기 위해 그것의 시스템을 한번 확장합니다.

어플리케이션 컴포넌트와 어플리케이션 서버와 EIS 사이의 표준이 되는 계약을 개발하는 것은 그 통합 노력의 전체적인 범위를 감소시킵니다. 이것은 전체의 자바 개발 사회를 위한 이익을 전달합니다.

• 하나의 EIS 벤더는 단지 새로 만들 필요가 있습니다. 그런데 그것은 EIS로의 오픈된 인터페이스입니다 (implemented in the resource adapter). 이 자원어댑터는 어떤 고분고분한(우낀다.^^) J2EE 어플리케이 서버도 가지고 사용될 수 있습니다. 그리고 도구와 Enterprise Application Integration (EAI) 벤더에 대해 표준이 되는 인터페이스를 제공합니다. 하나의 인터페이스를 유지하는 것은 EIS 벤더를 위해 개발 노력을 감소시킵니다. 그런데 오늘 개개의 벤더에 표적으로 정해진 포인트 해법을 건설해야 하고 응낙을 위한 개개의 시스템을 증명해야 합니다.
  
• Application Servers 벤더 (vendors of any compliant J2EE servers)는 단지 Connector Architecture에 의해 정의된 시스템 계약을 지원하기 위해 그들의 시스템을 한번 확장할 필요가 있습니다. 어떤 EIS-specific system-level 프로그래밍도 없는 다중의 EIS와 관련된 통합을 지원하면서, 그들은 그 서버를 확장하기 위해 다중의 자원어댑터로 단순히 부지런히 일할 수 있습니다.
  
• Enterprise Application Integration (EAI)과 개발 도구 벤더는 표준이 되는 application-level 인터페이스로 EIS 자원까지 접근을 단순하게 하기 위해 Common Client Interface (CCI)를 사용합니다.
  
• 어플리케이션 컴포넌트 개발자는 EIS에서의 자료나 기능을 접근할 때 트랜젝션,커넥션 풀링,보안관계[고려]의 복잡함으로부터 보호되고 사업과 어플리케이션 로직을 확장하면서 그 대신에 집중할 수 있습니다.

넓은 범위의 도구와 서버와 EIS 벤더의 기여로, Connector Architecture는 Java Community Process 프로그램의 생산품입니다.

커넥 아키텍쳐 개관

Connector Architecture는 어플리케이 서버와 EIS-specific 자원어댑에 구현됩니다. 자원어댑은 EIS까지 시스템 도서관 특성이고 EIS에게 연결성을 제공합니다. 자원어댑은 JDBC 운전수와 유사합니다. 자원어댑과 EIS 사이의 인터페이스는 밑에 있는 EIS에게 특정합니다; 그것은 고유의 인터페이스일 수 있습니다.

Connector Architecture는 세 주가 된 구성요소를 가지고 있습니다.

• 시스템 수준은 그 자원 어댑터와 그 어플리케이션 서버 사이에서 수축됩니다.
• Common Client Interface는 그 자원 어댑터를 접근하기 위해 그만큼 자바에게 클라이언트 API를 제공합니다. 그런데 그들은 어플리케이션과 개발 도구입니다.
• 자원 어댑터에 대한 표준 패키징, 디플로이 설비.

그림 Connector Architecture는 그 어플리케이 서버와 그 자원 어댑터 사이에 시스템 계약을 정의합니다. 그것은 또한 그 자원 어댑터 사이에 클라이언트 API와 어플리케이 구성요소를 정의합니다. 이 계약은 이 페이퍼로 더 훨씬 설명됩니다.

어플리케이션 서버에 있는 컨테이너 (hosting JSP pages and Servlets)는 웹 컨테이너와 EJB 컨테이너일 수 있습니다. 그 어플리케이 서버는 implementation-specific 방법에서 서비스의 집합을 제공합니다. 이 서비스는 커넥션 풀링, 트랜젝션 메니져와 보안 서비스 메니져와 메카니즘을 포함합니다. Connector Architecture는 정의하지 않는 어플리케이션 서버가 다른 이것을 구현하는 것을 서비스합니다.

• 그 어플리케이 서버 벤더는 Connector Architecture에 의해 정의된 시스템 계약을 지원하기 위해 그 서버를 확장합니다. 그 시스템 계약은 Service Provider Interface (SPI)로 여겨질 수 있습니다. SPI는 컨테이너를 확장하는 것이 다중의 EIS에게 연결성을 지원하는 표준 방식을 제공합니다.
  
• 그 시스템이 계약하는 EIS 그것 자신과 지원하는 것과 그 어플리케이션 서버에 대해 상호 작용하기 위해 EIS-specific 인터페이스를 사용하면서, EIS 벤더 (or a third party ISV)는 EIS에 대해 자원 어댑터를 새로 만듭니다. 또한, 그 자원 어댑터는 Connector Architecture에 의해 정의되면서 Common Client Interface로 부른 클라이언트 API나 CCI를 제공합니다. 어플리케이 개발 도구나 어플리케이 컴포넌트는 그 자원 어댑터와 직접적으로 상호 작용하기 위해 Common Client Interface를 사용합니다.

그 자원 어댑터는 어플리케이 서버의 주소 공간에서 실행되고 EIS 자원에 대한 접근을 관리합니다. Connector Architecture-compliant 자원 어댑터는 어떤 고분고분한 J2EE 서버도 가지고 일할 것입니다.

System-Level Contract

Connector Architecture의 1.0 버전은 그 자원어댑과 그 어플리케이 서버에 의해 구현되기 위해 다음의 시스템 계약을 제공합니다.

• 커넥션 관리
• 트랜젝션 관리
• 보안 관리

1.0이 이것을 놓아주므로, 계약은 엔터프라이즈 어플리케이션 통합하는 동안 관계[고려]를 대부분을 해결했습니다. 트랜젝션, 보안, 그리고 측정 가능성 그 명세의 미래 버전에서, 그 시스템 계약은 Java Message Service pluggability (JMS)과 실 관리에 대해 지원을 포함하기 위해 확장될 것입니다. JMS pluggability는 비 동시성의 message-based 통신을 위해 지원을 더할 것입니다.

다음의 부분은 이 계약의 간단한 개관을 제공합니다.

Connection Management Contract

EIS로의 연결은 비싼 시스템 자원입니다. 확장할 수 있는 어플리케이션를 지원하기 위해, 어플리케이션 서버는 밑에 있는 EIS로의 연결을 커넥션 풀링하기 위해 필요하게 됩니다. 어플리케이션 개발을 단순하게 하면서, 메카니즘을 공동출자하는 이 연결은 밑에 있는 EIS를 접근하는 어플리케이에 투명할 것입니다.

어플리케이 실행과 증가하는 측정 가능성을 최적화하면서, Connection Management 계약은 관리 커넥션 풀링하는 것을 지원합니다. Connection Management 계약은 어플리케이션 서버와 자원 어댑터 사이에 정의됩니다. 그것은 설비를 공동출자하는 그것의 연결을 구현하기 위해 어플리케이션 서버에게 지원을 제공합니다. 그 어플리케이션 서버는 조직화합니다. 그리고, 이행 특성에 그것의 연결 풀링 구현합니다. 그런데 그것은 방법입니다 - 그 풀링은 매우 원시적일 수 있거나 그 어플리케이션 서버에 의해 제공된 서비스의 성질에 의존하면서 나아갔습니다.

서버가 그 커넥션 관리 계약을 사용하는 어플리케이션

• EIS로의 새로운 연결을 새로 만드세요.
• JNDI namespace에 있는 컨넥션 팩토리를 구성하세요.
• 풀링된 연결의 현존하는 집합 출신의 권리[옳음] 연결을 발견하세요.

트랜젝션 관리와 보안 관리와 같게 그 커넥션 관리 계약은 그것의 서비스에서 적용되기 위해 어플리케이 서버를 가능하게 합니다.

..............................................................................................................................여기까지 재빠르게 편집[대충 주용 용어만]

Transaction Management Contract

EIS로의 업무의 접근은 사업 어플리케이를 위해 중요한 필요입니다. Connector Architecture는 처리의 개념을 지원합니다 - 던 작동[수술]는 그 자료가 일치한 채로 남아있고 자료 성실[완전함]를 유지하기 위해 그만큼 함께 전혀 맡겨져야 합니다.

많은 케이스에, 처리 (termed local transaction)는 단일한 EIS 시스템에게 범위에서 제한됩니다. 그리고 EIS 자원 경영자 그것 자신은 그런 처리를 관리합니다. XA 처리 (or global transaction)가 다중의 자원 경영자를 이를 수 있는 동안 처리의 이 양식은 어플리케이 서버로 뭉치로 만들어지면서 외부의 처리 경영자에 의한 처리 조정을 요구합니다. 경영자가 사용하는 two-phase가 처리를 관리하기 위해 조약안을 맡기는 처리는 그만큼 다중의 자원 경영자 (EISs)를 이릅니다. 한 자원 경영자가 XA 처리에 참가하고 있if_only 사용 one-phase가 optimization을 맡기는 그것

그 커넥 아키텍쳐는 어플리케이 서버와 자원어댑 (and its underlying resource manager) 사이에 처리 관리 계약을 정의합니다. 처리의 형태에 의존하면서, 그 처리 관리 계약은 그 연결 관리 계약을 확장하고 지방민의 관리와 계약이 두 부분을 가지고 있는 XA transactions.The 처리 관리에게 지원을 제공합니다.

• JTA XAResource 는 처리 경영자와 EIS 자원 경영자 사이에 계약을 기초를 뒀습니다.
• 지역적인 처리 관리 계약

이 계약은 어플리케이 서버가 처리 관리에 대해 그 지원시설과 runtime 환경을 제공할 수 있게 합니다. 어플리케이 구성요소는 coponent-level 처리 모델을 지원하는 것때문에 이 처리 지원시설에 의존합니다.

EIS 이행이 매우 변화되기 때문에, 그 업무의 지원은 매우 유연함에 틀림없습니다. Connector Architecture는 처리 관리를 위해 EIS로 어떤 필요도 강요하지 않습니다. EIS의 안에 있는 처리의 이행에 의존하면서, 자원어댑은 제공함에 틀림없습니다.


• 전부에 있는 어떤 처리 지원 - 이것은 유산 어플리케이와 많은 back-end 시스템 중에서 전형적입니다.
• 단지 지역적인 처리를 위한 지원
• 지역적이고 XA 처리를 위한 지원

어플리케이 서버는 처리의 모든 세 수준을 지원해야 합니다. 이것은 어플리케이 서버가 다른 처리 수준에 EIS를 지원할 수 있는 것을 보증합니다.

안전 계약

그것은 그만큼 중요합니다. EIS에 정보나 어떤 허가받지 않은 접근의 어떤 상실이나 부정확도 엔터프라이까지 극히 비용이 많이 들 수 있습니다. 그런 포함하는 안전 위협으로부터 EIS를 보호하는 데 이용될 수 있는 메카니즘이 있습니다.


• 그것들이 그들이 누구를 있는 것을 주장하는지라는 것을 검증하기 위해 교장 (human users)의 식별과 증명
• 위임과 접근은 교장이 어플리케이 서버와 EIS를 접근하도록 허락받든 간에 결정하기 위해 관리합니다.
• 어플리케이 서버와 EIS 사이의 통신의 안전 불안정한 연결 위의 통신은 증명과 성실[완전함]과 비밀성 서비스를 제공하는 조약안 (for example, Kerberos)을 사용하면서 보호될 수 있습니다. 통신은 또한 안전한 links 조약안 (for example, SSL)을 사용하는 것에 의해 보호될 수 있습니다.

Connector Architecture는 안전한 연결성에 대해 EIS까지 지원을 포함하기 위해 J2EE 안전 모델을 확장합니다.

그 안전 관리 계약은 안전 메카니즘과 기술로부터 독립적이도록 정의됩니다. 이것은 안전 기술을 위한 어플리케이 서버와 지원의 다른 수준과 함께 EIS가 그 안전 계약을 지원할 수 있게 합니다. 예를 들면, 그 안전 관리 계약은 기본적인 기초하는 user-password 증명이나 Kerberos-based end-to-end 안전 환경을 지원할 수 있습니다. 그것은 또한 EIS-specific 안전 메카니즘을 지원할 수 있습니다.

EIS 방송 개시

새로운 바디의 연결을 새로 만드는 것은 EIS에 방송 개시를 요구합니다. 현존하는 바디의 연결의 위에 있는 안전 문맥을 변화시키는 것은 또한 EIS 방송 개시를 요구할 수도 있습니다; 그 후자는 명명된 reauthentication입니다. 다음의 단계로 하나 이상의 EIS 방송 개시는 일반적으로 수반합니다.


• 누구의 안전 문맥 아래에서 안전 교장을 결정하면서, EIS로의 바디의 연결은 설립할 것입니다.
• 그것이 이미 인증되지 않는다면 안전 교장의 증명
• 그 어플리케이 서버와 EIS 사이의 안전한 관계를 맺습니다. 이것은 부가적인 안전 메카니즘 (example, data confidentiality and integrity)이 그 두 실체 사이에서 통신에 적용되어질 수 있게 합니다.
• EIS 자원에 대한 접근 제어

하나의 Connector Architecture 지원은 다중의 EIS를 통해 계약한 후 고용합니다. 하나의 방송 개시 능력은 다중의 EIS 시스템에서 자원에 대한 접근을 필요로 하는 어플리케이에서 유용합니다. 예를 들면, 고용인 self-service 어플리케이는 독신을 가지는 기록이 계약한 후 고용하는 HR과 Payroll에 고용인 접근을 줄 수 있습니다.

Security Contract은 공동출자된 연결의 EIS 신호 reauthentication을 필요한대로 지원하기 위해 Connection Management 계약을 확장합니다.

공통의 클라이언트 인터페이스

CCI는 어플리케이 구성요소에 대해 표준이 되는 클라이언트 API를 정의합니다. CCI는 어플리케이 구성요소와 Enterprise Application Integration (EAI) 기본틀이 공통의 클라이언트 API를 사용하는 이질적인 EIS를 가로질러 상호작용을 운전할 수 있게 합니다.

CCI의 목표 사용자는 엔터프라이 도구 벤더와 EAI 벤더입니다. 어플리케이 구성요소는 또한 API에 그들 스스로 쓸 수 있습니다. 그러나 CCI는 low-level API입니다. 대부분의 어플리케이 개발자에 의해 사용된 인터페이스를 작성하는 application-level인 P?e, 그 명세는 CCI, 그 도구 벤더에 의해 제공된 더 부유한 기능성 동안 기초인 것을 그만큼 추천합니다.

클라이언트 도구 통합의 시

EIS/application 서버 통합의 이종 시는 또한 엔터프라이 어플리케이 개발 도구 벤더와 EAI 기본틀을 위해 유효합니다. 일반적으로, EIS는 소유의 클라이언트 API를 제공합니다. 어플리케이 개발 도구나 EAI 기본틀은 더 높은 추상한 계층으로 이 다른 클라이언트 API를 적응할 필요가 있습니다. 이 추상한 계층은 도구와 EAI 벤더가 유용한 기능성을 건설하는 공통의 수준까지 API를 올립니다.

CCI는 이질적인 EIS를 가로질러 공통인 API를 제공함으로써 이 문제를 해결합니다. 이것은 도구와 EAI 벤더가 다양한 EIS-specific 클라이언트 API를 적응하기 위해 그 필요를 회피합니다. 이 벤더는 밑에 있는 EIS에 대하여 higher-level 기능성을 건설하기 위해 CCI를 사용할 수 있습니다.

공통의 클라이언트 인터페이스

CCI는 수행되는 것이 EIS에 기능을 하고 results.The CCI를 검색하는 것이 특정한 EIS로부터 독립적인 촛점에 맞는 먼 function-call 인터페이스를 정의합니다; 예를 들면 자료는 EIS에게 특성을 타이프합니다. 그러나 CCI는 저장소로부터의 EIS-specific metadata에 의해 운전될 능력이 있습니다.

CCI는 어플리케이가 EIS로의 연결을 새로 만들고 관리하고 상호작용을 실행하고 그리고 입력이나 산출이나 귀환 가치로 자료 기록을 관리할 수 있게 합니다. JavaBeans 아키텍쳐와 Java Collection 기본틀을 지렛대 역할을 하면서, CCI는 toolable이기 위해 설계됩니다.

동안, 그것이 그만큼 그 자원어댑을 요구하는 그 시스템 계약을 구현하는 Connector Architecture의 1.0 버전은 그것의 클라이언트 API로서의 자원어댑 지원 CCI를 그만큼 추천합니다. JDBC API에 기반하는 클라이언트 API와 같게 자원어댑은 CCI와 다른 클라이언트 API를 가지고 있기로 결정할 수 있습니다.

JDBC API와 Connectors

JDBC API 사이의 관계와 Connectors는 어플리케이 계약과 시스템 계약의 원근 화법에서 이해되어야 합니다.

• JDBC API는 CCI가 관계 데이타베이스가 아닌 EIS를 위해 EIS-independent 클라이언트 API를 정의하는 동안 관계 데이타베이스를 접근하기 위해 표준이 되는 클라이언트 API를 정의합니다. JDBC API는 CCI가 EIS의 다른 형태에게 추천된 클라이언트 API인 동안 관계 데이타베이스를 접근하기에 추천된 API입니다.

• 그 시스템 계약 수준에서, 커넥 SPI는 JDBC 2.0 계약의 일반화와 강화로서 보여야 합니다. Future JDBC 명세는 JDBC 2.0 SPI로 선택으로서 그것을 제공함으로써 Connector SPIs와 정렬해야 합니다. 어플리케이 서버 벤더를 위한 다른 선택은 Connector 시스템 계약 아래에서 JDBC 운전수를 싸게 있습니다.

Deployment 짐을 꾸리는 것과

다양한 자원어댑이 모듈식의 매너에 있는 고분고분한 J2EE 어플리케이 서버로 쉽게 부지런히 일할 수 있도록, Connector Architecture는 전개 인터페이스 짐을 꾸리는 것과를 제공합니다.

자원어댑 공급자는 자바 인터페이스의 집합과 그것의 자원어댑의 이행의 부분으로 학급을 개발합니다. 이 자바 학급은 그 자원어댑에 의해 제공된 Connector Architecture-specified 계약과 EIS-specific 기능성을 구현합니다. 자원어댑의 개발은 또한 밑에 있는 EIS에 출생지의 도서관의 특정한 사용을 요구할 수도 있습니다.

자바 인터페이스와 학급은 Resource Adapter Module를 새로 만들기 위해 전개 descriptor와 함께 짐이 꾸리어집니다. (with required native libraries, help files, documentation, and other resources) 전개 descriptor는 자원어댑 공급자와 자원어댑의 전개에 deployer 사이에 계약을 정의합니다.

공유되고 그리고, stand-alone 모듈 자원어댑 모듈은 전개될 수도 있습니다. 그런데 그것은 J2EE 어플리케이의 부분으로 짐이 꾸리어졌습니다. 전개 동안에, deployer는 어플리케이 서버에 자원어댑 모듈을 설치하고 그 조작상의 목표로 그것을 구성하고 환경. 자원어댑의 구성은 전개 descriptor를 그 자원어댑 모듈의 부분으로 타고 정의된 속성에 기반합니다.

Connector Architecture와 Enterprise Application Integration

Connector Architecture의 잠재한 이익을 설명하기 위해, 이 부분은 다른 원근 화법으로부터의 두 시나리오를 제공합니다.

Multiple Tools와 Servers와 EIS를 통합합니다.

소프트웨어 벤더는 촛점이 회사를 제조하는 mid-sized에 맞추어진 ERP 시스템을 제공합니다. 그것의 고객은 multi-tier, 이 어플리케이와 그 벤더의 ERP 시스템 사이에 꼭 연결된 통합을 건설하는 자바 어플리케이, 그리고 건설하기 위해 출발하고 있습니다.

ERP 벤더가 API를 출판할지라도, 그 어플리케이 서버 벤더 전부는 그것을 지원하는 것은 아닙니다. 또한, ERP 벤더에 대한 잠재한 logistical한 문제를 보여주면서, ERP 시스템의 고객은 던 다른 어플리케이 서버를 사용하고 있습니다.

각각의 시스템에 대해 인터페이스를 건설하거나 증명하는 대신에, ERP 벤더는 Connector Architecture를 사용하는 하나의 자원어댑을 새로 만듭니다. 이 자원어댑은 명시된 Connector Architecture 연결과 안전과 처리 계약을 구현합니다. 그리고 나서, 그 벤더는 이 사용가능한어댑을 만듭니다. 그리고 그들이 어떤 고분고분한 J2EE 어플리케이 서버도 가지고 일할 수 있다고 고객에게 알립니다. ERP 벤더는 또한 그것의 자원어댑에 CCI를 구현합니다. 클라이언트 구성요소로 접근을 직접적으로 엽니다. 또는 넓은 범위의 어플리케이 개발이나 EAI 도구A_NODE

넓은 다양한 고분고분한 J2EE 도구와 어플리케이 서버에 그것에게 조속한 통합과 일치한 작동[수술]를 주면서, Connector Architecture를 중요하게 사용하는 것은 ERP 벤더의 개발 노력을 감소시킵니다.

Business-to-Business 상업 해법

다음의 시나리오는 Business-to-Business 공급 사슬 해법에서의 Connector Architecture의 사용을 설명합니다.

Wombat Corporation은 그것의 공급자와 함께 상호작용을 개선하는 B2B 전자 상거래 해법을 구현하는 제조업자입니다. 대부분의 제조업자처럼, Wombat은 시스템을 처리하는 ERP 시스템과 mainframe 처리를 포함하는 그것의 현존하는 EIS 시스템에 거대한 투자를 가지고 있습니다.

작은곰 비슷한 유대동물은 고분고분한 J2EE에게 XML과 HTTP/HTTPS. Wombat을 사용하는 것이 B2B 서버 안으로 부지런히 일하는 재고의 자원어댑을 사용하는 그것의 EIS 시스템에 대한 접근을 통합하는 다중의 buyers/suppliers와 상호작용을 지원하는 어플리케이 서버 (called B2B server in this example)를 삽니다. 그것이 통합하는 EIS를 가지고 있음에 따라 작은곰 비슷한 유대동물은 많은 자원어댑으로서 전개할 수 있습니다. 그 시스템을 위한 다중의 "부지런히 일하세요" 자원어댑이 어플리케이를 위해 요구한 어플리케이 서버 깡통

이 시나리오는 중요한 포인트를 설명합니다. Connector Architecture는 꼭 연결된 통합을 새로 만들기 위해 설계됩니다 - 일반적으로, 그 엔터프라이의 안에 있는 통합 다른 회사 사이의 작동[수술]는 제조업자와 그것의 공급자 P?e 일반적으로 느슨하게 한쌍이 됩니다; 이것과 XML 동안, 메세지 송수신은 더욱 적절합니다.

커넥 아키텍쳐의 진화

Connector Architecture는 Java Community Process 프로그램의 생산품입니다. 그런데 그것은 자바 기술과 명세를 개발하고 교정하기 위해 자바 사회에 의해 사용된 열린 과정입니다. Connector 노력에 있는 태양의 동료는 EIS 벤더와 개발 도구 벤더와 EAI 벤더입니다. Key participants include BEA, Fujitsu, IBM, Inline, Inprise, iPlanet, Motorola, Oracle, SAP, Sybase, Tibco, and Unisys. 모든 주주가 그것의 채용[양자 입양]로부터 혜택을 받을 입장에 섬에 따라 그 표준을 데이트하는 것은 강한 산업 지원을 경험합니다.

J2EE Connector Architecture 명세의 1.0 석방[퇴원, 공개]는 그 인터페이스 전부와 잠재적으로 요구할 수 있는 시스템 계약을 언급한 것은 아닙니다. 그 1.0 석방[퇴원, 공개]의 목적은 어떤 면에서 필요를 누르는 것이 그 표준의 산업 채용[양자 입양]를 그만큼 서두르게 할 대부분을 언급하는 것이었습니다. 예를 들면, 그 1.0 석방[퇴원, 공개]는 위로 설명되면서 세 system-level 계약을 명시합니다. 이것은 그 인터페이스의 강제적인 구성요소입니다. 미래의 시스템 수준 계약은 Java Message Service (JMS)를 통해 실 관리와 메세지 송수신을 언급할 것입니다.

Common Client Interface (CCI)는 그 1.0 이행에서 선택적입니다. Connector Architecture는 자료 표현을 위한 메타 자료의 논점을 언급하고 도표로 나타내는 것을 타이프하지 않습니다. 그런데 그것은 확실히 CCI의 사용에서 관련성이 있게 될 것입니다. 이 논점은 미래 버전에 언급될 것입니다.

요약

JDBC API가 관계 데이타베이스를 통합하기 위해 자바 플랫포옴을 확장한 것처럼, Connector Architecture는 통합하고 그 엔터프라이에서 귀중한 과정과 자료를 관리하는 EIS를 확장하기 위해 J2EE 플랫포옴을 확장합니다. EIS에 있는 자료 성실[완전함]나 안전을 타협하지 않고, Connector Architecture는 귀중한 엔터프라이 자원에 대한 확장할 수 있는 간소화한 접근을 가능하게 합니다.

[정재동]

번역기로 돌려봤습니다. 편집해야 합니다. 편집해주세요~ 종종 다른놈들도 올려드리겠습니다. ^^/

[정재동]

출처:썬마이크로시스템즈