Mar 8th, 2007, 06:38 AM
alternative to local SLSB ejb
Sorry for bothering you again, but neither forum, not google search reveal any crear answer.
Is there alternative to local slsb. Namely:
- client and server are in the same jvm
- separate client-server classloaders (only service interface is shared)
- pass by reference not value (or very high performance pass-by-value)
- no any context propagation required
-(optionaly) service link reference refresh
Please, any idea!
Mar 8th, 2007, 06:49 AM
If the client and server are in the same VM: Why bothering with a remoting layer? Just use a POJO directly (via interface).
Mar 8th, 2007, 07:40 AM
direct method call is not an option, since i need decouple client and server code (place in different classloaders).
I'm looking not for remoting layer, but for kind of "separation" layer - share service interface, not implementation
Mar 8th, 2007, 07:53 AM
Well, in order to bridge classloaders you need either remoting or serialization.
For the remoting options have a look at Springs RMI invoker support.
Why do you need different classloaders in the first place?
Mar 8th, 2007, 08:11 AM
Yes, serialization is the option if there are not way to use local ejb like pass-by-reference.
Rmi invoker is not performant enough (actually i use this way right not and suffer great performance degration).
The main reason to to separate client from server are custom aspectj aspects that intercept with each other (yes, i can carefully review all aspects and remove all problems, but not sure if this is possible)
Another reason - similary named classes in client and server layers, but having different content (e.g - User (id, login,password) in client, User (id, account) in server), and obviously i do not want them intercept either
Mar 8th, 2007, 08:14 AM
Did you try another another remoting protocol like http-invoker? Not sure about how performance relates to RMI but possibly it is faster.
Mar 8th, 2007, 08:18 AM
Yes, spring http-invoker. Unfortunately the performance is getting worse.
caucho protocols and ws were not considered since i do not belive they outperform httpinvoker
Mar 8th, 2007, 08:22 AM
Then I have currently no further idea except serialization...
Mar 8th, 2007, 08:27 AM
yes, it seems the only solution for now. But HOW i can expose service, and access it?
Mar 8th, 2007, 08:38 AM
Hmm. Good question.
Maybe you could have an "exporter" bean that serializes an object and places the byte array in a ThreadLocal and an accessing factory bean that takes the byte array and deserializes it.
Of course the classes have to be accessible for deserialization. Could that be a problem in your scenario?