GlassFish Wiki : V3.1MetroOnePager

The design for Policy Alternatives in Metro 2.1 is being tracked here. The design is work-in-progress and is in intial stages. Please see the risks section of the document.

2.2.2 Metro High Availability Support

Metro HA support has a direct dependencies on the Glassish HA API and depends on the ability of GF HA infrastructure to deal with replication of the unacknowledged SOAP message payloads. While the size of a SOAP message payload is not limited in general, we assume that 90% of the common SOAP messaging use cases can be satisfied by message payloads of size less than 100KB.

Metro HA needs to be able to specify different SLAs for different backing stores and relies on the GF HA API to at least provide the ability to specify different SLAs. Note that Metro HA does not require all the SLAs to be initially supported/implemented by GF HA API.

Metro components are used upstack and all of Metro is used in other containers. Since Metro will introduce a dependency on the GF HA API, it is critical that GF HA API remains be independent of other GF code. This should also ensure that Metro standalone bundle size does not increase unreasonably.

3. Problem Summary

3.1. Problem Area:

3.1.1 Policy Alternatives in Metro Security

The design for Policy Alternatives in Metro 2.1 is being tracked here.

3.1.2 Metro High Availability Support

Nonce manager, Secured conversation and Reliable messaging domains provide stateful conversation. In clustered environment, these states must be properly replicated to provide NM, SC and RM fail-over. We do NOT plan to provide HA support for stateful web services.

3.1.3 WS-I Compliance

The goal is to support latest versions of standardized interoperability profiles and specifications in Metro.

3.1.4 Mavenization

With WSIT/Metro mavenization 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.

3.1.5 Unified Configuration

A new single configuration file capable to capture all configuration aspects of a WS developed and deployed on top of the Metro stack will be introduced.

3.1.6 Support for Error Handling in WS-Trust

Standard error codes are introduced in WS-Trust/SC spec.

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

We will add support for configuring skew of time for the difference allowed for the system clocks of the sender and recipient.

3.1.8 Servlet 3.0 Async Support

We will add an asynchronous transport using Servlet 3.0 API for AsyncProvider endpoints.

3.1.9 Test harness support for GlassFish v3.x

Existing test harness will be extended to support GlassFish v3.x as one of the test platforms.

3.1.10 wsimport -clientjar option

The proposed switch will provide a complete solution for avioding the need to fetch the WSDL/schemas from the remote endpoint during a service creation.

3.1.11 Embedded glassfish and webservices

The jsr 109 devtests will be modified to support deployment in embedded GlassFish

3.1.12 Support Web Logic 109 deployment descriptors

Web Logic application server provides extensions to the standard configuration allowed by JSR-109 deployment descriptors and uses weblogic-webservices.xml for storing such configuration. The goal is to first support the configuration that require minimal work using existing functionality in Metro/GlassFish.

3.1.13 Updating WS-AT implementation to support standard version

Out-dated implementation of pre-standardized version of WS-AtomicTransactions protocol will be updated to support standardized WS-AtomicTransactions protocol/specification.

3.2. Justification:

3.2.1 Policy Alternatives in Metro Security

Product Management has defined Interop Scenarios between Metro 2.1 and OWSM/WLS some of which require support for Policy Alternatives within Metro in the most generic sense.

3.2.2 Metro High Availability Support

Currently, the stateful features in Metro are not usable in clustered environment. Since Metro provides WS runtime for GlassFish, GlassFish HA story cannot be complete without Metro HA support. Our effort in this task aim to address these issues.

3.2.3 WS-I Compliance

To maintain the position of the leading open-source Java WS stack, Metro needs to make sure it is interoperable with other vendors' implementations. The best way how to achieve this is by making sure Metro is compliant with the latest WS-I profiles, namely

BP 1.2/2.0
BSP 1.1
RSP 1.0

3.2.4 Mavenization

Metro/WSIT mavenization should result in 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.

3.2.5 Unified Configuration

Improved developer and system administrator user experience.

3.2.6 Support for Error Handling in WS-Trust

Usability improvement - resolving problems with the user transactions being interrupted in certain cases.

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

Issued tokens and security contexts are only valid in a period of time. The support for configuring skew of time for the difference allowed for the system clocks of the sender and recipient will address the expiration issues in cases when the clocks of a sender and a receiver are not in sync.

3.2.8 Servlet 3.0 Async Support

Servlet 3.0 Async API+ AsyncProvider will provide a scalable solution on the server side. This can also be used to evaluate SEI async support.

3.2.9 Test harness support for GlassFish v3.x

JAX-WS unit tets can be run in multiple environments: 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.

3.2.10 wsimport -clientjar option

There are currently few solutions in the client-side programming model to avoid fetching a rempte WSDL during service creation (e.g. 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.

3.2.11 Embedded GlassFish and web services

This is a requirement in 3.1 to support embedded GlassFish and deployment of web services.

3.2.12 Support Web Logic 109 deployment descriptors

This allows for Web Services developed for Web Logic to run on GlassFish with little intervention.

3.2.13 Updating WS-AT implementation to support standard version

Existing outdated WS-AT implementation will be updated to support widely adopted standard WS-AT version for increased interoperability.

4. Technical Description:

4.1. Details:

4.1.1 Policy Alternatives in Metro Security

The design for Policy Alternatives in Metro 2.1 is being tracked here. The design is work-in-progress and is in its initial stages.

4.1.2 Metro High Availability Support

As part of this feature, Metro HA is intended to be available only on GlassFish 3.1 and later. 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. 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.

Metro needs to run also on containers that are not expected to provide support for GF HA API. To avoid multiple execution paths in the Metro code when running on containers other than GF, Metro will provide an own "NO-OP" implementation of GF HA API, that will be used when running outside GF. As the name suggests, this "NO-OP" implementation will not provide any HA support but will ensure that Metro can internally is able to maintain only a single code execution path that uses GF HA API even if running outside of GF.

4.1.3 WS-I Compliance

We need to develop a sets of predefined test scenarios for each supported WS-I profile and validate the compliance by successfully running 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.

4.1.4 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.

4.1.5 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.

4.1.6 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.

4.1.7 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.

4.1.8 Servlet 3.0 Async Support

ServletAdapter needs to recognize that an application is deployed in a Servlet 3 container, and uses Servlet 3 asynchronous API for AsyncProvider endpoints. It wouldn't affect applications deployed in Servlet 2.x containers. This support will be added for both sun-jaxws.xml and 109 deployments.

4.1.9 Test harness support for GlassFish v3.x

Test harness will be extended to support GlassFish v3.x by using asadmin/REST api.

4.1.10 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.

4.1.11 Embedded glassfish and webservices

For the first pass we will modify our devtests to start glassfish in embedded mode and run our tests and identify the issues. Then we will target on fixing these issues by M5

4.1.12 Support Web Logic 109 deployment descriptors

Web Logic application server provides extensions to the standard configuration allowed by JSR-109 deployment descriptors and uses weblogic-webservices.xml for storing such configuration. The [wiki page|^SupportWLDDInContainers#section-SupportWLDDInContainers-WebservicesWeblogicWebservices.xml] captures the extra configuration elements in weblogic-webservices.xml. The goal is to first support processing weblogic-webservices.xml which contains the standard configuration allowed by JSR-109. Then the possible next step is to support the configuration/features that require minimal work using existing functionality in Metro/GlassFish.

4.1.13 Updating WS-AT implementation to support standard version

Obsolete existing implementation will be replaced by an implementation that provides support for standard version of WS-AT protocol. The new implementation will also deprecate the manual step of deploying wstx-services.war, which is currently required to enable WS-AT support in Metro.

4.2. Bug/RFE Number(s):

4.2.1 Servlet 3.0 Async Support

This transport will help in evaluating(but not resolving) issue 787

4.3. In Scope:

See chapter 4.1 above.

4.4. Out of Scope:

See chapter 4.1 above.

4.5. Interfaces:

4.5.1 Public Interfaces

Unified Configuration

metro-webservices.xml - new single Metro configuration file

Updating WS-AT implementation to support standard version

@Transactional annotation, TransactionalFeature web service feature - programming API enablers of WS-AT feature
wsat:ATAssertion, wsat:ATAllwaysCapability standard WS-AtomicTransaction policy assertions

4.5.2 Private Interfaces

None identified at this time

4.5.3 Deprecated/Removed Interfaces:

None identified at this time

4.6. Doc Impact:

Metro User Guide

4.7. Admin/Config Impact:

4.7.1 Unified Configuration

A new deployment descriptor/configuration file will be supported for web service configuration. No changes to GlassFish GUIs, CLI, agents, plugins are expected however.

4.8. HA Impact:

Cluster support is a planned feature of the module. We have additional requirements on GlassFish HA API module - see section 4.1.2 for more details

4.9. I18N/L10N Impact:

Not anticipated.

4.10. Packaging, Delivery & Upgrade:

4.10.1. Packaging

Proposal will affect only the existing set of Metro OSGi bundles already shipped with the GlassFish server.

4.10.2. Delivery

No impact on delivery. The module is already included in the distribution.

4.10.3. Upgrade and Migration:

All changes either introduce a new functionality or are intended to remain backward-compatible. There is no known impact on existing instances or clients at this time.

4.11. Security Impact:

Metro security is fully aligned with GlassFish security concepts, mechanisms and APIs.

4.12. Compatibility Impact

Metro HA feature has a dependency on the GlassFish 3.1 HA API module. As such Metro 2.1 will only work with GlassFish 3.1 or later, unless the Metro 2.1 OSGi module is modified to bundle HA API classes. Another option is to generate a separate Metro 2.1 OSGi bundle for GlassFish 3.0.x.

Newly updated WS-AT implementation will not be fully backward compatible with the existing implementation in case of applications developed using the "from Java" programming model. Additional annotation or entry in the external Metro configuration file will have to be added to re-enable WS-AT capability of such applications. A migration path will be documented as part of the official Metro User's Guide.

4.13. Dependencies:

4.13.1 Internal Dependencies

4.13.2 External Dependencies

Metro

4.14. Testing Impact:

Existing Metro test suite will be extended with additional SQE, E2E and unit tests as appropriate for each feature of the project.

Metro 2.1 One Pager

1. Introduction

1.1. Project/Component Working Name:

1.2. Name(s) and e-mail address of Document Author(s)/Supplier:

1.3. Date of This Document:

2. Project Summary

2.1. Project Description:

2.2. Risks and Assumptions:

2.2.1 Policy Alternatives in Metro Security