'Network' 카테고리의 글 목록

Network

[WebService] 웹 서비스에 대하여 2019.09.18

[WebService] 웹 서비스에 대하여

2019. 9. 18. 15:04

개요

회사에서 진행하는 프로젝트에서 Apache Axis2를 사용하게 된 적이 있었다.

당시의 나는 SOAP, REST와 같은 웹 서비스에 대한 개념이 부족하여 여기저기 찾아보고는 했는데, 그때 조사한 내용을

이 글에 작성하고자 한다.

웹 서비스란?

출저 : https://javabeat.net/webservices-rest-vs-soap/

웹 서비스는 네트워크 상에서 상호운용 가능한 기계 간의 통신을 지원하도록 설계된 소프트웨어 시스템
Machine-Processable 포맷 (WSDL)으로 기술된 인터페이스이다.
다른 시스템들은 일반적으로 XML 직렬화로 HTTP를 사용하여 전달되는 SOAP 메시지를 사용하여 웹 서비스와 상호작용한다.
월드 와이드 웹(WWW)과는 달리 웹 서비스는 순수 컴퓨터와 컴퓨터간의 상호작용을 위한 시스템이다.
2002년에는 3가지 주요 표준(SOAP, WSDL, UDDI) 모두를 사용하는 것을 웹 서비스라고 정의하였으나, 2003년부터 어느 한가지만을 사용해도 웹 서비스를 구현한 것으로 정의하고 있다.

웹 서비스의 등장 배경

기존의 통합 방식

서로 다른 플랫폼 기반 어플리케이션 간 통신 수단이 상이하여 통합이 사실상 어려움
통합을 위해 EDI, VAN, Adapter, EAI/B2Bi 등 proprietary한 기술/솔루션을 적용하거나 전면 재개발
→ 많은 시간, 투자, 리소스가 요구

웹 서비스의 등장

인터넷과 XML 기반 SOAP과 같이 표준화된 통신 수단을 사용하여 서로 다른 플랫폼 기반 어플리케이션간 통신이 가능해짐
→ 별도의 솔루션을 도입할 필요 없이 통합이 가능해져 비용과 시간을 절약

웹 서비스의 특징

시스템 구조의 유연성 : 메인 프레임 또는 서버-클라이언트 방식과 달리 유연한 소프트웨어 구조를 통해 이질적인 데이터 표준을 유연하게 통합/운영
사용의 편리성 : 사용자는 소프트웨어를 설치한 후 자연스럽게 서비스를 제공받게 되며, 인터넷을 연결할 수 있는 유/무선 단말기를 통해 장소에 관계없는 접근 가능
기존 시스템의 통합 환경을 제공 : 이질적인 어플리케이션간의 통합 서비스를 제공받을 수 있고, 새로운 시스템과의 통합도 자동적으로 이루어진다.
비용 효율적 : 분산 시스템의 소프트웨어 간 통합을 자동화적으로 이행해줌으로써 개별 기업마다 투입해야 하는 IT 개발 및 운영 비용을 절감

웹 서비스의 구성 요소

출저 : http://www.jidum.com/jidums/view.do?jidumId=832

웹 서비스의 구성요소로는 크게 SOAP, WSDL, UDDI 세가지가 있다.

WSDL(Web Service Description Language)

웹 서비스를 표현하고 기술하는 언어(서비스 표현 언어)
웹 서비스의 공개 인터페이스를 설명하기 위한 XML 문법
공개 인터페이스
- 공개적으로 사용할 수 있는 기능들의 정보
- XML 메시지를 위한 데이터 타입 정보
- 사용된 전송 프로토콜에 관한 바인딩 정보
- 특정한 서비스 위치에 관한 주소 정보
WSDL은 SML(Service Metadata Locator) 메시지 시스템에 꼭 필요한 것은 아니지만 SOAP 메시지를 기술하기 위한 빌트인 익스텐션(built-in extensions)을 포함하고 있다.

UDDI(Universal Description, Discover and Integration)

필요한 서비스를 찾을 수 있는 웹 서비스 레지스트리 (서비스 등록, 검색)
웹 서비스와 비즈니스를 발행(Publish) / 검색(Find)하기 위한 기술적인 스펙
UDDI 데이터 범주
- White 페이지 : 회사에 대한 일반적인 정보 (비즈니스 이름, 세부내용, 주소)
- Yellow 페이지 : 회사나 서비스가 제공하는 분류된 데이터 (표준 분류법을 토대로 산업, 제품, 지리적 코드 별로 나뉜 데이터)
- Green 페이지 : 웹 서비스에 대한 기술적인 정보 (외부 스펙을 가리키거나 웹 서비스 호출에 대한 주소)

SOAP(Simple Object Access Protocol)

SOAP은 SOA(서비스 지향 아키텍처)와 SOA와 관련된 웹 서비스 규격의 필수적인 부분이다.
발신자와 수신자 사이의 메시지 경로를 만들어 주기 때문에 안전을 준수하는 접속, 접속 제어, 신뢰성 있는 전달과 오류 복구, 동적 서비스 발견 등을 지원한다.
SOAP의 메시지는 XML에서 high-level로 정의되지만, 대부분의 SOAP 어플리케이션은 XML로 작성된 WSDL을 사용한다.
SOAP의 데이터 구조는 XML을 기반으로 하고 있는데, 이는 웹 페이지를 정의하는데 사용되는 HTML과 여러 면에서 유사하다.
XML은 대체로 사람이 읽을 수 있어 SOAP 메시지를 쉽게 이해할 수 있게 하지만, 이진 데이터를 수용하는 CORBA 및 RPC 프로토콜에 비해 상대적으로 메시지를 크게 만든다.
SOAP의 가장 큰 단점은 헤비급 아키텍처를 위한 헤비급 프로토콜이라는 것이다. 메시지가 일련의 노드를 통과하여 각각 처리되어야 한다는 개념은 소프트웨어에 대한 프로토콜과 서비스 버스 아키텍처 모델을 혼합한 것으로 보이며, 그 두 가지 모두 오늘날 일반적으로 사용되는 마이크로 서비스 기반 개발에 최적으로 간주되지 않는다.

REST(Representational State Transfer)

REST는 웹 서비스 개발을 위한 아키텍처 스타일이다.
REST는 새로운 표준, 프레임워크 및 기술을 만드는 것이 아니라 인터넷 HTTP의 기존 시스템과 특징을 기반으로 구축되며 단순하다는 것 때문에 인기가 매우 높다.
Client-Server의 관점에서 REST의 주된 장점은 HTTP 사용에 익숙한 사람들에게 익숙한 구조를 사용하여 REST 기반 상호작용이 일어난다는 것이다. (REST 기반 상호작용이 모두 표준 HTTP 상태 코드를 사용하여 상태를 나타냄)
또한 암호화나 데이터 무결성 등의 세부 사항은 새로운 프레임워크나 기술을 사용하는 것이 아닌 SSL 암호화 및 TLS에 의존함으로써 해결한다. 그러므로 REST 아키텍처는 대부분의 개발자들이 이미 친숙한 개념으로 여길 수 있다.
REST는 언어에 독립적이다. Java, Kotlin, .NET, AngularJS, JavaScript 등 어떤 언어로도 작성할 수 있으며 프로그래밍 언어가 HTTP를 사용하여 웹 기반 요청을 할 수 있는 한, 그 언어를 사용하여 RESTful API나 웹 서비스를 호출하는 것이 가능하다.

REST를 사용하는 것의 또다른 이점은 이미 만연해 있다는 것이다. 서버 측에는 개발자가 RESTlet, Apache CXF 등 RESTful 웹 서비스를 만들 수 있도록 지원하는 다양한 REST 기반 프레임워크가 있다. 클라이언트 측에는 Jquery, Node.js, Angular, EmberJS와 같은 자바스크립트 프레임워크로 RESTful 웹 서비스를 호출하고, XML, JSON 기반 데이터를 사용하는 표준 라이브러리를 API에 내장하고 있다.

그러나 HTTP 구성을 사용하는 REST의 특성상 HTTP의 제한사항이 그대로 REST의 제한사항으로 적용한다는 단점이 있다. 예를 들어 HTTP는 서버에서 클라이언트로 Push 알람을 보내는 매커니즘이 없기 때문에, 서버에 대한 클라이언트측 폴링이나 다른 유형의 웹 후크(Webhook)를 사용하지 않고 서버가 클라이언트를 업데이트하는 유형의 서비스를 구현하기 어렵다.
또한 REST의 표준이 아직 확실하게 정해지지 않았기 때문에 개발자들이 RESTful한 소프트웨어를 개발하는 것에 오해를 불러일으키기 쉽다.

SOAP VS REST

	SOAP	REST
배경 및 현황	기업을 위한 비즈니스 응용에서부터 출발 IBM, BEA, Oracle 등을 선두로 하는 웹 서버 벤더에서 주창 SOA의 서비스는 대부분 비즈니스 컴포넌트로서의 의미를 가짐	WEB 2.0은 서비스 어플리케이션에서부터 시작 구글, 아마존, 야후와 같은 인터넷 서비스 기업에 의해서 주창 맵이나 뉴스, 가젯 등과 같이 UI 성격을 갖는 서비스가 대다수
특징	Machine-Readable Web Stateful : 오퍼레이션 중 서비스 상태가 일관되게 유지, 관리되어야 함 엄격한 문법 검사, 서비스 계약에 충실 웹 서버 등 웹 서비스 개발 환경이 지원되어야 함	Human-Readable Web Stateless : 오퍼레이션 중 서비스/리소스의 상태를 관리하지 않음(HTTP의 기본 메커니즘), 필요한 경우 직접 관리 요망 기본 XML만으로도 서비스 개발 가능 별도의 개발 환경 지원이 필요 없음
전달 매커니즘	Remote Procedure Call(원격 프로시저 호출)	Publish/Syndicate Pattern
전달 프로토콜	SOAP/HTTP, SMTP	HTTP
서비스 명세	WSDL	WADL, XML, JSON, hREST(시맨틱 REST) 등
서비스 레지스트리	UDDI	없음
필요 스택	W3C의 WS-*스택(WS-addressing, WS-security 등)	없음
주요 적용 분야	트랜잭션 프로세싱	데이터와 UI 프로세싱
문제점	어려운 사용법, 무거운 프로토콜	표준의 부재, 관리의 어려움

JAX-WS

OXM(Object-XML Mapping)

위 그림과 같이 SOAP은 보내고자 하는 메시지를 포장하는 포장지와 같다.

클라이언트에서 요청을 보낼 때 정보를 XML로 변환시키고 SOAP으로 포장하여 보내면 서버에서는 SOAP을 벗긴 후 내부 XML을 필요한 객체로 변환하는데, 이렇게 객체와 XML을 변환해 주는 것을 OXM(Object-XML Mapping)이라고 부른다.

JAX-WS(Java API for XML – Web Service)

출저 : https://www.slideshare.net/indicthreads/java-web-services-using-jaxws

OXM을 사용하고 SOAP 바인딩을 실현시켜주는 것이 웹 서비스 프레임워크이다.
웹 서비스 프레임워크는 JAVA기반의 JAX-WS와 .NET기반의 WCF가 있다.
JAX-WS의 구현체로는 대표적으로 CXF, AXIS2가 있다.
웹 서비스 프레임워크를 통해 웹 서비스의 WSDL 생성과 SOAP 메시지의 바인딩 OXM을 적용하여 웹 서비스의 전반적인 과정을 처리할 수 있다.