ajax로 검색한 결과 :: 시소커뮤니티[SSISO Community]

정치	경제
문화	칼럼
비디오게임	스포츠
핫이슈	TV
포토	온라인게임
PC게임	에뮬게임
라이프	사람들
유머	만화애니
방송	1
1	1
1	1
1	1
1	1
1

ajax로 검색한 결과

등록일:2008-03-20 10:20:52
작성자:

제목:XML과 웹 서비스, 자바로 길들이기

XML과 웹 서비스는 웹 2.0 그 자체라고 말할 수 있을 정도로 중요한 개념이다. 이미 XML은 개발자들 사이에서 널리 알려져 있지만, 아직도 파고들면 들수록 참으로 알듯 모를 듯한 면도 많다. XML/ 웹 서비스와 플랫폼의 독립성을 공유하는 자바를 통해서 그 방법을 찾아보자.

XML 예쁘게 보여주기

XML은 우리에게 어떤 모습으로 드러나 있을까? 크게 두 가지다. 하나는 웹에 공개되어 웹 브라우저로 보게 되거나, 또 하나는 파일로 저장되어 텍스트 에디터(XML을 열 수 있는 애플리케이션)로 확인할 수가 있다. 이렇게 XML은 물리적인 형태를 가질 수 있지만, XML 문서가 전달하는 의미는 그 형태와는 사실 독립적이다. 즉 XML Information Set(이하 XML 인포셋)이라는 추상적인 의미를 실체화하는 프레젠테이션으로 XML 파일이 존재하는 셈이다.

<그림 1> XML 인포셋과 XML 문서

결과적으로 DOM과 SAX와 같이 자바로 XML 문서를 파싱하는 경우 자바에서는 바로 이 XML 인포셋을 다루게 되는 셈이다. 그렇다면 자바에서 XML 문서를 만드는 경우는 어떨까? 사실 형태를 가진 존재일수록 그 형태가 아름답게 표현되면 보기가 좋은 것은 당연하다. XML도 마찬가지다.

<그림 2>기분 좋은 XML 표현과 짜증을 유발하는 XML 표현

위의 두 가지 XML 표현 가운데 어느 쪽이 더 보기 좋을까? 물어 보기가 쑥스러울 정도로 답은 자명하다. 그렇다고 XML 출력 자체가 그렇게 간단한 것은 아니다. 더욱 그 출력물을 예쁘게 다듬는 것도 쉽지가 않다. XML 출력은 JDK 5 이전에는 XML 쓰기(Serialize)에 대한 표준 API가 없어서 흔히 JAXP(Java API for XML Processing)의 Transformer를 쓰거나 비표준 라이브러리(대표적인 것이 Apache Xerces의 XMLSerializer)를 사용했었다. 여기에 들여쓰기와 같은 XML 출력 관련 옵션을 줄 수도 있었다. 하지만 JDK 5 이상을 사용할 경우, 정확히는 JAXP 1.3의 DOM Level 3를 쓴다면 간단하면서도 표준적인 옵션으로 예쁜 모양의 XML 출력이 가능하다. 그럼 XML을 출력하는 방법에 대해 살펴보면 다음과 같다.

가) JDK 5나 JAXP 1.3을 쓰는 경우

DOMImplementation implementation= DOMImplementationRegistry.
newInstance().getDOMImplementation(“XML 3.0”);DOM ImplementationLS feature = (DOMImplementationLS) implementation.
getFeature(“LS”,”3.0”);LSSerializer serializer = feature.create LSSerializer();LSOutput output = feature.createLSOutput(); output.setByteStream(System.out);serializer.write(doc, output)

위의 예제 코드는 org.w3c.dom.Node 타입의 doc을 System.out, 즉 콘솔 화면으로 출력한다. LSSerializer를 얻어오는 앞 3줄이 좀 복잡해보일 수 있지만, 그 이후로는 매우 직관적이고 간편하게 Node의 출력을 돕는다.

나) 사정상 JDK 5나 JAXP 1.3 이상을 쓸 수 없다면 차선책으로 javax.xml.transform.Transformer를 사용한다.

TransformerFactory transformerFactory = TransformerFactory.
newInstance();Transformer transformer = transformerFactory.
newTransformer();transformer.transform(new DOMSource(node), new StreamResult(System.out));

위의 코드 또한 하는 일은 가)의 코드와 똑같다. 팩토리에서 Transformer를 얻어 오는 부분은 가)의 LSSerializer를 얻어 오는 과정보다 간단해 보이지만, 최종적으로 출력하는 부분에 무려 2 개의 레퍼(Wrapper, DOMSource, StreamResult)가 쓰이게 돼 무겁다는 느낌을 지울 수 없다.

그렇다면, 앞에서 살펴본 XML 출력 로직에 성형 수술(?)을 하고자 할 경우 어떻게 하면 좋을까?

가)의 경우는 serializer.getDomConfig().setParameter( “format-pretty-print”, Boolean.TRUE); 를 serializer. write 하기 전에 설정하면 된다.

나)의 경우는 transformer.setOutputProperty“( indent”,“ yes”); 를 transformer.transform하기 전에 설정하면 된다. 이론은 이렇지만, 실제로는 고려해야 할 문제가 몇 가지 더 있다.

가)의 경우 안타깝게도 JAXP 1.3 스펙상 formatpretty-print 옵션의 지원이 필수가 아니어서 기본적으로 는 지원이 되지 않고 있는데, 필자가 제안한 패치(https:// jaxp.dev.java.net/issues/show_bug.cgi?id=6)가 JDK 6(빌드 92)부터 적용되어 사용 가능해졌다. (JDK 5에의 적용 여부는 불투명하다)

JDK에 내장된 JAXP를 쓰지 않고 Apache Xerces와 같은 별도의 JAXP 구현체를 쓰는 경우에는 Xerces 2.8.0 이후로 이 패치가 적용되어 format-pretty-print의 옵션 사용이 가능하다. 나)의 경우에는 XSLT 1.0 스펙의 16장 Output(http://www.w3.org/TR/xslt

)에서 정의하는 다양한 설정을 setOutputProperty로 설정이 가능하므로 참고하기 바란다.

JAXP 1.4

JAXB와 같은 XML 바인딩 솔루션이 나와 우리를 편하게 해주고 있지만, 자바의 XML 처리에 있어 가장 밑단에 자리 잡은 표준인 JAXP 또한 여전히 직접 XML을 다루어야 할 때 필요하다.

현재 최신 버전인 1.3이 JDK 5에 탑재되어 있고, JDK 1.4와도 함께 쓸 수 있다. JAXP 1.3은 자바에서 정의하지 않은 XML 스키마 타입을 추가하고, 앞에서 살펴본 DOM L3와 XPath 등을 지원하는 등 기능면에서 크게 향상되었다.

JDK 6에 내장될 JAXP 1.4는 이러한 JAXP 1.3의 높은 기능성을 바탕으로 풀(pull) 방식의 XML 처리 API인 StAX(St reaming API for XML)을 포함했다. 이제 자바도 .NET과 대등한 수준, 즉 인메모리 인포셋(DOM)-푸시(SAX)-풀(StAX)의 삼박자를 모두 갖추게 된 셈이다. JAXP 1.4 RI의 개발은 java.net에서 오픈 소스로 이루어지고 있으며, https://jaxp-sources.dev.java.net/ 에서 소스와 매주 배포되는 바이너리를 받을 수 있다. 아직 스펙이 최종 승인된 상태는 아니지만, JAXP 1.4를 미리 경험해보고 싶다면 JDK6(https://jdk6. dev.java.net/ 에서 최신 빌드를 받을 수 있다)의 사용을 권한다.

도대체 웹 서비스는 언제 뜨는 거야?

웹 개발자라면 듣기 싫어도 들을 수밖에 없는 말이 있다. 바로 웹 서비스란 단어다. 웹 서비스와 관련된 기술의 뿌리를 파고들면 XML과 거의 어깨를 나란히 하고 있다는 느낌을 지을 수가 없다.

필자는 기이하리만치 신기술과 관련된 책을 몇 번 번역한 경험이 있다. 가장 먼저 번역한 책이 <자바 서블릿 프로그래밍>의 개정판(2001년 출시)으로 책의 후반부 내용은 완전히 새로운 것이었다. 그 뒤를 이어 <자바 웹 서비스>(2002년 출시)도 한참 웹 서비스 바람이 거세게 불 때 번역하게 되었다. 이때만 해도 SOA(Service Oriented Architecture)의 바람이 일기 시작할 무렵이었다.(가장 최근에 번역한 <ajax 입문="">도 국내에서 처음 출간된 ajax 책이다)

돌이켜보면 필자의 번역작업도 벌써 4년 전의 일이 되었다. 반면에 IT기업에서 만큼은 사정이 매우 다른 것 같다. ESB(Enterprise Service Bus) 개념이 정립되어 가다가도 한편으로는 웹 서비스 기반의 SOA가 자리 잡아 가는 분위기다. 특히 아마존과 구글 등과 달리 국내에서는 아직도 웹 서비스의 확산이 매우 더딘 편이다.

필자의 개인적인 생각도 이와 다르지 않다. XML 개념이 나온 시점이 1999년이다. 그리고 국내 IT시장에 2003년 방카슈랑스를 통해 XML 기반의 기업 간 대형 통합 시스템이 등장했다. 기업 SOA도 이제 겨우 시작 단계에 불과한 편이다. 민간 SOA는 아마도 2007년 하반기에나 들어서야 물꼬가 트일 것이라는 생각이 든다.

IT 기업의 웹 서비스 기술 요구 수준은 전문가들의 예측대로 신뢰 가능 메시징(Reliable Messaging)과 보안(Security)를 기본으로 하고 있다. 뒤이어 트랜잭션까지 요구하게 되겠지만, 서비스라는 개념 자체가 매우 큰 업무 단위에서 서비스들을 한군데로 묶어 트랜잭션이 발생 가능하도록 하려면 아직도 시간이 필요할 것 같다.

이런 사정들을 놓고 볼 때 신뢰 가능 메시징이나 보안과 같은 일차적 진입 장벽은 아직 필수 요소가 아닌 것처럼 보이고, 앞으로 점차 그 필요성을 느낄 것으로 보인다. 따라서 현재 안정적으로 쓸 수 있는 웹 서비스 기술(자바와.NET)은 이러한 시장의 요구를 충분히 들어 줄 수 있는 수준에 올라 있다.

그리고 매우 다행스럽고도 기대가 되는 일이 있다. 이미 WS-I (Web Services Interoperability Organization)이라는 웹 서비스 상호운영성을 위한 공동체의 활동을 통해 SOAP과 WSDL의 사용에 대한 상호운영성을 확보한 일이다. 또 이 같은 바탕위에 WS-Addressing, WS-Reliable Messaging, WS-Security 등의 WS-*(스타) 스펙에 대한 상호운영성을 위해 웹 서비스계의 양대 산맥인 자바와.NET의 대표주자인 썬과 MS가 서로 손을 잡은 대목은 매우 고무적인 일이다. 서로 WSIT(Web Services Interope rability Technologies)와 WCF(Windows Communi cation Foundation) 기술의 상호 운영성 확보를 위한 노력을 함께 기울이고 있다. 2006년 8월 현재 이들 양사의 진행 상황을 정리하면 다음과 같다.

ajax>

<표 1> WSIT과 WCF의 WS-* 상호운영성 테스트 상황

아직까지는 상호운영성면에서 초기 단계에 불과해 WCF와 WSIT도 한창 개발 중에 있다. WCF는 윈도 비스타에 내장되므로 내년 1월 전에는 마무리되어야 하고, WSIT도 같은 시기에 완성판이 나와 서로 보조를 맞출 것으로 예상된다.

WSIT과 WCF의 공조가 서로 중요한 이유는, 썬과 MS가 각각 자바와 .NET의 차세대 플랫폼에 단순히 웹 서비스 기초 기술(SOAP과 WSDL)뿐만 아니라 고급 기술(WS-*)까지 기본으로 제공하여 사용자의 응용폭을 현실적으로 늘려갈 것이라는 기대가 깔려 있기 때문이다. WSIT이 JDK 6에 내장될지는 아직 정확히 알려져 있지는 않지만, 머지않아 자바와 윈도는 웹 서비스로 서로 완벽하게 묶일 수 있게 될 것으로 보인다.

JWS 2.0은 WSIT을 올리기 위한 기반 프레임워크로, JAX-WS, JAXB, SAAJ 등을 포함한다. Java SE 6에는 JWS 2.0이 들어 있고, .NET 프레임워크 3.0에도 WCF가 들어 있다. 구체적으로 말하면, 현재도 Windows 2003이나 XP에 .NET Framework 3.0을 깔면 WCF를 쓸 수 있다.

또 Java SE 5에 WSIT Milestone Release 1(https://wsit.dev.java.net/ 에서 받을 수 있다)을 설치하면 WSIT을 쓸 수 있다. 다만 WSIT 기반 서비스를 만들고 띄우려면 톰켓이나 글래스피시(GlassFish)와 같은 웹 컨테이너가 필요하다. 이전에 공개된 WCF 버전(3월 CTP나 6월 CTP)와 WSIT는 테스트되지 않은 상태이므로 WCF의 svcutil.exe 버전이 3.0.4011.0 인지를 확인해야 한다.

WSIT의 튜토리얼(http://java.sun.com/webser vices/interop/reference/tutorial/doc/index.html)을 보면 당장 WSIT이 무엇을 가장 급선무로 생각하는지를 알 수 있다. 바로 MTOM을 통한 메시지 최적화, 신뢰 가능한 메시징, 보안, 툴 지원(넷빈즈) 등의 항목들이 필요함을 알 수가 있다.

현재 우리들의 메신저 사용 패턴을 보면 (툴 지원을 제외하고 ) 위의 항목들이 거의 들어맞는 것을 볼 수가 있다. 메신저로 텍스트를 주고받기도 하지만, 이미지나 워드 문서같은 덩치 큰 바이너리 파일들도 곧잘 주고받는다. 따라서 기존의 SOAP 통신에서 바이너리를 텍스트로 변환하는 일명 Base64 방식의 인코딩-디코딩은 매우 비효율적이다.

MTOM은 XOP(XML Optimized Packaging)이라는 기술을 기반으로 SOAP 메시지 안에 들어있는 바이너리 데이터를 텍스트 양 쪽에서 모두 지원하므로 이제 첨부 파일이 들어간 웹 서비스 처리는 더 이상 비호환성의 늪에 빠지지 않아도 된다.

메신저를 쓰다 보면 가끔 상대방과의 연결이 끊겨 방금 쳤던 텍스트가 상대방에게 보내지지 않았다는 메시지를 보게 된다. 그러면 보통 텍스트를 그대로 다시 쳐서 상대방과의 대화를 계속하게 되는데, 이럴 경우 신뢰 가능한 메시징이 필요하다.

메신저로 보내는 메시지를 중간에 누군가가 가로채서 볼 수 있다면 정말 위험천만한 일일 것이다. 물론 SSL을 써서 전송층 전체에 보안을 걸 수도 있고, 신용카드와 같은 민감한 개인 정보 부분만 걸러서 보안을 강화할 수도 있다. 특히 돈과 관련된 사항은 필수적일 수밖에 없다.

<그림 3> 자바 플랫폼과 윈도 플랫폼의 웹 서비스 통합

어떤 웹 서비스에 대한 MTOM, WS-RM, WS-Security 등의 설정은 웹 서비스 플랫폼 나름대로(즉 비표준적으로) 할 수도 있지만(사실 과거에는 그래 왔다), WS-Policy라는 이름의 표준 스펙이 나오면서 이를 기반으로 WS-* 사용에 대한 설정을 표준적으로 할 수 있는 길이 열려 많은 웹 서비스 플랫폼들이 지원을 시작하고 있다.

하지만 WS-SecurityPolicy와 같은 스펙은 매우 복잡하여 사람이 직접 그 설정을 XML 문서로 작성하기에는 부담이 커서, 그 일을 도와주는 툴이 매우 유용하다. 넷빈즈 5.5(현재 베타 2)는 WSIT 플러그인을 지원하여 WSIT 기반 클라이언트/서버 개발 시에 Policy 파일을 직접 작성하지 않고도 WS-SecurityPolicy의 설정을 가능하도록 돕고 있다.

WSIT에 대한 구체적인 논의는 이 컬럼의 범위를 넘어서므로, 다음 기회로 미루기로 하고, 2007년 민간 IT기업의 웹 서비스 흥행을 위한 프리-프로덕션에 대해 살펴보면 다음과 같다.

● 가정: (일반인이나 중소기업, 즉 일종의 롱 테일 대상) 웹 서비스를 제공하는 사업을 한다.
● 하드웨어 인프라 준비: 적절한 규모의 웹 애플리케이션 서버 호스팅을 마련한다.
● 소프트웨어 플랫폼 준비: 오픈 소스 무료 유닉스 계열(리눅스나 오픈솔라리스 등) + JDK 6 + GlassFish v2 + WSIT
● 서비스 개발: 넷빈즈 5.5
● 고객 대상 API 공개: WSDL + Policy. 자바와 .NET으로 클라이언트작성 예제 제공.

지금부터 준비한다면 올해 안으로는 베타 서비스 개시가 가능하고, 내년 상반기에 베타 서비스를 운영하면서 안정화를 통해 하반기에 정착시키는 일이 가능하지 않을까 희망해본다(비즈니스 모델이 궁금하다면 아마존 웹 서비스 http://aws.amazon.com 을 참고하기 바란다).

대관절 웹 서비스는 언제 뜨는 거야?

필자가 올 상반기에 IBM의 ESB 담당자와 얘기를 나눈 적이 있는데, 올 하반기부터 ESB가 확실히 뜰 것이라는 말을 들었다. 그런데 바로 그 예언(?)이 실현되었다. 이미 굵직굵직한 차세대 통합 프로젝트들이 ESB을 필수 항목으로 요구하기 시작했다. 이 추세는 SOA의 구현에 있어 ESB가 메시지라는 피를 돌게 하는 심장의 역할을 할 것임을 뜻이기도 한다. BEA, IBM, Oracle 등 그간 이 분야에 많은 투자를 했던 회사들에게는 기회임이 분명하지만, ESB는 매우 광범위한 영역을 다루는 기술이다 보니 기본적으로 다음과 같은 요소들이 매우 중요하다.

● 웹 서비스: 앞에서도 언급했듯이 WS-Policy를 통한 WS-* 지원은 기초 중의 기초이다. ESB가 실어 나르는 메시지의 소비와 공급이 대부분 웹 서비스 클라이언트와 서버이고, 서비스간의 조율을 맡은 ESB는 웹 서비스 요소들과 긴밀히 상호작용해야 한다.

● XML: ESB에서 다루는 메시지는 라우팅(routing)과 변환(Transformation)의 대상이다. 메시지 포멧에는 여러 선택지가 있지만, 현재 가장 우세한 것은 역시 XML이다. 이는 텍스트 기반의 플랫폼 독립성이 결정적이었겠지만,
XQuery와 같은 XML 질의 언어가 빠르게 진화하고 있어 정보 섭렵의 강력함이 점차 기존 프로그래밍 언어나 SQL을 압도할 수준으로 성장했기 때문이다. 현재 자바는 XPath 1.0과 XSLT 1.0 정도를 지원하지만, 조만간 XPath 2.0에 기반한 XQuery 1.0과 XSLT 2.0의 사용이 ESB의 주요 기능으로 자리 잡을 것으로 보인다.

● 툴: ESB는 개발, 배치, 관리 포인트가 엄청나게 많다. 그걸 다 주먹구구식으로 한다면 그야말로 재앙일 것이다. 실제 많은 ESB 솔루션들이 전면에 내세우는 장점으로 자신들의 툴을 꼽고, ESB를 사용하려는 사람들의 가장 큰 관심사도 사실 툴 지원이다. 그리고 무엇보다도 오픈 소스 ESB 프로젝트들도 발걸음이 빨라졌다. 독자들도 시간이 나는대로 다음 내용을 꼭 참고하기 바란다.

아파치 ServiceMix http://www.servicemix.org/site/home.html 3.0 M2ObjectWeb Celtix http://forge.objectweb.org/projects/celtix/ 1.0 FCS
썬 OpenESB https://open-esb.dev.java.net/ Build060512_3
Mule http://mule.codehaus.org/ 1.3-rc4

오픈 소스 ESB들의 문제라면 아무래도 부족한 문서와 툴 지원이 되겠는데, 바로 여기에 틈새 시장이 있다고 하겠다. 또한 웹 서비스와 XML 관련 전문가에 대한 수요와 가치도 올라갈 것으로 보여, 다음과 같은 제안을 하고 싶다. Java EE 5, 특히 JWS 2.0과 WSIT 기반의 웹 서비스 설계, 구축, 관리에 대한 전문적인 기술을 제공하는 컨설팅이 필요하다.

XQuery 1.0 프로세서가 필요하다. 시중에 오픈 소스도 있지만 성능과 일부 기능이 빠져 있고 상용 완전판이 공존한다. 따라서 고성능과 부가 기능을 제공하는 XQuery 프로세서의 제공과 XQuery 작성 컨설팅이 필요하다.

상용 ESB에 대한 대안으로 오픈 소스 ESB를 선택할 수 있도록 지원해야 한다. 구축, 배치, 관리에 대한 컨설팅과 더불어 툴 제공이 가치가 있다.

괴물의 흥행 돌풍, 그 작용과 반작용

영화“괴물”이 개봉 21일 만에 천만 관객을 돌파했다는 소식이 마냥 기쁘게만 들리지 않는 데에는, 초대형 영화의 성공의 이면에 고사당하는 작은 영화들이 있기 때문이다.

시장 논리로만으로 풀어갈 수 없는 것이 바로 인간 사회이고, 자본주의하에서도 정부의 조정은 끊임없는 논란 속에 이어져왔다. 스크린 쿼터 문제만 해도 그렇다. 시장 지배력이 취약한 한국 영화의 앞날이 기로에 서 있다는 우려가 늘고 있다. 이런 영화시장의 현실은 스크린 쿼터 같은 보호막조차 없는 중소 소프트웨어 회사의 몰락을 망연자실 지켜 봐야 하는 우리들과 크게 다르지 않다는 생각이 든다.

과연 오픈 소스와 웹 2.0이 이런 열악한 상황을 타개할 길을 열어 줄지는 아직 확실하지 않다. 다만, 위기를 기회로 삼는 지혜가 빛을 발할 것이라는 희망을 가져보자.

XML과 웹 서비스는 여전히 미지의 영역으로 새로운 개척자를 기다리고 있다. @