< 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 JavaBeansBefore 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 and DevelopmentAt 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:
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. PackagingJavaBeans 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 ControlsEven 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 EJBsSo 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:
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 DevelopmentEJBs 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 BehaviorEntity 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 SupportAnother 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 ModelsNow 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 EJBsControls 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
Use or develop with controls when you
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 > |