This week's book giveaway is in the Jython/Python forum.
We're giving away four copies of Murach's Python Programming and have Michael Urban and Joel Murach on-line!
See this thread for details.
Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

EjbCommand pattern  RSS feed

 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In EJBCommand pattern,we have a command object that will have to application logic in the excute method so that excute on the server by the server calling the command.excute().
What is the advantage i derive by this when I( the client ) have to write code to access the domain (ejb entity objects) directly?
The client cannot invoke the local interfaces of the entity beans so having remote access code in excute method will be of no value.
Please give me your opion on this
 
Andres Gonzalez
Ranch Hand
Posts: 1561
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by william kane:
In EJBCommand pattern,we have a command object that will have to application logic in the excute method so that excute on the server by the server calling the command.excute().

hmm.. Yes...

What is the advantage i derive by this when I( the client ) have to write code to access the domain (ejb entity objects) directly?

you (the client)do not write code to access entity beans directly. you should NOT do that. That's what patterns are designed for (EJBCommand itself, session facade, business delegate, data transfer objects, etc..). If you access entity beans *directly* you're coupling your application, increasing your network calls, and you probably have to deal with transactions yourself, etc. That's what it is recommended not to do that. Your clients will interact locally with the Java class (setting values), call execute and internally it will be process in the remote server, if that's the case.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are a couple options about who writes the command object. I'm not familiar with EJBCommand as a pattern separate from command pattern, so I'm guessing a bit.
In one option, the server people write and own the command. The client sends along the name of the command and the server executes it. This is common in web stuff - an HTTP request comes in with the name of the request function. The server says, "You asked for the LogIn function, I'll get an instance of LogInCommand and execute it." The client knows an abstract name for the command, and the command is maybe a stateless session bean facade for some business function.
In the other option, the client people write and own the command. They send an object over the wire and the server executes it. I don't see that happening as the server would have to have the command class in its classpath, and that's a bad dependency on the client.
Did that makes sense? Can you point to where you found the pattern in the first place? Maybe we can see if I'm even close.
[ May 14, 2003: Message edited by: Stan James ]
 
Andres Gonzalez
Ranch Hand
Posts: 1561
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:

...Did that makes sense? Can you point to where you found the pattern in the first place? Maybe we can see if I'm even close.
[ May 14, 2003: Message edited by: Stan James ]


The command pattern achieves these (decoupling the client from EJB) by providing clients with classes that they interact with locally, but which actually execute within a remote EJB server, transparent to the client.
... clients get the command either by creating one or getting it from a factory, depending upon the implementation.

EJB design patterns, Floyd Marinescu
free PDF download at www.middleware-company.com
 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Andres Gonzalez:

EJB design patterns, Floyd Marinescu
free PDF download at www.middleware-company.com

Hey thanks andres infact thats exactly were i found it.Thanks james,i was refering to the later option you suggested in your post.In fact the code sample given at the end of the book shows command's excute making remote calls to ejb (be it session facade or the entity).My query was what good will the pattern do if it not able to exploit the local interfaces of ejb.
Think the issue of class file changes can be circumvented with the use of a command interface.
what do you guys feel?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
D'oh! Executing the command on the client side is an option I completely missed. That's a very slick way for someone to expose a service to you - they give you a ready-to-execute command that encapsulates all the tricky bits of using remote objects. It can do all the JNDI, get home, get remote, etc. and you won't even have to know it's doing J2EE.
I often say one measure of good decoupling is in the instructions to use a service. "Get a command and execute it" is a very simple set of instructions!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!