다음 섹션에서는 아키텍쳐에 웹 서비스로서 STATELESS EJB 컴포넌트를 노출하는 방법을 설명하겠다.

SOA/웹 서비스 프레임웍 설계하기
청 구서 발행, 금융, 인보이스 작업 같은 다양한 시스템들이 서로 상호작동 해야 하는 기업의 예를 들어보자. 이 애플리케이션들은 외부 세계에 노출되어 다양한 비즈니스 파트너들이 이 애플리케이션들과 인터랙팅 할 수 있어야 한다. 또한 다양한 애플리케이션을 위한 웹 기반의 솔루션도 마련해야 한다. 최상의 선택은 서비스에 기반한 약결합 시스템을 설계하는 것이다. 이들 서비스는 오픈 표준의 후원을 받아서 어떤 비즈니스 파트너라도 그 서비스를 호출할 수 있다.

이렇게 따지다 보면 웹 서비스/SOA 프레임웍에 초점이 맞춰질 것이다. STATELESS EJB 컴포넌트를 통해 웹 서비스로서 노출된 다양한 서비스들과 비즈니스 프로세스를 갖춘 프레임웍이다. 그림2는 기업의 내부 애플리케이션을 위한 SOA이다.

그림2. 기업의 내부 애플리케이션을 위한 SOA

SOA 프레임웍에서 인터랙팅하는 다양한 컴포넌트들이 아래 나열되어 있다. 이는 전형적인 MVC2 프레임웍이다.

• 클라이언트: 사용자들은 애플리케이션의 클라이언트로서 작용하는 웹 브라우저를 통해 다양한 애플리케이션들과 인터랙팅한다. 예를 들어 청구서 발행 부서 사용자는 청구서 발행에 대한 세부사항을 입력하고 그 정보를 애플리케이션에 게시한다. JSP 페이지와 XMHTML는 클라이언트 페이지들을 렌더링하는데 사용될 수 있다.
  
  
• 애플리케이션 콘트롤러: 애플리케이션 콘트롤러는 메인 콘트롤러 서블릿이다. 초기화를 담당하고 요청과 응답을 요청 프로세서에 보낸다.
  
  
• 요청 프로세서: 요청 프로세싱을 수행하는 자바 클래스로서 필요한 프로세싱을 수행하기 위해 상응하는 요청 핸들러를 호출하며 작동한다.
  
  
• 요청 핸들러: 요청 핸들러는 특정한 요청 액티비티를 수행한다. 이를 테면 다양한 엔터프라이즈 정보 시스템(EIS)에서 정보를 추가하거나 검색하기위해 서비스들과 인터랙팅 하는 것이 한 예이다. 요청 핸들러는 비즈니스 로케이터에 의존하여 상응하는 서비스를 찾은 다음 그 서비스를 통해 원하는 EIS 정보에 액세스한다.
  
  
• 비즈니스 로케이터: 서비스를 검색하는 복잡함을 숨긴다. 캐싱 로직 또한 제공한다. 비즈니스 로케이터는 많은 형식을 취할 수 있다. 예를 들어 웹 서비스 로케이터, EJB 로케이터, JMS 로케이터 등으로 될 수 있다.
  
  
• 세션 Facade: 멀티 시스템 또는 서비스에서 메소드들을 모아 복잡한 객체를 간단히 보여준다. 세션 Facade는 EJB 웹 서비스 메소드 주변의 래퍼이다.
  
  
• EJB 웹 서비스: EJB 1.4 스팩에 따라, 웹 서비스 엔드포인트는 STATELESS 세션 빈으로서 모델링 될 수 있다. 앞서 언급한 것 처럼 이 기술에는 많은 이점이 있다.
  
  
• 데이터 액세스 인터페이스: EJB-CMP, JDO, DAO, 다양한 영속성 기술 등 다양한 기술을 사용하여 EIS에 접근한다. 사용된 접근 기술은 인터페이스 요구사항과 페치, 삽입 또는 업데이트 될 데이터의 양에 의존한다. 이 레이어는 EIS와 인터랙팅하고 데이터를 상응하는 EJB 웹 서비스 메소드에 메소드가 기대하는 형식으로 리턴한다.
  
  
• MQSeries/JCA/CCF: 기존 메인프레임 기반의 서비스는 웹 서비스로서 노출 될 수 있으며 또한 이들을 외부 세계에 드러낼 수 있다. 웹 서비스 클라이언트는 HTTP 기반 SOAP 프로토콜을 사용하여 EJB 웹 서비스와 인터랙팅한다. EJB 메소드는 요청들을 JMS 프로토콜을 통해 MQSeries 큐에 게시한다. 메인프레임 쪽의 MQSeries 서버는 IMS DC 같은 백엔드 시스템과 인터랙팅에 필요한 로직을 제공하는 상응하는 COBOL 기반의 프로그램을 실행한다. 이 프로그램은 응답을 큐에 게시하고 애플리케이션 로직에 의해 검색되고 다시 EJB 메소드에 게시된다. SOAP 메시지는 HTTP, HTTPS, JMS 같은 다양한 프로토콜을 통해 전송될 수 있지만 이 예제에서는 HTTP와 HTTPS 만 사용하겠다.

이 컴포넌트들은 기업 내부 애플리케이션의 서비스 지향 아키텍쳐의 기초를 제공한다.

서비스 노출하기
서 비스를 외부 사용자에게 노출하려 한다면 권한이 있는 사용자들만 서비스에 액세스 할 수 있도록 하는 특정한 유형의 보안 제한이 필요하다. 한 가지 방법은 금지된 웹 서비스 요청을 필터링하고 로깅과 보안 제한을 제공하는 웹 서비스 레이어를 추가하는 것이다. 이 필터는 서비스의 서브세트에서 권한을 받은 클라이언트에만 노출하는 기능도 제공한다.

그림3은 기업 외부 애플리케이션을 위한 서비스 지향 아키텍쳐이다. 정제된 서비스를 외부에 노출한다.

그림3. 서비스 지향 아키텍쳐; 외부에 노출하기

다음은 이 아키텍쳐의 기본적인 기능 단위이다:

• 외부 클라이언트: 웹 기반 클라이언트, 모바일 클라이언트, .NET environment, Perl, 기타 프로그래밍 언어로 코딩 된 클라이언트가 포함될 수 있다. 이 모든 클라이언트들은 다양한 서비스에 요청을 보낸다. WS-I Profiles에 순응하는 한 상호운용성 문제는 없을 것이다.
  
  
• 기업 방화벽: 보안 정책에 기반하여 샘플 기업은 인트라넷과 인터넷 사이에 방화벽을 설치하여 인커밍 패킷 정보를 차단했다.
  
  
• Web Services Gateway:외부 서비스를 노출하기 위한 게이트웨이로 WebSphere Application Server 5.0에 포함된 Web Services Gateway를 사용하기로 했다. (Resources) Web Services Gateway는 미들웨어 컴포넌트로서 웹 서비스의 호출 작동 동안 인터넷과 인트라넷 사이에 매게 프레임웍을 제공한다. Web Services Gateway를 사용하여 개발자들과 IT 매니져들은 안전하게 웹 서비스를 노출하여 방화벽 밖의 클라이언트가 호출 할 수 있도록 한다. 이것은 서비스의 관리용 모델(전개/전개취소)과 필터(게이트웨이를 통해 흐르는 요청과 응답에 따라 작동하는 커스텀 코드)를 포함하고 있다. SOAP/HTTP 요청을 핸들하고 자바 클래스, EJB 컴포넌트 또는 SOAP 서버에 보내지는 게이트웨이를 통해 전달되는 요청을 핸들한다. 이것은 웹 서비스의 개별 메소드에 보안을 제공하고 전체적으로는 게이트웨이를 제공한다. Web Services Gateway를 사용하여, 클라이언트에서 온 요청들은 서비스에 필요한 메시징 프로토콜로 변형될 수 있다. 예를 들어 클라이언트의 요청은 HTTP를 통한 SOAP으로서 온다. 하지만 내부적으로는 JMS 프로토콜을 통한 SOAP을 사용한다. Web Service Gateway는 하나의 프로토콜에서 다른 프로토콜로의 수렴기능을 제공한다.
  
  
• EJB services: EJB 서비스에 변화가 없다. 나머지 프로세스는 그림 2에 설명한 아키텍쳐에서 제공하는 인트라넷 기반의 서비스와 비슷하다.

EJB 컴포넌트를 사용한 대단위(coarse-grained)
지 금까지 보았던 프로세스는 소단위(fine-grained) 웹 서비스를 클라이언트에 노출한 것이다. 각 비즈니스 서비스가 하나의 비즈니스 프로세스에서 실행되는 한 이러한 설정은 훌륭하게 작동한다. 하지만 고객이 자금을 송금 하려고 한다면? 그와 같은 상황에서는 대단위(coarse-grained) 인터페이스가 적합하다. 고객에게 모든 필요한 정보를 제공하고 이체될 금액, 송수신 은행의 정보 등이 포함되어야 한다. 또한 그와 같은 시나리오에서는 비즈니스 로직의 실행 전에 밸리데이션이 수행되어야 한다. 웹 서비스용 메소드를 디자인 할 때 이 모든 사항들을 염두해야하고 네트워크 호출 외에도 XML 요청과 응답의 파싱 및 고안에 대한 오버헤드도 생각해야 한다.

이러한 요소들을 염두해 두고 Session Facades를 EJB 웹 서비스 엔드포이트로서 모델링 할 수 있다. Session Facades는 웹 서비스 메소드에 요청을 보내기 전에 요청의 타당성 검사를 할 수 있다. 이러한 방식으로 대단위 서비스를 웹 서비스 클라이언트에 제공하는 것이다.

그림 4는 기업의 외부 애플리케이션에 대한 서비스 지향 아키텍쳐의 반복을 보여준다. 이 버전의 아키텍쳐는 대단위 서비스를 외부에 노출한다.

그림4. 대단위 서비스의 SOA

여기에서, 구현은 그림 3에 서 강조한 것과 같다. 유일한 차이점은 Session Facades를 웹 서비스 엔드포인트로서 노출했다는 점이다. EJB 웹 서비스는 원격 인터페이스가 아닌 로컬 인터페이스로서 모델링 될 수 있다. Session Facades와 모델 레벨의 보안을 사용하여 서비스 실행을 제한할 수 있다. Web Service Gateway를 사용하면 웹 서비스 클라이언트에 대한 보안 측정도 가능하다. 요구 사항에 따라 대단위 서비스와 소단위 서비스의 결합도 가능하다. 웹 서비스 게이트웨이 미들웨어를 튜닝하여 외부 클라이언트에게 이 둘 모두를 노출할 수 있는 것이다.(참고자료)

참고자료

• WS-I profiles.
  
  
• "Implementing business processes using WebSphere Studio Application Developer Integration Edition, Part 2: Extend your business process," David Leigh (September 2003).
  
  
• "DB2 Web services: The big picture," Grant Hutchinson (August 2002)
  
  
• "An introduction to Web services gateway," (developerWorks, May 2002).
  
  
• "Provide a Facade interface for enterprise Web services," (developerWorks, January 2004).
  
  
• developerWorks :
  • "Programming JMS applications using AXIS" (February 2003)
  • "Deliver Web services to mobile apps" (January 2003)
  • "Web services architecture using MVC style" (April 2002)

    [출처] J2EE를 이용한 서비스 지향 아키텍쳐 프레임웍 설계|작성자 눈꽃천사