FTP BC features

• FTP BC WSDL extensibility elements:
  • ftp:transfer - specify message transportation involving a sending party and a receiving party via FTP
  • ftp:message - specify message transportation between a service consumer and a service provider via FTP
  • ftp:address - specify endpoint for message transportation via FTP
  • ftp:binding - specify a FTP binding indication
  • ftp:operation - specify a FTP operation indication

• Design Time WSDL Semantic Validation

validate the WSDL at design time for such things as attribute values and relationship between extensibility elements, etc.

• Message Correlate For Synchronous Request-Response Service Invoking

a file name tagging scheme that is implemented by the BC to help correlating the request with the response for a synchronous service invoke, user can enabled to by configuring an attribute value for one of the transfer extensibility elements (ftp:transfer, ftp:message)

• Symetrical WSDL For Service Definition

extensibility elements ftp:message is symetrical in that both service consumer and service provider use the same WSDL in its implementation

• External Protocols
  • FTP (RFC 959)
  • FTP/TLS (RFC 2228 + RFC 4217) - Explicit SSL
  • FTP/TLS - Implicit SSL

• Directory Listing Styles
  • UNIX
  • AS400
  • AS400-UNIX
  • HCLFTPD 6.0.1.3
  • HCLFTPD 5.1
  • HP NonStop/Tandem
  • MPE
  • MSFTPD 2.0
  • MSP PDS (Fujitsu)
  • MSP PS (Fujitsu)
  • MVS GDG
  • MVS PDS
  • MVS Sequential
  • Netware 4.11
  • NT 3.5
  • NT 4.0
  • VM/ESA
  • VMS
  • VOS3 PDS (Hitachi)
  • VOS3 PS (Hitachi)
  • VOSK (Hitachi)
  • UNIX (EUC-JP)
  • UNIX (SJIS)

• Proxies
  • SOCKS4
  • SOCKS5

• Pre and Post Operations
  • DELETE - for post GET operation
  • COPY - for post GET operation
  • RENAME - for pre GET, post GET, and post PUT operation

Message FTP Binding and Synchronous Request-Response Service Invoking

When FTP protocol is used as message transportation between service consumer and service provider, we mean the following:

   +-----------+         +--------------+        +-----------+                  
   |           |         |  FTP server  |        |           |
   |           |         |  +--------+  |        |           |
   |           |  req    |  |  MSG   |  |  req   |           |
   |WS consumer+----------->|  AREA  |---------->|WS provider|
   |           |         |  | (dirs) |  |        |           |
   |(FTPclient)|         |  |        |  |        |(FTPclient)|
   |           |  resp   |  |        |  |  resp  |           |
   |           |<-----------|        |<----------|           |
   |           |         |  |        |  |        |           |
   |           |         |  +--------+  |        |           |
   +-----------+         +--------------+        +-----------+                  

What shown in the illustration is a full message path including request (IN-ROUTE) and response (OUT-ROUTE).

In addition to Request-Response message transfer, there are One-Way-In, One-Way-Out message transfer.

Note, the service consumption could be synchronous, where WS consumer post the message to a location agreed between consumer & provider and polling the response from a location agreed between consumer & provider, or asynchronous, where WS consumer post the message to a location agreed between consumer & provider then leave, a separate response poller could poll the response from an agreed place.

Request-Response correlating:

if request must be correlated to response, FTP BC supports a mechanism called: message name GUID tagging, where a GUID is generated at the origin of the request message (service consumer) and tagged to the message file name, FTP BC implementation will keep the GUID tagging on the requst message file, request message staging file, the corresponding response message file, response message staging file, all the way to the point where the response message with the same GUID tag is picked up by the original service consumer, for details about this FTP file name GUID tagging, please refer to "FTP BC Functional Spec" at FTP BC wiki main page.

Application level message correlating can be done also by embedding correlate ID into the message and perform message correlating in the application (e.g. BPEL scripts).

This page (revision-8) was last changed on 02-Aug-08 08:23 AM, -0700 by jimfu.
This page was created on 01-Dec-06 18:04 PM, -0800 by jimfu.

More info...