EJB design: Performance vs. Portability
I have been reading alot lately about .NET and remoting and trying to map it back to J2EE and EJB's. I have been struggling with the fact that there is esentially no equivalent to an entity bean in .NET. Instead all transaction logic is pushed to the database in the form on stored procedures. I have seen complaints over the past year that pushing this logic into the db is bad for portability. And that the loss of performance is ok because it protects the portability.
- Posted by: Michael Rasmussen
- Posted on: April 08 2004 15:08 EDT
This is fine, but I am asking myself one simple question. What is so great about portability? I understand that there is no vendor lock in and all that, but I don't get what is so bad about staying with a technology. If I invest thousands or millions in an oracle database, why would I swap out of it? Is there really some new technology that is going to come along to persuade me to leave a vendor? And if there is ,won't I be glad that I saved money by not implementing portability (portability=$) so that I can spend it on this new technology instead?
I'm not trolling here, I just want feedback.
Basically, I think we can divide software development into two major types related to customers.
1. You already got a customer and developing software with the customer's requirements.
2. You are developing a product, yet to find a customer.
In the first case, if you know that the database is going to be the same, You can always use, alternatives, like BMP, Session, DAO..., you don't need to stick portability.
In the second case, if you don't want to loose any customer just because you are using some "AAA" as a database, you may need to consider portability.
So, what I am trying to say is as a Platform, it should provide facilities to implement both the types. It is upto you to choose the right one for you.
There are a lot of hidden benefits to portability beyond supporting multiple environments.
Ease of Development: With a portable language like Java, you can develop and test on cheap Windows/Linux boxes before moving your code to expensive Unix/Mainframe machines.
Portable Programming Skills: Right now you might be working with a company that uses Windows, Linux or Unix exclusively, but you might change jobs or the company might go through a merger.
Forward Compatibility: If your code is portable between platforms, it is more likely to remain functional in future versions of the same platform.
This has been a long standing problem with Windows, particularly with enterprise applications. Enterpries apps written for NT often won't run on 2000 or XP. MS languages have also not remained backwards compatible: VB has gone through several major changes, where existing VB code could not be used in the more recent versions of VisualStudio (most recently VB6 to .NET).
In fairness to Microsoft, it seems that they have finally realized that it is unreasonable to expect enterprises to discard their entire codebase every 2 or 3 years when MS releases a new version of Windows or Visual Studio, and are making serious efforts to ensure that .NET remains backwards compatible.
This is a big advantage of the VM approach (both for JVM and CLR): it isolates your programs for your operating system, so that changes to the OS are less likely to break your code.
I just want to add one little point. It is actually not strictly related to portability, but goes to the same direction.
If you use portable mainstream technologies like Java, you will find thousands of great developers that are familiar with the technology and can develop your software. If you use a proprietary product there will be only hundreds of expensive specialists that can develop and maintain your code.
Of course some proprietary products are also mainstream - like Oracle you mentioned. But I think you got the idea.