I am designing a fast financial based system using EJBs. Currently, we use XML on HTTP to communicate between two logically separated EJB modules (session bean to session bean).
I had some questions
1. Is this the fastest way to communicate?
2. Is using the remote lookup better in speed?
3. Should I use sockets to send the XMLs?
4. Is HTTP scalable (can handle load?)
1. Definately not. HTTP in general is not very fast, and marshalling/unmarshalling of the paramters using XML is very expensive.
2. I guess you mean "is using RMI faster" and the answer is yes, and how much so depends on the particular type of data. Numbers, for instance, are much more efficient using RMI where they are transferred in their native encoding, rather than translated into text.
3. I don't think that's a very good idea. XML depends on some external protocols to determine MIME type, encoding, etc. Passing XML directly on sockets won't neccesarily cause a direct problem, but I'm not sure it's the proper way to distribute XML content.
4. That depends on the infrastructure. Notably there is a new HTTP feature that allows multiple HTTP requests to go on the same TCP connection, but not all servers/clients implement it at the moment.
Why are you communicating between your SBs using XML on HTTP rather than by their remote interface?
Thanks for the update.
In answer to your question:
1. In order for us to compile our code for one server, we had to have the remote & home files for all session beans on the other servers. We felt uncomfortable with this.
2. I had read somewhere that parsing a small sized XML document is FASTER than rmi serialization of objects.
3. InterJVM calls to remote interfaces are slower.
4. Some same name entity beans are being used in different servers and hence we could not bind them to the JNDI without changing the names.
5. Finally, we could tap the XML communication layer and look at the actual message sent between servers. This could be used for debugging and auditing.
Hi again. Just a couple of comments:
1. Why? If you remove the interface, you get no type information. You might as well build an RPC system. I think this is one indirection too many. Systems should not depend on each other's implementation, but they should certainly know each other's interface. That is an inherent assumption in OO systems.
2. Perhaps it is, for some types of data, provided that all you do is serialize it. If you're actually going to use it, i.e turn it into an object graph, convert non-textual datatypes to their Java representation (e.g, primitives, dates, etc), I think it would be substantially slower.
3. As are XML-based calls.
4. What do you mean, "had the same name"? The JNDI name has nothing to do with the entity's name. If you had a StockInfo bean on two server you could:
Bind them as "server1/SlotInfo", "server2/SlotInfo".
Bind them as "SlotInfo1", "SlotInfo2"
Or even bind them as "service123", "service456".
Besides, using JNDI for locating *remote* beans is not necessary, although App servers provide that option automatically. You could also bind the home handles to whatever media you like: put them in a file, bind them to a Jini lookup service, whatever.