Srini Penchikala

By Srini Penchikala

Java Application Architecture is going through a major paradigm shift in terms of design techniques, technologies, and frameworks that are used to build and deploy Java applications. Enterprise JavaBeans (EJB), traditional Message Queues (JMS), and even Application Servers as we know them are being replaced by light-weight POJO based frameworks such as Spring, ActiveMQ, and OSGi compatible containers.

This technical session will give an overview of Java application architectures of the past where EJB's, verbose EAR files and heavy-weight J2EE application servers were the only choice a Java developer had to develop and implement Java applications to the current pragmatic architectures where the concepts like POJO's and Domain Driven Design (DDD) have become the core design and development concerns like they should be. The presentation will also include a discussion on how concerns like Persistence, Transaction Management, Application Security and Asynchronous Messaging have become the infrastructure concerns that are managed by the frameworks (like Spring) out-of-the-box instead of developers having to spend a lot of time and effort in programming or dealing with complex configuration files and deployment descriptors for implementing these concerns.

The presentation will talk about the emerging design techniques like Domain Driven Design, Domain Specific Languages (DSL), Custom Annotations, Dependency Injection (DI), Aspect-Oriented Programming (AOP) and OSGi. I will also discuss the use cases where these techniques add value to the architecture and where they may be just an overkill.

The presentation will include the demo of a sample Java application that uses the techniques discussed in the session. I will also demonstrate how these techniques can be used in different phases of SDLC phases of the application (Architecture, Design, Development, Unit Testing and Implementation) as well as post implementation efforts such as Clustering and Monitoring.

By Srini Penchikala

Even though many companies have some kind of application architecture standards, they don't usually have a mechanism to enforce those standards. As a result of this lack of architecture governance, the Implementation (Code) often doesn't match the Requirements (Reference Architecture). Enforcing Reference Architecture guidelines promotes consistency and modularity in the System. It also helps in detecting structural complexity and preventing it earlier in the software development process. As a result, the application code is modifiable, portable, and testable.

In this presentation, I will talk about the significance of enforcing the architecture rules and standards and how to actually enforce them in software development projects. I will start off the discussion explaining various types of architecture rules that range from simple module dependencies to enforcing how APIs and specific idioms should be used. All these rules usually fall into categories such as Layered Architecture, Separation Of Concerns, Domain Driven Design, and Infrastructure. Some of the rules examples will include basic validations like DAO (Persistence) layer shouldn't depend on any other layers, Presentation layer should not use DAO classes directly, and Service layer should never call web layer. Separation of concerns rules are no transaction management in DAO classes and Service layer should be transactional. More sophisticated rules like that are used in a Domain Driven Design project such as Service object creation through a Factory object (i.e. no Service instantiation using the new keyword), No direct access to DAO's except from the Domain classes (go through Domain or Repository objects), and Business service that fails with a concurrency related failure can be retried.

The presentation will also include the discussion on Static and Dynamic Analysis architecture enforcement setup types and the techniques and tools architects can use for the enforcing the rules. Some of these techniques include Aspect-Oriented Programming (AOP), AspectJ Design Level Assertions (DLA's) and Design by Contract (DbC). As for the tools, Macker can be used for identifying module (package) dependency violations and other tools like Contract4J, SonarJ and Lattix can be used for more comprehensive rules enforcement. The session will include a demo of enforcing architecture rules in a sample Java application using Aspects as well as SonarJ tool. The attendees will be able to take away the techniques and tools discussed in the presentation back to their projects and start using them in their applications right away.

Prerequisite: This is an advanced AOP talk. It assumes the attendees are familiar with AOP and Aspects design concepts.

By Srini Penchikala

Domain Driven Design (DDD) technique helps architects and developers in mapping business domain concepts to software artifacts. When applying DDD techniques in a Java application, there are several domain classes and other artifacts (like configuration files) in Domain, Service and Application architecture layers that can be automatically generated using Code Generation techniques. For example, in a typical web application same data flows through the application layers in different forms like Domain Object (DO), Data Transfer Object (DTO) and XML. The developers usually write these classes manually from scratch or write the first class and then copy and paste when they need the classes for other use cases. These and other classes like Facade, Data Access Object (DAO interface, implementation and the unit test classes) are good candidates for code generation.

Code generation helps the software development process by generating consistent code for the classes and other artifacts that have infrastructure (boiler-plate) logic but don't have any business logic. It fits in very well with Domain Driven Design philosophy of "Domain First, Infrastructure Second" where the developers can focus on business domain concerns and take the advantage of code generation to address the infrastructure concerns. If Domain Driven Design provides the "What", it is the code generation, as a development technique, that can provide the "How". Code generation is a good long-term solution even though this effort involves some initial investment (in terms of coding and time) which pays itself off in medium to large domain models.

This technical session will discuss the role of code generation in a Java web application from the Domain Driven Design and Development context. I will start off the presentation with a quick overview of the Layered Architecture in a typical web application that was developed using DDD design pattern and implemented using Spring Framework (for middleware services) and JPA (with Hibernate3) for persistence. I will talk about the code generation concept in the project, that starts with the creation of a standard and consistent project template (using Maven Archetype feature). The discussion will include a list of the classes we need to write from scratch (like XSD, Domain Object and Service) and then code generate the Java classes and configuration files in domain and other layers (like DAO's, Factories, Repositories, Delegates, DTO's, Unit Tests, and Spring configuration files).

The presentation will include a demo of the Java application to show how domain elements and artifacts can be code generated using tools like openArchitectureWare (oAW), Eclipse, Maven, and Spring. The session will conclude with the design guidelines and best practices to follow when considering code generation as part of implementing a Business Domain Model.

By Srini Penchikala

In this technical session, I will discuss Domain Driven Design and Development from a practical implementation stand-point. The presentation looks at various architectural and design factors, best practices, frameworks and tools that affect the design of a business domain implementation project. It also covers the impact of various design concerns like Dependency Injection (DI), Aspect Oriented Programming (AOP), Persistence, Caching, Transaction Management and Application Security in Domain Modeling and Domain Driven Design problem space. The session also provides the domain model and code examples based on a real world DDD implementation project that utilized agile software development techniques such as SCRUM, Test Driven Development and Refactoring to realize a great success in completing the project on time and under budget.

Domain Driven Design (DDD) is about mapping business domain concepts into software artifacts. Most of the writings on Domain Driven Design (DDD) topic to-date have been based on Eric Evan's "Domain Driven Design" book, covering domain modeling and design aspects mainly from a conceptual and design stand-point. These writings discuss the main elements of DDD such as Entity, Value Object, Service etc or they talk about concepts like Bounded Context and Anti-Corruption Layer. While these concepts are important in a real-world DDD implementation, the practical side of DDD hasn't gotten enough attention from domain modeling community.

In this technical session, I will discuss Domain Driven Design and Development from a practical implementation stand-point. The presentation looks at various architectural and design factors, best practices, frameworks and tools that affect the design of a business domain implementation project. It also covers the impact of various design concerns like Dependency Injection (DI), Aspect Oriented Programming (AOP), Persistence, Caching, Transaction Management and Application Security in Domain Modeling and Domain Driven Design problem space. The session also provides the domain model and code examples based on a real world DDD implementation project that utilized agile software development techniques such as SCRUM, Test Driven Development and Refactoring to realize a great success in completing the project on time and under budget.

Other DDD techniques such as Annotations and Code Generation are covered in detail. Code generation of various artifacts in a business domain are discussed with code examples using Model Driven Architecture (MDA) and Model Driven Software Development (MDSD) tools like openArchitectureWare (oAW) and Java EE frameworks like JPA, Hibernate, Spring, Spring Security and Dozer.

Design patterns, that support Domain Driven Design efforts, such as Domain Object Model, Factory, DTOAssembler are discussed. There are also some DDD anti-patterns (smells) that developers need to keep in mind when working on domain implementation. These anti-patterns include Data Carriers, Fat Service Layer and Feature Envy. The presentation will include the discussion on these patterns with real-world code examples using a Home Loan Processing System.

Take-aways:

This session gives an overview of design and architectural factors that affect the practical Domain Driven Design implementation throughout the life cycle of the implementation project. It also offers the best practices and design patterns that technical leads and architects should adopt in achieving a successful domain driven implementation. The presentation will cover the different phases in a typical domain driven design project which includes modeling, design, development, unit testing, deployment and project management.

By Srini Penchikala

This presentation will give an overview of using Aspects/AOP to implement business domain event processing logic and Event Stream Processing (ESP) to analyze the event data streams in real-time. The presentation uses a sample application to demonstrate the use of ESP in a loan processing application. The sample application uses technologies like AspectJ, Spring AOP, and Esper (ESP container) to intercept the business domain events and process them based on pre-defined event processing queries. The application also uses ActiveMQ (JMS), JMX, and Groovy to add asynchronous messaging and application monitoring.

In a typical domain model run-time environment, several business events occur in the business process life cycle. Each of these domain events require further processing to either manage the domain state, notify other business processes, monitor the events or analyze event details for some type of decision-making. There are several reasons why event processing logic should not be coupled with the domain logic. This is where Domain Event Driven Architecture comes to the rescue where the event interception and management logic are defined in separate modules and are dynamically wired together to inject the event logic into the domain implementation code. The event data analysis is done using Event Stream Processing (ESP) techniques.

This presentation will give an overview of using Aspects/AOP to implement business domain event processing logic and Event Stream Processing (ESP) to analyze the event data streams in real-time. The presentation uses a sample application to demonstrate the use of ESP in a loan processing application. The sample application uses technologies like AspectJ, Spring AOP, and Esper (ESP container) to intercept the business domain events and process them based on pre-defined event processing queries. The application also uses ActiveMQ (JMS), JMX, and Groovy to add asynchronous messaging and application monitoring.

Prerequisite: Attendees should have some familiarity with Aspect-oriented Programming (AOP) concepts.

By Srini Penchikala

In this technical session, I will discuss how Spring AOP, one of the key components of Spring framework, can be used to greatly improve the design and development of Java applications. I will talk about the role of SpringAOP in the areas of Domain-Driven Design (DDD), Persistence (JPA), and JMX monitoring. We will also look at implementing custom Java annotations using Spring AOP.

The session will include the demonstration of a sample Java application which implements an Object Cache Monitoring framework using Spring AOP, JMX, and Rome technologies. The use case includes the cache monitoring implementation using different Spring AOP design options such as the Aspect Definition style (Annotation or XML, @AspectJ style), AOP Declaration Style (AspectJ or SpringAOP) and Aspect Weaving options (Compile time, Binary or Load Time Weaving).

The session will conclude with the discussion on tool support and best practices when using Spring AOP in Java application development.

Aspect oriented programming (AOP) complements OOP principles by managing the cross-cutting concerns like transaction management, persistence, application security, caching and architecture enforcement. It helps developers to add behavior to objects in a non-obtrusive manner through static and dynamic crosscutting and code cross-cutting concerns in separate modules and apply them in a declarative way.

Spring AOP, one of the key components of Spring framework, is used to provide declarative enterprise services such as transaction management. Coupled with Dependency Injection (DI) principle, AOP provides a powerful design and development technique to achieve higher modularity, extensibility, unit testability of various components in a typical J2EE application that is not possible with traditional design techniques.

Spring AOP is implemented in pure Java so there is no need for a special compilation process. Spring's support for AOP comes in four flavors: Classic Spring proxy-based AOP, @AspectJ annotation-driven aspects, Pure-POJO aspects, and Injected AspectJ aspects. A typical J2EE application implemented using Spring AOP includes the design decisions on what Aspect Definition style (Annotation or XML, @AspectJ style) to use, AOP Declaration Style (AspectJ or SpringAOP) and Aspect Weaving option (Compile time, binary weaving or Load Time Weaving).

In this technical session, I will discuss how Spring AOP can be used to greatly improve the design and development of Java applications to make them modular and extensible. I will talk about the role of SpringAOP in the areas of Domain-Driven Design (DDD), Persistence (JPA), and JMX monitoring. Spring AOP module has gone through major design refactoring from version 1.0 to the latest 3.0 version. We will look at how the implementation of SpringAOP aspects has changed from the previous versions to the latest version of Spring framework.

Spring AOP module allows users to implement custom aspects, complementing their use of OOP with AOP. We will also look at implementing custom Java annotations using Spring AOP. The session will include the demonstration of a sample Java application which implements an Object Cache Monitoring framework using Spring AOP, JMX, and Rome technologies. Adding the power of AOP in the object cache monitoring provides a loosely coupled, highly flexible and reusable module. The use case includes the cache monitoring implementation using different Spring AOP design options. The session will conclude with the discussion on tool support and best practices when using Spring AOP in Java application development.

Prerequisite: Familiarity with Aspects and Aspect-Oriented Programming (AOP) is required.

By Srini Penchikala

Software development teams in many organizations enforce architecture standards, but in most teams the reference architecture and design standards are not well documented or well managed over time. Having a software architecture documentation and architecture validation goes a long way. It promotes consistency in the System and helps the architects and developers to evaluate the architecture and use the architecture document go guide the implementation (design and code).

The main focus of this technical session is to present the concept of Documenting Software Architectures, especially in an Agile software development environments where design and architecture concerns often take a side-seat compared to coding. I will discuss an architecture documentation template that can be used in all IT projects to produce a consistent and easy to follow design document. I will also talk about the best practices and "gotchas" in documenting Software Architectures as well as the future trends in Software Architecture Documentation.

Software development teams in many organizations enforce architecture standards, but in most teams the reference architecture and design standards are not well documented or well managed over time. As a result of this lack of reference architecture documentation, the Implementation (Code) often doesn't match the Requirements (Reference Architecture) and the architecture quality suffers in the long run. Having a software architecture documentation and architecture validation goes a long way. It promotes consistency in the System and helps the architects and developers to evaluate the architecture and use the architecture document go guide the implementation (design and code).

The architecture of a system does not occur in a day. It has to be developed iteratively in the analysis, design, and development phases of an IT project. So, it is very important to document the software architecture in an organization. The main focus of this technical session is to present the concept of Documenting Software Architectures, especially in an Agile software development environments where design and architecture concerns often take a side-seat compared to coding.

Software Architecture can be described using Views (also known as Viewpoints or Perspectives) which are the representation of a set of system elements and the relations associated with them. Architecture Views are used to represent the system architecture using modeling specifications like UML 2.1, BPMN and other standards.

I will discuss what information, about an architecture, should be captured so that others can successfully use it, maintain it, and build a system from it. I will talk about the factors (business and technology) that influence the system architectures and how to align architecture efforts with business goals.

There are four different views that represent the system from different aspects. These are Design/Module, Build Time, Runtime, Deployment and Data Model Views. I will discuss the context of each view and its uses in the enterprise architecture big picture. I will also cover in detail, a framework we developed for documenting system architectures.

Other items included in the discussion are:

An architecture model that can be used in Agile Software Development process to capture the design and architecture details of an application.

Provide an architecture documentation template that can be used in all IT projects to produce a consistent and easy to follow design document. The Template document includes the architecture elements that add value to the software development process such as:

Document Road Map Visual Models Assumptions and Constraints Architecture analysis and rationale Mapping requirements to architecture for traceability purposes

I will also talk about the best practices and "gotchas" in documenting Software Architectures as well as the future trends in Software Architecture Documentation. Some of the architecture best practices include layered architecture, separation of concerns, domain-driven design.

Key Take-aways: Overview of multiple views to represent software architecture Role of UML 2.0 in documenting the software architecture View How the architecture Views can we used to manage the quality attributes (performance, availability, modifiability, security) Best practices and guidelines to make the architecture documentation valuable and more effective in software development environments especially those using Agile methodologies.

Prerequisite: Familiarity with software architecture and reference architecture is a plus.