시소당
SOA 전략 구현을 위한 6대 지침
SOA 전략 구현을 위한 6대 지침
오늘날 IT 기술은 비즈니스 프로세스와 밀접한 관련을 맺으며, 기업 발전을 견인하는 주요 동력으로 자리잡고 있다. 기업의 유기적 발전에 맞춰 비즈니스 프로세스를 빠르고 쉽게 최적화할 수 있는 전략으로서‘서비스 중심 아키텍처(SOA)’에 대한 관심도 한층 높아지고 있다. SOA 전문가들은 적절한 개발 방법론과 툴을 조합함으로써 SOA의 진정한 비즈니스 가치를 실현할 수 있다고 한다. 구체적인 사례와 함께 SOA 성공 지침을 확인해 본다.
비즈니스 프로세스의 유기적 발전 전략, SOA
Aloha Airlines의 CIO 겸 수석부사장 Soren Burkhart는 하와이 소재의 대기업 임원이라는 점에서 많은 이들의 부러움을 사고 있지만, 그가 항상 ‘낙원’에서 사는 것은 아니라고 말한다.
업체간의 치열한 경쟁은 항공업계도 예외가 아니어서, 늘 업무상 심각한 스트레스를 받고 있기 때문이다. 컴퓨터공학 / 전기 공학 학사 학위에 MBA 학위까지 가지고 있는 Burkhart는 Aloha Airlines가 성공하기 위해서는 기술 관리자를 포함하는 모든 직원이 핵심적인 이슈에 관심을 집중해야 한다는 사실을 절실히 느끼고 있다. “ 테크놀로지란 기업이 돈을 벌수도, 잃을 수 도 있게 만드는 주요 요인이라고 생각합니다.”Burkhart와 같은 CIO들이 시장 상황의 변화에 따라 비즈니스 프로세스를 업데이트 하고 최적화하기 위한 전략으로서 SOA(Service-Oriented Architecture)에 점점 더 많은 관심을 보이고 있다. 이미 많은 기업이 SOA가 제공하는 높은 수준의 호환성과 재활용성을 이용하여, 기존 애플리케이션을 확장하거나 새로운 애플리케이션을 개발 하기 위한 통합 개발 환경을 구현하고 있는 것이다.
Burkhart는“우리 회사의 비즈니스 프로세스를 웹 서비스를 통해 공개함으로써 전체 기업 환경의 데이터를 통합하고, 비즈니스 사용자, 외부 파트너, 고객에게 유용한 정보를 제공할 수 있습니다. 과거에는 소프트웨어 컴포넌트는 서로 다른 시스템이 제공하는 경직된 인터페이스를 활용할 수밖에 없었습니다. 하지만 이제는 느슨하게 결합된 형태의 인터페이스를 구현하고 BPEL(Business Process Execution Language)과 같은 표준을 활용하여, 비즈니스 프로세스에 더 집중할 수 있게 되었습니다.”라고SOA의 혜택을 설명한다.
하지만 SOA의 성공은 저절로 주어지는 것이 아니다. 표준을 준수한다고 해서 툴 또는 시스템 간의 호환성이 보장될 것이라 확신 할 수도 없다. 잘못 설계된 서비스로 인해 런타임 성능에 불필요한 오버헤드가 발생할 수도 있다. 또, 4세대 프로그래머들은 새로운 개발 방법론과 용어들에 다소 거부감을 느끼기도 할 것이다.
IEEE위원회의 Software Architecture 멤버이며, 유명 금융서비스 업체의 부사장 겸 선임 테크니컬 매니저인 Mark M. Davydov는 현재SOA 기반 뱅킹 애플리케이션을 구현하는 작업에 참여하고 있다.“ 환경을 올바르게 이해하는 개발자에게 SOA는 매우 다양한 혜택을 제공합니다. 하지만 새로운 프로토콜과 툴들을 이용하기만 하면 이러한 혜택이 마술처럼 실현될 것이라고 믿는 사람들은 생각지도 못했던 문제로 어려움을 겪게 될 것입니다.”라고 경각심을 일깨운다. 그렇다고 미리 움츠러들 필요는 없다. SOA 전문가들은 적절한 개발 방법론과 툴을 조합함으로써 SOA의 진정한 비즈니스 가치를 실현할 수 있다고 조언한다.
기본 빌딩블록은 서비스
SOA의 진정한 매력은 리소스가 제한된 상황에서도 새로운 컴퓨팅 리소스를 구현할 수 있다는 점이다. 오라클의 개발 툴 제품 관리 담당 선임디렉터인 Roel Stalman은 “웹 서비스와 SOA를 이용하면, 기존 인프라스트럭처와 기존 애플리케이션을 새로운 환경에 쉽게 통합할 수 있습니다. 또 새로 구축된 애플리케이션을 기존 인프라스트럭처에 통합하는 작업도 한층 간단해집니다.” 라고 설명한다.
이와 같은 목표를 달성하기 위해 사용되는 SOA의 기본적인 빌딩블록이 바로 서비스이다. 여기서 서비스란 특정 작업을 수행하기 위한 코드를 의미한다. 효과적인 작업 환경을 구현하기 위해서는, 서비스가 적절한 수준의‘그래뉼래러티(granularity)’ 와‘커플링(coupling)’을 제공할 수 있어야 한다. 그래뉼래러티란 서비스의 성능 특성을 얼마나 섬세하게 조정할 수 있는가를 평가하는 기준이며, 커플링은 서로 다른 서비스가 얼 마나 긴밀하게 연결되어 있는지 판단하는 기준이 된다.‘ 긴밀하 게 연결된(tightly-coupled)’서비스에서는 개별 서비스가 서로 간에 밀접한 종속성을 갖는 반면,‘ 느슨하게 연결된(loosely- coupled)’서비스에서는 서비스가 높은 수준의 독립성을 갖게 된다. SOA 환경의 개발자들은‘느슨하게 연결된’서비스 를 통해 유연성을 극대화하는 접근 방식을 택하고 있다.
각 서비스는 인터페이스를 공개함으로써 다른 서비스의 인터페이스와 플랫폼 중립적, 언어 중립적, 운영체제 중립적인 방식으로 연결된다. XML, SOAP과 같은 웹 표준은 호환성을 보장하기 위한 핵심 기반으로 활용된다. 서비스가 생성되고 나면, UDDI 디렉토리와 같은 서비스 레지스트리를 통해 그 존재가 알려지며, 다른 서비스는 이렇게 공개된 기능을 활용하여 비즈니스 프로세스를 구현할 수 있다. <그림 1>은SOA 라이프사이 클을 정리한 것이다.
서비스가 갖는 이러한 특성은 매우 분명한 효과를 제공한다. 개발자들이 작성한 코드는 새로운 애플리케이션에서도 재활용 할 수 있다. 따라서 고객 이름 확인과 같은 공통적인 태스크를 단 한 차례의 코딩으로 구현할 수 있다. 개발자들은 기존에 작성된 서비스 풀(service pool)에서 필요한 기능을 호출하고 새로운 프로젝트에 연결한다. BPEL과 같은 프로세스 자동화 툴은 이러한 과정을 더욱 단순화시켜 주며, 새로운 비즈니스에 서비스들을 조합하기 위한 개방형 표준이다.
Sageza Group의 마케팅 분석 및 서비스 그룹 담당 연구 디렉터 Rob Kidd는 궁극적으로SOA는 비즈니스 목표 달성을 위한 핵심 동력이 될 것으로 전망하고 있다.“ 이러한 목표를 달성하기 위해서는 먼저 핵심 비즈니스 프로세스를 제대로 이해하고, 이 프로세스를 지원할 수 있는 다양한 서비스를 구현할 수 있 어야 합니다.”
SOA가 약속하는 애플리케이션 통합, 호환성, 재활용성 등의 효과는 한 때 꿈같은 것으로 여겨지기도 했지만, 이제는 현실로 나타나고 있다. Davydov는“우리 회사는 이제 개념적으로나 기술적으로나 진정한 의미의 애플리케이션 유연성을 구현 하는 단계에까지 도달했습니다. 이전 기술로는 달성이 불가능했 던 고지를 마침내 IT 업계가 점령한 것으로 보입니다.”라고 현 단계를 진단하고 있다.
성숙되고 있는 툴 시장
이제 다양한 웹 서비스 전문 개발 툴과 웹 서비스 관리 기술, 애플리케이션 서버, 구축 플랫폼이SOA 개발 환경의 발전을 주도 하고 있으며, 고전적인 IDE 환경도 최신 표준을 지원하기에 이르렀다. 애널리스트들은 SOA 시장과 표준이 계속적으로 진화 하고 있으며 아직 어떤 벤더도 완전한 패키지를 완성하지는 못 했다고 말한다. IDC의 SOA/웹 서비스 담당 프로그램 디렉터 Sandra Rogers는“다양한 벤더가SOA 플랫폼의 특정 영역을 위한 기술을 개별적으로 제공하고 있으며, 그 성숙도도 천차만별입니다.”라고 말한다.“ 대부분의 플랫폼 제공업체들이 포괄적 인 SOA 환경 구현을 위해 노력하고 있지만, 일부 벤더는 비즈 니스 프로세스의 개선 및 통합에, 또 일부 벤더는 관리 및 보안 영역에, 또 다른 벤더는 레지스트리 기반 기술과 개발 툴에 초점을 맞추기도 합니다.”
SOA 개발자들은 SOA 개발 환경이‘블랙박스’가 배제된 환경에서 자동화 기능을 제공할 수 있어야 한다고 말한다. 미국 에너지성에서SOA 기반의 연방 정부 애플리케이션을 개발하고 있는 소프트웨어 설계 담당자 Edmon Begoli는“서비스에 버그가 발견되는 경우, 개발자는 프로세스에 대한 완전한 제어 능력을 필요로 합니다. 그래야만 어떤 부분에서 문제가 발생했는지 단계별로 확인할 수 있습니다.”라고 말한다.
오라클은 통합 및 구축 서비스, 프로세스 통합, 개발 및 데이터 관리 기술 등 포괄적인 범주의SOA 기능을 구현하고 있다. Oracle JDeveloper 인터페이스는 SOA 애플리케이션이 제공하는 기본 서비스(primary service)와 서브서비스(subservice)에 대한 통합적인 뷰를 제공한다. Oracle JDeveloper 10.1.3에서는 웹 서비스 보안 표준과 통합된 툴킷도 제공된다.
오라클의 애플리케이션 개발 담당 수석 아키텍트 Ted Farrell은“개발자들은 비즈니스 프로세스를 통합하거나, 백엔드 서비스를 구축하거나, 웹 서비스를 공개하거나, 서비스 간에 데이터를 매핑하는 것과 같은 모든 작업을 동일한 프레임워크와 인프라스트럭처 상에서 수행할 수 있습니다. 모든 작업이 같은 툴 안에서 이루어지므로, 서로 다른 툴 간에 데이터를 이동하는 문제로 고민할 필요가 없습니다.”라고 설명한다.
기업은 또 Oracle Application Development Framework가 제공하는 런타임 라이브러리와 J2EE 디자인 패턴을 사용하여 웹 서비스를 생성하고, 플랫폼에 익숙하지 않은 개발자들이 쉽게 J2EE 개발 작업을 시작할 수 있는 환경을 구현할 수 있다. IDC의 Rogers는“Oracle Application Development Framework의 특이한 점은 SOA가 계층 단위(모델 계층, 뷰 계층, 컨트롤러 계층)로 구현되어 있다는 것입니다. 이와 같은 형태로 구상된 솔루션은 그 자체로서‘서비스 지향적’인 성격을 갖게 됩니다.”라고 말한다.
서비스가 생성되고 나면, 개발자는 Oracle Application Server의 핵심 J2EE 런타임 엔진인 Oracle Containers for J2EE (OC4J)를 이용하여 서비스의‘배포(deploy)’작업을 수행할 수 있다. 그 밖에도 Oracle SOA 솔루션에 포함된 Oracle Application Server TopLink는 스키마 또는 테이블을 Java 오브젝트로 매핑하기 위한‘Object-Relational Persistence’아키텍처를 제공한다. Oracle Application Server TopLink는 매핑 정보를 XML 파일에 캡처하며, POJO(Plain Old Java Objects), EJB(Enterprise Java Beans)와 같은 다양한 지속성(persistence) 모델을 지원한다.
마지막으로, 이러한 서비스를 비즈니스 프로세스 워크플로 우에 통합하기 위한 툴로 Oracle BPEL Process Manager가 제공된다. OASIS 표준을 기반으로 구현된 Oracle BPEL Process Manager는 그래픽 방식의 모델 기반 접근방식을 통해 서비스를 손쉽게 통합하고 연결할 수 있는 환경을 구현한다.
개발 툴의 기능이 아무리 뛰어나다 해도, 개발 툴만으로 SOA 성공을 보장할 수는 없다. 실제 환경에서 서비스를 효과적으로 구현하려면 숙련된 개발 인력이 필요하다.“ IEEE SOA 관련 활동에 참여했던 저도, 비용효율적이지 못한 SOA 프로젝트 사례를 여러 차례 경험한 일이 있습니다.”라고 Davydov는 말 한다.“ 기술적인 측면에서는 프로젝트가 매우 흥미롭게 보였습 니다. 하지만 비즈니스 측면에서는 한 푼도 도움이 되지 못했습 니다.”컴포넌트 기반의 CORBA IDL 인터페이스를 SOA의 WSDL(Web Services Description Language) 인터페이스로 단순 변환하는 경우, 효율적이지 못한 서비스가 생성될 수 있다고 그는 지적한다.“ 때로 개발자들은 CORBA의 사고방식으 로 SOA에 접근하려 합니다. 매우 엄격하게 정의된 인터페이스를 생성한 다음, 그것을 웹 서비스를 통해 공개하는 방식을 사용 하는 거죠. 하지만 이러한 환경에서 레거시 애플리케이션과 맞먹는 수준의 성능을 구현하려면 매우 고가의 하드웨어를 사용해 야만 합니다. 결국 돈만 잃고 효과는 보지 못하는 악순환이 시작 됩니다.”
SOA 개발 방법론에 근거한 새로운 사고 방식으로 이러한 악순환의 고리를 끊을 수 있다는 것은 매우 다행스러운 일이다. 전문가들이 이야기하는, SOA 성공을 위한 6가지 핵심 요건은 다음과 같다.
1. 비즈니스를 이해하라
Aloha Airline은 차세대 고객중심형 애플리케이션을 개발하기 위한 기반으로 SOA 서비스를 활용하고 있다. Burkhart는 SOA 환경의 개발 작업을 시작하기에 앞서, 비즈니스 우선순위를 정의하는 작업을 진행했다. Burkhart는 먼저CEO 및 각 비즈니스 사업부의 리더들과 만나, 비즈니스 성장에 필요한 요건 이 무엇인지 논의했다.“ 각 사업부의 예산 집행 과정에 직접 관여하면서, 그들이 갖고 있는 비즈니스 요구사항과 목표를 분명 하게 파악할 수 있었습니다. 이러한 작업을 완료한 다음, 그들의 요구사항을 해결하기 위해서 어떤 IT 기능을 구현해야 하는지 검토하였습니다.”그런 다음, 그는 기존 테크놀로지 인프라스트 럭처의 장점과 단점을 평가하고, 기업의 비즈니스 목표 달성을 위한 테크놀로지 로드맵을 작성하였다.
Aloha Airlines의 테크놀로지 로드맵은 메인프레임 클라이언트를 웹 기반PC 환경으로 전환하고, Oracle Database 10g를 이 용하여 중앙 데이터 저장소를 구현하는 내용을 골자로 하고 있다. 또 이러한 인프라스트럭처 기반 환경에서 Oracle JDeveloper를 사용하여 새로운 승객 예약 시스템을 개발하는 계획이 입안되었다. 새로운 예약 애플리케이션이 제공되는 웹 서비스를 이용하여 Aloha Airline의 기존 프로그램과 EDS가 제공하는 백엔드 예약 시스템을 통합하는 것으로 결정되었다.
Burkhart는 10만 달러의 투자가 수반되는 이 프로젝트를 통해 1백만 달러에 달하는 비용을 절감할 수 있으며, 업무 효율성의 개선을 통해 매년 1백만 달러를 추가적으로 절감할 수 있을 것으로 예측하고 있다.“ 저는 언제나 경성 비용(hard cost) 의 관점에서 절감 효과를 따집니다. 영업과 매출이 증가할 것을 가정하여 장밋빛 그림을 그려볼 수도 있을 것입니다. 하지만 운영 비용을 확실하게 절감할 수 있다면, 매출 효과와 같은 부수적인 결과는 자동적으로 따라올 것이라고 믿습니다.”
2. 상향 방식과 하향 방식을 조화시켜라
서비스를 생성하는 본격적인 작업을 시작하기 전에, SOA 개발자들은 서로 상반되는 두 가지 개발 접근법을 어떻게 조화시킬 것인지 고민해야 한다. 하향(top-down) 방식은 일반적으로 서비스를 완전히 새롭게 구축하는 경우에 활용되는 반면, 상향 (bottom-up) 방식은 기존 애플리케이션을 SOA 환경에 통합하는 경우에 유용하게 활용된다.
하향 방식을 사용하기 위해서는 비즈니스 요구사항을 철저 하게 분석하는 과정이 선행되어야 하며, 특히 이 과정에서 기술 담당자와 비즈니스 담당자 간의 협력을 통해 서비스를 명확하게 정의하고, 서비스에 필요한 기술적 요소를 적용하는 작업이 수 반되는 것이 일반적이다. 반면 상향 방식에서는 기존 소프트웨 어 환경에 대한‘발견(discovery)’과정을 통해 가장 많은 잠재력과 활용가치를 내재한 소프트웨어 컴포넌트가 무엇인지 확 인하는 작업에 초점이 맞춰진다.
Davydov는 두 가지 중 하나만을 선택하는 극단적인 방법 대신, 모든 종류의 서비스에 대해 두 가지 전략을 혼합적으로 사용하는 전략을 선택하는 것이 바람직하다고 조언한다.“ SOA 환경에 기존 애플리케이션을 통합하려는 경우에도 두 가지 방법론을 조합한 접근 방식만이 성공을 보장할 수 있습니다. 단순한 생각으로‘그래, 기존 애플리케이션의 목록이 여기 있으니까, 뒤져보면 내게 필요한 애플리케이션을 발견할 수 있을 거야’라고 말하는 것은,‘ 여기 쓰레기 더미가 있으니까 쓸만한 물건을 찾아낼 수 있을 거야’라고 말하는 것과 똑같습니다.”
신중한 고려 없이 레거시 애플리케이션을 무작정 재활용 하는 경우, 비즈니스 여건이 변화하는 경우에도 코드를 쉽게 수정하지 못하는 문제가 발생하게 된다.“ 기존 서비스를 재활용하는 것은 좋습니다. 하지만 다른 프로젝트에서도 그 서비스를 활용할 수 있게 하려면, 서비스에 새로운 기능을 추가해야만 합니다.”라고 Davydov는 말한다. 하향 방식에서도 마찬가지 원칙이 적용된다. 개발자는 새로운 서비스를 재활용 할 수 있는 가능성에 대해 계속적으로 고민해야 한다.
SOA 관련 표준
•
BPEL (Business Process Execution Language) : 서로 다른 서비스를 엔드투엔드 비즈니스
프로세스에 조합하기 위한 표준. . J2EE 1.4 : Java 2 Platform, Enterprise Edition의 최신
버전으로, 웹 서비스의 구현 및 관리를 위한 API를 제공.
• JSR 168 : 포탈 및 포틀릿 호환성을 위한 표준.
• JSR 181 : 웹 서비스 메타데이터 주석 기능을 위한 API.
• SOAP (Simple Object Access Protocol) : 애플리케이션 간의 정보 교환을 위한 W3C 표준.
• UDDI (Universal Description, Discovery, and Integration) : 웹 서비스 레지스트리의 정의를 위한 OASIS의 표준 사양.
• WS-I (Web Services Interoperability) : 플랫폼, 시스템, 언어 간의 웹 서비스 호환성을 촉진하기 위한 개방형 표준 기구.
• WS-Reliability (Web Services Reliability) : SOAP 메시지 교환을 위한 SOAP 기반 프로토콜 (메시지의 전달 및 전달순서 보장).
• WS-Security (Web Services Security) : 웹 서비스 환경의 데이터 무결성, 보안, 인증을 위한 SOAP 기반 프로토콜.
• WSDL (Web Service Description Language) : XML을 이용하여 웹 서비스를 정의하기 위한 W3C 표준.
• WSIF (Web Services Invocation Framework) : 웹 서버 환경에서 WSDL을 이용하여 EJB를 기술하기 위한 개방형 표준.
• WSRP (Web Services for Remote Portlets): 원격 웹 서비스를 포탈에 통합하기 위한 OASIS 표준.
• XML (Extensible Markup Language): 웹 서비스를 위한 데이터 마크업 언어.
3. 빠른 결과를 얻어내라
SOA 기반 서비스의 호환성과 재활용성은 비즈니스의 상황 변화에 신속하게 대응할 수 있는 환경을 보장한다. 하지만 Burkhart는 개발 프로세스를 제대로 관리하지 않는다면, 새로운 애플리케이션의 효과가 바로 나타나기 어렵다고 말한다. Burkhart는 30일, 60일, 90일 단위로 애플리케이션 개발 성과를 측정할 것을 권장한다.“ 예를 들어, 30일 내에 프로토타입을 얻어냈다면, 60일 이내에 파일럿 시스템의 구축을 완료해야 합니다. 또 90일 이내에 운영체제로 전환할 수 있어야 합니다. 5년의 ROI 기간을 필요로 하는 8개월 또는 24개월 단위의 전략을 사용하기에는 시장 상황이 너무나 빠르게 변하고 있습니다. 그 때쯤이면 이미 회사가 망해버렸을지도 모르는 일입니다.”
4. 오버헤드를 주의하라
SOA 전략의 구상이 완료되었다면, 이제 서비스의 구현 작업을 본격적으로 시작할 차례이다. 오늘날의 서비스 환경은 일반적으로 SOAP, WSDL과 같은 개방형 표준을 기반으로 하고 있다. 웹 서비스 표준을 준수하는 경우 개발 작업이 한층 쉬워지며, Java, .NET 등 어떤 환경에서도 효과적으로 동작할 수 있는 서비스를 구현할 수 있다. Begoli는“서비스 중 일부는 다양한 플랫폼을 지원할 수 있도록 작성되어야 합니다. 이러한 경우 SOAP 기반 웹 서비스가 가장 적절한 선택이 될 수 있습니다.”라고 말한다.
하지만 SOAP/WSDL에 기반한 서비스를 생성하는 것이 유일한 발안(또는 최선의 대안)이 아닐 수도 있다. 어떤 경우에는 개발자가 웹 서비스 인터페이스뿐 아니라 네이티브 웹 서비스를 직접 개발해야 할 수도 있다. 오라클의 웹 서비스 및 UML 담당 수석 프로덕트 매니저 Guus Ramackers는“예를 들어, BPEL에서는 외부 웹 서비스를 호출하여 데이터를 얻어낸 후, 이 데이터를 가공하고 변환한 결과를 다른 외부 서비스를 통해 공개할 수 있습니다. 이제 이러한 프로세스에서, 개발자가 개발한 코드를 직접 호출하기를 원할수 도 있습니다. 개발자가 고객 데이터를 검증하기 위한 EJB를 구현한 경우를 가정해 봅시다. 가장 일반적인 방법은 EJB를 웹 서비스로 변환하고 BPEL에서 이를 호출하는 것입니다. 이러한 방법을 써도 프로세스는 정상적으로 동작합니다.”라고 설명한다.
5. 미래를 위해 준비하라
SOA의 중요한 장점 중 하나로, 웹 서비스 개발자의 작업 결과 가 단일 프로젝트에 한정되지 않는다는 점을 들 수 있다. 호환성이 보장된 환경이라면, 다른 프로젝트의 초기 개발 단계에서 기존에 개발된 서비스를 연결하여 활용하는 것이 가능하다. 하지 만 그러기 위해서는 사전 준비가 필요하다. 소프트웨어를 제한 적으로 활용할 계획만 가지고 있다 하더라도, 미래의 요구사항에 대비할 필요가 있다. Davydov는“애플리케이션이 10명의 동시 사용자를 지원한다면,‘ 왜 이런 문제를 미리 걱정해야 할까’라고 생각할 수도 있습니다. 하지만 개발자가 매력적인 서비 스를 개발해냈다면, 이 서비스가 전체 기업 환경에서 활용될 가 능성도 그만큼 높아집니다. 따라서 10 명의 동시 사용자 환경이 나중에는 수천 명의 동시 사용자를 지원하는 환경으로 발전될 수도 있습니다. 서비스를 개발할 때에는 언제나 더 넓은 안목을 가져야 합니다.”라고 설명한다
하지만 이러한 방법에는 프로세싱 오버헤드가 수반된다. 웹 서비스가 호출되는 과정에서 프로그램은 네트워크를 통해 전송 될 XML 메시지를 생성한다.“ 메시지가 상대방에 도달하는 시 점에, 바인딩 작업을 위해 다시 매핑을 수행해야 합니다. 하지만 이미 같은 기능이 내부적으로 구현되어 있는 경우라면, 굳이 웹 서비스를 활용할 필요가 없을 것입니다. 내부 기능으로도SOAP 및 XML 기반 프로세싱을 수행할 수 있기 때문입니다. 하지만 이러한 과정에서 불필요한 시간이 낭비됩니다.”라고 Ramackers는 말한다. 이와 같은 방법의 대안으로 Web Services Invo-cation Framework(WSIF)를 활용할 수도 있 다. WSIF는WSDL을 이용해서 웹 서버의 EJB Impleme-ntation을 기술하기 위한 오픈 소스 표준이다.“ WSIF를 이용하는 경우, 런타임에 EJB의 Java 클래스를 호출하는 방법이 사용됩 니다. 하지만 XML 메시지를 생성하는 작업은 수행되지 않습니 다. 웹 서비스는 비즈니스 프로세스를 표준화하는 데 매우 유용한 도구입니다. 하지만 때로는 WISF 바인딩을 이용해서 더 높은 성능 을 얻을 수도 있습니다.”라고 Ramackers는 말한다.
어떤 개발자들은 SOAP와WSDL을 이용하여 웹 서비스를 개발하면, 어떤 플랫폼에서나 호환 가능할 것이라고 믿기도 한다. 하지만 그렇게 문제가 간단하지는 않다. Davydov는“개발 자들은 기술적인 측면에만 초점을 맞추는 경향이 강합니다. 많은 개발자들이WSDL 인터페이스를 사용하면 서비스의 재활용 이 언제나 가능할 것이라는 잘못된 믿음을 갖고 있습니다. WSDL 인터페이스의 형태로 공개된 API가 있는 것은 사실입니다. 하지만 인터페이스의 구현 방식, 서비스가 요구하는 데이터, 서비스가 반환하는 데이터의 성격에 따라서는 다른 프로젝트에서 전혀 활용 가치가 없을 수도 있습니다.”라고 말한다.
Oracle Application Server Containers for J2EE 담당 수석 프로덕트 매니저 Debu Panda는 호환성을 원한다면 먼저 데이터타입을 고려하라고 조언한다. 예를 들어, Java 환경에서 사용되는 데이터타입 중 일부는 .NET과 같은 다른 프로젝 트에서 지원되지 않는다.“ 호환성이 중요하다면 모든 플랫폼에 서 지원 가능한 데이터타입을 사용해야 합니다.”문제를 예방하 려면 , Web Services Interoperability Organization (WSIO)의 WS-I Basic Proile(http://ws-i.org/deliverables/ workinggroup.aspx?wg=basicprofile)에 포함된 호환성 가이드라인을 준수하는 것이 바람직하다. WSIO는 오라클 을 비롯한 여러SOA 테크놀로지 벤더에 의해 설립된 개방형 표준 기구로, Java, .NET, Linux, UNIX, Windows 등의 환경 에서 웹 서비스의 플랫폼간 호환성을 테스트하기 위한 테스팅 툴을 제공하고 있다.
6. 점진적인 작은 성과를 통해 큰 성과를 얻어내라
마지막으로, SOA를 고려하는 기업은 장기적인SOA 전략을 구현하고, 조금씩 목표를 달성해 나가는 접근법을 사용해야 한다고 Begoli는 조언한다.“ 엔터프라이즈 컴퓨팅 환경에 전면적으로 웹 서비스 표준을 적용하려는 맹목적인 사례가 발견되기도 합니다.”
Begoli는 웹 서비스를 통해 가능한 모든 문제를 한꺼번에 해결하려는 방법보다는, 장기적으로 중요성을 갖는 핵심 전략 서비스를 확인하고, 이러한 서비스를 SOA 환경에 우선적으로 구현하는 전략이 바람직하다고 말한다.“ 먼저 기업의 마인드를 제고하고 SOA의 적용 범위에 대한 이해를 도모합니다. 그리고나서 작은 승리를 얻어나가다 보면, SOA 접근에 대한 인식이 점차 확산되면서 큰 성과를 거두게 될 때가 올 것입니다.”
SOA와 그리드 환경
SOA 애플리케이션은 그리드 컴퓨팅과 일맥상통하는 개념이다.두 가지 개념 모두‘컴퓨팅 리소스를 작은 규모의 전문화된 컴포넌트로 분리함으로써 성능 및 유연성을 극대화할 수 있다’는 공통된 철학에 기반하고 있다.
Oracle Application Server 담당 프로덕트 매니지먼트 디렉터 Mohamad Afshar는“개별적인 애플리케이션, 컴포넌트, 서비스를 일련의 하드웨어 박스에 구현함으로써, 요구사항에 비례하여 점진적인 확장을 꾀할 수 있습니다. 하나의 거대한 객차만을 끌고가는 거대한 기관차를 상상해 보십시오. 이 거대한 객차에 항상 승객이 들어차는 것은 아니기 때문에 연료의 낭비가 불가피합니다. 이 거대한 객차를 여러 개의 작은 객차로 대체한다면, 사람이 많지 않은 경우에는 하나의 객차만을 사용하고 또 승객이 늘면 2 개의 객차를 연결해서 운행할 수 있습니다. 또 더 나아가 10개의 객차와 2개의 화물차를 연결하도록 기차를 설계할 수도 있습니다. 그리드 환경에서 서비스 지향형 애플리케이션을 설계하고 구현하는 방식도 이와 유사합니다.”라고 설명한다.
그리드 환경을 위한 서비스 구현 작업을 지원하기 위해 Oracle Application Development Framework는 Java 개발 환경에서 사용되는 MVC(Model/View/Controller) 아키텍처를 확장함으로써 어느 위치에서나 서비스와 데이터를 가져올 수 있는 서비스 계층(service layer)을 구현하고 있다. 이 서비스 계층은 Java, EJB, Oracle Business Components, Java Connector Architecture, 웹 서비스 등의 다양한 개발 플랫폼을 지원한다. 개발자는 WSDL을 사용하여 개발된 서비스를‘그리드 서비스’의 형태로 실행할 수 있다.
서비스가 내부 그리드뿐 아니라 외부 그리드로 확장되어야 하는 경우에는, Global Grid Forum의 GSI(Open Grid Service Infrastructure) 프로토콜이 제공하는 호환성 표준을 활용할 수 있다. OGSI는 그리드 환경에 최적화된WSDL 버전인GWSDL을 제공하고 있다.
서비스가 그리드 환경에서 구현되고 나면, 관리자는 Oracle Application Server 10g에 포함된 Oracle Grid Control을 이용하여 소프트웨어 컴포넌트들을 중앙집중적으로 관리할 수 있다. Oracle Grid Control은 서비스의 온 디맨드, 다이내믹 복제 작업을 통해 컴퓨팅 리소스를 할당하는 작업을 지원한다. 오라클의 웹 서비스와 UML 제품 수석 매니저인 Guus Ramackers는“그리드 환경이 제공하는 유연성을 활용 하여, 각 애플리케이션 그룹별로 필요한 프로세싱 자원을 결정 할 수 있습니다.”라고 말한다.
미래를 위한 효율성
여러 표준 기구의 노력 덕분에, SOA 서비스의 호환성 및 재활용성 수준은 지속적으로 개선되고 있다. 2005년에도 이러한 흐름에는 변화가 없을 것이다. 내년 초에는 J2EE 5.0 표준이 발표될 예정이다.
racle Application Server Containers for J2EE 담당 수석 프로덕트 매니저 Debu Panda는 J2EE 5.0 표준 환경에서는 디폴트 설정과‘메타데이터 주석’을 이용하여 SQL 개발 작업을 단순화하고, 배포 디스크립터의 적용을 최소화할 수 있게 될 것이라 말한다. J2EE 5.0에는 웹 서비스 메타데이터 주석을 위한 API인 JSR 181이 포함되어 있다. JSR 181은 개발자들이 인터페이스, 배포 디스크립터 등의 웹 서비스 구성 요소를 개발하는 과정에서 수반되는 복잡성을 줄여 주는 효과를 제공하게 될 것이다.
또 J2EE 5.0에 새로이 포함되는 Enterprise JavaBeans 3.0은 EJB 생성 작업을 지원하기 위한 디폴트 및 메타데이터 주석 기능을 제공한다. Panda는“지금까지는 단순한 형태의 EJB 를 구현하더라도 최소한 두 개의 인터페이스를 명시해야 했습니 다. 그 하나가 빈 클래스, 또 다른 하나는 배포 디스크립터입니 다. 또 이를 위해서 여러 가지 EJB 관련 API가 사용되어야 합니다.”라고 설명한다.
Enterprise JavaBeans 3.0에서는세션빈또는엔티티빈 등의 EJB 관련 인터페이스를 구현할 필요가 없게 되었다. Panda는“따라서 순수한 Java 클래스가 구현된 셈입니다. Stateless Session Bean이 필요하다면‘stateless’주석을 추가하기만 하면 됩니다. 배포 디스크립터를 사용할 필요도 없고, 여러 개의 인터페이스를 사용할 필요도 없습니다. 개발자의 부담이 한층 가벼워질 것입니다.”라고 말한다.
SOA의 성공을 위한 청사진
SOA 개발자들은 Middleware Company와 SOA 테크놀로지 벤더들 - 오라클을 비롯한 - 이 함께 개발한 청사진을 이용하여 서비스 생성 프로세스를 바로 시작할 수 있다(www.middlewareresearch. com/soa-blueprints).
Middleware Company의 청사진은 가상의 기업을 대상으로 하는 서비스 구축 과정을 소개하고, 개발자들이 애플리케이션 통합 프로세스를 단계별로 경험할 수 있게 한다. 그 밖에도 J2EE, .NET, 웹 서비스 등의 다양한 서비스 환경을 위한 가이드가 함께 제공된다.