JMS 관리 객체를 JNDI Lookup을 통해 얻기 위해서는 먼저 JNDI 서비스가 정의되어 있어야 한다.

JNDI 서비스는 다음의 3가지 프로퍼티로 정의할 수 있다.

정의된 3가지 프로퍼티는 다음의 방법으로 적용할 수 있다.

Connection Factory는 JEUS MQ 서버에 커넥션(Connection)을 맺는 데 필요한 정보를 가지고 있다.

일반적으로 JMS 클라이언트는 JNDI Lookup을 통해 Connection Factory를 얻고 이를 사용해서 JMS 서버로의 커넥션을 생성한다.

ConnectionFactory connectionFactory =
    (ConnectionFactory) context.lookup("jms/ConnectionFactory");
QueueConnectionFactory queueConnectionFactory =
    (QueueConnectionFactory) context.lookup("jms/QueueConnectionFactory");
TopicConnectionFactory topicConnectionFactory =
    (TopicConnectionFactory) context.lookup("jms/TopicConnectionFactory");

JEUS MQ의 분산 트랜잭션을 사용하려면 XAConnectionFactory, XAQueueConnectionFactory, XATopicConnectionFactory도 위와 비슷하게 Lookup하여 사용할 수 있다.

Jakarta EE 클라이언트에서는 InitialContext.lookup() 메소드를 호출하는 대신 @Resource Annotation을 사용해서 다음과 같이 Connection Factory를 가져오는 방법도 있다.

@Resource(mappedName="jms/ConnectionFactory")
private static ConnectionFactory connectionFactory;

JNDI 서비스를 이용할 수 없는 상황에서는 JEUS MQ가 제공하는 전용 API를 사용하여 JNDI Lookup 없이 Connection Factory를 얻을 수 있다.

jeus.jms.client.util.JeusConnectionFactoryCreator connectionFactoryCreator =
    new jeus.jms.client.util.JeusConnectionFactoryCreator();
connectionFactoryCreator.setFactoryName("ConnectionFactory");
connectionFactoryCreator.addServerAddress("127.0.0.1", 9741, "internal");
ConnectionFactory connectionFactory =
    (ConnectionFactory) connectionFactoryCreator.createConnectionFactory();

Destination은 서버에 의해 관리되는 메시지를 저장하는 공간으로 Queue와 Topic의 2가지 종류가 있다.

Queue는 하나의 메시지를 하나의 클라이언트에만 전달하는 방식(one to one)을 지원하고, Topic은 하나의 메시지를 모든 클라이언트에게 동일하게 전달하는 방식(one to many)을 지원한다.

JMS 클라이언트는 서버에서 관리하는 Destination 객체의 Reference를 얻어서 Destination에 메시지를 송신하거나 Destination으로부터 메시지를 수신한다.

JEUS MQ 클라이언트에서 Destination을 얻는 가장 일반적인 방법은 JEUS MQ 서버가 Destination Reference를 등록한 JNDI 서버를 통해 JNDI 이름으로 Lookup하는 것이다.

Queue queue = (Queue) context.lookup("jms/ExamplesQueue");
Topic topic = (Topic) context.lookup("jms/ExamplesTopic");

Jakarta EE 클라이언트에서는 InitialContext.lookup() 메소드를 호출하는 대신 @Resource Annotation을 사용하여 다음과 같이 Destination Reference를 가져오는 방법도 있다.

@Resource(mappedName="jms/ExamplesQueue")
private static Queue queue;

Connection Factory와 마찬가지로 JEUS MQ 전용 API를 사용하면 JNDI Lookup 없이 Destination Reference를 얻을 수 있다. 이때 Destination을 참조하기 위해서는 JEUS MQ 서버가 내부적으로 사용하는 Destination 이름을 사용해야 한다.

jeus.jms.client.util.JeusDestinationCreator destinationCreator =
    new jeus.jms.client.util.JeusDestinationCreator();
destinationCreator.setDestinationName("ExamplesQueue");
destinationCreator.setDestinationClass(Destination.class);
Destination destination = (Destination) destinationCreator.createDestination();

또는 JMS 구현체마다 다르게 구현하도록 되어 있는 Session.createQueue(String), Session.createTopic(String) 메소드를 사용할 수 있다. 앞의 예에서와 마찬가지로 실제 Destination 이름을 파라미터로 넘겨주어야 한다.

Queue queue = session.createQueue("ExamplesQueue");
Topic topic = session.createTopic("ExamplesTopic");

다음의 예에서는 Destination 이름이 "DynamicQueue", JNDI 이름이 "jms/DynamicQueue"인 Queue를 동적으로 생성하고 있다.

QueueConnectionFactory queueConnectionFactory =
    (QueueConnectionFactory) context.lookup("jms/QueueConnectionFactory");
QueueConnection queueConnection = queueConnectionFactory.createQueueConnection();
QueueSession queueSession =
    queueConnection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
Queue queue = queueSession.createQueue(
    "DynamicQueue?export-name=jms/DynamicQueue");

이 API에는 다음과 같은 특징이 있다.

위의 예에서 생성한 Destination은 JEUS MQ서버가 종료되기 전까지 설정에 의한 Destination들과 동일하게 동작한다.

메시지 수신자에게 전달된 메시지가 서버 측 Destination으로 복구되는 상황은 다음과 같다.

복구된 메시지는 메시지 수신자에게 다시 전달되는데 만일 비즈니스 로직이나 클라이언트의 오류로 인해 반복적으로 특정 메시지 처리에 실패한다면 계속해서 Destination에는 메시지가 쌓이고 클라이언트는 메시지를 수신하지 못하게 된다. 이런 문제를 피하기 위해 JEUS MQ는 메시지가 복구되는 최대 횟수를 제한할 수 있는 기능을 제공한다. "JMS_JEUS_RedeliveryLimit" 메시지 프로퍼티 값을 설정하고 메시지를 송신한다.

message.setIntProperty("JMS_JEUS_RedeliveryLimit", <integer value>)

메시지 프로퍼티의 기본값은 메시지 송신자 클라이언트를 실행할 때 다음과 같이 "jeus.jms.client.default-redelivery-limit" 시스템 프로퍼티를 설정하여 변경할 수 있다.

-Djeus.jms.client.default-redelivery-limit=<integer value>

별도로 설정하지 않으면 3이 사용된다. JEUS MQ 서버는 기동할 때 "JEUSMQ_DLQ"라는 이름의 비정상 메시지 Destination을 생성한다. 비정상 메시지 Destination에 쌓인 메시지는 보통 시스템 관리 툴에서 처리하지만 일반 클라이언트도 이 이름으로 비정상 메시지 Destination에 접근하여 원하는 작업을 할 수 있다.

커넥션은 클라이언트가 JMS 서버와 작업하기 위해 최초로 생성하는 객체이며 JMS 서버와의 물리적 혹은 논리적 연결을 나타낸다. 커넥션은 Connection Factory의 createConnection() 메소드를 호출하여 생성한다.

public Connection createConnection()
                            throws JMSException;
public Connection createConnection(String userName, String password)
                            throws JMSException;

JEUS MQ 서버가 보안 기능을 사용하는 경우 userName/password에 해당하는 Subject에게 "jeus.jms.client.connectionFactory" 리소스에 대한 "createConnection" 권한이 없으면 JMSException이 발생한다.

JEUS MQ 클라이언트를 실행할 때 다음과 같은 옵션을 시스템 프로퍼티로 설정할 수 있다.

-Djeus.jms.client.connect.timeout=<long value>

커넥션이 맺어질 때까지 ConnectionFactory.createConnection() 메소드가 대기하는 시간이다. 이 시간 동안 연결되지 않으면 ConnectionFactory.createConnection() 메소드에서 JMSException이 발생한다. 0으로 설정하면 연결에 성공할 때까지 무한 대기한다. (기본값: 5초, 단위: ms)

클라이언트 코드에 다음과 같은 문장을 추가하면 런타임에도 설정 변경이 가능하다.

System.setProperty("jeus.jms.client.connect.timeout", <long value>);

또는

System.setProperty(jeus.jms.common.JeusJMSProperties.KEY_CLIENT_CONNECT_TIMEOUT, <long value>);

JMS 세션은 메시지를 생성하여 Destination에 송신하거나 Destination으로부터 메시지를 수신하는 것과 같은 모든 메시징 작업의 기본 단위가 된다. 또한 세션은 JMS 클라이언트가 로컬 및 XA 트랜잭션에 참여하는 단위이기도 하다.

세션과 세션을 거치는 모든 작업들은 기본적으로 단일 스레드 컨텍스트에 의해 처리되어야 하며 이는 세션 객체 자체가 멀티 스레드에 안전하지 않다는 것을 의미한다.

세션은 커넥션 객체로부터 다음 API를 사용하여 생성한다.

public Session createSession(boolean transacted, int acknowledgeMode)
                             throws JMSException;

Session.AUTO_ACKNOWLEDGE = 1
Session.CLIENT_ACKNOWLEDGE = 2
Session.DUPS_OK_ACKNOWLEDGE = 3
Session.SESSION_TRANSACTED = 0

JEUS MQ는 메시지 송수신 성능을 극대화시켜야 하는 경우를 위해 추가적인 ACKNOWLEDGE 모드를 지원한다.

jeus.jms.JeusSession.NONE_ACKNOWLEDGE = -1

앞서 커넥션 공유에서 설명했듯이 일반적인 애플리케이션 사용 패턴에서는 Client Facility들을(Connection, Session, Message Producer) 반복적으로 생성하여 사용한다. 그런데 이런 객체들은 한 번 생성될 때마다 서버와 관리 메시지를 주고받게 되고 사용자 메시지를 한 번 보내기 위해서 실제로는 더 많은 수의 관리 메시지를 주고받게 되어 성능에 영향을 미친다.

이런 문제를 해결하기 위해서 JEUS MQ에서는 Client Facility들을 Pooling하는 기능을 제공한다. 이 기능은 트랜잭션이 아니거나 JEUS MQ 장애 극복이 설정되지 않은 환경에서 Message Producer를 사용하는 경우에만 적용되며 메시지 수신자나 트랜잭션이 사용될 때는 Pooling을 하지 않고 사용되었던 Client Facility들은 close할 때 바로 제거한다.

이 기능은 선택적으로 적용할 수 있으며 다음과 같은 클라이언트 JVM 옵션을 설정할 수 있다.

트랜잭션 처리된 세션을 제외하면 JMS의 기본 ACKNOWLEDGE 모드는 메시지를 수신하는 경우에만 의미가 있지만 NONE_ACKNOWLEDGE 모드는 메시지 송신 동작에도 영향을 미친다.

이 ACKNOWLEDGE 모드를 사용하면 성능은 높아지지만 JMS의 중요한 특징 중 하나인 신뢰성있는 메시지의 송수신은 어렵게 된다. 그러므로 해당 세션을 통해 클라이언트가 다룰 메시지의 특성과 성능 및 신뢰도 요구 사항, 그리고 기타 주변 상황을 고려하여 NONE_ACKNOWLEDGE 모드 사용 여부를 판단해야 한다.

JMS 스펙에서 좀더 손쉬운 사용을 위해 커넥션과 세션을 통합시킨 형태의 JMSContext라는 인터페이스를 제공하고 있다. JMSContext는 커넥션과 세션의 기능을 모두 하고 있으며, 커넥션과 비슷하게 ConnectionFactory에 다음과 같이 정의된 API로 생성한다.

public Connection createContext()
                            throws JMSException;
public Connection createContext(int sessionMode)
                            throws JMSException;
public Connection createContext(String userName, String password)
                            throws JMSException;
public Connection createConnection(String userName, String password, int sessionMode)
                            throws JMSException;

세션을 생성할 때와 마찬가지로 ACKNOWLEDGE 모드를 설정하고 있는데, 세션 생성과는 달리 트랜잭션 여부는 별도의 파라미터가 아닌 ACKNOWLEDGE 모드에 의해 결정된다. JEUS MQ에서는 JMSContext 또한 커넥션과 세션처럼 Client Facility Pooling에 포함되며, 각각 커넥션과 세션의 pool을 공유해 사용한다. 따라서, 이에 관한 세부 설정은 커넥션과 세션의 pooling을 따른다.

JMS는 다음과 같은 메시지 헤더 필드들을 정의하고 있다.

JEUS MQ는 메시지에 유일한 메시지 ID를 부여하므로 다음과 같은 기능은 제공하지 않는다.

다음은 JEUS MQ가 지원하는 전용 메시지 프로퍼티이다.

JMS 스펙은 메시지 바디의 형태에 따라 5가지 타입의 메시지를 정의하고 있다.

각 타입의 메시지는 다음 API를 사용해서 세션 객체로부터 생성할 수 있다.

public StreamMessage createStreamMessage()
                            throws JMSException;
public MapMessage createMapMessage()
                            throws JMSException;
public TextMessage createTextMessage()
                            throws JMSException;
public TextMessage createTextMessage(String text)
                            throws JMSException;
public ObjectMessage createObjectMessage()
                            throws JMSException;
public ObjectMessage createObjectMessage(Serializable object)
                            throws JMSException;
public BytesMessage createBytesMessage()
                            throws JMSException;

JEUS MQ는 JMS 기본 메시지 타입 외에 FileMessage를 추가로 지원한다. JMS는 메시지 기반으로 동작하기 때문에 메모리에 메시지 내용이 모두 올라와 있어야만 메시지 송수신이 가능하다. 이는 메시지의 크기가 매우 클 경우 클라이언트나 서버에서 메모리 Overflow가 발생할 수 있으므로 문제가 된다. JEUS MQ가 제공하는 FileMessage를 사용하면 파일의 내용을 블록 단위로 전송하기 때문에 이와 같은 문제를 피할 수 있다.

로컬 트랜잭션은 Connection.createSession(boolean transacted, int acknowledgeMode) 메소드에 transacted 파라미터 값을 true로 설정하고 생성한 세션에 의해 수행되며 이전에 commit이나 rollback이 수행된 시점 또는 처음 세션이 생성된 시점 이후로 해당 세션을 통해 이루어진 모든 메시징 작업들을 포함한다. 즉, 모든 작업은 어느 하나의 트랜잭션에 속하게 된다는 것을 의미한다.

하나의 로컬 트랜잭션 내에서 여러 개의 세션을 처리하는 것은 불가능하지만 하나 이상의 메시지 송신자를 생성하여 다수의 Destination에 메시지를 송신하는 것은 가능하다. 마찬가지로 다수의 Destination으로부터 메시지를 수신할 수 있다.

다음은 로컬 트랜잭션에 참여하는 작업들과 그 범위를 나타낸 것이다.

JMS 스펙은 XASession이 제공하는 XAResource를 트랜잭션에 등록함으로써 XA 트랜잭션에 참여할 수 있다. 이는 JMS의 부가적인 스펙으로서 실제 구현 방식은 각 벤더에 따라 다르다.

JEUS MQ 클라이언트에서 XASession을 사용할 때에는 다음 사항에 주의해야 한다.