[자바 SOA 개발, Α와 Ω] ① SOA App. 설계와 시스템 구성
목차
예전에 소개했던 SOA 프레임워크인 비하이브에 이어 앞으로 4회에 걸쳐 서비스 지향 아키텍처에 기반 한 애플리케이션 개발의 알파부터 오메가까지 알아보려 한다.
지난 학기의 EJB와 웹서비스 과제로부터 EJB 3.0과 웹 서비스 게이트웨이에 깊은 감명을 받은 필자는 지난 12월 벨기에의 자바 폴리스 컨퍼런스에서 서비스 지향 아키텍처(Service Oriented Architecture, 이하 SOA) 관련 세션들을 들으면서 다음과 같은 생각이 들었다.
SOA, SOA하는데, 비하이브 프레임워크도 있다는데, 정말 말처럼 뭔가 좋아지는 것일까? 웹서비스도 좋고 XML도 좋지만 성능과 확장성은 어떻게 되는 걸까? 다 제쳐 두고라도 쉽고 효율적인(그리고 재밌으면 더 바랄 것이 없을) 애플리케이션 개발이 가능해질까? 이러한 자문에 답하는 방법으로 택한 것이 바로 이 연재를 통해 독자들과 함께 SOA를 고민하고 실천하는 것이라 생각했다,
<newselement></newselement>기본 배경 - J2EE 5.0
연재 가이드
운영체제 : 윈도우 2000/XP, 유닉스 계열, 리눅스나 Mac OS X도 가능
개발도구 : 이클립스 3.1
기초지식 : 자바, 웹서비스, XML
응용분야 : 자바 플랫폼을 이용한 웹서비스 제공
J2EE 1.4가 나온 지도 이제 1년이 지났고 예정대로라면 올해 하반기에 위용을 드러낼 J2EE 5.0(J2SE 5.0처럼 1.5가 아닌 5.0으로 버전이 고쳐졌다)을 벌써부터 다루는 것이 무척 성급하게 비칠 수도 있지만 이미 필자가 작년 11월에 J2EE 5.0의 핵심 기술 중 하나인 JBoss의 EJB 3.0 조기 구현체로 과제를 무사히 마쳤을 정도로 상황이 빠르게 진행되고 있다. 웹 쪽은 JSP 2.1, JSTL 1.1, 그리고 JSF 1.2로 EL 공유와 통합이 한창이고, 웹 서비스도 J2EE 1.4에서 보여준 초기적 기술 상태를 벗어나기 위해 JAX-RPC 2.0과 JAXB 2.0, 그리고 WSM(Web Services Metadata) 1.1로 재무장되어 가고 있다.
이들 3대 요소의 공통점은 메타데이터와 EL을 통해 개발의 편의성을 최우선으로 하겠다는 의지와 함께 서비스의 구현, 서비스의 UI, 서비스의 공개라는 ‘서비스 중심’의 구도를 공고히 하려는 포석이다. 그렇다면 조합해서 ‘쉬운 서비스 개발’이 되는데, 바로 이것이 J2EE 5.0의 모토이기도 하다.
사건의 전말 - 예제 안내이 연재는 서두에서도 밝혔듯이 개개의 기술을 나열 설명하는 대신 예제를 상정한 후 SOA적 구축을 위해 어떻게 해당 기술을 사용하는지를 보이려 한다. 앞으로 다룰 예제는 무척 간단하게도 택시 예약 서비스이다. 이 서비스는 다음에 나열된 기능들을 제공한다.
◆ 고객이 주소와 시간을 조건으로 예약 가능한 택시를 검색한다.
◆ 원하는 택시를 예약한다.
◆ 예약된 상황을 조회한다.
◆ 예약을 취소한다.
|
|
|
JBoss가 과거 썬과의 기술 우위에 대한 앙금을 씻고 J2EE 1.4를 인증한 후 J2EE 5.0에 이르러서는 오히려 매우 적극적인 참여를 보여주고 있는데, EJB 3.0의 경우가 특히 두드러진다. EJB 3.0은 세션 빈에서 홈 인터페이스(home interface)를 없애는 과감함을 보여주는 동시에(그동안 열심히 홈 인터페이스-컴포넌트 인터페이스-빈 클래스의 삼위일체를 설명했던 자신이 부질없기 느껴지기도 했다) 엔티티 빈의 경우에는 "이거 EJB 맞아?”라는 생각이 들 정도로 그야말로 혁신적으로 변했다. 그 배경에 JBoss가 이끄는 하이버네이트(Hibernate)가 있음은 주지의 사실인데, 따라서 JBoss가 자신들의 AOP 프레임워크와 하이버네이트를 결합하여 EJB 3.0의 조기 구현체를 공개하는 것도 그리 무리는 아니라는 생각이다.
아무튼 사용자의 입장에서는 아직 스펙도 다 정해지지 않은 기술을 실제 사용해 볼 수 있다는 점에서 매우 흥미로운데, 자세한 사정은 공식 사이트를 참고하기 바란다. 설치가 그리 까다롭지는 않는데, 다만 현재 최신판인 EJB 3.0 프리뷰 2가 JBoss 4.0.1 최종판과 사이가 좋지 않아 대신 4.0.1 RC1를 꼭 써야 한다. 아마도 이 문제는 이 원고가 활자화된 후 프리뷰 3가 나오면 해결되어 있으리라 믿는다. |
|
|
| |
|
|
|
물론 모든 서비스의 요청과 응답은 사용자 인증 후에 이뤄진다. 여기서 한 가지 염두에 둘 것이 있다. SOA의 시작은 서비스의 정의에 있다. 서비스는 고객을 위해 존재한다. 소프트웨어 개발자가 서비스업 종사자인지 아닌지에 대해서는 애매함과 논란이 공존하지만, SOA를 실천함에 있어서 서비스의 개념을 잊어서는 안된다. 서비스가 고객을 위해서 존재하는 것이라면, 고객이 무엇을 원하는지부터 또는 무엇을 원할지를 파악하는 일에서부터 서비스의 설계가 시작된다. 이러한 사고를 <그림 1>처럼 도식화할 수 있다.
 |
| <그림 1> 택시 서비스의 구상 |
웹 서비스 개발에서도 누누이 강조하는 개념 중의 하나로 coarse-grained가 있다. 필자가 처음 이 용어의 번역을 시도했을 때(O'Reilly의 Java Web Services, 2002년), 오로지 생각하는 것이라고는 스타벅스에서 원두를 샀을 때 “어떻게 갈아드릴까요?”라는 질문에 “굵게 갈아주세요”하는 바로 그 ‘굵게 갈음(coarse-grained)’이었다. 웹 서비스에서는 반대말인 fine-grained를 하지 말라는 뜻이기도 한데 도대체 뭘 잘게 갈지 말고 굵게 갈라는 뜻일까?
대답은 의외로 간단하다. 사용자가 사용할 인터페이스에 개발자의 잣대를 들이대지 말라는 말이다. 사용자는 장소와 시간을 주고 예약 가능한 택시 목록을 보고 싶다. 개발자는 ‘음··· 일단 xx1 메쏘드를 호출하는 식으로 장소와 시간을 받아온 뒤 xx2 메쏘드를 불러 DB 연결을 얻어 온 후 xx3 메쏘드로 사용자 인증을 한 후 xx4에서 장소를 정규화하고···’ 이렇게 머릿속에는 이미 아스트랄한 메쏘드 세상이 펼쳐지는 것도 모자라서 ‘이렇게 해놓으면 나중에 또 쓸 수 있겠지?’하며 흐믓한 미소마저 짓는다. 재사용을 위한다면 메쏘드를 public으로 할 것이고, 이러다 보면 메쏘드의 공개는 파죽지세로 이어진다.
이러한 public 메쏘드와는 별도로 공개된(published) 메쏘드라는 개념이 나와 관심을 끈다. 물론 공개된 메쏘드는 자바 문법으로는 나타낼 수 없지만 단순히 접근 수준을 정하는 정도가 아니라 이 메쏘드를 외부의 클라이언트가 호출할 수 있게 하겠느냐는 뜻에서 공개되었다는 표현을 쓴 것이다(Erich Gamma와 Kent Beck이 쓴 『Contributing to Eclipse』에서 발췌). WSM에서는 공개된 메쏘드에 대한 표식을 가능하게 하는 메타데이터가 제공되고 있으니 정리하면 사용자에게 쓰도록 내비칠 오퍼레이션(웹 서비스에서는 메쏘드라는 프로그래밍 언어적 용어 대신 오퍼레이션을 대응하여 쓴다)은 최대한 굵게, 그리고 프로그래밍 언어의 public과는 차별화해야함이 coarse-grained의 현실적 취지이다.
앞으로 반복해서 강조할지도 모르지만 택시 예약 서비스는 매우 간단한 예에 지나지 않는다. 아마 실제로 뭔가 만들려면 정말 생각할 것이 많을 것이다. 그러나 잘 들여다보면 모든 것은 이 간단함에서 시작하며, 그것이 바로 분할하여 통치하라는 율리우스 카이사르의 지혜와 맞닿아 있다.
|
|
|
WSDL(이라고 쓰고 ‘위즈들’이라고 읽는다)은 SOA에 있어 가장 밑바탕이 되는 설계도면과 같다. 벌써부터 개개의 웹 서비스를 합치고 조율하는 BPM을 논하고 있지만, 그러기 위해서는 WSDL이라는 벽돌의 아귀가 딱딱 맞아야 하는 것이다.
WSDL이 XML로 되어 있으니 사람이 읽기에는 문제가 없다고 생각하면 마음은 매우 편하다. 하지만 실상은 간단한 Hello World 정도가 아닌 이상 머리가 팽팽 돌게 만들기 십상이다. 여러 비주얼 툴들이 WSDL의 요약 화면을 제공하지만 그렇게 남이 요리해준 것만 먹기에는 세상은 험하고도 험하다.
보기만 해도 길고 긴 네임스페이스 정의들과 그 이름이 그 이름 같은 이름들의 나열에 어느덧 졸고 있는 자신을 만나기 전에, WSDL 보기의 기반을 닦아보도록 하자. 웹 서비스의 시작은 꽤 되었지만 최근 몇 년 사이에 마이크로소프트의 주도아래 급속도로 Literal 인코딩 방식이 표준으로 자리 잡아 (WS-I Basic Profile 1.0 이후), 스키마의 사용이 거의 필수화되어 WSDL 읽기가 더 심난해진 것이 사실이다.
이 시점에서 독자들에게 권하고 싶은 것은 WSDL을 이해하기 위해서는 (이제는) XML 스키마의 이해도 병행되어야함이다. XML 스키마에도 여러 종류가 있지만 W3C의 XML 스키마가 가장 보편적으로 쓰이고 있어 너무 걱정할 것은 없다(그리 위안이 되는 현실은 아니지만).
자바 프로그래머라면 메쏘드를 정의하고 메쏘드 본문에 구현하는 코드를 쓰는 것이 매우 자연스러울 터! 혹시 메쏘드의 인수나 반환 값에 레퍼런스 타입을 쓴다면 그에 해당하는 클래스를 미리 정의해야함도 자명하다. WSDL이라고 ‘용가리 통뼈’가 아닌 다음에야 타입을 먼저 정의하고 나서 메쏘드에 준하는 오퍼레이션을 정의할 것이다. 다만 이 오퍼레이션 정의에 메시지라는 개념이 한 단계 더 들어간다.
type -> message -> operation
왜 메시지라는 것이 필요할까? 웹 서비스가 RPC(Remote Procedure Call)의 복고에서 시작했다고는 해도, MOM(Message Oriented Middleware)을 깡그리 무시하지도 않았다. 웹 서비스에 지대한 영향을 준 CORBA가 후기에 들어 비동기 호출과 메시징을 지원하는 식으로 확장한 것을 떠올린다면 웹 서비스가 단순히 원격 메쏘드 호출의 XML 버전의 자리에만 연연할 것이라는 추측은 XML-RPC과 함께 잊어도 좋다. WSDL에서 메시지는 서비스의 요청자와 응답자가 어떤 형태의 XML 메시지를 주고받을지를 type에서 정의한 스키마에 따라 정의하는 꽤 존재감 강한 요소이다.
그리고 사실 오퍼레이션은 WSDL에서 최상위 요소는 아니다. 대신 port type(실제 WSDL에서는 <portType>으로 표기)이 오퍼레이션을 감싸고 있는데, 이는 마치 자바에서 인터페이스가 메쏘드를 품고 있는 것과 흡사하다.
여기까지 보면, type > message > port type (operation)의 계층 구조가 대강 눈에 들어온다. 웹 서비스에서 오퍼레이션은 자바 메쏘드와 한 가지 심대한 차이점을 지니고 있는데, 바로 IN, OUT, INOUT 매개변수 종류이다. 아마 PL/SQL이나 CORBA의 IDL을 접해봤다면 익숙할 (심지어 ODBMS에서 쓰이는 ODL에도 있는) 이 개념은 어찌 보면 함수의 입출력 구조를 복잡하게 하기 그지없지만, 또 다른 관점에서는 하나의 리턴 타입(물론 레퍼런스로 잡으면 복합적으로 되지만)만 가지는 구조보다 유연하다. 따라서 이 문제는 WSDL과 프로그래밍 언어 간의 처리 시 주의를 요하는데 잠시 뒤에 다루도록 하자.
나머지 WSDL 최상위 요소인 binding과 service는 ‘추상적인 인터페이스의 공개’라는 측면과는 거리가 있는, 실제 port type으로 정리된 서비스를 어떤 스타일과 메시지 프로토콜과 전송 프로토콜(현재는 Ducument/Literal 스타일에 SOAP/HTTP가 우세하지만, 꼭 그렇게만 써야하는 것은 아니다)로 구체화하고 웹에서 어떤 주소(URL)로 공개할지를 기술한다. 그래서 보통 port type 이전을 추상(abstract) WSDL, 부분(partial) WSDL이라고 하고, service까지 다 있는 WSDL을 완전(full) WSDL, 구현된(implemented) WSDL, 재정의된(overriden) WSDL이라고도 한다.
그러면 이제 WSDL 한 장을 놓고 대강 이런 서비스가 전개되겠구나 하는 감을 잡을 수 있다고 가정하면, 그 다음에는 WSDL 처리라는 관문이 버티고 있다. 순수히 XML 웹 서비스의 설계만을 다루지 않고서는 프로그래밍 언어 측면에서의 작업은 피할 수가 없다. 필자가 영국에서 공부를 시작하기 전에 밤낮으로 하던 일이 바로 그 WSDL 처리를 자바로 어떻게 할까였다. 물론 각 플랫폼과 툴마다 방식이 다르므로 일률적으로 어떻게 하라고는 말할 수 없다. 이 점은 본인도 참으로 안타깝게 여기는데, 어째서 JAX-RPC에서 WSDL을 처리하는 툴의 사용법에 대한 표준화를 하지 않는지가 아쉽다(툴이 어떤 일을 해야 한다는 것만 정의하고 있다).
따라서 WSDL로부터 자바 코드를 생성하는 이른바 아티팩트-WSDL의 type부터 자바의 대응 클래스 타입, port type으로부터 대응하는 자바 인터페이스, 그리고 클라이언트용 스텁과 서버용 스켈레톤-생성은 전적으로 자신이 사용하는 툴에 의존하게 된다. 현 상황은 이런 아티팩트의 플랫폼간 호환성이 없다. 예를 들어 아파치의 Axis에서 생성한 아티팩트와 썬의 JWSDP가 생성한 아티팩트는 비슷한 부분도 있지만 차별화된 부분도 있다. J2EE 5.0의 웹 서비스에 쓰일 JAX-RPC 2.0과 JAXB 2.0은 이러한 불화를 없애기 위해 아티팩트 이식성을 논의하고 있는 중이다. 실은 J2SE 6.0이 JAX-RPC 2.0과 JAXB 2.0을 기본으로 포함할 것이기 때문에 아티팩트의 이식성은 필연적일 수밖에 없는 것이다. |
|
|
| |
|
|
|
큰 그림 - 시스템 구조
서비스의 요구사항과 취지는 이 정도로 마치고 다음으로 전체 시스템의 구도를 잡아보자.
 |
| <그림 2> J2EE 5.0 관점의 택시 예약 서비스 구조 |
<그림 2>를 풀어 쓰면 다음과 같다.
◆ EJB 3.0은 서비스를 실제 수행하는 서버측 비즈니스 로직을 맡는다(예제에서는 DB를 따로 마련하지 않고 JBoss에 내장된 HSQL을 쓸 것이다. 사실 EJB 3.0의 CMP를 쓰면 전혀 설정할 것이 없다).
◆ WSM은 서비스의 공개와 입출력을 맡는다. 현재로서는 WSM 1.1의 스펙도 나와 있지 않고 그에 준하는 구현체도 따라서 당연히 없으므로 일단은 비하이브의 WSM 1.0 구현체를 쓸 것이다.
◆ 클라이언트는 J2SE에서는 이클립스의 RCP(Rich Client Platform), J2ME에서는 휴대폰용 MIDlet, 그리고 씬 클라이언트로 JSF를 통한 HTML과 WML이 제공된다.
◆ 모든 클라이언트는 택시 예약 서비스로 공개된 WSDL에 기반하여 서버와 소통한다.
◆ 대용량의 서비스를 위해, 특히 성능 향상과 관리 능력 강화를 위해 게이트웨이를 도입, 개싱과 로깅을 시도한다.
◆ 비동기 웹 서비스를 제공하며 WS-Addressing으로 요청 엔드포인트(endpoint, 즉 URL 주소)와 응답 엔드포인트를 지정한다.
이와 같은 시스템을 구축하기 위한 환경은 다음과 같이 꾸린다.
J2SE 영역
◆ JDK 5.0 업데이트 1(아마 이 연재가 진행 중인 시점에 업데이트 2가 나올 것이다)
J2EE 영역
◆ JBoss AS 4.0.1(이후 4.0.2가 나올 수 있으나 EJB 3.0 구현체와 맞는 것을 쓰도록 한다)
◆ JBoss EJB 3.0 PR2(매달 새 버전을 내기로 했으니 PR3 이후도 기대할 만하다)
◆ 톰캣 5.5(빠르게 업데이트되고 있다. 5.5.6 이후를 쓰게 될 것이다)
◆ 제티(Jetty) 5.1(새롭게 부상하고 있는 웹 컨테이너, 5.1.1 이후를 쓴다)
◆ 비하이브e V1 알파(지난 아파치 컨퍼런스 발표용인데, 가까운 장래에 정식 릴리스가 나오리라 본다)
◆ Axis 1.2 RC2(1.2가 아직도 최종판이 나오지 않아 개발진의 일원으로서 송구할 뿐이지만, 실제 사용에는 큰 무리가 없을 것이다)
◆ MyFaces 1.0(JSF의 대표적 오픈소스 구현체로서, 1.0.8 이후를 쓴다)
툴 영역
◆ 이클립스 3.1 M4(2월중에 M5가 나오므로 거의 완성된 3.1을 쓰게 되는 셈이다)
◆ WTK 2.2(썬의 MIDP용 애플리케이션 개발 툴이다)
◆ TestNG(메타데이터를 활용한 차세대 JUnit. 현재는 구글 소속의 Cedric Beust의 개인 프로젝트이기도 하다. 참고로 구글은 연구원의 개인 프로젝트를 의무화하고 있다고 한다)
◆ CruiseControl(XP의 Continous Integration을 실천하는 툴이다)
각 소프트웨어는 검색을 통해 쉽게 접근할 수 있을 정도로 각 분야의 대표적이거나 유명한 것들로 모았다. 이 연재는 앞의 환경을 기준으로 진행할 것이며, 다른 환경이라도 기본적으로 J2EE에 기반하므로 이식에 큰 무리는 없으리라 여겨진다.
서비스의 재구성 - 구성 요소들
본격적인 개발은 다음 글에 펼쳐지겠지만 미리 예고편을 틀어보면 이 시스템은 서버측만, 혹은 클라이언트측만 구축하는 것이 아니라 끝에서 끝까지(end-to-end) 만드는 것으로 다음과 같은 영역이 병렬로 진행된다.
서비스 제공자 측
◆ 서비스 구현 영역 : EJB 3.0으로 서비스 구현
◆ 서비스 공개 영역 : WSM으로 서비스 공개
서비스 요구자 측
◆ J2SE 리치 클라이언트 : RCP로 클라이언트 작성
◆ J2ME 리치 클라이언트 : MIDlet으로 클라이언트 작성
◆ J2SE, J2ME 공용 씬 클라이언트 : JSF로 클라이언트 작성
하지만 영화나 글이나 일차원적이므로 사실상으로 총 5분야는 계속 도는 식으로 생각하고 있다. EJB 3.0의 세션 빈에서는 홈 인터페이스가 사라졌으므로 바로 비즈니스 인터페이스를 짜면 되는데, 앞서 구상한 서비스에 맞춰 다음과 같이 설계한다.
soa.service.TaxiBookService [인터페이스]
Taxi[] getAvailableTaxis(Location location, Calendar calendar)
void reserve(int taxiId)
Order[] viewOrders()
void cancelOrder(int orderId)
앞의 메쏘드 시그니처는 추후 바뀔 수 있으며 Location, Taxi, Order와 같은 타입 또한 이후 구체화할 것이다. 택시 예약 서비스에 대한 WSDL은 WSM을 통해 위의 자바 인터페이스로부터 끌어낼 수 있으므로 직접 작성할 필요는 사라진다.
|
|
|
J2SE 5.0의 코드명과 똑같아 자바 개발자들에게는 익숙한 이름인 타이거는 애플의 차세대 운영체계에서도 쓰여 왔다. 우연인지 몰라도 MacOS 10.4부터 J2SE 5.0을 지원하는데, 아직은 공식적으로 배포되지 않은 터라 애플 개발자 프로그램에 등록된 개발자들에 한해 접근이 허용되고 있는 실정이다.
필자가 지난 자바폴리스 컨퍼런스에서 크게 놀랐던 점 중의 하나는 상당수의 참가자(아마 대개 자바 개발 관련자이겠지만)가 파워북을 쓰고 있었다는 점이다. 대략 어림짐작으로도 노트북을 펼쳐 들고 있는 사람들의 약 3분의 1, 발표자들의 경우에는 약 2분의 1이 맥을 쓰고 있었다. 이러한 (유럽, 북미의) 자바 개발자들 사이의 맥에 대한 인기의 이유는 무엇일까?
인텔 기반 PC가 대세인 상황이라 윈도우 OS가 널리 쓰이고 있긴 하지만 확실히 자바는 싹이 튼 곳이 유닉스로 먹고 사는 썬이다 보니 유닉스와 가깝다. IDE 툴이 많이 대중화되었지만, 유닉스의 셸을 통한 개발의 강력함도 유닉스에 친숙한 개발자들에게는 무척 매력적이다. 하지만 리눅스 노트북은 흔치 않다. 윈도우의 GUI에 익숙해져 아직 리눅스에는 만족스럽지 못할 수 있다. 여기에 맥의 호소력이 있다. BSD 유닉스에 기반하면서도 아쿠아라는 환상적인 UI를 선사하는, 더군다나 알게 모르게 인텔과 MS의 마수에서 벗어난듯한 자유로움이 가격적인 망설임을 극복하게 만드는 것이 아닐까?
아직 확인된 소식은 아니지만 올 2사분기에는 64비트 CPU인 G5를 탑재한 파워북 노트북이 등장한다니 64비트에 최적화된 두 마리 호랑이(MacOS, J2SE 둘 다)를 쓰다듬는 쾌감이 지금부터 상당히 기대된다. 늦은 시간 전철의 빈자리에 앉아 64비트 프로그래밍을 즐기는 여유, 여름이라면 아이스커피 한잔과도 잘 어울리라 상상해 본다. |
|
|
| |
|
|
|
팀플레이 - 협업 방식
여기까지가 필자의 몫이었다면 지금부터는 독자의 몫이다. 이 시스템의 구축에는 다음과 같은 역할이 필요하다.
◆ 코디네이터 : 프로젝트 매니저, 리드 등이라고 볼 수도 있겠지만 뭔가 강압적이고 우위에 섰다기 보다는 모든 역할을 조율하고 매끄럽게 작업이 되도록 돕는다.
◆ EJB 담당 : 서비스의 비즈니스 로직을 맡는다. 웹 서비스나 클라이언트에 대해 알 필요가 없다.
◆ WSM 담당 : 서비스의 노출을 맡는다. EJB와의 연결, 클라이언트와의 교신에 대해 알아야 하지만, 이외의 EJB·클라이언트 사항은 알 필요가 없다.
◆ RCP 담당 : RCP 기반 클라이언트 제작을 맡는다. Axis에서 WSDL 처리와 서비스 호출 방법은 알고 있어야 하지만 이외의 서비스 측 사항은 알 필요가 없다.
◆ MIDlet 담당 : MIDlet 기반 클라이언트 제작을 맡는다. WTK에서 WSDL 처리와 서비스 호출 방법은 알고 있어야 하지만 이외의 서비스 측 사항은 알 필요가 없다.
◆ JSF 담당 : JSF 기반 클라이언트 제작을 맡는다. Axis에서 WSDL 처리와 서비스 호출 방법은 알고 있어야 하지만 이외의 서비스 측 사항은 알 필요가 없다.
혼자 다 할 수도 있겠지만, 가장 권장하는 것은 6명이 팀을 이뤄 해보는 것이다. 일단 팀을 이루었다면, 다음 호 진행을 함께하기 전에 각자가 필요한 기술을 미리 준비해둔다.
◆ 코디네이터 : 엔드투엔드(end-to-end) 설계 전반, SOA 방침, WSDL, XML 스키마, SVN, CruiseControl, Wiki
◆ EJB 담당 : EJB 3.0 기술, JBoss EJB 3.0 조기 구현체, JBoss 4.0
◆ WSM 담당 : WSM 1.0 기술, 비하이브 WSM, 톰캣 5.5
◆ RCP 담당 : SWT, JFace, 이클립스 RCP, JAX-RPC 1.1, Axis WSDL 툴, Axis 클라이언트 런타임
◆ MIDlet 담당 : MIDP 2.0, JSR 172 J2ME 웹 서비스, WTK WSDL 툴
◆ JSF 담당 : JSF 기술, MyFaces(HTML 렌더링 킷, WML 렌더링 킷), 제티 5.0, JAX-RPC 1.1, Axis WSDL 툴, Axis 클라이언트 런타임
그리고 사전 작업도 해둔다.
◆ 코디네이터 : SVN, CruiseControl, 위키 환경 구축 및 사용 방법 전파
◆ EJB 담당 : JBoss 4.0 + EJB 3.0 서버 준비 및 세션 빈, 엔티티 빈 테스트
◆ WSM 담당 : 톰캣 5.5 + 비하이브 WSM 준비 및 기초 서비스 테스트
◆ RCP 담당 : 이클립스 RCP 실행 환경 및 Axis 클라이언트 테스트
◆ MIDlet 담당 : WTK 2.2 실행환경 및 웹 서비스 테스트
◆ JSF 담당 : 제티 5.0 + MyFaces 서버 준비 및 HTML·WML 렌더링 테스트
택시 예약 서비스 구축으로 들어가기 전에 다 함께 결정하면 좋을 것으로는 다음과 같은 것들이 있다.
◆ 이상적인 SVN 구조 합의
◆ 테스트 작성 방식(각 모듈 담당은 독립적으로 테스트 작성. 코디네이터는 통합 테스트 작성 및 각 모듈 당당이 독립적인 테스트 작성을 할 수 있도록 더미 데이터 제공)
◆ 위키를 통한 실시간 문서 작성 규칙(문서 양식과 대상 항목 등)
그리고 혹시 좀 더 본격적인 교육으로 이 연재를 활용하고 싶다면 각 모듈을 2명의 프로그래머가 담당하게 하고 한 명은 해당 분야에 익숙한 사람을, 다른 한명은 초보로 짝을 지어 짝 프로그래밍(Pair Programming)으로 사전 기술 습득, 서버 구축, 테스트 작업을 함께 하면 효과가 배가될 것이다.
|
|
|
솔직히 고백한다. 필자도 문서 작업은 정말 싫어한다. 그래도 하라고 하니까 했다. 웹 사이트 구축 프로젝트 말미에는 어김없이 찾아오는 프로그램 설명서(말로 해도 어려운데 글로 하자니 참···)는 그나마 형식이 정해져 있어서 고마울 지경이고, 오픈소스 프로젝트에서는 더더욱 문서 작성이 까다롭다. 만국의 프로그래머에게 통할 수 있도록 영어로 작성해야 하는데다 아파치의 경우에는 포레스트(Forrest)라는 만만치 않은 문서 구축 프레임워크에 임시로 Wiki를 쓰기는 하지만 아무튼 부담스럽기는 매한가지다.
프로그램 짜는 건 그래도 할 만한데 왜 문서 쓰기는 한숨부터 나올까? 프로그램도 그렇지만 글도 쓰면 쓸수록 느는 동시에 쓰면 쓸수록 어려워진다. 스스로에 대한 기대치가 높아지니까 아예 하고 싶어지지 않게 된다. 게다가 슬금슬금 귀찮아지기까지 한다. ‘내가 아니까 누가 물어보면 직접 대답해주면 되지···’ 이런 심정인 셈이다. 그리고 솔직히 작업에 허용된 시간도 빠듯하니 문서 작성은 개발 과정에 있어 우선순위가 밀려버리고 만다.
필자가 지난 학기에 수강했던 시스템 디자인이라는 과목에서 아주 웃기는 제목의 논문 읽기를 강요받았다(시험에 나온다고 무척 강조되었다). David L. Parnas라는 사람이 쓴 「A Rational Design Process: how and why to fake it」이라는 글로서, 요지는 간단히도 “합리적인 설계 절차란 사실상 없으며, 우리는 다만 현실에서 그것을 흉내낼 수만 있을 뿐이다.” 그리고 그 구체적인 방법으로 문서 작성을 들고 있다.
그럼 좀 비약해서 문서 작성을 제대로 안하면 합리적인 소프트웨어 개발 절차는 실천은 고사하고 흉내조차 못낸다는 말인데, 곰곰이 생각해보면 (그동안 프로그램 개발에 있어) 얼마나 장대한 부조리가 펼쳐졌는가(그리고 펼쳐질건가)가 마음결에 살포시 내려앉는다. 또 하나, Parnas는 이 문서가 단순히 “내가 왕년에 이렇게 했었다”는 식의 소설이 아니라 누군가가 해당 소프트웨어에 대해 뭔가 궁금함을 가졌을 때 찾아 볼 수 있는 참고자료로서 형식과 내용을 강조하고 있다. 내가 짰으니까 당연히 나는 궁금할 것이 없다. 바로 여기에 합리성이 고개를 든다. 자기만 생각하는 세상에 합리는 요샛말로 무효다. 사람(즉 남)이 읽기 쉬운 코드를 짜라는 금언도 마찬가지이다. “나는 그렇다 치고, 남은 과연 어떻게 생각할까”라는 단순한 발상에서 이성적이고 합당한 절차의 이상으로 한 발짝씩 다가가는 것이다.
순수 이성적인 소프트웨어 설계 절차가 불가능하다고 한 이유는 미래를 완벽히 예지할 수도, 타인의 마음을 완전히 인지할 수도 없는 인간의 근본적 한계에 기인하지 않을까 생각해 본다. |
|
|
| |
|
|
|
하지 않겠는가 - SOA 개발
벌써부터 신나지 않는가? 적게는 2～3명에서 많게는 11명까지 함께 할 수 있으며, XP와 TDD를 십분 활용하여 서비스 지향적인 개발팀을 만든다. 마치 보병의 소대처럼, 한 팀에 각 분야의 전문가가 모두 있다. 작전 지휘의 소대장에서 프로젝트 조정의 코디네이터로, 임무 달성에서 서비스 제공으로 진화한다. 기존의 애플리케이션 개발과의 차별성은 바로 이런 데에 있다. SOA는 기민한 소프트웨어 개발을 가능케 하며, 소프트웨어의 사용자가 제공자를 빈틈없이 이어준다. 마지막으로 도전욕 강한 팀에게는 다음 연재를 기다릴 것도 없이 택시 예약 서비스를 미리 만들어보고 필자의 과정 그리고 결과와 비교해보는 스릴을 느껴보기를 기대해 본다.@
* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.
댓글
댓글 쓰기