Index Changes
Page Difference

Difference between version and version     

Back to FTPBC Features, or FTPBC Features Info


At line 7 removed 1 line.
**ftp:messageActivePassive - specify message transportation between a service consumer and service provider via FTP but allow consumer and provider has different FTP active/passive mode
At line 18 changed 1 line.
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, ftp:messageActivePassive)
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)
At line 22 changed 1 line.
extensibility elements ftp:message, ftp:messageActivePassive are symetrical in that both service consumer and service provider use the same WSDL in their implementation
extensibility elements ftp:message is symetrical in that both service consumer and service provider use the same WSDL in its implementation
At line 25 added 2 lines.
** FTP/TLS (RFC 2228 + RFC 4217) - Explicit SSL
** FTP/TLS - Implicit SSL
At line 62 removed 1 line.
__SOAP FTP Binding Illustrated__
At line 64 added 28 lines.
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).
At line 65 removed 1 line.
For a legacy data transfer protocol like FTP, the SOAP FTP binding is straight forward, for a typical request-response message exchange pattern, the request SOAP envelop is transported as FTP data (through data channel) and persisted as a file on the remote FTP server, the target file and the target directory will be used to communicate to the next hop, i.e, the next hop on the SOAP message path will pick up the request at the "location" agreed between sender and receiver, as illustrated below:
At line 67 removed 80 lines.
\\
[{Image src='http://alaska.stc.com:10000/alaska/attach/FTP/SOAP_REQ_RESP.JPG' align='left' caption=''}]
\\
\\
This is a sync request-response one hop SOAP message exchange, using the FTP persistence storage as message exchange area, it is easy to construct a multi-hop scenario of SOAP message processing.
\\
\\
By inserting correlation ID as part of the SOAP header information, it is easy to construct a async scenario.
\\
\\
Note, as can be seen from above description, SOAP message remains opaque to the FTP BC, i.e., SOAP processing are not in the scope if the FTP BC functions, it is the application (e.g. business logic in SU) that is responsible to handle semantics in SOAP message;
!!4. Symetrical WSDL and design of ftp:transfer
\\
\\
FTP BC WSDL is designed complying with JBI message exchange pattern paragdim, and message direction is alway from the point of view of provider:
\\
\\
In each route, there are two actors: sender / receiver
\\
\\
__IN-OUT:__
\\
\\
this MEP has two routes:
\\
\\
__IN-route:__
consumer --[send]--> persist storage -- [receive] --> provider
\\
\\
__OUT-route:__
consumer <--[receive]-- persist storage <-- [send] -- provider
\\
\\
[{Image src='http://alaska.stc.com:10000/alaska/attach/FTP/WSDL_INPUT_OUTPUT.JPG' align='left' caption=''}]
\\
\\
[{Image src='http://alaska.stc.com:10000/alaska/attach/FTP/FTP_TRANSFER_ATTRIBUTES.JPG' align='left' caption=''}]
\\
\\
[{Image src='http://alaska.stc.com:10000/alaska/attach/FTP/REQUEST_RESPONSE_FLOW.JPG' align='left' caption=''}]
\\
\\
Note:
\\
\\
in the above sequence diagram, request' and request" are not necessorily
the same due to pre/post (or staging) operations.
\\
\\
for the same reason, response' and response" are not necessorily
the same.
\\
\\
__OneWay:__ OneWay is treated as one route of the above two routes,
either IN-route, which is "notification", or OUT-route,
which is soliciting.
\\
\\
!!__???FTP BC as FTP server???__
\\
\\
Discussion has been held for this specific FTP BC mode, i.e., with an FTP server running inside the BC (e.g. listening on command port 21, and data port 20), here are the issues need to be further investigated:
\\
\\
(1) standard compliance issue, if the server receive FTP commands such as 'ACCT', 'PORT', 'STOR' etc. on the command channel and afterwards read a data (payload/message depends how you view it) from a client, according to RFC 959, it can only persist it to a local file - nothing else, if we pass the message to the next hop, this is not defined behavior in RFC 959, so it is no longer a FTP server.
\\
\\
(2) if we implement it as a ServerSocket listening on port 21 and just pass along the packets to the next hop, then it is a proxy, it does not even need to understand FTP protocol.
\\
\\
(3) what is the real life use case for a FTP server built inside a FTP BC.
\\
\\
(4) implementing a full blown FTP server is involved, though there are open source FTP server (may be).
\\
\\
So we leave this particular FTP BC mode open for further comments.
\\
\\
At line 148 removed 7 lines.
!! Schedule
!! Known Bugs to be fixed
!! Engineering Tasks
!! Release Criteria
!! Release Artifacts (will include a list of all jar files and third-party jar files)
* Runtime JBI module
* Design-time Netbeans module
G'day, Anonymous Guest

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-8) was last changed on 02-Aug-08 08:23 AM, -0700 by jimfu