Understanding the Versata Logic Server within the J2EE Framework. > A Technical Brief for Java Developers and Architects

Transcription

1 Understanding the Logic Server within the J2EE Framework > A Technical Brief for Java Developers and Architects

2 Table of Contents: Introduction Questions and Answers What is the solution comprised of? What is the Logic Server? Is it a full application server? Can be managed like other application server components? What are business objects? How are they deployed? What type of EJBs does use? How does it manage persistence? How are these business object EJBs accessed by non- applications? What is the role of the Presentation Server? What if I want to use JSP pages? What are my options? This layered architecture sounds complex. How do the J2EE recommendations relate to it?....5 How does provide for session state and failover? What about security? What J2EE standards does use? What services does provide above and beyond the J2EE platform services? What are the key take-aways for Java developers?..8 A Case Study Example

3 Introduction This paper describes the architecture of the Logic Server operating within a Java 2 Enterprise Edition (J2EE) application server, such as IBM WebSphere or BEA WebLogic. This paper is designed to: > Demystify the runtime environment for Java developers and architects > Describe how can be used with components such as Java Server Pages (JSPs) and Enterprise JavaBeans (EJB) created in other standards-based development tools > Delineate the services provided by the Logic Server and explain how these services complement the services provided by the J2EE application server > Explain how rules create Java application logic and how this logic can be extended by Java developers shares the industry s enthusiasm for robust J2EE-based application servers whose containers provide the runtime foundation for secure, distributed, heterogeneous, e-business applications. The Question and Answer format of this paper will demonstrate how adds value to the J2EE model throughout the application lifecycle encompassing development, deployment, and runtime: 1. During development, uses business rules to automate the construction and maintenance of complex, transactional applications whose logic is available to other J2EE-compliant components 2. During deployment, automates the deployment of components as EJBs running in the J2EE application server 3. During runtime, provides high-level business logic services on top of J2EE services and provides a high-performance framework, within the EJB container, for the execution of those services Questions and Answers What is the solution comprised of? is comprised of six key components (see Figure One): 1. The Studio provides the visual development environment for capturing business rules and application design requirements and automatically creating and deploying application components from them. 2. The Logic Server hosts business components, providing business logic services and a high-performance execution framework as well as access to external resources and integration services. 3. The Presentation Server and Presentation Adapters extend logic to any interface or presentation client in the form of dynamic HTML, Java, XML, JSP, and other third-party interfaces. 4. The Design Adapters enable integration with specialized tools for data modeling, source code control, and content management streamlining the design and development environment. 5. The Connectors allows integration with external data sources using the extensible Data Access (XDA) framework. 6. Finally, the Console is a management interface into the Logic Server that provides configuration and security information, traces rule execution, and monitors application resource utilization. 2001, Inc. All rights reserved. 1

4 Design Present Rational Rose Modeling/ UML Java HTML JSP Server ATG Vignette Wireless Design Adapter Presentation Server Presentation Adapters Develop Studio Transact Logic Rules Logic Server Process Rules Application Designer Business Rules Designer Application Server IBM Websphere, BEA WebLogic, CORBA Inprise Console Process Designer Deployment Manager XML Repository Connect Connectors Lotus CICS Web DBMS Notes AS/400 Methods Custom Connectors MQ Series Tibco Figure One: Six Key Components of the System What is the Logic Server? Is it a full application server? In the J2EE application server (IBM WebSphere and BEA WebLogic) environment, the Logic Server applies to a small set of sophisticated EJBs that run inside the application server s EJB container. The Logic Server provides support services for the business and application objects built by. The primary EJBs in the Logic Server are VLSContext (processes business logic) and PLSContext (processes presentation logic). Their JAR files contain the extensive Logic Server Class Libraries needed to provide runtime services to the business and application components created by. These EJBs are placed into a J2EE application server EJB container when is installed, and can be viewed from the administrative interface of the application server. Can be managed like other application server components? For instance, can it be loadbalanced like my other EJBs? Porting the Logic Server to a J2EE application server involves implementing the Logic Server in such a way that it is managed just like any other platform component. This includes targeting to the security, transaction management, distribution, and deployment specifics of that vendor s platform ensuring that all of the features of that platform can be leveraged. Models and Clones For load balancing in IBM WebSphere, for instance, adopts IBM s concept of models and clones. WebSphere allows an instance of a Java virtual machine, one or more enterprise bean server processes, and a servlet engine to be logically grouped into an application server. These applications servers may be modeled (contents and configuration information written to the WebSphere application server database), and cloned (replicated to another application server instance). The model acts as a template for creating copies (clones) of application servers. WebSphere ensures that cloned application servers are automatically updated when the model is changed. To leverage this capability, has been implemented as a WebSphere application server. An instance of a application server will include: > The core Logic Server implemented as EJBs (VLSContext, PLSContext, etc.). The JAR file for each EJB will include services classes. Its CLASSPATH will include the JAR files that contain all of the classes for the business and application objects deployed through. > Business objects that have been (optionally) deployed as EJBs > A servlet engine plus servlets for each deployed application , Inc. All rights reserved.

5 Workload Management When the application server is cloned, it becomes available to the workload management facility of WebSphere. When a user initiates a new session, WebSphere creates a Logic Server (and Presentation Logic Server) context for that user on a application server clone, according to the Workload Management policy set by the WebSphere Administrator (round-robin, random, etc.). Since the Logic Server and Presentation Logic Server are implemented as workload-managed session EJBs, WebSphere will direct the user back to this application server for all subsequent requests for the duration of the user session. s implementation on BEA s WebLogic is similar BEA WebLogic allows application servers and their resources to be replicated. Since the Logic Server is configured as an instance of a WebLogic application server, multiple copies of can run with the same configuration. WebLogic distributes the user load among all of the Verstata Logic Server replicates. What are business objects? How are they deployed? business objects contain the implementation of the business logic defined in rules. They are deployed as Java classes packaged in a JAR file (one per repository) that is added to the CLASSPATH of the VLSContext EJB. To improve performance, the Logic Server accesses these objects locally during rules processing and other logic-intensive operations. Objects to be referenced by clients other than the Logic Server can also be deployed as EJBs complete with home and remote interfaces. DataObjects are deployed as entity EJBs and QueryObjects are deployed as session EJBs. As shown in Figure Two, these objects are automatically installed in the same EJB container as the Logic Server. Think of these EJBs as remotely referenceable façades of their corresponding business objects; they make objects available to other, non-, EJBs. With, there is no inherent performance penalty when deploying objects as EJBs since the Logic Server uses local access for all logic operations, regardless of whether the object has an EJB façade. Furthermore, rulesprocessing and other services will still be applied to these EJB objects, regardless of whether the object is accessed by or by a non- application. WebSphere Administrator Console components grouped together in a WebSphere Application Server Logic Server EJB Logic Server Presentation Logic EJB Business Objects deployed as EJBs application servlets Figure Two: Components Displayed in WebSphere Administrator Console 2001, Inc. All rights reserved. 3

6 What type of EJBs does use? How does it manage persistence? The Logic Server EJB The VLSContext EJB, which controls business logic processing, is a sophisticated session bean that handles the bean-managed persistence on the data objects under its control. Since automatically handles persistence of its objects, developers reap the performance and flexibility benefits of beanmanaged persistence such as persistence to any data source, including non-relational sources. At the same time, developers enjoy freedom from implementation details, similar to the benefit provided by container-managed persistence (CMP). Yet goes a step further: With, developers need not worry about cumbersome deployment descriptors required by CMP. Through the Console, developers can re-target objects from one persistent store to another at runtime, without re-deploying the objects. Business Object EJBs employs two types of business objects: > Data objects, which map more or less directly to an underlying data server such as a DBMS, and > Query objects, which can be used as a view into one or more joined or projected data objects. Developers have the option of deploying an external interface to these objects as EJBs. deploys the external representation of a Data Object as an entity bean; deploys the external representation of a Query Object as a session bean. These entity and session beans call on the Logic Server for persistence services, ensuring the same class of service for all objects. How are these business object EJBs accessed by non- applications? For every business object, automatically creates a home interface and a remote interface file. When deploys an object as an EJB, the home interface allows non- applications to create objects and, in the case of a DataObject deployed as an entity bean, to access the object by its primary key. To make other business object methods available to non- applications, developers include those in the remote interface file. In addition, the Logic Server has a sophisticated set of client-side libraries (the Foundation Classes) that provide high-performance, set-based access from any Java-capable client. What is the role of the Presentation Server? What architecture does it use for HTML applications? The Presentation Server extends business object logic to the presentation layer. Its rich set of class libraries automatically build and run the Java or HTML applications modeled in the Application Designer of the Studio. The components of a -created HTML application will include: > HTML pages automatically created by from templates called archtetypes. These pages use standard HTML elements such as input fields, hyperlinks, forms, and other elements all of which can be edited using standard web tools. In addition, these pages contain -specific tags that are processed by the Presentation Server to control behavior such as data binding, scrolling through data sets, and displaying error messages. > Java classes one for each HTML page. These classes dynamically generate HTML content at runtime and contain logic for each data source, hyperlink, pick list, or other element on the page. These Java classes are deployed into the JAR file of the PLSContext EJB and normally execute in the same EJB container as the Logic Server. > A servlet for the application. The application servlet accepts communication from the HTTP browser and calls appropriate pages in the Presentation Logic Server. As such, it acts as the traffic cop of the application mediating between the web components and the EJB components , Inc. All rights reserved.

7 What if I want to use JSP pages? What are my options? There are several ways to access objects through JSPs (and any other non- client). As we have seen, business objects can be deployed as EJBs, making their methods available to external clients through remote method calls. These remote methods can be made available to JSPs by packaging them into a Data Access Bean or similar reusable component. Remote access directly through an object s EJB interface requires some custom coding. For JSPs, this additional coding step can be avoided by using the JSP Presentation Adapter. The JSP Adapter allows JSPs to access the full power of the Logic Server without exporting business objects as EJBs. The JSP Presentation Adapter provides three modes of access: 1. Inline Java This mode is for those using JSP 1.0, which does not support JSP tag libraries. 2. JavaBeans In this mode, two example Java Beans are included, vlsconnection class and vlsobject class, to handle Logic Server security, session, and access to business objects. 3. Custom tags For those using JSP 1.1, this mode includes a custom tag library that allows page designers to declaratively access business objects through JSPs with HTML-like tags. This is the preferred development method since it isolates the designer from server-side Java code. In addition, provides a complete client-side Java API. This API can access objects from any Java application, applet, or servlet. This layered architecture sounds complex. How do the J2EE recommendations relate to it? A widely accepted pattern in the J2EE world is the Model-View-Controller (MVC) architecture, where business logic, presentation logic, and persistence logic is de-coupled. This architecture makes systems more adaptable, but it greatly increases the number and complexity of component interactions. For this reason, it is often reserved for the most sophisticated J2EE applications. As show in Figures Three and Four, makes the benefits of the MVC architecture readily available to every application. Another way to think of this of this architecture is to break it along the boundaries of Present, Transact, and Connect, in which case Model View Controller MVC implementation In MVC, the Model is the set of business objects and logic that will apply, potentially, across many applications. The View presents the content of a model and interprets user interaction. The View is typically specific to the device (web browser, WAP phone, etc.) that will render the applications. The Controller mediates between the Model and the View by accepting input from the View and selecting appropriate Views in response. s MVC Implementation In, the Model is comprised of Data Objects, business rules, customized object logic, and the persistence layer. The View is the collection of HTML pages and other web resources constructed by and dynamically populated by page objects. Alternately, it may be a Java application or applet similarly constructed by. The Controller includes Query Objects which abstract Data Objects in the presentation layer, the application servlet which calls pages as needed, and page objects that define application behavior. Figure Three: Architecture compared to MVC Architecture 2001, Inc. All rights reserved. 5

8 Application Server Objects Java HTML XML JSP Wireless Servlet Web Server Controller EJB Container Page Objects (PLS) View View View Objects Model View Controller Query Objects (VLS) Data Objects (VLS) Controller Controller Controller Model Model Model XDA CICS S390 MQ Series Figure Four: Runtime Architecture Mapped to Model- View-Controller Concepts provides specialized services for each of these functions. In addition, allows each of these layers to be specified through a set of rules. The rules allow the developer to easily state the specification for each layer. rules-based development automatically results in a system architecture that is layered for maximum performance and flexibility. Is the Logic Server a stateful or stateless bean? How does provide for session state and failover? In the J2EE layered architecture, there are two states to be maintained: 1. Presentation state which can include user id, the pages the user has navigated, the page the user is currently viewing, and so on. 2. Business object state which can include the changed value of data before it is written to a database. Architects usually recommend the presentation state be maintained in the presentation logic layers. complies with this recommendation by persisting state for: > Java applications and applets automatically persisted by the users session object > HTML applications through an API in the PLSServlet (Page Logic Server Servlet) class. PLSServlet implements a SessionStateManager interface to StoreState and LoadState on reintialization. Either a filesystem file or a database can be used to store the state. Architects also recommend that the business logic state be maintained through the use of stateful session EJBs. The Logic Server is a stateful session bean. Upon deactivation, the EJB container can automatically persist the state of the Logic Server. In addition, most application servers provide failover capabilities to stateful sessions beans. What about security? How does map to the security provided by the application server? Application servers must manage security on both web resources (such as HTML pages and images) and EJB resources (such as method groups). Web resources are typically protected by comparing a user s id, prompted for by the web server, to permissions on the files or directories containing web resources. Streams of data being directed to or sent from the web server may be protected by an encryption mechanism such as SSL , Inc. All rights reserved.

9 EJBs, on the other hand, are protected by limiting access to their methods. Users (through their membership in a role) are granted permission to execute all or selected Java methods in the remote or home interface of an enterprise bean. One of the challenges of building multi-tiered business applications has been reconciling the security mechanisms provided by each of the tiers and providing an appropriately granular control over the business objects and application components of the system. provides such reconciliation and control by: > First leveraging standard mechanisms to establish user identity and giving users access to the Java processes that make up the Logic Server. > Then providing an extra layer of services, providing fine-grained and easy-to-administer permissions for all of the system components deployed by. Authentication: Establishing User Identity Before accessing resources (business objects or applications), users must be authenticated either through a mechanism or through an external mechanism supported by the Java application server hosting. Both WebLogic and WebSphere provide choices for user authentication, either via the operating system user registry or a supported directory service such as LDAP. To facilitate administration, Java application servers typically allow all of the resources needed for an application (EJBs, servlets, etc.) to be grouped together. WebSphere calls these Enterprise Applications; J2EE has standardized on the term Web Resource Collection. User or group permissions can then be applied to the collection, rather than to the hundreds of components that may comprise the application. leverages this facility by grouping the Logic Server components into such a group. Users are then given application server permission to access the Logic Server (much like database users are given permission to access a database server). Authorization: Granting Permission of controlled Components reviews a user s membership in a role to grant access to objects or applications. To coordinate with the security of the WebLogic or WebSphere application server, the role of the user will be determined by the name of the enterprise application (or J2EE equivalent) the user has signed on to. For instance, if this collection of Logic Server resources have been grouped into a collection called order_entry, the user will be given order_entry level permission within. Since resources may be grouped together into multiple enterprise applications, many roles within are supported. The Logic Server console provides an easy way to assign permissions to roles. In general, permissions are more fine-grained than the method permissions specified in J2EE. For instance, distinguishes between update permission on an existing business object and insert permission for a new object. J2EE provides only for a general write method. s object authorization service also automates presentation behavior. For instance, users will not be presented with SAVE button on HTML pages if they do not have authorization to insert or update the root RecordSource of the page. This seamless integration of business object logic with presentation control is another example of the power of business rules application automation with. What J2EE standards does use? The current version of the Logic Server was built with the JDK 1.2 to the EJB 1.1 specification. It performs client-to- Logic Server lookups using JNDI 1.2 (through the application server) and using RMI/IIOP (by default on WebSphere and optionally on WebLogic). Database connectivity uses the JDBC 2.0 specification. Transactions are written using the JTA 1.1. The JSP adapter supports the JSP 1.1 standard. Collectively, these comprise the core J2EE standards applicable to a logic server architecture such as the Logic Server. Other parts of the J2EE standard not directly applicable to the transaction model used by (such as JavaMail and JMS) can be leveraged to provide 2001, Inc. All rights reserved. 7

10 asynchronous communication. These APIs can be called through rules, objects, or the XDA layer. What services does provide above and beyond the J2EE platform services? Services are illustrated in the Case Study on page 9. provides enhanced services in each of its architectural layers Present, Transact, and Connect. The services provided by the Logic Server are generally higher-level services than those provided by the J2EE application server. Services provided by the Logic Server can be compared to services provided by J2EE application servers in the following way: J2EE services free the developer from routine infrastructure programming, allowing them to concentrate on business logic; services free the developer from routine business logic programming, allowing them to concentrate on issues such as complex connectivity to legacy systems which are unique to their environment. services include: > MetaData Services > Cached Value Lists Services > Query Services > ResultSet Services > PageListener Services > StateManagement Services > Transition Services > Transaction Buffering Services > Optimistic Locking Services > Object Mapping Services > Rules Processing Services > Transaction Services These services can be grouped around three main objectives: 1. Optimizing the performance and flexibility of retrieval and query operations 2. Optimizing the performance, flexibility, and integrity of transactions (updates or inserts) 3. Processing business rules and other application logic The use of these services is detailed in the Case Study on page 9. Can you summarize? What are the key take-aways for Java developers? In a nutshell, here s what Java developers should know about : > The Logic Server is made up of standard J2EE components, such as EJBs, which can be managed within a J2EE application server such as IBM WebSphere and BEA WebLogic using familiar tools and techniques. > Within EJBs, provides a complete and high-performance framework for executing applications that have been automatically created with business rules. > While much of application development is automated, it is always under the complete control of the Java developer. provides many levels of integration which allow s very foundation to be extended by the developer. > can call and be called from other components. This allows to be integrated into an enterprise architecture built around the J2EE standard , Inc. All rights reserved.

11 A Case Study Example What services does provide above and beyond the J2EE platform services? The following section examines a few of the Logic Server services involved in processing the requests of a typical user, who: > Is presented a CUSTOMER_QUERY HTML page with which to query for customers by any of their attributes., including a pull-down list from which to select the Address_State > Is presented with a table of CUSTOMERs that satisfy the query. Upon choosing the correct CUSTOMER, user selects a View_Detail option that links to a page to view > A CUSTOMER and a table of related ORDERS, from which the user > Makes a change to an ORDER (changes the Qty_Ordered) > And presses Save. Coded values lists consist of displayed/stored pair of values which are initially stored in the database, but which are cached at runtime in the Logic Server. To increase performance, the cache containing validation lists are shared among users. In our example, the Logic Server will immediately respond to the user, delivering a list from cache and enabling the user to pick from a fully formed state name (such as Maine not ME). In clients, nearly all bound controls (text boxes, table data, etc.) implement a Queryable interface. This service automatically collects user input from all of the queryable controls on a form and constructs the where clause of an ad-hoc query which is passed to the Logic Server. In the case of our example, where the user has just completed the CUSTOMER_QUERY page, a hyperlinked page to accept the result of the query will be called. Services used in Step 1 Querying to find a CUSTOMER MetaData Services: The power of objects stems in part from the objects rich set of metadata. In the case of an HTML page object, the metadata describes the data and query objects on the page, any master/detail dependencies between the data objects, attributes to be shown for each object, and so on (this metadata is stored in the XML repositories.) When displaying the CUSTOMER_QUERY page, uses its MetaData services to create a page showing all of the correct (and empty) input fields into which the user can type query parameters. Cached Value Lists Services: The Address_State will have a pull-down showing all valid states. This is a Coded Values list which is automatically constructed by based on the data model (whose validation rule for Address_State indicates that the validation for this attribute is provided by a Coded Values List ). Services used in Step 2 Displaying a set of customers In our example, a page is called on which is displayed a set of customers that satisfy the user s criteria. When the results page is called, the query is automatically passed by to the new page. Query Services: The Logic Server, with knowledge of the application s metadata, determines whether this is a query against a simple DataObject object (no joins, master/detail relationships, etc.) or a QueryObject (objects joined on the key fields, or those with restricted or derived attributes). Regardless of the complexity of the object being queried, and regardless of the source of the object (RDBMS or other data source), the Logic Server will execute a query against that data source and return a ResultSet to the client. 2001, Inc. All rights reserved. 9

12 The exact mechanism that uses to access the data source varies by type and by configuration. In the case of an RDBMS, can be configured to use DBMS Connection Pooling in cases where it is provided by the application server. abstracts connection details in its XDA (extensible Data Access layer), providing a single, high-level query interface for all objects. ResultSet Services: A performance optimization in is Just-in- Time (JIT) object instantiation. This pattern is also called lazy instantiation in the Java world. JIT is the set-based access service that returns CUSTOMER data rows to the presentation-tier as highly optimized byte arrays. Metatdata passed with these structures allows them to be converted to numbers, strings, and dates in the client. In this way, the EJB tier need not create server objects for each row in large data collection. Results are returned in tunable buffers. Buffer management, including pre-fetching new buffers, is another service that improves network and database performance. During buffered queries, the query statement remains open with the database server, using an assigned connection. This incremental retrieval preserves both memory and network resources. In our example, the user is free to scroll around in the CUSTOMER ResultSet. ResultSet methods include scrolling to the first, next, last, and previous records as well as getting and refreshing specific rows. Other services allow tables of ResultSets to be sorted by any column. In our example, after the user selects the correct CUSTOMER, a detail page is called displaying CUSTOMER and ORDER information. This sequence uses: > PageListener Services to detect the selected customer > QueryServices to pass a detailed query for customers and orders to the next page, and > StateManagement Services and Transition Services to understand the users current position in a stack of pages and move forward to the next logical page Services used in Step 3 Displaying and updating a Customer s Orders In client applications, automatically coordinates objects in master/detail relationships. Part of the metadata of an HTML page details the relationship of the master DataSource to one or more dependent DataSources. services enforce substantial logic around these master/detail relationships. In our example, these services automatically join our selected Customer and the associated Orders at runtime. Furthermore, as the user scrolls through Customers (next Customer, first Customer, and so on), the Orders on the bottom of the page automatically scroll as well. Master/detail coordination services also extend to data inserts and updates. By default, childmost data objects can be inserted on pages. Therefore, in our example, will have constructed an Insert function automatically for the ORDER table. In our example, the user chooses to update the Qty_Ordered attribute for an Order in the Order table and presses Save. Once the Save action is detected, begins its careful choreography of multi-object rules processing. Services used in Step 4 Processing Rules and Persisting Changes The client-side save operation in collects changes indicated by the user and submits them to the Logic Server for processing. When designing an application, the developer indicates the save mode for each DataSource, either: > SAVE_IMMEDIATE mode, where all the changes on the current row are automatically saved when the user changes the currency of the result set (scrolls to the next Customer, for example); > SAVE_BUFFERED mode, where all the changes on the result set are saved when the user clicks a button with the action db_save. provides Transaction Buffering Services to increase performance by combining multiple client updates into a single transaction , Inc. All rights reserved.

13 When the Logic Server receives a batch update message from the client, the message contains both the new and previous values of the rows being updated. uses previous values to support Optimistic Locking Services. To preserve database concurrency, s Optimistic Locking Service retrieves data and displays it to the client application without locks. As clients update data in the ResultSet buffer (subject to security controls), maintains both old and new attribute values. When a transaction begins, the old attribute values are compared to values newly refreshed from the database. If the refreshed values differ from the originally retrieved values in the result set, the user is notified that the Object is dirty (has changed). The user is informed via standard error handling, and is given an opportunity to resubmit the transaction or retract any updates. If the refresh values are the same as those originally retrieved, the transaction will proceed. Objects are locked only for the duration of the transaction resulting in the best possible system performance. Query Base Object Mapping Services As we have illustrated, client applications can use either base DataObjects or more abstracted QueryObjects as the basis for page DataSources. Recall also that DataObjects are analogous to database tables, while QueryObjects are analogous to database views and may join several tables, exclude some attributes and calculate virtual attributes at runtime. QueryObjects greatly increase application flexibility by de-coupling the data model from the presentation layer but ultimately QueryObjects must be mapped back to base objects for rules processing and transaction processing. For this requirement, provides Object Mapping Services, Rules Processing Services, and Transaction Services. These combined services ensure that: > Updates are made to all appropriate base objects that underlie the query object and transaction boundaries are set correctly > Rules are applied to all underlying objects and are applied in the correct sequence The following describes example rules processing and transaction services: Rules Processing Services: Much of the groundwork for rules processing is laid at application deployment when the Business Rules Compiler creates Java logic in the DataObjects to implement the logic specified by the business rules. Since many rules imply cross-object logic (e.g. compute ORDER.Total before updating CUSTOMER.Balance), the Business Rules Compiler makes several passes through the business rules to graph dependencies, sequence operations, and ensure that methods will be called in the correct order. Some of the business logic in DataObjects is relatively simple, such as setting the default values specified in rules. Other business logic is more complex and implements methods to set formula values, check constraint rules, and enforce referential integrity between objects. Fundamental to all this logic are some basic interfaces, including those that: > Listen for and take actions on RuleEvents. These services are exposed as a programmable event model available to the developer as a way to customize object behavior > Handle exceptions and automate error messages during rules processing > Package transactions for the XDA Data Access Layer (for persistence) Some of the most sophisticated rules services are provided for changes that must be propagated across multiple business objects. These services understand the nested scope of execution and re-execute rules at each nested level. Consider the following example, which comes from the sample repository. The sample includes three objects: CUSTOMER, ORDER, and ORDERITEM. To compute the CUSTOMER.Balance attribute: > First the ORDERITEM.Total must be computed by multiplying the quantity by the price, > Second, the ORDER.Total must be computed by summing ORDERITEM.Total attribute for all of the ORDERITEMS 2001, Inc. All rights reserved. 11

14 > Third, the Customer.Balance can be computed by adding the ORDER.Totals for his ORDERS Normally, processing for the Customer.Balance rule is completed in three However, more complex nesting can occur. steps (nest level 3). A rule can be written, for example, that applies a 10% volume discount to all order items under $50 in any ORDER that has in excess of 100 ORDER ITEMS. Processing this particular logic would require five nested steps. > When an ORDERITEM business object (nest level 1) adjusts an ORDER so that the 100 ORDER ITEM condition is met, the discount is replicated from the ORDERS object (at nest level 2) back down to the ORDERITEM object (which is re-entered at nest level 3). > After necessary calculations are made to each ORDER ITEM under $50 (using a conditional formula), the ORDERS Total Amount would need to be recalculated with another parent adjustment (nest level 4). > Finally, the CUSTOMERS account balance would be adjusted again (nest level 5). After each of the nest levels is completed, the business logic unwinds like function calls being popped off of a stack, until the transaction is completed back at nest level 1. This helps illustrate why some of the most unique services concern rules processing. For its objects, automatically: > Calculates the scope of the transactions (e.g. around the entire parent/child/child relationship); > Registers each connection on behalf of the user (thread) and issues calls on the connection to bracket the transaction; and > Leverages other facilities, such as those for connection pooling or two-phase commit, when available.. Transaction Services: Like many services, the underlying implementation of Transaction Services depends on the functionality of the application server which hosts the Logic Server. On the EJB platform, by default, uses the Java Transaction Services provided by the IBM WebSphere or BEA WebLogic application server. basic data access service is through highperformance local access by the Logic Server to Java classes under its control. has written its bean-managed persistence using the JTA (Java Transaction Services API) , Inc. All rights reserved.

15 , Inc. 300 Lakeside Drive, Suite 1500, Oakland, CA USA web toll-free ph fx United Kingdom Parkshot House 5 Kew Road Richmond Surrey TW9 2PR England ph +44 (0) fx +44 (0) France avenue Hoche Paris France ph +33 (0) fx +33 (0) Germany Flughafenstr. 52 D Hamburg Germany ph +49 (0) fx +49 (0) Forumstr. 24 D Neuss Germany ph +49 (0) fx +49 (0) Steinheimer Str. 117 D Seligenstadt Germany ph +49 (0) fx +49 (0) , Inc. All rights reserved., Logic Server, and Studio are trademarks of, Inc. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All other company and product names mentioned are the trademarks or registered trademarks of their respective companies. 06/01 USA DESIGN: