조대협의 블로그

SOA 아키텍쳐중에 요건중의 하나가 웹서비스로 들어오고 나가는 데이타에 대한 Transformation과 Filtering이 문제인데, 일반적으로 ESB에서 이를 구현하고 결과적으로 과도한 XQuery로 성능저하로 아주 많은 문제를 일으키는 경우가 있는데, 이에 대한 대응 아키텍쳐로 SoapHandler를 사용해 보는 방법을 고려해볼 수 있다. WebService는 일반적인 형태로 개발하고, Filtering이 필요할 경우 앞에 Filter의 기능에 따라서 SoapHandler를 붙이고 다른 endpoint를 부여 하는 방식을 사용할 수 있다. 자세한 내용은 여기에.. http://www.javaworld.com/javaworld/jw-02-2007/jw-02-handler.html?page=3 조만간 ..

http://www.crosschecknet.com/ SOA 구현시 테스팅이 문제인데, 기존에 SOAP UI만 사용하다가 좋은 툴을 발견 HP TC와 연동도 되고, JUnit형태로도 뽑아져서 Regression(회귀) 테스트에도 반영 가능하단다. InforWorld에서 SOA 테스팅 툴 부분에서 가장 좋은 점수를 받은 툴

SOA 시스템에 대한 컨설팅 (설계나 Code Inspection)을 다니다 보면, Goverance나 프로젝트 관리상에서도 문제가 많이 나타나지만, 설계상에서 근본적인 문제로 나타나는 패턴들이 있다. SOA의 근본적인 정의를 다시 내려보면, "비지니스적인 의미를 가지는 컴포넌트를 기업내의 통합된 프로토콜로 서비스하여 제공한다." 이다. BPM을 이용한 Composition이나 ESB를 이용한 유연성의 증대도 SOA 에서 큰 의미를 차지하지만, 일단 시작은 SOA를 통해서 제공되는 컴포넌트의 형태이다. 즉 기본이 되는 SOA 서비스와 그 인터페이스에 대한 정의와 구현이 제대로 되어야 하는데 통상적으로 SOA 시스템을 설계하고 구현하는데 있어서 발견되는 실수는 다음과 같다. 1. 표준 전문의 미사용 서비스..

OMG에서 SOA를 디자인할 수 있는 UML의 확장판인 SOAML을 발표했습니다. http://www.omg.org/docs/ad/08-08-04.pdf SOA 시스템 디자인하기에 편하겠네요.

1. Cloud and grid computing 클라우드 컴퓨팅과 이를 구현하기 위한 솔루션인 그리드 컴퓨팅은 금년에도 이슈가 될것같다. 구글이나 야후, 아마존들을 중심으로 한 글로벌 서비스 기업들이 그리드와 클라우드 컴퓨팅에 선두가 되고 있지만 정작, 기업에 있어서 클라우드 컴퓨팅이나 그리드 컴퓨팅의 도입은 소극적이다. 특히 클라우드 컴퓨팅의 경우 보안이나 성능상의 이슈로 기업에 도입이 될지 않될지는 지켜봐야 할것 같지만 그리드 컴퓨팅의 경우 Coherence와 같은 Data Grid제품이나, Hadoop과 같은 File grid, grid dbms등은 기업에도 충분히 사용이 가능한 솔루션이다. 얼마나 기업 고객들이 이 개념들을 이해하고 적응하느냐가 관건일테고, 다른 한축으로는 대부분의 그리드 솔루션..

문제는 JMS Proxy에서는 Transaction start를 지원하지만 가장 많이 사용하는 WebService Proxy는 Global Transaction을 start하지 않기 때문에 Transactional EJB를 Composition하는 경우 분산 트렌젝션에 대한 구현 문제가 생긴다. 방법은 두가지 인데. 1) 단순하게 EJB를 하나 만들어서 ALSB(OSB)에 배포하여 Code로 Tx를 composition한후, 이 EJB를 Biz Service로 등록하고 WebService로 Expose하는 방법 2) 좀더 OSB 다운 방법은 WebService Proxy에서 JMS Q로 callout한후 JMS Proxy에서 읽어서 Tx 처리하고나서 Recv Q에 return하면 WebService Pr..

간만에 파워포인트와 MS-WORD를 놓고 이클립스를 열었는데.. 하루종일 xsd,x query,x path,wsdl과 싸움... 오랜만에 머리 쥐나는 느낌... SOA도 생각보다 신경써야 할 부분이 많다~~

SOA 프로젝트를 하다보면 Mash up과 Composition를 혼용해서 쓰는 사람들이 종종있다. 먼저 유래부터 살펴보면 SOA 사상이 먼저 나온후에, WEB 2.0 이란 사상이 대두 되고, SOA의 무거운 부분과 복잡성을 제외하고, 단순성과 편의성을 위주로 OPEN API라는 개념이 나왔다. SOA에서 통상적으로 웹서비스로 구현되는 서비스를 JSON이나 PLAIN OLD XML등과 같이 경량의 사용하기 쉬운 메세지 포맷을 이용해서 OPEN API라는 것이 개발되었고, 이 오픈 API를 조합하여 새로운 기능을 만들어 내는것을 MASH UP이라고 한다. SOA WEB 2.0 컴포넌트 개념 웹서비스 기반의 서비스 경량 기반의 서비스 서비스 조합 Composition (Orchestration) Mash u..

SOA가 나온지도 오래되었고 개념이 좋다는 것은 다들 인정하고 있지만 쉽게 확산 되지 않는 이유가 무엇일까? 결과부터 따져보자면 성공적인 SOA

오늘 WOA에 대해서 듣게 되었는데. 역시나 생각들은 비슷한가보다. SOA로 대표되는 아키텍쳐는 기본적으로 엔터프라이즈 시스템을 위해 고안되었고 그로 인해서 기업의 업무를 충실히 지원하기 위해서 많은 기능들을 제공한다. 그로 인한 문제가 복잡도가 많이 올라갔다는 것인데... WEB 2.0 사상이 나오면서 REST,JSON,POX(Plain Old XML)등과 같이 이른바 OPEN API로 지칭되는 서비스들에서 사용되기 위한 경량의 프로토콜과 메세지 포맷, 네트워크 아키텍쳐들이 많이 소개 되었다. WOA는 SOA의 사상과 같이 서비스 중심의 아키텍쳐 이면서 서비스를 제공하지만 SOA와 같은 강력한 기능 (트렌젝션, 여러 메세징 방법과 프로토콜)을 지원하지 않지만 최소한의 기능을 최대한 쉽게 지원하는데 목적..