Speaker

Arno Schmidmeier
AspectSoft

Arno Schmidmeier is CTO and founder of AspectSoft, a consulting company focusing in aspect oriented software development, service level management (SLM) solutions and enterprise application integration (EAI). Before founding AspectSoft he worked very successful as Chief Scientist at Sirius Software, where he was responsible for the commercial adoption of new technologies like AOP. During this time he and his team deployed several mission critical SLM-projects based on AspectJ. Three of these projects have been awarded at the TeleManagement World 2001 in Nice, 2001 in Las Vegas and 2002 in Nice. He was the first person outside PARC offering consulting services for use and introduction of AspectJ in commercial projects. He joined therefore several frequent travellers programs to fulfil his passion to teach aspect oriented software development. He represents his work regularly on international top conferences. He was the co-organiser of the AOSD Commercialisation workshop in Boston this year. And finally he served the Java community as an independent member of the expert team during the JSR 90, "Quality of Service API". Arno spends most of his rare spare time with his wife Eva and their daughter Sophia. If he can afford the time he loves to play some games of blitz or tournament chess.

Presentation: "Why do objects have to care about persistence at all?"

Monday 10:45 - 11:30, Protected Room

The time comes in most projects when persistence has to be considered. Objects did not made this task much easier, even if there were plenty of different approaches and APIs starting by simple approaches, like property files and custom implemented persistence mechanisms, it offers intermediate solutions like serialisation, plain jdbc, DOM, XML schema and ends with heavyweight transactional solutions like ODMG databases, object relational mappers, JDO, EJB, etc.

All of these APIs have one thing in common: the objects deals themselves with persistence, collaborate with persistence subsystems, or have been designed having a specific persistence subsystem in mind. But business objects should not need to know anything about persistence. Why does an account object have to know that it is going to be stored in an relational database? How do developers and architects react, if they recognize that two subsystems are to closely connected. They simply decouple both systems as far as possible.

This talk analyses why the current tight coupling of persistency and objects is the problem, and how to decouple objects and persistence APIs. It presents a successfully applied solution based on aspect oriented programming. It explains some requirements from this approach to persistence subsystems, and looks how some of the mentioned approaches fit to this scenario.

Why do objects have to care about persistence at all? - (slides)

Please notice that the slides are password protected. You should have received an e-mail containing the required username and password.

Presentation: "Introduction to Aspect oriented programming with AspectJ"

Tuesday 14:00 - 14:45, Private Room

Modern distributed component computing and its platforms like J2EE and .NET have found its way into quite a lot of projects. They remove the burden of architecting, designing and implementing non functional core requirements like transaction handling, persistence and distribution. Combined with modern programming techniques like refactoring they promise an unexpected level of software productivity.

Unfortunately they fail in implementing the remaining non-functional requirements in a modular way. Problems like tracing, logging, synchronisation, caching, pooling, auditing, security and exception handling, just to name some of them can not be modularised. Even worse it is hard (if not impossible) to implement business functionality, which capture business rules, in a modular way in most architectures.

The results are source code fragments, which do belong to one functionality (and of course it should be stored in exactly one module), but these fragments are spread out through the whole code base. This has several severe impacts on the software development process:

• It reduces the reusability of components, because they are often limited by non functional limitations, which are not defined by the problem domain (e.g availability of a specific logging API, some security/ auditing constraints, etc. )
• It reduces the productivity of the developer, because they cannot focus on just one requirement, but they have to implement totally different requirements at the same time.
• Developers must manually insert redundant code in plenty of places, just to fulfil company policies for some major non functional requirements. This boring and expensive manual task, makes it hard and costly to maintain and evolve the code base, because simple and necessary changes can not be performed in a single place.

Aspect oriented software development (AOSD) is the next programming paradigm, which eliminates these problems. The current focus of AOSD is on aspect oriented program (AOP). Early adopters from research and industry have gained great productivity improvements with AOP. MIT considers therefore AOSD as one of the 10 technologies for the next 10 years.

This presentation explains how AOP works, and AspectJ can be used to improve existing Java based programs or how to write new programs with improved quality

Introduction to Aspect oriented programming with AspectJ - (slides)

Please notice that the slides are password protected. You should have received an e-mail containing the required username and password.