Why Does Modular Middleware Matters

1,426 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,426
On SlideShare
0
From Embeds
0
Number of Embeds
63
Actions
Shares
0
Downloads
61
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Why Does Modular Middleware Matters

  1. 1. Why Does Modular Middleware Mater? Paul Fremantle Co-Founder & CTO paul@wso2.com +44 7740 199729 htp://wso2.com/
  2. 2. Paul Fremantle – CTO • Co-founder and CTO of WSO2. • VP of Apache Synapse, Co-Chair OASIS WSRX TC. • Nominated Infoworld’s top 25 CTO in 2008. • Previously a Senior Technical Staf Member at IBM. • Author of two books: Building Web Services in Java, 2nd Editon, and The XML Files. • MA in Mathematcs and Philosophy and an MSc in Computaton, both from Oxford University.
  3. 3. WSO2 • Founded in 2005 by acknowledged leaders in XML, Web Services Technologies & Standards and Open Source. • Producing entre middleware platorm 100% open source under Apache license. • Business model is to sell comprehensive support & maintenance for our products. • Venture funded by Intel Capital. • Global corporaton with ofces in USA, UK & Sri Lanka. • 80+ employees and growing.
  4. 4. Engagement Model • Quick Start – Combinaton of consultng, training and POC development in one week by WSO2 on-site team working hand-in-hand with customer team. • Development Support – On-going support for Customer's engineering teams. • Producton Support – Full 24x7x365 enterprise support providing sofware maintenance and support.
  5. 5. Agenda • What is Modular Middleware? – WSO2 Carbon • What is it and why did we build it? • Why is it important? – How does it work? – Carbon 3.0.0 • Digging into the new release – What’s next • The Carbon App • Beter Provisioning
  6. 6. Our Strategy • Design Objectves for WSO2 Middleware: – Self-consistent and lean – Internal interoperability – External interoperability – Infnitely fexible and agile for rapid soluton architecture adopton – Open standards and Open Source – A complete middleware platorm from data to screen
  7. 7. What is Carbon and why? • Carbon is modular middleware • “Eclipse for Servers” – Completely built as a set of well-defned OSGi components – Highly stable foundaton for middleware • High volume producton use cases 200m+ transactons/day – Re-confgurable • Install new features, uninstall, revert – Fits the middleware to the architecture • Zero bloat but more than 150 features
  8. 8. WSO2 Enterprise Platorm 8
  9. 9. The Soluton: WSO2 Carbon
  10. 10. The Soluton: WSO2 Carbon
  11. 11. The Soluton: WSO2 Carbon
  12. 12. Why did we build Carbon? • Initally we wanted to have small independent teams – Fast and agile • But we soon ended up with overlap and underlap – Some teams were duplicatng functon – Some products were missing functon that was already coded – But we didn’t want to lose the small team agility
  13. 13. Why is it important? 1. It makes WSO2 even more agile 2. It means that you already know how to manage WSO2 systems a. Security management of BPS is the same as ESB, WSAS, etc b. Clustering, Keystores, etc etc are all consistent 3. It is highly extensible: new components can be writen by WSO2 or you 4. You can confgure the systems to ft your architecture
  14. 14. The right SOA middleware for the architecture
  15. 15. The right middleware • Use just the components you need • Add the right components in the right place – Data Services + Mediaton – BPS and Data Services – etc… • No need for multple product installs to accomplish simple functon – Compare the size of Carbon with ESB and BPS loaded to competng BPMS+ESB
  16. 16. Carbon Architecture • Clean “front-end/back-end” separaton – Every component has a core runtme, a clean SOA management interface, a well-defned front-end console component – All completely pluggable, versioned, etc • Full dependency management – Hence full re-use • Pluggable common core services: – Registry, Key Management, Identty Management, Clustering, Monitoring/JMX, Transports, etc – Cloud enabled (hold that thought)
  17. 17. Carbon Component Manager
  18. 18. p2 – Provisioning Platorm • Part of the OSGi Equinox project – A well-defned model for provisioning components – Based on a web or fle based repository • Can be hosted internally for an organizaton – Three approaches: • Command line • Web console • Secure remote API • Today – Provision the middleware • Coming soon - Provision user applicatons
  19. 19. How big is Carbon? • WSO2 Carbon Download (just Carbon) – 73Mb • p2 features repository – 77Mb extra (130Mb in total) • Total codebase – 150Mb • Latest RCs (as of April 9th): – htp://builder.wso2.org/~carbon/releases/carbon/3.0.0/4RC3/ – htp://builder.wso2.org/~carbon/releases/carbon/3.0.0/4RC3/wso2carbon-3.0.0.zip – htp://builder.wso2.org/~carbon/releases/carbon/3.0.0/4RC3/p2-repo/
  20. 20. Carbon 3.0 aka Iridium • Core improvements – Component Manager – Improvements to p2 • Patches are now p2 managed – Beter Registry management – Cluster manager – WS-Discovery Support – cApp (coming in June) • Lots of per-product improvements (see announcements)
  21. 21. Iridium Release Plans • Phase 1 – April 2010 – WSO2 WSAS 3.2 – WSO2 ESB 3.0 – WSO2 Governance Registry 3.5 – WSO2 Identty Server 3.0 • Phase 2 – May 2010 – WSO2 Data Services Server 2.5 – WSO2 Business Process Server 2.0 – WSO2 Business Actvity Monitor 1.1 – WSO2 Mashup Server 2.1 – WSO2 Gadget Server 1.1 – WSO2 Business Rules Server 1.0
  22. 22. Patches under Carbon 3.0 • Patches are p2 features – Patch management now allows installaton, de-installaton and revert to version • Service Packs are p2 group features – Manage dependencies – Install all pre-requisite patches – Uninstall / revert Please note that patches and service packs are only licensed for producton use to our producton support customers
  23. 23. Carbon Apps (cApps) • A cApp is a repository of features • Each feature is a deployable OSGi bundle containing a part of an applicaton – E.g. ESB sequence, Services, BPEL fow, etc • The cApp contains a “logical topology” – Mapping from app components to roles • An automated build/deploy process adds a “physical topology” – Mapping into physical Carbon VMs • The applicaton features have dependencies on the runtme components they run on: – Deploying an ESB sequence will ensure there is ESB code to run it on
  24. 24. Other Futures • Webapp support • Consistent endpoint management (Discovery vs Deployment) • Cloud! – Cloud deployment – Mult-tenancy – Plenty more
  25. 25. Summary • WSO2 Carbon is the only complete modular middleware platorm – Confgure your SOA as your architecture needs – Grow as your needs grow – Provision exactly what you need – Prepare for a cloudy future
  26. 26. Resources • Company Website: htp://wso2.com • Paul: paul@wso2.com • Business Team: bizdev@wso2.com

×