BEA WebLogic Platform™ 8.1기반의 애플리케이션을 위한 애플리케이션 아키텍처
by Bob Hensle
2005/02/14
개요
본 문서에서는 WebLogic Platform 8.1을 사용하여 구축한 소프트웨어 애플리케이션의 아키텍처 및 애플리케이션의 모범 사례를 소개하며 WebLogic Server, WebLogic Portal, WebLogic Integration, WebLogic Workshop 및 Liquid Data for WebLogic 등의 기술들을 설명합니다. 본 문서는 엔터프라이즈 설계자와 애플리케이션 설계자를 위해 작성된 것으로 4+1 View Model을 사용하여 WebLogic Platform 8.1 기반으로 구축된 애플리케이션의 아키텍처에 대해 살펴봅니다.
소개
소프트웨어 애플리케이션 아키텍처를 설명하기 위해 일반적으로 사용하는 모델이 4+1 View Model입니다. 이 모델의 5가지 뷰는 다음과 같습니다.
- 개발 뷰 ("구현 뷰"라고도 함)
- 물리적 뷰 ("배포 뷰"라고도 함)
- 프로세스 뷰 ("동시성 뷰"라고도 함)
- 논리적 뷰 ("디자인 뷰"라고도 함)
- 유스케이스 뷰 ("요구 사항 뷰,"라고도 하며, "4+1" "+1"에 해당됨)
4+1 View Model은 일반적으로 특정 소프트웨어 애플리케이션을 설명하는 데 사용됩니다. 이 문서에서는 4+1 View Model을 사용하여 BEA WebLogic Platform에 구축한 애플리케이션의 견고한 소프트웨어 아키텍처에 대해 설명합니다. 특히, 이 모델은 각 뷰에 관련된 모범 사례뿐만 아니라 일반적인 WebLogic Platform 컴포넌트에 대해 간략하게 설명합니다. 여기에서 다루는 제품 및 기능이 방대하기 때문에 개별 제품에 대해 깊이 다루지 않는 대신, 전체 플랫폼을 사용하여 유지 관리가 가능하고 견고한 아키텍처를 가진 소프트웨어 애플리케이션을 구축하는 방법을 설명하는 데 초점을 맞추도록 하겠습니다.
이 문서는 특정 소프트웨어 애플리케이션에 대해 설명하는 것이 아니므로 어떠한 유스케이스도 소개되지 않습니다. 이런 이유로 유스케이스 뷰에 대한 내용은 생략합니다. 마찬가지로 논리적 뷰에서 자세히 설명할 유스케이스 또한 없기 때문에 논리적 뷰에 대한 내용도 생략하기로 합니다. 뷰는 BEA WebLogic Platform을 사용하여 시스템을 구축하는 방법을 독자들이 이해하기 쉽게 순서대로 제시됩니다. 그러므로 특정 애플리케이션의 아키텍처에 대해 설명하는 경우 일반적으로 수행되는 순서는 다릅니다. 하지만 각 뷰는 자체에 포함된 방식대로 제시되므로 독자가 원하는 순서대로 뷰를 볼 수 있습니다.
이 문서는 제품 소개서나 제품의 자습서 또는 제품의 기능이나 내부 작동에 대한 설명서가 아닙니다. 추가 문서는 이 문서의 마지막 부분에 제시되어 있습니다. 이 문서를 읽으려는 독자는 4+1 View Model, 객체 지향적 분석 및 설계, J2EE에 대해 알고 있어야 하며 UML(Unified Modeling Language)에 대한 실제 경험이 있어야 합니다.
개발 뷰
다음 다이어그램은 WebLogic Platform 기반으로 구축한 애플리케이션의 개발 뷰(구현 뷰라고도 함)를 나타냅니다.
그림 1. 일반 WebLogic Platform 애플리케이션의 개발 뷰
개발 뷰에서 애플리케이션 아키텍처는 4개의 레이어로 구분됩니다.
- 프레젠테이션 및 인터페이스
- 비즈니스 프로세스
- 비즈니스 로직
- 데이터 액세스 및 통합
각 레이어는 전반적인 애플리케이션 아키텍처에 특정 기능을 제공합니다. 이러한 레이어에 따라 애플리케이션의 컴포넌트를 구분하고 모듈화하면 시스템의 유지 관리 기능은 향상됩니다. 또한 대규모 애플리케이션을 구축하는 경우 개발팀은 레이어 간 서로 다른 상호 작용을 수행하는 특정 레이어를 각각 맡아 작업을 수행합니다.
모든 애플리케이션에 이 모든 레이어가 다 있는 것은 아닙니다. 간단한 CRUD(create, read, update, delete) 애플리케이션의 경우 애플리케이션 스펙트럼의 한 쪽 끝에 프레젠테이션 및 인터페이스 레이어와 데이터 액세스 및 통합 레이어만 있습니다. 이렇게 간단한 애플리케이션은 비즈니스 로직을 포함하지도 않으며 다른 시스템에 대한 인터페이스도 제공하지 않습니다. 이 애플리케이션은 2계층으로 된 애플리케이션입니다. 애플리케이션 스펙트럼의 다른 끝은 프로세스 포털로, 여기에는 개인화된 인터페이스, 비즈니스 프로세스 실행, 복잡한 비즈니스 로직 및 다양한 백엔드 시스템(예: CRM, SCM 및 ERP)에 대한 액세스가 포함되어 있습니다.
레이어 간의 통신
모든 컴포넌트는 애플리케이션의 레이어나 모든 하위 레이어 내의 컴포넌트에만 액세스하도록 애플리케이션을 구축해야 합니다. 이러한 제한에 대한 예외는 거의 없어야 하고 명확하게 규정되어야 합니다. 컴포넌트는 인접하지 않은 하위 레이어에 액세스할 수 있습니다. 예를 들어, 프레젠테이션 및 인터페이스 레이어의 컴포넌트는 비즈니스 프로세스 레이어의 컴포넌트를 통하지 않고 비즈니스 로직 레이어의 컴포넌트에 직접 액세스할 수 있습니다. 그러나 각 레이어는 특정 목적을 위해 존재함을 명심하고 레이어를 임의로 바이패스하지 않아야 합니다.
WebLogic Platform에는 콜백 메커니즘이라는 것이 있는데, 처음 보기에는 상위 레이어에 액세스하여 하위 레이어에 대한 제한을 위반하는 것처럼 보입니다. 예를 들어, 프레젠테이션 레이어의 컴포넌트인 웹 서비스는 하위 비즈니스 로직 레이어의 컴포넌트인 사용자 정의 Java 컨트롤로부터 콜백을 수신할 수 있습니다. 그러나 콜백은 상위 레이어가 호출하는 하위 레이어 컴포넌트에 대해 상위 레이어 컴포넌트가 설정한 응답 채널입니다. 상위 레이어 컴포넌트는 콜백을 "초대"하고 수신하는 콜백에 대한 핸들러를 명시적으로 제공합니다. 그러므로 콜백은 레이어 간의 통신 규칙을 따르며 사실 상 컴포넌트 간 비동기 통신을 위한 간단한 메커니즘을 제공합니다.
레이어 구성 및 SOA
비즈니스 프로세스 컴포넌트와 비즈니스 로직 레이어의 컴포넌트를 프로그래밍 방식의 인터페이스를 통해 프레젠테이션 및 통합 레이어에 제공할 수 있습니다. 프로그래밍 방식의 인터페이스를 통해 제공하면 애플리케이션은 서비스 지향 아키텍처(SOA)에 공급자로서 참여할 수 있습니다. 데이터 액세스 및 통합 레이어를 통해 이러한 애플리케이션이 SOA에서 다른 시스템이 제공한 서비스를 이용할 수 있습니다. 다시 말해, 이러한 애플리케이션 아키텍처는 애플리케이션 간 비즈니스 로직 및 비즈니스 프로세스를 공유할 수 있는 진정한 SOA 구현에 도움을 주어 SODA(Service Oriented Development of Applications)을 통해 복합 애플리케이션을 원할하게 구축할 수 있도록 합니다.
다음 단원에서는 개발 뷰의 다양한 레이어에 대해 설명하고 각 레이어의 컴포넌트에 대해 간략한 개요를 제공합니다.
프레젠테이션 및 인터페이스 레이어
프레젠테이션 및 인터페이스 레이어는 애플리케이션에 대한 인터페이스를 제공합니다. 이 레이어는 웹 또는 포털 애플리케이션의 경우 브라우저 인터페이스의 형태가 될 수 있으며 리치 클라이언트 또는 또 다른 시스템의 경우 프로그래밍 방식의 인터페이스 형태가 될 수 있습니다. 브라우저 인터페이스는 원격으로 실행되고 HTTP 또는 보안 HTTP를 통해 애플리케이션에 액세스하는 반면 프로그래밍 방식의 인터페이스는 HTTP, SOAP, RMI, RMI/IIOP, ebXML 또는 RossettaNet을 사용할 수 있습니다.
웹 인터페이스는 애플리케이션에 가장 단순한 사용자 인터페이스를 제공합니다. 웹 브라우저 클라이언트 애플리케이션은 모든 웹 애플리케이션의 사용자 인터페이스를 호스트하는 플랫폼입니다. 브라우저에 표시되는 컨텐츠는 JavaScript에서 처리하는 클라이언트 측 프로세싱을 제외하고는 대부분 정적 컨텐츠입니다. 클라이언트 측 프로세싱은 일반적으로 간단한 초기 데이터 유효성 검사를 수행하거나 또는 사용자 인터페이스를 시각적으로 강화하기 위해 사용됩니다.
포털 인터페이스는 통일된 인터페이스에서 애플리케이션 및 정보에 대한 단일 액세스 지점을 제공합니다. 포털 인터페이스는 재사용 가능한 포털 리소스를 사용하는 다수의 사용자에게 사용자 정의된 컨텐츠 및 애플리케이션을 제공할 수 있습니다. 또한 포털 인터페이스를 통해 대량의 데이터를 쉽게 체계화 및 액세스할 수 있습니다. 이러한 점에서 포털 인터페이스가 B2C(business-to-consumer) 및 B2E(business-to-employee) 애플리케이션에 이상적입니다.
프로그래밍 방식의 인터페이스를 사용하면 다른 애플리케이션에서도 이러한 애플리케이션의 데이터, 비즈니스 프로세스 및 비즈니스 로직에 액세스할 수 있습니다. 프로그래밍 방식의 인터페이스는 이러한 애플리케이션과 클라이언트 애플리케이션 간 공적인 계약이기 때문에 설계 시 주의를 기울여야 합니다. 프로그래밍 방식의 인터페이스를 조금이라도 변경하면 클라이언트 애플리케이션에 심각한 영향을 미칩니다. 그러므로 이 인터페이스는 기본 구현을 추상화하여 클라이언트 애플리케이션에 변경 요청을 하지 않고 이러한 애플리케이션을 변경할 수 있도록 설계되어야 합니다.
WebLogic Platform은 HTTP, SOAP(즉, 웹 서비스), RMI, RMI/IIOP, ebXML 및 RossetaNet을 지원합니다. B2B(business-to-business) 애플리케이션의 경우 ebXML 및 RossetaNet은 당연한 선택이며 일반적으로 구축되는 애플리케이션의 요구 사항에 의해 결정됩니다. SOAP와 RMI/IIOP 중에서 무엇을 선택해야 하는지 명확하지는 않지만 SOAP 인터페이스가 일반적으로 RMI 또는 RMI/IIOP 보다 선호되고 있습니다. SOAP 인터페이스의 장점은 다음과 같습니다.
- 플랫폼 및 언어 독립성
- 다른 웹 서비스 아키텍처와의 상호 운용성
- 콜백 지원
- 사용하기 쉬운 비동기 및 대화형 의미
- SOA 지원
- XML(바이너리 아님) 인터페이스로 인해 유연한 인터페이스
- 문서 중심의 인터페이스로 더욱 간편하게 지원
RMI 또는 RMI/IIOP가 가진 장점은 성능입니다. SOAP 메시지의 구문 분석은 바이너리 프로토콜에서는 발생되지 않는 추가 오버헤드가 생성됩니다. 그러므로 성능이 주된 요구 사항일 경우 RMI 또는 RMI/IIOP를 선택하는 것이 좋습니다.
다음은 프레젠테이션 및 인터페이스 레이어에 나타난 각 컴포넌트, 이러한 컴포넌트와 나머지 애플리케이션과의 상호 작용, 컴포넌트와 관련한 설계 고려 사항을 설명한 것입니다.
-
Display - 그림 1에서 표시 컴포넌트는 실제로 브라우저가 포털을 표시하는 방법을 제어하는 WebLogic Portal 내의 다양한 구조를 모두 모아놓은 것입니다. 이러한 구조에는 외양과 느낌, 스킨, 주제, 레이아웃, 셸 등이 포함됩니다. 일반적으로 이러한 것들은 아키텍처에서 중요하지는 않지만 사용자 경험에 강렬한 효과를 줄 수 있습니다. WebLogic Portal의 이러한 구조는 포털 애플리케이션에 원하는 사용자 경험을 만들기 위해 쉽게 수정할 수 있으면서도 상당히 유연한 메커니즘을 제공합니다.
-
ebXML - ebXML 컴포넌트는 ebXML 사양에서 MSH(Message Service Handler)를 구현합니다. 이 컴포넌트는 ebXML 프로토콜을 사용하여 통신하려는 파트너업체를 위해 B2B 상호 작용을 위한 인터페이스를 제공합니다. 실제 파트너 상호 작용은 비즈니스 프로세스 레이어의 프로세스 정의에 의해 실행됩니다.
-
HTML - HTML 페이지는 아키텍처 내에서 정적 컨텐츠를 제공하는 데 사용됩니다. HTML 페이지는 독립 실행형이거나 페이지 플로우의 일부일 수 있습니다. 페이지 탐색은 HTML 페이지 중에서 추상화하고 해당 HTML 페이지가 포함된 페이지 플로우의 JPF(Controller) 파일에 넣어두는 것이 좋습니다. HTML 페이지는 포털 인터페이스 또는 웹 인터페이스에서 사용될 수 있습니다.
-
Image - 이미지는 페이지 내에 정적 컨텐츠를 제공합니다. 페이지에 이미지가 크거나 너무 많으면 성능이 저하될 수 있습니다. 이미지는 포털 인터페이스의 일부이거나 웹 인터페이스의 일부일 수 있습니다.
-
Java Server Page - JSP(Java server pages)는 아키텍처 내에서 페이지에 동적 컨텐츠를 제공하기 위해 사용됩니다. JSP 내에 Java 코드가 전혀 없거나 조금 있어야 하고 오히려 태그 라이브러리(예: netui, content, es)를 사용해야 합니다. JSP의 Java 코드는 데이터 액세스 및 데이터 표시에 사용해야 합니다. JSP의 Java 코드가 비즈니스 로직을 제공해서는 안됩니다. 또한 페이지 탐색도 JSP에 있으면 안되고 차라리 JSP가 포함된 페이지 플로우의 JPF(Controller) 파일로 추상화해야 합니다. JSP는 포털 인터페이스 또는 웹 인터페이스에서 사용될 수 있습니다.
-
Page Flow - 일반적으로 페이지 플로우는 JPF(또는 Controller) 파일 및 JSP 모음으로 구성되어 있습니다. JPF 파일은 포털 인터페이스 또는 웹 인터페이스 내에서 페이지 탐색을 제공합니다. 또한 일반적으로 사용자 인터페이스를 나머지 아키텍처에 연결하는 Java 코드가 포함되어 있습니다. Java 컨트롤은 일반적으로 JPF 파일 내에서 아키텍처의 다른 레이어에 액세스하는 데 사용되는 메커니즘입니다. 대규모 웹 애플리케이션의 경우 커다란 페이지 플로우 하나를 개발 및 유지하는 것 보다 페이지 플로우를 여러 개 만드는 것이 더 좋습니다. 이 경우 페이지 플로우는 더 큰 애플리케이션 내의 기능 영역을 나타냅니다.
BEA는 Apache Software Foundation에 페이지 플로우의 소스를 공개하여 WebLogic 기반 개발 뿐만 아니라 모든 Java 개발에서 사용할 수 있습니다.
-
Portal - 포털 컴포넌트는 애플리케이션 로직 또는 웹 페이지에 독립적으로 포털 인터페이스를 만들 수 있는 강력한 프레임워크입니다. 포털에서 사용자는 포틀릿이라고 하는 개개인의 창에서 각 애플리케이션 또는 웹 페이지를 볼 수 있으며 단일 브라우저 창에 여러 포틀릿을 포함할 수 있습니다. 대형 포털의 경우 포털을 동시에 개발할 수 있도록 작게 나누는 것이 더 나을 수 있습니다. 이러한 방법은 .pinc 및 .portion 파일을 사용하면 지원됩니다.
-
Portlet - 포틀릿은 포털의 일부입니다. 포틀릿에는 HTML, JSP, 웹 플로우, 페이지 플로우, struts, .pinc, JSR 168 포틀릿 또는 WSRP 프록시 포틀릿이 포함됩니다. 포틀릿은 애플리케이션 작업이 포털 내부에서 수행되는 경우 효과적입니다. 기본적으로 포털 내의 각 포틀릿은 순차적으로 또는 병렬(옵션)로 자체 정보를 로드합니다. 하지만 모든 포틀릿에서 로드가 완료할 때까지 포털 페이지를 표시할 수 없습니다. 그러므로 하나의 포틀릿으로 인해 전체 포털이 너무 느리게 표시되지 않도록 일부 포틀릿에서 비동기 로드 메커니즘을 제공하는 것이 필요할 수 있습니다.
-
RosettaNet - RosettaNet 컴포넌트는 RosettaNet 프로토콜을 사용하여 통신하려는 파트너 기업과의 B2B 상호 작용을 위한 인터페이스를 제공합니다. RosettaNet PIP는 비즈니스 프로세스 레이어에서 프로세스 정의로서 구현됩니다.
-
Servlet - 과거 서블릿은 웹 애플리케이션의 Model-View-Controller 패턴에서 Controller로 사용되었습니다(JavaServer Pages Model 2 아키텍처 이해 참조). 페이지 플로우는, 특히 JPF 파일에서 WebLogic Platform 내에 이러한 기능을 제공하므로 서블릿은 거의 사용되지 않습니다.
-
Style Sheet - CSS(Cascading style sheets)는 웹 애플리케이션에 일관성있는 스타일을 만드는 데 사용됩니다. 포털 애플리케이션의 경우 표시 컴포넌트에 스타일 시트가 포함됩니다. 그러나 스타일 시트는 비포털 인터페이스에도 적용할 수 있으므로 표시 컴포넌트와 분리될 수 있습니다.
-
Web service - 웹 서비스는 애플리케이션에 프로그래밍 방식의 인터페이스를 제공합니다. 이 인터페이스는 JWS(Java Web service) 파일에서 정의되고 WSDL을 통해 클라이언트에게 제공됩니다. JWS 파일에는 데이터 유효성 검사 및 번역 로직만 포함해야 하고 모든 비즈니스 로직은 아키텍처의 하위 레이어에 위임해야 합니다. 대화형 웹 서비스의 경우 JWS 파일은 로컬 변수에 상태 정보를 포함할 수 있습니다. 이 변수는 대화 상태를 저장할 수 있도록 serialize해야 합니다.
BEA는 Apache Software Foundation에서 사용자 정의 컨트롤 프레임워크의 소스를 공개하여 WebLogic 기반 개발 뿐만 아니라 모든 Java 개발에 이 프레임워크를 사용할 수 있도록 했습니다.
비즈니스 프로세스 레이어
그림 1에서 표시한 비즈니스 프로세스 레이어는 비즈니스 프로세스 관리(BPM; Business Process Management)를 제공합니다. 비즈니스 프로세스는 프로세스 정의 또는 프로세스 정의의 조합으로 생성됩니다. 비즈니스 프로세스는 완전히 자동화된 프로세스일 수도 있고 또는 시스템과 사용자와의 상호 작용이 포함된 프로세스일 수도 있습니다. 비즈니스 프로세스에서 사용자의 간섭이 필요한 경우 프로세스 정의에 인터페이스 지점을 제공하기 위해 작업 목록 컨트롤이 사용됩니다.
비즈니스 프로세스 레이어는 프레젠테이션 또는 시스템이나 사용자에 대한 인터페이스와는 관련이 없습니다. 오히려 프레젠테이션 및 인터페이스 레이어는 비즈니스 프로세스가 자동(프로그래밍 방식의 인터페이스)화된 프로세스이거나 사용자와 상호 작용하는 프로세스이거나 상관 없이 모든 비즈니스 프로세스에 대한 사용자 인터페이스를 제공합니다. 비즈니스 프로세스 레이어에서 개발된 코드에는 프레젠테이션 또는 인터페이스 로직이 없어야 합니다.
다음 단원에서는 비즈니스 프로세스 레이어에 나타나는 각 컴포넌트, 나머지 애플리케이션과 컴포넌트와의 상호 작용 및 컴포넌트와 관련된 설계 고려 사항에 대해 설명합니다.
프로세스 정의
프로세스 정의 컴포넌트는 비즈니스 프로세스를 캡처하는 데 사용되며 비즈니스 프로세스 레이어의 핵심입니다. 프로세스 정의는 특정 프로세스를 암호화해야 하고Java에서 비즈니스 로직을 작성하기 위한 대안으로 사용해서는 안됩니다. 중요한 것은 프로세스 정의가 개별적인 비즈니스 로직 컴포넌트 사이의 상호 작용을 연결 및 조정하는 것입니다.
애플리케이션에는 몇몇 상위 레벨 프로세스에서 하위 레벨 프로세스를 공통적으로 가지고 있는 경우가 많이 있습니다. 이와 마찬가지로 프로세스 정의 컴포넌트는 상위 레벨 프로세스를 모델링할 수 있고, 차례로 하위 레벨 프로세스를 모델링하는 다른 프로세스를 호출할 수 있습니다. 애플리케이션의 유스케이스를 분석해 보면 다른 유스케이스에 포함되어 있는 유스케이스가 바로 이러한 유형의 재사용 가능한 프로세스 정의에 주로 해당됩니다.
프로세스 정의는 클라이언트 요청(즉, 동기적으로) 또는 메시지 브로커로부터 도착하는 메시지(즉, 비동기적으로)를 통해 시작될 수 있습니다. 클라이언트 요청으로 시작된 프로세스 정의는 클라이언트가 응답을 기다리면서 차단되어 있기 때문에 최대한 빨리 클라이언트에게 응답을 해야 합니다. 요청이 오래 걸리거나 얼마나 걸릴지 알 수 없는 경우 프로세스 정의는 클라이언트에게 "처리 중"이라는 메시지와 함께 응답을 보내고 요청을 비동기적으로 처리해야 합니다. 이 때가 특히 콜백을 유용하게 사용할 수 있는 경우입니다.
프로세스 정의는 JPD(Java Process Definition) 파일에 설명되어 있습니다. WebLogic Workshop은 JPD 파일의 그래픽 뷰를 제공합니다. 개발자는 프로세스 정의 내에서 사용되는 .jpd 파일에 Java 코드를 선택적으로 추가할 수 있습니다. 이 코드는 해당 프로세스 정의에만 사용할 수 있기 때문에 재사용되지 않으므로 크기를 최소화해야 합니다. 하나의 프로세스 정의 보다 더 많은 고객에게 사용될 수 있는 코드는 별도의 Java 클래스, EJB 또는 사용자 정의 Java 컨트롤에 넣어두어야 합니다.
프로세스 컨트롤
프로세스 컨트롤은 프로세스 정의에 액세스하는 데 사용됩니다. 이 컨트롤은 페이지 플로우, 웹 서비스, 또 다른 프로세스 정의 또는 사용자 정의 컨트롤 등 다양한 다른 컴포넌트 내에서 사용해야 합니다. 프로세스 컨트롤은 JCX 파일이고 WebLogic Workshop의 프로세스 정의(JPD) 파일에서 자동으로 생성할 수 있습니다.
작업 목록 컨트롤
작업 목록 컨트롤을 사용하면 프로세스 정의를 사용자 작업이 포함된 비즈니스 프로세스에서 사용할 수 있습니다. 작업 목록 컨트롤을 사용하여 프로세스 정의는 사용자에게 작업을 할당하고 작업이 완료되면 사용자가 프로세스 정의에 알리도록 할 수 있습니다. 작업 목록 컨트롤의 두 가지 유형은 작업 컨트롤 및 작업자 컨트롤입니다.
Publish 컨트롤
게시 컨트롤을 사용하여 프로세스 정의는 메시지를 메시지 브로커의 채널에 게시할 수 있습니다. 그러면 프로세스 정의는 메시지를 또 다른 프로세스 정의로 전달할 수 있어서, 또 다른 프로세스 정의를 시작하거나 이 메시지를 기다리기 위해 중지되었던 지점에서 프로세싱을 다시 시작하도록 할 수 있습니다. 이것이 애플리케이션이 비즈니스 프로세스에 대한 비동기 프로세싱을 초기화하는 데 사용하는 기본 메커니즘입니다.
Subscribe 컨트롤
구독 컨트롤을 사용하여 프로세스 정의는 특정 채널에 전달된 메시지 브로커로부터 메시지를 기다릴 수 있습니다. 이것이 비동기 프로세싱을 초기화하거나 지속하는 기본 메커니즘입니다.
비즈니스 로직 레이어
모든 비즈니스 로직은 그림 1과 같이 비즈니스 로직 레이어에 구현됩니다. 요청 처리 시 이 레이어의 컴포넌트는 고유한 비즈니스 규칙에 따라 요청에서 정보의 유효성을 검사하고, 요청된 비즈니스 로직을 수행하고, 적절한 외부 엔티티를 생성, 읽기, 수정 또는 삭제하기 위해 데이터 액세스 및 통합 레이어를 호출할 수도 있습니다. 가장 일반적인 외부 엔티티는 관계형 데이터베이스입니다.
비즈니스 로직 레이어 내의 컴포넌트는 비즈니스 프로세스 레이어 또는 프레젠테이션 및 인터페이스 레이어에서 호출됩니다. 비즈니스 프로세스 레이어에서 컴포넌트를 호출하면 이 컴포넌트는 프로세스 정의의 일부로 사용됩니다. 이것이 공통적인 비즈니스 로직을 여러 비즈니스 프로세스에서 사용할 수 있는 방법입니다.
비즈니스 로직 레이어 컴포넌트를 프레젠테이션 및 인터페이스 레이어에서 호출하면 이 컴포넌트는 사용자 요청을 수행합니다. 이것이 J2EE 애플리케이션 내에서 가장 일반적으로 사용되는 설계 패턴입니다. 그러나 J2EE 애플리케이션에서 비즈니스 프로세스를 서블릿 또는 세션 빈에 하드 코딩하기도 합니다. 비즈니스 프로세스를 프로세스 정의 또는 페이지 플로우에 추상화하면 애플리케이션의 유연성 및 유지 관리 기능이 향상됩니다.
다음 단원에서는 비즈니스 로직 레이어에 나타난 각 컴포넌트, 이러한 컴포넌트와 나머지 애플리케이션과의 상호 작용, 컴포넌트 관련 설계 고려 사항에 대해 설명합니다.
사용자 정의 컨트롤
사용자 정의 컨트롤은 재사용 가능한 기능을 암호화하는 Java 컨트롤입니다. 사용자 정의 컨트롤은 JCS(Java control source) 파일 및 관련 Java 파일에서 생성됩니다. 사용자 정의 컨트롤은 애플리케이션 또는 패키지 내에서 사용할 수 있어서 여러 애플리케이션에서 사용할 수 있습니다. 그러므로 사용자 정의 컨트롤은 EJB와 유사합니다. 그러나 사용자 정의 컨트롤은 EJB 보다 다음과 같은 장점이 있습니다.
- 다른 Java 컨트롤 사용 가능
- 확장 가능
- 콜백을 통해 비동기 지원
BEA는 Apache Software Foundation에 사용자 정의 컨트롤 프레임워크의 소스를 공개하여 WebLogic 기반 개발뿐만 아니라 모든 Java 개발에 사용할 수 있도록 했습니다.
EJB 컨트롤
EJB 컨트롤은 세션 또는 엔티티 빈을 호출하는 데 사용됩니다. 이 컨트롤은 모든 초기 컨텍스트 조회, 홈 인터페이스 액세스 등을 관리하고 개발자가 원하는 기능을 수행하는 EJB에서 메서드를 호출할 수 있도록 합니다.
메시지 드리븐 빈
메시지 드리븐 빈(MDB)은 JMS 항목 또는 대기열의 메시지를 처리하는 데 사용됩니다. MDB는 WebLogic Workshop을 사용하여 손쉽게 개발 및 배포할 수 있습니다. MDB에는 비즈니스 로직을 포함하지 않아야 하며, JMS에서 메시지를 수신하고, 데이터 유효성 검사 및 변환을 수행한 다음 비상태유지 세션 빈 또는 재사용 가능한 비즈니스 로직을 포함하는 다른 컴포넌트를 호출해야 합니다.
상태유지 세션 빈
상태유지 세션 빈(SFSB)은 클라이언트와의 상태유지 상호 작용을 제공하는 데 사용됩니다. SFSB는 WebLogic Workshop을 사용하여 손쉽게 개발 및 배포할 수 있습니다. 대부분의 경우 특정 상황에만 사용하도록 제한된 SFSB 보다 상태유지 세션 빈이 더 많이 사용됩니다.
비상태유지 세션 빈
비상태유지 세션 빈(SLSB)은 비즈니스 로직을 암호화하는 데 사용됩니다. 상태유지 세션 빈과 달리SLFS는 뛰어난 확장성 및 성능을 제공합니다. SLSB는 WebLogic Workshop을 사용하여 손쉽게 개발 및 배포할 수 있습니다.
타이머 컨트롤
타이머 컨트롤은 특정 기간이 경과되거나 지정한 시간에 도달한 경우 이를 애플리케이션에 통지합니다. 타이머 컨트롤을 사용하여 비즈니스 프로세스를 시작하거나 특정 시간 동안 이벤트(예: 응답 메시지 수신)가 발생하기를 기다릴 수 있습니다.
데이터 액세스 및 통합 레이어
데이터 액세스 및 통합 레이어의 컴포넌트는 애플리케이션 외부의 EIS(Enterprise Information Systems)에서 데이터를 송수신합니다. 가장 일반적인 EIS는 데이터베이스 관리 시스템입니다. 이 레이어는 다양한 EIS와 통신하는 복잡성을 암호화하기 위해 필요합니다.
오늘날 기업에서는 애플리케이션이 단순한 데이터베이스 보다 훨씬 다양한 EIS로 통합되고 있습니다. 메인 프레임에서 독점 레거시 시스템에 이르기까지 수많은 외부 시스템은 모두 애플리케이션으로 데이터를 보내거나 애플리케이션에서 데이터를 수신하는 대상이 될 수 있습니다. SOAP(Simple Object Access Protocol)를 사용하는 웹 서비스, JMS(Java Messaging Service)를 지원하는 다양한 메시징 서비스, 다양한 J2EE CA(J2EE Connector Architecture) 사양 구현은 데이터 액세스 및 통합 레이어에서 구성할 수 있는 통합 전송 컴포넌트의 예입니다. 이러한 각 컴포넌트는 정보를 전달 또는 검색하기 위해 EIS에서 API를 호출합니다.
다음은 데이터 액세스 및 통합 레이어에 나타난 각 컴포넌트, 이 컴포넌트와 나머지 애플리케이션과의 상호 작용, 컴포넌트 관련 설계 고려 사항에 대한 설명입니다.
-
애플리케이션 뷰 - 애플리케이션 뷰 컴포넌트는 J2EE CA 어댑터를 암호화하고 애플리케이션과 기본 EIS 사이의 추상화 수준을 제공합니다. 애플리케이션 뷰를 사용하여 개발자는 개발되는 애플리케이션에 적절한 인터페이스를 프로그래밍할 수 있고 기본 EIS의 복잡성을 숨깁니다. 또한 애플리케이션 코드에 전혀 영향을 주지 않고 J2EE CA 어댑터를 변경할 수 있습니다.
J2EE CA 어댑터에는 몇 가지가 있습니다. Type 1 어댑터는 BEA에서 사용할 수 있는 제품이고 가장 일반적인 EIS를 지원합니다. Type 2 어댑터(필드 기반 어댑터라고도 함)는 그 보다는 덜 일반적인 EIS를 지원하고 BEA 필드 기반 어댑터 그룹에서 사용할 수 있습니다. Type 3 어댑터는 BEA 파트너에서 사용할 수 있습니다. 사용자 정의 J2EE 어댑터를 항상 애플리케이션 개발 노력의 일환으로 구성할 수 있습니다. 하지만 굳이 사용자 정의 어댑터를 구축해야 할 이유가 없다면 Type 1, 2 및 3 어댑터를 사용하는 것이 좋습니다.
-
데이터베이스 컨트롤 - 데이터베이스 컨트롤은 관계형 데이터베이스에 있는 데이터에 액세스하기 위해 사용됩니다. 데이터베이스 컨트롤은 데이터를 RowSet, XML 또는 Java 객체로 반환할 수 있습니다. 이러한 데이터베이스 컨트롤은 JDBC 코드를 코딩하거나 엔티티 빈을 사용하는 것 보다 편리하게 관계형 데이터베이스에 액세스할 수 있는 메커니즘을 제공합니다./p>
BEA는 Apache Software Foundation에서 사용자 정의 컨트롤 프레임워크의 소스를 공개하여 WebLogic 기반 개발 뿐만 아니라 모든 Java 개발에 이 프레임워크를 사용할 수 있도록 했습니다.
-
이메일 컨트롤 - 이메일 컨트롤은 메일을 보내는 데 사용됩니다. 이메일 컨트롤을 사용하여 첨부 파일을 포함한 일반적인 이메일 필드(예: 받는 사람, 참조, 숨은 참조, 제목)를 사용할 수 있습니다.
-
엔티티 빈 - 엔티티 빈은 객체 지향 J2EE와 관계형 데이터베이스를 연결하는 데 필요한 객체 대 관계 매핑을 제공합니다. 또한 엔티티 빈은 거의 다 읽거나 데이터만 읽기 위한 강력한 캐싱 메커니즘을 제공합니다. 엔티티 빈은 WebLogic Workshop을 사용해서 손쉽게 개발 및 배포할 수 있습니다.
일반적으로 CMP(Container Managed Persistence) 엔티티 빈을 사용하면 개발자가 JDBC 코드를 개발해야 하는 수고를 덜어주기 때문에 가능하다면 Bean Managed Persistence 엔티티 빈 보다 CMP 엔티티 빈을 더 많이 사용해야 합니다.
-
파일 컨트롤 - 파일 컨트롤은 파일 시스템에 있는 파일을 읽거나 작성 또는 보류하는 데 사용됩니다. 파일 유형은 XmlObject, Binary(원시 데이터) 또는 String 중 하나일 수 있습니다. 또한 파일 컨트롤은 복사, 이름 바꾸기 및 삭제 같은 파일 작업을 지원합니다. 더욱이 파일 컨트롤을 사용하여 지정한 디렉터리에 저장된 파일을 나열할 수도 있습니다.
-
JMS 컨트롤 - JMS 컨트롤은 JMS 대상으로 메시지를 전송하거나 JMS 대상에서 메시지를 검색하는 데 사용됩니다. 메시징 시스템(예: MQSeries, Tibco)은 레거시 시스템에 액세스하는 데 자주 사용됩니다. 이 컨트롤은 이러한 메시징 시스템 및 레거시 시스템과 인터페이스하기 위한 편리한 메커니즘을 제공합니다./p>
-
Liquid Data 컨트롤 - Liquid Data 컨트롤은 Liquid Data for WebLogic에서 제공하는 데이터에 액세스하는 데 사용됩니다. 이 컨트롤은 Liquid Data for WebLogic이 가져오고 집계한 다양한 EIS의 데이터를 통합할 수 있는 편리한 메커니즘을 제공합니다.
Liquid Data는 EIS 내에서 데이터 쿼리 및 데이터 집계를 생성할 수 있는 사용하기 편하고 강력한 툴입니다. 여러 백엔드 데이터 소스의 데이터를 집계하기 위해 사용자 정의 코드를 작성해서는 안됩니다. Liquid Data가 그런 작업을 간단히 수행할 수 있으며 집계된 데이터에 대해 구성 가능한 캐싱을 추가로 제공합니다.
-
TPM 컨트롤 - TPM(Trading Partner Management) 컨트롤은 거래 파트너 및 TPM 리포지토리에 저장된 서비스 정보에 액세스하기 위한 쿼리(읽기 전용)를 제공합니다. 이 컨트롤은 예를 들어 ebXML B2B 프로세스 정의의 일부로 사용될 수 있습니다.
-
변환 컨트롤 - 변환 컨트롤은 데이터 변환을 수행하는 데 사용됩니다. 바이너리에서 XML로, XML에서 바이너리로, 또는 XML에서 XML로 변환할 수 있습니다. 그러므로 모든 포맷 변환은 Workshop 내에서 쉽게 정의되고 사용됩니다. XML에서 XML로 변환은 변환 시 XSLT를 사용하는 것 보다 빠르고 유연한 Xquery의 기능을 사용합니다.
-
웹 서비스 컨트롤 - 웹 서비스 컨트롤은 웹 서비스에 액세스하는 데 사용됩니다. WSDL(Web service Description Language) 파일을 사용할 수 있는 모든 웹 서비스는 이 컨트롤을 통해 액세스할 수 있습니다.
BEA는 Apache Software Foundation에서 사용자 정의 컨트롤 프레임워크의 소스를 공개하여 WebLogic 기반 개발 뿐만 아니라 모든 Java 개발에 이 프레임워크를 사용할 수 있도록 했습니다.
-
XMLBeans - XMLBeans는 개발자에게 친숙한 XML 인터페이스를 제공합니다. XMLBeans는 XML 스키마를 Workshop 애플리케이션의 스키마 디렉터리로 가져오면 생성됩니다. Workshop은 Workshop 개발 환경에서 사용할 수 있는 적절한 Java 클래스를 자동으로 생성합니다.
XMLBeans는 JAXB, DOM 또는 SAX 보다 사용하기가 훨씬 쉽습니다. XMLBeans는 커서로 XML 데이터를 간단하게 탐색할 수 있는 효율적인 XML 토큰 스트림에 기반을 두고 있습니다. XMLBeans는 원래 XML의 구조 및 서식을 그대로 유지합니다. BEA는 Apache Software Foundation에 XMLBeans의 소스를 공개하여 WebLogic 기반 개발 뿐만 아니라 모든 Java 개발에 사용할 수 있습니다.
데이터베이스 액세스 옵션
J2EE는 JDBC, 엔티티 빈 및 JDO(Java Data Objects)를 비롯한 관계형 데이터베이스에 액세스할 수 있는 몇 가지 메커니즘을 제공합니다. 이러한 메커니즘 이외에 BEA WebLogic Platform은 데이터베이스 컨트롤 및 Liquid Data를 추가합니다.
Data Access Object 설계 패턴을 사용하여 수많은 J2EE 애플리케이션을 작성해 왔습니다. 이 패턴에서는 개발자가 JDBC를 사용하여 데이터베이스 액세스 코드를 전부 작성해야 합니다. 데이터베이스 컨트롤을 사용하여 Data Access Object 설계 패턴을 훨씬 쉽고 빠르게 구성할 수 있습니다. 데이터베이스 컨트롤을 사용하면 개발자가 SQL을 지정할 수 있어서 지겨운 JDBC 코드를 작성해야 하는 수고를 덜어줍니다.
EJB 1.1 사양의 결점으로 인해 많은 경우 Data Access Object 설계 패턴이 엔티티 빈 대신 사용되었습니다. EJB 2.0 사양은 로컬 인터페이스 및 강력한 CMP를 제공하여 EJB 1.1 엔티티 빈과 관련된 주요 문제를 해결했습니다. 그러므로 기본 관계형 스키마를 숨기는 객체 지향 지속성 레이어를 제공해야 하거나 제공하기를 원할 경우 CMP 엔티티 빈을 사용해야 합니다. 그러면 Java 코드에서의 객체 대 관계 매핑이 배포 설명자로 이동됩니다.
많은 애플리케이션의 경우 기본 관계형 스키마를 숨기는 객체 모델을 구성해야 할 필요는 없습니다. 일반적으로 이러한 유형의 애플리케이션은 많은 경우 서블릿에서 직접 JDBC를 사용했습니다. WebLogic Platform의 경우 데이터베이스 컨트롤이 이러한 유형의 애플리케이션에 권장되는 접근 방식입니다. 데이터베이스 컨트롤은 SQL 선택의 결과를 결과 세트, Java 객체 또는 XML로 반환할 수 있습니다. 페이지 플로우 및 데이터 바인딩 JSP 태그와 결합된 데이터베이스 컨트롤을 사용하여 RAD(Rapid Application Development)를 실현할 수 있습니다.
Liquid Data는 다른 데이터베이스 액세스 옵션과는 근본적으로 다릅니다. Liquid Data는 데이터 소스에 대한 쓰기 액세스를 제공하지 않습니다. 이것은 다양한 데이터 소스(데이터베이스, 파일, J2EE CA, 웹 서비스 등)에서 데이터를 집계하고 집계된 데이터를 XML 문서로 반환하도록 특별히 설계되었습니다. 단일 데이터베이스에서 데이터를 집계하려면 SQL join에서 데이터베이스 컨트롤을 사용하고 결과를 XML로 반환하십시오. 하지만 둘 이상의 데이터 소스에서 데이터를 집계하려면 Liquid Data를 사용하는 것이 적절합니다.
이것으로 개발 뷰에 관련된 다양한 레이어에 대한 설명을 마칩니다. 다음 단원에서는 4+1 View Model의 물리적 뷰에 대해 설명합니다.
물리적 뷰
물리적 뷰(배포 뷰라고도 함)는 애플리케이션을 배포할 하드웨어를 보여 줍니다. 또한 애플리케이션의 어느 부분을 하드웨어의 어느 물리적 위치에 배포할 것인지를 설명해 줍니다.
이 단원에서 설명하는 하드웨어 및 소프트웨어 배포는 WebLogic Platform에 구축한 애플리케이션의 배포 방법을 보여주는 한 가지 예로, "가장 일반적"이거나 "모범 사례" 아키텍처를 나타냅니다. 그러나 가능한 구성 방법은 여러 가지가 있습니다. 실제 아키텍처는 실제 애플리케이션에 따라 달라지며 예산, 현실성, 가용성, 확장성, 보안, 기존 네트워크 및 컴퓨팅 리소스 등 서로 상충되는 수많은 제한 요인과 균형을 맞춥니다.
하드웨어 배포
그림 2는 WebLogic Platform을 기반으로 구축한 애플리케이션을 배포할 수 있는 일반적인 하드웨어 환경을 보여 줍니다.
그림 2. 일반적인 하드웨어 환경
이 다이어그램은 웹 계층 및 애플리케이션 계층에 모두 3개의 서버가 있습니다. 이러한 계층은 서버 수에 제한이 없습니다. 또한 각 서버는 하나 또는 여러 CPU를 가질 수도 있습니다. 다음 단원에서는 이러한 하드웨어 환경에 대해 설명합니다.
클라이언트
이 하드웨어 아키텍처에는 인터넷 클라이언트, 인트라넷 클라이언트 및 내부 클라이언트 등 3가지 클라이언트가 있습니다. 이것은 순전히 클라이언트를 보여주기 위한 것이며 네트워크에 연결되어 있습니다. 그럼에도 불구하고 더 많은 고객이 시스템에서 승인되지 않은 액세스를 방지하기 위해 더 많은 보안 레이어를 필요로 한다는 것을 보여 줍니다.
설명한 각 클라이언트는 브라우저(HTTP 사용)를 통하거나 웹 서비스(SOAP 사용)를 통하거나, RMI 또는 RMI/IIOP(HTTP를 통해 터널링됨)를 통하거나, 심지어 ebXML 또는 RosettaNet 같은 B2B 프로토콜을 통해 시스템에 액세스할 수 있습니다. 액세스 프로토콜에 상관없이 요청은 소프트웨어 아키텍처의 프레젠테이션 및 인터페이스 레이어에서 처리됩니다.
방화벽
이 하드웨어 아키텍처에는 3개의 방화벽이 나타나 있습니다. 첫 번째 방화벽은 유해한 인터넷 사용자로부터 웹 계층을 보호합니다. 두 번째 방화벽은 애플리케이션 계층을 보호하고, 세 번째 방화벽(옵션)은 기업 데이터가 포함된 EIS 레이어를 보호합니다.
웹 계층
웹 계층은 첫 번째 방화벽과 두 번째 방화벽 사이에 존재합니다. 이것을 DMZ이라고도 합니다. 이 레이어의 주요 기능은 인터넷과 기업의 다른 컴퓨팅 환경 사이에 보안 레이어를 제공하는 것입니다. 또한 웹 계층은 로드 밸런싱 및 정적 컨텐츠 제공과 같은 다른 기능도 제공합니다. SSO(Single-Sign-On)를 원할 경우 일반적으로 초기 인증이 이 계층에서 수행됩니다.
웹 계층의 컴퓨팅 리소스는 웹 서버 팜(예: Apache, Netscape, IIS, BEA WebLogic Express)을 실행하는 데 사용됩니다. 이 계층에 배포된 애플리케이션 코드가 없어야 합니다. 정적 컨텐츠(즉, 이미지 및 HTML)만 이 계층에서 수행되어야 합니다. 애플리케이션에 대한 클라이언트 요청은 웹 서버에 설치된 WebLogic 프록시를 통해 애플리케이션 계층으로 전달됩니다.
애플리케이션 계층
애플리케이션 계층은 애플리케이션이 배포되어 있는 계층입니다. 애플리케이션 아키텍처의 4가지 레이어(그림 1 참조)가 이 계층에 배포됩니다. 고가용성을 원할 경우 WebLogic 클러스터를 배포 프로세스의 일부로 구성해야 합니다. 이 다이어그램은 WebLogic 도메인의 존재를 보여 줍니다. 하드웨어는 하나 또는 여러 WebLogic 도메인을 호스트할 수 있고 각 도메인은 하나 또는 여러 애플리케이션을 가질 수 있습니다.
J2EE는 웹 컨테이너 및 EJB 컨테이너를 정의하기 때문에 일부 기업에서는 별도의 하드웨어 계층에 이러한 컨테이너를 배포하기도 합니다. 이것은 WebLogic Platform을 사용할 경우 권장되는 접근 방법이 아닙니다. 웹 컨테이너를 EJB 컨테이너와 분리하면 애플리케이션의 배포가 더 어려워지고 심각한 성능 저하가 발생됩니다. 성능 저하는 추가 네트워크 왕복 및 네트워크 점검에 필요한 마샬링 및 디마샬링(demarshalling)으로 인한 것입니다. 반대로 애플리케이션을 단일 EAR 파일로 배포하는 경우 로컬 인터페이스 및 pass by reference를 애플리케이션 컴포넌트 간 호출에 사용할 수 있습니다.
EIS 계층
EIS(Enterprise Information Systems) 계층은 비즈니스 도메인에 대한 모든 정보를 주로 저장하는 곳입니다. 오늘날 기업에서는 이러한 데이터를 기업 데이터베이스 관리 시스템, 레거시 또는 메인 프레임 시스템, COTS(Commercial-Off-The-Shelf) 제품(예: Siebel, SAP, PeopleSoft), 메시징 전송이나 웹 서비스 배후에서 추상화한 알려지지 않은 장소에 저장할 수 있습니다.
소프트웨어 배포
다음 그림은 위의 그림 2에서 보여준 애플리케이션 계층에 애플리케이션을 배포한 것입니다.
그림 3. 애플리케이션 계층에 애플리케이션 배포
이 그림은 애플리케이션 계층의 3개 서버에 배포한 단일 클러스터 애플리케이션을 보여 줍니다. 이것은 WebLogic Platform 기반에 구축한 애플리케이션을 가장 단순하게 배포하는 방법이지만 다른 가능성도 많이 있습니다. 다음 다이어그램은 또 다른 배포 유형을 보여 줍니다.
그림 4. 포털 애플리케이션 및 BPM
이 그림은 단일 서버에 배포된 BPM(Business Process Management)에 대한 별도의 클러스터 애플리케이션에 있는 두 서버 상의 포털 애플리케이션을 보여 줍니다. 이러한 배포에서 포털 애플리케이션은 고가용성을 제공하는 반면 BPM 애플리케이션은 그렇지 않습니다. 이러한 배포는 포털 애플리케이션은 크리티컬하지만 크리티컬하지 않은 BPM 애플리케이션을 사용하는 경우 적합할 수 있습니다.
이 예제에는 각각 하나의 WebLogic 인스턴스를 가진 3개의 서버가 있습니다. 그러나 서버 수는 여러 개가 될 수 있고 서버 당 하나 이상의 WebLogic 인스턴스를 가질 수 있습니다. 사실 애플리케이션을 BEA WebLogic Platform에 구축할 수 있는 방법은 상당히 유연합니다. 배포 시 "황금률"은 다음과 같습니다.
- 2 또는 3개의 CPU마다 WebLogic 인스턴스 하나
- 공용 WebLogic 도메인에는 함께 관리할 애플리케이션이 있어야 함.
- 관련이 없는 애플리케이션은 하드웨어 리소스를 공유하더라도 별도의 WebLogic 도에인에 있어야 함.
- 고가용성 또는 무정지 기능이 필요할 경우 WebLogic 인스턴스를 클러스터해야 함
- 필요한 성능 및 처리량을 제공하기 위해 애플리케이션에 N개의 서버가 필요할 경우 애플케이션을 서버 중단에 대비하여 N+1 서버에 배포해야 함.
이 단원으로 물리적 뷰에서 하드웨어 및 소프트웨어 배포에 관한 설명을 마칩니다. 다음 단원에서는 4+1 View Model의 프로세스 뷰에 대해 살펴보겠습니다.
프로세스 뷰
프로세스 뷰(동시성 뷰라고도 함)는 다양한 프로세스 및 프로세스 사이에서 발생되는 커뮤니케이션을 보여 줍니다. 다음 다이어그램은 관계형 데이터베이스에 있는 데이터에 대한 웹 브라우저 요청을 수행하는 것과 관련된 프로세스를 보여 줍니다.
그림 5. 프로세스 뷰
간단한 프로세스 예제 다이어그램에서 단일 브라우저 요청을 수행하는 데 다양한 프로세스 및 스레드가 관련됨을 보여 줍니다. 이러한 프로세스 다이어그램은 특히 단일 요청을 수행하는 데 비동기 및 다양한 백엔드 시스템이 관련될 경우 훨씬 복잡해질 수 있습니다.
다음 다이어그램은 WebLogic Platform의 프로세스 및 스레드를 보여 줍니다.
그림 6. WebLogic Platform의 프로세스 및 스레드
위 다이어그램에 나타난 바와 같이 WebLogic Server의 단일 인스턴스는 다중 스레드를 사용하는 단일 프로세스에 상응합니다. 기본적으로 WebLogic Server는 단일 요청 대기열로 구성됩니다. 서로 다른 요청 유형을 구분하기 위해 추가 요청 대기열을 구성할 수 있습니다. 예를 들면, 우선 순위가 높은 요청과 우선 순위가 낮으면서 비용이 많이 드는 요청을 구분하는 것이 나을 수 있습니다.
pure-Java 소켓 리더 구현을 사용하는 경우 Socket Reader 스레드 및 Worker 스레드 모두 동일한 스레드 풀에서 가져옵니다. native IO를 구성한 경우 native 소켓 리더 multiplexor 스레드는 자체 실행 대기열을 갖고 있어서 요청 대기열 스레드 풀에서 스레드를 빌려오지 않습니다.
통신
WebLogic Platform 기반으로 구축된 애플리케이션 내의 통신은 플랫폼에서 투명하게 처리합니다. 그러나 플랫폼에서 지원되는 통신 구조 중 일부는 아키텍처에 중요한 영향을 미치는 것도 있습니다.
대화
WebLogic Platform에서 제공되는 웹 서비스는 클라이언트 및 애플리케이션 사이의 대화를 간편하게 만들 수 있는 메커니즘을 제공합니다. 대화 상태는 영구적으로 저장되므로 대화는 오랫동안 지속되며 시스템을 종료하더라도 유지될 수 있습니다. (또한 포기한 대화를 자동으로 정리하도록 대화 시간 초과를 설정할 수 있습니다.)
비동기 지원
WebLogic Platform은 비동기 통신을 위해 몇 가지 메커니즘을 제공합니다.
- 컨트롤 아키텍처는 콜백의 생성 및 등록을 위한 간단한 메커니즘을 제공합니다.
- JWS( Java Web Service) 파일을 사용하여 비동기 웹 서비스를 간단하게 구성할 수 있습니다.
- 이 플랫폼에는 신뢰할 수 있는 SOAP 메시징 프레임워크가 포함되어 있어서 하나의 WebLogic 인스턴스에서 실행되는 애플리케이션이 또 다른 WebLogic 인스턴스에서 실행되는 웹 서비스를 호출할 수 있습니다.
- 이 플랫폼에는 프로세스 정의와 비동기 통신을 할 수 있는 메시지 브로커가 포함되어 있습니다.
- 이 플랫폼에는 비동기 통신에 대한 J2EE 표준 메커니즘인 JMS 및 MDB 지원이 포함되어 있습니다.
보안
일반적으로 보안을 애플리케이션 내의 컴포넌트 간 통신의 일부라고 생각하지는 않습니다. 하지만 WebLogic Platform에는 애플리케이션 내의 통신을 투명하게 가로채서 조치를 취하는 업계 주도적인 보안 인프라스트럭처가 포함되어 있습니다. 이러한 보안 인프라스트럭처는 WebLogic Server의 일부이며 나머지 플랫폼에서 애플리케이션의 모든 면에 대해 일관성 있고 선언적인 정책 기반의 보안을 생성하기 위해 사용됩니다. 애플리케이션 내의 보안을 강화하기 위해 사용자 정의 코드를 작성해야 할 필요성은 거의 없습니다.
또한 WebLogic Platform은 WS-Security를 지원합니다. 이로써 웹 서비스 메시지의 암호화를 제공할 뿐만 아니라 웹 서비스 스택을 기본 보안 인프라스트럭처에 연결합니다.
WLES(WebLogic Enterprise Security)는 WebLogic Platform에 구축한 솔루션에 통합할 수 있는 또 다른 BEA 제품입니다. WLES는 정책 기반의 위임된 관리, Single Sign-On을 사용하는 인증, 통합된 감사, 위임을 사용하는 동적 역할 및 정책 기반의 권한 부여 기능이 포함된 향상된 애플리케이션 보안을 제공합니다.
결론
이 문서의 목적은 BEA WebLogic Platform에서 제공하는 광범위한 기능을 애플리케이션 설계자가 간편하게 요약할 수 있는 수준 높은 뷰에 제공하는 것입니다. 그러기 위해 4+1 View Model을 사용하여 WebLogic Platform에 구축한 애플리케이션의 아키텍처에 대해 설명했습니다. 개발자 뷰는 WebLogic Server, WebLogic Portal, WebLogic Integration, WebLogic Workshop 및 Liquid Data for WebLogic에서 제공하는 컴포넌트에 대해 통일된 뷰를 제공합니다. 또한 이 뷰에서는 잘 설계된 애플리케이션의 아키텍처 레이어를 보여 주고 각 레이어의 컴포넌트를 식별합니다. 물리적 뷰는 WebLogic Platform에 구축된 애플리케이션의 배포에 대한 간단한 예제를 제공합니다. 소프트웨어 배포 및 물리적 하드웨어 배포가 모두 나타납니다. 프로세스 뷰는 사용자 요청을 수행하는 데 관련된 스레드 및 프로세스를 설명합니다. 또한 대화, 비동기 및 보안 같은 애플리케이션 통신 문제에도 관여합니다.
이 문서를 통해 WebLogic Platform 및 WebLogic Platform이 애플리케이션 개발을 위해 제공하는 견고한 기반을 보다 잘 이해하고 이러한 이해를 바탕으로 WebLogic Platform에서 제공하는 기능을 사용하는 애플리케이션을 구축 및 설계하는 데 도움이 될 수 있기를 바랍니다.
추가자료
Bob Hensle은 BEA Systems의 컨설턴트이며 최근 그는 BEA WebLogic 제품군을 사용하여 구축한 서비스 지향 아키텍처에 전념하고 있습니다. |
