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)

B2B 메시지 교환 프로토콜의 비교 평가 문서 Enterprise

나의 블로그는 링크만 거는 식을 탈피하려고 하는데 출장이 내일인지라 그냥 링크만 거는 불성실함을 보인다. http://www.ebxml.org/ebxml_jmt/documents/wp_messaging_req_052303.pdf 꼭 ebMS나 VAN만이 절대적으로 우위에 있는 기술이라 보기는 어렵다는 것을 나는 주장하고 싶다. 후다닥
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

한일 철강 ebXML적용을 위한 회의 Enterprise

를 참석하기 위해 일본에 출장을 간다. 많은 부분 부족하지만 경험을 쌓는다고 생각하고 우리 제품을 잘 설명해야겠다. 일본이 우리보다 결코 ebXML기술이 뒤쳐져있지는 않지만 철강부분에서의 적용만큼은 비교적 우리가 앞서있으므로 서로가 많은 것을 메울 수 있을 거라 생각한다. 휴~ 두번째 해외 출장인데 여전히 긴장되는 것은 마찬가지군..
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

SMTP 는 훌륭한 Loosely Coupling을 위한 프로토콜 Enterprise

바로 이전 글에서 파트너사들의 유동아이피로 골치 아프다는 이야기를 했었다. 그래서 이러한 파트너의 endpoint를 resolve하는 웹서비스 스펙도 준비중이라는 이야기를 했었다. 그리고 이러한 점이 Loosely Coupled한 웹서비스의 특징이라고 언급했었다. 특히 웹서비스가 지닌 프로토콜 독립적인 부분은 매우 유리한 점이 있음을 알 것 같다. 유동아이피등의 문제가 있을 경우 SMTP 프로토콜을 사용하면 HTTP를 사용할 때보다 문제를 해결하기 쉬워지는 것이다. 음... 자려다가 잠깐 생각나서... 적는다.... -___-;;
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

WS-EndpointResolution과 B2Bi... Enterprise

요즘들어 여러 중소업체들을 대상으로 시범적으로 우리의 ebXML제품을 도입하고 있다. 그러다보니 이곳저곳에서 부닥치는 예상치 못한 일들이 한두가지가 아니다. 우선 기존의 굴뚝업체들의 낮은 IT인프라구축환경으로 겪는 문제가 시급하다고 생각한다.
예를 들어 그래도 꽤 크다고 생각되는 업체임에도 사내 인터넷 망이 ADSL등의 유동아이피 환경으로 구축되어있는 점이다. 이런 때에는 정말 난감하기 그지없다. 전산담당자에게 이야기를 해도 잘 먹히지도 않으니 하소연할 수가 없다. 기본적으로 인터넷망을 이용하여 전자문서거래를 하겠다고 한다면 전용선 정도는 깔려있어야 뭐를 해먹던지 하지... -__-;;

우리나라의 IT환경이 너무 빨리 변하다보니 미처 따라오지 못하는 많은 기존 오프라인 업체들이 있음을 절실히 깨닫게 되었고 많은 이들이 이제 IT인프라는 구축될만큼 되었기 때문에 더이상 수요가 없어서 현재의 불황이 왔다고 푸념하지만 생각보다 많은 사회각 부분에서 제대로 된 IT 인프라를 구축하려면 보다 많은 시간이 필요할 것 같다는 생각을 한다. 아무튼 간에 웹서비스에서는 특히 GXA(이건 또 나중에 설명할 때가 있겠지.) 에서 제안하는 WS-EndpointResolution이라는 스펙이 있다. 이는 to-party의 endpoint를 어느 시점에서 정확히 어떤 것을 기준으로 하여 설정할 것이냐에 대한 해결을 제시한다.
이를테면 어떤 전송자가 수신자에게 메시지를 전달할 때 이 수신자의 Endpoint 컴퓨터의 IP는 언제 결정되어야 할까? 전송할 때? 아니면 받는 시점에서? 웹서비스의 가장 큰 특징중의 하나인 'Loosely Coupling'을 생각할 때 당연히 받는 시점에서 동적으로 수신자 컴퓨터의 IP가 결정되어야 마땅하다. 하지만 이런 것으로 이 스펙이 우리의 갈증을 해결해주는 것은 아니다. 좀 더 파고들면 그 이후에도 문제는 발생할 수 있다.
만약 어떤 메시지가 특정 컴퓨터 내의 특정 애플리케이션(익스플로어, 파워포인트)과 메시지를 주고받는 것이라면 과연 그 특정 '애플리케이션'은 어떻게 찾을 것인가? 그에 더해서 특정 애플리케이션의 인스턴스가 여러개 띄워져있을 경우 어떤 인스턴스와 교신해야할까 등등의 다양한 문제점에 대해 해결책을 제시해주고 있는 스펙이 바로 WS-EndpointResolution이다. 아 근데 이건 B2Bi보다는 EAI쪽의 해결을 위한 것인 듯 싶고 아직 스펙도 안나온 것으로 알고 있다. 아무튼 조금 다른 이야기이긴 한데 B2Bi에서도 위에서 설명한 여러 문제점을 어떻게 해결해나가야 할지.. 그리고 이 외에도 산적한 많은 문제가 있음을 하소연한다..
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

좋은 서비스의 설계란? Enterprise

http://www.mcdowall.com/webservices/#200070890
흔히 우리가 이야기하는 웹서비스에서의 '서비스'에 대한 정의와 그 서비스를 어떻게 하면 좀 더 잘 설계할 수 있을지에 대한 글이 있어 소개한다. 내용 요약 서비스는 서비스를 중심축으로 하여 양쪽에 비즈니스 영역과 기술적인 영역으로 나눠서 생각해볼 수 있다.
만약 어떤 서비스가 비즈니스적인 요구사항을 반영하지 못하거나 비즈니스적인 효과를 발휘하지 못한다면 그것은 좋은 서비스라고 할 수 없다. 현실 세계에 있어서 이 서비스라는 것을 정의하고 설계하는 데에는 많은 어려움이 따르고 하여 다음과 같은 설계가이드라인을 제시하고자 한다.
1.서비스는 공유되어 사용되는 리소스와도 같은 것이다.
2.서비스는 그 사용목적이 명확하다.
3.서비스는 그 구성요소들이 매우 느슨하게 연결되어 있으며 대부분 서비스들간에 직접적으로 연결이 이루어지지 않는다. 따라서 언제든 동일한 작업을 하는 다른 서비스를 사용하는 것이 가능하다.
4.서비스는 언제든 찾을 수 있어야하고 자체 검사기능을 제공한다.
5.서비스는 SOA(Service Oriented Architecture)에 플러그인 된다.
6.서비스는 다른 서비스들과 잘 융합된다.
7.서비스는 잘 정의된 인터페이스와 정책을 가진다.
8.서비스는 잘 정의된 입력을 받으며 잘 정의된 출력 정보를 전달한다. 즉 정확하고 표준된 방법을 통한 입출력 정의로 서비스의 행위를 결정한다.
9.서비스는 숨겨진 부작용을 갖고 있지 않는다.
10.서비스는 프로세스의 인터페이스이다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

WS-Choreography와 BPEL4WS Enterprise

현재 BPEL4WS는 OASIS에서 MS와 IBM을 주축으로 TC가 결성되어 진행중이고 WS-Choreography는 W3C에서 BEA나 Sun, SAP등의 회사들이 주축이 되어 진행중이다. 이렇게 두가지 표준이 존재해져버린 이유는 뭐 항상 그렇듯이 업체들간의 표준에 대한 주도권 다툼이다. 항간에는 BPEL4WS가 스펙의 성숙도 면에서 더 좋다고는 하지만 그런 것들이 시장을 주도할 수 있는 절대적인 힘이 되는 것은 아니었으니 앞으로도 이러한 경쟁구도는 지속될 것으로 보인다. 결국 고객의 입장에서 보면 이러한 웹서비스 스펙의 난립으로 인하여 현업 적용에 어려움을 겪게되는 것이긴 하지만 어떻게 보면 이러한 경쟁으로 스펙의 충실도가 더 높아질 수 있는 결과를 낳을 수도 있을 것이라는... 희망적인 생각도 가져본다.
태그 :

공유하기 버튼

 
트랙백(0)덧글(0)

WS-Reliability Enterprise

많은 이들이 이미 아는 바와 같이 작년에 경합을 벌이던 Reliable Webservices Messaging을 위한 스펙이었던 MS의 WS-ReliableMessaging과 기타 Sun이나 후지쯔등의 WS-Reliability중에서 후자가 OASIS에 채택되어 현재 TC에서 보다 나은 스펙을 위하여 작업이 분주하다. 사실 올해 초에 WS-Reliability가 나왔을 때 욕을 상당히 많이 먹었다. 2년전에 나왔던 비즈토크 2.0과도 별로 달라진 것 없이 단지 P2P방식의 메시지 전달만이 가능하다며 불평불만이 많았지만 암튼 참여회사들의 힘이랄까? 상대적으로 WS-ReliableMessaging보다 기능이 떨어진다고 평하는 WS-Reliability가 대세가 되었다. SOAP과 함께 WS-Reliability는 어떻게 보면 웹서비스를 실제 업무에 적용하는 데 있어 첫 관문이 되는 기술이라 할 수 있다. 게다가 WS-Reliability는 SOAP과 다르게 적용 범위나 대상마다 조금씩 Customizing도 필요한 것이 많아서 여러 다양한 제품이 나올 여지가 있다. 물론 개발도 다른 웹서비스 스펙에 비하여 쉬운 편이다. 따라서 만약 처음 웹서비스 토탈 솔루션을 개발하고자 하는 업체나 단체라면 이 WS-Reliability에 눈독을 들여볼만할 것 같다.
태그 :

공유하기 버튼

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