Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Does VO not suitable for local architecture?

 
Jacky Doner
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi folks,
The J2EE platform provides facilities to help create distributed applications,but it also lets application developers apply a local model to their application.So a key consideration for us is whether to use ejbs with a local client view or a remote client view.
It is said that value objects are not necessary for entity beans implemented with a local client view.
what puzzle me is that if we design application based on local architecture,does it means all ties(web ties,ejb ties etc)are located on
one physical machine(one unit)? Well,if we deploy the web tier separate from the ejb tier,does it call distribute architecture?
And if we adopt the local architecture for the consideration of performance ,etc,Does it say there is no need to use value object or business delegate?
Hope for any reply,thank in advance.
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are thinking in the right direction. Local beans simply provide optimized access to clients but does not eliminate the need for remote access. Using the "Entity beans as data gateway" approach, entity beans are to be modelled as local beans. This provides a local client view of the bean - to the clients in the same JVM. These clients are often session beans hidden behind a Session Facade.
That's only a part of the picture in a typical distributed J2EE architecture. As you rightly pointed out, Web clients normally reside elsewhere and require a distributed lookup and access to your bean soup. This is where the Remote Session Facade concept comes in. No matter how you model your business, you should still provide access to this "middle tier" through one or more remotely accessible interfaces. Closely associated to this need for remoteness is the need to exchange data and do bulk data transfers. Therefore value objects still play a dominant role. Local beans only lets you model your domain objects efficiently but does not completely eliminate the nuances of remote client access and all the baggage associated with it.

Cheers,
 
Jacky Doner
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Ajith,you analyzed the issue so detailedly,and I think for complex system design,it's better to adopt the distribute architecture and deploy
each tier on different physical machine.By the way,does session facade usually implement by stateless session bean?
Additionally,I examine the component diagrams in Cade's book carefully,one of them depicts as follows,

I'm not sure whether the AccountManager depicted above we can call it
a session facade.
Hope for your reply,thanks again.
[Andrew: put the diagram between [code] and [/code] UBB tags]
[ March 11, 2004: Message edited by: Andrew Monkhouse ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jacky,
I have edited your post to put the code between [code] and [/code] UBB tags. Doing this ensures that indenting is preserved, which makes the code easier to read.
When you are writing your post, there are a number of buttons just below the edit pane, which will insert the tags for you, so you don't have to remember what they are.
If you would like to edit your original post so that you can see what I have done, you can click on the button that is just above your post.
I do not think that the AccountManager stateless session bean is a facade in this particular case - it presents more of an adapter patern, adapting the CustomerDAO to the stateless session bean requirements.
If you look at the previous diagram (Figure 8-8 Order Component Diagram) in the Cade book (sorry too detailed for me to try and draw them here), then you will see a more classical facade scenario - the OrderProcessor session bean provides access to multiple back end subsystems, hiding those details from the OrderController (which might also be a facade).
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic