(I missed the start of this talk as it clashed with another but had background from talking to Vincent last year at ESUG.) VAST rule-driven insurance system. User supplies data (e.g. on web), data sent to model, model fires rules, rules determine what offers and further questions are now asked user.
Rule systems of this complexity are intractable although much checking can be done. Example:
- User asks car insurance, system takes no special action
-
- User identifies as sports car, system offers special cover, related offers
Instance variables seemed not well suited to capturing these relations (e.g. roles: did this person own, insure or steal the vehicle? :-)). Thus they built a system that modelled object nets generically and dynamically: <aPerson> owns <aVehicle>, <aCover> insures <aVehicle>
They have put their meta-modelling stuff on-line, not for commercial use but for study. Vincent overviewed how it handles relations, roles, etc. They have a path: navigation algorithm that walks over relationships to find things, so self path: insuredObject might start at a FireCover, work to a comprehensive cover, then to an insurance, thence to an insured car.
Data driven rules systems have complexity traps. Firstly, what language should be used for rules? If you don't use Smalltalk the product design department might be happy with some domain-specific language but the interface problem will be costly and changing as new features appear. So they chose Smalltalk and provided a graphical interface to help business users. Secondly, the rules and attributes differ in each specification so how to model methods and instances. They modelled dynamic Smalltalk. They could have specified them as strings and use the runtime compiler but it is 10 times slower than anything else. They could have made parse trees executable but that is very dialect and dialect-version specific. So they pre-compile to simplified parse trees (by sending precompile to constructed expressions). They have a 'Smalltalk in 12 easy classes' framework (BlockExpression, Assignment, VariableExpression, etc.) with which they can build smalltalk on Smalltalk. (I was reminded of Michel Tilman's similar framework for VW, in the Zork-Analysis package.)
Vincent showed how this worked in a simple example, building up a simple parse-tree-like object graph running to completion (detailed examples on slides). It runs 30% slower than native smalltalk. They use this to build dynamic classes with dynamic attributes. They chose to make using the framework quite distinct from using native Smalltalk. By contrast, I tend to make them the same, as does e.g. Michel Tilman in his Argo framework. So Q. Why not use DNU to integrate static and dynamic? (Much discussion ending with) if Vincent were the only programmer he would want this but as they have a turnover of people, often less experienced smalltalkers, he sees much value in forcing them to call path: to get a dynamic method to work on an object, so they don't get confused between static and dynamic.
Dynamic expressions and semantic nets worked well for them. They found writing the compiler for it was the hardest task. SmartPVS uses 100 business classes and there are 2000+ dynamic classes for their insurance products. Most of these are linked and putting it in a diagram is unusable (too large) so must be managed otherwise. They are stored in normalised tables in the DB (since 1994). DB2 COBOL (with a decent DBA) handles this fine. Since they don't want 2000+ changing tables, they hold the data in a meta-schema: a table for classes, a table for relations, a table for data.
They have data-driven security: they enable which actions the user is allowed to do based on their profile (a dynamically-modelled object just like their products). SmartPVS sessions can be long-running and may be reactivated or abandoned. They recognise a client from the IP address if they are on the intranet, or by object identity but that is performance costly. They are careful to configure each session and attach data to sessions to avoid mix-ups. SmartPVS offers a transaction per main business object, e.g. each partner and each contract mentioned in a session would have its own transaction. A single transaction for the session would be too restrictive; the user would like to work on a contract and e.g., add another vehicle then abort that without aborting the whole contract, to which they may have spent time adding data. SmartPVS has full responsibility for data quality: every host call to the DB is just commit or abort.
They communicate with the database via MQ (he skipped the example for time reasons; it is on the slides). From Smalltalk, he would rather use XML protocol. From COBOL, they could not find the right tool. They looked at tools that convert existing DB WS stores to XML but all the tools 'nearly work' (e.g. one had a convert-EBCDIC-for-numbers problem, another had another problem, etc.) so as they just had 50 calls they wrote them by hand. From an interfacing point of view, code generation is static so not ideal.
Lessons learned: do not put business logic in interfaces or have transactions across system boundaries. Use the Bart Simpson pattern over RMI and MQ. Use active rule systems with dynamic GUI. Use business objects as the anchors of your transactions. Marry OO graphs to normalised DBs.
Q. Download costs? The performance is like opening a 15-page word doc over the net, so its no problem for the system's acceptability. (Server start time is minutes as it reads all the meta-data but the users doesn't see that.)
Q. Resynching deltas? They use data-propagator (IBM tool) and almost never see a problem. The user can explicitly request a reload but they find the system very robust. On-line over wireless (narrow pipe) means they will keep this feature, otherwise they might be prepared to drop it. Deltas are checked coming back and if there are any problems then it is checked (e.g. sometimes someone makes a claim before their policy is complete!)
Q. Your dynamic framework is only 30% slower than Smalltalk; is that surprising? We certainly were, but the figure is reasonably verified.
Q. DB / OO understanding? They were very lucky in their original DB designer who was smart enough to understand the whole system and create a good (meta-oriented) schema.
Discussion: they find having VAJ in a shared Envy repository with their Smalltalk incredibly convenient for having a lightweight cross-testable Java front-end to their system connected via RMI. They don't want to lose that (so are a little concerned about IBM's WSAD enthusiasm). I mentioned Sandstone with their tiny VAJ wrapper to their VAST system; Sandstone don't care whether VAJ evolves or not since it exists and can wrapper them (and, being old and lacking latest Java features means it will work on all browsers, the old ones as well as the latest versions).
Previous Topic
