If you remember one knowledge pearl about business rule engines, i think you may want to remember the relationship between rule engine and rules. I think these are the 2 main entities to *deploy* to an ent app.
Verizon’s circuit fault-isolator is a typical enterprise application using JRules. Think of your ent app as a host-app (or user or caller) of the rule stuff. There are quite a lot of rule stuff to *deploy* and you will soon realize the 2 main thingies are the (A) generic rule-engine and (B) your rules.
– The rule-engine is written by ILOG (or JBoss or whoever) but the rules are written by you.
– Rule Engine is a standard, generic component but the rules are specific to your business.
– The rule-engine is first and foremost the interpreter of your rules
* a good analogy is found in XSL transformer vs xsl stylesheet. Your host application need to load both of them into memory
* A similar relationship exists between spring the framework and the spring-beans you create.
You may be tempted to use
Top drawbacks, ranked
1) when complexities increase, ultimately the code maintainer will have to consider dropping -p switch and putting in a visible while() loop. Quite a few changes and lots of testing.
) what if u need to write to multiple files?
) inflexible — logic before/after the loop must be put in the BEGIN/END blocks
) the LINE label is invisible and confusing to some readers and maintainers
I think -p and -n are probably designed for
B) scripts without growing complexity
C) scripts without other maintainers
Background: when applying design patterns to your business logic, you need to describe your business-logic using domain object names (example? no)
For an Object A to get access to Object B, there are some extremely common patterns, ranked in terms of /incidence/ (ie how common they occur):
* A.method1 receives an \\arg//B
** A.method1 receives an \\arg//Y which is a collection containing B
** A.method1 receives an \\arg//K with a getter returning B
* A calls some method that returns a B 
** A calls some method that returns a collection containing B
** A calls some method that returns a D with a getter returning B
* A makes an explicit call to new B()  . Common
* A “knows” B from birth — A’s constructor initializes an instance variable to a B object
 and invariably saves it in some instance/method-local variable
 or new C() which connects to a B via a collection or getter
 Longer version: A.method2 (usually interpreted as a behaviour of object A) calls some method (defined in any class) returning a B
J4: fundamental concept for design-pattern. This could be a simple concept, but it’s important to be thoroughly familiar until you can spot the pattern without thinking.
A method call  usually has a primary  “customer object”, ie the object to consult, to enrich, to read or to modify. This object can be
– the call’s hosting object. eg: student.setAge()
– the call’s argument object. eg: increaseCreditLimit(customer)
– the call’s initiator object. eg: this.amount = product.discount();
– some other object. eg: remoteControl.setCommand(TVon); # TVon object has-a TV object, which is the customer object.
For each method call, You need to quickly spot the customer object when you communicate with other people. Communicate during design, documentation, coaching, …
 rarely 2.
 we are talking about a call, not a method. Only when you use the method in a business logic can you put your finger on the customer objects.
You want to see the exact timing data such as time of the day, etc.
Apparently, you can see it on a Box, not a Command.
When creating a job, you can specify the timing and system won’t complain! If you can’t see it later, then you can’t verify — perhaps the timing data is lost, silently.
Autosys trainer said yes you can have a /top-level/, /standalone/, /boxless/ command job with it’s own timing.
Thanks for your 3 reasons. They sound very similar to the undoings of many other dotbombs of the era.
I feel funding often follows sales “results”. Investors (if you had them) are business people — business people look at results.
As to customization, I am no expert but would still put forward my 2 cents — many successful ERP/CRM packages didn’t initially offer a lot of customizability but still attracted enough customers.
I studied Mambo and sugarCRM (all claim to be customizable) in some details, as a developer and not a businessman. I think they are modular, extensible, plugin-friendly, with many skins, with hundreds of configurable parameters, but still show rigidity as soon as you try to get it to work “your way”. My experience with sugarCRM is, if I try 10 potential customers, at most 1 can manage to get it to work “his way”. Of course, the success rate could improve if I figure out more ways to be creative with sugarCRM. (drawing a subway map with spreadsheet?)
I think the key with this customization challenge is finding a special type of customers who don’t ask for customizations. I think you know what I mean. Each HR software was initially designed for a specific subset of companies. Because it’s designed for them, they don’t need customization. The next bigger circle of customers would need some but hopefully minimal customization.
“With our laser equipped, rechargable, transparent, odorless mouse trap, what homes should we target?”
On 10/28/07, Raja wrote:
> The company did not survive for 3 reasons
> 1. We were late to market. Not enough sales with all the competition.
> 2. Each of the customers wanted a lot of customisation to the base product –
> the technology and the framework we had at that time was not agile enough to
> adopt. We are talking about the early J2EE days 🙂
> 3. There were some funding issues also.
Justification: jargon. In a non-trivial enterprise app documentation, usually there are too many (hundreds) jargons for an uninitiated reader. Wiki can help. Let’s look at an example. Under generous assumptions, every time a document mentions “Price Spread”, this word will become a hyperlink to the wiki page for this jargon.
Justification: linking. linking up hundreds of related topics.
Justification: Easy update. Everyone can update every wiki page, without approval.