Warning: Unexpected character in input: ''' (ASCII=39) state=1 in /webroot/libs/skin/post_widget_data.php(976) : eval()'d code on line 1 Parse error: syntax error, unexpected T_STRING in /webroot/libs/skin/post_widget_data.php(976) : eval()'d code on line 1 calmglow (최진호)

calmglow (최진호)

calmglow.egloos.com
포토로그

adsense(728_90)

차를 술삼아

조금 일찍 퇴근하여 돼지우리에 왔습니다.
겨우내 꼼짝않고 누워 잠만 자던 돼지 우리.
우리 안의 사물들도 겨우내 추워 거의 움직이지 않았습니다.
조금 한기가 있지만 모든 창문을 활짝 열고
아닌 밤 중에 대청소를 합니다.
아직 봄이었던 적 없었던 듯
어서 봄이 오라고 재촉하듯
창문 활짝 열고 깨끗하게 단장합니다.

그리고 오랜만에 차를 오래고 오랜 다정한 벗 삼아 ,
차를 걸쭉한 술 삼아 벌컥벌컥 마십니다.

태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

괜찮은 XSLT 편집기 추천해주세요 Enterprise

이 블로그가 별로 인기없기는 하지만, 그래서 여기에 질문을 올리는 게 적당치는 않은 것 같지만
혹시나 해서 이 블로그에 오시는 분들에게 질문드려봅니다.
상용이든 공짜 소프트웨어이든,
괜찮은 XSLT 편집기 좀 추천해주세요.ㅜㅜ

태그 :

공유하기 버튼

 
트랙백(0)덧글(2)

REST를 위한 라이브러리. RESTlet Enterprise

내가 누누히 이 블로그에서 강조하는 기술 중의 하나는 REST이다.
실제로 이 REST를 적용하여 프로젝트를 해본 결과 너무나 간단하게 상호간의 통신을 자유롭게 할 수 있었고 플랫폼에 여의치 않고 어떤 컴포넌트와도 통신하는 것이 가능하였기 때문에 그 가능성을 높이 사는 것이다.
실제로 아직 외국에서는 REST와 SOAP간에 서로 누가 좋다 나쁘다 하면서 경쟁을 하고 있고 JBI에서도 REST 프로토콜이 기본적으로 지원될만큼 REST는 간단한 개발과 SOA환경을 위해 꼭 추천하고 싶은 기술이다.
이 사용하기 편한 REST를 보다 더 편하게 사용할 수 있는 라이브러리가 나와서 추천한다.
RESTlet이다.
웹서비스 기술에 관심 많은 이들의 많은 적용을 바란다
http://www.restlet.org/


태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

SCA (Service Component Architecture) 개요 Enterprise

바로 이전 블로그에서 JBI의 개요를 설명하였다. JBI의 구조나 기타 여러가지 하고 싶었던 말은 마소 3월호에 나오거나 나중에 틈틈히 이 블로그에서 다루기로 하고 이번에는 JBI와 함께 SOA환경에서 서비스 개발 환경을 혁신적으로 강화시켜줄 SCA라는 물건에 대해 한번 알아보자. 역시 개요다. ㅋㅋ

SCA는 SOA환경에서 자신이 원하는 비즈니스 서비스를 쉽게 개발하기 위한 새로운 차원의 프로그래밍 모델이다. 이 표준은 2005년 11월 30일에 IBM과 BEA 그리고 오라클 등의 수많은 소프트웨어 벤더들의 주도로 발표되었다. 이 SCA의 주된 용도는 SOA세계에서의 애플리케이션 과 복합 애플리케이션(Composite Application: 기업 내에 존재하는 통합되어야 할 애플리케이션. 단순한 통합이 아닌 기업 비즈니스 프로세스에 의해 유기적으로 연결되는 방식의 애플리케이션을 일컫는다.) 개발에 따르는 어려움을 해결하기 위함이다. 즉, SCA의 목표는 SOA 환경에서의 애플리케이션 개발을 좀 더 쉽게 하자라는 것이며 SCA는 특정 프로그래밍 언어나 특정 미들웨어의 API에 연연하지 않고 그러한 애플리케이션들을 묶어서 SOA환경에서 실행하고 관리할 수 있는 환경을 제공한다.

SOA 환경에서의 기업 내의 이기종 서비스들을 연계하여 유연한 서비스 컴포넌트를 개발하는 과정을 상상해보자. 기업 내에는 다양한 컴포넌트와 프로토콜 그리고 프로세스들이 존재하며 이러한 여러 서비스들을 Top-Down 방식으로 조직화하는 일련의 과정이 표준화되어 있지 않다면 유연한 기업 환경을 기대할 수 없을 것이다. 즉, 기업 내의 모든 IT 리소스들을 그 구현 형식과 내용에 관계없이 통일된 방식으로 표현하여 그들간의 애플리케이션 조립(Application Composition)을 위한 런타임 인프라스트럭쳐를 제공하는 것이 SCA의 목적인 것이다. 따라서 SCA에서 가장 최소한의 단위는 서비스 컴포넌트이며 이 서비스 컴포넌트는 비즈니스 프로세스나 비즈니스 룰, 자바 구현물이나 그 외 다양한 구현물에 대한 추상화된 컴포넌트라고 할 수 있으며 이러한 서비스 컴포넌트가 묶여서 서비스 모듈이라는 단위가 SCA의 완성된 모습이라 할 수 있다.

WSDL이 애플리케이션들간의 상호운영성을 높여주는 진일보된 기술로 자리매김하고 있으나 WSDL은 오직 단일 서비스의 인터페이스에만 초점을 맞추고 있을 뿐, 이 서비스가 다른 서비스들간에 어떠한 정책과 의존성으로 관계를 맺고 있는지에 대한 것을 보여주는 데에는 한계가 있다. SCA가 WSDL에 더하여 보완하려하는 것은 바로 WSDL의 한계를 넘어서 여러 서비스들을 엮어서 비즈니스 컴포넌트로 정의할 수 있는 모델을 만들고자 하는 데에 있다. 이를 바로 서비스 컴포넌트라 부르며 서비스 개발자는 SCA의 서비스 컴포넌트를 통해 서비스에 대한 인터페이스 설계뿐만 아니라 서로 다른 서비스들간의 관계와 의존성(트랜잭션, 보안, 신뢰성있는 전송 등등등)등에 대한 설정을 아주 쉽게 해낼 수 있게 된다. 이는 개발자의 SOA환경에 놀랄만큼 편리함을 주는 것으로서 이제 더이상 특정 벤더의 독점적인 방식으로 각각의 서비스들에 대한 관계를 기술하거나 그러한 내용을 서비스 구현 자체에 포함시키지 않아도 표준적인 방식으로 관리하는 것이 가능해졌기 때문이다.

릴리즈 된 지 얼마 되지 않은 표준임에도 불구하고 얼마 안있어 우리는 SCA 구현물을 아파치 프로젝트를 통해 만날 수 있을 것으로 보인다. 아파치 인큐베이터에서는 자바와 C++ 기반의 SCA 엔진 구현을 목표로 Tuscany라는 프로젝트가 진행 중이다. 앞서 언급한 대로 SCA는 특정 언어에 독립적인 표준이기 때문에 자바 이외에 C++ 혹은 C# 그리고 php 등의 다양한 프로그래밍 언어로 이루어진 환경에 적용하는 것이 가능하다.

또한 이클립스에서도 SCA 기반의 SOA 개발 환경을 접할 수 있을 것이다. SCA가 결국 서비스 개발자를 위한 환경임을 생각할 때 가장 널리 사용되고 있는 IDE중의 하나인 이클립스에서 공식적으로 이 SCA가 SOA 기반의 개발을 위한 기본 플랫폼으로 채택되었다는 것은 SCA의 장래를 밝게 해주고 있다. 이 프로젝트는 SOA Tools Platform(STP) 이라는 이름으로 진행 중이다.



태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

JBI(Java Business Integration (JBI : JSR 208)의 개요 Enterprise

이제까지 EAI 제품들은 대부분 제각기 서로 다른, 표준이 아닌 각자의 기술로 구현되었고 이러한 결과로 현재 통합에 있어 큰 문제를 야기하고 있다. 어떠한 단일 기업도 EAI에 대한 통합 솔루션을 제공할 수 없음을 고려해볼 때 이것은 결국 사용자의 입장에서는 엄청난 부담으로 다가올 수 밖에 없다. 아무리 근래의 EAI의 방향이 웹서비스라는 표준을 기반으로 움직이고 있다고 하나 이러한 웹서비스들 간의 비즈니스 통합과 이기종간의 통합을 위한 아키텍처는 여전히 EAI 솔루션 벤더들의 독자적인 몫으로 남겨지다 보니 차세대 EAI 시스템 역시 서로 다른 아키텍처로 인한 통합의 문제는 고스란히 사용자에게 전가될 수 밖에 없는 것이다.

이러한 문제를 해결하기 위한 대안이 바로 엔터프라이즈 서비스 버스 (ESB)라는 개념이며 이는 기존의 다양한 통합기술을 활용하면서도 시스템간 연동을 위한 대형 도로를 만드는 작업이다. 처음 ESB라는 개념이 제안되었을 때에는 이것이 단순히 시스템 통합을 위한 아키텍처 모델 정도로 시작되었으나 점차 SOA환경에 대한 관심이 높아지자 많은 IT벤더들이 SOA 환경 구축을 위한 필수 통합 플랫폼으로서 제품을 내놓기 시작하였다. 특히 엔터프라이즈 시장에서 막강한 영향력을 행사하고 있는 자바 기술 기반의 벤더들이 가장 활발하게 진행중인 상황에서 각 벤더들간의 ESB에 대한 표준의 필요성을 인식하게 되었다. ESB라는 것이 향후 가장 핵심이 되는 인프라스트럭쳐가 될 것으로 예상된다면 ESB의 아키텍처에 대한 표준을 제정하여 보다 많은 벤더들의 참여를 보장하자는 것이 자바 진영의 의견이다. 이러한 자바 진영에서의 고심의 결과가 바로 Java Business Integration (JBI: JSR208)이며 통합 솔루션들을 위한 메타 컨테이너의 개념으로서 자바 진영이 제안하는 인프라 스트럭쳐이다. 이 인프라스트럭쳐는 어떠한 벤더의 제품이더라도 플러그인 형식으로 JBI 표준을 준수하는 시스템에 적용될 수 있으며 이 JBI 기반의 엔터프라이즈 환경을 구축한 사용자라면 훨씬 더 폭넓은 선택의 기회를 잡을 수가 있게 되는 것이다. JBI와 같은 개념의 표준과 기술은 이제까지 줄기차게 제기되어 왔으며 JBI가 낯설고 참신한 시도라고 할 수는 없을 것이지만 JBI가 그 기반으로서 웹서비스와 SOA를 갖고 있으며 아울러 많은 기업들이 자바 환경으로의 대 이전을 고려하고 있는 이 시점에 있어서 JBI는 그 가능성을 충분히 내재하고 있다고 할 수 있다.

JBI의 참여 업체 및 제품

JCP가 자바 진영에서 차지하는 영향력을 생각해볼 때 거의 대부분의 EAI 관련 IT업체들과 단체들이 이 JBI에 참여하고 있다. 즉, 썬 마이크로시스템즈와 오라클 그리고 소닉이나 팁코등의 단체와 아파치와 JBOSS같은 오픈소스 단체들이 포진해있다. 현재 JBI 기반에서 출시된 혹은 개발 중인 구현체에 대한 목록을 살펴보면 특히 이 JBI가 자바 오픈소스 진영에서 열렬한 환영을 받으며 그 세력을 키워나가고 있는 만큼 JBI의 미래는 매우 밝다고 할 수 있다. 이는 자바 진영에서 현재 IT 업계에서 화두가 되고 있는 ESB에 대한 오픈 소스 개발자들의 높은 관심을 반영하는 것이라고 할 수 있겠다.

가장 활발한 관련 오픈소스 프로젝트만 해도 두 세개가 꼽힐만 하지만 그 중에서 아파치 인큐베이터 프로젝트로 진행 중인 ServiceMix는 올해 가장 높은 관심을 불러일으킬 것으로 예상된다. 이 ServiceMix에 대해서는 3부에서 자세하게 다룰 것이지만 여러 오픈소스 단체 및 오픈소스 협력 업체가 합심하여 진행되고 있는 만큼 올해 상당한 진전이 예상된다. 이 외에도 썬 마이크로시스템즈에서는 Open ESB라고 하는 JBI 구현체+확장 기능을 다루는 오픈소스 프로젝트를 진행 중이며 기존의 JBoss Messaging에 JBI를 적용하는 프로젝트를 진행 중이고 SymphonySoft라는 회사에서 진행하고 있는 오픈소스 프로젝트인 Mule 역시 JBI 표준을 따르는 ESB 구현체이다.

오픈소스 진영에 비해 IT 벤더를 통해 출시된 JBI 구현체는 상대적으로 빈약한 편이다. 현재 썬 마이크로시스템즈는 2006년 봄에 JBI를 적용한 Sun Java Enterprise System 5.0 제품을 선보일 예정이다. 그리고 JBI 표준에 참여하고 있는 10여개의 업체들이 올해 안에 JBI 표준을 준수한 SOA 플랫폼이나 툴등을 발표할 계획에 있다. 다만 눈여겨 볼 것은 가장 막강한 영향력을 가지고 있는 IBM과 Bea가 이 JBI 표준에 참여하지 않고 있다는 점인데 이 부분에 대해서는 얼마 전의 블로그에서도 설명한 바가 있다.



태그 :

공유하기 버튼

 
트랙백(0)덧글(2)

SOA와 ESB가 꼭 필요해? Enterprise

정말 많은 사람들은 SOA는 세일즈 구라쟁이들의 새로운 무기일 뿐이고 포장만 그럴듯하게 한 개념이라고 말한다. 더구나 ESB라는 것은 그저 EAI의 아키텍처 형태일 뿐인데, 이미 있던 걸 가지고 다시 이름만 바꿔서 판매하려 들고 있다고 말한다. 일면 타당한 면이 많은 것도 사실이다. 그러나 SOA나 ESB가 주목을 받고 있는 데에는 결코 IT 벤더들의 마케팅의 힘만은 아니다. 이것은 분명 IT업계가 당면한 현실이고 그렇기 때문에 많은 사용자들이 SOA와 ESB에 관심을 갖고 지켜보고 있는 것이다. 한 기업의 예를 들어서 왜 SOA와 ESB가 기업에서 각광을 받고 있는 아키텍처가 되고 있는지를 설명해보겠다.

'띠바기업'은 보험업계에서 상당한 입지를 구축하고 있는 회사이다. 이 회사 IT 자산들의 중요한 부분은 여전히 메인 프레임으로 돌아가고 있으며 일부 신규 서비스에 한해서만 웹기반, J2EE 환경에서 운영되고 있다. 이 회사에 최근 새롭게 도입되거나 재개발된 서비스에는 CRM이나 콜센터 서비스 등이 있다. 이 띠바기업은 상당히 많은 업무들이 여전히 메인 프레임 위주로 운영되다보니 이로 인한 비용이 천문학적인 수준에 달하고 있다. 이 호스트 기반의 운영에 익숙한 IT부서 사람들은 이러한 천문학적인 비용에도 불구하고 쉽게 오픈 환경으로의 이전을 주저하고 있다. 비록 비용은 덜 들지라도 확실히 메인 프레임 기반의 운영이 안정적이고 관리하기가 편하기 때문이다. 그들이 이미 목격해본 바에 따르면 J2EE 기반의 서비스들은 너무나 불안정하며 관리하기도 어렵다.
분산 환경이 아닌 중앙 집중식 환경인 메인프레임 기반의 운영을 경험한 이들은 분산 환경 기반의 J2EE가 낯설고 복잡할 수 밖에 없다. 메인 프레임은 그저 한 화면에서 모든 것을 관리할 수 있었다. 문제가 발생한다 해도 원인이 무엇인지를 찾기란 정말 쉽다. 트랜잭션이 어디서 걸리고 있는지도 한 눈에 보인다.
그런데 분산 환경으로 오니 가장 걸리는 것이 관리 운영이다. 스레드 기반으로 트랜잭션이 처리되다 보니 이것이 대체 어느 서버의 어느 레이어에서 문제가 발생하고 있는지 찾아내기가 너무나 어렵다. 더구나 새로운 서비스나 솔루션이 도입되면 이것이 전체 시스템의 복잡도를 증가시키고 관리의 어려움 뿐만 아니라 연결의 상호운영성 문제도 항상 발생할 수 밖에 없다. 연결의 상호운영성? 그렇다. 이들이 메인프레임에서 분산 환경으로의 이전을 고려하는 이유중의 하나는 회사 내에 존재하는 수많은 서비스들을 자유롭게 연계하여 보다 유연한 환경을 만들고자 하는 목표가 있었다. 즉 비즈니스 프로세스에 기반하여 각각의 자원들을 관리하고 엮어서 쉽게 회사의 비전과 전략에 맞추어 IT자산을 활용하자는 데 있었던 것이다. 그런데 회사 자산들은 서로를 모르며 서로와 친해질 마음이 전혀 없어보인다. 몇몇 IT벤더들은 EAI솔루션을 들고 나오며 온갖 미사어구를 사용하여 통합의 장점을 이야기 하지만, 운영 관리자 입장에서 보면 여전히 분산 환경에서의 운영 환경은 최악이며 상호 운영성도 보장할 수 없다.
이러한 띠바기업과 같은 상황에서 고려할 수 있는 최선의 방법은 SOA이며 ESB환경이다. ESB는 회사 자원들을 모두 Bus라는 경유지에 집합시키며 이들간의 관계와 프로세스를 정리해준다. 또한 이들의 상태를 한눈에 확인할 수 있으며 상호운영성의 문제를 해결해줄 수 있는 것이다. 설사 향후 띠바기업에 어떤 새로운 솔루션이나 서비스가 개발되어도 띠바기업의 IT환경은 복잡도가 증가하는 것이 아니라 가능성과 유연성의 증가를 가져오게 될 것이다.
위의 예는 결코 낯설고 이상적인 이야기가 아니다. 현재 많은 기업들이 당면하고 있는 이야기이고 궁극적으로 SOA와 ESB를 도입할 수 밖에 없게하는 이야기인 것이다.

태그 :

공유하기 버튼

 
트랙백(0)덧글(2)

SCA(Service Compoent Architecture)와 JBI (Java Business Integration) 그리고 SDO의 관계 Enterprise

앞으로 이 블로그에 한동안 중심 주제 중의 하나로 다루게 될 SCA와 ESB 및 JBI에 대한 첫번째 블로그이다.
SCA는 IBM과 BEA 오라클 등의 대형 벤더들이 힘을 합쳐 좀 SOA 개발 편하게 해보자고 만들어진 프로그래밍 모델이다. 엄밀하게 말하자면 서비스 개발자를 위한 표준이고 그 기반은 SDO (Service Data Object)가 되겠다. SDO는 모든 데이타에 대하여 동일한 관점에서 처리할 수 있도록 추상화시켜놓은 웹서비스 시대의 POJO라고 보면 되겠다. 이 SCA와 JBI간의 관계에 대해서 경쟁 관계다 혹은 공존 가능한 관계다 해서 말이 많지만 내부적으로 들어가보면 대형벤더들과 아직 EAI시장에서 큰 힘을 발휘하지 못하는 소형 벤더들간의 싸움일 뿐이고 앞으로 추세를 보면 아마도 JBI에 SCA가 추가되는 형태로 JCP가 움직이지 않을까 생각하고 있다. 특히 ServiceMix라는 JBI구현체 중 가장 큰 힘을 받고 있는 오픈소스 ESB는 JBI와 SCA 둘을 모두 포함시키려 노력하고 있는 물건이다. 올해 ServiceMix라는 물건에 관심을 가져보면 ESB의 미래에 대해 보다 많은 것들을 건질 수 있을 것이다.
아래는 간단하게 정리한 SDO, SCA, JBI간의 관계 구조이다. 사실 이렇게 모양새 좋게 서로의 레이어를 달리해서 만들어진 것은 아니지만...

태그 :

공유하기 버튼

 
트랙백(0)덧글(0)
이전 41 42 43 44 45 46 47 48 49 50 다음

프로필

밥값하는 IT 아키텍트가 되기 위해 노력중입니다. 연락처: calmglow at gmail.comby Calmglow
이글루스 피플

카테고리

최근 트랙백

RSS

RSS

태그

태그 전체보기

Google Analytics

calmglow.egloos.com is powered by Egloos. Subscribe to RSS. Skin designed by calmglow.