My question is if there's something like this already implemented (not
necessarily with RMI), where I can easily specify what types are
returned as a value and serialized and which types of return values
should be stubbed.
First and foremost thing which I would like to suggest is that you should get rid of RMI
. RMI
is quite low level when you think about it. Why would you drop all the way back to CORBA? Only answer to this may be that you don't need a Java EE EJB
app server. But you have to keep client and server JVMs in sync. You don't upgrade the client without upgrading the server. You have to write all the services that the EJB app server provides for you (e.g., connection pooling, naming and directory services, pooling, request queuing, transactions, etc.).
EJB vs RMI
EJBs are built on top of RMI. Both imply Java clients and beans. If your clients need to be written in something else (e.g., .NET, PHP, etc.) go with web services or something else that speaks a platform-agnostic wire protocol, like HTTP or XML over HTTP or SOAP.
Spring vs EJB
A better choice in EJB 3.0 versus Spring depends on whether you like POJO development, want a choice of relational technologies besides ORM and JPA, among other things. Advantage of EJB 3.0 is that EJB 3.0 is a spec with many vendors; Spring can only be had from Spring Source. Whereas Spring is very solid, has lots of traction, isn't going anywhere. It leaves all your options open.
WebServices
Spring's web service module is very flexible & wonderful in terms of POJO service interfaces. These will allow you to get the conceptual isolation you want, defer the deployment choice until the last moment, and let you change your mind if the first thought doesn't perform well. Web services are great in theory, but there are some gotchas that you need to watch out for:
- Latency. Fowler's first law of distributed objects: "Don't!" An architecture consisting of lots of fine-grained distributed SOAP services will be elegant, beautiful, and slow as molasses. Think carefully before distributing.
- Marshalling from XML to objects and back consumes CPU cycles that aren't providing any business value besides allowing your clients to speak a platform-agnostic protocol.
- SOAP is a standard that is becoming more bloated and complex every day, but it has lots of tool support. Vendors like it because it helps drive sales of ESBs. REST is simple but not as well understood. It's not supported by tools.
In the end, I would recommend to use Spring Web Services