The Service Bus group on the System Admin menu displays five screen links that take you to functionality that is a part of the Kuali Service Bus (KSB) module. KSB is a lightweight service bus designed to allow developers to quickly develop and deploy services for remote and local consumption. At the heart of the KSB is a service registry. This registry is a listing of all services available for consumption on the bus. The registry provides the bus with the information necessary to achieve load balancing, failover, and more.
Figure 1532 Kuali Service Bus – Overview
You can deploy services to the bus using Spring or programmatically. Services must be named when they are deployed to the bus. Services are acquired from the bus using their name.
Transactional Asynchronous Messaging - You can call services asynchronously to support a 'fire and forget' model of calling services. Messaging participates in existing JTA transactions, so that messages are not sent until the currently running transaction is committed and are not sent if the transaction is rolled back. You can increase the performance of service calling code because you are not waiting for a response.
Synchronous Messaging - Call any service on the bus using a request response paradigm.
Queue Style Messaging - Supports executing Java services using message queues. When a message is sent to a queue, only one of the services listening for messages on the queue is given the message.
Topic Style Messaging - Supports executing Java services using messaging topics. When a message is sent to a topic, all services that are listening for messages on the topic receive the message.
Quality of Service - Determines how queues and topics handle messages that have problems. Time to live is supported, giving the message a configured amount of time to be handled successfully before exception handling is invoked for that message type. Messages can be given a number of retry attempts before exception handling is invoked. The delay separating each call increases. Exception handlers can be registered with each queue and topic for custom behavior when messages fail and Quality of Service limits have been reached.
Discovery - Services are automatically discovered along the bus by service name. End-point URLs are not needed to connect to services.
Reliability - Should problems arise, messages sent to services via queues or synchronous calls automatically fail-over to any other services bound to the same name on the bus. Services that are not available are removed from the bus until they come back online, at which time they will be rediscovered for messaging.
Persisted Callback - Callback objects can be sent with any message. This object will be called each time the message is received with the response of the service (think topic as opposed to queue). In this way, we can deploy services for messaging that actually return values.
Primitive Business Activity Monitoring - If turned on, each call to every service, including the parameters pass into that service, is recorded. This feature can be turned on and off at runtime.
Spring-Based Integration - KSB is designed with Spring-based integration in mind. A typical scenario is making an existing Spring-based POJO available for remote asynchronous calls.
Programmatic Based Integration - KSB can be configured programmatically if Spring configuration is not desired. Services can also be added and removed from the bus programmatically at runtime.
Bean-Based Services: Typically, KSB programming is centered on exposing Spring-configured beans to other calling code using a number of different protocols. Using this paradigm the client developer and the organization can rapidly build and consume services, often a daunting challenge using other buses.
Figure 1533 Overview Of Supported Service Protocols (conceptual architecture)
KSB is a registry with service-calling behavior on the client end (Java client). All policies and behaviors (async as opposed to sync) are coordinated on the client. The client offers some very attractive messaging features:
• Synchronization - Synchronization of message sending with currently running transaction (meaning all messages sent during a transaction are ONLY sent if the transaction is successfully committed)
• Failover - If a call to a service comes back with a 404 (or various other network-related errors), it will try to call other services of the same name on the bus. This is for both sync and async calls.
• Load balancing - Clients will round-robin call services of the same name on the bus. Proxy instances, however, are bound to single machines if you want to keep a line of communication open to a single machine for long periods of time.
• Topics and Queues -
• Persistent messages - When using message persistence a message cannot be lost. It will be persisted until it is sent.
• Message Driven Service Execution - Bind standard JavaBean services to messaging queues for message driven beans.
The Service Bus group on the System Admin menu displays five screen links that take you to functionality that is a part of the Kuali Service Bus (KSB) module.
Figure 1534 System Admin Menu - Service Bus Group
Table 952 System Admin Menu - Service Bus Group Link Descriptions
Link (& cross-reference link to detailed documentation topic) |
Short Description |
Allows administrators to monitor messages that are flowing through the Service Bus. Messages can be edited, deleted or forwarded to other machines for processing from this screen. | |
Provides a means by which an administrator can change the size of the Thread Pool used by the Service Bus for processing messages. | |
Displays a read-only view of the Service Bus's Service Registry. The Service Registry shows all services that are exposed on the Service Bus and includes information about them (such as IP Address, endpoint url, etc.). | |
Allows you to view message processing and email batch jobs and put them in the queue. | |
Create new or view existing client keystore files. |
Subtopics: