Special Edition Using Enterprise JavaBeans 2.0
| By now, hopefully you understand the importance and value of components , but we have not made a case yet for using EJB over any other distributed component-based technology. The reasons for using Enterprise JavaBeans build on the same reasons for using Java as your development language. Those reasons are
Write Once, Run Anywhere Philosophy
Even from the beginning, Java was intended to be platform-neutral. This means that developers could use the Java language to develop applications without regard to the underlying operating system that would be hosting the application. It allows this because Java runs inside a virtual machine that works between the application and the operating system. The virtual machine is dependent on the operating system, but the application code isn't. This offers a tremendous amount of flexibility and portability for Java applications. This behavior is not true of most other languages. Smalltalk works this way, but not languages like C++ or Visual Basic. Because Enterprise JavaBeans are based on the Java language, you may also take advantage of this portability. Enterprise JavaBeans that are developed on one particular operating system can be ported to another. This sometimes happens when you have a customer that refuses to use a particular operating system and you must port your application to a different one. It's nice to have the flexibility to move your components to a different virtual machine without modifying your code. Specification Separate from Implementation
Another facet about the Java language that has been around from the beginning is the idea of separating the interfaces for a service from the implementation. With the introduction of new Java features such as the extension mechanism, it has become easier to achieve this separation. The idea of separating the interface from the implementation is also used in the CORBA world. With CORBA, you specify your interfaces by using the Interface Definition Language (IDL). IDL is language- and platform-neutral. You then generate your implementation based on the IDL. This gives you the freedom to generate the implementation for almost any language and platform. You surely are familiar with the various application programming interfaces (APIs) for Java, such as JDBC. You probably are aware that the APIs are just that: interfaces. This means that many components in the java.sql and javax.sql packages are just Java interfaces. Little or no implementation is provided within the APIs. You must install a JDBC driver provided by one of many different vendors , who provide implementations for the JDBC APIs. This separation or decoupling of the real implementation from the client APIs provides developers with the opportunity to select the best vendor out there and use their implementation. Other languages don't take this approach, and you can find yourself stuck with a slow, awkward implementation without any recourse. EJB is similar in this respect. An industry committee of system vendors defines the EJB specification, which is primarily a set of Java APIs. Any software company or open source community is then free to build products (EJB servers) that implement the EJB specification. This leaves developers free to select the brand that meets their requirements. Provides Interoperability
Many languages and architectures provide a means by which an application can communicate with other languages. With Microsoft technologies, you can use DCOM. Applications written in CORBA use the Internet Interoperability Protocol (IIOP) to allow distributed components to communicate with one another over TCP/IP. EJB is no exception and provides several different ways to achieve interoperability with applications written in other languages and on other platforms. Similar to CORBA, EJB interoperability is based on standards and committees . This has the effect of bringing more vendors and technologies into the fold, which increases the chance that you can communicate with other applications. EJB interoperability is covered in Chapter 20. Developers Can Focus on Business Logic
Any time you start building an enterprise application, you must answer many questions. How are you going to handle the distributed communication, security, persistence, messaging, and many more complicated services? You can see how easy it might be to spend most of your time building these infrastructure services, when you really should be solving the business problem. EJB and the other technologies that make up the Java 2 Enterprise Edition (J2EE) provide most of these services for you. Again, what Sun and its committee members provide are the specifications or APIs. It's up to different technology vendors to provide the implementations. In a typical EJB server you'll find services for security, logging, persistence, and the other necessary services. You are able to spend more of your time building the business logic required by the application. Also, because there are specifications for the services, you can plug in services from different vendors to optimize the performance. In this way, the best-of-breed approach can be used. Compatible with CORBA/IIOP Protocols
Many enterprise applications are written based on the CORBA specification. One of the reasons that there are so many is because CORBA enables you to develop applications in several different languages, including C++, Visual Basic, Cobol, Java, and others. Because there are so many already written using this technology, it would be nice to leverage what's already done when designing new enterprise applications or components. Fortunately, the EJB specification is designed especially for interoperability with CORBA and the IIOP wire protocol, which is at the heart of the CORBA specification. This again opens the door for EJB applications to be easily integrated with existing enterprise applications and brings many more vendors into the EJB market. All this helps support portability and flexibility in designing and developing new applications. |