svcc services presentation (silicon valley code camp 2011)

Proprietary and Confidential

Learning to Love ServicesExperiences from the Transition to a

Service-oriented Architecture

Jeff GreenStaff Software Engineer

Background

Proprietary and Confidential 3

Ingenuity Systems• Collect large curated, computable knowledge

base of biological information– Molecules (genes, chemicals)– Relationships between molecules– Pathways– Biological processes

• Develop software applications to leverage knowledge base for researchers– Ingenuity Pathways Analysis (IPA)– iReports– Next Generation Sequencing application


IPA

Analyze dataset of molecules uploaded by user


IPA

Visualize and explore relationships between molecules


IPA

Search and browse through biological content


Technologies• Client: Swing-based primary client with some

browser-based visualizations• Server: Multi-tier Java web application in Tomcat

and Jetty servlet containers• Oracle database


Legacy Architecture

• Servers separated for scalability• Communicate through multicasting• Early notion of services except:

– Significant overlap of code and data access– Tightly coupled build, package, deployment– Entire system released quarterly


Why move toService-oriented Architecture?

• Code/data reuse– Single definition of services and model objects– Common implementation

• More precise scalability– Scale only parts of system under stress

• More rapid releases– Push new features and fixes out to customers faster

• Simplify testing• Separation of responsibilities

– Untangle unnecessary dependencies– Reduce learning curve of code


Constraints• IPA enhancements must continue simultaneously

– Changes cannot impact Production system prematurely

– Majority of engineering resources still focused on new development

• Homogeneous implementation– All services will be in Java, although external clients

may be Swing or browser-based.• Majority of services will be private

– Existing public apis will remain but are exception


Key Considerations• High-level architecture

– What parts of the system should be services?• Implementation

– How is a service defined?• Communication

– How will consumers interact with providers?• Versioning

– How can changes be managed?• Testing

– How can quality be ensured?

High-level Architecture


Architecture Questions• What existing capabilities should become

separate services?• What is the responsibility of each service?• What data does each service own?• What are the dependencies?

– No circularity• How granular should the system be?

– If too granular, hard to maintain– If not granular enough, lose benefits of services

(reuse, scalability, modularity, etc.)


Ingenuity Service Categories

• Biological content– Provide biological content from a single source in a

consistent model• Algorithms

– Optimized for executing algorithms on data• User management

– User records– Authentication/authorization– Account creation– License management

Key Driver:

Reuse functionality to reduce development cost and enforce consistency


Ingenuity Service Categories (cont.)

• Views of biological entities– Common rendering for reports of all biological

information about a molecule, chemical, etc.• Utilities

– Event tracking– Document generation


Previous Design


IPA with Services

Implementation


Strategy• Adopt a common nomenclature, ideally somewhat

similar to existing system• Define simple, brief standards to guide

development and ensure consistency– Code organization– Server directory structure

• For each service, pick best implementation approach– Implement from scratch– Customize third-party application– Refactor existing code


What exactly is a service anyway?• A set of operations available to consumers• Defined by an Application Programming Interface

(API): the set of operations and the data structures that serve as their input and output

• Java implementation: an interface and the model objects (Plain Old Java Objects, POJOs) that serve as arguments and return values


Module• Encapsulates one or more related services and

their implementations– Source code: API, business logic, data access– XML and property files– Web resources– Test code (both unit and integration)

• Vertical slice of functionality– Improved modularity, reuse

• Buildable unit resulting in <module>.jar and other artifacts

• Existed in previous architecture, albeit different in nature


Module Source Packages• Defined new basic package structure to organize

code within modules– Consistency helps with finding, understanding code


Module Directories• Defined new basic directory structure to organize

resources within modules– Consistency helps with finding resources– Simplifies tools


Component• Encapsulates one or more modules for

packaging/deployment (i.e. a releasable unit)• In practice, one per JVM• Unit of scale and redundancy• Owner of modules and schemas

Biological Content Component

Molecule Module Finding Module Graph Module

Molecule Service Finding Service Notation Service

Graph Service


Why have a module?• In smaller components, component = single

module• In larger components, additional unit of

encapsulation helps to further modularize the code

• Clarifies code organization• Forces consideration of dependencies

– Package boundaries not inherently enforced• An attempt to fight spaghetti


Tactics: Rebuild or Refactor?• Rebuild where existing approach was not

sufficient– New licensing schemes– SSO authentication (CAS implementation)

• Refactor where behavior should not change significantly– Content, algorithms, views

• Changes must not impact ongoing enhancements– Rebuilt components have no immediate impact– Refactor on separate branch; schedule merge at

appropriate time


Build, Package, Deploy• Before

– Ant script built entire system at once– All components deployed together across multiple

JVMs• After

– Modified ant script builds a single component– Resulting component package is union of resources

in modules it owns– Each component deployed separately

• Current Tools– Hudson used to manage build/package tasks– Custom installer

Communication


Considerations• How does a consumer locate a service provider?• Once found, what is protocol for communication?• Requirements

– Consumers and providers must be loosely coupled– Flexibility to add providers without impacting

consumers and vice-versa– Synchronous communication is acceptable


Spring Remoting• Already in use in existing application• Abstract data transfer from consumer and

provider• Provides flexibility to switch from remote to local

services through configurationGraphServiceGraphAlgorithm

GraphServiceImpl

getGraph(id)

GraphObj

Within single component


Spring Remoting• Already in use in existing application• Abstract data transfer from consumer and

provider• Provides flexibility to switch from remote to local

services through configurationGraphServiceGraphAlgorithm

HttpProxy

getGraph(id)

GraphObj

Across components

GraphService

GraphServiceImpl

getGraph(id)

GraphObj

HttpService

Http request w/ serialized objects

Http response w/ serialized objects

URL fromconfiguration


Service Discovery Manager (SDM)• Simple, custom utility provides a single (logical)

point for service discovery– Provider registers service– Consumer requests service location

SDM

AlgorithmComponent

ServerA




SDM

ContentComponent

GraphService

ServerB

AlgorithmComponent

ServerA

Provider registers at startup

GraphService@ServerB




SDM

ContentComponent

GraphService

ServerB

AlgorithmComponent

ServerAGraphService

@ServerB

1a) Consumer requests service location

GraphService




SDM

ContentComponent

GraphService

ServerB

AlgorithmComponent

ServerAGraphService

@ServerB

1b) SDM responds with location

ServerB




SDM

ContentComponent

GraphService

ServerB

AlgorithmComponent

ServerAGraphService

@ServerB

2a) Consumer requests servicedirectly from ServerB




SDM

ContentComponent

GraphService

ServerB

AlgorithmComponent

ServerAGraphService

@ServerB

2b) Provider responds with data

• Additional overhead with multiple requests, so stickiness is available– In practice, have not needed it


Service Discovery Manager (SDM)• Spring remoting bean replaced with SDM-

implementation– Still abstracted from consumer and provider code

GraphServiceGraphAlgorithm

SDMConsumer

getGraph(id)

GraphObj

GraphService

GraphServiceImpl

getGraph(id)

GraphObj

SDMProvider

Http request w/ serialized objects

Http response w/ serialized objects

URL fromSDM


api.jar• Consumers and providers must share api

definition• <module>-api.jar encapsulates module service

interfaces and model object classes• Built/published along with component providing

the service• Consumer picks up published jar at build time

Versioning

v1.0

v2.0


Change is Inevitable• A service is defined by API, which will change

over time• Consumers and providers may change at different

rates• Goal is to minimize impact of change on

consumers


Types of Service Changes• Implementation only

– No change to API; therefore no impact on consumer• API addition

– New method or member in model object• API change or deletion

– Service contract has changed


Version Label

<major>.<minor>.<build>• <build> = implementation change

– Updated every build (svn revision number)– No impact on consumer

• <minor> = API addition– All releases with same major version are backward

compatible– Consumer of older service can ignore

• <major> = API change– Consumer must adapt


Usage during Service Discovery• Api.jar stamped with specific version• Consumer includes versioned api when built• Consumer requests service with specific version• SDM finds provider with = major version and >=

minor version• Multiple versions can coexist

SDM

ContentComponent

GraphService2.3

ServerCAlgorithm

Component

ServerAGraphService2.2

@ServerBGraphService 2.2

ServerBor

ServerC

ContentComponent

GraphService2.2

ServerB

GraphService2.3@ServerC


Usage during Service Discovery• Api.jar stamped with specific version• Consumer includes versioned api when built• Consumer requests service with specific version• SDM finds provider with = major version and >=

minor version• Multiple versions can coexist

SDM

ContentComponent

GraphService2.3

ServerCAlgorithm

Component

ServerAGraphService2.2

@ServerBGraphService 2.3

ServerC

ContentComponent

GraphService2.2

ServerB

GraphService2.3@ServerC


Java Serialization Id• Every Java class has serialization id

– Assigned by compiler or programmer– Intent is to identify change

• If unspecified, API model object will get new id with every change– Potentially breaks backwards compatibility of minor

version change• Solution is to specify id for all model objects


Stability Level• Need to separate components at different stages

of lifecycle– Ongoing development should not impact testing

and demos• Versioning not sufficient because only reflects API

changes


Option: Duplicate Environments• Duplicate entire system for each stage of stability


Option: Duplicate Environments• Duplicate entire system for each stage of stability

• Significant redundancy• Unmanageable when several environments


Better Option: Zones• Establish zones: logical categories of stability

– Development vs. testing vs. stable– In practice, zone can be String

• Providers broadcast service in appropriate zone• Consumers look for service in desired zone


Full Service Discovery Protocol• Discovery protocol involves three pieces of info

– Service name (i.e. full interface name)– Version– Zone

• Same SDM instance can be used across all zones

SDM

AlgorithmComponent

ServerA

GraphService2.3Stable@ServerB

GraphService 2.3Stable

ServerB

GraphService2.3

ServerB

GraphService2.3

ServerC

GraphService2.3

ServerD

Dev

Test

Stable

GraphService2.3Test@ServerC

GraphService2.3Dev@ServerD

Testing


Goals• Ensure component meets contract defined by API

– Opportunity for more granular testing– No user interface available– Critical for individual release cycles

• Ensure component is backwards compatible• Test component as a whole

– “Unit test” where component is the testable unit– Not comfortable relying solely on class unit tests– Requires realistic data

• Automate test execution– Enable more frequent updates with less cost


FitNesse• Framework for writing, organizing, and executing

tests• Acts as a consumer of the component under test• Tests written in wiki-like syntax in browser client

• Classes called Fixtures transform data to/from API model objects

• Results are displayed and history is maintained


Test Resources• Modules that encapsulate code for

services also contain the testing-related resources– FitNesse wiki pages– Fixtures

• Fixtures built at same time as component• All test resources encapsulated in a separate package– Package includes api jars of the service it tests, just

like other consumers of the service• For every component, there is a suite of FitNesse

tests to validate it


Continuous Integration (CI)• Goal: rapidly iterate through the develop, build,

test, and release cycle in as automated a way as possible

• Basic workflow– Developer commits change to component– Altered component is built and deployed– Suite of tests are executed against the component– Assuming tests pass, build is released

• Process is as automated as possible• Ideally frequency is limited only by hardware

constraints


CI in Practice

Dev

Test

Stable

CI

Stable

ContentComponent

FitNesse

1) Component is implemented in a Dev zone


CI in Practice

Dev

Test

Stable

CI

Stable

ContentComponent

FitNesse2) Component is built and

deployed in the CI zone


CI in Practice

Dev

Test

Stable

CI

Stable

ContentComponent

FitNesse

3) Component tests are deployed to the FitNesse server


CI in Practice

Dev

Test

Stable

CI

Stable

ContentComponent

FitNesse

4) Tests are executed against the component


CI in Practice

Dev

Test

Stable

CI

StableContent

Component

FitNesse

5) If tests pass, component is promoted to Stable zone


CI in Practice

Dev

Test

Stable

CI

StableContent

Component

FitNesse

AlgorithmComponentConsumers use services in

the Stable zone, even during development and testing


CI in Practice

Dev

Test

Stable

CI

StableContent

Component

FitNesse

Consumers go through the same CI workflow to be promoted to Stable

AlgorithmComponent


CI in Practice

Dev

Test

Stable

CI

StableContent

Component

FitNesse

The process is initiated automatically once per day and the steps are automated from build to Stable promotion. Builds are still manually released to Production for now.

AlgorithmComponent


Backwards Compatibility• Services must be backwards compatible

– Support consumers of all previous minor versions– Ensures provider can be updated independently of

consumer• To validate, execute test bundles built with

previous minor versions– Confirms previous contract is still met– Confirms api jars are still compatible

Results


Successes• New applications utilized services immediately

– Enabled teams to focus on new innovation– Previously code/capability had to be duplicated– Apps used services even before IPA did

• Faster, more frequent releases– Legacy system previously updated quarterly– User management service now updated within iteration

(< 2 weeks)– Fixes released within a couple hours

• More modular code base• Consistency in code structure, server layout• Several servers smaller than before

– Improved startup time– Now feasible to run/debug within IDE


Challenges and Do-overs• Difficult to overhaul so many aspects of the

system simultaneously• Major version in API package names

– Potentially results in “false positive” change to significant numbers of files

– 20% case complicated the 80% case• Jar dependencies

– Attempt at simplification ended up being more difficult


Next Steps• Recently achieved milestone of porting legacy

application to use services it spawned• Improve service APIs, possibly rewrite

– Feasible now that components have clearly defined boundaries

• Improve test coverage• Performance testing of individual components

– Understand load profiles to guide scalability decisions

• Transition to standard tools– maven– puppet


Key Takeaways• Identify early what is necessary and what is not;

focus on what is necessary• Take incremental steps where possible

– Important for remaining agile• Establish simple patterns or standards to follow in

implementation, packaging, and testing– Helps with tools creation, understanding of system

• Be flexible– Try new approaches and process; adapt if first try

does not work out


Questions?

Jeff GreenStaff Software EngineerIngenuity Systemswww.ingenuity.com

Slides available at:http://www.slideshare.net/jenlwong/svcc-services-presentation-201110

Photo Credits: Petronas Towers: Franco Pecchio (Ai@ce, flickr.com); Coffee beans: Al Gebra (photl.com); Telegraph: Bill Bradford (mrbill, flickr.com); Chimp: Afrika Expeditionary Force (flickr.com); Mug shot: Jimmy Prescott (flickr.com); Crash test: NASA (everystockphoto.com); Trophies: Roberto Arias (Ariaski, flickr.com)

svcc services presentation (silicon valley code camp 2011)

Technology