Using EJB vs Socket : expensive satellite line

Question

We are migrating a bank system from Clipper to Java(J2EE). One of the requisites is to save the bandwidth through the satellite line. Some developers came with a idea to make an object in bank store that talks with the central server through sockets, and in the central server a thread is created to handle that call and call the session bean. Anyone know how big (in bytes) is a EJB call??? (not the jndi lookup neither home finding), just a method to a session bean. How many bytes are added to the parameters data??? It could be a good idea to change from EJB to sockets through the satellite??? Another point is that the satellite has a 1.22 sec delay. Should it be used messages??? And the same question I make for messages, how big would be (in bytes) to send a message using JMS???

Answer 1

Greetings,
We are migrating a bank system from Clipper to
Java(J2EE). One of the requisites is to save the
bandwidth through the satellite line. Some developers
came with a idea to make an object in bank store that
talks with the central server through sockets, and inUltimately, this developer is just "reinventing the wheel". All synchronous network technologies communicate over sockets. This is the job of the object stubs through which EJBs (as well as other component models: CORBA, DCE, DCOM, etc.), communicate. In essence, this developer is suggesting communication client and server "objects" to take the place of a communication "stub" and "skeleton" pair. Only, in this case it would really only add to the complexity of the issue by adding an additional communication framework (aka "point of failure") - over-satellite client/server pair - in front of the framework that must still be used - EJB stub/skeleton pair (additionally, EJB skeletons are optional and may not even be used by your particular vendor). Furthermore, this solution will also require the creation of a new protocol to be communicated over the satellite decorators (an additional maintenance piece; aka "added complexity"). This solution may save some up-front bandwidth (largely depending on the implemented protocol), but the increased latency and maintenance complexity in your application may simply negate it (increased possibility for transmission repeats, session failures, protocol errors, etc.).
the central server a thread is created to handle that
call and call the session bean. Anyone know how big
(in bytes) is a EJB call??? (not the jndi lookup
neither home finding), just a method to a session
bean. How many bytes are added to the parameters
data??? It could be a good idea to change from EJB toAn EJB sits atop a communication layer which may be implemented using a vendor's protocol of choice. Such may be JRMP (RMI), IIOP (CORBA), or proprietary (e.g. WebLogic's 'T3'). The answer to this question, therefore, depends upon the (packet size of) the actual protocol in use.
sockets through the satellite??? Another point is thatDepends... the added complexity of this approach will add the TCO of your application in other ways. The real question is "which is more - maintenance cost, or bandwidth cost?" Some things to keep in mind:
* An effective socket implementation requires: invention of a stable and robust protocol; proper state management; a scalable threading model; and let's not forget - its own full lifecycle of DDTM: design, development, testing, and maintenance.
* Current component models - EJB most certainly included :) - already have, and have undergone, the previous.
the satellite has a 1.22 sec delay. Should it be usedAdjust your server's timeout parameters.
messages??? And the same question I make for messages,Depends if your application needs synchronous or asynchronous communication, and if asynchronous, 1-way or 2-way. If synchronous (response must follow request), then "socket-based" communication is required - whether it's through EJB or direct. If asynchronous 1-way (response not required), then JMS or low-level datagram-based communication may be used; both may also be used for 2-way (anytime response), but both, of course, also have their own sets of pros and cons depending on your application and following many of the same arguments as above...
how big would be (in bytes) to send a message using
JMS???As with EJB, depends on the protocol implementor.
Regards,
Tony "Vee Schade" Cook