Proprietary
Middleware
The alternative - proprietary middleware.- Though EJBs require upfront costs and experience, the alternative can be far more expensive in the long run.
- Before EJBs, companies often wrote their own middleware, or server-side plumbing. There are many inherent risks with this.
- First, the cost. All software must be maintained. With proprietary software, the company must be responsible for this entire cost. But for EJBs, there are forums to share knowledge - such as magazines, mailing lists, and Java Users Groups. If you're having a problem, odds are you're not the first. Others who have had the problem in the past are often more than happy to help you with yours, for free.
- Further, consider the division of labor. If you can buy components instead of build them, you do not need to know how they work internally. Instead, you can install the purchased components and treat them as a black box.
- Next, proprietary software lends itself to information silos - developers who become experts, not lending their knowledge to others. Should the developer decide to leave the company, the company is in a vulnerable position.
- Developing on an open system is much faster. If a new product is developed for this system, it can be purchased and implemented quickly, giving the company a competitive advantage. On the other hand, the company with the proprietary system often must dedicate the time and resources to developing the product from the ground-up.
- Finally, proprietary systems tend to lock companies into older technologies. For example, say your proprietary system was written in the age of byte-stream socket communications. Imagine using sockets to communicate between client and server instead of RMI, SOAP/Web Services, or any other modern distributed computing protocol!