PPT

230 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
230
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

PPT

  1. 1. handling complexity (mess?) integration or federation Stephen Todd IBM WebSphere MQ e-Science Institute: Edinburgh 14 October 2003 The opinions expressed here are those of the author and do not necessarily represent those of IBM.
  2. 2. outline <ul><li>what are the difficulties facing </li></ul><ul><ul><li>our customers? </li></ul></ul><ul><ul><li>the industry? </li></ul></ul><ul><li>how should we address these difficulties </li></ul><ul><ul><li>integration? </li></ul></ul><ul><ul><li>federation? </li></ul></ul>?
  3. 3. customer difficulties <ul><li>lots of departments </li></ul><ul><ul><li>every customer address stored 5 times </li></ul></ul><ul><ul><ul><li>in 5 different technologies </li></ul></ul></ul><ul><ul><li>don't even know if they are the same customer </li></ul></ul><ul><li>mergers and acquisitions </li></ul><ul><ul><li>complexity - scale - heterogeneity </li></ul></ul>i.e. .....
  4. 4. complexity <ul><li>clean complexity </li></ul><ul><ul><li>quantum theory </li></ul></ul><ul><ul><li>non first normal form </li></ul></ul><ul><li>dirty complexity </li></ul><ul><ul><li>islands of automation </li></ul></ul><ul><ul><li>heritage applications and systems </li></ul></ul><ul><li>(smart complexity?) </li></ul><ul><ul><li>(autonomics?) </li></ul></ul>bomb
  5. 5. the industry has a solution <ul><li>let us sell you our </li></ul><ul><ul><li>magic middleware </li></ul></ul><ul><ul><ul><li>database system </li></ul></ul></ul><ul><ul><ul><li>application server </li></ul></ul></ul><ul><ul><ul><li>messaging system </li></ul></ul></ul><ul><ul><li>application solution </li></ul></ul>
  6. 6. even for legacy <ul><li>we can even wrap your old one </li></ul><ul><ul><li>eg relational front end to an IMS database </li></ul></ul>&quot;It's easy to put a relational front end on a pure IMS database ~~~~ at least, it would be if there were any.&quot; dirty complexity
  7. 7. we can all grow with your needs 1 2 3 4
  8. 8. and the result is DB2 Oracle Sybase IMS WebSphere app server CICS WebLogic MQ Rendezvous MSMQ different dirty complexity
  9. 9. luckily, we have a solution <ul><li>let us sell you our systems management system </li></ul>database application server messaging system systems management system
  10. 10. so .... <ul><li>can't you give us a more integrated solution? </li></ul><ul><li>but ... </li></ul>
  11. 11. but ... middleware religion <ul><li>corporate directive </li></ul><ul><ul><li>databases are ... </li></ul></ul><ul><ul><li>application servers are ... </li></ul></ul><ul><ul><li>messaging system is ... </li></ul></ul><ul><ul><li>(no MS software, but 1000 VB programmers) </li></ul></ul>&quot;We can't install your messaging system if it requires DB2 -- even if it is hidden. Corporate directive is Oracle.&quot; complexity and contradiction
  12. 12. so, what are our problems when providing middleware to help? database application server messaging system systems management system
  13. 13. <ul><li>many overlapping solutions </li></ul><ul><ul><li>integrated islands </li></ul></ul><ul><ul><li>heritage products </li></ul></ul><ul><li>how many transaction coordinators? </li></ul><ul><li>how many databases? </li></ul><ul><ul><li>and even more persistent stores... </li></ul></ul>our own dirty complexity database application server messaging system systems management system
  14. 14. product growth example: MQ <ul><li>'simple' point-to-point messaging/queuing </li></ul><ul><ul><li>reliable, heterogeneous </li></ul></ul><ul><li>resource manager not database because ... </li></ul><ul><li>transaction coordinator not external because ... </li></ul><ul><li>publish/subscribe </li></ul><ul><li>broker </li></ul><ul><ul><li>message semantics and dictionary not schema because ... </li></ul></ul><ul><ul><li>transformations not SQL because ... </li></ul></ul><ul><ul><li>database interaction </li></ul></ul><ul><ul><ul><li>-with many databases so no integration ... </li></ul></ul></ul><ul><ul><li>almost an application server but not because ... </li></ul></ul>
  15. 15. so, potential for integration <ul><li>common tooling </li></ul><ul><li>common systems administration </li></ul><ul><li>common data and programming model </li></ul><ul><li>etc etc </li></ul>database application server messaging system
  16. 16. database application server <ul><li>least affinity ~~ impedance mismatch </li></ul><ul><li>subsumption, not integration </li></ul><ul><ul><li>even back to CICS, IMS </li></ul></ul><ul><li>DB subsumes application server </li></ul><ul><ul><li>stored procedures & UDFs make DB an app server </li></ul></ul><ul><li>applications subsume database </li></ul><ul><ul><li>programming persistence or object DB </li></ul></ul><ul><ul><ul><li>removes need for (explicit) DB </li></ul></ul></ul><ul><ul><ul><li>but loses much DB modelling and query power? </li></ul></ul></ul>integration potential
  17. 17. application servers messaging <ul><li>increased 'active' component in messaging </li></ul><ul><li>need for wider reach in app server </li></ul><ul><ul><li>more heterogeneity </li></ul></ul><ul><ul><li>wider geographies </li></ul></ul><ul><ul><ul><li>implies distributed, async </li></ul></ul></ul><ul><ul><ul><li>linked transaction model </li></ul></ul></ul>integration potential
  18. 18. database / messaging <ul><li>low level </li></ul><ul><ul><li>persistence, resource management, transactions </li></ul></ul><ul><li>high level </li></ul><ul><ul><li>transformations, data models, streams </li></ul></ul><ul><li>data placement and replication </li></ul>relation input stream result stream integration potential
  19. 19. <ul><li>the data you want </li></ul><ul><ul><li>where you want it </li></ul></ul><ul><ul><li>when you want it </li></ul></ul><ul><ul><li>in the form you want it </li></ul></ul><ul><li>integration potential </li></ul><ul><ul><li>same messages, same pictures </li></ul></ul>
  20. 20. but should we integrate, or federate, or ...? <ul><li>integration </li></ul><ul><ul><li>cleaner models </li></ul></ul><ul><ul><li>easier administration </li></ul></ul><ul><li>federation </li></ul><ul><ul><li>heterogeneity </li></ul></ul><ul><ul><li>choice </li></ul></ul><ul><ul><li>handle dirty complexity </li></ul></ul>Can componentization give us the best of both? How big must the components be? How interdependent?
  21. 21. What does the future hold? Will it change anything fundamentally? <ul><li>WebServices </li></ul><ul><ul><li>same technology, another name </li></ul></ul><ul><ul><li>very strong federation credentials </li></ul></ul><ul><ul><ul><li>(how widely will it really work) </li></ul></ul></ul><ul><li>Grid </li></ul><ul><ul><li>??? ### ??? </li></ul></ul><ul><li>Aspect programming </li></ul><ul><li>Pickled chocolates </li></ul>
  22. 22. so, to summarize <ul><li>big, horrid monsters </li></ul><ul><ul><li>dirty complexity </li></ul></ul><ul><ul><li>face our customers </li></ul></ul><ul><ul><li>face the industry </li></ul></ul><ul><li>what's the solution? </li></ul><ul><li>(We know how to draw the picture) </li></ul><ul><ul><li>integration </li></ul></ul><ul><ul><li>federation </li></ul></ul><ul><li>or .... </li></ul>
  23. 23. brand solution <ul><li>customers want integration </li></ul><ul><li>but it's impossible in the real world </li></ul><ul><li>so rebrand federation as integration </li></ul><ul><ul><li>and give them what they want </li></ul></ul><ul><ul><li>AND what they need </li></ul></ul>

×