'UP!/Web Service'에 해당되는 글 24건

  1. 2008.08.21 분산객체시스템 종류
  2. 2008.08.21 웹 서비스와 관련된 10가지 질문
  3. 2008.08.21 XML,SOAP,UDDI,WSDL
  4. 2008.08.21 COBRA

분산객체시스템 종류

UP!/Web Service 2008. 8. 21. 14:08
출처 : http://ebiz.u-aizu.ac.jp/~paikic/ecswtech/ec_tech/oot/corba_iiop/corba_iiop_9.html
---------------------------
⑷ 분산 객체 종류
 ㈎ DCE(Distributed Computing Environment)
 OSF(Open System Foundation)에서 개발 되었고, 절차지향 기술 모델을 기반으로 하는 분산 환경의 표준이다. DCE는 RPC호출을 통한 풍부한 의미를 지원한다. DCE의 구성요소 다음과 같다.

        RPC
        디렉토리 서비스
        분산 시간 서비스
        멀티 쓰레드
        보안
        분산 파일 서비스

 ㈏ DCOM(Distributed Object Model)
 DCOM 은 원격 객체 액세스를 지원하는 마이크로소프트의 기술이다. 윈도우 환경에서 컴포넌트간의 연동을 위한 분산 객체 시스템이다. 네트웍 에서 원격 객체가 제공하는 서비스들을 요청하기 위해 클라이언트 응용프로그램을 사용하도록 지원한다. 객체들은 다수의 언어에서 작성 될 수 있으며 표준을 따르면 다른 객체에 의해 호출된다. 언어 독립성을 제공한다.

 ㈐ CORBA
 CORBA 는 비영리 단체인 OMG(Object Management Group) 에 의해 90년대 초반에 만들어졌다. CORBA는 객체 사이 의 통신을 위한 표준이다. CORBA의 핵심은 ORB (Object Request Broker)이다. ORB는 객체의 위치가 로컬 이나 네트워크 상에 관계없이 서비스를 요청하고 응답을 받을 수 있도록 지원한다. CORBA 지원 응용프로그램에 있는 클라이언트 는 객체의 위치는 물론 어떤 프로그래밍 언어로 객체가 작성되는지, 어떤 플랫폼에 객체가 상주하는지에 대한 정보를 가지고 있을 필요 가 없다. 따라서 CORBA는 객체 기반의 분산 시스템을 지원한다.

 ㈑ RMI(Remote Method Invocation)
 RMI 는 자바 기반 분산 객체 기술이다. Java RMI은 분산된 객체를 마치 로컬에 있는 객체를 다루듯이 사용할수 있으며 기존의 소 켓 프로그래밍과 같은 복잡한 설계 절차와 애러를 발생시키는 요인을 극소화 시켰다. 모든 네트웍 프로그래밍의 자세한 부분, 즉 소 켓 API 를 사용해서 구현되는 부분은 RMI package, client stub 그리고 server stub에 의해 숨겨진 다. RPC(Remote Procedure Call)와는 달리 RMI 는 Java VM 환경에서 실행된다. 따라서, 자바 이외 의 다른 언어는 지원하지 않는다. RMI의 특징은 객체지향 다형성을 제공한다.
 JavaRMI는 다음과 같은 특징을 갖는다.

        원격 호출의 제공
        서버에서 애플랫으로의 콜백 제공
        분산모델을 자바 환경으로의 통합
        분산 객체와 비분산 객체의 명확한 구분

 ㈒ 기타
 ① JOE
 썬에 의해 개발된 자바로 구현된 ORB이다. CORBA표준을 따르며, 썬 시스템에서 사용 가능하다

 ② NCA(Network Computing Architecture)
 오 라클의 네크웍 컴퓨팅 아키텍쳐는 클라이언트/서버 네트워크, 웹 그리고 인트라넷 상의 분산 객체 응용 프로그램을 개발하는데 적합 한 개방형 표준 프레임워크이다. CORBA의 IIOP를 기반으로 CORBA/COM 연결을 통해 ActiveX/COM을 통합하였 다.

 ③ Netscape ONE
 웹과 인트라넷 상에서의 분산객체 애플리케이션을 개발하기 위한 개방형 표준 프레임워크이다. CORBA와 IIOP는 그 핵심 요소를 이룬다.

 ④ OpenDOC
 애플 컴퓨터, IBM, 로터스 등에 의해 제안된 데스크탑 환경 내의 객체 요소이다.

 ⑤ SOM/DSOM
 SOM(System Object Model)과 DSOM(Distributed)은 IBM에 한정된 객체 프레임워크이다.

'UP! > Web Service' 카테고리의 다른 글

그리드 서비스를 위한 Repository 시스템 개발  (0) 2008.08.21
분산객체와 웹 서비스의 차이점  (0) 2008.08.21
웹 서비스와 관련된 10가지 질문  (0) 2008.08.21
XML,SOAP,UDDI,WSDL  (0) 2008.08.21
COBRA  (0) 2008.08.21
Posted by 으랏차
,

웹 서비스와 관련된 10가지 질문

UP!/Web Service 2008. 8. 21. 14:08
출처 : http://itroom.net/contentChannel/article.php?aca_idx=1&scol_serial=200210261348150000
--------------------

웹 서비스와 관련된 질문 중에서 가장 많이 언급되는 10가지 질문
본 기사는 웹 서비스와 관련된 질문 중에서 가장 많이 언급되는 10가지 질문에 대한 해답이다. 따라서 독자들은 웹 서비스 개요뿐만 아니라 좀더 세부적인 내용도 충분히 참고할 수 있을 것이다.
 
웹 서 비스는 분산시스템을 제작이 중요한 진화적 과정을 거치고 있다는 것을 의미한다. 그러나 사람들은 웹 서비스가 정확히 무엇을 말하 는 것이며 웹 서비스 프로토콜 스택(stack)이 무엇인지, W3C가 지원하고 있는 웹 서비스 표준이 존재하는지에 대해서는 잘 알 고 있지 못하는 것 같다.

본 기사는 웹 서비스와 관련된 질문 중에서 가장 많이 언급되는 10가지 질문에 대한 해답이다. 따라서 독자들은 웹 서비스 개요뿐만 아니라 좀더 세부적인 내용도 충분히 참고할 수 있을 것이다.

1. 웹 서비스란 무엇인가?

웹 서비스 정의에 대해 많은 논란이 있었다. 그렇지만 사람들의 공통적인 의견을 추린다면 웹 서비스란 인터넷을 통해 표준화된 XML 메시지 시스템을 사용하는 소프트웨어의 작은 조각이라고 말할 수 있다.

XML 은 웹 서비스의 모든 통신을 인코딩 하는데 사용된다. 예를 들어 클라이언트는 XML 메시지를 통해 웹 서비스를 시작하며 요청에 대 응하는 XML 응답을 기다린다. 결국 XML을 사용하여 모든 통신이 이루어지기 때문에 웹 서비스는 특정한 OS나 언어에 구애받 지 않는다. 이는 곧 자바와 펄(Perl)이 서로 통신할 수 있고 윈도우 애플리케이션과 유닉스 애플리케이션도 통신할 수 있다는 뜻 이다.

이러한 기본적인 정의 이외에도 웹 서비스는 아래와 같은 두 가지 추가적인 속성을 가지고 있다.
첫 째, 웹 서비스는 XML로 정의된 공개 인터페이스를 가진다. 인터페이스는 클라이언트가 사용할 수 있는 메소드를 정의하고 메소드 에 대한 용법을 설명한다. 현재 인터페이스 정의는 WSDL(Web Service Description Language)를 통해 서 이루어진다. (FAQ 7번 참고)
둘째, 웹 서비스를 작성한다면 그것을 발행(Publish)하기 위한 단순한 메커니즘 이 필요하다. 마찬가지로 인터페이스를 공개하거나 서비스를 사용하고자 하는 곳에 제공하기 위한 메커니즘도 필요하다. 현재 유력 한 웹 서비스 디렉토리 서비스 는 UDDI(Universal Description, Discovery, and Integration)을 통해 이루어지고 있 다. (FAQ 8번 참고)
웹 서비스는 현재 뉴스 배급회사와 같은 거대한 시스템을 비롯하여 날씨, 주식 정보, 배송추적 과 같은 세부적인 시스템에까지 운영되고 있다. 현재 사용가능한 웹 서비스의 범위를 보고싶다면 웹 서비스 디렉토리인 XMethods 를 방문해보자.

2. 웹 서비스에서 새로워진 점은? 

사람들은 지금도 RPC(Remote Procedure Calls)을 사용하고 있다. 그리고 과거에도 HTTP를 통해 RPC를 전달하는 방법을 모르고 있었던 것은 아니다.

그렇다면 과연 무엇으로 인해 웹 서비스가 과거 기술과는 달리 새로워졌다는 것인가? 정답은 XML이다.

XML은 웹 서비스의 핵심이며 RPC, 웹 서비스, 웹 서비스 디렉토리를 기술하는 공통 언어를 제공한다.

XML 이전에도 다른 애플리케이션 간에 데이터를 공유할 수 있었지만 XML은 이것을 좀더 쉽게 할 수 있게 해주었다. 같은 맥락으 로 웹 서비스 없이도 코드와 서비스를 공유할 수 있었지만 XML로 인해 같은 기능을 좀더 수월하게 수행할 수가 있게 되었다.

XML으로 모든 것을 표준화시킴으로써 서로 다른 애플리케이션은 좀더 편하게 상대방과 통신할 수 있고 이로 인해 소프트웨어에 대한 관심이 증가되고 있다.

3. 웹 서비스에 대한 글은 읽었지만 실제로 웹 서비스가 동작되는 것은 본적은 없다. 웹 서비스가 실행되는 것을 보여줄 수 있는가? 

웹 서 비스에 좀더 관심이 있다면 IBM Alphaworks 사이트에 있는 IBM 웹서비스 브라우저를 실행해 보아라. 이 브라우저 는 웹 서비스 데모를 제공하고 있다. 브라우저 화면 뒤에서는 SOAP, WSDL, UDDI 기술이 웹 서비스 검색과 실행을 위 한 단순한 plug-and-play 인터페이스를 제공하기 위해 작동되고 있다. 예를 들어 주식 시세 서비스, 교통 정보 서비 스, 날씨 정보 서비스를 발견했다면 각각의 서비스는 독립적으로 작동되기 때문에 건물 벽돌처럼 쌓을 수 있다. 그러므로 여러 개 로 된 서비스 결과를 마치 my.yahoo, my.excite처럼 하나의 페이지에 담을 수 있다.
--------------------------------------------------------------------------------

참고 기사: 아마존의 새로운 웹 서비스 사용하기

위에서 예로든 IBM Alphaworks 사이트 말고도 한빛미디어 네트워크 페이지에 등록된「아마존의 새로운 웹 서비스 사용하기」에서 웹 서비스에 대한 더 자세한 내용을 참고할 수 있습니다.
--------------------------------------------------------------------------------
4. 웹 서비스 프로토콜 스택(stack)은 무엇인가? 

웹 서비스 프로토콜 스택은 웹 서비스 정의, 발견, 실행을 위해 사용되는 프로토콜의 집합이다. 핵심 프로토콜 스택은 다음과 같이 4개의 층(layer)으로 이루어져 있다.
서비스 전송 계층: 애플리케이션 간 메시지 전송의 책임이 있다. 현재 HTTP, SMTP, FTP와 BEEP(Blocks Extensible Exchange Protocol) 같은 새로운 프로토콜을 포함한다.
XML 메시지 계층: 종단(end)에서 메시지가 해석되기 위해 공통된 XML 포맷으로 메시지를 인코딩 해야 하는 책임이 있다.
서비스 기술(description) 계층: 웹 서비스를 설명하기 위해 공개 인터페이스를 기술해야 하는 책임이 있다. 현재 WSDL이 사용된다.
서비스 발견(discovery) 계층: 공통 레지스트리로 서비스를 집중화시키거나, 발행(publish)/검색(find) 기능을 제공해야 하는 책임이 있다. 현재 UDDI가 사용된다.
웹 서 비스의 본질을 이루고 있는 XML-RPC, SOAP, WSDL, UDDI 이외에도 웹 서비스 프로토콜 스택 은 WSFL (Web Services Flow Language), SOAP- DSIG (SOAP Security Extensions: Digital Signature), USML (UDDI Search Markup Language) 과 같은 새로운 프로토콜을 포함하고 있다. 이러한 프로토콜을 자세히 알려면 오라일리 on XML.com에 있 는 Pavel Kulchenko의 기사 「Web Services Acronyms, Demystified」를 참고하기 바란다.

다행하게도 웹 서비스를 구현하기 위해서 이러한 전체 프로토콜 스택을 이해 해야 할 필요는 없다. HTTP에 대해서 알고 있다면 XML 메시지 층위에서 웹 서비스를 실행해 볼 수 있기 때문이다.

--------------------------------------------------------------------------------
참고 도서
Web Services Essentials
Ethan Cerami
--------------------------------------------------------------------------------

5. XML-RPC는 무엇인가?

XML-RPC는 RPC를 수행하기 위해 XML 메시지를 이용하는 프로토콜이다. 요청은 XML로 인코딩 되며 HTTP POST 메소드를 통해 전송된다. XML 응답은 HTTP 응답 메시지 안에 포함되어 있다.

좀더 보기 쉽게 표현한다면 "XML-RPC = HTTP + XML + RPC"라고 할 수 있다.

XML-RPC는 플랫폼 독립적이기 때문에 다양한 애플리케이션과 통신 할 수 있다. 예를 들어 자바 클라이언트는 XML-RPC를 통해 펄 서버와 대화 할 수 있다.

XML-RPC를 좀더 빨리 이해할 수 있게 날씨 정보 서비스에 대한 XML-RPC 요청(request) 예를 들어보겠다. (HTTP 헤더는 생략)

   weather.getWeather
 
     
10016
   
요청은 단순한  요소로 이루어져 있다. 이것은 메소드 이름(getWeather)과 메소드 파라미터(zip code)를 가지고 있다. 날씨 정보 서비스에 대한 XML-RPC 응답(response)은 다음과 같다.
     
         65

응답은 리턴 값(현재 온도)을 포함하고 있는 하나의  요소로 구성되어 있다. 이 경우에 리턴 값은 정수 값이다.

다양한 방법으로 XML-RPC는 SOAP보다 단순해 질 수 있기 때문에 웹 서비스를 가장 쉽게 시작할 수 있는 방법이다.

공 식적인 XML-RPC 스펙은 XML-RPC.com에서 참고할 수 있다. 위 사이트에서는 펄, 파이썬, 자바, 루비(Ruby)로 이 루어진 XML-RPC를 시험해 볼 수 있다. 완전한 실행 목록을 보려면 XML-RPC 홈페이지를 방문해 볼 것을 권장한다.

6. SOAP은 무엇인가? 

SOAP 은 컴퓨터 사이에서 정보를 교환하기 위한 XML 기반 프로토콜이다. 비록 SOAP이 다양한 메시지 시스템에서 사용될 수 있고, 다 양한 전송 프로토콜 위에서 전달될 수 있지만, 중요한 것은 HTTP를 통해 RPC가 가능하다는 것이다. XML-RPC처럼 SOAP 도 플랫폼 독립적이기 때문에 다양한 애플리케이션의 상호통신이 가능하다.

이해를 돕기 위해서 날씨 정보 서비스 요청에 대한 SOAP 메시지 예를 살펴보도록 하자. (HTTP 헤더는 생략)


   xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   
     
         xmlns:ns1="urn:examples:weatherservice"
         SOAP-ENV:encodingStyle=" http://www.w3.org/2001/09/soap-encoding
         10016
 


보 다시피 이 요청은 XML-RPC보다 다소 복잡하고 XML 네임스페이스와 XML 스키마를 사용하였다. XML-RPC와 비슷하게 요청 의 바디부분은 메소드 이름(getWeather)과 파라미터 목록(zipcode)을 가지고 있다.  
   
Programming Web Services with SOAP

날씨 정보 서비스 SOAP 응답은 다음과 같다.

   xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   
     
         xmlns:ns1="urn:examples:weatherservice"
         SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding">
         65



응답은 단순한 정수 리턴 값(현재 온도)을 나타내고 있다.

W3C 는 SOAP 표준 제정을 진행하고 있다. 최근 개발 초안은 SOAP 1.2 이며 두 부분으로 나뉘어 졌다. Part 1 은 SOAP 메시지 프레임워크와 엔빌로프(envelop) 스펙을 기술하고 Part 2는 SOAP 인코딩 법칙과 SOAP-RPC 규 약, HTTP 바인딩을 기술하고 있다.

7. WSDL은 무엇인가? 

WSDL(Web Services Description Language) 은 현재 웹 서비스 프로토콜 스택 층 위에서 서비스 기술(description)층을 나타내고 있다. 간단히 말해 WSDL란 웹 서 비스의 공개 인터페이스를 설명하기 위한 XML 문법이다. 공개 인터페이스는 다음과 같은 것들을 포함한다.
- 공개적으로 사용할 수 있는 기능들의 정보
- XML 메시지를 위한 데이터 타입 정보
- 사용된 전송 프로토콜에 관한 바인딩 정보
- 특정한 서비스 위치에 관한 주소 정보
WSDL은 XML 메시지 시스템에 꼭 필요한 것은 아니지만 SOAP 메시지를 기술하기 위한 빌드인 익스텐션(built-in extensions)을 포함하고 있다.

다음은 WSDL 예제이다. 이것은 이전 SOAP 예제에서 사용된 날씨 정보 서비스에 대한 공개 인터페이스를 기술하고 있다. 이 예제를 이해하려면 많은 것을 알아야 하지만 일단은 두 가지만 생각해보자.
첫째,  요소는 컴퓨터사이에서 전송되는 각각의 XML 메시지를 설명한다. 이 경우에는 getWeatherRequest, getWeatherResponse를 가지고 있다. 둘째,  요소는 SOAP과 특정 URL을 통해서 사용 가능한 서비스를 설명하고 있다.


   targetNamespace="http://www.ecerami.com/wsdl/WeatherService.wsdl"
   xmlns="http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:tns="http://www.ecerami.com/wsdl/WeatherService.wsdl"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   
     
         transport="http://schemas.xmlsoap.org/soap/http"/>
         
         
           
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:weatherservice"
               use="encoded"/>
         
           
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:weatherservice"
               use="encoded"/>
   
      WSDL File for Weather Service
     
         
            location="http://localhost:8080/soap/servlet/rpcrouter"/>
 
WSDL 을 사용해서 클라이언트는 웹 서비스의 위치를 지정할 수 있고 공개적으로 사용 가능한 기능들을 불러 낼 수도 있다. WSDL을 감지 하는 유틸리티를 통해 모든 프로세스는 자동적으로 수행되며 새로운 서비스는 부가적인 작업 없이 쉽게 애플리케이션에 통합 될 수 있 다. 예를 들자면 Mind Electic사의 GLUE 플랫폼을 참고하기 바란다.

WSDL은 W3C에 제출되었지만 현재까지 공식적인 위치를 가지고 있지 않다. 최근 초안인 W3C 페이지를 참고하기 바란다.

8. UDDI는 무엇인가? 

UDDI(Universal Description, Discovery, and Integration)는 웹 서비스 프로토콜 스택에서 서비스 발견 계층을 나타낸다.

UDDI는 원래 마이크로소프트(Microsoft), IBM, 아리바(Ariba)에 의해서 만들어 졌고, 웹 서비스와 비즈니스를 발행(publish)/검색(Find)하기 위한 기술적인 스펙을 나타낸다.

UDDI는 다음과 같이 두 부분으로 구성되어 있다.
첫 째, UDDI는 비즈니스와 웹 서비스에 대한 분산 디렉토리를 만들기 위한 기술적인 스펙이다. 데이터는 특정한 XML 포맷으로 저장 되고, UDDI 스펙은 존재하는 데이터를 검색하고 새로운 데이터를 발행하기 위한 세부적인 API를 포함하고 있다.
둘 째, UBR(UDDI Business Registry)는 UDDI 스펙에 대한 완전한 실행 방법이다. 2001년 5월 마이크로소프 트와 IBM에 의해서 시작된 UDDI 레지스트리는 누구나 UDDI 데이터를 검색해 볼 수 있고 기업은 그들의 서비스를 등록할 수 도 있다. 그리고 UDDI의 데이터의 범주를 크게 나누면 다음과 같이 세 가지 카테고리로 나뉜다.








White 페이지: 회사에 대한 일반적인 정보를 포함하고 있다. 예를 들면 비즈니스 이름, 비즈니스 세부내용, 비즈니스 주소가 있다.








Yellow 페이지: 회사나 서비스가 제공하는 분류된 데이터를 포함하고 있다. 예를 들면 표준 분류법을 토대로 산업별, 제품별, 지리적 코드별로 나뉜 데이터를 가지고 있다.







Green 페 이지: 웹 서비스에 대한 기술적인 정보를 포함하고 있다. 일반적으로 외부 스펙을 가리키거나 웹 서비스 호출에 대한 주소를 가지 고 있다. 마이크포소프트 UDDI 사이트, IBM UDDI 사이트를 참고하고 완전한 UDDI 스펙은 uddi.org에서 사용 할 수 있다.  
















9. 웹서비스를 어떻게 시작할 것인가? 

웹 서 비스를 시작하는 가장 쉬운 방법은 XML-RPC를 이용하는 것이다. XML-RPC 스펙이나 필자 의 책 『Web Service Essentials』나 사이먼 세인트 라우런트(Simon St. Laurent), 조 존스턴 (Joe Johnston), 에드 덤빌(Edd Dumbill)이 함 께 쓴 『Programming Web Services with XML-RPC』를 참고하자.

일단 XML-RPC의 기 초를 익히고 난 후 SOAP, WSDL, UDDI를 차근차근 배우면 된다. 이러한 주제들은 모 두 『Web Service Essentials』에서 다루고 있다. SOAP에 대해 더 자세한 내용을 알고 싶다면 더그 디드웰 (Doug Tidwell), 제임스 스넬(James Snell), 파벨 쿨첸코(Pavel Kulchenko) 가 쓴 『Programming Web Services with SOAP』을 참고하면 된다.

10. W3C는 웹 서비스 표준을 지원하고 있는가? 

W3C(World Wide Web Consortium) 는 활발하게 웹 서비스 프로토콜 표준화를 추진하고 있다. 2000년 11월 W3C는 XML Protocol Activity를 설립 했다. 이 그룹의 목표는 SOAP의 정식 표준을 제정하는 것이다. SOAP 1.2 초안은 현재 검토 중이며 공식적인 W3C의 권 고 안을 통해 진행중이다.

2002년 2월 25일 W3C는 Web Service Activity 조직 편성을 발표하 였다. 이 새로운 조직은 두 개의 새로운 작업 그룹뿐만 아니라 현재의 SOAP 작업그룹도 포함하고 있다. 첫 번째 그룹은 WSDL 에 관한 웹 서비스 기술 작업과 관련된 것이며, 두 번째 그룹은 웹 서비스 프로토콜 프레임워크에 대한 웹 서비스 구조를 만드는 활 동이다.

W3C의 Web Service Activity에 대한 더 자세한 정보를 얻고 싶다면 오라일리 XML.com 을 들어가서 에드 덤빌(Edd Dumbill)의 기사 「Welcome Web Services Activity」를 참고하기 바란 다.

'UP! > Web Service' 카테고리의 다른 글

그리드 서비스를 위한 Repository 시스템 개발  (0) 2008.08.21
분산객체와 웹 서비스의 차이점  (0) 2008.08.21
분산객체시스템 종류  (0) 2008.08.21
XML,SOAP,UDDI,WSDL  (0) 2008.08.21
COBRA  (0) 2008.08.21
Posted by 으랏차
,

XML,SOAP,UDDI,WSDL

UP!/Web Service 2008. 8. 21. 14:08
웹서비스는 커뮤니케이션의 형태가 웹이 출현하면서 Person to Person에서 Person to Machine으로 진화되었고, 이제 다시 Machine to Machine(빌 게이츠는 Software to Software라고 표현한다)으로 인간의 수작업 이 최소화 되고 Application 간의 커뮤니케이션이 이루어지는 것을 의미한다.

이미 구축된 HTTP라는 인프라 를 그대로 사용하면서 XML, SOAP, WSDL, UDDI를 통해 이를 가능토록 한다는 것인데 XML은 모르는 분이 없으실테 고, SOAP(Simple Object Access Protocol)은 한마디로 메세징 프로토콜로 상세한 구현절차에 상관 없이 데 이터 간의 커뮤니케이션을 가능케 하는 효과적인 패키저의 역할을 수행하는 프로토콜이다.

서비스 제공자는 요청자의 구현절차에 대해서는 아무 런 정보도 알지 못하고 서비스 요청자와 서비스 제공자 모두 요청 및 응답 메시지의 형태와 내용 밖에는 아무 것도 모르기 때문에- 알 필요가 없기 때문에- 작업을 단순화시켜 주는 요인이 된다. 즉,SOAP을 사용하면 프로토콜을 맞추기 위해 개발자 간의 약속 이 더 이상 필요 없게 된다. 웹 서비스 구현은 요청 및 응답 메시지가 변경되지 않는 한, 해당 서비스의 이용자에게 아무런 영향을 주지 않고 변경이 가능하다. 대신 기존 코드를 SOAP으로 감싸주는 박막 작업이 필요 하며 새로운 코드로 바뀌더라도 관련 변경 작업은 서비스 이용자에게 노출되지 않는다.

UDDI(Universal Description, Discovery, and Integration) 는 과거 야후!와 비교될 수 있다.1994년 야후!가 웹를 통해 사용자가 원하는 정보 리스트를 찾을 수 있는 방법을 제시했다 면 UDDI는 웹기반의 소프트웨어가 다른 소프트웨어와 어떻게 연결될 수 있는지를 제시한다.

UDDI는 일종의 애플리 케이션의 야후!로 이 레지스트리를 통해 필요한 서비스를 검색하고 활용할 수 있는 방법을 알 수 있으며 이런 UDDI의 특성으로 인 해 벌써부터 일부 전문가들은 UDDI가 Integration Broker로 발전될 것이라는 전망을 내 놓기도 한다.

분 명히 UDDI 는 enterprise application integration, supply chain management, collaborative planning 등 의 영역에서 다이나믹한 변화들을 만들어 낼 것이라고 예상된다. 아리바나 커머스원등의 B2B 서비스업자
들은 비용절감 효과를 극대화 하면서 그들의 비즈니스를 보다 풍부하게 할 수 있을 것이고 반면에 Tibco와 같은 XSP들은 자체적인 UDDI 레지스트리 구축을 신중히 검토해야 할 것이다.

UDDI 에 등록하는 것은 누구나 가능하며 그 방법은 야후!에 등록하듯 등록하는 방법이 있고 IBM이나 MS에서 제공하는 툴키트를 다운로 드 하여 UDDI 공개 API들을 사용하여 등록하는 방법이 있는데 후자의 방법이 빠를 뿐만 아니라 늘 신선한 레지스트리를 유지시 킬 수도 있기 때문에 앞으로 이 방법이 선호될 것으로 예상된다.

WSDL(Web Service Definition Language) 은 말 그대로 웹 서비스를 정의하는 언어로 UDDI에서 서비스를 이용하고자 하는 사용자가 해당 서비스의 형태가 어떻게 생겼다는 것 을 알 수 있게 XML로 정의된 것을 의미한다.

앞에서 웹서비스의 근간이 되는 기술 이슈들에 대해 간단하게 살펴 보 았다.그런데 하나하나의 기술 단어들만 나열하고 있으면 좀처럼 감이 오질 않는다.그러니까 XML,SOAP,UDDI,WSDL에 대 해 각기 풀다보면 한 눈에 들어오지 않는 것이 사실이다. 웹서비스를 유기적으로 다시 구조를 짜 맞추면 이해하기가 한결 수월한데 그것은 아래와 같이 4개로 표현될 수 있다.

1.Lookup and discovery(such as Universal Description, Discovery, and Integration-UDDI, a mechanism for locating services and discovering what they do)
2.Description(a way of description what input and outputs the services recognize Web Services Description Language-WSDL)
3.Transport(the means of sending messages between services-Simple Object Access Protocol-SOAP)
4.Environment(the facility for developing and deploying the services-Visual Studio .NET,WebSphere, WebLogic...)

위 의 유기적인 웹서비스 시스템이 구축되어진다면 웹을 통해 서비스를 판매하고자 하는 업자는 이제 자신이 구축해야 할 서비스들의 목록 을 구분하고 그것을 다 시 Core Services, Infrastructure Services, Application Services로 나눌 수 있 을 것이고 그 중 Application Services는 UDDI를 통해 개발이 아닌 임대를 하여 서비스를 할 수 있을 것이다.

지금까지 이야기 한 것을 바탕으로 웹서비스의 혜택을 표현하면 이렇다.

"Web Service Benefits include faster time to market, convergence
of disparate e-business initiatives, significant reduction in cost of ownership, real-time updating and dynamic linking of partner than IT staffs, automates the process of linking business partners and their core competencies across a value chain quickly and efficiently on the Internet".

Web Service에 대한 컬럼을 마치면서 davidndanny는 다음과 같이 3가지 제안을 하고자 한다.

1. 새로운 서비스 브로커들은 그들의 사적인 네트워크를 통해 밸류체인을 다시 배열하고 새로운 멤버들이 합류할 경우 비용 효율적이고 빠 른 방법으로 통합된 서비스를 제공할 능력을 보유해야만 한다.뿐만 아니라 새로운 서비스 브로커들의 자격은 서비스 보증에 대한 합리 적 방안,법적 문제에 대한 노하우를 포함한다.
2. 포탈은 애플리케이션 벤더들과의 Application 협업 시스템을 신속히 구축하고 그에 따르는 지적 재산권,사용 범위 등을 규정하는 가이드라인을 공표하여 현재의 Text data를 제공하는 구조에서 벗어나
다이나믹한 서비스를 제공할 방법에 대해 집중적으로 고민해야 한다.

3. 정부는 관련 기관들과 긴밀히 협조하여 Web Service 표준 규약에 적합한 형태의 한국형 UDDI를 신속히 구축,웹서비스 인프라를 만들어야 하며 또한 국제적인 홍보에 앞장서야만 한다.

http://ibiznet.inews24.com/column/column_view.php?key=2258&cate=030100

'UP! > Web Service' 카테고리의 다른 글

그리드 서비스를 위한 Repository 시스템 개발  (0) 2008.08.21
분산객체와 웹 서비스의 차이점  (0) 2008.08.21
분산객체시스템 종류  (0) 2008.08.21
웹 서비스와 관련된 10가지 질문  (0) 2008.08.21
COBRA  (0) 2008.08.21
Posted by 으랏차
,

COBRA

UP!/Web Service 2008. 8. 21. 14:06
*** CORBA(Common Object Request Broker Architecture)

1989 년대에, 현존하는 객체지향 기술을 바탕으로 응용 프로그램들을 결합하기 위한 객체지향 표준을 제정하기 위 해 OMG(Object Management Group)가 탄생하였다. OMG는 700개 이상의 컴퓨터 관련 단체들이 참가하여 객체 지향 기술을 기반으로 이종의 분산된 환경 하에서 응용 프로그램들을 통합하고 상호연동할 수 있는 표준기술을 제정했는데, 바로 이 표 준이 OMA(Object Management Architecture)이다.

OMA는 응용 프로그램간의 통합뿐만 아니 라 객체의 생성, 소멸에서부터 저장, 트랜잭션(transaction) 기능에 이르기까지 분산 객체 환경에서 필요한 모든 서비스 를 총칭하는 것이다. 이들 기능 중 CORBA는 컴퓨터 내부의 Bus처럼 서로 다른 프로그램들 사이의 Bus 역할을 하는 모듈로 서 프로그래머가 원하는 메소드 등의 위치에 관계없이 마치 로컬에 있는 것처럼 사용할 수 있도록 하는 기능을 제공한다. 따라 서 CORBA는 OMA에서 가장 중요한 요소가 된다.

CORBA는 어플리케이션으로 하여금 한 operation이 분산 객체에 의해서 수행되게 하며, 그 operation의 결과에 대하여 그 요청을 만든 어플리케이션에게 리턴하도록 한다. 이것은 기본 적인 클라이언트/서버 기능이며, 클라이언트는 요청을 만들어 서버에게 주고 그 서버는 그 요청에 대해 응답한다. 데이터는 클라이언트 로부터 서버로 전달되며, 그 데이터는 특정 객체의 특정 operation으로 구성되어 있다. 데이터는 그러고 나서 응답의 형태 (form)로 클라이언트에게 리턴된다.

CORBA를 사용함으로써 다음과 같은 이점을 얻을 수 있다.
1. CORBA는 많은 언어를 지원한다. CORBA는 또한 하나의 분산 어플리케이션에서 이것을 혼합된 형태로도 지원한다.
2. CORBA는 분산과 객체 지향을 지원한다.
3. CORBA 는 산업 표준이다. 이것은 벤더들 사이에서의 경쟁을 유발하고 질좋은 구현들이 존재할 수 있도록 해준다. CORBA 표준은 또한 개발자들에게 구현들 사이에서의 일정 수준의 portability를 제공한다.
4. CORBA는 고수준의 상호작용성을 제공한다. 이것은 서로 다른 CORBA제품에서 만들어진 분산 객체들이 서로 통신 할 수 있도록 한다.


* 참조 사이트

1. Corba Homepage
   http://www.corba.org

2. OMG Homepage
   http://www.omg.org/

3. OMG Korean Working Group
   http://dpnm.postech.ac.kr/komg/

*** OMG에 대해

OMG 는 지난 89년 5월 8개 회사(3Com, 아메리카 온라인, 캐논, 데이터 제너럴, HP, 필립스 텔레커뮤니케이션즈, 썬 마이크로 시스템즈, 유니시스)가 주축이 돼 설립했다. 그 해 10월 비영리 집단으로서 독립적인 활동을 시작했다. 기술적으로 훌륭하며 상업적 으로 가치가 있고 소프트웨어 산업에서 벤더 독립적인 것을 개발하기 위한 노력으로 현재 OMG의 회원은 800개사를 넘어섰 다. OMG에서는 분산객체 관리 시스템의 요구 사항을 충족시키기 위해 CORBA를 제안했다. 이러한 디자인 과정에서 OMG가 무게 를 두고 있는 부분은 완전히 개방된 객체 구조를 생성한다는 점이다. 즉, 현재의 소프트웨어는 기본적으로 이식성 (portability)과 상호 운용성(interoperability)을 가져야 한다는 요구 조건을 기본으로 하고 있다.

OMG가 제안한 표준은 현재 대다수의 컴퓨터 회사나 연구 분야에서 받아들여지고 있는데 그 성공 비결은 다음과 같다.

OMG 는 프로그램 코드 자체를 제안하는 것이 아니라 인터페이스 명세만 제안한다. 이 인터페이스 명세 는 IDL(Interface Definition Language)이라는 특정 프로그래밍 언어에 종속되지 않는 독립적인 언어이며 특 정 운영체제 또는 네트워크에 종속되지 않는다.

각 ORB 구현 제품은 CORBA 2.0/2.3/3.0 명세를 따르면 이 제품들 간에 상호 운용할 수 있다.

OMG 는 세계 표준인 CORBA/IIOP, 객체 서비스, 인터넷 퍼실리티(Internet Facilities), 도메인 인터페이스 규격 (Domain Interface Specification)을 통해 '세상 어디서나 사용하는 미들웨어'라는 슬로건을 내걸고 발전 해 나가고 있다.

OMG는 표준화 객체 소프트웨어의 도입을 통해 컴포넌트 기반의 소프트웨어 시장을 형성하는 역할을 했 다. 즉, 애플리케이션 개발을 위한 공통적인 프레임워크를 제공하기 위해 세부적인 규격을 제정하고 있는 것이다. OMG에 대 한 더 많은 정보는 OMG 홈페이지(www.omg.org)를 참고하기 바란다.

*** CORBA의 각종 서비스

CORBA 의 서비스에 대한 일반적인 정의를 내리자면, ORB를 이용해 소프트웨어를 개발할 때 개발된 코드를 재사용하기 위해, 개발 소프트웨 어 도메인에 독립적으로 작업할 수 있는 프로그램을 말한다. 이것은 개발에 필요한 중요한 문제를 해결하기 위해 여러 중요한 기능 을 한 가지씩 담당할 수 있게 만들어졌고, 이 서비스들을 조합해 당면한 문제들을 해결할 수도 있다. 현재 OMG는 15개 의 CORBA 서비스 규격을 발표했다.

*** COSS1에 정의된 CORBA 서비스

* 명명 서비스 (Naming Service) : 객체 정보의 등록 및 검색과 관련된 기능을 제공하는 서비스로 네트워크에 산재돼 있는 구현객체들 이 자신의 정보를 등록하고, 클라이언트 프로그램들은 자신이 필요한 구현객체의 정보를 이름으로 검색, 구현객체 정보를 취득한다. 취 득한 구현객체의 정보로 구현객체에 접근할 수 있도록 해주는 서비스가 명명 서비스다.

* POS 서비스 : POS 는 CORBA 객체가 종료돼도 객체의 상태를 유지 관리해주는 서비스다. 클라이언트 프로그램은 이 POS를 이용해 객체의 현재 상태 를 다른 매체에 저장하고 필요할 때 PID를 이용, 저장된 객체를 복구해 사용할 수 있다.

* 생명 주기 서비스 (Life Cycle Service) : 이 서비스는 객체의 초기 생성부터 소멸되는 시점까지 일련의 객체 생명 주기를 관리하는 서 비스로, Naming, Externalization, Relationship 서비스와 연계해 사용한다.

* 이벤트 서비스(Event Service) : 이벤트 서비스는 객체들간의 이벤 트 메시지를 처리할 수 있는 서비스로, 객체들 간의 콜백 기능을 이벤트 서비스로 대치해 사용할 수 있다.

*** COSS2에 정의된 CORBA 서비스

* 트랜잭션 서비스(Transaction Service, OTS) : OTS는 객체의 트랜잭션을 관리하는 서비스로 RDB에서 트랜잭션을 관리하듯이, CORBA 객체에 대한 트랜잭션을 처리할 수 있게 지원하는 서비스다.

* 동 시 동작 제어 서비스(Concurrency Control Service) : 객체들의 특정 자원에 대한 동시 접근을 제어하는 서비 스다. 예를 들어, 프린팅하는 기능을 갖는 구현객체가 프린터를 사용중일 때 다른 객체가 프린터를 사용하지 못하게 하고, 먼저 프린 터를 사용하는 객체가 프린터를 독점하지 못하게 제어하는 기능을 지원하는 서비스다.

* 관계 서비스(Relationship Service) : 객체 사이의 관계를 관리하는 서비스로 디자인 시에 작성된 관계 외에도 관계가 없는 객체 사이를 런타임에 관계를 설정할 수 있게 지원하는 서비스다.

* 외 부화 서비스(Externalization Service) : 객체 상태의 저장 및 재생을 지원하는 서비스로 POS는 플랫 파 일, 관계형 데이터베이스, 객체 데이터베이스 등을 사용해 관리하지만 이 서비스는 객체 상태를 스트림화하기 때문에 다양한 방법으 로 저장하고 나중에 재생해 사용할 수 있는 기능을 지원한다.

*** COSS3에 정의된 CORBA 서비스

* 보 안 서비스(Security Service) : CORBA 객체들의 보안을 관리하는 서비스로 네트워크를 기반으로 하는 분산 환경에 서 시스템을 공격하고자 하는 사람, 부적절한 방법으로 시스템을 이용하는 사용자에 의해 발견될 수 있는 모든 보안 구멍 (security holes)을 막도록 설계했으며 안전한 환경에서 상호 작용하는 객체가 보안 정책이 집행 중이라는 사실 을 알 수 없도록 설계돼 있다.

* 시간 서비스(Time Service) : 분산된 객체간의 시간 동기화를 관리하 는 서비스다. 예를 들어, 서울과 미국에서 9시에 어떤 통계 작업을 진행하고자 할 때 서로 시각에 대한 개념이 다르기 때문에 집계 가 잘 안 될 수 있다. 이때 이 서비스를 통해 서로의 시간을 동기화할 수 있으면 정확히 9시에 통계 작업이 진행돼 원하는 결과 를 얻을 수 있을 것이다.

*** COSS4에 정의된 CORBA 서비스

* 질의 서비스 (Query Service) : 질의문을 사용, 객체를 검색하는 기능을 갖는 서비스로 질의문에서 작성된 기준에 만족하는 어트리뷰트 를 갖는 객체를 검색해 낼 수 있다. 이 서비스에서 사용하는 질의문은 SQL이나 OQL 중 하나를 사용할 수 있다.

* 라 이선싱 서비스(Licensing Service) : 사용자가 객체를 사용하기 위한 라이선스를 관리하는 서비스로, ORB 기반의 컴 포넌트를 개발하고 서비스를 제공하는 제공업자가 사용자들이 사용한 컴포넌트들에 대한 사용 대가를 회수할 때에 필요한 자료 및 기능 을 제공하기 위해, ORB 기반의 컴포넌트 사용에 대한 라이선스를 관리하는 서비스다.

* 프로퍼티 서비스 (Properties Service) : 객체의 동적 프로퍼티를 생성하고, 이를 관리하는 서비스다. 이미 IDL에 정의되어 있 는 객체에 프로퍼티를 추가할 경우 보통의 경우 해당 객체의 IDL을 수정, 다시 컴파일해 사용해야 한다. 하지만 이 서비스를 사용 하면 런타임에 특정 객체의 프로퍼티를 동적으로 생성해 사용할 수 있는 기능을 지원한다.

*** COSS5에서 정의된 CORBA 서비스

* 트 레이더 서비스(Trader Service) : 객체를 등록하고, 검색할 수 있도록 지원하는 서비스로 Exporter가 트레이더에 게 기능 정보를 제공하면, Importer가 필요한 기능을 질의문으로 만들어 객체 정보를 검색하는 서비스다. 이 서비스를 사용하 면, Exporter가 제공하는 기능 정보를 Importer가 트레이더를 통해 필요한 기능의 객체를 검색하고, 검색된 객체 정보 를 이용해 네트워크에 분산돼 있는 구현객체에 접근, 필요한 기능을 사용할 수 있다.

* 컬렉션 서비 스 (Collection Service) : 이 서비스는 객체들에 대한 리스트 관리를 지원하는 서비스로, 동일한 객체들을 일렬 로 묶거나(list), 서로 다른 객체들을 꾸러미(bag)로 만들 필요가 있을 때 사용하는 서비스다.

'UP! > Web Service' 카테고리의 다른 글

그리드 서비스를 위한 Repository 시스템 개발  (0) 2008.08.21
분산객체와 웹 서비스의 차이점  (0) 2008.08.21
분산객체시스템 종류  (0) 2008.08.21
웹 서비스와 관련된 10가지 질문  (0) 2008.08.21
XML,SOAP,UDDI,WSDL  (0) 2008.08.21
Posted by 으랏차
,

티스토리툴바