한빛출판네트워크

저자: 이아스님 (http://iasandcb.hihome.com

자바 웹 서비스의 분위기

엔시즈(전에는 인프라이즈 코리아였다는군요)에서 소닉 소프트웨어의 소닉MQ(JMS 서버)와 XQ(웹 서비스 버스)를 내놓았습니다. 마침 제가 요새 오라일리의 자바 웹 서비스를 번역하는 관계로 겸사겸사 솔루션 소개장에 다녀왔습니다. 자바 웹 서비스의 저자중 한명인 데이빗 채플(David A. Chappell)씨는 소닉 소프트웨어의 부사장 겸 수석 기술 이벤졀리스트입니다. 우연하게도 데이빗 채플과 그분과 함께 일하는 분(연사 이름은 까먹었습니다... 죄송...)이 멀리 미국에서부터 날아오셔서 강연을 맡아주셨습니다.

주제는 "안정적인 웹 서비스를 위한 서비스 지향 아키텍처 구축"이었는데요, 그만큼 아직까지 웹 서비스는 "불안정함-시기상조"라는 인상이 강하다는 느낌도 받았습니다. 거기에 SOA(Service Oriented Architecture)도 무척 생소하지요.

서비스 요청자(requestor) + 서비스 제공자(provider) + 서비스 중개자(broker)

이러한 삼위일체식의 구성이 SOA의 기본입니다. 요청자는 보통 클라이언트(client)라고도 불리며, 중개자는 브로커라는 말보다는 레지스트리(registry), 디렉토리(directory)라는 말로 더 유명합니다.

재미있는 것은 SOA의 정점을 이루고 있는 각각의 요소들이 네트워크 상으로 연결만 되어 있을 뿐 각각 서로 다른 컴퓨터 자원에서 돌아간다는 점입니다. 요청자-제공자-중개자 개념은 결코 어떤 사람(자연인)만을 가리키는 것은 아니고, 법인(회사같은 조직), 소프트웨어(컴포넌트나 컨테이너), 심지어는 역할(role)을 나타낼 수도 있는 무척 광범위한(comprehensive) 용어입니다.

SOA에는 앞에 분산(distributed)라는 수식어가 더 붙기도 하는데, 이는 그만큼 SOA를 따르는 웹 서비스가 분산 처리의 21세기적 발현임을 시사합니다. 그동안 많은 분산 처리 솔루션(자바의 RMI나 OMG의 코바)이 나왔지만, 각각의 고유한 OOP기반의 컴포넌트라는 태생적인 한계는 결국 하이브리드(다종간)한 사용에 치명적이었고, 그것들을 사용하는 기업에 있어서는 TCO를 비롯하여 결코 충분히 생산적이지 않았다는 것이 DSOA측의 주장입니다. (그렇다고 객체지향적인 패러다임이 가져다 준 설계 및 유지보수 용이성을 간과하는 것은 아니지요.)

아무튼 웹 서비스 진영(IBM이 시작하여 MS와 썬까지 거들고 있는)의 이야기는 자바 컴포넌트(RMI)건 MS 컨포넌트(COM, DCOM)건 OMG CORBA건 네트워크 거미줄에 엉켜있는 수많은 애플리케이션 간의 상호운영성(interoperability)를 XML 기반의 메시징(messaging)이 처리할 것이라는 야무진 계획에 근거합니다.

원래 자바(와 같은 객체지향 개발환경)에서는 오브젝트의 메소드를 호출하는 행위도 메시징이라고 부를 정도로 메시징은 그리 먼 나라 소식이 아닙니다만, 당황스러운 것은 그동안 자바(적어도 J2EE)로 엔터프라이즈 시장을 잘도 우려먹더니 갑자기 뚱딴지같은 XML, 그리고 코끼리 꼬리처럼 감이 안오는 메시징 개념이 하필 웹서비스를 구성하고 있냐는 것이죠.

여기서 간과해서는 안될 것은 웹 서비스의 정치(politics)입니다. 사실 웹 서비스 제공자는 서비스를 구현(implement)해야 하기 때문에, 코볼로 짜든 C#으로 짜든 자바로 짜든 간에 코딩을 해야 합니다. 즉 비즈니스 로직을 실제 컴퓨팅으로 옮겨야 한다는 사실! 이런 사실이 웹 서비스의 선전 문구에서 가장 희석된 부분입니다. SOAP-UDDI-WSDL이라는 말만 들어도 획획 도는(그러고도 모두 약자입니다. Simple Object Access Protocol/ Universal Description, Discovery, and Integration/ Web Services Description Language... 헥헥... 이거 다 외우려고 해도 하세월입니다.) 웬지 모르는 고상함에는 개발자가 담당할 수 밖에 없는 구현(implementation-코딩)이 없습니다.

• 비즈니스 로직(다른 말로 고객을 위한 서비스)를 구현한 오브젝트를 접근할 규약으로서의 소프(SOAP)
• 서비스를 등록(publish)하고 검색(look-up)할 수단으로서의 유디디아이(UDDI)
• 서비스의 스팩을 보여주는 WSDL

웹서비스는 서비스의 구조이지 애플리케이션의 구조가 아닙니다. 만약 현재의 어떤 사이트가 철저하게 MVC(Model-View-Controller) 개념으로 컴포넌트화되어 있다면 별다른 수고 없이 바로 웹 서비스 체제로 통합할 수 있습니다. 왜냐하면 웹 서비스는 어디까지가 서비스를 묶고 나누는 시스템이지, 어떻게 화면에 보이고(View-JSP), 어떻게 통제하고(Controller-Servlet), 실제로는 어떤 자료를 어떻게 처리해야 하는지(Model-Bean)를 규정하는 시스템은 아니기 때문입니다.

이미 EJB도 분산 객체였고, RMI로도 충분히 메시징 스타일의 호출을 할 수 있었지만, 그것은 IBM이 웹 서비스의 아이디어를 내놓으면서 지적했던 대로 "어디까지나 자바" 이야기였습니다. 세상이 모조리 자바로 돌아가는 것은 아닙니다. 많은 기업들이 뒤죽박죽 여기저기 시스템을 보유한 채 오늘날까지 그럭저럭 굴려왔습니다. 현재의 상황도 썩 나쁜 것은 아니지만, 시너지 효과라면 사족을 못쓰는 오늘날의 세태라고 치부한다면 너무한 것일까요?

XML이 HTML을 대체하지 않듯, 웹 서비스 또한 웹 애플리케이션을 대체하는 존재는 아닙니다. XML이 HTML의 프리젠테이션적 역할과는 다른 길을 가듯이, 웹 서비스도 웹 애플리케이션의 비즈니스 로직 구현적 역할과는 다른 길을 가리라는 생각이 들었습니다.

---

Java3D 메일링 리스트를 보며...

언제였던가(기억이 잘 나진 않지만) 자바3D 메일링 리스트를 주욱 훑었던 적이 있습니다. 사실 MacOS X에서 자바3D가 언제쯤 지원될지 궁금해서 그랬는데 대신 엉뚱한 것들만 알게 되었네요.

• Java3D 1.3 FCS는 2사분기내에(현재 베타2가) 소리소문 없이(4월 30일) 나왔습니다.
• 1.3에서 가장 주목을 끄는 점은 "투명 객체 렌더링의 정상화"
• 그러나 자바 3D팀의 예산이 깍였다는 풍문이 돌면서 자바 3D API의 미래가 불투명해짐

대체로 루머성일 수도 있지만, 아무튼 자바3D는 지금 "고민중"인지도 모릅니다. 자바2D가 윈도우 플랫폼에서 디렉트 X의 디렉트 매핑(대응)으로 돌아선 마당에 자바3D가 버틸 곳은 어디일까요. 웹 3D시장이 예상과 달리 달아오르지 않는 것도 자바3D의 마음을 급하게 만들고 있습니다. 더불어 자바2 스탠다드 에디션(SE)이 확산되지 않는 현실이 가장 치명적이겠지만요.

제가 왜 이런 찬밥신세처럼 보이는 자바3D에 관심을 가지는고 하니, 『생생한 게임 개발에 꼭 필요한 기본 물리』(원제 『Physics for Game Developers))의 예제를 자바로 포팅하는 프로젝트에 착수했기 때문입니다. 이 책에 있는 총 9개의 예제 중 3D를 쓰는 것이 3개입니다. 현재 2D를 쓰는 것은 J2SE 1.4의 VolatileImage를 최대한 활용할 예정이고, 3D는 Java3D 1.3을 쓸 생각입니다. 책 자체도 아주 좋고, 예제도 재미납니다. 올 여름이 끝나면 책의 공식 사이트에 게재할 예정입니다.

아!, 메일링 리스트를 보니 J2SE의 미디어 관련 기능을 일목요연하게 논한 책이 있어 소개합니다. Java Media APIs(아마존 링크는 여기)라고 하는데요, 2D(Image I/O, Java Advanced Imaging포함), Media Framework(JMF), 3D등 Java Sound를 제외한 거의 대부분의 미디어 API를 소개하고 있습니다(아마 저자가 비주얼 쪽이 강한가봐요.).

---

for문의 효율적인 활용법

성능조율(Performance tuning)-최적화(optimization)의 단골 화제인 for 반복문의 "더 빠른 용법"에 대한 얘기를 해보죠.

int[] a ... 

for (int i = 0; i < a.length; i++)
{
...
}

보통은 배열의 반복 접근을 위와 같은 식으로 하는데, 여기서 잡히는 꼬투리는 "a.length가 매번 실행된다. 즉 a배열의 length속성은 사실상 상수인데 매번 접근하는 시간낭비(아주 짧은 시간이나마)를 한다"는 것입니다. 따라서…

int[] a ...

int l = a.length;
for (int i = 0; i < l; i++)
{
...
}

과 같이 하면 된다는 것이죠. 여기에 메모리 사용량(일명 풋프린트(footprint))조차 줄이기 위해 l을 for문안의 유효범위(scope)로 잡아주면,

for (int i = 0, l = a.length; i < l; i++)
{
...
}

위와 같은 코드는 실제로 제가 핸드폰용 애플리케이션을 작성할 때(Coding over CLDC) 사용했었습니다. 저런 식으로 하나 쓴다고 뭐 크게 달라지겠냐 싶겠지만, 티끌모아 태산이라고... 절약하는 정신이 좋은 성능으로 승화하지 않을까하서 이렇게 저렇게 해보았습니다.

---

자바스크립트의 replace와 멀린의 replace

진작에 자바스크립트에는 문자열 치환(예를 들어 "나는 나를 왜 미워할까"에서 "나"를 "너"로 바꾸어서 "너를 너를 왜 미워할까"로 바꾸는) 명령이 있었습니다.

a = "abc abcd abcde";
a.replace("ab", "xy");

대강 이런 식인데요, 정작 자바에서는 이러한 문자열 치환이 아니고 스트링의 replace(char, char) 메소드에서와 같이 문자(char) 치환만이 한번에 가능하고 나머지는 각자 메소드를 따로 만들어야 했죠.

이런 상황을 참으로 많은 자바 개발자가 불평했었는데, 드디어 J2SE 1.4에서 정규표현식(regular expression)의 도입과 함께 이 문제를 해결하였습니다. 그럼 어떻게 쓰느냐...

String a = "나는 나를 왜 미워할까";
String b = a.replaceAll("나", "너");

하면 됩니다.(당연하지만 한글도 잘 됩니다.) 그래서 예전에는 웹 폼(특히 textarea)에서 줄바꿈(\r\n)을
로 바꾸기 위해 만들어 써야 했던 메소드 대신,

String refinedComment = comment.replaceAll("\r\n", "
");

로 하면 깔끔하게 웹에서 줄바꿈이 잘 된 게시판 글을 보게 할 수 있는 것이죠.

이번 1.4에서 추가된 String 클래스의 replaceAll(과 replaceFirst) 메소드는 사실 java.util.regex 패키지의 Pattern 클래스를 활용하고 있습니다. 더욱 섬세한 치환과 검색을 원하시는 분들은 우선 정규표현식을 익히시고(『Mastering Regular Expressions』라는 책을 많이 권하고 있더군요.)나서 java.util.regex 패키지를 파보시면 되겠습니다.

참고 URL - http://developer.java.sun.com/developer/technicalArticles/releases/1.4regex/

---

일본어판 자바 서플릿 프로그래밍(이하 JASP) 제 2판을 읽고...

제가 개인적으로 작년(2001년 9월)에 번역 출간했던 『자바 서블릿 프로그래밍 2판』 보다는 조금 늦은 올해(2002년 1월) 일본어판이 나왔습니다.

직접 서점에 가서 읽어본 느낌을 풀어보자면, 그렇게 제가 열을 내며 주장하던 com.oreilly.servlet(이하 COS) 패키지의 국제화(i18n)에 대해서는 전혀 언급이 없더군요. 아마도 아직 일본에서는 업로드 모듈이 그다지 많이 쓰이지 않나봅니다. (사실 일본 게시판에는 첨부파일 업로드 기능같이 네트워크 대역폭을 많이 잡아먹는 일은 거의 없지요.)

가격? 얼마일 것 같아요? 무려 5200엔!!! 우리 돈으로는 거의 5만원이지요.

그래서 그런지 종이질도 더 좋고, 웬지 편집과 인쇄는 더 깔끔하다는 인상이 듭니다. 번역자에 대해서도 관심을 가지지 않을 수 없는데요, 67년생의 지긋하신 개발자분이셨습니다. 일본에서는 『자바 헬프』라는 오라일리 책도 번역하셨더군요.

한국판처럼 초월이식의 요소는 전~혀~ 없습니다. (굳이 사실 필요 없어요.)

최근 COS때문에 제이슨(자바 JASP의 저자)과 주고받은 메일이 있었는데, JASP의 3판에 대해서는 다음과 같이 언급하였습니다.

• 서블릿 2.4가 나온 후에 고려해보겠다.
• COS의 국제화에 기여한 한글판 번역자를 서두에 언급하겠다.
• HttpChatApplet의 IE JVM과의 버그를 바로잡을 수 있다.(고친 소스를 제출했습니다.)
• 한글 2판에 수록된 "서버측 이미지 프로세싱"에 대한 박스 기사를 추가할 수 있다. (영문으로 제공해야겠죠.)

COS의 공식 배포처이기도 한 servlets.com은 제이슨이 운영하고 있는 서블릿 기술 전문 사이트입니다. 이 사이트에 곧 제가 쓸 COS 최신 버전의 국제화와 재명명 기법에 대한 글(article)이 게재될 예정입니다. 많은 관심 바랍니다.