달력

3

« 2024/3 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

'I.lib()/I.lib(Soap)'에 해당되는 글 1

  1. 2010.04.01 SOAP( Simple Object Access Protocol) 이란?
.. .. ..


SOAP 란 ?


 SOAP은 웹상의 객체들을 액세스하기 위한 마이크로소프트의 프로토콜이다.

이 프로토콜은 HTTP를 사용하여 인터넷에 텍스트 명령어를 보내기 위해 XML 구문을 쓴다. 
 SOAP은 COM, DCOM, 인터넷 익스플로러, 마이크로소프트의 자바 이행 등 내에서 지원된다.


왜 SOAP 인가?


 인터넷을 통해 기업과 기업, 기업과 고객의 장벽이 없어진 상황에서 서로 다른 인프라를 바탕으로 하는 컴포넌트를 연결하는 방법이 절실한 현실에서 JAVA, CORBA, COM 등의 주요 컴포넌트 기술은 독자적인 인프라와 기술을 사용하므로 상호 운용성이 크게 떨어지게 마련이다.

 즉, 현재의 주 컴포넌트 기술로 일컬어지는 JAVA, CORBA, COM 등은 목적은 비슷하지만 목적을 구현하는 방법은 매우 다르므로 호환성을 기대하기 어렵다.

 예를 들어보자.

 상호 운용에 필요한 하나의 요소는 컴포넌트를 액세스하기 위한 타입(클래스, 인터페이스)이다.

CORBA와 COM은 IDL에 기반한다는 공통점이 있지만, IDL 문법에 차이가 많으며 IDL이 생성한 컴포넌트의 타입 정보를 제공하는 방법 역시 공통점을 찾기 어렵다. 반면 JAVA는 IDL을 사용하지 않고 언어 자체가 갖는 타입 정보를 이용한다. 또한, 상호 운용에서 중요한 것은 통신 메커니즘이지만 CORBA는 IIOP(Internet Inter-ORB Protocol)를, 자바는 RMI(Remote Method Invocation)를, COM은 DEC RPC(Remote Procedure Call)을 사용한다. 그리고 이들 통신 메커니즘 역시 공통점이 없다.

이들 컴포넌트 기술들은 고유의 장단점을 갖고 있으며, 어는 것이 다른 것에 대해 우월하다거나 뒤진다고 말할 수 없다. 또한 수년에 걸쳐 많은 자원과 시간을 투자한 고유의 추종자들을 거느리고 있으므로 JAVA, CORBA, COM 중 어느 하나가 사라질 것으로 예견하는 이는 아무도 없을 것이다. 더욱 문제되는 것은 이들 중 어느 한 기술이 인터넷을 지배하고 있거나, 지배할 가능성 역시 거의 없다는 것이다. 이것이 현재의 컴포넌트 기술들이 갖는 상호 운용성의 큰 문제가 되는 것이다.



결국 해결책은 SOAP ?


SOAP은 XML과 HTTP를 사용해 플랫폼에 독립적으로 서비스 혹은 분산 객체를 액세스하는 방법을 정의한다.


HTTP는 인터넷 표준이며 누구나 어떠한 플랫폼에서도 사용할 수 있는 프로토콜이다.

그 어떤 개인이나 기업도 HTTP를 인정한다. XML은 HTTP보다 상대적으로 늦게 나온 기술이지만 최근 들어 널리 사용되며 업계 표준으로 자리잡고 있다. 또한 HTTP와 XML은 공통적으로 텍스트에 기반하고 있으므로 이들을 처리하는 소요 비용(프로세싱 시간, 메모리 등)은 상대적으로 매우 적다. 텍스트 문자열을 제어하고 TCP/IP에 접근할 수 잇는 어떠한 응용 프로그램도 HTTP를 통해 XML데이터를 전송하거나 수신할 수 있다는 것이다. 이러한 손쉬운 사용성은 이들 두 기술이 빠르게 IT 환경에 적응하는 발판이 됐다.

 SOAP은 이런 XML과 HTTP를 사용함으로써 이들이 갖는 장점을 모두 포함하면서 컴포넌트의 상호 운용성을 높일 수 있는 것이다.


SOAP의 장점


  • 독립성

     
 SOAP은 XML과 HTTP를 이용해 어떤 인터페이스의 메쏘드를 호출할 것이며, 이 메쏘드에 대한 매개변수를 알리는 역할만 담당한다. 따라서 실제 컴포넌트를 생성하거나 컴포넌트에 대한 직접적인 호출에 관여하지 않는다.

 즉, SOAP은 컴포넌트를 활성화하는 방법이나 호출 방법에 대해 전혀 관여하지 않으며, 이에 대한 상세한 것은 HTTP Request를 수신하는 수신자에게 위임하고 있다. 따라서 객체 지향 기술이나 컴포넌트 기술을 사용하지 않는 애플리케이션일지라도 SOAP을 통해 객체 서비스를 제공하거나 제공받을 수 있다.

 결론적으로 말해, SOAP은 JAVA, CORBA, COM 등의 분산 객체 기술에 구애받지 않는 프로토콜이며 심지어 이들 분산 객체 기술을 전혀 사용하지 않는 애플리케이션도 SOAP을 통해 원격 프로시져 호출이나 데이터 전송을 수행할 수 있다. SOAP이 원격 객체의 구현에 대해 언급하고 있지 않으므로, 원격 객체는 어떤 프로그래밍 언어로도 구현할 수 있다.
 
  • 인터넷 적용성

 SOAP은 transport로서 HTTP를 사용한다.
 HTTP를 사용함으로써 얻을 수 있는 장점은 인터넷에서 널리 사용할 수 있다는 점이다.
 실제로 SOAP은 인터넷에서 원격 객체를 액세스하기 위해 고안된 프로토콜이다.
 그렇다면 기존 객체 지향 기술은 인터넷에서 문제가 있었던 것인가 살펴보도록 하자.

 JAVA, CORBA, COM 등이 사용하는 transport는 고유의 transport로서 RMI, IIOP, DCOM을 사용하지만, 이들 프로토콜은 TCP/IP 포트를 동적 할당하는 메커니즘을 사용하고 있다. 이것 때문에 이들 프로토콜이 방화벽을 통과하는데 문제점이 드러난다.

 예를 들어 DCOM을 인터넷에서 사용하려면 방화벽에 일정 영역의 TCP/IP 포트를 열어 놓아야 하는데, 이것은 방화벽을 사용하지 않는 것과 다름없게 만들어 버린다.
 반면 대부분의 기업 네트워크는 자사의 웹 사이트를 위해 HTTP가 사용하는 포트를 열어 놓고 있다.

 SOAP은 HTTP를 사용하므로 아무런 문제 없이 방화벽을 통과할 수 있다. 또한 대부분의 방화벽 제품은 HTTP 헤더의 내용을 읽어 필터링을 수행할 수 있으므로 특정 인터페이스의 특정 메쏘드를 호출하는 SOAP 메시지만을 통과시키도록 설정할 수도 있다.

 SOAP은 HTTP를 통해 인터넷에 분산된 객체들에 접근할 수 있으며 방화벽이나 HTTPS 등의 인터넷 보안 기술을 그대로 적용받을 수 있는 것이다.
 
  •  표준

 SOAP 탄생의 주역은 마이크로소프트와 IBM이다.

 초기 마이크로소프트 제품의 대부분이 자사의 고유한 기술을 사용했던 것과 반대로 최근 마이크로소프트의 제품들은 업계 표준이나 인터넷 표준을 준수하기 시작했다. SOAP 역시 인터넷 표준으로서 XML과 HTTP를 채택하고 있으며 SOAP 자체 역시 W3C에 표준으로서 제출된 상태이다. 2001년 초 현재 W3C에 제출됐고 검토되고 있는 SOAP의 최신 버전은 스펙 1.1이다.


 SOAP이 W3C로부터 공식 표준으로 인정받을 것은 확실시 되고 있으며 플랫폼과 운영체제, 애플리케이션 그리고 프로그래밍 언어를 뛰어넘는 분산 객체 프로토콜로 자리잡을 가능성 역시 매우 높다. 


출처 [http://www.saga21.net/417]
글쓴이 [사가]

.
:
Posted by .07274.