Table of Contents
There are two main parts to the Java WS Core programming model: the service and the resource. The service performs the business logic on the resource, and the resource represents the managed state. The web service is just a stateless POJO (Plain Old Java Object) that discovers the resource associated with the request and then performs operations on that resource. The resources are managed and discovered via ResourceHome implementations. The ResourceHome implementations can also be responsible for creating new resources, performing operations on a set of resources at a time, etc. The ResourceHome implementations are configured in JNDI and are associated with a particular web service. JNDI is a central transient registry that is mainly used for discovery of ResourceHome implementations but it can be used to store and retrieve arbitrary information. The web services are configured in the Web Services Deployment Descriptor (WSDD).
WSDL in document/literal style is assumed as a starting point for writing
a service. A number of generic interfaces are defined so that custom implementations
of these interfaces can be used instead of the default implementations
included in the Java WS Core. No special base classes are required for
a web service or resource implementation. However, the resource object
at minimal must implement the org.globus.wsrf.Resource interface
(it defines no operations; it is used just as a marker interface). The
service developer can pick and choose which other resource interfaces the
resource object should implement to tailor the implementation to his/her
needs.
Stable API:
- org.globus.wsrf.Resource
- org.globus.wsrf.ResourceKey
- org.globus.wsrf.ResourceProperty
- org.globus.wsrf.ResourcePropertyMetaData
- org.globus.wsrf.ResourcePropertySet
- org.globus.wsrf.ResourceProperties
- org.globus.wsrf.ResourceHome
- org.globus.wsrf.ResourceLifetime
- org.globus.wsrf.ResourceIdentifier
- org.globus.wsrf.ResourceContext
- org.globus.wsrf.RemoveCallback
- org.globus.wsrf.PersistentCallback
- org.globus.wsrf.Subscription
- org.globus.wsrf.Topic
- org.globus.wsrf.TopicList
- org.globus.wsrf.TopicListMetaData
- org.globus.wsrf.TopicAccessor
- org.globus.wsrf.TopicListener
- org.globus.wsrf.TopicListenerList
Less stable API:
- org.globus.wsrf.NotificationConsumerCallbackManager
- org.globus.wsrf.NotificationConsumerManager
- org.globus.wsrf.NotifyCallback
- org.globus.wsrf.encoding.ObjectSerializer
- org.globus.wsrf.encoding.ObjectDeserializer
- org.globus.wsrf.impl.SimpleResourceKey
- org.globus.wsrf.impl.BaseResourceProperty
- org.globus.wsrf.impl.ReflectionResourceProperty
- org.globus.wsrf.impl.SimpleResourceProperty
- org.globus.wsrf.impl.SimpleResourcePropertyMetaData
- org.globus.wsrf.impl.SimpleResourcePropertySet
- org.globus.wsrf.impl.ResourceContextImpl
- org.globus.wsrf.impl.ResourceHomeImpl
- org.globus.wsrf.impl.SingletonResourceHome
- org.globus.wsrf.impl.ServiceResourceHome
- org.globus.wsrf.impl.ResourcePropertyTopic
- org.globus.wsrf.impl.SimpleTopic
- org.globus.wsrf.impl.SimpleTopicList
- org.globus.wsrf.impl.SimpleTopicListMetaData
- org.globus.wsrf.query.QueryEngine
- org.globus.wsrf.query.ExpressionEvaluator
- org.globus.wsrf.topicexpression.TopicExpressionEngine
- org.globus.wsrf.topicexpression.TopicExpressionEvaluator
- org.globus.wsrf.utils.FaultHelper
- org.globus.wsrf.utils.XmlUtils
- org.globus.wsrf.utils.AddressingUtils
- org.globus.wsrf.container.ServiceHost
The complete Java WS Core API.
Java WS Core contains an implementation of the following specifications. Please see the corresponding specifications for details:
Please see the Java WS Core Command Reference.
There is no support for this type of interface for Java WS Core.
Please see Java WS Core Configuration.
Table 1. Globus standard environment variables
| Name | Value | Description | Comments |
| GLOBUS_LOCATION | <path> | The <path> is the root location of the Java WS Core installation. Must be an absolute path. | Required |
| GLOBUS_TCP_PORT_RANGE | <min,max> | The <min,max> is the minimum and maximum port range for TCP server sockets (useful for systems behind firewalls). For example, if set, the notification sink on the client will be started within that port range. | Optional |
| GLOBUS_UDP_SOURCE_PORT_RANGE | <min,max> | The <min,max> is the minimum and maximum port range for UDP outgoing sockets (useful for systems behind firewalls). | Optional (since GT 4.0.1) |
| GLOBUS_HOSTNAME | <host> | The <host> is either a hostname or ip address. The host ip address under which the container and services will be exposed. | Optional |
Table 2. Launch script specific environment variables
| Name | Value | Description | Comments |
| GLOBUS_OPTIONS | <arguments> | The <arguments> are arbitrary arguments that can be passed to the JVM. See below for a detailed list of supported options. | Optional |
| JAVA_HOME | <path> | The <path> is the root location of the JVM installation. If set, the JVM from that installation will be used. Otherwise, the first one found in path will be used. | Optional |
| CLASSPATH | <classpath> | This environment property is ignored by launch scripts. | Ignored |
Table 3. Options supported by the GLOBUS_OPTIONS environment property
| Name | Value | Description | Comments |
| -Dorg.globus.wsrf.proxy.port | int | This property specifies the port number of the proxy server. The proxy server must run on the same machine as the container. This setting will cause the service address to have the port of the proxy instead of the container (only applies to code that uses the ServiceHost or AddressingUtils API. | |
| -Dorg.globus.wsrf.container.server.id | string | This property specifies the server id. The server id is used to uniquely identify each container instance. For example, each container gets its own persistent directory based on the server id.
In GT 4.0.0, by default the container will store the persistent resources under the ~/.globus/persisted/<ip>/ directory. Therefore, if there are multiple containers running as the same user on the same machine the same directory will be used for the persistent resources. That might cause the containers to overwrite each other's persistent data. However, this conflict is less likely in GT 4.0.1+ because of better server id defaults. In GT 4.0.1+, by default the standalone container will store the persistent resources under the ~/.globus/persisted/<ip>-<containerPort> directory. While in Tomcat the ~/.globus/persisted/<ip>-<webApplicationName> directory will be used instead.
This property overwrites the default server id and therefore indirectly controls which storage directory is used by the container. If set, the container will store the persisted resources under ~/.globus/persisted/<server.id>/ instead.
| |
| -Dorg.globus.wsrf.container.persistence.dir | directory | This property specifies the base directory that will be used for storing the persistent resources. This property overwrites the default (~/.globus/persisted/) base directory assumed by the container. | Since GT 4.0.2 |