Welcome!

Java IoT Authors: Pat Romanski, Elizabeth White, Liz McMillan, Yeshim Deniz, Mehdi Daoudi

Related Topics: Java IoT

Java IoT: Article

Developing Coarse Grained Business Components

Developing Coarse Grained Business Components

Discussion groups have recently been abuzz with talk of "coarse-grained entity beans" - a slight misnomer deriving, I suspect, from the addition of mandatory entity beans in EJB 1.1. This month I'll examine the finer points of the Enterprise JavaBeans specification regarding coarse-grained entities, as well as my own, and provide an example for you - with plenty of comments to provide food for thought when you tackle the challenge yourself.

For those of you who finally came out of your Y2K shelter, EJB is a specification for building server-side business components on the Java platform. Its initial release required only enterprise beans called session beans, which are a logical extension of a client's business process. The specification mentioned entity beans, which represent persistent business components, but didn't mark them as mandatory for EJB 1.0 compliance.

However, industry demand for details about entity beans forced Sun and its partners to include them in the EJB 1.1 release. The updated specification provides some structure around entity bean development, but it created a whole new set of questions about EJB design patterns. The main EJB design pattern I'll cover this month revolves around coarse-grained entity beans and dependent objects.

Granularity of a Bean
I was recently on "The Hill," near the campus of the University of Colorado at Boulder, and noticed that the sidewalk had numerous quotes from philosophers and great thinkers - they must be there to provide inspiration to students who look at their feet when they walk or something! I'm going to start off with a few quotes myself, by way of helping to describe the granularity of an entity bean.

Section 9.1.2 of the EJB specification 1.1 reads: "In general, an entity bean should represent an independent business object that has independent identity and lifecycle, and is referenced by multiple enterprise beans and/or clients. A dependent object should not be implemented as an entity bean. Instead, a dependent object is better implemented as a Java class...and included as part of the entity bean on which it depends."

Great, but now you're asking what in the heck "dependent objects" are. Richard Monson-Haefel sums up the notion of dependent objects well in this quote from his book Enterprise JavaBeans (O'Reilly and Associates, 1999): "Dependent objects are objects that only have meaning within the context of another business object. They typically represent fairly fine-grained business concepts, like an address, phone number or order item. For example, an address has little meaning when it is not associated with a business object like Person or Organization. It depends on the context of the business object to give it meaning. Such an object can be thought of as a wrapper for related data. The fields that make up an address (street, city, state, and zip) should be packaged together in a single object called Address. In turn, the Address object is usually an attribute or property of another business object; in EJB, we would typically see an Address or some other dependent object as a property of an entity bean."

If I could say it better, I would.

Why Coarse-Grained?
The three core reasons for building coarse-grained entity beans are:

  1. Reusable business value
  2. Less work to develop and deploy
  3. Scalability, manageability of EJB Server

First, let me reiterate: Enterprise JavaBeans is a specification for server-side business components for the Java platform. EJB strives for reusable, configurable business components. With EJB you're no longer working with fine-grained objects. Small business objects by themselves provide little value. Most likely they'll rely on helper objects to provide real value, and together they make a component. Coarse-grained components provide a reusable piece of business functionality that can be applied to many different solutions as a single unit. Although I'm happy to see people get excited about innovative EJB design patterns, coarse-grained components are really nothing new; the design pattern has been around for years. I used to call it a "constellation," a collection of interrelated objects, all fetched from a root business object and dependent on that parent for management of their life cycle.

Second, enterprise beans aren't easy to develop, so the fewer beans you need to develop and deploy, the faster your applications are going to get to market. For instance, when developing a typical entity bean, you must code and test a remote interface, home interface, bean class, primary key class (unless you're using the J2EE reference implementation - has anybody figured that thing out yet?) and deployment descriptor.

You need to walk through various steps to package these classes in the correct format and deploy them in a nice little JAR file along with a manifest file describing each entry. Couple your EJB classes with the classes your container generates to manage your component, and you have a major class explosion on your hands. Sounds like a lot of work, and it is. However, building coarse-grained components eliminates tedious steps and class explosion by encapsulating the functionality of dependent classes within their parent entity bean.

Third, fewer entity beans means fewer resources for your server to manage and greater performance for object interactions within your components. Entity beans are remote objects, which can be costly for a server to manage when their numbers are high. For instance, a bean's home is registered in a naming service for remote lookups. As the naming service becomes full of entries, lookups may take longer. Have you ever done a file search on a directory with 10 files, then the same search on a directory with 100, 200 or 1000+ files? You get the picture.

Your EJB Server should provide a scalable, secure execution environment for your EJBs; however, you should work with it, not against it, to promote this scalability in your bean design. Because beans are remote objects, the server is required to manage remote connections and garbage collection, and usually maintains caches for your bean instances. Fine-grained objects usually interact closely with one another to perform their business functions. Fine-grained interactions aren't suitable for remote objects, which must marshal calls to each other, repeatedly creating copies of parameters and return values that must be garbage-collected at some point. These interactions are more conducive to a coarse-grained business component that encapsulates all logic behind its umbrella of locality.

While your application logic may be scalable, sometimes the pipeline to it or the server itself gets taxed. Keeping the number of remote connections to your server, remote method invocations and bean instances to a minimum is thus advisable. A coarse-grained business component encourages these best practices.

An Example: PersonBean
It's time for an example of a coarse-grained entity bean that manages dependent objects according to the EJB specification. I've chosen the Person business component because it appears in various shapes and sizes across numerous industries. My example (see Listing 1) consists of a Person entity bean and an Address, a dependent object and a test class to see the bean in action. It's written on WebLogic 4.5.1, an EJB 1.0-compliant server; although 5.0, which is 1.1 compliant, isn't available at this writing, I've nevertheless adhered to the EJB 1.1 specification's guidelines for building coarse-grained entity beans.

The example demonstrates a coarse-grained, bean-managed persistence (BMP) entity bean that manages the whole life-cycle of its dependent objects from insert to delete. It is configurable via its deployment descriptor to perform either lazy-loading (fetching only when requested) or eager-loading (loading dependents in anticipation of their use) of its dependent objects, both of which are supported by the spec. It then performs smart writes to the database, updating only modified dependent objects in its cached data.

As you'll see from the code at the end of the article, the example is loaded with comments to help you think about the issues behind building your own BMP entity beans.

Person to Address Association
The basic rules governing the PersonBean is that a Person can exist in the system without an address; however, an Address is dependent on the Person - it can't be inserted without its parent (i.e., PersonBean) and must be removed when the Person is deleted. This logic is evident in the factory interface of the PersonBean. For instance, the PersonHome.create method takes only Person attributes, but requires no Address object(s).

public interface PersonHome extends EJBHome {
PersonEJB create(int personID, String title,
String firstName, String lastName)
throws CreateException, RemoteException;

This inherently implies that it may be inserted without addresses, though the interface is flexible enough for an application requiring a Person to have at least one address. Such an application could wrap the PersonBean in a session bean and call PersonEJB.addAddress (newAddress) in the same transaction, ensuring that an Address was always inserted along with the Person. Already, you've seen a reusable scenario for this coarse-grained business component!

Caching Dependent Objects
When developing coarse-grained entity beans, you'll have to understand the EJB 1.1 specification's demands around loading and storing cached data.

Loading Cached Data
The EJB specification lists three ways to load cached data in an entity bean. The first is an eager-load, in which your code loads all cached data at once in the ejbLoad method (see Listing 1). The second approach is to lazy-load entity data, loading it only when it's needed to satisfy a business method. The last method to caching entity bean data is not to cache at all, but to pass all access to entity bean state directly to the underlying database.

The PersonBean caches its own fields as well as dependent Address objects in a local java.util.List. The loading of the Address list is determined at deployment of the bean via its "lazyLoad" bean environment property. If it's true, the ejbLoad method will not load address data. Instead, it will clear the list to ensure proper management of the cached data according to the EJB spec, section 9.1.7 (see Listing 1). Cached data that's not loaded needs to be cleared here, since ejbLoad is called whenever a container needs to synchronize state with the database, such as in the event of a javax.transaction.TransactionRolledBackException.

If "lazyLoad" is false, it will perform a JDBC query to fill its list right away. The PersonBean uses environment properties for flexibility and reusability by allowing bean deployers to modify the behavior of the component declaratively without ever touching the code.

A copy of the PersonBean's Address list is publicly accessible via the component interface method getAddresses. When the container invokes this method on behalf of a client, the PersonBean will check to see if the address list is already available. If so, it returns the list without reading from the database. Otherwise the PersonBean will use a JDBC query to fetch all of its addresses, caching each in its local list before returning the list to the caller.

Updating and Removing Cached Data
The EJB specification states, "When the container invokes the ejbStore method on the instance, the instance must push all cached updates to the entity object's state to the underlying database" (EJB specification 1.1, sec. 9.1.7).

The key phrase in this quote is cached updates. In other words, you can apply "smart updates" to your bean's cached data by checking for modifications and updating only this information back to the database.

The PersonBean uses smart updates for its dependent Address objects (see Listing 2). For instance, when the client updates an Address, the PersonBean will mark the Address as "modified" and replace the old version with the new one in the local list. The PersonBean will wait until ejbStore is invoked before updating the modified Address object to the database. When the container calls ejbStore, the PersonBean will loop through each Address in its list, calling a JDBC Update only for modified objects.

Similar to the way ejbStore manages all cached state for the entity bean, ejbRemove also handles the referential integrity of the PersonBean component, ensuring that all Address objects are removed when the PersonBean is deleted (see Listing 3). There are a couple of ways to maintain component integrity upon deletion of a parent. One approach is to create a cascading delete in the database that will automatically delete all related rows in the Address table when its Person is removed. In this case there would be no need to code a JDBC Delete call from within ejbRemove. A second option, the one I chose, is to manually perform the JDBC Delete of child-dependent object rows. This ensures the component's integrity no matter what JDBC-compliant database platform it's deployed against. Both methods have advantages and disadvantages, so "pick your poison."

The management of cached data in an entity bean is confusing at first, but soon you'll find it flexible enough for you to develop tuned, configurable data access code. The PersonBean uses two tuned data access patterns: lazy-loading and smart updates.

Summary
I hope this discussion has dissipated the confusion that's been circulating within numerous discussion groups about how to develop these components. The example demonstrated how to build a BMP entity bean that controls the life cycle of a dependent object and focused on some gray areas of the EJB 1.1 specification, such as how to manage cached state when loading, storing and removing an entity bean that encapsulates dependent objects. Please refer to the full code listing on the Web (www.sys-con.com) and modify the test case to perform more in-depth exercises on the behavior of a coarse-grained component.

More Stories By Jason Westra

Jason Westra is the CTO of Verge Technologies Group, Inc. (www.vergecorp.com). Verge is a Boulder, CO based firm specializing in eBusiness solutions with Enterprise JavaBeans.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed, transparency and flexibility, paving the way for a more pervasive use of IoT to accelerate enterprises' digitalisation efforts. AI-powered intelligent connectivity over Microsoft Azure will be the fastest connected pat...
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
Codete accelerates their clients growth through technological expertise and experience. Codite team works with organizations to meet the challenges that digitalization presents. Their clients include digital start-ups as well as established enterprises in the IT industry. To stay competitive in a highly innovative IT industry, strong R&D departments and bold spin-off initiatives is a must. Codete Data Science and Software Architects teams help corporate clients to stay up to date with the mod...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Druva is the global leader in Cloud Data Protection and Management, delivering the industry's first data management-as-a-service solution that aggregates data from endpoints, servers and cloud applications and leverages the public cloud to offer a single pane of glass to enable data protection, governance and intelligence-dramatically increasing the availability and visibility of business critical information, while reducing the risk, cost and complexity of managing and protecting it. Druva's...
BMC has unmatched experience in IT management, supporting 92 of the Forbes Global 100, and earning recognition as an ITSM Gartner Magic Quadrant Leader for five years running. Our solutions offer speed, agility, and efficiency to tackle business challenges in the areas of service management, automation, operations, and the mainframe.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...
DSR is a supplier of project management, consultancy services and IT solutions that increase effectiveness of a company's operations in the production sector. The company combines in-depth knowledge of international companies with expert knowledge utilising IT tools that support manufacturing and distribution processes. DSR ensures optimization and integration of internal processes which is necessary for companies to grow rapidly. The rapid growth is possible thanks, to specialized services an...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...