• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Modern (Java) Enterprise Architectures

on

  • 5,366 views

Presentation from my WJAX 2010 talk about modern Java Enterprise Architectures. Talks about dynamic changes to systems and approaches like Java, Java EE, OSGi, Cloud, Spring.

Presentation from my WJAX 2010 talk about modern Java Enterprise Architectures. Talks about dynamic changes to systems and approaches like Java, Java EE, OSGi, Cloud, Spring.

Statistics

Views

Total Views
5,366
Views on SlideShare
5,365
Embed Views
1

Actions

Likes
2
Downloads
111
Comments
0

1 Embed 1

http://oracle.sociview.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Modern (Java) Enterprise Architectures Modern (Java) Enterprise Architectures Presentation Transcript

    • Eberhard Wolff, SpringSource – A division of VMware Modern  Enterprise-­‐ Architectures  
    • About  me   •  Eberhard  Wolff   •  Principal  Technologist   •  Consultant  &  Trainer   •  Author  (e.g.  first  German  Spring  book)   •  ewolff@vmware.com   •  TwiGer:  @ewolff   •  Blog:  hGp://ewolff.com  
    • A  division  of  VMware   Spring   tc  Server   VM   Hybrid   Cloud   Spring   tc  Server   Virtual  App   Environment   Lightweight   App  RunOme   Lightweight   App  Framework  
    • Overview   •  IntroducOon   •  Java  EE  Deployment  opOons   •  OSGi   •  Cloud  
    • Which  PlaWorm  Shall  I  use?   •  Actually  two  decisions:   –  Which  server  environment?   Your  App   –  Which  programming  model?   Programming   Spring Model   •  Java  EE  is  both   Java EE Infrastructure   •  Spring  is  a  programming  model   (Server)   •  i.e.  you  can  use  Spring  with  any  server   environment   •  i.e.  you  can  update  Spring  versions   without  updaOng  the  server  
    • So?   •  Spring  is  the  beGer  programming  model   Your  App   •  I  am  biased…   •  hGp://jandiandme.blogspot.com/2010/10/   Roo  /  Grails  …   spring-­‐vs-­‐java-­‐ee-­‐and-­‐why-­‐i-­‐dont-­‐care.html   •  More  producOvity  only  with   new  tools,  not  framework   Programming   Model   •  Spring  Roo  offers  a  much  broader  approach   –  Inspired  by  Ruby  on  Rails:  Generator   –  Raises  the  level  of  abstracOons   –  Covers  build   –  Introduces  tools   –  No  similar  technology  for  Java  EE  available!   •  Other  languages  (Groovy  /  Grails,  Scala  …)   •  So  I  will  focus  on  the  server  infrastructure  
    • Modular  Programming   •  Key  to  developing  socware  producOvely   •  Much  improvement  in  the  last  few  years   •  Dependency  management  is  ubiquitous   •  Architecture  management   •  What  is  the  next  level?  
    • Modular  Deployment   •  What  is  the  granularity  of  deployment?   •  Let's  assume  a  Java  EE  applicaOon   •  Customer  module   •  Payment  module   •  Dependency:  Payment  depends  on  Costumer   •  How  do  we  get  this  deployed?  
    • Approach:  Everything  in  One  Unit   •  Everything  is  in  one  unit  (i.e.  WAR  /  EAR)   •  TradiOonal  Java  EE  model   WAR / EAR Customer Payment
    • One  Unit:  Advantages   •  Every  class  in  the  system  only  once   •  including  e.g.  libraries   •  Efficient  
    • One  Unit:  Challenges   •  ModularizaOon  might  not  be  as  good  as  you  think   –  as  runOme  does  not  enforce  it   •  Complex  build  process   –  If  you  use  EARs   •  Long  deployment   •  Small  changes  require  complete  redeployment   •  Might  influence  turn  around  Ome  during  development   •  ConOnuous  integraOon     •  Note:  If  you  set  up  a  completely  new  system  for   producOon  anyway  this  might  be  not  such  a  big  issue  
    • Approach:  1  Module  =  1  Deployment   •  Each  module  is  a  unit  (e.g.  WAR)   •  Unorthodox  Java  EE  model   •  Units  are  isolated:  no  shared  classes  nor  objects   •  No  direct  communicaOon  possible   must include classes from payment.war customer.war HTTP JMX (Web Services, ClassLoader isolation REST, HTTP Invoker, …) customer.war
    • 1  Module  =  1  Deployment:  Advantages   •  Each  module  can  be  deployed  independently   •  i.e.  a  change  in  the  payment  module  can  be  deployed   independently  from  the  rest   •  Might  be  an  advantage   •  Process  (e.g.  retesOng)  must  sOll  be  followed   •  If  you  install  a  completely  new  system  anyway  that  does   not  maGer   •  Faster  turn  around   •  Only  one  module  built  and  redeployed  
    • 1  Module  =  1  Deployment:  Challenges   •  CommunicaOon  between  modules  complex   •  No  shared  classes   •  e.g.  domain  classes  for  communicaOon   •  Perm  Gen  space   •  Stores  loaded  classes   •  Each  class  loaded  once  per  deployment   •  e.g.  all  libraries  (Spring,  JPA,  …)  
    • These  are  limits  of  Java  EE's   Class-­‐Loader-­‐per-­‐App  and   deployment  model   ClassLoader isolation
    • How  can  we  answer  the  challenge…   •  It  must  be  possible  to   •  share  classes  between  deployment  units   •  add  or  remove  deployment  units  at  runOme   •  That  was  the  whole  point   •  This  opens  up  all  kinds  of  interesOng  challenges   •  Deployment  units  with  classes  come  and  go  at  runOme   •  ImplementaOons  should  be  exchangeable  at  runOme  
    • Either  you  accept  these   limitaOons  or  you  have  to   choose  a  different  approach  
    • Main  concern:  Class  Loader   ClassLoader isolation
    • OSGi   •  Solves  these  issues   •  Should  disOnguish  between  import  of  packages  and   services   •  API  update  sOll  requires  restart  of  payment   •  But  an  update  of  the  service  implementaOon  in  the   running  system  is  possible   import packages Customer API Payment import services Customer Service
    • OSGi  Advantages   •  Each  module  can  be  deployed  independently   –  Same  issues  as  before  (e.g.  retesOng)   •  Faster  turn  around   –  Only  one  module  built  and  redeployed   •  CommunicaOon  between  modules  easily  possible   (OSGi  services)   •  Sharing  classes  between  modules  possible   •  More  efficient  use  of  Perm  Gen  Space   •  Your  architecture  might  benefit:   –  Enforces  modularizaOon  at  runOme   –  Supports  versioning  (Java's  missing  feature)  
    • Main  benefit:  Probably  enforcing   the  modularizaOon  at  runOme  
    • Not  dynamic  deployment  of  new   modules  
    • OSGi  Challenges   •  More  complex   –  Have  to  deal  with  import  /  exports  of  packages  /  services   –  Just  a  result  of  the  modularizaOon   •  Web  support  and  byte  code  manipulaOon  (e.g.  JPA)   might  be  challenges   •  Approaches  like  Eclipse  Virgo  (runOme  environment)   help   •  Different  deployment  model  and  server  environment   from  Java  EE   –  OperaOons  might  not  like  that   •  API  changes  sOll  require  a  restart  of  dependent  modules  
    • OSGi  is  just  a  tool   •  It  won't  solve  all  your  problems   •  The  applicaOon  /  architecture  must  allow   for  dynamic  updates   •  State  in  services  is  not  a  brilliant  idea   •  MulOple  versions  at  the  same  Ome   •  What  about  database  schemas?   •  Have  to  deal  with  API  updates   •  Well  known  problem  in  distributed  environments   •  RetesOng   •  Can  you  reproduce  your  producOon  environment?  
    • Dynamic  changes  to  random   parts  are  hard.  
    • Dynamic  changes  to  random   parts  are  probably  not  needed   and  not  wanted.  
    • You  need  to  idenOfy  which  parts   of  the  system  change  frequently.  
    • What  are  some  ways  to  deal   with  dynamic  behavior?  
    • Dealing  with  dynamics   •  Update  the  logic  on  parts  of  your  cluster   •  The  rest  runs  the  old  version   •  Eventually  the  whole  cluster  is  migrated   •  …or  rolled  back   •  SOll  need  to  deal  with  the  database  or  external   clients  for  example  
    • Dealing  with  dynamics   •  Some  technologies  support  changes  to  the  behavior   without  changing  code   •  Rule  engines   •  Dynamic  /  script  languages  (can  be  reloaded  at  runOme)   •  Workflow  engines   •  Obviously  they  also  have  other  features   •  SomeOmes  they  are  used  primarily  because  of   dynamics  
    • An  Anecdote   "We  have  issues  because  we  use  a   complex  rule  base."   "Well,  have  you  thought  about   using  code  instead?"   "We  can't."   "Why?"   "Because  every  code  change  will   go  through  a  complex  retesOng   phase.  Rules  are  just   configuraOon  and  not  tested."  
    • Numerous  other  examples   •  "The  Spring  configuraOon  should  be  read  from  the   database."   •  "Can  you  change  the  Spring  configuraOon   dynamically?"    
    • Something  is  wrong  here   •  Either  the  retesOng  is  unnecessary   –  Then  it  should  not  be  done  independent  of  the   technology   –  …and  you  are  wasOng  money   •  …or  it  is  necessary   –  Then  it  should  not  be  done  independent  of  the   technology   –  …and  you  are  tesOng  in  producOon  (risk  maximizing)   •  AnO  PaGern:  Hide  logic  away  from  operaOons  and   processes  in  configuraOon  
    • Processes:   OperaOons  vs.  Developers  
    • DevOps  to  the  Rescue?   •  Processes,  methods  and  systems  for   •  CommunicaOon,  collaboraOon  and  integraOon   •  Between  Development,  Technology  OperaOons  and   Quality  Assurance  (QA)   If you only remember one slide from my talk – make it this one. •  More  and  smaller  changes:  less  risk   •  Giving  developers  more  environment  control   •  Giving  infrastructure  more  applicaOon-­‐centric   understanding   •  Clearly  arOculaOng  simple  processes   •  AutomaOng  as  much  as  possible   •  CollaboraOon  between  dev  and  ops  
    • What  about…   The  Cloud  
    • What  is  Cloud  CompuOng?   •  “Cloud”  is  an  abstracOon…   •  Provide  IT  as  a  service   •  Self  serviced   •  Pay  as  you  go   •  Just  like…  
    • Clouds   •  Infrastructure  as  a  Service  –  IaaS   –  Computer  infrastructure  as  a  service   –  Amazon  EC2,  VMware  vCloud  Director   –  Typically  plaWorm  virtualizaOon  environment   •  PlaWorm  as  a  Service  –  PaaS   Socware   –  CompuOng  plaWorm  and/or  soluOon  stack  as  a   service   –  Google  App  Engine,  VMforce   –  Ocen  consuming  cloud  infrastructure     PlaWorm   –  Ocen  sustaining  cloud  applicaOons.   •  Socware  as  a  Service  –  SaaS   –  Socware  as  a  service  over  the  Internet   Infrastructure   –  Salesforce.com   –  EliminaOng  the  need  to  install  and  run  the   applicaOon  on  the  customer's  own  computers     –  Simplifying  maintenance  and  support  
    • Clouds   •  Private:  My  data  center   •  Public:  Someone  else's  data  center   •  Managed:  Managed  for  me   •  Hybrid:  Mix   Public Cloud Private Cloud
    • Cloud  is  inevitable   •  Clear  economically  benefits   •  BeGer  compuOng  resource  uOlizaOon   •  Flexibility   •  Self  serviced:  A  developer  can  just  create  a  test   environment   •  Massive  producOvity  gain  
    • How  is  this  relevant?  
    • Cloud  is  self  serviced   •  Developers  starts  the  (tesOng)  environment  all  by   himself.   •  OperaOons  define  policies,  approved  infrastructure  etc.   •  Otherwise  developers  use  a  public  cloud   •  Processes  might  be  changed  radically   •  I.e.  more  responsibility  and  influence  for  developers  
    • Cloud  =  Pay  as  you  Go   •  Higher  load  requires  more  resources   •  Less  load  should  consume  less    resources   •  More  (or  less)  systems  will  share  the  load   •  It  must  be  possible  to  create  (and  remove)  systems   on  the  fly   •  You  can't  afford  a  complex  installaOon  processes   •  You  will  be  handled  like  a  SaaS  
    • Puqng  Things  into  ProducOon   •  A  deployment  to  a  new  piece  of  metal  has  to  be   automated   –  Otherwise  you  can't  handle  increased  demand   –  IaaS:  Do  it  yourself   –  PaaS:  Taken  care  of   •  Deployment  process  will  be  radically  different   •  Might  eliminate  the  need  for  dynamic  changes   •  A  real  deployment  is  fast  enough   •  Note:  TesOng  /  quality  must  sOll  be  assured  
    • Commit  =  Deploy?  
    • Logical  conclusion  of  Agility   •  Lots  of  small  improvements  in  producOon   •  ApplicaOon  always  compileable  /  executable   •  Automated  tests   •  ConOnuous  integraOon   •  ConOnuous  Deployment     •  Why  bother  with  dynamic  reconfiguraOon  of  parts?  
    • Programming  Model  again   •  Spring  based  soluOons   •  Google  App  Engine   •  VMforce  (VMware  /  SpringSource  +  Salesforce)   •  No  Java  EE  based  PaaS   •  Focus  on  lightweight  infrastructure  important   •  Less  resources  to  start  up  new  (virtual)  computers   •  Technology  agnosOc  approach  important   •  Cloud  has  different  model   •  See  Google  App  Engine  and  its  limited  Java  /  JPA  …   •  See  NoSQL  for  data  storage  (Spring  Data)   •  See  AMQP  for  messaging  (Spring  AMQP)  
    • Conclusion  
    • Conclusion   •  Java  EE's  model  is  limited  by  class  loader  isolaOon   –  doesn't  maGer  if  you  install  a  system  completely  afresh   anyway   •  OSGi  solves  this  problem   •  But  you  will  define  hot  spots  for  changes   •  and  could  use  rule  engines  etc.  instead   •  Important:  TesOng,  process,  operaOons   •  Cloud  will  change  this  completely   –  much  faster,  self  service  deployment  on  fresh  system,   programming  model  
    • What  is  the  slide  you  should   have  remembered?  
    • DevOps  to  the  Rescue?   •  Processes,  methods  and  systems  for   •  CommunicaOon,  collaboraOon  and  integraOon   •  Between  Development,  Technology  OperaOons  and   Quality  Assurance  (QA)   •  More  and  smaller  changes:  less  risk   •  Giving  developers  more  environment  control   •  Giving  infrastructure  more  applicaOon-­‐centric   understanding   •  Clearly  arOculaOng  simple  processes   •  AutomaOng  as  much  as  possible   •  CollaboraOon  between  dev  and  ops  
    • QuesOons?