JEE Packaging & Assembly vs. OSGi - but what about the Cloud?
•
0 gefällt mir•1,013 views
PLEASE READ THE SLIDE NOTES TO FIND MORE DETAILS TO THE STATEMENTS. Sum up where traditional monolithic JEE applications fail in packaging and assembly compared to modern OSGi applications that can be built in an µSOA style. In times of cloud applications a modularized and well structured application with clearly defined dependencies and scopes is the way to go.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Empfohlen
Empfohlen (20)
JEE Packaging & Assembly vs. OSGi - but what about the Cloud?
- 1. OpenWMS.org Technology JEE Packaging & Assembly vs. OSGi - but what about the Cloud? scherrer@openwms.org
- 2. Topics • Preface • Get on Stage - with JEE • Problem area JEE • OSGi is the Balm! • Where OSGi fills the Gaps • What does it cost? scherrer@openwms.org
- 3. Preface • JEE is a platform specification - not an application framework • JSR-316/EE.8: Assembly & Deployment scherrer@openwms.org
- 4. Get on Stage - with JEE • Packaging Types • Package Visibility • Versioning } Maintainability scherrer@openwms.org
- 5. Problem area JEE • Packaging Types ‣ Monolithic single unit deployment ‣ Classloader interferences scherrer@openwms.org
- 6. Problem area JEE • Visibility ‣ The missing types in Java • Versioning ‣ Fixed versions + ranges scherrer@openwms.org
- 7. Problem area JEE • Location transparency ‣ Service Binding, Protocols, Nodes • Elastic Cloud Services? • Dynamic Service Availability • Granularity - µSOA scherrer@openwms.org
- 8. OSGi is the Balm! • OSGi targets to build modularized applications with • OSGi also defines a stack of application services • OSGi addresses NFR like Manageability, Availability, Scalability, ... scherrer@openwms.org
- 9. OSGi is the Balm! • Your application does actually not know that it runs on OSGi! ‣ Deployment transparency • Consumers don’t care about service availability at all (damping) ‣ Tolerance towards Availability scherrer@openwms.org
- 10. OSGi fills the Gaps • Types of Packaging • Package Visibility + Versioning • Clearly defined Classloaders • Location Transparency scherrer@openwms.org
- 11. OSGi fills the Gaps • Service Availability • Granularity scherrer@openwms.org
- 12. What does it cost? • Decompose your Ghosts • Define Component Maps (Subsystems) • OSGi still lacks on Acceptance scherrer@openwms.org
Hinweis der Redaktion
- \n
- \n
- Even JEE defines the whole platform itself including API, SPI, roles and responsibilities as well as some kind of processes it should also take care in detail about the assembly and deployment process\n\nThe most important part of the JEE umbrella specification we take in account here cares about Assembly & Deployment. That chapter itself would be enough to move into a separate JSR!\n\n
- Show up how today traditional JEE applications looks like:\n\nJEE defines a couple of packaging types that are used to deploy varying application artifacts in terms of JEE. In common, all of them are just archives that bundle other archives with some kind of Java types and have a well defined classloading mechanism.\nPackage Visibility: JSE/JEE defines a too coarse-grained package visibility mechanism. Means, defining dependencies between packages by extending the META-INF/MANIFEST.MF/Class-Path or by putting an archive in a folder that’s visible to all other libraries in the application\nVersioning: Currently there is no way to define versions between JEE module dependencies\nMaintainability: The existing packaging types together with the visibility concept and the lack of versioning has an impact on the maintainability of large enterprise applications\n
- Single unit deployment: In case of bugfixes or new features, the whole application (unit) has to be redeployed. This results in complex deployment strategies with multiple isolated tracks or complex cluster environments just to avoid downtimes and keep availability on a maximum, but with the loss of maintainability and reliability. There is no well-defined solution how a single service can be redeployed properly without the need to stop the whole world application and affecting all other services.\nClassloader interferences: An application has to package its dependencies. This leads to huge deployment units that have almost all libraries in. However each enterprise application has it’s own classloader, there can be interferences between classes that are already deployed on the system classpath as well. Documenting the purpose, the version and all depending libraries of a 3rd-party library that is packaged along the application, does not take place and is somehow cumbersome!\n
- Visibility: Only 4 types of visibility exist in Java. There is currently no type to explicitly restrict the visibility of Java types (like packages/interfaces/classes), to other modules. Due to the lack of a more fine-grained visibility concept, modules of an application have access to modules or libraries or inner private-view classes of those, they usually shall not have access to. Dependencies, used library versions and the purpose of existence for all packaged libraries are hard to document and to maintain.\nVersioning: Because there is no concept in JavaSE/EE to define dependencies between Java modules (archives like JARs), it is also not possible to define versions along these dependencies. Versioning and visibility (-dependency) declaration are associated with each other.\n
- Location transparency: Service consumers need to know about the assembly and deployment environment of provided services. There is no global service registry in JEE where services can be registered with logical names solely without any deployment specific name prefixes. Clustered runtime environment behave like slaves to a master cluster node. Location transparency requires that all actively participating cluster members are peers and services are available regardless the protocol they were exposed to others, nor on which node they currently run on. This is still not solved in JEE6.\n\nElastic Cloud Services: How elastic are typical JEE applications nowadays? There is no ability to scale, neither horizontal nor vertical, at runtime depending on the current system load, in an elastic way. What does elastic in these terms means? Elastic means, that resources are managed dynamically. Resources like CPU and memory are shifted around, server instances are started and shut down on demand and service pools are increased and decreased as required. This is not completely impossible for JEE server environments, but common available services have to be designed to work that way, too. This has to be solved by application frameworks on their own.\n\nDynamic Service Availability: In real distributed enterprise environments, services can come and go. For enterprise applications, that demand a maximum of general availability, it is absolutely unacceptable that redeployments of single services force a shutdown of the whole application. Whenever a service is not available, the managing (enterprise !) runtime environment has to care about buffering of outstanding method calls for a certain amount of time, before the caller runs into an processing error (damping).\n\nGranularity - µSOA: Years ago, I invented the term µSOA when I talked about the OSGi platform itself, because it has so many similarities to the well-known concept of SOA. But the main difference is, that you’re going to use heterogenous services in a SOA but in OSGi you are using services implemented in plain Java only. Nevertheless the concept of service orchestration shall be valid for JEE applications as well, no matter how an application is packaged and deployed at runtime. But in reality the way an application is packaged and deployed to the server prevents from a clearly concept of separation. The granularity of the application becomes blurred and promiscuous.\n
- Initially (1999) OSGi was established to build modularized applications with. Other functional features like application services were introduced later on.\nA couple of architectural principles as well as NFR are fulfilled due to the strict concept an OSGi application is following to separate its parts into logical modules with highest cohesion and absolutely minimized coupling. BTW: OSGi is not a product it is a specification formed by many popular companies around the Java technology.\n\nApplication Services: Compared to JEE, that is a platform specification, OSGi defines the most important application services that are used in enterprise applications. That means, services like Configuration, Logging, Event and more are provided by the certified OSGi enterprise server out of the box and take care of all features that are specified by the OSGi Blueprint specification. That means, applications can built thin facades around these enterprise services to become nearly OSGi independent but they can heavily benefit from these managed distributed services.\n\n\n
- Deployment transparency: Write once, run anywhere! Focus on your business logic, not on infrastructure stuff! After your service is engineered, it is exposed as OSGi Service. How this works? With enterprise add-ons that are shipped with the popular OSGi enterprise servers. Developers declare how there services are exposed to others, depending on the runtime environment. In OpenWMS.org we have developed plain Java interfaces without any technical framework metadata that are implemented by POJOs (Plain Old Java Objects). Those classes can then be exposed as webservices, OSGi Services or what ever you want (just depending on the underlying runtime). This keeps your business logic clean from OSGi or other technical stuff.\n\nService availability: In real OSGi environments, the managing OSGi server cares about service outages - not your code! In earlier days, service consumers had to code controller logic tied to OSGi, that handles those service outages. Nowadays, the OSGi servers buffer method calls between service consumer and service provider. Each time a provided services becomes unavailable, the OSGi enterprise server (with delivered enterprise extensions) buffers method calls to that service for a configurable amount of time. After that time period (e.g. 5 minutes) the OSGi server returns an exception to the caller. This is usually enough time for service redeployments or enrollments. This effect is called damping.\n
- Types of Packaging: OSGi knows about bundles. Bundles are in almost all cases simple JAR files with Java types of high cohesion are packaged together. Bundles do not bundle other bundles!\nPackage Visibility: OSGi clearly defines a fine-grained visibility mechanism. A bundle defines the Java types (packages/interfaces/classes) that are exposed to other bundles. This is achieved in the bundle’s meta-data technically - and not through architectural or developer guidelines. There are no additional OSGi specific deployment descriptors, all is kept in the standard MANIFEST.MF of the bundle JAR.\nVersioning: In addition to the feature how Java types are exported to other bundles, resp. imported from other bundles, OSGi offers the concept to define fixed versions as well as version ranges for dependencies.\nClassloaders: Each bundle has it’s own classloader. The classpath of each bundle classloader is clearly defined to the scope of the bundle plus all Java types that are defined to be imported from other bundles.\nLocation Transparency: In the past, there where no clear concept how to build OSGi applications that consist of services/bundles distributed over several JVM. One of the most important projects that handles these needs is the R-OSGi project from the ETH Zurich university. The key concept is again, the application does not need to know about infrastructure and where depending services are running on. It’s just a matter of how these services were exported and how they gonna be imported again.\n
- Service Availability: In the nature of OSGi there are no huge deployment units. Only things that belong together and bundled and delivered together. But all bundles (part of the whole application) has to work together in a network of peers. It has no influence to a service consumer when a service fails or is not available anymore. The OSGi runtime environment cares about the service outage and buffers method calls for a certain amount of time. Usually this time is used to redeploy a patched service with a different version.\nGranularity: Due to there exist only bundles that work together in a network of peers and the concept of application assembly (packaging, versioning, visibility) are clearly defined, the granularity of an OSGi application is extremely high. This might not always be an advantage, and there must be a trade-off between single unit deployments and applications that are split into hundreds of small bundles. In the OSGi specification R5 (03.2012) the community has defined other packaging types, so called subsystems, to group bundles together logically. For example a subsystem can be a simple descriptive file that lists all bundles that belong to an application.\n
- Decomposition: The task of decomposing an existing application into a well-structured OSGi application should not be underestimated. But this is a task you should always work and improve on - even without OSGi.\n\nSubsystems: This term is new to the OSGi specification and was originally introduced by the Springframework team that were working on their OSGi extension Spring Dynamic Modules. Grouping multiple OSGi service (bundles) into larger subsystems is just a job of defining the application architecture.\n\nAcceptance: Even OSGi is present on the market since 1999, it has not that attention that it should have in the Java enterprise ecosystem. Nowadays modern application frameworks like the Eclipse Gemini project (earlier known as Spring Dynamic Modules) shield developers from implementing against OSGi API. Developers can focus on writing business logic in plain Java, probably with their favorite frameworks. On the server side, many JEE server vendors use OSGi inside their application servers but do not offer the runtime to applications. For example JBoss AS and Glassfish are built on OSGi kernels. The Glassfish application server offers the possibility for JEE applications to connect to deployed OSGi bundles, but this is not that OSGi support that is specified. OSGi certified servers like Spring dmServer, Eclipse Virgo, Apache Felix come with great management support, deployment tools, failover logging and other extended features, but do not have these big companies behind and do also not offer that professional enterprise support that big customers want to achieve\n\n