1 / 49

COMS W4156: Advanced Software Engineering

COMS W4156: Advanced Software Engineering. Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/. Enterprise Java Beans (primarily EJB 1.1). Goals. Standard component architecture for building distributed business applications in Java

neylan
Download Presentation

COMS W4156: Advanced Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/ Kaiser: COMS W4156 Fall 2006

  2. Enterprise Java Beans(primarily EJB 1.1) Kaiser: COMS W4156 Fall 2006

  3. Goals • Standard component architecture for building distributed business applications in Java • Make it easy to write applications: Application developers do not have to understand complex low-level APIs • Part of the Enterprise-grade Java initiative • Provide interoperability between enterprise beans and Java 2 Platform, Enterprise Edition (J2EE) components as well as non-Java applications Kaiser: COMS W4156 Fall 2006

  4. Goals • Follow the Write Once, Run Anywhere philosophy of Java - an enterprise bean can be developed once and then deployed on multiple platforms without recompilation or source code modification • Define the contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at runtime • Compatible with other Java APIs • Compatible with CORBA protocols Kaiser: COMS W4156 Fall 2006

  5. EJB specifications • EJB is an open specification, like all of the J2EE platform • EJB specs have been evolving: • 1.0: initial release • 1.1: core specs that define most of the EJB functionality to date • 2.0 - 2.1 - 3.0: further refinements and extensions • Any vendor can develop a runtime environment that complies with the specification • Usually vendors lag a little behind the latest specs release • Typically, EJB frameworks take the form of “application servers” • Application servers usually sit on top of web servers • Embrace N-tiers architectures for distributed business applications Kaiser: COMS W4156 Fall 2006

  6. N-tier distributed applications • 2-tiers = client-server • e.g., a “classic” web site • 3-tiers: insert a middle tier for business logic • while the back-end tier hosts data/content upon which the application operates • N-tiers (N>3): add other layers • e.g., for load balancing / clustering Kaiser: COMS W4156 Fall 2006

  7. Database Database LDAP Back-end tier Application logic components EJBs Component middleware Middle tier (web) Application server Client Front-end tier 3-tiered architecture Kaiser: COMS W4156 Fall 2006

  8. Database Database LDAP Back-end tier EJBs EJBs EJBs App. server App. server App. server Clustered middle tier Load Balancer Gateway tier Client Front-end tier 4-tiered architecture Kaiser: COMS W4156 Fall 2006

  9. EJB as components • Enterprise Java Beans are components that deal with mid-tier business logic … • … and interact heavily with the data layer of the application • EJB framework conforms and at the same time induces a 3+ tiers architecture for distributed applications • Particularly suited for information systems Kaiser: COMS W4156 Fall 2006

  10. EJB as components • EJB specifications define a full-fledged component model / framework • Includes: • Standardized interfaces + programming model • Runtime environment • Built-in services (identification, transactions, persistence, etc.) • Meta-data • Deployment facilities Kaiser: COMS W4156 Fall 2006

  11. Enterprise Bean • Typically represents business data, or business logic that operates on the enterprise’s data (J2EE) • Instances are created and managed at runtime by a Container • Client access is mediated by the bean instance’s Container - isolates the bean from direct access by client applications (and other beans) Kaiser: COMS W4156 Fall 2006

  12. Enterprise Bean • If an enterprise bean uses only the services defined by the EJB specification, the bean can be deployed in any compliant EJB Container • Can be included in an assembled application without requiring source code changes or recompilation • Various services information, such as a transaction and security attributes, are separate from the enterprise bean class - this allows the services information to be managed by tools during application assembly and deployment • Can be customized at deployment time by editing the bean’s environment entries and/or deployment descriptor Kaiser: COMS W4156 Fall 2006

  13. EJB Container • Hosts and manages an enterprise bean in the same manner that the Java Web Server hosts a servlet or an HTML browser hosts a Java applet • Manages every aspect of an enterprise bean at runtime, including [remote] access to the bean, security, persistence, transactions, concurrency and access to and pooling of resources • An enterprise bean cannot function outside of an EJB container Kaiser: COMS W4156 Fall 2006

  14. EJB Container Kaiser: COMS W4156 Fall 2006

  15. EJB Container • When a client application invokes a remote method on an enterprise bean, the container first intercepts the invocation to ensure persistence, transactions, and security are applied properly to every operation a client performs on the bean • The enterprise bean developer can focus on encapsulating business rules, while the container takes care of everything else Kaiser: COMS W4156 Fall 2006

  16. Container Resource Management • Containers manage many beans simultaneously • To reduce memory consumption and processing, containers pool resources and manage the lifecycles of beans very carefully • When a bean is not being used, a container will place it in a pool to be reused by another client, or possibly evict it from memory and only bring it back when its needed Kaiser: COMS W4156 Fall 2006

  17. Container Resource Management • Because client applications don't have direct access to the beans, the client application is completely unaware of the container’s resource management activities • A bean that is not in use might be evicted from memory on the server, while its remote reference on the client remains intact • When the client invokes a method on the remote reference, the container re-incarnates the bean to service the request Kaiser: COMS W4156 Fall 2006

  18. Interaction with Container • The enterprise bean interacts with its container through one of three mechanisms: • Callback methods • The EJBContext interface • Java Naming and Directory Interface (JNDI) Kaiser: COMS W4156 Fall 2006

  19. Callback Methods • Every bean implements a subtype of the EnterpriseBean interface, which defines several methods • Each callback method alerts the bean to a different event in its lifecycle • The container will invoke these methods to notify the bean when it's about to activate the bean, persist its state to the database, end a transaction, remove the bean from memory, etc. • The callback methods give the bean a chance to do some housework immediately before or after some event Kaiser: COMS W4156 Fall 2006

  20. EJBContext • Every bean obtains an EJBContext object, which is a reference directly to the container • The EJBContext interface provides methods for interacting with the container so that the bean can request information about its environment like the identity of its client, the status of a transaction, or to obtain remote references to itself Kaiser: COMS W4156 Fall 2006

  21. Java Naming and Directory Interface • JNDI is a standard extension to the Java platform for accessing naming systems like LDAP (Lightweight Directory Access Protocol), file systems, etc. • Every bean automatically has access to a special naming system called the Environment Naming Context (ENC) • The ENC is managed by the container and accessed by beans using JNDI • The JNDI ENC allows a bean to access resources like JDBC connections, other enterprise beans, and properties specific to that bean Kaiser: COMS W4156 Fall 2006

  22. Bean-Container Contract • The EJB specification defines a bean-container contract, which includes the callbacks, EJBContext, and JNDI ENC • As well as a strict set of rules that describe how enterprise beans and their containers will behave at runtime, how security access is checked, how transactions are managed, how persistence is applied, etc. • The bean-container contract is designed to make enterprise beans portable between EJB containers so that enterprise beans can be developed once, then run in any EJB container Kaiser: COMS W4156 Fall 2006

  23. Portability • Portability is central to EJB • Portability ensures that a bean developed for one container can be migrated to another if another brand offers more performance, features, or savings • Portability also means that the bean developer's skills can be leveraged across several EJB container brands, providing organizations and developers with better opportunities Kaiser: COMS W4156 Fall 2006

  24. Enterprise Beans • To create an EJB server-side component, an enterprise bean developer provides two interfaces, remote and home, plus the actual bean implementation class • The client uses these public interfaces to create, update, manipulate, interact with and remove beans from the EJB server • The implementation class (or bean class) is instantiated at runtime and becomes a distributed object Kaiser: COMS W4156 Fall 2006

  25. Enterprise Beans Kaiser: COMS W4156 Fall 2006

  26. Enterprise Beans as Distributed Objects • The remote and home interfaces are types of Java RMI Remote interfaces • The java.rmi.Remote interface is used by distributed objects to represent the bean in a different address space (process or machine) • An enterprise bean class is instantiated and lives in its container but can be accessed by client applications that live in other address spaces, using skeletons and stubs Kaiser: COMS W4156 Fall 2006

  27. Stubs and Skeletons • To make an object instance in one address space available in another is accomplished using a little trick involving network sockets • To make the trick work, wrap the instance in a special object called a skeleton that has a network connection to another special object called a stub Kaiser: COMS W4156 Fall 2006

  28. Stubs and Skeletons Kaiser: COMS W4156 Fall 2006

  29. How this works • The stub implements the remote interface so it looks like a business object • But the stub doesn't contain business logic, it holds a network socket connection to the skeleton • Every time a business method is invoked on the stub's remote interface, the stub sends a network message to the skeleton telling it which method was invoked • When the skeleton receives a network message from the stub, it identifies the method invoked and the arguments, and then invokes the corresponding method on the actual instance • The instance executes the business method and returns the result to the skeleton, which sends it to the stub • The stub returns the result to the application that invoked its remote interface method Kaiser: COMS W4156 Fall 2006

  30. Implementing the Skeleton • The skeleton for the remote and home interfaces are implemented by the container, not the bean class • This is to ensure that every method invoked on these reference types by a client application are first handled by the container and then delegated to the bean instance • The container intercepts so that it can apply persistence, transactions, and access control automatically Kaiser: COMS W4156 Fall 2006

  31. Network Communication • Distributed object protocols define the format of network messages sent between address spaces • Most EJB servers support either the Java Remote Method Protocol (JRMP) or CORBA's Internet Inter-ORB Protocol (IIOP) • Which is hidden under a specialized version of the Java RMI API • The bean and application programmer only see the bean class and its remote interface, the details of the network communication are hidden Kaiser: COMS W4156 Fall 2006

  32. Remote and Home Interfaces • The home interface represents the life-cycle methods of the component (create, destroy, find), extending javax.ejb.EJBHome • The remote interface represents the business methods of the bean, extending javax.ejb.EJBObject • These EJB interface types define a standard set of utility methods and provide common base types for all remote and home interfaces Kaiser: COMS W4156 Fall 2006

  33. Remote and Home Interfaces Kaiser: COMS W4156 Fall 2006

  34. Client Access • Clients use JNDI to get a home interface, then used to create or find a bean • The create and find methods return a reference to the remote interface • The remote interface defines the business methods like • accessor and mutator methods, e.g., for changing a customer's name • business methods that perform tasks, e.g., using the HotelClerk bean to reserve a room at a hotel Kaiser: COMS W4156 Fall 2006

  35. Client Access Example // ... obtain a reference that // implements the home interface CustomerHome home = … // Use the home interface to create a // new instance of the Customer bean Customer customer = home.create(customerID); // using a business method on the Customer customer.setName(someName); Kaiser: COMS W4156 Fall 2006

  36. Remote Interface Example import javax.ejb.EJBObject; import java.rmi.RemoteException; public interface Customer extends EJBObject { public Name getName() throws RemoteException; public void setName(Name name) throws …; public Address getAddress() throws …; public void setAddress(Address address) …; } Kaiser: COMS W4156 Fall 2006

  37. Life Cycle Methods • All beans have a home interface • The home interface provides life cycle methods for creating, destroying, and locating beans • These life cycle behaviors are separated out of the remote interface because they represent behaviors that are not specific to a single bean class • The home interface implementation is (usually) automatically provided by the EJB container Kaiser: COMS W4156 Fall 2006

  38. Example import javax.ejb.EJBHome; import …; public interface CustomerHome extends EJBHome { public Customer create(Integer customerNumber) throws RemoteException, CreateException; public Customer findByPrimaryKey(Integer customerNumber) throws RemoteException, FinderException; public Enumeration findByZipCode(int zipCode) throws …; } Kaiser: COMS W4156 Fall 2006

  39. Example Discussion • The create method is used to create a new entity, which will result in a new record in the database • The number and datatype of the arguments of each create are left up to the bean developer, but the return type must be the remote interface datatype • The findByPrimaryKey and findByZipCode methods are used to locate specific instances of the Customer bean • A home may have many create and find methods Kaiser: COMS W4156 Fall 2006

  40. Using Remote and Home Interfaces • The remote and home interfaces are used by applications to access enterprise beans at runtime • The home interface allows the application to create or locate the bean, while the remote interface allows the application to invoke a bean's business methods Kaiser: COMS W4156 Fall 2006

  41. Next Time • Business Methods – entity and session beans • And (some of) the EJB services they use Kaiser: COMS W4156 Fall 2006

  42. Project concept (P/F) Revised concept (P/F) First iteration (25%) 1st iteration plan 1st iteration progress report 1st iteration demo 1st iteration final report Second iteration (25%) 2nd iteration plan Code inspection 2nd iteration progress report 2nd iteration demo 2nd iteration final report Project Deliverables Kaiser: COMS W4156 Fall 2006

  43. Project Concept due Tuesday October 3rd • Each team must submit one assignment all together: individuals and pairs should not submit separately. • You should propose a very small system, something your team can easily implement from scratch within three (3) weeks, keeping in mind the other courses you are taking (and their deadlines!) and any other commitments.  Kaiser: COMS W4156 Fall 2006

  44. Project Concept: Component Framework Requirement • All main system facilities must be coded in some programming language (e.g., Java, C++, C#), using some component model framework (EJB, COM+ or the .NET variant of COM+ - you must obtain permission of the instructor in advance to use any other component model framework).  • The intent is that your eventual implementation actually USE several (not all) of the various services provided by the chosen component model framework in some non-trivial manner, as opposed to ignoring or working around them. Kaiser: COMS W4156 Fall 2006

  45. Project Concept: Deliverable • Cover page (1 page): Indicate the name of your team (pick a name), and list all team members with their full names and email addresses. Indicate that this document presents your Project Concept. • Basic concept (2-3 pages): Briefly describe the system your team proposes to build.  Focus on what the users will do with the system, not how it will be implemented. (But do keep in mind the implementation requirements.) • Controversies (1 page): If everyone in your team agrees 100% with your proposed system as elaborated thus far, state so (in which case that would be all you'd need to write in this section).  Otherwise, briefly explain any disagreements, ongoing arguments, or other controversies.  It is not necessary to indicate which team members hold which positions. Kaiser: COMS W4156 Fall 2006

  46. Upcoming • Individual development assignment #3 due October 10th • Revised project concept due October 17th • First iteration plan due October 24th Kaiser: COMS W4156 Fall 2006

  47. Teams Finalized • I hope… • http://york.cs.columbia.edu/classes/cs4156/homeworks/teams.htm Kaiser: COMS W4156 Fall 2006

  48. 2nd TA • Swapneel Sheth • sks2142@columbia.edu • Office hours: T 2:30-3:30, R 3:30-4:30 @ TA Room (122A MUDD) Kaiser: COMS W4156 Fall 2006

  49. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/ Kaiser: COMS W4156 Fall 2006

More Related