GlassFish Server Open Source Edition 3.1 - Metro

Introduction

There are 3 main focus areas for the Project Metro in scope of GF 3.1:

• High availability
  • focused on RM and SC session failover
  • optional: stateful WS failover
• Architectural cleanups
  • unified configuration
  • proper split into modules/mavenization
  • other cleanups and updates (removing GFv2 dependencies, dropping support for transactional WS, compiling against Java 6, etc.)
• Interoperability (WS-I, .NET 4.0, other Oracle stacks)

Scope

Feature Overview

Policy Alternatives

The goal is to support multiple alternatives for authentication (username password or SAML token, etc.).
We see less demand for alternatives outside of the security domain, so the scope of this feature is to support alternatives just for security assertions/authentication mechanisms.

Metro High Availability Support

Metro WS stack provides certain stateful features, such as secured conversation, reliable messaging or stateful web services. To support the stateful features in a clustered environment we need to identify all the state information that needs to be saved and replicated and update Metro implementation to support the state saving as well as state recovery from a replica in case of a node failure.

NOTE: Our focus is primarily on HA support in the areas of SC and RM. Optionally, we may be supporting HA for stateful web services. We do NOT plan to support HA for transactional WS as the feature, in its current implementation, is already proposed for dropping completely from the Metro stack.

WS-I Compliance

In addition to standardized WS-* specification, WS-I organization is chartered to define a set of interoperability profiles that attempt to resolve ambiguities of the original WS-* specifications to improve interoperability. The goal is to support these profiles in Metro. We need to develop a sets of predefined test scenarios for each supported WS-I profile and validate the compliance by successfully passing these test cases against our own implementation as well as against implementations of other vendors (MS, IBM). The actual test scenarios in RSP and BSP domains will be implemented by external contractors.

Mavenization

Currently, the Metro build process is ant-based and is tightly integrated into the build of WSIT/Tango. As a project with a significant number of dependencies, dependency management becomes more and more challenging. At the same time, Metro needs to provide maven artifacts to correctly integrate with GF.

In this effort we aim to decouple Metro and WSIT builds and switch the build system from ANT to MAVEN to better align our build system to the one used by GFv3. As a result, we plan to achieve a transparent and simplified dependency management, improved modularization of the code, natural identification of inter-module dependencies and (internal) APIs as well as reduced cost of build and RE maintenance.

Unified Configuration

As part of this feature we plan to introduce a new single configuration file for all domains and all configuration options of the Metro stack as opposed to current approach that may require users to use multiple configuration files to configure a single web service. The new configuration file format should also be better aligned with the standard webservices.xml format as defined in JSR109. As part of the feature we plan to design mechanisms that would allow us to provide unified support for other deployment descriptors, with an initial focus on the support for the WebLogic Web Services deployment descriptor.

Support for Error Handling in WS-Trust

Standard error codes are introduced in WS-Trust/SC spec. We will use some of them as thrown by the server to enable automatic session renew to avoid that the user transaction being interrupted.

Time Skew for WS-Trust and WS-SecureConversation Token Lifetime

Issued tokens and security contexts are only valid in a period of time. We will add support for configuring skew of time for the difference allowed for the system clocks of the sender and recipient. Used in case that the clocks may not be in sync.

Servlet 3.0 Async Support

Servlet 3.0 has asynchronous support and it can be used to process a HTTP request using multiple threads. Servlet 3.0 + AsyncProvider will provide a scalable solution on the server side. This can also be used to evaluate SEI async support proposal 787. This doesn't affect servlet 2.x deployments.

Test harness support for GlassFish v3.x

JAX-WS unit tets can be run in multiple enviornments: Tomcat, GlassFish v2, in-vm, lwshs, JaxwsInJDK. Test harness will be extended so that JAX-WS/Metro unit tests can also be run on GlassFish v3.x.

wsimport -clientjar option

Client side programming model involves creating a Service object and that in turn fetches WSDL during service creation. There are few solutions to avoid this(using catalog), but they are not complete. The proposed switch gets the WSDL/schemas, fixes the import locations, jars all the generated artifacts. Generated service is also modified to refer to the WSDL in the jar file.

Design Document

• Please see the Metro 2.1 One Pager

Milestone Schedule

Task List

Dev Tests

• Coming soon

References

• GlassFish v2.x CLI Commands
• GlassFish v2 Cluster Architecture

Email Alias

• Please contact us at dev@glassfish.java.net