WSO2Con USA 2015: Jump-Starting Middleware Services
•
0 likes•868 views
In this presentation we will take a look at the NYU’s year long journey into design and implementation of middleware services. We will take a use case — Profile service, and walk through the challenges that we faced and small wins we had during our journey. Profile service provided an implementable use case for NYU while providing the technology team an opportunity to work with many products within WSO2. We will showcase the service that we built utilizing WSO2 and integration(s) with incumbent Identity management systems.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to WSO2Con USA 2015: Jump-Starting Middleware Services
Similar to WSO2Con USA 2015: Jump-Starting Middleware Services (20)
More from WSO2
More from WSO2 (20)
Recently uploaded
Recently uploaded (20)
WSO2Con USA 2015: Jump-Starting Middleware Services
- 2. Topics for discussion today • Agile Innovation • Enterprise Service Bus as an agility accelerator • Concrete examples of the ESB in action • Where do go next?
- 3. What is Agility Agility = Speed x Accuracy
- 4. Agile Innova8on at NYU * Guiding Principles of Learned Innovation January 22, 2012 by Greg Satell http://www.innovationexcellence.com/blog/2012/01/22/guiding-principles-of-learned-innovation
- 5. Agility Accelerators • Agile Processes • Lean Investments • Product Life Cycle integration • Cloud Services • Dynamic provisioning • Unified Architecture • Others? Culture? Need to change the engine mid air?
- 6. Agile Innova8on -‐ Guiding Principles Start Small ▪ small proof of concepts, test the technology before you launch a grand campaign “Effec8ve innova8ons start small. They are not grandiose.” – Peter Drucker Balance Risk and Value ▪ Build the things that maOer most – first First implementa8ons will be flawed ▪ Good enough will get beOer ▪ Perfec8on never arrives ▪ If the value is there – then invest in “bullet proofing” Innova8on is Combina8on ▪ Many Innova8ons are the result of applying two (or more) incremental improvements Success requires Persistence and Passion ▪ Prove each layer along the way ▪ Keep it simple ▪ Test oZen ▪ Don’t be afraid to refactor ▪ Don’t be afraid of Failure (Fail Faster – Learn – Stop Failing!)
- 7. Biggest Hurdles Have a defined process for introducing new technologies ▪ If you don’t have this process established up front, expecta8ons on bugs, support, maintenance etc. will become an opportunity for someone else to step in and say “I can do beOer” :-‐) ▪ Find good partners that can help get you there Make sure everyone understands the value ▪ Decoupling sources of “system hardening” at the UI, Middleware, and Data Services level creates MANY opportuni8es for value ▪ Service re-‐use ▪ More cohesiveness in each service ▪ Able to switch out a service without having to recode everything Address misconcep8ons early ▪ ESB can be a loaded term to a lot of people who “have already been there” ▪ Why not just do “micro-‐services”? ▪ Are we just crea8ng another central point of failure? ▪ You won’t hear the cri8cisms directly! ▪ Don’t assume that silence is agreement -‐ they could be just wai8ng
- 8. Innova8on Proces Proposed stages for Innovation Projects: Environments Security Process Service Link / KB Help Desk Support PoC Hardened, secure, QA Shibb Security Consult, Best effort security Initial documentation Initial Knowledge base Development team Beta Prod Shibb, monitoring Security review in process SLAs defined KB defined Dev team working with Service team Pilot Alerting and escalation Security review completed SLAs tested KB tested Service team primary, with support from Dev team Full Production Full operational scaling, failover and DR model Continuous monitoring and alerting Prod SLAs in force Full Help Desk model in force Service Team fully supporting
- 9. Agile Objec8ve: ESB Agility Accelerators • Re-usable services • Content based routing • Service virtualization • Load balancing • Fail-over sending • Protocol switching • Message transformation • Logging & monitoring • Message splitting and aggregation • Enterprise integration patterns • Request throttling • Response caching • API Registry governance management
- 10. Agile Objec8ve: ESB Event Driven Architecture • Event sources can be hosted in the ESB • ESB acts as an events broker. • Events going through the broker can be mediated to perform any required changes before distributing. • Event sources can contain static subscriptions defined with the subscription manager and the interested parties can also subscribe to the event sources dynamically (with the right permissions). • Permissions can be managed dynamically through Registry Governance Manager.
- 12. Modular Integra8on Pladorm A pladorm for modular integra8on (Enterprise Service Bus): 1. provides the ability to orchestrate func8onality in real 8me by allowing modular soZware components to connect and communicate in a highly decoupled manner 2. can provide a basis for real 8me discovery of available services 3. provides communica8on and guaranteed message delivery between components in a lightweight and low latency manner 4. provides the ability for soZware components to communicate with each other in a protocol agnos8c manner by transla8ng and transforming protocols in flight 5. provides a mechanism for data to be shared through a governance model that does not require changing method parameters. All of this can help the organiza8on move away from manual processes and fragile script driven automa8on
- 13. Example -‐ ESB in the Cloud
- 14. Example -‐ ESB in the Cloud Example - ESB in the Cloud
- 15. Example -‐ ESB in the Cloud
- 16. ESB Agility Accelerators • A Web server will be serving the requests i.e. any request to the Produc8on environment routed through Apache-‐Web server • Access informa8on can be easily monitored • Any access rules/redirec8on rules/ aliasing etc. can be wriOen without impac8ng the applica8on server
- 17. Lessons Learned • Need to address change cohesively People / Culture - there will be resistance to ANY change. It’s human nature. Technology - introduce it incrementally based on Value / Risk tradeoff. Process - find a way to do PoCs safely. Otherwise they will be used politically.
- 18. Next Steps • Reusable Service Orchestra8on (API Management) is a good start • Next step : THE DATA • Decoupling the way we provide and consume data IS the key! • Architecture guiding principles • Suppor8ng a culture of collabora8on • Other?