'개발자/Java Enterprise'에 해당되는 글 2건

  1. 2013.05.30 Plain Old Java Object(POJO)
  2. 2013.05.15 Java Message Service API 2

POJO 란?


각종 프레임웍 책에서, 그리고 기술 서적에서 POJO라는 단어를 통해 처음 접하게 된 용어이다. 그런데 막상 책에 나온 설명을 읽고, 다시 인터넷을 찾아봐도 이해가 되지 않았다. 평범한 객체!? 명백(Plain) 오래(Old) 자바(Java) 객체(Object)라는데 이게 무슨 말일까? 


실제적으로 POJO를 이해하기 위해선 Enterprize Java Bean(EJB)를 이해해야 한다. EJB에서 나오는 빈을 사용하는데 단점들을 극복하기 위해서 시작되었다. EJB에서 복잡한 3-티어(tier) 애플리케이션 환경을 이해해야 하는 어려움이 있었다. 단순히 빈을 만들기 위해서 다양한 부모 클래스를 알아야 했고, 인터페이스를 구현해야 했던 것이다. 이러한 제약들을 없애고 '단순한 자바 객체'를 이용해 개발하자는 것이었다. 이후에는 데이터베이스와 직접 상호 작용하기 위해 POJO 기반의 하이버네이트가 개발되어고, 간단하게 작업을 ORM 기능을 구현할 수 있게 되었다.(하이버네이트를 공부해보니, mybatis보다 쉽게 데이터베이스 작업을 할 수 있다. 한번 공부해놓으면 좋은 기술이다.)


개념적으로는 자바 언어 명세에서 강제적으로 제한되어진 것을 제외하고 어떠한 제약이 없는 자바 객체를 말한다. 구체적으로 예를 들면 다음과 같다. 


1. 부모 클래스를 확장하지 않는다.

public class Foo extends javax.servlet.http.HttpServlet { ...


2. 인터페이스 클래스를 구현하지 않는다.

public class Bar implements javax.ejb.EntityBean { ...


3. 어노테이션(Annotation)을 포함하지 않는다.

@javax.persistence.Entity public class Baz { ...


하지만, 여러 이유 때문에 많은 소프트웨어 제품이나 프레임워크에서 영속성(Persistence)과 같은 기능이 제대로 작동할 수 있도록 어노테이션을 사용하도록 제한을 두고 있다.


POJO는 기존의 복잡한 것들을 버리고, 간단한 자바 객체를 가지고 일을 처리하자는 철학을 가지고 있다.

클래스를 간단히 설계하고, 이 클래스를 여기저기에 배치하기 쉽게 의존성을 줄인 것이다.



POJO는 어떻게 쓰이나?


1. JavaBeans

자바빈 = 직렬화된 POJO. 특징을 살펴 보면 생성자는 어떠한 매개변수도 갖지 않으며, 간단한 이름 명명 규칙([get|set] + 변수명)을 따르는 getter/setter 메소드를 이용해 속성(Property)에 접근할 수 있다. (이러한 규칙을 활용해 코드를 작성하지 않고, 어떻게 사용할 것인가 모델을 명시하면, 프로그램을 작성되는 솔루션도 있다.)  


다음은 POJO 속성들과 양방향 연결을 가진  JSF 컴포넌트의 예를 보여 준다.

<h:inputText value="#{myBean.someProperty}"/>

POJO 클래스는 아래와 같이 정의 될 수 있다.

public class MyBean {
 
    private String someProperty;
 
    public String getSomeProperty() {
         return someProperty;
    }
 
    public void setSomeProperty(String someProperty) {
        this.someProperty = someProperty;
    }
}


자바빈에서 속성 값 "someProperty"을 자동으로 "getSomeProperty()" 메소드를 연결해 값을 가져오고, "setSomeProperty(String)" 메소드를 연결해 값을 설정할 수 있기 때문에 위와 같이 사용할 수 있다.


2. Framwork

POJO를 사용하는 설계들이 점점 더 일반적으로 사용면서, 프레임워크내에서도 POJO의 역할이 커졌다. 이런 모델에서 개발자는 POJO 이외의 것은 생성할 필요가 없어졌다. POJO는 프레임워크 내에 어떠한 의존성을 가지지 않으면서, 순수하게 비즈니스 로직에 초점을 맞출수 있었다. 결국 개발자는 프레임워크를 이용해 개발할 때 비즈니스 로직을 포함한 단순한 클래스를 생성하고, 이를 맵핑해주는 설정 파일만 작성하면 할 일이 끝난다. 


이러한 생각들을 제일 먼저 구현한게 Spring이고, 현재 가장 인기있는 프레임워크가 되었다. 다른 것들에는 다음과 같은 것들이 있다.


- Enterprise JavaBeans

  2.0 버전에서는 JavaBeans 구현하기 위해서 EnterpriseBean을 상속받는 클래스로 구현해야 했지만, EJB3부터 POJO를 지원하기 시작했다. 뒤늦게 POJO의 영향력이 커지며 이를 반영했다.


- JPA (including Hibernate)

  Java persistence API로 자바를 이용해 관계형 데이터를 관리하는 프레임워크이다. 흔히 쓰는 mybatis 같은 O/R 맵핑 프레임워크라고 생각하면 된다. 대신 좀 더 간단하게 쓰기 쉽게 사용할 수 있고, JPA를 기반으로 개발되어진게 Hibernate이다.


- CDI (http://jcp.org/en/jsr/detail?id=299)

  이건 뭐지? 조금 찾아봐야겠다. 2009년에 마지막 릴리즈 이후 추가 개발 활동은 없고, 커뮤니티 가도 2011년 글이 끝이고, 소리 소문 없이 사장되고 있나보다.

  


실제로 POJO를 사용하는 프레임워크를 사용하려면 POJO클래스를 어디서 사용해야 할지 설정이 필요하다. 초기에는 이를 주로 XML을 이용해 설정하다, 이후 어노테이션(Annotation)을 이용하기 시작됐고, 대부분의 프레임워크가 둘 다 지원하게 되었다.


만약 아무것도 배우지 않고 프레임워크를 접하게 된다면, 아무것도 할 수 있는게 없다. 마치 디자인 패턴을 배우지 않은 사람이 디자인 패턴으로 도배된 코드를 보면서 헤메는 것과 같다고나 할까? 프레임워크를 사용하기 위해서는 사용설명서를 반드시 읽어야 한다는 것이다.


프레임워크에서 POJO를 사용하면서 다양한 기술을 사용할 수 있게 되었다. 그게 AOP(Aspect-oriented programming)를 가능하게 만든게 아닐까 하는 생각이 든다. 



정리


POJO를 처음 접하게 되면, 인터넷을 찾아보고, POJO에 대한 글을 읽으며 혼란을 느꼈었다. 뭐 단순한 클래스라고 하는데, 무슨 말이야? 라는 의문이 제일 먼저 들었다. 그런데 시간이 지나면서 프레임워크에 대한 지식도 쌓이고, 설계도 관심을 가지게 되면서 POJO의 역할을 생각해보면, POJO란 하나의 철학이 아닐까 한다. 그 철할을 활용한 것이 프레임워크가 된 것이고 말이다. 처음 접하는 사람은 너무 복잡하게 생각하지 말고, 아~ 이런게 있구나 라고 넘어가도 될 것 같다.



참고 사이트


http://en.wikipedia.org/wiki/Plain_Old_Java_Object

http://blog.naver.com/PostView.nhn?blogId=iamtheman&logNo=130127393725

http://gissmmo.tistory.com/436

http://keymaker83.blogspot.kr/2010/05/pojo%EB%9E%80%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80.html

http://srzero.tistory.com/m/post/view/id/86


* 생각이 조금 다른 부분이 있다면 댓글을 남겨주세요. 위에 글은 개인적인 정리글이라 틀린 부분이 있을 수 있습니다.

'개발자 > Java Enterprise' 카테고리의 다른 글

Java Message Service API  (2) 2013.05.15
Posted by 빌리 :

1. Java Message Service(JMS) 소개

Java Message Service(JMS) API는 두개 또는 그 이상의 클라이언트 간에 메세지를 주고 받을 수 있도록 하는 Java Message Oriented Middleware(MOM) API 이다. 


JMS는 Java Platform, Enterprise Edition의 한 부분이며, Java Enterprise Edition(JEE) 기반의 애플리캐이션 컴퍼넌트들 간의 메세지를 생성하고, 전송하고, 전송받고, 읽는 기능을 사용할 수 있게 한다. 분산 처리 시스템에서 다른 컴포넌트 간의 느슨한 결합(Loosely coupled)과 신뢰성있으며, 그리고 비동기적으로 통신할 수 있게 해준다.


메세지 서비스를 제공하는 MOM 시스템에 JMS API를 이용해 접근할 수 있으며, 이를 통해 컴퍼넌트간에 통신을 할 수 있게 만들 수 있는 것이다. 즉, 소프트웨어 애플리케이션 또는 소프트웨어 컴포넌트들 간의 통신 방법을 정의해 놓은 것이다.


Component <-> JMS <-> Component


JMS는 서로 연결된 다양한 컴포넌트 사이에서 다른 컴포넌트가 갖고 있는 자원을 사용할 수도 있고, 네트워크가 연결되지 않은 상태에서도 메세지를 이용하여 필요한 업무를 요청할 수 있다.

2. JMS 사용시 고려 사항

어떤 상황에서 JMS를 사용할 수 있을까? 다음 상황을 고려해 보자.


- 다른 컴포넌트의 인터페이스 정보에 의존하지 않고 컴포넌트가 쉽게 변경되는 서비스를 원할 때

-> RMI와 같은 서비스를 이용해 컴포넌트끼리 통신하려면 인터페이스 정보를 알아야 한다. 또한 인터페이스가 변경 되면 모두 재컴파일 해야 하는 문제가 있다.

- 동시에 모든 애플리케이션이 작동하고 있는 상황에서 특정 애플리케이션이 작동하기를 원할 때

-> 특정 애플리케이션에게만 통신을 하려고 할때이다.

- 애플리케이션 비즈니스 모델을 사용하는 컴포넌트가 다른 곳으로 정보를 전달하고, 바로 응답을 받지 않은 상태에서도 계속 작동하는 것을 원할 때

-> 메소드를 이용해 다른 컴포넌트를 호출하면 반환값을 확인할 때까지 멈춰 있어야만 하는데, 다른 컴포넌트에 메세지만 보내고, 처리 상황에 대해 알지 않아도 될때를 말한다.


3. 구성 요소

- JMS provider

Message Oriented Middleware(MOM)을 위한 JMS 인터페이스 구현체이다. JAVS JMS 구현체 또는 non-java MOM을 구현하고 있다.

- JMS client

- JMS producer/publisher

- JMS consumer/subscriber

- JMS message

- JMS queue

- JMS topic

여러 구독자들(subscribers)에게 메세지를 전달할 수 있는 분산 메카니즘

4. Models

- Point-to-point model

메세지를 지정된 큐(Queue)로 전달하고 큐로부터 메세지를 전달받는 형식이다. 각각의 메세지는 오직 하나의 소비자(consumer)에게 전달된다. 


- Publish/subscribe model

메세지를 지정된 토픽(Topic)으로 전달하고 해당 토픽을 구독하고 있는 독자들에게 메세지가 전달받는 형식이다. 토픽인 큐처럼 클라이언트 에게서 메세지를 전달받으면 가지고 있다가 다른 여러 클라이언트에게 메세지를 전달할 수 있다. 


이 모델은 여러 게시판이 있고, 그 게시판에 글을 쓰면 다양한 사람이 글을 읽을 수 있는 게시판 구조랑 비슷하다. 각각의 게시판은 토픽(Topic)이 되고 게시글들은 메세지(message)가 된다.

-> JMS api는 각 모델에 상관없이 메시지를 보낸 쪽과 받는 쪽에서 모두 같은 코드를 사용할 수 있도록 공통 인터페이스를 가지고 있다.


5. JMS Object

- Administered Object

1) Connection Factory

클라이언트가 JMS 서비스에 연결하기 위한 커넥션을 생성할 때 사용하는 객체

2) Destination

생성된 메세지가 저장되는 저장소로 그리고 메세지가 소비되는 곳으로 사용되는 객체


- Connection

JMS Provider를 이용한 가상의 커넥션을 캡슐화한 객체. 사용하고 나면 close 메소드를 호출해 닫아야 한다. 커넥션은 클라이언트와 Provider 사이에 통신을 하며, 개발자는 커낵션을 이용해 세션(Session)을 생성할 수 있다.

- Session

메세지를 생성하고 소비하는 단일 스레드 단위이며, 트랜젝션 기능을 제공한다.


- Message Producer

목적지에 메시지를 전달하는 역할을 하는 객체로, 세션 객체를 통해 생성한다.

- Message Consumer

목적지에 전달된 메시지를 전달받는 역할을 하는 객체로, 메세지 생산자(Message producer)와 같이 세션 객체를 통해 생성한다.

1) Message Listener

이벤트 핸들러로 비동기식으로 메시지를 전달 받을 때 사용하는 객체로, 메세지 소비자(Message Consumer)에 등록해서 메세지가 전송됐을 때만 처리할 수 있게 해준다.

2) Message Selector

전달 받은 메세지를 필터링 할 필요가 있을때 사용하는 객체로, 메세지 소비자를 생성할때 매개 변수로 메세지 셀렉터를 지정하여 사용한다. 셀렉터를 사용하면 메세지의 헤더(Header)와 프로퍼티(Property)가 일치하는 메세지만 전달 받을 수 있다.


- Message

다른 클라이언트에서 메세지를 보내고, 받아 사용할 수 있도록 사용하는 객체로, non-java MOM에서도 사용할 수 있는 구조를 가지고 있다. 메세지는 헤더, 프로퍼티, 보디로 구성되며, 헤더는 필수로 지정되어야 한다.

1) Message Header

JMS클라이언트와 JMS 제공자(Provider)가 메세지를 확인하고 전달하기 위해 사용하는 값을 가지고 있다.

2) Message Property

헤더에서 제공하는 정보 외에 추가로 필요한 정보가 있을때 사용한다.

3) Message Body

다양한 데이터 타입을 지정해 보낼 때 사용한다. 메시지는 다음 종류가 있다.

-> Text message

-> Map Message

-> Bytes Message

-> Stream Message

-> Object Message


-Exception Handling


6. 예제

-> 추후 작성 


7. 글쓴이 요약

JMS API는 MOM 서비스(Message를 저장하고 보내주는 서비스)에 연결하는 도구이며, 실제 JMS를 쓰기 위해서는 MOM이 시스템 JDNI에 등록되어 있어야 하고, 이를 검색해서 JMS API를 이용해 컴포넌트 간에 메세지를 보내고, 받을 수 있는 식이다.

현재 프로젝트에서 쓰고 있는 예를 보니 이메일 알림 기능을 JMS를 이용해 구현해 사용하고 있다. MOM의 경우 Active MQ를 사용하고, MOM을 스프링 프레임웍에 접근이 가능하도록 등록 한후 내부적으로 JMS API를 메세지를 처리하는 방식으로 사용하고 있다.


8. Reference

Java Message Service
http://en.wikipedia.org/wiki/Java_Message_Service

Java Message Service Tutorial
http://docs.oracle.com/javaee/1.3/jms/tutorial/index.html


9. 별첨

Message-oriented middleware(MOM)은 분산 시스템 사이에 메시지를 보내거나 받을 수 있는 소프트웨어 또는 하드웨어이다.

예를 들어 특정 서비스를 제공하는 소프트웨어가 여러 플랫폼을 개발되었다고 하자. 하나는 안드로이드 어플리케이션(Java), 또 하나는 iOS(Object C) 어플리케이션이다. 그리고 서버는 C언어를 이용해 개발 되었다면, 각각의 어플리케이션은 서버와 통신을 해야만 한다. 이때 서로 통신하기 위해 사용하는 것중에 하나가 MOM인 것이다. 

MOM 프로그램에는 다음과 같은 종류가 있다. 

- SAP Process Integration ESB

- Apache ActiveMQ

- BEA Weblogic (part of the Fusion Middleware suite) and Oracle AQ from Oracle

- EMS from TIBCO

- FFMQ, GNU LGPL licensed

- JBoss Messaging and HornetQ from JBoss

- JORAM, from the OW2 Consortium

- Open Message Queue, from Oracle

- OpenJMS, from The OpenJMS Group

- Solace JMS from Solace Systems

- SonicMQ from Progress Software

- StormMQ, using AMQP

- SwiftMQ

- Tervela

- Ultra Messaging from 29 West (acquired by Informatica)

- webMethods from Software AG

- WebSphere Application Server from IBM, which provides an inbuilt default messaging provider known as the Service Integration Bus (SIBus), or which can connect to WebSphere MQ as a JMS provider[5]

- WebSphere MQ (formerly MQSeries) from IBM


'개발자 > Java Enterprise' 카테고리의 다른 글

Plain Old Java Object(POJO)  (0) 2013.05.30
Posted by 빌리 :