Comparing Controls, EJBs, and JavaBeans

 <  Day Day Up  >  

On the surface, controls look much like their JavaBean and EJB cousins. Almost always, the question "Why use a control at all?" comes up. Why not simply use JavaBeans or EJBs? In fact, controls are similar to EJBs and JavaBeans in many ways. After all, the EJB component model enables developers to interact with other resources, much like a WebLogic Workshop control. However, controls have many fundamental and important differences.

Controls Versus JavaBeans

Before beginning a comparison of JavaBeans and controls, review the JavaBean definition. According to the JavaBeans v1.01 specification, "A JavaBean is a reusable software component that can be manipulated visually in a builder tool." The specification goes on to discuss introspection support, support for events, and support for properties, all the while emphasizing the concept of a JavaBean as a client-side object. The underlying point is that JavaBeans are targeted at client-side visual builder tools, which brings up the first major difference.

JavaBeans are designed primarily for client-side visual development . Controls, on the other hand, are designed for both client-side visual development and server-side runtime consumption. More specifically , controls are used in WebLogic Workshop during development and are instantiated at runtime by the server engine. Similarly, JavaBeans are available via an Integrated Development Environment (IDE) during development, but they are instantiated on the client at runtime.

The idea that JavaBeans are targeted primarily at client-side visual development whereas controls are designed for both client and server side points out a number of important differences that fall into four major areas:

  • Design

  • Development

  • Packaging

  • Runtime support

Design and Development

At the highest level, the JavaBean specification dictates that JavaBeans are primarily designed to be plugged into an IDE. Controls are also designed to be IDE pluggable, but have a well-defined runtime support model as well. In addition, controls have a well-defined life cycle that enables developers to ignore object management issues. JavaBeans, when not consumed via an IDE, must have their runtime environment managed by the developer. Both JavaBeans and controls can take advantage of library support; however, controls go one step further and define a number of parent classes that support the inheritance of common behaviors.

On the coding front, JavaBeans and controls differ considerably. JavaBeans must follow a relatively simple model of mutator/accessor methods based on the underlying data they contain. For example, a simple integer count variable normally has getCount() and setCount() methods taking and returning an integer, based on the type of the underlying count variable. Controls can have complex methods defined as needed and can take and return data in whatever format makes the most sense. Control methods need not be simple mutator/accessors, but can do whatever is required and still be available in the WebLogic Workshop IDE. JavaBeans are constrained to the underlying Java types and their derivatives. Additionally, WebLogic Workshop contains a number of wizards supporting the automatic generation of common control types, making development quick and easy. For example, a fully functional control for accessing a back-end database table can be created in mere minutes. Controls also support XML natively by using XML Beans. With XML Beans, there's no need to develop complex read/write mechanisms. After adding a Schema to a project, a control can take advantage of the Schema data types automatically. This support allows controls to work with data in its natural form, instead of shoehorning everything into getter/setter-style access and predefined data types.

Another significant difference between controls and JavaBeans lies in messaging support. Typical message models support synchronous and asynchronous messaging. JavaBeans can take advantage of synchronous messaging via their specified event model. Controls extend the concept of the JavaBeans message model to support bidirectional asynchronous messaging via a well-defined callback interface. As you've seen, callbacks are interfaces defined within a control and are implemented by the calling client. With callbacks, a developer can define a callback method and then invoke it asynchronously as needed. Registered clients then receive the method call.

An area that's becoming more important in messaging is connectivity. Three specific types of connected behavior can occur in today's networks:

  • Fully connected ” The client and server are connected all the time.

  • Disconnected ” The client is never connected to a server.

  • Partially connected ” The client is sometimes connected to the server.

The control's runtime engine has support specifically targeted toward connectivity ”namely, the capability to manage a conversation. Controls can clearly define which methods start, continue, and end a conversation. More important, controls provide mechanisms for obtaining conversation IDs so that applications can re-establish a conversation. Being able to re-establish a conversation in progress is the key to supporting a partially connected network model. JavaBeans don't have this feature, which is a significant drawback.

In a typical scenario, a client starts a process running, logs out, and later returns to check the status. Controls have mechanisms for getting and setting the conversation ID. However, by noting the original conversation ID with getConversationID() , a developer can re-establish a connection to an existing control with setConversationID() and return to get information about the process.

Packaging

JavaBeans are typically packaged into JARs by using the Jar utility. JavaBean developers are limited to the security measures the Jar utility affords them. Controls go much further than JAR files in offering packaging and security features. With the Control Developer's Kit, WebLogic Workshop enables third-party developers to not only package and deploy controls, but also to encrypt and license them. JavaBeans have no license model, so third-party developers are at the mercy of their clients for runtime use. Anyone who has access to a JAR file can use the JavaBeans it contains.

When to Use JavaBeans Versus Controls

Even with the drawbacks mentioned previously, JavaBeans are still an important development mechanism. In fact, I use JavaBeans on a daily basis. But when would you use a JavaBean rather than a control? In my experience, the most common use of a JavaBean in a WebLogic Workshop application is for value objects. I've created many JavaBean inner classes that are used as input to, and return data from, control methods. Of course, JavaBeans still make sense as data containers for JavaServer Pages (JSPs), and I often use JavaBeans as state within a Page Flow.

Controls Versus EJBs

So far, controls and JavaBeans have been compared. However, JavaBeans and controls weren't designed for the same purposes. A more reasonable "apples to apples" comparison can be applied to EJBs and controls. A closer look at EJBs and controls reveals the following:

  • EJBs are specialized server-side components designed to abstract transaction, security, and data management and to map into an easily configurable object. The EJB specification defines stateless session, stateful session, entity, and message-driven models, along with associated life cycles. Writing EJBs requires fairly sophisticated skills, and developing EJB clients also requires a fair amount of skill, although not as much as what's needed for writing EJBs.

  • Controls are generalized server-side components designed to be easily consumed by a large number of developers. Controls have a well-defined object model supporting transactions, security, deployment management, and life cycle management. Controls also have developer support in the form of consumer tools and developer wizards. Controls support all the EJB models as well as partially connected and fully asynchronous models. In addition, controls provide a set of mechanisms for accessing other well-known J2EE resources, such as databases and Web services, via built-in wizards. Additionally, controls and WebLogic Workshop provide a rigorous environment for extending the model and definition of new control types. Clients can consume new controls in the same way as "out of the box" controls.

The differences between controls and EJBs fall into the same four major areas: design, development, entity behavior, and transaction behavior and support. In addition, the same packaging issues exist.

Design and Development

EJBs and controls have very different design and development paradigms . Starting with the simplest area, method development, you can see both similarities and differences. Controls are based on a number of well-defined core types and are usually developed by using wizards. WebLogic Workshop wizards have a number of features that enable almost anyone to create controls quickly and easily. Developers can drag and drop methods onto a control, manage control attributes via properties, and generally design and develop controls using a what-you-see-is-what-you-get (WYSIWYG) approach.

EJBs also have a variety of tools that can make development easier. WebLogic Workshop supports a WYSIWYG paradigm for development; however, one important difference exists from the start. With EJB development, you must immediately choose one of the four EJB types: stateless session, stateful session, entity, or message-driven. From then on, the EJB is constrained by the original type. MDBs can't take on stateful behavior, session beans cannot become entity beans, and so forth. Controls differ from EJBs in that they are inherently stateful within a given user session. You can create stateless controls by simply not relying on state variables , but you don't need to be concerned with state because the underlying engine handles it for you. Over the development cycle of a control, you might create a control that exhibits a combination of stateful, entity, and MDB behaviors, or whatever combination is needed. From a pure coding perspective, EJBs require sophisticated knowledge for successful development, whereas control development simply requires an understanding of Java semantics.

Another important aspect of comparing controls and EJBs has to do with the complexity of the underlying model. With EJBs, you must know quite a bit about the EJB specification. Even with tools support, you must understand what interfaces to extend and the services of the underlying parent class, and you must code many life cycle “based methods. Controls, on the other hand, have a well-defined life cycle and include methods to interact with the server life cycle points. Unlike EJBs, most life cycle management for controls is handled for you; you can take advantage of life cycle events, but it's not required.

Entity Behavior

Entity behavior is another area where controls and EJBs differ significantly. Controls accessing database tables can easily be constructed by using the Rowset Control Wizard, which builds a control by accessing the underlying database, querying for its Schema, and then constructing methods that can access the database automatically. Entity EJBs can be written to perform similar functions; in fact, WebLogic Workshop offers EJB development support via the EJBGen utility. However, EJBs differ from controls in that entity EJBs can go beyond simple table access and support complex entity relationships, such as joins, cascading deletes, on-demand data loading via groups, and other areas. Similar functionality can be developed with controls, although not as quickly or as easily, as this development must be done by hand. The capability to write and manage complex entity relationships puts EJBs ahead of controls when this functionality is needed, but behind controls when only simple, single-table access is required.

Another difference has to do with data caching. Entity EJBs offer fine- tuned control over what data is loaded by specific calls, how this data is cached, and how complex entity relationships are managed over the data's lifetime. Database and rowset controls are designed for easy access, but do not provide built-in sophisticated mechanisms for controlling data loading. Controls do offer mechanisms for defining the maximum number of rows returned, but nothing more sophisticated. For simple data access, rowset controls can be created quickly, perform exceptionally well, and are easy to use. For complex multi-table interactions, in which data from many tables must be accessed simultaneously , entity EJBs provide a more robust mechanism.

Transaction Behavior and Support

Another significant difference between controls and EJBs is in the area of transactions. EJBs can be transactional, but EJB development requires that you be aware of and take steps to explicitly define transactional behavior. However, this explicit definition gives you additional levels of control, and the EJB specification defines a number of clear transaction types, supporting dozens of different levels of transaction interactions at both the overall EJB and individual method levels.

Controls are implicitly transactional, and all calls in a method are within the same transaction. Implicit control behavior has both positives and negatives . All controls and method calls to other controls are part of a transaction, but multiple transaction types and their interactions aren't available to developers. Your control can easily be part of a transaction; in fact, it is automatically, but opting out of a transaction isn't as easy.

Mixing and Matching Models

Now that you've seen a comparison of EJBs and controls, it's time to examine the underlying models of behavior as they apply to both EJBs and controls. As mentioned previously, EJBs define four basic models (stateless session, stateful session, entity, and message-driven). An EJB developer typically chooses a model and then implements a solution for the problem within the context of the model. Switching midstream between models is difficult, and mixing the behavior of two different models ”for example, asynchronous behavior with stateful behavior ”is difficult.

Controls go well beyond their EJB cousins in support of multiple programming models. Controls can grow and change over time as the developer requires. Stateless, stateful, and entity behavior can easily be added without undue complexity. However, controls really shine over EJBs in the area of asynchronous message-driven behavior.

The EJB specification defines a mechanism known as a message-driven bean (MDB) . MDBs are simple to write and deploy and have a single method that's called when a message is delivered for processing. MDBs are usually bound to a JMS queue or topic and receive and process messages as needed. Additionally, MDBs can have an optional selection criteria for filtering which messages are received, based on message content, required fields, or both.

Controls go well beyond the MDB mechanism by supporting callbacks. Assume that you want to develop a component that has many traditional synchronous methods, but also has some long-running asynchronous behaviors. Additionally, you want notifications when the asynchronous background operations are completed.

You can solve this problem and stay within the EJB specification. You need to develop at least two EJBs: an MDB to listen for the request for the long-running behavior and an EJB to process the other synchronous requests, perhaps with methods to submit requests to the MBD. In addition, you need two JMS queues ”one for requests and one for responses. You'd probably need to implement some sort of polling mechanism as well to determine when the request is completed. All in all, this architecture is rather complex and requires careful design, development, and testing. To make matters worse , what happens if the client is intermittent and only partially connected? You'd need to develop a custom scheme to reconnect to the client.

Controls solve these problems with callbacks and conversations. A control can handle the same component-development problem described previously, but does so very differently. The control developer creates a long-running method, enables the message buffer property, and changes the method behavior, making it asynchronous in nature. The method is automatically made asynchronous and associated with a queue that's managed by the runtime engine without any specialized development. Client notifications are then handled by callbacks.

Additionally, with a partially connected client, the client disconnects and then returns to check the status of a previously started operation. Controls provide a mechanism for managing conversations via a built-in conversation ID. By marking methods appropriately, a control becomes conversational. A client can obtain a conversation ID, store it in whatever fashion is appropriate, and later re-establish the conversation to interact with the control running in the background. All this functionality is available with only a few simple lines of code ”specifically, one line of code in the control to call the callback method when needed, and one line of code in the client to register the callback. This simplicity is a far cry from the intricacies of developing the same solution with EJBs.

Also note that if you use the EJB solution for this same component-development problem, complex messaging formats must be defined to pass data to a MDB and receive results back. Controls, on the other hand, handle callbacks and long-running process invocations in the same way, as native method calls. Method calls can be written that look exactly like everyday method calls, yet are used to manage asynchronous behavior. In these cases, the complexity of the client and control methods are significantly reduced because no complex messaging formats need be developed.

Conclusion: When to Use Controls Versus EJBs

Controls and EJBs can be compared in other areas, but the most important question is when do you use EJBs or controls?

Develop with EJBs when you

  • Need to remotely call an object, but specifically don't want to implement the object as a Web service.

  • Need to tightly manage transaction interactions.

  • Need to take advantage of the EJB entity relationship model for the purpose of managing multiple related database tables as though they were a single entity.

  • Want to take advantage of stateful session replication.

  • Need to extend the functionality of existing thick clients that can't be moved to WebLogic Workshop at this time.

  • Are comfortable with the EJB model and don't want to move to another model.

Use or develop with controls when you

  • Need lightweight, locally accessible components.

  • Want to develop complex persistence logic quickly and easily, using multiple data stores beyond simple databases, without the complexities of EJB Bean-Managed Persistence (BMP).

  • Need a tightly coupled yet asynchronous enabled communications model.

  • Need a partially connected communications model, in which communications are established, disconnected, and then later re-established.

  • Want implicit transaction logic and state management without development overhead.

  • Need to access data in its native format, such as binding data directly to an XML Bean.

  • Need to develop complex XML mapping logic quickly.

  • Want to access J2EE services quickly and easily with newly developed services via one of the many wizards or directly via a prepackaged control.

  • Want access to one of the dozens of third-party vendor controls.

  • Want tight integration with WebLogic Workshop.

  • Want a tightly controlled licensing, packaging, and distribution model.

In reality, both controls and EJBs have their place in WebLogic Workshop development, and both happily co-exist. You simply need to examine closely what you're attempting to do and the answer to your question about which model to use will become apparent.

 <  Day Day Up  >  


BEA WebLogic Workshop 8.1 Kick Start
BEA WebLogic Workshop 8.1 Kick Start: Simplifying Java Web Applications and J2EE
ISBN: 0672326221
EAN: 2147483647
Year: 2004
Pages: 138

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net