좋은 개념으로 포장된 JBI로 가는 길

Java기반의 SOA의 구현에서 매우 중요한 역활을 차지하는 ESB를 이해하는데 도움이 되는 글입니다.

좋은 개념으로 포장된 JBI로 가는 길
(The Road to JBI: Paved with Good Intentions)
(http://www.theserverside.com/tt/articles/article.tss?l=TheRoadtoJBI)

by Ross Mason


논점

SOA 원칙의 채용과 ESB 관련 기술을 통한 통합이 증가하면서 SOA의 다양한 관점에서 표준을 제정하려는 노력들이 많다.(예를들어 메시징과 통신을 위하여 JMS를 사용하고, Web Service를 통하여 커뮤니케이션 하기 위하여 WS-*를 사용하는 것등)

IT에서는 일반적으로 표준이 좋지만 표준이 항상 존재하는 것은 아니다. 표준을 제정하는 과정은 때때로 경쟁관계에 있는 벤더간의 파벌싸움으로 이어져 희생자가 발생하거나 타협의 결과로 프랭케인슈타인(Frankenstein)과 같은 결과가 만들어 지기도 한다.

좋든 싫든 결과적으로 사용자는 마지막까지 살아남은 표준을 검증하여 채용한다.

JBI(Java Business Integration or JSR-208)는 엔터프라이즈 서비스 버스(ESB)의 구현을 위한 방법을 표준화하는 방안이다. 2005년 8월에 발표되었으며 JBI을 만들때 다음과 같은 많은 긍정적인 생각들이 포함되었다.

• 많은 부분들로 구성되어 있어 복잡도의 문제가 발생하는 어플리케이션 개발의 영역의 문제를 해결할 수 있도록 표준화하는데 노력했다.
• JBI 시스템과 상호작용하는 사용자의 각기 다른 역활에 대한 규격을 정하였다.
• 전체 개발에 대한 노력을 감소시키고 유지보수 비용을 절감하기 위하여 비핵심 컴포넌트의 재사용성을 높였다.

그러나 업계에서는 표준이 재정된 후에 여러 논쟁이 있었으며 벤더에서 표준으로 채용하는데 적극적이지 않았다. 어떠한 이유로 업계이서 JBI 표준을 채용하는지 않았는가? 무었이 JBI를 사용하지 않는 이유인가?

JBI는 TCP/IP가 아니다.

표준은 문제가 되는 영역을 전제적으로 이해할 수 있는 방법을 정의하는 것이다.

예를들어 TCP/IP는 네트워크 위에서 정보의 교환을 위하여 잘 정의된 실제적인 표준입니다. TCP/IP의 영역은 매우 명확하며, 프로토콜은 정확하고 단일 영역의 문제를 처리하여 준다.

사실상 각 조직내에서 상존하는 각기 다른 커스텀 어플리케이션과 기술 및 인프라스트럭쳐의 차이가 통합의 문제를 만들어 냈습니다. 더욱이 이러한 것들은 대부분 항상 일정 수준이상 변경할 수 없다.

이러한 문제의 핵심은 많은 독점적인 통합 솔루션 (EAI brokers, ESBs, SOA suites)가 생긴 이래로 부정확하게도 조직은 편리하게 어플리케이션을 개발할 수 있거나 교체할 수 있는 조각으로 만들어 진다는 가정을 한다.

JBI는 종이호랑이에 불과한데 미들웨어 벤더에 의하여 미들웨어 벤더를 위한 "표준"을 작성하였기 때문이다. 일반적으로 JBI 요구되는것보다 더 많이 문제 영역을 관장합니다. 이로인해 벤더는 개발비용이 더 많이 사용한다.

통합의 표준화를 위한 영역에서 JBI는 좋은 점수를 얻지 못하고 있다. 왜냐하면 JBI는 TCP/IP가 아니기 때문이다.


통합을 위한 강제화는 나쁘다.

통합에 대하여 이야기할때 최고의 가치는 연관된 시스템간을 접착시키는 것이다. 이러한 접착은 광범위한 통합과 SOA 시나리오를 위하여 최대한 유연하여야 한다.

JBI는 서비스를 호스트하는 컨테이너를 표준화할 수 있도록 시도하였으며 서비스간에 바인딩을 하고 서비스를 연결해주고 어떻게 서비스를하고 바인딩을 로드하는지에 관한 컨테이너이다. 표면적으로는 이러한 이야기들은 아주 좋은 아이디로로 들린다.

문제는 API 주변의 모든 이러한 엘리먼트를 바탕을 어떻게 데이타를 주변으로 전달할것인가? 어떻게 서비스들을 이러한 인터페이스 계약에 의하여 확장할 것인가? 그리고 어떻게 사람들은 서비스를 작성할 것인가에 대한 가정을 하면서 시작된다.
이러한 가정은 이러한 것들의 강제된 것과 같이 묶어두는데 우리는 이러한 것이 나쁜 통합이라는 것을 알고 있다.

이러한 가정에 포함된 내용은 다음과 같다.

• XML 메시지는 데이타에 관한 것들을 옮기는데 사용될 것이다. 몇몇시스템에서는 이러한 가정은 옮지만 XML이 탄생하기 전에 구축된 대부분의 레가시 시스템은 Cobol의 CopyBook, CSV, 바이너리 레코드, 사용자 정의 평문 파일 등과 같은 다양한 메시지 타입을 사용한다.
  
• 데이타의 이동은 항상 XML 기반이다. 이동은 통합에 있어 매우 중요한 요소이다. JBI 스펙은 모든 이동은 Java XML Transformation 프레임웍을 사용하여 구축될 것이라고 가정한다. 이것은 매우 중대한 제한이다.
  
• 서비스 계약은 WSDL일 것이다. 첫번째 가정과 짝을 이루는 가정인데 XML 중심과 웹 서비스 중심의 관점이 문제이다. 예를 들면 엔터프라이즈 백엔드 미들오피스 통합(enterprise back- and middle-office integration)은 웹 서비스를 필요로하지 않으며, 일반적인 성능과 확장성이 필요하다. 덧붙여서 이러한 가정은 Java Annotation이나 WSDL 및 Java Interface에 대한 부분들에 대한 서비스 계약 정의를 고려하지 않는다.
  
• 메시지 스트리밍은 필요하지 않다. JBI를 통하여 스트림 메시지들을 사용하는 것은 쉽지 않다. 몇몇 벤더들은 스트리밍을 지원하는 API에 대한 작업을 하였지만 주어진 API의 목적을 해치는 시도이다.
  

컴포넌트 재활용에 대한 신화

JBI를 판매할 경우에 가장 큰 장점은 표준화된 컴포넌트를 재활용하여 개발 비용을 감소시켜준다는 것이다. 하지만 오늘날까지 JBI의 재활용은 매우 제한적이다.

예를 들어 이러한 표준을 위한 서비스 엔진(Service Engines)들과 바인등 컴포넌트(Binding Components)들은 공통화되지 않았다. Sun은 JBI로 J-Way 커넥터를 포팅하여지만 아직까지 어떠한 벤더도 지원하고 있지 않다.

각각 벤더들은 JBI 스펙을 채용하여 자신의 JMS, FILE, HTTP, FTP와 같은 각각의 바인딩 컴포넌트를 작성하였다.

따라서 벤더간의 호환성을 가진 재활용 JBI는 요원한 것이다. 근본적으로 벤더들은 서로 경쟁하기 위하여 자신만의 각기 다르게 구현하고 있다.



표준화는 쓸모없는 것인가?

JBI를 통하여 표준화에 대한 문제를 확인하였을 것이다.

XML 설정에 한 부분인 Service Component Architecture(SCA)는 옭은 방향으로 나아가고 있는 것처럼 보인다. 하지만 일부 사람들은