SOAP과 RDF in Web Service

SOAP과 RDF

원격 프로시져 호출을 넘어서..

난이도 : 초급

Uche Ogbuji, 컨설턴트, Fourthought, Inc

2002 년 2 월 01 일

이 글을 통해 RDF 모델에서 정보를 교환하는데 SOAP이 사용될 수 있는 방법들이 검토된다. RDF 모델의 기본적인 데이터를 PC 교환이나 RDF/XML 직렬화 형식에서 모델의 부분들을 직접 전달하는데 필요한 SOAP 인코딩으로 변환하는방법을 연구한다.

SOAP은 저수준 인터넷 프로토콜을 통해 XML payload를 전송하는데 쓰이는 전송 프로토콜이다. 1.2 이전의 전송 스팩은 프로그래밍 언어 구조체의 직렬화로 연동된 XML의 기본 인코딩에 빌트인되었다. 그와같은 인코딩은 원격 프로시져 호출(RPC) 시스템의 요소이다. RPC 인코딩의 다른 예제는 "구(classic) RPC의 External Data Representation (XDR)이고 CORBA의 Common Data Representation (CDR)이 있다. 이와 같이 유사한 것들로 인코딩을 번들한 결과 SOAP은 명확히 애플리케이션 프로그래밍 느낌을 띠게되고 일반적인 데이터 교환의 유용성은 의심스러워졌다.

초기의 "SOAP의 향기"는 많은 논란을 일으켰다. 우선, 혼합 전송과 데이터 인코딩은 통신에 있어서 매우 어지러운 접근방식이다. 수십년동안 네트워킹 관례로 되어있는 레이어드 프로토콜을 무시한 것이다. 결국, HTML 마크업 스팩은 HTTP 스팩으로 삽입되지 않는다. 두 번째, 탁월성을 위해 RPC 비슷한 인코딩을 선택한다면 SOAP을 이상한 지점에 놓는 것이다; 이것은 이전 XML RPC 메커니즘 보다 좀 더 강력한 힘을 가지고 있지만 실제로는 덜 효과적이다. XML의 수다스러움과 HTTP, SMTP 등과 같은 좀 더 일반적인 아키텍쳐 때문이다. 차세대 RPC 로서 SOAP의 유일한 장점은 Microsoft와 CORBA 진영을 통합했다는 것이다; 이는 중요하지만 SOAP이 반드시 약속해야할 부분은 아니다.

RPC로서의 SOAP의 한가지 중요한 결과는 그와 같은 시스템이 일반적으로 차세대 EDI 의 야망을 가진 웹 서비스에게는 완벽히 맞지 않는다는 점이다. 만일 웹 서비스가 네트워크를 통한 새로운 방식의 비지니스가 된다면 프로그래밍 언어 API의 레벨이 아닌 비지니스와 합법적 요청의 레벨에서 통신하는 전송 메커니즘을 필요로 한다. 그리고 국제적 전자 비지니스 통신을 위한 시스템을 만드는데 XML을 사용하는 것이 목적인 ebXML 이니셔티브는 몇몇의 다른 영향력있는 곳과 마찬가지로 SOAP 사용을 주저하게 한다.

그 이후로 상황은 많이 안정되었다. SOAP 1.2은 특별한 인코딩 의존성을 다소 탈피했고, 대부분의 프로들은 ebXML을 포함하여 SOAP을 사용하고 있다. 대부분의 SOAP 구현은 여전히 특별한 SOAP 인코딩을 독점적으로 사용하고 있지만 점점 개방될 것이다. 광범위한 인코딩 선택을 위해 플러그인 아키텍쳐를 이용하여 좀더 다양한 통신 문제를 다루게 될 것이다. 그중 하나의 문제는 메테데이터를 교환하는 것이다.

Resource Description Framework (RDF)은 그와 같은 메타데이터 교환을 해결하는 몇 가지 도구를 갖춘 모델링 시스템이다. 이 글에서는 그와 같은 메타데이터의 인코딩을 위해 어떻게 RDF가 SOAP과 함께 사용될 수 있는지를 검토한다. 또한 RDF에 인코딩된 데이터 인스턴스가 어떻게 직접적으로 SOAP 인코딩으로 변환하지 않고 직접 전송될 수 있는지도 검토한다. SOAP과 RDF에 익숙해져야 한다. (참고자료). IBM developerWorks XML 존의 Thinking XML 칼럼을 참조하기 바란다.

RDF라는 멋진 배

RDF를 갖추고 있을 경우 한 시스템에서 또 다른 SOAP으로 옮기기 위해 할 수 있는 일을 설명하겠다. Thinking XML 칼럼에서 소개한 지속적인 이슈 추적 프로젝트에서 예제를 들어 설명하겠다. 한 시스템에 추가된 이슈의 상세한 부분을 하나의 원격 머신으로 교환하기 원한다고 해보자. 이것은 분산화된 이슈 트래커의 기초가 될 수도 있다. RDF 직렬화에서 이슈가 어떻게 보이는지의 예제는 Listing 1에 나와있다.

Listing 1: RDF/XML serialization

<?xml version="1.0"?> <rdf:RDF xmlns:it="http://rdfinference.org/schemata/issue-tracker/" xmlns:dc="http://purl.org/dc/elements/1.1#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xml:base="http://rdfinference.org/versa/issues"> <it:issue rdf:ID="0101"> <dc:relation rdf:resource="http://rdfinference.org/versa/0/2"/> <dc:identifier>0101</dc:identifier> <dc:creator rdf:resource="mailto:uche.ogbuji@fourthought.com"/> <dc:date>2002-01-27</dc:date> <dc:title>Data type conversions</dc:title> <dc:description>Not all the data type conversions listed make sense. In particular the question of how to convert numeric types to resources and vice versa require much thought.</dc:description> </it:issue> </rdf:RDF>

이것은 웹 서비스에 대해 발생한 예제 이슈이다. 이슈 그 자체는 URI http://rdfinference.org/versa/issues#0101에 의해 구분된다. 이는 문서의 기본 URI를 받아서 이슈를 나타내는 유형화된 노드에서 rdf:ID 속성에 의해 주어진 것 처럼 조각을 추가하는 것이다. 문서 요소의 기본 URI는 xml:base 속성을 사용하여 http://rdfinference.org/versa/issues 처럼 주어진다. 그런다음 이슈 자체에 대한 여러 문장을 만들면서 Dublin Core의 dc:relation 메타데이터 태그를 사용하여 이슈가 참조할 리소스를 주는 것이 중요하다. 또한 친근한 디스플레이를위해 이슈의 전체 URI를 단축한 식별자, 이슈의 작성자, 제출 날자, 간단한 제목, 설명등을 제공한다.

가장 중요한 문제는 어떻게 이것이 추상적 RDF 모델로 변환되는 지가 중요하다. 예를 들어, 그림 1은 RDF 시각화 툴로 만들어졌다. Dan Brickley의 온라인 RDF visualizer를 사용하여 비슷한 그래프를 만들 수 있다.

그림 1: 샘플 RDF 모델의 그래프

이제 SOAP 메시지로 이 모델을 전송하는 두 가지 방법을 살펴보자; 우선 SOAP 인코딩으로 변환하고 그 다음 직접 RDF에서 인코딩 한다.

SOAP 인코딩 사용하기

우선, 전송에 필요한 메소드를 이해해야 한다. 여러분이 정의한 RDF는 데이터 묶음이고 메시지로 데이터 묶음을 전송하는 것이다. 이 데이터를 받은 사람이 무엇을 할것인지에 따라 이름을 정한다. 이 경우 원격 서버에 추적할 새로운 이슈가 있다는 것을 알린다. 그래서 newIssue 메소드를 호출했다. 이제부터 여러분은 SOAP 인코딩을 사용하고 있다는 것을 주목하고 메소드 이름을 RPC용 SOAP 바인딩을 가진 프로그래밍 언어에 적합하도록 맞추어야 한다.

그런다음 새로운 이슈 객체를 전송할 방법을 찾아야 한다. 새로운 객체의 ID와 속성을 전송하는 방법이 있다. 기본적으로 새로운 이슈 객체의 각 속성을 없애고 메시지 매개변수로 변환한다. SOAP 인코딩은 타입 정보로 가득 차있기 때문에 각 매개변수를 type (Listing 2 참조)으로 꾸며야 한다.

Listing 2: newIssue SOAP message

http://www.w3.org/2001/12/soap-envelope"> <env:Body> <itsoap:newIssue env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap" xmlns:it="http://rdfinference.org/schemata/issue-tracker/" xmlns:dc="http://purl.org/dc/elements/1.1#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <dc:identifier xsi:type="xs:nonNegativeInteger">0101</dc:identifier> <dc:relation xsi:type="xs:anyURI">http://rdfinference.org/versa/0/2</dc:relation> <dc:creator xsi:type="xs:anyURI">mailto:uche.ogbuji@fourthought.com</dc:creator> <dc:date xsi:type="xs:date">2002-01-27</dc:date> <dc:title xsi:type="xs:string">Data type conversions</dc:title> <dc:description xsi:type="xs:string">Not all the data type conversions listed make sense. In particular the question of how to convert numeric types to resources and vice versa require much thought.</dc:description> </itsoap:newIssue > </env:Body> </env:Envelope>

모든 값들은 SOAP 인코딩 규칙이 요구하는 대로 엘리먼트의 내용에 위치된다. 여기에는 RDF의 리소스로서 마킹된 값들도 포함하고 있다. 그리고 anyURI데 이터 타입에 주어진다. 이것은 URI 레퍼런스인 값들 뿐만아니라 전체 URI도 허용한다는 것을 주목하자. 그와 같은 모든 메시지가 이 포맷을 갖고 있다면 메시지 엘리먼트에 대한 XML 스키마 정의를 내림으로서 매번 데이터 타입을 반복해야 하는 필요를 없앨 수 있다. Listings 3 과 Listing 4 는 그와 같은 schemata의 조각들이다.

Listing 3: newIssue SOAP message element용 schema fragment

<?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Body> <itsoap:newIssue env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap" xmlns:it="http://rdfinference.org/schemata/issue-tracker/" xmlns:dc="http://purl.org/dc/elements/1.1#" > <dc:identifier>0101</dc:identifier> <dc:relation>http://rdfinference.org/versa/0/2</dc:relation> <dc:creator>mailto:uche.ogbuji@fourthought.com</dc:creator> <dc:date>2002-01-27</dc:date> <dc:title>Data type conversions</dc:title> <dc:description>Not all the data type conversions listed make sense. In particular the question of how to convert numeric types to resources and vice versa require much thought.</dc:description> </itsoap:newIssue > </env:Body> </env:Envelope>

Listing 4: newIssue SOAP message parameter elements용 schema fragment

<!-- with target namespace = http://purl.org/dc/elements/1.1# --> <xsd:element name="identifier" type="xsd:nonNegativeInteger"/> <xsd:element name="relation" type="xsd:anyURI"/> <xsd:element name="creator" type="xsd:anyURI"/> <xsd:element name="date" type="xsd:string"/> <xsd:element name="title" type="xsd:string"/> <xsd:element name="description" type="xsd:string"/>

 

이러한 것들은 SOAP 메시지를 Listing 5 처럼 단순하게 만든다.

Listing 5: 인라인 타입의 데코레이션이 없는 newIssue SOAP message

<?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Body> <itsoap:newIssue env:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap" xmlns:it="http://rdfinference.org/schemata/issue-tracker/" xmlns:dc="http://purl.org/dc/elements/1.1#" > <dc:identifier>0101</dc:identifier> <dc:relation>http://rdfinference.org/versa/0/2</dc:relation> <dc:creator>mailto:uche.ogbuji@fourthought.com</dc:creator> <dc:date>2002-01-27</dc:date> <dc:title>Data type conversions</dc:title> <dc:description>Not all the data type conversions listed make sense. In particular the question of how to convert numeric types to resources and vice versa require much thought.</dc:description> </itsoap:newIssue > </env:Body> </env:Envelope>

미가공(raw) RDF 보내기

이 글을 시작하면서 언급했지만 SOAP을 사용하기 위해서 SOAP 메시지를 RPC 형식으로 바꿀 필요는 없다. RPC 통합 필요성을 절감하는 것이 아니라면 데이터를 보내고 이를 원격 시스템에서 자유롭게 프로세스하는 접근 방식을 취할 수 있다. SOAP을 위한 공식적인 RDF 인코딩은 없지만 이 논의는 RDF와 SOAP의 규약과 규정에 근거한 것이다.

가장 단순한 접근 방식은 rdf:RDF 엘리먼트를 SOAP 바디의 하나의 상위 레벨 엘리먼트로 만드는 것이다. (Listing 6).

Listing 6: RDF와 같은 SOAP 메시지

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"> <env:Body> <rdf:RDF env:encodingStyle="http://rdfinference.org/rdfws/soap-encoding" xmlns:it="http://rdfinference.org/schemata/issue-tracker/" xmlns:dc="http://purl.org/dc/elements/1.1#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" > <it:issue rdf:about="http://rdfinference.org/versa/issues#0101"> <dc:relation rdf:resource="http://rdfinference.org/versa/0/2"/> <dc:identifier>0101</dc:identifier> <dc:creator rdf:resource="mailto:uche.ogbuji@fourthought.com"/> <dc:date>2002-01-27</dc:date> <dc:title>Data type conversions</dc:title> <dc:description>Not all the data type conversions listed make sense. In particular the question of how to convert numeric types to resources and vice versa require much thought.</dc:description> </it:issue> </rdf:RDF> </env:Body> </env:Envelope>

 

인코딩 ID가 사용되고, http://rdfinference.org/rdfws/soap-encoding 는 비표준이고 기본적으로 RDF/XML을 SOAP 메시지 바디로 직접 임베딩하는 것을 명령하고 있다. 메시지 형식과 단순한(plain) 형식 사이의 한 가지 주요한 차이점은 rdf:about 이 이슈 리소스를 구분하기 위해 사용된다는 점이다. SOAP 전송을 위해 RDF 모델을 직렬화하는 중요한 원칙이 있다: 인라인 선언을 피하는 것이다. xml:base을 사용하여 ID에 대한 기본 위치를 고정할 수 있다면 그와같은 원칙은 불필요하다. 하지만 인라인 전송 리소스의 생명주기와 소유권을 위한 어떤 분명한 의미를 상상하기는 힘들다. 어떤 상황에서도 피할 수 없다.

위로

결론

SOAP과 RDF가 상호작동할 수 있는 방법에 있어서 다른 접근방식들이 있다. 실제로 이것은 RDF 사용자들이 웹 서비스를 발견할 때 지속적으로 흥미를 가져가는 부분이다. 자세한 내용은 참고자료 부분을 참조하기 바란다. XML 기반 데이터를 직렬화하는 일반적인 시스템은 웹 서비스 세계를 더욱 풍요롭게 만들것이다.