1. ejb-jar.xml
   This deployment descriptor contains:
   
   • (a) Entity Mapping
     Example:
     Content
     org.picola.delibra.cms.persistence.ContentHome
     org.picola.delibra.cms.persistence.ContentEntity
     org.picola.delibra.cms.persistence.ContentEJB
     Tip:
     Since our beans are local and the home interface extends EJBLocalHome, we need to specify local-home and local.
     
   • CMP-Field declaration
     content
     primaryKey
     resource
     Tip:
     In the implementation each cmp-field is required to have both a getter and a setter method, and each accessor must be declared abstract
     
   • EJB-REF
     Declaring an ejb reference: I have declared an internal EJB reference since ContentEJB is in the same application (same jar file) as MetadataEJB.
     Example:
     <ejb-ref>
     <ejb-ref-name>local/Metadata</ejb-ref-name>
     <ejb-ref-type>Entity</ejb-ref-type>
     <home>MetadataHome</home>
     <remote>MetadataEntity</remote>
     <ejb-link>Metadata</ejb-link>
     </ejb-ref>
     
   • Finder methods
     All finder methods are handled by the container. To implement a finder method you need to make an entry in this file (exception is the findByPrimaryKey method)
     Example:
     <query>
     <query-method>
     <method-name>findByKey</method-name>
     <method-params><method-param>java.lang.String</method-param></method-params>
     </query-method>
     <ejb-ql>
     <![CDATA[SELECT OBJECT(g) FROM metadatakey g WHERE g.key = ?1]]>
     </ejb-ql>
     </query>
     
   • CMR: Container Managed Relationships
     I have defined two relationships:
     - Content and Metadata: 1 to many
     - Metadata and MetadataKey: 1 to many
     Example:
     Search for <ejb-relation> ... </ejb-relation>
   • Container managed transactions
     You need to specify what transactions the container will manage
     Example:
     Search for <container-transaction> ... </container-transaction>
2. jboss.xml
   The container defines default JNDI names like: local/Content
   Here you can define custom jndi names that will over-ride the default ones
3. jbosscmp-jdbc.xml
   CMP-Field Column Mapping
   The mapping of a cmp-field is declared in a cmp-field element within the entity. An example cmp-field mapping follows:
   <cmp-field>
   <field-name>primaryKey</field-name>
   <column-name>ID</column-name>
   </cmp-field>
   

• What is a rules centric approach to automate validation of business rules? Research ways in which business rules and related processes can be separated from application code
• Study the role of XML as an integration technology in a rule based system. In particular determine how XML objects are used to define business rules
• Rules Engine UI for the non-programmer: develop a prototype to demonstrate the representation of rules in a user friendly format

• The independent study will produce a software prototype and a research paper that will cover all or a combination of the above mentions topics. This paper will be written with the goal of submitting it to an IT journal (e.g. the Enterprise Application Integration journal)
• Develop a prototype representing the UI of the Rules Engine. The scope of the prototype is limited to the demonstration of an intuitive UI to represent rules

Critical business processes are bottlenecked by costly, inefficient manual procedures that are too difficult to automate using conventional applications. Existing enterprise systems are unable to change to meet the evolving needs of the business. The results are increased costs, missed business opportunities and declining customer base.

This is where Business Process Management plays an important role. BPM systems take out the complexity of automating business processes. Furthermore BPM is a software system that streamlines business processes by integrating them with existing systems.

The underlying framework of a BPM solution is a Rules Engine where the business rules can automate human decision making while leaving the existing enterprise infrastructure unchanged. A rule driven BPM system uses business rule engine technology to drive the business process. The main advantage of such a system is that a business analyst can go ahead and model the process by defining business rules rather than wait for a developer to code the logic of the task.

As stated in the earlier section, there are many commercial rule-based engines in the market such as Advisor, Haley’s, and Jess. These products come from the Artificial Intelligence arena and thus are designed for highly inference based situations. The applicability of such rule-based engines in enterprise information systems is not suitable as their capability often exceeds the business requirements.

I believe that a simple rule-base engine that runs on an event-condition based paradigm is strongly suited for enterprise information systems. Examples can be drawn from this paper: Prototype 1 and Prototype 2. Both these prototypes are based on an event-condition based paradigm. They are programmed using Java, XML and XSL and not with JESS or Prolog that are based on a inference methods like forward chaining and backward chaining respectively.

The tradeoff of using rule-based systems using the event-condition paradigm may involve too excessive maintenance. However, such maintenance is necessary and unavoidable because business changes continuously and thus rules need to be updated. Does this mean that the development cycle of the rule-based engine will never end? The answer is that the development done by the programmer will end and the business user will take over. By providing a comprehensive User Interface with tools to create, modify and delete rules and to model decision trees, a rule-based system can evolve with changes in business.

Rule-based programming is widely used in the insurance and financial services industries where complex criteria needs to applied to large amounts of information. In the Artificial Intelligence field Knowledge based systems are a well known research topic. However, these systems have not been widely deployed in corporate information systems. A main reason may be because these systems depend on pre-built large domain bases to work. Creation and maintenance of these domain bases requires a large commitment of resources and time. Such a commitment is hard for companies to make. However, this is where rules-based systems come in. Deployment of Knowledge based systems without an exhaustive domain description is feasible. The domain description can be incrementally built using condition-action rules. Business rules are in fact small pieces of knowledge about a business domain. The only issue with such rules is that they are widely scattered by different applications, often replicated and usually hard-coded. Thus they can end up being not reusable. A business rules architect can work around this problem by creating a business rules framework that can be used globally in all systems of a company.

This study has shown us the benefits and scope of a Rules Engine when applied to business. A growing trend today is using rule-based technology for Enterprise Application Integration. Today, most EAI vendors have rules capabilities that are either too simple to use or too complex to implement either directly or indirectly.

The business user of tomorrow needs to focus on finding a solution that has all or most the following attributes:

• Ease of use: GUI interface with decision tables for the business user
• Versatility: Easy integration with other vendors
• Rule management: Central rule management capability
• Inference capability: The workflow should be able to make its own decisions
• Performance: Rules Engines need to be efficient to process large amounts of data

The bottom line is that the Business Rules Engine is one of the major technologies that can help meet the fast changing technology world. There would be substantial growth in this field in the near future.