| The EJB component architecture is the backbone of the J2EE platform. The core of a J2EE application is comprised of one or several enterprise beans that perform the application's business operations and encapsulate the business logic of an application. Other parts of the J2EE platform, such as the JSP, complement the EJB architecture to provide such functions as presentation logic and client interaction control logic. ISVs, integrators, and customers can develop and customize EJB applications. As we explain how EJB applications overcome the limitations of the two- and three-tier architectures and the early Web application architectures and enjoy additional advantages not found in these architectures, keep in mind that the EJB architecture defines the following major roles, which Chapter 3, Enterprise JavaBeans Roles, discusses in detail: Bean developer Develops the enterprise bean component Application assembler Composes the enterprise bean component into larger, deployable units Deployer Deploys the application within a particular operational environment System administrator Configures and administers the enterprise computing and networking infrastructure EJB container provider and EJB server provider A vendor (or vendors) specializing in transaction and application management and other low-level services
The EJB architecture provides benefits to all these roles. Here we focus on the benefits to application developers and customers. 1.2.1 Benefits to the Application Developer The EJB architecture provides the following benefits to the application developer: simplicity, application portability, component reusability, ability to build complex applications, separation of business logic from presentation logic, easy development of Web services, deployment in many operating environments, distributed deployment, application interoperability, integration with non-Java systems, and educational resources and development tools. Simplicity It is easier to develop an enterprise application with the EJB architecture than without it. Because the EJB architecture helps the application developer access and use enterprise services with minimal effort and time, writing an enterprise bean is almost as simple as writing a Java class. The application developer does not have to be concerned with system-level issues, such as security, transactions, multithreading, security protocols, distributed programming, connection resource pooling, and so forth. As a result, the application developer can concentrate on the business logic for the domain-specific application. Application portability An EJB application can be deployed on any J2EE-compliant server. This means that the application developer can sell the application to any customers who use a J2EE-compliant server. This also means that enterprises are not locked in to a particular application server vendor. Instead, they can choose the "best-of-breed" application server that meets their requirements. Component reusability An EJB application consists of enterprise bean components. Each enterprise bean is a reusable building block. There are two essential ways to reuse an enterprise bean: An enterprise bean not yet deployed can be reused at application development time by being included in several applications. The bean can be customized for each application without requiring changes, or even access, to its source code. Other applications can reuse an enterprise bean that is already deployed in a customer's operational environment, by making calls to its client-view interfaces. Multiple applications can make calls to the deployed bean.
In addition, the business logic of enterprise beans can be reused through Java subclassing of the enterprise bean class. Ability to build complex applications The EJB architecture simplifies building complex enterprise applications. These EJB applications are built by a team of developers and evolve over time. The component-based EJB architecture is well suited to the development and maintenance of complex enterprise applications. With its clear definition of roles and well-defined interfaces, the EJB architecture promotes and supports team-based development and lessens the demands on individual developers. Separation of business logic from presentation logic An enterprise bean typically encapsulates a business process or a business entity (an object representing enterprise business data), making it independent of the presentation logic. The business programmer need not worry about formatting the output; the Web page designer developing the Web page need be concerned only with the output data that will be passed to the Web page. In addition, this separation makes it possible to develop multiple presentation logic for the same business process or to change the presentation logic of a business process without needing to modify the code that implements the business process. Easy development of Web services The Web services features of the EJB architecture provide an easy way for Java developers to develop and access Web services. Java developers do not need to bother about the complex details of Web services description formats and XML-based wire protocols but instead can program at the familiar level of enterprise bean components and Java interfaces and data types. The tools provided by the container manage the mapping to the Web services standards. Deployment in many operating environments The goal of an ISV is to sell an application to many customers. Because each customer has a unique operational environment, the application typically needs to be customized at deployment time to each operational environment, including different database schemas. The EJB architecture allows the bean developer to separate the common application business logic from the customization logic performed at deployment. The EJB architecture allows an entity bean to be bound to different database schemas. This persistence binding is done at deployment. The application developer can write code that is not limited to a single type of database management system (DBMS) or database schema. The EJB architecture facilitates the deployment of an application by establishing deployment standards, such as those for data source lookup, other application dependencies, security configuration, and so forth. The standards enable the use of deployment tools. The standards and tools remove much of the possibility of miscommunication between the developer and the deployer.
Distributed deployment The EJB architecture makes it possible for applications to be deployed in a distributed manner across multiple servers on a network. The bean developer does not have to be aware of the deployment topology when developing enterprise beans but rather writes the same code whether the client of an enterprise bean is on the same machine or a different one. Application interoperability The EJB architecture makes it easier to integrate applications from different vendors. The enterprise bean's client-view interface serves as a well-defined integration point between applications. Integration with non-Java systems The related J2EE APIs, such as the J2EE Connector specification and the Java™ Message Service (JMS) specification, and J2EE Web services technologies, such as the Java™ API for XML-based RPC (JAX-RPC), make it possible to integrate enterprise bean applications with various non-Java applications, such as ERP systems or mainframe applications, in a standard way. Educational resources and development tools Because the EJB architecture is an industrywide standard, the EJB application developer benefits from a growing body of educational resources on how to build EJB applications. More important, the powerful application development tools available from the leading tool vendors simplify the development and maintenance of EJB applications.
1.2.2 Benefits to Customers A customer's perspective on the EJB architecture is different from that of the application developer. The EJB architecture provides the following benefits to the customer: choice of application server, facilitation of application management, integration with the customer's existing applications and data, integration with enterprise applications of customers, partners, and suppliers, and application security. Choice of server Because the EJB architecture is an industrywide standard and is part of the J2EE platform, customer organizations have a wide choice of J2EE-compliant servers. Customers can select a product that meets their needs in terms of scalability, integration capabilities with other systems, security protocols, price, and so forth. Customers are not locked in to a specific vendor's product. Should their needs change, customers can easily redeploy an EJB application in a server from a different vendor. Facilitation of application management Because the EJB architecture provides a standardized environment, server vendors have had the motivation to develop application management tools to enhance their products. As a result, sophisticated application management tools provided with the EJB container allow the customer's IT department to perform such functions as starting and stopping the application, allocating system resources to the application, and monitoring security violations, among others. Integration with a customer's existing applications and data The EJB architecture and the other related J2EE APIs simplify and standardize the integration of EJB applications with any non-Java applications and systems at the customer operational environment. For example, a customer does not have to change an existing database schema to fit an application. Instead, an EJB application can be made to fit the existing database schema when it is deployed. Integration with enterprise applications of customers, partners, and suppliers The interoperability and Web services features of the EJB architecture allow EJB-based applications to be exposed as Web services to other enterprises. This means that enterprises have a single, consistent technology for developing intranet, Internet, and e-business applications. Application security The EJB architecture shifts most of the responsibility for an application's security from the application developer to the server vendor, system administrator, and the deployer. The people performing these roles are more qualified than the application developer to secure the application. This leads to better security of the operational applications.
|
