All entries for Thursday 15 June 2006

June 15, 2006

SpringOne day one wrap–up

So, day one is over. Thoughts:

1) Some of the new stuff is pretty cool. Hooking up with AspectJ was definitely a smart move, and the AOP stuff both in 2.0, and planned for 2.1, is really making AOP more accessible to the 'average joe'

2) We (elab) seem to be ahead of the curve as far as DDD/Rich Domain Models are concerned. People are talking about it as if it's the latest thing, but we've been doing it for at least the last 18 months, arguably longer. There's no doubt that AOP can make it easier, but it's far from essential.

3) Using a multiplex as a venue is a cool idea. You can eat popcorn whilst listening to presentations!


session 7: practical Rich Domain Models

this presentation started out quite good, but the longer it went on, the less I suspect that the presenter has implemented many real RDM apps)

  • Anemic domain == not cost–effective; no competitive advantage
  • Rich Domain: Persistence is a secondary concern
  • challenges: Use RDM in a 3–tier architecture; leverage existing domain modelling skills; capture domain expertise
  • goals: Manage complexity of domain and of software; improve test strategies; make refactoring possible
  • prerequisites: Compexity – not worth it for a 2–month project. Investment + skills; committed team; compatible process; access to domain experts (I am not sure I buy this; most of these are sucess factors for any projects but none of them are essential)
  • separation of concerns (layered architecture): importance is appreciated but is not well understood in the field (is it possible to have SoC without a layered architecture? I think maybe)
  • You can't managed complexity with design patterns alone.
  • Encapsulation is fundamental. Getters, and especially setters are eeeviilll. Enforce class invariants; don't expose internal state.
  • Immutable classes: instead of changing object state, create a new object with the changed state and return that. (n.b. that private fields are accessible from other instances of the same class). Good example: java.lang.String – methods on it all return a new string. Dramatically reduces the complexity of large, modular applications, though it's probably overkill on simpler apps
  • Entity classes are generally mutable (often a requirement of the persistence technology) , though you can use immutable classes and use the EntityManager / Session merge() method to reconcile changes. This doesn't work with immutable items in immutable collections though
  • Aggregate objects: Don't expose the aggregation, and don't be mutable.
  • Rich domain models are very testable – easy to mock and amenable to TFD
  • Don't let your tests be longer than 15 lines (!)
  • lessons learned: ORM – tools will impact the deisgn (availability of immutable entity semantics). Always use field access; Avoid LazyInitialisationException (OSIV is not the answer – alternatives include AJAX*, use fetch joins; use eager loading)
    lessons learned – MVC – binding generally requires untyped setters (though spring binding + propertyEditors will avoid that)

* that's a stupid recommendation; each ajax call will increase the latency of your application: L~N(ajax–calls)


Session 6: Statefull Web Control Flows (SWF)

4 parts to each request

– constant URL ( I wonder if we should stop using a query param to identify the page to operate on)

– task execution key – identifies instance of flow to execute

– event ID – outcome of current step

– task input – data needed to continue processing

Implication of having a single URL: Clients (i.e. HTML) has no knowledge of it's position in the flow. form's ACTION does not affect where the flow will progress to next


Session 5: Spring + JPA integration

[Rod Johnson]

(Rod Johnson sounds just like the 'dead ringers' version of Rolf Harris, which makes it harder than it should be to take seriously :–))

Why

– make it possible to switch providers – plug the gaps in the spec

– make it simpler to use JPA

– will be the main focus of Spring's ORM support, going forwards

How

– instrumentation of classes – either done at compile–time or at load–time; load–time is a big performance hit; compile–time is a pain for testing. Spring 2 has a LoadTimeWeaver which is class–loader scoped, either using it's own custom classloader, or ussing weaving capabilities from Oc4J, Resin, or Weblogic where available.

– Custom EntityManagerFactories – Local and Container contracts . Since spring is doing all of the container's work, it makes testing very straightforward.

JPAVendorAdapter and JPADialect to facade away the bits outside the spec

– spring injection of EntityManager, or JPA–style injection, or JPATemplate
– Exception Translation either through JPATemplate or via AOP, if you mark up your code as @Repository (== 'class is a DAO')

– AbstractJPATest – super–easy–to–use test superclass for JPA integration testing
When

– right now (spring 2.0)

– spring 2.1 – leverage load–time weaving, add criteria API abstraction, other cool stuff


Session 4: Enterprise Development with JPA

[Patrick Linskey / Mike Keith]

blah blah; JPA is a lot like hibernate. Two of the worst posible examples for mapping inheritance person<={employee, customer} , animal<={land animal, air animal} (can't employees buy stuff? What about penguins and sugar–gliders) :–)

There are a couple of slightly ugly–looking features in JPA that the 'enterprise–ness' foists on you, like forcing optimistic locking version numbers into the bean – great if you do intend to use detach/re–attach semantics, a pain if not.

Some EJB persistence providers will auto–detect annotated classes from a JAR, so you don't need to declare anything about which classes are persistent outside of the classes themselves. This could be really cool, if it's sufficiently fast


Session3: AOP and Domain Driven Design

Contention: You can't do full DDD without AOP

DDD is about moving away from database–driven design and towards an object model with is a meta–language for the problem domain

Itegration services (email facade, report generator) == good ; technical services (AccountingService – providing TX + Audit to Accounts) == bad
AJ gives us a (nother) way of injecting services onto POJOs when they come out of persistent storage; has the advantage that it can also DI on construction and/or deserialization

neat semantic trick; given Order and OrderLine classes, have a method Order.with(product, quantity) to

add a new OrderLine and return a reference to self, so you can say

customer.addOrder.with("widget",2).with("gadget",6),with("sprocket",7)

Example of Domain AOP: associating failure behaviour (retry or check credit history) with domain objects – have a set of aspects which encapsulate the behaviour, applied to the order object (which need not contain this logic). I guess this would be OK if your whole team and your development process was AOP–friendly.

refactoring towards DDD: move logic from service layers into domain objects; move crosscutting concerns into aspects. Finally remove the service layer itself. If there's still logic in the service layer, look for missing domain objects


session 2: spring AOP

[Adrian Colyer]

– spring AOP can be applied either using xml config (optionally with the [aop:] namespace) or using @AspectJ apsects
– spring and AJ are still separate projects, but spring now uses the AJ pointcut paser/matching API not using the weaving engine / compiler
really simple to advise beans being instantiated via the container.
– Lots of really good examples. I hope we get access sample code
– AJ can do pretty smart code inspection to generate warnings and errors about code usage.
– jMon profiling library – easy to integrate with apsects around methods to be profiled.
– migration to AOP: start with spring OOTB AOP (e.g. transactions), then add custom spring AOP, then use AJ for enforcement/inspection, then intfrastructure with AJ, finally domain aspects with AJ


springone keynote

It's the conference season again. I'm in Antwerp for SpringOne, a developer get–together for users of the spring framework. I'll be blogging key points from all of the sessions I attend, battery permitting. So to begin; Rod Johnson's keynote.

– Rod's intro section is largely bog–standard 'rah rah rah for spring'. However, he then bought on the IT director of VOCA (BACS as was) talking about their experience of using Spring for totally mission–critical software (i.e. the UK banks clearing house). Writing code for handling 100,000,000 complex transactions in a 4 hour window with no failures. It's impressive to hear about how the technology's being adopted in such a conservative and risk–averse environment.

Rod then goes on to talk about how BEA are building on spring 2 to provide their JEE5 implementation. (pitchfork), then the 'what's new in spring 2.0' highlights – simplified config, AOP, web flow, simplified transactions, IL8N, and JPA.

Support for dynamic JVM languages (groovy, jruby, etc) looks pretty cool – define a bean in jRuby, and spring will let you use it just like a regular java class, except that it will also allow you to periodically poll the script for changes and bring them in at runtime – auto–redeploys ahoy :–)

Then onto Adrian Colyer, who talked a little bit about AspectJ AOP (good) vs JEE5 AOP (bad), then goes onto spring post–2.0. Spring 2.0 is the launchpad; the set of foundation abstractions, but there's a lot more to do. Moving towards a more rails–ish environment with an emphasis on convention over configuration, rolling out support for profiling and instrumentation and looking at reducing time–to–refresh in development. Also operational enhancements to make it easier and more productive at runtime – including OSGi support for module replacement, and SCA support.

On a side note, the keynote is held in a cinema, with comfy seats and THX sound, which would be totally cool were it not for the fact that the aircon is shot and the temperature is about 70 degrees C.


Most recent entries

Loading…

Search this blog

on twitter...


    Tags

    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXX