컴포넌트 기술들의 통신 메커니즘
COM : RPC 기반의 DCOM
JAVA : RMI
CORBA : IIOP
문제점 : 각 컴포넌트간의 상호운영성이 떨어집니다.
SOAP의 등장
SOAP(Simple Object Access)은 XML과 HTTP를 사용하여 플랫폼에 독집적으로 서버스 혹은 분산 객체를 액세스하는 방법을 정의합니다.
SOAP는 XML 메시지를 처리하는 플랫폼이나 프로그래밍 언어를 제한하지 않으므로 HTTP 프로토콜을 이해하고
SOAP의 XML메시지를 이해하기만 한다면 어떤 프로그래밍 언어로 구현을 하든지 상관이 없습니다.
Web Service 개념
인터넷 상에서 SOAP 메시지와 HTTP를 통해 운영체제나 구현기술에 구애 받지 않고 다양한 크라이언트에게 어떤 기능을 제공하는 것을 웹서비스라 합니다.
"전통적으로 X.25와 같이 보안성이 높은 네크워크를 사용하거나 암호화된 TCP 메시지를 통해 슨인 요청을 받고 그에 대한 처리결과를 반환해 왔다. 메인 프레임 기반으로 구성된 금융권의 계정계 시스템에서 이러한 방식은 소위 '전문' 방식이라 하며 아직도 많이 사용하는 메시지 처리 기법이다. 전문방식의 문제점은 스크립트 언어 기반의 클라이언트가 X.25 혹은 TCP와 같은 하위 프로토콜 수준의 프로그래밍이 쉽지 않다는 것돠 클라이언트로 하여금 카드회사의 프로토콜을 따르도록 강요하는 정도이다. 따라서 전문 방식의 통신은 카드 가맹점들이 사용하는 POS(Point of Sale 시스템을 제약할 뿐만 아니라 카드 회사의 비즈니스 영역을 제한하는 효과를 가져올 수 있다."
Web Service 적용상의 문제점과 대응책들
문제점
* SOAP 스펙을 준수하는 웹서비스 구현 사이의 미미한 차이점에서 오는 호환성 문제
* SOAP 메시지에 대한 다양한 기능 강화
* SOAP 메시지에 대한 인증. 암호화와 같은 보안에 대한 표준 스펙부재
* SOAP과 HTTP를 통해 느슨하게 연결된 (loosely coupled) 웹서비스 사이의 트랜잭션 요구
* SOAP 메시지의 전달에 대한 신뢰성 부재
* WSDL(Web Service Descripttion Language)을 통해 전달되는 웹 서비스의 메타 데이터에 대한 상세 내역 결여
대응책
* Compatibility
WS-I(WS-Interoperability) Base Profile : SOAP 표준과 WSDL 을 적용하고 구현하는데 호환성을 지키기 위한
가이드 라인 및 테스트 도구
* Messaging
WS-Addressing : SOAP 메시지가 HTTP 뿐만 아니라 TCP나 SMTP 등의 다른 트랜스포트를 통해서도 전송이 될 수 있도록 메시지를 수신하는 서비스에 대한 정보를 SOAP 헤더에 명시함으로써 메시지가 인터넷 상에 다양한
매개체를 통해 라우팅 될 수 있도록 하는 것을 목적으로 합니다.
MTOM(Message Transmission Optimization Mechanism): SOAP 메시지를 통해 커다란 바이너리 데이터를
전송하기 위해 고안된 표준 스펙입니다. SOAP은 XML을 사용하고 XML은 텍스트를 사용하기 때문에 바이너리 데이터를 전송하기 위해서는 Base64 혹은 Uuencoding 등의 바이너리 인코딩을 사용해야합니다. 이러한 변환 작업은
SOAP 메시지의 크기를 33% 정도 더 크게 만들며, 메시지 크기가 커짐에 따라 네트워크 대역폭 역시 손해를 감수햐야만 합니다. MTOM은 이렇게 바이너리 데이터를 전송할 때 효율적으로 SOAP 메시지를 구성하도록
MIME(Multi-part Message Encoding)을 사용하여 SOAP 메시지를 재구성하는 방법을 정의하는 표준입니다.
MTOM을 사용하여 바이너리 데이터가 직접 전송되게됩니다.
* Security of Web Service
SOAP는 보안을 위하여 일반적으로 HTTP에 적용할 수 있는 인증(authentication) 기술과
SSL(Secure Socket Layer) 기반의 보안 통신을 사용하면 된다고 생각했기 때문에 원격 호출 개념이 강한 웹 서비스에는 이러한 기술이 한계를 나타낼 수 밖에 없었습니다.
첫째. 웹 서비스가 HTTP를 트랜스포트로 사용할 때 많이 사용되는 SSL 과 같은 기술은 트랜스포트 수준의 보안으로써
클라이언트와 서비스가 직접 연결되는 경우에만 유효한 보안 채널이라는 접입니다. 인터넷 상에서 클라이언트와
사이에는 프록시 서버, 캐시 서버, 방화벽등 다양한 중간 매개체가 존재할 수 있기 때문에, SSL 과 같이 종단간
(Point-to-Point) 보안은 취약할 수 밖에 없습니다.
둘째. SOAP 메시지가 HTTP 가 아닌 TCP 나 SMTP 같은 다른 트랜스포트를 통해 전송될때는 SSL 과 같이 HTTP에
의존적인 보안을 사용할 수 없습니다.
WS-Security, WS-Trust, WS-SecurityConversion : WS-Security가 핵심이되며 이 스펙은 SOAP 메시지 자체를
메시지 수준에서 인증하거나 암호화하는데 필요한 표준을 정의하고 있습니다.
* Reliability
WS-ReliableMessagine : 신뢰도가 낮은 네트워크나 인프라 상황에서 신뢰도 놓은 SOAP 메시지의 전달을 위해
정의된 표준입니다.
* Transaction
WS-AtomicTransaction, WS-Coordination : SOAP 메시지를 통해 2-phase commit 프로토콜을 구현하며 플랫폼과
트랜잭션 관리자와 무관하게 분산 트랜잭션을 처리할 수 있도록 하는 웹 서비스 표준입니다.
* Rich Metadata
SOAP와 같이 등장한 스펙이 웹서비스의 메타 데이터에 대한 표준인 WSDL(Web Service Description Language)
입니다. WSDL은 웹서비스가 어떤 기능을 가지고 있으며 매개변수는 어떠한지에 대한 정보뿐만아니라 웹서비스를
호출하는데 필요한 트랜스포트 정보역시 제공합니다. 하지만 서비스가 어떤 보안을 사용하는지, 세션을 사용하는지,
트랜잭션을 지우너하는지 등의 정보는 제공하지 않습니다.
WS-Policy, WS-MetadataExchange : 웹서비스가 어떤 방식으로 메시지를 주고 받는지에 대한 풍부한 메타데이터를
제공합니다.
COM : RPC 기반의 DCOM
JAVA : RMI
CORBA : IIOP
문제점 : 각 컴포넌트간의 상호운영성이 떨어집니다.
SOAP의 등장
SOAP(Simple Object Access)은 XML과 HTTP를 사용하여 플랫폼에 독집적으로 서버스 혹은 분산 객체를 액세스하는 방법을 정의합니다.
SOAP는 XML 메시지를 처리하는 플랫폼이나 프로그래밍 언어를 제한하지 않으므로 HTTP 프로토콜을 이해하고
SOAP의 XML메시지를 이해하기만 한다면 어떤 프로그래밍 언어로 구현을 하든지 상관이 없습니다.
Web Service 개념
인터넷 상에서 SOAP 메시지와 HTTP를 통해 운영체제나 구현기술에 구애 받지 않고 다양한 크라이언트에게 어떤 기능을 제공하는 것을 웹서비스라 합니다.
"전통적으로 X.25와 같이 보안성이 높은 네크워크를 사용하거나 암호화된 TCP 메시지를 통해 슨인 요청을 받고 그에 대한 처리결과를 반환해 왔다. 메인 프레임 기반으로 구성된 금융권의 계정계 시스템에서 이러한 방식은 소위 '전문' 방식이라 하며 아직도 많이 사용하는 메시지 처리 기법이다. 전문방식의 문제점은 스크립트 언어 기반의 클라이언트가 X.25 혹은 TCP와 같은 하위 프로토콜 수준의 프로그래밍이 쉽지 않다는 것돠 클라이언트로 하여금 카드회사의 프로토콜을 따르도록 강요하는 정도이다. 따라서 전문 방식의 통신은 카드 가맹점들이 사용하는 POS(Point of Sale 시스템을 제약할 뿐만 아니라 카드 회사의 비즈니스 영역을 제한하는 효과를 가져올 수 있다."
Web Service 적용상의 문제점과 대응책들
문제점
* SOAP 스펙을 준수하는 웹서비스 구현 사이의 미미한 차이점에서 오는 호환성 문제
* SOAP 메시지에 대한 다양한 기능 강화
* SOAP 메시지에 대한 인증. 암호화와 같은 보안에 대한 표준 스펙부재
* SOAP과 HTTP를 통해 느슨하게 연결된 (loosely coupled) 웹서비스 사이의 트랜잭션 요구
* SOAP 메시지의 전달에 대한 신뢰성 부재
* WSDL(Web Service Descripttion Language)을 통해 전달되는 웹 서비스의 메타 데이터에 대한 상세 내역 결여
대응책
* Compatibility
WS-I(WS-Interoperability) Base Profile : SOAP 표준과 WSDL 을 적용하고 구현하는데 호환성을 지키기 위한
가이드 라인 및 테스트 도구
* Messaging
WS-Addressing : SOAP 메시지가 HTTP 뿐만 아니라 TCP나 SMTP 등의 다른 트랜스포트를 통해서도 전송이 될 수 있도록 메시지를 수신하는 서비스에 대한 정보를 SOAP 헤더에 명시함으로써 메시지가 인터넷 상에 다양한
매개체를 통해 라우팅 될 수 있도록 하는 것을 목적으로 합니다.
MTOM(Message Transmission Optimization Mechanism): SOAP 메시지를 통해 커다란 바이너리 데이터를
전송하기 위해 고안된 표준 스펙입니다. SOAP은 XML을 사용하고 XML은 텍스트를 사용하기 때문에 바이너리 데이터를 전송하기 위해서는 Base64 혹은 Uuencoding 등의 바이너리 인코딩을 사용해야합니다. 이러한 변환 작업은
SOAP 메시지의 크기를 33% 정도 더 크게 만들며, 메시지 크기가 커짐에 따라 네트워크 대역폭 역시 손해를 감수햐야만 합니다. MTOM은 이렇게 바이너리 데이터를 전송할 때 효율적으로 SOAP 메시지를 구성하도록
MIME(Multi-part Message Encoding)을 사용하여 SOAP 메시지를 재구성하는 방법을 정의하는 표준입니다.
MTOM을 사용하여 바이너리 데이터가 직접 전송되게됩니다.
* Security of Web Service
SOAP는 보안을 위하여 일반적으로 HTTP에 적용할 수 있는 인증(authentication) 기술과
SSL(Secure Socket Layer) 기반의 보안 통신을 사용하면 된다고 생각했기 때문에 원격 호출 개념이 강한 웹 서비스에는 이러한 기술이 한계를 나타낼 수 밖에 없었습니다.
첫째. 웹 서비스가 HTTP를 트랜스포트로 사용할 때 많이 사용되는 SSL 과 같은 기술은 트랜스포트 수준의 보안으로써
클라이언트와 서비스가 직접 연결되는 경우에만 유효한 보안 채널이라는 접입니다. 인터넷 상에서 클라이언트와
사이에는 프록시 서버, 캐시 서버, 방화벽등 다양한 중간 매개체가 존재할 수 있기 때문에, SSL 과 같이 종단간
(Point-to-Point) 보안은 취약할 수 밖에 없습니다.
둘째. SOAP 메시지가 HTTP 가 아닌 TCP 나 SMTP 같은 다른 트랜스포트를 통해 전송될때는 SSL 과 같이 HTTP에
의존적인 보안을 사용할 수 없습니다.
WS-Security, WS-Trust, WS-SecurityConversion : WS-Security가 핵심이되며 이 스펙은 SOAP 메시지 자체를
메시지 수준에서 인증하거나 암호화하는데 필요한 표준을 정의하고 있습니다.
* Reliability
WS-ReliableMessagine : 신뢰도가 낮은 네트워크나 인프라 상황에서 신뢰도 놓은 SOAP 메시지의 전달을 위해
정의된 표준입니다.
* Transaction
WS-AtomicTransaction, WS-Coordination : SOAP 메시지를 통해 2-phase commit 프로토콜을 구현하며 플랫폼과
트랜잭션 관리자와 무관하게 분산 트랜잭션을 처리할 수 있도록 하는 웹 서비스 표준입니다.
* Rich Metadata
SOAP와 같이 등장한 스펙이 웹서비스의 메타 데이터에 대한 표준인 WSDL(Web Service Description Language)
입니다. WSDL은 웹서비스가 어떤 기능을 가지고 있으며 매개변수는 어떠한지에 대한 정보뿐만아니라 웹서비스를
호출하는데 필요한 트랜스포트 정보역시 제공합니다. 하지만 서비스가 어떤 보안을 사용하는지, 세션을 사용하는지,
트랜잭션을 지우너하는지 등의 정보는 제공하지 않습니다.
WS-Policy, WS-MetadataExchange : 웹서비스가 어떤 방식으로 메시지를 주고 받는지에 대한 풍부한 메타데이터를
제공합니다.
