with JNDI and RMI we solve 2 issues:
1- how to find or locate a remote object (JNDI)
2- how to call a method in a remote object (RMI).
so lets say you have an object and you want to make it available for remote clients, what you should do is creating a proxy for this object (a stub), register it in JNDI.
now, the client will do a search in JNDI and retrieve the Proxy (the stub), and deal with the proxy as it is the real object. The stub will handle all the underline communication.
Business Delegate Design Pattern
as you can see we have alot of code duplication, all business delegate deal with JNDI, thats why we have a Service Locator pattern
Service Locator Pattern
as you can see we have an object, ServicLocator, which is responsible for all JNDI calls
Data Transfer Object Pattern
lets take a loot to a REMOTE MVC Structure where the model is on another Machine
1- as you can see, firstly you register in JNDI,
2- the business deligate call the service locator to return a stub.
3- the stub calls the remote method and return the result WHICH IN THIS CASE A CUSTOMER OBJECT, HOWEVER WE ARE RETURNING NOW A STUB TO THE CUSTOMER OBJECT.
4- add the Customer Stub to the Request
5- the view will read the Customer Stub
6- now, in the view for every single information in the Customer Stub, a remote call will be created.
THIS IS AN OVERHEAD,
Thats why we have something called Data Transfer Object, rather than returning a Customer Stub, we return a Customer POJO, we serialize this object and return it back, in that case we dont have to do a remote call every time.
and here is the big picture of
Business Tier Patterns
Improving the MVC Controller With Struts
basically the controller should do 3 things:
howerver, this is alot, the idea here is why dont we make the things Declarative (i.e. define it in XML file), we can for example put the validation information in xml file, then we can set the view and model information in XML file:
this is what Struts do, it makes the controller declaritive:
The Key Components in Struts are: