Message Transportation Through FTP Binding Component

As illustrated in Figure, the FTP Binding Component uses directories on the FTP server as message persistence where service consumers and service providers exchange messages. In the current implementation, some assumptions are made so that there is a controlled transport of messages in the FTP context. This is true when multiple components access a directory.

The following are assumptions made under the current implementation.

1. Each service operation with FTP binding has an endpoint information like host name, port, account login, password and so forth. This information specifies a message exchange area on the remote FTP server where both the consumer and provider communicate.

   For example, in the case of a request/response type operation, the following is performed in the message area during message transport from the consumer to the provider (request - IN-Route) and from the provider to the consumer (response - OUT-Route):

   1. Consumer: Staging (Put) request

   2. Consumer: Expose (Rename to target location) request to provider when staging completes

   3. Provider: Poll (Get periodically) request

   4. Provider: Archive/Remove request after received

   5. Provider: Staging (Put) response

   6. Provider: Expose (Rename to target location) response to consumer when staging completes

   7. Consumer: Poll (Get periodically) response

   8. Consumer: Archive/Remove response received

   Figure: Message Transportation

   

   The message exchange area is a dedicated directory on the remote FTP server. The FTP Binding Component or the Administrator can create subdirectories (which serve as archiving area, staging area, exchange area, and so on) during runtime. This is similar to the queues and topics in the JMS paradigm.

2. The service consumer and the service provider either login using the same FTP account (they share the same FTP context - For example, login home where all relative paths are referred), or use different accounts for a given service. If different accounts are used, an administrative configuration is needed to ensure that the login home is mapped to the same location on FTP server. Appropriate access rights have to be granted according to the chosen scenario.

3. Different service operations use dedicated message exchange areas on the remote FTP server. There is no overlapping between the base directories.

4. FTP file names are leveraged so that the consumers and providers can push and poll messages between them. For example, consumers post request messages into the FTP file with names that match the .msg pattern. The corresponding providers use the same pattern to retrieve these request messages from the agreed location. A similar process occurs for the response routing from providers to consumers. Numerous patterns are available for configuration of a particular message transfer (implemented as FTP Binding Component extensibility elements: ftp:message, ftp:messageActivePassive (deprecated), ftp:transfer). These ensure that the messages posted get polled according to their name pattern.

   ---

   Note - Request-response messages cannot be correlated across FTP.

   ---

5. The FTP files serve as intermediary message persistence on FTP server. The names of the FTP files are leveraged to support Request-response correlation. The scenario works as follows:

On the Consumer Side:

The message routing starts with the consumer who invokes a service (INVOKE in BPEL script). On the other side of the NMR, FTP Binding Component OutboundProcessor accepts the request message, de-normalizes the message and labels the message body (which is the payload to a FTP file) with name as req (Refer to Figure: Message Transportation).

The consumer thread (FTP Binding Component OutboundProcessor) spawns off a ResponsePoller thread which starts polling a response with name resp.

The request is fetched when resp becomes available at the location agreed between the consumer and provider. This completes the request-response correlation sequence. The fetched message is wrapped up as a normalized message and sent into NMR using the same Message Exchange ID. This ensures that the response is available as the OUT variable of the INVOKE activity in the BPEL script.

Figure: UUID Tagged Response Message

On the Provider Side:

The provider polls (RECEIVE activity in BPEL) the message receiving area (agreed between the consumer and provider) for a request. The provider polls for a request with the FTP file name pattern req.%u, where %u denotes any string that matches the pattern of a typical UUID in the string form (refer to JDK java.util.UUID - since 1.5) (refer to Figure 1: Message Transportation).

The UUID tag is extracted from the file name upon receipt of the request message (polled from remote FTP directory). The tag is attached as metadata for the message exchange. The payload is wrapped in a normalized message and sent into the NMR. The request message participates in any business logic in the service unit. A response is sent to the NMR with the same message exchange (ME - attached with meta information including the UUID tagged with the request). The OutboundProcessor fulfills the contract by associating the message to a FTP file named as resp. See Figure 3: UUID Tagged Response Message for examples of UUID tagged response messages. This completes the request-response correlation.