The Java WS Core is an implementation of the Web Services Resource Framework (WSRF) and the Web Service Notification (WSN) family of standards. It provides APIs and tools for building stateful Web services.

2. Feature Summary

New Features in the GT 4.1.1 release

Persistent HTTP/S connection support (client and server side)
Support for SOAP with Attachments (DIME, MIME, and MTOM formats). See the SOAP Attachements section for details.
Dynamic deployment support for the standalone container. See the Java WS Core Container Dynamic Deploy Design Document for more information.
WS-Enumeration support. See the Java WS Core WS-Enumeration Design Document for more information.
JBOSS 4.0.x support.
The TargetedXPath query dialect implementation that enables simpler and more efficient querying of resource property documents.

Other Supported Features

A standalone and embeddable container
Tomcat 4.1, 5.0, and 5.5 support
Basic API for resource persistence and recovery
Persistent subscriptions support
Automatic service and ResourceHome activation on startup
Operation providers

Deprecated Features

None

3. Changes Summary

The following changes have occurred for Java WS Core since the last stable release, 4.0.4:

3.1. New command line tools

The globus-validate-descriptors command line tool is used to validate the Web Services Deployment Descriptor (.wsdd) files, JNDI configuration files (jndi-config.xml), and security descriptors for all services.
The globus-check-environment command line tool is used to display component version information and to validate JVM version.
The globus-reload-container, globus-remote-deploy-gar, and globus-remote-undeploy-gar command line tools (see the dynamic deployment feature for details).
The ws-enumerate-start, ws-enumerate, and ws-enumerate-end command line tools (see the WS-Enumeration support feature for details).
The globus-xpath-query command line tool for querying the resource property document of a resource using the new TargetedXPath query dialect.

3.2. New common command line options

-t, --timeout option is used to configure the client-side timeout value.

3.3. Standalone container changes

A new -i command line option was added to globus-start-container to force the container to bind to the specified network address.
globus-start-container now performs a JVM version check to ensure that at least Java 1.4 JVM is used to start the container.
The OutOfMemoryError error handling was improved in the standalone container. All ResourceHome caches will now be automatically cleared on OutOfMemoryError error.
SOAP requests containing attachments will now be handled correctly by the container.
The globus-start-container-detached, and globus-stop-container-detached tools now support options for specifying alternative log and pid file locations.
Adjusted the number of threads used by the container in standalone and embedded mode. By default the container in standalone mode will now have a minimum of 2 threads and a maximum of 20. The container in embedded mode will now have a minimum of 1 thread and maximum of 3 threads.

3.4. GAR deployment/undeployment changes

globus-deploy-gar will NOT overwrite the existing GAR deployment by default now. The existing deployment must be undeployed first or the GAR must be deployed with -overwrite option.
During GAR deployment the service configuration files such as .wsdd files, jndi-config.xml file, and security deployment descriptors will now be automatically validated.
Client-side type mapping will now be properly removed during GAR undeployment.
Both GAR deployment and undeployment operations now explicitly check if the container is currently running. If so, the operation is aborted. The container must be off before deploying or undeploying GAR files.
globus-deploy-gar and globus-undeploy-gar tools can now deploy or undeploy a GAR file directly from Apache Tomcat with the -tomcat option.
The command line syntax of the globus-deploy-gar and globus-undeploy-gar tools has changed. The tools now expect the options first followed by the required arguments.

3.5. Simpler local invocation

It is now easier to make local invocations. Axis' MessageContext does not need to be associated with the current thread anymore and the stub does not need to be configured in any way to make local invocations.

3.6. Other changes

A new MessageContextHelper API were added to help in associating an arbitrary MessageContext object with the current thread of execution.
A new EPRResourceContext API was added to help obtaining ResourceKey, ResourceHome, or the resource object associated with a given WS-Addressing endpoint.
GLOBUS_TCP_SOURCE_PORT_RANGE environment property is now supported.
The test framework was extended to allow for execution of a specific test suite or a specific set of test cases within a test suite (Bug 3668).
A new Version API were added to obtain Java WS Core version information programmatically.
A new JNDIUtils.getInitialContext() method was added to obtain the right JNDI registry. This is now the preferred way of getting the InitialContext as it will work correctly on any application server with other JNDI implementations present.
Added support for Sun Java SE 6 RC.
Added init.d start/stop script for the standalone container. Please see the Configuring Java WS Core for details.
A resource cache can now be configured with a size limit (in addition to a timeout).
A persistent resource object (when used with ResourceHomeImpl) can now have a private or protected no-argument constructor.
The factory parameter for simple Java Bean resources declared in the jndi-config.xml files is now optional. By default, the org.globus.wsrf.tools.jndi.BeanFactory factory class will be used if the factory resource parameter is not specified.
A launch script for the myproxy Java command line tool will now be created on Windows.
Added error codes to all error messages generated by Java WS Core.
The setTerminationTime() function can now throw a TerminationTimeRejectedException if the new termination time cannot be accepted by the service.
Changed the timestamp format of the container log file to ISO 8601 complaint format. The new format has the following syntax: YYYY-MM-DDThh:mm:ss,sss[+-]hh:mm. It uses local time with UTC time zone offset.

3.7. Updated 3rd party libraries

CoG JGlobus (see the CoG JGlobus Release Notes for more details)
Apache Xerces 2.7.1
OpenSAML 1.1
BouncyCastle 1.31
Apache Log4j 1.2.13
Apache Commons Logging 1.1
Apache Commons CLI 2.0 (latest snapshot)
Switched to JNDI Naming library from the Apache Directory Project.
Post 1.4 version of Apache Axis. Please see Axis changes for details.

3.8. Axis changes

GT 4.1.1 release contains a newer version of Apache Axis. The following changes have been noted in Axis:

xsd:group handling has changed. A Java Bean will NOT be generated now for a xsd:group type. See AXIS-1525 for more details.
The ordering of the parameters of the constructors of the generated Java Beans has changed once again. It is recommended to avoid the full constructors of the generated Java Beans. Use individual setter functions to set the values of the Bean instead.
An error will now be raised by BeanSerializer when serializing a null value that is not optional or non-nillable. This behavior can be disabled by setting BeanSerializer.errorOnNullWithNonNillableElement system property to false. Example:
```
export GLOBUS_OPTIONS="-DBeanSerializer.errorOnNullWithNonNillableElement=false"
```
WSDL2Java will not generate Java Beans for certain array objects. The -w option must be passed to WSDL2Java to force it to generate the Java Beans for such types. This change is transparent to the users of the build scripts provided by Java WS Core.
MTOM attachments are now supported.

4. Bug Fixes

Bug 2921: Support for TerminationTimeChangeRejectedFault
Bug 2926: Local transport does not work without a current MessageContext
Bug 3736: log4j timestamps are not ISO 8601 compatible
Bug 4117: ReflectionResourceProperty throws Exception
Bug 4126: Wrong method invoked when Delegation Service is used
Bug 4204: WorkManagerImpl incorrectly implements the WorkManager.schedule(...) method
Bug 4209: globus-start-container-detached log and pid file selection
Bug 4227: QueryResourceProperites xpath dialect doesn't handle namespaces
Bug 4324: ServiceContainer reports failed startup at incorrect severity
Bug 4325: Exceptions of type 'expectedType' could be more useful
Bug 4595: wsrf-query with a bad XPath query returns 'null'
Bug 4622: globus-ws container.log file
Bug 4679: ServiceHost.getBaseURL() incorrect in Tomcat
Bug 4842: Incorrect default ports used in ServiceURL
Bug 4636: WorkManager configuration broken
Bug 5006: Configuration error does not print file name in error message
Bug 5048: Deadlock during container startup with GT from HEAD

5. Known Problems

The following problems and limitations are known to exist for Java WS Core at the time of the 4.1.1 release:

5.1. Limitations

WS-Notification support:
- Only the Simple topic dialect is supported (others can be added)
- Only flat topic spaces are supported (architecture does allow for more advanced structures)
- Actions on the precondition, selector and policy fields in a subscription are not supported
- When a resource is removed its subscriptions are not removed automatically
Only XPath resource property queries are supported (others can be added)
A resource might not get destroyed at the exact time as indicated by the scheduled termination time. A sweeper thread that removes expired resources runs periodically (every 1 minute by default) so an expired resource might not get removed until the next time the sweeper thread runs.

5.2. Known Bugs

Bug 2471: Message security signature verification issues
Bug 2445: Same input and output messages in WSDL confuse Axis
Bug 3113: Processing by the WSDLPreprocessor produces output different depending on the JVM
Bug 3482: wsa:From is not set correctly when service calls another service
Bug 3483: xsd:anyType not serialized correctly
Bug 4432: SimpleTopic.notify(SOAPElement element) drop child elements

6. Technology Dependencies

Java WS Core depends on the following GT components:

Java CoG Kit

Java WS Core depends on the following 3rd party software:

Please see Java WS Core Technical Dependencies Details for details.

7. Tested Platforms

Java WS Core should work on any platform that supports J2SE 1.4.1 or higher.

Tested platforms for Java WS Core:

Linux (Debian 3.1)
Windows XP
Solaris 9

Tested JVMs for Java WS Core:

Sun JVM 1.4.2, 1.5.0, and 1.6.0 RC
IBM JVM 1.4.1, and 1.4.2
BEA JRockit JVM 1.5.0

JVM notes:

GCJ is not supported.
If using IBM JVM 1.4.1 please see bug 2828 for more information.

Tested containers for Java WS Core:

Java WS Core container
Tomcat 4.1.34
Tomcat 5.0.30
Tomcat 5.5.20
JBoss 4.0.2

8. Backward Compatibility Summary

Protocol changes since GT version 4.0.4

No changes.

API changes since GT version 4.0.4

The ReflectionResourceProperty now throws ResourcePropertyException instead of Exception.
Since the Axis version was upgraded the Axis generated classes might be slightly different in certain cases. Please see Axis changes for more details.

Schema changes since GT version 4.0.4

No changes.

Other changes since GT version 4.0.4

globus-deploy-gar will NOT overwrite the existing GAR deployment by default now. Please see GAR deployment/undeployment changes for more details.
The command line syntax of the globus-deploy-gar and globus-undeploy-gar tools has changed. The tools now expect the options first followed by the required arguments.

9. Associated Standards

Associated standards for Java WS Core:

10. For More Information

Please see Java WS Core for more information.

Prev	Up	Next
How-tos for Java WS Core	Home	GT 4.1.1 Java WS Core : System Administrator's Guide