교차 플랫폼 XML 아키텍처
상태바
교차 플랫폼 XML 아키텍처
  • Network Computing
  • 승인 2004.02.06 00:00
  • 댓글 0
이 기사를 공유합니다

SOAP이 언제나 애플리케이션용의 가장 확실한 통합 모델이 되는 것은 아니다. 물론 W3C의 웹서비스 아키텍처가 마이크로소프트 닷넷과 J2EE 기반 애플리케이션이 함께 작동하게 해주는 사실상 표준 방안이 된 것은 사실이다. 그리고 IBM z시리즈 메인프레임 서버나 이와 유사한 플랫폼을 SOAP(Simple Object Access Protocol)의 XML 기반 웹서비스와 함께 사용함으로써 인트라넷 아키텍처를 통합할 수도 있다. 하지만 이것이 효율적이지 못한 환경도 있으며, 여기에 대한 한 가지 대안으로 간단한 교차 플랫폼 XML 아키텍처를 사용해볼 수 있다.

오래된 코볼 기반의 OLTP 애플리케이션을 자바로 개조하다 보면 네트워크 응답시간이 고통을 줄 수도 있고 CPU 이용량이 치솟을 수도 있다. 즉, 기존 주문 입력 애플리케이션을 SOAP 서비스로 개조할 경우 100%나 더 많은 CPU 이용이 요구되고 응답시간은 저하될 수 있다. 그리고 이러한 셋업은 자바 애플리케이션을 사용하는 것만큼 효율적이지도 못하다.

클라이언트 쪽과 서버 쪽

바로 이 때문에 SOAP 기반 웹서비스에 대한 대안이 등장하게 된 것이다. 한 가지 옵션으로 썬의 J2EE 블루프린츠(Blueprints)가 있지만 이 J2EE 디자인 패턴은 객체에 너무 의존하기 때문에 트랜잭션의 작업처리량이 떨어질 수 있다. 여기 내가 일하는 소매점에서는 SOAP 없이 보다 간단한 교차 플랫폼 XML 기반 아키텍처를 배치하고 있다. 이 XML 아키텍처에는 객체가 거의 필요치 않으며 자바 애플리케이션이나 서블릿 안에서 쉽게 이행될 수 있다.

XML은 사실 대형 이기종 분산 컴퓨팅 환경에서는 공용어가 되어가고 있다. 애플리케이션은 XML 포맷으로 데이터를 받고 만들어 낸다. 우리 조직에서 이행했던 통합 모델은 3층이 아니라 2층 클라이언트-서버 모델이다. SOAP RPC 모델에서와 마찬가지로 XML 데이터는 네트워크를 통해 전달된다. 그러나 SOAP와 달리 우리 셋업에는 메시지와 헤더용으로 인코딩된 정보를 가지고 봉해진 엔벌로프(envelope)가 포함돼 있지 않다. SOAP의 XML 페이로드가 있는 프로세싱 오버헤드는 W3C의 주요 트레이드 오프다. 시간에 민감한 트랜잭션 프로세싱 애플리케이션에는 이런 종류의 페이로드 부담이 필요하지 않다.

네트워크에서 XML 메시지를 단순히 송수신하기 위한 XML 기반 인트라넷 모델을 구성할 수 있다. HTML 페이지와 J2EE 애플리케이션 서버를 만들기 위해 XSLT(Ex- tensible Stylesheet Language Transformation) 프로세싱과 같은 교차 플랫폼 컴포넌트를 사용하기 때문에, 이러한 아키텍처는 프로세서를 구성할 수 있는 방식에 있어 많은 여지를 주며, 이것은 큰 이점이다. 대부분의 조직에서 애플리케이션 호스팅 및 구성을 이끄는 주 동력은 총 소유비용(애플리케이션 구축, 호스팅 및 유지보수 비용)이다.

이러한 축소판 XML 아키텍처의 주 목적은 파싱(parsing)에서 오버헤드를 줄임으로써 애플리케이션의 성능을 향상시킨다는 것이며, 이것은 XSLT 프로세싱용으로도 또한 유연하다. 예를 들어 XSLT용으로 다른 프로세스나 서버를 구입해야 한다고 하자. 이 XML 모델은 새 하드웨어를 구입하거나 자바 자원을 이용하는 대신 보다 저렴하게 HTTP 서버나 클라이언트 브라우저로 XSLT 프로세싱의 부하를 옮길 수 있게 해줄 것이다.

XSLT 프로세싱을 HTTP 서버에 가져다 놓는 것은 XML 문서를 대량 배포하고 싶을 때 최상의 선택이며, 이들을 브라우저용으로 HTML로 변형시키는 것은 서버의 일이다. 하지만 클라이언트 쪽 방안은 약간 까다롭다. 클라이언트에서 XSLT를 돌리고 싶다면 브라우저가 마이크로소프트 인터넷 익스플로러 5+나 넷스케이프 6+, XSLT WD, XSLT 1.0을 지원해야만 한다. 그리고 클라이언트 기계에 최소한 1기가바이트의 메모리가 있어야 한다.

한편 IBM의 z시리즈는 I/O 집약적인 데이터 관리 시스템과 대기열 병렬처리 애플리케이션용으로 최적화돼 있기 때문에 이 첨단 서버를 정적 페이지, GIF 및 XML 파일이 있는 HTTP 웹 프로세싱용으로 사용하는 것은 적절치가 못하다. 메인프레임은 데이터베이스 호출을 처리하도록 하고 XSLT 프로세싱은 HTTP 서버나 클라이언트에 두라.

그러나 이 XML 기반 애플리케이션 통합 아키텍처의 핵심은 모든 수신 XML 요청을 처리하고 데이터베이스에 통합하는 J2EE 애플리케이션 서버다. 이 서버는 JSP(Java Server Pages), EJB(Enterprise JavaBeans), 그리고 자바 서블릿을 처리한다.

WSAD 이용

그렇다면 이 레퍼런스 아키텍처를 어떻게 설계 및 이행할 것인가? 우리는 IBM의 웹스피어 스튜디오 애플리케이션 디벨로퍼(WebSphere Studio Application Develop-er: WSAD) 5.0.1을 이용했다.

WSAD는 IBM의 코어 애플리케이션 J2EE 인터랙티브 배치 환경이다. 이것은 비록 오픈 소스인 이클립스 2.1(Eclipse 2.1: XML 기반 인트라넷 아키텍처용의 핵심 프레임워크)을 기반으로 만들어졌지만 IBM의 웹스피어 애플리케이션 서버에서의 J2EE 애플리케이션 배치를 타깃으로 하고 있다.

독립 소프트웨어 업체들을 주 대상으로 하는 이클립스에는 플러그인이 로딩되고 실행되는 런타임 모듈이 포함돼 있다. 이 플러그인들은 XML 파싱이나 이와 유사한 작업들을 위한 것이다(한 때 BEA 웹로직 개발 프로젝트에 이클립스를 사용한 적이 있었는데, 이처럼 비 IBM 플랫폼에서도 작동이 가능하다).

일반적으로 XML 레퍼런스 아키텍처는 JSP 모델 2 아키텍처와 유사하다. 클라이언트 애플리케이션은 컨트롤러 서블릿으로 요청을 만들며, 이 서블릿은 요청을 처리해서 클라이언트에게 XML이나 HTML 메시지의 형태로 응답을 보낸다. 그러나 J2P 모델 2는 HTML 페이지 형태로만 응답을 보내는 반면 XML 아키텍처는 XML이나 HTML로 응답한다. JSP는 순수하게 서버 기반이기 때문에 XSLT 프로세싱의 부하도 역시 덜어줄 수 없다.

XML 아키텍처는 대부분의 비즈니스 애플리케이션 툴과 마찬가지로 인터넷 기술을 이용해 데이터베이스 관리 시스템에 있는 데이터를 확보하고 설정하기 위한 것이다. 이것은 SQL 구문을 이용해 검색될 데이터를 정의하거나 데이터베이스 내부로 설정을 할 뿐만 아니라 HTML 페이지를 만드는 데 사용되는 기본적인 XSLT 스타일과 XML 스트럭처를 위한 것이기도 하다. 그리고 바로 여기서 WSAD 마법사가 등장한다.

<그림: 선택할 수 있는 옵션>에서는 웹 애플리케이션 안에 있는 XML 데이터 처리를 위한 핵심 비즈니스 로직을 보여주고 있다. 임플로이서블릿(EmployeeServelet)은 클라이언트 브라우저에서 요청을 받아 SQLToXMLds 객체로 이 요청을 전달한다.

WSAD와 함께 번들링되는 SQLToXMLds 클래스는 데이터베이스 접속성과 XML 메시지로 매핑되는 핵심 JDBC 리절트세트(Resultset)를 제공한다. XML을 이용해 데이터베이스에 데이터를 삽입, 업데이트, 혹은 삭제하기를 원한다면 XMLToSQL 클래스를 사용하면 된다.

SQLToXMLds 클래스는 웹 애플리케이션에 데이터베이스 접속 풀링을 제공하며, 이것은 새로운 접속을 만들어내는 게 아니라 기존의 데이터베이스 접속을 재사용함으로써 애플리케이션 응답시간을 향상시킨다. 대부분의 J2EE 엔터프라이즈 애플리케이션들은 접속 풀링을 요구하고 있다.

이러한 웹 애플리케이션들과 마찬가지로 우리가 사용하는 XML 모델은 파라미터를 보내고 데이터베이스에서 데이터를 받는다. 요청은 서블릿으로 전송되며, 서블릿은 SQLToXMLds 객체를 불러낸다. 그러면 이 객체는 DBMS와 통합되며 HTML은 다시 클라이언트 브라우저로 보내진다.

가벼운 XML

따라서 SOAP이 애플리케이션 환경용으로 너무 무거울 경우에는 가벼운 XML을 이용해 기존의 애플리케이션에 J2EE 기반 것들을 통합시켜 보라. 이것은 인트라넷에서 HTTP를 통해 XML만을 이용해 네트워크 트래픽을 줄여준다.

이것은 프로세싱 오버헤드에서 큰 역할을 하는 파싱을 가장 효율적인 플랫폼에 배치하기 때문에 애플리케이션의 성능을 더 낫게 만든다.

함정은 이 아키텍처로 J2EE 애플리케이션 서버뿐만 아니라 서버 대신 클라이언트에서 XSLT 프로세싱을 하고자 할 경우 최신 버전의 브라우저가 필요하다는 것이다. 그러나 바뀐 애플리케이션이 효율적으로 작동하도록 보장하기 위해서는 이런 노력을 할 만한 가치가 충분히 있다.

XML과 XSL 프로세싱 작동법

1. 브라우저가 페이지를 제출한다. HTML 페이지가 양식 요청(즉 을 제출하고 서블릿에 있는 doPost() 메소드로 요청을 보낸다)

2. 서블릿은 로컬 프로텍티드 메소드를 불러낸다. doPost()는 runQuerty() 메소드를 호출하고 응답 객체로 들어간다.

3. XML을 포함하고 XML 작성용으로 사용되는 객체가 만들어진다. PrintWriter 객체에 ByteArrayOutputStream이 설치된다.

4. JDBC ResultSet과 XML 파싱용 객체가 만들어진다. SQL 구문과 데이터 정보를 포함하는 객체와 함께 SQLToXMLds 객체는 생성된다.

5. XML을 포함하는 객체가 SQLToXMLds 객체로 보내진다. PrintWriter 객체가 SQLToXMLds 클래스 안에 설정된다.

6. DBMS에서 데이터가 검색되어 실행 메소드를 불러냄으로써 XML 스트링 객체로 매핑된다. SQL 구문이 실행된다.

7. JDBC ResultSet이 스트링 객체에 저장되며, 이것은 스트링 객체로 전환된다. 클라이언트 쪽 XSLT 프로세싱이 요구될 경우에는 위의 단계만이 서버에서 실행되며 나머지 단계는 클라이언트나 HTTP 서버에서 실행될 것이다.

8. XML 프리젠테이션, HTTP 응답 및 XSL 프로세싱용 객체가 생성된다.

9. XSLT 변형용으로 사용되는 객체가 생성된다. 변형 객체는 .xsl Source 문서와 함께 만들어지며 XML이 있는 객체가 처리된다.

10. 서버가 클라이언트로 응답을 보낸다. HTML 응답이 doPost()를 시작한 클라이언트로 다시 전달된다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.