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)


Loose Coupling Enterprise

coupling이란 서로 상호작용하는 시스템들간의 의존성을 의미한다. 의존성은 실질적 의존성과 인위적 의존성으로 나뉠 수 있다. 실질적 의존성은 한 시스템이 소비하는 다른 시스템의 기능이나 서비스 집합을 의미한다 인위적 의존성은 한 시스템이 다른 시스템이 제공하는 기능이나 서비스를 소비하기 위해 필요한 여러 요소들의 집합을 의미한다. 전형적으로 인위적 의존성은 언어적인 의존성, 플랫폼 의존성, API 의존성등이 있다. 인위적 의존성은 언제나 존재하지만 그 비용은 충분히 감소될 수 있다. Loose Coupling은 이러한 인위적 의존성을 최소한으로 줄이는 구조를 의미한다.
from WebServices Architecture Glossary of W3C

공유하기 버튼

 

웹서비스 프로토콜 스택 Enterprise

쓸만한 웹서비스 프로토콜 스택그림을 찾았다. 비록 완전하지도 않고 미묘한 의견대립을 가져올 수 있는 그림이지만 이를 기반으로 적절한 아키텍처 그림을 그려볼 수 있을 것이다. 일단 BP관련 기술이 Description에 있다는 것이 조금 의아스럽다. 또한 문서 Semantic에 대한 부분이 결여되어있는 점 등이 아쉽다


공유하기 버튼

 

웹서비스의 policy모델 Enterprise

GXA 아키텍처에서 가장 핵심이 되는 스펙중의 하나는 WS-Policy이다. 바로 이전 블로그에서도 언급하였듯이 Policy라는 것은 어떤 웹서비스가 있을때 그 웹서비스가 제공하는 서비스의 여러 정책을 나타내는 용어이다. 이를테면 서비스를 제공하는 입장에서 보안을 위하여 프로토콜 수준에서 SSL을 사용하고자 하며 메시지 수준에서는 X.509 혹은 Kerberos를 사용할 수 있으며 언어는 한글과 영어를 동시에 지원한다던지 메시지의 Hop을 지정하는 등의 여러가지 정책과 서비스 Quality등을 미리 제시하고 클라이언트가 이에 대해 미리 준비를 할 수 있다면 보다 안정적인 웹서비스 환경을 구축할 수 있을 것이다. 따라서 이러한 정책에 대한 표준은 웹서비스가 보다 높은 차원의 질을 제공하는 데 없어서는 안될 중요한 요소이다. 더욱이 웹서비스의 특성상 그 어떤 미래의 보안 및 기타 기술의 요소들도 포함할 수 있어야 할 것이므로 그 확장성이 무엇보다 요구되는 스펙이라 할 수 있다. 이렇게 기존의 WSDL에 더 나아가 서비스에 대한 본격적인 Quality와 Policy를 기술하는 관련 기술에는 크게 GXA의 WS-Policy와 ebXML의 CPPA가 존재한다. 비록 쓰임새와 모양새는 서로 다르기는 하지만 기본적인 취지는 대동소이하며 모두 매우 잘 설계된 XML의 표본이다. CPPA의 경우 전자상거래라는 특수 분야에 맞추어서 보다 구체적이며 일찍부터 사용된 만큼 많은 부분에서 노하우가 쌓인 기술인 반면에 GXA의 WS-Policy의 경우 이제 막 시장에 나온 기술이기에 보다 높은 수준의 확장성을 지닌 특징을 가지고 있다. 또한 두 스펙의 큰 차이중의 하나는 CPPA의 경우 ebXML RegRep을 통해 Publish된다는 점이고 WS-Policy의 경우 UDDI의 특정 개체와 WS-PolicyAttachment라는 기술을 통해 연결되어 Publish되고 사용된다는 점이다.

공유하기 버튼

 

WS-Policy에서 자주 쓰이는 용어정리 Enterprise

Policy : Policy Assertion으로 표현되는 모든 추상적인 정보를 일컬을 때 Policy를 사용한다.
Policy Assertion : 어떤 개체 각각의 우선순위, 요구사항이나 환경, 능력 혹은 속성등을 표현하는 단위.
Policy Expression : 하나 이상의 Policy Assertion을 포함하는 XML 정보집합을 일컫는다.
Policy Subject : Policy Expression이 관계를 맺고 있는 entity들(endpoint, object, resource...)
Policy Attachment : Policy Expression과 하나 이상의 subject들이 서로 관계를 맺는 메카니즘

공유하기 버튼

 

WS Reliable Messaging 스펙 간단 비교 Enterprise

요즘에 틈틈히 웹서비스의 RM관련 스펙을 들춰보고 있다. ebXML MS와 WS-RM, 그리고 WS-Reliability 총 세개이다.

좀 더 세부적인 비교가 이뤄져야 겠지만 총평을 하자면 WS-Reliability는 정말로 구리다는 것이다. Routing에 대한 이야기나 Security에 대한 얘기도 쏙빠지고 Policy에 대한 이야기도 언급이 없이 순수하게 그냥 Reliable Messaging에 대한 개념적인 이야기만 풀어대고 있다. ebXML MS스펙에 참여한 사람이 WS-Reliability에도 참여하고 있건만 ebXML MS 아류작도 안되는 듯... 아직 드래프트버젼이라고는 하지만 지금 세월이 어느 세월인데 아직도 이 정도의 수준에서 머무르는 것인지...-_-;;; 가장 큰 문제는 RM의 문제는 결코 RM에 대한 이야기로 마무리될 성질의 것이 아니라 보다 큰 아키텍처적인 측면에서 바라보고 Security와 Policy에 대한 긴밀한 연결관계속에서 해결책을 보여줘야하는 것인데 그러한 면에서 GXA나 ebXML에 비해 너무 부족한 듯 보인다.
반면에 WS-ReliableMessaging의 경우에는 MS가 만들고 있는 GXA의 탄탄한 토대위에서 만들어진 스펙이다보니 WS-Policy나 WS-Routing 그리고 WS-Security와의 연계관계를 매우 짜임새있게 서술하였다. 하지만 실제 구현물에 바로 적용할 수 있는 모양새가 갖춰진 듯한 느낌은 들지 않는 것이, RM에 대한 보다 명확한 각 시나리오별 Sequencing에 대한 것이 다뤄지지 않았으며 WS-Security를 적용하였을 때의 보다 명확한 지침이 다뤄지지 않았다. 하지만 일단 뼈대있는 아키텍처에서 탄생한 스펙이기에 될성 싶은 떡잎으로 평가한다.
마지막으로 ebXML MS는 이미 많은 업체에서 구현물을 내놓고 서로간에 상호운영성테스트를 진행하고 있는 스펙이니 더 말할 필요는 없을 것 같다. 물론... 상용화하는데에는 아직도 많은 문제가 남아있기는 하지만 현재까지는 그나마 가장 현실적인 대안인 듯 싶다.

공유하기 버튼

 

GXA Enterprise

나는 가끔 주위 개발자분들로부터 웹서비스 적용에 대한 질문을 받곤 한다. 이러이러한 통합의 문제가 있는데 이것을 웹서비스 기술을 적용하는 것이 어떠한지를 묻는 질문이다. 참으로 난감한 질문이 아닐 수 없다. 왜냐하면 난 아직까지도 웹서비스가 덜 여문 갓난아기의 기술이라고 생각하기 때문에 섣불리 권할 수 없다. 만약 보다 Critical한 부분에의 웹서비스 적용이라면 대체 SOAP을 어떻게 믿고 섣불리 적용하느냐고 반박할 것이며 덜 Critical하면서 단지 두 모듈간의 결합과 단순한 메시지 교환을 위한 것이라면 굳이 SOAP같은 덩치 크고 느린 기술을 쓸 이유가 없이 XMLRPC를 쓰면 된다고 반박할 것이다. 우리 주위의 EAI수준의 문제거리들은 대부분 웹서비스를 이용하지 않아도 충분하다.
우리가 간혹 듣게 되는 SOA 즉 서비스 중심의 아키텍처는 이제껏 우리에게 문제시 되었던 엔터프라이즈 환경에서 기업내부의 통합을 위한 개념이라 보기는 힘들다. 그보다는 점차 합병과 협력을 통해 기업의 덩치를 키우고 마케팅 효과를 극대화하기 위한 여러 글로벌한 비즈니스 요구사항이 거세지는 앞으로의 기업 요구사항에 대응하기 위한 개념이 SOA라고 나는 생각한다. 따라서 이러한 아키텍처를 구성하는 데에는 생각보다 오랜 시일이 걸린다.
우선 서비스 중심의 아키텍처의 큰 그림을 그려서 보다 안정적이면서도 상호운영성을 획득할 필요가 있으며 그와 함께 비즈니스 중심의 표준 아키텍처의 도입이 필수적이다. 그 중에서도 서비스 중심의 웹서비스 표준 아키텍처 중의 하나가 바로 W3C에서 IBM이나 MS등이 진행중인 GXA이다. 벌써 2001년에 그 개략적인 그림이 나오고 여전히 갈 길이 먼 GXA는 그동안 꾸준히 여러 관련 스펙이 나옴으로써 조금씩 그 모습을 드러내고 있으며 나는 조만간 이 GXA와 ebXML의 비교를 시도하고 싶다.

공유하기 버튼

 

WSCI와 BPEL4WS Enterprise

웹서비스는 각종 예측통계나 전문가들의 의견을 빌지 않더라도 앞으로의 IT를 이끌 핵심 기술임에는 누구도 부인하지 않는다. 또한 웹서비스는 단순히 애플리케이션의 통합이 아닌 비즈니스 서비스의 통합을 성취할 핵심 기술이기 때문에 많은 기업들에서 관심을 갖는 기술이다. 지금도 많은 기업들은 웹서비스의 표준화를 위해 노력하고 있으며 상당부분 진척되고 있는 상태이다. 그 중에서 Choreography 표준의 경우는 비즈니스와 맞닿아 있는 최전선이기 때문에 각 기업들이 더욱 첨예하게 그들의 이익을 대변하기 위해 노력하고 있는 분야이기도 하다. 그러다보니 현재 표준도 두 개로 양립되어 있는 형국이다. BPEL4WS:IBM,MS,OASIS - WSCI:Oracle,Sun, BEA,SAP등의 29기업, W3C 초기에는 오히려 이러한 대결형국이 서로의 발전에 영향을 끼치며 긍정적인 효과를 가져오겠지만 머지않아 이들의 승패가 결정날 것으로 보인다. 물론 아직은 잘 모르겠지만.. ^^

공유하기 버튼

 

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


Google Analytics