While trying to address a new requirement we wanted to provide a generic soln and pass on our pain to the customer. :)
Application: Say I have some application listening to a port or JMS or something where it receives some encrypted messages/requests. To process the requests it need to decrypt the message using some algorith. We support some default set of algorithms say A1 & A2 (same application calls A1 or A2 depending on message header info). Frequency of message arrival is pretty high.
Requirement: Customers want their own decryption algorithm C1 to be used instead of A1 or A2.
One soln is
- provide an extension point (an interface)
- which can be implemented by customers for their own algorithm in a stateless session bean.
- based on the message header we can look up the correct JNDI from some conf file
- create the bean and invoke any algorithm.
Problem with this is that it's a remote bean call, which kills the performance. We can't make it a local interface call (or POJO) because the original application's (EAR's) packaging has to be changed to add the customer's bean implementation (requires repackaging, and redeployment of EAR), which kills the basic idea or an extension point.
(Idea that I'm working on currently is to give a jar file path to the class loader at runtime and hope to create an instance of customer's class without packaging it in my application's EAR).