Win a copy of Fixing your Scrum this week in the Agile forum!

dieman nambawan

+ Follow
since Jul 11, 2005
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by dieman nambawan

I just downloaded the newest certification logos from Sun. The idea was to use them (or at least the SCEA) on my resume and in my email signature.

But my gosh, they all look so ugly! The font on the logos is too small, so as soon as you try to size the logo down it quickly becomes unreadable. The long and narrow shape is weird. And what's with those flashy colors?? The thing looks like a ketchup stain on my resume!

The overall concept of the logos looks so cheap and amaturistic, especially in the company of well-designed EMC and IBM logos that I also display. I just wonder why after Java certifications have existed for 10 or so years and thousands of people proudly call themselves Sun Certified something, Sun won't hire a professional graphic artist to develop an attractive logo?

[ February 09, 2008: Message edited by: dieman nambawan ]
I'd say: access it directly from the client then. Why involve another EJB?

What I meant in my first reply: in my design I ran across a number of situations where some of the data originating in the EIS layer does need to be stored in the session for future use but does not be be shown to the user (and thus, passed to the client). In this case it's only natural to have another EJB store this data on the SFSB.
AFAIK the purpose of having an SFSB in your system is to be able to keep the session state close to other EJB. If you intend to manage that state routinely from the (remote) client, it would defeat the purpose of having the SFSB at all. Why not keep the state on the client itself then?
[ August 30, 2005: Message edited by: dieman nambawan ]
Thanks for your response Ian!

I thought that a sub-set of J2EE technology is also j2EE technology? If you do use J2EE technology for your project, you don't necessarily have to use ALL that there is?

In any case, I'll post my exam results.


I've used architecture based on Session Beans directly using DAO's. (I am in the "wait" phase at the moment). I used this aproach before in a real-life application, and it's performance/scalability were satisfactory and coding relatively simple.

I honestly find mixing lifecycle management with object-relational mapping in one component a bad idea. Implementing entity beans is not trivial; one needs to follow some rather complex design rules (Composite entity etc.). They do not add any lucidity into the design, but take away some performance (many CMP implementations are outright SLOW). Hopefully it's changed in the J2EE v. 3...

I would be very interested to know whether someone else skipped the entity beans for the SCEA assignment and got away with it?


[ August 26, 2005: Message edited by: dieman nambawan ]
Hello everyone,

A question on inter-session bean communication.

In my architecture the stateful bean is only accessesd by other (stateless) beans. That means that in principle I need only a local business interface for that bean. At the same time, a stub of that SFSB is kept on the(generally remote) controller object. My question: how does it work in this case? Can I remotely store (and re-use) a reference to a local-access stateful bean? I know that local interface is to be combined with the local home interface.

Is it the case where I need 2 pair of interfaces(remote/home and local/localhome)?

Thanks in advance for all replies
[ August 22, 2005: Message edited by: dieman nambawan ]

Originally posted by Marie Pierre Courbevoie:
Hi Dieman

You store a reference to a stateful Handle (in the HttpSession or in a BusinessDelegate), Handle objects are serializable.
Your SLSB will use getEJBObject() to obtain a reference to the EJBObject (for your stateful)

Hope this helps

Marie Pierre

Hi Marie Pierre,

Your response is helpful, although I am still a little bit confused. Could you please elaborate just a little bit more: do you mean that I can use the SAME EJBObject handle from the controller (for example a servlet) and from within the EJB layer (for example a stateless Session Facade EJB)? The handle does not get stale if I pass it as a parameter remotely across layers?

Alternatively, If I do getEJBObject(StatefulBeanName), as you recommend in your second sentence, do I get the SAME instance of the SFSB that already possibly contains some data from previous calls (naturally, this is what I want)? Does container guarantee that I get the same instance? Or maybe it will just give me a fresh instance of the SFSB?
The transmaster interface description is really very confusing.

I am struggling to understand one thing: after I've sent my HTTP POST containing the XML-RPC request, will the response from the TransMaster server contain the XML authorization response or not?!?!? Or will it be sent later? What does the "stream of objects" mean??

I know, I know: "if you're not sure, use asynchronous". But how do I recieve a stream of plain XML then? TCP sockets again? Do we really need a trip back to the Stone Age?

What do you think, guys? Please any thoughts.
[ August 11, 2005: Message edited by: dieman nambawan ]
Hi Ali,

You are certainly right, but my point is: how does your session facade SLSB gets this reference? Perhaps I can pass it as a parameter from the controller to the SLSB? Will this really work? I am not sure. Can I use the same EJB stub inside and outside the EJB layer?
Hello everyone,

Could you please help me with the following.

How do I make sure that all my Stateless Session EJB's that are willing to save/retreive something from the Stateful Session EJB ("shopping cart") make sure that they get indeed always the same bean instance of that shopping cart EJB?

Does it happen automatically whenever I invoke create() method of the shopping cart bean? Does container guarantee that I always get the same instance? If not, what is the correct way to do this?

Of course a workaround for this situation would be to always return the output of the SLSB's to the controller and then store in on the shopping cart from the controller (controller maintains the stub of the SFSB. On the other hand, SLSBs expire after every call, thus storing the reference to the shopping card in the SLSB makes no sense. This solution would involve extra remote calls, thus not good for performance.

Thanks in advance for all replies.
There has been a lot of discussion about the architecture for the swing client. Many posters seem to presume that a application client must be a part of the architecture.

On the other hand, the requirement(as far as I can see) do not imply necessity of such a client. We are only told that travel agents will get graphic terminals, that's all. Also, need to interface the TransMaster's web interface implies availability of a TCP/IP connection at such a terminal.

Thus, we have a graphic terminal that can (apparently) run a JVM and is connected to a TCP/IP LAN. Why can't one assume that such a terminal can run a web browser and give the travel agents a web interface similar to that given to the internet users?