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.
  • Michael Hall and Brian Proffitt from "The Joy of Linux"

    As it was, I wasn’t aware I’d set foot in the middle of one of the bloodiest and most protracted battles ever fought in the UNIX world, so I replied in kind. Vi, I argued, is for masochists and lickspittles on some sort of bizarre kick that causes second-year college students to run away to monastic cults until they get tired of eating porridge and sweeping the floors with rush brooms that are too short. Emacs, on the other hand, is a comfortable tool meant to be used by people who want a hand in personalizing the text-editing experience, the most important thing a real UNIX user ever does. People who use vi, I posited, are backwards and probably use the word “new-fangled” while they tug on their suspenders.
    from - "The Joy of Linux"

    Transaction Processing: Concepts and Techniques

    "There are many examples of systems that tried and failed to implement fault-tolerant or distributed computations using ad hoc techniques rather than a transaction concept. Subsequently, some of these systems were successfully implemented using transaction techniques. After the fact, the implementers confessed that they simply hit a complexity barrier and could not debug the ad hoc system without a simple unifying concept to deal with the exceptions. Perhaps even more surprising, the subsequent transaction-oriented systems had better performance than the ad hoc incorrect systems, because transaction logging tends to convert many small messages and random disk inputs and outputs (I/O) into a few larger messages and sequential disk I/Os."