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)

웹서비스 연재 Enterprise

월간 마이크로소프트웨어 1월호부터 웹서비스에 대한 기사를 연재하게 되었다.
내용은 주로 e비즈니스에서의 웹서비스 그리고 비즈니스 프로세스등을 중점적으로
다룰 것 같다. 때문에 3,4회 연재되는 동안 WSDL이나 SOAP, UDDI같은
웹서비스 소개기사에 약방의 감초처럼 등장하는 3인방은 거의 거론되지 않을 것 같다.
(음..WSDL은 조금이나마 다뤄지겠군..)
2년만에 쓰는 연재인지라 글 다듬기가 쉽지 않고 마냥 조심스럽기만 하다.
아무래도 내용이 부실하다 싶어 그림도 직접 그려서 몇 개 넣었는데 유치하다고
기자님이 삭제하지나 않을지 벌써부터 걱정이 앞선다. 강력하게 주장을 했으니 넣어주겠지.
이번에 담당하는 기자님은 박은정 기자님인데 원래는 이종림 기자로 정해졌다가
워낙에 친하게 지내는 관계로 서로 일로 상대하는 것은 피하자는 합의(?)하에
조금은 어려운 분에게 편집을 맡기게 되었다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

웹서비스 Choreography Enterprise

calmglow가 이 블로그에 글을 쓴지 거진 1년이 되어간다.
이 블로그를 만든 동기는 나와 같은 웹서비스나 ebxml에 대해 관심을 가진
이들과 이야기를 하고 싶어서였고 때문에 초기에는 블로그와 커뮤니티를
혼합한 형태로 운영하였다. 하지만 시간이 지나도 그다지 참여하는 분이
많지 않았기 때문에 결국은 이렇게 달랑 블로그와 정체와 목적을 알 수 없는
게시판 하나만 남아버렸다.
그렇게 1년이 지났건만 상황은 크게 다르지 않은 것 같다.

오늘 무심코 구글로 '웹서비스 Choreography'라는 검색어를 주고 검색해보았더니
달랑 3페이지 정도가 나왔다. 그나마도 웹서비스에서의 Choreography에 대한 개념을
이야기한 내용은 없고 웹서비스 소개에만 그친 페이지 정도였다.
그래서 'Webservices Choreography'라는 검색어로 검색하였더니
페이지를 셀 수가 없을 만큼 무수하게 많이 검색되어 좀 더 자세하게 검색하기
위해서는 다른 키워드를 입력해야만 할 지경이었다.

웹서비스에서의 Choreography의 개념은 서비스의 Composition을 개념상으로
나누기 위해 나온 것으로서 Multi party들의 서비스들간의 협업을 대상으로 하는
것일 때에는 Choreography, 두 참여자들끼리의 협업에서 한 참여자의 관점에서
바라볼 때의 Transaction 묶음을 Orchestration이라 구분한다. 전자의
Choreography는 특정 서비스 독립적인 비즈니스처리에 기반한 서비스 묶음이라고
한다면 후자의 Orchestration은 서비스와 구현 기반의 서비스 묶음으로 보통
개념상 나뉘어서 설명되곤 한다. 사실 이 두 개념은 아직까지 웹서비스가
그 아키텍처의 레이어를 엄격하게 나누지 못하고 혼돈을 거듭하는 까닭에
많은 이들에게 논란의 여지를 남겨두고 있기는 하지만 비교적 최근에는
이러한 구분이 많은 이들에게 수긍을 받고 있는 편이라 할 수 있다.

혹자는 웹서비스 Composition 언어 중에 BPEL의 경우는 Orchestration에
적합한 언어이고 WSCI는 Choreography에 적합한 언어라고 평하고는 있지만
기본적인 Workflow언어의 기능상 관점뿐만 아니라 웹서비스의 특성을
고려한 측면에서 본다면 WSCI는 BPEL에 많이 못미치는
것이 사실이다. WSCI는 그 원류가 BPML과 BPSS이기 때문에 원래의 목적이었던
워크플로우의 모습을 많이 띄고 있으며 BPEL의 경우 초기부터 웹서비스 표준화에
많은 노력을 한 IBM과 MS의 두 스펙의 장점을 혼합한 것이기 때문에 보다
자유로운 웹서비스 Composition 표현이 가능한 특징을 가지고 있다.

나는 이 두 언어의 단점 중의 하나를 WSDL 종속적인 특징에 있다고 생각한다.
WSDL에 종속되어 서비스의 Composition을 구성해야하는 점 때문에 처음부터
서비스 종속적인 설계가 되어야한다. 물론 WSDL이 보다 추상적인 형태의
서비스 설계에도 사용될 수 있지만 서비스 Composition 즉, 서비스들간의
Collaboration에 대한 도출은 비즈니스 요구 분석과 설계에서 나오는 것이기
때문에 이러한 비즈니스 프로세스 내에서 Collaboration을 바라볼 때
처음부터 서비스종속적인 관점에서의 설계는 많은 한계를 가지고 있다고 생각한다.
그래서 웹서비스 진영에서는 WSDL과 특정 웹서비스 프레임워크에 독립적인
WS-CDL이라는 스펙을 추진하고 있다
태그 :

공유하기 버튼

 
트랙백(0)덧글(2)

서비스는 어디에 있을까? Enterprise

며칠 전에 내년부터는 범정부차원에서 웹서비스를 적극 도입하겠다는 신문기사를
읽었던 적이 있다. 그러면서 일기예보나 기타 당장 도입이 가능한 부분부터
웹서비스를 도입함으로써 관련 기술의 국산화에 노력하겠다는 기사였다.
물론 웹서비스 기반 기술 자체의 수용은 많은 도움이 될듯도 하다만
과연 우리는 무엇이 서비스인지 그리고 어디서 어떻게서비스가 나오는지
알고 있을까? 나도 모르기는 마찬가지지만 웹서비스가 꿈꾸는 서비스 세상에서
서비스란 주식알림이나 일기예보알림 정도로 그치는 것은 아닐거라 생각한다.
그렇다고 웹서비스가 분산객체기술의 한계에서 비롯된 기술로 자리매김할 것으로만
보기에도 어렵다고 생각한다. 보안의 문제가 차차 해결된다고 할지라도
기업 내부 시스템을 굳이 웹서비스로 바꿔야 할 만큼 기존 오프라인 기업들이
표준 적용에 대한 의지를 가지고 있거나 문제의식을 가지고 있는 것도 아니다.
그렇다면 서비스는 어디에 있을까?

서비스는 비즈니스와 기술 어느 쪽에 가까운 개념이라고 생각하는가?
나는 서비스가 비즈니스에 가깝다고 생각한다. 이제까지 IT는 비즈니스의 요구에
너무 소극적인 대안만을 제시해왔다. 비즈니스가 IT에게 어떤 세부적인
요구를 하면 IT는 그것에 맞게 특정 플랫폼과 프레임워크와 구현물을 제공하기에
급급하였다. 비즈니스의 IT적인 요구가 발생하여 그 요구가 충족되는 과정을
가만히 살펴보면 먼저 비즈니스의 요구가 발생하고 IT개발자와 비즈니스 전문가는
그 요구를 분석하고 설계(여기서의 분석과 설계는 충분히 IT적인 프레임워크를
구현하기 위한 테두리 내의 행위들이다)해서 구현하고 테스트하고 납품하는 것으로
종료된다고 할 수 있다. 그런데 이 이벤트가 발생하는 방아쇠인 비즈니스의
IT적인 요구는 아주 근시안적이고 모호한 부분에서부터 출발해버린다.
즉, 비즈니스 요구사항이 도출되는 행위 자체는 아무런 표준화된
프레임워크 없이 IT에게 반영됨으로써 결국은 각각의 완성된 비즈니스 덩어리들이
서로간에 아무런 협업을 이룰 수 없게 되버린다는 데 있다.
다시 말해서 비즈니스 요구사항이 정제되거나 표준화된 방법에 의해 도출되지 못하고
그 때 그 때 기업 내부의 필요사항에 따라 만들어짐으로 인하여
요즘처럼 기업간 협업이 중요시 되는 때에 큰 악영향을 끼친다는 점이다.
우리가 그동안 잃어버렸던 그 고리는 비즈니스를 산업간에 종적으로 혹은
횡적으로 추상화하여 표준화된 프레임워크인 것이다.
따라서 웹서비스는 사실 기술에 있는 것이 아니라 비즈니스에 있으며
비즈니스를 서비스화하는 일련의 표준화된 과정이 일단 IT와 여러 산업별 인프라에
충분하게 뿌리 내렸을 때 웹서비스 세상이 올 수있지 않을까 한다.

그렇다면 어떻게 비즈니스가 서비스로 설계되고 이 서비스에 맞게
IT가 개발하는 것이 가능할까?
크게는 두 가지의 요소가 필요하다. 말과 행위의 표준화이다.
말이라 함은 공통된 비즈니스 언어를 통해 산업별 국가별 표준화된 채널을
사용함으로써만이 글로벌한 협업을 이룰 수 있다는 것이다.
이러한 기술에는 UBL이나 OAGI, CC, EDI, 로제타넷 등을 들 수 있다.

또한 행위라 함은 공통된 프레임워크안에서 산업간 기업간 거래하는 행위들에 대해
기술할 수 있는 인프라를 말한다. 여기에는 이러한 프레임워크를 구축할 수 있는
방법론까지를 포함하는 경우가 있는데 이러한 방법론에는 로제타넷이나 BCF가 있으며
프레임워크에는 웹서비스와 ebXML이 있다.

이렇게 하여 보다 자유롭고 글로벌한 전자거래를 위한 노력이 현재 진행중이건만
정부에서는 이러한 차원에서의 접근보다는 일기예보나 우편번호 웹서비스 정도의 것을
전자정부에 도입함으로써 무슨 웹서비스 기술 증진의 효과를 볼런지 잘 모르겠다.

태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

IBM의 IAA(Insurance Application Architecture) Enterprise

요즘 BCF를 공부하면서 더더욱 특정 도메인에서의
아키텍처를 보고 싶다는 생각을 하고 있는 중이다..
그 중에서 IBM의 IAA는 전세계 수많은 보험관련 회사 도메인 관련 프로젝트에서
IBM이 쌓은 노하우를 담은 아키텍처이다.
이걸 어떻게 한번 볼 수 없을까...휴~
IAA
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

MDA를 이용한 웹서비스 설계 그리고 UMM Enterprise

Using Model Driven Architecture to Manage Metadata
많은 이들이 웹서비스를 강조한다. 덕분에 우리 주변에는 어느새 웹서비스 기술로 넘쳐나는 것만 같다. 그런데 정작 그 기술이 어떻게 쓰이는 것인지 과연 웹서비스가 말하는 서비스는 어디에 존재하고 누가 만드는 지 까마득하다. 웹서비스는 본래 특정 기술에 상관없는 자동화된 비즈니스 요구를 만족하기 위해 태어났건만 우리들 기술 공동체는 SOAP이나 WSDL같은 눈에 보이는 기술만을 너무 편애하는 것이 아닌가 한다.

그러면 어떻게 비즈니스에서 서비스가 나오는지에 대해 보다
분명한 지침이 있어야할텐데 아직까지는 이렇다할 좋은 참조자료를
찾기는 쉽지 않다. 일단 이 IONA에서 제공하는 문서는 이러한
문제를 되짚어보고 MDA를 이용한 웹서비스 설계에 대해 가능성을
보여준 문서라고 하겠다. 하지만 가능성일 뿐이다.
UML과 UP, UML Profile, OCL등을 이용하여 서비스를 설계할 수 있다고
언급하고는 있지만 실제로 특정 비즈니스를 분석 설계하고 서비스를
도출하기 위해서는 그것에 맞게 잘 정제된 방법론이 필요하다.
현재로서는 웹서비스에서는 이러한 방법론에 대한 접근이 부족하지만
UN/CEFACT의 TMG에서 연구 배포하는 UMM(UN/CEFACT Modeling Methodology)의 경우 특정 비즈니스에 독립적으로
비즈니스를 분석하고 설계하여 구현할 수 있는 방법론을 제공한다.
UMM은 UP와 EDI방법론, BCF등을 종합하여 B2B거래에 적용가능한 방법론을
제공한다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

IBM 와우센터 Enterprise

우리 회사에도 여느 SI업체와 마찬가지로
웹서비스 도입의 일환으로 IBM 웹서비스 와우센터인가 하는 것을
들여오게 되었다. 그 일 관계로 우리 회사에서 웹서비스 관련 실무자들과
IBM 기술진들과의 회의를 몇번 갖게 되었고
IBM이 제공할 수 있는 웹서비스 솔루션들에 대해 대화를 하였다.
뭐 말이 웹서비스 솔루션이지 IBM DB2와 MQ Series 그리고 웹스피어에
웹서비스 관련 툴이 포함된 토탈 솔루션을 판매하기 위한 IBM의 마케팅 전략인거고
우리는 IBM의 솔루션을 저렴한 가격에 구매할 수 있고
웹서비스 솔루션을 개발하였을 때 약간의 마케팅적인 요소를 추가할 수 있다는,
서로의 요구가 맞아떨어져서 계약을 맺은 것일거고 회의도
자연스럽게 그런 분위기로 오고 가게 되었다.
그 중에서도 우리 팀이 만든 것들은 이미 Oracle 9ias나 웹로직 그리고 JBOSS
환경에서 잘 돌아가던 것이고 웹서비스 관련 모듈은 우리가 만들어서 넣었으니
웹스피어를 도입한다고 어려울 점은 없었기에 나는 주로 IBM이 제공하는
웹서비스 솔루션이 얼마나 최신 스펙을 따라가는지에 대해 질문을 하였다.
우선 웹스피어의 GUI부분에서의 웹서비스 지원은 실로 입이 다물어지지 못할 정도로
훌륭한 것이었다.
우리팀 내에서도 이클립스 플러그인으로 웹서비스 관련 모듈을 개발했기에
조금은 기분이 야릇하기도 하였다.
하지만 아직까지 웹스피어도 기본적인 보안모듈과 Axis등을 이용한
서비스 올리는 수준 정도의 기능만을 제공할 뿐이었고
Reliable한 메시징조차 지원하지 못하는 허접(?)함을 보여주었다.
아무튼...금요일마다 미팅을 해야하는... 귀찮은 일이 생겨버렸다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

IBM의 새로운 표준기반 ESB Enterprise

ESB즉 Enterprise Service Bus가 최근 많이 화자되고 있다. IBM은 자사의 MQSeries와 웹서비스 기술을 바탕으로 ESB를 출시할 예정이라고 며칠전 발표하였다. ESB란 결국 기업 내부의 여러 시스템을 자유자재로 한데 묶을 수 있도록 하는 표준 기반의 메시징 시스템이라 할 수 있다. 이를 위해 웹서비스 기술이 동원되는 것은 필수이다. 벤더들은 이러한 ESB 기술이 기업 내부의 cost를 현저하게 낮춰줄 것이라고 주장하지만 기업 내부의 시스템을 굳이 표준으로 다시 재정비할만한 여력을 갖춘 기업이 많다고 볼 수 없고 그 효과가 근시일 내에 나타나는 것도 아니다. 많은 대형 기업들(삼성이나 LG, 포스코 등등)은 자체 내부 시스템의 표준화에 그렇게 많은 관심을 기울이지 않는 편이다. ESB기술이 보다 많은 기업들에게 관심을 불러일으키기 위해서는 기업 내부의 기술적인 관점에서의 통합이 아니라 비즈니스 프로세스에 의한 통합과 관리를 제공할 수 있어야할 것이다. 관련 기사
태그 :

공유하기 버튼

 
트랙백(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.