Download
1 / 46
460 likes | 576 Vues
Lecture 14 Enterprise and Web Application Programming. Enterprise JavaBeans. Topics. J2EE Overview Enterprise JavaBeans Overview Enterprise Entity Beans Case Study How to build them. Distributed Multi-tiered Applications.
E N D
Lecture 14Enterprise and Web Application Programming Enterprise JavaBeans
Topics • J2EE Overview • Enterprise JavaBeans Overview • Enterprise Entity Beans Case Study • How to build them
Distributed Multi-tiered Applications • The J2EE platform uses a distributed multi-tiered application model for enterprise applications • Application logic is divided into components according to function, and the various application components that make up a J2EE application are installed on different machines depending on the tier in the multi-tiered J2EE environment to which the application component belongs.
J2EE Components • J2EE applications are made up of components • A J2EE componentis a self-contained functional software unit that is assembled into a J2EE application with its related classes and files and that communicates with other components. • The J2EE specification defines the following J2EE components: • Application clients and applets are components that run on the client. • Java Servlet and JavaServer Pages™ (JSP™) technology components are web components that run on the server. • Enterprise JavaBeans™ (EJB™) components (enterprise beans) are business components that run on the server.
J2EE Clients • Web Clients • A web client consists of two parts: • (1) Dynamic web pages containing various types of markup language (HTML, XML, and so on), which are generated by web components running in the web tier, and • (2) Web browser, which renders the pages received from the server.
J2EE Clients • Applets • A web page received from the web tier can include an embedded applet. • An applet is a small client application written in the Java programming language that executes in the Java virtual machine installed in the web browser. • Application Clients • An application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language. • It typically has a graphical user interface (GUI) created from the Swing API, but a command-line interface is certainly possible.
Why use EJB? EJB provides developers architectural independence • EJB insulates developers from the underlying middleware because the only environment an EJB developer sees is the Java environment. It also helps the EJB server/container vendor to change and make improvements on the underlying middleware layer without affecting a user’s existing enterprise applications. • WORA (Write-once-run-anywhere) for server-side components • Because EJB is based on Java technology, both the developer and the user are guaranteed that their components are Write Once, Run Anywhere (WORA). As long as an EJB server faithfully conforms to the EJB specification, any third-party EJB component should run within that server. • EJB establishes roles for application development • The EJB specification assigns specific roles for project participants charged with enterprise application development using EJBs.
Why use EJB? • EJB takes care of transaction management • The EJB container vendor is required to provide transaction control. The EJB developer who is writing the business functionality need not worry about starting and terminating transactions. • EJB provides distributed transaction support • EJB provides transparency for distributed transactions. This means a client can begin a transaction and then invoke methods on EJBs present within two different servers, running on different machines, platforms, or Java virtual machines. Methods in one EJB can call methods in the other EJB with the assurance they will execute in the same transaction context. • EJB helps create portable and scalable solutions • EJBs conforming to the EJB API will install and run in a portable fashion on any EJB server.
Why use EJB? • EJB seamlessly integrates with CORBA • EJB and CORBA are a natural combination that complement each other. For example, EJBs may provide CORBA/IIOP for a robust transport mechanism or pure CORBA clients can access EJBs as EJB clients. Currently, a highlight of OMG’s CORBAServices is the wide range of features they provide to an enterprise application developer. In the future, rather than trying to rewrite these services, EJB server vendors may simply wrap them with a simplified API, so EJB developers can use them without being CORBA experts. • EJB provides for vendor specific enhancements • Because the EJB specification provides considerable flexibility for the vendors to create their own enhancements, the EJB environment may end up being feature-rich.
The JavaBeans™ Component Architecture • The server and client tiers might also include components based on the Java-Beans component architecture (JavaBeans components) to manage the data flow between an application client or applet and components running on the J2EE server, or between server components and a database. • JavaBeans components are not considered J2EE components by the J2EE specification. • JavaBeans components have properties and have get and set methods for accessing the properties. • JavaBeans components used in this way are typically simple in design and implementation but should conform to the naming and design conventions outlined in the JavaBeans component architecture.
Web Components • J2EE web components are either servlets or pages created using JSP technology (JSP pages). • Servlets are Java programming language classes that dynamically process requests and construct responses. • JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content. • Static HTML pages and applets are bundled with web components during application assembly but are not considered web components by the J2EE specification. • Server-side utility classes can also be bundled with web components and, like HTML pages, are not considered web components
Business Components • Business code, which is logic that solves or meets the needs of a particular business domain such as banking, retail, or finance, is handled by enterprise beans running in the business tier. • Previous slide shows how an enterprise bean receives data from client programs, processes it (if necessary), and sends it to the enterprise information system tier for storage. • An enterprise bean also retrieves data from storage, processes it (if necessary), and sends it back to the client program.
Types of Enterprise Beans • Three kinds of enterprise beans: session beans, entity beans, and message-driven beans. • A sessionbeanrepresents a transient conversation with a client. • When the client finishes executing, the session bean and its data are gone. • An entitybeanrepresents persistent data stored in one row of a database table. • If the client terminates or if the server shuts down, the underlying services ensure that the entity bean data is saved. • A message-drivenbeancombines features of a session bean and a Java Message Service (JMS) message listener, allowing a business component to receive JMS messages asynchronously.
Enterprise Information System Tier • The enterprise information system tier handles EIS software and includes enterprise infrastructure systems such as: • enterprise resource planning (ERP) • mainframe transaction processing • database systems, and • other legacy information systems. • For example, J2EE application components might need access to enterprise information systems for database connectivity.
J2EE Containers • Normally, thin-client multi-tiered applications are hard to write because they involve many lines of intricate code to handle transaction and state management, multithreading, resource pooling, and other complex low-level details. • The component-based and platform-independent J2EE architecture makes J2EE applications easier to write because business logic is organized into reusable components. • In addition, the J2EE server provides underlying services in the form of a container for every component type. • Because you do not have to develop these services yourself, you are free to concentrate on solving the business problem at hand.
Container Services • Containers are the interface between a component and the low-level platform specific functionality that supports the component. • Before a web component, enterprise bean, or application client component can be executed, it must be assembled into a J2EE module and deployed into its container. • The assembly process involves specifying container settings for each component in the J2EE application and for the J2EE application itself. • Container settings customize the underlying support provided by the J2EE server, including services such as security, transaction management, Java Naming and Directory Interface™ (JNDI) lookups, and remote connectivity
Container Services - Highlights • The J2EE securitymodel lets you configure a web component or enterprise bean so that system resources are accessed only by authorized users. • The J2EE transaction model lets you specify relationships among methods that make up a single transaction so that all methods in one transaction are treated as a single unit. • JNDI lookup services provide a unified interface to multiple naming and directory services in the enterprise so that application components can access naming and directory services. • The J2EE remote connectivity model manages low-level communications between clients and enterprise beans. After an enterprise bean is created, a client invokes methods on it as if it were in the same virtual machine.
Container Types • J2EE server • The runtime portion of a J2EE product. A J2EE server provides EJB and web containers. • Enterprise JavaBeans (EJB) container • Manages the execution of enterprise beans for J2EE applications. Enterprise beans and their container run on the J2EE server. • Web container • Manages the execution of JSP page and servlet components for J2EE applications. Web components and their container run on the J2EE server. • Application client container • Manages the execution of application client components. Application clients and their container run on the client. • Applet container • Manages the execution of applets. Consists of a web browser and Java Plug-in running on the client together.
What are Transactions? • To a user, a transaction is a single change event that either happens or does not happen • To the system implementers, a transaction is a programming style that enables them to code modules that can participate in distributed computations • Ex: transferring money from a checking to a savings bank account • Sounds easy but in a distributed environment need transaction control • Java Transaction Service • Transaction manager – keeps track of the progress of a transaction • Commits or rolls back the ENTIRE transactions which can be updates to multiple database tables in multiple databases...
What is a Naming Service? • A naming system provides a natural, understandable way of identifying and associating names with data • Enable humans to interact with complex computer addressing systems by associating data and objects with simple names • Independent from computer systems that use them • Can serve any system that can connect to them and understands their protocol
Enterprise Java Beans • “Written in the Java programming language, an enterprise bean is a server-sidecomponent that encapsulates the business logic of an application. The business logic is the code that fulfills the purpose of the application” (Sun, 2006). • For example, in a university student services application, this logic would include the registration of students, but not the underlying networking code allowing registration via a web browser. • An enterprise bean typically contains business logic that operates on the enterprise’s data • An enterprise bean’s instances are created and managed at runtime by a container • An enterprise bean can be customized at deployment time by editing its environment entries. • Various service information, such as transaction and security attributes, are separate from the enterprise bean class and can be configured without changes to the software
EJB Server • EJB server provides an organized framework or execution environment in which EJB containers can run. • Makes available system services for multiprocessing, load balancing, and device access for EJB containers. • EJB server also makes EJB containers running within them visible to the outside world. • It may also provide vendor-specific features like an optimized data access interface, additional CORBA Services, SSL support, a JNDI-accessible naming service, and transaction management services.
The Home Interface and Home Object • Contains Factory methods for locating, creating and removing instances of EJBs • EJB developer defines the Home Interface for his bean • Home Object is generated by tools provided by the Container vendor • Home Object is the implementation of the Home Interface
The Remote Interface and the EJB Object • Remote Interface lists the business methods present in the EJB class • Remote Interface is defined by the EJB developer • EJB Object which is the concrete class for the Remote Interface is generated by tools provided by the container vendor • EJB Clients use the methods present in the Remote Interface to invoke business methods of the EJB
EJB Containers • An EJB container acts as the interface between an enterprise bean and low-level, platform-specific functionality that supports the bean. • Container vendor is also free to provide additional services implemented at either the container or the server level. • EJB client never accesses a bean directly. • Any bean access is done through the methods of the container-generated classes, which, in turn, invoke the bean's methods. • Having the container interpose on all bean invocations allows the container to manage transactions, load bean instances, if necessary, and, in general, to do all the wonderful things EJBs do. • Two types of containers exist: • session containers that may contain transient, nonpersistent EJBs whose states are not saved • entity containers that contain persistent EJBs whose states are saved between invocations.
The Enterprise JavaBean • Real enterprise bean itself is contained within an EJB container and is never directly accessed by anyone but the container • EJB container mediates all EJBs • Does not implement the remote interface within the bean itself – uses skeleton
The EJB Client • Finds EJB containers using JNDI • Uses EJB containers to invoke EJB methods • EJB Client only gets a reference to an EJB Object instance – not actual bean • Uses the Home Object to locate, create or destroy an EJB class • Uses the EJB Object instance to invoke business methods of the EJB instance
The EJB Lifecycle – Roles in EJB • EJB Server Provider – creates EJB Servers • EJB Container Provider – creates EJB container and tools • EJB Developer – creates EJBs • EJB Deployer – deploys the EJBs on a Server • Application Assembler – uses the EJBs
Developing EJBs • Define your Home Interface • Define your Remote Interface • Develop your Entity or Session Bean • In the case of Entity Beans, define a Primary Key class • Write your Deployment Descriptor • Compile your classes and generate the Container code using the tools provided • Set up your Data Source to the Database • Develop the client code • Startup your Server & execute your client
The Contents of an Enterprise Bean • To develop an enterprise bean, you must provide the following files: • Deployment descriptor: An XML file that specifies information about the bean such as its persistence type and transaction attributes. • The deploy tool utility creates the deployment descriptor when you step through the New Enterprise Bean wizard. • Enterprise bean class: • Implements the methods defined in the following interfaces. • Interfaces: The remote and home interfaces are required for remote access. • For local access, the local and local home interfaces are required. • For access by web service clients, the web service endpoint interface is required. (Please note that these interfaces are not used by • Helper classes: • Other classes needed by the enterprise bean class, such as exception and utility classes.
The Life Cycles of Enterprise Beans • An enterprise bean goes through various stages during its lifetime, or life cycle. • Each type of enterprise bean—session, entity, or message-driven—has a different life cycle.
