DayTwo @ JavaOne

Jet lag is a cruel thing... I missed the Oracle Keynote this morning. I Will have to catch the web cast of that one first thing tomorrow morning. JavaOne is relentless. This is a busy day, like yesterday, but without the jet lag. The last session I plan to attend is the "XMLBeans 2.1 Java Technology Developers Perspective" which ends at 11:20 PM.

Sooo... here is the annotated schedule:

DayOne @ JavaOne

No sign of Scott McNeally today, Sad... I loved his bravado and humor. I attended the first JavaOne conference in 1996. It was like attending Woodstock. There was an incredible amount of excitement and anticipation for the platform and Scott set the tone for the week. Jonathon Schwartz is a sharp individual, but doesn't grip the room like Scott can. I know this sounds like superficial rumination, but can't help voicing my first impression of the keynote...

Anyway... on to some "real" information... This is the largest JavaOne ever, exact numbers have yet to be announced. The conference definitely feels much more crowded than last year, but it's hard to tell if there are significantly more people or that it is just due to the new requirement to register for a seat for sessions. Waiting to get in seemed silly. Event managers held up attendees while the previous session cleared. This led to long lines as people waved their RFID badges on the way in and get the green light to enter.

There is a definite push to get individuals involved in the JCP. This was repeated several times in several sessions. Maybe Sun hopes it'll feel more like open source if more individuals are involved in the JCP.

Motorola CEO Ed Zander arrived to push his cell phones and announce that Java is "the platform" for motorola's phones going forward. The industry will ship 1 billion Java devices this year with motorola shipping 2oo million of them. Ed also announced motorola's participation in the NetBeans project. In fact there were a number of announcements around new membership in the NetBeans develop community. Seem's that Sun has put a big push behind getting NetBeans viewed as a viable platform against Eclipse.

Changes in licensing were announced to allow Linux vendors to include Java as part of there distribution. In fact, shwartz stated that 60% of the PC's sold today include Java out of the box and Sun is pushing hard, working with PC vendors to include Java on their platforms.

One of Schwartz's first acts as CEO was to bring back Rich Green as Excutive Vice President of Software. Schwartz brought Green on stage and immediately asked the question.... "Are you going to open source Java?". Basically, after some banter, Green said It's not a question of When Java will be open sourced, it's a question of how."

Business Rules: A Report from the Field

I'll preface this entry by stating that I'm not a "Business Rules" expert by any stretch. I write this as one who has experienced an implementation from the trenches and who is about to dive into the deep once again at my latest account.

I arrived on a project that needed an injection of technical leadership. The project was basically a complex settlement system for a large energy market. There were hundreds of steps required to create a bill for a customer with numerous regulatory considerations. The complexity of each step could range from a simple atomic calculation to an extremely complex set of "business rules" with 10 to 15 pages of single spaced specifications. In general it was determined by the client that a business rules engine should be used to construct these steps. The goal would be to allow the business users to maintain the rules for the new system. I a'm not going to explain business rules basics, but going to assume youÂ've read the basic marketing available. This article contains the implementation experience that I pass on to you.

Business People Should Write Business Rules?

The ability for a business person to directly control the business rules, this is the Holy Grail when implementing business rules engines. The thinking here is that a visual tool can allow business users to simply "draw" a business flow. Additionally, by bypassing the Business Analyst, developer and associated typical software development life cycle (SDLC) that rules can be constructed more quickly and managed more easily. It is true that Business Rule Management Systems (BRMS) can accelerate and streamline the implementation of business rules, but buyers should understand some of the realities of adopting the technology and adjust their expectations accordingly.

It has been my experience that even the most advanced rules engine with the slickest interface requires training and, in some respects, structured thinking about how to organize and construct the rules. There are two factors at work here. First, visual rule environments provided by Business Rules Engines are not "Visio". There are structural constraints enforced during the definition of a valid visual rule flow. How long before a business user becomes frustrated because they just can't draw the "picture" they can clearly see in their minds eye.

The second issue with business users and direct manipulation of rules is rule decomposition. Rules engines that implement a Rete algorithm allow large numbers of simple rule statements to be automatically organized into a network of nodes that allow efficient execution of highly interdependent rules. Business users typically do not think in terms of rules, they think in terms of business policies.

Merriam-Webster defines policy as
"a high-level overall plan embracing the general goals and acceptable procedures"

So in essence policies are much broader than individual rules. Someone must decompose the various business policies into discrete rules and structure them appropriately in order to represent these policies in a form that can be executed by the engine. Although rules can be structured such that they can be easily read and understood by business users, rules engines are not "Natural Language" processors. They require strict syntax in order to operate. An example would be the Yasu QuickRules engine. The user interface allows rules to be entered either visually or as text that adhere to a VB like syntax. Rules that do not conform to the syntax can not be saved and therefore never executed by the engine. The product gives relatively vague error messages, so good knowledge of the syntax and operation of the engine are typically required.

So if the business person is not the most appropriate person to implement business rules, who is? We could naturally gravitate towards the programmer as an option, but my experience is that a typical programmer does not easily become an effective business rules designer. There is the natural tendency for a programmer to try and use the engine's rule language like another general purpose programming language. This usually ends in frustration because general purpose "programming" is not the goal of a rules engine and therefore can seem a poor substitute for languages targeted for the general purpose space like Java or C#.

Business rules in general should be recognized as a separate disciplinep. Special roles such as rules analyst, designer and administrator should be created. Talent for these roles can be sourced from disciplines like business analysis, software development and operations, but there must be the appropriate investment in training, mentoring and time to allow existing employees to grow into these roles. Think back to the investment required to move functional programmers to a more object oriented methodology. It took significant investment and effort for a successful transition. You can expect your results to match your investment.

Business Rules Require Facts (Data)

Business rules operate on facts.Facts are essentially the data provided to the business rules for execution and also derived during their operation. Facts are compiled, or loaded, by the calling application and passed into the rules engine for evaluation. The Fact Model is the entire set of facts that has been exposed for use to the rules engine. This model is typically constructed incrementally over time as facts are added to support new or modified business rules. The complete fact model can be developed in advance of implementing any rules, but in practice this can be very time consuming.

There are two issues that may arise in the management and transfer of facts (data) to the business rules engine. The first is version control. New facts required because of rule changes result in associated changes to the calling application. Additionally this requires that the modified application be deployed along with the new business rules. Something that we would hope to minimize as part of a business rules strategy. So in this case, the SDLC overhead can not be avoided and synchronized deployment of business rules and application software must be managed appropriately.

The second issue arises from the overhead of moving data in and out of the rules engine. Depending on the amount of data and the location of the engine (remote?), this could be a relatively costly endeavor. There are a number of engines that can execute within the same memory space as the calling application and therefore reduce the overhead of moving data between the two. But again, depending on the amount of data required it may be questionable as to whether data, not explicitly required for rule execution, should be loaded at all. Some engines have the ability to read and write application databases directly which can simplify the data movement process, but this mixes IO overhead with rule execution. This feature also removes the ability to use optimization techniques like write-through share memory caching in applications.

Business Rules Portability?

With industry support for standards such as the Java Rule Engine API or Java Specification Requests (JSR) 94, applications can be developed that can plug in different rules engines. JSR-94 standardizes the way rules engines are called, but does not standardize how rules are written. We can plug a new rules engine into an application quickly, but moving the rules between engines can be problematic. There are initiatives out there like RuleML that attempt to facilitate interoperability among vendors, but none have reach critical mass. Do not count on JSR-94 to ease replacement of a rules engine significantly.


When constructing a suite of business rules, it is important to be able to verify that we achieve the desired results. Testing all rules in isolation will not necessarily give a definitive answer as to expected outcomes. Dependencies between rules may have unexpected effects. Yes we can do "what if" scenario testing, but the real work is in defining a comprehensive set of test cases that exercise the dark corners of the rule network. This was our most difficult part of the project, generating the volume of scenarios and associated data to ensure coverage across all the business rules.

JavaOne: A Session Surfing Day

I have to admit that I surfed a few sessions today. Basically there were a number of interesting session running concurrently so I started with the most interesting and sometimes cut out to catch the tail end of another....

Here are a few:

  • TS-3513 Think MDBs Are Only for Java Message service? J2EE Connectors Demystified.

    This one would have probably been interesting if the speaker was intelligible. Incomprehensible, English as a third language

  • TS-7659 Runtime Aspects with JVM Support.

    This was an incredible session and I'll post more about it in a separate entry

  • TS-3268 Java Technology Performance Myths Exposed.

    Very informative presentation. Basically, the new JSE 5.0 features have no appreciable impact on performance... so use them. Object pooling only makes sense for very large objects that require long setup. Multi-core chips will shift some of the performance issues to lock management and require much more synchronization then most developers would expect.

  • TS-7849 Omnisicent Debugging

    A technology more for retrospectively stepping through a program run and inspecting memory. This works by instrumenting applications and recording each execution step and all memory state changes. Interesting, but sounds really slow.

  • TS-7212 Clustering, Consistency and Caching: An Implementor's View of JSR 107

    Thought this would focus more on clustering, but actually focused on caching so I bailed on this one 1/2 way through

  • TS-1073 The New Weblogic Server 9.0

    Interesting but basically a laundry list of features expected in 9.0... Think quick fly over a city, but I would have preferred a walking tour.

  • TS-7725 Java EE Ease of Development: Platform Specification and Tools Perspective

    Basically just a walk through a number of tools and how they currently support Java EE development... no insite here so I bailed and walked over to the next talk.

  • TS-3281 Finalization, Threads, and the Java Technology Memory Model

    Incredibly complex, but interesting. The bottom line here is "avoid finalizers at all costs!"

  • BOF-9385 Apt Usage of APT: When and How to Use the Annotation Processing Tool

    Compared APT to other templating tools. I walked away feeling that APT needs more work. Can't wait till this is standardized though.

  • BOF-9467 Latest Trends in Java Technology Management and Monitoring

    Waste of time... the latest trend in management and monitoring???? use JMX. I didn't need a BOF to tell me that.

  • BOF-9161 Exploring Annotation-Based Programming Through the APT and Mirror API's

    Great talk on APT usage and upcoming standardization. The BEA guys also demonstrated Eclipse support. Annotations will be real useful in a few years;)

  • BOF-9441 Practical Application of Aspects in Everyday Development

    Interesting talk about some uses of AOP. Also points out that AOP will be really practical and useful... in a few years;)
  • JavaOne: Heard at Scott McNealy's General Session

  • The most attended session on the first day of JavaOne was Java Business Integration: A Foundation for SOA
  • Sun purchased SeeBeyond this morning. Scott McNealy stated:
    This is not an example of stunt acquisition!
  • Java owns the Mars Lander market.
  • It's taken 10 years to achieve 1 billion Java smart cards on the market, but it's expected to reach 2 billion within 3 years.
  • Brazilian HealthCare has standardized on Java for the nations healthcare systems and has written 2.5 million lines of code in 4 months
  • There are 4.5 million Java technology developers and 550 user groups and 912 Java Community Process program members.
  • JavaOne: BEA Embraces Spring

    While attending BEA's general session yesterday, I fully expected that I would hear all about the proprietary features that differentiated Weblogic from the rest of the J2EE container crowd. Of course that's part of what I heard, but Chief Technology Officer Mark Carges also discussed issues that Enterprise developers have been struggling with since J2EE was first released. Mark, pointed out that the Open Source community is pointing the way to a kinder more gentle J2EE development strategy. Features like:


  • POJO - Simplify enterprise development by using plain old Java objects.
  • Dependency Injection - Support for inversion of control, where the container provides the resource instead of requiring the component to wire the resource in. Dependencies are resolved declaratively, simplifying code and unit testing. Supports test driven development.
  • Meta Data - The ability to leverage annotations for inline meta data to avoid seperate XML descriptor file proliferation.
  • AOP - leverage Aspect Oriented Programming to support seperation of concerns and simplify implementation of cross-cutting concerns.

  • I then expected Mark to announce a new BEA product that would address this... or at lease reposition an old one. But to my supprise, he announced that BEA will formally begin to support a set of Open Source Frameworks. The Spring strategic partnership is the first strategic anouncment.

    JavaOne: Heard at BOF-9213 Writing Performant WSDL

  • BigDecimal is, by default, unlimited scale. This could cause unexpectedly long string representations of floating point numbers to be transfered.
  • There is virtually no impact when moving from simple types to complex type
  • When only a small amount of xml needs to be processed in a large document, use XML attachements.
  • Error codes perform better than SOAP Faults. If your going to be throughing alot of SOAP faults, consider using error codes instead.