• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Next-Generation Enterprise Application Development with SpringSource dm Server (formerly known as SpringSource Application Platform)
 

Next-Generation Enterprise Application Development with SpringSource dm Server (formerly known as SpringSource Application Platform)

on

  • 2,958 views

White paper regarding SpringSource dm Server and the changes it brings to Java / JavaEE landscape.

White paper regarding SpringSource dm Server and the changes it brings to Java / JavaEE landscape.

Statistics

Views

Total Views
2,958
Views on SlideShare
2,949
Embed Views
9

Actions

Likes
1
Downloads
0
Comments
0

2 Embeds 9

http://www.lmodules.com 8
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Next-Generation Enterprise Application Development with SpringSource dm Server (formerly known as SpringSource Application Platform) Next-Generation Enterprise Application Development with SpringSource dm Server (formerly known as SpringSource Application Platform) Document Transcript

    • Capgemini India Private Limited Next-Generation Enterprise Application Development with SpringSource™ Application Platform Aditya Jha Page 1 of 7
    • Capgemini India Private Limited Introduction The Java, Enterprise Edition (formerly, J2EE) landscape has always been dynamic; constantly updating itself to cater to requirements driven by the Java community. Just like other worthy open-source ventures, it has maintained its status-quo as largely a community-driven endeavor. Most of the changes to this landscape have been called for by developers worldwide, for whom not only the Java EE is the very bread and butter, but also a means of expressing their creativity. It’s no surprise that with the latest version of Java EE, the platform has taken an entirely new shape, whereby features like Dependency-Injection and Annotation-driven drop-and-play components have become standard practice. However, the changes remain largely in the area of construction of enterprise software. An area equally important, if not more, is that of Application Packaging & Deployment. Unfortunately, not much progress has been recorded in terms of packaging formats, deployment techniques, administrator’s ease-of-use and standard ways of software versioning. Let’s face it – We might start writing POJO-based EJBs and Web-Services without a single XML descriptor, but we will still use the old method of WARing and EARing our application in order to deploy it to a container of our choice. And I’m not even counting any container-specific tasks that may be required to carry out as part of the process. Have the authorities been too busy to listen to the growing resentment in community? Not really. There is JSR 277 in pipeline (anticipated in JDK 7), which might prove to have the answers to some of the questions below. However, as explained further in the document, it is sort-of reinventing the wheel due to the fact that a proven, reliable technique is already there, and the folks in community have been using it for ages; only, not knowing that it could be the very answer they are looking for. Issues with current state of Java/JavaEE Application Packaging & Deployment Consider the following cases, and try to reason plausible solutions:  Is hot-deployment a reality? How confident are you as a developer with regards to memory footprint and resource loading of server in cases of hot-deployment?  Module ‘A’ of your application has a critical flaw in its configuration files. Would it be possible to redeploy a single module without bringing down the whole system? Consider advantages this could provide in a scenario where the target server is on the other side of the globe, and it takes 30+ minutes to transfer your complete application-archive. Page 2 of 7
    • Capgemini India Private Limited  Is there a standard way of versioning your application? Is it possible from the server console to query/manage the version-number of your application?  How about versioning individual modules (for ex., Domain, Services, Web etc.) of your application?  Module ‘A’ of your system depends on version 1.1 of library ‘L’. Module ‘B’ depends on version 1.2 of the same library. Is it possible to satisfy such a requirement within the same application? Consider that module ‘A’ might be incompatible with version 1.2 of library ‘L’.  You have two web-applications in two different EARs. Both require 15 third-party JARs? Is there a standard way to share the dependencies, such that each WAR need not be bloated with libraries? To take the idea further, is it possible to use some kind of a global/organization-level repository of libraries, with only the declarative dependencies mentioned in application/module meta-data?  Is it possible to expose your POJO services without requiring consumer of these services requiring to ‘approach’ or ‘obtain’ them (WSDL, JNDI)? How about Dependency-Injection on a Library-level, or even Service-level?  You have package ‘com.acme.myapp.service’ in your Service module, defining façade interfaces for services. Corresponding implementations are in the same module JAR in a package titled ‘com.acme.myapp.serviceimpl’. You want to expose only the interfaces to other modules of the system. Is this possible in the current scheme of packaging formats? Consider that the implementation classes might need to be ‘public’ because of framework reasons (Spring-beans, EJB etc.).  How clearly can you represent the boundaries and interfaces of individual modules in your application? Is there standard tooling possible which can read the meta-data of the application and present a module-level interaction report? There have been attempts by individual server vendors to address some of these problems. However, there remains a need of standard, proven ways to provide a generic meta-data facility in Java/JavaEE modules along with generic standards for packaging and easy deployment, thereby resolving the above mentioned issues. The resolution of above mentioned issues can be classified into two major groups – A robust packaging and versioning technique, and an infrastructure to support, manage and take advantage of such packaged modules/applications. Page 3 of 7
    • Capgemini India Private Limited Resolution of Packaging and Versioning Issues For quite some time in past, Java community has been using a sophisticated, proven and extensible technique of managing meta-data at module-level. This technique not only solves the existing problems, but also enables us to future-proof our packaging strategies. Think about it – we have been installing/creating several plugins in our Eclipse™ environment. Plugin ‘A’ might require version 1.0 of plugin ‘B’. Plugin ‘C’ might require version 1.1 of plugin ‘B’ itself. These requirements (and others) have been successfully, reliably and extensibly fulfilled by adopting a common format for packaging and meta- data specification. This format is called Open-Source Gateway initiative (OSGi). The OSGi format is a standard, open format specified by the OSGi Alliance Group. As per the OSGi website (http://www.osgi.org/), “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”. OSGi format uses standard JAR format to define components of an application. These components are termed as ‘bundles’ and each bundle has its meta-data in a standard format in file META-INF/manifest.mf. Thus, the manifest file of each bundle (JAR) will provide the following:  Name and version of the module  Type of module  Dependencies required for the module  Public interface (exposure) of the module The component of Spring portfolio which helps in working with OSGi bundles is named as Spring-DM (Dynamic Modules). This is a separate framework, independent of other frameworks in the portfolio. The OSGi technology resolves the following problems:  It gives a standard way of versioning individual modules of an application.  Dependencies (package/library/service) can be defined in a clear, unambiguous and consistent manner.  It provides greater control over the public interface of individual modules, by providing a layer of encapsulation. Packages needed to be exposed can be explicitly specified. The boundary and interfaces of a module are cleanly defined. Page 4 of 7
    • Capgemini India Private Limited Resolution of Infrastructure Issues Having a common, stable and extensible packaging format is good, but it’s not the end of the story. If we still have to do all the version-resolution and dependency management tasks ourselves, it won’t do much of a benefit, would it? This is where SpringSource™ Application Platform (S2AP) comes into picture. The 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. It not only manages the lifecycle and dependency management for OSGi modules, but also supports the standard Java EE WAR (Web ARchive) format as a first- class citizen. There’s more to it – The S2AP is not really a new server (which has to prove its worth), rather it’s actually a Spring-DM kernel/runtime over Apache Tomcat, the leading Java EE web-server in industry. Thus, you get all the reliability, community support and robustness of a proven server infrastructure underneath the S2AP. OSGi standard + Spring-DM + Apache Tomcat = SpringSource™ Application Platform The SpringSource Application Platform is based on the new SpringSource Dynamic Module Kernel™ (dm-Kernel). The dm-Kernel provides a module-based backbone for the server, which also harnesses the power of Spring, Apache Tomcat and OSGi-based technologies. Reference to SpringSource™ Application Platform can be found at the official website - http://www.springsource.com/products/suite/applicationplatform. S2AP helps in resolving the following issues:  Hot deployment (even on production) becomes a reality. It provides complete control over an application and its constituent modules. Individual modules or even the application as a whole can be deployed at runtime. Even the so-called ‘pre-deployed’ applications are actually sensed and deployed in the truest sense at runtime only.  Provides out-of-the-box support for OSGi bundles. S2AP is fully aware of corresponding standards and is able to read, manage and use the application meta-data specified in manifest files.  Provides dependency-injection at three levels – package level, library level and service level. Respects and validates cleanly separated boundaries of individual modules as per their meta-data.  Supports the notion of centralized repository for bundles/libraries.  Coupled with SpringSource™ Tool Suite (STS), provides an integrated, comprehensive development environment with easy-to-use tools. Page 5 of 7
    • Capgemini India Private Limited Migration from standard WAR format to OSGi format S2AP supports deployment of an application packaged in the following formats. These formats or different ways of packaging an application are also known as ‘Personalities’:  Standard WAR format  OSGi Bundle (Web-module or Standard-module) o Shared Libraries format o Shared Services format  PAR (Platform Archive) format OSGi bundles are classified into two types – Web and Standard. Web bundles are having the UI code, such as JSPs, MVC artifacts etc. (akin to a WAR), whereas Standard bundles are either services or utility bundles (akin to normal JARs in an enterprise application). The WAR (Web ARchive) Format As mentioned previously, a standard Java EE WAR format is directly deployable in S2AP. Naturally, if the application depends upon server-specific arrangements (connection-pool, security-settings), the same have to be configured on S2AP as well. To make the application completely portable, Spring encourages usage of Spring Security framework and open-source, reliable connection-pooling frameworks (such as C3P0 or Apache Commons DBCP). These not only make the application package completely portable (drop-n-deploy), but also provide some new features, all in the familiar Spring-bean style of configuration. Shared-Library Format The first step towards standardization is to pull out all the JARs from WEB-INF/lib, thereby solving the library-bloat problems commonly found in web-applications. Instead, dependency markers are put in manifest file to indicate which JARs are needed at runtime. Please note that you do not have to put markers for transitive dependencies, if your direct dependencies are in OSGi format themselves. To facilitate this better, equivalent OSGi bundles for various commonly used APIs have been provided in an Enterprise Repository hosted by SpringSource™ (http://www.springsource.com/repository). Compatible tooling provided by STS ensures that these markers are understood at development time as well in order to resolve compilation issues. Thus, the effective memory-footprint of web-application reduces to a great extent. This format is called the ‘Shared-library’ format. Page 6 of 7
    • Capgemini India Private Limited Shared-Services Format The next step is to structure the application by dividing it into parts with clear, defined and explicit boundaries. An application may be divided into parts either by aspects (Domain, Services, Web etc.) or use-cases (InsertData, UpdateData etc.), or both. In both cases, a valid division is not expected to have cyclic dependencies among its constituent parts (or modules). Each of these modules is an OSGi bundle, having its own meta-data and can be deployed/redeployed independently (provided dependency among modules is taken care of). Thus, the services module can be reused in different modules, across applications. This is possible because an OSGi bundle in itself is a deployable and hence, exposable unit for S2AP. The original web-application’s footprint becomes even smaller. This format is called ‘Shared-Services’ format. PAR (Platform Archive) Format The final step towards PAR format is to identify related modules of an application and pack them as a single unit of deployment, known as Platform Archive, or PAR format. The PAR is simply a JAR file containing its constituent modules (OSGi bundles). The PAR not only provides a packaging layer for the whole application for the purpose of atomic deployment/undeployment, but also provides a synthetic scope for the whole application. In other words, it provides a layer of encapsulation, so that two similar modules (residing in different PARs) do not collide with each other. Summary SpringSource™ Application Platform brings the much-needed changes in enterprise- application development, packaging, versioning and deployment processes. It presents a refreshing, new and powerful way of merging OSGi standard with the mainstream development and deployment processes. It further enhances reuse by promoting reusable services and centralized repository of libraries. SpringSource™ Application Platform has reached ‘Release Candidate’ beta version and is about to be available for production very soon. In my humble opinion, this will be a deserving force to reckon with for standard Java EE application-servers. All in all, definitely a good news for Java community. Page 7 of 7