modern (java) enterprise architectures
Post on 13-Sep-2014
5.616 views
DESCRIPTION
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.TRANSCRIPT
![Page 1: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/1.jpg)
Modern Enterprise-‐Architectures
Eberhard Wolff, SpringSource – A division of VMware
![Page 2: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/2.jpg)
About me • Eberhard Wolff • Principal Technologist • Consultant & Trainer • Author (e.g. first German Spring book)
• [email protected] • TwiGer: @ewolff • Blog: hGp://ewolff.com
![Page 3: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/3.jpg)
A division of VMware
Lightweight App RunOme
Virtual App Environment
Hybrid Cloud
Spring tc Server
VM
Spring tc Server
Lightweight App Framework
![Page 4: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/4.jpg)
Overview • IntroducOon
• Java EE Deployment opOons
• OSGi
• Cloud
![Page 5: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/5.jpg)
Which PlaWorm Shall I use? • Actually two decisions:
– Which server environment? – Which programming model?
• Java EE is both • Spring is a programming model • i.e. you can use Spring with any server environment
• i.e. you can update Spring versions without updaOng the server
Infrastructure (Server)
Programming Model
Your App
Spring
Java EE
![Page 6: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/6.jpg)
So? • Spring is the beGer programming model • I am biased… • hGp://jandiandme.blogspot.com/2010/10/ spring-‐vs-‐java-‐ee-‐and-‐why-‐i-‐dont-‐care.html
• More producOvity only with new tools, not framework
• 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
Programming Model
Your App
Roo / Grails …
![Page 7: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/7.jpg)
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?
![Page 8: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/8.jpg)
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?
![Page 9: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/9.jpg)
Approach: Everything in One Unit • Everything is in one unit (i.e. WAR / EAR) • TradiOonal Java EE model
WAR / EAR
Customer Payment
![Page 10: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/10.jpg)
One Unit: Advantages • Every class in the system only once
• including e.g. libraries
• Efficient
![Page 11: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/11.jpg)
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
![Page 12: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/12.jpg)
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
customer.war
payment.war
ClassLoader isolation HTTP (Web Services, REST, HTTP Invoker, …)
JMX
must include classes from customer.war
![Page 13: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/13.jpg)
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
![Page 14: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/14.jpg)
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, …)
![Page 15: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/15.jpg)
These are limits of Java EE's Class-‐Loader-‐per-‐App and
deployment model
ClassLoader isolation
![Page 16: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/16.jpg)
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
![Page 17: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/17.jpg)
Either you accept these limitaOons or you have to
choose a different approach
![Page 18: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/18.jpg)
Main concern: Class Loader
ClassLoader isolation
![Page 19: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/19.jpg)
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
Customer API Payment
Customer Service
import packages
import services
![Page 20: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/20.jpg)
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)
![Page 21: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/21.jpg)
Main benefit: Probably enforcing the modularizaOon at runOme
![Page 22: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/22.jpg)
Not dynamic deployment of new modules
![Page 23: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/23.jpg)
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
![Page 24: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/24.jpg)
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?
![Page 25: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/25.jpg)
Dynamic changes to random parts are hard.
![Page 26: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/26.jpg)
Dynamic changes to random parts are probably not needed
and not wanted.
![Page 27: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/27.jpg)
You need to idenOfy which parts of the system change frequently.
![Page 28: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/28.jpg)
What are some ways to deal with dynamic behavior?
![Page 29: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/29.jpg)
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
![Page 30: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/30.jpg)
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
![Page 31: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/31.jpg)
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."
![Page 32: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/32.jpg)
Numerous other examples • "The Spring configuraOon should be read from the database."
• "Can you change the Spring configuraOon dynamically?"
![Page 33: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/33.jpg)
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
![Page 34: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/34.jpg)
Processes: OperaOons vs. Developers
![Page 35: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/35.jpg)
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
If you only remember one slide from my talk – make it this one.
![Page 36: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/36.jpg)
What about…
The Cloud
![Page 37: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/37.jpg)
What is Cloud CompuOng? • “Cloud” is an abstracOon…
• Provide IT as a service • Self serviced • Pay as you go
• Just like…
![Page 38: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/38.jpg)
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 – CompuOng plaWorm and/or soluOon stack as a
service – Google App Engine, VMforce – Ocen consuming cloud infrastructure – Ocen sustaining cloud applicaOons.
• Socware as a Service – SaaS – Socware as a service over the Internet – Salesforce.com – EliminaOng the need to install and run the
applicaOon on the customer's own computers – Simplifying maintenance and support
Socware
PlaWorm
Infrastructure
![Page 39: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/39.jpg)
Clouds • Private: My data center
• Public: Someone else's data center
• Managed: Managed for me
• Hybrid: Mix Private Cloud Public Cloud
![Page 40: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/40.jpg)
Cloud is inevitable • Clear economically benefits
• BeGer compuOng resource uOlizaOon
• Flexibility
• Self serviced: A developer can just create a test environment • Massive producOvity gain
![Page 41: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/41.jpg)
How is this relevant?
![Page 42: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/42.jpg)
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
![Page 43: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/43.jpg)
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
![Page 44: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/44.jpg)
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
![Page 45: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/45.jpg)
Commit = Deploy?
![Page 46: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/46.jpg)
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?
![Page 47: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/47.jpg)
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) • Roo/Grails should be able to level these differences
![Page 48: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/48.jpg)
Conclusion
![Page 49: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/49.jpg)
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
![Page 50: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/50.jpg)
What is the slide you should have remembered?
![Page 51: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/51.jpg)
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
![Page 52: Modern (Java) Enterprise Architectures](https://reader034.vdocument.in/reader034/viewer/2022042518/541483dc8d7f72506c8b45e0/html5/thumbnails/52.jpg)
QuesOons?