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)


공짜로 구할 수 있는 J2EE 소프트웨어 Programming

오늘은 매우 흥미로운 글을 발견하였다. ONJava.com의 글인데 내용은 공짜로 구할 수 있는 EJB관련 툴들에 대한 설명이었다.
원문: http://www.onjava.com/pub/a/onjava/2003/02/26/ejbinherit5.html?page=1
먼저 오픈소스로서 구할 수 있는 J2EE서버에 대한 설명이다.
JBOSS 워낙 유명한 오픈소스계 대표 J2EE서버이니까 다들 한번씩은 들어봤을 것 같다. 요즘들어 각종 해외 사이트에서 더욱 관심을 가지고 종종 소식을 전해준다. 이 JBOSS를 주관하는 곳은 사실 개발자 커뮤니티가 아니라 JBOSS Group이라는 회사이다. 그래서 언젠가는 이 JBOSS가 상용화가 될 것이라는 소문이 돌았다고도 한다. 하지만 아마도 그럴 것 같지는 않다. 왜냐하면 참여하고 있는 이들은 이 JBOSS를 J2EE서버계의 톰캣같은 존재로 키우고 싶어하는 것 같기 때문이다. 아무튼 현재 이 JBOSS는 EJB2.0을 지원하고 CMP, JMS, JTA, Servlet/JSP, JNDI, JMX, SOAP등을 지원하여 여느 상용 서버 못지 않은 성능을 자랑한다. 하지만 아직 매뉴얼등이 많이 부족한 상태이고 이러한 컨설팅을 원할경우 JBOSS Group에게 대가(?)를 지불해야한다. -_- http://www.jboss.org/
JOnAS 이 서버가 JBOSS보다 안유명한 이유는 영업을 못해서라고 밖에 할말이 없다. 한 1년전인가의 벤치마킹 결과로는 이 JOnAS가 JBOSS보다 월등히 좋은 성능을 자랑했던 자료를 본 적이 있었기 때문이다. 더욱이 JBOSS는 미국개발자들 중심으로 진행중이고 JOnAS는 유럽 개발자들 중심으로 진행중이어서 사실 묘한 경쟁의식이 있는 제품들이기도 하다. 아무튼 이 제품도 이제 막 EJB2.0을 지원하기 시작하며 성능도 꽤 좋은 오픈소스 제품이다. 이 제품 역시 JBOSS처럼 ObjectWeb이라는 그룹이 관리하여 프로젝트가 진행중이며 이 그룹에서는 이 JOnAS뿐만 아니라 JORAM이라는 꽤 유명한 오픈소스 JMS엔진도 개발하고 있다. 또한 이 ObjectWeb이라는 그룹은 사실상 Bull.com이라는 회사 개발자들이 주축이 되어 운영되고 있다고 한다. http://www.objectweb.org/jonas

이 외에도 비록 오픈소스 프로젝트는 아니지만 공짜로 구해서 사용할 수 있는 J2EE서버는 꽤 많다. 나열해보자면 J2EE 1.4 SDK, HP-AS, Sun ONE Application Server 7, Sybase EAServer 등이다. 또한 이 글에서는 각종 EJB개발에 필요한 툴들에 대해서도 설명하고 있는데 이 글에서 미처 다 설명하지 못한 그 무수한 툴들을 소개하는 리스트 사이트를 알려줬다. EJB개발자는 필히 북마크를 해두자.
Javamug's J2EE links JMiddleware.com's EJB links Java Skyline's Enterprise Development page 일단 적어도 아주 유명하고 필수적인 툴에 대해서는 잠깐씩 언급해보자.
Ant 물론 Ant는 J2EE개발이 아닌 어떠한 자바 개발에도 필수이긴 하지만 특히 Ant의 EJB 태스크를 사용하면 아주 편리하게 작업이 가능하다. 즉 벤더들의 특성에 맞게 배치와 컴파일등을 할 수 있는 옵션 팩을 사용하면 훨씬 편리하게 작업이 가능하다. 관련 URL: http://ant.apache.org/manual/OptionalTasks/ejb.html

JUnit 뭐 JUnit 자체로는 EJB 테스트가 힘들기 때문에 여러 확장 툴을 사용하는데 가장 유명한 것은 아무래도 Cactus일 듯 싶다.

Lomboz Lomboz는 이클립스의 플러그인이다. 이전에 웹로직으로 개발할 때 아주 편리하게 잘 사용했었다. Lomboz는 웹로직뿐만 아니라 JBoss나 톰등도 지원한다. 아직 조금 불안한 면이 있기는 하지만 J2EE개발에 조금 빈약한게 사실인 이클립스로서는 아주 고마운 툴이 아닐 수 없다.

EJBGen EJBGen은 자동으로 빈 클래스들을 생성해주는 툴이다. 요즘에는 좀 괜찮다싶은 IDE에서는 이러한 기능을 제공하기 때문에 나는 사용해본적이 없다.

XDoclet XDoclet 이거 정말 물건이다. Ant task를 이용하여 자동으로 각 벤더 제품에 맞는 코드를 자동으로 생성해주는 툴인데 아주 다양한 기능을 가지고 있는 듯 하다. JavaDoc Doclet 방식으로 코드에다가 특정 형식에 맞게 적어주면 자동으로 뭔가를 많이 해주는 거 같은데 시간이 없어서 아직 제대로 보지는 못했다. 하지만 정말 편할것만 같은 툴이다.

MiddleGen MiddleGen은 나도 처음 들어본 툴인데 GUI방식으로 각종 벤더에 맞게 Entity Bean이나 JDO, JSP등을 만들어준다고 한다. 항상 까만 콘솔화면에서만 작업하는 게 싫증나는 나로서는 아주 반가운 툴이 아닐 수 없을 것 같다. 지원하는 벤더서버도 매우 다양하다.(JBoss, HP AS, WebSphere, WebLogic..)

공유하기 버튼

 

Axis를 이용하여 JMS 애플리케이션 개발하기 Enterprise

내가 만든 ebXML RIM/RS 솔루션은 웹서비스의 UDDI와 비슷한 기능을 제공한다. 주로 비즈니스 문서 저장소로서의 역할을 가지며 모든 것이 XML방식으로 이루어진다. 아무튼 이 제품에 드디어 비동기의 날개를 달 때가 다가온다. ebXML RIM/RS의 새로운 스펙에서 드디어 비동기적인 메시징 처리를 필수로 요구하기 때문이다. SOAP을 갖고 메시징을 하는 데 있어 자바쪽에서 Axis만한 확장성있는 제품은 존재하지 않는다.
이 Axis는 현재 아파치 프로젝트에서 진행중이고 IBM이나 BEA등의 WAS뿐만 아니라 OC4J등 대부분의 자바 제품군들에서 기본적으로 Axis지원을 약속할만큼 유명하다. 오늘 보게된 아티클은 IBM DeveloperWorks에서 제공하는 Programming JMS applications using AXIS라는 기사이다. 이는 간단한 예제와 함께 어떻게 Axis에서 JMS 애플리케이션을 구동할 것인지 아주 잘 설명하고 있다.
JMS엔진은 IBM의 MQSeries인데 뭐 대부분 JMS하면 이 제품을 사용할테지만 나의 프로젝트에는 일단 Open JMS나 기타 다른 공개용으로 써야할 것 같다. 보통 내가 알고 있는 ebXML 제품들 중에는 비동기처리를 지원하지 않는 것들이 상당히 많다. 웹서비스의 낮은 신뢰성에도 불구하고 아직까지는 이러한 비동기처리마저도 제대로 되지 않는 것이다.
여러가지 이유가 있겠지만 아직까지 웹서비스에서의 비동기처리의 개념을 개발자들이 파악하지 못한 것이 아닐까도 생각해본다. 아무튼 아래 그림은 JMS엔진을 사용하였을 때의 서버와 클라이언트간의 통신 구조를 나타낸 것이다.

그림에서 보는바와 같이 JMSSOAP Client는 Axis의 Call객체를 이용하여 원격의 서버 종단점에 대한 여러 사항(위치, 파라미터, 서비스와 메소드이름, 전송 메카니즘)을 설정하며 AXISClient 가 여기서 만들어진 Call객체를 이용하여 SOAP메시지를 만들고 JMSSOAPHandler(이것은 Axis의 Handler를 확장하여 구현한 JMS용 클래스로서 SOAP메시지와 JMS간의 메시지 교환을 담당하는 클래스이다.)에 넘겨주면 JMSSOAPHandler는 SOAP메시지를 MessageContext(SOAP 요청, 응답 메시지를 감싸고 있는 Axis의 클래스)에 담아서 RequestQueue에 보내면 JMSSOAPListener가 onMessage() 메소드를 통해서 비동기적으로 큐에 있는 요청 메시지를 받아서 AXISServer 엔진에 메시지를 날려주면 해당 웹서비스에 메시지를 전달하고 그 반대의 경로를 통해 응답메시지가 또 다시 처리된다.
이렇게 기존의 SOAP처리 시스템에 JMS를 이용한 비동기 처리를 간단하게 할 수 있는 배경에는 Axis의 놀랄만큼 강력한 유연성이 자리잡고 있다. 좀 더 자세한 예제와 관련 문서가 필요할 때 다음 URL을 참고해야할 듯 하다.
http://www-106.ibm.com/developerworks/library/ws-jms/?ca=dnt-48h

공유하기 버튼

 

허접 오라클 OC4J Programming

요즘 내가 회사에서 하고 있는 일은 웹로직 6.1 기반으로 개발이 완료된 제품을 오라클 9ias 903 버젼으로 마이그레이션하여 포스코 파일럿 프로젝트에 적용하는 것이다.
이미 두달전부터 해오던 일이지만 앞으로도 포스코쪽에서 무수하게 추가 요구사항을 보낼 것이고 이 블로그의 많은 부분은 아무래도 포스코 험담이나 신세한탄으로 채워질 것만 같다. 하지만 오늘 할 이야기는 포스코 험담이 아니라 오라클 험담이다. 아는 사람들은 알겠지만 한국 오라클은 포스코없으면 큰일날 정도로 포스코에서 얻어가는 것이 많다. 아시아 최대 규모의 ERP 프로젝트인 포스코 PI를 오라클의 최신 ERP 패키지(구현사례도 없는 따끈 따끈한 버그투성이 제품이었다.)를 이용하여 구축하였고 DB나 WAS등 대부분의 소프트웨어 제품들을 오라클 제품을 이용한다. 이러니 혹자들은 포스코가 한국 오라클 베타테스터라는 말까지 나온다.

아무튼 오늘도 내가 한 일은 포스코센터가서 웹로직 6.1기반으로 되어있던 우리 회사 제품을 9ias로 마이그레이션 하는 것이었다. 굳이 9ias 903이라는 아직 검증되지 않은 제품을 선택해야했던 이유는 우리 제품이 CMP를 Local Interface를 이용하여 구현하였는데 이것이 9ias에서는 903 최신버젼에서만 겨우 겨우 지원하기 때문이었다. 따라서 아직 포스코에서 이 Local Interface나 CMP2 기반으로 프로젝트 한 것은 없었고 포스코측에 있는 오라클 직원들도 잘 몰랐다. 더더욱 거의 대부분 이 OC4J를 쓰기 보다는 오라클의 BC4J를 사용하여 프로젝트가 진행중이었다.

포스코센터에 상주하고 있는 WAS관리팀들도 혀를 내두르지만 정말 오라클 9ias는 관리하기 너무나 벅차고 개발자가 제대로 코딩하기에 힘들만큼 로그기능이 빈약하다. 얼마나 성능이 다른 WAS에 비하여 뛰어날 지는 모르겠으나 최신 J2EE 스펙에 대한 지원도 매우 느리고 그 흔한 GUI관리툴도 없어서(EM이라는 것이 있기는 하지만 오라클에서 조차 권장하지 않을만큼 형편없다.) 콘솔창에서 대부분의 중요한 에러 메시지를 빠뜨리는 로그파일을 보며 배치와 관리를 해야한다. 게다가 그 구조는 어찌나 복잡한지 벌써 한달 째 oc4j를 접하고 있지만 여전히 이 놈이 어떻게 동작하는 지 파악이 잘 안된다.
내가 이제껏 웹로직 6.1의 편리한 개발 환경에 익숙해져서인 탓도 있지만 JBoss가 오히려 관리측면에서는 9ias보다도 더 나은 측면이 있다. 더욱이 요 근래 웹로직 7.0을 익히고 있는데 웹로직 7.0의 그 화려한 개발환경에 감탄하다보니 더더욱 오라클 9ias의 최신버전이라는 9ias 903에 대해 정내미가 떨어질 수 밖에 없는 것이다. 그동안 오라클 9ias에 받은 상처와 눈물을 이 하나의 블로그에 모두 담을 수는 없으므로 앞으로 두고두고 씹기로 하고 이번 블로그를 마친다.

공유하기 버튼

 

03년 준비 Art and Life

공유하기 버튼

 

무관심 Art and Life

공유하기 버튼

 

언과 혜경 Art and Life

공유하기 버튼

 

민물장어의 꿈 Art and Life

공유하기 버튼

 

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


Google Analytics