3. XML, SOAP, WSDL, UDDI
3.1. XML(eXtensible Markup Language) 기초
3.1.1. XML 개요
XML(eXtensible Markup Language)는 데이터를 전송하고 저장하는데 사용되는 마크업 언어(markup language)다. XML은 HTML(Hyper Text Markup Language)와는 다른 목적으로 사용된다. HTML이 데이터를 표시하는데 사용된다면, XML은 데이터를 전송하고 저장하는데 사용된다.
사실 XML은 어떤 일을 하지 않는다. XML은 정보를 구조화하고 저장하고 전송하기 위해 사용된다. 다음은 갑돌이가 갑순이에게 보내는 쪽지를 XML 형식으로 저장한 예이다.
<note>
<from>갑돌이</from>
<to>갑순이</to>
<heading>알림</heading>
<body>이번 주말 데이트 잊지 마!</body>
</note>
위의 쪽지(note)에는 보내는 사람(from)과 받는 사람(to)의 정보가 포함되어 있으며, 제목(heading)과 메시지 몸체(body)를 갖고 있다. 그러나 이 XML 다큐먼트는 아무 것도 하지 않는다. 그저 태그(tag) 안에 둘러싸여 있는 순수한 정보일 뿐이다. 이 다큐먼트를 보내고 받고, 표시하기 위해서는 누군가 소프트웨어를 작성해야 한다.
XML에는 특별한 것이 없다. 그저 평범한 텍스트일 뿐이다. 텍스트를 처리할 수 있는 소프트웨어는 XML도 처리할 수 있다. 그러나 XML 애플리케이션은 XML 태그를 특별한 방식으로 처리한다. 태그의 기능적인 의미는 애플리케이션에 달려있다.
위의 예에서 <from>과 <to>와 같은 태그는 XML 표준에 정의되어 있지 않다. 이들 태그는 XML 다큐먼트의 저작자가 “만들어 낸” 것이다. 그것은 XML 언어가 어떤 태그도 미리 정의하고 있지 않기 때문이다. 반면에 HTML에서 사용되는 태그와 구조는 미리 정의되어 있다. HTML 다큐먼트는 <p>나 <h1>과 같이 HTML 표준에서 정의된 태그 만 사용해야 한다. 그러나 XML은 저작자가 자기 자신의 태그와 다큐먼트 구조를 정의할 수 있게 한다.
XML은 HTML을 대체하는 것이 아니라 보완한다. 대부분의 웹 애플리케이션에서 XML은 데이터를 전송하는데 사용되지만, HTML은 데이터를 형식화하고 표시하는데 사용된다.
3.1.2. XML의 이점
XML은 데이터 저장과 공유를 단순화하기 위해 웹 개발의 여러 분야에서 사용된다.
1) XML은 HTML로부터 데이터를 분리한다
HTML 다큐먼트에 동적인 데이터를 표시해야 하는 경우에 데이터가 변경될 때마다 HTML를 수정해야 하는 번거러운 작업을 해야 한다. 이런 경우라면 데이터를 별도의 XML 파일에 저장하게 하고 HTML에는 데이터의 레이아웃을 결정하고 표시하는데 집중하게 할 수 있다. 그리고 몇 행의 자바 스크립트로 XML 파일을 읽어서 HTML에 데이터의 내용을 표시하게 함으로써 해당 데이터가 변경될 때 HTML을 변경하지 않아도 되게 할 수 있다.
2) XML은 데이터 공유를 단순하게 한다
실세계에서 컴퓨터 시스템과 데이터베이스는 호환되지 않는 형식으로 데이터를 저장한다. 그러나 XML 데이터는 평범한 텍스트 형식으로 저장된다. 이것은 소프트웨어와 하드웨어 독립적인 형식으로 데이터를 저장할 수 있는 기능을 제공하므로,서로 다른 애플리케이션이 공유할 수 있는 데이터를 손쉽게 생성할 수 있게 된다.
3) XML은 데이터 전송을 단순하게 한다
XML을 사용하면 호환되지 않는 시스템 사이에 데이터를 손쉽게 교환할 수 있다. 개발자들이 가장 많이 시간을 소비하는 문제 중의 하나가 인터넷을 통해 호환되지 않은 시스템 사이에 데이터를 교환하는 일이다. XML로 데이터를 교환하면 이런 복잡성을 크게 감소시킬 수 있다.
4) XML은 플랫폼 변화를 단순하게 한다
새로운 시스템(하드웨어나 소프트웨어 플랫폼)으로 업그레이드하는 것은 항상 많은 시간을 소비하게 한다. 많은 양의 데이터가 변환되어야 하며 호환되지 않는 데이터를 손실되는 경우가 많다. XML 데이터는 텍스트 형식으로 저장되므로, 데이터를 잃어버리지 않고도 새로운 운영체제나 애플리케이션으로 확장하거나 업그레이드하기 쉽다.
5) XML은 새로운 인터넷 언어를 만드는데 사용된다
많은 새로운 인터넷 언어들이 XML을 기반으로 생성된다. 그 중 몇가지 예를 들면 다음과 같다.
o XHTML : HTML의 최신 버전
o WSDL : 웹 서비스 디스크립션
o WAP 과 WML : 핸드헬드 디바이스의 마크업 언어
o RSS : 뉴스 제공 언어
o RDF와 OWL : 리소스와 온톨로지 디스크립션
o SMIL : 웹 용 멀티미디어 디스크립션
3.1.3. XML 트리
XML 다큐먼트는 루트(root)에서 시작하여 리프(leaf)로 분기하는 트리(tree) 구조를 형성한다. XML 다큐먼트는 자기 소개 형식의 단순한 구문을 사용한다.
<?xml version="1.0" encoding="UTF-8"?>
<note>
<from>갑돌이</from>
<to>갑순이</to>
<heading>메시지</heading>
<body>이번 주말 데이트 잊지 마!</body>
</note>
위의 예에서 첫번째 행에서는 XML을 선언한다. 즉, 이 문서가 XML 다큐먼트임을 말해준다. 여기에서는 XML 1.0 버전을 사용하며, UTF-8 인코딩 방식 즉, 유니코드 인코딩 방식을 사용함을 정의하고 있다. 두번째 행에서는 XML 다큐먼트의 루트 요소를 기술한다. 즉, 이 문서는 note라고 말하는 것과 같다. 다음 4행은 4개의 리프 요소 즉, from과 to, heading, body를 기술한다. 마지막 행은 루트 요소의 끝임을 정의한다.
위의 예에서 처럼 XML 다큐먼트는 하나의 루트 요소를 포함해야 하며, 루트 요소는 다른 모든 요소의 “부모”로서의 역할을 하게 된다. XML 다큐먼트에서 요소들은 트리 구조를 형성한다. 트리는 루트에서 시작하여 최하위 레벨까지 분기한다. 모든 요소는 서브 요소 또는 자식 요소를 가질 수 있다.
<root>
<child>
<subchild>….</subchild>
</child>
</root>
요소 사이의 관계를 기술하는데 부모(parent), 자식(child), 이웃(sibling)이란 용어가 사용된다. 부모 요소는 자식들을 가질 수 있으며, 같은 레벨에 있는 자식들을 이웃이라고 한다. 모든 요소는 텍스트 컨텐츠(content)와 애트리뷰트(attribute)를 가질 수 있다.
위의 그림은 하나의 책을 다음과 같이 XML로 표현한다.
<bookstore>
<book category="COOKING">
<title lang="en">Everyday Italian</title>
<author>Giada De Laurentiis</author>
<year>2005</year>
<price>30.00</price>
</book>
<book category="CHILDREN">
<title lang="en">Harry Potter</title>
<author>J K. Rowling</author>
<year>2005</year>
<price>29.99</price>
</book>
<book category="WEB">
<title lang="en">Learning XML</title>
<author>Erik T. Ray</author>
<year>2003</year>
<price>39.95</price>
</book>
</bookstore>
위의 예에서 루트 요소는 <bookstore>이며, 모든 <book> 요소는 <bookstore> 안에 포함된다. <book> 요소는 4개의 자식 요소를 가지며, 여기에는 <title>, <author>, <year>, <price>가 포함된다.
3.1.4. XML 구문 규칙
XML 구문 규칙은 아주 단순하며 논리적이므로, 배우기 쉽고 사용하기 쉽다.
1) 모든 XML 문서는 끝 태크(end tag)를 가져야 한다
HTML에서는 다음과 같이 끝 태그를 갖지 않는 요소를 볼 수 있다.
<p>이것은 문단입니다
<p>이것은 다른 문단입니다
그러나 XML에서는 끝 태그를 생략할 수 없으며, 모든 요소는 끝 태그를 가져야만 한다.
<p>이것은 문단입니다</p>
<p>이것은 다른 문단입니다</p>
2) XML 태그는 대소문자를 구별한다
XML 요소는 XML 태그를 사용하여 정의되며, XML 태그는 대소문자를 구별한다. 따라서 <Letter> 태그와 <letter> 태그는 서로 다르다. 시작 태그와 끝 태그는 같은 대소문자로 작성되어야 한다.
<Message>이것은 틀렸습니다</message>
<message>이것은 맞습니다</message>
3) XML 요소는 적절하게 네스팅되어야 한다
HTML에서는 다음과 같이 부적절하게 네스팅된 요소를 종종 볼 수 있다.
<b><i>이 텍스트는 굵은체와 기울임체입니다</b></i>
그러나 XML에서는 모든 요소가 서로 안에서 적절하게 네스팅되어야 한다. 여기에서 적절하게 네스팅된다라고 하는 말은 다음 예와 같이 <i> 요소가 <b> 요소 안에서 열렸을 때 <b> 요소 안에서 닫혀야 한다는 것을 의미한다.
<b><i>이 텍스트는 굵은체와 기울임체입니다</i></b>
4) XML 다큐먼트는 하나의 루트 요소를 가져야 한다
XML 다큐먼트는 모든 요소의 부모가 되는 하나의 요소를 포함해야 하며, 이 요소를 루트 요소라고 한다.
<root>
<child>
<subchild>….</subchild>
</child>
</root>
5) XML 애트리뷰 값은 쌍따옴표로 둘러싸야 한다
HTML과 같이 XML 요소도 이름과 값의 쌍으로 된 애트리뷰트를 가질 수 있다. XML에서 애트리뷰트 값은 항상 쌍따옴표로 둘러싸야 한다. 다음 두개의 XML 다큐먼트에서 첫번째 것은 틀린 것이고 두번째 것이 맞는 것이다.
<note date=2008/6/22>
<from>갑돌이</from>
<to>갑순이</to>
</note>
<note date=”2008/6/22”>
<from>갑돌이</from>
<to>갑순이</to>
</note>
6) 엔터티 참조(entity reference)
어떤 문자는 XML에서 특별한 의미를 갖는다. 예를 들어 XML 요소 안에 ‘<’ 문자를 사용한다면 XML 파서는 새로운 요소가 시작한다고 해석하여 에러를 발생시키게 될 것이다. 다음 구문은 에러를 발생시킨다.
<message>if salary < 1000000 then</message>
이러한 에러를 피하려면 ‘<’ 문자를 엔터티 참조로 대체해야 한다.
<message>if salary < 1000000 then</message>
XML에서는 5개의 엔터티 참조가 미리 정의되어 있다.
< | < | 작다 |
> | > | 크다 |
& | & | 엠퍼샌드 |
' | ‘ | 홑따옴표 |
" | “ | 쌍따옴표 |
7) 주석
XML에서 주석 구문은 HTML과 유사하다.
<!-- 이것은 주석문입니다 -->
8) 공백 문자
HTML에서 다음과 같이 여러 개의 공백 문자(white space character)는 하나의 공백 문자로 축소된다.
HTML | 안녕하세요? 내 이름은 전병선입니다. |
결과 | 안녕하세요? 내 이름은 전병선입니다. |
그러나 XML에서는 여러 개의 공백 문자는 그대로 유지된다.
HTML | 안녕하세요? 내 이름은 전병선입니다. |
결과 | 안녕하세요? 내 이름은 전병선입니다. |
9) 개행 문자
윈도우 애플리케이션에서 개행 문자는 CR(carriage return)과 LF(line feed)의 결합으로 저장된다. 반면에 유닉스 애플리케이션에서는 LF 문자로만 저장되며, 매킨토시 애플리케이션에서는 CR 문자로만 저장된다. XML에서 개행(new line) 문자는 LF 문자로 저장된다.
3.1.5. XML 요소
XML 요소는 요소의 시작 태그에서 시작하여 끝 태그까지의 모든 것으로, 하나의 요소는 다른 요소나 텍스트 또는 요소와 텍스트의 혼합을 포함할 수 있다. 또한 요소는 애트리뷰트를 가질 수 있다.
<bookstore>
<book category="CHILDREN">
<title lang="en">Harry Potter</title>
<author>J K. Rowling</author>
<year>2005</year>
<price>29.99</price>
</book>
<book category="WEB">
<title lang="en">Learning XML</title>
<author>Erik T. Ray</author>
<year>2003</year>
<price>39.95</price>
</book>
</bookstore>
위의 예에서 <bookstore>와 <book>은 다른 요소를 포함하고 있기 때문에 요소 컨텐츠(element contents)를 갖는다. <author>는 텍스트를 포함하므로 텍스트 컨텐츠(text contents)를 갖는다. 위의 예에서 <book> 요소만 값이 각각 “CHILDREN”과“WEB”인 category란 애트리뷰트를 갖는다.
XML 요소는 다음과 같은 명명 규칙을 따라야 한다.
o 이름은 문자, 숫자, 기타 문자를 포함할 수 있다
o 이름은 숫자나 구두점 문자로 시작할 수 없다
o 이름은 xml 이나 XML, Xml 등으로 시작할 수 없다
o 이름에는 공백 문자를 포함시킬 수 없다
어떤 이름이라도 사용할 수 있으며 예약어는 없다.
이름을 이해하기 쉽게 만드는 것이 좋다. <first_name>, <last_name>와 같이 단어는 밑줄 문자로 연결시킨다. 이름은 가능한 한 짧고 단순한 것이 좋다. 따라서 <the_title_of_the_book> 보다는 <book_title>이 더 낫다. ‘-‘ 문자는 사용하지 않는다. <first-name>이란 이름을 사용한다면 first에서 name을 빼는 것으로 오해할 소지가 있다. 마찬가지로 ‘.’ 문자는 사용하지 않는다. <first.name> 이란 이름을 사용한다면 first 란 객체의 name 이란 속성을 의미하는 것으로 오해할 수 있다. 또한 ‘:’ 문자도 피한다. 콜론 문자는 네임스페이스(namespace)에 사용된다.
XML 요소는 확장 가능하다. 즉, XML 요소는 더 많은 정보를 포함할 수 있도록 확장시킬 수 있다. 다음 XML 예를 생각해보기로 한다.
<note>
<from>갑돌이</from>
<to>갑순이</to>
<body>이번 주말 데이트 잊지 마!</body>
</note>
우리가 위의 XML 다큐먼트로부터 <from>, <to>, 그리고 <body> 요소를 추출하여 다음과 같은 결과를 보여주는 애플케이션을 작성해야 한다고 생각해보자.
메시지 수신 : 갑순이 발신 : 갑돌이 내용 : 이번 주말 데이트 잊지 마! |
그런데 XML 다큐먼트의 저작자가 이 문서에 다음과 같이 여분의 정보를 추가했다고 하자.
<note>
<date>2008-06-22</date>
<from>갑돌이</from>
<to>갑순이</to>
<heading>메시지</heading>
<body>이번 주말 데이트 잊지 마!</body>
</note>
이 경우 기존의 애플리케이션에는 에러가 발생할까? 아니다. 애플리케이션은 아직도 XML 다큐먼트로부터 <from>, <to>, 그리고 <body> 요소를 추출하여 같은 결과를 보여줄 수 있다. XML의 하나의 이점은 애플리케이션을 변경시키지 않고 확장시킬 수 있다는 것이다.
3.1.6. XML 애트리뷰트
HTML에서는 시작 태그에 애트리뷰트를 지정할 수 있다. 애트리뷰트는 요소에 대한 추가적인 정보를 제공한다. <img src=”computer.gif”> 에서 “src” 애트리뷰트는 <img> 요소에 대한 추가적인 정보를 제공한다. XML 요소도 마찬가지로 시작 태그에 애트리뷰트를 지정할 수 있다. 애트리뷰트는 데이터가 아닌 정보를 제공하는데 사용된다. 다음 예에서 파일 타입은 데이터로서는 적당하지 않지만, 소프트웨에가 이 요소를 처리하는데 필요한 정보를 제공한다.
<file type="gif">computer.gif</file>
XML 애트리뷰트는 따옴표로 묶어야 한다. 이때 홑따옴표나 쌍따옴표 어느 것을 사용할 수도 있다. 예를 들어 사람의 성별에 대하여 person 태그는 다음과 같이 작성될 수 있다.
<person sex=”female”>
또는,
<person sex=’female’>
애트리뷰트 값에 쌍따옴표가 포함되어 있다면 다음 예와 같이 홑따옴표로 묶을 수 있다.
<gangster name=’George “Shotgun” Ziegler’>
또는, 엔터티 참조를 사용하여 다음과 같이 표현할 수 있다.
<gangster name=”George "Shotgun" Ziegler”>
애트리뷰트를 사용할 때와 요소를 사용할 때를 판단할 수 있는 규칙은 없다. 다음 두가지 예를 살펴보기로 하자.
첫번째 예:
<person sex=”남자”>
<firstname>병선</firstname>
<lastname>전</lastname>
</person>
두번째 예:
<person>
<sex>남자</sex>
<firstname>병선</firstname>
<lastname>전</lastname>
</person>
첫번째 예에서는 sex는 애트리뷰트이고, 두번째 예에서는 요소이다. 두 코드의 예는 같은 정보를 제공하기 때문에 어느 방법을 사용해도 좋다. 일반적으로 HTML에서는 애트리뷰트를 많이 사용하지만, XML에서는 요소를 사용하는 것이 유리할 때가 많다.
애트리뷰트를 사용할 때 몇가지 문제가 있다.
o 애트리뷰트는 여러 값을 포함할 수 없다
o 애트리뷰트는 트리 구조를 포함할 수 없다
o 애트리뷰트는 쉽게 확장할 수 없다
또한 애트리뷰트는 읽고 유지 보수하기 어렵게 한다. 따라서 데이터에 대해서는 요소를 사용하고, 데이터로서 적당하지 않은 정보에 대해서만 애트리뷰트를 사용하는 것이 좋다.
따라서 다음과 같이 애트리뷰트를 사용하는 것 보다는,
<note year=”2008”, month=”06”, day=”22”>
<date>2008-06-22</date>
<from>갑돌이</from>
<to>갑순이</to>
<heading>메시지</heading>
<body>이번 주말 데이트 잊지 마!</body>
</note>
다음과 같이 요소를 사용하는 것이 바람직하다.
<note>
<date>
<year>2008</year>
<month>06</month>
<day>22</day>
</date>
<from>갑돌이</from>
<to>갑순이</to>
<heading>메시지</heading>
<body>이번 주말 데이트 잊지 마!</body>
</note>
3.1.7. XML 스키마
XML 다큐먼트의 구조를 정의할 때 DTD(document type definition)을 사용할 수 있다. DTD는 유효한 요소와 애트리뷰트 목록으로 XML 다큐먼트의 구조를 정의한다. 다음은 note.dtd 파일명을 갖는 DTD의 예를 보여준다.
<!DOCTYPE note [
<!ELEMENT note (from, to, heading, body)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>
W3C에서는 DTD 대신에 XML 기반의 스키마(schema) 즉, XML 스키마를 지원한다. 다음은 note.xsd 파일명을 갖는 XML 스키마의 예를 보여준다.
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.w3schools.com"
xmlns="http://www.w3schools.com"
elementFormDefault="qualified">
<xs:element name=”note”>
<xs:complexType>
<xs:sequence>
<xs:element name=”from” type=”xs:string”/>
<xs:element name=”to” type=”xs:string”/>
<xs:element name=”heading” type=”xs:string”/>
<xs:element name=”body” type=”xs:string”/>
</xs:sequence>
</xs:complexType>
</xs:element>
XML 스키마는 XML 다큐먼트의 구조를 기술하며, XML 스키마 언어를 XSD(XML schema definition)이라고 한다. 위의 XML스키마 예에서 note 요소는 다른 요소를 포함하기 때문에 복합 타입(complex type)이 된다. from이나 to, heading, body 등의 요소는 다른 요소를 포함하지 않으므로 단순 타입(simple type)이 된다.
XML 다큐먼트는 XML 스키마를 참조할 수 있다. 다음은 note.xsd 라는 파일명을 갖는 XML 스키마를 참조하는 XML 다큐먼트의 예를 보여준다.
<?xml version="1.0"?>
<note
xmlns="http://www.w3schools.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ensoa.co.kr note.xsd">
<from>갑돌이</from>
<to>갑순이</to>
<heading>메시지</heading>
<body>이번 주말 데이트 잊지 마!</body>
</note>
3.1.8. XML DOM
XML DOM(document object model)은 XML 다큐먼트에 접근하고 조작하는 표준 방법을 정의한다. DOM은 XML 다큐먼트를 트리 구조로 간주한다. 모든 요소는 DOM 트리를 통해서 접근할 수 있다. 요소의 컨텐츠(텍스트와 애트리뷰트)는 수정될 수도 있고 삭제될 수 있으며, 새로운 요소가 생성될 수도 있다. 요소와 텍스트, 애트리뷰트는 모두 노드(note)로 간주된다. 다음 예제 코드는 <to> 요소로부터 텍스트를 구하는 예이다.
xmlDoc.getElementsByTagName("to")[0].childNodes[0].nodeValue
위의 예에서
o xmlDoc은 파서(parser)가 생성하는 XML 다큐먼트이고,
o getElementsByTagName(“to”)[0] 은 첫번째 <to> 요소에 접근하며,
o childNodes[0]은 <to> 요소의 첫번째 자식 노드를 가르키며,
o nodeValue는 노드의 값 즉, 텍스트를 가르킨다
3.1.9. XML 네임스페이스
XML에서 요소명은 개발자가 정의한다. 따라서 다른 XML 애플리케이션에서 생성한 XML 다큐먼트가 혼합된다면 이름이 충돌할 수도 있다. 예를 들어 다음 XML 코드는 HTML의 테이블 정보를 표현한다.
<table>
<tr>
<td>사과</td>
<td>바나나</td>
</tr>
</table>
그러나 다음 XML 코드는 가구인 탁자에 대한 정보를 표현한다.
<table>
<name>밥상</name>
<width>300</width>
<length>800</length>
</table>
이들 두 XML 코드가 함께 사용된다면 <table> 이란 요소명이 충돌하게 된다. 모두 <table>이란 요소를 포함하고 있지만 서로 다른 컨텐츠와 의미를 갖는다. 이 경우 XML 파서는 이들 사이의 차이점을 처리하는 방법을 알지 못하게 된다.
XML에서 이름 충돌을 피할 수 있는 가장 손쉬운 방법은 전치사(prefix)를 사용하는 것이다. 다음은 전치사를 사용한 예이다.
<h:table>
<h:tr>
<h:td>사과</h:td>
<h:td>바나나</h:td>
</h:tr>
</h:table>
<f:table>
<f:name>밥상</f:name>
<f:width>300</f:width>
<f:length>800</f:length>
</f:table>
XML에 전치사를 사요알 때 전치사에 대한 네임스페이스(namespace)가 정의되어야 한다. 네임스페이스는 요소의 시작 태그에xmlns 애트리뷰트로 정의한다. 네임스페이스는 다음과 같은 구문을 갖는다.
xmlns:prefix=”URI”
위의 구문에서 URI(Uniform Resource Identifier)는 인터넷 리소스를 식별하는 문자열로서, 가장 일반적인 URI는 인터넷 도메인 주소를 나타내는 URL(Uniform Resource Locator)이며, URN(Universal Resource Name)도 URI의 일종이다.
다음은 네임스페이스를 정의한 예이다.
<root>
<h:table xmlns:h="http://www.w3.org/TR/html4/">
<h:tr>
<h:td>사과</h:td>
<h:td>바나나</h:td>
</h:tr>
</h:table>
<f:table xmlns:f=”http://www.ensoa.co.kr/furniture”>
<f:name>밥상</f:name>
<f:width>300</f:width>
<f:length>800</f:length>
</f:table>
</root>
네임스페이스는 다음과 같이 XML 루트 요소에 정의할 수도 있다.
<root
xmlns:h="http://www.w3.org/TR/html4/"
xmlns:f=”http://www.ensoa.co.kr/furniture”>
<h:table>
<h:tr>
<h:td>사과</h:td>
<h:td>바나나</h:td>
</h:tr>
</h:table>
<f:table>
<f:name>밥상</f:name>
<f:width>300</f:width>
<f:length>800</f:length>
</f:table>
</root>
다음과 같은 구문으로 요소에 디폴트 네임스페이스를 정의하면 모든 자식 요소에 전치사를 붙여줘야 하는 부담에서 벗어날 수 있다.
xmlns=”namespaceURI”
다음은 디폴트 네임스페이스를 사용한 예이다.
<table xmlns="http://www.w3.org/TR/html4/">
<tr>
<td>사과</td>
<td>바나나</td>
</tr>
</table>
<table xmlns=”http://www.ensoa.co.kr/furniture”>
<name>밥상</name>
<width>300</width>
<length>800</length>
</table>
3.1.10. XML 인코딩
XML 다큐먼트는 한글과 같은 비 아스키 문자를 포함할 수 있다. 따라서 XML 다큐먼트를 읽을 때 다음과 같은 인코딩 문제가 발생할 수 있다.
o 텍스트 컨텐츠에 유효하지 않은 문자가 있다
XML 에 비 아스키 문자가 포함되어 있으며, 인코딩이 지정되지 않은 채 파일이 아스키 코드로 저장될 때 발생한다
o 현재 인코딩 방식을 지정된 인코딩 방식으로 전환이 지원되지 않는다
1바이트 인코딩(UTF-8) 방식이 지정된 채 2바이트 유니코드(UTF-16)로 XML 파일이 저장되거나, 2바이트 인코딩(UTF-16)방식이 지정된 채 1바이트인 아스키 코드로 저장될 때 발생한다
이러한 XML 인코딩 문제를 피하기 위해서는 다음 사항에 유의한다.
o 항상 인코딩 애트리뷰트를 사용한다
o 인코딩을 지원하는 에디터를 사용한다
o 에디터가 사용하는 인코딩 방식을 확인한다
o 인코딩 애트리뷰트와 동일한 인코딩을 사용한다
XML 인코딩 애트리뷰트는 다음과 같이 지정한다.
<?xml version="1.0" encoding="UTF-8"?>
인코딩이란 특정한 문자 집합 안의 문자들을 컴퓨터 시스템에서 사용할 목적으로 일정한 범위 안의 정수(코드값)들로 변환하는 방법이다. 여기에는 유니코드 코드 포인트를 8비트 숫자의 집합으로 나타내는 UTF-8이나, 16비트 숫자의 집합으로 나타내는 UTF-16, 그리고 대부분의 일반적인 문자 인코딩들이 포함된다.
UTF-8(8-bit Unicode Transformation Format)은 유니코드를 위한 가변 길이 문자 인코딩 방식 중 하나로, UTF-8 인코딩은 유니코드 한 문자를 나타내기 위해 1바이트에서 4바이트까지를 사용한다. UTF-16(16-bit Unicode Transformation Format)도 유니코드 문자 인코딩 방식의 하나로서, 주로 사용되는 기본 다국어 평면 (BMP, Basic multilingual plane)에 속하는 문자들은 그대로16비트 값으로 인코딩이 되고 그 이상의 문자는 특별히 정해진 방식으로 32비트로 인코딩이 된다.
EUC-KR 인코딩 방식은 유니코드 이전의 완성형 한글을 표현한다. EUC(Extended Unix Code, 확장 유닉스 코드)란 한국어, 중국어, 일본어 문자 전산화에 주로 사용되는 8비트 문자 인코딩 방식이며, EUC-KR은 이 인코딩 방식을 사용하여 한글 등 한국어에서 사용되는 문자를 표현한 것이다. 코드 페이지 949(CP949)는 마이크로소프트 한글 윈도우에서 사용되는 코드 페이지이다.본래는 KSC 5601의 완성형 한글을 표현한 코드 페이지였으나, 확장 완성형 혹은 통합형 한글 코드(Unified Hangul Code)이라는 명칭으로 확장되어 모든 현대 한글을 수용하게 되었다. 마이크로소프트에서는 이 인코딩을 기반 문자 집합 이름인 "ks_c_5601-1987"로 사용하고 있다.
3.2. SOAP(simple object access protocol) 기초
3.2.1. SOAP 개요
SOAP(simple object access protocol)은 분산 환경에서 구조적인 정보를 교환하기 위한 XML 기반의 프로토콜이다. 원칙적으로 SOAP은 트랜스포트 독립적이며, 따라서 HTTP와 JMS, SMTP 또는 FTP 등과 같은 다양한 프로토콜과 조합해서 사용될 수 있다. 그러나 현재로서 가장 일반적인 SOAP 메시지 교환 방식은 HTTP를 통한 것이며, HTTP 프로코콜은 WS-I 기본 프로파일(WS-I Basic Profile) 1.0에 의해서 지원되는 유일한 프로토콜이다.
SOAP는 다음과 같은 특징을 갖는다.
o SOAP은 커뮤니케이션 프로토콜이다
o SOAP은 애플리케이션 사이의 커뮤니케이션을 목적으로 한다
o SOAP은 메시지 전송 형식이다
o SOAP은 인터넷을 통한 커뮤니케이션을 위해 설계되었다
o SOAP은 언어 독립적이다
o SOAP은 XML을 기반으로 한다
o SOAP은 단순하며 확장 가능하다
o SOAP은 방화벽을 피할 수 있게 한다
o SOAP은 W3C 표준이다
SOAP은 2000년 4월에 1.1 버전이 확정되었고, 2003년 5월에 1.2 버전이 발표되었다. 여기에서는 특별한 언급이 없는 한 SOAP 1.1에 대해서 설명한다. 그것은 현재로서는 SOAP 1.2 보다 SOAP 1.1이 훨씬 광범위하게 사용되고 있고, JAX-WS를 사용하여 구현된 웹 서비스 엔드포인트가 디폴트 바인딩으로 SOAP 1.1/HTTP를 사용하고 있기 때문이다.
3.2.2. SOAP 구문
SOAP 메시지는 다음 요소를 포함하는 일반적인 XML 다큐먼트이다.
o Envelope 요소 : XML 다큐먼트를 SOAP 메시지로 식별하게 하는 필수 요소
o Header 요소 : 헤더 정보를 포함하는 0개 이상의 선택 요소
o Body 요소 : 호출 및 응답 정보를 포함하는 하나의 필수 요소
o Fault 요소 : 메시지를 처리하는 동안 발생한 에러에 대한 정보를 제공하는 선택 요소
SOAP 구문 규칙은 다음과 같다.
o SOAP 메시지는 XML을 사용하여 인코딩되어야 한다
o SOAP 메시지는 SOAP Envelope 네임스페이스를 사용해야 한다
o SOAP 메시지는 SOAP Encoding 네임스페이스를 사용해야 한다
o SOAP 메시지는 DTD 참조를 포함하지 않아야 한다
o SOAP 메시지는 XML 처리 명령을 포함하지 않아야 한다
SOAP 메시지의 골격 구조는 다음과 같다.
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"
soap:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding">
<soap:Header>
...
...
</soap:Header>
<soap:Body>
...
...
<soap:Fault>
...
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
3.2.3. SOAP Envelope 요소
SOAP Envelope 요소는 SOAP 메시지의 루트 요소이며, XML 다큐먼트를 SOAP 메시지로 정의한다. Envelope 요소의 xmlns:soap 네임스페이스 애트리뷰트는 다음과 같이 정의된다.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope">
Envelope 요소의 encodingStyle 애트리뷰트는 다큐먼트에서 사용되는 데이터 타입을 정의하기 위해 사용된다. 이 애트리뷰트는 어떤 SOAP 요소에서도 나타날 수 있으며, 요소의 컨텐츠와 모든 자식 요소에 적용된다. SOAP 메시지는 디폴트 인코딩이 없다.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"
soap:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding">
3.2.4. SOAP Header 요소
SOAP Header 요소는 트랜잭션이나 인증과 같이 SOAP 메시지에 관한 애플리케이션에 고유한 정보를 포함한다. Header 요소가 있다면 Envelope 요소의 첫번째 자식 요소가 되어야 한다.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"
soap:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding">
<soap:Header>
<m:Trans xmlns:m="http://www.ensoa.co.kr/transaction/">234</m:Trans>
</soap:Header>
</soap:Envelope>
위의 예에서는 Header 요소는 Trans 자식 요소를 포함하고 있으며, Trans 요소는 값이 1인mustUnderstand 애트리뷰트를 포함하며, Trans 요소의 값은 234이다.
SOAP은 디폴트 네임스페이스("http://schemas.xmlsoap.org/soap/envelope")에 3개의 애트리뷰트를 정의한다. 이들 애트리뷰트에는 actor와 mustUnderstand, 그리고 encodingStyle 특성이 포함된다. SOAP Header에 정의된 애트리뷰트는 수신자가 SOAP 메시지를 처리하는 방법을 정의한다.
SOAP 메시지는 메시지 경로에 따라 서로 다른 엔드포인트(endpoint)를 넘겨줌으로써 송신자로부터 수신자로 이동한다. SOAP메시지의 모든 부분이 SOAP 메시지의 최종 엔드포인트에 전달되어야 하는 것은 아니다. 그보다는 메시지 경로에 있는 하나 이상의 엔드포인트에 전달될 수도 있다.
SOAP actor 애트리뷰트는 Header 요소가 특정한 엔드포인트에 전달되도록 하는데 사용된다. actor 애트리뷰트에는 다음 구문과 같이 URI 값을 지정한다.
soap:actor=”URI”
다음은 actor 애트리뷰트의 사용 예를 보여준다.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"
soap:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding">
<soap:Header>
<m:Trans xmlns:m="http://www.ensoa.co.kr/transaction/"
soap:actor=” http://www.ensoa.co.kr/appml/">234</m:Trans>
</soap:Header>
</soap:Envelope>
SOAP mustUnderstand 애트리뷰트는 헤더 요소를 수신자가 필수적으로 처리해야 하는 지 선택적으로 처리해야 하는 지를 지정하는데 사용된다. Header 요소의 자신 요소에 1이 지정되면 Header를 처리하는 수신자가 요소를 인식해야만 한다는 것을 나타낸다. 수신자가 요소를 인식하지 못한다면 Header 요소를 처리할 때 실패해야 한다. mustUnderstand 애트리뷰트에는 0 또는 1을 지정한다.
soap:mustUnderstand=”0 | 1”
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"
soap:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding">
<soap:Header>
<m:Trans xmlns:m="http://www.ensoa.co.kr/transaction/"
soap:mustUnderstand=”1”>234</m:Trans>
</soap:Header>
</soap:Envelope>
SOAP encodingStyle 특성은 Envelope 요소의 encodingStyle 특성과 동일하다.
3.2.5. SOAP Body 요소
SOAP Body 요소는 메시지의 최종 엔드포인트를 목적지에 전달되어야 하는 실제 SOAP 메시지를 포함한다. SOAP Body 요소의 자신 요소는 네임스페이스가 명시될 수 있다. SOAP은 디폴트 네임스페이스("http://schemas.xmlsoap.org/soap/envelope")에 Body 요소 안에 에러 메시지를 표시하는데 사용되는 SOAP Fault 요소를 정의한다.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"
soap:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding">
<soap:Body>
<m:getPrice xmlns:m="http://www.ensoa.co.kr/prices">
<m:Item>Apples</m:Item>
</m:getPrice>
</soap:Body>
</soap:Envelope>
위의 예에서는 사과의 값을 요청한다. m:getPrice와 m:Item 요소는 애플리케이션에 고유한 요소이며 SOAP 표준의 일부는 아니다. 이 요청에 대하여 SOAP 응답은 다음과 같은 형태를 취한다.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"
soap:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding">
<soap:Body>
<m:getPriceResponse xmlns:m="http://www.ensoa.co.kr/prices">
<m:Price>500</m:Price>
</m:getPriceResponse>
</soap:Body>
</soap:Envelope>
3.2.6. SOAP Fault 요소
SOAP Fault 요소는 SOAP 메시지에 대한 에러 및 상태 정보를 저장하는데 사용된다. SOAP 메시지로부터의 에러 메시지는 Fault 요소에 저장되어 전송된다. Fault 요소는 Body 요소의 자식 노드이며, SOAP 메시지 안에 단 한번 만 나타날 수 있다.
SOAP Fault 요소는 다음과 같은 하위 요소를 갖는다.
하위 요소 | 설명 |
<faultcode> | 에러 코드 |
<faultstring> | 에러 설명 |
<faultactor> | 에러를 발생시킨 액터에 대한 정보 |
<detail> | Body 요소에 관련된 애플리케이션 특정한 에러 정보 |
<faultcode> 요소에 저장되는 에러 코드는 다음과 같이 정의되어 있다.
에러 | 설명 |
VersionMismatch | SOAP Envelope 요소에 잘못된 네임스페이스가 지정됨 |
MustUnderstand | mustUnderstand 특성에 “1”이 지정되어 있는 Header 요소의 자식 요소를 알 수 없음 |
Client | 메시지가 잘못되었거나 부정확한 정보를 포함하고 있음 |
Server | 서버에 문제가 발생하여 메시지를 처리할 수 없음 |
3.2.7. SOAP HTTP 바인딩
HTTP 프로토콜을 사용할 때 HTTP는 TCP/IP 상에 커뮤니케이션한다. HTTP 클라이언트가 TCP를 사용하여 HTTP 서버에 연결되며, 클라이언트 서버에 HTTP 요청 메시지를 보낼 수 있다.
POST /item HTTP/1.1
Host: 192.168.1.1
Content-Type: text/plain
Content-Length: 200
이때 서버는 요청을 처리하고 클라이언트에게 HTTP 응답을 되돌려보낸다. 응답에는 요청 상태를 표시하는 상태 코드가 포함된다.
200 OK
Content-Type: text/plain
Content-Length: 200
위의 예에서 서비스는 성공을 나타내는 상태 코드 200을 반환하고 있다. 만약 서버가 요청을 해독할 수 없다면 다음과 같은 응답을 반환하게 된다.
400 Bad Request
Content-Length: 0
SOAP은 트랜스포트 레이어에 독립적이므로 반드시 HTTP 프로토콜을 사용해야 하는 것은 아니지만, 현재로서 가장 일반적인 SOAP 메시지 교환 방식이 HTTP 프로토콜을 사용하는 하는 것이다. 그러므로 우리는 SOAP 메서드는 SOAP 인코딩 규칙을 준수하는 HTTP 요청/응답으로 생각할 수 있다. 따라서 다음과 같은 공식을 세울 수도 있다.
HTTP + XML = SOAP
이때 SOAP 요청은 HTTP POST이거나 HTTP GET 요청이며, HTTP POST 요청은 Content-Type과 Content-Length 등 적어도2개의 HTTP 헤더를 지정한다.
SOAP 요청/응답의 Content-Type 헤더는 XML 몸체에서 사용하게 될 메시지의 MIME 타입과 문자 인코딩을 정의한다.
Content-Type: MIMETYPE; charset=문자인코딩
Content-Type 헤더의 예는 다음과 같다.
POST /item HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
SOAP 요청/응답의 Content-Length 헤더에는 요청 또는 응답 몸체의 바이트 수를 지정한다.
Content-Length: 바이트수
POST /item HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 250
다음 예는 getStockPrice 요청을 서버에 전송한다. 요청에는 StockName 매개변수를 가지며, Price 매개변수가 응답에 반환된다. 이 기능의 네임스페이스는 “http://localhost/stock” 주소에 저장된다.
POST /stock HTTP/1.1
Host: localhost
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 250
<?xml version=”1.0”?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"
soap:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding">
<soap:Body xmlns:m="http://localhost/stock">
<m:getStockPrice>
<m:StockName>PC</m:StockName>
</m:getStockPrice>
</soap:Body>
</soap:Envelope>
위의 요청에 대한 SOAP 응답은 다음과 같다.
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 250
<?xml version=”1.0”?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope"
soap:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding">
<soap:Body xmlns:m="http://localhost/stock">
<m:getStockPriceResponse>
<m:Price>2000000</m:Price>
</m:getStockPriceResponse>
</soap:Body>
</soap:Envelope>
3.3. WSDL과 UDDI 기초
3.3.1. WSDL 개요
WSDL(Web Services Description Language)는 웹 서비스와 접근 방법을 기술하는 XML 기반의 언어이다.
o WSDL은 XML로 작성된다
o WSDL은 XML 다큐먼트이다
o WSDL은 웹 서비스를 기술하는데 사용된다
o WSDL은 웹 서비스의 위치와 웹 서비스가 제공하는 오퍼레이션을 명시한다
o WSDL은 아직 W3C 표준은 아니다
WSDL 1.1은 2001년 5월에 W3C Note로 출판되었으며, 2002년 7월에 WSDL 1.2가 Working Draft로 출판되었지만 Recommendation 되지는 못하였다. 가장 최신 버전인 WSDL 2.0은 Candidate Recommendation 상태이다. 여기에서는 특별한 언급이 없는 한WSDL 1.0에 대해서 설명한다. 그것은 JAX-WS 2.0의 핵심 컴포넌트가 WSDL 1.1과 Java 사이를 맵핑하고 있으며, WSDL 2.0에 대해서는 맵핑이 정의되어 있지 않기 때문이다.
3.3.2. WSDL 다큐먼트 구조
WSDL 다큐먼트는 단순한 XML 다큐먼트로서 웹 서비스를 기술하는 정의 집합(set of definition to describe a web service)을 포함한다.
WSDL 다큐먼트는 다음과 같은 요소를 사용하여 웹 서비스를 기술한다.
요소 | 정의 |
<portType> | 웹 서비스가 수행하는 오퍼레이션 |
<message> | 웹 서비스가 사용하는 메시지 |
<types> | 웹 서비스가 사용하는 데이터 타입 |
<binding> | 웹 서비스가 사용하는 커뮤니케이션 프로토콜 |
<portType> 요소는 가장 중요한 WSDL 요소로서, 웹 서비스와 웹 서비스가 수행하는 오퍼레이션, 그리고 포함되는 메시지를 정의한다. <portType> 요소는 전통적인 프로그래밍 언어에서 함수 라이브러리나 모듈, 클래스와 유사하다. <message> 요소는 오퍼레이션의 데이터 요소를 정의한다. 각 메시지는 하나 이상의 파트(part)로 구성될 수 있다. 파트는 전통적인 프로그래밍 언어에서 함수의 매개변수와 유사하다. <types> 요소는 웹 서비스가 사용하는 데이터 타입을 정의한다. 플랫폼 중립성을 극대화하기 위해 XML 스키마 구문을 사용하여 데이터 타입을 정의한다. <binding> 요소는 각 포트의 메시지 형식과 프로토콜을 상세히 정의한다.
WSDL 다큐먼트의 주요 구조는 다음과 같다.
<definitions>
<types>
타입 정의…
</types>
<message>
메시지 정의...
</message>
<portType>
포트 정의...
</portType>
<binding>
바인딩 정의…
</binding>
</definitions>
WSDL 다큐먼트는 확장 요소(extension element)나 서비스 요소(service element)와 같은 다른 요소를 포함하여 하나의 WSDL다큐먼트에 여러 개의 웹 서비스 정의를 함께 묶을 수 있다.
다음은 WSDL 다큐먼트의 간단한 예이다.
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
위의 예에서 <portType> 요소는 포트 이름으로 glossaryTerms을, 그리고 오퍼레이션 이름으로 getTerm을 정의한다. getTerm오퍼레이션은 getTermRequest라는 입력 메시지와 getTermResponse라는 출력 메시지를 갖는다. <message> 요소는 각 메시지의 파트 및 관련된 데이터 타입을 정의한다. 전통적인 프로그래밍에 비교한다면 glossaryTerms 는 함수 라이브러리가 되고, getTerm은 입력 매개변수로 getTermRequest와 반환 타입으로 getTermResponse를 갖는 함수가 된다.
3.3.3. WSDL 포트
WSDL 포트(port)는 웹 서비스가 노출하는 인터페이스를 기술한다. 앞에서 언급한 바와 같이 <portType> 요소는 가장 중요한 WSDL 요소로서, 웹 서비스와 웹 서비스가 수행하는 오퍼레이션, 그리고 포함되는 메시지를 정의한다. 포트는 웹 서비스와의 연결 점(connection point)를 정의한다.
WSDL에서 가장 일반적인 오퍼레이션 타입(operation type)은 요청-응답(request-response)이지만, WSDL은 다음과 같은 4개의 타입을 정의한다.
포트 타입 | 정의 |
단방향(one-way) | 오퍼레이션은 메시지를 받을 수는 있지만 응답을 반환하지는 않는다 |
요청-응답(reques-response) | 오퍼레이션은 메시지를 받으며 응답을 반환한다 |
응답 청구(solicit-response) | 오퍼레이션은 요청을 보낼 수 잇으며 응답을 기다린다 |
알림(notfication) | 오퍼레이션이 메시지를 보낼 수 있지만 응답을 기다리지는 않는다 |
단방향(one-way) 오퍼레이션의 예는 다음과 같다.
<message name="newTermValues">
<part name="term" type="xs:string"/>
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="setTerm">
<input name="newTerm" message="newTermValues"/>
</operation>
</portType >
위의 예에서 glossaryTerms 포트는 setTerm이라는 단방향 오퍼레이션을 정의한다. setTerm 오퍼레이션은 term과 value 입력 매개변수를 갖는 newTermsValues 메시지를 사용하여 새로운 용어집 메시지의 입력을 허용한다. 그러나 오퍼레이션에 응답을 정의하지는 않고 있다.
요청-응답(reques-response) 오퍼레이션의 예는 다음과 같다.
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
위의 예에서 glossaryTerms 포트는 getTerm이라는 요청-응답 오퍼레이션을 정의한다. getTerm 오퍼레이션은 term 매개변수를 갖는 getTermRequest 요청 메시지를 요구하며, value라는 매개변수를 갖는 getTermResponse 응답 메시지를 반환하고 있다.
3.3.4. WSDL 바인딩
WSDL 바인딩(bindings)는 웹 서비스의 메시지 형식과 프로토콜을 상세히 정의한다
다음 요청-응답 오퍼레이션은 SOAP에 바인딩하는 예를 보여준다.
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
<binding type="glossaryTerms" name="b1">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<operation>
<soap:operation soapAction="http://localhost/getTerm"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<binding> 요소는 두개의 애트리뷰트를 갖는다. name 애트리뷰트는 바인딩 이름을 정의하며, type 애트리뷰트는 바인딩 포트를 가르킨다. 위의 예에서는 바인딩 이름은 b1이고, 바인딩 포트는 glossaryTerms 포트가 된다.
<soap:binding> 요소도 두개의 애트리뷰트를 갖는다. style 애트리뷰트는 “rpc”이거나 “document” 일 수 있다. 위의 예에서는document가 사용되고 있다. transport 애트리뷰트는 사용할 SOAP 프로코콜을 정의한다. 위의 예에서는 HTTP가 사용된다.
<operation> 요소는 포트가 노출하는 각 오퍼레이션을 정의한다. 각 오퍼레이션에 대하여 대응되는 SOAP 액션(action)을 정의해야 한다. 또한 입출력이 인코딩되는 방법도 지정해야 한다. 위의 예에서는 literal이 사용되고 있다.
3.3.5. UDDI 기초
UDDI(Universal Description, Discovery and Integration)는 비즈니스가 웹 서비스를 등록하고 검색할 수 있는 플랫폼 독립적인 디렉터리 서비스 프레임워크다.
o UDDI는 웹 서비스에 대한 정보를 저장하고 있는 디렉터리다
o UDDI는 WSDL로 기술된 웹 서비스 인터페이스의 디렉터리다
o UDDI는 SOAP을 통해 커뮤니케이션한다
UDDI는 XML, HTTP, DNS 프로토콜과 같은 W3C와 IETF 인터넷 표준을 사용하며, WSDL을 사용하여 웹 서비스 인터페이스를 기술한다. 이와함께 SOAP를 채택하여 이기종 플랫폼 프로그래밍 기능을 제공한다.
기본은 16MB, 64bit에서는 64MB임
