|
Courses Java |
|
|
Enterprise Java Beans (EJB) are an exciting technology that was first introduced in 1998. Since almost its inception, it has gained widespread support by the industry. The EJB component model is a key part of J2EE and is supported by all J2EE-compliant application servers. What is the definition of "Enterprise" The term "Enterprise" (as defined at the Javasoft website):
...implies highly scalable, highly available, highly reliable, highly secure, transactional, distributed applications. Enterprise applications require access to a variety of infrastructure services, such as distributed communication services, naming and directory services, transaction services, messaging services, data access and persistence services, and resource-sharing services. These infrastructure services are frequently implemented on different platforms using different products and technologies, making it difficult to build portable enterprise-class application systems. The Enterprise Java APIs provide a common interface to the underlying infrastructure services, regardless of the actual implementation. JavaBeans versus Enterprise JavaBeans A JavaBean is a Java software component that can be manipulated in a visual programming environment (much like VBX or OCX/ActiveX controls can be manipulated in visual builder tool such as Visual Basic, Powerbuilder, or Visual C++). Using a builder tool that supports JavaBeans, application developers can instantiate beans from a component palette and integrate them together into an application by visually manipulating the bean's properties and events. For a brief introduction to JavaBeans, see our JavaBeans topic description. An Enterprise JavaBean is also a component model, but for server-side (or "middleware") components. An EJB is a non-visual remote Java component or business object, designed to run on a server and be invoked by clients. An EJB can be invoked via CORBA/IIOP, or through RMI. The Enterprise JavaBeans model provides a framework for components to be "plugged in" to an application server, thereby utilizing the server's functionality. Within an application server, EJBs execute inside a container and delegate major responsibility, including security, transactional behavior, concurrency, and persistence, to the container. The two-tier client/server model was a precursor to the multi-tier, or n-tier model. In a client/server system, the application and business logic appear together in one layer, separate from the database layer. In a three-tier (or "n-tier") system, the business logic is separated into another layer. Typically the business logic runs inside of an application server. The server provides enterprise-level services that the business logic uses. Such services may including messaging services, file services, transaction processing, load balancing, database services, etc. Building an n-tier application is not as easy as building a 2-tier client/server application. In an n-tier system, the business logic interacts and interfaces with a variety of services. This involves many lines of intricate coding, handling transactions, state management, multi-threading, resource pooling, and other complex, low-level details. Some development tools generate code (ie. server objects) that run in an application server and utilize the services of the application server. But this generated code is not portable and does not run in other application servers.
Goals of the EJB Component Model The goals of the EJB component model is to:
An application server provides a container to manage the execution of an EJB. When a client invokes a method of the EJB, the container automatically allocates a process thread and invokes the method of the EJB. Clients never access the EJB directly. Access is performed by container-generated methods, which in turn call the EJB's methods. The container manages all resources and services on behalf of the EJB. It also manages all interactions between the EJB and the external systems. Different containers will use different implementation of the services. All EJB containers support a "standard" interface. So, if you need to make your business objects use a different set of enterprise services, your business object does not need to be modified. You'll just re-deploy your business object so that it runs in a different container that provides a different implementation of the services.
"An application that uses IBM TXSeries, DCE services, and Oracle on one system could be moved to a different system and automatically use BEA Systems M3, LDAP, and Sybase instead. No porting effort would be required." (Javasoft) Container provide a number of services, including:
Session Beans Versus Entity Beans
If you are building a custom course, you will need to cover these topics before this topic can be presented: In addition, material covered in this section requires attendees to know the following:
A table of contents of this module is available upon request.
Return to the Custom Order Page.
Copyright ©2007 by Petronio Technology Group, Inc. All
rights reserved. Petronio, "Targeted Technology Training", "T3"
and "Turning new technologies into your competitive advantage"
are trademarks of Petronio Technology Group. All other trademarks are the
properties of their respective companies. | ||||||