The Enterprise Java Beans Part Two

1. The Enterprise Java BeansPart Two Biduri Kumala Christine Angelina Debora Y.N Desiana Nurul Maftuhah Farania Gama A.R Hipasdo Abrianto

2. Topics Covering: • Chapter 12: Persistence Best Practices • Chapter 13: EJB Design Strategies • Chapter 14: Clustering

3. Chapter 12 Persistence Best Practices

4. Why? and What to Learn? • Most modern business applications require us to persist data—create, update, delete,etc • Thus, in this chapter we will cover: • When to use and when not to use entity beans • How to choose between CMP and BMP • A collection of persistence best practices, such as: versioning EJB components, dealing with a legacy data design Note: It’s assumed that we use relational database

5. 1* When to Use Entity Beans? • Actually we have 2 approaches to persist information: • Through entity beans (CMP or BMP) • Session beans plus JDBC • Points to compare both of them: • Control • Parameter Passing Analogy • Procedural vs. Object-Oriented • Caching • Enforcement of Schema Independence • Ease of Use • Migration • Rapid Application Development

6. 2* Choosing Between CMP & BMP • Code Reduction and Rapid Application Development • Performance • Bugs • Control • Application Server and Database Independence • Relationship • Learning Curve and Cost

7. 2b* Choosing Granularity for Entity Beans • Granularity  how big/small our entity beans are • Choices: • Small grained entity beans • Make some of our entity beans be Java classes (in CMP: ‘dependent value classes’)

8. ...Dependent Value Classes • Example: package examples; public class LineItem implements java.io.Serializable{ private String product; private int quantity; public void setProduct(String product) {this.product=product;} public String getProduct {return product;} public void setQuantity(int quantity) {this.quantity=quantity;} public int getQuantity {return quantity;} } • Don’t forget the rules! • (+) quick to develop (-) lose many of the entity bean benefits

9. 3* Persistence Tips and Tricks • Beware the Object-Relational Impedance Mismatch • Hard-Coded vs. Soft-Coded SQL • When to Use Stored Procedures • Normalizing and Denormalizing • Use Our EJB Object Model to Drive Our Data Model

10. 3* Persistence Tips and Tricks • Follow A Good Data Design Process • Use Surrogate Keys • Understand the Impacts of Database Updates • Versioning EJB Components • Living with a Legacy Database Design • Handling Large Result Sets

11. Chapter 13 EJB Design Strategies

12. Stateful vs Stateless • Statelessness leads to increased scalability • Stateful backers: Have to rearchitect entire system to accommodate statelessness. Two Virtues of Statelessness: • Ability to easily pool and reuse components at little or no overhead. • Any components can service the client’s need.

13. Statelessness (Client-spesific Data) • You need to push client-spesific data into stateless bean for each method invocation. • How? • Pass the data as parameters into the bean method. • The bean to store data persistently on behalf of a client. • Store the client-spesific data in a directory structure using JNDI.

14. Advantages of Messaging • Database performance: perform relational database work. • Quick response: allows client to process other item when they would otherwise be blocking for the method to return. • Request prioritization: asynchronous server can prioritize messages in different order then they arrive into the system. • Rapidly assembling disparate systems: provides rapid development for systems that have to communicate with one another. • Loosely coupled system: enables loose coupling between application. • etc

15. When not to use Messaging? • When you’re not sure if the operation will succeed. • When you need a return result. • When you need an operation to be part of a larger transaction. • When you need to propagate the client’s security identity to the server. • When you are concerned about request performance. • When you want a strongly-typed, OO system. • When you want a tighter, more straightforward system.

16. How to guarantee a response time with capacity Planning Limit the amount of work any given EJB server instance can process at any one time. • by limiting the thread pool of your EJB server. • by limiting the bean instance pool. How to achieve singletons with EJB? Singletons  a single instantiation of a class with one global point of access. To create a singleton  use a static keyword when defining a class. But, one restriction of EJB  you CAN’T use static fields in your bean. So, how?  JNDI

17. Wrap Entity Bean with Session Bean The business process components map very well to session bean, and the data components map very well to entity bean. • Session beans perform bulk create, read, update, delete (CRUD) operations on behalf of remote clients. • Makes entity bean into an implementation detail of session bean. • The entity beans are never seen to the external client.

18. Tips and Tricks to make your entity beans high-performing • Entity bean should not be called directly from remote clients. • Use your container’s caching option as much as possible. • Be sure your transactions run on the server as short as possible. • Having your container batch JDBC updates all at once at the end of transaction. • Use container managed persistence, if possible. • Lazy-load some of your fields rather than loading it all. • etc

19. Choosing between local and remote interface • Local interface  allow you to pass nonserializable parameters around which is handy. For optimal performance: build system using all local interfaces, then have one or more session bean wrappers with remote interfaces, exposing the system to remote client.

20. How to debug EJB Issues True debugging is a problem with EJB. Try these several options: • IDE Debugging environments. • Check your database’s logfile. • Use a JDBC driver wrapper that logs all SQL statements. • Use the keepgenerated option • Decompile the offending classes.

21. Partitioning Your Resource Bean-spesific resources: resources your bean uses that are tied to spesific data instance in an underlying storage. Bean-independent resources: resources that can be used over and over again, no matter what underlying data your instance represents.

22. Assembling Components The problem with assembling heterogeneous components is getting them all to work together: • Need to write some workflow component that maps to each vendor’s proprietary API and object model. • Data mapping. • Every participant component must agree on a standard representation, or schema, for exchanged data.

23. Bean Reusability • Reuse as given: The application assembler uses the acquired bean as it is to build an application. • Reuse by customization: The application assembler configures the acquired bean by modifying the bean properties to fit the spesific needs of the application. • Reuse by extension (subclass): The application assembler creates custom application-spesific beans by subclassing the prebuilt acquired beans.

24. Legacy Integration with EJB Most large-scale EJB/J2EE deployments involve one or more existing systems. You have two basic choices for dealing with this legacy system: • Rewrite that existing system using EJBs. • Bridge into that existing system.

25. Chapter 14 Clustering

26. .: CLUSTERING :. • Definition : • -n . Close group or bunch of similar people or things or occurring together (Oxford D.) • … loosely coupled group of servers that provide simple view of the services that they offer individually…(Mastering EJBs).

27. What’s The Topic ?? • Approaches and characteristic of large-scale system with J2EE application servers. • Approaches that can be employed to instrument clustered EJBs. • Issues related to design clustered EJB systems. • Issues that impact EJB performance in clustered system.

28. Scale System Requirement • Large Scale v.s. Small Scale  What’s the different ?? • Fact ?? • Characteristic of Large- Scale System : 1. Reliability 2. Availability 3. Serviceability

29. Cluster Node Load Balancing Highly available sys. Fail-over (Fo) Request-Level Fo Transparent / Automatic Session Fo. Single access point Transaction/second Request/second Arrivals per second Throughput Invocations/second Basic Terminology

30. 4 – Tier architecture  separate the web server component and application server component into separate processes. Partition Cluster • 3 - Tier architecture  runs the Web Server component (servlets and JSPs) and application server component (EJBs) in same process. There’s important to know what difference between them. Some may not consider the browser to be a-separate tier, since no logic runs in……

31. How EJBs Can be Clustared • Many Location, that vendors can provide clustering logic (like load balancing or Fo logic): • JNDI driver • Container • Home Stub • Remote Stub

32. - Idempotence - • Is one method can be called repeatedly with the same arguments and archieve the same result. • In a distributed system, it doesn’t impact the state of the system. Because it can be called called repeatedly without worry of altering the system. • The idempotent, leaves thevalue in the persistant store the same no matter how many invocation of method () occur..

33. Continued…. • A failed request could’ve occurred may cause, : 1. After the request has been initiated, but before the method invocation in the serverhas begun to execute. 2. After the method invocation on the server to executed, but before the method has completed. 3. After the method invocation on the server was completed, but before the response has been successfully transmitted to the remoted client.

34. Stateless Session Bean Clustering • We can cluster each type of EJB componenent, firstly begin with stateless session be ans : • Load Balancing: all method invocations on the remote home stub and remote stub can be load balance. EJB server give the flexibelity here.. • Fail Over: automatic Fo on remote home stub can always occur,if the called method is idempotent . • Recall the stateless session bean home stubs have only one method which is an empty () method.

35. Statefull Session Bean Clustering • EJB server vendor support replication of state .When a statefull session bean is creation,the must must be copied to another machine.The bean is routine synchronized with it’s backup to ensure that both location are current. • Replication of statefull data typically can occurs : 1. At the end of every method 2. After the commit of a transaction

36. Continued… • Most EJB servers perform statefull Fo in one of two ways, such : Load Balancing: remote house stubs can freely load balance create (..) request to different server in the cluster. Fail Over : !! That Fo can be occur with statefull session if the state is replicated across a cluster or the methods are idempotent.

37. Entity Bean Clustering • Load Balancing:coding EJB correct, will wrap entity beans with a session bean façade most access to entity EJBs should occur over local interfaces by in-process session beans rather than remote clients. • Fail – Over : always access entity beans using local interfaces, Fo make little sense.

38. Continued… • Caching: container provides many different types of caching algorithm, which have the principles reduce the frequency of ejbLoad () and ejbStore(). • Read-Only Caches: containt a bunch of read-only entity beans, useful because most enterprises data is read-only.Implement a validation strategy that determines when the data in read-only instance is no longer valid and shold be reloaded from the persistent store.

39. Common algorithm include : 1. Timeout 2. Programmatic 3. System-wide notification • Distributed Shared Data Object Caches. advanced EJB server feature.This immediately have obvius problem :cache consistency.Detect collisions at the database level, through database triggers.

40. Continued … • Read- Mostly Caches : have read – only entity beans that also updated every now and then without having the burden of a true distributed shared object cache. The idea 1. When perform the operation 2. When perform a write operation • The read-mostly characteristic : 1. Each cacheuses the different JNDI name. 2. Pattern only requires the use of read only cache.

41. Massage-Driven Bean Clustering • Different another, because their don’t have home and remote interfaces, any stubs or skeletons remotely. • Like a consumer, really about JMS clustering and depend upon the clusterable features of the JMS server and destination. • Fo of message – driven beans is integrated into the very nature of the beans themselves.occurs when being processed is acknowledged as unsuccessful to JMS server.

42. Other EJB issues • First Contact : ehen want to use EJB component, client must always first connect to the JNDI tree. • Type of Clustered naming server : 1. Centralized 2. Shared, Replicated.

43. Initial Access Logic • when application server provides a centralized server, the logic that clients use to get access to the cluster is simple. 1. Hard-code DNS code 2. IP address of centralized naming server • Arcitect for J2EE vendors that support a shared, replicated naming server by : 1.DNS round robing. 2. Software proxies 3. Hardware proxies