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

OASIS의 CEO인 Patrick Gannon은 어떠한 표준이든지간에 그것이 성공하기 위해서는 Sanction과 Traction이 잘 조화를 이루어야한다고 강조한다.

Sanction이란 얼마나 그 표준이 열려있는가(Open Standard)? 표준에 관심이 있고 참여하려는 모든 이에게 그 표준이 얼마나 처리 과정을 열어두느냐를 뜻한다.
Traction이란 산업계의 영향력을 행사하는 이들이 얼마나 그 표준에 관심을 갖고 참여하느냐를 뜻한다. 즉, 기술을 선도하고 기술을 이용하여 이득을 취하려는 기업이나 단체가 얼마나 그 표준에 참여하고 영향력을 행사하려 하느냐를 뜻한다.

이 두 가지의 요소는 언뜻 보기에 표준의 양면성을 나타낸다고 할 수 있다. 어느 한 기업이 독점하는 표준은 그 폐쇄성으로 인하여 표준의 의미를 상실하고 비록 개방적인 표준이라 할지라도 어떤 기업들도 사용하지 않는다면 이 또한 죽은 표준이라 할 수 있다. 따라서 성공적인 표준이라함은 이 Sanction과 Traction이 얼마나 잘 조화를 이루어 발전하느냐에 달려있다 할 수 있는 것이다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

모래시계를 이용한 업무 IT



벌써 2년 정도 된 듯 싶은데... c2.com의 xp 페이지를 정신없이 돌아다니다가 참 재미있는 페이지를 읽었던 기억이 난다. 우연찮게 읽은 창준이형의 글이었는데 모래시계 코딩이었나? 모래시계 프로그래밍이었나 암튼 비슷한 내용의 글이었다. 내용인즉슨 사람은 리듬을 탈 때 가장 능률도 많이 올라가고 집중이 잘되므로 코딩을 할 때에도 10분정도의 모래시계를 두고 번갈아가면서 코딩하는 것을 반복하다보면 자연스럽게 10분정도의 모래시계의 리듬에 자신이 맞추어지게 되고 점차 그 10분을 Full로 이용할 수 있게 된다는 내용이었던것 같다.
아 지금은 찾지 못하겠다. 그 내용이 맞는지 아니면 내가 시간이 흐르는 동안 내용을 왜곡하여 기억하게 되었는지는 모르겠지만 아무튼 그 때는 참 긴가민가했던게...10분동안 뭘 할 수 있을까 하며 반신반의했었다.
하지만 석천이나 몇몇 XPer들의 글을 읽다보면 시간에 대해 잘 정리하고 간수를 하는 것을 감탄하곤 하는 터여서 요즘들어 다시 그 글을 생각하며 괜찮은 모래시계가 있으면 좋겠다며 지내왔다.

어제 고등학교때 친구들과 함께 월차를 내고 정동진에 갔었다. ^^ 거의 6년만에 가져보는 대책없고 지지리 궁상인 젊었을 적에나 해봤을 가난한 여행을 하였는데 정동진에서 꽤나 괜찮은 모래시계를 5000원에 주고 사왔다. 사무실에서 10분 단위로 여러가지 작업들을 진행해보는 연습을 하는데...생각보다 집중이 잘되고 자신을 잘 정리할 수 있는 도구인듯 싶다.
태그 :

공유하기 버튼

 
트랙백(1)덧글(0)

WS-ReliableMessaing Spec Enterprise

웹서비스가 제대로 뿌리내리기 위해서는 주고받는 메시지를 믿을 수 있어야한다. 따라서 앞으로도 계속 연구되고 개발되어야하는 분야중의 하나가 메시징쪽인데 웹서비스의 경우 이부분이 많이 취약한 편이었고 따라서 B2B나 금융같이 메시지의 보안이나 안전이 무엇보다 중요한 분야에서는 웹서비스가 아직은 덜 여문 기술이었다. 그래서 ebXML에서는 ebMS라는 메시징 스펙이 존재하며 이 ebMS는 SOAP의 확장판이라고 할 수 있다.

그런데 드디어 웹서비스 진영에서도 이 Reliable한 메시징 처리를 위한 스펙이 나왔으니 이름하여 WS-ReliableMessaging이라는 스펙이다. ebMS의 경우에는 많은 부분을 두 Party들간의 Profile정보와 협약정보를 담은 CPP, CPA 문서를 이용하여 endpoint들간의 통신 프로토콜이나 보안정책이나 Business Process등을 ebMS엔진에서 처리할 수가 있지만 웹서비스의 경우에는 이 CPP나 CPA등의 문서 개념이 없기 때문에 특별히 WS-Addressing같은 스펙등이 필요하였고 스펙 자체에서도 이 endpoint들간의 상호운용성을 맞추는 문제에 ebMS보다 많이 할애한 흔적이 보인다. 개인적으로 ebXML이 현재 진행중인 많은 부분을 웹서비스 진영에 내어줄 것이라는 예측을 한다.
베타비디오가 기능상 더 우수했을지라도 선택되지 않은 것처럼 비록 ebXML이 기능이나 내용면에서 알차고 훌륭하지만 참여하는 벤더나 여러가지 모습들이 웹서비스에게 유리한 방향으로 흘러가고 있지 않느냐는 느낌을 많이 받곤 한다. 물론 BP나 CC등의 경우에는 ebXML이 선두에 서서 기술을 이끌어나가겠지만 오아시스에서 진행중인 ebXML관련 기술들의 많은 부분이 웹서비스쪽으로 무게가 실릴 것이라는 조심스런 예측을 한다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

변화관리와 설득을 위한 글. Art and Life

오늘 박준용군이 보라고 던져준 URL을 소개할까한다. http://www.dhemery.com/articles.html 출처는 어느 XP동네에서 가져왔다는데 몇번 클릭을 해보기만 해도 상당히 재미있는 내용임을 알아차릴 수 있었다. 퇴근 길 지하철에서 'Managing Yourself Through Change' 이라는 변화관리에 관한 글과 'Resistance as a Resource'라는 자신의 주장을 상대에게 설득하기 위한 요령을 담은 글을 읽었다. 먼저 'Managing Yourself Through Change'라는 글은 우선 Satir의 변화곡선을 보여주면서 인간이 평상시 변화라는 요인을 접하면서 어떻게 그것을 맞닥뜨리고 적응해나가는지를 설명하였다.


이 글에서 필자가 강조하는 것은 변화에 대한 능동적인 대처라고 할 수 있다. 즉 평상시에도 너무 나태하고 변화없는 일상의 고정적 환경에서 지내지 말라는 것이다. 우리가 믿어마지 않는 인생의 고정요소들은 단지 믿음일 뿐 실제는 아니며 변화는 필연적인 것이다. 따라서 능동적으로 평소에도 자신에게 스스로 변화를 일으켜서 더 큰 외부의 변화에 적응할 수 있도록 훈련할 필요가 있으며 지금의 행복과 지금의 불행이 끝이 아니라 좀 더 나은 미래를 위한 과정일 뿐임을 명심하라는 내용이 주이다.

두번째는 'Resistance as a Resource'라는 글이다. 이 글은 자신이 누군가에게 조직의 문제를 이야기하고 자신이 생각하는 문제의 핵심과 그것에 대한 해결책을 이야기하였을 때 해당 조직에서 어떠한 거부 반응을 보이고 그 반응의 종류는 무엇이 있으며 그 종류의 원인과 대처방안이 무엇인지를 아주 세부적으로 잘 설명하였다. 거부를 하는 첫번째 원인은 '기대심리'이다. 즉 내가 누군가에게 어떤 Solution을 이야기할 때 상대방은 일단 그 새로운 Solution을 실행해야하는 상대방의 입장에서 보았을 때 실행할 수 있는 능력이 있는지 그리고 그 결과는 무엇이고 그 결과로 얻을 이익(가치)는 무엇이 있는지 저마다 다른 개성을 가진 그들만의 판단으로 거부를 하게 된다는 것이다.
좀 더 세분화하면 Request를 받은 상대방은 그 Request에 대해 자신이 해낼 기술에 대한 기대와 결과에 대한 기대, 그리고 가치에 대한 기대에 따라 제각기 다른 반응을 보인다.
두번째 원인은 대화(Communication)이다. 같은 대답이라도 듣는이에 따라서 얼마든지 해석의 방향은 달라질 수 있다. 얼마나 상대방과 대화를 잘 하고 상대방의 의도가 정확히 무엇인지 최소한 두개 이상의 의도를 유추해내어 상대의 의도에 적절한 대답을 해야한다.
세번째 원인은 관계이다. Request에 대해 거부반응을 보이는 것은 그나마 나은 편이다. 만약 Request에 대해 아무런 반응도 없고 관심이 없다면 그것은 Request의 정당성 여부를 떠나 청자가 화자에 대한 관계에서의 믿음이 없다는 것을 의미한다.
네번째 원인은 환경이다.

이 외에도 그 페이지에는 꽤 재밌는 읽어볼만한 글들이 많다. 누군가의 말처럼 볼거없어서 심심해죽을 틈을 안주는 인터넷이다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

MindMapping에 대해 IT

내가 마인드매핑에 대해 알게된 지는 몇개월되지 않는다. XML관련 업무를 많이 하다보니 자연스럽게 지식기반 탐색기법이나 지식관리 등등 지식을 어떻게 효율적으로 사용하고 분류할 것이냐에 대한 문제로 많은 글을 접하게 된다. 그러다가 우연히 마인드매핑이라는 추리방법을 배우게되었다. 이 마인드 매핑을 이용하다보니 생각도 그 전보다 훨씬 정리가 잘되고 특히 프리젠테이션할 때 정보를 모으고 정리하는 데 매우 유용하였다. 요 근래에는 ebMS(ebXML 메시징관련 스펙) 스펙을 공부하고 있는데 이 마인드매핑이 또한번 그 복잡한 스펙을 일목요연하게 정리하는 데 많은 도움을 주고 있다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

능력이란 무엇인가 IT

오늘도 오랜만에 자바서비스넷에 들어갔다. 우선 눈에 띄는 것은 JSTL에 대한 이야기들. 여전히 JSTL이나 커스텀태그는 기존의 자바개발자에게는 익숙하지 않고 불편하기 때문에 여러 개발자들이 JSTL을 적용해본 경험담을 이야기하였다.
나는 저번 프로젝트에서도 끝내 커스텀태그 하나 없이 웹쪽 부분을 개발하였다. 나혼자 개발하는 것이 아니고 다른 팀원들과 발을 맞춰가며 개발을 해야하는데 그들과 커스텀태그나 JSTL등에 대한 지식을 공유한다는 게 결코 쉽지 않을것이라 생각하였기 때문이다. 물론 결과는 웹개발이 조금 더 짜증났었고 앞으로도 새로운 요구사항이 있을 경우 계속 짜증날 수도 있는 상황이다. 하지만 암튼간에 지금은 그 프로젝트는 끝났고 나는 최신의 기법을 사용하지 않은 것에 대해 아무런 불만은 없다.
나는 기존의 웹프레임워크를 간소화시켜서 Request Dispatcher부분만을 이용한 간단한 웹프레임워크를 만들어 사용하였는데 이제 팀원들은 프레임워크의 필요성에 대해 절실하게 깨닫게 되었다. 또한 조금씩 커스텀태그나 JSTL등에 관심을 가지게 되었다. 그것으로 족하다고 생각한다. 우리의 팀웍은 유지되었으며 프로젝트는 끝났으며 많은 것을 배웠다. 그리고 우리에게는 새로운 프로젝트가 기다리고 있다. 우리는 성공할 것이다. -_-;;; 프로젝트에서 무엇보다 요구되는 능력은 기술보다는 팀웍과 팀에 대한 배려가 아닐까? -_-;; 이전에 했던 이야기를 또한번 반복하게 되었다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

ebXML 적용을 위한 5단계 Enterprise

보통 ebXML 을 각 산업에 적용하기 위해서는 필수적으로 5단계의 과정을 필요로 한다.
1. 설계/모델링: 비즈니스 분석전문가나 프로세스 설계자가 UML 설계 툴을 이용하여 B2B 비즈니스 프로세스를 설계하면 이를 이용하여 BPSS 정의를 생성한다. 그럼 이 BPSS를 이용하여 각 기업들이 자신의 정보와 결합하여 CPP를 만들고 BPSS와 CPP가 ebXML Repository에 저장되는 것이다. 이것으로서 각 기업들이 서로간에 거래를 하기 위한 기본적인 준비과정이 끝난다.
2. 통합(Integrate): 1번 단계가 비즈니스 의미의 재해석과 문서중심의 준비단계 즉 BOV(Business Operational View)관점에서의 준비과정이었다고 한다면 2번단계는 FSV(Functional Service View) 관점에서의 준비단계라고 할 수 있다. BSI(Business Service Interface: 즉 메시징을 처리하고 BP와 CPPA를 해석할 수 있는 신뢰성있는 엔진)가 각 기업의 백엔드 시스템에 통합되어 레가시 시스템의 정보를 활용하게 된다. 즉 이렇게 함으로써 기업의 백엔드 시스템이 Service Oriented Architecture로 구축되어 웹서비스를 할 수 있게 된다.
3. 파트너: 이 단계는 BOV와 FSV 준비가 끝났으므로 자신이 원하는 거래 파트너를 찾아서 계약을 체결하는 과정이다. 먼저 ebXML Registry를 이용하여 자신이 원하는 거래 파트너의 정보(이를테면 CPP, BP)를 찾는다. 이 작업이 끝나면 협상(Negotiation) 과정이 필요한데 이 과정에는 계약금을 지불하고 계약을 맺는 여러 과정이 포함되어 있으며 이 과정을 통해 협상이 성립되면 두 CPP를 통합하여 CPA를 만들고 이 CPA를 각자 회사내의 MSH(Message Service Handler)에 설치한다. MSH에서는 협상을 통해 만들어진 CPA를 아주 쉽게 설치하여 쌍방간에 메시징에 필요한 여러 부수적인 작업들을 자동적으로 처리할 수 있게 한다.
4. 거래 시작: 이제 B2B 트랜잭션이 각 기업들의 백엔드 시스템과 결합하여 실행된다. ebXML은 이 과정에서 reliable 메시징과 부인방지, 프로세스 choreography등을 지원한다. 더욱이 이렇게 복잡한 비즈니스 프로세스의 엔드 투 엔드(end to end) 통합은 BPM이라고 하는 public(파트너들간)과 private(백엔드시스템) 프로세스들을 통합 관리해주는 엔진이 수행한다.
5. 관리: BPM이라고 하는 것은 비즈니스 프로세스에 대한 과정을 관리하는 엔진이며 MSH는 end to end간에 오고가는 비즈니스 문서들을 모니터링하는 기능을 담당한다. 또한 웹서비스 시스템 역시 이러한 총괄적인 시스템 관리에 매우 중요한 요소를 담당하는 부분이다.
태그 :

공유하기 버튼

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