J2EE: How to inject a new POJO class in an app server

[thekashyap]

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.

Any ideas?

(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).

[BestJewSinceJC]

You're much better off either asking a more code specific question here or relying on the people you work with rather than a vague question like the one you provided. From the fact that you said 'extension point' I'm assuming you are working in Eclipse RCP, since I have worked in it before and that's the only place I've heard that term? Regardless, please provide some more detailed information.

[thekashyap]

>> You're much better off either asking a more code specific question here or relying on the people you work with rather than a vague question like the one you provided.
I know, I tried to be as specific as possible. There is no code to post yet, so it's not posted. Or did you mean this is not the right forum?

>> From the fact that you said 'extension point' I'm assuming you are working in Eclipse RCP,
We use eclipse just just as development tool, nothing to do with actual application at all. I just borrowed the phrase to describe my soln.

>> Regardless, please provide some more detailed information.
Any particular thing that's not clear where details are needed?
I try to summerize the problem again here:
We want the customer to provide implementation for any additional algorithms they want. Given that performance is an issue, we can not allow call to this cusomter's implementation from our application to be "remote call". To make the call "local" (e.g. local interface of a bean or a call to POJO) we need to do repackaging of our EAR file, which is not acceptatble as our primary aim is to let customer do the work without changes in our application when they want a new algorithm.

[~s.o.s~]

You could certainly make the JAR path configurable and then load the class by dynamically creating a class and invoking the method using reflection but it has a few disadvantages:
- Reflection is slow, at least slower than normal method calls.
- Too many assumptions, assuming the name of class, the name of method. Again this can be configured but still a brittle solution.

The way we normally do this is by coding to an interface e.g. creating an interface called Decryptor which has multiple implementations. Then based on the requirement, we can switch implementations by changing the XML config file (if you are using something like Spring, Guice) or by changing the code which creates a new Decryptor instance.

Another way would be expose this *decryption* implementation using JNDI or bind this implementation bean to JNDI and access the decryption class the same way you access datasources etc. You'd have to probably do the binding stuff when the application initializes; I'll leave the specifics to you though.

HTH

[thekashyap]

>> ...creating an interface called Decryptor ....switch implementations by changing the XML config file...
This is exactly what we planned (as described under One soln is in first post). Good to know we might be on the right track. :)

>> Another way would be expose this *decryption* implementation using JNDI...
Yes, but performance degradation due to remote call is a concern so this one is ruled out.

>> reflectio ...has a few disadvantages:
This is considered. Idea is to force users to write a thread safe implementation of the Dectypt interface, so we can cache a single instance at startup and thus avoid reflection during msg processing.

[~s.o.s~]

> Yes, but performance degradation due to remote call is a concern so
> this one is ruled out

You sure? Assuming your EJB's are deployed on an App server like Jboss, you can publish this Decryptor service to JNDI on the same server instance which makes the EJB -> Decryptor almost as efficient as local. Anyways, I wouldn't actually believe the degradation of performance without concrete tests. Even if lookups are expensive, you can cache the service reference. Some application servers come with the setting of passing objects by reference rather than marshalling/unmarshalling them if remote calls are made over the same VM.

But then again it depends on the kind of extensibility required or the kind of design the client is OK with, so yeah, whatever floats your boat. :-)