Ken Krebs

Greetings Andrew !

It seems to me the that Sockets would be a good alternative if you need maximum performance or there's something you can't live with in RMI but you'll have to embed your own protocol, hence the extra work.

I actually don't use RMI much in my own work, preferring to use Spring's HttpInvoker (Java serialization over Http) as it's firewall friendly. We can't of course use that for the cert.

The client proxy you get will know nothing about RemoteServicesImpl and cannot be cast to it. The client code must use the Services interface to do its work. Data can only be used on the server side.

I don't think that referenceData() is of any help to you here. If you look at the javadoc, it is called before the initial rendering of the View before the form is submitted. Generally, this is your opportunity to put things in the Model (request attributes) that your form needs when it is rendered before it is submitted. If you want to pass something to another Controller, you can put it in the Model or if you're redirecting to the other Controller you can put it in the session.

So if you use an Ajax technique to refresh the page, what's the matter with returning a null ModelAndView ?

The referenceData method is called by the framework before your onSubmit method is called, not after.

The workfow is well documented in the Javadoc for AbstractFormController.

The Factory pattern is typically implemented using static method calls in the object that has the dependency. This can make Unit Testing very difficult. If something outside the object wires up the dependency, such as a Spring container, the dependency can easily be replaced with a different implementation in your tests.

Not quite sure how you're doing this or if you're using Spring MVC.

If you are, you should return null in your Controller implementation when it expects you to to return a ModelAndView. This tells the DispatcherServlet workflow that you've handled the response yourself and there is no View to render.

I'm also not sure if you know it, but Spring MVC provides support for Jakarta Commons FileUpload to support this kind of use case. It is an alternative to reinventing the wheel, unless of course you want to reinvent the wheel.

How about something like this:

public class RemoteServicesImpl extends UnicastRemoteObject implements RemoteServices { private Data data; public RemoteServicesImpl(Data data) { this.data = data; } ... }

You would then make whatever calls on data that are necessary to support implementing your Services intrerface.

Although your RemoteServicesImpl cannot be cast to Data, it can certainly delegate to an instance of Data to help it implement the Services interface.

Let's revisit RMI a little.

On the server side:
Your RemoteServicesImpl implements the Services interface either directly or through a helper. RMI provides a server side proxy (stub) that also implements the Services interface and delegates to the RemoteServicesImpl instance that you bound to the RMI registry. All communication via RMI from the client side goes through this proxy.

On the client side:
RMI provides a proxy against which you can make your Services method calls. This object is created by RMI is neither a RemoteServicesImpl or a Data object. The proxy object RMI provides can only be cast to Services. All communication via RMI to the server side goes through this proxy.


I leave it to you to figure out the rest. I don't want to spoil your fun.



FYI: You cannot use the following for the cert, but it can be useful afterwards.

Spring provides a nice Remoting technology that is a simple alternative to RMI called HttpInvoker. Essentially it provides Remoting via Java serialization over HTTP. Unlike RMI, it does not need a central registry, it only needs an HTTP port to serve. Another real plus for this is that since runs over HTTP, it is very firewall friendly, unlike RMI. This strategy, of course, only is useful when both the client and server are implemented using Java and Spring. You only need to write your service interface and its implementation as POJO's that have no knowledge whatsoever of any Remoting that is going on and don't have to handle any checked Exceptions.

Spring also maps RemoteExceptions to unchecked RemoteAccessExceptions making your code much easier to write. In fact it does this exception mapping for a number of other Remoting technologies as well as HttpInvoker.

Switching Remoting strategies is often as simple as tweaking 2 simple XML configurations, 1 on the server and 1 on the client.

Your question is so broad as to be unanswerable. Do you expect someone to reply with a tutorial ?

I can only make 2 recommendations:

Read the Spring documentation

Don't use any EJB to perform business logic. Do that in testabe POJO's. The EJB should only be a thin wrapper around 1 more POJO's that it delegates the work to.

[ July 11, 2008: Message edited by: Ken Krebs ]

I didn't know Andrew had a book out on this but I can say that his comments on this forum were quite helpful to me when I did this cert in 2004.

To those who are tempted to do a lot of cut and paste of other peoples ideas just to get the cert, YOU ARE ONLY CHEATING YOURSELF.

The most valuable thing about this cert is the learning.


"The journey is the reward."

There actually are a large number of ways to solve this problem, far too many alternatives to cover here. All of them involve using the autoproxy facility. There is decent coverage of this topic in the manual. In Spring 2.5.4, this in

Chapter 7.9. Using the "autoproxy" facility

.

You will need to determine which autoproxy technology makes the most sense for you. If you are using Java 5 or later, metadata-driven auto-proxying is a particularly nice choice. We are using this quite nicely where I work.

Another approach is to use a single InternalResourceViewResolver, i.e.
<bean id="viewResolver"class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="viewClass" value="org.springframework.web.servlet.view.JstlView" /> <property name="prefix" value="/WEB-INF/jsp/" /> <property name="suffix" value=".jsp" /> </bean>

you can then simply include the name of the folder as part of the view name

wouldn't you have to synchronize a lot of the code, creating a whole bunch of synchronized bottle necks?

Not necessarily. You can also make Singletons that are completely threadsafe and totally unsynchronized. As long the Singleton only accesses its own ***unchanging*** state or local data from the method calls it is perfectly threadsafe. If you need to maintain client-state between method calls then you must you use some sort of mechanism to hold the state other than instance or static fields on your Singleton. A common approach used by many frameworks is to use a ThreadLocal to store the client data (see the Javadoc for more info).