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)

SOAP Box Enterprise

SOAP메시징관련 일을 하다보면 테스트를 위해 Axis의 TcpMonitor를 사용하게 된다. 이는 정말 매우 유용해서 상호운영성 테스트에도 사용될 정도로 흡족한 무료 제품이지만 SOAP메시지에 대한 XML처리를 해줄 수 있는 기능들이 들어간다면 더할 나위없이 좋았을 거라 생각한다. 즉 자신이 원하는 엘리먼트를 추가하거나 XML Security관련 작업을 자동으로 해주거나 SSL을 처리해주거나 서명, 암호를 키만 입력하면 자동으로 해줘서 테스트를 가상으로 해볼 수 있게 만들었다면 정말 기특했을 것인데.. 그런 기특한 물건이 있었다! 바로 Vordel이라는 회사에서 무료로 제공하는 SOAP Box! 앞에서 언급한 원하는 기능을 모두 제공하고 화면도 이쁜! 앞으로 주로 사용하게 될 SOAP 과 보안 관련 디버깅 툴이 될 듯 하다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

웹서비스에서의 트랜잭션 Enterprise

ebXML Registry/Repository 2.5버젼에서부터 REST기능이 추가되었고 그래서 구현중이었다고 이전 블로그에서 언급한 적이 있다. 이 REST를 추가한 주된 동기는 웹상에 존재하는 다수의 정보등록소의 컨텐츠를 연결하기 위함이다. 즉 어느 등록소에서든 자신이 원하는 정보를 얻을 수 있고 그 정보를 제어할 수 있게 하기 위함이다. 그러다보니 여러 등록소간의 서비스가 하나의 트랜잭션 하에서 동작해야할 때가 있고 자연스럽게 웹서비스에서의 트랜잭션에 대해 심각한 고민을 해야만 한다. 이제까지의 트랜잭션이라 함은 하나의 엔터프라이즈 환경 내에서 범주를 정했다고 볼 수 있다. 하지만 웹을 통해 산재해있는 여러 리소스들간의 Collaboration을 트랜잭션의 범주로 볼 경우 이전과는 다른 보다 복잡한 여러가지 문제가 앞에 놓이게 된다. 이를 위해 웹서비스에서는 Ws-Transaction 이라는 스펙을 내놓았지만 현재의 우리 팀의 여력상 그것을 돌아볼 겨를은 없고 제약조건을 여러 개 두어서 막아놓는 땜빵을 해야하고 있다.. 만약 메시징을 ebMS를 이용하였다면 이런 트랜잭션의 문제는 거의 발생하지 않았으련만...
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

XGen과 Castor Programming

저번 자바 바인딩 툴 비교 블로그에서 언급했듯이 바인딩 툴의 성능은 소프트웨어나 서비스의 내부구조에 엄청난 영향을 끼친다. 해당 벤치마킹을 통해 XGen이 Castor나 다른 바인딩 툴에 비해 성능이 좋게 나타났음을 이야기했는데 비단 속도 뿐만 아니라 바인딩한 클래스의 구조도 XGen이 다른 Castor류보다 훨씬 확장성이 있고 개발이 편리함을 요즘 몸소! 체험하고 있다. 그렇다 할지라도 지금 Castor로 돌아가고 있는 시스템을 XGen으로 바꾸는 것은 투석을 받는 환자만큼이나 괴로운 일이니 어쩔 수 없이 Castor를 쓴다지만 혹시 이 글을 읽는 다른 개발자는 절대로 Castor를 쓰지 말기를 부탁한다. 커머스원에서 만든 XGen을 꼭 추천한다. 이전 블로그에서 언급한 바인딩 툴 말고도 JIBX라는 바인딩툴이 있기는 하지만 속도만 빠를 뿐 사용성 측면에서는 좋은 점수를 주기가 어렵다. 예를 들어보자. '동물'이라는 엘리먼트가 있고 '동물'의 타입을 정의한 '동물타입'이 있다. 이 '동물타입'을 상속받은 여러 개의 동물들 즉 '낙타타입','소타입','고양이타입','개타입'이 있다. 이제 '동물원타입'을 만들려고 한다. '동물원타입'에는 '동물'의 리스트가 들어간다. 이러한 관계를 자바 객체로 바인딩할 경우 Castor는 동물원 클래스에 동물객체의 리스트가 들어간다. 그럼? 낙타는 동물객체의 리스트에 추가시킬 수가 없다. 낙타는 동물타입클래스에서 상속받은 것이지 동물클래스에서 상속받은 게 아니기 때문이다. 결국 바인딩 클래스를 조금 고쳐서 사용해야하고 마샬링시에도 조금 어색한 XML문서가 추출된다. 물론 이건 스키마에도 일정부분 문제가 있는 것일지도 모르지만 의외로 많은 스키마들이 저렇게 정의되어있는데 어쩌란 말인가 반면에 XGen은 상속과 Composition을 절묘하게 사용하여 잘 해결해준다. XGen을 강추한다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

UML의 Activity Diagram과 BP Enterprise

UMM에서도 그렇고 MDA에서도 그렇고 UML의 용도는 비단 소프트웨어 개발과 설계에만 국한되지는 않는다. Process와 비즈니스 그리고 서비스가 화두가 되는 요즘같은 e비즈니스 시대에는 UML을 이용한 비즈니스 모델링에 적극 활용하고 있다. 그런데 UML의 대부분의 다이어그램은 객체지향적인 개발을 위한 다이어그램으로 태어난 것들이기 때문에 아무리 stereotype을 붙여서 확장한다고는 해도 뭔가 좀 어색한 느낌을 지울 수가 없다. 그나마 그 중에서 가장 객체지향이랑은 상관없이 태어났다고 해도 좋을 Activity Diagram은 이러한 비즈니스 모델링에 적극 활용된다. 형태가 일단 Flowwork Diagram 형식이다보니 사용하기도 편한 측면이 있다. 때문에 UMM이나 MDA에서도 이걸 종종 사용하고는 하는데 내 생각에는 여전히 이 Activity Diagram도 불편하기는 마찬가지다. 이 설계안을 토대로 다시 BPEL이나 BPSS등의 XML문서로 만드는 것이 그렇게 쉽지가 않다. 차라리 전용 BP 모델링 툴을 사용하는 것이 나을 것이라고 보는데... 왜 굳이 UML을 BP 모델링에서 고집해야하는 지 모르겠다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

REST (REpresentational State Transfer) Enterprise

오늘 회사에서 작업한 내용은 기존 Bizbinder RegRep 서버에 REST인터페이스를 추가하는 일이었다. 기존에는 SOAP 인터페이스만을 제공하다가 스펙 2.5부터 이 REST인터페이스가 추가되었다. REST는 URI를 이용하여 리소스를 지정하고 이를 HTTP의 네가지 액션을 통해 제어하는 방식으로서 RPC방식의 분산 객체 기술이 아닌 문서 방식의 느슨한 연결을 제공하는 아주 간단하고도 쓰임새 많은 기술이다. 기술 자체는 너무나 간단하지만 이 기술은 웹서비스의 근간을 이루는 핵심이라고 할 수 있다. SOAP기술이 태어난 동기는 DCOM이나 CORBA가 할 수 없었던 제약사항들을 해결하는 데 있었기에 WebBroker라는 이름을 가졌던 적도 있었고 때문에 웹에서의 RPC라는 고정관념이 강하다. 그러나 근본적으로 RPC방식은 인터페이스의 수정이 매우 어렵기 때문에 Late Binding에 적합한 방식은 아니다. 반면에 웹이라는 특성은 철저하게 Late Binding한 특성을 지녔고(URI를 통해 리소스를 가져오는 순간 해당 리소스가 바인딩된다) URI라는 표준에 입각한 주소체계를 가진 한마디로 웹 자체가 거대한 분산 시스템이라 할 수 있다. REST는 이러한 웹의 근본적인 특성을 최대한 이용한 방식이다. 실제로 이전에 BizBinder RegRep에 접근하기 위해서는 SOAP 메시지를 만들어야만 했고 전용 클라이언트가 있어야하거나 전용 웹사이트가 있어서 직접 SOAP메시지를 만들어서 HTTP 프로토콜로 전달해야했다. 하지만 REST 인터페이스를 구현할 경우 BizBinder RegRep의 모든 리소스는 웹브라우저나 텔넷 클라이언트로 URI만 지정하여 검색이나 관리가 가능해진다. 모든 리소스가 URI로 표현되기 때문이다. 이렇게 오늘 REST인터페이스를 만든 이유는 철강산업의 RegRep과 국가중앙저장등록소간의 통합 분산질의 시스템을 구축하기 위함이다. 이렇게 REST를 구축함으로 인하여 엄청난 확장성을 얻게 된다. 두 등록소는 아주 간단하게 연결되어 서로 질의가 가능해지고 향후에도 너무나 손쉽게 확장이 가능해지는 구조가 되어버린다. REST의 환상적인 세계를 경험하고 싶다면 다음을 참고하기 바란다. REST Wiki
태그 :

공유하기 버튼

 
트랙백(0)핑백(2)덧글(0)

BP, WSCI, BPEL,WorkFlow,WS-CDL... Enterprise

요새는 BP안에 내재되어있는 모호함과 싸우고 있다. 워낙에 많은 사람들이 여기에 관여하고 서로 자기가 옳다고 이야기를 하니 관망하는 나로서는 혼란스럽기 그지없다. Workflow와 Business Process는 다른가? Business Process와 웹서비스에서의 BusinessProcess는 다른가? Choreography와 Orchestration은 다른가? Collaboration은 어디에 속하는가? Orchestration+ Transaction = Choreography 혹은 Collaboration인가? BPSS는 그 모든 것을 포함하는가? BPEL은 왜 Collaboration의 개념이 부족한가? WS-CDL은 WSCI와 얼마나 다른가? WSCI와 BPEL은 어째서 WSDL종속적이어야만 했는가? 혹시 WSCI와 BPEL에는 벤더들의 입김이 작용하지는 않는가? BPEL은 BPML을 대체할 수 있는가? 혹은 WorkFlow를 대체할 수 있는가? 물어볼 사람도 없고 답해줄만한 책도 없다. 그냥 여기저기 돌아다니면서 확인하는 수밖에.. 휴~ 그래도 재미는 있군. -_-;; ps. 한동안 재즈만을 듣다보니 귀가 재즈쪽으로 익숙해진 건가? 오랜만에 들어본 좋아하던 newage 음악들이 낯설고 싱겁게 느껴진다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

ebXML과 웹서비스 Enterprise

오늘은 '한국 전자OOOOO ' 분들을 만나 프로젝트에 대해 회의하였다. 회의가 끝나고 ebXML과 웹서비스 동향에 대해 같이 짧게 이야기할 시간을 갖게 되었다. ebXML을 전문으로 연구하고 이끌고 있는 많은 이들 조차 ebXML의 미래에 대해 아직은 확신을 갖지 못하고 웹서비스의 우세를 예상하는 느낌을 받았다. 물론 충분히 이해가 가는 의견들이기는 하나 ebXML과 웹서비스를 둘로 보는 그 견해가 난 그다지 옳다고 보여지지는 않는다. 웹서비스는 XML기술을 활용한 소프트웨어의 기능에 대한 표준화된 인터페이스 기술의 개념적인 정의이며 ebXML은 이러한 웹서비스 기술을 이용한 전자거래를 위한 프레임워크라고 할 때 그 둘의 사이에는 대립할 여지가 거의 없다.
따라서 ebXML은 얼마든지 웹서비스계에서 만들어지는 많은 기술 리소스들을 자신의 필요에 맞게 가져와서 사용할 수 있으며 본래의 목적인 글로벌한 마켓플레이스를 구축하는데 유용하다면 결코 ebXML의 정신에 위배되는 것은 아니다. 예를 들어 현재 ebXML RegRep의 정보모델과 질의기능은 UDDI에 비해 전자거래에 있어 장점이 있는 반면에 인지도나 범용성 측면에서 떨어진다면 ebXML은 얼마든지 UDDI를 취할 수 있다. 또한 현재까지는 ebXML의 메시징 기술이 웹서비스에 비해 보다 안정적이며 상호운영성을 가지고 있으나 앞으로 대형 벤더에 의해 웹서비스 RM 기술이 우위를 가지는 상황이 생긴다면 그때는 그러한 기술을 채용하면 된다.
어차피 두 기술 모두 Loose Coupled를 기반으로 태어난 것 아닌가. 이러한 현상은 현재의 오아시스에서도 여실히 드러난다. 몇년 전만 하더라도 주로 ebXML기술에 대한 TC가 주를 이루던 오아시스에는 이제는 ebXML과 웹서비스에 대한 어떠한 구분도 찾아볼 수가 없으며 비슷한 웹서비스 관련 TC도 존재할 정도로 혼탁(?)하다. 좋으면 쓰면 된다. 그다지 집착할 필요는 없다. -_-;;
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)
이전 51 52 53 54 55 56 57 58 59 60 다음

프로필

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

카테고리

최근 트랙백

RSS

RSS

태그

태그 전체보기

Google Analytics

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