Understanding Single Sign-On (SSO) and Message Queues in Web Development with J2EE Examples

Preface

After a long break, the author introduces two frequently used concepts in web development—Single Sign‑On (SSO) and Message Queues (MQ)—and discusses their implementation in J2EE.

Single Sign‑On (SSO)

Business scenario

SSO allows a user who logs in to one site to be trusted by other sites, enabling one‑click access across applications. It works by sharing a security context or credential between systems. Cookies are often used within the same top‑level domain, but they cannot be transferred across domains, so a dedicated authentication subsystem is needed.

Core elements

All applications share a single authentication system.

Each subsystem obtains the user’s credential (identity, permissions, etc.) from that system.

Simple implementation using Cookies

The author describes a scenario with a trust server A, a relying server B, and a client C. Both B and C keep sessions and write a tokenId‑containing cookie. Various cases are outlined: matching session and cookie, missing or mismatched cookie leading to a request to A, and login flow that synchronises tokens between A and B.

Message Queues (MQ)

Business scenario

MQ is essentially a queue; the key is defining the message format to satisfy processing needs. It is suitable for high‑concurrency, low‑real‑time‑requirement tasks such as comment posting on a large social site, where producers enqueue comment data and consumers insert it into storage.

Two modes

Producer/Consumer: each message is processed by a single consumer thread.

Publish/Subscribe: all subscribers receive messages published after they subscribe.

Implementation options

Common MQ products include RabbitMQ, ActiveMQ, Kafka, and Redis.

Spring + Redis example

Dependencies to add in pom.xml :

<dependency>
  <groupId>org.springframework.data</groupId>
  <artifactId>spring-data-redis</artifactId>
  <version>1.4.2.RELEASE</version>
</dependency>
<dependency>
  <groupId>org.apache.commons</groupId>
  <artifactId>commons-pool2</artifactId>
  <version>2.3</version>
</dependency>
<dependency>
  <groupId>redis.clients</groupId>
  <artifactId>jedis</artifactId>
  <version>2.6.2</version>
</dependency>

XML configuration snippets (ApplicationContext.xml) for Redis pool, connection factory, template, serializer, listener, and container are provided, for example:

<bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig">
  <property name="maxTotal" value="${redis.maxTotal}"/>
  <property name="maxIdle" value="${redis.maxIdle}"/>
  <property name="maxWaitMillis" value="${redis.maxWaitMillis}"/>
  <property name="testOnBorrow" value="${redis.testOnBorrow}"/>
</bean>
...
<redis:listener-container>
  <redis:listener ref="messageListener" method="handleMessage" serializer="jdkSerializer" topic="java"/>
</redis:listener-container>

A simple Java listener class is shown:

import java.io.Serializable;
import org.springframework.stereotype.Component;

@Component(value="messageDelegateListener")
public class ListenMessage {
    public void handleMessage(Serializable message){
        System.out.println(message);
    }
}