J2EE Design Patterns :

J2EE Layers:
10 Object Oriented Design principles Java
programmer should know (guest post)
By Marina Sprava | February 25, 2013






This article was originally posted by Javin Paul at Javarevisited.

Object Oriented Design Principles are core of OOPS programming but I have seen most of Java
programmer chasing design patterns like Singleton pattern, Decorator pattern or Observer pattern but not
putting enough attention on Object oriented analysis and design or following these design principles.
I have regularly seen Java programmers and developers of various experience level who either
doesn’t heard about these OOPS and SOLID design principle or simply doesn’t know what benefits
a particular design principle offers or how to use these design principle in coding.
Bottom line is always strive for highly cohesive and loosely couple solution, code or design and
looking open source code from Apache and Sun are good examples of Java design principles or
how design principles should be used in Java coding. Java Development Kit follows several design
principle like Factory Pattern in BorderFactory class, Singleton pattern in Runtime class and if you
interested more on Java code read Effective Java by Joshua Bloch , a gem by the guy who wrote Java
API. My another personal favorite on object oriented design pattern is Head First Design Pattern by
Kathy Sierra and others and Head First Object Oriented Analysis and Design.
Though best way of learning design principles or pattern is real world example and understanding the
consequences of violating that design principle, subject of this article is Introducing Object oriented design
principles for Java Programmers who are either not exposed to it or in learning phase. I personally think each
of these design principle need an article to explain it clearly and I will definitely try to do it here but for now

just get yourself ready for quick bike ride on design principle town

Object oriented design principle 1 – DRY (Don’t

repeat yourself)
As name suggest DRY (don’t repeat yourself) means don’t write duplicate code, instead
use abstraction to abstract common things in one place. if you use a hardcoded value more than one
time consider making it public final constant, if you have block of code in more than two place
consider making it a separate method. Benefit of this SOLID design principle is in maintenance. Its
worth to note is don’t abuse it, duplicate is not for code but for functionality means if you used
common code to validate OrderID and SSN it doesn’t mean they are same or they will remain same
in future. By using common code for two different functionality or thing you closely couple them
forever and when your OrderID changes its format, your SSN validation code will break. So be
aware of such coupling and just don’t combine anything which uses similar code but are not related.

Object oriented design principle 2 – Encapsulate

what varies
Only one thing is constant in software field and that is “Change”, So encapsulate the code you
expect or suspect to be changed in future. Benefit of this OOPS Design principle is that Its easy to
test and maintain proper encapsulated code. If you are coding in Java then follow principle of making
variable and methods private by default and increasing access step by step e.g. from private to
protected and not public. Several of design pattern in Java uses Encapsulation, Factory design
pattern is one example of Encapsulation which encapsulate object creation code and provides
flexibility to introduce new product later with no impact on existing code.

Object oriented design principle 3 – Open

Closed principle
Classes, methods or functions should be Open for extension (new functionality) and Closed for
modification. This is another beautiful object oriented design principle which prevents some-one from
changing already tried and tested code. Ideally if you are adding new functionality only than your
code should be tested and that’s the goal of Open Closed Design principle.

Object oriented design principle 4 – Single

Responsibility Principle (SRP)
There should not be more than one reason for a class to change or a class should always handle
single functionality. If you put more than one functionality in one Class in Java it
introduce coupling between two functionality and even if you change one functionality there is
chance you broke coupled functionality which require another round of testing to avoid any surprise
on production environment.
Object oriented design principle 5 – Dependency
Injection or Inversion principle
Don’t ask for dependency it will be provided to you by framework. This has been very well
implemented in Spring framework, beauty of this design principle is that any class which is injected
by DI framework is easy to test with mock object and easier to maintain because object creation
code is centralized in framework and client code is not littered with that.There are multiple ways to
implemented Dependency injection like using byte code instrumentation which some AOP (Aspect
Oriented programming) framework like AspectJ does or by using proxies just like used in Spring.

Object oriented design principle 6 – Favour

Composition over Inheritance
Always favour composition over inheritance if possible. Some of you may argue this but I found that
Composition is lot more flexible than Inheritance. Composition allows to change behaviour of a class
at runtime by setting property during runtime and by using Interfaces to compose a class we
use polymorphism which provides flexibility of to replace with better implementation any time.
Even Effective Java advise to favor composition over inheritance.

Object oriented design principle 7 – Liskov

Substitution Principle (LSP)
According to Liskov Substitution Principle Subtypes must be substitutable for super type i.e.
methods or functions which uses super class type must be able to work with object of sub class
without any issue”. LSP is closely related to Single responsibility principle and Interface Segregation
Principle. If a class has more functionality than subclass might not support some of the functionality
and does violated LSP. In order to follow LSP design principle, derived class or sub class must
enhance functionality not reducing it.

Object oriented design principle 8 – Interface

Segregation principle (ISP)
Interface Segregation Principle stats that a client should not implement an interface if it doesn’t use
that. this happens mostly when one interface contains more than one functionality and client only
need one functionality and not other.Interface design is tricky job because once you release your
interface you can not change it without breaking all implementation. Another benefit of this desing
principle in Java is, interface has disadvantage to implement all method before any class can use it
so having single functionality means less method to implement.

Object oriented design principle 9 –

Programming for Interface not implementation
Always program for interface and not for implementation this will lead to flexible code which can
work with any new implementation of interface. So use interface type on variables, return types of
method or argument type of methods in Java. This has been advised by many Java programmer
including in Effective Java and head first design pattern book.

Object oriented design principle 10 – Delegation

principle
Don’t do all stuff by yourself, delegate it to respective class. Classical example of delegation design
principle is equals() and hashCode() method in Java. In order to compare two object for equality we ask
class itself to do comparison instead of Client class doing that check. Benefit of this design principle
is no duplication of code and pretty easy to modify behaviour.
All these object oriented design principle helps you write flexible and better code by striving high
cohesion and low coupling. Theory is first step but what is most important is to develop ability to find
out when and to apply these design principle and find our whether we are violating any design
principle and compromising flexibility of code. but again as nothing is perfect in this world, don’t
always try to solve problem with design patterns and design principle they are mostly for large
enterprise project which has longer maintenance cycle.

SOA Design patterns

10 Soa Design Patterns Every Architect Should

Know
posted by Anna Mar, September 07, 2010

These 10 SOA design patterns are so important and widely used that they
almost seem a little obvious.

1. Agnostic Services
Agnostic services implement logic that is common to multiple business
problems. Separating agnostic logic into discrete services facilitates service
reuse and composability.
principles: reuse, service composability

2. Agnostic Service Declaration

Agnostic services should explicitly declare that they are agnostic. This makes
it clear to future designers and builders which services are designed to be
reused.
principles: reuse, service composability

3. Atomic Service Transaction

Services can be wrapped in atomic transactions with a rollback feature that
reverses all actions and changes. Transaction management services can be
implemented in the component layer and reused by multiple services.
principles: service statelessness

4. Enterprise Service Bus (ESB)

An ESB acts as a message broker between consumers and services. The ESB
can perform message transformations, routing and connect to applications
via a variety of communication protocols.
principles: loose coupling, interoperability, endpoint abstraction

5. Service Façade
A service façade sits between a service and a contract. It eliminates the tight
coupling between the service and its contract. This is intended to minimize
changes to the service if the contract changes. A service can have multiple
service façades to support multiple contracts.
principles: loose coupling

6. Service Callback
A service requires its consumers to call it asynchronously. If the consumer
needs a response it provides a callback address. When the service reaches
some milestone in processing it messages the consumer with a response.
This approach frees resources and is useful when services are expected to
be long running.
principles: loose coupling

7. Multiple Service Contracts

A service may support multiple contracts concurrently. This can be done to
support backward compatibility (so that when a service changes all the
consumers do not have to be updated). It is also done to provide different
views to the service for different purposes (thus facilitating reuse).
principles: reuse, loose coupling

8. Authentication Broker
An authentication broker assumes responsibility for authenticating
consumers. Consumers are issued a token they can use to access services.
principles: service composability

9. Message Origin Authentication

Digital certificates are used to authenticate clients.

principles: service composability

10. Message Screening
Messages are screened for harmful data before processing.

principles: standard service contract

SOA (Service Oriented Architecture) Principles

SOA is based on some key principles which are mentioned below

1. Standardized Service Contract - Services adhere to a service description. A

service must have some sort of description which describes what the service
is about. This makes it easier for client applications to understand what the
service does.

2. Loose Coupling – Less dependency on each other. This is one of the main
characteristics of web services which just states that there should be as less
dependency as possible between the web services and the client invoking the
web service. So if the service functionality changes at any point in time, it
should not break the client application or stop it from working.

3. Service Abstraction - Services hide the logic they encapsulate from the
outside world. The service should not expose how it executes its functionality;
it should just tell the client application on what it does and not on how it does
it.
 4. Service Reusability - Logic is divided into services with the intent of
maximizing reuse. In any development company re-usability is a big topic
because obviously one wouldn't want to spend time and effort building the
same code again and again across multiple applications which require them.
Hence, once the code for a web service is written it should have the ability
work with various application types.

5. Service Autonomy - Services should have control over the logic they
encapsulate. The service knows everything on what functionality it offers and
hence should also have complete control over the code it contains.

6. Service Statelessness - Ideally, services should be stateless. This means

that services should not withhold information from one state to the other. This
would need to be done from either the client application. An example can be
an order placed on a shopping site. Now you can have a web service which
gives you the price of a particular item. But if the items are added to a
shopping cart and the web page navigates to the page where you do the
payment, the responsibility of the price of the item to be transferred to the
payment page should not be done by the web service. Instead, it needs to be
done by the web application.

7. Service Discoverability - Services can be discovered (usually in a service

registry). We have already seen this in the concept of the UDDI, which
performs a registry which can hold information about the web service.

8. Service Composability - Services break big problems into little problems.

One should never embed all functionality of an application into one single
service but instead, break the service down into modules each with a
separate business functionality.

9. Service Interoperability - Services should use standards that allow diverse

subscribers to use the service. In web services, standards as XML and
communication over HTTP is used to ensure it conforms to this principle.

Messaging Patterns Overview

Why Enterprise Integration Patterns?

Enterprise integration is too complex to be solved with a simple 'cookbook' approach.

Instead, patterns can provide guidance by documenting the kind of experience that
usually lives only in architects' heads: they are accepted solutions to recurring
problems within a given context. Patterns are abstract enough to apply to most
integration technologies, but specific enough to provide hands-on guidance to
designers and architects. Patterns also provide a vocabulary for developers to
efficiently describe their solution.

Patterns are not 'invented'; they are harvested from repeated use in practice. If you
have built integration solutions, it is likely that you have used some of these patterns,
maybe in slight variations and maybe calling them by a different name. The purpose
of this site is not to "invent" new approaches, but to present a coherent collection of
relevant and proven patterns, which in total form an integration pattern language.

Despite the 700+ pages, our book covers only a fraction of patterns (and the problems
to be solved) in the integration space. The current patterns focus on Messaging, which
forms the basis of most other integration patterns. We have started to harvest more
patterns but are realizing (once again) how much work documenting these patterns
really is. So please stay tuned.

Messaging Patterns

We have documented 65 messaging patterns, organized as follows:

Message Construct.
Message
Command Message
Document Message
Event Message
Request-Reply
Return Address
Correlation Identifier
Message Sequence
Message Expiration
Format Indicator
Message Routing
Pipes-and-Filters
Message Router
Content-based Router
Message Filter
Dynamic Router
Recipient List
Splitter
Aggregator
Resequencer
Composed Msg. Processor
Scatter-Gather
Routing Slip
Process Manager
Message Broker
Message
Transformation
Message Translator
Envelope Wrapper
Content Enricher
Content Filter
Claim Check
Normalizer
Canonical Data Model
Messaging Endpoints
Message Endpoint
Messaging Gateway
Messaging Mapper
Transactional Client
Polling Consumer
Event-driven Consumer
Competing Consumers
Message Dispatcher
Selective Consumer
Durable Subscriber
Idempotent Receiver
Service Activator
Messaging Channels
Message Channel
Point-to-Point Channel
Publish-Subscr. Channel
Datatype Channel
Invalid Message Channel
Dead Letter Channel
Guaranteed Delivery
Channel Adapter
Messaging Bridge
Message Bus
Systems Mgmt.
Control Bus
Detour
Wire Tap
Message History
Message Store
Smart Proxy
Test Message
Channel Purger
 Integration Styles document different ways applications can be integrated,
providing a historical account of integration technologies. All subsequent
patterns follow the Messaging style.
 Channel Patterns describe how messages are transported across a Message
Channel. These patterns are implemented by most commercial and open source
messaging systems.
 Message Construction Patterns describe the intent, form and content of the
messages that travel across the messaging system. The base pattern for this
section is the Message pattern.
 Routing Patterns discuss how messages are routed from a sender to the correct
receiver. Message routing patterns consume a message from one channel and
republish it message, usually without modification, to another channel based on
a set of conditions. The patterns presented in this section are specializations of
the Message Routerpattern.
 Transformation Patterns change the content of a message, for example to
accommodate different data formats used by the sending and the receiving
system. Data may have to be added, taken away or existing data may have to be
rearranged. The base pattern for this section is the Message Translator.
  Endpoint Patterns describe how messaging system clients produce or
consume messages.
 System Management Patterns describe the tools to keep a complex message-
based system running, including dealing with error conditions, performance
bottlenecks and changes in the participating systems.

What Products Implement or Use Enterprise Integration Patterns?

The patterns are not tied to a specific implementation. They help you design better
solutions, whether you use any of the following platforms:

 EAI and SOA platforms, such as IBM WebSphere

MQ, TIBCO, Vitria, Oracle Service Bus, WebMethods (now Software
AG), Microsoft BizTalk, or Fiorano.
 Open source ESB's like Mule ESB, JBoss Fuse, Open ESB, WSo2, Spring
Integration, or Talend ESB
 Message Brokers like ActiveMQ, Apache Kafka, or RabbitMQ
 Web service- or REST-based integration, including Amazon Simple Queue
Service (SQS) or Google Cloud Pub/Sub
 JMS-based messaging systems
 Microsoft technologies like MSMQ or Windows Communication Foundation
(WCF)

How Can You Use the Patterns?

We want to encourage widespread use of the integration pattern language. We have

therefore provided a variety of ways to access them:

 Reference. A summary of each pattern from the book is available on this site.
 Read. Of course, the book Enterprise Integration Patterns (Addison-Wesley,
ISBN 0321200683) contains the full catalog of patterns with a much more
detailed discussion and examples -- over 700 pages worth of material. You can
also read the full text on-line on Safari (with membership).
 Document. You can create design documents using our icon language by
downloading the Visio stencil or using the OmniGraffle stencil created by one
of our readers.
 Reuse. You are also welcome to build on top of what we have done. We made
the pattern name, icon, problem and solution statements, as well as the sketches
(the diagram below the solution statement) available under the Creative
Commons Attribution license. In brief, this license allows you share, use and
modify these passages as long as you give proper attribution. In our case, this
 would mean a link to the site and a reference to the book title and authors. If
you have questions regarding this requirement, please contact us.
 Build. A number of open-source frameworks, such as Mule, Apache Camel,
or Spring Integration incorporate our patterns. Now you can not only think in
integration patterns, but also to code in them!
 Teach. A number of professors use our material in lectures. If you are
interested in getting access to material for academic purposes, please contact
us.

What about REST / SOA / Web Service Patterns?

The book is now over 10 years old. Yet, the integration problems we have to solve
every day remain frustratingly similar. Because the patterns encapsulate design
knowledge, this knowledge does not age nearly as quickly as a specific technology.
For more on applying the patterns to recent integration technologies
like REST or Google Cloud Pub/Sub, follow our Ramblings.

Messaging Patterns
HOME PATTERNS RAMBLINGS ARTICLES TALKS DOWNLOAD BOOKS
CONTACT

Me
Table of Contents Messaging Patterns ss
ag
MESSAGING PATTERNS » TABLE OF CONTENTS Previous Next in
g
Messaging Patterns Overview Pa
tte
Table of Contents Detailed table of contents. rn
s
Preface

Introduction

Solving Integration Problems

using Patterns
Integration Styles
Introduction to Integration
Styles
How can I integrate multiple applications so that
File Transfer they work together and can exchange
information?
 How can I integrate multiple applications so that
Shared Database they work together and can exchange
information?
How can I integrate multiple applications so that
Remote Procedure Invocation they work together and can exchange
information?
How can I integrate multiple applications so that
Messaging they work together and can exchange
information?
Messaging Systems
Introduction to Messaging
Systems

How does one application communicate with

Message Channel
another using messaging?
How can two applications connected by a
Message message channel exchange a piece of
information?
How can we perform complex processing on a
Pipes and Filters message while maintaining independence and
flexibility?
How can you decouple individual processing
steps so that messages can be passed to
Message Router
different filters depending on a set of
conditions?
How can systems using different data formats
Message Translator
communicate with each other using messaging?
How does an application connect to a
Message Endpoint messaging channel to send and receive
messages?
Messaging Channels
Introduction to Messaging
Channels

How can the caller be sure that exactly one

Point-to-Point Channel receiver will receive the document or perform
the call?
How can the sender broadcast an event to all
Publish-Subscribe Channel
interested receivers?

How can the application send a data item such

Datatype Channel
that the receiver will know how to process it?
How can a messaging receiver gracefully
Invalid Message Channel handle receiving a message that makes no
sense?
What will the messaging system do with a
Dead Letter Channel
message it cannot deliver?
 How can the sender make sure that a message
Guaranteed Delivery will be delivered, even if the messaging system
fails?
How can you connect an application to the
Channel Adapter messaging system so that it can send and
receive messages?
How can multiple messaging systems be
Messaging Bridge connected so that messages available on one
are also available on the others?
What is an architecture that enables separate
applications to work together, but in a
Message Bus decoupled fashion such that applications can be
easily added or removed without affecting the
others?
Message Construction
Introduction to Message
Construction

How can messaging be used to invoke a

Command Message
procedure in another application?

How can messaging be used to transfer data

Document Message
between applications?

How can messaging be used to transmit events

Event Message
from one application to another?

When an application sends a message, how

Request-Reply
can it get a response from the receiver?

How does a replier know where to send the

Return Address
reply?

How does a requestor that has received a reply

Correlation Identifier
know which request this is the reply for?

How can messaging transmit an arbitrarily large

Message Sequence
amount of data?
How can a sender indicate when a message
Message Expiration should be considered stale and thus shouldn’t
be processed?
How can a message’s data format be designed
Format Indicator
to allow for possible future changes?
Interlude: Simple Messaging
Introduction to Simple
Messaging Examples

JMS Request/Reply Example

.NET Request/Reply Example

 JMS Publish/Subscribe
Example
Message Routing
Introduction to Message
Routing
How do we handle a situation where the
implementation of a single logical function (e.g.,
Content-Based Router
inventory check) is spread across multiple
physical systems?
How can a component avoid receiving
Message Filter
uninteresting messages?
How can you avoid the dependency of the
Dynamic Router router on all possible destinations while
maintaining its efficiency?
How do we route a message to a list of
Recipient List
dynamically specified recipients?
How can we process a message if it contains
Splitter multiple elements, each of which may have to
be processed in a different way?
How do we combine the results of individual,
Aggregator but related messages so that they can be
processed as a whole?
How can we get a stream of related but out-of-
Resequencer sequence messages back into the correct
order?
How can you maintain the overall message flow
when processing a message consisting of
Composed Message Processor
multiple elements, each of which may require
different processing?
How do you maintain the overall message flow
Scatter-Gather when a message needs to be sent to multiple
recipients, each of which may send a reply?
How do we route a message consecutively
through a series of processing steps when the
Routing Slip
sequence of steps is not known at design-time
and may vary for each message?
How do we route a message through multiple
processing steps when the required steps may
Process Manager
not be known at design-time and may not be
sequential?
How can you decouple the destination of a
Message Broker message from the sender and maintain central
control over the flow of messages?
Message Transformation
Introduction to Message
Transformation
 How can existing systems participate in a
messaging exchange that places specific
Envelope Wrapper
requirements on the message format, such as
message header fields or encryption?
How do we communicate with another system if
Content Enricher the message originator does not have all the
required data items available?
How do you simplify dealing with a large
Content Filter message, when you are interested only in a few
data items?
How can we reduce the data volume of
Claim Check message sent across the system without
sacrificing information content?
How do you process messages that are
Normalizer semantically equivalent, but arrive in a different
format?
How can you minimize dependencies when
Canonical Data Model integrating applications that use different data
formats?
Interlude: Composed Messaging
Introduction to Composed
Messaging Examples

Synchronous Implementation
using Web Services

Asynchronous Implementation
with MSMQ

Asynchronous Implementation
with TIBCO ActiveEnterprise
Messaging Endpoints
Introduction to Messaging
Endpoints
How do you encapsulate access to the
Messaging Gateway messaging system from the rest of the
application?
How do you move data between domain objects
Messaging Mapper and the messaging infrastructure while keeping
the two independent of each other?
How can a client control its transactions with the
Transactional Client
messaging system?

How can an application consume a message

Polling Consumer
when the application is ready?

How can an application automatically consume

Event-Driven Consumer
messages as they become available?

How can a messaging client process multiple

Competing Consumers
messages concurrently?
 How can multiple consumers on a single
Message Dispatcher
channel coordinate their message processing?

How can a message consumer select which

Selective Consumer
messages it wishes to receive?

How can a subscriber avoid missing messages

Durable Subscriber
while it’s not listening for them?
How can a message receiver deal with
Idempotent Receiver
duplicate messages?
How can an application design a service to be
invoked both via various messaging
Service Activator
technologies and via non-messaging
techniques?
System Management
Introduction to System
Management
How can we effectively administer a messaging
Control Bus system that is distributed across multiple
platforms and a wide geographic area?
How can you route a message through
Detour intermediate steps to perform validation, testing
or debugging functions?
How do you inspect messages that travel on a
Wire Tap
point-to-point channel?
How can we effectively analyze and debug the
Message History
flow of messages in a loosely coupled system?
How can we report against message
information without disturbing the loosely
Message Store
coupled and transient nature of a messaging
system?
How can you track messages on a service that
Smart Proxy publishes reply messages to the Return
Address specified by the requestor?
What happens, though, if a component is
Test Message actively processing messages, but garbles
outgoing messages due to an internal fault?
How can you keep 'left-over' messages on a
Channel Purger channel from disturbing tests or running
systems?
Interlude: Systems Management Example
Loan Broker System
Management
Integration Patterns in Practice
Case Study: Bond Trading
System
Concluding Remarks
 Emerging Standards and
Futures in Enterprise
Integration
Appendices
Annotated list of references and recommended
Bibliography
reading.
Revision History Chronological list of changes.