OSGi Sticker Shock Eclipse Con 2010

894 views

Published on

Slides for EclipseCon 2010 presentation.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
894
On SlideShare
0
From Embeds
0
Number of Embeds
69
Actions
Shares
0
Downloads
36
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Welcome. Thank you for the opportunity to tell you more about TIBCO and how we can help you. Let me introduce my team….
  • TIBCO is a leading provider of business integration and process management software. I’m going to play a short video that does a great job of highlighting TIBCO’s core capabilities. <mouse click> By being the leading business integration and process management software provider we can help you: <mouse click> Accelerate projects, initiatives and go-to-market cycles <mouse click> We can help you automate and streamline business processes <mouse click> And we can help you improve operational visibility, collaboration and ability to be proactive.
  • OSGi Sticker Shock Eclipse Con 2010

    1. 1. Overcoming Sticker Shock Addressing the unexpected costs of OSGi in the Enterprise Eric Johnson
    2. 2. We think OSGi is great. <ul><li>Developers are forced to identify dependencies
    3. 3. Cannot “cheat” on component architecture
    4. 4. Runtime fails to “wire”, rather than obscure Class incompatibilities
    5. 5. Potentially a very dynamic runtime! </li></ul>
    6. 6. Where are we using OSGi? <ul><li>Runtime </li><ul><li>Bundles inside of OSGi frameworks </li></ul><li>Design-time </li><ul><li>Extending the Eclipse environment </li></ul><li>Deployment </li><ul><li>Tracking what is and needs to be deployed, and where? </li></ul><li>Build-time </li><ul><li>Using stated dependencies to reduce surprises </li></ul></ul>
    7. 7. OSGi is too fine grained. <ul><li>We build features, not individual OSGi bundles
    8. 8. We ship products, not features or bundles
    9. 9. … therefore we need additional levels of metadata </li><ul><li>Not all dependency data can be derived from lower levels. </li></ul></ul>
    10. 10. More specifically, what has slowed us down? <ul><li>Metadata </li><ul><li>Metadata for our own software
    11. 11. Third party software metadata - including Eclipse! </li></ul><li>Build architecture, infrastructure, & tooling
    12. 12. Packaging & deployment granularity
    13. 13. Dual-target code </li><ul><li>Same code running in design-time (Eclipse), and runtime (pure Equinox), but not the same metadata! </li></ul><li>Common development platform … and none of that is code to solve customer problems!!! </li></ul>
    14. 14. For our own metadata, what do we do? <ul><li>Version entire feature as one! </li><ul><li>Even if you touch only one source file, bump every package, every bundle, and version of feature
    15. 15. Only way to safely maintain multiple branches of code. </li></ul><li>Use “Import-Package” </li><ul><li>Different runtime environments have different packages from “outside” OSGi runtime
    16. 16. All packages are versioned on export and import </li></ul><li>Version ranges </li><ul><li>Always up to, but not including next major version </li></ul></ul>1.0 1.0 1.0 1.1 1.1 1.1
    17. 17. What have we learned about integrating third-party libraries? <ul><li>We wrap all of them. Why? </li><ul><li>No Java standard for versioning of JAR files, much less packages
    18. 18. Need to state all “Import-Package” entries
    19. 19. Existing attempts not strict enough (SpringSource) </li></ul><li>Wrap Eclipse stuff too! </li><ul><li>Eclipse typically uses Require-Bundle instead of Import-Package
    20. 20. Once you redo bundles, you have to build new features.... </li></ul><li>We built a validation tool... </li><ul><li>Scans byte-code to make sure that all needed packages have been imported.
    21. 21. … and enforces other best practices (naming, versions, etc.) </li></ul></ul>
    22. 22. What about version #s? <ul><li>Version numbers are customer facing!
    23. 23. Only first three parts of version # matter </li><ul><li>Impractical to maintain Import-Package constraints that vary qualifier
    24. 24. IDE tooling doesn't support it </li></ul><li>Yet we maintain four distinct branches: </li><ul><li>Major, minor, service pack, “hot fix” -> version space is incomplete
    25. 25. Solution: A.B.100 is a “service pack” A.B.1, A.B.2 are “hot fixes” </li></ul><li>Built tools for: </li><ul><li>Checking version number consistency against what's GA'd
    26. 26. Bumping version numbers consistently. </li></ul></ul>
    27. 27. We've developed our own build infrastructure and tooling. <ul><li>Numerous “update sites” </li><ul><li>Capturing release/debug builds
    28. 28. “Stable” vs. “unstable”
    29. 29. Eclipse specific sites (Eclipse 3.2, Eclipse 3.3, Eclipse 3.4, …) </li></ul><li>Leveraged existing PDE builder & Ant
    30. 30. Built tooling to create “target platforms” </li><ul><li>See my presentation from EclipseCon 2009
    31. 31. Must generate dynamically for agility </li></ul><li>Internal web site for: </li><ul><li>Analyzing products/features/bundles
    32. 32. What's used by what?
    33. 33. What's shipped?
    34. 34. What's in the pipeline? </li></ul></ul>
    35. 35. How do we present “deployment” to our users? <ul><li>Customers don't want to see individual bundles </li><ul><li>Want product “features”
    36. 36. “functionality” always larger than Eclipse features </li></ul><li>Our customers want stable environments </li><ul><li>Updating bundle X must not affect bundle Y
    37. 37. So OSGi dynamism not a key capability
    38. 38. Sometimes, you just need a separate JVM </li></ul></ul>What customer wants to see Products, features, bundles
    39. 39. Dual-targets, huh? And why? <ul><li>Some bundles are the same </li><ul><li>EMF-based models, utility classes, validation code, need to work in both Eclipse and runtime </li></ul><li>Runtime metadata doesn't work with Eclipse </li><ul><li>“Import-Package” in conjunction with “Require-Bundle” can be bad </li></ul><li>Bundles only need to be dual target... </li><ul><li>When importing a package provided by Eclipse environment
    40. 40. When using javax.* packages </li></ul><li>Consequence: We need a parallel set of feature & plugin metadata! </li></ul>
    41. 41. What did we do to accommodate Eclipse? <ul><li>Conventions:
    42. 42. To reduce complexity </li><ul><li>Same exact version number
    43. 43. No code rebuilt, just metadata changes
    44. 44. Developers only provide alternate bundle MANIFEST.MF </li><ul><li>feature.xml file are generated </li></ul></ul></ul>feature.foo_1.0.0 bundle.foo_1.0.0 feature.foo.eclipse_1.0.0 bundle.foo.eclipse_1.0.0
    45. 45. We need a common Eclipse environment..., but we could be doing more... <ul><li>Examples: </li><ul><li>Need a team using same version of EMF, version control plugin
    46. 46. Want everyone using code coverage tools, static analysis tools
    47. 47. Efficiency – preconfigured Mylyn, integration with our automated systems. </li></ul><li>Caveats: </li><ul><li>A single company-wide mandate doesn't work
    48. 48. Different branches require different versions of EMF
    49. 49. Each team wants one or more configurations...
    50. 50. Preferences for different tool sets </li></ul><li>Still need to... </li><ul><li>Figure out best way to share/compare configurations
    51. 51. Get developers up-to-speed quickly </li></ul></ul>
    52. 52. Where do we go from here...? <ul><li>Community conventions on using OSGi? </li><ul><li>Common versioning expectations?
    53. 53. Import-Package everywhere? </li></ul><li>Bundle grouping </li><ul><li>“features” - not quite right
    54. 54. OSGi Alliance might help with an “application” notion </li></ul><li>Build infrastructure </li><ul><li>Tooling that builds a target platform from OSGi metadata? </li></ul></ul>
    55. 56. References <ul><li>Artwork: </li><ul><li>Slide 2 boot: http://www.openclipart.org/detail/826 , house: http://www.openclipart.org/detail/177
    56. 57. Slide 3 stop: http://www.openclipart.org/detail/13218 , dancers: http://www.openclipart.org/detail/23585
    57. 58. Slide 4 ant: http://www.openclipart.org/detail/66
    58. 59. Slide 8 box: http://www.openclipart.org/detail/1509 , checkmark: http://www.openclipart.org/detail/25208
    59. 60. Slide 15 road: http://www.openclipart.org/detail/14720
    60. 61. Slide 16 question mark: http://www.openclipart.org/detail/28725 </li></ul><li>Content </li><ul><li>EclipseCon 2009 talk: http://www.eclipsecon.org/2009/sessions?id=587
    61. 62. Version qualifiers thread: http://markmail.org/message/xwzjddhdeqsmzhgb </li></ul></ul>

    ×