JAVA로 SOAP 구축하기(2)

part2. Axis Overview

SOAP Part1에서는 SOAP에 대한 기본적인 사항을 살펴보았다. 이번장에서는 SOAP처리기라고 알려진 Axis를 살펴보자.

Axis 는 Apache SOAP프로젝트의 산물이다. 지금까지 크게 2가지의 Version(Axis1.x, Axis2.x)이 나와있으며 Axis2에서는 기존 Axis보다 보다 유연한 구조(module이 쉽게 configuration 될 수 있는),  성능 향상, 비동기 웹 서비스, hot deploy기능 등을 제공하고 있다. W3C에서는 SOAP를 다음과 같이 정의하고 있다.

SOAP is a lightweight protocol for exchanging structured information in a decentralized, distributed
environment. It is an XML based protocol that consists of three parts: an envelope that defines a
framework for describing what is in a message and how to process it, a set of encoding rules for expressing
instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.

자 세히 설명하자면 SOAP은 분산환경에서 정보의 교환, 즉 웹서비스를 통해 정보를 교환하는 일종의 XML 기반의 protocol이며 그 protocol을 정의하고 있는 SOAP message내에는 무슨 내용이 있으며 어떻게 message를 처리해야하는지와 encoding rule이 정의되어 있다. 즉 일종의 쌍방(서비스 제공자와 요청자)간의 협약이 맺어져 있어 Axis에서는 해당 SOAP message를 처리한다.

먼저 Apache Axis1의 acchitecture부터 살펴보는것 부터 시작하도록 하자.

[ Axis Architecture ]

Figure1. Axis의 기본 구성.

요청자    -------------------------------->   Axis 엔진  <--------------------------> 웹 서비스
              전송매체(HTTP, SMTP, MQ, etc)


Figure1 에서 보듯이 Axis는 SOAP message를 HTTP와 같은 전송매체를 통해 받아 웹 서비스에 전달하고 SOAP message로 만들어진 응답을 다시 요청자에게 전달하는 역할을 하는데 다음고 같은 구성요소들이 어우러져 SOAP을 처리한다.

• Axis Engine : SOAP 처리기
• Handler : Axis내부의 기본적인 구성요소로 기본의 백엔드시스템과 Axis를 연결하는 역할을 한다.
• Chain : 순차적으로 정렬된 Handler들의 모음을 말한다.
• 전송매체 : SOAP message 흐름이 Axis에 들어오고 나갈 수 있데 하는 메커니즘이다.
• 구축/설정 : Axis를 통해 웹 서비스를 사용할 수 있도록 하는 수단이다.
• Seriaizers / Deserializers : Java와 같은 원래 Datatype을 XML로 변환하는 코드/원래 Datatype으로 복원하는 코드이다.

1. Axis Engine

Axis Engine은 여러 컴포넌트, 즉 Handler를 이용해 SOAP message의 흐름을 운영할 뿐만 아니라 이데 대한 순서를 조정하는 책임을 갖는다.

2. Handler & Chain

Chain은 순서대로 정렬된 코드형태의 컴포넌트 모음을 말하며 Axis는 정해진 순서대로 이들을 순차적으로 기동하게 되는데, 이렇게 순차적으로 기동되는 컴포넌트들을 가리켜 Handler라고 한다. 각 Handler는 웹 서비스 기동 전 후의 message에 대해 추가적인 처리를 수행할 필요가 있을 경우에 사용되는데 logging이나 SOAP Header Block을 처리하기 위해 많이 쓰인다. 그럼 웹 서비스 자체내에서 해당 로직, 즉 바로 앞에서 예로 든 logging이나 SOAP Header block처리 같은,을 처리하지 않고 Handler를 사용해서 처리할까? 이유는 웹 서비스 코드는 비즈니스 관점에서 해당 로직만을 처리함으로써 재사용성이 증대되고 각 Handler는 다른작업에 개의치 않고 각자의 고유역할에만 전념할 수 있으므로 코드가 중복되는 여지를 없앨 수 있으며 Axis설정을 통해 새로운 Handler를 추가하거나 삭제하는 식으로 처리가 가능함으로 인해 웹서비스의 재사용성을 증대시키는 역할을 할 수 있기 때문이다. 만약 Security가  적용되어 있는 기존의 웹 서비스에 RealiableMessage를 적용해야 한다는 요구사항이 발생한다면 기존의 로직을 수정하지 않고 간단하게 RealiableMessage를 처리할 수 있는 Handler를 제작한 후 Axis설정만으로 해당 Handler를 SOAP message처리에 참여시킴으로써  비즈니스 로직을 처리하는 웹 서비스, 보안관련사항을 처리하는 Handler, ReliableMessage를 처리하는 Handler를 각각의 역할만 하도록 제한시킬 수 있는 것이다.

그럼 웹 서비스에 대해 정의되어 있는 Handler의 Chain이 모든 요청에 대해 기동할까? 답은 그렇지 않다. 아니 설정을 통해 모든 요청에 대해 기동할 수도 있고 특정부분만이 기동할 수도 있다. 다음 그림을 보도록 하자

Figure1. Axis Server Architecture.

 

Figure1 은 Axis의 Server단의 Architecture를 도식으로 표현한 것이다. (Apache Axis 도식 참조) 작은 cylinder는 handler, 작은 cylinder를 감싸는 큰 cylinder는 chain을 나타낸다.

Axis Engine내에 크게 3부분(Transport, Global, Service)으로 구성되어 있는데, Transport는 전송매체지정체인으로 특정 전송매체(HTTP, SMTP, MIME...)에 따라 압축 또는 인증 등의 일을 처리하기 위해 정의될 수 있으며, Global은 전역체인으로 웹 서비스의 종류에 상관없이 동일한 처리를 핑요로 하는 경우에 정의된다. 또한 Service는 특정웹서비스용체인으로 말그대로 특정 웹서비스만을 위한 Chain을 필요로 하는 경우에 정의된다. 서비스내의 Provider는 일종의 Handler인데 backend의 실질적인 웹서비스와 Axis를 잇는 중계자 역할을 한다. 즉, SOAP message를 해석해서 필요로 하는 웹 서비스와 관련된 코드 부분을 찾아내어 해당 웹서비스를 기동시키는 역할을 한다. 예를 들어,  XML을 자바객체로 변환한 후 기동시킬 적정한 자바 메소드를 찾아 기동시키고, 가능한 응답 데이터를 XML 형태로 재변환하여 응답 SOAP message에 넣는 일을 한다.  Transport Listener는 request의 특정 protocol의 data를 받는 최초 접점으로 해당 protocol-specific data를 Message Object로 package한 후 Message Object와 각종 properties를 MessageContext에 설정한 후 MessageContext를 Axis에 전달하는 역할을 한다. 장황해서 좀 그런데 다시 정리하면...

 1). TransportListener는 요청에 대해 MessageContext Object를 Axis에 전달한다.

 2). 전송매체지정체인이 정의되어 있으면 Chain에 속한 Handler가 기동된다.

 3). 전역체인이 정의되어 있으면 해당 Chain이 기동된다.

 4). 특정웹서비스용체인이 있으면 해당 Chain이 기동된다.

 5). 응답도 이와 비슷한 과정을 거친다........

 

3. Transport

SOAP message를 전달하기 위해 전송매체가 HTTP만이 쓰이는 것은 아니다. SMTP, FTP 등이 사용될 수 있는데 실질적으로 Axis자체는 다중 전송매체를 지원하지는 않는다. 무슨말인고 하니, Axis는 들어오는 메세지로 Axis Engine이 호출되어 다시 응답메세지로 보내는 단순한 코드모음 이상, 이하도 아니며 또한 SOAP message를 기다리는 TransportListener는 Axis Engine의 일부가 아니다. Axis에서는 AxisServlet이라는 TransportListener를 제공하고 만약 특별한 처리가 필요하다면 전송매체에 맞는 TransportListener를 새로 작성해야만 한다. 따라서 Axis Engine은 TransportListener에 의해 메커니즘이 관리되는데 Axis Engine의 기동(요청마다 Engine이 생성되느냐 혹은 하나의 instance를 공유하느냐), message의 Axis Engine으로의 전달, 어떠한 전송매체가 사용되는지를 Axis Engine에게 통보함으로써 Axis는 설정된 특정전송매체지정체인을 기동하게 된다.

지 금까지 Axis Server Architecture를 간략하게 살펴봤는데 Client Architecture는 Provider대신에 Sender라는 전송매체전송자라는 Handler가 대체되고 Transport, Global, Service가 반대로 실행된다고 생각하면 된다. Figure2를 참조하고 자세한 사항은 Apache Axis관련 사이트를 참조하자.

Figure2. Axis Client Architecture

 

지 금까지 Axis의 기본 Architecture에 대해 살펴보았는데 처음보면 이게 무엇인지 감을 잡기 힘들다.(나만 그런가?ㅡ.ㅡ) 우선은 이것만 기억하자. Axis는 SOAP message처리 Engine으로 Handler라는 기본 component 들에 의해 message처리가 이루어진다. (너무 간단한가? 내 실력이 요것밖에 안된다. 아직...ㅜ.ㅜ) 

[ Axis Installation ]

여기다 정리하려고 했는데 좋은 문서가 벌써 있는것 같아 해당 문서사용.apache_axis.doc

문서를 보면서 그냥 한번 따라해보면 좋고, 아님 말고, 그래도 한번 해보는 것이 둏지 아니할런지...

- 출처 : http://ammoguy.springnote.com/pages/2289088 -