조대협의 블로그

ALM 프레임웍중에서, JIRA와 같은 이슈 추적 시스템을 이용하여 스케쥴 관리와 작업 추적을 할 수 있지만, 프로젝트에 따라서는 이슈 추적 시스템의 도입이 어렵거나, 별도의 프로세스 정립이나 Learning Curve가 필요한 경우가 있기 때문에, 때에 따라서는 Excel 기반의 Task관리가 효율적일 수 있다. 조엘 온 소프트웨어에서도 언급된바있는 내용인데, 엑셀 항목에 TASK # | Category | Sub task | Detail Task | Assignee | Priority | Due data | Status 를 정한다. Category는 Task의 종류가 된다. 디자인,분석 같은 단계가 될 수 도 있고, Logging,Exception Handling과 같은 각 패키지가 될 수 도 있다...

요즘 프로젝트가 바쁘다 보니, 블로그에 포스팅할 시간이 없다. REST, ROA (Resource Oriented Architecture), Collaboration, Code Review등 포스팅 하고 싶은 것들이 많은데.. 그나마 시간내서 쓰던 포스팅들도 이번달에는 거의 힘든 상태가 되었다. 아마도 다음달이나 되야, 포스팅들이 올라가지 않을까? 이번 글은 어제 저녁에 써놨던 아키텍트,PM,개발자의 차이 중 2번째로 아키텍트에 대해서 이야기 해보고자 한다. 아키텍트 아키텍트는 전체 시스템을 디자인하고 설계하는 역할을 가지는 사람이다. 아키텍처링은 크게 두가지로 나뉘어 지는데 첫번째는 비지니스 아키텍쳐, 다음은 테크니컬 아키텍쳐이다. 비 지니스 아키텍쳐랑, 해당 시스템이 비지니스적으로 어떤 의미를 갖는지..

예전 플루토 미디어에서 ALM에 대해서 강의한 내용이 온라인으로 올라왔습니다. http://www.bizdeli.com/online/detail.asp?pfid=S2343 에 있구요. 유료로 올라왔네요. 작년에 여러군데서 강의했는데, 혹시 필요하신데 못 들으신분들은 참고하시면 되겠습니다.

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

ALM의 이슈트랙킹 시스템을 통한 프로젝트 관리 방법입니다. 아래 그림이 구현하고자 하는 내용의 모두라고 볼 수 있습니다. PM : 요구 사항을 시스템에 등록하고 각 요구 사항에 대해서 스케쥴링을 한후에 각 요구사항을 해당 개발팀의 팀장에게 ASSIGN합니다. PL : PL은 각 요구사항을 분석하여 실제 작업(TASK)로 쪼게고 개발자의 스케쥴과 역량 그리고 작업의 심각도와 긴급도에 따라서 개발자에게 ASSIGN합니다. 개발자 : 개발자는 진척 상황을 TASK에 COMMENT로 로깅하고, 각 TASK에 연관된 단위 테스트 케이스를 작성하여 진행을 합니다. PM은 요구 사항을 개발 PL뿐만 아니라, QA 팀에도 ASSIGN하는데 QA 팀에서는 각 요건을 검증할 수 있는 테스트 케이스를 개발 초기단계 부터 ..

제 블로그에 자주 오시는 분들이나 혹은 강연이나 기고를 보신분들은 아시겠지만 2008년 한해는 ALM (Application Lifecycle Management)쪽에 많은 시간을 할애한 한 해였습니다. CI(Contiguous Integration), Unit Test,실용주의 방법론이 유행한 한해이기 때문에, 유난히 관련 서적을 많이 접했던 이유도 있지만 컨설턴트로써 프로젝트 관리와 소프트웨어 품질 관리에 대한 필요성이 많았기에 많은 시간을 부었습니다. ALM에 대해서 시간이 나는데로 좀더 정리를 해보고자 합니다. 제가 이야기 하는 ALM은 기존의 어떤 방법론이나 사상은 아닙니다. 프로젝트를 하면서 필요하다고 생각되는 부분을 묶어서 정리한 하나의 간단한 방법론 정도로 생각하면 됩니다. ALM은 크게 ..

PM,아키텍트,개발자.. 모두 프로젝트에서 없어서는 안될 사람들이다. IT 생활을 하다보니 각자의 역할이 명확하게 다르고 거기에 요구 되는 능력도 다르다는것을 알게 되는데. 반대로 제역할을 못하는 사람들과 일을 하게 되면 참으로 고달퍼 지는건 사실이다. * 프로젝트 메니져 프로젝트 메니져의 역할은 어떻게든 프로젝트를 성공적으로 끝내는 것이다. 인원이나 일정에 대한 관리뿐만 아니라, 특히 돈 (Budget)과 위험요소(Risk)에 대한 관리가 중요하다. 무엇보다 중요한것은 Communication이다. 고객과의 의사소통과 팀원들과의 의사소통이 가장 중요한 역할이다. 그 과정에서 RISK들이 자연스럽게 도출되고, 각자의 능력을 최대화해줄 수 있는 방법을 찾을 수 있게 된다. 경험상 많은 프로젝트 관리자들을 ..

요즘 진행하고 있는 프로젝트 성격상 XML에 관련된 작업이 많습니다. 그중에서 흥미로운것을 하나 발견해서 Posting을 하는데 JAVA2XML 솔루션입니다. Java2XML 솔루션이란 한마디로 Java ValueObject를 XML 문서로 변환해주거나 XML 문서를 Java ValueObject로 변환해주는 라이브러리들을 이야기 합니다. XML Scheme가 Class의 데이타 타입을 정의해주는 원리입니다. 예전에는 Castor와 같은 오픈소스 프레임웍들이 유행을 했지만 요즘은 J2EE5부터 JAXB2.0이 들어 있어서 JAXB2.0을 추천할만합니다. 사용법도 쉽고, 성능도 상당히 좋아져서 프로젝트에 사용하기에 무리가 없습니다. 그런데 재미있는 녀석중에 하나가 XMLBeans입니다. JAXB의 경우 J..

ALSB에서 SOAP 을 REST POX (Plain Old Xml)로 변환하는 XmlBeans 구현 예제. ALSB에서 Java Callout으로 사용이 가능함 == import javax.xml.namespace.QName; import org.apache.xmlbeans.XmlCursor; import org.apache.xmlbeans.XmlObject; import org.apache.xmlbeans.XmlCursor.TokenType; public class RESTTransformer { public static XmlObject toREST(XmlObject soap){ XmlCursor cur = soap.newCursor(); cur.toFirstChild(); cur.toChild(n..

Mediation에서 Route To 추가하고 거기에 Dynamic Routing 추가한후에, Expression에 다음과 같이 써줌 GeneralProxySampleProject/samplewebservice/localproxy/PersonService.local == Route하고자 하는 destination이 Proxy일 경우 isProxy를 true로 해줄것. service 경로는 "프로젝트명/폴더.../폴더/Proxy명" 예를 들어 default 프로젝트의 localproxy 폴더의 common.local.proxy의 경우 default/localproxy/common.local (.proxy를 뺀다.) 가 된다.

JAX-WS를 이용해서 웹서비스를 만드는 방법입니다. 영어로 작성했지만 내용은 쉽습니다. Overview This is a programming guide for component developer to make a webservice easily. Technical Standard This is webservice creation guide for component team. We will use webservice development standard like this. JAX-WS JAXB Standard IDE is WebLogic workshop 10.3. You can use any IDE that you want. JAX-WS is standard.WebLogic provides eaises..

SOAP2REST 변환에서 유용하게 사용할 수 있음 == ==

0123456789 " " true false :null , { : , } [ null , ]

SPEC도 없고, 적당한 구현 프레임웍도 없던 REST가 드디어 반격을 시작하는지? 여기저기서 들려오는 소리가 대부분 REST에 대한 소식이다. WSDL처럼 REST의 스펙을 정의하는 WADL REST 프로그래밍 스펙이 JSR 311-JAX RS로 등록이 되고 Sun에서는 JAX RS의 Implementation체인 Jersey (https://jersey.dev.java.net/) 도 있고.. WSDL2.0에서도 REST스펙이 추가 되었다하니 아마 REST 기반의 개발이 가속화 되지 않을까? 금년에는 유난히 REST에 대한 이야기가 많네 그랴..

WebLogic Workshop 10.3 기준입니다. (9.X 이후는 비슷합니다.) WLW에서 EJB 작성 방법 1. EJB 프로젝트를 생성 2. Project Facet에서 EJB Module 2.1을 선택, WebLogic EJBGen Support 를 선택 3. EJB 코딩 (이때 메서드를 클릭하면 Property에 속성을 선택할 수 있는 창이 나옴) 4. CLIENT JAR 생성 방법 : Project를 선택 > 오른쪽 버튼 > WebLogicEJB 선택후, > Jar setting – EJB client.jar에서 use default 해제하고, 여기에 상대 경로 예를 들어 client/EJBclient.jar라고 써주면 EJB 를 export할때, ${EJB_PROJECT}/client/EJB..

문제는 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..

ESB에 대한 부하테스트를 SOAP UI를 해보니.. 400 Thread에서 Connection Refused가 계속 나왔다. 원인은 Apache에서 Connection Refuse를 보낸것이었고 Apache 용량 부족이었는데. ServerLimit Parameter가 제대로 작동 하지 않았다. 버그인지.. 넣는 위치에 영향을 받네. 아래는 설정값

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

WebLogic 10.3 에서, WebLogic Workshop (이클립스 기반 IDE)를 가지고 JAX-WS 기반으로 웹서비스를 생성하기 JAXB를 표준 데이타 포맷으로 사용하였고. 매우 심플하고 간단함

ALL : http://www.w3schools.com/sitemap.asp XQuery : http://www.w3schools.com/xquery/xquery_add.asp JAXB Annotation http://edocs.bea.com/wls/docs103/webserv/data_types.html JAX-WS Annotation http://edocs.bea.com/wls/docs103/webserv/jws.html#program_jws_file

1. OSB 설치시 Default로 하면 Eclipse를 인스톨 하기를 요청하기 때문에 Custom으로 선택하고 Workshop에서 Eclipse 모듈을 제외하고 설치할것. 2. Managed Server을 추가로 추가하기가 복잡하기 때문에, 아예 설치시부터 Managed Server를 추가하는 것이 좋다. 3. DBMS를 사용하기 때문에, 초반에 DB 설정을 해놓고 인스톨하는 것이 좋다.

강좌 같은 것 만들어서 배포하고 싶을때가 있었는데.. 화면 레코딩할 수 있는 소프트웨어가 대부분 상용이라서 못하고 있었다가.. 서핑중에 괜찮은 도구 하나 찾아서 링크!! http://camstudio.org/

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..

SCA (Service Composition Architecture)가 1~2년전에 나타났다가 요즘 잠잠하더니.. Oracle Product에 다시금 나타났다. ESB, Repository 등등 모든 제품들이 SCA를 지원하고 나섰는데.. SCA 개념 자체가 좋은 개념이기 때문에 구현만 잘된다면 새로운 Composition (또는 Orchestration 아키텍쳐)로 사용되기 충분할듯 하다. 작년에 정리해놨던 SCA 소개 자료를 첨부한다.

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

Unit Test with Easy Mock 자바스터디 조대협(bwcho75@지메일.컴) 단위 테스트는 소프트웨어 구성 요소의 각 컴포넌트를 독립된 환경에서 테스트 하는 것이다. 그렇지만 일반적으로 소프트웨어 컴포넌트는 혼자서 동작할 수 없고 다른 컴포넌트에 대해서 종속성(Dependency)를 가지고 있기 때문에 종속관계에 있는 컴포넌트가 완성되지 않거나 그 컴포넌트에 오류가 있으면 정상적으로 테스트를 진행할 수 없다. 이 문서를 읽기 전에 먼저 Junit 테스트에 대해서 숙지하기 바란다. http://bcho.tistory.com/entry/단위-테스트-1회-JUnit 이런 문제를 해결하기 위해서 사용하는 것이 Mock Object 이다. Mock Object는 가상 오브젝트로 테스트를 위한 Oper..

Mylyn을 이용해서 이클립스 상에서 JIRA를 웹 인터페이스가 아닌 클라이언트 인터페이스로 사용할 수 는 있지만 부족한 느낌이 많았다. 그래서 사실 사용도 안했고 오늘 다른것 찾던중에 JIRA 전용 클라이언트를 발견... 가격도 그리 비싼거 같지 않고. 뷰가 마치 아웃룩 같다. Polarion 등에서 이런 뷰를 제공하는게 부러웠는데.. 더 이상 부러울것이 없는듯. 아직 사용은 못해봤는데.. 웹보다 편할지 아닐지는 써봐야 할거 같고. 보기에는 일단 마음에는 든다. http://almworks.com ALM 솔루션,빌드 자동화, 테스트 모두 모아서 조합해놓고.. 판매하고 컨설팅하는 회사나 하나 차릴까? 솔루션 컨설팅하면서 할려니 정말 깊게 볼 시간이 없네.. 그랴..

ALM 이후로 가지고 놀 수 있는 장남감을 찾던중에 발견한 장난감. 요즘 Vitualization과 cloud computing 이야기가 많은데. Cloud computing중에서 data grid에 해당 하는 부분 자바 애플리케이션을 개발하면 문제중에 하나가 JVM Instance끼리 데이타 공유가 불가능하다는 것이다. 이런 경우는 DB나 FILE을 이용하는데 성능상의 문제도 많고 DB로 공유하기에는 어려운 데이타들이 있는 것이 사실인데. 이런것을 커버해주는 것이 NAM (Network Attached Memory)라는 개념이다. 애플리케이션 입장에서는 일반적인 메모리를 ACCESS하는 것처럼 사용하지만, NAM 서버들이 서로 클러스터링 되어서 대용량의 데이타를 애플리케이션 입장에서 하나처럼 보여주는 ..

ALM 플랫폼을 만들었을때 대충 컴포넌트가 프로젝트 관리 부분 테스트 자동화 부분 자동 빌드 부분 3군데로 나뉘어져서 디자인을 했고. 각 모듈에 사용 되는 제품들은 오픈소스들을 대부분 조합하였다. 그런데 이 경우 seamless하게 제품을 조합하는 것과 유지보수 문제에 대한 고민이 있어서... 혼자 생각으로 이런 모든 Full Process를 묶어서 제품화 했으면 좋겠다 생각을 했는데. 오늘 우연히 구글 광고에서 재미있는 제품을 발견했다. http://www.appperfect.com 단위 테스트 자동화, 부하 테스트, UAT등을 지원하고 요건 관리,테스트 케이스 관리등이 모두 지원된다. 겉보기에는 썩 괜찮은툴인듯... ^^ 아직 한국에 들어오지 않은게 아쉽지만 가격도 꽤 경쟁력 있어보이는데... 항상 ..

WebLogic에서 간만에 재미있는 기능을 찾아서 포스팅. ESB나 EAI 제품과 같은 아키텍쳐에서 Sync Call의 구조를 보면 다음과 같다. Request가 들어오면 특정 Thread가 그 request를 받아서 Backend의 Component에 보내고, 응답을 기다린다. 응답이 오면 Client에게 그 응답을 전달하는 구조이다. 그런데 이 경우 Client에서 요청을 받은 후 그 요청을 Component에 전달하고 나면 Component로 부터 응답이 오기까지는 Request Thread는 아무것도 하지 않고 단지 기다리기만 한다. 즉 하는 일없이 Thread만 점유하고 있는 것이다. 만약에 Component에서의 처리시간이 오래 걸리게 되면 Request Thread가 held 되는 시간이 늘..