Thursday, November 09, 2006

[Event] The last day at the W-JAX

Today was the last day at the W-JAX.

Beginning with the session concentrated on ESB - Enterprise Service Bus. The speaker (Wolfgang Frank, Michael Kloss) discussed about the concepts and usage scenarios of an ESB. They also mentioned that many people think that ESB is SOA. That's wrong, ESB is not SOA. An ESB provides a central communication plattform for components, by providing entry points, different transport protocolls and more. After providing an overview of an ESB the speaker explained the concept of JBI (Java Business Integration). JBI provides a PlugIn mechanismus by defining:
  • Interface
  • Communication ways
  • Messaging
  • Management
  • Deployment
This session closed with a live demo of the OpenSource ESB ServiceMix.

As architecture is one of my main interests I attended the session about How to avoid the architecture breakup in projects. It is distinguished between a structural and technical architecture in software systems:
  • Structural architecture, describes how the software system is structured (components, interfacs,..)
  • Technical architecture, describes with which technology the architecture is build
Many software systems know the Big Ball of Mud Pattern. To avoid such a breakup it is necessary to expose your code to daylight, by using:
  • Code Reading
  • Defining Rules (naming conventions, exception handling)
  • Define metrics
Current software projects often miss the architecture layer. Special architecture tools help to create this absence layer. In order to manage the architecture, these tools need an abstract architecture (subsystems and their interfaces, rules) . He also mentioned that the layered architecture is the most common style. The plain layered architecture is often not sufficient in real projects. Therefore combinations of layeres are used:
  • Process and library layered model
  • Vertical slices
  • A layer is further refined into layers
Then the speaker discussed classical architecture smells:
  • Cycles
  • Duplicated code
  • Size of the code modules
  • Coupling
  • Unused code artifacts
  • and more
To avoid such smells it is necessary to introduce an architecture management. But many companies (management) do not attach importance to this area. Tools for architecture management support:
  • Architecture Analysis
  • Understand code basis
  • Reengineering Support
This session shows that architecture management is an important process in current and future software projects.

Spring, Hibernate, JSF or Maven are defacto standard technologies in current software projects. The session Architecture Magic with Maven, Spring & Co illustrates how to built the technical archicture with proved technologies. He mentioned that many companies do not know their architecture, when you ask for it. The only thing is: "Hmm, we use Spring, JSF and Hibernate, is it not the architecture?". Technology is not architecture! Technology can be used as MetaData for the architecture. Then said something about Enterprise Java Next Generation (EJNG):
  • DI/IOC/DRY/POJOs
  • Lightweight Container
  • Ajax
  • J2EE without EJB
  • Testing, Continuoius Integration
Technologies are often difficult to integrate in a suitable way. Often developers must set up bridges to integrate two or more frameworks. The session ends with a little live demo, showing how to make a technical architecture with Maven & Co. Therefore Maven is an ideal canditat to manage:
  • Dependencies and their scopes
  • Deployment of artifacts
And Spring is a good choice to integrate the components at runtime, by using Dependency Injection and the like.

The last session Patterns for asynchronous messaging gives me an overview about messaging with JMS. Adam Bien illustrates problems when using messaging (Point-To-Point, Pub/Sub). The most difficult thing with messaging is the exception handling and recovering. Here he pointed to the "Dead Lacking Queue" where messages are saved which are not arrived their destination. It is important to know, that JMS is not suitable for every software system. Software Architecture must make a trade off between decoupling and performance. Also the test of a system using messaging becomes more difficult. Adam presented the following patterns:
  • Fire and Get
  • Broadcaster
  • AP (Asynchron Reply Response)
  • Observer - Observable
  • Pseudo - Observeable
  • Pseudo Synchronous
  • Thread Imulator
  • Concurrency Control
Adam Bien was my favourite speaker on the W-JAX, because he presented at a high level of competence.

3 comments:

James Strachan said...

BTW the DLQ term is "Dead Letter Queue"

sascha frevel said...

think this must be 'fire and forget'...

Markus Demolsky said...

thanks for your hints