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 (최진호)

adsense(728_90)


컨텍스트란 무엇인가? Enterprise

컨텍스트라는 용어는 정말 다양한 곳에서 다양한 의미로 쓰인다. 사전적인 의미는 문맥이나 환경, 정황등의 뜻이지만 그것을 그대로 웹서비스나 기타 정보통신 용어로 사용하기에는 개념상 혼동스러울 것 같다.

대충 정보통신 용어로서의 컨텍스트는 호출, 응답 간의 환경 정보라고 정의할 수 있을 것 같다. 즉, 누가 무엇을 어떤 의도를 가지고 언제 행위를 하였는지에 대한 정보를 통칭하여 컨텍스트라고 하는 듯 하다.

이 컨텍스트 정보가 그냥 일반적인 환경설정 정보와 어떤 차이를 지니냐면 컨텍스트 정보는 일반적인 환경설정 정보와 다르게 런타임시에 생성되는 정보라고 할 수 있다.

웹서비스에서 컨텍스트 기반 관리라고 한다면 웹서비스들간의 협업시에 발생할 수 있는 여러 비즈니스적인 로직을 제어, 관리하는 기능이라 할 수 있다. 즉 BPEL이나 웹서비스 Security등의 개별 기술을 통합하여 조율하여 전체적인 Orchestration을 담당하는 것이 웹서비스 컨텍스트 기반 관리이다.

ebXML의 경우는 BSI나 CPPA등이 이러한 일을 담당한다고 할 수 있고 웹서비스의 경우는 오아시스의 WS-CAF나 MS,IBM, BEA등의 WS-Coordination과 WS-Transaction등이 담당한다고 할 수 있다. 좀 더 단순하게 이해하자면 결국 웹서비스간 협업 프로세스의 트랜잭션 정보를 컨텍스트 정보라고 보면 된다.

공유하기 버튼

 

자바 Keytool 관리GUI 툴 Programming

keytool은 자주 사용하는 사람에게는 command line방식이 어렵지 않지만
가끔 사용하는 사람에게는 그다지 편한 인터페이스를 제공한다고 보기는 어렵다.
이 GUI툴은 keytool을 GUI방식으로 관리할 수 있게 해주는 유용한 툴이다.
http://www.waynegrant.info/downloads.html

공유하기 버튼

 

BCF와 BPEL의 통합 Enterprise

BCF는 간단히 말하자면 MDA에 B2B용 스테레오타입과 비즈니스 패턴
그리고 OCL등을 합친 비즈니스 프로세스 설계를 위한 방법론 및 프레임워크이다.
특정 서비스 구현 아키텍처에 독립적이기 때문에 하부에는
ebXML뿐만 아니라 로제타넷이나 웹서비스스택이 들어갈 수 있다.

즉, 도메인 분석에서 요구사항 추출을 통해 비즈니스 프로세스 내의
비즈니스 협업과 트랜잭션 그리고 문서 리소스등을 추출하고
이것들을 분석하여 상호간의 유기적인 흐름을 여러 다이어그램을 통해
작성하고 다시 이것들을 서비스 단위로 추출하여 서비스 설계가
마무리 된다. 이 부분부터는 ebXML 프레임워크나 로제타넷 혹은
웹서비스 프레임워크가 이어받아서 다음 과정을 수행한다.

예를 들어 ebXML의 경우 BPSS를 작성하고 CC 매핑을 하며 CPP를
작성하면 협업을 위한 준비가 마무리된다.
웹서비스의 경우 아직 그 프레임워크가 완성된 것은 아니지만
WSCDL이나 BPEL을 이용하여 Composition을 작성하고서
WS-Transaction이나 WS-Trust, WS-Policy등의 스펙을 이용하여
서비스간 프로파일을 작성함으로써 협업을 위한 준비가 마무리 된다.

요즘 하고 있는 작업은 BCF에서 만들어진 산출물을 이용하여 어떻게
BPEL로 매핑할 수 있는지를 연구하는 것이다. 관련 자료가 거의
전무하다보니 나쁜 머리만 고생하고 있다...으으윽.

공유하기 버튼

 

BCF와 MDA Enterprise

요즘에 BCF와 UMM을 공부하면서 참 고마움을 많이 느낀다.
특정 영역의 비즈니스 도메인을 분석하는 데에는 많은 노력과 경험이 필요하다.
더욱이 범용적으로 사용할 목적으로 설계하는 것이라면 웬만한 대기업
하나가 해나갈 수 있는 영역이 아니다. 때문에 공부하는 입장에서는
이런 부분에서 막히고 갈증을 느낄 수 밖에 없다.
얼마 전에 언급했던 IBM의 IAA(Insurance Application Architecture)의 경우
IBM이 수십년 동안 금융기관에서 쌓아온 경험을 바탕으로 글로벌하게 적용이
가능한 아키텍처이기에 도메인 전문가나 아키텍트에게는 침흘릴만한 모범이
되겠지만 당연히 이런 것이 공개될리는 없다. 더구나 이러한 비즈니스 도메인의
아키텍처를 구축하는 방법론에 대한 보다 정확한 정보는 찾기가 힘들다.
MDA의 경우는 비즈니스 도메인과 모델이 이미 확정되어있는 상태의
PIM에서는 어떻게 비즈니스 도메인이 모델로 확정되는가에 대한 보다
보편적인 방법과 모습은 보이지 않는다.

때문에 비록 B2B거래에 국한됨에도 불구하고 UNTMG에서 공개하는
BCF는 가뭄의 단비와도 같은 존재라고 생각한다.
만약 논문을 쓰는 환경이 된다면
BCF와 MDA와의 결합을 통한 도메인에 독립적인 비즈니스 모델 프레임워크라는
주제로 쓰고 싶다는 생각을...-_-;;;;

공유하기 버튼

 

위키에서 다층형 분류체계 만들기 IT

보통 위키의 작은(?) 약점으로 지적되는 것 중의 하나는 분류체계에 대한 것이다.
위키의 경우 분류 역시 각각의 페이지로 구성되는 데
노스모크의 예를 들면 동물지도,
언어지도, 철학지도 등의 지도라든 접미어가 붙은 페이지가 분류역할을 하고 있다.
그런데 이 분류페이지의 약점은 1단계밖에 지원하지 못한다는 것에 있다.
가령 동물 중의 포유류 분류를 나타내고자할 때는 난처해지는 것이다.

그래서 내 경우에는 분류 페이지를 다음과 같이 명명한다.
'분류.동물'
'분류.동물.포유류' '분류.동물.파충류'
위와 같이 자바 패키지 명명법과 같은 순서대로 페이지를 만든다.
처음부터 모든 자세한 하위 체계 페이지를 만들 필요는 없다.
만약 '분류.동물'분류에 해당하는 페이지가 너무 많아질 경우에
그 때 하위 체계에 해당하는 페이지를 만들어서 재 분류를 하면 된다.
이렇게 할 경우 '분류.동물'의 모든 하위 체계에 해당하는 페이지를
검색할 수도 있고 '분류.동물.'으로 검색하면 모든 하위 체계에 해당하는
페이지만(부모체계페이지 제외) 검색할 수도 있다.
이러한 분류체계를 관리하기 위해 노스모크의 지도지도 페이지처럼
분류페이지의 체계를 잘 정리한 페이지 하나는 꼭 필요하고 항상
실제 분류페이지 체계와 동일한 내용을 담고 있어야 한다.

공유하기 버튼

 

서비스란 무엇인가? Enterprise

언젠가 친구를 만날 일이 있어 시내 한 카페에 들린 적이 있었다. 겉으로 보기에는 다른 카페보다 특별히 아늑하거나 차가 맛있다거나 하지는 않았지만 내가 유독 그 카페를 기억하고 이야기를 꺼내는 이유는 테이블 마다 유리잔에 담배 두개피가 있었기 때문이었다. 나같은 흡연자는 담배가 있다 할지라도 공짜라는 기분에 그것을 펴보게 되고 설사 비흡연자라 할지라도 애인을 주고싶은 마음에 담배를 가져가기도 한다. 그러면서 나같은 이는 '이 집 서비스가 괜찮은걸'이라 여기며 그 카페를 기억한다. 그렇다면 우리가 보통 사용하는 이 '서비스'라는 말의 의미는 무엇일까?

우리는 일상 생활에서 서비스를 흔히 '무상으로 제공되는 것', '고객을 대응하는 자세나 태도', '타인에 대한 봉사' 등의 의미로 사용한다. 하지만 우리는 적어도 그 의미를 넘어설 필요가 있다. 공급 원가에 마진을 보태 고객에게 제공되는 가격을 책정하면서 이미 그 서비스 요금이 포함이 되어있다면 더 이상 '봉사'라고 할 수 없기 때문이다. 따라서 단순히 '봉사'의 의미로서 '서비스'를 국한하기에는 뭔가 어색한 측면이 있다.

과거 물자가 귀하던 시절에는 제품의 생산이 바로 기업의 수익으로 연결되었다. 하지만 요즘같이 물자가 넘치는 시절에는 제품 자체의 원가는 제품의 가격에 많은 영향을 미치지는 않는다. 오히려 마케팅 비용이 제품 자체에 드는 비용보다 많이 들기도 하고 마케팅이야 말로 제품의 운명을 좌우하는 시대에 오면서 서비스라는 용어가 빈번히 사용되었다. 즉 서비스란 기업이 더 이상 제품만 판매하는 것으로 자신의 활동을 제한하지 않고 보다 적극적으로 고객과의 대화에 나서겠다는 의지와 행위라고 할 수 있다.

다시 말해 새로운 기술과 경영 혁신에 따라 신제품과 새로운 유형의 서비스가 계속 등장하고 있기 때문에 서비스의 정의는 산업별로 다양할 수 있겠지만 결국 '서비스'는 궁극적으로 비즈니스 목적을 위한 적극적인 대화 행위를 의미하며 대상에는 비단 고객이나 기업 내부 뿐 아니라 기업과 기업간에도 비즈니스 목적을 위한 대화의 상대라면 서비스의 대상에는 제한이 없다.

때문에 혹자는 서비스를 비즈니스적으로 의미있는 최소 단위로 정의하기도 한다. 그렇다면 이 '서비스'에 웹이라는 수식어가 붙은 웹서비스는 고객 혹은 대화가 필요한 누군가와 웹을 통해 비즈니스적인 소통을 하는 기술을 의미할 것이다

공유하기 버튼

 

웹서비스 연재 Enterprise

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

공유하기 버튼

 

이전 51 52 53 54 55 56 57 58 59 60 다음


Google Analytics