See: Description
Interface | Description |
---|---|
IncomingSOAPRequestActivity |
An incoming request activity, created when a SOAP request is
received by the RA.
|
OutgoingSOAPRequestActivity |
An outgoing request activity, created when an application sends
a SOAP request.
|
SOAPActivity |
Superclass for SOAP request and response activities.
|
SOAPActivityContextInterfaceFactory |
SOAP Activity Context Interface Factory, implemented by the SLEE.
|
SOAPEvent |
Superclass for events carrying a SOAP message payload.
|
SOAPProvider |
Provider interface for applications that want to process or
send SOAP requests.
|
SOAPRequest |
A SOAP request event.
|
SOAPResponse |
A SOAP response event.
|
The Rhino SLEE SOAP Resource Adaptor allows SLEE services to receive SOAP requests as events, and initiate SOAP requests to external systems.
The SOAP RA uses the
SAAJ API
(previously part of JAX-RPC) to represent SOAP messages in both
requests and responses. The SOAPMessage
class is
the top-level object used to represent a SOAP message, for both
request and response payloads.
The
SOAPProvider
provider interface provides methods to obtain
appropriate javax.xml.soap.MessageFactory
and
javax.xml.soap.SOAPFactory
instances. These methods should
be used in preference to the SAAJ newInstance()
methods, as
using newInstance()
is likely to fail in a SLEE environment
due to classloader structure.
SBBs can obtain a SOAPProvider
instance via JNDI
by specifying an appropriate <resource-adaptor-entity-binding>
entry in the SBB deployment descriptor.
When the SOAP RA receives a SOAP request, it creates a new
IncomingSOAPRequestActivity
activity and fires a
SOAPRequest
event on that activity. The address of
the fired event is the requested URL path (from the HTTP request line)
(NB: address is Not Yet Implemented).
Services that are interested in handling SOAP requests should:
To respond to a request, a SBB should use the
IncomingSOAPRequestActivity.sendResponse()
method, providing
the SOAP message to send as a response. This can be done either directly
from the SOAPRequest event handler, or asynchronously at some later point
(for example, after data for the response has been collected from a separate
external system). When a response is provided, the IncomingSOAPRequestActivity
is automatically ended by the resource adaptor.
If no SBB processes a SOAPRequest event, or if there is no SOAP response provided by a SBB within a configurable timeout, the SOAP RA will send a SOAP Fault response and end the IncomingSOAPRequestActivity.
The SOAPProvider interface provides methods that allow SBBs to send synchronous or asynchronous SOAP requests.
SOAP requests consist of a SOAPMessage payload and a URL specifying the
location to deliver the request to. Responses consist of a SOAPMessage payload,
and HTTP-level status codes (numeric code and reason), encapsulated together in
the SOAPResponse
class.
If a connection error or HTTP-level error occurs such that no SOAP response is available from the remote server, a SOAP response containing an appropriate SOAP fault is synthesized and returned.
Synchronous SOAP requests are made by invoking the
SOAPProvider.sendSyncRequest()
method. This method blocks until a response is available, and
returns that response.
Asynchronous SOAP requests are initiated by invoking the
SOAPProvider.sendRequest()
methods. These methods causes a new
OutgoingSOAPRequestActivity
activity to be created and associated with the request. When the
request completes, a SOAPResponse
event is fired on
the outgoing activity. SBBs that wish to receive the response
should attach to the activity returned by sendRequest
.
By default, an outgoing SOAP request activity is ended when a response
is received. This can be prevented by passing false
as
endOnResponse
when calling sendRequest()
.
In this case, the outgoing activity must be explicitly ended by a
SBB calling OutgoingSOAPRequestActivity.endActivity()
when the activity is no longer needed.
The SOAP resource adaptor has a number of configuration properties: