Skip to content

Latest commit

 

History

History

understand

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
images
images
 
 
script
script
 
 
README.adoc
README.adoc
 
 

README.adoc

Understand AMQ Online

Table of Contents
Goals

  • Understand the concepts of AMQ Online

  • How to use AMQ Online

1. AMQ Online Components

AMQ Online is a solution (Operator) to manage multiple components to provide the over all functionality of running self-service (Messaging as a Service) messaging platform on OpenShift

  • AMQ Broker :

    • AMQ Broker is a full-featured, message-oriented middleware broker. It offers advanced addressing and queueing, fast message persistence, and high availability. AMQ Broker supports multiple protocols and operating environments, enabling you to use your existing assets.

    • This is where all your brokers hosted and it is responsible for persisting messages.

  • AMQ Interconnect :

    • AMQ Interconnect provides flexible routing of messages between AMQP-enabled endpoints, including clients, brokers, and standalone services. With a single connection into a network of AMQ Interconnect routers, a client can exchange messages with any other endpoint connected to the network.

    • This is where all your routes hosted (it will come later when explaining address).

Tip
 For more information regarding different AMQ separate products, please refer to https://access.redhat.com/documentation/en-us/red_hat_amq/7.5/html/introducing_red_hat_amq_7/components#broker

  • keycloak :

    • Open Source Identity and Access Management, which is used to host access control information for queues, topic,etc.

2. Understanding AMQ Online Custom Types

After installing AMQ Online it defines new types (CRDs) which we will try to briefly explain them.

2.1. AuthenticationService

Describes an authentication service instance used to authenticate massaging clients. This is simply your way to configure keycloak server itself.

2.2. AddressSpacePlan

Describes the messaging resources available for address spaces (will come later) using this plan (so it an aggregate of all AddressPlan), such as the available address plans and the amount of router and broker resources that can be used. Think of it like the main quota control, it knows how much hardware can be used by referring to infrastructure configuration. [IMPORTANT] It Defines the infrastructure to be deployed, and as it’s name depicts "plan" it define quota restrictions (i.e., maximum number of addresses)

2.3. AddressPlan

Describes the messaging resources consumed by a particular address using this plan, such as what fraction of routers and brokers an address will use and other properties that should be set for multiple addresses.

2.4. Infrastructure configuration

as name suggested, it configures the hardware resource allocated to the components, such as CPU. memory, storage of console, broker and router, also some other specific config too. it mainly two types;

2.4.1. StandardInfraConfig

This will allow you to host both AMQ Brokers, and AMQ Interconnect routes

2.4.2. BrokeredInfraConfig

This will allow you to host both AMQ Brokers only.

2.4.3. Address Space

Group of addresses accessible through single connection

2.4.4. Address

Defines semantics of address, Has set of properties

  • Available address types determined by the address space type

  • Available plans determined by the address type

20 Comp

  • Address Space - refer back to AddressSpacePlan and here the magic happen as it go and create AMQ broker pod and AMQ Interconnect Pod base on the type (standard or brokered), also it like them with keycloak (AuthenticationService) as authentication/authorization source, and do all needed configuration .

  • Address - the destinations which use the spinned pods from AddressSpace to configure broker or routers.

  • Message User - defines the authentication/authorization attributes (which user can do what) for destination (like queue or topic). It mainly go and write the rules to keycloak.

Important

  • A single router and broker pod has a maximum usage of one. If a new address requires additional resources and the resource consumption is within the address space plan limits, a new pod will be created automatically to handle the increased load.

  • A single router can support five instances of addresses (0.2) and broker can support three instances of addresses (0.3) with this plan. If the number of addresses with this plan increases to four, another broker is created. If it increases further to six, another router is created as well.

  • In the standard address space, address plans for the queue address type may contain a field partitions, which allows a queue to be shared across multiple brokers for HA and improved performance. Specifying an amount of broker resource above 1 will automatically cause a queue to be partitioned.

3. Understanding AMQ Online from Roles & Responsibilities point of View

There are two main roles in AMQ Online;

3.1. Admins

Admin does the installation of the platform foundation on OpenShift, they install all the basic elements that controls all the needed brokers, routers, user console and monitoring tools, and also takes care of setting up the authentication and authorization of who has access to the platform. We don’t always have unlimited computing resource for all users, admin also has control over the resource limitation and create different plans that can apply to accompany different needs from users.

3.2. Developers / Application Owners / Tenants

They are the users of the platform, they will be creating "Address Space", and create destinations by applying the plans on top of it. After the queue and topics are created, the tenants can go ahead and create credentials maps (MessagingUser) to different access roles, they can decide what account has access to admin console, which account has consume/produce right to any addresses(queues/ topics) in the Address Space. Please note, tenants will have no visibility to queue or topics of other Address Space, unless specially specified. Once the address are created and config correctly, application will be able to use the credential to read/write to the messaging address.

So A typical workflow will be;

  1. Admins install AMQ online from Operator Hub or install it manually

  2. Admins will create needed objects in amq-online namespace

    1. Define AuthenticationService(s)

    2. Define StandardInfraConfig(s) Or BrokeredInfraConfig(s)

    3. Define AddressSpacePlan

    4. Define AddressPlan

  3. Each Tenant will create needed objects in his own namespace

    1. Define AddressSpace

    2. Define Address

    3. Define MessageUser

Important
 Each application owner will create separate Address and AddressSapce in their namespace utilizing what Administrators created as infra objects.

4. Understanding what is the difference between Standard and Brokered InfraConfig

Table 1. Supported features reference table
Feature Brokered address space Standard address space

Address type

Queue

Yes

Yes

Topic

Yes

Yes

Multicast

No

Yes

Anycast

No

Yes

Subscription

No

Yes

Messaging protocol

AMQP

Yes

Yes

MQTT

Yes

Technology preview only

CORE

Yes

No

OpenWire

Yes

No

STOMP

Yes

No

Transports

TCP

Yes

Yes

WebSocket

Yes

Yes

Durable subscriptions

JMS durable subscriptions

Yes

No

"Named" durable subscriptions

No

Yes

JMS

Transaction support

Yes

No

Selectors on queues

Yes

No

Message ordering guarantees (including prioritization)

Yes

No

Scalability

Scalable distributed queues and topics

No

Yes

5. Installing AMQ Online on OpenShift 4.x server

There are two ways for installing AMQ online.

  1. Using the source files for RedHat portal.

  2. Using the AMQ online operator from OperatorHub.

    • For ease of use i created a oc cli script which effectively use OperatorHub for installation install_amq_online.sh.

6. JMS clients and libraries

There are multiple JMS Clients depending on the underlying Messaging Protocol (as shown in above table) each one have a set features and may have also some limitations.

  • Messaging Protocol

    1. AMQP: AMQP JMS client provides full AMQP 1.0 support and works with any AMQ server.

      AMQ AMQP JMS is a Java Message Service (JMS) 2.0 client for use in messaging applications that send and receive AMQP messages.

      1. Key features

        1. JMS 1.1 and 2.0 compatible

        2. SSL/TLS for secure communication

        3. Flexible SASL authentication

        4. Automatic reconnect and failover

        5. Distributed tracing based on the OpenTracing standard

        6. Ready for use with OSGi containers

        7. Pure-Java implementation

      2. Procedure

        1. Add the Red Hat repository to your Maven settings or POM file. For example configuration files, see Section B.1, “Using the online repository”.

          <repository>
  <id>red-hat-ga</id>
  <url>https://maven.repository.redhat.com/ga</url>
</repository>

        2. Add the client dependency to your POM file.

          <dependency>
  <groupId>org.apache.qpid</groupId>
  <artifactId>qpid-jms-client</artifactId>
  <version>0.45.0.redhat-00002</version>
</dependency>

          The client library is now available in your Maven project.

          Important
          Important Note on AMQ JMS client for AMQP

          AMQ JMS does not currently support distributed transactions (XA). If your application requires distributed transactions, it is recommended that you use the AMQ Core Protocol JMS client.

    2. OPENWIRE: OPENWIRE JMS CLIENT

      AMQ OpenWire JMS is a Java Message Service (JMS) 1.1 client for use in messaging applications that send and receive OpenWire messages. To support existing applications based on A-MQ 6

      1. Key features

        1. JMS 1.1 compatible

        2. SSL/TLS for secure communication

        3. Automatic reconnect and failover

        4. Distributed transactions (XA)

        5. Pure-Java implementation

      2. Procedure

        1. Add the Red Hat repository to your Maven settings or POM file. For example configuration files, see Section B.1, “Using the online repository”.

          <repository>
  <id>red-hat-ga</id>
  <url>https://maven.repository.redhat.com/ga</url>
</repository>

        2. Add the library dependency to your POM file.

          <dependency>
  <groupId>org.apache.activemq</groupId>
  <artifactId>activemq-client</artifactId>
  <version>5.11.0.redhat-630329</version>
</dependency>

          The client is now available in your Maven project.

    3. CORE: AMQ Core Protocol JMS is a Java Message Service (JMS) 2.0 client for use in messaging applications that send and receive Artemis Core Protocol messages. Artemis core is a messaging system with its own API.

      1. Key features

        1. JMS 1.1 and 2.0 compatible

        2. SSL/TLS for secure communication

        3. Automatic reconnect and failover

        4. Distributed transactions (XA)

        5. Pure-Java implementation

      2. Procedure

        1. Add the Red Hat repository to your Maven settings or POM file.

          <repository>
  <id>red-hat-ga</id>
  <url>https://maven.repository.redhat.com/ga</url>
</repository>

        2. Add the library dependency to your POM file.

          <dependency>
  <groupId>org.apache.activemq</groupId>
  <artifactId>artemis-jms-client</artifactId>
  <version>2.9.0.redhat-00002</version>
</dependency>

          The client is now available in your Maven project.