Sun Microsystems—the company that created the Java platform and plays a central role in Java technologies, including the Java EE specification—has promoted the Java platform as a solid strategy for building applications that aren’t locked into a single platform. In the same way, the architects of Java EE have created it as an open specification that can be implemented by anyone.
To date, there are scores of Java EE-based application servers that provide a platform for building and deploying scalable n-tier applications. Any application server that bills itself as Java EEcompliant must provide the same suite of services using the interfaces and specifications that Sun has made part of Java EE.
This provides the application developer with a number of choices when implementing a project, and similar choices down the road as more applications are added to an organization’s suite of solutions. Building an application atop the Java EE architecture provides substantial decoupling between the application logic that you write and the other stuff—security, database access, transaction support, and so on—provided by the Java EE server.
Remember that all Java EE servers must support the same interfaces defined in the Java EE specification. That means you can design your application on one server implementation and deploy it on a different one. You can decide later that you want to change which Java EE server you use in your production environment. Moving your application over to the new production environment can be almost trivial.
Platform independence is something that you can take advantage of in your development. For example, you may be away from the office quite a bit, and use your notebook computer running Windows to do development. It’s pretty easy to use that configuration to build, test, and debug (Java EE has great support for pool-side computing). When you’re back in the office and happy with a particular component, you can deploy it to, say, Linux-based servers with little effort, despite the fact that those servers are running a different operating system and different Java EE implementation (after testing, of course!).
Bear in mind that each Java EE vendor provides some added value to its particular Java EE implementation. After all, if there weren’t market differentiators, there would be no competition. The Java EE specification covers a lot, but there is also a lot that is not specified in Java EE. Performance, reliability, and scalability are just a few of the areas that aren’t part of the Java EE specification but are areas where vendors have focused a great deal of time and attention. That added value may be ease of use in its deployment tools, highly optimized performance, support for server clustering (which makes a group of servers able to serve application clients as if it were a single super-fast, super-big server), and so on. The key point here is to keep two issues in mind:
• Your production applications can potentially benefit from capabilities not supported in the Sun Java EE reference implementation. Just because your application’s performance stinks on the reference implementation running on your laptop doesn’t mean that Java EE is inherently slow.
• Any vendor-specific capabilities that you take advantage of in your production applications may impact the vendor independence of your application.
To date, there are scores of Java EE-based application servers that provide a platform for building and deploying scalable n-tier applications. Any application server that bills itself as Java EEcompliant must provide the same suite of services using the interfaces and specifications that Sun has made part of Java EE.
This provides the application developer with a number of choices when implementing a project, and similar choices down the road as more applications are added to an organization’s suite of solutions. Building an application atop the Java EE architecture provides substantial decoupling between the application logic that you write and the other stuff—security, database access, transaction support, and so on—provided by the Java EE server.
Remember that all Java EE servers must support the same interfaces defined in the Java EE specification. That means you can design your application on one server implementation and deploy it on a different one. You can decide later that you want to change which Java EE server you use in your production environment. Moving your application over to the new production environment can be almost trivial.
Platform independence is something that you can take advantage of in your development. For example, you may be away from the office quite a bit, and use your notebook computer running Windows to do development. It’s pretty easy to use that configuration to build, test, and debug (Java EE has great support for pool-side computing). When you’re back in the office and happy with a particular component, you can deploy it to, say, Linux-based servers with little effort, despite the fact that those servers are running a different operating system and different Java EE implementation (after testing, of course!).
Bear in mind that each Java EE vendor provides some added value to its particular Java EE implementation. After all, if there weren’t market differentiators, there would be no competition. The Java EE specification covers a lot, but there is also a lot that is not specified in Java EE. Performance, reliability, and scalability are just a few of the areas that aren’t part of the Java EE specification but are areas where vendors have focused a great deal of time and attention. That added value may be ease of use in its deployment tools, highly optimized performance, support for server clustering (which makes a group of servers able to serve application clients as if it were a single super-fast, super-big server), and so on. The key point here is to keep two issues in mind:
• Your production applications can potentially benefit from capabilities not supported in the Sun Java EE reference implementation. Just because your application’s performance stinks on the reference implementation running on your laptop doesn’t mean that Java EE is inherently slow.
• Any vendor-specific capabilities that you take advantage of in your production applications may impact the vendor independence of your application.
No comments:
Post a Comment