SpringSource dm Server (formerly known as SpringSource Application Platform)

1,333 views

Published on

A presentation about SpringSource dm Server and the changes it brings to Java / JavaEE landscape.

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

No Downloads
Views
Total views
1,333
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

SpringSource dm Server (formerly known as SpringSource Application Platform)

  1. 1. SpringSource Application Platform Aditya Jha
  2. 2. Introduction <ul><li>Java, Enterprise Edition has undergone major changes in recent times </li></ul><ul><li>Most of the changes are in the area of construction of enterprise software </li></ul><ul><li>An area equally important is that of Application Packaging & Deployment </li></ul><ul><li>Disparate forms of packaging (JAR, WAR, EAR) have been existing since the childhood of relevant technologies, with little or no improvement with changing times </li></ul><ul><li>Need to rethink packaging & distribution strategy to make it simpler, more controlled and extensible and modern </li></ul>
  3. 3. Introduction contd… <ul><li>They have heard – JSR 277 in pipeline </li></ul><ul><li>Attempts for a unified standard format of packaging </li></ul><ul><li>Natural support for headless service applications needed </li></ul><ul><li>Defining modular boundaries of enterprise application and a clear picture of their dependency graph is required </li></ul><ul><li>Individual middleware vendors tried to address some of the issues; however, a standard resolution is needed for portability </li></ul><ul><li>We already HAVE the answer – we just need to IDENTIFY it as the answer to our questions </li></ul>
  4. 4. Issues with Java/JavaEE Application Packaging & Deployment <ul><li>Hot-deployment? Is it really hot or lukewarm? </li></ul><ul><li>Redeploying a single module of an enterprise application? </li></ul><ul><li>Application versioning; individual Module versioning? </li></ul><ul><li>A -> B -> Cv1; A -> Cv2 – Natural, but is it easy? </li></ul><ul><li>Library bloat – monolithic archives. How to avoid? </li></ul><ul><li>Exposing POJO services – WITHOUT needing the client code to know how to obtain them (WSDL, JNDI)? </li></ul><ul><li>Selective exposure of packages from an archive? </li></ul><ul><li>Clear representation of boundaries and interfaces of individual modules? Standard meta-data? </li></ul>
  5. 5. Resolution <ul><li>Resolution of these issues can be categorized into two parts </li></ul><ul><li>Formulating a robust packaging and versioning technique with extensible meta-data facility </li></ul><ul><li>A standard infrastructure to support, manage and take advantage of such packaged modules or applications </li></ul>
  6. 6. Resolution of Packaging and Versioning Issues <ul><li>For quite some time in past, Java community has been using a sophisticated, proven and extensible technique of managing meta-data at module-level </li></ul><ul><li>This technique not only solves the existing problems, but also enables us to future-proof our packaging strategies </li></ul><ul><li>The Open-Source Gateway initiative (OSGi) has proven its worth in Eclipse platform and other ways </li></ul><ul><li>The OSGi technology provides the standardized primitives that allow applications to be constructed from small, reusable and collaborative components. These components can be composed into an application and deployed </li></ul>
  7. 7. Resolution of Packaging and Versioning Issues contd… <ul><li>OSGi format uses standard JAR format to define components of an application </li></ul><ul><li>These components are termed as ‘bundles’ </li></ul><ul><li>Each bundle has its meta-data in a standard format in file META-INF/manifest.mf </li></ul><ul><li>Manifest file of each bundle (JAR) will provide </li></ul><ul><ul><li>Name and version of the module </li></ul></ul><ul><ul><li>Type of module </li></ul></ul><ul><ul><li>Dependencies required for the module </li></ul></ul><ul><ul><li>Public interface (exposure) of the module </li></ul></ul><ul><li>Spring-DM (Dynamic Modules) understands OSGi </li></ul>
  8. 8. OSGi Helps <ul><li>Provides a standard way of versioning individual modules of an application </li></ul><ul><li>Dependencies (package/library/service) can be defined in a clear, unambiguous and consistent manner </li></ul><ul><li>Provides greater control over the public interface of individual modules, by providing a layer of encapsulation </li></ul>
  9. 9. Resolution of Infrastructure Issues <ul><li>Need for infrastructure – Server as well as tooling </li></ul><ul><li>SpringSource™ Application Platform (S2AP) and STS </li></ul><ul><li>S2AP is a completely module-based Java application server that is designed to run enterprise Java applications and Spring-powered applications with a new degree of flexibility and reliability </li></ul><ul><li>Manages the lifecycle and dependency management for OSGi modules </li></ul><ul><li>Supports the standard Java EE WAR format as a first-class citizen </li></ul>
  10. 10. Resolution of Infrastructure Issues S2AP & STS <ul><li>Best part - S2AP is not really a new server (which has to prove its worth) </li></ul><ul><li>It’s actually a Spring-DM kernel/runtime over Apache Tomcat </li></ul><ul><li>OSGi standard + Spring-DM + Apache Tomcat = SpringSource™ Application Platform </li></ul><ul><ul><li>References can be found at http://www.springsource.com/products/suite/applicationplatform </li></ul></ul>
  11. 11. S2AP Helps <ul><li>Hot deployment (even on production) becomes a reality </li></ul><ul><li>Provides out-of-the-box support for OSGi bundles </li></ul><ul><li>Provides dependency-injection at three levels – package level, library level and service level </li></ul><ul><li>Supports the notion of centralized repository for bundles/libraries </li></ul><ul><li>Coupled with SpringSource™ Tool Suite (STS), provides an integrated, comprehensive development environment with easy-to-use tools </li></ul>
  12. 12. Migration from standard WAR format to OSGi format <ul><li>S2AP supports deployment of an application packaged in the following formats </li></ul><ul><li>These formats or different ways of packaging an application are also known as ‘ Personalities ’ </li></ul><ul><ul><li>Standard WAR format </li></ul></ul><ul><ul><li>OSGi Bundle (Web-module or Standard-module) </li></ul></ul><ul><ul><ul><li>Shared Libraries format </li></ul></ul></ul><ul><ul><ul><li>Shared Services format </li></ul></ul></ul><ul><ul><li>PAR (Platform Archive) format </li></ul></ul><ul><li>OSGi bundles are classified into two types – Web (akin to WAR) and Standard (akin to JAR) </li></ul>
  13. 13. Summary <ul><li>SpringSource™ Application Platform brings the much-needed changes in enterprise-application development, packaging, versioning and deployment processes </li></ul><ul><li>Presents a refreshing, new and powerful way of merging OSGi standard with the mainstream development and deployment processes </li></ul><ul><li>Further enhances reuse by promoting reusable services and centralized repository of libraries </li></ul><ul><li>A welcome enhancement to the options in Java EE middleware market </li></ul>
  14. 14. Thank You

×