Service Oriented Design with Spring

1
Service Oriented Design with Spring

• Clark D. Richey, Jr.
• Principal Consultant, RABA Technologies, LLC.
• Clark.Richey_at_raba.com

2
About Me

• Principal Consultant, RABA Technologies, LLC
• Sun Java Champion
• Associate Professor Loyola College
• Published articles on SOA and more
• Working with Java 10 years

3
Creating a Service Oriented Architecture

• Service Enablement
• Building an adapter layer to enable existing
  systems to participate in the SOA
• Service Oriented Design
• Building new applications that are designed as
  services

4
What is a Service?

• A service is a stand alone application that
  performs a specific business function and
  provides a means for exposing that functionality
  to its environment
• A service may provide a client but it must allow
  for other types of clients
• Services can be small or large and often build on
  other services

5
What is Service Oriented Design?

• Application of standard, good design principles
• Program to an interface, not an implementation
• Depend upon abstractions, not concrete classes
• Focused on building small, maintainable services
• Composing applications as aggregates of services

6
Service Oriented Design Process

• Define a service contract
• Focused on the business logic
• Decouples the service client from the
  implementation details
• Shields the client from change
• Enable the creation of multiple implementations
  of the service contract
• Allows the service to support multiple types of
  clients
• Provides an easy avenue for testing
• Good project structure

7
Advantages of SOD

• Applications built using SOD tend to be
• Very maintainable
• Highly scalable
• Produce significant amounts of reusable code

8
Project Structure

• Why does project structure matter?
• Shapes our application
• Has the ability to either constrain or empower
  our code
• Directory Structure
• How is source code separated from test code?
• Where are our configuration files?
• Where does our output go?
• Project Decomposition
• Does everything live in the same project?
• How are things related to each other?

9
Features of a Good Directory Structure

• Separate directory for
• Source code
• Test code
• Documentation
• Build output
• Easy to understand
• Flexible
• Works well with your build tool(s)

10
Existing Project Decomposition Strategies

• Vary significantly depending on their target
  application
• Dont promote reuse or flexibility
• Couple our implementations to our contract
• Optimized for use with ANT
• Tied to directory structure
• Complicated

11
Blueprints Conventions Reusable Components
12
Blueprints Conventions Web App
13
Blueprints Conventions J2EE Projects
14
SOD Approach to Directory Structures
15

• Flexibility

16

• Simplicity

17
Simplified Project Structure
18
What About

• 3rd party libraries?
• configurations files?
• build scripts?
• pictures of my children?

19
Time for Code!
20
SOD Approach to Project Decomposition
21
Terminology

• Project The overall system being built and
  deployed
• Composed of modules
• Module Highly cohesive code that performs a
  specific function
• Composed of multiple classes
• May depend on another module
• Not stadalone, runnable units

22
Interface Implementation Modules

• Interface Module
• Modules containing the service contract
• Consists primarily of interfaces but may contain
  some concrete classes
• Implementation Module
• Implementation of the service contract as
  specified in an Interface Module

23
Why Separate Contract and Implementation?

• Allows for easy creation of multiple
  implementations
• Shields the client from changes
• Makes it possible for work to begin on dependent
  modules before the implementation is complete
• Greatly simplifies unit testing

24
Time for Code!
25
Getting Back Together
26

• Dependency Injection

27

• Spring

28

• Could I use a different framework?

29

• Of Course!

30

• Program to an interface, not an implementation

31

• Depend upon abstractions, not concrete classes

32
What is Spring?

• Spring provides LOTS of services
• AOP
• Persistence support (JDBC, Hibernate, etc.)
• Web framework (Web MVC)
• Dependency injection
• A.K.A. Inversion of Control

33
What is Dependency Injection?

• Provides our code with concrete instances of the
  objects that we depend upon
• Dynamic class loading
• Allows us to program to an interface, not an
  implementation
• Prevents us from having to instantiate the
  implementation of the service contract using the
  new keyword

34
Dependency Injection Example

• Without dependency injection
• SongService service new DefaultSongService()
• With dependency injection
• SongService service

35
How Does It Work?

• Java classes (beans) defined in an application
  context document
• Typically XML (ClassPathXmlApplicationContext)
• Defines both beans to be injected and the beans
  that require injection
• Dynamic class loading
• Setter automatically called on the class
  requiring the injection
• Beans can be accessed directly from the
  ApplicationContect

36
Example Configuration File

• lt?xml version"1.0" encoding"UTF-8"?gt
• lt!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
  "http//www.springframework.org/dtd/spring-beans.d
  td" gt
• ltbeansgt
• ltbean id"SongService" class"org.jugaccino.mu
  sic.JiniClientSongService"/gt
• lt/beansgt

37
Time for Code!
38
Questions?Clark.Richey_at_raba.com

• Clark D. Richey, Jr.
• Principal Consultant, RABA Technologies, LLC.
• Sun Java Champion