소개

전략적 아키텍처 구성 요소인 Enterprise Service Bus는 서비스 공급자가 제공하는 서비스의 소비가능성을 높일 수 있는 다양한 옵션을 서비스 공급자에게 제공한다. 이러한 옵션을 활용하면 기존 논리를 서비스로 재사용할 수 있을 뿐만 아니라 새로운 소비자 클래스에게도 서비스를 제공할 수 있다. "REST"(Representational state transfer)는 HTTP 프로토콜에서 제공하는 상호 작용 기능을 활용한다. WebSphere Enterprise Service Bus, WebSphere Message Broker 및 WebSphere DataPower는 모두 HTTP 요청을 처리할 수 있다. 따라서 이러한 도구를 활용하면 RESTful 서비스를 효과적으로 노출할 수 있다.

위로

RESTful 서비스의 특징

간단히 말해서 RESTful 서비스는 네트워크 주소를 지정하여 액세스할 수 있는 리소스로, 해당 서비스의 구현자에 의해 정의된 동사 세트를 처리한다. 이러한 동사 세트는 일반적으로 HTTP 메소드(예: GET, POST, PUT 및 DELETE)에 맵핑된다. 이 맵핑은 일반적으로 사용되는 방법일 뿐 반드시 따라야 하는 것은 아니다. 다음 순서도에서는 클라이언트가 RESTful 서비스를 호출하여 해당 서비스에서 처리할 동사와 컨텐츠(예: 매개변수)를 전달하는 일반적인 RESTful 상호 작용을 보여 준다.

서비스에서는 다양한 표현 형식으로 응답할 수 있다. XML도 이러한 표현 형식 중 하나이지만 서비스 공급자나 소비자가 인식할 수 있는 다른 형식을 사용할 수도 있다. 예를 들어, 서비스에서 AJAX(Asynchronous JavaScript and XML) 애플리케이션과 통신하는 경우에는 XML 보다는 JSON(JavaScript Object Notation)을 사용하는 것이 더 효과적이다. 이에 반해 이 기사의 뒷부분에서 설명하는 예제에서는 이 형식이 임의로 선택해서 사용할 수 있는 형식임을 강조하기 위해 원시 2진 형식을 사용하여 클라이언트와 서비스 간에 데이터를 교환한다.

위로

관련 Web 2.0 기술

구현을 단순화하기 위해 RESTful 상호 작용에 활용할 수 있는 몇 가지 Web 2.0 기술이 있다. 그 중에서도 가장 일반적으로 사용되는 기술로는 서비스에서 리턴된 오브젝트의 형식을 정의하는 데 사용되는 "JSON"(JavaScript Object Notation)과 기존 기술 세트를 활용하여 클라이언트와 RESTful 서비스 간의 데이터 교환 방법을 정의하는 "AJAX"(Asynchronous JavaScript and XML)가 있다.

이 기사에서 설명하는 예제에서는 원시 데이터의 교환을 보여 주므로 JSON 형식의 데이터를 교환하고 AJAX 클라이언트에서 서비스를 호출하는 방법은 특별한 경우를 다루는 예제이다.

위로

Enterprise Service Bus의 역할

Enterprise Service Bus는 서비스 공급자와 소비자 모두에게 추가 옵션을 제공하는 중개 기능을 제공한다. 주요 기능 중 하나로 서비스 자체를 변경하지 않고도 서비스 호출 방법을 변경할 수 있는 기능이 있다. 예를 들어, IBM Enterprise Service Bus 제품 중 하나를 사용하면 기존 SOAP 기반 웹 서비스를 REST 클라이언트에서 액세스할 수 있도록 만들 수 있다(시나리오 1). 또한 Enterprise Service Bus 기능을 사용하여 RESTful 서비스를 웹 서비스 클라이언트를 위한 SOAP 기반 서비스로 노출할 수도 있다(시나리오 2). 앞에서 설명한 두 가지 시나리오를 보여 주는 다음 다이어그램을 보면 Enterprise Service Bus에 전개된 중개 기능이 기존 자산(비즈니스 논리를 실현한 서비스 또는 서비스 구성 요소)의 인터페이스 역할을 수행한다는 것을 알 수 있다.

비즈니스 관점에서 본다면 소비자에게 필요한 모든 작업을 노출하는 기존 서비스가 있을 경우에는 이러한 서비스를 변경하지 않은 채로 호출할 수 있는 다른 방법을 마련하는 것이 효과적일 것이다. 예를 들어, 원래 SOAP 기반 클라이언트용으로 작성된 서비스를 REST 형식으로 완전하게 호출할 수 있다면 좋을 것이다. 이때 필요한 작업이 바로 적합한 중개 아티팩트를 생성한 후 ESB를 통해 이러한 아티팩트를 사용할 수 있는 환경을 소비자에게 제공하는 것이다.

이 기사의 다음 섹션에서는 WebSphere ESB, WebSphere Message Broker 및 WebSphere DataPower를 사용하여 두 시나리오에 적합한 중개 기능을 구현하는 방법을 보여 준다. 그런 다음 작성 중인 중개 아티팩트를 테스트하는 데 활용할 수 있는 몇몇 유용한 도구를 살펴본 후 다양한 프로그래밍 플랫폼(Java, .NET 및 PHP)을 사용하여 구현된 몇 가지 샘플 소비자에 대해서도 설명한다.

위로

중개 기능 구현하기

이제 WebSphere Enterprise Service Bus, WebSphere Message Broker 및 WebSphere DataPower를 사용하여 위에서 언급한 두 시나리오에 필요한 중개 기능을 구현하는 방법을 살펴보자.

샘플 백엔드 서비스

구현 단계를 보여 주기 위해 이 기사에서는 두 가지 기존 서비스가 있다고 가정한다. 하나는 SOAP/HTTP를 통해 호출하는 웹 서비스로 시나리오 1에 사용되며, 다른 하나는 시나리오 2에 사용할 RESTful이다. 두 서비스 모두 계정 번호를 매개변수로 인식하고 비즈니스 논리를 나타내는 간단한 규칙을 기반으로 계정 번호에 해당하는 신용 점수를 리턴하는 간단한 한 가지 작업만을 수행한다. 다음 WSDL listing에서는 시나리오 1에 사용되는 웹 서비스의 인터페이스를 보여 준다.

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="AccountScore"
targetNamespace="http://www.example.org/AccountScore/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.example.org/AccountScore/" 
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <wsdl:types>
    <xsd:schema targetNamespace="http://www.example.org/AccountScore/">
      <xsd:element name="getAccountScore">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="accountNumber" type="xsd:string"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
      <xsd:element name="getAccountScoreResponse">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="score" type="xsd:string"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
    </xsd:schema>
  </wsdl:types>
  <wsdl:message name="getAccountScoreRequest">
    <wsdl:part element="tns:getAccountScore" name="parameters"/>
  </wsdl:message>
  <wsdl:message name="getAccountScoreResponse">
    <wsdl:part element="tns:getAccountScoreResponse" name="parameters"/>
  </wsdl:message>
  <wsdl:portType name="AccountScore">
    <wsdl:operation name="getAccountScore">
      <wsdl:input message="tns:getAccountScoreRequest"/>
      <wsdl:output message="tns:getAccountScoreResponse"/>
    </wsdl:operation>
  </wsdl:portType>
  <wsdl:binding name="AccountScoreSOAP" type="tns:AccountScore">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="getAccountScore">
      <soap:operation soapAction="http://www.example.org/AccountScore/NewOperation"/>
      <wsdl:input>
        <soap:body use="literal"/>
      </wsdl:input>
      <wsdl:output>
        <soap:body use="literal"/>
      </wsdl:output>
    </wsdl:operation>
  </wsdl:binding>
  <wsdl:service name="AccountScore">
    <wsdl:port binding="tns:AccountScoreSOAP" name="AccountScoreSOAP">
      <soap:address location=
        "https://localhost:9446/AccountScore/services/AccountScoreSOAP"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>
			

다음 listing에서 보여 주는 doPost() 메소드는 간단한 서블릿으로 시나리오 2 예제에 사용할 RESTful 서비스이다.

BufferedReader br = new BufferedReader(new InputStreamReader(request .getInputStream()));
String inputString=br.readLine();
System.out.println(inputString);
String outputString="";

if(inputString.equals("AccountNum=123"))
       	 outputString="Score=4000";
else if(inputString.equals("AccountNum=456"))
       	 outputString="Score=6000";
else
       	 outputString="Score=N/A";

OutputStream os = response.getOutputStream();
byte[] buffer = new byte[outputString.getBytes().length];
response.setContentType(request.getContentType());
buffer=outputString.getBytes();
os.write(buffer, 0, buffer.length);
os.flush();
os.close();

이 서블릿은 "AccountNum=123" 또는 "AccountNum=456" 텍스트가 포함된 본문을 사용하여 서블릿이 전개되어 있는 URL에 POST HTTP 요청을 보내서 호출할 수 있다.

이 기사의 예제에서는 이해하기 쉽도록 하나의 동사(POST)만 처리하고 있으며, 여러 동사를 지원하려면 수신 프론트 부분에 필요한 코드를 추가해야 한다.

이 섹션의 이후 부분에서는 두 시나리오를 실현하기 위해 두 시나리오에 필요한 중개 기능을 구현하는 방법을 단계별로 설명한다.

위로

WebSphere Enterprise Service Bus 사용하기

RESTful 상호 작용에서는 HTTP 프로토콜의 기능을 활용하므로 WebSphere Enterprise Service Bus는 일반적인 HTTP 바인딩을 사용하여 RESTful 상호 작용을 지원한다. 이 섹션의 나머지 부분에서는 WebSphere Enterprise Service Bus에서 구현할 시나리오 1과 2를 살펴보고 그 구현 방법에 대해 설명한다.

시나리오 1 이해하기

시나리오 1을 구현하기 위해 이 기사에서는 HTTP 바인딩이 포함된 내보내기를 사용하여 REST 클라이언트의 HTTP 요청을 받는다. 이 경우 요청 메시지에 따라 수행할 작업을 결정하기 위해 사전 패키지된 함수 선택기 중 하나를 사용하도록 HTTP 내보내기를 구성하거나 사용자 정의 함수 선택기를 개발할 수도 있다. 하지만 이 기사의 예제에서 설명하는 백엔드 웹 서비스에서는 하나의 작업만 제공하므로 함수 선택기가 필요하지 않다. WebSphere Integration Developer 정보 센터의 "내보내기 바인딩에서 함수 선택기" 항목에서 자세한 정보를 확인할 수 있다.

다음 그림에서는 HTTP 내보내기가 중개 플로우에 연결되어 있으며, 이 중개 플로우에서는 REST 클라이언트에서 보낸 페이로드(HTTP 요청의 본문)에 대한 필수 변환을 수행한다. 앞에서 설명한 대로 이 기사의 예제에서는 페이로드의 데이터를 2진 데이터로 전송하므로 중개 플로우는 2진 페이로드의 컨텐츠를 XML의 일부가 될 문자열 형식으로 변환하여 백엔드 서비스에 전달되는 SOAP 요청을 만든다.

중개 플로우는 다양한 유형의 백엔드를 호출할 수 있다. 하지만 여기에서는 시나리오 1을 구현하기 위해 중개 플로우가 웹 서비스 바인딩이 포함된 가져오기를 사용하여 샘플 백엔드 웹 서비스를 호출한다.

시나리오 1 구현하기

이 섹션에서는 WebSphere Integration Developer를 사용하여 시나리오 1을 구현하는 단계를 보여 준다. 중개 모듈에서 HTTP 요청 및 응답을 2진 데이터로 처리할 수 있으려면 구현 전에 몇 가지 단계를 수행해야 한다.

1. Business Integration Perspective에 있는지 확인한다. Business Integration 보기에서 중개 모듈을 작성한 후 새로 작성한 모듈을 마우스 오른쪽 단추로 클릭한다. 상황에 맞는 메뉴에서 Open Dependencies를 선택한다. 다음 그림에서 이 작업의 수행 방법을 보여 준다.

2. Predefined Resources에서 Schema for predefined HTTP bytes data binding을 선택한다. 작업을 저장하고 종속성 편집기를 닫는다.

3. 다음 그림과 같이 Data Types 섹션 아래에 새로운 두 데이터 유형이 작성되었는지 확인한다.

4. 새로 작성된 중개 모듈을 노출하는 데 사용할 새 인터페이스를 작성한다. 인터페이스 입력 및 출력은 페이로드를 2진 데이터로 처리하기 위해 HTTPBytes 유형(앞 단계에서 작성한 두 데이터 유형 중 하나)이어야 한다.

이제 2진 데이터를 받을 수 있는 인터페이스를 작성했으므로 다음 단계에서 이 인터페이스를 Export와 함께 사용하여 HTTP를 통해 모듈을 노출할 수 있는 준비가 완료되었다.

5. Assembly Editor에서 새 Export를 작성한 후 앞에서 작성한 인터페이스를 새 내보내기로 끌어서 놓는다.

6. Assembly Editor에서 작성한 Export를 마우스 오른쪽 단추로 클릭한다. 상황에 맞는 메뉴에서 Generate Binding > HTTP Binding을 선택한다.

7. URL의 일부가 될 Context path를 RESTful 서비스를 나타내는 중개 모듈에 입력한다. 예를 들어, RESTful 서비스의 URL은 http://your_server_ip:your_server_port/RestIntegration_MediationModuleWeb/Export1이 될 수 있다.

8. 내보내기를 중개 플로우 프리미티브에 연결한다.

이제부터는 중개 모듈에서 HTTP를 통해 전달되는 2진 데이터를 받을 수 있다. 이후 단계에서는 시나리오 1을 완성하기 위해 중개 모듈에서 SOAP 기반 백엔드 웹 서비스를 호출하도록 만드는 방법을 보여 준다.

9. Assembly Editor에서 시나리오 1에 대한 샘플 웹 서비스의 WSDL 파일을 캔버스로 끌어서 놓은 후 Import with Web Service Binding을 선택한다. 이 단계에서는 샘플 WSDL을 기반으로 새 가져오기가 작성된다.

10. 중개 플로우 프리미티브를 새로 작성된 가져오기에 연결한다.

11. 중개 플로우를 더블 클릭하여 REST 소비자에게 제공하는 작업을 백엔드 웹 서비스에서 제공하는 작업에 맵핑한다.

12. 캔버스에 대한 새 Business Object Mapper 프리미티브를 작성한다. 이 맵퍼의 용도는 2진 입력을 문자열로 변환하고 조작하는 것이다. 이 맵퍼는 내보내기의 getScore 요청 작업을 통해 전달된 메시지를 가져오기의 getAccountScore 요청 작업으로 변환한다. 이 맵핑은 사용자 정의 중개 또는 XSLT 프리미티브를 사용해서도 수행할 수 있다.

13. 앞 단계에서 작성한 Business Object Mapper 내에서 맵핑을 수행할 사용자 정의 맵을 작성한다.

String inputString= new String((byte[])ServiceMessageObject_body_getScore_input1_value);
String accNum=inputString.split("=")[1];
ServiceMessageObject_1_body_getAccountScore_accountNumber=accNum;

14. 웹 서비스의 응답 문자열을 2진 형식으로 변환하기 위해 비슷한 방법으로 응답 경로에 대한 맵을 작성한다.

String Score="Score=";
Score+=ServiceMessageObject_body_getAccountScoreResponse_score;
ServiceMessageObject_1_body_getScoreResponse_output1_value=Score.getBytes();

이제 위에서 제공한 샘플 웹 서비스에 해당하는 RESTful 중개가 완료되었다. 이 중개는 내보내기(단계 7)에서 지정한 URL을 통해 액세스할 수 있으며 POST HTTP 조치를 받는다. 또한 이 서비스는 HTTP 요청의 본문에서 "AccountNum=XYZ"의 형식으로 매개변수로 전달된 계정 번호에 대한 신용 점수를 검사하는 한 가지 작업을 수행한다. 응답은 매개변수와 관련된 계정 번호의 소유자에 해당하는 신용 점수를 나타내는 문자열을 가지고 있는 2진 형식의 데이터이다.

시나리오 2 이해하기

다음 그림과 같이 시나리오 2의 구현에서도 이전 시나리오와 유사한 아티팩트를 작성하며 그 용도도 비슷하다.

유일한 차이점으로는 내보내기에서 웹 서비스 바인딩을 사용하고 가져오기에서 HTTP 바인딩을 사용한다는 점과 중개 플로우가 SOAP 요청에서 페이로드를 추출하여 2진 페이로드를 샘플 백엔드 RESTful 서비스로 보낸다는 점이 있다.

시나리오 2 구현하기

다음 단계에서는 중개 모듈에서 WebSphere Integration Developer를 사용하여 SOAP 기반 클라이언트와 RESTful 백엔드 서비스 사이에서 중개 기능을 수행하는 방법을 보여 준다.

1. 중개 모듈을 웹 서비스로 노출하기 위해 내보내기와 함께 사용할 새 인터페이스를 작성한다.

2. 인터페이스를 Assembly Editor 캔버스로 끌어서 놓은 다음 Export with Web Service Binding을 선택한다.

3. 여기에서는 시나리오 1을 구현하는 동안 1-4단계에서 작성한 인터페이스와 가져오기를 함께 사용하여 시나리오 2에 사용할 샘플 RESTful 백엔드 서비스를 호출한다. 해당 인터페이스를 캔버스로 끌어서 놓은 후 Import with no Binding을 선택한다. 다음 단계에서는 바인딩을 정의할 차례이다.

4. 작성한 가져오기를 마우스 오른쪽 단추로 클릭하고 Generate Binding > HTTP Binding을 선택한다.

5. REST 공급자의 URL 주소를 지정한다. 이 예제에서는 앞에서 설명한 간단한 서블릿인 doPost() 메소드를 사용한다.

6. Mediation flow를 Import와 Export에 연결한다. 그러면 중개 플로우 자체를 구현할 준비가 완료된다.

이제 위에서 간단한 서블릿으로 제공된 샘플 RESTful 서비스에 해당하는 웹 서비스 중개가 완료되었다. 이 중개는 시나리오 1에서 작성한 중개와 동일한 기능을 수행하며 SOAP 기반 인터페이스를 사용한다.

위로

WebSphere Message Broker 사용하기

WebSphere Message Broker는 메시지 플로우 내에서 세 가지 프리미티브 즉, HTTPInput, HTTPRelpy 및 HTTPRequest를 사용하여 RESTful 상호 작용을 지원한다. 이 섹션의 나머지 부분에서는 WebSphere Message Broker에서 구현할 시나리오 1과 2를 살펴보고 그 구현 방법에 대해 설명한다.

시나리오 1 이해하기

WebSphere Message Broker에서 구현할 시나리오 1은 WebSphere Enterprise Service Bus에서 구현한 시나리오 1과 개념 차원에서 크게 다르지 않다. 다음 그림과 같이 HTTPInput 노드를 사용하여 REST 클라이언트의 HTTP 요청을 받을 수 있다.

HTTPInput은 요청을 Compute 노드에 전달하며, Compute 노드에서는 필요한 추가 처리를 위해 요청 페이로드를 2진 유형에서 문자열 유형으로 변환하는 필수 작업을 수행한다. Compute 노드는 SOAPRequest 노드를 통해 시나리오 1에 대한 샘플 백엔드 웹 서비스를 호출하여 SOAP 기반 통신을 처리한다. HTTPReply 노드는 HTTP 응답을 생성하여 요청을 보낸 REST 클라이언트에게 보낸다.

시나리오 1 구현하기

이 섹션에서는 WebSphere Message Brokers Toolkit을 사용하여 시나리오 1을 구현하는 단계를 보여 준다.

1. Message Flow를 작성한 다음 HTTPInput 노드를 캔버스를 끌어서 놓고 HTTPInput에 대한 Path suffix for URL을 입력한다. 이 접미부는 RESTful 서비스를 나타내는 플로우에 대한 URL 주소의 일부로 사용된다. 예를 들어, http://localhost:7080/Rest를 사용하여 요청 주소에 대한 입력 노드에 액세스할 수 있다.

2. REST 클라이언트에서 보낸 메시지의 페이로드를 노드에서 구문 분석하지 않도록 하기 위해 메시지 유형이 "BLOB"(Binary Large Object)인지 확인한다. 이렇게 하면 페이로드가 2진 데이터인 상태 그대로 잠시 후에 작성할 Compute 노드에 전달된다.

3. 이제 샘플 백엔드 웹 서비스를 호출하는 부분이다. 시나리오 1에서 가져온 샘플 백엔드 웹 서비스의 WSDL 파일을 캔버스로 끌어서 놓는다. 그러면 Service Invocation 서브플로우가 자동으로 작성된다. 서브플로우를 더블 클릭했을 때 호출 프리미티브가 사용 가능하면 정상적으로 작성된 것이다.

4. 메시지 형식을 BLOB와 SOAP로 상호 변환할 수 있도록 Service Invocation의 앞과 뒤에 Compute 노드를 추가한다. 그런 다음 필수 응답을 리턴하는 HTTPReply 노드를 배치한다.

5. 변환을 수행하는 코드를 추가하려면 Service Invocation 앞에 있는 Compute 노드를 더블 클릭한다. 다음 코드를 사용하여 이 작업을 수행할 수 있다.

DECLARE InputString CHARACTER;
DECLARE OutString CHARACTER;
DECLARE CCNum CHARACTER;
SET InputString = CAST ( InputRoot.BLOB.BLOB AS CHAR CCSID 1208);
		
SET OutString = OVERLAY(InputString PLACING '' FROM 1 FOR POSITION('=' IN InputString));

SET OutputRoot.SOAP.Body.ns:getAccountScore.accountNumber=OutString;
RETURN TRUE;

6. Listing 6과 같이 Service Invocation 뒤의 Compute 노드에 대한 코드를 추가한다.

DECLARE OutString CHARACTER 'Score=';
Set OutString=  OutString || InputRoot.XMLNSC.ns:getAccountScoreResponse.score;
SET OutputRoot.BLOB.BLOB=CAST (OutString AS BLOB CCSID 1208);
RETURN TRUE;

위 단계를 완료하면 WebSphere Enterprise Service Bus에서 시나리오 1을 구현할 때 작성했던 RESTful 중개와 동일한 작업을 수행하는 RESTful 중개가 완성된다. 새 RESTful 서비스의 URL 주소는 위의 단계 1에서 지정한 주소이다.

시나리오 2 이해하기

WebSphere Message Broker에서는 웹 서비스 클라이언트의 SOAP 기반 요청을 받을 수 있는 SOAPInput 노드를 제공한다. 다음 그림에서는 그러한 요청을 Compute 노드에 전달하여 수신 요청을 SOAP에서 2진 데이터로 변환하는 과정을 보여 준다.

2진 메시지는 앞에서 언급한 샘플 RESTful 서비스를 호출하는 데 사용되며 이 서비스는 시나리오 2의 HTTPRequest 노드에서 사용된다. 그런 다음 Compute 노드를 사용하여 결과를 SOAP로 다시 변환하며, 이렇게 변환된 결과는 SOAPReply 노드를 통해 요청을 보낸 웹 서비스 클라이언트에게 다시 보낼 수 있다.

시나리오 2 구현하기

이 섹션에서는 WebSphere Message Broker의 Toolkit을 사용하여 시나리오 2를 구현하는 단계를 보여 준다.

1. 1. 플로우를 웹 서비스로 노출하기 위해 샘플 웹 서비스의 WSDL 파일을 새 메시지 세트로 가져온다. 다음 단계에서 사용하기 위해 WSDL을 캔버스로 끌어서 놓는다.

2. RESTful 백엔드 서비스로 보낼 수 있도록 수신 메시지 데이터를 SOAP에서 BLOB(2진)로 변환하는 Compute 노드를 배치한다.

DECLARE OutString CHARACTER 'AccountNum=';
Set OutString=  OutString || InputRoot.SOAP.Body.ns:getAccountScore.accountNumber;
SET OutputRoot.BLOB.BLOB=CAST (OutString AS BLOB CCSID 1208);
RETURN TRUE;

DECLARE InputString CHARACTER;
DECLARE OutString CHARACTER;
SET InputString = CAST ( InputRoot.BLOB.BLOB AS CHAR CCSID 1208);
SET OutString = OVERLAY(InputString PLACING '' FROM 1 FOR POSITION('=' IN InputString));
Set OutputRoot.XMLNSC.ns:getAccountScoreResponse.score=OutString;
RETURN TRUE;

3. 샘플 백엔드 RESTful 서비스를 호출할 HTTPRequest 노드를 배치한다.

4. HTTPRequest 노드에 RESTful 서비스의 URL 주소를 입력한다. 이 예제에서는 앞에서 설명한 간단한 서블릿인 doPost() 메소드를 사용한다.

5. 마지막으로 백엔드 RESTful 서비스에서 보낸 응답을 추가한 SOAPReply 노드를 통해 호출 웹 서비스 클라이언트에 보낼 SOAP 응답으로 변환할 Compute 노드를 배치한다.

이제 시나리오 2를 구현하는 동안 WebSphere Enterprise Service Bus를 사용하여 앞에서 작성한 웹 서비스와 완전히 동일하게 작동하는 웹 서비스가 준비되었다.

위로

WebSphere DataPower 사용하기

WebSphere DataPower는 다양한 방법으로 RESTful 상호 작용을 지원하지만 이 섹션에서는 WebSphere DataPower에서 시나리오 1과 2를 구현하는 한 가지 방법만 설명한다.

시나리오 1 이해하기

여러 방법으로 시나리오 1을 구현할 수 있지만 이 기사에서는 XML Firewall을 사용하여 REST 클라이언트의 HTTP 요청을 받는 권장 방법(다음 그림 참조)에 대해서만 설명한다.

수신 요청에는 2진 페이로드가 들어 있으므로 XML Firewall에서는 WebSphere Transformation Extender 맵을 사용하여 해당 2진 페이로드를 웹 서비스에서 받을 수 있는 SOAP로 변환한다. 이와는 반대로 웹 서비스의 SOAP 응답을 요청을 보낸 REST 클라이언트에 보낼 수 있는 2진으로 변환하는 작업도 수행된다. 이러한 변환 외에도 XML Firewall에서는 XSLT 함수를 사용하여 Web Service Proxy를 통해 백엔드 웹 서비스를 호출한다. 따라서 이 시나리오에서는 XML Firewall에 대한 루프백 옵션을 사용한다. 이 작업은 Web Service Proxy를 호출하는 정적 백엔드를 사용해서도 수행할 수 있다.

다음 기사 http://www.ibm.com/developerworks/websphere/techjournal/0903_peterson/0903_peterson.html에서 2진 페이로드를 처리하지 않는 방식으로 작업을 수행하는 이 구현의 다른 변형에 대한 자세한 정보를 볼 수 있다.

시나리오 1 구현하기

이 섹션에서는 WebSphere DataPower에서 시나리오 1을 구현하는 데 필요한 단계를 보여 준다. 먼저 2진과 XML을 상호 변환하기 위한 맵핑을 수행한다. 그런 다음 백엔드 웹 서비스와의 통신을 처리하도록 Web Service Proxy를 구성한다. 마지막으로 REST 요청을 수신하는 XML Firewall을 사용하여 작성한 맵을 사용하여 2진 페이로드를 XML로 변환하여 Web Service Proxy로 전달한다. 그러면 Web Service Proxy가 XML을 샘플 백엔드 웹 서비스에 전달한다.

먼저 수신 요청 메시지와 샘플 백엔드 웹 서비스에 전달되는 SOAP 메시지를 정의하기 위해 WebSphere Transformation Extender Design Studio를 사용하여 두 개의 Type Trees를 작성하자.

xml 이외의 입력의 경우 유형 트리를 수동으로 생성하며, 이러한 입력은 AccountID=123의 형태로 수신된다.

1. REST 클라이언트에서 보내는 메시지에 대한 새 Type Tree를 작성한다. 이러한 메시지는 2진 데이터(XML 이외의 데이터)로 처리된다.

2. 다음 그림과 같이 새로 작성한 Type Tree 아래에 하나의 Group과 두 개의 Items를 작성한다.

3. REST 클라이언트의 페이로드는 AccountNum=123 형식이므로 "Property" Item의 종결 기호를 "="로 설정한다. 이렇게 하면 WTX 엔진은 '=' 기호의 앞부분을 "Property" 형식으로 해석하고 기호의 뒷부분을 값으로 해석한다.

4. Tree > Analyze를 선택한 다음 Save를 선택한다.
5. 샘플 백엔드 웹 서비스에 보낼 SOAP 메시지에 대한 또 하나의 Type Tree를 작성한다. 샘플 백엔드 웹 서비스의 WSDL 파일을 가져와서 이 Type Tree를 작성할 수 있다.

6. 기본값을 승인한 후 마지막에 Finish 단추를 누른다. 생성된 트리를 연 다음 Analyze와 Save를 차례로 선택한다.

이제 두 개의 MTT(Map Type Tree) 파일이 작성되었다. 다음 단계에서는 클라이언트의 2진 메시지를 설명하는 Binary.mtt라는 파일과 샘플 백엔드 웹 서비스의 WSDL 파일을 기반으로 하는 메시지를 설명하는 AccountScore.mtt라는 파일을 찾는다. 이제 다음 단계를 수행하여 이러한 Type Trees를 통해 Map 자체를 작성할 준비가 완료되었다.

7. 다음 그림과 같이 Input Card와 Output Card가 하나씩 있는 새 맵을 작성한다.

8. Input Card "Binary"의 특성 값을 아래 그림처럼 설정한다. 여기서 binary.txt라는 텍스트 파일에는 테스트를 위해 AccountID=123이라는 컨텐츠가 있다. Type Tree 특성을 앞에서 2진 메시지용으로 작성한 Type Tree의 이름으로 설정한다는 점에 유의한다.

9. 다음 그림과 같이 Output Card "XML_OUT"의 특성을 설정한다. 이 카드에서는 앞에서 SOAP 기반 웹 서비스 메시지용으로 작성한 다른 Type Tree를 사용한다.

10. 다음 그림의 값을 사용하여 맵핑을 완료한다.

11. Map > Build를 선택한 다음 Map > Run을 선택하여 맵을 테스트한다.
12. 맵의 Map Settings의 MapRuntime 특성을 WebSphere Transformation Extender 대신 DataPower로 변경한다. 이렇게 하면 ".dpa" 확장자를 사용하여 컴파일된 맵을 DataPower에 전개할 수 있다. 예를 들어, 이 파일에 "BinaryToXML.dpa"라는 이름을 지정할 수 있다. Map > Build를 선택하여 파일을 생성한다.

이제 필수 유형 맵핑을 모두 수행했으므로 WebSphere DataPower SOA Appliance에서 작성한 아티팩트를 전개할 준비가 완료되었다. 맵핑을 적용하려면 먼저 다음 단계를 수행하여 WebSphere DataPower에서 Web Service Proxy와 XML Firewall을 작성해야 한다.

1. Control Panel에서 Web Service Proxy 아이콘을 클릭하고 Add를 클릭한다. Web Service Proxy 이름(예: WS-BinaryToSOAP)을 입력하고 Create Web Service Proxy 단추를 클릭한다.
2. 샘플 백엔드 웹 서비스의 WSDL을 아직 업로드하지 않은 경우에는 File to upload을 입력하고 Upload를 클릭한다.

3. 파일을 업로드한 후 Next를 클릭한다.

4. 새 Front Side Handler를 작성한다. IP, Port 및 지원할 동사를 할당한 다음 Add를 클릭한다.

5. 백엔드 샘플 웹 서비스에 대한 IP, port and Remote URI를 설정한 다음 Next를 클릭한다.

이제 Web Service Proxy가 구성되었으므로 샘플 백엔드 서비스를 호출할 준비가 완료되었다. 다음 단계에서는 방금 작성한 Web Service Proxy에 수신 요청을 제공해야 하는 루프백 XML Firewall을 구성하는 방법을 보여 준다.

1. DataPower Control Panel에서 XML Firewall을 선택한다. 그런 다음 Add를 클릭한다.
2. 다음 그림과 같이 Pass Thru를 선택한다. 그런 다음 Next를 클릭한다.

3. 이름을 입력한다. 예: RESTtoSOAPService.
4. Firewall Type을 loopback-proxy로 선택한다.
5. 들어오는 클라이언트 요청을 수신할 Device Address와 포트를 입력한다. IP 주소를 0.0.0.0으로 설정하면 안된다. Next를 클릭한다.

6. Commit와 Done을 차례로 선택한다.
7. 이 기사에서는 REST 클라이언트의 2진 페이로드를 예상하고 있으므로 XML Firewall 설정을 열고 Request Type을 Non-XML로 변경한다.
8. Firewall Policy를 편집하기 위해 연다. 이 화면에는 아래에서 설명하는 4가지 조치가 있다.

9. Match Rule: 지정된 IP 주소 및 포트에서 임의의 URI에 대해 들어오는 모든 요청을 받는다.
10. Binary Transformation 조치: 다음과 같이 앞 단계에서 작성한 WTX 맵 중 하나를 호출하여 2진 입력을 SOAP Request로 변환한다.

11. Transformation 조치: 간단한 XSLT를 사용하여 Web Service Proxy를 통해 샘플 백엔드 서비스를 호출한 다음 요청을 보낸 클라이언트에 돌려 보낼 응답 메시지를 작성한다. 이 변환의 스타일 시트는 다음과 같다.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
    xmlns:dp="http://www.datapower.com/extensions"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    extension-element-prefixes="dp"
    exclude-result-prefixes="dp"
    version="1.1">
    
    <xsl:template match="/">
        <xsl:copy-of
select="dp:soap-call('http://the_address_of_wsproxy:the_port
                    _of_wsproxy/mockAccountScoreSOAP',/,'',0)"/>
    </xsl:template>
    
</xsl:stylesheet>

12. Binary transformation 조치: SOAP 응답을 클라이언트에 보낼 XML 이외의 응답으로 변환하는 XSL 스타일 시트를 사용한다. 이 변환의 스타일 시트는 다음과 같다.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
                xmlns:fo="http://www.w3.org/1999/XSL/Format">
<xsl:output method="text"/>
<xsl:template match="/">score=<xsl:value-of select="//score"/>
</xsl:template>
</xsl:stylesheet>

위 단계를 수행하면 WebSphere Enterprise Service Bus와 WebSphere Message Broker에서 시나리오 1을 구현할 때 작성했던 RESTful 서비스와 동일한 작업을 수행하는 RESTful 서비스가 완성된다. 새 RESTful 서비스의 URL 주소는 XML Firewall의 주소이다.

시나리오 2 이해하기

시나리오 2에서는 다음과 같이 기본적으로 Web Service Proxy와 XML Firewall을 상호 전환한다.

Web Service Proxy는 샘플 백엔드 웹 서비스의 WSDL을 기반으로 웹 서비스 클라이언트의 SOAP 요청을 받은 다음 XML Firewall에 전달하여 SOAP를 2진으로 변환하는 필수 작업을 수행한다. 또한 XML Firewall은 샘플 백엔드 RESTful 서비스를 호출한다.

시나리오 2 구현하기

시나리오 1에서와 마찬가지로 먼저 WebSphere Transformation Extender Design Studio를 사용하여 XML 기반 컨텐츠와 2진 컨텐츠 간의 맵핑을 수행하는 데 필요한 아티팩트를 작성한다. 다행스럽게도 시나리오 1에서 작성한 두 가지 트리 유형을 사용할 수 있지만 그 사용 방법은 다르다. 다음 단계에서는 샘플 백엔드 RESTful 서비스에서 리턴한 2진 응답을 SOAP에 맵핑하기 위한 Response Map을 작성하는 방법을 보여 준다. 이 맵핑을 수행하고 나면 요청을 보낸 웹 서비스 클라이언트에게 Web Service Proxy를 통해 응답을 돌려 보낼 수 있다.

1. 시나리오 1에서 요청 맵을 작성할 때와 동일한 단계를 수행하여 Response Map을 작성한다. XML_OUT Output Card의 경우 다음 그림처럼 응답에 대해 Envelope 그룹을 선택한다.

2. 다음 그림처럼 맵핑을 완료한다. Rules > Insert NONE if Empty를 선택하여 빈 필드를 자동으로 NONE으로 설정할 수도 있다.

3. Map > Build를 선택한 다음 Map > Run을 선택하여 맵을 테스트한다.
4. 시나리오 1에서와 마찬가지로 Map Settings에서 MapRuntime을 WebSphere DataPower로 변경한다.

이제 WebSphere DataPower에 사용할 맵핑 아티팩트가 준비되었다. 다음 단계에서는 WebSphere DataPower에서의 필수 구성을 보여 준다.

Web Service Proxy를 작성하기 위해 시나리오 1에서 수행했던 것과 동일한 단계를 수행한다. 하지만 백엔드를 웹 서비스로 설정하는 대신 아래에서 작성할 XML Firewall의 IP Address 및 Port로 설정한다. 이 XML Firewall에서는 샘플 백엔드 RESTful 서비스와 통신할 수 있도록 SOAP 요청/응답을 2진으로 상호 변환한다.

또한 XML Firewall을 작성해야 한다. 다음 단계에서는 자세한 과정을 보여 준다.

1. 정적 백엔드를 사용하여 새 XML Firewall(시나리오 1에서 사용한 루프백 대신)을 작성한다. 샘플 백엔드 RESTful 서비스를 호스팅하는 서버의 Server Address와 Port를 입력한다.

2. 새로 작성한 XML Firewall을 열고 프론트엔드에 대한 Request Type을 SOAP로 설정하고 백엔드에 대한 Request Type을 Non-XML로 설정한다.
3. Processing Policy를 열고 다음과 같이 Request Rule과 Response Rule을 작성한다.
   1. Request Rule의 경우 다음 조치를 정의한다.
   2. Response Rule의 경우 Binary Transformation 조치만 작성한다. 이 조치는 사용자가 작성한 WebSphere Transformation Extender Response Map을 사용하여 2진 응답을 SOAP 응답으로 변환하며, 이렇게 변환된 응답은 요청을 보낸 웹 서비스 클라이언트에게 Web Service Proxy를 통해 전달된다.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
            xmlns:fo="http://www.w3.org/1999/XSL/Format">
<xsl:output method="text"/>
<xsl:template match="/">AccountID=<xsl:value-of select="//accountNumber"/>
</xsl:template>
</xsl:stylesheet>

이제 시나리오 2를 구현하는 동안 WebSphere Enterprise Service Bus와 WebSphere Message Broker를 사용하여 앞에서 작성한 웹 서비스와 완전히 동일하게 작동하는 웹 서비스가 준비되었다.

위로

서비스 공급자 테스트하기

지금까지 서비스를 위한 다양한 인터페이스를 다루어 보았으며, 이들 중 일부는 SOAP 기반 인터페이스이고, 일부는 RESTful 인터페이스이다. 이제 몇 가지 샘플 도구를 사용하여 서비스가 올바르게 작동하는지 확인하는 방법을 살펴보자. 이 기사에서 종합적인 도구 목록을 제공하지는 않지만 이러한 도구가 사용자가 작성한 중개와 백엔드 서비스를 테스트하는 데 유용하다는 것을 알 수 있다. 다음 그림에서는 설명하려는 도구에 대한 요약과 앞에서 구현한 두 시나리오를 기반으로 서비스 공급자를 테스트하는 적절한 용도를 보여 준다.

위로

TCP/IP Monitor

TCP/IP Monitor는 WebSphere Integration Developer, 기타 여러 Rational Software Delivery 제품 및 기본 Eclipse 플랫폼과 함께 제공되는 유용한 유틸리티이다. TCP/IP Monitor를 사용하면 클라이언트와 애플리케이션 서버 사이의 트래픽을 모니터링할 수 있다. 또한 TCP/IP Monitor에서는 이 기사에서 작성한 RESTful 서비스와 웹 서비스의 트래픽을 볼 수도 있다. 다음 단계에서는 WebSphere Integration Developer를 사용하여 RESTful 클라이언트와 서비스 공급자 사이의 트래픽을 모니터링하는 예제를 보여 준다. 서비스 공급자는 시나리오 2에서 사용한 서블릿인 샘플 RESTful 백엔드 서비스나 시나리오 1에서 서비스를 랩핑하기 위해 작성했던 중개일 수 있다.

1. Window > Show view > TCP/IP Monitor를 클릭한다.

2. TCP/IP Monitor 보기의 내부를 마우스 오른쪽 단추로 클릭한 다음 Properties를 선택한다.

3. TCP/IP 모니터링 서버를 추가하고 서비스를 테스트 중인 환경과 일치하도록 포트를 변경한다.

4. 이 구성을 사용하면 서비스에 대한 트래픽을 모니터링할 수 있어야 한다. REST 클라이언트의 요청을 RESTful 서비스에 전송한다. 요청은 TCP/IP 모니터링 서버의 포트가 아닌 RESTful 서비스가 전개된 포트로 전송된다는 점에 유의해야 한다. 예를 들어, 위 그림과 같이 RESTful 백엔드 서비스를 포트 9090에 전개했다면 클라이언트에서는 사용자가 작성한 모니터의 포트 9083이 아닌 포트 9090에 요청을 전송해야 한다. REST 클라이언트가 준비되지 않은 경우에는 이 용도로 사용할 수 있는 도구와 서비스를 테스트하는 데 사용할 수 있는 클라이언트용 코드 샘플이 표시되므로 걱정하지 않아도 된다.
5. 요청을 서비스에 전송하면 TCP/IP Monitor 보기에서 해당 컨텐츠를 즉시 볼 수 있다. 이 보기에는 클라이언트에서 보낸 요청이 표시되며 중개 모듈의 응답을 사용할 수 있다.

이 섹션의 앞부분에서 설명한 대로 위에서 설명한 것과 동일한 단계를 수행하여 TCP/IP Monitor를 통해 웹 서비스를 모니터링할 수 있다.

위로

cURL

cURL은 파일과 데이터를 URL로 전송하여 사용자가 작성한 RESTful 공급자를 테스트하는 데 적합한 파일과 데이터로 만들어 주는 유명한 써드파티 오픈 소스 명령행 도구이다. 다음은 WebSphere Enterprise Service Bus에서 작성한 예제 중개 플로우에 요청을 전송하는 데 사용할 수 있는 샘플 명령이다.

curl -H "Content-type: text/plain" -X POST -d "AccountNum=123"  
http://your_server_ip:your_server_port/RestIntegration_Medi
ationModuleWeb/Export1

제공된 샘플 RESTful 서비스의 논리에 따라 서비스에서 리턴된 응답은 Score=4000이어야 한다. 앞 섹션에서 설명한 대로 cURL과 TCP/IP Monitor를 사용하는 서비스 사이에서 이 명령의 결과로서 교환된 요청 및 응답을 모니터링할 수 있다.

cURL을 사용하여 SOAP 요청을 사용자가 작성한 웹 서비스 공급자에게 전송할 수도 있다.

위로

RESTClient

RESTClient는 RESTful 애플리케이션을 테스트하는 데 사용할 수 있는 또 하나의 써드파티 오픈 소스 Java 애플리케이션이다. 다음 단계에서는 이 애플리케이션을 사용하여 RESTful 서비스를 테스트하는 방법을 보여 준다.

1. 다음 명령을 사용하여 RESTClient를 실행한다.

 
$ java –jar [path to RESTClient jar]

2. 테스트할 RESTful 서비스 공급자의 URL을 입력한다. 예를 들어, WebSphere Enterprise Service Bus의 시나리오 1에서 작성한 중개 플로우의 URL을 입력한다.

3. HTTP 메소드를 POST로 변경한다.

4. Body 탭을 클릭한 후 RESTful 서비스에 보낼 페이로드인 "AccountNum=123"을 입력한다.

5. URL 필드 옆의 Send 단추를 누르고 RESTful 서비스의 응답을 관찰한다.

앞에서 설명한 대로 cURL을 사용하면 TCP/IP Monitor를 사용하여 RESTClient에서 RESTful 서비스 공급자로 전송되는 트래픽을 모니터링할 수 있다.

위로

Web Service Explorer

TCP/IP Monitor와 마찬가지로 Web Service Explorer는 WebSphere Integration Developer와 함께 제공되는 도구이며 Eclipse 플랫폼의 일부이다. Web Service Explorer를 통해 개발자는 웹 서비스의 WSDL 및 해당 위치를 사용하여 해당 서비스를 호출할 수 있다. 다음 단계에서는 WebSphere Integration Developer 내에서 Web Service Explorer를 사용하여 웹 서비스 공급자를 테스트하는 방법을 보여 준다.

1. 테스트할 서비스의 WSDL 파일을 마우스 오른쪽 단추로 클릭한다. Web Services > Test With Web Service Explorer를 선택한다.

2. 웹 서비스의 엔드 포인트가 나열되지 않은 경우에는 Add 링크를 사용하여 엔드 포인트를 추가한다.

3. 호출할 작업을 클릭한다. 예를 들어, 제공된 샘플 웹 서비스의 getAccountScore()나 시나리오 2에서 작성한 중개를 클릭한다(위 이미지 참조).
4. 엔드 포인트를 선택한 후 전송할 웹 서비스 매개변수를 추가한다. 예를 들어, "123"을 추가하고 Go 단추를 클릭한다.

5. 웹 서비스 공급자에서 리턴된 결과가 표시되어야 한다.

위로

RESTful 서비스 공급자 사용하기

RESTful 서비스를 노출하여 얻게 되는 장점 중 하나는 다양한 클라이언트 프로그래밍 언어에서 상호 운용성 문제 없이 RESTful 서비스를 사용할 수 있다는 것이다. 이는 RESTful 상호 작용이 다양한 소프트웨어 제품 공급자들 간에 매우 안정적인 HTTP 프로토콜을 기반으로 하기 때문이다. 다음은 JAVA, .NET 및 PHP로 작성된 코드로 시나리오 1에서 작성한 것과 동일한 RESTful 서비스와 시나리오 2에서 사용한 샘플 백엔드 RESTful 서비스를 호출한다.

Java 소비자

Java 기반 소비자의 예로는 JSP(JavaServer Page) 또는 Servlet이 있다. 다음 Listing에서는 사용자가 노출한 RESTful 서비스를 호출하는 방법을 보여 준다.

//(1)
	URL url = new URL(the_URL_address_of_the_REST_provider);
	HttpURLConnection con = (HttpURLConnection)url.openConnection();
			
	//(2)
	con.setRequestMethod("POST");
		
	//(3)
	con.setRequestProperty("Content-Type", "text/plain");
			
	//4
	String content=”AccountNum=123”
	byte[] contentBytes=content.getBytes();

	//5		    
	OutputStream out = con.getOutputStream();
	out.write(contentBytes);
	out.flush();
	out.close();
		
	//6	    	
	BufferedReader br
			=new BufferedReader(new InputStreamReader(con.getInputStream()));
	String result = br.readLine();
	con.disconnect();

단계 (1)에서는 RESTful 공급자에 대한 연결을 연다. 단계 (2)에서는 HTTP 메소드를 POST로 설정하여 RESTful 서비스에서 실행할 작업을 결정한다. 단계 (3)에서 HTTP 헤더가 설정된다. 단계 (4)에서는 문자열을 바이트 배열 즉, 2진으로 변환하여 스트림을 통해 전송할 요청을 준비한다. 단계 (5)에서 요청이 전송된다. 단계 (6)에서는 서비스에서 리턴된 응답을 읽는다.

.NET 소비자

앞의 경우와 마찬가지로 .NET 소비자는 웹 기반 또는 Windows 애플리케이션일 수 있다. 웹 기반일 경우에는 기존의 ASP 또는 최신 ASP.NET일 수 있다.

//(1)
	// url is the address of the REST provider 
	HttpWebRequest myReq =(HttpWebRequest)WebRequest.Create((String) url );
	
	//(2)			
	myReq.Method = "POST";
	String content=”AccountNum=123”
	byte[]  contentdata = Encoding.UTF8.GetBytes(content);
	myReq.ContentLength = contentdata.Length   ;			
	myReq.ContentType = "text/plain ;					
	myReq.Credentials = CredentialCache.DefaultCredentials;
	
	//(3)
	Stream strm =  myReq.GetRequestStream();
	strm.Write(contentdata,0,contentdata.Length);    
	strm.Close();
			

	//4		
	HttpWebResponse myres =( HttpWebResponse)myReq.GetResponse();
	Stream recStream = myres.GetResponseStream();
	StreamReader strRead = new StreamReader(recStream, Encoding.UTF8);
	string result = strRead.ReadToEnd();
	strRead.Close();
	myres.Close();

단계 (1)에서는 RESTful 공급자에 대한 웹 요청을 연다. 단계 (2)에서는 HTTP 요청 헤더를 설정한 후 단계 (3)에서 스트림을 통해 서비스에 전송할 페이로드를 준비한다. 단계 (4)에서는 서비스의 응답을 읽은 후 보유 중인 리소스를 릴리스한다.

PHP 소비자

PHP로 작성된 소비자는 다음과 같다.

//(1)
	$properties = array(
	  'http'=>array(
	    'method'=>"POST"
	    ,'header'=>"Content-Type: text/plain; charset= utf-8\r\n"
	    ,"content"=>"AccountNum=123"
	    )
	    );

	//(2)	    
    	$context = stream_context_create($properties);

	//(3)
	// $url is the address of the REST provider 
	$result = file_get_contents($url, false, $context);

단계 (1)에서는 단계 (2)에서 수행할 클라이언트와 서버 사이의 스트림을 작성하는 데 필요한 특성을 설정한다. 단계 (3)에서는 RESTful 서비스에 요청을 보내고 리턴된 결과를 받는다.

위로

감사의 인사

이 기사를 검토하고서 소중한 의견을 제안해 준 Greg Flurry에게 감사의 뜻을 전한다.

위로

결론

레거시 애플리케이션을 RESTful 서비스로 노출하는 기능을 Enterprise Service Bus에 위임할 수 있으며 Enterprise Service Bus를 사용하여 RESTful 서비스 자체를 다양하게 노출할 수도 있다. 이 기사에서는 백엔드 웹 서비스를 RESTful 서비스로 노출하는 시나리오와 백엔드 RESTful 서비스를 웹 서비스로 노출하는 서비스 등의 두 가지 시나리오를 살펴보았다. 이러한 두 시나리오를 WebSphere Enterprise Service Bus, WebSphere Message Broker 및 WebSphere DataPower에서 구현해 보았다. 또한 웹 서비스와 RESTful 인터페이스를 테스트하는 방법도 살펴보았다. 마지막으로 동일한 RESTful 서비스를 사용하는 소비자를 다양한 프로그래밍 언어로 구현하여 REST 형식으로 완전하게 상호 작용할 수 있는 뛰어난 상호 운용성을 살펴보았다.

참고자료

교육

• WebSphere Integration Developer HTTP 기능 선택기 개요를 읽어보자.
  
  
• WebSphere Integration Developer의 사전 패키지된 HTTP 데이터 형식 변환에 대해 자세히 알아보자.
  
  
• WebSphere Message Broker 정보 센터에서 추가 정보를 확인할 수 있다.
  
  
• "Implementing REST services with WebSphere DataPower SOA Appliances"(developerWorks, 2009년 3월)에서는 Web 2.0과 WebSphere DataPower SOA Appliances를 이용한 REST에 대해 설명한다.
  
  
• 추가 WebSphere DataPower Documentation을 읽어보자.
  
  
• IBM WebSphere DataPower SOA Appliance Handbook을 읽어보자.
  
  
• 추가 WebSphere DataPower Documentation을 읽어보자.
  
  
• WebSphere DataPower SOA Appliances에 대한 새 Redbook을 읽어보자.
  
  

제품 및 기술 얻기

• IBM 시험판 제품을 다운로드하거나 IBM SOA Sandbox의 온라인 시험판을 살펴보고 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®의 애플리케이션 개발 도구 및 미들웨어 제품을 사용해 볼 수 있다.
  
  

필자소개

Ahmed Abbas는 Cairo Technology Development Center 소속의 IT Architect이며 랩 서비스에서 고객의 비즈니스 요구에 부응하기 위해 기술의 이론과 실제 구현 사이의 차이를 줄여나가는 데 많은 관심을 두고 있다.

Mohab El-Hilaly는 이집트의 IBM Cairo Technology Development Center에서 Staff Software Engineer로 활동하고 있으며 다양한 고객을 위해 Websphere Enterprise Service Bus 기술을 사용하여 사용자 정의 솔루션을 개발 및 설계하고 있다. 이전에는 다양한 Microsoft 기술(주로 ASP.NET)을 사용하여 사용자 정의 솔루션을 개발했었다. 카이로의 American University에서 전산학을 전공한 그는 여가 시간에 축구 경기를 하거나 관람하는 것을 좋아한다.

Hany Harraz는 이집트의 Cairo lab에서 ISSW Tech Practice 팀 소속의 WebSphere Consultant로 활동하고 있으며 주로 WebSphere Transformation Extender, DataPower 및 WebSphere Message Broker와 관련된 업무를 맡고 있다. 이전에는 다양한 Microsoft 기술(주로 C#)을 사용하여 사용자 정의 솔루션을 개발했었다. 카이로의 Cairo University에서 전산학을 전공한 그의 취미는 여행과 다이빙이다.

아티클 순위

의견

위로

목차

• 소개
• RESTful 서비스의 특징
• 관련 Web 2.0 기술
• Enterprise Service Bus의 역할
• 중개 기능 구현하기
• WebSphere Enterprise Service Bus 사용하기
• WebSphere Message Broker 사용하기
• WebSphere DataPower 사용하기
• 서비스 공급자 테스트하기
• TCP/IP Monitor
• cURL
• RESTClient
• Web Service Explorer
• RESTful 서비스 공급자 사용하기
• 감사의 인사
• 결론
• 참고자료
• 필자소개
• 의견