Migration from Protocol Manager Application Block Usage
Starting with release 8.5.0, use of the Protocol Manager Application Block is no longer recommended. This application block is now considered a legacy component and has been deprecated.
This article provides an overview of how to migrate existing applications, and outlines how behavior that was previously handled by the application block should now be implemented.
Functional Aspects of the Protocol Manager Application Block
Protocols configurations helper classes:
- Protocols handshake options
- Connection configuration related options
- WarmStandby related options
Protocol Management Service functionality:
- MessageReceiver sharing feature
- ChannelListener's sharing feature
- Protocols WarmStandby initialization feature
- Bulk BeginOpen/BeginClose functions
The usual Protocol Manager Application Block usage scenario is to help with the initialization of multiple protocol connections. Protocol Management configuration classes contain following parts:
- protocol handshake options,
- typified connection configuration options,
- WarmStandby options.
Connection Configuration Feature
Last PSDK versions contain extended ConnectionConfiguration interfaces with set of typified properties for connections configuration. So, generally speaking, now we can initialize all of these options right with protocol connection initialization and it is not needed to have additional intermediate (duplicating) configuration structures.
Elimination of Protocol Management Service may look like:
MessageReceiver Sharing Feature
The Protocol Manager Service instance unconditionally uses its own instance of MessageReceiver for all of its registered protocols.
So, it is not possible to use protocol.receive() on protocols instances created with ProtocolManagementService. It may be done with pmServiceImpl.getReceiver().receive(). This method returns asynchronous incoming message from shared queue of all protocols registered with this pmServiceImpl.
Actually, MessageReceiver mechanism is deprecated and, usually, it is not effective to use single handler/queue to process event messages from different protocols connections.
Application logic will be more clear and supportable when each protocol has own specific event handling logic.
So, the recommendation is to use specific MessageHandler for protocol instance where it is required. For example:
ChannelListener Events Concentration
Protocol Management service supports notifications to set of clients ChannelListeners.
To migrate out of Protocol Manager Application Block usage, ChannelListeners may be added directly to protocol connections.
By the way, in most cases situation like "publish channel events from all of the N connections to all of the M listeners" is a kind of an application design issue, though, it is possible to be realized.
WarmStandby Service Initialization
Protocol Manager service instance does initialize WarmStandby service internally if given protocol configuration contains WarmStandby related options/values.
The recommendation is to create and initialize it explicitly. Initialization schema was mentioned above. Initialization may look like:
For more details, see WarmStandby Application Block documentation.
Bulk Open/Close Functions
Actually, pmService.beginOpen() means protocol.beginOpen() for all protocols registered in given PM Service.